Professional Documents
Culture Documents
Srisuresh
Request for Comments: 2663 M. Holdrege
Categora: Informativo Lucent Technologies
Agosto 1999
Nota de Copyright
Prefacio
Los autores que se enumeran son los editores de este documento, que
debe su contenido a las contribuciones de los miembros del Working
Group. Se han extrado grandes fragmentos del documento titulado
"Traductor de Direcciones de Red IP", IP Network Address Translator
(NAT), de manera casi literal, para formar la base inicial de este
documento. A los editores les gustara agradecer a los autores Pyda
Srisuresh y Kjeld Egevang dichas contribuciones. A los editores
tambin les gustara dar las gracias a Praveen Akkiraju por sus
contribuciones en la descripcin de los escenarios de despliegue de
NAT. Los editores tambin quisieran agradecer a los miembros del IESG
Scott Bradner, Vern Paxson y Thomas Narten por su detallada revisin
del documento, y por aadir claridad al texto.
Resumen
Las tcnicas IPsec, que estn pensadas para mantener las direcciones
finales de un paquete IP, no funcionarn con NAT intermedio para la
mayora de las aplicaciones en uso. Tcnicas tales como AH y ESP
protegen los contenidos de las cabeceras IP (incluyendo las
direcciones de origen y destino) de su modificacin. An as, la
principal funcin del NAT es alterar las direcciones IP en la
cabecera de un paquete.
Dese cuenta que tambin es posible que una conexin TCP termine sin
que el dispositivo NAT sea consciente del evento (por ejemplo, en el
caso de que uno o ambos extremos reinicien). En consecuencia, se
necesita recoger la basura en los dispositivos NAT para eliminar
informacin de estado intil sobre las sesiones TCP que ya no
existan. Sin embargo, por lo general no es posible distinguir entre
conexiones que han estado inactivas durante un largo tiempo de
aqullas que ya no existen. En el caso de sesiones basadas en UDP, no
hay una nica manera de determinar cundo acaba una sesin, ya que
los protocolos basados en UDP son especficos de las aplicaciones.
3. Qu es NAT ?
\ | / . /
+--------------------+ WAN . +------------------------+/
|Encaminador Regional|---------------|Encaminador frontera NAT|---
+--------------------+ . +------------------------+\
. | \
. | LAN
. ---------------
Frontera del dominio
----------------
( Dominio )
( Direcciones ) +--+
( Externo )-- |__|
( (N-Ext) ) /____\
(________________) Host-X
| (Addr-X)
|(Addr-Nx)
+--------------+
| Encaminador |
| |
| NAT |
+--------------+
|(Addr-Np)
|
----------------
( Dominio )
+--+ ( Direcciones )
|__|------( Privado )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A)
Existen dos variantes del NAT tradicional, lase NAT bsico y NAPT
(Network Address Port Translation). Se discuten en los siguientes
apartados.
y de transporte.
El NAT doble es una variante del NAT en el que tanto las direcciones
de origen como de destino son modificadas mediante NAT cuando el
datagrama atraviesa dominios de direcciones. Esto contrasta con el
NAT tradicional y con el NAT bidireccional, donde slo se traduce una
de las direcciones (bien la de origen, bien la de destino). Dese
cuenta que no hay algo as como "NAT simple".
a) En la red privada
a) En la red Pblica
Para asegurar que la conectividad de una red privada con las redes
externas se mantiene an cuando uno de los enlaces NAT falle, a
menudo es deseable conectar la red privada al mismo o mltiples
proveedores de servicio con mltiples conexiones desde el domino
privado, tanto desde la misma como desde diferentes mquinas NAT.
Por ejemplo, una red privada podra tener enlaces hacia dos
proveedores diferentes y las sesiones desde las mquinas privadas
podran fluir a travs del encaminador NAT con una mejor mtrica al
destino. Cuando uno de los encaminadores NAT falle, el otro podra
encaminar el trfico para todas las conexiones.
.
.
.
2. Asume una direccin del dominio externo cuando se comunica con las
mquinas en ese dominio. Tales direcciones pueden ser asignadas
estticamente u obtenidas dinmicamente (mediante un protocolo an
por definir) desde un nodo capaz de asignar direcciones del
dominio externo. El servidor RSA-IP poda ser el nodo que
coordinase la asignacin de direcciones del dominio externo.
.
.
.
.
.
.
Por ejemplo, una red privada virtual conectada a un socio del negocio
mediante una VPN puede utilizar NAT tradicional para comunicarse con
el asociado. De igual forma, es posible emplear NAT doble, si el
espacio de direcciones del asociado se solapa con la red privada.
Podra haber un dispositivo NAT en un extremo del tnel o en ambos
extremos. En todos los casos, se puede encriptar el trfico a lo
largo de la VPN por razones de seguridad. Aqu la seguridad se
refiere a la del trfico slo a lo largo de las VPN. La seguridad
extremo a extremo requiere confiar en los dispositivos NAT dentro de
la red privada.
Hay muchas situaciones en las que una red privada (por ejemplo, una
red corporativa) se extiende por varias localizaciones, usando
troncales pblicos para la comunicacin entre dichas localizaciones.
En tales casos, no es deseable hacer traduccin de direcciones, tanto
por el hecho de haber muchas mquinas que deseen comunicarse a lo
largo del troncal, necesitando grandes tablas de direcciones, como
por la existencia de ms aplicaciones que dependen de las direcciones
configuradas, en lugar de acudir a un servidor de nombres. A dichas
redes privadas las denominamos redes privadas particionadas mediante
troncales.
Dese cuenta que se puede usar el modo tnel ESP de IPsec siempre que
los contenidos del paquete encapsulado no se vean afectados por la
traduccin de la cabecera IP externa. Aunque esta tcnica no funciona
en despliegues NAT tradicionales (es decir, donde las mquinas no son
conscientes de la presencia de NAT), la tcnica es aplicable a IP
Especfica de Dominio segn se describe en la Seccin 5.0.
Sin embargo, hay aplicaciones tales como H.323 que utilizan una o ms
sesiones de control para establecer las caractersticas de las
sesiones que vendrn a continuacin, usando para ello la carga til
de la sesin de control. Tales aplicaciones requieren del uso de ALG
Otro caso sera cuando cada uno de los caracteres de los paquetes que
contienen comandos "PORT" o respuestas a "PASV" se envan en
datagramas separados, sin fragmentar. En este caso, NAT simplemente
debera dejar pasar los paquetes sin traducir la carga til TCP. Por
supuesto, la aplicacin fallar si la carga til necesitaba ser
alterada. An as la aplicacin podra funcionar en algunos casos,
sin modificaciones intermedias, cuando los contenidos de la carga
til sean vlidos en ambos dominios. Por ejemplo, los FTP originados
desde una mquina privada funcionaran mientras que atraviesen un
dispositivo NAT tradicional o bidireccional, siempre que la sesin de
control FTP haya utilizado el comando PASV para establecer las
sesiones de datos. La razn es que la direccin y el nmero de puerto
especificados por el servidor FTP en la respuesta PASV (enviada como
mltiples pawuetes no fragmentados) resulta vlida tal cual para la
mquina privada. El dispositivo NAT simplemente ver la siguiente
sesin de datos (con origen tambin en la mquina privada) como una
sesin TCP independiente.
NAT es una tarea que implica clculos intensivos incluso con la ayuda
de un algoritmo inteligente para el ajuste de las sumas de
verificacin, puesto que cada paquete de datos implica bsquedas y
modificaciones en la tabla de NAT. En consecuencia, la velocidad de
reenvo del encaminador puede descender considerablemente. Sin
embargo, mientras que la velocidad de proceso del dispositivo de NAT
supere la necesaria para satisfacer la velocidad de lnea, esto no
debera suponer problema alguno.
Supongamos que una mquina en una red privada inicia una sesin
multicast. El datagrama enviado por la mquina privada puede
desencadenar respuestas en el sentido contrario provenientes de
mltiples mquinas exteriores. Las implementaciones tradicionales
de NAT que utilizan un nico estado para hacer un seguimiento de
una sesin multicast no pueden determinar con seguridad si el
paquete UDP entrante es una respuesta a una sesin multicast
existente o es el comienzo de una nueva sesin UDP iniciada por un
atacante.
REFERENCIAS
[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
Agosto 1980.
[17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig
nature Option", RFC 2385, Agosto 1998.
Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Matt Holdrege
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502
Traduccin al castellano:
EMail: jdomingo@internautas.org
Copyright (C) The Internet Society (1999). Todos los derechos reser
vados.
Reconocimientos