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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 15 Jul 2013 18:44:51 +0000

Forwarding it to rtcweb..

-----Original Message-----
From: Muthu Arul Mozhi Perumal (mperumal) 
Sent: Tuesday, July 16, 2013 12:13 AM
To: [email-masked]
Subject: FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

The text and the algorithm in the draft are significantly simplified in this updated version. 

Comments welcome..

- Authors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 15, 2013 11:08 PM
To: [email-masked]
Subject: I-D Action: draft-muthu-behave-consent-freshness-04.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
                          Tirumaleswar Reddy
	Filename        : draft-muthu-behave-consent-freshness-04.txt
	Pages           : 7
	Date            : 2013-07-15

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 application may want to detect
   connection failure and take appropriate action.

   This document describes how a WebRTC browser can verify peer consent
   to continue sending traffic and detect connection failure.

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-04

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

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: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 16 Jul 2013 10:49:07 +0000

[Added rtcweb since I am not sure if everyone involved there are following this discussion in behave]

Thanks for the review. See inline.. 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: [email-masked]
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|> The text and the algorithm in the draft are significantly simplified in this updated version.
|>
|> Comments welcome..
|
|MUCH better introduction. Now I feel like I understand the need exactly.
|
|The "Design Considerations" section is still very confusing to me.
|
|>    Though ICE specifies STUN Binding indications to be used for
|>    keepalives, it requires that an agent be prepared to receive
|>    connectivity check as well.  If a connectivity check is received, a
|>    response is generated, but there is no impact on ICE processing, as
|>    described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE restart..

|
|>    While a WebRTC browser could verify whether the peer continues to
|>    send SRTCP reports before sending traffic to the peer, the usage of
|>    SRTCP together with Security Descriptions [RFC4568] requires exposing
|>    the media keys to the JavaScript and renders SRTCP unsuitable for
|>    consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"? Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet.

|
|>    For consent, calculating the SHA1 HMAC is necessary for MESSAGE-
|>    INTEGRITY which is computationally expensive.
|
|You need to qualify "expensive". It's certainly not expensive in all cases.
|
|>    Security analysis
|>    concluded that the STUN 96 bits transaction ID is sufficient for
|>    consent, without needing MESSAGE-INTEGRITY.
|
|What analysis? You would need to explain it in detail. But if that's not
|part of your suggested solution, just remove the sentence.

Agree it could be elaborated. The intention was to say the foll:

   STUN requires the 96 bits transaction ID to be uniformly and randomly
   chosen from the interval 0 .. 2**96-1, and be cryptographically
   random. This should suffice to prevent off path attacks on consent 
   freshness, so MESSAGE-INTEGRITY is not necessary from a security
   perspective.

However, MESSAGE-INTEGRITY is still used to maintain backward compatibility 
with legacy ICE/ICE-lite implementations.

|
|Now on to section "4. Solution Overview"...
|
|>    Every Tc seconds, the WebRTC browser sends a STUN Binding Request to
|>    the peer.  This request MUST use a new, cryptographically random
|>    Transaction ID [RFC4086], and is formatted as for an ICE connectivity
|>    check [RFC5245].  A valid STUN Binding Response is also formatted as
|>    for an ICE connectivity check [RFC5245].  The STUN Binding Request
|>    and STUN Binding Response are validated as for an ICE connectivity
|>    check [RFC5245].
|
|Couldn't this whole paragraph be simplified to "Every Tc seconds, the
|WebRTC browser sends an ICE connectivity check."? Is there anything new
|here besides the "every Tc" thing?

The difference from the ICE connectivity check is that there is no exponential back off for retransmissions.
 
|
|>    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.).
|
|This seems to me like it will not fulfill the goal set in the abstract:
|"to ensure that a malicious JavaScript cannot use the browser as a
|platform for launching attacks". If the JavaScript is free to ignore the
|notification from the browser, then it has no security benefits. If you
|want to reach that goal, the browser needs to forcefully stop transmitting.

That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on that candidate pair, including liveness checks, if there is a consent failure.

|
|>    When not actively sending traffic on a nominated candidate pair,
|>    performing consent freshness does not serve any purpose from a
|>    security perspective.
|
|I don't understand what this means. Why is the "security perspective"
|important here? Aren't we concerned about keepalives?

You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness would be required for sending them as well?

|
|>    In ICE [RFC5245] the STUN request/response are protected with
|>    MESSAGE-INTEGRITY, using an ephemeral username and password exchanged
|>    in the SDP ice-ufrag and ice-pwd attributes.  This prevents ICE from
|>    accidentally connecting to an in-intended peer, in that ICE will only
|>    connect to a peer that also knows the same username and password
|>    (exchanged in call signaling).  Once that connection to the remote
|>    peer has been established with ICE, the consent to continue sending
|>    traffic does not benefit from re-asserting that same username and
|>    password, so long as the senders and receiver's IP addresses remain
|>    the same (as they usually do).
|
|I had not understood from the text that there was no auth stuff in the
|request. The text said "This request [...] is formatted as for an ICE
|connectivity check [RFC5245]." I thought that included auth stuff.
|
|The explanation why no auth stuff in the request is acceptable should be
|moved to section 3.

