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

[Arturo Servin]

	Como dice Fernando esto es en capa 2 donde los dispositivos son más "tontos" y tienen que ser mucho más rápidos. El fragmentar y defragmentar un paquete para ver de que se trata implica mucho procesamiento que por un lado encarece el costo de los switches y por otro los alenta. Al final en lugar de un switch de capa 2, terminas con IPS.

	Y defendiendo un poco al RA-Guard no creo que no defienda de nada, estoy de acuerdo que no es una herramienta de seguridad que te protege al 100% de ataques tipo RA, pero de que sirve, sirve.  El problema IMHO es que se le ha vendido como si resolviera el problema al 100% cuando en realidad te sirve solo para ataques involuntarios o accidentales (que por ahora son el 80% o más de los problemas que al menos nosotros hemos visto en nuestras redes de los eventos con IPv6).

	

	
Slds,
as

On 3 Feb 2012, at 00:23, Fernando Gont wrote:

> On 02/02/2012 02:32 PM, Eduardo Trápani wrote:
>>>> 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.
>> 
>> Sí, a lo que voy es que esa protección no es específica de RA-Guard (el
>> tema del documento).  De repente podría ir en un documento más general.
> 
> Hay una diferencia crucial entre RA-Guard y el caso "general": en el
> caso general, el filtrado se realiza en capa 3. En el caso de RA-Guard,
> el filtrado se realiza en capa 2.
> 
> En general, si a uno le preocupan cosas como "overlaping fragments" y
> demas, siempre podes optar por "reensamblar, y luego reenviar". SIn
> embargo, en capa 2 esto no es posible.
> 
> 
> 
>> No sé, hay algo del "scope" que me suena raro.  Como que una buena idea
>> podría pasar desapercibida.  Pero en algún lado tiene que estar.
> 
> Hay otra cuestión, no técnica, sino mas bien politica:
> 
> * El documento en cuestión ataca un problema concreto, de un dispositivo
> concreto. Si uno tuviera que hacer un I-D sobre firewalls, la longitud
> seria al menos 10x la de este documento, y el tiempo de publicacion al
> menos 2x.
> 
> * Hay mucha gente asumiendo protección mediante RA-Guard, cuando en
> realidad no los protege de nada. Este documento concientiza sobre el
> tema, y especifica como implementar RA-Guard (en particular)
> 
> 
> 
>> ¿Nadie más está sugiriendo dejar caer esos paquetes en otros documentos?
> 
> No.
> 
> 
> 
>>> 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.
>> 
>> Sí, tu mensaje me respondió.  Y lo de la practicidad es para tener en
>> cuenta, no lo había pensado tanto.  Hay usos teóricos que supongo que no
>> vale la pena proteger, sobre todo si son utilizados para atacar de
>> manera práctica.
> 
> El problema es la cuestion de complejidad. A veces se termina teniendo
> software demasiado complejo, por usos meramente teóricos, que en la
> práctica no existen.
> 
> Saludos,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont en si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog