Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13

From: Meral Shirazipour <[email-masked]>
Date: Fri, 15 May 2015 20:17:38 +0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-rtcweb-stun-consent-freshness-13
Reviewer: Meral Shirazipour
Review Date: 2015-05-15
IETF LC End Date:  2015-05-15
IESG Telechat date: NA

Summary:
This draft is ready to be published as Standards Track RFC but I have some comments .

Major issues:

Minor issues:

Nits/editorial comments:

-The abstract lacks context, please consider adding some more text. A suggestion: repeat the first sentence from the intro in the abstract:
"To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic."

-[Page 2] Intro: It was not clear if this document is specific to webRTC implementations. Is there any limitation to only use for webRTC? Maybe a sentence in the intro could clarify if there is or there is not such limitation.

-[Page 2] Intro, it would be good if the intro section could give a good example (use case, application) of when a receiving end would revoke the consent during the session.(why closing the session is not enough)

-[Page 3], Section2, "Transport Address" definition. It would be good to clarify this wrt 5-tuple. The two terms are used interchangeably, yet Transport address carries only destination IP protocol port, not the sender's (as carried in 5-tuple).
e.g. [Page 4]:"....the remote peer's transport address, the endpoint MUST cease transmission on that 5-tuple."

-[Page 4] "Initial consent to send traffic is obtained using ICE.  Consent expires after 30 seconds."
Is this value specified by [RFC6062] or this document? not clear.

-[Page 4-5]Section 4.1 addresses security issues. Section 8 adds additional content on security. It would be best to consolidate or at least have Section 8 point back to 4.1.

nits:

-[Page 5], "can not cause"--->"cannot cause"
-[Page 6], "each others keys"--->"each other's keys"
-[Page 7], typo "through review"--->"thorough review"
-SRTCP,DTLs, etc. please spell out acronyms at first use.

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 May 2015 17:03:40 +0000

Hi Meral,

Thanks for your feedback. See inline

-----Original Message-----
From: Meral Shirazipour <[email-masked]>
Date: Saturday, 16 May 2015 1:47 am
To: "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Gen-ART Last Call review of
draft-ietf-rtcweb-stun-consent-freshness-13
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>
Resent-Date: Saturday, 16 May 2015 1:48 am

>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
>http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>
>-The abstract lacks context, please consider adding some more text. A
>suggestion: repeat the first sentence from the intro in the abstract:

Sure we will add this text

>
>-[Page 2] Intro: It was not clear if this document is specific to webRTC
>implementations. Is there any limitation to only use for webRTC? Maybe a
>sentence in the intro could clarify if there is or there is not such
>Limitation

This document does not restrict itself to webRTC implementations alone
which is the reason we have not specified any where that Consent freshness
is for only webRTC clients. Any full ICE implementations can use Consent
freshness. We have this text at the end of introduction in the current
draft

"This document defines what it takes to obtain, maintain, and lose
   consent to send.  Consent to send applies to a single 5-tuple.  How
   applications react to changes in consent is not described in this
   document.
   Consent is obtained only by full ICE implementations.  An ICE-lite
   implementation will not generate consent checks, but will just
   respond to consent checks it receives."

Is this not sufficient ?

Regards,
Ram

---

From: Meral Shirazipour <[email-masked]>
Date: Mon, 18 May 2015 18:01:30 +0000

Hi Ram,
   Thank you for the response. Please see in line. Also, I did not see response to the rest of the comments, not sure if it was cut from the email (please see below-I copy pasted the original email).

Best regards,
Meral

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Monday, May 18, 2015 10:04 AM
To: Meral Shirazipour; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi Meral,

-----Original Message-----
From: Meral Shirazipour <[email-masked]>
Date: Saturday, 16 May 2015 1:47 am
To: "[email-masked]"

[Msh] thank you

>
>-[Page 2] Intro: It was not clear if this document is specific to 
>webRTC implementations. Is there any limitation to only use for webRTC? 
>Maybe a sentence in the intro could clarify if there is or there is not 
>such Limitation

This document does not restrict itself to webRTC implementations alone which is the reason we have not specified any where that Consent freshness is for only webRTC clients. Any full ICE implementations can use Consent freshness. We have this text at the end of introduction in the current draft

Is this not sufficient ?

[Msh] Somehow I had to read twice to deduce that. If you think that is sufficient and there is no need to specifically state not limited to webRTC the I am ok with it too.

Regards,
Ram

From: Gen-art [mailto:[email-masked]] On Behalf Of Meral Shirazipour
Sent: Friday, May 15, 2015 1:18 PM
To: [email-masked]; [email-masked]
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

nits:

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 19 May 2015 14:49:30 +0000

