Subject: RE: [Ietf-behave] New draft on UDP unicast behavior

From: "Francois Audet" <[email-masked]>
Date: Mon, 28 Feb 2005 18:56:07 -0800 (PST)

Here is my take:

- I don't like this idea of a new IP header option (you don't either,
  so this is good). I think it is very important that the NAT vendors
  that are BEHAVE-compliant TODAY, don't get penalized to look like
  they are not compliant because of this flag. It would result in
  extreme measures (like forcing a TURN server) when there is 
  really no need.

- I also don't like forcing hyper-complex diagnostics on the application
  to determine if the NAT is behave compliant. However, it is certainly
  an option for the application writer. We could recommend that the 
  application treats un-usable NATs gratefully (e.g., provide 
  a warning, etc.). To me, it means that if your code arrives to the
  conclusion that it won't work (because the NAT is bad), it would
  treat it gracefully. 

- Personnally, I think an application could at least determine if
  the NAT has an "external NAT mapping is endpoint independent" for UDP
  address and port mapping behavior. And then take appropriate
  action (use TURN, display an error message, etc.). But again,
  I don't think we should mandate any of this.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Bryan Ford
> Sent: Monday, February 28, 2005 08:07
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] New draft on UDP unicast behavior
> 
> 
> On Tuesday 26 October 2004 10:38, Robert Sanders wrote:
> > Dan Wing wrote:
> > >BEHAVE needs a "how a UDP application can use a 
> BEHAVE-capable NAT" 
> > >document, which would provide guidance.
> >
> > If this usage differs from how the UDP application might use a 
> > non-BEHAVE-capable NAT, or from the scenarios described in 
> > draft-ietf-sipping-nat-scenarios et cetera, it would also 
> be useful to 
> > show how an application might *detect* a well-BEHAVEd NAT.
> 
> I'm not at all sure that such detection is really necessary: 
> for the most part 
> I think we should just be recommending that apps assume that NATs are 
> well-BEHAVEd going forward, and perhaps make a few specific 
> exceptions as 
> necessary to account for particularly common forms of "bad" 
> legacy behavior.
> 
> On the other hand, if it is useful for applications to be 
> able to distinguish 
> reliably between BEHAVE NATs and non-BEHAVE NATs, then I can 
> think of at 
> least one relatively simple technical solution to this 
> problem, which would 
> operate completely "in-band" and is both 
> transport-independent and require no 
> explicit communication with NAT (e.g., MIDCOM, NSIS, etc.).  
> Basically, we 
> could define a new IP header option, which applications can 
> attach to the 
> initial packets in a new transport session they're 
> establishing if desired.  
> The application places in this IP option a copy of its source 
> IP address and 
> transport-level port number.  Non-BEHAVE NATs will 
> (hopefully) just ignore 
> this option, translating only the IP address and port number 
> in the main 
> IP/TCP/UDP headers.  BEHAVE NATs would first compare the 
> address/port in the 
> option against the address/port in the main headers, 
> translate the option too 
> if they match, and zero or remove the option if they don't 
> match.  The 
> application at the receiving end can then determine what's on 
> the path as 
> follows:
> 
> 1. If the IP option was preserved and has the same 
> address/port as in the main 
> IP/TCP/UDP headers, then ALL of the NATs in the path (if any) are 
> well-BEHAVEd.
> 2. If the IP option disappeared or arrived with an 
> address/port number that 
> doesn't match the info in the main IP/TCP/UDP headers, then 
> there is at least 
> one NAT in the path that is not BEHAVE-compliant.
> 
> A variant of this idea was discussed in one of the early 
> P2P-over-NAT drafts I 
> wrote with Pyda Srisuresh, draft-ford-midcom-p2p-00.txt.
> 
> Anyway, to reiterate what I said above, I'm not at all convinced that 
> "well-BEHAVEd NAT detection" is really necessary or even a 
> good idea, but I 
> at least wanted to lay this option on the table in case it 
> seems useful.
> 
> > I know that NAT type detection has been deprecated in 
> RFC3489bis, and 
> > that the problem of detection has become more complex than 
> originally 
> > estimated.  Requiring more than one internal IP address to fully 
> > disambiguate the behavior of "non-deterministic" NATs is 
> problematic. 
> > So perhaps precise detection is not feasible in many cases.
> >
> > The question I have is whether the purpose of BEHAVE is to 
> specify an 
> > ideal NAT's behavior and then to provide usage guidelines for 
> > applications working through a compliant set of NATs, or to 
> recommend 
> > NAT behaviors that increase the efficiency or reliability 
> of existing 
> > techniques.  If it's the latter case then BEHAVE shouldn't need its 
> > own usage document.  Any application which wishes to 
> function through 
> > non well-BEHAVEd NATs, or through non-traditional NAT 
> scenarios such 
> > as twice NAT, couldn't limit itself to techniques dependent upon 
> > BEHAVE compliance.
> 
> I think the purpose of BEHAVE is some combination of these 
> goals.  We need to 
> specify "ideal NAT behavior" strongly and coherently enough so that 
> applications have a definite, practical design path they can 
> take and be 
> certain of working reliably over future BEHAVE-compliant NATs 
> in all typical 
> deployment scenarios.  At the same time, it is important that 
> this "ideal NAT 
> behavior" be consistent and compatible with existing 
> widespread techniques 
> whenever possible.  Ultimately, we have to live with the fact 
> that with 
> legacy NATs, all bets are off - applications may or may not 
> work, and there's 
> no way an application can make itself 100% reliable with 
> existing NATs, so 
> that cannot be our goal.  But our goal can be to make sure 
> that future 
> applications can be (at least pretty darn close to) 100% 
> reliable with future 
> BEHAVE-compliant NATs; that should be our goal.  And to do 
> that it's clearly 
> important for us to specify exactly how applications can best 
> take advantage 
> of the more predictable behavior of well-BEHAVEd NATs.
> 
> Cheers,
> Bryan
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Bryan Ford <[email-masked]>
Date: Tue, 1 Mar 2005 02:49:17 -0800 (PST)

Hi Francois,

>   I don't think we should mandate any of this.

Agreed on all points.