[LACNIC/Seguridad] [LAC-TF] Fwd: RFC 7217 on A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

[Carlos M. Martinez]

Hola,

On 5/13/14, 6:25 PM, Iván Arce wrote:
> Bueno en esto ya entramos en el terreno de las opiniones
> 
> Siguiendo esa lógica la recomendación de deshabilitar *cualquier cosa*
> sería abstracta pero consideremeos tambien que hay una industria de
> miles de millones de dólares que se dedica a solucionar ese problema
> "abstracto" de gestionar los dispositivos (de red, endpoints, móviles,
> etc) en redes corporativas.

Deshabilitar por defecto + implementar L2 security + implementar ipv6 a
nivel de borde y en los equipos de seguridad seria algo menos abstracto:
no tengo ipv6 en el 90-99% de los dispositivos, pero estoy preparado
para analizar / filtrar /  y tengo a mi personal de gestión de red
capacitado en IPv6, etc.

Deshabilitar solo, como solución cuasi-mágica, solo genera FUD, y crea
un caldo de cultivo ideal para que luego el ipv6, que no va a
desaparecer de la red completamente por un decreto corporativo, sea
usado como vector de ataque, invisible para los administradores.

Creo que hay un gap entre la literatura y las posiciones académicas en
estos temas (y en muchos otros) y lo que luego ocurre en la práctica, en
redes de verdad.


> 
> Indudablemente las cosas serían mas sencillas si la configuración por
> defecto de los dispositivos tuviera deshabilitado todo aquello que no es
> estrictamente necesario para arrancar pero sospecho que no es así no por
> motivos de seguridad para evitar generar complacencia sino porque en
> términos generales para los fabricantes y vendedores de dispositivos las
> consideraciones de seguridad no son prioritarias respecto de otras
> consideraciones. Eso, y no solo la naturaleza "abstracta" de la
> recomendación, tambien explicaría porque genera controversia en el IETF.
> 

No creo que haya intencionalidad de generar complacencia. Es una
consecuencia. Lo que no esta permitido por las politicas corporativas
queda excluido de la realidad.

No es por maldad, es porque esta gente tiene ya demasiado para hacer con
lo que 'si esta permitido'.

Una recomendación mucho mas sana podría ser: 'incluso en aquellas redes
donde no se permite el uso de ipv6 en la red corporativa, se debería
implementar ipv6 como mínimo en el equipamiento de seguridad'.

s2

Carlos



> 
> saludos,
> 
> -ivan
> 
> 
> On 5/13/14 6:12 PM, Carlos M. Martinez wrote:
>> Hola,
>>
>> On 5/13/14, 6:01 PM, Iván Arce wrote:
>>> La mejor práctica de seguridad es desactivar IPv6 (y cualquier otra
>>> funcionalidad no necesaria) y solo activarlo en el caso de que sea
>>> necesario o requerido.
>>
>> ¿Deshabilitar donde? ¿En el 100% de los dispositivos que se conectan a
>> tu red?
>>
>> Esta discusión es abstracta desde el momento que la recomendación no es
>> accionable. Entiendo perfectamente porque genera controversia en el IETF.
>>
>>>
>>> Ciertamente no es la mejor práctica para promover la adopción de IPv6 en
>>> el mundo pero si es la mejor práctica de seguridad.
>>
>> IPv6 en redes corporativas puede seguir sin desplegarse nunca y el mundo
>> va a seguir igual, no es ahi donde se juega el partido de IPv6.
>>
>> Mi punto va al corazón del argumento. Creo que deshabilitar ipv6 como
>> recomendación 'blank' así a secas ignora el comportamiento humano de
>> quienes administran esas redes, genera complacencia y por ello una
>> debilidad estructural en esas mismas redes que se intenta proteger, ya
>> que la recomendación en sí es abstracta.
>>
>> s2
>>
>> Carlos
>>
>>>
>>>
>>> -ivan
>>>
>>>
>>> On 5/13/14 2:53 PM, Arturo Servin wrote:
>>>>
>>>> También que la seguridad es tan buena como el eslabón más débil, en
>>>> estos casos el dispositivo del usuario que trae IPv6 activado por
>>>> default y que el administrador no tiene control sobre él.
>>>>
>>>> Creo que la medida no es desactivar IPv6, si no asegurar que la red esta
>>>> protegida ante ataques IPv6 aunque solo se use IPv4. Esa debe ser la
>>>> mejor práctica.
>>>>
>>>> .as
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Seguridad mailing list
>>> Seguridad en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/seguridad
>>>
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>