Not sure why the email I received got truncated. Attached for reference
the original email I received.

Please see below for responses to your other comments:

-----Original Message-----
From: Meral Shirazipour <[email-masked]>
Date: Monday, 18 May 2015 11:31 pm
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Gen-ART Last Call review of
draft-ietf-rtcweb-stun-consent-freshness-13

>Hi Ram,
>   Thank you for the response. Please see in line. Also, I did not see
>response to the rest of the comments, not sure if it was cut from the
>email (please see below-I copy pasted the original email).
>
>Best regards,
>Meral
>
>To: Meral Shirazipour;
>[email-masked];
>[email-masked]; [email-masked]
>Subject: Re: Gen-ART Last Call review of
>which is the reason we have not specified any where that Consent
>freshness is for only webRTC clients. Any full ICE implementations can
>use Consent freshness. We have this text at the end of introduction in
>the current draft
>
>[Msh] Somehow I had to read twice to deduce that. If you think that is
>sufficient and there is no need to specifically state not limited to
>webRTC the I am ok with it too.

We are planning to add a new section ³Applicability² that would cover some
more details on this right after the introduction section.  Here is the
tentative proposed text. After discussing in WG I
will refine this and add to document

This document defines what it takes to obtain, maintain, and lose consent
to send using ICE.Verification of peer consent before sending traffic is
necessary in
deployments like WebRTC to ensure that a malicious JavaScript cannot use
the browser
as a platform for launching attacks.Section 4.4 and section 5.3 of
[I-D.ietf-rtcweb-security-arch] explains why webRTC application needs
consent.

Other Applications that have similar security requirement where it is
required to verify 
peer's consent before sending non-ICE packets can use the consent
mechanism described in
this draft.

>Subject: [Gen-art] Gen-ART Last Call review of

Sure. As mentioned above, we will add this text in abstract

>limitation.
>-[Page 2] Intro, it would be good if the intro section could give a good
>example (use case, application) of when a receiving end would revoke the
>consent during the session.(why closing the session is not enough)

Section 4.2 has some details on when Consent is revoked. one use-case is
mentioned in 4.2 is immediate revocation when we receive a TLS Alert.

> 
>
>-[Page 3], Section2, "Transport Address" definition. It would be good to
>clarify this wrt 5-tuple. The two terms are used interchangeably, yet
>Transport address carries only destination IP protocol port, not the
>sender's (as carried in 5-tuple).

Terminology section defines Transport address.

>Is this value specified by [RFC6062] or this document? not clear.

30 second timeout period was selected so that consent checks could be sent
between 7 to 5 times (to handle packet loss) . This was discussed a lot in
WG and it was agreed to make 30 seconds as consent expiry.

>
>-[Page 4-5]Section 4.1 addresses security issues. Section 8 adds
>additional content on security. It would be best to consolidate or at
>least have Section 8 point back to 4.1.

Sure we will add some back reference from security considerations to 4.1

>-SRTCP,DTLs, etc. please spell out acronyms at first use.

Thanks. Will take care of these nits.

Regards,
Ram

>www.ericsson.com

Subject: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13
From: Meral Shirazipour <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 15 May 2015 20:17:38 +0000
List-Id: <[email-masked]>

Please resolve these comments along with any other Last Call comments you
may receive.

Summary:
This draft is ready to be published as Standards Track RFC but I have some
comments .

Major issues:

Minor issues:

Nits/editorial comments:

-The abstract lacks context, please consider adding some more text. A
suggestion: repeat the first sentence from the intro in the abstract:
"To prevent attacks on peers, endpoints have to ensure the remote peer is
willing to receive traffic."

limitation

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 19 May 2015 14:53:15 +0000

Hi,
  Thank you for the replies. 

Best Regards,
Meral

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Tuesday, May 19, 2015 7:50 AM
To: Meral Shirazipour
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13

Not sure why the email I received got truncated. Attached for reference the original email I received.

-----Original Message-----
From: Meral Shirazipour <[email-masked]>
Date: Monday, 18 May 2015 11:31 pm
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]"

>>Maybe a sentence in the intro could clarify if there is or there is 
>>not such Limitation
>

We are planning to add a new section ³Applicability² that would cover some more details on this right after the introduction section.  Here is the tentative proposed text. After discussing in WG I will refine this and add to document

This document defines what it takes to obtain, maintain, and lose consent to send using ICE.Verification of peer consent before sending traffic is necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks.Section 4.4 and section 5.3 of [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs consent.

Other Applications that have similar security requirement where it is required to verify peer's consent before sending non-ICE packets can use the consent mechanism described in this draft.

Regards,
Ram