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

From: "Francois Audet" <[email-masked]>
Date: Wed, 23 Feb 2005 11:12:22 -0800 (PST)

I think the key is that port preservation can not be mandated
and can not be prohibited. In other words, you have to be prepared
for both.

This means that it is not terribly useful for traffic analysis.

That's why I'm proposing what I am proposing...

> -----Original Message-----
> From: nagendra modadugu [mailto:nagendra@xxxxxxxxxxxxxxx] 
> Sent: Wednesday, February 23, 2005 10:57
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: Re: [Ietf-behave] New draft: NAT Behavioral 
> Requirements for TCP
> 
> 
> 
> Thanks for elaborating on this point.  My comments inline.
> 
> > 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.
> 
> 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
> 
>