draft-ietf-nat-protocol-complications-05.txt   rfc3027.txt 
NAT Working Group Matt Holdrege
INTERNET-DRAFT ipVerse Network Working Group M. Holdrege
Category: Informational Pyda Srisuresh Request for Comments: 3027 ipVerse
Expires as of April 9, 2001 Consultant Category: Informational P. Srisuresh
October, 2000 Jasmine Networks
January 2001
Protocol Complications with the IP Network Address Translator Protocol Complications with the IP Network Address Translator
<draft-ietf-nat-protocol-complications-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This memo provides information for the Internet community. It does
with all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract: Abstract
Many internet applications can be adversely affected when end nodes Many internet applications can be adversely affected when end nodes
are not in the same address realm and seek the assistance of NAT are not in the same address realm and seek the assistance of an IP
enroute to bridge the realms. NAT device alone cannot provide the Network Address Translator (NAT) enroute to bridge the realms. The
necessary application/protocol transparency in all cases and seeks NAT device alone cannot provide the necessary application/protocol
the assistance of Application Level Gateways (ALGs) where possible, transparency in all cases and seeks the assistance of Application
to provide transparency. The purpose of this document is to Level Gateways (ALGs) where possible, to provide transparency. The
identify the protocols and applications that break with NAT enroute. purpose of this document is to identify the protocols and
The document also attempts to identify any known workarounds. It is applications that break with NAT enroute. The document also attempts
impossible to capture all the applications that break with NAT in a to identify any known workarounds. It is not possible to capture all
single document. This document attempts to capture as much informa- applications that break with NAT in a single document. This document
tion as possible, but by no means a comprehensive coverage. We hope attempts to capture as much information as possible, but is by no
this coverage provides clues for applications not covered here. means a comprehensive coverage. We hope the coverage provides
sufficient clues for applications not covered.
Table of Contents Table of Contents
1.0 Introduction 1.0 Introduction .............................................. 2
2.0 Common Characteristics of Protocols broken by NAT ......... 2
2.0 Common Characteristics of Protocols broken by NAT 3.0 Protocols that cannot work with NAT enroute ............... 4
4.0 Protocols that can work with the aid of an ALG ............ 8
3.0 Protocols that cannot work with NAT enroute 5.0 Protocols designed explicitly to work with NAT enroute .... 16
6.0 Acknowledgements .......................................... 17
4.0 Protocols that can work with the aid of an ALG 7.0 Security Considerations ................................... 17
8.0 References ................................................ 17
5.0 Protocols designed explicitly to work with NAT enroute 9.0 Authors' Addresses ........................................ 19
10.0 Full Copyright Statement ................................ 20
6.0 Acknowledgements
7.0 Security Considerations
8.0 References
9.0 Authors Addresses
1.0 Introduction: 1.0 Introduction
This document requires the reader to be familiar with the This document requires the reader to be familiar with the terminology
terminology and function of NAT devices as described in [NAT-TERM]. and function of NAT devices as described in [NAT-TERM]. In a
In a nutshell, NAT attempts to provide a transparent routing solution nutshell, NAT attempts to provide a transparent routing solution to
to end hosts requiring communication to disparate address realms. NAT end hosts requiring communication to disparate address realms. NAT
modifies end node addresses (within the IP header of a packet) modifies end node addresses (within the IP header of a packet) en-
en-route and maintains state for these updates so that datagrams route and maintains state for these updates so that datagrams
pertaining to a session are transparently routed to the right pertaining to a session are transparently routed to the right end-
end-node in either realm. Where possible, application specific node in either realm. Where possible, application specific ALGs may
ALGs may be used in conjunction with NAT to provide application level be used in conjunction with NAT to provide application level
transparency. Unlike NAT, the function of ALG is application specific transparency. Unlike NAT, the function of ALG is application
and would likely require examination and recomposition of IP payload. specific and would likely require examination and recomposition of IP
payload.
The following sections attempt to list applications that are known The following sections attempt to list applications that are known to
to have been impacted by NAT devices enroute. However, this is by no have been impacted by NAT devices enroute. However, this is by no
means a comprehensive list of all known protocols and applications means a comprehensive list of all known protocols and applications
that have complications with NAT - rather just a subset of the list that have complications with NAT - rather just a subset of the list
gathered by the authors. It is also important to note that this gathered by the authors. It is also important to note that this
document is not intended to advocate NAT, but rather to point out document is not intended to advocate NAT, but rather to point out the
the complications with protocols and applications when NAT devices complications with protocols and applications when NAT devices are
are enroute. enroute.
2.0 Common Characteristics of Protocols broken by NAT 2.0 Common Characteristics of Protocols broken by NAT
[NAT-TERM] and [NAT-TRAD] have sections listing the specific nature [NAT-TERM] and [NAT-TRAD] have sections listing the specific nature
of problems and limitations to NAT devices. Some of these limitations of problems and limitations to NAT devices. Some of these
are being restated in this section to summarize characteristics of limitations are being restated in this section to summarize
protocols that are broken by NAT. characteristics of protocols that are broken by NAT.
2.1 Realm-specific IP address information in payload 2.1 Realm-specific IP address information in payload
A wide range of applications fail with NAT enroute when IP packets A wide range of applications fail with NAT enroute when IP packets
contain realm-specific IP address or port information in payload. contain realm-specific IP address or port information in payload. An
An ALG may be able to provide work around in some cases. But, ALG may be able to provide work around in some cases. But, if the
if the packet payload is IPsec secured (or secure by a transport packet payload is IPsec secured (or secure by a transport or
or application level security mechanisms), the application is application level security mechanisms), the application is bound to
bound to fail. fail.
2.2 Bundled session applications 2.2 Bundled session applications
Bundled session applications such as FTP, H.323, SIP and RTSP, which Bundled session applications such as FTP, H.323, SIP and RTSP, which
use a control connection to establish a data flow are also usually use a control connection to establish a data flow are also usually
broken by NAT devices enroute. This is because these applications broken by NAT devices enroute. This is because these applications
exchange address and port parameters within control session to exchange address and port parameters within control session to
establish data sessions and session orientations. NAT cannot know establish data sessions and session orientations. NAT cannot know
the inter-dependency of the bundled sessions and would treat each the inter-dependency of the bundled sessions and would treat each
session to be unrelated to one another. Applications in this case session to be unrelated to one another. Applications in this case
can fail for a variety of reasons. Two most likely reasons for can fail for a variety of reasons. Two most likely reasons for
failures are: (a) addressing information in control payload is failures are: (a) addressing information in control payload is
realm-specific and is not valid once packet crosses the originating realm-specific and is not valid once packet crosses the originating
realm, (b) control session permits data session(s) to originate in realm, (b) control session permits data session(s) to originate in a
a direction that NAT might not permit. direction that NAT might not permit.
When DNS names are used in control payload, NAT device in conjunction When DNS names are used in control payload, NAT device in conjunction
with a DNS-ALG might be able to offer the necessary application level with a DNS-ALG might be able to offer the necessary application level
transparency, if NAT has no contention with data session orientation. transparency, if NAT has no contention with data session orientation.
However, using DNS names in place of realm-specific IP addresses may However, using DNS names in place of realm-specific IP addresses may
not be an option to many of these applications (e.g.: FTP). not be an option to many of these applications (e.g., FTP).
When realm-specific addressing is specified in payload, and the payload When realm-specific addressing is specified in payload, and the
is not encrypted, an ALG may in some cases be able to provide the work payload is not encrypted, an ALG may in some cases be able to provide
around necessary to make the applications run transparently across the work around necessary to make the applications run transparently
realms. The complexity of ALG depends on the application level across realms. The complexity of ALG depends on the application
knowledge required to process payload and maintain state. level knowledge required to process payload and maintain state.
2.3 Peer-to-peer applications 2.3 Peer-to-peer applications
Peer-to-peer applications more than client-server based applications Peer-to-peer applications more than client-server based applications
are likely to break with NAT enroute. Unlike Client-server are likely to break with NAT enroute. Unlike Client-server
applications, Peer-to-peer applications can be originated by any of applications, Peer-to-peer applications can be originated by any of
the peers. When peers are distributed across private and public the peers. When peers are distributed across private and public
realms, a session originated from an external realm is just as realms, a session originated from an external realm is just as likely
likely as the session from a host in private realm. External as the session from a host in private realm. External peers will be
peers will be able to locate their peers in private realm only able to locate their peers in private realm only when they know the
when they know the externally assigned IP address or the FQDN externally assigned IP address or the FQDN ahead of time. FQDN name
ahead of time. FQDN name to assigned address mapping can happen to assigned address mapping can happen only so long as the enroute
only so long as the enroute NAT device supports DNS-ALG. Examples NAT device supports DNS-ALG. Examples of Peer-to-peer applications
of Peer-to-peer applications include interactive games, Internet include interactive games, Internet telephony and event-based
telephony and event-based protocols (such as Instant-Messaging). protocols (such as Instant-Messaging).
This is particularly a problem with traditional NAT and may be less This is particularly a problem with traditional NAT and may be less
of an issue with bi-directional NAT, where sessions are permitted of an issue with bi-directional NAT, where sessions are permitted in
in both directions. both directions.
A possible work-around for this type of problem with traditional-NAT A possible work-around for this type of problem with traditional-NAT
is for private hosts to maintain an outbound connection with a is for private hosts to maintain an outbound connection with a server
server acting as their representative to the globally routed acting as their representative to the globally routed Internet.
Internet.
2.4 IP fragmentation with NAPT enroute 2.4 IP fragmentation with NAPT enroute
IP fragmentation with NAPT enroute is not an issue with any single IP fragmentation with NAPT enroute is not an issue with any single
application, but pervades across all TCP/UDP applications. The application, but pervades across all TCP/UDP applications. The
problem is described in detail in [NAT-TRAD]. Briefly, the problem problem is described in detail in [NAT-TRAD]. Briefly, the problem
goes as follows. Say, two private hosts originated fragmented goes as follows. Say, two private hosts originated fragmented
TCP/UDP packets to the same destination host. And, they happened to TCP/UDP packets to the same destination host. And, they happened to
use the same fragmentation identifier. When the target host receives use the same fragmentation identifier. When the target host receives
the two unrelated datagrams, carrying same fragmentation id, and the two unrelated datagrams, carrying same fragmentation id, and from
from the same assigned host address, the target host is unable to the same assigned host address, the target host is unable to
determine which of the two sessions the datagrams belong to. determine which of the two sessions the datagrams belong to.
Consequently, both sessions will be corrupted. Consequently, both sessions will be corrupted.
2.5 Applications requiring retention of address mapping 2.5 Applications requiring retention of address mapping
NAT will most likely break applications that require address NAT will most likely break applications that require address mapping
mapping to be retained across contiguous sessions. These to be retained across contiguous sessions. These applications
applications require the private-to-external address mapping require the private-to-external address mapping to be retained
to be retained between sessions so the same external address between sessions so the same external address may be reused for
may be reused for subsequent session interactions. NAT cannot subsequent session interactions. NAT cannot know this requirement
know this requirement and may reassign external address to and may reassign external address to different hosts between
different hosts between sessions. sessions.
Trying to keep NAT from discarding an address mapping would Trying to keep NAT from discarding an address mapping would require a
require the application to keep sending Keepalives - which can NAT extension protocol to the application that would allow the
be annoying or sometimes not even possible. Alternately, an application to inform the NAT device to retain the mappings.
ALG may be required to interact with NAT to keep the address Alternately, an ALG may be required to interact with NAT to keep the
mapping from being discarded by NAT. address mapping from being discarded by NAT.
2.6 Applications requiring more public addresses than available 2.6 Applications requiring more public addresses than available
This is a problem when the number of private hosts is larger than This is a problem when the number of private hosts is larger than the
the external addresses available to map the private addresses external addresses available to map the private addresses into. Take
into. Take for example the rlogin service initiated from a host for example the rlogin service initiated from a host in private realm
in private realm supported by NAPT. Rlogin service clients supported by NAPT. Rlogin service clients use well-known rlogin port
use well-known rlogin port 512 as their TCP port ID. No more than 512 as their TCP port ID. No more than one host in private realm can
one host in private realm can initiate the service. This is a initiate the service. This is a case of trying to use a service that
case of trying to use a service that fundamentally requires more fundamentally requires more public addresses than are available. NAT
public addresses than are available. NAT devices can conserve devices can conserve addresses, but they cannot create more
addresses, but they cannot create more addresses. addresses.
3.0 Protocols that cannot work with NAT enroute 3.0 Protocols that cannot work with NAT enroute
3.1 IPsec and IKE 3.1 IPsec and IKE
NAT fundamentally operates by modifying end node addresses (within the NAT fundamentally operates by modifying end node addresses (within
IP header) en-route. The IPsec AH standard [RFC 2402] on the other the IP header) en-route. The IPsec AH standard [IPsec-AH] on the
hand is explicitly designed to detect alterations to IP packet other hand is explicitly designed to detect alterations to IP packet
header. So when NAT alters the address information enroute in IP header. So when NAT alters the address information enroute in IP
header, the destination host receiving the altered packet will header, the destination host receiving the altered packet will
invalidate the packet since the contents of the headers have been invalidate the packet since the contents of the headers have been
altered. The IPsec AH secure packet traversing NAT will simply not altered. The IPsec AH secure packet traversing NAT will simply not
reach the target application, as a result. reach the target application, as a result.
IPsec ESP encrypted packets may be altered by NAT device enroute only IPsec ESP ([IPsec-ESP]) encrypted packets may be altered by NAT
in a limited number of cases. In the case of TCP/UDP packets, NAT would device enroute only in a limited number of cases. In the case of
need to update the checksum in TCP/UDP headers, when an address in TCP/UDP packets, NAT would need to update the checksum in TCP/UDP
IP header is changed. However, as the TCP/UDP header is encrypted by headers, when an address in IP header is changed. However, as the
the ESP, NAT would not be able to make this checksum update. As a TCP/UDP header is encrypted by the ESP, NAT would not be able to make
result, TCP/UDP packets encyrpted in transport mode ESP, traversing a this checksum update. As a result, TCP/UDP packets encrypted in
NAT device will fail the TCP/UDP checksum validation on the receiving transport mode ESP, traversing a NAT device will fail the TCP/UDP
end and will simply not reach the target application. checksum validation on the receiving end and will simply not reach
the target application.
Internet Key Exchange Protocol IKE can potentially pass IP addresses Internet Key Exchange Protocol IKE can potentially pass IP addresses
as node identifiers during Main, Aggressive and Quick Modes. In order as node identifiers during Main, Aggressive and Quick Modes. In
for an IKE negotiation to correctly pass through a NAT, these order for an IKE negotiation to correctly pass through a NAT, these
payloads would need to be modified. However, these payloads are payloads would need to be modified. However, these payloads are
often protected by hash or obscured by encryption. Even in the often protected by hash or obscured by encryption. Even in the case
case where IP addresses are not used in IKE payloads and an IKE where IP addresses are not used in IKE payloads and an IKE
negotiation could occur uninterrupted, there is difficulty with negotiation could occur uninterrupted, there is difficulty with
retaining the private-to-external address mapping on NAT from the retaining the private-to-external address mapping on NAT from the
time IKE completed negotiation to the time IPsec uses the key on time IKE completed negotiation to the time IPsec uses the key on an
an application. In the end, the use of end-to-end IPsec is severely application. In the end, the use of end-to-end IPsec is severely
hampered anyway, as described earlier. hampered anyway, as described earlier.
For all practical purposes, end-to-end IPsec is impossible to For all practical purposes, end-to-end IPsec is impossible to
accomplish with NAT enroute. accomplish with NAT enroute.
3.2 Kerberos 4 3.2 Kerberos 4
Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be
written. when the KDC receives a ticket request, it includes the written. When the KDC receives a ticket request, it includes the
source IP address in the returned ticket. Not all Kerberos 4 source IP address in the returned ticket. Not all Kerberos 4
services actually check source IP addresses. AFS is a good services actually check source IP addresses. AFS is a good example
example of a Kerberos 4 service which does not. Services which of a Kerberos 4 service which does not. Services which don't check
don't check are not picky about NAT devices enroute. Kerberos are not picky about NAT devices enroute. Kerberos tickets are tied
tickets are tied to the IP address that requested the ticket and to the IP address that requested the ticket and the service with
the service with which to use the ticket. which to use the ticket.
The K4 ticket (response) contains a single IP address describing the The K4 ticket (response) contains a single IP address describing the
interface used by the client to retrieve the ticket from the TGT interface used by the client to retrieve the ticket from the TGT
from the perspective of KDC. This works fine if the KDC is across a from the perspective of KDC. This works fine if the KDC is across a
NAT gateway and as long as all of the Kerberos services are also NAT gateway and as long as all of the Kerberos services are also
across a NAT gateway. The end user on private network will not notice across a NAT gateway. The end user on private network will not
any problems. notice any problems.
There is also the caveat that NAT uses the same address mapping for There is also the caveat that NAT uses the same address mapping for
the private host for the connection between the client and the KDC the private host for the connection between the client and the KDC as
as for the connection between the client and the application server. for the connection between the client and the application server. A
A work around this problem would be to keep an arbitrary connection work around this problem would be to keep an arbitrary connection
open to remote server during throughout the ticket lifetime, so as open to remote server during throughout the ticket lifetime, so as
not to let NAT drop the address binding. Alternately, an ALG will not to let NAT drop the address binding. Alternately, an ALG will
need to be deployed to ensure that NAT would not change address need to be deployed to ensure that NAT would not change address
bindings during the lifetime of a ticket and between the time a bindings during the lifetime of a ticket and between the time a
ticket is issued to private host and the time the ticket is used ticket is issued to private host and the time the ticket is used by
by private host. private host.
But, the ticket will be valid from any host within the private realm But, the ticket will be valid from any host within the private realm
of NAPT. Without NAPT, an attacker needs to be able to of NAPT. Without NAPT, an attacker needs to be able to spoof the
spoof the source IP addresses of a connection that is being made in source IP addresses of a connection that is being made in order to
order to use a stolen ticket on a different host. With NAPT, all use a stolen ticket on a different host. With NAPT, all the attacker
the attacker needs to do from the private realm of NAPT is to simply needs to do from the private realm of NAPT is to simply gain
gain possession of a ticket. Of course, this assumes, NAPT private possession of a ticket. Of course, this assumes, NAPT private domain
domain is not a trusted network - not surprisingly, since many attacks is not a trusted network - not surprisingly, since many attacks occur
occur from inside the organization. from inside the organization.
3.3 Kerberos 5 3.3 Kerberos 5
Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore, Just as with Kerberos 4, Kerberos 5 tickets are encrypted.
an ALG cannot be written. Therefore, an ALG cannot be written.
In Kerberos 5, the client specifies a list of IP addresses which the In Kerberos 5, the client specifies a list of IP addresses which the
ticket should be valid for, or it can ask for a ticket valid for all ticket should be valid for, or it can ask for a ticket valid for all
IP addresses. By asking for an all-IP-addresses ticket or a ticket IP addresses. By asking for an all-IP-addresses ticket or a ticket
containing the NAPT device address, you can get krb5 to work with an containing the NAPT device address, you can get krb5 to work with an
NAPT device, although it isn't very transparent (it requires the NAPT device, although it isn't very transparent (it requires the
clients to behave differently than they otherwise would). The MIT clients to behave differently than they otherwise would). The MIT
krb5 1.0 implementation didn't have any configurability for what IP krb5 1.0 implementation didn't have any configurability for what IP
addresses the client asked for (it always asked for the set of its addresses the client asked for (it always asked for the set of its
interface addresses) and did not interact well with NAT. The MIT krb5 interface addresses) and did not interact well with NAT. The MIT
1.1 implementation allows you to put "noaddresses" somewhere in krb5 1.1 implementation allows you to put "noaddresses" somewhere in
krb5.conf to request all-IP-addresses-valid tickets. krb5.conf to request all-IP-addresses-valid tickets.
The K5 ticket (response) contains IP addresses, as requested by the The K5 ticket (response) contains IP addresses, as requested by the
client node, from which the ticket is to be considered valid. If the client node, from which the ticket is to be considered valid. If the
services being accessed with Kerberos authentication are on the services being accessed with Kerberos authentication are on the
public side of the NAT, then the Kerberos authentication will fail public side of the NAT, then the Kerberos authentication will fail
because the IP address used by the NAT (basic NAT or NAPT) is not in because the IP address used by the NAT (basic NAT or NAPT) is not in
the list of acceptable addresses. the list of acceptable addresses.
There are two workarounds in Kerberos 5 both of which reduce the There are two workarounds in Kerberos 5 both of which reduce the
security of the tickets. The first is to have the clients in NAPT security of the tickets. The first is to have the clients in NAPT
private realm specify the public IP address of the NAPT in the private realm specify the public IP address of the NAPT in the
ticket's IP list. But this leads to the same security problem ticket's IP list. But this leads to the same security problem
detailed for K4. Plus, it is not obvious for the client in the detailed for K4. Plus, it is not obvious for the client in the
private domain to find out the public IP Address of the NAPT. That private domain to find out the public IP Address of the NAPT. That
would be a change of application behavior on end-host. would be a change of application behavior on end-host.
The second method is to remove all IP addresses from the K5 tickets The second method is to remove all IP addresses from the K5 tickets
but this now makes theft of the ticket even worse since the tickets but this now makes theft of the ticket even worse since the tickets
can be used from anywhere. Not just from within the private network. can be used from anywhere. Not just from within the private network.
3.4 The X Windowing System and X-term/Telnet 3.4 The X Windowing System and X-term/Telnet
The X Windowing system is TCP based. However, the client-server The X Windowing system is TCP based. However, the client-server
relationship with these applications is reverse compared to relationship with these applications is reverse compared to most
most other applications. The X server or Open-windows server is the other applications. The X server or Open-windows server is the
display/mouse/keyboard unit (i.e., the one that controls the actual display/mouse/keyboard unit (i.e., the one that controls the actual
Windows interface). The clients are the application programs driving Windows interface). The clients are the application programs driving
the Windows interface. the Windows interface.
Some machines run multiple X Windows servers on the same machine. The Some machines run multiple X Windows servers on the same machine.
first X Windows server is at TCP port 6000. The first Open Windows The first X Windows server is at TCP port 6000. The first Open
server can be at port 6000 or port 2000 (more flexible). We will Windows server can be at port 6000 or port 2000 (more flexible). We
mainly refer X windowing system for illustration purposes here. will mainly refer X windowing system for illustration purposes here.
X-term Transmits IP addresses from the client to the server for the X-term Transmits IP addresses from the client to the server for the
purpose of setting the DISPLAY variable. When set the DISPLAY purpose of setting the DISPLAY variable. When set the DISPLAY
variable is used for subsequent connections from X clients on the variable is used for subsequent connections from X clients on the
host to an X server on the workstation. The DISPLAY variable is host to an X server on the workstation. The DISPLAY variable is sent
sent inline during the TELNET negotiations as inline during the TELNET negotiations as
DISPLAY=<local-ip-addr>:<server>.<display>
where the <local-ip-addr> is retrieved by looking at the local ip DISPLAY=<local-ip-addr>:<server>.<display>
address associated with the socket used to connect to <server>. The
<server> determines which port (6000 + <server>) should be used
to make the connection. <display> is used to indicate which monitor
attached to the X server should be used but is not important to this
discussion.
The <local-ip-addr> used is not a DNS name because: where the <local-ip-addr> is retrieved by looking at the local ip
address associated with the socket used to connect to <server>. The
<server> determines which port (6000 + <server>) should be used to
make the connection. <display> is used to indicate which monitor
attached to the X server should be used but is not important to this
discussion.
. The is no ability for the local machine to know its DNS name The <local-ip-addr> used is not a DNS name because:
without performing a reverse DNS lookup on the local-ip-addr
. There is no guarantee that the name returned by a reverse . The is no ability for the local machine to know its DNS name
DNS lookup actually maps back to the local IP address. without performing a reverse DNS lookup on the local-ip-addr
. Lastly, without DNSSEC, it may not be safe to use DNS addresses . There is no guarantee that the name returned by a reverse
because they can easily be spoofed. NAT and DNS-ALG cannot work DNS lookup actually maps back to the local IP address.
unless DNSSEC is disabled.
A common use of this application is people dialing in to corporate . Lastly, without DNSSEC, it may not be safe to use DNS addresses
offices from their X terminals at home. Say, the X client is running because they can easily be spoofed. NAT and DNS-ALG cannot work
on a host on the public side of the NAT and X server is running on a unless DNSSEC is disabled.
host on the private side of the NAT. The DISPLAY variable is
transmitted inline to the host the X client is running in some way.
The process transmitting the contents of the DISPLAY variable does
not know the address of the NAT.
If the channel transmitting the DISPLAY variable is not encrypted, A common use of this application is people dialing in to corporate
NAT device might solicit the help of an ALG to replace the offices from their X terminals at home. Say, the X client is running
IP address and configure a port in the valid display range (ports on a host on the public side of the NAT and X server is running on a
6000 and higher) to act as a gateway. Alternately, NAT may be host on the private side of the NAT. The DISPLAY variable is
configured to listen for incoming connections to provide access transmitted inline to the host the X client is running in some way.
to the X Server(s), without requiring an ALG. But, this approach The process transmitting the contents of the DISPLAY variable does
increases the security risk by providing access to the X server that not know the address of the NAT.
would not otherwise be available. As the ALG tampers with the
IP addresses it will also not be possible for X Authorization methods
other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the
least secure of all the documented X Authorization methods.
When START_TLS is used there may be client certificate verification If the channel transmitting the DISPLAY variable is not encrypted,
problems caused by the NAT depending on the information provided in NAT device might solicit the help of an ALG to replace the IP address
the certificate. and configure a port in the valid display range (ports 6000 and
higher) to act as a gateway. Alternately, NAT may be configured to
listen for incoming connections to provide access to the X Server(s),
without requiring an ALG. But, this approach increases the security
risk by providing access to the X server that would not otherwise be
available. As the ALG tampers with the IP addresses it will also not
be possible for X Authorization methods other than MIT-MAGIC-COOKIE-1
to be used. MIT-MAGIC-COOKIE-1 is the least secure of all the
documented X Authorization methods.
When START_TLS is used there may be client certificate verification
problems caused by the NAT depending on the information provided in
the certificate.
3.5 RSH/RLOGIN 3.5 RSH/RLOGIN
RSH uses multiple sessions to support separate streams for stdout and RSH uses multiple sessions to support separate streams for stdout and
stderr. A random port number is transmitted inline from the client to stderr. A random port number is transmitted inline from the client
the server for use as stderr port. The stderr socket is a connection to the server for use as stderr port. The stderr socket is a
back from the server to the client. And unlike FTP, there is no connection back from the server to the client. And unlike FTP, there
equivalent to PASV mode. For traditional NAT, this is a problem is no equivalent to PASV mode. For traditional NAT, this is a
as traditional NAT would not permit incoming sessions. problem as traditional NAT would not permit incoming sessions.
RLOGIN does not use multiple sessions. But the Kerberos protected RLOGIN does not use multiple sessions. But the Kerberos protected
versions of RSH and RLOGIN will not work in a NAT environment due versions of RSH and RLOGIN will not work in a NAT environment due to
to the ticket problems and the use of multiple sessions. the ticket problems and the use of multiple sessions.
4.0 Protocols that can work with the aid of an ALG 4.0 Protocols that can work with the aid of an ALG
This document predominantly addresses problems associated with This document predominantly addresses problems associated with
Traditional NAT, especially NAPT. Traditional NAT, especially NAPT.
4.1 FTP 4.1 FTP
FTP is a TCP based application, used to reliably transfer files between FTP is a TCP based application, used to reliably transfer files
two hosts. FTP uses bundled session approach to accomplish this. between two hosts. FTP uses bundled session approach to accomplish
this.
FTP is initiated by a client accessing a well-known port number 21 on FTP is initiated by a client accessing a well-known port number 21 on
the FTP server. This is called the FTP control session. Often, an the FTP server. This is called the FTP control session. Often, an
additional data session accompanies the control session. By default, the additional data session accompanies the control session. By default,
data session would be from TCP port 20 on server to the TCP port client the data session would be from TCP port 20 on server to the TCP port
used to initiate control session. However, the data session ports may be client used to initiate control session. However, the data session
altered within the FTP control sessions using ASCII encoded PORT and ports may be altered within the FTP control sessions using ASCII
PASV commands and responses. encoded PORT and PASV commands and responses.
Say, an FTP client is in a NAT supported private network. An FTP ALG Say, an FTP client is in a NAT supported private network. An FTP ALG
will be required to monitor the FTP control session (for both PORT and will be required to monitor the FTP control session (for both PORT
PASV modes) to identify the FTP data session port numbers and modify the and PASV modes) to identify the FTP data session port numbers and
private address and port number with the externally valid address and modify the private address and port number with the externally valid
port number. In addition, the sequence and acknowledgement numbers, TCP address and port number. In addition, the sequence and
checksum, IP packet length and checksum have to be updated. Consequently acknowledgement numbers, TCP checksum, IP packet length and checksum
the sequence numbers in all subsequent packets for that stream must be have to be updated. Consequently the sequence numbers in all
adjusted as well as TCP ACK fields and checksums. subsequent packets for that stream must be adjusted as well as TCP
ACK fields and checksums.
In rare cases, increasing the size of the packet could cause it to In rare cases, increasing the size of the packet could cause it to
exceed the MTU of a given transport link. The packet would then have exceed the MTU of a given transport link. The packet would then have
to be fragmented which could affect performance. Or, if the packet has to be fragmented which could affect performance. Or, if the packet
the DF bit set, it would be ICMP rejected and the originating host has the DF bit set, it would be ICMP rejected and the originating
would then have to perform Path MTU Discovery. This could have an host would then have to perform Path MTU Discovery. This could have
adverse effect on performance. an adverse effect on performance.
Note however, if the control command channel is secured, it will be Note however, if the control command channel is secured, it will be
impossible for an ALG to update the IP addresses in the command impossible for an ALG to update the IP addresses in the command
exchange. exchange.
When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same
problems that occur with X-Term/Telnet occur with FTP. problems that occur with X-Term/Telnet occur with FTP.
Lastly, it is of interest to note section 4 of RFC 2428 (FTP extensions Lastly, it is of interest to note section 4 of RFC 2428 (FTP
for IPv6 and NATs) which describes how a new FTP port command (EPSV ALL) extensions for IPv6 and NATs) which describes how a new FTP port
can be used to allow NAT devices to fast-track the FTP protocol, command (EPSV ALL) can be used to allow NAT devices to fast-track the
eliminating further processing through ALG, if the remote server FTP protocol, eliminating further processing through ALG, if the
accepts "EPSV ALL". remote server accepts "EPSV ALL".
4.2 RSVP 4.2 RSVP
RSVP is positioned in the protocol stack at the transport layer, RSVP is positioned in the protocol stack at the transport layer,
operating on top of IP (either IPv4 or IPv6). However, unlike other operating on top of IP (either IPv4 or IPv6). However, unlike other
transport protocols, RSVP does not transport application data but transport protocols, RSVP does not transport application data but
instead acts like other Internet control protocols (for example, ICMP, instead acts like other Internet control protocols (for example,
IGMP, routing protocols). RSVP messages are sent hop-by-hop between ICMP, IGMP, routing protocols). RSVP messages are sent hop-by-hop
RSVP-capable routers as raw IP datagrams using protocol number 46. It is between RSVP-capable routers as raw IP datagrams using protocol
intended that raw IP datagrams should be used between the end systems number 46. It is intended that raw IP datagrams should be used
and the first (or last) hop router. However, this may not always be between the end systems and the first (or last) hop router. However,
possible as not all systems can do raw network I/O. Because of this, it this may not always be possible as not all systems can do raw network
is possible to encapsulate RSVP messages within UDP datagrams for end- I/O. Because of this, it is possible to encapsulate RSVP messages
system communication. UDP-encapsulated RSVP messages are sent to either within UDP datagrams for end-system communication. UDP-encapsulated
port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP- RSVP messages are sent to either port 1698 (if sent by an end system)
enabled router). For more information concerning UDP encapsulation of or port 1699 (if sent by an RSVP-enabled router). For more
RSVP messages; consult Appendix C of RFC 2205. information concerning UDP encapsulation of RSVP messages; consult
Appendix C of RFC 2205.
An RSVP session, a data flow with a particular destination and An RSVP session, a data flow with a particular destination and
transport-layer protocol, is defined by: transport-layer protocol, is defined by:
Destination Address - the destination IP address for the data packets. Destination Address - the destination IP address for the data
This may be either a unicast or a multicast address. packets. This may be either a unicast or a multicast address.
Protocol ID - the IP protocol ID (for example, UDP or TCP). Protocol ID - the IP protocol ID (for example, UDP or TCP).
Destination Port - a generalized destination port that is used for Destination Port - a generalized destination port that is used for
demultiplexing at a layer above the IP layer. demultiplexing at a layer above the IP layer.
NAT devices are presented with unique problems when it comes to NAT devices are presented with unique problems when it comes to
supporting RSVP. Two issues are: supporting RSVP. Two issues are:
1. RSVP message objects may contain IP addresses. The result is that an 1. RSVP message objects may contain IP addresses. The result is that
RSVP-ALG must be able to replace the IP addresses based upon the an RSVP-ALG must be able to replace the IP addresses based upon the
direction and type of the message. For example, if an external sender direction and type of the message. For example, if an external
were to send an RSVP Path message to an internal receiver, the RSVP sender were to send an RSVP Path message to an internal receiver, the
session will specify the IP address that the external sender believes is RSVP session will specify the IP address that the external sender
the IP address of the internal receiver. However, when the RSVP Path believes is the IP address of the internal receiver. However, when
message reaches the NAT device, the RSVP session must be changed to the RSVP Path message reaches the NAT device, the RSVP session must
reflect the IP address that is used internally for the receiver. Similar be changed to reflect the IP address that is used internally for the
actions must be taken for all message objects that contain IP addresses. receiver. Similar actions must be taken for all message objects that
contain IP addresses.
2. RSVP provides a means, the RSVP Integrity object, to guarantee the 2. RSVP provides a means, the RSVP Integrity object, to guarantee the
integrity of RSVP messages. The problem is that because of the first integrity of RSVP messages. The problem is that because of the first
point, a NAT device must be able to change IP addresses within the RSVP point, a NAT device must be able to change IP addresses within the
messages. However, when this is done, the RSVP Integrity object is no RSVP messages. However, when this is done, the RSVP Integrity object
longer valid as the RSVP message has been changed. Therefore an RSVP-ALG is no longer valid as the RSVP message has been changed. Therefore
will not work when RSVP Integrity Object is used. an RSVP-ALG will not work when RSVP Integrity Object is used.
4.3 DNS 4.3 DNS
DNS is a TCP/UDP based protocol. Domain Names are an issue for hosts DNS is a TCP/UDP based protocol. Domain Names are an issue for hosts
which use local DNS servers in NAT private realm. DNS name to address which use local DNS servers in NAT private realm. DNS name to
mapping for hosts in private domain should be configured on an address mapping for hosts in private domain should be configured on
authoritative name server within private domain. This server would an authoritative name server within private domain. This server
be accessed by external and internal hosts alike for name would be accessed by external and internal hosts alike for name
resolutions. A DNS-ALG would be required to perform address to name resolutions. A DNS-ALG would be required to perform address to name
conversions on DNS queries and responses. RFC 2694 describes DNS-ALG conversions on DNS queries and responses. [DNS-ALG] describes DNS-
in detail. If DNS packets are encrypted/authenticated per DNSSEC, ALG
then DNS_ALG will fail because it won't be able to perform payload in detail. If DNS packets are encrypted/authenticated per DNSSEC,
modifications. then DNS_ALG will fail because it won't be able to perform payload
modifications.
Applications using DNS resolver to resolve a DNS name into an Applications using DNS resolver to resolve a DNS name into an IP
IP address, assume availability of address assignment for reuse address, assume availability of address assignment for reuse by the
by the application specific session. As a result, DNS-ALG will application specific session. As a result, DNS-ALG will be required
be required to keep the address assignment (between private and to keep the address assignment (between private and external
external addresses) valid for a pre-configured period of time, addresses) valid for a pre-configured period of time, past the DNS
past the DNS query. query.
Alternately, if there isn't a need for a name server within private Alternately, if there isn't a need for a name server within private
domain, private domain hosts could simply point to an external name domain, private domain hosts could simply point to an external name
server for external name lookup. No ALG is required when the name server for external name lookup. No ALG is required when the name
server is located in external domain. server is located in external domain.
4.4 SMTP 4.4 SMTP
SMTP is a TCP based protocol (Refer RFC 821), used by Internet SMTP is a TCP based protocol ([SMTP]), used by Internet email
email programs such as sendmail to send TCP-based email messages programs such as sendmail to send TCP-based email messages to well-
to well-known port 25. The mail server may be located within or known port 25. The mail server may be located within or outside
outside private domain. But, the server must be assigned a global private domain. But, the server must be assigned a global name and
name and address, accessible by external hosts. When mail server address, accessible by external hosts. When mail server is located
is located within private domain, inbound SMTP sessions must be within private domain, inbound SMTP sessions must be redirected to
redirected to the private host from its externally assigned the private host from its externally assigned address. No special
address. No special mapping is required when Mail server is mapping is required when Mail server is located in external domain.
located in external domain.
Generally speaking, mail systems are configured such that all Generally speaking, mail systems are configured such that all users
users specify a single centralized address (such as specify a single centralized address (such as fooboo@company.com),
fooboo@company.com), instead of including individual hosts (such instead of including individual hosts (such as
as fooboo@hostA.company.com). The central address must have an MX fooboo@hostA.company.com). The central address must have an MX
record specified in the DNS name server accessible by external record specified in the DNS name server accessible by external hosts.
hosts.
In the majority of cases, mail messages do not contain reference In the majority of cases, mail messages do not contain reference to
to private IP addresses or links to content data via names that private IP addresses or links to content data via names that are not
are not visible to outside. However, some mail messages do contain visible to outside. However, some mail messages do contain IP
IP addresses of the MTAs that relay the message in the "Received: " addresses of the MTAs that relay the message in the "Received: "
field. Some mail messages use IP addresses in place of FQDN for field. Some mail messages use IP addresses in place of FQDN for
debug purposes or due to lack of a DNS record, in "Mail From: " debug purposes or due to lack of a DNS record, in "Mail From: "
field. field.
If one or more MTAs were to be located behind NAT in a private If one or more MTAs were to be located behind NAT in a private
domain, and the mail messages are not secured by signature or domain, and the mail messages are not secured by signature or
cryptographic keys, an SMTP-ALG may be used to translate the cryptographic keys, an SMTP-ALG may be used to translate the IP
IP address information registered by the MTAs. If the MTAs address information registered by the MTAs. If the MTAs have static
have static address mapping, the translation would be valid address mapping, the translation would be valid across realms for
across realms for long periods of time. long periods of time.
The ability to trace the mail route may be hampered or prevented The ability to trace the mail route may be hampered or prevented by
by NAT alone, without the ALG. This can cause problems when NAT alone, without the ALG. This can cause problems when debugging
debugging mail problems or tracking down abusive users of mail. mail problems or tracking down abusive users of mail.
4.5 SIP 4.5 SIP
SIP (Refer [SIP]) can run on either TCP or UDP, but by default on SIP (Refer [SIP]) can run on either TCP or UDP, but by default on the
the same port 5060. same port 5060.
When used with UDP, a response to a SIP request does not go to the
source port the request came from. Rather the SIP message contains
the port number the response should be sent to. SIP makes use of
ICMP port unreachable errors in the response to request
transmissions. Request messages are usually sent on the connected
socket. If responses are sent to the source port in the request,
each thread handling a request would have to listen on the socket
it sent the request on. However, by allowing responses to come to
a single port, a single thread can be used for listening instead.
A server may prefer to place the source port of each connected When used with UDP, a response to a SIP request does not go to the
socket in the message. Then each thread can listen for responses source port the request came from. Rather the SIP message contains
separately. Since the port number for a response may not go to the port number the response should be sent to. SIP makes use of
the source port of the request, SIP will not normally traverse ICMP port unreachable errors in the response to request
a NAT and would require a SIP-ALG. transmissions. Request messages are usually sent on the connected
socket. If responses are sent to the source port in the request,
each thread handling a request would have to listen on the socket it
sent the request on. However, by allowing responses to come to a
single port, a single thread can be used for listening instead.
SIP messages carry arbitrary content, which is defined by a MIME type. A server may prefer to place the source port of each connected socket
in the message. Then each thread can listen for responses
separately. Since the port number for a response may not go to the
source port of the request, SIP will not normally traverse a NAT and
would require a SIP-ALG.
For multimedia sessions, this is usually the Session Description SIP messages carry arbitrary content, which is defined by a MIME
Protocol (SDP RFC 2327). SDP may specify IP addresses or ports to be type. For multimedia sessions, this is usually the Session
used for the exchange of multimedia. These may loose significance when Description Protocol (SDP RFC 2327). SDP may specify IP addresses or
traversing a NAT. Thus a SIP-ALG would need the intelligence to ports to be used for the exchange of multimedia. These may loose
decipher and translate realm-relevant information. significance when traversing a NAT. Thus a SIP-ALG would need the
intelligence to decipher and translate realm-relevant information.
SIP carries URL's in its Contact, To and From fields that specify SIP carries URL's in its Contact, To and From fields that specify
signaling addresses. These URL's can contain IP addresses or domain signaling addresses. These URL's can contain IP addresses or domain
names in the host port portion of the URL. These may not be valid names in the host port portion of the URL. These may not be valid
once they traverse a NAT. once they traverse a NAT.
As an alternative to an SIP-ALG, SIP supports a proxy server which As an alternative to an SIP-ALG, SIP supports a proxy server which
could co-reside with NAT and function on the globally significant could co-reside with NAT and function on the globally significant NAT
NAT port. Such a proxy would have a locally specific configuration. port. Such a proxy would have a locally specific configuration.
4.6 RealAudio 4.6 RealAudio
In default mode, RealAudio clients (say, in a private domain) In default mode, RealAudio clients (say, in a private domain) access
access TCP port 7070 to initiate conversation with a real-audio server TCP port 7070 to initiate conversation with a real-audio server (say,
(say, located an external domain) and to exchange control messages located an external domain) and to exchange control messages during
during playback (ex: pausing or stopping the audio stream). Audio playback (ex: pausing or stopping the audio stream). Audio session
session parameters are embedded in the TCP control session as parameters are embedded in the TCP control session as byte stream.
byte stream.
The actual audio traffic is carried in the opposite direction on The actual audio traffic is carried in the opposite direction on
incoming UDP based packets (originated from the server) directed incoming UDP based packets (originated from the server) directed to
to ports in the range of 6970-7170. ports in the range of 6970-7170.
As a result, RealAudio is broken by default on a traditional NAT As a result, RealAudio is broken by default on a traditional NAT
device. A work around for this would be for the ALG to examine the device. A work around for this would be for the ALG to examine the
TCP traffic to determine the audio session parameters and TCP traffic to determine the audio session parameters and selectively
selectively enable inbound UDP sessions for the ports agreed upon enable inbound UDP sessions for the ports agreed upon in the TCP
in the TCP control session. Alternately, the ALG could simply control session. Alternately, the ALG could simply redirect all
redirect all inbound UDP sessions directed to ports 6970-7170 to inbound UDP sessions directed to ports 6970-7170 to the client
the client address in the private domain. address in the private domain.
For bi-Directional NAT, you will not need an ALG. Bi-directional NAT For bi-Directional NAT, you will not need an ALG. Bi-directional NAT
could simply treat each of the TCP and UDP sessions as 2 unrelated could simply treat each of the TCP and UDP sessions as 2 unrelated
sessions and perform IP and TCP/UDP header level translations. sessions and perform IP and TCP/UDP header level translations.
The readers may contact RealNetworks, Inc. for detailed guidelines The readers may contact RealNetworks for detailed guidelines on how
on how their applications can be made to work, traversing through NAT their applications can be made to work, traversing through NAT and
and firewall devices. firewall devices.
4.7 H.323 4.7 H.323
H.323 is complex, uses dynamic ports, and includes multiple UDP streams. H.323 is complex, uses dynamic ports, and includes multiple UDP
Here is a summary of the relevant issues: streams. Here is a summary of the relevant issues:
An H.323 call is made up of many different simultaneous connections. At An H.323 call is made up of many different simultaneous connections.
least two of the connections are TCP. For an audio-only conference, At least two of the connections are TCP. For an audio-only
there may be up to 4 different UDP 'connections' made. conference, there may be up to 4 different UDP 'connections' made.
All connections except one are made to ephemeral (dynamic) ports. All connections except one are made to ephemeral (dynamic) ports.
Calls can be initiated from the private as well as the external domain. Calls can be initiated from the private as well as the external
For conferencing to be useful, external users need to be able to domain. For conferencing to be useful, external users need to be
establish calls directly with internal users' desktop systems. able to establish calls directly with internal users' desktop
systems.
The addresses and port numbers are exchanged within the data stream of The addresses and port numbers are exchanged within the data stream
the 'next higher' connection. For example, the port number for the H.245 of the 'next higher' connection. For example, the port number for
connection is established within the Q.931 data stream. (This makes it the H.245 connection is established within the Q.931 data stream.
particularly difficult for the ALG, which will be required to modify the (This makes it particularly difficult for the ALG, which will be
addresses inside those data streams.) To make matters worse, it is required to modify the addresses inside these data streams.) To make
possible in Q.931, for example, to specify that the H.245 connection matters worse, it is possible in Q.931, for example, to specify that
should be secure (encrypted). If a session is encrypted, it is the H.245 connection should be secure (encrypted). If a session is
impossible for the ALG to decipher encrypted, it is impossible for the ALG to decipher the data stream,
the data stream, unless it has access to the shared key. unless it has access to the shared key.
Most of the control information is encoded in ASN.1 (only the User-User Most of the control information is encoded in ASN.1 (only the User-
Information within Q.931 Protocol Data Units, or PDUs, is ASN.1-encoded User Information within Q.931 Protocol Data Units, or PDUs, is
(other parts of each Q.931 PDU are not encoded). For those unfamiliar ASN.1-encoded (other parts of each Q.931 PDU are not encoded). For
with ASN.1, suffice it to say that it is a complex encoding scheme, those unfamiliar with ASN.1, suffice it to say that it is a complex
which does not end up with fixed byte offsets for address information. encoding scheme, which does not end up with fixed byte offsets for
In fact, the same version of the same application connecting to the same address information. In fact, the same version of the same
destination may negotiate to include different options, changing the application connecting to the same destination may negotiate to
byte offsets. include different options, changing the byte offsets.
Below is the protocol exchange for a typical H.323 call between User A Below is the protocol exchange for a typical H.323 call between User
and User B. A's IP address is 88.88.88.88 and B's IP address is A and User B. A's IP address is 88.88.88.88 and B's IP address is
99.99.99.99. Note that the Q.931 and H.245 messages are encoded in 99.99.99.99. Note that the Q.931 and H.245 messages are encoded in
ASN.1 in the payload of an RTP packet. So to accomplish a connection ASN.1 in the payload of an RTP packet. So to accomplish a connection
through a NAT device, an H.323-ALG will be required to examine the through a NAT device, an H.323-ALG will be required to examine the
packet, decode the ASN.1, and translate the various H.323 control IP packet, decode the ASN.1, and translate the various H.323 control IP
addresses. addresses.
User A User B User A User B
A establishes connection to B on well- A establishes connection to B on well-
known Q.931 port (1720) known Q.931 port (1720)
-----------------------------------------------> ----------------------------------------------->
Q.931 Setup caller address = 88.88.88.88 Q.931 Setup caller address = 88.88.88.88
caller port = 1120 caller port = 1120
callee address = 99.99.99.99 callee address = 99.99.99.99
callee port = 1720 callee port = 1720
<-----------------------------------------------
Q.931 Alerting
<-----------------------------------------------
Q.931 Connect H.245 address = 99.99.99.99
H.245 port = 1092
<----------------------------------------------- User A establishes connection to User B at
Q.931 Alerting 99.99.99.99, port 1092
<-----------------------------------------------
Q.931 Connect H.245 address = 99.99.99.99
H.245 port = 1092
User A establishes connection to User B at <---------------------------------------------->
99.99.99.99, port 1092 Several H.245 messages are exchanged (Terminal
Capability Set, Master Slave Determination and
their respective ACKs)
<----------------------------------------------> <-----------------------------------------------
Several H.245 messages are exchanged (Terminal H.245 Open Logical Channel, channel = 257
Capability Set, Master Slave Determination and RTCP address = 99.99.99.99
their respective ACKs) RTCP port = 1093
----------------------------------------------->
H.245 Open Logical Channel Ack, channel = 257
RTP address = 88.88.88.88
RTP port = 2002
(This is where User A would like RTP
data sent to)
<----------------------------------------------- RTCP address = 88.88.88.88
H.245 Open Logical Channel, channel = 257 RTCP port = 2003
RTCP address = 99.99.99.99 ----------------------------------------------->
RTCP port = 1093 H.245 Open Logical Channel, channel = 257
-----------------------------------------------> RTCP address = 88.88.88.88
H.245 Open Logical Channel Ack, channel = 257 RTCP port = 2003
RTP address = 88.88.88.88 <-----------------------------------------------
RTP port = 2002 H.245 Open Logical Channel Ack, channel = 257
(This is where User A would like RTP RTP address = 99.99.99.99
data sent to) RTP port = 1092
RTCP address = 88.88.88.88 (This is where User B would like RTP data
RTCP port = 2003 sent to)
-----------------------------------------------> RTCP address = 99.99.99.99
H.245 Open Logical Channel, channel = 257 RTP port = 1093
RTCP address = 88.88.88.88
RTCP port = 2003
<-----------------------------------------------
H.245 Open Logical Channel Ack, channel = 257
RTP address = 99.99.99.99
RTP port = 1092
(This is where User B would like RTP data
sent to)
RTCP address = 99.99.99.99
RTP port = 1093
Also note that if an H.323 Gateway resided inside a NAT boundary, the Also note that if an H.323 Gateway resided inside a NAT boundary, the
ALG would have to be cognizant of the various gateway discovery schemes ALG would have to be cognizant of the various gateway discovery
and adapt to those schemes as well. Or if just the H.323 host/terminal schemes and adapt to those schemes as well. Or if just the H.323
was inside the NAT boundary and tried to register with a Gatekeeper, the host/terminal was inside the NAT boundary and tried to register with
IP information in the registration messages would have to be translated a Gatekeeper, the IP information in the registration messages would
by NAT. have to be translated by NAT.
4.8 SNMP 4.8 SNMP
SNMP is a network management protocol based on UDP. SNMP payload may SNMP is a network management protocol based on UDP. SNMP payload may
contain IP addresses or may refer IP addresses through an index contain IP addresses or may refer IP addresses through an index into
into a table. As a result, when devices within a private network a table. As a result, when devices within a private network are
are managed by an external node, SNMP packets transiting a NAT managed by an external node, SNMP packets transiting a NAT device may
device may contain information that is not relevant in external contain information that is not relevant in external domain. In some
domain. In some cases, as described in [SNMP-ALG], an SNMP ALG may cases, as described in [SNMP-ALG], an SNMP ALG may be used to
be used to transparently convert realm-specific addresses into transparently convert realm-specific addresses into globally unique
globally unique addresses. Such an ALG assumes static address addresses. Such an ALG assumes static address mapping and bi-
mapping and can only work in conjunction with SNMPv1 or SNMPv2c directional NAT. It can only work for the set of data types (textual
protocols and bi-directional NAT. conventions) understood by the SNMP-ALG implementation and for a
given set of MIB modules. Furthermore, replacing IP addresses in the
Making SNMP ALGs completely transparent to all management SNMP payload may lead to communication failures due to changes in
applications is not an achievable task. The ALGs will run into message size or changes in the lexicographic ordering.
problems with SNMPv3 security features, when authentication (and
optionally privacy) is enabled, unless the ALG has access to
security keys.
Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used Making SNMP ALGs completely transparent to all management
in conjunction with NAT to forward SNMP messages to external SNMP applications is not an achievable task. The ALGs will run into
engines (and vice versa). SNMP proxies are tailored to the private problems with SNMPv3 security features, when authentication (and
domain context and can hence operate independent of the specific optionally privacy) is enabled, unless the ALG has access to security
managed object types being accessed. The proxy solution will require keys. [NAT-ARCH] also hints at potential issues with SNMP management
the external management application to be aware of the proxy via NAT.
forwarder and the individual nodes being managed will need to be
configured to direct their SNMP traffic (notifications and requests)
to the proxy forwarder.
[NAT-ARCH] also refers to limitations with running centralized SNMP Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used in
based applications, controlling devices/networks in multiple address conjunction with NAT to forward SNMP messages to external SNMP
realms. Such an application would require context specific SNMP engines (and vice versa). SNMP proxies are tailored to the private
packets to transit NAT devices. domain context and can hence operate independent of the specific
managed object types being accessed. The proxy solution will require
the external management application to be aware of the proxy
forwarder and the individual nodes being managed will need to be
configured to direct their SNMP traffic (notifications and requests)
to the proxy forwarder.
5.0 Protocols designed explicitly to work with NAT enroute 5.0 Protocols designed explicitly to work with NAT enroute
5.1 Activision Games 5.1 Activision Games
Activision Games were designed to be NAT-friendly so as not to require Activision Games were designed to be NAT-friendly so as not to
an ALG for the games to work transparently through traditional NAT require an ALG for the games to work transparently through
devices. Game players within a private domain can play with other traditional NAT devices. Game players within a private domain can
players in the same domain or external domain. Activision gaming play with other players in the same domain or external domain.
protocol is proprietary and is based on UDP. The server uses UDP Activision gaming protocol is proprietary and is based on UDP. The
port no. 21157. address server uses UDP port number 21157 and is expected to be
located in the global address realm.
All peers are somehow informed of each others' public and private Game players connect to the address server first, and send their
addresses, and each client opens up symmetrical direct connection to private IP address information (such as private IP address and UDP
each other and use whichever address (private or external) works first. port number) in the initial connect message. The server notes
Now, the clients can have a session directly with other clients directly private address information from the connect message and external
(or) they can have session with other clients via the gaming server. address information from the IP and UDP headers. The server then
The key is to allow the reuse of the tuple of the same (global sends both the private and external address information of the game
address, assigned UDP port) for initial connection to the game server player to all the other peer players. At this point, each game
(helper) and the subsequent connection to the client. A game player is player knows the private and public address information of every
recognized by one of (private address, UDP port) or (Assigned global other peer. Subsequent to this, each client opens up symmetrical
address, assigned UDP port) by all other peer players. So, the binding direct connection to each other and uses whichever address (private
between tuples should remain unchanged so long as the gaming player is or external) works first.
in session with one or multiple other players.
Opening a connection to a game server in external realm from a private Now, the clients can have a session directly with other clients (or)
host is no problem. All NAT would have to do is provide routing they can have session with other clients via the gaming server. The
transparency. key is to allow reuse of the same (global address, assigned UDP port)
tuple used for initial connection to the game server for all
subsequent connections to the client. A game player is recognized by
one of (private address, UDP port) or (global address, assigned UDP
port) by all other peer players. So, the binding between tuples
should remain unchanged on NAT, so long as the gaming player is in
session with one or multiple other players.
But, an NAPT configuration MUST allow multiple simultaneous UDP Opening a connection to a game server in external realm from a
connections on the same assigned global address/port. private host is no problem. All NAT would have to do is provide
routing transparency and retain the same private-to-external address
binding so long as there is a minimum of one gaming session with an
external node. But, an NAPT configuration must allow multiple
simultaneous UDP connections on the same assigned global
address/port.
The readers may refer Activision for the proprietary, detailed The above approach has some problems. For example, a client could
information on the function and design of this protocol. try contacting a private address, but that private address could be
in use locally, when the private address at some other realm is
meant. If the node that was contacted wrongfully has some other
service or no service registered for the UDP port, the Activision
connect messages are expected to be simply dropped. In the unlikely
event, a registered application chooses to interpret the message, the
results can be unpredictable.
6.0. Acknowledgements The readers may refer to Activision for the proprietary, detailed
information on the function and design of this protocol.
The authors would like to express sincere thanks to Bernard Aboba, 6.0 Acknowledgements
Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine,
Jeffrey Altman, Keith Moore, Vernon Shryver and others that had
provided valuable input in preparing this draft.
7.0. Security considerations The authors would like to express sincere thanks to Bernard Aboba,
Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine,
Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver and others
that had provided valuable input in preparing this document. Special
thanks to Dan Kegel for sharing the Activision games design
methodology.
The security considerations outlined in [NAT-TERM] are relevant to 7.0 Security Considerations
all NAT devices. This draft does not warrant additional security
considerations.
8.0 References The security considerations outlined in [NAT-TERM] are relevant to
all NAT devices. This document does not warrant additional security
considerations.
[NAT-TERM] Srisuresh, P., Holdrege, M. "IP Network Address Translator 8.0 References
(NAT) Terminology and Considerations", RFC 2663
[NAT-TRAD] Srisuresh, P., Egevang, K. "Traditional IP Network Address [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator(Traditional NAT)", Translator (NAT) Terminology and Considerations", RFC
<draft-ietf-nat-traditional-04.txt> 2663, August 1999.
[H.323] ITU-T SG16 H.323, Intel white paper, H.323 and
Firewalls; Dave Chouinard, John Richardson, Milind Khare
(with further assistance from Jamie Jason).
[SNMP-ALG] Raz, D., Schoenwaelder, J., and Sugla, B. "An SNMP [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Application Level Gateway for Payload Address Translation", Address Translator (Traditional NAT)", RFC 3022, January
<draft-ietf-nat-snmp-alg-05.txt> 2001.
[SNMP_APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", [H.323] ITU-T SG16 H.323, Intel white paper, "H.323 and
RFC 2573 Firewalls", Dave Chouinard, John Richardson, Milind
Khare (with further assistance from Jamie Jason).
[NAT-ARCH] Hain, T. "Architectural Implications of NAT", [SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP
<draft-iab-nat-implications-09.txt> Application Level Gateway for Payload Address
Translation", RFC 2962, October 2000.
[SMTP] RFC 821 [SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
RFC 2573, April 1999.
[FTP] RFC 959 [NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993,
November 2000.
[SIP] RFC 2543 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10,
RFC 821, August 1982.
[X Windows] RFC 1198 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol
(FTP)", STD 9, RFC 959, October 1985.
[RSVP] RFC 2205 [SIP] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[DNS] RFC 1034, RFC 1035, RFC 2694 [X Windows] Scheifler, B., "FYI on the X Window System", FYI 6, RFC
1198, January 1991.
[IPsec] RFC 2401, RFC 2402, RFC 2406, RFC 2411, RFC 2709 [RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, [DNS-TERMS] Mockapetris, P., "Domain Names - Concepts and
and, Lear, E. "Address Allocation for Private Internets", Facilities", STD 13, RFC 1034, November 1987.
RFC 1918
[ADDR-BEHA] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 [DNS-IMPL] Mockapetris, P., "Domain Names - Implementation and
Address Behaviour Today", RFC 2101 Specification", STD 13, RFC 1035, November 1987.
Authors Addresses:
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
Heffernan, "DNS extensions to Network Address
Translators (DNS_ALG)", RFC 2694, September 1999.
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode IPsec
for NAT Domains", RFC 2709, October 1999.
[PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
Authors' Addresses
Matt Holdrege Matt Holdrege
ipVerse ipVerse
223 Ximeno Ave. 223 Ximeno Ave.
Long Beach, CA 90803 Long Beach, CA 90803
EMail: matt@ipverse.com EMail: matt@ipverse.com
Pyda Srisuresh Pyda Srisuresh
Consultant Jasmine Networks, Inc.
849 Erie Circle 3061 Zanker Road, Suite B
Milpitas, CA 95035 San Jose, CA 95134
U.S.A. U.S.A.
Voice: (408) 263-7527
Phone: (408) 895-5032
EMail: srisuresh@yahoo.com EMail: srisuresh@yahoo.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 128 change blocks. 
663 lines changed or deleted 697 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/