Subject: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-01.txt

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 17 Jul 2012 07:37:53 +0000

The draft has been updated based on the mailing list discussions and Eric's security presentation at the RTCWEB interim meeting. The sections that have been updated/added:

1. Abstract
   Adds session liveness

2. Introduction 
   Adds session liveness

3. Definitions
   Defines session liveness

4. Solution Overview
   Discusses the combined consent freshness and session liveness 
   test (slide "Combined Consent/Liveness Proposal II" from the 
   RTCWEB interim).

5. Design Considerations
   Discusses the pros and cons of reusing the STUN Binding request/response

6. Open Items
   Lists the current open issues.

While we have been discussing on a separate ICE spec/profile for RTCWEB, I would like to close on the smaller problem of our next steps for this draft. Issues we need consensus on to move forward:

1. Should we reuse the STUN Binding request/response for consent freshness and session liveness, considering interoperability with existing ICE and ICE-lite implementations even at the incurred cost of the SHA-1 computation for the message integrity on gateways? Seems to be a "yes" from the mailing list discussions so far. Any concerns?

2. Where does this draft really belong to? Considering that the use-case is relevant to WebRTC and we many not significantly change any BEHAVE protocol, should it be resubmitted to RTCWEB?

Muthu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 16, 2012 9:39 PM
To: [email-masked]
Subject: I-D Action: draft-muthu-behave-consent-freshness-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : STUN Usage for Consent Freshness and Session Liveness
	Author(s)       : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Hadriel Kaplan
	Filename        : draft-muthu-behave-consent-freshness-01.txt
	Pages           : 9
	Date            : 2012-07-16

Abstract:
   Verification of peer consent is necessary in WebRTC deployments to
   ensure that a malicious JavaScript cannot use the browser as a
   platform for launching attacks.  A related problem is session
   liveness.  WebRTC applications may want to detect connection failure
   and take appropriate actions.  This document describes a STUN usage
   that enables a WebRTC browser to perform the following on a candidate
   pair ICE is using for a media component after session establishment:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-muthu-behave-consent-freshness-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-muthu-behave-consent-freshness-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2012 09:38:48 -0700

>    test (slide "Combined Consent/Liveness Proposal II" from the

This looks like a reasonable start.  I'm not sure why there are so
many other sections in the document.  It was pretty clear to me that
consensus was reached around the use of Binding requests.  I'd suggest
that you trim the document down to just this section if you intend for
it to be adopted.

There needs to be more detail about the nature of the consent/liveness
test with respect to the observed round trip time and packet loss.
Based on the discussions at the interim, it was clear that the
complete 60+ second check time was unnecessary for consent/liveness
refresh.

>    Lists the current open issues.

I can see how you might reach the conclusion that consent is not
needed for RTCP flows, but I don't see the benefit of creating a
special case for it.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 18 Jul 2012 15:33:14 +0000

|This looks like a reasonable start.  I'm not sure why there are 
|so many other sections in the document.  It was pretty clear to 
|me that consensus was reached around the use of Binding requests. 
|I'd suggest that you trim the document down to just this section 
|if you intend for it to be adopted.

These sections define a new STUN Consent method. The document will be trimmed if we declare consensus to reuse the STUN Binding method (hopefully after IETF-84, one way or other).

|There needs to be more detail about the nature of the consent/liveness
|test with respect to the observed round trip time and packet loss.

Agree. We will add them in the next revision.

|Based on the discussions at the interim, it was clear that the
|complete 60+ second check time was unnecessary for consent/liveness
|refresh.

STUN requests are retransmitted 7 times by default. With an RTO of 500 ms the transaction would fail after 39.5 ms if there is no response. Our current thinking is this could be limited to 5 retransmissions for consent freshness, so that the transaction fails after 15.5 sec. Does it sound reasonable?

|I can see how you might reach the conclusion that consent is not
|needed for RTCP flows, but I don't see the benefit of creating a
|special case for it.

Yes, the only benefit I can think of is, it reduces some network traffic. 

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:[email-masked]]
|Sent: Tuesday, July 17, 2012 10:09 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-01.txt
|
|On 17 July 2012 00:37, Muthu Arul Mozhi Perumal (mperumal)
|<[email-masked]> wrote:
|> 4. Solution Overview
|>    Discusses the combined consent freshness and session liveness
|>    test (slide "Combined Consent/Liveness Proposal II" from the
|>    RTCWEB interim).
|
|This looks like a reasonable start.  I'm not sure why there are so
|many other sections in the document.  It was pretty clear to me that
|consensus was reached around the use of Binding requests.  I'd suggest
|that you trim the document down to just this section if you intend for
|it to be adopted.
|
|There needs to be more detail about the nature of the consent/liveness
|test with respect to the observed round trip time and packet loss.
|Based on the discussions at the interim, it was clear that the
|complete 60+ second check time was unnecessary for consent/liveness
|refresh.
|
|> 6. Open Items
|>    Lists the current open issues.
|
|I can see how you might reach the conclusion that consent is not
|needed for RTCP flows, but I don't see the benefit of creating a
|special case for it.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jul 2012 09:55:59 -0700

> STUN requests are retransmitted 7 times by default. With an RTO of 500 ms the transaction would fail after 39.5 ms if there is no response. Our current thinking is this could be limited to 5 retran…

Not really.  You have a liveness timer that triggers this at (as low
as) 500ms.  Are you suggesting that I wait at least 16s to determine
that a peer is not sending anything?  Can the liveness timer trip
again during this process?

These aren't hard questions to resolve, but they do need some
resolution (in this model).  I have another model in mind.

--Martin