[LAC-TF] [LACNIC/Politicas] Fwd:I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt

[JORDI PALET MARTINEZ]

Hola Carlos,

Basicamente si a casi todo. Continuo debajo.

Saludos,
Jordi




> De: Carlos Barcenilla <barce at frlp.utn.edu.ar>
> Responder a: "lactf at lac.ipv6tf.org" <lactf at lac.ipv6tf.org>
> Fecha: Thu, 21 Jul 2005 21:42:05 +0200
> Para: "lactf at lac.ipv6tf.org" <lactf at lac.ipv6tf.org>, <politicas at lacnic.net>
> Asunto: Re: [LAC-TF] [LACNIC/Politicas] Fwd:I-D
> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> Hola
> 
>     Con respecto a esta discusión quisiese resumir algunos aspectos de
> lo que se ha dicho, y que me hacen llegar ya a alguna conclusión. Aclaro
> de entrada que solo hablo de casos de IPv6.
> 
>     En lo que respecta a la publicación en WHOIS público, o la cesión de
> los datos por parte de un ISP para las asignaciones de /48 o /56.
> Empiezo resaltando que estas subasignaciones tienen una característica
> muy distinta a las subasignaciones que los ISP hacen a sus clientes en
> IPv4. En IPv4 lo que veo que se registran son subasignaciones de
> bloques, por ejemplo un /24, /25, /26... Tal como están las cosas en
> IPv4 el número de estas asignaciones es "manejable" cómodamente en una
> base de datos, y normalmente a lo que se refieren como "clientes" son
> organizaciones, y no personas particulares, es decir que es muy poco
> probable que estemos hablando de un hogar con ADSL al que se le asigne
> un prefijo IPv4 y se publique en el WHOIS.

En realidad si es lo mismo, porque la politica IPv4 tambien podria pedir que
se registre en el WHOIS a un usuario a partir de determinado tamaño de
prefijo, y las implicaciones serian exactamente las mismas que con IPv6.
Ademas, los ISPs en IPv4 tambien tienen una base de datos que relacionan
cada IP con cada usuario, para la gestion de la red ;-)

>    
>     La asignación de prefijos /48 o /56 a los usuarios residenciales en
> IPv6 hace las veces a los efectos prácticos de lo que es en IPv4 una
> asignación estática de una dirección IP, ya que estas serían las
> unidades "mínimas" de asignación (eventualmente /64). De esta forma, el
> registrar en IPv6 cada asignación y publicarla en WHOIS de este tipo
> sería como hacer lo propio para cada IP que se le asigna a un usuario
> residencial, y esto no se realiza hoy hasta donde yo se.
> 
>     Aclarado el alcance del concepto y sus diferencias paso a resaltar
> algunos puntos según mi opinión, y según he venido leyendo en esta lista:
> 
>     a) Los ISP no verían con agrado el publicar los datos de sus
> clientes particulares. Estos datos son muy importantes a nivel
> comercial, y "cedérselos" gratuitamente a la competencia no veo que les
> haga mucha gracia. Como ejemplo se han citado aquí casos utilización
> inapropiada de estas bases de datos de clientes para propósitos
> comerciales, de publicidad, telemercadeo, fraudes, etc...
> 
>     b) Según leyes de protección de datos personales, y comparando con
> casos como la telefonía, los bloques asignados podrían ser considerados
> datos de este tipo y prohibida su publicación y/o cesión a terceras
> partes. Se comentó el caso europeo, se comentó que en LAC parece que
> solo Argentina tiene una ley de este tipo en la actualidad. Lo cierto es
> que en este aspecto hay tendencias jurídicas y que hoy sea dispar no
> quiere decir que a mediano/largo plazo varios países de la región no
> tengan leyes de este tipo.
> 
>     c) A los usuarios en particular supongo que no les agradaría que se
> publicasen sus datos si fuesen conscientes de sus implicancias. Tengan
> derechos legales o no a oponerse a la publicación. Tengamos también en
> cuenta que si bien a los efectos de asignación estas serían "similares"
> a un número telefónico de hoy, de lo que van a hacer publicidad en todo
> caso los usuarios será de URIs SIP o de direcciones de e-mail
> probablemente, y no de información de red.
> 
>     d) A nivel de seguridad no lo veo tampoco conveniente. Si tengo un
> "enemigo" y puedo acceder fácilmente a sus datos, su bloque IP, etc. Me
> facilitará el lanzar un ataque específico. Se que la seguridad por
> oscuridad no es lo más adecuado, pero tampoco es cuestión de irse al
> otro extremo.
> 
>     e) Dado el estricto direccionamiento jerárquico (provider
> aggregatable) de IPv6, no parece de gran utilidad siquiera conocer el
> nombre de la persona a la que se le asignó el bloque. Con conocer el ISP
> titular del bloque al que pertenece sería suficiente. Ya que a nivel
> operativo de red lo importante es localizar al ISP, y que este proceda
> ante un abuso por parte de un cliente como sea conveniente, y no salir a
> cazar a usuarios individuales. Se imaginan que a un atacante le cuelan
> uno de estos virus zombies, y que éste "destruye" desde ahí decenas de
> computadoras, y los afectados lo encuentran por el WHOIS, y deciden
> hacer justicia por mano propia. En todo caso será, como se ha comentado
> aquí, un juez el que pueda intervenir en caso de juicios por daños y
> perjuicios o lo que corresponda, los datos del usuario los tiene el ISP
> en su base de datos administrativa y los podrá ceder ante requerimiento
> judicial.

