Subject: [NAT] [fwd] comments on draft-ietf-nat-app-guide-05.txt

From: Keith Moore <[email-masked]>
Date: Wed, 11 Apr 2001 19:40:38 -0400

Hi.  several weeks ago I wrote these comments and sent them to 
the author of the draft via private mail. a few days later,
at his suggestion, they were forwarded to the nat list address.  
unfortunately they were blocked by the list software in use
at the time.

so now that the list has been moved, and the restrictions on posting 
removed, I'm resubmitting my comments. I'm sorry this has taken so 
long; I hope they're still useful.

Keith

------- Forwarded Message

To: [email-masked]
Subject: comments on draft-ietf-nat-app-guide-05.txt
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Mon, 26 Mar 2001 15:07:49 -0500

Hi.  I've read your draft with interest as I had started writing one 
of my own on a similar topic.  I have the following comments to make:

> Preface:
> 
>    While many common Internet applications will operate cleanly in the
>    presence of Network Address Translators, others suffer from a variety
>    of problems when crossing these devices. This document discusses
>    those things that application designers might wish to consider when
>    designing new protocols. Guidelines are presented herein to help
>    ensure new protocols and applications will, to the extent possible,
>    be compatible with NAT.

a secondary goal might be to help designers realize when their approaches
are (of necessity) incompatible with NAT.  

> 1. Introduction
> 
>    Other documents that describe Network Address Translation (NAT)
>    discuss the Terminology and Considerations [RFC2663] and Protocol
>    Issues [RFC3022], [RFC3027] or discuss the perceived implications of
>    NAT [RFC2993]. 

suggest you delete 'perceived' 

>    All of those relate to various issues with the NAT
>    mechanism and its effects on protocols that already exist. 

not true - 2993 talks about architectural issues in general, which are
not limited to already-deployed protocols.

> It is the
>    focus of this document to instruct authors of new protocols what to
>    think about when designing new protocols such that special handling
>    is not required at NAT gateway points.

Instead of 'instruct' I would say 'inform' or 'suggest'

>    When a protocol is unable to pass cleanly through a NAT, the use of
>    an Application Level Gateway (ALG) can still permit operation of the
>    protocol.  Depending on the encoding used in a protocol, the ALG may
>    be difficult or easy to construct. 

this is a bit misleading in two ways:

1. some, but not all, protocols can work through NAT with an ALG.
   the above text could be read as saying that all protocols can work
   through NAT with an ALG, but this isn't the case.
   
   such ALGs might therefore be easy, difficult, or impossible to construct :)

2. it might be useful to make a distinction between ALGs that were 
   designed and specified in conjunction with a protocol and ALGs that
   were designed after the fact.   if an ALG is necessary, the protocol
   is much more likely to work well with NAT if the ALG is part of the
   protocol design.

   one could argue that a generic ALG is needed, though perhaps this
   document is not the place to do it.

> While adjunct to NAT, the
>    formulation of protocols that cannot directly operate through NAT
>    should be considered such that the ALG design may be simple and
>    automated. ALGs typically operate inside small routers along with the
>    NAT component. Ideally, the ALG should be simple and not require
>    excessive computation or state storage.

I suspect that a bit more could be said about limitations placed on ALGs.
it might be worthwhile to make a separate section in the document for
discussion of ALG design.

>    The same issues in application design that create issues for NAT (and
>    thus can require ALG support) are also issues for firewalls. 

this doesn't seem true to me - there is some overlap between the issues
associated with NATs and firewalls but there seem to be far more 
NAT-specific or firewall-specific issues than issues common to both.

OTOH, if your application deals with NAT issues then it has probably 
covered some of the bases for firewalls also - perhaps you would rather 
say something like:

] Many of the same issues associated with deployment of applications 
] in a network containing firewalls are also issues associated with
] deployment of applications in a network containing NATs.  Thus an
] application which is NAT-friendly is more likely to be firewall-friendly.

but even this is a stretch.  in general the issues associated with
administrative prohibitions on traffic are orthogonal to the issues
associated with operating across multiple addressing realms.
the main things that they have in common are 

- - both firewall configurations and NATs often assume that there is an 
  "inside" and an "outside" and that connections are initiated from 
  "inside".  

- - nats and firewalls both employ ALGs, and the problems caused by those
  ALGs in firewalls are similar to the problem caused by ALGs in NATs.

but neither of these support a generalization to the effect that the
issues are the same for NATs and firewalls.

> An
>    application designer would do well to keep this in mind, as any
>    protocol that does require special handling by NAT or firewall
>    products will be more difficult to deploy than those that require no
>    special handling.

very true.

> 2. Discussion
> 
>    Network Address Translation presents a challenge to some existing
>    applications. It should be possible for developers of new
>    applications to avoid problems if they understand the issues
>    involved. 

this is an over-generalization.  NATs do impair the ability of the network
to support some kinds of applications (with or without ALGs); thus, it is 
not always possible for developers to avoid such problems.  of course it
is useful to make developers aware of those fundamental limitations.

> This document aims to provide the application designer with
>    information on what to do, and what to avoid, when building
>    applications.
> 
>    The proliferation of NAT, especially in homes and small offices
>    cannot be dismissed. The emerging technologies for providing high
>    bandwidth to these types of locations often allow only a single IP
>    address per location.  

the first statement is true; the second one is not.  providing high 
bandwidth has nothing to do with providing only a single IP address; 
furthermore, the technologies employed to make high bandwidth available
to homes and small offices often do allow the use of multiple IP 
addresses.  use of a single IP address is a business/marketing decision,
not an inherent limitation of the bearer technology.

(it is unfortunately true that some of the bearer technologies use the
IP address as both a layer 2 and layer 3 address, thus making it 
slightly more difficult to route multiple IP addresses to a single
port.  but this is not true for all or even most of them)

> As such NAT is a clear choice for connecting
>    more than a single system per location.
> 
>    Clearly the most common problem associated with NAT implementations
>    is the passing of addressing data between stations. Where possible,
>    applications should find alternatives to such schemes. Studying a few
>    existing protocols will serve to highlight the different approaches
>    possible.
> 
>    Two common forms of Traditional NAT exist. With Basic NAT, only the
>    IP addresses of packets are altered by the NAT implementation. Many
>    applications will operate correctly with Basic NAT. The other common
>    form is Network Address Port Translation. With NAPT, both the IP
>    addresses and the source and destination ports (for TCP and UDP) are
>    potentially altered by the gateway. As such, applications passing
>    only port number information will work with Basic NAT, but not with
>    NAPT.
> 
>    Application designers should ensure compatibility with NAPT, as this
>    form of NAT is the most widely deployed. This is also the form of NAT
>    that will likely see the greatest penetration in homes and small
>    offices.

