Subject: draft-ietf-nat-protocol-complications (was Re: interception proxies)

From: Vernon Schryver <[email-masked]>
Date: Thu, 20 Apr 2000 09:22:21 -0600 (MDT)

> From: Pyda Srisuresh <[email-masked]>
> To: Vernon Schryver <[email-masked]>, [email-masked]
> Cc: [email-masked], [email-masked]

> ...
> > Is there an RFC that includes the many complaints that have been made about
> > NAT boxes in the main IETF list?
>
> Not an RFC. But, a draft addressing precisely this. 
> It is titled "Protocol Complications with the IP Network Address Translator".
> <draft-ietf-nat-protocol-complications-02.txt>.  ...

That draft does not mention anything about the IP fragmentation problem
that we were talking about in the WREC list that provoked that comment.

Many people act on the silly superstition that a 56 Kbit/sec modem or 128
Kbit/sec ISDN link is faster with a tiny MTU.  When they do that, IP
fragmentation must occur except when Path MTU works.  (Do most NAT boxes
do the right things when they see the DF bit?)  (That draft doesn't list
ICMP as an application whose payloads can need to be modified; consider
the packet headers in some ICMP payloads.)

NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection
proxies are likely to do the wrong things when the bits in the payload
that need to be modified are not in the first IP fragment, at least unless
they do (the equivalent) of IP fragment reassembly before forwarding.

Neither kind of box can even redirect incoming IP fragments to the correct
local host, since the UDP and TCP port numbers are only in the first
fragment.

Tiny incoming IP fragments seem most likely when both TCP hosts or more
than one UDP application (there can be >2 with multicast) are using NAT
boxes.  I've seen people run servers for various applications behind
NAT boxes, including HTTP, SMTP and proprietary applications.

Vernon Schryver    [email-masked]

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 21 Apr 2000 00:13:20 -0700 (PDT)

> that we were talking about in the WREC list that provoked that comment.

I dont know the exact problem you were talking about in the WREC list.
But, IP fragmentation problem is listed as one of known NAT limitations
in section 6.3 of <draft-ietf-nat-traditional-03.txt> as follows. 
We will add a note at the end of section-1 in the Complications draft, 
refering readers to known NAT limitations listed in RFC 2663 and the
traditional-nat draft.

   6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup
   
   Translation of outbound TCP/UDP fragments (i.e., those originating
   from private hosts) in NAPT setup are doomed to fail. The reason is 
   as follows. Only the first fragment contains the TCP/UDP header that 
   would be necessary to associate the packet to a session for 
   translation purposes. Subsequent fragments do not contain TCP/UDP 
   port information, but simply carry the same fragmentation identifier 
   specified in the first fragment. Say, two private hosts originated
   fragmented TCP/UDP packets to the same destination host.  And, they
   happened to use the same fragmentation identifier. When the
   target host receives the two unrelated datagrams, carrying same 
   fragmentation id, and from the same assigned host address, it 
   is unable to determine which of the two sessions the datagrams 
   belong to. Consequently, both sessions will be corrupted. 

> do the right things when they see the DF bit?)  (That draft doesn't list

What excatly is your concern with NAT boxes and DF bit? Please elaborate.

> the packet headers in some ICMP payloads.)

Agreed. This is part of NAT operation described in traditional-nat draft.
I dont believe, this belongs in "NAT complications" draft. 
 
> NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection

NAT boxes are not same as ALGs. NAT boxes are those that implement a 
NAT type (typically NAPT or Basic-NAT, as described RFC 2663) and some
number of ALGs.

> they do (the equivalent) of IP fragment reassembly before forwarding.
You will need an ALG to do any kind of modification to the payload.
What is the problem with IP fragments here?

> local host, since the UDP and TCP port numbers are only in the first
When IP fragments are directed to the NAT box, NAT will need to 
reassemble the fragments into a single MTU prior to translation.
And, NAT devices do just that. 
  
> NAT boxes, including HTTP, SMTP and proprietary applications.

I believe, this is addressed in my previous comment already.

> Vernon Schryver    [email-masked]

cheers,
suresh 

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com