Agree, it could be moved under design considerations.

Muthu 

|
|Simon
|_______________________________________________
|Behave mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Jul 2013 14:04:17 +0200

> Meant to stress these Binding request/response doesn't trigger an ICE restart..

Ok, then s/but/and/.

> That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by…

Ok, then say so in the draft.

> with legacy ICE/ICE-lite implementations.

Ok, then say so in the draft.

> The difference from the ICE connectivity check is that there is no exponential back off for retransmissions.

Ok, then say so in the draft.

> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on that candidate pair, including liveness checks, if there is a consent failure.

That's not what the draft says. It says that the browser "notifies" the
JS app. It needs to say that the browser MUST stop sending.

> You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness would be required for sending them as well?

No.

This is a section about keepalives. I just don't understand this
sentence, and I don't understand why it talks about security.

Simon

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 16 Jul 2013 12:43:26 +0000

Inline..

|-----Original Message-----
|From: Simon Perreault [mailto:[email-masked]]
|Sent: Tuesday, July 16, 2013 5:34 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]; [email-masked]
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Le 2013-07-16 12:49, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|> |>    Though ICE specifies STUN Binding indications to be used for
|> |>    keepalives, it requires that an agent be prepared to receive
|> |>    connectivity check as well.  If a connectivity check is received, a
|> |>    response is generated, but there is no impact on ICE processing, as
|> |>    described in section 10 of [RFC5245].
|> |
|> |...so? Why is "an impact on ICE processing" necessary?
|>
|> Meant to stress these Binding request/response doesn't trigger an ICE restart..
|
|Ok, then s/but/and/.
|
|> |>    While a WebRTC browser could verify whether the peer continues to
|> |>    send SRTCP reports before sending traffic to the peer, the usage of
|> |>    SRTCP together with Security Descriptions [RFC4568] requires exposing
|> |>    the media keys to the JavaScript and renders SRTCP unsuitable for
|> |>    consent freshness.
|> |
|> |Why does it "require exposing the media keys to the JavaScript"? Is this
|> |because of a law of nature, or is it because of the way the JavaScript
|> |API is being designed? Could the JS API be changed to accommodate
|> |SRTCP+SDES?
|>
|> That's how the API construct looks like today -- the JavaScript would get an SDP blob from the
|browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by
|putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet.
|
|Ok, then say so in the draft.
|
|> |>    Security analysis
|> |>    concluded that the STUN 96 bits transaction ID is sufficient for
|> |>    consent, without needing MESSAGE-INTEGRITY.
|> |
|> |What analysis? You would need to explain it in detail. But if that's not
|> |part of your suggested solution, just remove the sentence.
|>
|> Agree it could be elaborated. The intention was to say the foll:
|>
|>    STUN requires the 96 bits transaction ID to be uniformly and randomly
|>    chosen from the interval 0 .. 2**96-1, and be cryptographically
|>    random. This should suffice to prevent off path attacks on consent
|>    freshness, so MESSAGE-INTEGRITY is not necessary from a security
|>    perspective.
|>
|> However, MESSAGE-INTEGRITY is still used to maintain backward compatibility
|> with legacy ICE/ICE-lite implementations.
|
|Ok, then say so in the draft.
|
|> |Now on to section "4. Solution Overview"...
|> |
|> |>    Every Tc seconds, the WebRTC browser sends a STUN Binding Request to
|> |>    the peer.  This request MUST use a new, cryptographically random
|> |>    Transaction ID [RFC4086], and is formatted as for an ICE connectivity
|> |>    check [RFC5245].  A valid STUN Binding Response is also formatted as
|> |>    for an ICE connectivity check [RFC5245].  The STUN Binding Request
|> |>    and STUN Binding Response are validated as for an ICE connectivity
|> |>    check [RFC5245].
|> |
|> |Couldn't this whole paragraph be simplified to "Every Tc seconds, the
|> |WebRTC browser sends an ICE connectivity check."? Is there anything new
|> |here besides the "every Tc" thing?
|>
|> The difference from the ICE connectivity check is that there is no exponential back off for
|retransmissions.
|
|Ok, then say so in the draft.
|
|> |>    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.).
|> |
|> |This seems to me like it will not fulfill the goal set in the abstract:
|> |"to ensure that a malicious JavaScript cannot use the browser as a
|> |platform for launching attacks". If the JavaScript is free to ignore the
|> |notification from the browser, then it has no security benefits. If you
|> |want to reach that goal, the browser needs to forcefully stop transmitting.
|>
|> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on
|that candidate pair, including liveness checks, if there is a consent failure.
|
|That's not what the draft says. It says that the browser "notifies" the
|JS app. It needs to say that the browser MUST stop sending.

No. That section is about liveness check and its intention is just notify the JavaScript of a potential connectivity loss. It is when the consent check fails the browser actually stops sending everything. Does the draft need more text on the distinction between consent and liveness tests?

