Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT)

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

Hi Ben,

Thanks for your feedback. Please see my responses inline

-----Original Message-----
From: Ben Campbell <[e-mail]>
Date: Wednesday, 5 August 2015 3:38 am
To: The IESG <[e-mail]>
Cc: "[e-mail]"
<[e-mail]>,
"[e-mail]" <[e-mail]>,
"[e-mail]"
<[e-mail]>,
"[e-mail]"
<[e-mail]>, "[e-mail]"
<[e-mail]>
Subject: Ben Campbell's Yes on
draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT)

>Ben Campbell has entered the following ballot position for
>draft-ietf-rtcweb-stun-consent-freshness-15: Yes
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>This looks good overall. I have a few minor comments:
>
>-- General: 
>
>After re-reading this, and the relevant parts of
>rtcweb-security-architecture, I think a novice reader might find the
>meaning of "consent" a bit vague, especially in terms of how it might
>differ from "reachability". Can you offer an example of when an otherwise
>reachable peer might choose to withdraw consent?

Reachability of a endpoint does not indicate that it is willing to receive
traffic. 
So if a peer has to continue sending data it must do consent.
If the peer does not intend to send data, it can stop consent and later
resume Whenever it wants to send data again.
An example would be "As with a teacher in a classroom who grants consent
to each student to speak words, consent is granted to each sender to
transmit packets."



>
>-- section 1, first paragraph:
>
>I think readers are going to stumble over why we think a device that
>plans to attack a peer is going to worry about consent. This makes more
>sense in section 2. It might be helpful to move (or copy) the bit about
>"... deployments of WebRTC..." and "... malicious javascript" forward to
>the intro.

Sure. I will move the text related to malicious javascript to first para
of intro. 

OLD:
To prevent attacks on peers, endpoints have to ensure the remote peer
   is willing to receive traffic.  This is performed both when the
   session is first established to the remote peer using Interactive
   Connectivity Establishment ICE [RFC5245] connectivity checks, and
   periodically for the duration of the session using the procedures
   defined in this document.


NEW: 
To prevent attacks on peers, endpoints have to ensure the remote peer
   is willing to receive traffic. 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. This is performed both when the session is first established to
the
 remote peer using Interactive Connectivity Establishment ICE [RFC5245]
connectivity checks, and periodically for the duration of the session
using the procedures defined in this document.



>
>- 4, 3rd paragraph:
>
>Should the reader infer that the receipt of a package that is strongly
>assured to have come from a party implies consent from that party? If so,
>it might be worth an explicit mention.

No. Even in that case consent is needed.



>
>-- 5.1, first paragraph:
>
>The normative MUST feels wrong here, (and is probably redundant with
>other normative language further down in the section.) For example, could
>a sender just choose to stop sending?

Sender can stop sending data on that pair at anytime. If
the sender continues to send data, it must do consent other wise consent
will expire. That is the reason the document says that consent
must be maintained when application sends data. The other usage of
normative statements are for timer selection which is needed
to ensure that every implementation derives the timers based
on the suggested range.


>
>-- 5.1, 5th paragraph:
>
>>From the next paragraph, I infer that you mean consent expires after 30
>seconds when you have been sending binding request every few seconds, not
>30 seconds after sending any particular binding request. If that's
>correct it might be helpful to add a few words to that effect.

The next para discusses how the endpoint has to pace the bind requests for
consent. 
It mentions that the interval is between 4 - 6.




>
>-- 5.1, 6th paragraph:
>
>Does the "MUST NOT" refer to the general interval between checks prior to
>randomization, or to the specific interval between a pair of checks after
>Randomization?

It is between a pair of checks after randomization. So essentially each
request should be paced between 4 - 6 seconds after initial consent
obtained (via ICE validation)


>
>Nits:
>
>-- 2, 2nd paragraph: "verify peer's consent"
>
>Missing article (or "verify peer consent")
>
>-- 5.1, paragraph 3:
>
>s/sending an stun binding/sending a stun binding
>
>-- 5.1, 7th paragraph: "Each STUN binding request for consent MUST use a
>new STUN transaction
>   identifier for every consent binding request..."
>
>That's sort of redundant. I suggest something to the effect of "each
>consent binding request MUST use a new stun transaction identifier. "

Thanks. Will address all the nits above.

Regards,
Ram


>
>