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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 26 Feb 2013 15:06:49 +0000

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Feb 2013 16:26:49 -0800

Hi Muthu,

There's a little too much economy in the draft: the draft doesn't
define precisely what a 'STUN Transaction' entails.

I can't remember if this was discussed much, but we did discuss the
effect of just having Tc with respect to routing flaps (maybe it was
off-list).  Because we are winding timers for ICE down and shortening
the overall process to just a few seconds (or less for consent), there
is a real chance that a transitory failure could accidentally trigger
consent failure handling unnecessarily.

In any case, the suggested solution to that was to not send a
controlled burst of STUN Binding requests, but to instead send them
continuously at a measured interval.  Several missed responses would
be required in order to fail the flow.  As an example, with Tc = 32s,
sending a new request every 10 seconds would make the flow far more
reliable.

Similarly, the application-requested interval needs to send just a
single packet, lest more "robust" transaction handling cause
overlapping.  Any API that is specified (none yet!) should make it
clear that applications need to expect the occasional missed packet
and not do anything drastic as a result.

On 26 February 2013 07:06, Muthu Arul Mozhi Perumal (mperumal)
<[email-masked]> wrote:
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

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

Hi Martin,

Thanks for the feedback. The tuning of times for consent is far from finished. You are right we had an off-the-list discussion, but didn't take it forward (I'll work with you and others who were involved).

|There's a little too much economy in the draft: the draft doesn't
|define precisely what a 'STUN Transaction' entails.

In its current form, the draft uses the STUN transaction as defined in RFC5389, which implies the requests are retransmitted until a response is received, or until a total of 7 requests have been sent (assuming no hard ICMP error is received). So, reporting a consent freshness failure is sufficiently guarded against transitory network failures.

However, with the default 500 ms RTO recommended in RFC5389, it would take 39.5 sec for the transaction to timeout -- this was considered too long to declare a consent freshness failure.

One option could be to define a new STUN transaction that doesn't do the exponential backoff for retransmission, but instead retransmits at periodic intervals and declare failure if there is no response after sending a bunch of them, as you are suggesting. But, I am not sure at this point how that would be both superior compared to the transaction defined in RFC5389 and sufficiently guard against transitory network failures.

|Any API that is specified (none yet!) should make it
|clear that applications need to expect the occasional missed packet
|and not do anything drastic as a result.