|
|> |>    When not actively sending traffic on a nominated candidate pair,
|> |>    performing consent freshness does not serve any purpose from a
|> |>    security perspective.
|> |
|> |I don't understand what this means. Why is the "security perspective"
|> |important here? Aren't we concerned about keepalives?
|>
|> You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness
|would be required for sending them as well?
|
|No.
|
|This is a section about keepalives. I just don't understand this
|sentence, and I don't understand why it talks about security.

Ok, let me elaborate:
- Consent freshness is not necessary when the browser is not sending any 
  traffic on a candidate pair.
- If the browser is not performing consent freshness on a candidate pair 
  for the above reason, it performs ICE keepalives (or RTP keepalives) to
  refresh NAT bindings.

Of course, the browser could continue performing consent freshness even when it is not sending any other traffic on that candidate pair and skip ICE keepalives.

Muthu

|
|Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Jul 2013 15:03:56 +0200

> No. That section is about liveness check and its intention is just notify the JavaScript of a potential connectivity loss. It is when the consent check fails the browser actually stops sending ever…

Ah! No, you're right, and the text is already perfectly clear about
this. No need to change. I was just confused.

> Of course, the browser could continue performing consent freshness even when it is not sending any other traffic on that candidate pair and skip ICE keepalives.

Ah, ok I understand with your explanation. It makes sense. There should
be a way to reformulate the text to make it clearer.

Thanks,
Simon

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Wed, 17 Jul 2013 05:48:51 +0000

Hi Muthu

Though using STUN request/response may be good for querying about consent, I feel it is overloading the functionality of STUN. Many publicly available STUN servers or those that are part of Call servers may not support this.

Can't there be some other neutral mechanism to query peer's consent - through signaling? 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Simon Perreault
Sent: Tuesday, July 16, 2013 6:34 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

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

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 17 Jul 2013 06:37:15 +0000

Ranjit,

|Many publicly available STUN servers or those that are part of Call servers
|may not support this.

Public STUN servers and call servers are not expected to support this.

|Can't there be some other neutral mechanism to query peer's consent - through 
|signaling?

No. That signaling between the JS and the web server could be anything (SIP or XMPP or proprietary or whatever) and the browser has no control over it.

Muthu

|-----Original Message-----
|From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
|Sent: Wednesday, July 17, 2013 11:19 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]; [email-masked]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Hi Muthu
|
|Though using STUN request/response may be good for querying about consent, I feel it is overloading
|the functionality of STUN. Many publicly available STUN servers or those that are part of Call servers
|may not support this.
|
|Can't there be some other neutral mechanism to query peer's consent - through signaling?
|
|
|Regards
|Ranjit
|
|
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Simon Perreault
|Sent: Tuesday, July 16, 2013 6:34 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]; [email-masked]
|Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|> |> |>    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.).
|> |> |
|> |> |This seems to me like it will not fulfill the goal set in the abstract:
|> |> |"to ensure that a malicious JavaScript cannot use the browser as a
|> |> |platform for launching attacks". If the JavaScript is free to ignore the
|> |> |notification from the browser, then it has no security benefits. If you
|> |> |want to reach that goal, the browser needs to forcefully stop transmitting.
|> |>
|> |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on
|> |that candidate pair, including liveness checks, if there is a consent failure.
|> |
|> |That's not what the draft says. It says that the browser "notifies" the
|> |JS app. It needs to say that the browser MUST stop sending.
|>
|> No. That section is about liveness check and its intention is just notify the JavaScript of a
|potential connectivity loss. It is when the consent check fails the browser actually stops sending
|everything. Does the draft need more text on the distinction between consent and liveness tests?
|
|Ah! No, you're right, and the text is already perfectly clear about
|this. No need to change. I was just confused.
|
|> |> |>    When not actively sending traffic on a nominated candidate pair,
|> |> |>    performing consent freshness does not serve any purpose from a
|> |> |>    security perspective.
|> |> |
|> |> |I don't understand what this means. Why is the "security perspective"
|> |> |important here? Aren't we concerned about keepalives?
|> |>
|> |> You mean one could use keepalives (Binding indications) for launching attacks, so consent
|freshness
|> |would be required for sending them as well?
|> |
|> |No.
|> |
|> |This is a section about keepalives. I just don't understand this
|> |sentence, and I don't understand why it talks about security.
|>
|> Ok, let me elaborate:
|> - Consent freshness is not necessary when the browser is not sending any
|>   traffic on a candidate pair.
|> - If the browser is not performing consent freshness on a candidate pair
|>   for the above reason, it performs ICE keepalives (or RTP keepalives) to
|>   refresh NAT bindings.
|>
|> Of course, the browser could continue performing consent freshness even when it is not sending any
|other traffic on that candidate pair and skip ICE keepalives.
|
|Ah, ok I understand with your explanation. It makes sense. There should
|be a way to reformulate the text to make it clearer.
|
|Thanks,
|Simon
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Wed, 17 Jul 2013 06:46:06 +0000

Hi Muthu

If many public STUN servers and call servers that implement STUN or ICElite functionalities, are not expected to support, then who would have interest to support this functionality? Ideally getting consent for receiving traffic or call should be part of signaling. I do not think using STUN is appropriate.

