Re: [AVT] Token draft rev'ed (other than security)

[Jonathan Lennox <[e-mail]>]

On Nov 9, 2010, at 11:06 AM, Ali C. Begen (abegen) wrote:

>> This is a failure case that clients may need to be prepared to deal with.  If this happens, the client needs to send a new port
>> mapping request.  It might be a good idea to say that in this case the client SHOULD send the new port mapping request from
>> *c1, and use it before *c1's NAT bindings expire.  (Essentially, behind an Arbitrary Address Pooling NAT, the client will end up
>> behaving as though Tokens were really Cookies, as a fallback mechanism following failures.)
> 
> Rather than saying like this, we encouraged to have ct=c0=c1. Is not this a better approach? It deals with this problem in the first place.

I think "send the port mapping request from c1" and "ct=c1" are two ways of saying the same thing.  The one tricky thing is that if you got your (now-expired) Token from a previous session with the same server, your new c0=c1 is different than your old c0=c1, I think.

The other issue that for fully BEHAVE-compliant NATs, ct=c0=c1 is simply good practice in order to reduce the number of NAT bindings; however, for non- or conditionally-BEHAVE compliant NATs, there are cases where it's actually required.  It's possibly worth explicating this in the draft, probably in terms of the RFC 4787 language.


>> If your NAT has both Arbitrary Address Pooling and Address and Port-Dependent Mapping, though, this still may not work if
>> PT != P3.  (Such a NAT is not BEHAVE-compliant, since Endpoint-Independent Mapping is a MUST in RFC 4787.)  Does PT = P3
>> therefore need to be SHOULD strength, rather than MAY?  At any rate, this should probably be pointed out.
> 
> I am fine with making it SHOULD, but if the NAT is not compliant, who knows what other stupid things it will do. One thing we need to note is that P3 is (often) different for different unicast sessions (the feedback target on the server), so in this case, the port in the "a=portmapping-req" line will be equal to the port in the "a=rtcp:" line for the SSM session (which is fine of course).

I don't quite follow this, but I guess your point is that (at least in some architectures) different sessions should have different P3 values, but share the same PT value?  I see how that complicates things.

Fair point about stupid NATs.

I think that this draft achieves the goal of "simple topologies with well-behaved NATs work well; broken NATs or overly-complicated architectures work no worse than Cookies."  So that's good. 

--
Jonathan Lennox
[e-mail]