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

> -----Original Message-----
> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
> Sent: Tuesday, November 09, 2010 8:54 AM
> To: Ali C. Begen (abegen)
> Cc: avt@ietf.org
> Subject: Re: [AVT] Token draft rev'ed (other than security)
> 
> I had a few other points on the draft, unrelated to security, that I noticed on my latest re-read.  If people agree with my
> conclusions about the behavior, I don't think any of them should block adoption of Tokens by the WG to replace cookies.
> 
> 
> First of all, for the Address Pooling NATs section, you assert that “As long as an internal host maintains an active mapping in
> the NAT, the same [external] IPv4 address is assigned to new connections.”  This is certainly a nice property — RFC 4787 calls
> it an IP address pooling policy of "Paired".  However, it's only RECOMMENDED by RFC 4787, not required.  Additionally,
> there's no keepalive on the *cT - PT connection, since as you mention the client can acquire a Token during initialization,
> which may be well before it joins any multicast groups.

That's why we encourage to use ct=c0=c1.

> Thus, if an Address Pooling NAT has an "Arbitrary" policy in RFC 4787's terminology, or if the binding expired, it's possible
> that the external mapping of *cT and the external mapping of *c1 will get assigned to different external IP addresses.  In this
> case, the Token acquired with *cT will be considered invalid by the server for requests from *c1, and Token Verification will
> fail.

Yes, it will fail. And the client will realize it needs to get a new one.

> 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.

> 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).

-acbegen

> 
> 
> Other minor points:
> 
> For the token, should there be a magic expiry time value, or other indication in the Port Mapping Response, that indicates
> that the Token is intended as for one use only?  Or do you just want to have a very short timeout for it, e.g. on the order of
> seconds?
> 
> 
> I need to think about this some more to be sure, but it may be necessary to say that servers SHOULD NOT set Token expiry
> times to be less than the Regular RTCP Interval for their associated sessions.
> 
> 
> Would there be any benefit to having separate RAMS error codes for the various reasons why a Token might be invalid
> (expired/wrong source IP/unrecognized)?  I guess the question is whether either a client might want to take different action
> in the different cases, or if it would significantly help to diagnose problems.
> 
> 
> On Nov 8, 2010, at 5:23 PM, Ali C. Begen (abegen) wrote:
> 
> > After the session, we got together to agree on the text for the attacks Magnus described in the session. I rev'ed the draft:
> > http://www.ietf.org/id/draft-begen-avt-token-for-portmapping-03.txt
> >
> > if you have remaining concerns, please speak up.
> >
> > Chairs,
> >
> > Please confirm the next step to make this draft move as fast as possible.
> >
> > Thanks,
> > -acbegen
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
> 
> --
> Jonathan Lennox
> jonathan@vidyo.com
> 