Regards
Ranjit

-----Original Message-----
From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 12:07 PM
To: Avasarala, Ranjit (NSN - IN/Bangalore)
Cc: [email-masked]; [email-masked]
Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

Ranjit,

Muthu

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 17 Jul 2013 08:46:02 +0000

|If many public STUN servers and call servers that implement STUN or ICElite 
|functionalities, are not expected to support

I should have said they have no role to play. It is similar to peer-to-peer ICE connectivity checks -- those checks don't go through public STUN or call servers at all. 

The difference between ICE connectivity checks and consent freshness checks is that the former is performed before session establishment and the later is performed after session establishment.

|then who would have interest to support this functionality?

RTCWEB browsers and browser-like platforms.

|Ideally getting consent for receiving traffic or call should be part of signaling. 
|I do not think using STUN is appropriate.

ICE already does that. You think it is inappropriate?

Muthu

|-----Original Message-----
|From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
|Sent: Wednesday, July 17, 2013 12:16 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Hi Muthu
|
|If many public STUN servers and call servers that implement STUN or ICElite functionalities, are not
|expected to support, then who would have interest to support this functionality? Ideally getting
|consent for receiving traffic or call should be part of signaling. I do not think using STUN is
|appropriate.
|
|Regards
|Ranjit
|
|
|
|
|-----Original Message-----
|From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
|Sent: Wednesday, July 17, 2013 12:07 PM
|To: Avasarala, Ranjit (NSN - IN/Bangalore)
|Cc: [email-masked]; [email-masked]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Ranjit,
|
||Many publicly available STUN servers or those that are part of Call servers
||may not support this.
|
|Public STUN servers and call servers are not expected to support this.
|
||Can't there be some other neutral mechanism to query peer's consent - through
||signaling?
|
|No. That signaling between the JS and the web server could be anything (SIP or XMPP or proprietary or
|whatever) and the browser has no control over it.
|
|Muthu
|
||-----Original Message-----
||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
||Sent: Wednesday, July 17, 2013 11:19 AM
||To: Muthu Arul Mozhi Perumal (mperumal)
||Cc: [email-masked]; [email-masked]
||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||
||Hi Muthu
||
||Though using STUN request/response may be good for querying about consent, I feel it is overloading
||the functionality of STUN. Many publicly available STUN servers or those that are part of Call
|servers
||may not support this.
||
||Can't there be some other neutral mechanism to query peer's consent - through signaling?
||
||
||Regards
||Ranjit
||
||
||
||-----Original Message-----
||From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Simon Perreault
||Sent: Tuesday, July 16, 2013 6:34 PM
||To: Muthu Arul Mozhi Perumal (mperumal)
||Cc: [email-masked]; [email-masked]
||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||
||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a écrit :
||> |> |>    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.).
||> |> |
||> |> |This seems to me like it will not fulfill the goal set in the abstract:
||> |> |"to ensure that a malicious JavaScript cannot use the browser as a
||> |> |platform for launching attacks". If the JavaScript is free to ignore the
||> |> |notification from the browser, then it has no security benefits. If you
||> |> |want to reach that goal, the browser needs to forcefully stop transmitting.
||> |>
||> |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything
|on
||> |that candidate pair, including liveness checks, if there is a consent failure.
||> |
||> |That's not what the draft says. It says that the browser "notifies" the
||> |JS app. It needs to say that the browser MUST stop sending.
||>
||> No. That section is about liveness check and its intention is just notify the JavaScript of a
||potential connectivity loss. It is when the consent check fails the browser actually stops sending
||everything. Does the draft need more text on the distinction between consent and liveness tests?
||
||Ah! No, you're right, and the text is already perfectly clear about
||this. No need to change. I was just confused.
||
||> |> |>    When not actively sending traffic on a nominated candidate pair,
||> |> |>    performing consent freshness does not serve any purpose from a
||> |> |>    security perspective.
||> |> |
||> |> |I don't understand what this means. Why is the "security perspective"
||> |> |important here? Aren't we concerned about keepalives?
||> |>
||> |> You mean one could use keepalives (Binding indications) for launching attacks, so consent
||freshness
||> |would be required for sending them as well?
||> |
||> |No.
||> |
||> |This is a section about keepalives. I just don't understand this
||> |sentence, and I don't understand why it talks about security.
||>
||> Ok, let me elaborate:
||> - Consent freshness is not necessary when the browser is not sending any
||>   traffic on a candidate pair.
||> - If the browser is not performing consent freshness on a candidate pair
||>   for the above reason, it performs ICE keepalives (or RTP keepalives) to
||>   refresh NAT bindings.
||>
||> Of course, the browser could continue performing consent freshness even when it is not sending any
||other traffic on that candidate pair and skip ICE keepalives.
||
||Ah, ok I understand with your explanation. It makes sense. There should
||be a way to reformulate the text to make it clearer.
||
||Thanks,
||Simon
||_______________________________________________
||rtcweb mailing list
[email-masked]
||https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jul 2013 17:02:07 +0800

