Subject: Re: [rtcweb] I-D Action: draft-muthu-behave-consent-freshness-03.txt - ICE lite?

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Feb 2013 08:00:19 +0000

Hi,

The draft does mention ICE lite in the "Design Considerations" section, but not elsewhere in the document.

So, when the consent freshness mechanism is used, and one endpoint is ICE lite, I assume it would not send consent STUN requests, but only receive them. Or?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Muthu Arul Mozhi Perumal (mperumal)
Sent: 26. helmikuuta 2013 17:07
To: [email-masked]
Subject: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt

WG,

This draft was presented in RTCWEB during IETF 83.5 and 84 and was discussed earlier in the BEHAVE and RTCWEB mailing lists. Most of the comments received and consensus reached so far have been incorporated (as a result the draft has been trimmed). It now also has a section on the W3C API implications.

Is the draft heading in the right direction? Given that it just describes a STUN usage for performing consent freshness and liveness test and provides recommendations for the W3C APIs, would RTCWEB be a better home for this draft?

Comments welcome.

- Authors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 25, 2013 11:57 PM
To: [email-masked]
Subject: I-D Action: draft-muthu-behave-consent-freshness-03.txt

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

	Title           : STUN Usage for Consent Freshness
	Author(s)       : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Ram Mohan Ravindranath
                          Hadriel Kaplan
	Filename        : draft-muthu-behave-consent-freshness-03.txt
	Pages           : 7
	Date            : 2013-02-25

Abstract:
   Verification of peer consent before sending traffic 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-03

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

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
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Feb 2013 08:18:30 -0800

> So, when the consent freshness mechanism is used, and one endpoint is ICE lite, I assume it would not send consent STUN requests, but only receive them. Or?

Yeah, good call.  An ICE lite endpoint never generates checks, and I
expect that this doesn't change that characteristic.  It should
probably say as much.

(The main reason ICE lite is mentioned in considerations is that some
of the options discussed were eliminated on the basis of having to
interoperate with an ICE lite endpoint.)

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 28 Feb 2013 17:47:35 +0000

|Yeah, good call.  An ICE lite endpoint never generates checks, and I
|expect that this doesn't change that characteristic.  It should
|probably say as much.

Sure, will clarify in the next revision.

|(The main reason ICE lite is mentioned in considerations is that some
|of the options discussed were eliminated on the basis of having to
|interoperate with an ICE lite endpoint.)

Exactly.

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:[email-masked]]
|Sent: Thursday, February 28, 2013 9:49 PM
|To: Christer Holmberg
|Cc: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
|Subject: Re: [rtcweb] I-D Action: draft-muthu-behave-consent-freshness-03.txt - ICE lite?
|
|On 28 February 2013 00:00, Christer Holmberg
|<[email-masked]> wrote:
|> So, when the consent freshness mechanism is used, and one endpoint is ICE lite, I assume it would
|not send consent STUN requests, but only receive them. Or?
|
|Yeah, good call.  An ICE lite endpoint never generates checks, and I
|expect that this doesn't change that characteristic.  It should
|probably say as much.
|
|(The main reason ICE lite is mentioned in considerations is that some
|of the options discussed were eliminated on the basis of having to
|interoperate with an ICE lite endpoint.)