[LAC-TF] Seguridad y Direccionamiento IPv6
Alejandro Acosta
alejandroacostaalamo at gmail.com
Tue Sep 9 01:20:28 BRT 2014
Hola,
Como dice Carlos este caso creo que lo sacaron de proporcion.
Estuve siguiendo el thread que hablaba sobre
http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week
en nanog y luego lo pasaron a la IETF.
Trabaje cerca de 18 anos en operadores de red y perfectamente pude
haber escrito cientos de cosas similares en redes IPv4, podia hasta
decir que se consumieron mi semana, mi mes y hasta varios meses.
Tambien llame a los vendors y me pusieron ingenieros en sitio, tuve
conferencias telefónicas, tele-presencias, asistencia remotas, cambios
de hardware, de software y mucho mas. Puedo decir con certeza que tuve
problemas en casi todas las tecnologias adyacentes o en las tangentes
a IP: en routing (basico, medio y avanzado), en ARP, en STP, en SIP,
h323, QinQ, DNS, QoS, SNMP, http, smtp, etc, etc.... bueno, bueno,
tampoco me voy a quedar guindado en esto, seguro todos han pasado por
cosas parecidas.
Ahora, regresando al articulo me parece que esta muy completo pero
aun asi queria saber mas, tener mas informacion, tener trazas,
topologia, configuraciones que es evidente que nunca las veremos.
Mis comentarios los enmarco en:
- No siempre es el vendor
- No todo se arregla con patchs.
- No todos los problemas son bugs (jajaja, esta es la mas facil, como
lo dicen por alli)
- La red no es solo capa 3, en el mismo articulo hablan mucho sobre
Spanning Tree (uff, mi profundo respeto a STP!!), loops de bridge y
esas cosas
- Recuerden que a veces es capa 8 los problemas.
Abrazos,
Alejandro,
P.D Reconozco que una vez estuve con un importante cliente que tenia
una red mediana, Routers y Firewalls de ultima generacion, HSRP,
protocolo de enrutamiento dinamico, todos los periquitos
espectaculares pero unos Lan Switch 3com de hace mas de 15 anos,
compro unas super impresoras ultimo modelo que tenian IPv6 por default
y tumbaba la red constantemente. Se quito IPv6 en las impresoras y
voila. Esto fue en Feb del 2013.
2014-09-08 22:47 GMT-04:30 Carlos M. Martinez <carlosm3011 at gmail.com>:
> Comparto lo que dice Fernando, pero tambien es cierto que me parece que
> la persona que escribe eso saca los problemas de proporcion.
>
> Uno tiene que ser consciente del hardware que tiene y de sus
> limitaciones. Y esto no es solo cierto para IPv6, es cierto para
> cualquier feature que uno quiera habilitar.
>
> Siempre van a haber redes o personas que tengan mas o menos problemas.
>
> s2
>
> -Carlos
>
> On 9/8/2014 6:00 PM, Erick Lobo Marín wrote:
>> Fernando, me inquieta
>> <http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/>
>> tanto el problema como la solución de eliminar IPv6...
>> Varios de los problemas indicados son "neighbor discovery", el mecanismo
>> de privacidad IPv6 en "comunión" con una implementación "raw" del código
>> IPv6.
>> En este caso particular crees que una de las soluciones propuestas de
>> utilizar DHCPv6 en lugar de SLAAC (y el mecanismo asociado de
>> privacidad) hubiera sido un "work around" y mantener extendido el uso de
>> IPv6?
>>
>>
>>
>> Atentamente,
>> Erick Lobo
>>
>> lgD
>>
>> El 8 de septiembre de 2014, 2:47, Fernando Gont <fgont at si6networks.com
>> <mailto:fgont at si6networks.com>> escribió:
>>
>> Estimados,
>>
>> [para quienes solo estén interesados en la parte de ops, saltar a lo
>> marcado con asteriscos más abajo]
>>
>> El pasado 5 de septiembre, en el contexto de IEAR 2014
>> <http://43jaiio.sadio.org.ar/?q=IEAR>, realicé la siguiente presentación
>> <http://www.si6networks.com/presentations/iear2014/fgont-iear2014-ipv6-addressing.pdf>
>> (slide 9 solo para "endendidos" ;-) ).
>>
>>
>> Al final de la presentación se planteó una discusión con dos Directores
>> de Area de IETF, en la cual básicamente se argumentaba que la solución a
>> los problemas mencionados era utilizar RFC4941 (direcciones temporales),
>> haciendo que las mismas *nunca se vuelvan invalidas* si hay alguna
>> conexion TCP utilizandolas. Tal como lo mencioné en su momento,
>> personalmente creo que eso es equivocado (conceptualmente) asi como
>> también impracticable -- y el blog post de abajo, parece ser un
>> datapoint interesante en este aspecto...
>>
>>
>> **** Cuestiones Operacionales ****
>>
>> Irónicamente, acabo de recibir el siguiente enlace:
>> <http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/>
>>
>>
>>
>> Algunos datos interesantes:
>>
>> * RFC7217 -- que basicamente es lo que uno usaria para mitigar
>> cuestiones de seguridad/privacidad, incluso deshabilitando RFC4941 --
>> fue bastante doloroso de publicar...
>>
>> *
>> <http://tools.ietf.org/id/draft-gont-6man-managing-privacy-extensions-01.txt>
>> podría haberse utilizado para solucionar este problema sin necesidad de
>> configuración manual, ni deshabilitar IPv6... pero tuvo oposición de
>> algun fabricante por ahí.
>>
>>
>> Me embriague hasta el vacio
>> con tu miel venenosa
>> fuiste mia
>> y el hastio
>> nos llevo al desengaño
>> y eso paso
>> Fue
>>
>> (<https://www.youtube.com/watch?v=3qW9ygULVbc>)
>>
>> Saludos cordiales,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont at si6networks.com <mailto:fgont at si6networks.com>
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net <mailto:LACTF at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>> <mailto:lactf-unsubscribe at lacnic.net>
>>
>>
>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
--
=====
^A.......o$
More information about the LACTF
mailing list