Subject: [rtcweb] Consent alternative

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Nov 2013 09:55:09 -0800

I know that I've been a fan of consent via ICE, but with the decision
in Berlin to move to DTLS only, several of us have observed that
perhaps RFC 6520 might be a better alternative.

We've put together an exploration of the idea here:

http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00

The best part of this is that it changes the dynamics (for the better,
I think).  You don't need to send extra packets if you are actively
using the flow.  That means that 1:1 sessions won't need to spend
extra cycles or bytes on keeping the session live.

There are some gotchas for multiparty sessions, but I believe those to
be manageable.

---

From: tim panton <[email-masked]>
Date: Fri, 22 Nov 2013 10:08:21 -0800

> There are some gotchas for multiparty sessions, but I believe those to

I have misgivings about this - It feels to me to force a mixing of layers in the 
packet handling - At the moment in the implementation I’m familiar with, the ICE/DTLS/SRTP 
state machines are almost completely isolated. This proposal seems (at first glance)
to make them intertwine in a quite complex way - consent is generated (if I understand it correctly)
by any of the layers. Likewise each of the layers needs to know if the others have generated consent 
granting packets. 

If we are to blur the boundaries like this, we should go the whole hog and get some real benefits - like
for example remove some round-trips in session establishment by (say) carrying the DTLS hello in the
same STUN packet as has ICE USE-CANDIDATE set - for example.

I’m against including this sort of change at this stage in the standards process.

T.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Nov 2013 10:28:08 -0800

> This proposal seems (at first glance) to make them intertwine in a quite complex way 

[BA] Might I point out that we already have two mechanisms that affect a sender's ability to continue to send to a given receiver: consent and circuit breakers.  So the complexity you speak of is already there.  For example, the studies we have seen so far raise questions about whether circuit breakers are very likely to fire prior to consent loss, potentially shutting off the packet flow even in situations where consent would be provided.   In those situations, the ICE consent mechanism serves merely to add overhead while providing little or no additional protection.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Nov 2013 10:41:07 -0800

Actually, this removes some of the complication.  At worst, it just moves it.

This concentrates all of the logic at the DTLS layer.  If you choose
to treat it so, ICE no longer needs to play any role in determining
consent.

DTLS already has a consent mechanism in place (that's the function of
the cookie in the handshake, a feature we don't tend to use when
running ICE).   This expands that to include an ongoing process.  The
only complications come from the interaction between DTLS and SRTP, a
relationship that is already complicated somewhat on the keying layer.

I don't know whether anyone implementing DTLS-SRTP also implements
DTLS renegotiation and EKT at the same time, but those are the areas
where things get tricky.  Otherwise, you have a DTLS (or DTLS-SRTP)
layer that manages consent.

---

From: tim panton <[email-masked]>
Date: Fri, 22 Nov 2013 10:41:39 -0800

> [BA] Might I point out that we already have two mechanisms that affect a sender's ability to continue to send to a given receiver: consent and circuit breakers.  So the complexity you speak of is a…

I need to think about that some more, but my first feeling is that the proposal deepens the interdependency because it means each sender has to notify a central timer to indicate that a consent-requesting packet has been sent and kill the deadman’s handle on the DTLS keep-alive. The ICE mechanism is clearer - you send the packets anyway with no dependency on whatever else has been sent.

I also need to think about how RTCP plays into this (which isn’t mentioned in the draft, and probably should be).

This whole discussion makes me yearn for a cleaner non-layered protocol - like RFC 5456 - but if we are to have layers we should keep them apart as far as possible.

T.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Nov 2013 10:44:01 -0800

On 22 November 2013 10:41, tim panton <[email-masked]> wrote:
> The ICE mechanism is clearer - you send the packets anyway with no dependency on whatever else has been sent.

If you can tolerate the additional overhead, send a heartbeat when
your timer pops.  We're not prohibiting it.  It's just suboptimal.

> I also need to think about how RTCP plays into this (which isn’t mentioned in the draft, and probably should be).

Someone already pointed that out to me.  RTCP is authenticated just
like RTP, so if they are on the same flow, they both refresh consent.
If they are on separate flows, consent is independent.

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 25 Nov 2013 15:43:52 +0100

Il giorno Fri, 22 Nov 2013 10:41:07 -0800

> to treat it so, ICE no longer needs to play any role in determining

