[LACNIC/Politicas] LAC-2012-011 - Nueva versión (2) / Nova versão (2) / New version (2)

Arturo Servin aservin at lacnic.net
Mon Oct 8 09:42:34 BRT 2012 

Gustavo,

	Usando tu ejemplo (hacking) sería la misma responsabilidad de que
alguien lograra tener acceso a los DNSs de zonas reversas e hicieran que
el correo del "address holder" se fuera a SPAM. O como menciona Roque la
modificación del WHOIS.

	El detalle, como mencioné lo consulto.


Saludos,
as

On 08/10/2012 10:20, Gustavo Lozano wrote:
> Arturo,
> 
> Comentarios entre lineas.
> 
> 2012/10/8 Arturo Servin <aservin at lacnic.net>
> 
>>
>>         No soy abogado, voy a remitir tu pregunta al canal legal, pero por
>> lo pronto de acuerdo al manual de políticas:
>>
>> "
>>         2.3.2.9. Non-Guaranteed Routability
>> Portable (provider-independent) IPv4 addresses allocated by LACNIC or NIRs
>> are not guaranteed to be globally routable.
>> These problems shall be solved between the holders of the IPv4 addresses
>> involved and their connectivity provider or providers. In those cases
>> deemed necessary, LACNIC shall provide the necessary guidance.
>> "
>>
>>
> Esperemos la interpretacion de legal al respecto.
> 
>         Además en los casos de un error en algun componente del sistema
>> (repositorio, sistema hosteado, up/down) el resultado seria un prefijo con
>> estado de "unknown" que es igual a lo que existe ahora. Si alguien tiene
>> algun ejemplo donde esto no suceda sería bueno analizarlo (por ahora todos
>> me dan unknowm como resultado, incluso el de un certificado con los
>> recursos faltantes).
>>
>>
> Atacante X que desea hacer hijacking de rutas (el hijacking de rutas es uno
> de los argumentos mas fuertes para crear RPKI).
> 
> El atacante X vulnera la seguridad del sistema hosteado de LACNIC y elimina
> los ROA para el prefijo. El atacante X anuncia el prefijo, el ISP tiene
> problemas para recibir trafico, desde la persepectiva del ISP un prefijo
> asegurado por RPKI ha sido secuestrado.
> 
> Si quieres otros escenarios el atacante o un bug en el sistema RPKI LACNIC
> genera ROAs  para mis prefijos con otro AS.
> 
> Slds
>> as
>>
>>
>>
>>
>>
>> On 7 Oct 2012, at 22:33, Gustavo Lozano wrote:
>>
>>> Creo que ya expuse mis argumentos por los cuales seria un error aprobar
>> la
>>> propuesta LAC-2012-011, los cuales aplican para la versión 2 de la misma.
>>>
>>>
>>> Ha sido un buen ejercicio pensar en las ramificaciones de propuestas que
>>> buscan forzar tecnologías en los miembros.
>>>
>>>
>>> Durante mi análisis de esta propuesta, me surge una duda que me gustaría
>>> que el staff de LACNIC me apoyara a resolver:
>>>
>>>
>>> Si la propuesta LAC-2012-011 fuera aprobada, y ratificada por el
>>> directorio, entonces los miembros de LACNIC se verían forzados a
>> desplegar
>>> una tecnología. Si un miembro tuviera problemas (ej. problemas de
>>> visibilidad de sus prefijos) por un error atribuible al sistema de LACNIC
>>> (ej. bug en el sistema RPKI de LACNIC) podría ese miembro buscar una
>>> compensación económica por parte de LACNIC?
>>>
>>> Saludos,
>>> Gustavo Lozano
>>>
>>> 2012/10/5 Max Larson Henry <maxlarson.henry at transversal.ht>
>>>
>>>> Estimados suscriptores de la lista de políticas de LACNIC,
>>>>
>>>> Se recibió una nueva versión (2) de la propuesta de Política
>> LAC-2012-011:
>>>>
>>>> -----------------------------------------
>>>>
>>>> Prezados membros da lista políticas do LACNIC,
>>>>
>>>> Se recebeu uma nova versão (2) da proposta de Política LAC-2012-011 :
>>>>
>>>> -----------------------------------------
>>>>
>>>> Dear Policy-list Members,
>>>>
>>>> There is a new version (2) of the Policy Proposal LAC-2012-011:
>>>>
>>>> It' will be published shortly in the other two LACNIC working languages.
>>>>
>>>> Max Larson Henry
>>>> Nicolas Antoniello
>>>> co-Chairs of Public Policy Forum - LACNIC
>>>>
>>>> ============================================================
>>>>
>>>> DATOS DEL AUTORES:
>>>>
>>>>
>>>> Nombre - eMail - Teléfono (Phone) - Entidad (Organización)
>>>>
>>>> Roque Gagliano - rogaglia at cisco.com - - Cisco Systems
>>>>
>>>> DATOS de la PROPUESTA:
>>>>
>>>>
>>>> Título de la Propuesta: Requerimiento de inscripción en RPKI para
>>>> recursos adicionales
>>>>
>>>> Tipo de propuesta: LACNIC
>>>>
>>>> Id (Si existe): LAC-2012-11
>>>>
>>>> Versión: 2 (Thu Oct 4 06:48:40 2012)
>>>>
>>>> Resumen de la Propuesta: La propuesta consiste en requerir que toda
>>>> entidad buscando recursos adicionales de LACNIC deba
>>>> haber previamente inscripto sus recursos en el sistema RPKI. Se
>>>> entiende que se cumple con este
>>>> requerimiento cuando la entidad cuente con: una o más entidades
>>>> certificadoras registradas en el
>>>> sistema de LACNIC, uno o más certificados RPKI que cubran la totalidad
>>>> de los recursos. S i
>>>> corresponde, uno o más ROAs que cubran la totalidad de los recursos no
>>>> delegados y uno o más
>>>> repositorios públicos donde se pueda obtener esta información sin
>>>> restricciones.
>>>>
>>>>
>>>> Justificación: La implementación actual de RPKI require algunos pasos
>>>> mínimos para que los miembros en el sistema
>>>> de gestión de LACNIC. Muchas veces nos enfrentamos a problemas
>>>> operativos en las entidades. Por
>>>> ejemplo, comúnmente, la persona que opera la red puede no ser la misma
>>>> que utiliza el sistema de LACNIC.
>>>>
>>>> Adicionalmente, como todo sistema de registro, RPKI sufre el problema
>>>> de antiguedad de la
>>>> información almacenada. Con esta propuesta, se le da una herramienta
>>>> al sistema de registro para
>>>> requerir una evaluación de la información en el RPKI cada vez que la
>>>> entidad entra en contacto con
>>>> LACNIC para solicitar recursos adicionales. Herramientas similares ya
>>>> existen en el manual de
>>>> políticas de LACNIC para el registro Whois y DNS reverse.
>>>>
>>>> Con esta propuesta de política, se logran varios objetivos:
>>>> - palear el problema de la antiguedad de la información en el registro
>> RPKI
>>>> - inducir la generación de material criptográfico en el RPKI.
>>>> - educar sobre el RPKI y seguridad en el sistema global de enrutamiento.
>>>>
>>>> El costo para el operador es mínimo (un par de clicks en el sistema de
>>>> LACNIC), siempre que cuente
>>>> con un sistema de gestión de la información.
>>>>
>>>> El costo para LACNIC debería ser mínimo pues no requiere cambios en
>>>> los sistemas de gestión.
>>>>
>>>>
>>>> Texto de la Propuesta: Sección 2.3.4.
>>>> (Se agrega este texto como punto 8 y se renumera el siguiente como
>> punto 9)
>>>>
>>>> 8- El solicitante debe estar al día con sus registro en el sistema de
>>>> certificación
>>>> RPKI. Para ello debe contar con:
>>>> a. una o más entidades certificadoras registradas en el sistema RPKI de
>>>> LACNIC
>>>> b. uno o más certificados válidos (según RFC 6487) de entidad
>>>> certificadora (CA) RPKI que cubran la
>>>> totalidad d e los recursos
>>>>
>>>> Si corresponde, se solicitará que el solicitante verifique que cuenta
>> con:
>>>> c. uno o más ROAs bien formados (según RFC 6482) que cubran la
>>>> totalidad de los recursos no delegados
>>>> d. uno o más repositorios públicos que verifiquen RFC 6481, donde se
>>>> pueda obtener esta información
>>>> sin restricciones.
>>>>
>>>> ---------
>>>> IPv6: Sección 4.5.2.1. Criterio de distribución subsiguiente
>>>> Se adiciona el siguiente texto:
>>>>
>>>> El solicitante debe estar al día con sus registro en el sistema de
>>>> certificación RPKI. Para ello
>>>> debe contar con:
>>>> a. una o más entidades certificadoras registradas en el sistema RPKI de
>>>> LACNIC
>>>> b. uno o más certificados válidos (según RFC 6487) de entidad
>>>> certificadora (CA) RPKI que cubran la
>>>> totalidad de los recursos
>>>>
>>>> Si corresponde, se solicitará que el solicitante verifique que cuenta
>> con:
>>>> c. uno o más ROAs bien formados (según RFC 6482) que cubran la
>>>> totalidad de los recursos no delegados
>>>> d. uno o más repositorio s públicos que verifiquen RFC 6481, donde se
>>>> pueda obtener esta información
>>>> sin restricciones.
>>>>
>>>>
>>>> INFORMACÍON ADICIONAL:
>>>>
>>>>
>>>> Tiempo de implementación: inmediato
>>>>
>>>> Grupo de trabajo: políticas
>>>>
>>>> Propuestas previas relacionadas:
>>>>
>>>> Referencias: http://rpki.lacnic.net
>>>>
>>>> Cambios desde versión anterior: - Pedido de ROAs y repositorios es
>>>> condicional.
>>>> Esto es pues pueden haber razones para no publicar
>>>> ROAs (por ejemplo redes no públicas).
>>>> - Agregué información normativa como fue
>>>> consensuado en la lista.
>>>> - Agregué la justificación relacionada con la
>>>> antiguedad de la información
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>> Gustavo Lozano
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
> 
> 
>

More information about the Politicas mailing list