[LAC-TF] [LACNIC/Seguridad] Seguridad en IPv6 Neighbor Discovery (práctica)

[Fernando Gont]

Hola, Arturo,

On 12/01/2012 06:24 PM, Arturo Servin wrote:
> 
> 	Necesitas las primeras 5 secciones (bueno, 3, 4 y 5)? No seria mejor
> solo hacer referencia a los RFCs correspondientes?

Las secciones en cuestion analizan vectores de ataque basados en cada
uno de esos mensajes/opciones, asi cmo tambien recomiendan sanity checks
para los campos correspondientes. Dicha información, en su mayoría no
esta incluída en ninun RFC.

En lineas generales, te diria que las secciones 1-5 es para que si vos
pensas, por ej., en una opción de ND, tengas una sección dedicada a
dicha opción, que te mencione todas las cosas (malas) que odes hacer por
la misma.

Por el contrario, la sección 6 vendria a ser una cross-reference por
"tipo de vulnerabilidad"... en muchos casos, incluyendo pointers a las
secciones 1-5.


> 	En mi opinion, lo bueno es la seccion 6. Lo demas es referencia que en
> mi leida rapida posiblemente no aporta mucho.

En la sección 6 es imposible incluir sanity checks. O bien, tal vez
seria posible, pero eso no seguiría el "flujo de implementacion". El
tipo que esta escribiendo el codigo para, por ej., la "source link-layer
address option", quiere tener disponible, todo en un mismo lugar, todos
los sanity checks que deberia aplicar a la misma. Si el documento
constara solamente de la sección 6, dicha info estaria desparramada por
varias secciones, lo cual seria poco practico, y proclive a que los
programadores se lviden de incluir alguno(s) de lo(s) sanity check(s).



> 	Tampoco citas al RFC6583 (este es documento que vino de v6ops) que
> cubre problemas similiares a los que mencionas. Seria bueno que vieras
> que nuevo aportas en el I+D que no tenga el 6583. 

Un par de coomentarios: El texto de este I-D, pese a la fecha de
publicación del I-D, data del 2009-2011. Es decir, es anterior al RFC en
cuestión.

Mas allá de eso, pese a que voy a incluir una cita al RFC 6583, creo que
dicho RFC carece de información fundamental. Esto lo hice expreso en
debidamente en su momento en:
<http://www.ietf.org/mail-archive/web/v6ops/current/msg11932.html>.

De hecho, eso de limitar la cantidad de entradas en el estado INCOMPLETE
es la solución adecuada al problema que ellos describen. :-)



> Tal como esta asumo
> que habra comentarios en v6ops y opsec no muy positivos por lo parecido
> que pueden ser los temas.

Mi documento (pese a que el titulo no es lo mas adecuado que podría
ser), intenta ser de utilidad para el implementador de Neighbor
Discovery, al estilo de RFC 6274.  Creo que nada de lo que se ha
publicado hasta el momento sigue en esa linea.

Dicho eso, soy algo esceptico a las opiniones. He tenido documentos
objetados por años, que eran buenos y simples, y otros algo
cuestionesbles que, por motivos diversos, se movieron para adelante sin
que nadie diga nada.

De cualquier modo, la idea de esta version -00 era teer algo de feedback
preliminar para luego producir la version -01, y que sea *esa* la que
empiece a ser discutida en opsec.

Un abrazo, y gracias!
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492