[LACNIC/Politicas] LAC-2012-1

Wed Sep 12 11:41:01 BRT 2012

Clarificando,

Mi comentario respecto a los bugs es que no existe un sistema 100% libre de
bugs, y que una tecnologia alcanza madurez mediante pruebas y un despliegue
ordenado y paulatino.

2012/9/12 Gustavo Lozano <glozano.gli at gmail.com>

> Hola Roque,
>
> No he visto en tu propuesta o en los siguientes correos porque debemos
> forzar una tecnologia X o Y; y no dejar que los operadores que viven la
> realidad operativa decidan cuando es el mejor momento de implementarla.
>
> Comentarios entre lineas.
>
> 2012/9/10 Roque Gagliano (rogaglia) <rogaglia at cisco.com>
>
>> Hola Gustavo,
>>
>> Creo que comparar la resolucion inversa con RPKI es como comparar peras
>> con
>> manzanas. Haciendo una analogia (con todo lo problematico que tienen las
>> anologias), una mejor comparacion seria que los TLDs le dijeran a sus
>> clientes que no podran renovar sus dominios si no implementan DNSSEC.
>>
>> Exacto!, por eso ICANN le obliga a los nuevos gTLD a soportar DNSSEC (
>> http://newgtlds.icann.org/en/applicants/agb) o incluso el NIC.BR<
>> http://NIC.BR> obliga a quienes registran en b.br<http://b.br> a
>> soportar DNSSEC (http://www.nic.br/atividades/dom-bbr.htm).
>>
>>
>
> La explicacion de Ricardo es clara al respecto.
>
>
> Los TLDs y los RIRs son los eslabones de la parte superior de la cadena,
> soportan las nuevas tecnologias y nadie esta forzando a los usuarios
> finales existentes a implementar cierta tecnologia o en su defecto tener
> repercuciones negativas (no obtener mas recursos por ejemplo), entonces
> hasta el momento es una igualdad de circunstancias operativas.
>
> Mi punto es pasar a tomar una medida activa de promoción para transitar el
>> camino hacia RPKI y sortear los problemas administrativos. Y si vamos a ser
>> pioneros....vamos! Lo único que estamos pidiendo es a los miembros que
>> registren el ASN de origen que usan....
>>
>>
> Creo que todos estamos a favor de implementar nuevas tecnologias pero
> siguiendo el camino de analisis e implementacion paulatina que demandan los
> servicios criticos.
>
>
>> Las tecnologias son adoptadas cuando llegan a su madurez y existe una
>> relacion positiva en el costo/beneficio al utilizarlas.
>>
>> Vamos a suponer que tu propuesta es aceptada.
>>
>>
>> Las tecnologias tienen un ciclo tecnologico, en el caso de RPKI estamos en
>> la etapa de los innovadores y van a pasar años para que llegue a la
>> madurez.
>>
>> El paso que una tecnología se adopta no tiene una escala de años o
>> tiempos. La mente humana trabaja en forma lineal, pero las tecnologías
>> pueden avanzar a razón exponencial. Y no debemos olvidar que LACNIC está
>> invirtiendo activamente (y me refieron a $ de verdad) desde el año 2006 y
>> tiene un sistema operativo desde el 2009.
>>
>> RPKI tiene una característica muy distinta que DNSSEC: sólo se necesita
>> que 50K entidades lo adopten en el mundo, comparado con los millones para
>> DNSSEC. Por eso, el desarrollo puede ser mucho más rápido de lo que te
>> imaginas.
>>
>> En esta misma línea, nuestra región sólo tiene que conseguir la adopción
>> de unas 3000 entidades. Porqué tener que condenarnos a ser seguidores si
>> podemos ser pioneros? Piénsalo, estamos a sólo unos 6000 clicks en una
>> página web para que cubramos toda la región!!! Porqué conformarnos con
>> menos? Es más la gran mayoría de entidades tienen un sólo ASN y un sólo
>> prefijo...entiendo tus argumentos pero los beneficios son tan grandes que
>> me parece que estás tapando el océano.
>>
>> Y debe agregar dos puntos:
>> - Esta política va a ser necesaria de todas maneras para intentar
>> compensar el problema de la vejez de la información de registro, algo que
>> ya discutimos con Ricardo. Entonces sabemos que vamos a necesitarla en el
>> futuro, para qué esperar?
>> - LACNIC tiene el proceso de desarrollo de políticas más flexible que
>> conozco, si el costo para los ISPs es tan grande que no se pueda soportar o
>> si realmente no da resultados....tenemos muchas herramientas para volver
>> atrás! incluso con el proceso expeditivo....en 6 semanas lo podemos
>> desarmar!
>>
>>
>>
>> Lo que estas forzando es que los operadores de la region es que asuman
>> riesgos innecesarios al implementar una parte de RPKI.
>>
>>
>> Actualmente si no creo ROAs para mis prefijos seran clasificados como
>> UNKNOWN. Si me forzas a usar RPKI entonces mis prefijos solo tienen dos
>> posibles estados VALID o INVALID.
>>
>>
>> Los prefijos clasificados como UNKNOWN seran clasificados como VALID
>> mientras la tecnologia no alcance madurez, lo cual es logico, no
>> implemento
>> la tecnologia por lo tanto no existe riesgo para mi operacion. Cualquier
>> operador no quiere poner en riesgo su operacion y la mayoria no van a
>> crear
>> ROAs hasta que la tecnologia alcance madurez, sea una practica comun, su
>> personal este capacitado para poder realizar troubleshooting, etc. Dudo
>> mucho que la infraestructura actual de RPKI pueda ser considerada carrier
>> grade para forzar la tecnologia a los operadores.
>>
>> Esto es incorrecto.
>>
>>
> Creo que mi mensaje anterior no fue claro.
>
>
> Para que RPKI sea despleagado se necesitan dos cosas:
>
>
>    - Que los operadores validen rutas.
>    - Que los operadores generen objetos.
>
>  Si actualmente no genero objetos ROAs estoy en el status quo, entonces
> no estoy mas seguro, ni menos inseguro, estoy en el estado UNKNOWN desde la
> persepectiva de los validadores.En el estado UNKNOWN estoy expuesto a los
> problemas existentes de hijacking de rutas, en pocas palabras mi exposicion
> al riesgo es igual. Recordemos que solamente yo puedo generar objetos ROAs
> para mis prefijos.
>
>
> Conforme los operadores desplieguen los validadores, no van a castigar a
> los UNKNOWN en un principio. Despues de años, la practica comun sera
> castigar a los UNKNOWN, y este es el momento donde la realidad operativa
> forza a un operador a generar objetos.
>
>
> Implementar tu propuesta significa:
>
>
>
>    - Que tengo personal capacitado y herramientas para poder depurar
>    cualquier problema que puedan presenter mis prefijos con operadores que
>    validen rutas. En otras palabras, la queja de un cliente de no puedo
>    accesar a una pagina y mi amigo que usa otro ISP si puede, requeriria
>    incluir en la ecuacion la depuracion de RPKI.
>    - Que no tengo oportunidad de evaluar o modificar mis sistemas para
>    desplegar una parte de RPKI, quizas quiero generar los objetos desde mi
>    sistema de aprovisionamiento, por ejemplo.
>    - Que confio plenamente que el sistema de LACNIC funciona
>    adecuademente. El equipo de TI de LACNIC esta conformado por personas
>    excelentes y capaces, pero los bugs existen y los sistemas maduran con
>    pruebas, pruebas y pruebas. Por ejemplo, LACNIC todavia esta trabajando en
>    el CPS, http://lacnic.net/en/rpki/cps/, lo cual es logico porque el
>    despliegue de una nueva tecnologia es paulatina.
>
>
> Las tecnologias se implementan paulatinamente, analizando riesgos, tomando
> decisiones de costo/beneficio, no por mandato como lo pretende hacer tu
> propuesta.
>
>
> Saludos,
> Gustavo
>
>
>> Primero, la creación de los ROAs no tiene ninguna relación con la
>> implementación de la validación de rutas en un proveedor. Yo puedo crear
>> mis ROAs pero no realizar validación de rutas.
>>
>> Si una entidad genera sus ROAs, otra entidad (o ella misma) puede
>> utilizar esta información para generar políticas de rutamiento. La entidad
>> que crea el ROA no tienen control sobre qué política la entidad que utiliza
>> esa información establecerá. Las políticas para VALID/NOT FOUND/INVALID son
>> locales para entidad por lo que tu descripción es incorrecta y no refleja
>> la implementación que al menos estoy (muy) familiarizado de validación de
>> origen. Es más, existen mejores prácticas que establecen exactamente lo
>> contrario a lo que tu escribes.
>>
>> Ref: http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19#section-5
>> "Announcements with Valid origins SHOULD be preferred over those with
>> NotFound or Invalid origins, if the latter are accepted at all."
>>
>> Roque
>>
>>
>>
>> Saludos,
>> Gustavo
>>
>> 2012/9/7 Roque Gagliano (rogaglia) <rogaglia at cisco.com<mailto:
>> rogaglia at cisco.com>>
>>
>> Gustavo,
>>
>> Me parece que la diferencia radica en que yo veo la generación de material
>> criptográfico como una inherente a la función misma de LACNIC y no una
>> tecnología foránea que uno fuerza. O acaso se deberá dejar de pedir que
>> cumpla con la resolución inversa?
>>
>> Roque
>>
>> On Sep 7, 2012, at 4:18 PM, Gustavo Lozano wrote:
>>
>> Roque,
>>
>> Comentarios entre lineas.
>>
>> 2012/9/7 Roque Gagliano (rogaglia) <rogaglia at cisco.com<mailto:
>> rogaglia at cisco.com>>
>>
>> Hola Gustavo,
>>
>> Gracias por el comentario.
>>
>> Yo creo que LACNIC podría generar certificados CA en forma automática
>> sin
>> necesidad de una política para todos sus miembros, pues esto es una
>> simple
>> extensión de su rol de registro (o notario). Pero esto no ayuda a que el
>> resto del mundo pueda utilizar esta información a menos que también se
>> generen los ROAs correspondientes y este paso no se puede hacer
>> automático
>> pues muchos proveedores tienen más de un ASN registrado u otras
>> peculiaridades.
>>
>>
>> Si realmente RPKI es valioso para los operadores entonces ellos mismos se
>> van a preocupar por generar los objetos que necesiten de forma correcta y
>> por las personas informadas sobre el tema en la organizacion y no
>> simplemente por cumplir un requisito dando clicks como detallas en tu
>> propuesta.
>>
>> Mi punto es que queremos utilizar las politicas para forzar tecnologias
>> en
>> el mercado.
>>
>> Esta comunidad tiene un foco: la asignación de recursos (IPs y ASN) y por
>> lo tanto tiene un rol e impacto clave en el desarrollo de RPKI. No es lo
>> mismo para esta comunidad RPKI que FTTH o Cloud o DNSSEC. Incluso ya hay
>> hoy propuestas sobre la mesa (como LAC-2011-08) para buscar nuevos usos
>> de
>> este recurso.
>>
>>
>> Roque lo de FTTH y certificaciones fue un chiste :).
>>
>> Entrando en materia, http://lacnic.net/sp/sobre-lacnic/estatuto/i.html,
>> en
>> ningun lado dice forzar tecnologias en el mercado.
>>
>> La propuesta es un paso muy modesto (pero a mi entender eficaz) para
>> acelerar el desarrollo de lo que debemos tener consenso va a ser una
>> nueva
>> práctica en la industria. Nosotros ya aplicamos esta mismo estrategia
>> con
>> IPv6! Comenzamos a exigir muy poco ("tener un plan") y luego fuimos
>> evaluando el impacto e incrementando los requerimientos....Mi propuesta
>> es
>> comenzar ese mismo camino para RPKI, de vuelta con un paso muy modesto y
>> prácticamente sin costo para el operador. LACNIC puede ayudar con
>> material
>> didáctico específico para cumplir con este requerimiento.
>>
>>
>>
>> No es un paso modesto, es un requisito extra y sin sentido para pedir
>> recursos.
>>
>> Si va a ser una nueva practica en la industria entonces que la industria
>> lo
>> adopte como buena practica, no es necesario una politica para crear
>> buenas
>> practicas. En teoria es una buena practica agregar tus bloques y quitamos
>> toda referencia a lo mismo porque son politicas de asignacion de
>> recursos,
>> no un conjunto de buenas practicas.
>>
>> LACNIC puede crear el material didactico y mandarlo por email,
>> presentarlo
>> en talleres, etc, tenemos que entender que las tecnologias son adoptadas
>> no
>> forzadas.
>>
>> Roque
>>
>>
>>
>> On Sep 7, 2012, at 1:37 AM, Gustavo Lozano wrote:
>>
>> Hola a todos,
>>
>>
>>
>> Estoy en contra de la propuesta.
>>
>>
>>
>> Parece que seguimos viendo las políticas de LACNIC como el método para
>> forzar la adopción de nuevas tecnologías.
>>
>>
>>
>> Recordemos que ya pasamos por una propuesta no aceptada que requería la
>> implementación de IPv6 para obtener recursos.
>>
>>
>>
>> También recuerdo que aprobamos una propuesta para eliminar los términos
>> de
>> agregación de bloques con la justificación que en las políticas no
>> deben
>> existir requerimientos técnicos.
>>
>>
>>
>> El objetivo de la propuesta es:
>>
>> * educar sobre el RPKI y seguridad en el sistema global de
>> enrutamiento.
>>
>> Propongo entonces que LACNIC mande un email cada "x" tiempo explicando
>> lo
>> que es RPKI a los tomadores de decisión o que publique anuncios en los
>> diarios u otras miles de formas para dar a conocer un tema a una
>> audiencia.
>>
>>
>>
>> * inducir la generación de material criptográfico en el RPKI.
>>
>> Propongo  que se generen objetos en el sistema de forma automática si
>> creemos que eso agrega valor.
>>
>>
>>
>> No estoy de acuerdo en usar las políticas para ayudar o forzar el
>> despliegue de ciertas tecnologías. Ahora bien si creemos que las
>> políticas
>> pueden ser usadas para promocionar tecnologías entonces podríamos tener
>> propuestas que para obtener recursos adicionales necesitas:
>>
>> * Activar DNSSEC en tus zonas de reserva.
>>
>> * Si quieres IP para hosting entonces que tu hosting ofrezca IPv6 y
>> DNSSEC.
>>
>> * Si eres una telefónica entonces implementa FiOS para el x% de tus
>> clientes.
>>
>> * Tienes que tener al menos un empleado certificado en x o y
>> tecnología.
>>
>> * etc, etc.
>>
>>
>>
>> El tema de RPKI resulta además delicado porque por muchas personas es
>> visto
>> como el mecanismo para que los RIRs sigan obteniendo recursos cuando
>> IPv4
>> sea historia y con un bloque de IPv6 sea suficiente para la operación
>> de
>> un
>> ISP por décadas.
>>
>> Saludos,
>> Gustavo Lozano
>>
>> 2012/9/6 Nicolas Antoniello <nantoniello at gmail.com<mailto:
>> nantoniello at gmail.com>>
>>
>> Alejandro, Carlos, Roque, todos,
>>
>> Agrego algun comentario a los que mencionaba antes:
>>
>> - Por un lado, no veo bien el indicar "no hacer algo" hasta que el
>> resto lo
>> haga... así claramente no se avanza (en mi opinión es como el problema
>> de
>> los comezales en la mesa con menos cubietos que comenzales... si todos
>> esperan no come nadie, pero no todos pueden comer al mismo tiempo...
>> en
>> fin).
>> Desde ese punto de vista, no veo que el espíritu de la propuesta de
>> Roque
>> sea "imponer requerimientos técnicos vía políticas"... sino que más
>> bien es
>> un tema de "lo que implica".
>>
>> - El rotuer en todo caso dialoga con el repositorio de RPKI para
>> realizar
>> la eventual verificación, pero creo que en lo que a hardware respecta
>> no se
>> requeriría mayor cambio... más biene es un tema de software.
>>
>> ... pero todo eso es más bien técnico...
>>
>>
>> - RPKI claramente tiene usos independientemente de que los routers
>> verifiquen ROA y los mismos son eventualmente totalmente externos a
>> los
>> routers... eso de alguna manera quería indicar en los comentarios
>> anteriores.
>>
>> En definitiva, Roque, tal vez una aproximación que podría resultar más
>> aceptada (que comentábamos off-line con Carlos M.) podría ser incluir
>> en
>> una primer aproximación de política que lo que se solicite al recibir
>> la
>> delegación de un prefijo sea la generación de los certificados (el
>> tema
>> del
>> mantenimiento de los mismos vuelve a la mesa de debate, pero eso
>> entiendo
>> que es un problema que ya existe con muchos otros recursos o
>> sistemas).
>>
>> Luego, la generación de los ROA si implica una desición de ruteo, pues
>> allí
>> se incluye el AS que estaría "autorizado" a generar el prefijo... tal
>> vez
>> ese es el punto en que se "filtra" algo más técnico pues implica
>> deciciones
>> de ruteo.
>>
>> De todas formas en algún momento hay que generar los ROA si lo que se
>> quiere es validar el origen...
>>
>> No me estoy expresando ni a favor ni en contra, sino que planteo
>> opciones a
>> la redacción de la política, que podrían resultar más aceptables en
>> vista
>> de los comentarios expuestos en la lista.
>>
>> Roque?
>>
>> Saludos,
>> Nico
>>
>>
>>
>>
>>
>> 2012/9/6 Alejandro Rodriguez <arodriguez at b2ec.net<mailto:
>> arodriguez at b2ec.net>>
>>
>> Estimados:
>>
>> No estoy de acuerdo de acuerdo con esta política. Se esta tratando de
>> imponer un requerimiento técnico para la solicitud de recursos
>> adicionales.
>> Para requerimiento técnico se utiliza un standard de baja adopción y
>> que
>> prácticamente nadie utiliza.  Al final lo se lograría es aumentar el
>> costo
>> administrativo a los ISP , sin prácticamente ningún beneficio. Quizás
>> en
>> 5
>> años, si la adopción de RPKI es masiva, esta política tendría
>> sentido.
>>
>> alguna consideraciones a tener en cuenta:
>> - Un router que necesite verificar el ROA de 300k rutas, va necesitar
>> un
>> hardware mas potente que uno que no realice esta función . O se mas
>> $$$$.
>> Por ello no me parece que de forma masiva se vaya a implementar RPKI
>> en
>> un
>> futuro cercano.
>> - De lo que entiendo el único fabricante que en estos momentos
>> soporta
>> RPKI es Cisco. ¿ Se debe implementar una política que beneficie a un
>> solo
>> fabricante ?
>> - Capacitación. Aprobar esta política implica que todos los
>> responsables
>> de recursos deben tener conocimientos de RPKI.
>>
>>
>> saludos
>>
>> Alejandro Rodriguez
>> Gerente Tecnico
>> Stealth Telecom del Ecuador
>> www.stealthtelecom.net<http://www.stealthtelecom.net>
>> Telf: 2248233 / 2248887
>>
>> El 06/09/2012 13:53, Carlos M. martinez escribió:
>>
>> Hola!
>>
>> Quiero hacer únicamente algunos comentarios sobre la tecnología y no
>> sobre la política:
>>
>> - No hay que mezclar el concepto de validación de origen (lo que
>> hacen
>> los routers) con el concepto de la RPKI.
>>
>> - En el contexto de la política, la RPKI es otra base de datos y
>> puede
>> no tener ningún impacto operativo.
>>
>> Algunos otros comentarios entre líneas:
>>
>>
>> On 9/6/12 2:44 PM, Nicolas Antoniello wrote:
>>
>> set chair hat == off;
>>
>> Estimados,
>>
>> Expongo mi o mis punto/s de vista:
>>
>> Si bien la tecnología (por decirlo de alguna manera) de RPKI es una
>> solución a una parte de los problemas de BGP (tal y como intenta
>> serlo
>> BGPsec para otros problemas de seguridad; y si bien RPKI en
>> comparación
>> con
>> BGPsec y otras propuestas está bastante más "aceptado" hoy día (no
>> era
>> así
>> hace unos años)... creo que aún hoy no es "la" tecnología definida
>> y
>> aceptada por todos para asegurar el origen de los prefijos.
>>
>> Al dia de hoy casi todas las propuestas girar alrededor de la PKI
>> de
>> recursos. Hay únicamente otra propuesta que involucra el uso del DNS
>> reverso pero no esta teniendo gran apoyo. En mi opinión, esta si ya
>> bastante establecido que la PKI de recursos es una componente
>> fundacional de las propuestas de enrutamiento seguro de los próximos
>> 5 o
>> mas años.
>>
>>
>> Incluso recien hace muy poco tiempo un fabricante publicó la
>> incorporación
>> del soporte a sus routers, para chequeo de RPKI en algunos de sus
>> sistemas
>> operativos... con esto quiero decir que aún falta camino por
>> recorrer.
>> Si bien aunque no se tenga soporte de los sistemas operativos en
>> los
>> routers, es posible utilizar los ROA para disparar alarmas, etc...
>> es
>> decir, que aún sin el soporte completo por parte de los routers, el
>> sistema
>> es útil; creo que no está lo suficiente maduro como para asumir que
>> va
>> a
>> ser la solución aceptada y determinar o pretender impulsarla desde
>> una
>> política.
>>
>> Al dia de hoy los routers no 'chequean RPKI', los routers arman una
>> tablita y comparan los UPDATES de BGP contra esa tablita. Creo que
>> la
>> falta o no de soporte de validación de origen en los enrutadores es
>> ortogonal al mérito o no de la política.
>>
>> Por un lado, sigo siendo reticente a que por política se incluyan
>> cuestiones que o bien sean abietamente temas técnicos o bien
>> indirectamente
>> cubran aspectos técnicos u operativos que sean ajenos a los que
>> rijan
>> asignaciónes, gestión o manejo de recursos de los RIR/NIR.
>>
>> Por otro lado, alguien podría entender que la generación de los ROA
>> está
>> directamente relacionada con el recurso (en este caso un prefijo
>> IP)
>> y
>> por
>> lo tanto, podría estar dentro de la política de un RIR la
>> "securización"
>> o
>> "autenticación" de las asignaciones... pero entonces, debería
>> explicitarse
>> un mecanismo de mantenimiento/actualización de los ROA, ya que si
>> la
>> info.
>> se vuelve obsoleta por "aging" no tiene sentido que esté en una
>> política
>> (sigamos la idea de que no parecen tener mucho sentido políticas
>> que
>> desde
>> su planteo se sepa que son "inaplicables" o "inverificables" por
>> parte
>> de
>> los RIR/NIR).
>>
>>
>> Entonces, ¿Qué opina el resto de la lista?
>>
>> Frateno saludo,
>> Nico
>>
>>
>>
>> 2012/9/6 Ricardo Patara <patara at registro.br<mailto:patara at registro.br>>
>>
>> Hola Roque,
>>
>> 1) Valides de la información:
>> Entiendo que tu comentario era sobre la "forma" de los objetos
>> firmados. Obviamente si alguien usa el sistema "hospedado" de
>> LACNIC
>> o
>> de un NIR esto está descartado. Por eso no lo consideré en la
>> propuesta
>> original. Es cierto que si alguien administra su propia entidad
>> certificadora, sería bueno hacer un chequeo. Aquí estamos
>> hablando
>> de
>> chequear los objetos.
>>
>> No solamente cuanto a la forma, pero que la información sea
>> "correcta".
>> Por ejemplo. Para una ROA, que de hecho figure allá el ASN por
>> lo
>> cual
>> el ISP va a originar sus anuncios. Y eso implica en trabajo
>> extra
>> para
>> los RIR/NIRs.
>> Y
>>
>> (Roque) Me estas mezclando de vuelta. La política no pide a los
>> RIR/NIR que verique nada del ASN que el miembro ingresó.
>> Verificar
>> la
>> "forma" viene gratis en las herramientas existentes. Además, TODA
>> política tiene costos para los RIR/NIRs.
>>
>> no. mi punto es que bajo la presion para obtener recursos
>> adicionales
>> uno puede poner lo que quiera en un objeto ROA, por ejemplo
>> ( y eso tiene relación también con la calidad de la información
>> que
>> me
>> refería )
>>
>>
>> 2) Mantenimiento de la información (o en inglés "information
>> aging"):
>> Esto es un problema tradicional de cualquier base de datos de
>> registro. Existe este problema actualmente con, digamos, la
>> información
>> de Whois de LACNIC.
>> Personalmente, yo creo que la política es incluso una mejora en
>> este
>> sentido pues le da los instrumentos al staff para requerirle a
>> un
>> miembro a que actualice la información en la base de datos.
>>
>> No estoy de acuerdo que eso va a mejorar la calidad de la
>> información.
>> Si no hay incentivos para utilizar una tecnología, no habrá
>> incentivos
>> para mantener la información actualizada.
>>
>> Y la información de RPKI tiene poca relación con información de
>> asignación/sub asignación (en lo que toca el whois).
>>
>> (Roque) Mi comentario sobre la base de registro es que mantener
>> la
>> información del email de contacto de una entidad sufre del mismo
>> problema de mantenimiento de la información. En tu comentario
>> estás
>> asumiendo que la mayoría de la información va a caducar
>> rápidamente.
>> Yo creo lo contrario, ISPs cambian muy raramente de sistema
>> autónomo
>> y por ende la información se va a mantener válida.
>>
>> Al fin y al cabo, el objetivo es fomentar la adopción, correcto?
>>
>> ok,
>> pero sigo que la compración no es buena :)
>>
>> 3) Verificación de información de ruteo:
>> Esto no esta incluido en la propuesta, justamente por la
>> dependencia
>> en el punto de observación. Por eso mi comentario de que en
>> general
>> las herramientas para generar los objetos RPKI (i.e. la web de
>> rpki.lacnic.net<http://rpki.lacnic.net> o las herramientas que comentaba
>> Arturo)
>> ayudan
>> a
>> un
>> operador a crear ROAs "adecuados".
>>
>> Okay, pero poner la necesidad de generalos asociada a
>> justificativa
>> de
>> obtener asignación no es adecuado. Ese es mí punto.
>>
>> 4) Motivación de despliegue:
>> Hay diferentes factores que motivan el despliegue de una
>> tecnología.
>> Hay factores económicos, regulatorios, políticos, ecológicos,
>> etc
>> (i.e. análisis de PESTEL). Personalmente, creo que esta
>> política
>> motiva la creación de material criptográfico que aumente el
>> valor
>> percibido de la tecnología no para una entidad específica, pero
>> para
>> el conjunto de la comunidad.
>>
>> Que es mejor, tener un montón de información "sin calidad" o
>> pocas
>> pero
>> de calidad buena?
>>
>> (Roque) Porqué sería "sin calidad"?, creo que sobre-estimas el
>> valor
>> de mantener información correcta para los miembros.
>>
>> si un ISP tiene la presión por obtener recursos adicionales y se
>> ve
>> obrigado a tener RPKI, va a poner lo que sea más facil para
>> cumplir
>> con
>> la regla.
>>
>> y eso, no es motivación para aprender ni tampoco fomentar la
>> tecnlogía.
>>
>>
>> 5) Madurez de la tecnología:
>> Justamente la adopción de esta política va a fomentar más
>> material
>> criptográfico y por ende más resultados concretos para seguir
>> mejorando la madurez de la tecnología. Yo creo realmente en el
>> valor
>> de diseños iterativos e incrementales (i.e. ágiles).
>>
>> No estoy de acuerdo.
>> Creo que lo que está haciendo LACNIC está bien, o sea, los
>> tutoriales,
>> charlas, etc. Eso crea masa critica no solamente para
>> implementar
>> sino
>> que para discutir
>>
>> "Obligar" uno a ir por ese camino no creo que es lo que va a
>> traer
>> la
>> madurez.
>>
>>
>> (Roque) No es "obligar", es como comunidad entender que es una
>> buena
>> práctica estimular poblar la base de datos del RPKI. La realidad
>> es
>> que en las tareas de difusión es muy difícil llegar a todos los
>> miembros e incluso a las personas que tienen o la clave del
>> sistema
>> de LACNIC o la información de routing. En el momento de pedir
>> recursos, los canales de diålogo son más fluidos con LACNIC y
>> dentro
>> de las empresas. Creo que la región de LACNIC puede avanzar muy
>> rápidamente en este sentido. Si estamos tan cerca, por qué
>> frenarnos?
>>
>> Es obligar.
>> Si yo necesito de IPs adicionales, utilice bien los recursos que
>> me
>> fueran asignados pero aún así no logro obtener más por esa
>> cuestión
>> de
>> RPKI, me veré obligado a hacer eso, mismo que todavía no sepa
>> bien,
>> no
>> la use, y ella no esté madura lo suficiente.
>>
>> Mi punto es que mejor crear masa critica, difundir informaciones,
>> etc
>>
>> Ricardo
>>
>>
>> Roque
>>
>>
>> abrazos.
>> Ricardo
>>
>> Roque
>>
>>
>>
>> On Sep 6, 2012, at 3:11 PM, Ricardo Patara wrote:
>>
>> Hola,
>>
>> Como decía, creo que es interesante el esfuerzo en motivar
>> RPKI,
>> pero
>> quería explicitar que no estoy de acuerdo a la propuesta.
>>
>> hay ese punto en relación a los NIRs y eso puede ser
>> interpretado
>> también que se está intentando poner criterios en las
>> políticas
>> con
>>
>> base
>>
>> en algo "técnico" pero que todavía no está aún en el nível de
>> madurez
>> deseado.
>>
>> Cuanto al comentario de Roque en se agregar verificación en
>> los
>>
>> objetos
>>
>> (roas, certs) de acuerdo rfcs. Es un paso, pero nuevamente, tener
>> eso
>>
>> en
>>
>> la política por si solo no va a motivar el uso de la tecnología.
>>
>> Por ejemplo. Suponga que estos criterios de verificación
>> figuren
>> en
>> la
>> política y tal verificación se haga al momento de la solicitud
>> de
>> bloques adicionales. Qué motivación va a tener el ISP en
>> mantener
>>
>> estos
>>
>> objetos "correctos" y actualizados?
>>
>> Y mismo que se agregue ese último comentario de Christian, de
>> que
>> la
>> asignación es válida desde que se mantenga actualizada la
>> información
>>
>> de
>>
>> RPKI. Como LACNIC verificaría eso?
>> Una cosa es registrar información de sub asignación. Otra es
>> registrar
>> información de ruteo. Qué parametros seguiría LACNIC para
>> verificar
>>
>> eso?
>>
>> Y nuevamente al punto, como les parece que eso motiva el
>> despliegue
>> da
>> la tecnología?
>> Uno puede tener todo bien registrado, pero qué vale si nadie
>> lo
>> usa
>> porque no sabe, no conoce?
>>
>> No me gusta la idea de hacer adoptada una tecnología (en
>> especial
>>
>> nueva
>>
>> y no tan madura), a través de políticas de asignación.
>>
>> Abrazos.
>>
>> Ricardo Patara
>>
>> Em 06-09-2012 09:56, Christian O'Flaherty escreveu:
>>
>> Apoyo la propuesta incluyendo los comentarios de Ricardo
>> (hacer
>>
>> alguna
>>
>> referencia al caso de los NIR e incluir la "verificación" del
>> ROA).
>>
>> Tambien habría que modificar este punto del manual:
>>
>> 2.3.2.10. Validez de las distribuciones de direcciones IPv4
>>
>> Las distribuciones de direcciones IPv4 son válidas
>> mientras...
>>
>> mantener actualizada la información de las distribuiciones y
>> asignaciones en la base de datos Whois de LACNIC + RPKI
>>
>> Tambien habría que incluirlo en el manual para las
>> asignaciones
>> IPv6,
>> no? (4.5.6, 4.5.2, etc.)
>>
>> Christian
>>
>> 2012/9/6 Roque Gagliano (rogaglia) <rogaglia at cisco.com<mailto:
>> rogaglia at cisco.com>>:
>>
>> Hola Ricardo,
>>
>> On Sep 6, 2012, at 2:10 PM, Ricardo Patara wrote:
>>
>> Hola Roque,
>>
>> Me pareció interesante la idea. Pero me preocupa en
>> especial
>> qué
>>
>> pasaría
>>
>> con los NIRs que siguen las políticas de LACNIC pero que todavía
>>
>> no
>>
>> tienen un sistema RPKI?
>>
>> Quizás sea un incentivo para que lo implementen? Me
>> imagino
>> que
>>
>> los NIR tienen su plan y este tipo de discusiones las
>> deberían
>> tener con
>> sus comunidades.
>>
>> comprendo. pero mi pregunta es que pasaría si la propuesta es
>>
>> aceptada
>>
>> pero los NIRs no tiene todavía su RPKI?
>>
>> Dicho esto, entiendo que LACNIC, los NIR y sus respectivas
>>
>> comunidades se pondrán de acuerdo en una hoja de ruta
>> razonable
>> para
>> implementar la política. No es lo que sucede en todos los casos?
>>
>> Además de eso la propuesta no indica nada cuanto a validez de
>>
>> los dados
>>
>> de RPKI, por ejemplo, no indica que si la ROA tiene o no que ser
>>
>> válida,
>>
>> tampoco si los certificados tienen o no que estar validos (no
>>
>> revocados
>>
>> y dentro de las fechas de validez).
>>
>> Si la idea es motivar el uso, hay que tener preocupación
>> con
>> la
>>
>> validez
>>
>> y también de alguna forma motivar su uso. Creo que faltaría esa
>>
>> parte en
>>
>> la propuesta.
>>
>> Aquí hay dos cosas:
>>  - "valido" o "invalido" es una clasificación que depende
>> del
>>
>> punto de observación. Por esto no creo que podamos poner
>> ningún
>> texto que
>> ayude aquí. Para mitigar errores de tipeo por parte de los
>> operadores,
>> las
>> herramientas ayudan al operador con información sobre el status de
>> la
>> tabla
>> global de rutas en distintos puntos de observación (RIS o
>> Routeviews).
>>
>> valido y invalido lo queria decir no es en comparación con las
>>
>> rutas,
>>
>> sino que un objeto ROA "correctamente" creado.
>>
>> Uno puede por ejemplo crear un ROA de cualquier forma
>> solamente
>>
>> para
>>
>> cumplir con la solicitud de recursos adicionales y poner por
>>
>> ejemplo ASN
>>
>> 0, o un ASN reservado, o otra cosa.
>>
>>
>>   - hay un tema de "aging" de la información. Básicamente
>> por
>>
>> más que la información sea "correcta" en el momento de
>> crearla,
>> al pasar el
>> tiempo la info en el RPKI no acompañe la información en el sistema
>> de
>> rutas. Esta propuesta ayuda con la mitigación de este problema
>> pues
>> obliga
>> al ISP a revisar sus ROAs cada vez que pide nuevos  bloques.
>>
>> y nuevamente, si la idea es motivar el uso, al no hacer controle
>> o
>>
>> tener
>>
>> motivaciones para que la información sea valida pueda crear más
>>
>> problemas.
>>
>> Uno puede crear una ROA "incorrecta", o crear y revocar su
>>
>> certificado
>>
>> EE solamente para cumprir con los tramites.
>>
>> Y si al mismo tiempo un provedor inicia el
>> uso/verificación,
>> el
>>
>> problema
>>
>> al ISP que genero los datos puede ser mayor.
>>
>> Lo que quiero decir con eso, que es interesante motivar,
>> pero
>>
>> poner en
>>
>> la política puntos que uno puede "cumplir" por "cumplir" sin
>> otras
>> medidas que motiven el uso puede ser peor .
>>
>> Entiendo tu punto. Perdón por la confusión.
>>
>> Te parece agregar que los certificados sean validos según
>> RFC6481
>> y
>>
>> los ROAs según RFC 6483?
>>
>> Roque
>>
>> saludos
>> Ricardo
>>
>> Roque
>>
>> un abrazo.
>>
>> Ricardo Patara
>>
>> Em 06-09-2012 04:59, Roque Gagliano (rogaglia) escreveu:
>>
>> Hola Gente,
>>
>> Yo soy el autor de LAC-2012-11.
>>
>> Básicamente la propuesta es muy simple. Lo que dice es
>> que
>>
>> agreguemos a los requerimientos para obtener recursos
>> adicionales que una
>> entidad tenga que registrar en el RPKI los recursos que ya tiene.
>>
>> El objetivo es simplemente solucionar un problema
>>
>> administrativo y lograr acelerar la adopción de RPKI.
>> Muchas
>> veces la
>> persona con la clave del sistema de LACNIC no es la misma que
>> opera
>> la
>> red.
>> Con este pedido, simplemente les pedimos a ambas entidades que se
>> "comuniquen" y coloquen la información en el sistema RPKI. También
>> logramos
>> que más miembros se eduquen sobre las capacidades RPKI.
>>
>> El costo para el miembro es mínimo pues la política no pide que
>>
>> registre bloques delegados y pues se puede solucionar con
>> dos
>> o tres clicks
>> en la web RPKI de LACNIC.
>>
>> Espero sus comentarios.
>> Roque
>>
>>
>>
>> On Sep 6, 2012, at 4:45 AM, Nicolas Antoniello wrote:
>>
>> Dear Policy-list Members,
>>
>> There are three new Policy Proposals; numbers
>> LAC-2012-09,
>>
>> LAC-2012-10 and
>>
>> LAC-2012-11:
>>
>> - LAC-2012-09 Update
>> RIRs-on-48<
>>
>>
>> http://lacnic.net/documentos/**politicas/lac-2012-09-EN.pdf
>> <http://lacnic.net/documentos/politicas/lac-2012-09-EN.pdf>
>>
>>
>> - LAC-2012-10 Allocation of IPv6 address blocks larger than a
>> /32<
>> http://lacnic.net/**documentos/politicas/lac-2012-**
>> 10-EN.pdf<
>> http://lacnic.net/documentos/politicas/lac-2012-10-EN.pdf>
>>
>> - LAC-2012-11 Requirement to sign up for RPKI when
>> requesting
>>
>> additional
>>
>> resources <
>>
>>
>> http://lacnic.net/documentos/**politicas/lac-2012-11-EN.pdf
>> <http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>
>>
>> <http://lacnic.net/documentos/**politicas/lac-2012-11-EN.pdf<
>> http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>
>>
>> As your comments are important, we encourage you to
>> express
>>
>> your views on
>>
>> the proposals:
>>
>>  - Do you support or oppose this proposal?
>>  - Does this proposal solve a problem you are
>> experiencing?
>>
>> If
>>
>>      so, tell the community about your situation.
>>  - Do you see any disadvantages in this proposal?
>>  - Is there anything in the proposal that is not
>> clear?
>>  - What changes could be made to this proposal to make
>> it
>>
>> more
>>
>>      effective?
>>
>>
>> Max Larson Henry
>> Nicolas Antoniello
>> co-Chairs of Public Policy Forum - LACNIC
>>
>>
>> ==============================**
>> ==============================**=======================
>>
>> Estimados suscriptores de la lista de políticas de LACNIC,
>>
>> Se recibieron tres nuevas propuestas de Política;
>> números
>>
>> LAC-2012-09,
>>
>> LAC-2012-10 y LAC-2012-11:
>>
>>
>> - LAC-2012-09 Actualización
>> RIRs-on-48<
>>
>>
>> http://lacnic.net/documentos/**politicas/lac-2012-09-SP.pdf
>> <http://lacnic.net/documentos/politicas/lac-2012-09-SP.pdf>
>>
>>
>> - LAC-2012-10 Distribución de direcciones IPv6 mayores que
>> /32<
>> http://lacnic.net/**documentos/politicas/lac-2012-**
>> 10-SP.pdf<
>> http://lacnic.net/documentos/politicas/lac-2012-10-SP.pdf>
>>
>> - LAC-2012-11 Requerimiento de inscripción en RPKI para
>>
>> recursos
>>
>> adicionales <
>>
>>
>> http://lacnic.net/documentos/**politicas/lac-2012-11-SP.pdf
>> <http://lacnic.net/documentos/politicas/lac-2012-11-SP.pdf>
>>
>>
>>
>> Dado que sus comentarios son importantes, solicitamos
>> que
>>
>> exprese sus
>>
>> puntos de vista sobre las propuestas:
>>
>>  - ¿Apoya usted o se opone a esta propuesta?
>>  - ¿Ésta propuesta resolvería un problema que ud. está
>> experimentado? En caso
>>      afirmativo, podría describir sus situación?
>>  - ¿Ve alguna desventaja en esta propuesta?
>>  - ¿Hay algo en la propuesta que no está claro?
>>  - ¿Qué cambios podrían hacerse a esta propuesta para
>> que
>> sea
>> más eficaz?
>>
>>
>> Max Larson Henry
>> Nicolas Antoniello
>> Moderadores del Foro Público de Políticas de LACNIC
>>
>>
>> ==============================**
>> ==============================**========================
>>
>> Prezados membros da lista políticas do LACNIC,
>>
>> Se recebeu os três seguintes propostas de Política é
>> asignó o
>>
>> numero
>>
>> LAC-2012-09, LAC-2012-10 é LAC-2012-11:
>>
>>
>> - LAC-2012-09 Atualização
>> RIRs-on-48<
>>
>>
>> http://lacnic.net/documentos/**politicas/lac-2012-09-PT.pdf
>> <http://lacnic.net/documentos/politicas/lac-2012-09-PT.pdf>
>>
>>
>> - LAC-2012-10 Alocações IPv6 maiores que
>> /32<
>> http://lacnic.net/**documentos/politicas/lac-2012-**
>> 10-PT.pdf<
>> http://lacnic.net/documentos/politicas/lac-2012-10-PT.pdf>
>>
>> - LAC-2012-11 Requerimento de inscrição no RPKI para
>> recursos
>> adicionais<
>>
>>
>> http://lacnic.net/documentos/**politicas/lac-2012-11-PT.pdf
>> <http://lacnic.net/documentos/politicas/lac-2012-11-PT.pdf>
>>
>>
>>
>> Considerando que seus comentários são importantes,
>> pedimos
>> que
>>
>> expresse
>>
>> suas opiniões sobre as propostas:
>>
>>   - Você apoia ou se opõe a esta proposta?
>>   - Esta proposta resolveria um problema que você
>>
>> experiencia?
>>
>>        No caso afirmativo, você poderia descrever a sua
>>
>> situação?
>>
>>     - Você vê algum inconveniente com esta proposta?
>>   - Há algo na proposta que não está claro?
>>   - Que mudanças poderiam ser feitas para a presente
>> proposta
>>      para torná-lo mais eficaz?
>>
>>
>> Max Larson Henry
>> Nicolás Antoniello
>> Moderadores do Foro Público de Políticas - LACNIC
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>> ______________________________**_________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>
>>
>>
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>>
>>
>>
>> --
>>
>> Regards,
>> Gustavo Lozano
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>>
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>>
>>
>>
>> --
>>
>> Regards,
>> Gustavo Lozano
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>>
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>>
>>
>>
>> --
>>
>> Regards,
>> Gustavo Lozano
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net<mailto: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
>>
>>
>
>
> --
>
> Regards,
> Gustavo Lozano
>
>

-- 

Regards,
Gustavo Lozano