Subject: (NAT) Comments on draft-iab-nat-implications-08.txt

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 20 Jul 2000 07:23:56 -0700 (PDT)

Tony,

Some general comments.

        1. There seem to be lot of spurious characters - Italicized "AE".
           "u^" spread throught the text. 

	2. As an architectural document, I believe, you should have a 
           section citing the limitations of NAT - topological limitations
	   or what have you, architecturally speaking. For example, NAT 
           function should be run on a border router unique to a stub 
           domain, where all packets either originate from the domain 
           or are destined to the domain.

           I dont know, if you meant "Scope" (section 3) to be that. It 
           certainly doesnt come across that way. The closest observation
           I found was a sentence in the last paragraph of "Introduction" 
           (section 1) which states that a NAT device should not be 
           viewed as a simple router replacement. 

	3. I appreciate your concern about misleading marketing
           literature, implementation errors/violations and 
           misconfigurations with respect to some NAT deployments. 
           However, I find it misleading to mention these in the same 
           tone as NAT functionality to illutrate disadvantages. 

Below are my detailed comments.

regards,
suresh

> 1.  Introduction 
<... stuff deleted>     

>     
>    The architectural intent of NAT is to divide the Internet into 
                                           ^^^^^^
Just the opposite. The intent of NAT is to bridge independent 
address realms. NAT doesnt create the realms. The realms are already
there. NAT is used to bridge them.

<... stuff deleted>
>    addresses were guaranteed to be ambiguous. For example, when NATs 
>    are inserted into the network, the process of resolving names to or 
>    from addresses becomes dependent on where the question was asked. 
>    The result of this division is to enforce a client/server 
>    architecture (vs. peer/peer) where the servers need to exist in the 
>    public address realm.
   
The last sentence sounds like a non-sequitor to me. How does one infer
this from the previous sentence? I can have Bi-directional NAT and 
still have peer-to-peer architecture between realms. What is the problem?

<... stuff deleted>
>    NAT devices (particularly the NAPT variety) undermine most of these, 
>    basic advantages of the end-to-end model, reducing overall 
>    flexibility, while often increasing operational complexity and 
>    impeding diagnostic capabilities. 

It must be noted here that there is a paradigm shift in IP networking 
in today's world. Stateful managment of end-sessions within the network
is a trend being pursued with policy based security gateways, web-caching
devices, QOS enforcement devices, firewalls and Network Address Translators. 
A basic property/requirement of the stateful networks is that packets 
pertaining to a session traverse the same node in both directions.

Further, stateful networks do require carefully orchestrated 
network topology to ensure the networks are operational. While you 
mention this as a undesirable consequence of NAT deployment, you do
not mention other elements that also contribute to the statefulness 
in networks in the same breath).

<... stuff deletd>
> 2.  Terminology 
>     
>    Recognizing that many of these terms are defined in detail in RFC 
>    2663 [3], the following are summaries as used in this document.  
>     
>    NAT - Network Address Translation in simple form is a method by 
>    which IP addresses are mapped from one address administration to 
>    another. The NAT function is unaware of the applications traversing 
>    it, as it only looks at the IP headers. 
>     
>    ALG - Application Layer Gateway: inserted between application peers 
>    to simulate a direct connection when some intervening protocol or 
>    device prevents direct access.  It terminates the transport 
>    protocol, and may modify the data stream before forwarding.

ALG does not terminate the transport protocol. A Proxy does.
      
<... stuff deleted>
>    Firewall - access control point that may be a special case of an 
>    ALG, or routing filter. 

Firewall is not a special case of an ALG, or a routing filter.
By routing filter, did you mean one that filters routing PDU content
or one that filters data papckets?
     
>    Proxy - Special case of an ALG that is a simple relay service 
>    designed into a protocol, rather than arbitrarily inserted. 

I dont understand this definition. As far as I can tell, Proxy terminates
a session. One of the application ends know about the existence of Proxy
enroute. This unlike an ALG.
 
<... stuff deleted>
 
> 6.  Problems with NATs 
 
>    While RSIP addresses the transparency and ALG issues, for the 
>    specific case of an individual private host needing public access, 
>    there is still a node with state required to maintain the 
>    connection.  Dynamic NAT and RSIP will eventually violate higher 
>    layer assumptions about address/port number reuse as defined in RFC-
>    793 [10] RFC-1323 [11]. The TCP state, TCP_TIME_WAIT, is 
>    specifically designed to prevent replay of packets between the 4-
>    tuple of IP and port for a given IP address pair. Since the TCP 
>    state machine of a node is unaware of any previous use of RSIP, its 
>    attempt to connect to the same remote service that its neighbor just 
>    released (which is still in TCP_TIME_WAIT) may fail, or with a 
>    larger sequence number may open the prior connection directly from 
>    TCP_TIME_WAIT state, at the loss of the protection afforded by the 
>    TCP_TIME_WAIT state. 

This is a problem only when implementations recycle port numbers without
a wait time. This is not the recommended practice. Please refer 
section 2.6 of RFC 2663.

<... stuff deleted> 

>    In particular, it is sometimes erroneously believed that NATs serve 
>    to provide routing isolation.  In fact, if someone were to define an 
>    OSPF ALG it would actually be possible to route across a NAT 
>    boundary. Rather than NAT providing the boundary, it is the 
>    experienced operators who know how to limit network topology that 
>    serve to avoid leaking addresses across a NAT. This is an 
>    operational necessity given the potential for leaked addresses to 
>    introduce inconsistencies into the public infrastructure. 

