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

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 18 Apr 2005 07:41:51 -0700 (PDT)

--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:
> On Sun, 2005-04-17 at 23:33 -0700, Pyda Srisuresh wrote:
> 
> > Basically, selecting a large timeout ties up resources in the NAT devices
> for a
> > long time. Making the timeout too short is problematic from end-to-end
> session
> > perspective. The recommendation has to strike a balance between the two.
> > 
> > What do you think of the following proposal. 
> > SYN timeout (Connecting phase):    60 secs.
> > TCP session timeout (Estab phase): 60 mins.
> > Closing timeout (Closign phase):   4 mins.
> 
> Regarding SYN timeout, I feel 60s is fine. Although RFC 1122 suggests a
> 2xMSL of 4min, Linux, BSD and most other stacks use a 2xMSL of 60s. So
> this gives them enough time to receive the response from the
> destination, if any. 
> 
> As for session timeout, RFC 1122 reads "[TCP Keep-Alive] interval MUST
> be configurable and MUST default to no less than two hours." which means
> that end-hosts that do not exchange any data for a while will, by
> default, check liveness of a connection by sending a probe every 2
> hours. 'ssh -o TCPKeepAlive' does this I believe. So I feel 2h would be
> a better recommendation unless the NAT aggressively checks liveness. The
> NAT may send a TCPKeepalive probe after 60 min ... and if no response is
> received within 2xMSL, then expire the connection. If the NAT chooses
> not to implement this, then it must not expire the connection before 2h.
> 

[suresh] Interesting. 2 hrs seem like a lot to recommend for a minimum TCP
session timeout. As for the servers out there, do you know if majority of them
use 2krs keepalive or less? What do others think?

I agree with your second comment about requiring to send keepalives, when the
session timeout is less than the recommended value. 

> > [suresh] I see. Thanks for clarifyig. The above description is indeed what
> I
> > consider to be TCP port binding. There are about 20% of the devices that
> list
> > the TCP binding type as "Address and Port" or  "Session". From your
> description
> > of binding types in http://nutss.gforge.cis.cornell.edu/stunt-client.php,
> it
> > seems "address and port" and "Session" type are one and the same and they
> both
> > represent symmetric NAT behavior, right?
> 
> No. Assume the local endpoint LA:LP, remote endpoints RA_k:RP_k and the
> mapped address MA:MP_k (assuming NAPT with only one external IP)
> 
> Consider the following sequence of connections:
> (1) LA:LP -> RA_1:RP_1
> (2) LA:LP -> RA_1:RP_1
> (3) LA:LP -> RA_1:RP_1
> (4) LA:LP -> RA_2:RP_2
> (5) LA:LP -> RA_2:RP_2
> (6) LA:LP -> RA_2:RP_2
> 
> For NB="Address and port" the mappings will be
> (1) MA:MP_1
> (2) MA:MP_1
> (3) MA:MP_1
> (4) MA:MP_2
> (5) MA:MP_2
> (6) MA:MP_2
> 
> For NB="Session" the mappings will be
> (1) MA:MP_1
> (2) MA:MP_2
> (3) MA:MP_3
> (4) MA:MP_4
> (5) MA:MP_5
> (6) MA:MP_6
> 
> This is something not seen in the UDP case. Essentially, in the session
> case, a new port is allocated every time a SYN packet is sent out.
> 
[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. 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)?
considering that they both are symmetric NAT, Do you know if this behavior has
any benefit over the second behavior?

Thanks.

> -- 
> Saikat
cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Mon, 18 Apr 2005 15:51:01 -0700 (PDT)

On Mon, 2005-04-18 at 07:41 -0700, Pyda Srisuresh wrote:
> 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.

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!

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

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

> In the first case, it seems

In my experience, as long as the allocated mapping is not garbage
collected, new sessions between the same endpoints use the existing
mappings.

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

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?

Cheers
-- 
Saikat
Attachment:
signature.asc

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 18 Apr 2005 17:26:33 -0700 (PDT)

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?
Does either of these messages cause the originating host to behave differently?
I think sending a RST or ICMP Unreachable would not prevent a host app from 
retrying
a number of times (it is programmed to retry), right? Of course, I agree 
that ICMP
unreachables are slightly better for the rate limiting reason.

Senthil

Cheers
--
Saikat
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Saikat Guha <[email-masked]>
Date: Mon, 18 Apr 2005 18:59:59 -0700 (PDT)

On Mon, 2005-04-18 at 17:26 -0700, Senthil Sivakumar wrote:
> retrying a number of times (it is programmed to retry), right? 

There are a couple of minor differences. Error values returned from the
socket functions is different: ECONNREFUSED for RST vs. EHOSTUNREACH for
ICMP host unreachable, which in turn generates different error strings
"Connection refused" vs. "No route to host" respectively. 

According to RFC1122 btw, ICMP host unreachable _must_ be soft, ICMP
port unreachable _should_ be hard and RST _must_ be hard. Then again,
Linux doesn't retry on some soft errors (host unreach in SYN_SENT) and
windows retries on some hard errors (RST in SYN_SENT) ... so retries in
the stack is unpredictable as it is. :-p

-- 
Saikat
Attachment:
signature.asc