Subject: [Ietf-behave] TCP - what to test

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Dec 2004 17:11:57 -0800 (PST)

A a rough straw man of things we might want to test in TCP I went and pulled
these out of the ford-midcom-p2p draft and Saikat's work.

If a SYN packets goes out, will a SYN packet be allowed in

If nothing has gone out, will an inbound SYN get dropped or get a RST or
ICMP

If a connection from IP1:port1 is made to an outside destination, will a
connection from the same source to a different destination get the same port
on the outside of the NAT

What is the timeout for a connection when only a SYN has been seen. Is it
larger than 60 seconds?

What is the timeout for an established connection. Is it larger than 7200
seconds?

---

From: Senthil Sivakumar <[email-masked]>
Date: Tue, 7 Dec 2004 22:15:06 -0800 (PST)

To add to this list:

Would a RST/Fin- FinACK clean the NAT entry, if not how long does the
session last?
Both endpoints behind the same NAT.

Test all of these for both dynamic NAT and PAT configs.

Senthil

At 05:11 PM 12/7/2004 -0800, Cullen Jennings wrote:

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

---

From: Bryan Ford <[email-masked]>
Date: Thu, 9 Dec 2004 07:36:03 -0800 (PST)

On Tuesday 07 December 2004 20:11, Cullen Jennings wrote:
> A a rough straw man of things we might want to test in TCP I went and
> pulled these out of the ford-midcom-p2p draft and Saikat's work.
>
> connection from the same source to a different destination get the same
> port on the outside of the NAT
>

I can think of two other related properties that are likely to be important:

* After a TCP session has been closed via graceful shutdown (a FIN has been 
seen from each endpoint), does the NAT "close the hole" immediately and 
reject any subsequent incoming SYNs from the same external endpoint, or does 
it leave the hole open a while longer (e.g., at least 60 seconds, or perhaps 
for the duration of the TCP TIME-WAIT state)?

* Similarly, after a TCP session has been closed non-gracefully due to an RST 
being received from one endpoint, does the NAT "close the hole" immediately 
or leave it open for some time longer?

For obscure political reasons I have to get someone's permission before 
discussing in detail why these properties are important, but I'll explain 
shortly when I can. :)  But the upshot is that I think a NAT's timeouts may 
be important in practice not only for half-open and open connections, but 
also for recently-closed and recently-reset connections.

Thanks,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Thu, 9 Dec 2004 07:50:40 -0800 (PST)

> Would a RST/Fin- FinACK clean the NAT entry, if not how long does the

Oops, I should have read through the rest of my E-mail before posting my last 
message... :)

Another important one:

* Does the NAT properly implement hairpin aka loopback translation?

Thanks,
Bryan

---

From: Kaushik Biswas <[email-masked]>
Date: Thu, 9 Dec 2004 11:58:27 -0800 (PST)

Couple more to the list:

* When a TCP Segmented packet comes how does the NAT behave, does it spoof 
back an ACK (it should if it is handling segmentation-reassembly since 
otherwise the end-point will not generate subsequent TCP segments, and it 
shouldn't if the ALG processing is disabled in the NAT) . [Query: Do we 
want to cover this aspect in the first place]

* If the outgoing TCP packet is sourced on a well-known-port does NAT 
change this port to something else (even if that port is available for NAT 
to use), if it is sharing the NAT Pool-address with one of its 
interface-address.

* Also how does the NAT allocate the ports wrt port-ranges: 
well-known-range, priv-range & user-range.

Thanks,
Kaushik