Apologies for this late comment, but I only now read the draft. I agree
with you that it makes more sense to handle content freshness in DTLS,
especially since, as the draft says, you wouldn't send data until the
DTLS handshake has completed anyway, and this would remove the need
for all those connectivity checks. The only doubt I have is sec.3: is
specifying an ALPN really necessary, if "any DTLS message is
sufficient to refresh consent"? are you envisaging a scenario where it's
the DTLS stack that filters unwanted incoming packets (e.g., SCTP where
you only want RTP), or would it be there for a different reason?

Thanks,
Lorenzo

> >> I know that I've been a fan of consent via ICE, but with the
> >> decision in Berlin to move to DTLS only, several of us have
> >> observed that perhaps RFC 6520 might be a better alternative.
> >>
> >> The best part of this is that it changes the dynamics (for the
> >> better, I think).  You don't need to send extra packets if you are
> >> actively using the flow.  That means that 1:1 sessions won't need
> >> to spend extra cycles or bytes on keeping the session live.
> >>
> >> There are some gotchas for multiparty sessions, but I believe
> >> those to be manageable.
> >
> > I have misgivings about this - It feels to me to force a mixing of
> > layers in the packet handling - At the moment in the implementation
> > I’m familiar with, the ICE/DTLS/SRTP state machines are almost
> > completely isolated. This proposal seems (at first glance) to make
> > them intertwine in a quite complex way - consent is generated (if I
> > understand it correctly) by any of the layers. Likewise each of the
> > layers needs to know if the others have generated consent granting
> > packets.
> >
> > If we are to blur the boundaries like this, we should go the whole
> > hog and get some real benefits - like for example remove some
> > round-trips in session establishment by (say) carrying the DTLS
> > hello in the same STUN packet as has ICE USE-CANDIDATE set - for
> > example.
> >

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2013 09:21:05 -0800

On 25 November 2013 06:43, Lorenzo Miniero <[email-masked]> wrote:
> The only doubt I have is sec.3: is

The reason that this section is there is to place some constraints
around to consent to limit its scope.  As more and more protocols
enable (D)TLS, there is an increasing chance that the endpoint you are
talking to speaks (D)TLS, but isn't actually willing to converse with
the protocol you expect.  Rather than provide carte blanche consent,
this allows a data channels-only server to indicate that it's not
interested in SRTP, or your database server from being put on the
other end of a data channel firehose.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Nov 2013 14:40:03 +0100

> There are some gotchas for multiparty sessions, but I believe those to

Hi,

I have looked briefly on this and wonder if this isn't vulnerable to
active attacks from a attacker (Alice) that likes to use a set of WebRTC
browsers, including (Bob) to generate DDOS traffic towards the target
(Charlie).

So Alice has a web-service which see has attracted a user base or
subverted an existing one for her purpose. The users of said web-service
includes Bob.

So Alice gets Bob's browser to establish a PeerConnection with Alice,
establishing an DTLS security context between them. Then using the
regular signaling Alice triggers an ICE reneg, to move the transport
address target for the Alice to Bob PC to become between Bob and
Charlie. This will require that Alice can intercept or spoof binding
requests response to the Bob's binding requests, especially anyone
promoting it for use so that Bob thinks the ICE reneg succeeds with
Charlie's transport address.

When that has happened, Alice can send periodically Bob DTLS messages
with source address spoofed like they come from Charlie's transport
address to maintain consent. Alice also can use the Stats API and the
HTTP/Websocket connection to Alice web service to forge DTLS protected
RTCP report block messages for the traffic Bob sends to Charlie.

Comparing the ICE based mechanism and the DTLS based consent mechanisms
I would draw the following conclusions.

1. If one doesn't have any chance to intercept STUN binding requests at
all, they are equally secure.

2. If the attacker has some limited or very expensive method for
intercepting Bob's STUN binding requests, then he might be able to mount
the above attack using DTLS consent as he only needs interception
initially when moving Bob to the target, compared to continuously as
long as he like to maintain the attack using the ICE based method.

Cases when this might apply is when Bob are in a poorly protected shared
network and Alice or Alice agent likes to leave the network after having
initiated the attack, rather than have to remain.

This change of properties is due to that the consent is associated with
the DTLS connections security context, rather than constant return
routability with random token property that ICE has.

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