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

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 20 Apr 2005 17:51:52 -0700 (PDT)

--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:
> On Mon, 2005-04-18 at 07:41 -0700, Pyda Srisuresh wrote:
> > [suresh] Interesting. 2 hrs seem like a lot to recommend for a minimum TCP
> > session timeout. 
> 
> It does seem large, however, it is only for the case when the session is
> not closed normally (FIN or RST) due to a host crashing. In addition, if
> the host comes back up, then subsequent packets from the first
> connections would trigger a RST, further mitigating the resource leakage
> problem.
> 
[suresh] OK.

> On a related note, some NATs support a very small number of concurrent
> connections. The actual numbers are being added to the STUNT page, but
> from initial estimates it looks like atleast Linksys, Netgear and D-Link
> NATs have a limit of only 255 open connections!
> 

[suresh] I am sure, most devices have a limit on the number of open
connections. The actual count may vary across vendors.
 
> > As for the servers out there, do you know if majority of them
> > use 2krs keepalive or less? 
> 
> I don't know how often servers keep a session open for 2h. HTTP servers,
> and many applications implement some sort of application level idle
> timer and explicitly close the connection after a couple of minutes of
> inactivity. Other servers such as TELNET, SSH, RSH etc are designed to
> sustain sessions indefinitely.
> 
> > [suresh] OK, I see the difference. I would still argue, they both exhibit
> > symmetric NAT behavior in that they provide different endpoint
> associattions to
> > the local endpoint for different session tuples. 
> 
> True. Deprecating symmetric behavior (or NB != I behavior in draft-ietf-
> behave-nat-udp terms) would deprecate both "address and port" and
> "session" equally.  
> 
[suresh] Yup.

> > In the first case, it seems
> > the NAT device remembers the endpoint association on a per-session basis
> > (LA:LP->RA_1:RP_1 vs. LA:LP->RA_2:RP_2) and resues the association. Is this
> > true only when the sessions are continuously made with the same tuple
> (i.e.,
> > from LA:LP to RA_1:RP_1 continuously three times, one after the other)?
> 
> In my experience, as long as the allocated mapping is not garbage
> collected, new sessions between the same endpoints use the existing
> mappings.
> 
[suresh] OK. 

> > considering that they both are symmetric NAT, Do you know if this behavior
> has
> > any benefit over the second behavior?
> 
> 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. 

> 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. I see no difference in
resource consumption between  the two cases.

> That brings up another question, if a SYN (or any packet) is filtered,
> what should the response be? Silently dropping the packet opens the NAT
> up to IP Spoofing attacks where an adversary in the middle of the
> network spoofs the NATs IP in a SYN, and replies with a spoofed ACK
> knowing that the SYNACK was dropped silently by the NAT; thus fooling
> the victim. Generating RST packets seems to violate the semantics of
> RST, which in my opinion means the host replying can authoritatively say
> that there is no application expecting to receive the packet. 
> 
> I propose the NAT should respond with ICMP Destination Unreachable
> (Code: Host unreachable or Port unreachable) much like a router responds
> with net unreachables. The response would naturally be subject to ICMP
> rate limiting to prevent reflection attacks. Second, NATs should process
> incoming ICMP Host or Port Unreachables the same way they would process
> a RST or FIN/FINACK. Thoughts?
> 
[suresh] Let me try and respond to this in a different thread.

> Cheers
> -- 
> Saikat

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Mon, 25 Apr 2005 19:22:08 -0700 (PDT)

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

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

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