I'd recommend that you separate the description of the barriers that
NAT/NAPTs impose to new applications from recommendations to application
designers.  The reason is that every application is different.  Your 
description of NATs limitations and characteristics are likely to be 
useful to all application designers, but for any particular application
the compromise between efficiency/functionality of the application on
one hand and deployability/NAT-compatibility on the other may need to be
made at a different place than you would recommend.  It's simply not 
appropriate for every application to use TCP and DNS names, and be 
client-server with connectiions coming from inside, etc. 

> 3. Recommendations and Examples
> 
>    When possible, applications designers should strive to avoid the
>    necessity of ALG functions in NAT implementations. Since the same
>    issues apply to firewalls, application designers have added incentive
>    to consider these recommendations.

again, I would reword this not to say what designers "should" do but
to say that certain kinds of designs will be more compatible with NATs
than others.  I would delete the second sentence for reasons given above.

>    Applications that work in such fashion as to not need ALG support
>    will be much easier to deploy, and have the greatest chance of
>    operation on a broad spectrum of NAT implementations.

you might give some more generalizations here.  for example:

(most deployable)
applications that are compatible with NAPTs without needing ALGs
applications that are compatible with NATs without needing ALGs
applications that are compatible with NATs or NAPTs but need ALGs
applications that are compatible with NATs or NAPTs but require
 explicit configuration of the NATs
applications that are incompatible with NATs or NAPTs
(least deployable)

>    Each of the areas called out below are examples of issues to consider
>    when building an application. This list is likely not comprehensive,
>    but does cover a number of important issues and considerations.
> 
> 
>     3.1 Issues and Recommendations affecting all types of Network
>       Address Translators
> 
>     3.1.1. Peer-to-Peer Applications Limitations
> 
>       Peer to peer applications are problematic in a NAT world. Client-
>       server applications are more generally workable. Peer-to-peer
>       applications rely on each peer being reachable as a server for the
>       other to connect to. 

the notion of "server" is probably misleading here  since peer-to-peer
implies no distinction between servers and clients - why not say that
peer-to-peer applications rely on each peer being able to accept 
incoming connections from other peers?

> With NAPT, there are likely many machines
>       behind one address. With other types of NAT such as one-to-one
>       mappings, there is a greater chance of making such applications
>       work.
> 
>       Some implementations of NAT can be made to function for UDP-based
>       peer-to-peer applications such as interactive gaming. This
>       capability is dependent on the methodology used to implement the
>       UDP sessions in the NAT device. If the NAT device tracks the tuple
>       (private address, private port, public port) then it is possible
>       for an outbound UDP packet to establish a channel by which
>       incoming traffic can flow from a source other than that originally
>       contacted by the system. NAT devices which track source and
>       destination IP addresses, in addition to port numbers, will not
>       permit third-party packets. The latter implementation is generally
>       more secure.

I think this is confusing two issues, which are better treated separately: 

1) use of UDP across NATs in general

UDP has problems with some NATs because they don't know what to assume
regarding translation lifetime (actually, they don't know this for TCP 
either, but they think they do).  reportedly some NATs do not deal with
UDP at all, while others implement simple timeout mechanisms.

2) from which side of a 'sessions' must be initiated in order to
   allocate a translation in the NAT  (or open up a pinhole in a firewall)

as you state, a lot of NATs and firewalls expect "clients" to initiate
the connection, but it might be more accurate to say that the connections
must be initiated from 'inside' the NAT or firewall.

>       NAT device implementations could be constructed to have a switch
>       within them, permitting the consumer the ability to select whether
>       they want greater security, or greater ability to run peer-to-peer
>       applications.

I don't think this is a security vs. functionality tradeoff.  address 
translation does little to enhance security, and it's not clear how much 
functionality such a switch could add in any case.  absent explicit 
configuration, a NAPT has no idea how to map addresses for incoming traffic 
where no connection/session state has been established.  a NAT *might* have 
an idea if it is either doing entirely static mapping between two addressing 
domains (I gather this is rare) or if it is already processing some other 
traffic for that host.  a switch might be appropriate for a firewall,
but for a NAT, what would such a switch accomplish?

>     3.1.2. Applications Requiring End-to-End IPSec Will Fail
> 
>       Use of IPSec for end-to-end security will not function in the
>       presence of a NAT implementation. Application designers may want
>       to explore the use of TLS as a mechanism that will traverse NAT
>       cleanly. See [RFC2709] for additional discussion on combining NAT
>       with Tunnel-mode IPSec security on the same device.
> 
>       Some vendors have implemented a pass-through capabilty which
>       permits IPSec tunnel mode from a client in the private realm to
>       communicate with an endpoint in the public realm.
>
>     3.1.3. Use DNS Names, Not IP Addresses In Payload
> 
>       Applications should take care to use fully qualified domain names,
>       rather than IP addresses when referring to IP endpoints. 

again, I would avoid giving advice to application designers.  it's not
always appropriate to use DNS names rather than IP addresses, and 
payloads are not the only issue.  rather, the goal should be to make
application designers aware of the tradeoffs when using IP addresses
vs. DNS names.

Compared to IP routing, DNS lookups are slow, ambiguous, unreliable, 
and prone to misconfiguration.   DNS lookups can often take 30 seconds
or more.  DNS names are routinely used as service names pointing to
several hosts, so a DNS name is less likely to be an unambiguous 
identifier for a host than an IP address.  This also means that 
once two processes in a distributed application have begun communicating
with each other and have established distributed state in particular
processes on particular hosts, a DNS name and port number are not 
sufficient to allow one of those processes to be reached.
Another problem with DNS names is that they are also subject to
multiple layers of translation - due to both proxies and DNS ALG -
so a DNS name is not necessarily less ambiguous than an IP address.
Finally, DNS servers can be attacked in different ways than the routing
system - dependence on on DNS increases vulnerability to attack.

