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

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 17 Apr 2005 23:33:55 -0700 (PDT)

Saikat,

My comments inline below. Thanks.

cheers,
suresh

--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:
> On Sun, 2005-04-17 at 08:59 -0700, Pyda Srisuresh wrote:
> > I believe, your results indicate that a overwheleming majority of the
> devices
> > use the following timeouts in various phases of the TCP session.
> 
> The reports included hosts that ran the test without being behind a NAT
> or were configured in the DMZ for the NAT (all unmatched packets were
> sent to them). Those showed up as TCP Filtering Type: Open and may have
> thrown off your numbers.

[suresh] I see. I didnt quite know what you meant by open filtering. Now that
you mention this, it seems, about 30% of the devices are non-NAT devices,
right.

>                          I've changed the default tabulation to hide
> those for now.
> 
> > SYN-SENT:   >1min (73%)
> > ESTD:       >2hrs (53%), 15min-1hr (31 out of 100)
> > TIMED-WAIT: >1 min (65%)
> > RST:        >1 min  (58%)
> 
> I get 
> SYN-SENT: >1m 45/72 (62%)
> ESTD: >2h 26/72 (36%), 15m-2h 31/72 (43%
>      (note 15m-2h and not 1h)
> TIMED-WAIT: >1m 36/72 (50%)
> RST: >1m 29/72 (40%)
> 
[suresh] OK. Thanks for recaliberating. This certainly changes the TCP session
timeout value usage. I guess, it is also important to note that a good 21% of
the devices use a TCP session timeout of 15mins or less.

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.

> > However, I noticed that only a small portion of the devices tested (13%)
> use
> > port binding. Vast majority of the devices tested (85%) use independent
> > binding. By "independent binding", I assume, you meant address binding. If
> not,
> > please clarify. 
> 
> By independent, I mean NB=I from draft-ietf-behave-nat-udp-01 i.e. the
> external address and port is determined uniquely by the 2-tuple (source
> address and port) of the packet initiating the flow. If a host uses
> LA:LP to connect to RA1:RP1 as is allocated the mapping MA:MP, then when
> the host uses LA:LP to connect to RA2:RP2, it will be allocated the
> mapping MA:MP as well. 

[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?

>                        As for the numbers, I get 53/78 (63%) for
> "Independent" ... unintentional inclusion the non NAT'ed or DMZ'ed hosts
> artificially inflated the previous estimate. The other classifications
> in this category "Address", "Port", "Session" and "Address and Port" are
> explained in http://nutss.gforge.cis.cornell.edu/stunt-client.php
> 
[suresh] It is still heartening to note that 63% of the devices tested already
enforce port binding. This is good news. We want to depricate symmetric NAT
type of behavior.

> 
> > I am a concerned if the results are representative of the NAPT devices
> > profile.
> 
> While almost all results are from NAPT devices, they may not be
> representative of the global NAT deployment. For instance, according to
> market surveys, NATs from Buffalo Technologies is more common than D-
> Link and Netgear, however our sample set does not reflect this.
> 

[suresh] I understand what you mean. It is also important to note that the
study of existing devices does not imply that we want to recommend what is
already status quo for a majority of the devices. It is just good to understand
where the current state of the NAT devices is. We should not hesitate proposing
a change, when a change is required. 

Thanks.

> -- 
> Saikat

cheers,
suresh

---

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

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

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

-- 
Saikat
Attachment:
signature.asc

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Apr 2005 17:03:49 -0700 (PDT)

On 4/18/05 1:32 AM, "Saikat Guha" <sg266@xxxxxxxxxxx> wrote:

> hours. 

I agree with having this greater than two hours. The default for several OS
including windows, solaris, and linux is 7200 seconds for TCP keep alives. I
think we need to be enough above 7200 seconds that even with race conditions
on the keep alive packet and NAT, things wok out ok

Cullen (not as chair)