[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:48:54 BRT 2012 

	Una aclaración.

On 08/10/2012 10:42, Arturo Servin wrote:
> 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.

	Es decir, invalidará el PTR de un servidor de correo y esto podría
hacer que el correo desde este servidor fuera marcado como SPAM.

Slds
as

 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
>>>
>>
>>
>>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>

More information about the Politicas mailing list