[LACNIC/Seguridad] IETF I-D revisado: Security Assessment of the IPv6 Flow Label

Fernando Gont fgont en si6networks.com
Mar Ene 24 06:17:40 BRST 2012


Hola, Javier,


Mis disculpas por la demora en responder. Mis respuestas van entre lineas...

On 01/13/2012 01:03 PM, Javier Liendo wrote:
> en mi humilde opinion, el gran problema del campo flow-label en el
> encabezado de ipv6 es que en ninguna parte se define un mecanismo de
> proteccion que garantice (i.e. checksums, otros?) que el campo nunca
> fue modificado en transito entre dos puntos lo que a mi parecer lo
> hace inutil como mecanismo para el mantenimiento de estado en
> cualquier mecanismo de infraestructura que pretenda utilizarlo (QoS,
> routing, policy filtering, etc.)...el rfc6436 hace referencia
> precisamente a esto...

Sin duda que, sin estar protegido por un mecanismo de deteccion de
errores (como un checksum), no se puede depender de la "inmutabilidad"
del FlowLabel.

Hay algunas otras cosas a tener en cuenta:

*  El "quite" de checksum en v6 viene motivado, aparentemente, por el
hecho de que en v4 muchos routers (por cuestiones de performance),
diractamente no verificaban el checksum (entonces la logica fue "si no
lo van averificar, entonces no lo ponemos).

* El checksum fue en gral, como el apendice de los seres humanos -- todo
el mundo lo tiene, pero no se sabe bien para qué.

* En materia de "QoS", mas que "hacer magia", viene a "compensar" el
hecho de que, por la estructura de encabezamientos IPv6 (header chain),
es muy dificil (o bien es posible, pero con implicancas negativas de
performance) poder encontrar aquellos campos con los que hoy se hace
distribucion de carga (direcciones IP y numeros de puerto)

* Al momento, casi nadie (alguien??) lo setea... por lo cual no se puede
hacer uso de el...

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






Más información sobre la lista de distribución Seguridad