Network Working Group P. Srisuresh Request for Comments: 2663 M. Holdrege Categoría: Informativo Lucent Technologies Agosto 1999 Terminología y consideraciones sobre Traducción de Direcciones IP Status de este memorándum Este memorándum proporciona información a la comunidad Internet. No especifica ningún tipo de estándar de Internet. La distribución de este memorándum es ilimitada. Nota de Copyright Copyright (C) The Internet Society (1999). Todos los derechos reservados. Prefacio El motivo de este documento es aclarar el uso de los términos usados en los Traductores de Direcciones de Red. El término "Traductor de Direcciones de Red" tiene distintos significados en contextos diferentes. La intención de este documento es definir los diversos sabores de NAT y estandarizar el significado de los términos empleados. 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 extraído 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 gustaría agradecer a los autores Pyda Srisuresh y Kjeld Egevang dichas contribuciones. A los editores también les gustaría dar las gracias a Praveen Akkiraju por sus contribuciones en la descripción de los escenarios de despliegue de NAT. Los editores también quisieran agradecer a los miembros del IESG Scott Bradner, Vern Paxson y Thomas Narten por su detallada revisión del documento, y por añadir claridad al texto. Resumen La "Traducción de Direcciones de Red", Network Address Translation, es un método por el cual se mapean las direcciones IP desde un dominio a otro, en un intento de proporcionar encaminamiento transparente a las máquinas. Tradicionalmente, los dispositivos de NAT se han usado para conectar un dominio de direcciones privadas no Srisuresh & Holdrege Informativo [Pág. 1] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 registradas aislado con un dominio externo de direcciones registradas globalmente únicas. Este documento intenta describir el funcionamiento de los dispositivos de NAT y las consideraciones generales asociadas, y definir la terminología que se usa para identificar los diversos sabores de NAT. 1. Introducción y panorama general La necesidad de la traducción de direcciones IP surge cuando las direcciones IP internas de la red no pueden ser usadas fuera de la red, bien porque no son válidas en el exterior, bien porque el direccionamiento interno debe mantenerse separado de la red externa. La traducción de direcciones permite (en muchos casos, salvo en aquellos descritos en las secciones 8 y 9) que las máquinas de una red privada se comuniquen de manera transparente con destinos en una red externa y viceversa. Hay una variedad de sabores de NAT y términos que se usan para describirlos. Este documento intenta definir la terminología que se usa, e identificar varios sabores de NAT. El documento también intenta describir otras consideraciones aplicables a los dispositivos de NAT en general. Sin embargo, dese cuenta que este documento no pretende describir el funcionamiento de las variantes concretas de NAT ni la aplicabilidad de los dispositivos de NAT. Los dispositivos de NAT intentan proporcionar una solución de encaminamiento transparente a los sistemas finales que intentan comunicarse desde dominios de direcciones dispares. Esto se consigue modificando "al vuelo" las direcciones de los nodos finales y manteniendo el estado de estos cambios para que los datagramas pertenecientes a una sesión sean encaminados hacia el nodo final correcto en cualquiera de los dominios. Esta solución sólo funciona cuando las aplicaciones no usan las direcciones IP como parte del propio protocolo. Por ejemplo, identificar los extremos usando nombres DNS en lugar de direcciones hace a las aplicaciones menos dependientes de las direcciones reales que el NAT elija, y evita la necesidad de traducir también los contenidos de los paquetes cuando NAT cambie una dirección IP. La función de NAT no puede por sí misma soportar todas las aplicaciones de manera transparente, y por esta razón a menudo debe coexistir con "Pasarelas de Nivel de Aplicación", Application Level Gateways (ALG). Quienes busquen el despliegue de soluciones fundamentadas en NAT primero deben determinar sus necesidades de aplicaciones y valorar las extensiones al NAT (por ejemplo, ALG) necesarias para proporcionar transparencia a las aplicaciones de su entorno. Srisuresh & Holdrege Informativo [Pág. 2] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Las técnicas IPsec, que están pensadas para mantener las direcciones finales de un paquete IP, no funcionarán con NAT intermedio para la mayoría de las aplicaciones en uso. Técnicas tales como AH y ESP protegen los contenidos de las cabeceras IP (incluyendo las direcciones de origen y destino) de su modificación. Aún así, la principal función del NAT es alterar las direcciones IP en la cabecera de un paquete. 2. Terminología y conceptos usados Los términos que se usan más a menudo en el contexto de NAT se definen como referencia a continuación. 2.1. Dominio de direcciones o dominio Un dominio de direcciones es un dominio de red en el que las direcciones de red son asignadas a las entidades de manera unívoca, de manera que los datagramas puedan ser encaminados hacia ellas. Los protocolos de encaminamiento que se usen en el interior del dominio de red son los responsables de encontrar las rutas hacia las entidades a partir de sus direcciones de red. Dese cuenta que este documento se limita a describir el NAT en entornos IPv4 y no se ocupa del uso de NAT en otros tipos de entornos (por ejemplo, entornos IPv6). 2.2. Encaminamiento transparente El término "encaminamiento transparente" se usa a lo largo del documento para identificar la funcionalidad de encaminamiento que proporciona un dispositivo de NAT. Ésta es diferente de la funcionalidad de encaminamiento que proporciona un dispositivo encaminador tradicional porque un encaminador tradicional encamina los paquetes en el interior de un único dominio de direcciones. El encaminamiento transparente se refiere al encaminamiento de un datagrama entre dominios de direcciones dispares, modificando los contenidos de la dirección en la cabecera IP para que la dirección sea válida en el dominio en el cual se encamina el datagrama. La Sección 3.2 contiene una detallada descripción del encaminamiento transparente. 2.3. Flujo de sesión vs. flujo de paquete Los flujos de conexión o sesión son diferentes de los flujos de paquetes. Un flujo de sesión indica la dirección en que se inició la sesión con referencia a una interfase de red. El flujo de paquetes es la dirección en la que el paquete ha viajado con referencia a un inteface de red. Por ejemplo, considere una sesión de telnet Srisuresh & Holdrege Informativo [Pág. 3] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 saliente. La sesión de telnet consiste en flujos de paquetes tanto en sentido entrante como saliente. Los paquetes de telnet salientes llevan las pulsaciones de teclas del terminal y los paquetes entrantes llevan las pantallas desde el servidor de telnet. Para los fines de este documento, una sesión se define como el conjunto de tráfico que es gestionado como una unidad para su traducción. Las sesiones TCP/UDP se identifican de manera unívoca por una tupla de (dirección IP origen, puerto TCP/UDP origen, dirección IP destino, puerto TCP/UDP destino). Las sesiones para peticiones ICMP se identifican mediante la tupla de (dirección IP origen, ID de la petición ICMP, dirección IP destino). El resto de sesiones se caracterizan por la tupla (dirección IP origen, dirección IP destino, protocolo IP). Las traducciones de direcciones realizadas por NAT están basadas en la sesión e incluirían la traducción de los paquetes tanto entrantes como salientes pertenecientes a esa sesión. La dirección de la sesión se identifica mediante la dirección del primer paquete de esa sesión (vea la Sección 2.5). Dese cuenta de que no hay garantía alguna de que la idea de una sesión, determinada por NAT como se acaba de explicar, coincida con la idea de sesión de la aplicación. Una aplicación podría ver un puñado de sesiones (sesiones de NAT) como una única sesión y podría incluso no considerar su comunicación con sus interlocutores como una sesión. No se garantiza que todas las aplicaciones funcionen a través de dominios, incluso usando ALG (definidos a continuación en la Sección 2.9) intermedios. 2.4. Puertos TU, puertos del servidor, puertos del cliente Para el resto de este documento, nos referiremos a los puertos TCP/UDP asociados con una dirección IP simplemente como "Puertos TU". Para la mayoría de las máquinas TCP/UDP, el rango de puertos TU 0-1023 es usado por servidores esperando conexiones entrantes. Los clientes que tratan de iniciar una conexión típicamente seleccionan un puerto TU origen en el rango 1024-65535. Sin embargo, este convenio no es universal y no siempre se sigue. Algunas estaciones cliente inician conexiones usando un número de puerto TU origen en el rango 0-1023, y hay servidores que escuchan en números de puerto TU en el rango 1024-65535. Se puede encontrar una lista de puertos TU asignados a servicios en la RFC 1700 [Ref 2]. 2.5. Inicio de una sesión para TCP, UDP y otros Srisuresh & Holdrege Informativo [Pág. 4] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 El primer paquete de cada sesión TCP intenta establecer una sesión y contiene información para el comienzo de la conexión. El primer paquete de una sesión TCP puede ser reconocido por la presencia del bit SYN y la ausencia del bit ACK en los flags TCP. Todos los paquetes TCP, con la excepción del primer paquete, deben tener el bit ACK establecido (N. de T.: bit establecido, puesto a uno, bit no establecido o ausente, puesto a cero). Sin embargo, no hay un método determinista de reconocer el comienzo de una sesión basada en UDP o cualquier otra sesión no TCP. Una aproximación heurística sería asumir que el primer paquete con parámetros de sesión hasta dicho momento inexistentes (como se define en la Sección 2.3) constituye el inicio de una nueva sesión. 2.6. Final de una sesión para TCP, UDP y otros El final de una sesión TCP se detecta cuando los dos extremos de la sesión asienten el FIN, o cuando cualquiera de los extremos recibe un segmento con el bit RST en el campo de flags TCP. Sin embargo, puesto que es imposible que un dispositivo NAT sepa si los paquetes que ve serán realmente entregados al destino (podrían ser descartados entre el dispositivo NAT y el destino), el dispositivo NAT no puede garantizar con seguridad que los segmentos que contienen FIN o SYN sean los últimos paquetes de una sesión (es decir, puede haber retransmisiones). En consecuencia, sólo puede asumirse el final de una sesión después de un periodo de 4 minutos contados desde el momento de su detección. La necesidad de este periodo de espera extendido se describe en el RFC 793 [Ref 7], que sugiere una duración del TIME-WAIT igual a 2 * MSL ("Vida Máxima del Segmento", Maximun Segment Lifetime) o 4 minutos. Dese cuenta que también es posible que una conexión 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 información de estado inútil 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 aquéllas que ya no existen. En el caso de sesiones basadas en UDP, no hay una única manera de determinar cuándo acaba una sesión, ya que los protocolos basados en UDP son específicos de las aplicaciones. Se usan muchas aproximaciones heurísticas para acabar las sesiones. Se puede asumir que las sesiones TCP que no se han usado durante digamos, 24 horas, y las sesiones no TCP que no se hayan usado durante un par de minutos, están finalizadas. Esta suposición funciona a menudo, pero a veces no. Estos plazos de periodo inactivo de sesión varían mucho tanto de aplicación a aplicación como de Srisuresh & Holdrege Informativo [Pág. 5] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 sesión a sesión dentro de la misma aplicación. En consecuencia, los temporizadores de sesión deben ser configurables. Incluso así, no hay garantía de poder encontrar un valor satisfactorio. Además, según se dice en la Sección 2.3, no hay garantías de que el NAT interprete el fin de la sesión de la misma manera que la aplicación lo hace. Otra manera de manejar las finalizaciones de las sesiones es fechar las entradas y mantenerlas el mayor tiempo posible, y retirar la sesión que más tiempo lleve inactiva cuando sea necesario. 2.7. Red pública/global/externa Una red global o pública es un dominio de direcciones con direcciones de red únicas asignadas por el Internet Assigned Numbers Authority (IANA) o un registro de direcciones equivalente. Al hablar de NAT a esta red también se la conoce como red externa. 2.8. Red privada/local Una red privada es un dominio de direcciones independiente de las direcciones de las red externas. A la red interna también se la conoce alternativamente como red local. El encaminamiento transparente entre máquinas de un dominio privado y un dominio externo es proporcionado por un encaminador NAT. El RFC 1918 [Ref 1] incluye recomendaciones acerca de la asignación de espacio para las redes privadas. El Internet Assigned Numbers Authority (IANA) dispone de tres bloques de direcciones IP, en concreto 10/8, 172.16/12, y 192.168/16 reservados pata internets privadas. En notación pre-CIDR, el primer bloque no más que un único número de red de clase A, mientras que el segundo bloque es un conjunto de 16 redes consecutivas de clase B, y el tercer bloque es un conjunto de 256 redes consecutivas de clase C. Una organización que decida usar direcciones IP en el espacio de direccionamiento definido arriba, puede hacerlo sin coordinarse con el IANA o cualquier otro registro de Internet tales como APNIC, RIPE y ARIN. Así, el espacio de direccionamiento puede ser utilizado de manera privada por muchas organizaciones independientes al mismo tiempo. Sin embargo, si más tarde estas organizaciones independientes deciden que desean comunicarse con las demás o con la Internet pública deberán, bien numerar de nuevo sus redes, bien habilitar NAT en sus encaminadores fronterizos. 2.9. Pasarela de Nivel de Aplicación, Application Level Gateway (ALG) No todas las aplicaciones permiten la traducción sencilla por parte de los dispositivos NAT; especialmente aquellas que incluyen las Srisuresh & Holdrege Informativo [Pág. 6] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 direcciones IP y los puertos TCP/UDP en la carga útil de los paquetes. Las "Pasarelas de Nivel de Aplicación", Application Level Gateways (ALG), son agentes de traducción específicos de aplicación que permiten que una aplicación en una máquina de un dominio de direcciones se conecte a su corresponsal ejecutándose en una máquina de un dominio diferente, de manera transparente. Una ALG puede interactuar con NAT para establecer el estado, usar información de estado de NAT, modificar la carga útil específica de la aplicación y cualquier otra cosa necesaria para conseguir que la aplicación funcione a través de dominios de direcciones distintos. Las ALG no tienen porqué usar siempre información de estado de NAT. Pueden echar un vistazo a la carga útil y simplemente notificar al NAT para que añada información de estado adicional en ciertos casos. Las ALG son parecidas a los proxys en que, tanto las ALG como los proxys, proporcionan comunicación específica de aplicación entre clientes y servidores. Los proxys utilizan un protocolo especial para comunicarse con clientes proxy y entregar los datos del cliente a los servidores y viceversa. A diferencia de los proxys, las ALG no usan un protocolo especial para comunicarse con las aplicaciones cliente y no necesitan de cambios en las aplicaciones cliente. 3. ¿ Qué es NAT ? La "Traducción de Direcciones de Red", Network Address Translation (NAT), es un método mediante el que las direcciones IP son mapeadas desde un dominio de direcciones a otro, proporcionando encaminamiento transparente a las máquinas finales. Existen muchas variantes de traducción de direcciones que se prestan a distintas aplicaciones. Sin embargo, todos las variantes de dispositivos NAT deberían compartir las siguientes características: a) Asignación transparente de direcciones. b) Encaminamiento transparente mediante la traducción de direcciones (aquí el encaminamiento se refiere al reenvío de paquetes, no al intercambio de información de encaminamiento). c) Traducción de la carga útil de los paquetes de error ICMP. A continuación se muestra un diagrama que ilustra un escenario donde se habilita NAT en un encaminador fronterizo de la zona, conectado a Internet a través de un encaminador regional proporcionado por un proveedor de servicios. Srisuresh & Holdrege Informativo [Pág. 7] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 \ | / . / +--------------------+ WAN . +------------------------+/ |Encaminador Regional|---------------|Encaminador frontera NAT|--- +--------------------+ . +------------------------+\ . | \ . | LAN . --------------- Frontera del dominio Figura 1: Un escenario de operación NAT típico 3.1. Asignación transparente de direcciones NAT asocia direcciones en la red privada con direcciones en la red global, y viceversa, para proporcionar un encaminamiento transparente a los datagramas que atraviesen varios dominios de direcciones. En algunos casos la asociación puede extenderse a los identificadores de nivel de transporte (como los puertos TCP/UDP). La asociación de direcciones se realiza al comienzo de una sesión. Las siguientes subsecciones describen dos tipos de asignaciones de direcciones. 3.1.1. Asignación estática de direcciones En el caso de asignación estática de direcciones, existe un mapeo uno a uno de direcciones para las máquinas entre una dirección privada de red y una dirección externa de red durante el tiempo en funcionamiento del NAT. La asignación estática de direcciones asegura que NAT no tiene que administrar la gestión de direcciones con los flujos de sesión. 3.1.2. Asignación dinámica de direcciones En este caso, las direcciones externas son asignadas a las máquinas de la red privada, o viceversa, de manera dinámica, basándose en los requisitos de uso y el flujo de sesión que el NAT determine heurísticamente. Cuando la última de las sesiones que use una dirección asociada termine, NAT liberará la asociación para que la dirección global pueda ser reciclada para su posterior uso. La naturaleza exacta de la asignación de direcciones es específica de cada implementación de NAT. 3.2. Encaminamiento transparente Un encaminador NAT se sitúa en la frontera entre dos dominios de direcciones y traduce las direcciones en las cabeceras IP para que cuando el paquete abandone un dominio y entre en otro, pueda ser correctamente encaminado. Puesto que los dispositivos NAT tienen conexiones a múltiples dominios de direcciones, deben tener cuidado Srisuresh & Holdrege Informativo [Pág. 8] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 de no propagar inadecuadamente información (por ejemplo, vía protocolos de encaminamiento) acerca de redes desde un dominio de direcciones a otro, donde tal anuncio sería juzgado inaceptable. Hay tres fases en la traducción de direcciones, que se explican a continuación. En conjunto, estas fases resultan en la creación, mantenimiento y terminación del estado de las sesiones que pasan a través de los dispositivos NAT. 3.2.1. Asociación de direcciones La asociación de direcciones es la fase en la que la dirección IP de un nodo local es asociada con una dirección externa, o viceversa, con el objetivo de su traducción. La asociación de direcciones es fija con asignaciones estáticas de direcciones, y es dinámica al comienzo de la sesión con asignaciones dinámicas de direcciones. Una vez realizada la asociación entre las dos direcciones, todas las sucesivas sesiones con origen o destino en esta máquina usarán la misma asociación para la traducción de paquetes basada en sesión. Las nuevas asociaciones de direcciones se hacen al comienzo de una nueva sesión, si tal asociación de direcciones no existe aún. Cuando una dirección local está ligada a una dirección externa, todas las sucesivas sesiones con origen en la misma dirección local, o dirigidas a la misma dirección local usarán la misma asociación. El comienzo de cada nueva sesión resultará en la creación de información de estado para facilitar la traducción de los datagramas pertenecientes a la sesión. Puede haber muchas sesiones simultáneas con origen en la misma máquina, basadas en una única asociación de direcciones. 3.2.2. Búsqueda de direcciones y traducción Una vez establecida la información de estado para una sesión , todos los paquetes que pertenezcan a la sesión estarán sujetos a la búsqueda de la dirección (y en algunos casos, la búsqueda del identificador de transporte) y a su traducción. La traducción de la dirección o del identificador de transporte para un datagrama resultará en el reenvío del datagrama desde el dominio de direcciones origen al dominio de direcciones destino con las direcciones de red apropiadamente actualizadas. 3.2.3. Desasociación de direcciones La desasociación de direcciones es la fase en la que una dirección privada deja de estar asociada con una dirección global a efectos de Srisuresh & Holdrege Informativo [Pág. 9] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 traducción. NAT llevará a cabo la desasociación de direcciones cuando piense que la última sesión que usaba dicha asociación ha terminado. Consulte la Sección 2.6 para encontrar algunos métodos heurísticos para manejar el final de las sesiones. 3.3. Traducción de los paquetes de error ICMP Todos los mensajes de error ICMP (con la excepción del tipo de mensaje Redirect) necesitarán ser modificados al pasar a través de NAT. Los tipos de mensaje de error ICMP que necesitan ser modificados por el NAT incluirán Destination-Unreachable, Source-Quench, Time- Exceeded y Parameter-Problem. NAT no debería intentar la modificación de un mensaje de tipo Redirect. Los cambios en los mensajes de error ICMP incluirán cambios en el paquete IP original (o partes de él) incluido en la carga útil del mensaje de error ICMP. A fin de que NAT sea completamente transparente para los nodos finales, las direcciones IP de la cabecera IP incluida en la carga útil del paquete ICMP deben ser modificadas, el campo suma de verificación de la misma cabecera IP debe ser modificado en consonancia, así como la cabecera de transporte que la acompaña. La suma de verificación de la cabecera IP debe ser modificada para reflejar los cambios realizados en la carga útil a las cabeceras IP y de transporte. Además, la cabecera IP normal también debe ser modificada. 4.0. Varios sabores de NAT Existen diversas variantes de traducción de direcciones, cada una de las cuales se presta a diferentes aplicaciones. La lista de variantes de NAT que se enumera en las subsecciones siguientes no es ni mucho menos exhaustiva, pero trata de mostrar las diferencias más significativas existentes. El siguiente diagrama se va a usar como modelo básico para ilustrar las variantes de NAT. La máquina Host-A, con dirección Addr-A, se encuentra en un dominio privado, representado por la red N-Pri. N-Pri está aislada del dominio de red externo mediante un encaminador NAT. La máquina Host-X, con dirección Addr-X, se encuentra en un dominio externo, representado por la red N-Ext. El encaminador NAT con dos interfases, cada una enganchada a uno de los dominios, proporciona encaminamiento transparente entre los dos dominios. La interfase hacia el dominio externo tiene asignada una dirección de Addr-Nx y la interfase hacia el dominio privado tiene asignada una dirección de Addr-Np. Además, se puede considerar que las direcciones Addr-A y Addr-Np corresponden a la red N-Pri y que las direcciones Addr-X y Addr-Nx corresponden a la red N-Ext. Srisuresh & Holdrege Informativo [Pág. 10] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 ---------------- ( Dominio ) ( Direcciones ) +--+ ( Externo )-- |__| ( (N-Ext) ) /____\ (________________) Host-X | (Addr-X) |(Addr-Nx) +--------------+ | Encaminador | | | | NAT | +--------------+ |(Addr-Np) | ---------------- ( Dominio ) +--+ ( Direcciones ) |__|------( Privado ) /____\ ( (N-pri) ) Host-A (________________) (Addr-A) Figura 2: Un modelo base para ilustrar la terminología de NAT. 4.1. NAT Tradicional (o) NAT Saliente El NAT tradicional permitirá, en la mayoría de los casos, que las máquinas en el interior de una red privada accedan de manera transparente a máquinas en la red externa. En un NAT tradicional, las sesiones son unidireccionales, salientes desde la red privada. Esto contrasta con el NAT bidireccional, que permite sesiones en los sentidos tanto saliente como entrante. Se puede encontrar una descripción detallada del NAT bidireccional en la Sección 4.2. A continuación se describen las propiedades de los dominios soportados por el NAT tradicional. Las direcciones IP de las máquinas en la red externa son únicas y válidas tanto en la red externa como en la interna. Sin embargo, las direcciones de las máquinas en la red privada son únicas sólo en el interior de la red privada y pueden no ser válidas en la red externa. En otras palabras, el NAT no anunciará las redes privadas al dominio externo. Pero las redes del dominio externo pueden ser anunciadas en el interior de la red privada. Las direcciones usadas en el interior de la red privada no deben solaparse con las direcciones externas. Cualquier dirección dada debe ser, bien una dirección privada, bien una dirección externa; no ambas. Srisuresh & Holdrege Informativo [Pág. 11] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Un encaminador NAT tradicional en la Figura 2 permitirá a la máquina Host-A iniciar sesiones hacia Host-X, pero no en el sentido contrario. También, N-Ext es encaminable desde el interior de N-Pri, mientras que N-Pri puede no ser encaminable desde N-Ext. El NAT tradicional se usa principalmente en lugares que usan direcciones privadas y desean permitir sesiones salientes desde sus instalaciones. Existen dos variantes del NAT tradicional, léase NAT básico y NAPT (Network Address Port Translation). Se discuten en los siguientes apartados. 4.1.1. NAT básico Con el NAT básico, un bloque de direcciones externas se reserva para traducir direcciones de máquinas en el dominio privado según originen sesiones hacia el dominio externo. Para los paquetes salientes desde la red privada, la dirección IP de origen y campos relacionados tales como las sumas de verificación de las cabeceras IP, TCP, UDP e ICMP son traducidos. Para los paquetes entrantes, se traducen la dirección IP de destino y las sumas de verificación recién enumeradas. Un encaminador NAT básico en la Figura 2 puede ser configurado para traducir N-Pri en un bloque de direcciones externas, por ejemplo desde Addr-i hasta Addr-n, seleccionadas de la red externa N-Ext. 4.1.2. Network Address Port Translation (NAPT) La "Traducción de Dirección de Red y Puerto", Network Address Port Translation (NAPT), extiende la noción de traducción un paso más allá, porque también traduce el identificador de transporte (por ejemplo, los números de puerto TCP y UDP, y los identificadores de petición ICMP). Esto permite que los identificadores de transporte de un cierto número de máquinas privadas sean multiplexados en los identificadores de transporte de una única dirección externa. NAPT permite a un conjunto de máquinas compartir una única dirección externa. Dese cuenta que NAPT se puede combinar con NAT básico para que se use un bloque de direcciones externas en conjunto con la traducción de puertos. Para los paquetes salientes de la red privada, NAPT traducirá la dirección IP de origen, el identificador de transporte origen y los campos relacionados tales como las sumas de verificación de las cabeceras IP, TCP, UDP e ICMP. El identificador de transporte puede ser el puerto TCP/UDP o el ID de la petición ICMP. Para los paquetes entrantes, se traducen la dirección IP de destino, el identificador de transporte destino y las sumas de verificación de las cabeceras IP Srisuresh & Holdrege Informativo [Pág. 12] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 y de transporte. Un encaminador NAPT en la Figura 2 puede ser configurado para traducir las sesiones con origen en N-Pri en una única dirección externa, Addr-i. Muy a menudo, la dirección de la interfase externa del encaminador NAPT, Addr-Nx, se usa como la dirección hacia la que mapear N-Pri. 4.2. NAT bidireccional (o) NAT de doble sentido Con el NAT bidireccional, las sesiones pueden iniciarse tanto desde máquinas en la red pública como desde máquinas en la red privada. Las direcciones de la red privada se asocian a direcciones globales únicas, estática o dinámicamente, según se establecen las conexiones en cualquier sentido. El espacio de nombres (es decir, sus "Nombres de Dominio Plenamente Cualificados", Fully Qualified Domain Names (FQDN)) entre las máquinas de las redes privada y externa se supone único extremo a extremo. Las máquinas en el dominio externo acceden a las máquinas del dominio privado usando DNS para la resolución de direcciones. Debe utilizarse un DNS-ALG junto con NAT bidireccional para facilitar el mapeo de nombres a direcciones. En concreto, el DNS-ALG debe ser capaz de traducir las direcciones del dominio privado en consultas DNS y las respuestas en sus direcciones del dominio externo asociadas, y viceversa, según los paquetes DNS viajan entre los dominios privado y externo. Los requisitos del espacio de direcciones indicados para los encaminadores NAT tradicionales son también aplicables aquí. Un encaminador NAT bidireccional en la Figura 2 permitirá que Host-A inicie sesiones hacia Host-X, y que Host-X inicie sesiones hacia Host-A. Al igual que con NAT tradicional, N-Ext es encaminable desde el interior de N-Pri, pero N-Pri puede no ser encaminable desde N- Ext. 4.3. NAT doble 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 sólo se traduce una de las direcciones (bien la de origen, bien la de destino). Dese cuenta que no hay algo así como "NAT simple". El NAT doble es necesario cuando los dominios privado y externo tienen colisiones de direcciones. El caso más habitual donde podría ocurrir esto es cuando un lugar ha numerado (inadecuadamente) sus Srisuresh & Holdrege Informativo [Pág. 13] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 nodos internos usando direcciones públicas que han sido asignadas a otra organización. Alternativamente, un sitio puede haber cambiado de uno a otro proveedor, pero manteniendo las direcciones (internamente) que le habían sido asignadas por el primer proveedor. De esta manera, ese proveedor podría más tarde reasignar estas direcciones a algún otro cliente. El elemento clave en estos casos es que la dirección de la máquina en el dominio externo puede haber sido asignada a la misma dirección que una máquina en el sitio local. Si esas direcciones aparecieran en un paquete, éste sería reenviado al nodo interno en lugar de al dominio externo a través del dispositivo de NAT. El NAT doble intenta puentear estos dominios traduciendo las direcciones de origen y destino de los paquetes IP, según el paquete atraviesa dominios. El NAT doble funciona como se describe a continuación. Cuando Host-A desea iniciar una sesión hacia Host-X, emite una petición DNS para el Host-X. Un DNS-ALG intercepta la consulta DNS, y en la respuesta que devuelve a Host-A el DNS-ALG sustituye la dirección del Host-X con una que sea adecuadamente encaminable en el sitio local (digamos Host-XPRIME). Entonces el Host-A inicia la comunicación con Host- XPRIME. Cuando los paquetes atraviesan el dispositivo NAT, la dirección IP de origen se traduce (como en el caso de NAT tradicional) y la dirección de destino se traduce a Host-X. En los paquetes de vuelta desde Host-X se lleva a cabo una traducción similar. A continuación se describen las propiedades de los dominios soportados por NAT doble. Las direcciones de red de las máquinas en la red externa son únicas en las redes externas, pero no en el interior de la red privada. De igual manera, las direcciones de red de las máquinas en la red privada son únicas sólo en el interior de la red privada. En otras palabras, el espacio de direcciones usado en la red privada para localizar máquinas en las redes privada y pública no está relacionado con el espacio de direcciones usado en la red pública para localizar máquinas en las redes privada y pública. El NAT doble no debería poder anunciar las redes locales a la red externa, y viceversa. Un encaminador NAT doble en la Figura 2 permitiría al Host-A iniciar sesiones hacia Host-X, y al Host-X iniciar sesiones hacia Host-A. Sin embargo, N-Ext (o un subconjunto de N-Ext) no es encaminable desde el interior de N-Pri, y N-Pri no es encaminable desde N-Ext. Es típico utilizar NAT doble cuando el espacio de direcciones usado en la red privada se solapa con direcciones usadas en el espacio público. Por ejemplo, digamos que un sitio privado usa el espacio de direcciones 200.200.200.0/24, que está oficialmente asignado a otro sitio en la Internet pública. Host_A (200.200.200.1) en el espacio Srisuresh & Holdrege Informativo [Pág. 14] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 privado trata de conectar con Host_X (200.200.200.100) en el espacio público. Para que esta conexión funcione, la dirección de Host_X se mapea a una dirección diferente para Host_A, y viceversa. El NAT doble situado en la frontera del sitio privado se puede configurar como sigue: Privado a Público: 200.200.200.0/24 -> 138.76.28.0/24 Público a Privado: 200.200.200.0/24 -> 172.16.1.0/24 Flujo de datagramas: Host_A(Privado) -> Host_X(Público) a) En la red privada DA: 172.16.1.100 SA: 200.200.200.1 b) Después de la traducción del NAT doble DA: 200.200.200.100 SA: 138.76.28.1 Flujo de datagramas Host_X (Público) -> Host_A (Privado) a) En la red Pública DA: 138.76.28.1 SA: 200.200.200.100 b) Después de la traducción del NAT doble, en la red privada SA: 200.200.200.1 DA: 172.16.1.100 4.4. Multihomed NAT Existen limitaciones en el uso de NAT. Por ejemplo, las peticiones y las respuestas pertenecientes a una sesión deben ser encaminadas a través del mismo encaminador NAT, puesto que un encaminador NAT mantiene la información de estado para las sesiones establecidas a través suyo. Por esta razón, a menudo se sugiere que los encaminadores NAT se sitúen en un encaminador fronterizo único para un dominio, donde todos los paquetes IP están, bien originados en el dominio, bien destinados a él. Sin embargo, tal configuración llevaría al encaminador NAT a convertirse en [un punto vulnerable centralizado: ]. Para asegurar que la conectividad de una red privada con las redes externas se mantiene aún cuando uno de los enlaces NAT falle, a menudo es deseable conectar la red privada al mismo o múltiples proveedores de servicio con múltiples conexiones desde el domino privado, tanto desde la misma como desde diferentes máquinas NAT. Srisuresh & Holdrege Informativo [Pág. 15] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Por ejemplo, una red privada podría tener enlaces hacia dos proveedores diferentes y las sesiones desde las máquinas privadas podrían fluir a través del encaminador NAT con una mejor métrica al destino. Cuando uno de los encaminadores NAT falle, el otro podría encaminar el tráfico para todas las conexiones. Múltiples máquinas NAT o múltiples enlaces en la misma máquina NAT, compartiendo la misma configuración de NAT, pueden proporcionarse respaldo a prueba de fallos entre sí. En tal caso, es necesario que el dispositivo NAT de respaldo intercambie información de estado para que el NAT de respaldo pueda hacerse cargo de la carga de sesiones de manera transparente cuando el NAT primario falle. El NAT de respaldo se simplifica cuando la configuración está basada en mapas estáticos. 5.0. IP Específico de Dominio, Realm Specific IP (RSIP) El "IP Específico de Dominio", Realm Specific IP (RSIP), se usa para caracterizar la funcionalidad de una máquina consciente de los dominios en un dominio privado, máquina que asume direcciones IP específicas del dominio para comunicarse con máquinas en los dominios privado o externo. Un "Cliente IP Específico de Dominio", Realm Specific IP Client (cliente RSIP), es una máquina en una red privada que adopta una dirección en el dominio externo cuando se conecta a máquinas en ese dominio, para lograr la comunicación extremo a extremo. En estas condiciones, los paquetes generados por una máquina en cualquier extremo estarían basados en direcciones que son únicas extremo a extremo en el dominio externo y no requieren de traducción por un proceso intermedio. Un "Servidor IP Específico de Dominio", Realm Specific IP Server (servidor RSIP), es un nodo que reside en los dominios privado y externo, y que puede facilitar el encaminamiento de los paquetes del dominio externo dentro de un dominio privado. Estos paquetes son, bien generados por un cliente RSIP, bien dirigidos a un cliente RSIP. El servidor RSIP también puede ser el nodo que asigne las direcciones del dominio externo a los clientes RSIP. Existen dos variantes de RSIP, llamadas "IP de Dirección Específica de Dominio", Realm-Specific Address IP (RSA-IP), e "IP de Dirección y Puerto Específicos de Dominio", Realm-Specific Address and Port IP (RSAP-IP). Estas variantes se discuten en las siguientes subsecciones. 5.1. IP de Dirección Específica de Dominio (RSA-IP) Un cliente de Dirección IP Específica de Dominio (RSA-IP), cuando se Srisuresh & Holdrege Informativo [Pág. 16] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 conecta a una máquina en un dominio externo, adopta una dirección de un espacio de direcciones externo. Una vez que un cliente RSA-IP asume una dirección externa, ninguna otra máquina en los dominios privado o externo puede asumir la misma dirección, hasta que esa dirección sea liberada por el cliente RSA-IP. A continuación se discuten las alternativas de encaminamiento que se pueden intentar para los paquetes RSA-IP extremo a extremo dentro del dominio privado. Una aproximación podría ser enviar el paquete por un túnel hasta el destinatario. La cabecera externa se puede traducir mediante NAT como habitualmente, sin afectar a las direcciones que se usan en la cabecera interna. Otra posibilidad sería establecer un túnel bidireccional entre el cliente RSA-IP y el encaminador frontera que separa los dos dominios de direcciones. Los paquetes desde y hacia el cliente serían enviados por el túnel, pero los paquetes serían reenviados de la forma habitual entre el encaminador fronterizo y el destino remoto. Dese cuenta que el túnel ENTRE el cliente Y el encaminador fronterizo puede no ser necesario. Podría bastar simplemente con reenviar el paquete directamente. Esto debería funcionar siempre que la red interna no esté filtrando paquetes en función de sus direcciones de origen (que en este caso serían direcciones externas). Por ejemplo, Host-A en la Figura 2 anterior, podría asumir una dirección Addr-k del dominio externo y actuar como un cliente RSA-IP para permitir las sesiones extremo a extremo entre Addr-k y Addr-X. Se puede ilustrar el paso de los paquetes extremo a extremo dentro del dominio privado de la siguiente manera: Srisuresh & Holdrege Informativo [Pág. 17] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Primer método, usando un encaminador NAT intermedio para traducir: ================================================================= Host-A Encaminador NAT Host-X ------ --------------- ------ , encapsulando --------------------------------> , encapsulando -------------------------------> . . . , encapsulando <---------------------------------- , encapsulando <------------------------------------- Srisuresh & Holdrege Informativo [Pág. 18] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Segundo método, usando un túnel dentro del dominio privado: ========================================================== Host-A Encaminador NAT Host-X ------ --------------- ------ , encapsulando -----------------------------> -------------------------------> . . . <-------------------------------- , encapsulando <--------------------------------- Pueden existir otras alternativas que considerar. Un cliente RSA-IP tiene las siguientes características. El conjunto de todas las operaciones llevadas a cabo por un cliente RSA-IP puede denominarse "RSA-IP". 1. Es consciente de a quién pertenecen sus nodos interlocutores. 2. Asume una dirección del dominio externo cuando se comunica con las máquinas en ese dominio. Tales direcciones pueden ser asignadas estáticamente u obtenidas dinámicamente (mediante un protocolo aún por definir) desde un nodo capaz de asignar direcciones del dominio externo. El servidor RSA-IP podía ser el nodo que coordinase la asignación de direcciones del dominio externo. Srisuresh & Holdrege Informativo [Pág. 19] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 3. Encaminar los paquetes a las máquinas externas usando una estrategia adecuada para el servidor RSA-IP. En todos los casos, el cliente RSA-IP probablemente necesitará actuar como uno de los extremos del túnel, capaz de encapsular los paquetes extremo a extremo, al tiempo que reenvía y desencapsula en el trayecto de vuelta. El Servidor de Dirección IP Específica de Dominio (Servidor RSA-IP) es un nodo que reside tanto en el dominio privado como en el externo, y que proporciona encaminamiento en el interior de un dominio privado a los paquetes del dominio externo específicos de los clientes RSA- IP. Un servidor RSA-IP puede ser descrito como aquél que dispone de las siguientes características. 1. Puede ser configurado para asignar direcciones desde el dominio externo a los clientes RSA-IP, bien estática o dinámicamente. 2. Debe ser un encaminador que resida tanto en el dominio de direcciones privado como en el externo. 3. Debe ser capaz de proporcionar un mecanismo para encaminar los paquetes del dominio externo dentro del dominio privado. De las dos aproximaciones descritas, la primera de ellas requiere que el servidor RSA-IP sea un encaminador NAT que proporcione encaminamiento transparente para la cabecera externa. Esta aproximación requiere que el interlocutor externo sea un extremo del túnel. Con la segunda aproximación, un servidor RSA-IP podría ser cualquier cualquier encaminador (incluyendo un encaminador NAT) que pueda ser un extremo del túnel con los clientes RSA-IP. El encaminador extrería del túnel los paquetes extremo a extremo salientes de los clientes RSA-IP y los reenviaría a las máquinas externas. En el camino de vuelta, localizaría el túnel del cliente RSA-IP, basado en la dirección destino de los paquetes extremo a extremo y encapsularía el paquete en un túnel para reenviarlo al cliente RSA-IP. Los clientes RSA-IP pueden intentar cualquiera de las técnicas IPsec, a saber, identificación y confidencialidad en modo transporte o túnel, usando cabeceras AH y ESP en los paquetes encapsulados. Cualquiera de las técnicas de túneles pueden ser adaptadas para la encapsulación entre el cliente RSA-IP y el servidor RSA-IP, o entre el cliente RSA-IP y las máquinas externas. Por ejemplo, la encapsulación IPsec en modo túnel es un tipo de encapsulación válido que asegura la autenticación y la confidencialidad IPsec de los paquetes extremo a extremo encapsulados. Srisuresh & Holdrege Informativo [Pág. 20] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 5.2 Dirección y Puerto IP específicos de Dominio (RSAP-IP) Dirección y Puerto IP Específicos de Dominio (RSAP-IP) es una variante de RSIP que permite a múltiples máquinas privadas usar una única dirección externa, multiplexando según los IDentificadores de transporte (es decir, los número de puerto TCP/UDP y los IDentificadores de consulta ICMP). Se puede definir el "Cliente RSAP-IP" como parecido a un cliente RSA- IP con la variación de que un cliente RSAP-IP asume una tupla (dirección externa, identificador de transporte) cuando se conecta a máquinas en el domino externo para lograr la comunicación extremo a extremo. En este caso, la comunicación de un cliente RSAP-IP con los nodos externos puede quedar limitada a sesiones TCP, UDP e ICMP. Un "Servidor RSAP-IP" se parece a un servidor RSA-IP en que facilita el encaminamiento de paquetes del dominio externo pertenecientes a los clientes RSAP-IP en el interior de un dominio privado. Lo habitual es que el servidor RSAP-IP también sea el que asigne las tuplas (dirección externa, identificador de transporte) a los clientes RSAP-IP. Un encaminador NAPT intermedio puede valer como servidor RSAP-IP, cuando la encapsulación externa está basada en TCP/UDP y esté direccionado entre el cliente RSAP-IP y el interlocutor externo. Esta aproximación requiere que el interlocutor externo sea uno de los extremos del túnel basado en TCP/UDP. Usando esta aproximación, los clientes RSAP-IP puedes utilizar cualquiera de las técnicas IPsec, identificación y confidencialidad en modo transporte o túnel, usando cabeceras AH y ESP en los paquetes encapsulados. Sin embargo, dese cuenta que el modo túnel IPsec no es un tipo válido de encapsulación, puesto que un encaminador NAPT no puede proporcionar encaminamiento transparente a los protocolos AH y ESP. Alternativamente, se puede enviar los paquetes por un túnel entre el cliente RSAP-IP y el servidor RSAP-IP, de manera que el servidor RSAP-IP sacaría los paquetes del túnel provenientes de los clientes RSAP-IP y los reenviaría a las máquinas externas. En el camino de vuelta, el servidor RSAP-IP localizaría el túnel del cliente RSAP-IP, basándose en la tupla (dirección destino, identificador de transporte) y encapsularía el paquete original dentro de un túnel para reenviarlo al cliente RSAP-IP. Con esta aproximación, no hay limitación en la técnica de túneles utilizada entre el cliente RSAP- IP y el servidor RSAP-IP. Sin embargo, existen limitaciones que aplican a la seguridad basada en IPsec de los paquetes extremo a extremo. Se puede conseguir identificación e integridad basados en modo transporte. Pero no se puede permitir la confidencialidad porque el servidor RSAP-IP debe ser capaz de examinar el identificador de Srisuresh & Holdrege Informativo [Pág. 21] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 transporte destino para así poder identificar el túnel RSAP-IP por el que enviar los paquetes que le lleguen. Por esta razón, sólo los paquetes TCP, UDP e ICMP protegidos mediante identificación AH y ESP en modo transporte pueden atravesar un servidor RSAP-IP usando esta aproximación. Por ejemplo, supongamos que Host-A de la Figura 2 anterior obtiene una tupla (Addr-Nx, puerto TCP T-Nx) de un encaminador NAPT para actuar como cliente RSAP-IP e iniciar sesiones TCP extremo a extremo con Host-X. El paso de los paquetes extremo a extremo dentro del dominio privado se puede ilustrar como se muestra a continuación. En el primer método, la capa externa del paquete desde Host-A usa (dirección privada Addr-A, puerto origen T-Na) como tupla origen para comunicarse con Host-X. El encaminador NAPT intermedio traduce esta tupla a (Addr-Nx, puerto T-Nxa). Esta traducción es independiente de los parámetros de la tupla del cliente RSAP-IP usados en el paquete encapsulado. Srisuresh & Holdrege Informativo [Pág. 22] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Primer método, usando un encaminador NAPT intermedio para traducir: ================================================================== Host-A Encaminador NAPT Host-X ------ ---------------- ------ , encapsulando -----------------------------> , encapsulando ---------------------------------------> . . . , encapsulando <------------------------------------- , encapsulando <----------------------------------- Srisuresh & Holdrege Informativo [Pág. 23] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Segundo método, usando un túnel dentro del dominio privado: ========================================================== Host-A Encaminador NAPT Host-X ------ ---------------- ------ , encapsulando -----------------------------> --------------------------------> . . . <---------------------------------- , encapsulando <---------------------------------- 6.0. Redes privadas y túneles Consideremos el caso donde su red privada se conecta al mundo exterior mediante túneles. En tal caso, el tráfico encapsulado en los túneles puede o no contener paquetes traducidos dependiendo de las características de los dominios de direcciones que un túnel esté enlazando. Las siguientes subsecciones discuten dos escenarios donde se usan túneles (a) junto con traducción de direcciones, y (b) sin traducción. Srisuresh & Holdrege Informativo [Pág. 24] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 6.1. Enviando los paquetes traducidos por el túnel. Todas las variantes de traducción de direcciones discutidas en la sección anterior pueden aplicarse a los enlaces directamente conectados así como a los túneles y a las "Redes Privadas Virtuales", Virtual Private Networks (VPN). 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. Podría haber un dispositivo NAT en un extremo del túnel o en ambos extremos. En todos los casos, se puede encriptar el tráfico a lo largo de la VPN por razones de seguridad. Aquí la seguridad se refiere a la del tráfico sólo a lo largo de las VPN. La seguridad extremo a extremo requiere confiar en los dispositivos NAT dentro de la red privada. 6.2. Redes privadas particionadas mediante troncales Hay muchas situaciones en las que una red privada (por ejemplo, una red corporativa) se extiende por varias localizaciones, usando troncales públicos para la comunicación entre dichas localizaciones. En tales casos, no es deseable hacer traducción de direcciones, tanto por el hecho de haber muchas máquinas que deseen comunicarse a lo largo del troncal, necesitando grandes tablas de direcciones, como por la existencia de más 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. Los extremos particionados mediante troncales deberían comportarse como si fuesen extremos no particionados. Es decir, los encaminadores en todas las particiones deberían mantener rutas hacia los espacios de direcciones locales de todas las particiones. Por supuesto, los troncales (públicos) no mantienen rutas hacia ninguna de las direcciones locales. Por lo tanto, los encaminadores fronterizos deben "tunelar" (mediante VPN) a través de los troncales usando encapsulación. Para hacer esto, cada dispositivo NAT reservará una dirección global para "tunelar". Cuando un dispositivo NAT x en el extremo de la partición X desea entregar un paquete al extremo de la partición Y, encapsulará el paquete en una cabecera IP con dirección destino establecida a la dirección global del dispositivo NAT y, reservada para la encapsulación. Cuando el dispositivo NAT recibe un paquete con esa dirección destino, desencapsula la cabecera IP y encamina internamente el paquete. Dese cuenta que no hay traducción de Srisuresh & Holdrege Informativo [Pág. 25] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 direcciones en el proceso; sólo hay transferencia de paquetes de la red privada por un túnel troncal en la red externa. 7.0. Características operacionales de NAT Los dispositivos de NAT no son conscientes de las aplicaciones, porque las traducciones están limitadas sólo a las cabeceras IP/TCP/UDP/ICMP y a los mensaje de error ICMP. Los dispositivos NAT no modifican la carga útil de los paquetes, puesto que éstos tienden a ser específicos de las aplicaciones. Los dispositivos NAT (sin incluir a las ALG) no examinan ni modifican la carga útil del protocolo de transporte. Por esta razón, en muchos casos los dispositivos NAT son transparentes a las aplicaciones. Sin embargo, hay dos áreas donde los dispositivos NAT a menudo tienen dificultades: 1) cuando la carga útil de un aplicación incluye una dirección IP, y 2) cuando es necesaria seguridad extremo a extremo. Dese cuenta que esta no es una lista exhaustiva. Las técnicas de seguridad en el nivel de aplicación que no hacen uso ni dependen de las direcciones IP funcionarán correctamente en presencia de NAT (por ejemplo, TLS, SSL y SSH). Sin embargo, las técnicas de nivel de transporte tales como el modo transporte IPsec o la opción de firma TCP MD5 de la RFC2385 [Ref 17] no. En modo transporte IPsec, tanto AH como ESP disponen de una comprobación de integridad que cubre la carga útil en su totalidad. Cuando la carga útil es TCP o UDP, la suma de verificación TCP/UDP queda cubierta por la comprobación de integridad. Cuando un dispositivo NAT modifica una dirección la suma de verificación deja de ser válida con respecto a la nueva dirección. Normalmente, NAT también actualiza la suma de verificación, pero esto no es efectivo cuando se usa AH o ESP. En consecuencia, los receptores descartarán un paquete bien porque falle la comprobación de integridad IPsec (si el dispositivo NAT actualiza la suma de verificación), bien porque la suma de verificación es inválida (si el dispositivo de NAT deja la suma de verificación sin modificar). Dese cuenta que se puede usar el modo túnel ESP de IPsec siempre que los contenidos del paquete encapsulado no se vean afectados por la traducción de la cabecera IP externa. Aunque esta técnica no funciona en despliegues NAT tradicionales (es decir, donde las máquinas no son conscientes de la presencia de NAT), la técnica es aplicable a IP Específica de Dominio según se describe en la Sección 5.0. Dese cuenta que la confidencialidad y la autenticación del modo de transporte extremo a extremo basado en ESP es posible para paquetes tales como los ICMP, donde la carga útil IP no se ve afectada por la Srisuresh & Holdrege Informativo [Pág. 26] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 traducción de la cabecera IP externa. Los dispositivos NAT también invalidan suposiciones fundamentales de las infraestructuras de distribución de clave pública tales como Secure DNS RFC2535 [Ref 18] y certificados X.509 con claves públicas firmadas. En el caso de Secure DNS, cada DNS RRset se firma con una clave desde el interior de la zona. Además, la autenticidad de una clave específica se verifica siguiendo una cadena de confianza que avanza hasta los DNS raíz. Cuando un DNS-ALG modifica direcciones (por ejemplo, en el caso de NAT doble), la verificación de las firmas falla. Puede ser interesante darse cuenta que IKE (protocolo de negociación de claves de sesión) es un protocolo de nivel de sesión basado en UDP y no está protegido por seguridad IPsec de nivel de red. Dentro de IKE sólo se protegen una parte de las cargas útiles individuales. En consecuencia, las sesiones IKE son posibles a través de NAT, siempre que la carga útil de IKE no contenga direcciones y/o identificadores de transporte específicos a un dominio y no al otro. Puesto que IKE se usa para establecer asociaciones IPsec, y puesto que actualmente no existen maneras conocidas de hacer que IPsec funcione a través de un dispositivo NAT, es un tema futuro de trabajo el aprovechar IKE a través de un dispositivo de NAT. Una de las aplicaciones de Internet más populares, FTP, no funcionaría con la definición de NAT según se ha descrito. La siguiente subsección está dedicada a describir cómo se soporta FTP en los dispositivos NAT. FTP ALG es una parte integral de la mayoría de implementaciones de NAT. Algunos fabricantes pueden optar por incluir ALG adicionales para soportar otras aplicaciones en el dispositivo NAT. 7.1. Soporte de FTP El comando "PORT" y la respuesta "PASV" en la carga útil en una sesión de control FTP identifican la dirección IP y el puerto TCP que deben ser usados para la sesión de datos a la que dan soporte. Los parámetros del comando PORT y la respuesta PASV son una dirección IP y un puerto en ASCII. Se necesita un FTP ALG para monitorizar y actualizar la carga útil de la sesión de control FTP para que la información contenida en la carga útil sea la adecuada para los nodos finales. La ALG también debe actualizar el NAT con las tuplas apropiadas de la sesión de datos y la orientación de la sesión para que NAT pueda establecer información de estado para las sesiones de datos FTP. Puesto que la dirección y el puerto TCP se codifican en ASCII, esto puede provocar cambios en el tamaño del paquete. Por ejemplo, Srisuresh & Holdrege Informativo [Pág. 27] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 10,18,177,42,64,87 mide 18 caracteres ASCII, mientras que 193,45,228,137,64,87 mide 20 caracteres ASCII. Si el nuevo tamaño es igual al anterior, sólo es necesario ajustar la suma de verificación TCP como consecuencia de cambiar los datos. Si el nuevo tamaño es inferior o superior al anterior, también deben cambiarse los números de secuencia TCP para hacer patente el cambio de longitud en la parte de los datos de control TCP. La ALG puede usar una tabla especial para corregir los números de secuencia y asentimientos de TCP. Será necesario llevar a cabo la corrección de los números de secuencia y asentimiento en todos los paquetes futuros de la conexión. 8.0. Limitaciones de NAT 8.1. Aplicaciones que contienen direcciones IP No todas las aplicaciones se prestan de manera sencilla a la traducción de direcciones mediante dispositivos NAT. En especial, las aplicaciones que transportan direcciones IP (y puertos TU, en el caso de NAT) en el interior de la carga útil. Se deben usar "Pasarelas de Nivel de Aplicación", Application Level Gateways (ALG), para llevar a cabo traducciones de paquetes pertenecientes a tales aplicaciones. Opcionalmente las ALG pueden utilizar las asignaciones de direcciones (y puertos TU) realizadas mediante NAT y llevar a cabo traducciones específicas a la aplicación. La combinación de la funcionalidad NAT con las ALG no proporcionará la seguridad extremo a extremo garantizada por IPsec. Sin embargo, se puede utilizar el modo túnel de IPsec cuando el encaminador NAT actúe como uno de los extremos del túnel. SNMP es una de esas aplicaciones que contienen direcciones en la carga útil. Los encaminadores NAT no traducirán las direcciones IP en el interior de los paquetes SNMP. No es infrecuente que un ALG específico para SNMP resida en el encamindor NAT para llevar a cabo traducciones SNMP MIB propias de la red privada. 8.2. Aplicaciones con sesiones de datos y control interdependientes. Los dispositivos NAT operan asumiendo que cada sesión es independiente. Las características de una sesión, como su orientación, las direcciones IP de origen y destino, protocolo de la sesión, y los identificadores del nivel de transporte origen y destino se determinan de manera independiente al comienzo de cada nueva sesión. Sin embargo, hay aplicaciones tales como H.323 que utilizan una o más sesiones de control para establecer las características de las sesiones que vendrán a continuación, usando para ello la carga útil de la sesión de control. Tales aplicaciones requieren del uso de ALG Srisuresh & Holdrege Informativo [Pág. 28] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 específicas de aplicación que puedan interpretar y traducir las cargas útiles, en caso necesario. La interpretación de la carga útil ayudaría a que NAT esté preparado para las sesiones de datos venideras. 8.3. Consideraciones de depuración NAT incrementa las posibilidades de direccionar erróneamente. Por ejemplo, la misma dirección local puede estar ligada a diferentes direcciones globales en diferentes momentos, y viceversa. En consecuencia, cualquier estudio del flujo de tráfico basado solamente en direcciones globales y puertos TU podría resultar confuso y provocar la malinterpretación de los resultados. Si alguna máquina está abusando de Internet de alguna manera (como tratando de atacar a otra máquina, o incluso enviando grandes cantidades de correo basura o por el estilo) es más difícil averiguar el origen de los problemas porque la dirección IP de la máquina está oculta en un encaminador NAT. 8.4. Traducción de paquetes de control FTP fragmentados La traducción de los paquetes de control TCP fragmentados "tiene truco" cuando los paquetes contienen comandos "PORT" o respuestas al comando "PASV". Claramente, este es un caso patológico. El encaminador NAT primero necesitaría rensamblar los fragmentos y entonces traducir antes del reenvío. Otro caso sería cuando cada uno de los caracteres de los paquetes que contienen comandos "PORT" o respuestas a "PASV" se envían en datagramas separados, sin fragmentar. En este caso, NAT simplemente debería dejar pasar los paquetes sin traducir la carga útil TCP. Por supuesto, la aplicación fallará si la carga útil necesitaba ser alterada. Aún así la aplicación podría funcionar en algunos casos, sin modificaciones intermedias, cuando los contenidos de la carga útil sean válidos en ambos dominios. Por ejemplo, los FTP originados desde una máquina privada funcionarían mientras que atraviesen un dispositivo NAT tradicional o bidireccional, siempre que la sesión de control FTP haya utilizado el comando PASV para establecer las sesiones de datos. La razón es que la dirección y el número de puerto especificados por el servidor FTP en la respuesta PASV (enviada como múltiples pawuetes no fragmentados) resulta válida tal cual para la máquina privada. El dispositivo NAT simplemente verá la siguiente sesión de datos (con origen también en la máquina privada) como una sesión TCP independiente. 8.5. Elevada potencia de cálculo Srisuresh & Holdrege Informativo [Pág. 29] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 NAT es una tarea que implica cálculos intensivos incluso con la ayuda de un algoritmo inteligente para el ajuste de las sumas de verificación, puesto que cada paquete de datos implica búsquedas y modificaciones en la tabla de NAT. En consecuencia, la velocidad de reenvío 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 línea, esto no debería suponer problema alguno. 9.0. Consideraciones de seguridad Mucha gente considera un encaminador NAT tradicional como un filtro de tráfico unidireccional (sesión por sesión), que restringe las sesiones provenientes de máquinas externas dirigidas hacia sus propias máquinas. Además, cuando la asignación de direcciones en el encaminador NAT se lleva a cabo dinámicamente, se hace más difícil que un atacante pueda apuntar hacia cualquier máquina concreta en el dominio NAT. Se pueden usar encaminadores NAT junto con cortafuegos para filtrar el tráfico no deseado. Si los dispositivos NAT y las ALG no están en un extremo de la red en que podamos confiar, esto constituye un problema de seguridad importante, puesto que las ALG podrían espiar la carga útil del tráfico de usuario. Se puede cifrar extremo a extremo la carga útil de nivel de sesión, siempre que la carga útil no contenga direcciones IP y/o identificadores de transporte que sean válidos en uno solo de los dominios. Con la excepción de RSIP, la seguridad extremo a extremo IP en el nivel de red obtenida mediante las actuales técnicas IPsec no es posible cuando hay dispositivos NAT por el camino. Uno de los extremos debe ser un dispositivo NAT. Consulte en la sección 7.0 la explicación de porqué no se puede garantizar la seguridad IPsec extremo a extremo cuando hay dispositivos NAT a lo largo de la ruta. La combinación de las funciones de NAT, ALG y cortafuegos, proporciona un entorno de trabajo transparente para un dominio de red privado. Con la excepción de RSIP, no se puede obtenner la seguridad extremo a extremo garantizada por IPsec para las máquinas finales en el interior de la red privada (consulte en la sección 5.0 el funcionamiento de RSIP). En el resto de casos, si desea obtener seguridad extremo a extremo mediante IPsec, no deberá haber dispositivos NAT por el camino. Si suponemos que los dispositivos NAT son parte de una frontera de confianza, se puede utilizar IPsec modo túnel mediante un encaminador NAT (o una combinación de NAT, ALG y cortafuegos) que actúe como uno de los extremos del túnel. Los dispositivos NAT, cuando se combinan con ALG, pueden garantizar que los datagramas enviados a Internet no tienen direcciones privadas en las cabeceras o en la carga útil. Las aplicaciones que no cumplan Srisuresh & Holdrege Informativo [Pág. 30] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 estos requisitos pueden ser descartadas por las reglas del cortafuegos. Por esta razón, no es infrecuente encontrarse con las funciones de NAT, ALG y cortafuegos integradas para proporcionar seguridad en las fronteras de una red privada. Se pueden usar pasarelas NAT como extremos de los túneles para proporcionar transporte seguro de datos de la VPN a través de un dominio de red externo. A continuación se muestran consideraciones adicionales de seguridad asociadas con los encaminadores NAT. 1. Las sesiones UDP son intrínsecamente inseguras. Las respuestas a un datagrama pueden provenir de una dirección distinta a la dirección destino utilizada por el remitente ([Ref 4]). En consecuencia, un paquete UDP entrante podría coincidir sólo en parte con una sesión saliente de un encaminador NAT tradicional (la dirección destino y el número de puerto UDP del paquete coinciden, pero la dirección y número de puerto de origen puede que no). En tal caso, hay un problema potencial de seguridad en el dispositivo NAT si permite la entrada de los paquetes que coinciden sólo parcialmente. Este problema de seguridad también es intrínseco a los cortafuegos. Las implementaciones de NAT que no hacen un seguimiento de los datagramas de cada sesión, sino que agrupan los estados de múltiples sesiones UDP usando la misma asociación de dirección sobre una única sesión unificada, pueden comprometer aún más la seguridad. Esto es debido a que la granularidad en la coincidencia del paquete sería todavía más limitada, y quedaría reducida a la dirección destino de los paquetes UDP entrantes. 2. Las sesiones multicast (basadas en UDP) son otra fuente de debilidades de seguridad en los encaminadores NAT tradicionales. También en este caso los cortafuegos afrontan el mismo dilema de seguridad que los encaminadores NAT. Supongamos que una máquina en una red privada inicia una sesión multicast. El datagrama enviado por la máquina privada puede desencadenar respuestas en el sentido contrario provenientes de múltiples máquinas exteriores. Las implementaciones tradicionales de NAT que utilizan un único estado para hacer un seguimiento de una sesión multicast no pueden determinar con seguridad si el paquete UDP entrante es una respuesta a una sesión multicast existente o es el comienzo de una nueva sesión UDP iniciada por un atacante. 3. Los dispositivos NAT pueden ser objeto de ataques. Srisuresh & Holdrege Informativo [Pág. 31] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Puesto que los dispositivos NAT son máquinas de Internet, pueden ser objeto de diversos ataques, tales como ataques de SYN flood y ping flood. Los dispositivos de NAT deben emplear el mismo tipo de técnicas de protección que utilizan los servidores de Internet. REFERENCIAS [1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, Febrero 1996. [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, Octubre, 1994. [3] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, Octubre 1989. [4] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, Octubre 1989. [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, Junio 1995. [6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, Octubre 1985. [7] Postel, J., "Transmission Control Protocol (TCP) Specification", STD 7, RFC 793, Septiembre 1981. [8] Postel, J., "Internet Control Message Protocol Specification" STD 5, RFC 792, Septiembre 1981. [9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, Agosto 1980. [10] Mogul, J. and J. Postel, "Internet Standard Subnetting Proce­ dure", STD 5, RFC 950, Agosto 1985. [11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, Febrero 1997. [12] Kent, S. and R. Atkinson, "Security Architecture for the Inter­ net Protocol", RFC 2401, Noviembre 1998. [13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, Noviembre 1998. Srisuresh & Holdrege Informativo [Pág. 32] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 [14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, Noviembre 1998. [15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, Noviembre 1998. [16] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, Noviembre 1998. [17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig­ nature Option", RFC 2385, Agosto 1998. [18] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, Marzo 1999. Direcciones de los Autores Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A. Teléfono: (925) 737-2153 Fax: (925) 737-2110 EMail: srisuresh@lucent.com Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 Teléfono: (510) 769-6001 EMail: holdrege@lucent.com Traducción al castellano: José Luis Domingo López C/ Cruz del Sur 22 28007 Madrid - España EMail: jdomingo@internautas.org Srisuresh & Holdrege Informativo [Pág. 33] RFC 2663 Terminología y consideraciones sobre NAT Agosto 1999 Declaración completa de copyright Copyright (C) The Internet Society (1999). Todos los derechos reser­ vados. Este documento y sus traducciones puede ser copiado y facilitado a otros, y los trabajos derivados que lo comentan o lo explican o ayu­ dan a su implementación pueden ser preparados, copiados, publicados y distribuídos, enteros o en parte, sin restricción de ningún tipo, siempre que se incluyan este párrafo y la nota de copyright expuesta arriba en todas esas copias y trabajos derivados. Sin embargo, este documento en sí no debe ser modificado de ninguna forma, tal como eliminando la nota de copyright o referencias a la 'Internet Society' u otras organizaciones de Internet, excepto cuando sea necesario en el desarrollo de estándares Internet, en cuyo caso se seguirán los procedimientos para copyrights definidos en el proceso de Estándares Internet, o con motivo de su traducción a otras lenguas aparte del Inglés. Este documento y la información contenida en él se proporcionan en su forma "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK FORCE RECHAZAN CUALESQUIERA GARANTIAS, EXPRESAS O IMPLICITAS, INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACION AQUI EXPUESTA NO INFRINGIRA NINGUN DERECHO O GARANTIAS IMPLICITAS DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECI­ FICO. Reconocimientos En la actualidad, la financiación para las funciones del editor RFC es proporcionada por la Internet Society. Srisuresh & Holdrege Informativo [Pág. 34]