> When
>       endpoints are across a NAT gateway, private addresses must not be
>       allowed to leak to the other endpoint. An example of where this
>       can happen today is with the HTTP and HTML protocols. It is
>       possible for web pages to be specified with numeric IP addresses,
>       rather than with names, for example http://192.168.1.10/index.html
>       could be used as a URL, but would likely create a problem if this
>       address is on a server located behind a NAT gateway. Users outside
>       the gateway would not be able to reach the address 192.168.1.10,
>       and so would not see the page.

http is probably a poor example, even if people are familiar with it.
too many people assume that everything works like HTTP - that other 
applications have (or should have) similar connection lifetimes, 
use TCP, have similar lack of state-sharing between transactions,
etc.
 
>       Further exacerbating the problem is the possibility of duplicate
>       addresses between realms. If a server offers a link with a private
>       address space IP address embedded within it, such as 192.168.1.10,
>       the page referenced may resolve to a system on the local network
>       the browser is on, but would be a completely different server. The
>       resulting confusion to end-users would be significant. Sessions
>       involving multiple NAT implementations would be exceptionally
>       vulnerable to address reuse issues of this sort.

this, I think, is the main point that needs to be made.  the fact that in 
a NATted environment IP addresses are ambiguous is reason enough to be
very careful about  using them.  that doesn't mean, however, that DNS names 
are an acceptable substitute in all cases.

>     3.1.4. Multicast Considerations
> 
>       Not all NAT devices implement multicast routing protocols.
>       Application designers  should verify whether the devices in their
>       networks are able to process multicast traffic if their
>       applications rely on that capability.

how often are application designers the same as the operators of the networks?

in general, it might help to distinguish between two cases for application
design w.r.t. NATs:

- - case where the application is only intended to be deployed in a limited
  environment with known characteristics

- - case where the application is intended to be deployed over the entire
  NAT-extended internet

one of the major contrasts between the pure IP network and the IP network
extended with NATs is that the characteristics of the former are relatively
well-defined and well-known. an application written to work over
IP (or over a service layered on IP) will generally work in the former
environment.  by contrast, a NATted network is not a general purpose network
with well-designed or even entirely predictable characteristics, but instead 
each individual NAT is designed based on assumptions about what kinds of 
applications need to be supported, and often incomplete information about
the needs of those applications.  as such, use of such networks with other 
applications that don't fit the NAT designers' models is always going to be 
a bit chancy.  the purpose of this document is to try to describe what 
NAT designers were assuming.  but there are limitations in doing this
description "after the fact" - different NATs assume different things,
and there are corner cases that cause problems but are hard to pin down.

> 
>     3.1.5. Retention Of Address Mapping
> 
>       With the exception of statically configured NAT bindings,
>       applications should not assume address mapping will be maintained
>       from one session to another. 

you might want to say something about the difference in address mapping
lifetimes between TCP, UDP, and other protocols.

also, the word "session" is used different ways by different folks, and
thus is ambiguous.  the IP stack does not have a session protocol, and
many applications are not based on TCP.  

> An example of this is RSVP, which
>       forms one connection to reserve the resources, then the actual
>       session for which resources were reserved is started. The sessions
>       do not necessarily overlap. There is no guarantee that the NAT
>       implementation will keep the binding association.  As such,
>       applications that rely on subsequent sessions being mapped to the
>       same destination system may not function without an ALG.

I would add a few other recommendations to this section:

1. don't assume that there are only two addressing realms.  in general,
   there can be an arbitrary number of addressing realms, and traffic 
   may traverse any number of NATs between endpoints.

2. don't assume that IP addresses are uniquely tied to a particular host
   or process, or that only one host is using a particular IP address at
   a particular time.  you can lose by making such assumptions even if
   you don't pass the IP address in the payload.

3. don't assume that hosts know their own IP addresses.  similarly,
   don't assume that they know their own DNS names.

> 
>     3.2 Recommendations for NAPT
> 
>       As many of the issues specifically address NAPT issues, this
>       section will group these issues. NAPT is the most common form of
>       NAT in actual deployment in routers, especially in smaller offices
>       and home offices.
> 
>     3.2.1 Realm Specific IP Addresses
> 
>       Avoid the use of IP address and port number information within the
>       payload of packets. While in some cases ALGs will permit such
>       protocols to function, this presupposes every NAT device can be
>       updated in a timely fashion to support a new protocol. Since this
>       is unlikely application writers are urged to avoid addressing
>       information in payloads all together.

I would retitle this section - it invites confusion with RSIP.

as with just addresses, it's not only the use of address+port in payloads
that causes problems.  programs should not assume that address+port is
unique at any given time; they should not depend on well-known ports working;
they should not assume that address+port1 and address+port2 are on the
same host and can be shared by the same process, or access the same files, 
etc.

>     3.2.2 Avoid Session Bundles
> 
>       Independent sessions, such as used by HTTP, are preferred to
>       protocols that attempt to manage a bundle of related sessions,
>       such as FTP.

again, you need to define 'session' or better yet, use a different
word.  if you're talking about tcp connections, say so.

>       In the FTP protocol, port information is passed over one TCP
>       connection and is used to construct a second TCP connection for
>       passing the actual data. Use of a separate connection to transfer
>       the file data makes determination of file end quite simple,
>       however other schemes could be envisioned which could use a single
>       connection.
> 
>       The HTTP protocol, for example, uses a header and content length
>       approach to passing data.  In this model, all data is transferred
>       over the single TCP connection, with the header portion indicating
>       the length of the data to follow. HTTP has evolved to allow
>       multiple objects to be passed on a single connection (thereby
>       cutting the connection establishment overhead). Clearly a new file
>       transfer function could be built that would perform most of the
>       functions of FTP without the need for additional TCP connections.
> 
>       The goal is to keep to single connections where possible. This
>       keeps us from needing to pass addressing information of any sort
>       across the network.

this glosses over a couple of things:

1) multiplexing multiple streams over a single connection is hard
   and there are subtle gotchas that can cause deadlocks

2) HTTP 1.1 does implement multiplexing, but it does it very poorly -
   it should not be held up as an example.

