Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

From: [email-masked]
Date: Thu, 10 Apr 2014 20:37:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

        Title           : STUN Usage for Consent Freshness
        Authors         : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Ram Mohan Ravindranath
                          Tirumaleswar Reddy
                          Martin Thomson
	Filename        : draft-ietf-rtcweb-stun-consent-freshness-02.txt
	Pages           : 8
	Date            : 2014-04-10

Abstract:
   To prevent sending excessive traffic to an endpoint, periodic consent
   needs to be obtained from that remote endpoint.

   This document describes a consent mechanism using a new STUN usage.
   This same mechanism can also determine connection loss ("liveness")
   with a remote peer.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 11 Apr 2014 05:00:39 +0000

Summary of changes in this revision

Addressed the comments received from the WG.
Removed the timers definition from solution overview and made the text
more generic.
Incorporated text from draft-thomson-rtcweb-consent.
Most of the text of solution overview is re-written however the idea is
still kept intact

Comments are welcome.

There is still some dangling reference (text) to SRTP/DTLS mechanism for
consent which we will modify in the next revision

Regards,
Authors

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, 11 April 2014 9:07 am
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-02.txt

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Apr 2014 06:52:07 +0000

Hi,

I think it would be good to have some text about usage of consent freshness when one entity is ICE lite.

And, I think it would be good to make it more clear that the usage of consent is always negotiated per direction.

Thanks!

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: 11. huhtikuuta 2014 8:01
To: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

Addressed the comments received from the WG.
Removed the timers definition from solution overview and made the text more generic.
Incorporated text from draft-thomson-rtcweb-consent.
Most of the text of solution overview is re-written however the idea is still kept intact

Comments are welcome.

There is still some dangling reference (text) to SRTP/DTLS mechanism for consent which we will modify in the next revision

Regards,
Authors

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Friday, 11 April 2014 9:07 am
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [rtcweb] I-D Action:

>http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshne
>ss-
>02
>
>
>Please note that it may take a couple of minutes from the time of 
>submission until the htmlized version and diff are available at 
>tools.ietf.org.
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 11 Apr 2014 06:54:00 +0000

Sure. We will add text for these two in the next revision.

Thanks,
Ram

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Friday, 11 April 2014 12:22 pm
To: Ram Mohan Ravindranath <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-02.txt

>And, I think it would be good to make it more clear that the usage of
>consent is always negotiated per direction.
>
>Thanks!
>
>Regards,
>
>Christer
>
>
>Subject: Re: [rtcweb] I-D Action:

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 11 Apr 2014 12:49:44 +0200

Harald,

Just remembered regarding ICE Lite in your transport document; I think your
statement regarding ICE, not ICE Lite therein, should be clarified so it is
understood that browsers must (also) operate against ICE Lite devices
(typical for a gateway).

(That is the way it already works in Chrome - buggy in Firefox though)
 
/Karl

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För Christer Holmberg
Skickat: den 11 april 2014 08:52
Till: Ram Mohan R (rmohanr); [email-masked]
Ämne: Re: [rtcweb] I-D Action:

Hi,

I think it would be good to have some text about usage of consent freshness
when one entity is ICE lite.

Thanks!

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Ram Mohan R
(rmohanr)
Sent: 11. huhtikuuta 2014 8:01
To: [email-masked]
Subject: Re: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-02.txt

Addressed the comments received from the WG.
Removed the timers definition from solution overview and made the text more
generic.
Incorporated text from draft-thomson-rtcweb-consent.
Most of the text of solution overview is re-written however the idea is
still kept intact

Comments are welcome.

Regards,
Authors

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Apr 2014 12:54:53 +0200

> understood that browsers must (also) operate against ICE Lite devices

Huh?

As far as I understand ICE-Lite, any full ICE implementation will
interoperate with an ICE-Lite implementation without any special handling.
Thus, any ICE implementation that doesn't do so has a bug.

I don't want to put in the document a statement that says "MUST
implement ICE and MUST NOT have bugs that prevent interoperability with
ICE-Lite". That's just not helpful.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 11 Apr 2014 17:52:00 +0000

Found this mail thread in the archives where this issue was discussed but
we have not reached to any conclusion -
https://www.ietf.org/mail-archive/web/rtcweb/current/msg04887.html

With ICE-lite mode since the ICE-lite endpoint does not typically generate
any binding requests, it may not generate STUN consent as well. This would
means a malicious application (running on a ICE-lite endpoint) can use it
for sending unwanted traffic.

Should we mandate an ICE-lite implementation to generate a STUN consent
request to its peer before it can send media ?

Regards,
Ram

-----Original Message-----
From: Ram Mohan Ravindranath <[email-masked]>
Date: Friday, 11 April 2014 12:23 pm
To: Christer Holmberg <[email-masked]>, "[email-masked]"
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Apr 2014 11:23:21 -0700

On 11 April 2014 10:52, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> any binding requests, it may not generate STUN consent as well.

Wat?

Consent is generated by responding to connectivity checks.  An
ICE-lite endpoint has to do that.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Apr 2014 20:37:55 +0000

Hi,

>> With ICE-lite mode since the ICE-lite endpoint does not typically 
>> generate any binding requests, it may not generate STUN consent as well.
>
>Wat?
>
>Consent is generated by responding to connectivity checks.  An ICE-lite endpoint has to do that.

