[lacnog] Fwd: RA-Guard: Advice on the implementation (feedback requested)

[Fernando Gont]

On 02/02/2012 09:32 AM, Eduardo Trápani wrote:
> Yo soy un "nuevo" total en IPv6 y más en aspectos tan técnicos,
> espero no estar exhibiendo demasiada burricie :).  Me dio curiosidad
> el tema y si no pregunto, no aprendo.

Las preguntas no solo ayudan a quien las hace, sino que también
"fuerzan" a reevaluar las cosas a quien las recibe. ;-) Así que siempre
son bienvenidas..



>> The most effective and efficient mitigation for the RA-Guard
>> evasion vulnerability discussed in this document would be to
>> prohibit the use of IPv6 Extension Headers in Neighbor Discovery
>> messages
> 
> ¿A nadie se le ocurre un uso legítimo (futuro) de extension headers
> en esos mensajes?  Y si el problema es con los RA, ¿por qué extender
> la prohibición a toda la familia de neighbor discovery?

Nota: Ninguna de loas propuestas actuales prohibe el uso de extension
headers en si.

Basicamente, son dos I-Ds:

* Uno de ellos es para arreglar RA-Guard (el que revise ayer), y
simplemente exige que en cada paquete sea posible encontrar cual es el
protocolo que se está transportando. (esté es el que revise ayer)

* El otro
(<http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-02.txt)>, en
su momento pretendia prohibir el uso de extension headers, pero ahora
fue modificado para que solo prohiba el uso de fragmentacion.


Respecto al "uso futuro", está claro que es imposible que se le podría
ocurrir a alguien. Pero lo cierto es que por mas de diez años nadie
encontró un uso, y soportar los encabezados de extensión para Neighbor
Discovery tiene un costo en los despliegues *actuales*. (es un
"tradeoff", si asi lo queres).

De cualquier manera, fijate que en la version actual del I-D (no el que
revise ayer, sino:
<http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-02.txt>)


>> When trying to identify an ICMPv6 Router Advertisement message,
>> follow the IPv6 header chain, enforcing a limit on the maximum
>> number of Extension Headers that is allowed for each packet.  If
>> such limit is exceeded, block the packet.
> 
> Así como lo leo el bloqueo parece aplicarse a todo el tráfico, es
> decir, ¿que pasa si no había RA pero sí una cantidad excesiva de
> encabezados extendidos?  También voy a bloquear el paquete en mi
> intento de identificar el RA, ¿no?  

Si. Esto es para evitar posibles ataques de DoS, en lso que el atacante
podria enviar con una cantidad ridiculamente alta de Extension headers.

DE cualquier modo, tené en cuenta que al dia de la fecha son menos de 10
los tipos de extension headers recibidos, y que no hay motivos para
tener mas de una instancia de ellos en un mismo paquete. POr ende, si
aplicaras un limite como "10" (o incluso algo como "5"(, no
"lastimarias" ningun trafico legitimo.


>> If the layer-2 device is unable to identify whether the packet is
>> an ICMPv6 Router Advertisement message or not (i.e., the packet is
>> a fragment, and the necessary information is missing), and the IPv6
>> Source Address of the packet is a link-local address or the
>> unspecified address (::), block the packet.
> 
> Pero, ¿eso no abarca a un montón de otros potenciales paquetes?  ¿Es 
> seguro? 

Dos cosas:

* Debido al chequeo de la direccion de origen y en particular del Hop
Limit, esa arregla abarca solamente al trafico local.

* Y para que el trafico fuera afectado deberia tratarse de trafico
fragmentado, y que aparte el primer fragmento contuviera nada mas que
encabezamientos (por ejemplo 1500 bytes de *encabezamientos* en el caso
de Ethernet), y *nada* de datos. -- lo cual seria un tanto ("demasiado",
diria) loco.


> En resumen, si bien las dos soluciones finales andarían para mitigar
> el problema del RA, ¿cuánto pueden afectar otros paquetes?

Espero que lo de arriba responda un poco... En sisntesis, siempre puede
imaginar uno algun paquete que pueda sufrir por alguna politica de
filtrado. La idea es minimizar esos casos, y especialmente en los casos
practicos.

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