Subject: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Nov 2013 15:58:42 +0100

Hi,

Here are my review comments on draft-ietf-rtcweb-stun-consent-freshness-00

1. General:
I understood one reason for splitting this out in its own document is
that we might have other future users of this mechanism. Thus I think it
should be written to be less WebRTC specific. It is appropriate to use
WebRTC as motivation for requirements etc, but the actual description of
the mechanism should be done in a neutral way.

2. Section 1.
   When a session is first established, WebRTC implementations are
   required to perform STUN connectivity checks as part of ICE
   [RFC5245].  That initial consent is not described further in this
   document.

When generalizing this, I think it is important to make clear that it is
assumed that ICE is being used for that initial consent.

3. Section 1:
"This document describes a new STUN usage with a request and response
   which verifies the remote peer consents to receive traffic, and
   detects loss of liveness."

I am missing a word after "request and response", transaction or
messages maybe?

4. Section 3:
 A
   response is necessary both for consent to continue sending traffic,
   as well as to ensure connectivity.

Is verify rather than "ensure" better?

5. Section 4:
   Consent freshness serves as a circuit breaker (so that if the path or
   remote peer fails the WebRTC browser stops sending all traffic on
   that remote peer), determining session liveness serves the purpose of
   notifying the application of connectivity failure so that the
   application can take appropriate action.

traffic on/traffic to

What is the definition of a peer here? What scope does the stop sending
have?

6. Section 4:
   1.  A consent timer, Tc, whose value is determined by the browser.
       This value MUST be 15 seconds.

I see a contradiction here, should it be determined by the browser or be
15 s? If it is 15, can you please motivate why it is this value, or
point to where it is motivated?

7. Section 4:
   If a valid STUN Binding Response is received, the consent timer is
   reset and fires again Tc seconds later.

Is it reset to the time of receiving it or the time of sending the
initial request this is the response for?

8. Section 4:
   If a valid STUN Binding Response is not received after 500ms, the
   STUN Binding Request is retransmitted (with the same Transaction ID
   and all other fields).  As long as a valid STUN Binding Response is
   not received, this retransmission is repeated every 500ms until Tf
   seconds have elapsed or a valid response is received.

So no exponential back-off on the retransmission timer. I think that is
fine. However, I think it do require you to expand a bit on what happens
when one gets multiple response on the same Transaction ID. For example
additional responses do they or do they not reset the Tc timer?

Then I wonder about the cases where the RTT is above 500 ms, should one
then scale this factor to be once per RTT?

9. Section 4:
"with the same Transaction ID"

Why not use a new transaction ID for each sent packet? It would allow
tracking loss and determine RTT more reliable. All for the small cost of
keeping track of slightly more Transaction IDs?

10. Section 4.
   Liveness timer: If no packets have been received on the local port in
   Tr seconds, the WebRTC browser MUST inform the JavaScript that
   connectivity has been lost.  The JavaScript application will use this
   notification however it desires (e.g., cease transmitting to the
   remote peer, provide a notification to the user, etc.).  Note the
   definition of a received packet is liberal, and includes an SRTP
   packet that fails authentication, a STUN Binding Request with an
   invalid USERNAME or PASSWORD, or any other packet.

I think this requires some considerations in regards to RTT. If the RTT
is 700 ms, high for a real-time app but not unheard of at all. Then a Tr
= 1 second would fire on a single loss.

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: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 14 Nov 2013 17:23:42 +0000

Hi Magnus,