Sure, but I guess what is meant is that the ICE-lite endpoint does not generate STUN consent REQUESTS.

Regards,

Christer

---

From: "Karl Stahl" <[email-masked]>
Date: Sat, 12 Apr 2014 01:06:18 +0200

-----Ursprungligt meddelande-----
Från: Harald Alvestrand [mailto:[email-masked]] 
Skickat: den 11 april 2014 12:55
Till: Karl Stahl; [email-masked]
Ämne: Re: SV: [rtcweb] I-D Action:

On 04/11/2014 12:49 PM, Karl Stahl wrote:
> Harald,
>
> Just remembered regarding ICE Lite in your transport document; I think 
> your statement regarding ICE, not ICE Lite therein, should be 
> clarified so it is understood that browsers must (also) operate 
> against ICE Lite devices (typical for a gateway).

Huh?

--- Agree, that is correct.

I don't want to put in the document a statement that says "MUST implement
ICE and MUST NOT have bugs that prevent interoperability with ICE-Lite".
That's just not helpful.

--- I am sure you can express it in a way that WOULD be helpful :) (I myself
had to ask our developers to get that understanding, so, just a point to
make it clearer and avoid doubts - we are not all experts on the details of
all specs.) 

/Karl

> There is still some dangling reference (text) to SRTP/DTLS mechanism 
> for consent which we will modify in the next revision
>
>
> Regards,
> Authors
>
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-fresh
>> ne
>> ss/
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 12 Apr 2014 07:59:09 +0200

Seems we have another reason why running a browser on ice-lite is a bad idea. Good that we do not allow that.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Apr 2014 08:26:27 +0000

Hi,

It’s not about running a browser on ice-lite – it is about a browser being prepared to run with a remote endpoint that is running ice-lite (e.g. a gateway). Certain browser implementations have had some problems with that, afaik…

Regards,

Christer

From: Harald Alvestrand [mailto:[email-masked]]
Sent: 12 April 2014 08:59
To: Christer Holmberg; Martin Thomson; Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

Seems we have another reason why running a browser on ice-lite is a bad idea. Good that we do not allow that.
On 11. april 2014 22:37:55 CEST, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Wat?

Regards,

Christer

________________________________

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

---

From: "Karl Stahl" <[email-masked]>
Date: Sat, 12 Apr 2014 11:57:10 +0200

To avoid confusion…

Gateways are not mentioned in draft-ietf-rtcweb-transports-03

Under 3.5.  Middle box related functions 

It too simply says:

ICE [RFC5245] MUST be supported.  The implementation MUST be a full

   ICE implementation, not ICE-Lite.

It needs to be said that gateways, i.e. devices having a media port on a public IP address – never behind a NAT/firewall – SHOULD implement ICE-Lite. (which browsers implementing full ICE correctly are compatible with – and has to be – which we all have the same understanding of, I believe)

/Karl

Från: rtcweb [mailto:[email-masked]] För Christer Holmberg
Skickat: den 12 april 2014 10:26
Till: Harald Alvestrand; Martin Thomson; Ram Mohan R (rmohanr)
Kopia: [email-masked]
Ämne: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

Hi,

Regards,

Christer

Hi,

Wat?

Regards,

Christer

  _____  

rtcweb mailing list
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 12 Apr 2014 14:55:34 +0200

On 04/12/2014 11:57 AM, Karl Stahl wrote:
>
> To avoid confusion…
>
> Gateways are not mentionedin draft-ietf-rtcweb-transports-03
>
> It needs to be said that gateways, i.e. devices having a media port on 
> a public IP address – never behind a NAT/firewall – SHOULD implement 
> ICE-Lite. (which browsers implementing full ICE correctly are 
> compatible with – and has to be – which we all have the same 
> understanding of, I believe)
>

I think we've been over this ground before.

At the moment, the RTCWEB protocol suite documentation deals with 
requirements for browsers, not requirements for gateways.

If someone wishes to start a requirements-for-gateways documents, I 
think they should be free to do that - but I hope we can finish this 
document set before that.

> /Karl
>
> *Från:*rtcweb [mailto:[email-masked]] *För *Christer Holmberg
> *Skickat:* den 12 april 2014 10:26
> *Till:* Harald Alvestrand; Martin Thomson; Ram Mohan R (rmohanr)
> *Kopia:* [email-masked]
> *Ämne:* Re: [rtcweb] I-D Action: 
> It’s not about running a browser on ice-lite – it is about a browser 
> being prepared to run with a remote endpoint that is running ice-lite 
> (e.g. a gateway). Certain browser implementations have had some 
> problems with that, afaik…
>
> Regards,
>
> Christer
>
> *From:*Harald Alvestrand [mailto:[email-masked]]
> *Sent:* 12 April 2014 08:59
> *To:* Christer Holmberg; Martin Thomson; Ram Mohan R (rmohanr)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [rtcweb] I-D Action: 
> Seems we have another reason why running a browser on ice-lite is a 
> bad idea. Good that we do not allow that.
>
> On 11. april 2014 22:37:55 CEST, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     ------------------------------------------------------------------------
>
>
>     rtcweb mailing list
>     [email-masked]  <mailto:[email-masked]>