On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

> |Subject: Re: [BEHAVE] FW: I-D Action:
> draft-muthu-behave-consent-freshness-04.txt
> |
> That's how the API construct looks like today -- the JavaScript would get
> an SDP blob from the browser containing the crypto keys used for SDES-SRTP.
> Of course, the browser could hide those keys by putting a "****" in SDP -:).

Uh, then how would they be sent to the other side?

As far as I can tell, with any plausible API SDES requires exposing the
keys to JS.

-Ekr

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Wed, 17 Jul 2013 09:05:54 +0000

My comments inline <Ranjit>

Regards
Ranjit

-----Original Message-----
From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 2:16 PM
To: Avasarala, Ranjit (NSN - IN/Bangalore)
Cc: [email-masked]
Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

I should have said they have no role to play. It is similar to peer-to-peer ICE connectivity checks -- those checks don't go through public STUN or call servers at all. 
[Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC Gateways which could be co-located with call handling servers. Then it won't make sense to have this feature.

The difference between ICE connectivity checks and consent freshness checks is that the former is performed before session establishment and the later is performed after session establishment.
[Ranjit] Why do you need to check consent of the peer after session is established? Ideally I should check consent before session establishment. If the peer does not want to receive traffic, then session itself should not be established. 

RTCWEB browsers and browser-like platforms.
[Ranjit] browser may implement, but it would be very customized one. I do not think the intermediate entities would want to support. 

ICE already does that. You think it is inappropriate?
[Ranjit] I am saying that using STUN for consent check is not appropriate as STUN has other dedicated functionality to do - like connectivity checks, keep alives, etc. Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the proposed feature would anyway fail.

Muthu

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Jul 2013 13:51:50 +0200

Le 2013-07-17 11:05, Avasarala, Ranjit (NSN - IN/Bangalore) a écrit :
> Why do you need to check consent of the peer after session is established? [...]
> I am saying that using STUN for consent check is not appropriate [...]

Ranjit,

I would expect one to fully understand the need for consent checks
*before* declaring the proposed solution inappropriate.

Simon

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 17 Jul 2013 12:47:02 +0000

|Uh, then how would they be sent to the other side?

Ah, the browser would have to modify the SDP when it is sent on the wire..

|As far as I can tell, with any plausible API SDES requires exposing the keys to JS.

That helps..thanks.

Muthu

From: Eric Rescorla [mailto:[email-masked]]
Sent: Wednesday, July 17, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Simon Perreault; [email-masked]; [email-masked]
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]<mailto:[email-masked]>> wrote:
[Added rtcweb since I am not sure if everyone involved there are following this discussion in behave]

|From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Simon Perreault
|To: [email-masked]<mailto:[email-masked]>

|

That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by putting a "****" in SDP -:).

As far as I can tell, with any plausible API SDES requires exposing the keys to JS.

-Ekr

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 17 Jul 2013 14:17:53 +0000