> 
>     3.2.3. Session Bundles Originate From Same End
> 
>       Origination of connections is an important consideration. Where
>       possible, the client should originate all connections. The FTP
>       protocol is the most obvious example, where by default the server
>       opens the data connection to a port on the client (the client
>       having specified the port number via a PORT command over the
>       control TCP session).
> 
>       As pointed out in [RFC1579], the use of the passive open option in
>       FTP (PASV) remedies this situation as the client is responsible
>       for opening the connection in this case. With client-opened
>       connections, the standard functions of NAPT will process the
>       request as it would any other simple TCP connection, and so an ALG
>       is not required.
> 
>       In cases where session bundles are unavoidable, each session in
>       the bundle should originate from the same end station.
> 
>     3.2.4. TCP preferred over UDP
> 
>       NAPT gateways must track which sessions are alive, and flush old
>       sessions. TCP has clear advantages in this area, since there are
>       specific beginning and end of session indicators in the packets
>       (SYN and FIN packets).  

problem is, TCP connection lifetime may not be the same as application
'session' lifetime.  the NAT is assuming they're the same, but they're not.
you might want to add a separate section saying this, which is different
than the issue with UDP.  of course it's well to point out that the 
NAT makes different assumptions regarding lifetime of address bindings  
for TCP than for UDP, but both sets of assumptions are just guesses,
and can cause failures

> While UDP works for some types of
>       applications with NAT, there can be issues when that data is
>       infrequent. Since there is no clean way to know when an end
>       station has finished using a UDP session, NAT implementations use
>       timeouts to guess when a UDP session completes. If an application
>       doesn't send data for a long period of time, the NAT translation
>       may time out.
> 
>       Protocols other than TCP and UDP are workable with Traditional NAT
>       in many cases, provided they are not carrying addressing
>       information.  

this is an overgeneralization - there are many more issues than that.

> For NAPT implementations Use of any protocols other
>       than TCP and UDP should be discouraged.

s/should be discouraged/are unlikely to work/

you might say something about this requiring explicit configuration
when it is possible, and not being possible on all NAPTs.

>       It's important to note that NAT deployments are based on the
>       assumption of a client-server application model, with the clients
>       in the private realm.

and also the assumption that there is a 'inside' vs. 'outside' realm.

but is this true for all NATs?  seems like  an over-generalization.

>     3.2.5. IP Fragmentation
> 
>       Applications should attempt to avoid fragmentation when packets
>       pass over NAPT devices. While not always practical or possible,
>       there are failures that can occur with NAPT. Specifically, if two
>       stations in the private realm pick matching fragmentation
>       identifiers, and talk to the same remote host, it will be
>       impossible to determine which fragments belong to which session.
> 
>       Ideally, applications should limit packet size, use Path MTU
>       Discovery or both.

do NATs universally support PMTU discovery?

>       Some implementations of NAT may implement fragment reassembly
>       prior to Forwarding, however many do not. Application designers
>       are advised to examine the devices they plan to deploy, or to
>       design assuming the devices do not Reassemble fragments.

