draft-ietf-nat-protocol-complications-04.txt   draft-ietf-nat-protocol-complications-05.txt 
NAT Working Group Matt Holdrege NAT Working Group Matt Holdrege
INTERNET-DRAFT ipVerse INTERNET-DRAFT ipVerse
Category: Informational Pyda Srisuresh Category: Informational Pyda Srisuresh
Expires as of January 14, 2001 Campio Communications Expires as of April 9, 2001 Consultant
July, 2000 October, 2000
Protocol Complications with the IP Network Address Translator Protocol Complications with the IP Network Address Translator
<draft-ietf-nat-protocol-complications-04.txt> <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 document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
skipping to change at page 1, line 41 skipping to change at page 1, line 41
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast). (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract: Abstract:
Many internet applications can be adversely affected when Many internet applications can be adversely affected when end nodes
communicating end nodes are not in the same address realm and seek are not in the same address realm and seek the assistance of NAT
the assistance of NAT enroute to bridge the realms. NAT device enroute to bridge the realms. NAT device alone cannot provide the
cannot provide the necessary application/protocol transparency in necessary application/protocol transparency in all cases and seeks
all cases and seeks the assistance of Application Level Gateways the assistance of Application Level Gateways (ALGs) where possible,
(ALGs) where possible, to provide transparency. The purpose of to provide transparency. The purpose of this document is to
this document is to identify the protocols and applications that identify the protocols and applications that break with NAT enroute.
break with NAT enroute. The document also attempts to identify The document also attempts to identify any known workarounds. It is
any known workarounds. It is impossible to capture all the impossible to capture all the applications that break with NAT in a
applications that break with NAT in a single document. This single document. This document attempts to capture as much informa-
document attempts to capture as much of the information as tion as possible, but by no means a comprehensive coverage. We hope
possible, but is by no means a comprehensive coverage. We hope this coverage provides clues for applications not covered here.
this coverage provides necessary clues for applications not
covered by the document.
Table of Contents Table of Contents
1.0 Introduction 1.0 Introduction
2.0 Common Characteristics of Protocols broken by NAT 2.0 Common Characteristics of Protocols broken by NAT
3.0 Protocols that cannot work with NAT enroute 3.0 Protocols that cannot work with NAT enroute
4.0 Protocols that can work with the aid of an ALG 4.0 Protocols that can work with the aid of an ALG
skipping to change at page 3, line 51 skipping to change at page 4, line 4
is not encrypted, an ALG may in some cases be able to provide the work is not encrypted, an ALG may in some cases be able to provide the work
around necessary to make the applications run transparently across around necessary to make the applications run transparently across
realms. The complexity of ALG depends on the application level realms. The complexity of ALG depends on the application level
knowledge required to process payload and maintain state. 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 as the session from a host in private realm. External likely as the session from a host in private realm. External
peers will be able to locate their peers in private realm only peers will be able to locate their peers in private realm only
when they know the externally assigned IP address or the FQDN when they know the externally assigned IP address or the FQDN
ahead of time. FQDN name to assigned address mapping can happen ahead of time. FQDN name to assigned address mapping can happen
only so long as the enroute NAT device supports DNS-ALG. Examples only so long as the enroute NAT device supports DNS-ALG. Examples
of Peer-to-peer applications include interactive games, Internet of Peer-to-peer applications include interactive games, Internet
telephony and event-based protocols (such as Instant-Messaging). telephony and event-based 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
skipping to change at page 6, line 51 skipping to change at page 7, line 4
occur from inside the organization. occur 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. Therefore,
an ALG cannot be written. 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 krb5
1.1 implementation allows you to put "noaddresses" somewhere in 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
skipping to change at page 8, line 51 skipping to change at page 9, line 4
other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the
least secure of all the documented X Authorization methods. least secure of all the documented X Authorization methods.
When START_TLS is used there may be client certificate verification When START_TLS is used there may be client certificate verification
problems caused by the NAT depending on the information provided in problems caused by the NAT depending on the information provided in
the certificate. 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 to
the server for use as stderr port. The stderr socket is a connection the server for use as stderr port. The stderr socket is a connection
back from the server to the client. And unlike FTP, there is no back from the server to the client. And unlike FTP, there is no
equivalent to PASV mode. For traditional NAT, this is a problem equivalent to PASV mode. For traditional NAT, this is a problem
as traditional NAT would not permit incoming sessions. 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 the ticket problems and the use of multiple sessions. to the ticket problems and the use of multiple sessions.
3.7 SNMP
SNMP configuration packet payload may contain router configuration
items, which are IP addresses. If such a packet transits NAT to another
IP address domain they will be incorrect. Network Admins should take
care to not send such packets across NAT. In some cases, it is possible
to use SNMP-ALG to convert realm-specific addresses to globally unique
addresses.
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 between
two hosts. FTP uses bundled session approach to accomplish this. two hosts. FTP uses bundled session approach to accomplish this.
skipping to change at page 16, line 10 skipping to change at page 16, line 4
(This is where User B would like RTP data (This is where User B would like RTP data
sent to) sent to)
RTCP address = 99.99.99.99 RTCP address = 99.99.99.99
RTP port = 1093 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 schemes
and adapt to those schemes as well. Or if just the H.323 host/terminal and adapt to those schemes as well. Or if just the H.323 host/terminal
was inside the NAT boundary and tried to register with a Gatekeeper, the was inside the NAT boundary and tried to register with a Gatekeeper, the
IP information in the registration messages would have to be translated IP information in the registration messages would have to be translated
by NAT. by NAT.
4.8 SNMP
SNMP is a network management protocol based on UDP. SNMP payload may
contain IP addresses or may refer IP addresses through an index
into a table. As a result, when devices within a private network
are managed by an external node, SNMP packets transiting a NAT
device may contain information that is not relevant in external
domain. In some cases, as described in [SNMP-ALG], an SNMP ALG may
be used to transparently convert realm-specific addresses into
globally unique addresses. Such an ALG assumes static address
mapping and can only work in conjunction with SNMPv1 or SNMPv2c
protocols and bi-directional NAT.
Making SNMP ALGs completely transparent to all management
applications is not an achievable task. The ALGs will run into
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
in conjunction with NAT to forward SNMP messages to external SNMP
engines (and vice versa). SNMP proxies are tailored to the private
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.
[NAT-ARCH] also refers to limitations with running centralized SNMP
based applications, controlling devices/networks in multiple address
realms. Such an application would require context specific SNMP
packets to transit NAT devices.
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 require
an ALG for the games to work transparently through traditional NAT an ALG for the games to work transparently through traditional NAT
devices. Game players within a private domain can play with other devices. Game players within a private domain can play with other
players in the same domain or external domain. Activision gaming players in the same domain or external domain. Activision gaming
protocol is proprietary and is based on UDP. The server uses UDP protocol is proprietary and is based on UDP. The server uses UDP
port no. 21157. port no. 21157.
skipping to change at page 17, line 28 skipping to change at page 18, line 9
(NAT) Terminology and Considerations", RFC 2663 (NAT) Terminology and Considerations", RFC 2663
[NAT-TRAD] Srisuresh, P., Egevang, K. "Traditional IP Network Address [NAT-TRAD] Srisuresh, P., Egevang, K. "Traditional IP Network Address
Translator(Traditional NAT)", Translator(Traditional NAT)",
<draft-ietf-nat-traditional-04.txt> <draft-ietf-nat-traditional-04.txt>
[H.323] ITU-T SG16 H.323, Intel white paper, H.323 and [H.323] ITU-T SG16 H.323, Intel white paper, H.323 and
Firewalls; Dave Chouinard, John Richardson, Milind Khare Firewalls; Dave Chouinard, John Richardson, Milind Khare
(with further assistance from Jamie Jason). (with further assistance from Jamie Jason).
[SNMP-ALG] Raz, D., Schoenwaelder, J., and Sugla, B. "An SNMP
Application Level Gateway for Payload Address Translation",
<draft-ietf-nat-snmp-alg-05.txt>
[SNMP_APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
RFC 2573
[NAT-ARCH] Hain, T. "Architectural Implications of NAT",
<draft-iab-nat-implications-09.txt>
[SMTP] RFC 821 [SMTP] RFC 821
[FTP] RFC 959 [FTP] RFC 959
[SIP] RFC 2543 [SIP] RFC 2543
[X Windows] RFC 1198 [X Windows] RFC 1198
[RSVP] RFC 2205 [RSVP] RFC 2205
skipping to change at page 18, line 12 skipping to change at page 19, line 14
Authors Addresses: 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
Campio Communications Consultant
630 Alder Drive 849 Erie Circle
Milpitas, CA 95035 Milpitas, CA 95035
U.S.A. U.S.A.
Voice: (408) 519-3849 Voice: (408) 263-7527
EMail: srisuresh@yahoo.com EMail: srisuresh@yahoo.com
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/