Agreed.

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:[email-masked]]
|Sent: Wednesday, February 27, 2013 5:57 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
|
|Hi Muthu,
|
|There's a little too much economy in the draft: the draft doesn't
|define precisely what a 'STUN Transaction' entails.
|
|I can't remember if this was discussed much, but we did discuss the
|effect of just having Tc with respect to routing flaps (maybe it was
|off-list).  Because we are winding timers for ICE down and shortening
|the overall process to just a few seconds (or less for consent), there
|is a real chance that a transitory failure could accidentally trigger
|consent failure handling unnecessarily.
|
|In any case, the suggested solution to that was to not send a
|controlled burst of STUN Binding requests, but to instead send them
|continuously at a measured interval.  Several missed responses would
|be required in order to fail the flow.  As an example, with Tc = 32s,
|sending a new request every 10 seconds would make the flow far more
|reliable.
|
|Similarly, the application-requested interval needs to send just a
|single packet, lest more "robust" transaction handling cause
|overlapping.  Any API that is specified (none yet!) should make it
|clear that applications need to expect the occasional missed packet
|and not do anything drastic as a result.
|
|On 26 February 2013 07:06, Muthu Arul Mozhi Perumal (mperumal)
|<[email-masked]> wrote:
|> 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 internet-
[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: Wed, 27 Feb 2013 11:43:49 -0800

> In its current form, the draft uses the STUN transaction as defined in RFC5389, which implies the requests are retransmitted until a response is received, or until a total of 7 requests have been s…

That's far too much.  And the backoff is designed for completely
different situations.

Imagine that you are running Tr at 1 second, with a complete
transaction required before you do anything.  Do you run 39 in
parallel with hundreds of checks, or do you not create a new
transaction when another is outstanding?  Keep in mind that the latter
choice means that you aren't really sending a check every second any
more, despite agreeing to do so.

> However, with the default 500 ms RTO recommended in RFC5389, it would take 39.5 sec for the transaction to timeout -- this was considered too long to declare a consent freshness failure.

We've discussed tightening the timers once the session is live.  We've
also discussed tightening timers when the session is starting.  Both
of which I would have expected to see in the document as proposed
solutions.

> One option could be to define a new STUN transaction that doesn't do the exponential backoff for retransmission, but instead retransmits at periodic intervals and declare failure if there is no res…

I think that the document only needs to talk in terms of "checks" or
Binding requests rather than transactions.

---

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

|Imagine that you are running Tr at 1 second, with a complete
|transaction required before you do anything.  Do you run 39 in
|parallel with hundreds of checks, or do you not create a new
|transaction when another is outstanding?  

Yes, that's what I had in mind -- don't generate a new request when a response is pending. A couple more constraints that could be useful:
- Don't generate a new consent freshness check when no traffic was sent over the last x sec (could save battery).
- Don't generate a new liveness check if any traffic was received since the last liveness check.

I had a crude algorithm:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg05000.html

Need to refine further.

|We've discussed tightening the timers once the session is live.  We've
|also discussed tightening timers when the session is starting.  Both
|of which I would have expected to see in the document as proposed
|solutions.

Not sure I understood. Do you mean tightening the backoff timer?

|I think that the document only needs to talk in terms of "checks" or
|Binding requests rather than transactions.

How would that help? They would degenerate into transactions, anyway.

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:[email-masked]]
|Sent: Thursday, February 28, 2013 1:14 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
|
|> In its current form, the draft uses the STUN transaction as defined in RFC5389, which implies the
|requests are retransmitted until a response is received, or until a total of 7 requests have been sent
|(assuming no hard ICMP error is received). So, reporting a consent freshness failure is sufficiently
|guarded against transitory network failures.
|
|That's far too much.  And the backoff is designed for completely
|different situations.
|
|Imagine that you are running Tr at 1 second, with a complete
|transaction required before you do anything.  Do you run 39 in
|parallel with hundreds of checks, or do you not create a new
|transaction when another is outstanding?  Keep in mind that the latter
|choice means that you aren't really sending a check every second any
|more, despite agreeing to do so.
|
|> However, with the default 500 ms RTO recommended in RFC5389, it would take 39.5 sec for the
|transaction to timeout -- this was considered too long to declare a consent freshness failure.
|
|We've discussed tightening the timers once the session is live.  We've
|also discussed tightening timers when the session is starting.  Both
|of which I would have expected to see in the document as proposed
|solutions.
|
|> One option could be to define a new STUN transaction that doesn't do the exponential backoff for
|retransmission, but instead retransmits at periodic intervals and declare failure if there is no
|response after sending a bunch of them, as you are suggesting. But, I am not sure at this point how
|that would be both superior compared to the transaction defined in RFC5389 and sufficiently guard
|against transitory network failures.
|
|I think that the document only needs to talk in terms of "checks" or
|Binding requests rather than transactions.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Feb 2013 10:32:46 -0800

> Yes, that's what I had in mind -- don't generate a new request when a response is pending. A couple more constraints that could be useful:

I would expect that to be hard for a low Tr value.  Overlapped
requests seem like a real possibility for Tr=1s.

> - Don't generate a new consent freshness check when no traffic was sent over the last x sec (could save battery).

Be careful here that you don't create a failure mode whereby you lose
NAT bindings.

> - Don't generate a new liveness check if any traffic was received since the last liveness check.

Definitely.  Mandatory even.

> Not sure I understood. Do you mean tightening the backoff timer?

The initial timer and the number of rounds before giving up.  In fact,
I don't consider exponential back-off to be a useful feature for a
live flow.  It's there to help avoid overwhelming unknown peers with
checks.  Exponential back-off could go entirely.  Hence the suggestion
for a constant interval.  A constant interval also avoids having
transitory problems trigger unnecessarily harsh actions like ICE
restart.