Efectivamente, justo lo acabo de indicar asi ;-) Creo que este es el quid de
la question, la obligatoriedad por parte del ISP a tener "limpia" esa base
de datos, pero no publica, salvo que clientes concretos (cosa que dudo que
en general ocurra) pidan la publicacion de sus datos.

> 
>     f) En lo que concierne a la evaluación del HD-RATIO por el RIR para
> la asignación de nuevos bloques, parece ser de utilidad tener los datos
> de las asignaciones, sin embargo, como ya se ha comentado, puede ser que
> según la legislación de algún país esto no esté permitido al ISP.
> Supongamos que el país A tiene esta restricción, entonces no podrá dar
> esa información al RIR, con lo que éste deberá utilizar otros medios
> para evaluar el HD-RATIO. Ahora pensemos que el RIR al país A no pone el
> requisito de registración de cada subasignación, y a los países B, C, D
> si se los pone. ¿no hay una falta de equidad aquí? Entonces tal vez sea
> mejor evaluar para todos de otra forma.

No, creo que los RIRs NO estan haciendo esta verificacion, quizas Ricardo o
German lo pueden confirmar. Ademas, aunque quisieran hacerlo, la ley de
proteccion de datos lo prohibe. Si se desea hacer, como tu bien dices, hay
que buscar otro metodo que sirva para todos los casos. Creo que en gran
medida se busca la confianza entre RIR y LIR, sino, muchas cosas no
funcionarian.

> 
>     Resumiendo, en cuanto a publicar en un WHOIS público los datos de
> asignaciones de /48 o /56 a usuarios particulares: A los ISP no les
> gustaría hacerlo, a la ley no le "gusta" mucho, a los usuarios
> probablemente no les gustaría, a la seguridad no la "beneficia", a la
> operatividad global de la red no brinda ventajas y los RIR podrían vivir
> sin esta información.
> 
>     Como conclusión, veo que casi todos los aspectos son negativos (tal
> vez me los busqué negativos inconscientemente ;) no pareciendo
> recomendable registrar públicamente toda esta información.
> 
>     Pido disculpas por cualquier error conceptual que haya cometido, ya
> que no soy gran experto en la materia, por favor sépanme corregir.
> 
> Saludos.
> Carlos.
> 
>    
> Enrique Torres Angeles escribió:
> 
>> Hola Todos
>> 
>> Les cuento un poco la experiencia que tuvimos aqui en Peru al respecto de la
>> confidencialidad de los datos cuando hace unos años comenzamos a implementar
>> el WHOIS y zonas WHOIS delegadas para alimentar los registros de ARIN.
>> 
>> Con respecto a la declaracion de los datos completos en el WHOIS la
>> problematica que se dio fue la siguiente:
>> 
>> 1- Utilizacion de la base de datos whois por otros operadores de
>> telecomunicaciones para atacar la base de clientes internet de la competencia
>> 
>> 2- Utilizacion de las bases de datos whois para crear bases de datos de
>> publicidad o telemercadeo
>> 
>> 3- Utilizacion en contadas oportunidades para fraudes basandose en la
>> informacion de la base WHOIS.
>> 
>> 
>> Contra esta problematica se opto en dos alternativas y creo que son las que
>> se 
>> deben analizar
>> 
>> 1- Declarar el bloque IP con el nombre de la Organizacion que lo tenia
>> delegado pero en la seccion de contactos administrativos y tecnicos que son
>> los datos visibles se publico la informacion del contacto tecnico y
>> administrativo del ISP que delega el numero.
>> 
>> Internamente existian datos que no eran mostrados donde estaba la data real
>> del usuario.
>> 
>> 2- Tuvimos solo un caso en donde el cliente no quiso que apareciera ninguna
>> informacion sobre el y se declaro como si el bloque estuviera utilizado por
>> el ISP y con sus contactos administrativos y tecnicos.
>> 
>> Cabe mencionar que en este caso fue el que mas complicacion nos creo porque
>> nos llevo a analizar la opcion de añadir un campo que indique el
>> Representante y el Beneficiario del bloque a fin de que solo se publique en
>> el WHOIS los datos del Representante.
>> 
>> 
>> En conclusion lo que les quiero decir es que este no es un problema
>> complicado 
>> de solucionar es un problema mas que todo del tipo administrativo que implica
>> adicionar datos al WHOIS algunos de los cuales no son publicados y definir
>> una opcion al momento de que registra el usuario los datos en que le permite
>> decidir si quiere mantener los datos confidenciales o no.
>> 
>> Es claro que ante los RIR esta opcion no era aplicable era solo aplicable
>> para 
>> declarar la sub delegaciones hechas por el ISP.
>> 
>> 
>> Saludos,
>>            Enrique
>>  
>> 
> 
> _______________________________________________
> LACTF mailing list
> LACTF at lac.ipv6tf.org
> http://lacnic.net/mailman/listinfo/lactf
> 




************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.