Subject: [AVT] Token draft rev'ed (security cons.)

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 8 Nov 2010 01:23:32 -0800

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 18:20:38 +0800

> if you have remaining concerns, please speak up.

After some talking with Ali and Dan I think the solution to the issue is
a very reasonable one. Multicast support basically requires you to have
source address validation or you have worse attacks that can happen. If
the server are uncertain of the support you can basically invalidate the
token for each request forcing it into a behavior with very similar
property of the cookie mechanism.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 8 Nov 2010 02:56:28 -0800

The proposed solution and the update to the draft look good.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Monday, November 08, 2010 6:21 PM
> To: IETF AVT WG
> Subject: Re: [AVT] Token draft rev'ed (security cons.)
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 8 Nov 2010 19:53:32 -0500

I think this largely addresses the security concerns that were raised the session.  However, I have one point about them that I think could use further amplification.

A Token is valid not just for the client that requested it, but for every client that's behind the same NAT (or more specifically, that is assigned mappings from the same external IP address).  The new language in the security considerations section — “if the attacker acquires a valid Token for a victim” — may wish to mention this explicitly.  In home NAT scenarios this may not be a very serious threat (there are many easier ways to achieve a DoS attack on another member of your household), but for enterprise or large-scale NATs this may be more of a concern.  Of course, such networks are also more likely to have source address verification on the NAT side as well.

I don't think that turning down the expiration times on Tokens ameliorates this version of the threat.

There are a few other points I had on the draft, unrelated to the security issue, that I noticed on my latest re-read; I'll bring these up in a separate e-mail to keep threading cleaner.

--
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 8 Nov 2010 19:53:34 -0500

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.

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.

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

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.

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.

--
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Nov 2010 10:17:34 +0800

> I don't think that turning down the expiration times on Tokens ameliorates this version of the threat.

No, you are correct. That issue also needs to be mentioned. I don't
expect the combination with multicast and large scale NAT is likely, but
the proper warning needs to be raised. An attack within the same NATed
lan can in most cases be solved .

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 8 Nov 2010 19:06:49 -0800

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Tuesday, November 09, 2010 8:54 AM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]
> 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.
> 
>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 8 Nov 2010 22:25:58 -0500

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

> 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 sess…

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
[email-masked]

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 8 Nov 2010 19:54:52 -0800

> Sent: Tuesday, November 09, 2010 11:26 AM
> 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.

C0, c1 and ct are up to you to choose. You can stick with the same values (if you know how to handle undesired RTP packets in case you receive something from an old session).

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

This looks like something Dan or you can propose some text for. And I will be happy to just insert it ;)
 
> > 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.

The feedback port may need to be different (see the RAMS for discsussion). It is largely because if the source SSRCs cannot be guaranteed to be unique, you gotta choose different feedback targets.
 
> 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.

Yup.
-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Wed, 10 Nov 2010 11:38:53 +0800

> 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 ad…
...
> Other minor points:
...
> 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…

On a related issue, would it make sense to define a Token Verification Failed RTCP feedback message in this draft? It seems strange that I can request and use a token using RTCP-based mechanisms, but feedback that my token is invalid comes using a different mechanism.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 9 Nov 2010 23:26:48 -0800

...
> On a related issue, would it make sense to define a Token Verification Failed RTCP feedback message in this draft? It seems
> strange that I can request and use a token using RTCP-based mechanisms, but feedback that my token is invalid comes using
> a different mechanism.

OK we can do this. Right now, we implied this by setting the expiration time to zero, but a new message type is as straightforward.

-acbegen