again, do application designers have any control over the choice of
devices in the network?  they might or might not have any knowledge
of the deployment environment (if it's a limited deployment application)
but will rarely have control or even significant influence.

> 
>     3.3 Issues and recommendations for Basic NAT
> 
>       If only Basic NAT implementations are involved, not NAPT, then
>       many of the issues above do not apply. This form of NAT is not a
>       panacea. 

for that matter, neither is NAPT or any other form of NAT.  but you seem 
to be contrasting NAT with NAPT here and thus implying that NAPT is a 
panacea while NAT is not.  I would just delete this sentence.

> In this case many of the issues still remain, and many
>       protocols will not function correctly without assistance.
> 
>     3.3.1. Use IP and TCP/UDP Headers Alone
> 
>       Applications that use only the information in the IP and TCP or
>       UDP headers for communication (in other words, do not pass any
>       additional addressing information in the payload of the packets),
>       are clearly easier to support in a NAT environment. Where
>       possible, applications designers should try to limit themselves in
>       this area.

this needs a clearer statement.  as written it would appear to mean
(for example) 'use the addresses in the headers for communication rather 
than other information (such as DNS names)'.  clearly you need external
addressing information, if only to get started.  and clearly you sometimes
need other information from these headers.

I think what you want to say is something like: addresses and ports
obtained from the IP, TCP, and UDP headers should only be used for 
sending replies to communications received, and then only for a 
limited time (for TCP, the duration of the connection ; for UDP
it's hard to know what to assume)  

and as I'm fond of pointing out, there are many more hazards than just 
putting IP addresses and/or ports in packet payloads.  so IMHO it's better
to state things in terms of what *can* reasonably be done with addresses
by applications than to say "don't do X".  (and then later "don't do X or 
Y"...and then still later "don't do X, Y, or Z, except on Sundays...")

>       The X windowing system, for example, uses fixed port numbers to
>       address X servers. With X, the server (display) is addressed via
>       ports 6000 through 6000 + n. These map to hostname:0 through
>       hostname:n server displays. Since only the address and port are
>       used, the NAT administrator could map these ports to one or more
>       private addresses, yielding a functioning solution.

I think the lesson here is "don't expect well known ports to work
across NAPTs"  which should be separate from advice about how to
use addresses or ports obtained from IP/TCP/UDP headers.

>       The X example, in the case of NAPT, requires configuration of the
>       NAT implementation. This results in the ability for no more than
>       one station inside the NAT gateway to use such a protocol. This
>       approach to the problem is thus OK for NAT but not recommended for
>       NAPT environments.
> 
>     3.3.2. Avoid Addressing In Payload
> 
>       As with NAPT, transporting IP address and/or port number
>       information in the payload is likely to cause trouble. The IP
>       address and/or port information valid in the realm on one side of
>       a NAT may well be invalid or even refer to different resources on
>       the other side of a NAT gateway.
> 
>     3.4 Bi-directional NAT
> 
>       Bi-directional NAT makes use of DNS mapping of names to point
>       sessions originating outside the private realm to servers in the
>       private realm.  Through use of a DNS-ALG [RFC2694], lookups are
>       performed to find the proper host and packets are sent to that
>       host.
> 
>       Requirements for applications are the same as for Basic NAT.
>       Addresses are mapped one-to-one to servers. Unlike Traditional NAT
>       devices, Bi-directional NAT devices (in conjunction with DNS-ALG)
>       are amenable to peer-to-peer applications.

the last sentence is a gross overgeneralization, as peer-to-peer applications 
do not automatically work over bidirectional NAT.  there are still issues with
address lifetimes and expirations, non-unique host addresses, non-routable
host addresses, etc.  this needs considerably more explanation.

I think you are trying to say that bidi nat devices don't do port translation
and so don't have the set of issues associated with port translations.
but they do still have most of the other issues associated with NATs,
and they introduce a few issues of their own. 

>     3.5 Twice NAT
> 
>       Twice NAT is address translation where both source and destination
>       IP addresses are modified due to addressing conflicts between two
>       private realms. Two bi-directional NAT boxes connected together
>       would essentially perform the same task, though a common address
>       space that is not otherwise used by either private realm would be
>       required.
> 
>       Requirements for applications to work in the Twice NAT environment
>       are the same as for Basic NAT. Addresses are mapped one to one.

I have similar problems with this section as with its predecessor.

> 
>     3.6 Multi-homed NAT
> 
>       Multi-homed NAT is the use of multiple NAT implementations to
>       provide redundancy. The multiple implementations share
>       configuration information so that sessions might continue in the
>       event of a fail-over. Unless the multiple implementations share
>       the same external addresses, sessions will have to restart
>       regardless.
> 
>       Requirements for multi-homed NAT are the same as for Basic NAT or
>       NAPT, depending on how the multi-homed NAT is implemented and
>       configured.
> 
>     3.7 Realm Specific IP (RSIP)
> 
>       Realm Specific IP is described in [RFC2663] and defined in [RSIP]
>       and related documents.  Clients within a private realm using RSIP
>       are aware of the delineation between private and public, and
>       access a server to allocate address (and optionally port)
>       information for use in conversing with hosts in the public realm.
>       By doing this, clients create packets that need not be altered by
>       the RSIP server on their way to the remote host. This technique
>       can permit IPSec to function, and potentially makes any
>       application function as if there were no special processing
>       involved at all.

one problem with RSIP is that it assumes that there are only two realms,
and that all peers of interest are in the 'outside' realm.  at best,
it's like a glorified SOCKS setup - it can provide the illusion of
presence for an application on the public internet but it costs a
lot of complexity and doesn't really address the problems of NAT.
(or for that matter, the problems with the shortage of addresses)

>     3.8 Performance Implications of Address Translation Implementations
> 
>       Resource utilization on the NAT gateway should be considered.  An
>       application that opens and closes many TCP connections, for
>       example, will use up more resources on the NAT router than an
>       application performing all transfers over a single TCP connection.
>       HTTP 1.0 opened a connection for each object on a web page,
>       whereas HTTP 1.1 permits the TCP session to be held open for
>       additional objects that may need to be transferred. Clearly the
>       latter imposes a lower overhead on the NAT gateway, as it is only
>       maintaining state on a single connection instead of multiple
>       connections.
> 
>       New session establishment will typically remain a software
>       function even in implementations where the packet-by-packet
>       translation work is handled by hardware forwarding engines. While
>       high-performance NAT boxes may be built, protocols that open many
>       sessions instead of multiplexing will be slower than those that do
>       not.
> 
>       Applications with different types of data, such as interactive
>       conferencing, require separate streams for the different types of
>       data.  In such cases the protocol needs of each stream must be
>       optimized. While the goal of multiplexing over a single session is
>       preferred, clearly there are cases where this is impractical.
> 
>       The latency of NAT translation overhead is implementation
>       dependent. On a per-packet basis, for established sessions only
>       the source or destination IP address is replaced, the source or
>       destination port (for NAPT) and the checksums for IP, and TCP or
>       UDP are recalculated. The functionality can be efficiently
>       implemented in hardware or software.
> 
> 4. Security Considerations
> 
> 
>    Network Address Translators have implications for IPSec, as noted
>    above.  When application developers are considering whether their
>    applications function with NAT implementations, care should be given
>    to selection of security methodology. Transport Layer Security (TLS)
>    [RFC2246] operates across translation boundaries. End-to-end IPSec
>    will prove problematic in many cases.

there are other security considerations, especially because NATs 
impair the ability of IP addresses to be used for trace information.

Keith

------- End of Forwarded Message

_______________________________________________
nat mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nat

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Apr 2001 13:10:36 -0400

[sorry this is so long. I've tried to omit sections of the original
message where we seem to have agreement, but it's still long.]

> I wasn't sure there was a need to spell this out. Also, other documents
> from the NAT WG give the details of what doesn't work. 

which ones?  Tony Hain's document talks about architectural issues
but not generic application design issues. RFC 3027 section 2 talks 
about such issues in a very general fashion - it describes kinds
of applications that are likely to break but does not really
describe protocol designs or implementation techniques that are 
likely to break.

> If you have
> specific suggestions in this area not covered by the other documents,
> please elaborate.

well, that's why I had started to work on my own document.  your
document covers much of the same territory; but while it recommends
certain design choices it doesn't say much about what design choices
won't work, or what problems cannot be worked around in the presence
of NATs.  I think it would be good to have the information about NATs
that application protocol designers and implementers need to know
in a single document.

> How about:
>  "All of those relate to various issues with the NAT mechanism, it's
> effects on existing protocols, and general effects on Internet
> architecture."
> 
> or something along those lines?

sounds good.

> How about "provide recommendations to" replacing "instruct"
> (with appropriate grammatical fixes to the rest of the sentence)?

maybe.  but I think it more appropriate for this document to inform the 
application designer or implementor as to the consequences of certain 
design or implementation choices than for this document to simply 
provide recommendations.  it's better to get the designer/implementor to 
understand the tradeoffs than simply to say "do it this way"

> Possible solution: change "can still" to "can, in some cases"?

fine.

> I can come up with some additional words to capture this thought.
> Certainly it's possible to design protocols such that they will be
> ALG-friendly, the concern generally has been there is no commonality,
> thus the chances of getting an ALG into a sufficient population of
> NAT boxes could be a problem. 

difficulty in deployment is one problem with ALGs.   but more generally,
proxies of all kinds (ALGs included) tend to cause problems with protocols - 
adding additional sources of failure or data corruption, and masking the
sources of failures (whether caused by the proxy or some other party).
this is especially true if the protocol was not originally designed
with proxies in mind and they were retro-fitted later.  

I think it would take a while to try to capture what is really needed 
for "firewall/ALG/proxy-friendly protocol design"  and I wasn't suggesting
that you try to do so in this document.  the point I was
trying to make is that if you're designing a protocol that is going
to require proxies (due to the anticipated presence of NATs or firewalls 
or whatever) you should make the proxy part of the design, rather than
expect a NAT or firewall vendor to figure out how to let your protocol
work through their devices with the necessary filtering/translation but
without disrupting authorized uses.  we've seen numerous examples of 
application failures caused by naive proxies.

> Which leads us to your next comment:
> 
> I agree such a "generic ALG" mechanism could be quite useful. While
> there'd still be an inertial element (i.e. getting such a thing
> deployed into sufficient numbers of NAT boxes) it would provide a
> MUCH better solution in a great many cases to the smattering of
> ALGs out there. The document we're discussing here is NOT the place
> for this to be designed, however. I'd be happy to discuss that
> idea separately.

sorry, that was just an aside comment.  I have been working on proposals 
for this, but we should discuss them in a different context.
 
> Again, I'd like to refrain from this. ALG design is something which
> could be better documented, but I hesitate to put that into this
> document. Given the timeline to implement and deploy ALGs, I still
> prefer to see protocol developers asking themselves how they might
> fit in with the presently-deployed devices, and only thinking
> about designing ALGs as a last resort.

on reflection (see above), I think you're right.  for now it should be
sufficient to say that folks who write applications that need ALGs/proxies
should (a) realize that this will impact deployability and 
(b) design the protocol with ALGs/proxies in mind and document how those
ALGs/proxies interact with other components.

> >From the implementations I've done of both, I think there's more in
> common than not. They both are mechanisms which generally perform
> stateful inspection of packets passing them. The NAT case adds the
> extra step of modifying packets, but otherwise is VERY similar.

I can easily see how implementation of a NAT and implementation of a firewall
would be quite similar.  But I don't think this is the same thing as saying
that designing an application to deal with the presence of NATs is the same 
thing as designing an application to deal with the presence of firewalls.
A NAT is something that translates addresses; a firewall is something
that attempts to enforce administrative restrictions on some kinds of 
traffic while transparently allowing other traffic to pass.   Behavior
of firewalls varies considerably from one installation to another.
Some block ports, others block SYN packets in one direction, others impose
interception proxies in an attempt to filter content that might appear
within an application protocol's payload, some require outside packets
to be authenticated via IPsec, and there are far more sophisticated
approaches than these.  Nor do firewalls inherently operate in one 
direction. Some academic institutions have inward-facing firewalls to 
prevent their students from mounting certain kinds of attacks to other
sites.

Since it's a firewall's job to block and/or filter certain kinds of traffic
without interfering with other kinds of traffic, a firewall-friendly 
protocol is one which makes the firewalls's job easy - it makes it 
easy to correctly distinguish between prohibited and permitted traffic 
and easy for the firewall to filter the traffic.  (A firewall-friendly
protocol is NOT one which circumvents firewalls, no matter what the 
"let's run everything over HTTP" folks think, because that just makes
the firewall's job harder and more error-prone.)

Different sites have different threat models, so they choose to prohibit
different kinds of traffic in order to protect their security interests
as they define them.  The prohibitions thus imposed may or may not 
be similar to the kinds of prohibitions imposed by NATs.  A NAT-compatible 
protocol might still be administratively prohibited by a firewall; and
a firewall-friendly protocol might still be incompatible with NATs.

> I'll see if I can reword this a bit. Perhaps replacing "It should be
> possible" with "In many cases, is possible" or something similarly toned
> down?

"many" is fine.  ("most" would be stretching it too far.)

> It is based on the present market conditions observed. Those who CAN
> get broadband at all (assuming their carriers haven't gone out of
> business yet) are either not offered options for multiple addresses
> (this was perhaps more true at the time those words were originally
> written) or are offered a VERY limited set (like 3 in the case
> of ATT Broadband in New England, all delivered over DHCP).

fine, but you made a statement about "technologies" not about "market
conditions".  many of the same ISPs that will sell you a broadband
connection with a single dynamic address will also sell you (for a 
different price) a broadband connection with a static subnet that
uses the same underlying technology.  they might have to provision 
things differently in order to provide the latter service, but 
that's no different than any other bearer technology.

> I agree completely it's a marketing decision. It's also spawned an
> industry... 

...and has arguably damaged other industries, like the folks making
distributed games, conferencing systems, internet telephony, etc.  

we'd all be far better off with an Internet that supported *both* 
plug-and-play configuration for hosts and leaf nets *and* large-scale 
distributed applications... and under those conditions would be an 
even greater market for autoconfiguring home/small office network hubs.

but I digress.

> I'd like suggestions on how to capture the reality of a marketplace
> where marketeers have imposed this issue, and where market forces
> make it a preferred solution for the average home user.

1. call it marketplace reality instead of technology
2. realize that such marketplace realities are subject to change very
   quickly - perhaps even shorter than technologies.   "current"
   marketplace conditions do not necessarily serve as good predictions
   for the future. 

> In the case of PPPoE, to which you allude, it's HIGHLY preferable to
> insert an appliance box between computer and DSL modem and have it
> do the PPPoE, rather than have to load PPPoE software onto the user's
> PC (I've talked non-technical family members through both. The PPPoE
> software provided by one ISP for Windows did a nice job of manglng
> the system. Outboard boxes which can simply be unplugged win hands
> down).

(actually I wasn't alluding to PPPoE, I was alluding to some of the
protocols used in cable modems and which were proposed for cell phones
that assign an IP address to each set-top-box/phone and then treat 
that IP address as link-layer address)

> > designers.
> The barriers are primarily documented in RFC 3027. I was trying NOT to
> repeat that document here. The goal was to have only enough to explain
> the recommendations.

3027 doesn't really document the barriers; it just describes some kinds
of applications that don't work well in the presence of NATs.  A designer 
or implementor could look at 3027 and avoid the pitfalls that it mentions
and still quite easily end up with an application/implementation that 
would not work in the presence of NAT.

> >  The reason is that every application is different.  Your
> The document should recommend the things that are most likely to work.
> Implementers may choose to ingore the recommendations. If they
> understand the reasons for the recommendations, they will be more
> likely to design with their eyes open, and understand the limitations
> they may face. I'm not sure there's a need for rework in this area.

The reason I press on this is that readers sometimes lose sight of the
context in which an RFC is written.  If an RFC (even an informational
one) says "you should do X" then far too many pointy-headed managers 
will treat that statement as absolute rather than considering the
implicit "if you want to be compatible with NAT".   If on the other 
hand an RFC says "X is more compatible with NAT than Y" the potential for 
misunderstanding is considerably diminished.

> "server" means it's serving a connection point, at least to me.

I don't think that meaning is universally accepted.  Folks think of
servers as things that provide services to clients or users, and/or 
things that require significant provisioning; neither of which
necessarily means that TCP connections are always initiated by clients
and accepted by servers.  In SMTP, MTA A can contact MTA B for the
purpose of receiving mail that is routed from B to A; which one is the 
"server" in this case?

I think it's therefore less ambiguous to say "a protocol engine that 
accepts incoming connections" than "server".  or if you need a shorthand,
how about "initiator" and "listener"?

> The underlying issue being written about here is how the state table in
> the NAT is implemented. In the implementations I've been involved
> with, the code ALWAYS tracks the tuple of (outside address, outside
> port, inside address, inside port). This means each packet is carried
> to across the NAT only if an association is established which covers
> those 4 variables. If one makes a UDP connection out to one outside
> address, and a response comes from another outside address, it is
> dropped. This is the same as a stateful inspection firewall would
> do. An interactive gaming software publisher noticed that on SOME
> boxes implementing NAT, they use only (outside port, inside port,
> inside address) as the mapping criterion for UDP. So, a connection
> out to one address outside creates the opportunity for ANYONE
> outside who learns of the outside port number to send traffic to
> the system which originated the original communication. The reason
> this was interesting for gaming is it'd allow a UDP connection to
> a server somewhere to be used for setting up a redez-vous of sorts.
> The server could tell another gamer, over a TCP session that they
> can now connect to the user behind the NAT by connecting to the
> outside port known to the server. I hope I explained all that clearly...

makes sense.  but one should be careful about claiming that NATs enhance
security...many regard this as a fairly marginal or even dubious benefit. 
 
> There are many ways to implement NAT and NAPT functionality. I believe
> this is the root cause of the frequent arguments over whether NAT
> boxes act as firewalls. The way some are coded, they ARE firewalls
> which happen to do NAT as a part of their operation, but that's not
> what the marketing people stressed when selling the product. 

true.  if a NAT happens do to what you want a firewall to do, then you
don't need a separate box.  and if you are designing a NAT, it is not 
hard to do so in such a way that it's easy to add some firewall 
features (just as routers often have some firewall features).  and yet 
NAT and firewall are conceptually different functions that happen to 
share some common kinds of processing internally.  it's not wise for
an application designer to assume that they're the same thing.

> > again, I would avoid giving advice to application designers.
> 
> I don't want to sound flip, but that's kind of the point of this
> document.

I think it would be better if the document were to inform application
designers of the consequences of certain design decisions and leave the 
decision-making to them.

> Would it work better if the line said: "Applications should, where
> possible, use fully-qualified domain names rather than IP addresses
> when referring to IP endpoints"? 

not much better.  it would be better to say something of the form
"FQDNs are more compatible with NATs than IP addresses". or perhaps:

] NATs separate the network into multiple addressing realms; an IP 
] address from one addressing realm may be assigned to a different host
] in a different addressing realm.  For this reason applications which
] use IP addresses as endpoint identifiers are unlikely to work properly
] over a NATted network.  Such applications MAY be able to employ DNS 
] names (rather than IP addresses) as endpoint identifiers; however 
] this generally requires that all DNS names be fully-qualified, that 
] the servers for those DNS names (and their delegation paths) be reachable 
] by all hosts which need to resolve those endpoint names, and that each
] participating host be aware of its fully-qualified DNS name.  This
] is unfortunately often not the case.  In addition it should be realized
] that DNS lookup is slower and less reliable that native IP routing.
] Nevertheless, use of DNS names as endpoint identifiers may permit
] an application to work in a NATted network when it could not do so
] otherwise.

