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

["Ram Mohan R (rmohanr)" <[e-mail]>]

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 <[e-mail]>
Date: Monday, 18 May 2015 11:31 pm
To: Cisco Employee <[e-mail]>
Cc: "[e-mail]"
<[e-mail]>,
"[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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
>
>-----Original Message-----
>From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
>Sent: Monday, May 18, 2015 10:04 AM
>To: Meral Shirazipour;
>[e-mail];
>[e-mail]; [e-mail]
>Subject: Re: Gen-ART Last Call review of
>draft-ietf-rtcweb-stun-consent-freshness-13
>
>Hi Meral,
>
>Thanks for your feedback. See inline
>
>-----Original Message-----
>From: Meral Shirazipour <[e-mail]>
>Date: Saturday, 16 May 2015 1:47 am
>To: "[e-mail]"
><[e-mail]>,
>"[e-mail]" <[e-mail]>
>Subject: Gen-ART Last Call review of
>draft-ietf-rtcweb-stun-consent-freshness-13
>Resent-From: <[e-mail]>
>Resent-To: <[e-mail]>
>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.
>>
>>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."
>
>Sure we will add this text
>
>[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
>
>"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 ?
>
>[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.




>
>
>
>Regards,
>Ram
>
>
>From: Gen-art [mailto:[e-mail]] On Behalf Of Meral
>Shirazipour
>Sent: Friday, May 15, 2015 1:18 PM
>To: [e-mail];
>[e-mail]
>Subject: [Gen-art] Gen-ART Last Call review of
>draft-ietf-rtcweb-stun-consent-freshness-13
>
>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."

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

>
>-[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)

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).
>e.g. [Page 4]:"....the remote peer's transport address, the endpoint MUST
>cease transmission on that 5-tuple."

Terminology section defines Transport address.

>-[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.

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

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

Thanks. Will take care of these nits.

Regards,
Ram

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

--- Begin Message ---

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

--- End Message ---