Subject: Re: [Ietf-behave] Next rev on TCP Behavior

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 26 Apr 2005 07:52:22 -0700 (PDT)

--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:
> On Wed, 2005-04-20 at 17:51 -0700, Pyda Srisuresh wrote:
> > > I think second one (NB="session") is quite bad since if a host behind
> > > such a NAT tries connecting to another NAT'ed host (where the other NAT
> > > drops incoming SYN packets), then each SYN packet sent by the host
> > > creates a new mapping that hangs around for a minute or two. Depending
> > 
> > [suresh] Hmm... This doesnt make sense. Why woudl a NAT create a new
> endpoint
> > association for each SYN packet, when the NAT-session already exists for
> the
> > first SYN? On the other hand, if the NAT-session already expired  when the
> new
> > SYN packet came, what difference does it make whether it reused the same
> > endpoint association or not. 
> 
> It's very bewildering actually. The packet trace I observed through a
> netgear NAT went something like:
> 
> Host  = a = 192.168.1.1
> NAT   = A = 128.84.154.97
> Server= B = 128.84.154.62
> 
> Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1052,B:3389)---> dropped
> Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1053,B:3389)---> dropped
> Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1054,B:3389)---> delivered
> Server---(SYNACK,B:3389,A:1054)---> NAT---(SYNACK,B:3389,a:1024)--->
>      delivered
> Host---(ACK,a:1024,B:3389)---> NAT---(ACK,A:1054,B:3389)---> delivered
> 
> The SYNs are TCP retransmissions at time 0s, 3s, 9s. It seems like this
> particular NAT allocates a new packet for _every_ SYN packet it sees;
> retransmission or not. The server receives one of the SYN packets and
> responds, and the source port of that SYN at the NAT enters established
> state while the others get garbage collected shortly afterward. 
> 

[suresh] Saikat - Thanks for the detailed description. Do you know for a fact
that the NAT device did not free up the first two NAT sessions, by the time it
created the third NAT session. I think, it may have and here is what I suspect
might have happened. 

Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1052,B:3389)---> dropped
         ==> NAT device created NAT session-1 (a:1024->A:1052,B:3389) 

Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1053,B:3389)---> dropped
         ==> At this point or before, NAT device freed up NAT session-1.
         ==> NAT device created NAT session-2 (a:1024->A:1053,B:3389) 

Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1054,B:3389)---> delivered
         ==> At this point or before, NAT device freed up NAT session-2.
         ==> NAT device created NAT session-3 (a:1024->A:1054,B:3389) 

Server---(SYNACK,B:3389,A:1054)---> NAT---(SYNACK,B:3389,a:1024)--->     
delivered
         ==> NAT device matched the packet from Server against NAT session-3.
         ==> NAT device changed the TCP-state of NAT Session-3 
         ==> NAT device used NAT Session-3 to translate & forward to Host a.

Host---(ACK,a:1024,B:3389)---> NAT---(ACK,A:1054,B:3389)---> delivered
         ==> NAT device matched the packet from Host-a against NAT session-3..
         ==> NAT device changed the TCP-state of NAT Session-3.
         ==> NAT device used NAT Session-3 to translate & forward to server.
> 
> > > on the OS, each TCP attempt uses up 3-5 entries in the NAT
> > > (corresponding to 3-5 retries); this eats into the 255 entries limit
> > > making it easier to DoS the NAT.
> > > 
> > [suresh] How so? For the same session 5-tuple, I dont see how a NAT will
> have
> > multiple concurrent NAT-sessions simultaneously. 
> 
> the session tuple could depend on the implementation. Logically it is a
> 5-tuple (proto, src_ip, src_port, dst_ip, dst_port) ... but the NAT may
> store it internally as, perhaps, a 8-tuple (..., map_ip, map_port,
> TCP_STATE).

[suresh] Yup, I agree. The NAT Session does need to include all the parameters
you list.

> My guess is that in the above case each SYN generates a new
> 8-tuple. inbound packets are matched based on map_ip/map_port. Outbound
> packets are matched on tcp status in addition to some combination of
> source and destination address and ports. Just a hunch. 

[suresh] Hmm.. That is possible. However, if a new xlation endpoint is
identified, I see no reason to retain the old NAT Session unless there is some
implementation glitch. The prior NAT Session should have been freed, if the NAT
device chose to create a new NAT session with a different endpoint to translate
to. If the NAT device is indeed holding on to all the previous NAT sessions, it
seems like an implementation glitch to me.

> 
> Cheers.
> -- 
> Saikat
> (who feels NAT firmware source should be made available for inspection
> to prevent hairloss)
> 

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Sun, 8 May 2005 22:16:07 -0700 (PDT)

Comments inline. Sorry for the delay; it was a DLink NAT (not netgear).

On Tue, 2005-04-26 at 07:52 -0700, Pyda Srisuresh wrote:
> here is what I suspect might have happened. 
> 

You are correct. This time I traced the traffic on both sides of the
NAT. If a SYN goes unanswered for about 2 seconds, the NAT frees up the
session and generates a RST for the internal stack. 

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 8 May 2005 23:22:54 -0700 (PDT)

OK. Sounds like, it doesnt matter how endpoint associations are made with
Symmetric NAT behavior. They all are equally unacceptable, right.

cheers,
suresh