Subject: [Ietf-behave] Catalogue of problems with deployed NATs

From: "Dave Hudson" <[email-masked]>
Date: Sat, 17 Dec 2005 12:09:25 -0800 (PST)

Does anyone have any pointers to documents/websites that describe
problems seen by widely-deployed NATs?  I've been looking into some very
odd behaviour I've seen from systems using P2P file-sharing applications
and it's not at all unusual for me to see 50 or 60 packets per minute
arriving at my test system (around 0.5% of all packets) where there's
very strong evidence of something wrong in the translations being
applied by remote NATs.

Many of these problems are leading to me seeing excessively high numbers
of TCP connections left in effectively a half-open state (e.g. with a 2
hour timeout applied to traffic in Establish, Fin-Wait-1, Fin-Wait-2 and
Close-Wait I can see 2k or 3k such connections after an hour or two even
when only using at a slow DSL connection) with a consequent impact on
overall performance.

I'm investigating strategies that will help me reduce both the amount of
bad traffic that I see arriving and the number of half-open connections
but a more comprehensive list of possible failure modes would help (if
there is one).

Failing that I'll be happy to summarise problems I have observed if
anyone's interested.

Thanks,
Dave

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 18 Dec 2005 21:06:05 -0800 (PST)

Dave,

RFC 3027 was done a while back documenting compliations with NATs.
draft-ford-behave-top-00.txt documents complications with the use of NATs in
certain topologies. The ID has expired. We will get a new rev out shortly.
Outside of these, I dont know of any other. 

Additional comments inline below.

cheers,
suresh

> when only using at a slow DSL connection) with a consequent impact on

[suresh] Sounds like, you are saying you noticed a lot of half-open or
half-close conenctions on the NATs. This may be specific to the file sharing
Peer-to-peer (P2P) application you are using and the algorithm the application
is using to traverse NATs. I dont know what the problem is. But, I suspect, the
problem is to do with symmteric NATs being enroute.

> but a more comprehensive list of possible failure modes would help (if
[suresh] You might want to take a look at
draft-srisuresh-behave-p2p-state-01.txt for a description of the various
algorithms in use by P2P apps for NAT traversal.

> Failing that I'll be happy to summarise problems I have observed if
[suresh] That sounds good in any case. Thanks.

cheers,
suresh

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

---

From: Saikat Guha <[email-masked]>
Date: Mon, 19 Dec 2005 09:55:40 -0800 (PST)

On Sat, 2005-12-17 at 12:09 -0800, Dave Hudson wrote:
> problems seen by widely-deployed NATs?  

We recently analyzed some problems in the following paper [1]:

[1] "Characterization and Measurement of TCP Traversal through NATs and
Firewalls", http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/

> something wrong in the translations being
> applied by remote NATs.

Interesting; this is TCP I am assuming? Do you mean the NAT is
incorrectly translating a particular TCP-or-IP header field, or that it
is mangling the data payload in the TCP packet?

> of TCP connections left in effectively a half-open state 

I know a number of NATs break the connection right after they see the
FIN packets, so the final ACKs may not always get delivered. This causes
hanging zombie connections. As for half-open, I recall there being a
problem in Windows XP SP1 and before where, if TCP simultaneous was
triggered, one side would go into half-open while the other side
wouldn't see the connection. This was discussed earlier on this list.

cheers,
-- 
Saikat
Attachment:
signature.asc