> >  it's not
> CLEARLY there are times when using DNS names is not appropriate.
> 
> > 
> All fine arguments for creating a host identity payload, of course.

or for using a non-segmented address space.  there are other tradeoffs
involved with a separate host identity which are only beginning to be
evaluated by some of the proponents of that approach.  (if you separate
the two then you need a mechanism to maintain the binding between the
two and perform translations when necessary; and you really need something
faster and more reliable than DNS for this) 

> I don't agree with the lookup time issues, though. If two hosts are
> already communicating over one channel of some sort, they've probably
> also done a DNS lookup on each other. 

not a safe assumption.  I know of distributed systems that do an address
lookup once, for each of hundreds of hosts or more, from a single point 
on the network.  then they distribute that address table to all 
particiapting hosts.  additional hosts may join or leave the computation,
but the computation can continue for weeks or months or even indefinitely -
certainly far longer than typical DNS TTLs.  they can tolerate failures
of individual hosts and partitioning of the network but they quite 
reasonably expect hosts to have stable IP addresses.

> Their local name servers ARE likely to cache that information for at 
> least a short while. 

nope, that's an unwarranted assumption.

> Actually, web servers tend often to have LOTS of state information kept
> between transactions, however it's necessarily carried in the form of
> IP addresses.

I hope they don't use IP addresses very often; this strategy would fail 
immediately for client machines supporting multiple users (either sequentually
or in parallel).   In my experience cookies, or URL fragments, or hidden 
variables in forms are more likely to be used as state tags than IP
addresses.