|-----Original Message-----
|From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
|Sent: Wednesday, July 17, 2013 2:36 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|My comments inline <Ranjit>
|
|Regards
|Ranjit
|
|-----Original Message-----
|From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
|Sent: Wednesday, July 17, 2013 2:16 PM
|To: Avasarala, Ranjit (NSN - IN/Bangalore)
|Cc: [email-masked]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
||If many public STUN servers and call servers that implement STUN or ICElite
||functionalities, are not expected to support
|
|I should have said they have no role to play. It is similar to peer-to-peer ICE connectivity checks --
|those checks don't go through public STUN or call servers at all.
|[Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC Gateways which could be co-
|located with call handling servers. Then it won't make sense to have this feature.

An RTCWeb gateway wouldn't have to do anything fancier than what it already does for ICE connectivity checks. 

|
|The difference between ICE connectivity checks and consent freshness checks is that the former is
|performed before session establishment and the later is performed after session establishment.
|[Ranjit] Why do you need to check consent of the peer after session is established? Ideally I should
|check consent before session establishment. If the peer does not want to receive traffic, then session
|itself should not be established.

See draft-ietf-rtcweb-security-arch:

<snip>
4.4.  Communications and Consent Freshness

   From a security perspective, everything from here on in is a little
   anticlimactic:  Alice and Bob exchange data protected by the keys
   negotiated by DTLS.  Because of the security guarantees discussed in
   the previous sections, they know that the communications are
   encrypted and authenticated.

   The one remaining security property we need to establish is "consent
   freshness", i.e., allowing Alice to verify that Bob is still prepared
   to receive her communications so that Alice does not continue to send
   large traffic volumes to entities which went abruptly offline.  ICE
   specifies periodic STUN keepalizes but only if media is not flowing.
   Because the consent issue is more difficult here, we require RTCWeb
   implementations to periodically send keepalives.  As described in
   Section 5.3, these keepalives MUST be based on the consent freshness
   mechanism specified in [I-D.muthu-behave-consent-freshness].  If a
   keepalive fails and no new ICE channels can be established, then the
   session is terminated.
</snip>

|
||then who would have interest to support this functionality?
|
|RTCWEB browsers and browser-like platforms.
|[Ranjit] browser may implement, but it would be very customized one. I do not think the intermediate
|entities would want to support.

You seem to be completely missing the very purpose of consent.

|
||Ideally getting consent for receiving traffic or call should be part of signaling.
||I do not think using STUN is appropriate.
|
|ICE already does that. You think it is inappropriate?
|[Ranjit] I am saying that using STUN for consent check is not appropriate as STUN has other dedicated
|functionality to do - like connectivity checks, keep alives, etc. 

See draft-ietf-rtcweb-security and draft-ietf-rtcweb-security.

|Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the proposed feature would anyway fail.

The solution is built on top of ICE, so should work across these.

Muthu

|
|Muthu
|
||-----Original Message-----
||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
||Sent: Wednesday, July 17, 2013 12:16 PM
||To: Muthu Arul Mozhi Perumal (mperumal)
||Cc: [email-masked]
||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||
||Hi Muthu
||
||If many public STUN servers and call servers that implement STUN or ICElite functionalities, are not
||expected to support, then who would have interest to support this functionality? Ideally getting
||consent for receiving traffic or call should be part of signaling. I do not think using STUN is
||appropriate.
||
||Regards
||Ranjit
||
||
||
||
||-----Original Message-----
||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
||Sent: Wednesday, July 17, 2013 12:07 PM
||To: Avasarala, Ranjit (NSN - IN/Bangalore)
||Cc: [email-masked]; [email-masked]
||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||
||Ranjit,
||
|||Many publicly available STUN servers or those that are part of Call servers
|||may not support this.
||
||Public STUN servers and call servers are not expected to support this.
||
|||Can't there be some other neutral mechanism to query peer's consent - through
|||signaling?
||
||No. That signaling between the JS and the web server could be anything (SIP or XMPP or proprietary or
||whatever) and the browser has no control over it.
||
||Muthu
||
|||-----Original Message-----
|||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
|||Sent: Wednesday, July 17, 2013 11:19 AM
|||To: Muthu Arul Mozhi Perumal (mperumal)
|||Cc: [email-masked]; [email-masked]
|||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|||
|||Hi Muthu
|||
|||Though using STUN request/response may be good for querying about consent, I feel it is overloading
|||the functionality of STUN. Many publicly available STUN servers or those that are part of Call
||servers
|||may not support this.
|||
|||Can't there be some other neutral mechanism to query peer's consent - through signaling?
|||
|||
|||Regards
|||Ranjit
|||
|||
|||
|||-----Original Message-----
|||From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Simon Perreault
|||Sent: Tuesday, July 16, 2013 6:34 PM
|||To: Muthu Arul Mozhi Perumal (mperumal)
|||Cc: [email-masked]; [email-masked]
|||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|||
|||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|||> |> |>    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.).
|||> |> |
|||> |> |This seems to me like it will not fulfill the goal set in the abstract:
|||> |> |"to ensure that a malicious JavaScript cannot use the browser as a
|||> |> |platform for launching attacks". If the JavaScript is free to ignore the
|||> |> |notification from the browser, then it has no security benefits. If you
|||> |> |want to reach that goal, the browser needs to forcefully stop transmitting.
|||> |>
|||> |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything
||on
|||> |that candidate pair, including liveness checks, if there is a consent failure.
|||> |
|||> |That's not what the draft says. It says that the browser "notifies" the
|||> |JS app. It needs to say that the browser MUST stop sending.
|||>
|||> No. That section is about liveness check and its intention is just notify the JavaScript of a
|||potential connectivity loss. It is when the consent check fails the browser actually stops sending
|||everything. Does the draft need more text on the distinction between consent and liveness tests?
|||
|||Ah! No, you're right, and the text is already perfectly clear about
|||this. No need to change. I was just confused.
|||
|||> |> |>    When not actively sending traffic on a nominated candidate pair,
|||> |> |>    performing consent freshness does not serve any purpose from a
|||> |> |>    security perspective.
|||> |> |
|||> |> |I don't understand what this means. Why is the "security perspective"
|||> |> |important here? Aren't we concerned about keepalives?
|||> |>
|||> |> You mean one could use keepalives (Binding indications) for launching attacks, so consent
|||freshness
|||> |would be required for sending them as well?
|||> |
|||> |No.
|||> |
|||> |This is a section about keepalives. I just don't understand this
|||> |sentence, and I don't understand why it talks about security.
|||>
|||> Ok, let me elaborate:
|||> - Consent freshness is not necessary when the browser is not sending any
|||>   traffic on a candidate pair.
|||> - If the browser is not performing consent freshness on a candidate pair
|||>   for the above reason, it performs ICE keepalives (or RTP keepalives) to
|||>   refresh NAT bindings.
|||>
|||> Of course, the browser could continue performing consent freshness even when it is not sending any
|||other traffic on that candidate pair and skip ICE keepalives.
|||
|||Ah, ok I understand with your explanation. It makes sense. There should
|||be a way to reformulate the text to make it clearer.
|||
|||Thanks,
|||Simon
|||_______________________________________________
|||rtcweb mailing list
[email-masked]
|||https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jul 2013 05:59:40 +0800