Thanks for your comments. Please see inline for responses.

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Date: Tuesday, 12 November 2013 8:28 PM
To: "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Cisco Employee
<[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, 12 November 2013 8:27 PM

>the mechanism should be done in a neutral way.

Ok. We will add text in Abstract/Introduction to reflect this point.

>assumed that ICE is being used for that initial consent.

Yes. We will add text to make it clear.

>I am missing a word after "request and response", transaction or

NEW:
This document describes a new STUN usage with a request and response
messages which verifies the remote peer consents to receive traffic, and
detects loss of liveness.

>Is verify rather than "ensure" better?

Agree will replace with "verify"

>   application can take appropriate action.

Thanks. will fix this.

>
>What is the definition of a peer here?

Peer is the sink for the traffic originated from the sender for that flow
(5 tuple). If a browser uses different 5 tuple for each stream(Audio,
video, data) it sends then it should do consent for each flow. If it uses
same 5-tuple (mux case) then there will be only one consent.

>What scope does the stop sending
>have?

The stream that is being sent on a flow(5 tuple) for which a consent has
failed will be stopped. If all the streams are muxed on a same 5 tuple the
entire traffic will be stopped.

>point to where it is motivated?

The default value of 15 was some thing that EKR and Justin gave us based
on the implementation/testing and fine tuning they have done on their
browsers. I agree we can have some text around it that explains how this
number is arrived. We will add the same.

>initial request this is the response for?

Consent timer is reset to the time of receiving it

>additional responses do they or do they not reset the Tc timer?

Additional responses MUST reset the Tc timer.

>keeping track of slightly more Transaction IDs?

Yes, new transaction ID will help to determine the packet loss and RTT.

>= 1 second would fire on a single loss.

Ok.  will start a discussion for this item in a separate email.

Regards,
Ram

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Nov 2013 10:02:16 +0100

Hi,

Removing things where I am in agreement or like your response.

> detects loss of liveness.

Isn't it either "which verifies the remote peer's consent to" or "which
verifies that the remote peer consents to"?

> same 5-tuple (mux case) then there will be only one consent.

Please be explicit about this. I think it is easy to interpret that this
would apply to all flows from one end-point to a given destination address.

> entire traffic will be stopped.

I am fine with this, as long as the document is explicit about this
being the scope.

> number is arrived. We will add the same.

Good, I think it is important we understand the considerations of why
this is a reasonable choice.

> Additional responses MUST reset the Tc timer.

Okay, that appears fine.

>> then scale this factor to be once per RTT?

What about this question?

> Yes, new transaction ID will help to determine the packet loss and RTT.

Yes, so what is preferable here? Doing cloned retransmission, or
generating new TIDs for each outgoing request?

> Ok.  will start a discussion for this item in a separate email.

Good

Cheers

Magnus Westerlund

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Nov 2013 10:07:48 -0800

I have a meta-question about consent freshness, which is whether it is still necessary if  DTLS/SRTP is both mandatory both to implement as well as to use (e.g. we could use DTLS heartbeat extension RFC 6520 instead).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Nov 2013 10:27:05 -0800

On 20 November 2013 10:07, Bernard Aboba <[email-masked]> wrote:
> I have a meta-question about consent freshness, which is whether it is still
> necessary if  DTLS/SRTP is both mandatory both to implement as well as to
> use (e.g. we could use DTLS heartbeat extension RFC 6520 instead).

Funny you should mention that.  You are by no means the first person
to ask this question.

In fact, I went so far as to write up a draft during the WebRTC
meeting last week.  Dan and I have been going back and forth on a
number of aspects, but I think that it's at least in good enough shape
to put up for wider discussion.

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

Overall, I think that this is cleaner.  The main advantage is that any
authenticated data counts toward refreshing consent.  That means zero
overhead in many common cases.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Nov 2013 10:31:37 -0800

> I think that it's at least in good enough shape to put up for wider discussion.

[BA] I have to agree that it is worth discussing, particularly given the potential for zero additional overhead.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 26 Nov 2013 10:34:10 +0000

Hi Bernard,

Yes, this needs to be discussed further. With DTLS, there is no need to send consent checks if authentic SRTP/SRTCP packets are being received.  we may also want to compare DTLS heartbeat mechanism with STUN consent. Some of my observations:

[1] Remote peer may or may not support DTLS heartbeat. 
[2] DTLS heartbeat can only be sent if remote peer accepts heartbeat request. 

[1] and [2] can be solved by mandating WebRTC endpoints to support consent.

[3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Generating arbitrary content (payload and padding 40 bytes), encrypting it). Though this may not a concern since heartbeat will only be sent when authenticated packets are not received.

[4] DTLS heartbeat doubles the timer value at each retransmission but with STUN consent retransmission is repeated every 500ms. There seems to be no application level control on the retransmission mechanism used by OpenSSL DTLS implementation. 

[5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS heartbeat API. 

[4] and [5] need enhancement in OpenSSL.

-Tiru.

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, November 21, 2013 12:02 AM
To: Martin Thomson
Cc: Magnus Westerlund; [email-masked]; [email-masked]; Eric Rescorla
Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Nov 2013 12:14:43 +0100

> [4] and [5] need enhancement in OpenSSL.
As you say: This is just an implementation issue of one particular implementation, not an issue with the protocol itself...

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Nov 2013 10:13:00 -0800

These are good observations.

> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.

Yes, that would be the plan.  We would also have to force the
inclusion of peer_allowed_to_send(1) in the extension, lest things get
perverse.

> [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Generating arbitrary content (payload and padding 40 bytes), encrypting it). Though this may not a concern since heartbeat will…

I'm thinking: a) not a concern because it's only a factor if you
aren't sending, and b) not a concern because it's not a lot of work to
generate an authenticated packet.  Less work I think if you are using
AES-GCM modes.

> [4] DTLS heartbeat doubles the timer value at each retransmission but with STUN consent retransmission is repeated every 500ms. There seems to be no application level control on the retransmission…

That's a good point, I'll have to check to see if we need to update
6520, or whether just saying to avoid retransmission is sufficient.
(I think the latter, but don't care too much.)

> [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS heartbeat API.

This is true to exactly the same extent for both forms.  Some STUN
implementations don't allow for the sending of a single check, they
also do the full exponential backoff thing.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 27 Nov 2013 02:06:41 +0000

Are there cases where you won't do ICE but do DTLS, for WebRTC? If not, I think you can combine the best of both:
- The initial consent is established by ICE connectivity checks already.
- The receipt of any authenticated packet, including DTLS heartbeat, grants 
  you consent to send more packets.
- If you doesn't receive any packet and consent is about to expire, send a 
  STUN binding request that is comparatively less CPU intensive.

Minimal overhead overall :)

Muthu

|-----Original Message-----
|From: rtcweb [mailto:[email-masked]] On Behalf Of Martin Thomson
|Sent: Tuesday, November 26, 2013 11:43 PM
|To: Tirumaleswar Reddy (tireddy)
|Cc: [email-masked]; [email-masked]
|Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
|
|These are good observations.
|
|On 26 November 2013 02:34, Tirumaleswar Reddy (tireddy)
|<[email-masked]> wrote:
|> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.
|
|Yes, that would be the plan.  We would also have to force the
|inclusion of peer_allowed_to_send(1) in the extension, lest things get
|perverse.
|
|> [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Generating arbitrary content
|(payload and padding 40 bytes), encrypting it). Though this may not a concern since heartbeat will
|only be sent when authenticated packets are not received.
|
|I'm thinking: a) not a concern because it's only a factor if you
|aren't sending, and b) not a concern because it's not a lot of work to
|generate an authenticated packet.  Less work I think if you are using
|AES-GCM modes.
|
|> [4] DTLS heartbeat doubles the timer value at each retransmission but with STUN consent
|retransmission is repeated every 500ms. There seems to be no application level control on the
|retransmission mechanism used by OpenSSL DTLS implementation.
|
|That's a good point, I'll have to check to see if we need to update
|6520, or whether just saying to avoid retransmission is sufficient.
|(I think the latter, but don't care too much.)
|
|> [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS
|heartbeat API.
|
|This is true to exactly the same extent for both forms.  Some STUN
|implementations don't allow for the sending of a single check, they
|also do the full exponential backoff thing.
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Nov 2013 07:38:51 +0000

Hi,

> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.

I thought we were going to do that anyway - no matter what consent mechanism we use.

Regards,

Christer

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 27 Nov 2013 07:52:24 +0000

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2013 1:09 PM
> To: Martin Thomson; Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]; [email-masked]

If DTLS based consent mechanism is picked then both peers must support DTLS heartbeat and willing to exchange DTLS heartbeat request/response.

Cheers,
-Tiru.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Nov 2013 08:02:29 +0000

Hi,

> If DTLS based consent mechanism is picked then both peers must support DTLS heartbeat and willing to exchange DTLS heartbeat request/response.

How is that different from using ICE for consent? That also require support from both peers, doesn't it?

Regards,

Christer

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 27 Nov 2013 13:02:26 +0000

> Sent: Wednesday, November 27, 2013 1:32 PM
> To: Tirumaleswar Reddy (tireddy); Martin Thomson
> > If DTLS based consent mechanism is picked then both peers must support DTLS
> heartbeat and willing to exchange DTLS heartbeat request/response.
> 
> How is that different from using ICE for consent? That also require support
> from both peers, doesn't it ?

Yes, ICE for consent also requires support from both peers. 

-Tiru.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Nov 2013 09:24:06 -0800

> Minimal overhead overall :)

I disagree.  One of the merits of using the DTLS handshake to
establish initial consent, authenticated packets to maintain it, and
the DTLS heartbeat in the absence of authenticated packets is that it
is all DTLS.  As someone who writes software, being able to keep all
the logic constrained to a single software module is a significant
improvement.

I don't believe the CPU cost of a DTLS heartbeat to be expensive
enough to justify changes to this.  Given that you aren't using the
CPU for crypto at all when you send it, I'm pretty sure that the CPU
cost can be borne.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 27 Nov 2013 17:38:04 +0000

|-----Original Message-----
|From: Martin Thomson [mailto:[email-masked]]
|Sent: Wednesday, November 27, 2013 10:54 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Tirumaleswar Reddy (tireddy); [email-masked];
[email-masked]
|Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
|
|On 26 November 2013 18:06, Muthu Arul Mozhi Perumal (mperumal)
|<[email-masked]> wrote:
|> Are there cases where you won't do ICE but do DTLS, for WebRTC? If not, I think you can combine the
|best of both:
|> - The initial consent is established by ICE connectivity checks already.
|> - The receipt of any authenticated packet, including DTLS heartbeat, grants
|>   you consent to send more packets.
|> - If you doesn't receive any packet and consent is about to expire, send a
|>   STUN binding request that is comparatively less CPU intensive.
|>
|> Minimal overhead overall :)
|
|I disagree.  One of the merits of using the DTLS handshake to
|establish initial consent, authenticated packets to maintain it, and
|the DTLS heartbeat in the absence of authenticated packets is that it
|is all DTLS.  As someone who writes software, being able to keep all
|the logic constrained to a single software module is a significant
|improvement.

Well, my point is, for WebRTC you can also do the same optimization by confining the logic to the STUN module -- both can establish and maintain consent without generating additional traffic for majority of the use-cases.

From a security perspective, I don't see a real advantage of one over the other.

Muthu

|
|I don't believe the CPU cost of a DTLS heartbeat to be expensive
|enough to justify changes to this.  Given that you aren't using the
|CPU for crypto at all when you send it, I'm pretty sure that the CPU
|cost can be borne.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Nov 2013 09:55:21 -0800

> From a security perspective, I don't see a real advantage of one over the other.

That's right, they are equivalent.  Unless you consider the risk of a
preimage attack on SHA-1 within the confines of the STUN message size
limit to be a realistic.  (I don't.)

Equivalence on security is only the first order bit upon which we decide.