> Agree. A valid alternative, where transactions are interacting with a
> common server, is the use of short-lived nonces, cookies or whatever 
> you want to call them (cookies, unfortunately, have troublesome 
> connotations in the web world, and I'm NOT talking about things that 
> get stored long-term).

if you just need some short-term state tag (or transaction demultiplexer,
whatever) then this works fine.  (modulo privacy concerns, of course)

if you need a long-term stable endpoint identifier then it may be that
neither IP addresses (due to NATs) nor DNS names (due to inherent
reliability and speed problems as well as issues with typical configurations)
will suffice.

> Only sometimes. In practice, perhaps rarely. Presenting this information
> will, perhaps, help application designers understand that they'd have to
> control everything if they really wanted their ALG-hungry protocol
> deployed
> in short order.

perhaps a slight rewording would help here.  e.g.

in general, application designers should not depend on multicast facilities 
unless they can determine that their target environments support them.
this is true regardless of whether NATs exist in that target environment.

(sad but true)

> see comment above. I guess I expected this would dawn on folks reading
> the document.

perhaps.
 
> > environment.
> This is true, depending on the definition of "work".
> 
> >  by contrast, a NATted network is not a general purpose network
> Absolutely. I guess the question is, what more do I need to say to spell
> this out? If people read this section and say "but I don't control what
> NAT box a home user buys," they may start to understand. For those lucky
> few who CAN control the deployment environment, they'll have some food
> for thought.

