[NAT] Re: comments on draft-ietf-nat-app-guide--5.txt

Daniel Senie <dts@senie.com> Fri, 13 April 2001 21:22 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18809; Fri, 13 Apr 2001 17:22:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25714; Fri, 13 Apr 2001 17:19:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25627 for <nat@ns.ietf.org>; Fri, 13 Apr 2001 17:14:49 -0400 (EDT)
Received: from garlic.amaranth.net ([216.235.243.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18638 for <nat@ietf.org>; Fri, 13 Apr 2001 17:14:46 -0400 (EDT)
Received: (from dts@localhost) by garlic.amaranth.net (8.11.1/8.11.1) id f3DLElX11416 for nat@ietf.org; Fri, 13 Apr 2001 17:14:47 -0400
Date: Fri, 13 Apr 2001 17:14:47 -0400
From: Daniel Senie <dts@senie.com>
Message-Id: <200104132114.f3DLElX11416@garlic.amaranth.net>
To: nat@ietf.org
Subject: [NAT] Re: comments on draft-ietf-nat-app-guide--5.txt
Sender: nat-admin@ietf.org
Errors-To: nat-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Network Address Translation <nat.ietf.org>
X-BeenThere: nat@ietf.org

Interspersed below are my reply comments to Keith. He makes several
good points, and I will incorporate many of them. I'd like to hear
discussion in several areas. Due to the length of Keith's message,
and this message, please don't quote this entire message in your
discussion (unless commenting on everything).

Dan

Keith Moore wrote:
> 
> 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: dts@senie.com
> Subject: comments on draft-ietf-nat-app-guide-05.txt
> cc: moore@cs.utk.edu
> From: Keith Moore <moore@cs.utk.edu>
> 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.

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. If you have
specific suggestions in this area not covered by the other documents,
please elaborate.

> 
> > 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'

Agree. Word choice was in response to the original few drafts of the
document which became RFC 2993.

> 
> >    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.

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?

> 
> > 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'

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

> 
> >    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 :)

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

> 
> 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.
> 

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. Which leads us to your next comment:

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

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.

> 
> > 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.

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.

> 
> >    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.

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.

> 
> 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.

OK. We'll have to discuss this one further. I'll see if I can come up
with some wording that captures my thoughts on this, while meeting
your concerns.

> 
> > 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.

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?

> 
> > 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;

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).

> 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.

I agree completely it's a marketing decision. It's also spawned an
industry... Linksys sells a box at just over $100 that's a NAT box
with one 10/100 port toward the DSL or Cable modem, and either a
single port or a small 10/100 switch on the customer side. This
set of products are some of the hottest selling in the marketplace.
It's also a lot easier to sell to the consumer, rather than trying
to explain how to program a router to handle a small subnet, or
how to set up a firewall to still permit DHCP for each device behind
the firewall.

> 
> (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)

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.

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).

> 
> > 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 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.

>  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.

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.

> 
> > 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.

I'll try to reword this as you suggest. The firewalls vs. NAT issue:
think about what a firewall must do to implement FTP properly. Now
think about what a NAT implementation must do. The code is amazingly
similar, with the only significant difference coming in the area of
packet modification. ALL of the stateful inspection is the same.
I can be convinced to remove all such information from this draft,
but am not convinced that will be beneficial to readers of the
resultant document.

> 
> >    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)

Interesting idea. I'm not entirely sure I agree with the order given,
but OK. Any thoughts from other WG folks?

> 
> >    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?

"server" means it's serving a connection point, at least to me.
I care not whether the machine acting as a server is my cell phone,
or a rack-mounted machine in a colo. Do we have some proper
terminology which could be employed to talk about a machine
listening for a connection vs. a machine initiating a connection?
While peer-to-peer machines can do both at the same time, the
problems often arise from trying to initiate the connection to
the machine attempting to act as "server" (i.e. listening) who
may not hear that connection arrive due to the lack of a
mapping in a NAT box.

> 
> > 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.

Many deal with timeouts and refresh timers based on observing traffic.
I have not recently come across an implementation which fails to
handle UDP. I expect there are some.

> 
> 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?

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...

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. Other NAT
boxes simply do translation, while not doing much packet inpection.
The text above tries to point out that the methodology for
implementation of NAPT can affect applications.

> 
> >     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.

I don't want to sound flip, but that's kind of the point of this document.

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"? I'm willing to soften this, but other
than pointing out a major weakness in the IP protocol stack (lack of
a way to identify a host, as opposed to an address), what do you
suggest?


>  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.

CLEARLY there are times when using DNS names is not appropriate.

> 
> 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.

All fine arguments for creating a host identity payload, of course.

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. Their local name servers ARE
likely to cache that information for at least a short while. The
applications themselves also can do such caching, and some do (and
some do it badly, such as some web browsers).

> 
> > 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.

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.


> 
> >       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.

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).

A nonce or handle, passed between systems and valid for a short duration
permits end stations to agree they're continuing a discussion from another
transaction, or at least a relationship from another transaction.

> 
> >     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?

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.

> 
> 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

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

> 
> 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.

This is true, depending on the definition of "work".

>  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.

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.

> 
> >
> >     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.

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

> 
> 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.

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

> 
> > 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.

A good point.

> 
> 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.

Also good.

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

Again, a good item.

> 
> >
> >     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.

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.

> 
> 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.

Good points.

> 
> >     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.

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.

> 
> >       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

Very true.

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

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

> 
> >
> >     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

Stateful inspection firewalls do the same things, and cause the same
troubles. I would be open to adding more text here, but could use some
suggestions on what to say.

> 
> > 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.

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.

> 
> > For NAPT implementations Use of any protocols other
> >       than TCP and UDP should be discouraged.
> 
> s/should be discouraged/are unlikely to work/

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

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

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.

> 
> >       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.

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?

> 
> >     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?

I found at least one NAT/Firewall box that destroyed it. Others do it
just fine. The question is whether to consider the failure case I saw
as a bug that might get fixed, or something endemic to NAT? There's
no problem getting this functionality right. I'm not sure it's worthwhile
to ask about "universal" support, in that it would seem most every product
will have a bug or limitation somewhere. Hopefully, with the output of
the NAT WG, implementations will implement NAT with greater commonality.

> 
> >       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.

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.

> 
> >
> >     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.

I'm open to that.

> 
> > 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)

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."

> 
> 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.

Well, no, it's "don't expect well known ports to work when crossing
a NAT from the 'outside' to the 'inside'" I think.
> 
> >       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.

I'll ask Suresh to respond to this, as I think this wording came from
a discussion with him. I have no strong opinion on this matter, and
am quite open to suggested wordings.

> 
> >     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.

Same comment as my previous comment.

> 
> >
> >     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)

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

> 
> >     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.

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

--
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com


_______________________________________________
nat mailing list
nat@ietf.org
http://www.ietf.org/mailman/listinfo/nat