[LAC-TF] NAT IPv6-IPv6

Carlos M. Martinez carlosm at csirt-antel.com.uy
Thu Nov 27 13:21:59 BRST 2008 

Creo que el hecho de que el NAT es horrible lo reconocen hasta los
propios proponentes de NAT66. El argumento de ellos es que igual la
gente va a querer hacer NAT y que mejor que lo hagan de una manera
estandarizada.

Habria que pesar esto contra el hecho de que si hay NAT, seguro que la
gente lo va a querer usar.

Es la maldita idea esa de que NAT == Seguridad :-) ¿En que momento se
propago eso?

slds

Carlos

Nicolas Antoniello wrote:
> 2008/11/25 Roque Gagliano <roque at lacnic.net>:
>> PAT es el nombre "Cisco", incluso ya en desuso en Cisco (comandos actuales
>> es NAT OVERLOAD).
> Si, me refería a eso justamente, al NAPT o PAT... para ser mas
> exactos, en la RFC 2663 "IP Network Address Translator (NAT)
> Terminology and Considerations" se puede ver en la sección: 4.1.2.
> Network Address Port Translation (NAPT).
> 
> 
> Quería comparti con uds. esta sección extraida de la RFC1631 - The IP
> Network Address Translator (NAT) de 1994... parece que no pusimos
> mucha atención a esto que se plantea aca:    :)
> 
> ..."Privacy, Security, and Debugging Considerations
> 
>    Unfortunately, NAT reduces the number of options for providing
>    security. With NAT, nothing that carries an IP address or information
>    derived from an IP address (such as the TCP-header checksum) can be
>    encrypted. While most application-level encryption should be ok, this
>    prevents encryption of the TCP header.
> 
>    On the other hand, NAT itself can be seen as providing a kind of
>    privacy mechanism. This comes from the fact that machines on the
>    backbone cannot monitor which hosts are sending and receiving traffic
>    (assuming of course that the application data is encrypted).
> 
>    The same characteristic that enhances privacy potentially makes
>    debugging problems (including security violations) more difficult. If
>    a host is abusing the Internet is some way (such as trying to attack
>    another machine or even sending large amounts of junk mail or
>    something) it is more difficult to pinpoint the source of the trouble
>    because the IP address of the host is hidden.
> 
> The negative characteristics are:
> 
> 1. It requires a sparse end-to-end traffic matrix. Otherwise, the NAT
>    tables will be large, thus giving lower performance. While the
>    expectation is that end-to-end traffic matrices are indeed sparse,
>    experience with NAT will determine whether or not they are. In any
>    event, future applications may require a rich traffic matrix (for
>    instance, distributed resource discovery), thus making long-term use
>    of NAT unattractive.
> 
> 2. It increases the probability of mis-addressing.
> 
> 3. It breaks certain applications (or at least makes them more difficult
>    to run).
> 
> 4. It hides the identity of hosts. While this has the benefit of
>    privacy, it is generally a negative effect.
> 
> 5. Problems with SNMP, DNS, ... you name it."...
> 
> Simplemente para tener en cuenta...    :)
> 
> Saludos,
> Nico.
> 
> 
> 2008/11/25 Roque Gagliano <roque at lacnic.net>:
>> PAT es el nombre "Cisco", incluso ya en desuso en Cisco (comandos actuales
>> es NAT OVERLOAD).
>> On Nov 24, 2008, at 1:45 PM, Nicolas Antoniello wrote:
>>
>> Estimados,
>>
>> Estamos hablando de NAT o de PAT?
>> Porque si es NAT puro, no veo como van a ocultar su topología,
>> De todas formas, para ocultar su topología en IPv6 hay otras técnicas
>> mucho mejores que el NAT (a mi entender)... por ejemplo, utilizar
>> direcciones generadas aleatoriamente dentro de un determinado rango
>> (aprovechando que los rangos son realmente grandes, etc...)
>>
>>
>> En realidad el ejemplo que yo daba era una direccion IPv6 conocida, pero que
>> sólo funciona en un contexto (la conexión externa). Una posible solución es
>> tener más de una IP por interfaz, algo que es una de las "ventajas"
>> publicitadas de IPv6.
>>
>> Por ahora sigo siendo de los que adhieren a la idea de que la seguridad
>> por ocultamiento utilizando NAT es pan para hoy y hambre para mañana.  :)
>>
>> De todas formas, sigo pensando que justamente lo que tenemos que hacer
>> es cambiar el paradigma de IPv4 en lugar de convencernos a nosotros
>> mismos de simplemente proceder igual que en IPv4.
>>
>> ... sobre el tema de reescribir las direcciones IP para bajar el numero
>> de rutas en las tablas globales... mmmm, eso ya me suena a un enorme
>> aumento de entropía en lo referente a la gestión y administración de las
>> redes y del espacio de direcciones.
>>
>>
>> En realidad GSE es una de las arquitecturas propuestas, hay otras como LISP
>> o AIP.
>> r.
>>
>> By the way... quien le pidio a Cisco eso del NAT66, si se puede saber el
>> "pecador" ?   :P
>>
>> Saludos,
>> Nico.
>>
>>
>>
>> Roque Gagliano wrote:
>>
>> hola Alejandro,
>>
>> aclaro que el ejemplo es de CIsco IT, de empresas conectándose a su red
>>
>> corporativa.
>>
>> Ahora, yo creo que hay otro elemento a considerar... NAT44 es a lo que
>>
>> todo el mundo está acostumbrado, es la realidad actual a la que vivimos.
>>
>> Hacer pensar a los administradores "con otra cabeza", lleva mucho
>>
>> esfuerzo. Esta "realidad" operativa, es lo que me da la impresión que va
>>
>> a empujarlo...
>>
>> r.
>>
>>
>> On Nov 24, 2008, at 12:19 PM, Alejandro Acosta wrote:
>>
>> Buen dia estimados,
>>
>>  En lo personal presiento que el NAT66 va a llegar. Quizas pueden
>>
>> existir justificaciones tecnicas para hacerlo y para no hacerlo, sin
>>
>> embargo estamos en un mundo comercial donde hay que ajustarse a los
>>
>> requerimiento de los clientes, como un excelente ejemplo tenemos lo
>>
>> que menciona Roque en su correo haciendo referencia a Cisco.
>>
>>  Por el momento he visto dos razones validas para hacr Nat en IPv6:
>>
>> 1) Ocultar topologia 2) Muchas personas siguen viendo el NAT como un
>>
>> pequeno grano de seguridad en redes
>>
>>  El hecho de que Cisco indique que sus clientes lo piden es un
>>
>> termometro hacia donde va a ir IPv6. Muchas veces me he reunido con
>>
>> clientes que por alguna u otra razon quien hacer las cosas de manera
>>
>> XXXX y se le explica que esa manera no es buena y de todas maneras lo
>>
>> quieren hacer. En este sentido, nosotros como tecnicos le podemos
>>
>> indicar al cliente que no es necesario NAT66 y de todas maneras el
>>
>> cliente va a querer hacer el NAT66. Si yo no complazco al cliente el
>>
>> buscara otra compania con quien hacerlo; si no lo hago yo lo hara
>>
>> otro. Muchos de ustedes diran que todos los tecnicos deben decir que
>>
>> NO y que el cliente no encontrara con quien irse..., pero esa no es la
>>
>> realidad.
>>
>>  En conclusion, IMHO presiento que el NAT66 va a llegar.
>>
>> Saludos,
>>
>> Alejandro Acosta,
>>
>> P.D. Acentos omitidos intencionalmente
>>
>> ------------------------------------------------------------------------
>>
>> *From:* lactf-bounces at lacnic.net <mailto:lactf-bounces at lacnic.net> on
>>
>> behalf of Roque Gagliano
>>
>> *Sent:* Mon 24/11/2008 9:36
>>
>> *To:* lactf at lac.ipv6tf.org <mailto:lactf at lac.ipv6tf.org>
>>
>> *Subject:* Re: [LAC-TF] NAT IPv6-IPv6
>>
>> Aquí les mando el link a la presentación que hicieron:
>>
>> http://www.ietf.org/proceedings/08nov/slides/behave-14.pdf
>>
>> Hay dos casos que discutieron (Io sé tirados de los pelos), pero sólo
>>
>> quería comentarles un poco:
>>
>> - Dos empresas interconectando sus redes y queriendo ocultar topología
>>
>> usando NAT66. El argumento es que hay empresas que se tienen que
>>
>> interconectar, pero no lo quieren hacer con las IP válidas de dentro
>>
>> de la red. Si lo hicieran y si hubiera algún ataque interno desde
>>
>> dentro de la red, el que ataca ya sabría la IP y los servicios en
>>
>> ellas. Este caso fue presentado por Cisco IT como algo que sus
>>
>> clientes piden.
>>
>> - GSE, es una arquitectura propuesta dentro del RRG (routing research
>>
>> group), pero aún en papeles. La idea es que el proveedor re-escribe
>>
>> las IPs de origen de forma de bajar la cantidad de rutas en la tabla
>>
>> global.
>>
>> slds
>>
>> r.
>>
>>
>>
>>
>> On Nov 22, 2008, at 6:56 PM, Nicolas Antoniello wrote:
>>
>> Estimados,
>>
>> Que "la gente va a pedir hacer nat" no lo veo como un argumento de
>>
>> peso para estandarizarlo, a menos que realmente exista la necesidad.
>>
>> Me gustaría saber si se maneja algún caso de estudio en el que se
>>
>> considere adecuado o incluso necesario hacer NAT en IPv6 (sin forzar
>>
>> uno claro esta)... en este momento no se me ocurre ninguno.
>>
>> De todas formas, tal vez, a esta altura (y con el aun escaso "deploy"
>>
>> que tiene IPv6 en el mundo, sería muy pero muy difícil que alguien
>>
>> planteara la necesidad de NAT (sobre todo porque creo que no la hay).
>>
>> Saludos,
>>
>> Nicolas.
>>
>>
>>
>> On 21/11/2008, at 05:57 PM, Roque Gagliano wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>>
>> Hash: SHA1
>>
>> Hola,
>>
>> Estoy en una reunión sobre NAT IPv6-IPv6 basado en el documento:
>>
>> http://tools.ietf.org/html/draft-mrw-behave-nat66-01
>>
>> Uno de los argumentos que se da es que "la gente va a pedir hacer NAT"
>>
>> y que abrí que dar "reglas" de cómo hacerlo.
>>
>> Han tenido ustedes algún caso/cliente que les ha pedido por un NAT
>>
>> IPv6-IPv6?
>>
>> slds
>>
>> r.
>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net <mailto:LACTF at lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/lactf
>>
>> _______________________________________________
>>
>> LACTF mailing list
>>
>> LACTF at lacnic.net <mailto:LACTF at lacnic.net>
>>
>> https://mail.lacnic.net/mailman/listinfo/lactf
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>>
>> LACTF mailing list
>>
>> LACTF at lacnic.net
>>
>> https://mail.lacnic.net/mailman/listinfo/lactf
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>>
>>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf

More information about the LACTF mailing list