On Wed, Jul 17, 2013 at 8:47 PM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

>  |Uh, then how would they be sent to the other side?****
>
> ** **
>

I don't really see how this helps since the server is going to see it and
call tell
the JS (remember, that's where the JS came from).

-Ekr

>
> |As far as I can tell, with any plausible API SDES requires exposing the
> keys to JS.****
>
> ** **
>
> That helps..thanks.****
>
> ** **
>
> Muthu****
>
> ** **
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Wednesday, July 17, 2013 2:32 PM
> *To:* Muthu Arul Mozhi Perumal (mperumal)
> *Cc:* Simon Perreault; [email-masked]; [email-masked]
> *Subject:* Re: [rtcweb] [BEHAVE] FW: I-D Action:
> draft-muthu-behave-consent-freshness-04.txt****
>
> ** **
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a écrit :****
>
> |****
> ****
> ** **
> ** **
> Uh, then how would they be sent to the other side?****
>
> ** **
>
> keys to JS.****
> ** **
> -Ekr****
> ** **

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Thu, 18 Jul 2013 09:20:37 +0000

One more question - Would consent freshness be an additional feature as part of ICE functionality?

Regards
Ranjit

-----Original Message-----
From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 7:48 PM
To: Avasarala, Ranjit (NSN - IN/Bangalore)
Cc: [email-masked]
Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

|

<snip>

|

|

Muthu

|
|Muthu
|

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 18 Jul 2013 10:28:50 +0000

|-----Original Message-----
|From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
|Sent: Thursday, July 18, 2013 2:51 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|One more question - Would consent freshness be an additional feature as part of ICE functionality?

Yes.

|
|Regards
|Ranjit
|
|
|
|-----Original Message-----
|From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
|Sent: Wednesday, July 17, 2013 7:48 PM
|To: Avasarala, Ranjit (NSN - IN/Bangalore)
|Cc: [email-masked]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
||-----Original Message-----
||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
||Sent: Wednesday, July 17, 2013 2:36 PM
||To: Muthu Arul Mozhi Perumal (mperumal)
||Cc: [email-masked]
||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||
||My comments inline <Ranjit>
||
||Regards
||Ranjit
||
||-----Original Message-----
||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
||Sent: Wednesday, July 17, 2013 2:16 PM
||To: Avasarala, Ranjit (NSN - IN/Bangalore)
||Cc: [email-masked]
||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||
|||If many public STUN servers and call servers that implement STUN or ICElite
|||functionalities, are not expected to support
||
||I should have said they have no role to play. It is similar to peer-to-peer ICE connectivity checks -
|-
||those checks don't go through public STUN or call servers at all.
||[Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC Gateways which could be
|co-
||located with call handling servers. Then it won't make sense to have this feature.
|
|An RTCWeb gateway wouldn't have to do anything fancier than what it already does for ICE connectivity
|checks.
|
||
||The difference between ICE connectivity checks and consent freshness checks is that the former is
||performed before session establishment and the later is performed after session establishment.
||[Ranjit] Why do you need to check consent of the peer after session is established? Ideally I should
||check consent before session establishment. If the peer does not want to receive traffic, then
|session
||itself should not be established.
|
|See draft-ietf-rtcweb-security-arch:
|
|<snip>
|4.4.  Communications and Consent Freshness
|
|   From a security perspective, everything from here on in is a little
|   anticlimactic:  Alice and Bob exchange data protected by the keys
|   negotiated by DTLS.  Because of the security guarantees discussed in
|   the previous sections, they know that the communications are
|   encrypted and authenticated.
|
|   The one remaining security property we need to establish is "consent
|   freshness", i.e., allowing Alice to verify that Bob is still prepared
|   to receive her communications so that Alice does not continue to send
|   large traffic volumes to entities which went abruptly offline.  ICE
|   specifies periodic STUN keepalizes but only if media is not flowing.
|   Because the consent issue is more difficult here, we require RTCWeb
|   implementations to periodically send keepalives.  As described in
|   Section 5.3, these keepalives MUST be based on the consent freshness
|   mechanism specified in [I-D.muthu-behave-consent-freshness].  If a
|   keepalive fails and no new ICE channels can be established, then the
|   session is terminated.
|</snip>
|
||
|||then who would have interest to support this functionality?
||
||RTCWEB browsers and browser-like platforms.
||[Ranjit] browser may implement, but it would be very customized one. I do not think the intermediate
||entities would want to support.
|
|You seem to be completely missing the very purpose of consent.
|
||
|||Ideally getting consent for receiving traffic or call should be part of signaling.
|||I do not think using STUN is appropriate.
||
||ICE already does that. You think it is inappropriate?
||[Ranjit] I am saying that using STUN for consent check is not appropriate as STUN has other dedicated
||functionality to do - like connectivity checks, keep alives, etc.
|
|See draft-ietf-rtcweb-security and draft-ietf-rtcweb-security.
|
||Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the proposed feature would
|anyway fail.
|
|The solution is built on top of ICE, so should work across these.
|
|Muthu
|
||
||Muthu
||
|||-----Original Message-----
|||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
|||Sent: Wednesday, July 17, 2013 12:16 PM
|||To: Muthu Arul Mozhi Perumal (mperumal)
|||Cc: [email-masked]
|||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|||
|||Hi Muthu
|||
|||If many public STUN servers and call servers that implement STUN or ICElite functionalities, are not
|||expected to support, then who would have interest to support this functionality? Ideally getting
|||consent for receiving traffic or call should be part of signaling. I do not think using STUN is
|||appropriate.
|||
|||Regards
|||Ranjit
|||
|||
|||
|||
|||-----Original Message-----
|||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
|||Sent: Wednesday, July 17, 2013 12:07 PM
|||To: Avasarala, Ranjit (NSN - IN/Bangalore)
|||Cc: [email-masked]; [email-masked]
|||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|||
|||Ranjit,
|||
||||Many publicly available STUN servers or those that are part of Call servers
||||may not support this.
|||
|||Public STUN servers and call servers are not expected to support this.
|||
||||Can't there be some other neutral mechanism to query peer's consent - through
||||signaling?
|||
|||No. That signaling between the JS and the web server could be anything (SIP or XMPP or proprietary
|or
|||whatever) and the browser has no control over it.
|||
|||Muthu
|||
||||-----Original Message-----
||||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[email-masked]]
||||Sent: Wednesday, July 17, 2013 11:19 AM
||||To: Muthu Arul Mozhi Perumal (mperumal)
||||Cc: [email-masked]; [email-masked]
||||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||||
||||Hi Muthu
||||
||||Though using STUN request/response may be good for querying about consent, I feel it is overloading
||||the functionality of STUN. Many publicly available STUN servers or those that are part of Call
|||servers
||||may not support this.
||||
||||Can't there be some other neutral mechanism to query peer's consent - through signaling?
||||
||||
||||Regards
||||Ranjit
||||
||||
||||
||||-----Original Message-----
||||From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Simon Perreault
||||Sent: Tuesday, July 16, 2013 6:34 PM
||||To: Muthu Arul Mozhi Perumal (mperumal)
||||Cc: [email-masked]; [email-masked]
||||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
||||
||||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a écrit :
||||> |> |>    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.).
||||> |> |
||||> |> |This seems to me like it will not fulfill the goal set in the abstract:
||||> |> |"to ensure that a malicious JavaScript cannot use the browser as a
||||> |> |platform for launching attacks". If the JavaScript is free to ignore the
||||> |> |notification from the browser, then it has no security benefits. If you
||||> |> |want to reach that goal, the browser needs to forcefully stop transmitting.
||||> |>
||||> |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything
|||on
||||> |that candidate pair, including liveness checks, if there is a consent failure.
||||> |
||||> |That's not what the draft says. It says that the browser "notifies" the
||||> |JS app. It needs to say that the browser MUST stop sending.
||||>
||||> No. That section is about liveness check and its intention is just notify the JavaScript of a
||||potential connectivity loss. It is when the consent check fails the browser actually stops sending
||||everything. Does the draft need more text on the distinction between consent and liveness tests?
||||
||||Ah! No, you're right, and the text is already perfectly clear about
||||this. No need to change. I was just confused.
||||
||||> |> |>    When not actively sending traffic on a nominated candidate pair,
||||> |> |>    performing consent freshness does not serve any purpose from a
||||> |> |>    security perspective.
||||> |> |
||||> |> |I don't understand what this means. Why is the "security perspective"
||||> |> |important here? Aren't we concerned about keepalives?
||||> |>
||||> |> You mean one could use keepalives (Binding indications) for launching attacks, so consent
||||freshness
||||> |would be required for sending them as well?
||||> |
||||> |No.
||||> |
||||> |This is a section about keepalives. I just don't understand this
||||> |sentence, and I don't understand why it talks about security.
||||>
||||> Ok, let me elaborate:
||||> - Consent freshness is not necessary when the browser is not sending any
||||>   traffic on a candidate pair.
||||> - If the browser is not performing consent freshness on a candidate pair
||||>   for the above reason, it performs ICE keepalives (or RTP keepalives) to
||||>   refresh NAT bindings.
||||>
||||> Of course, the browser could continue performing consent freshness even when it is not sending
|any
||||other traffic on that candidate pair and skip ICE keepalives.
||||
||||Ah, ok I understand with your explanation. It makes sense. There should
||||be a way to reformulate the text to make it clearer.
||||
||||Thanks,
||||Simon
||||_______________________________________________
||||rtcweb mailing list
[email-masked]
||||https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <[email-masked]>
Date: Fri, 19 Jul 2013 10:58:39 +0000

Hi Muthu
So if I understand correctly, this functionality is on top of ICE functionality and is optional for the gateways to support it. Right?

Regards
Ranjit

-----Original Message-----
From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Sent: Wednesday, July 17, 2013 7:48 PM
To: Avasarala, Ranjit (NSN - IN/Bangalore)
Cc: [email-masked]
Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

|

<snip>

|

|

Muthu

|
|Muthu
|