Subject: RE: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP

From: "Francois Audet" <[email-masked]>
Date: Tue, 22 Feb 2005 09:22:26 -0800 (PST)

Thanks Nagendra, good document.

On the point concerning "port preservation" and draft-ietf-behave-nat-udp, 
Nagendra and I had an offline discussion.

Let me reproduce here for clarity REQ-3 from draft-ietf-behave-nat-udp:

   REQ-3  It is RECOMMENDED that a NAT have a "Port assignment" behavior
          of "No port preservation".
          a) NAT MAY use a "Port assignment" behavior of "Port
             preservation".
          b) A NAT MUST NOT have a "Port assignment" behavior of "Port
             overloading".
          c) If the host's source port was in the range 1-1023, it is
             RECOMMENDED the NAT's source port also be in the same
             range.  If the host's source port was in the range
             1024-65535, it is RECOMMENDED that the NAT's source port
             also be in that range.

Nagendra's point is that the first requirement about not recommending
port preservation is not enforceable and meaningless. If ports are
assigned randomly, it is possible that it will randomly be preserved.
Therefore the application must be capable of dealing with the case
where it is preserved.

The reason we came up with this requirement in the first place is because
we have noticed a lot of NATs that tried to preserve the port when not
assigned (and behaved like a Cone NAT) and then switched to not-preserved
AND to a symmetric NAT when the port was already in use. It is not
the "preservation" that was the problem, but the switching from Cone
to symmetric (non-deterministic property).

In short, I agree with Nagendra. I'm not sure if we should recommend 
port preservation, or just not recommend anything at all. I would propose
to change REQ-3 of draft-ietf-nat-behave-udp to:

   REQ-3  A NAT MUST NOT have a "Port assignment" behavior of "Port
          overloading".
          a) If the host's source port was in the range 1-1023, it is
             RECOMMENDED the NAT's source port also be in the same
             range.  If the host's source port was in the range
             1024-65535, it is RECOMMENDED that the NAT's source port
             also be in that range.

And align the TCP document with this.

The other alternative is to explicitly recommend port preservation, in
which case it would look like:

   REQ-3  It is RECOMMENDED that a NAT have a "Port assignment" behavior
          of "Port preservation".
          a) A NAT MUST NOT have a "Port assignment" behavior of "Port
             overloading".
          b) If the host's source port was in the range 1-1023, it is
             RECOMMENDED the NAT's source port also be in the same
             range.  If the host's source port was in the range
             1024-65535, it is RECOMMENDED that the NAT's source port
             also be in that range.

I prefer the first approach, but I am happy with either.

Comments?

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> nagendra modadugu
> Sent: Monday, February 21, 2005 19:08
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP
> 
> 
> 
> I must apologize for the delayed notification about a new 
> draft -- the draft got held up as a result of a buggy IPR 
> statement (now fixed).
> 
> The draft is a TCP counterpart to the NAT-UDP draft by Audet 
> & Jennings.  I have attempted to reproduce as little material 
> possible 
> from the NAT-UDP draft while following its template.  As a 
> result, this draft may be read as a "diff" to the NAT-UDP 
> draft (though there is only one conflicting recommendation, 
> for which see below).
> 
> Some elements require expansion following further discussion 
> (timer values for instance).  
> 
> The recommendation on "Port Preservation" in this draft 
> (=RECOMMENDED) 
> differs from the recommendation made in the NAT-UDP draft (a brief 
> discussion on this issue is given in Section 7.1).  If there is a 
> consensus for "Port Preservation" preservation behavior, then 
> this change ought to be folded into the NAT-UDP or protocol 
> independent 
> behavior drafts.
> 
> nagendra
> 
> -- http://www.ietf.org/internet-drafts/draft-modadugu-nat-tcp-00.txt
> 
> Abstract
> 
>    This document specifies requirements for NAT devices when handling
>    TCP traffic.  In order to arrive at the requirements, basic
>    terminology regarding NAT TCP handling is defined.  The purpose of
>    this document is to provide a specification of TCP handling by NAT
>    devices so that TCP-using applications can work consistently.
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: nagendra modadugu <[email-masked]>
Date: Wed, 23 Feb 2005 10:56:46 -0800 (PST)

Thanks for elaborating on this point.  My comments inline.

>              1024-65535, it is RECOMMENDED that the NAT's source port

I'm happy with the recommendation taking this form.  The primary reason
I could find for recommending "Port Preservation" was the transparency
a low-use NAT will provide.  But upon further thought, this isn't a
sufficiently compelling reason for making a recommendation.  

As food for thought, does port preservation make traffic analysis any easier?

nagendra