By the very nature of address realms, and the NAT devices that support
them, there are restrictions on routing advertisements (refer section 4
in RFC 2663). So, why would you want to do an OSPF-ALG? It is technically
possible to do an OSPF_ALG, only if you had one-to-one static address 
mapping for all routing nodes and the subnets they support. In such a 
case, why would you have leaked addresses?

<... stuff deleted>
>  7.3. TCP state violations 
>    Host A completes its transaction and closes the web service on TCP 
>    port 80, and the RSIP releases the public side address used for Host 
>    A.  Host B attempts to open a connection to the same web service, 
>    and the NAT assigns then next free public side address which is the 
>    same one A just released.  The source port selection rules on Host B 
>    happen to lead it to the same choice that A used.  The connect 
>    request from Host B is rejected because the web server, conforming 
>    to the TCP specifications, has that 4-tuple in TIME WAIT for 4 
>    minutes.  By the time a call from Host B gets through to the 
>    helpdesk complaining about no access, the requested retry will work, 
>    so the issue is marked as resolved, when it in fact is an on-going, 
>    but intermittent, problem. 

How is this different from dynamic IP address assignment strategies
pursued by remote Access devices and DHCP servers?

<... stuff deleted> 
>     
>  7.4.  Symmetric state management 
                                   
>    To preserve a consistent view of routing, the best path to the 
>    Internet for Routers 1 & 2 is via NAT1, while the Internet is told 
>    the path to the address pool managed by the NATs is best found 
>    through NAT1. When the path X1 breaks, Router 2 would attempt to 
>    switch to NAT2, but the external return path would still be through 
>    NAT1. This is because the NAT1 device is advertising availability of 
>    a pool of addresses. 

So is NAT2. Depending upon the address block provides by the 
respective ISPs, NAT1 and NAT2 would be advertising different 
address blocks. I believe, there was a draft some time back from
Praveen and Yakov on the subject - describing the opposite view
point - i.e., benefit of multihoming with NAT devices. Sounds like,
it is a matter of configuring the device correctly. 

>                          Directly connected routers in this same 
>    situation would advertise the specific routes that existed after the 
>    loss. In this case, redundancy was useless.  

I dont understand what you say about directly connected routers. 
Could you elaborate?
 
>     
>    Consider the case that the path between Router 1 & 2 is up, and some 
>    remote link in the network X2 is down. It is also assumed that DNS 
>    returns addresses for both NATs when queried for Hosts A or B. When 
>    Host D tries to contact Host B, the request goes through NAT2, but 
>    due to the internal routing, the reply is through NAT1.

If X2 is broken, there is a routing issue of how Host-D can be accessed
through NAT1. The NAT1 service provider lost connectivity to Host-D. This
is a problem independent of NAT, with ay multi-homing scenario.

<... stuff deletd>
>    In a third case, both Host A & B want to contact Host D, when the 
>    remote link X2 in the Internet breaks. As long as the path X1 is 
>    down, Host B is able to connect, but Host A is cut off.
 
Once again, sounds like a routing problem to me. If X2 and X1 are broken,
there is no routing connectivity between  Host-A and Host-D. This is 
nothing to do with NAT1 or NAT2.

<... stuff deleted>
>                              Illustration 5 
>                                      
>    Everything in this simple example will work until an application 
>    embeds a name. For example, a Web service running on Host D might 
>    present embedded URLÆs of the form http://D/bar.html, which would 
>    work from Host C, but would thoroughly confuse Host A. 

But, shouldnt this be a FQDN? This would be a problem in general to 
resolve a name that is not FQDN across a global betwork. I dont see
the relation to NATs. For example, there may be multiple nodes called 
"ROCKY", but each is unique to a domain. (ex: rocky.altos.com, 
rocky.zagros.com etc.)

<... stuff deletd>

>               ---------------                     ---------------- 
>              |  10.10.10.10  |--------L2TP-------| Assigned by A  | 
>              |    Host A     |   ---       ---   |    Host B      | 
>              |    10.1.1.1   |--|NAT|-----|NAT|--|  10.10.10.10   | 
>               ---------------    ---       ---    ---------------- 
>                                      
>                                 -------- 
>                              Illustration 6 

This brings out a problem concerning PPP/L2TP address assignment,
when the assigned address could collide with the user's private address
space.  How is this a NAT issue?

<... stuff deleted>
> 9.  Security Considerations 
>     
>    NAT (particularly NAPT) actually has the potential to lower overall 
>    security because it creates the illusion of a security barrier, but 
>    does so without the managed intent of a firewall. 

NAT and firewall functions are different. So, one is not a replacement
for the other. On the other hand, there are many deployments that have
both functions on the same device co-existant.
 
<.. stuff deleted>
> 10.  Deployment Guidelines 
<... stuff deleted>
>    - Assure that applications used both internally and externally avoid 
>      embedding names, or use globally unique ones. 

Using names that are not globally unique would fail independent of 
NAT being enroute.

>    - For RSIP, determine the probability of TCP_Time_Wait collisions 
>      when subsequent private side hosts attempt to contact a recently 
>      disconnected public side service. 

I dont believe, this is limited to RSIP or NAT. This guideline applies 
to all IP stack implementors(for socket assignment) and PPP/DHCP servers
(for dynamic address asignment).

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.