maybe include something like the above in the introductory text, to set 
context for the rest of the document.

> These are rather dependent on implementation, and in some cases (I wish
> all cases) adjustable by the maintainer of the box.

so perhaps it should be stated. e.g.

] Different NATs make different assumptions about the lifetimes of 
] address bindings, and for a given NAT these are often different between 
] TCP and other IP-based protocols.  Thus a NAT may maintain a binding 
] between an internal and external address for less time than an 
] application expects.  Many NATs assume that TCP address bindings need 
] not last longer than a single TCP connection.  For UDP the behavior is 
] even less predictable.  Some NATs allow adjustment of the lifetime of 
] the binding assumed by the NAT; others do not.

> Association? Binding? Mapping? Any suggestion of what word to use?

TCP connection.  and this helps make it clearer that behavior of a
NAT regarding TCP doesn't necessarily apply to UDP, SCTP, RTSP, etc.

> I'll see what I can do. Anyone have suggestions? RSIP is called that for
> the same reason as this section is, but I agree it'd be good to avoid
> confusion.

on reflection, there's already some precedent for the term
"realm specific IP address" so maybe it's better to be consistent
with that precedent even though it could be confusing witb RSIP.
it might be more confusing to change terminology.

> Most definitely we're NOT talking just about TCP here. It could be any
> prototol. The issue is one of multiple associations of ports and
> addresses
> between two endpoints, all part of some particular communication. Do we
> have any standardized term for this? I'm not aware of one. I use session
> here to mean an ongoing communication between two hosts. A session
> bundle
> is a collection of sessions which are related.

then perhaps the thing to do is define what you mean by "session" 
in this context to make it clear that you're not simply referring
to TCP connections.

> Do you have a better example? I'd rather point to something (even if
> it's not the best of implementations) than nothing.

maybe BEEP?  I haven't followed it recently but I think they were trying
hard to do a better job of multiplexing than HTTP.

> Stateful inspection firewalls do the same things, and cause the same
> troubles. 

true.  but that doesn't mean they're not also caused by NATs.

> I would be open to adding more text here, but could use some
> suggestions on what to say.

I think you should point out not only that TCP is preferred over UDP,
but that applications using TCP shouldn't assume that the address binding
lifetime will be maintained (a) beyond that of a single TCP connection 
and (b) during substantial periods of inactivity on that connection. 

> Clearly. However, the most common UDP-using protocol, DNS, works just
> fine across most every NAT/NAPT ever built. I don't want to just come 
> out and say "don't use UDP" as that is neigher necessary nor accurate. 
> Another common UDP-based protocol, NTP, also does quite well with NATs.

there's a common :) assumption that only the most common protocols are
commonly used.  in reality there are many uncommon protocols in use.
none of these protocols may be widespread, but the use of uncommon protocols
in general *is* widespread.  thus the fact that a NAT behavior doesn't
inhibit the most common protocols doesn't mean that it's not a pain :)

but I digress again... mainly I was objecting to the "provided they are 
not carrying address information" part.  having just listed the issues
associated with NAPTs and TCP/UDP it would be indeed be tedious to re-list
all of same the issues which also applied to NATs and other IP-based 
protocols.  but just saying "things that don't carry addressing 
information" doesn't serve the reader either.  I'm not sure what to 
recommend here.

> Unless or until someone adds support. SCTP should work with NATs
> once it gets deployed and people add support for it.

again, I'm trying to avoid wording that some pointy-haired boss might use 
as justification to outlaw a protocol based on SCTP.
 
> I'll try to reword this section to make it clearer. I don't want 
> to get into discussions of what some implementations do vs. others.

I certainly wouldn't want to mention specific implementations, but
where there are significant variations in NAT behavior that would
affect application writer's design decisions, it does seem useful
to mention them. 
 
> Even in multi-port cases (e.g. LinkProof) there's still an "inside" and
> an "outside". From the perspective of any single NAT box, there's an
> assumption of two realms. Can you come up with an example that's 
> different from that?

I guess I'm thinking of multiple private networks tied together by NATs,
where there's no private-vs-public sides, there are two (or more) private 
sides.  also, even if from a NAT's point of view the world is divided into
only two regions, from an application's point of view this is not necessarily
the case.

> Good reason to not rely on it, eh? Application designers would be better
> off having their applications fire around 1000 byte packets than 5000
> byte fragmented packets. What shall I say here? If an application
> designer insists on using moster packets, they'll get into trouble
> in some environments. I think enough is said here for them to figure
> it out.

I would simply say 

Application designers should not assume that NAT devices will 
reassemble fragmented IP packets.

> I was thinking more along the lines of, don't use addressing info at
> all.
> You have a "connection" open, so just use it. Stick with a single
> "connection."

but it's simply not true.  you don't always have a connection, and
even if you do, you don't always have a single connection.  
you may need to recover from NAT failures or other disruptions.

> Well, no, it's "don't expect well known ports to work when crossing
> a NAT from the 'outside' to the 'inside'" I think.

right, but it gets tricky to explain that.  even parts of the
application that are always "outside" of a NAT need to be designed
with NATs in mind, but there are things you can do in a component
that knows it is on the outside of all NATs (essentially, on the
public Internet) that cannot be done on the inside of a NAT.

> I agree with your comments. How much of them shall I add to this
> section?

I recommend saying that application interaction with RSIP is for further
study and for other documents, should someone care to write them.

> The trace issue is appropriate for a different document. I don't see it
> as significantly affecting application designers' choices.

hmm.  since this document is about the impact of NATs on applications
design it probably makes sense for the security considerations section
to mention the impact of NATs on the security of such applications.
general security considerations of NATs are prsumably documented elsewhere.

however I think that tracing does (or at least should) impact application 
design choices  - both in the security sense of tracking down miscreants 
and in a more general sense of network/application management.  designers
don't consider such aspects nearly often enough, but they should do so
more often.

for instance, applications designed to run over NAT might do well to
insist on strong authentication from users and also to be immune to
denial-of-service attacks - since IP addresses are now useless for 
identifying the source of attacks.

Keith