[LACNIC/Politicas] LAC-2012-1

Mon Sep 10 11:51:46 BRT 2012

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).

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....

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.

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