Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

From: "Black, David" <[email-masked]>
Date: Wed, 27 May 2015 07:17:20 +0000

I'll limit comments here to the two major issues.  Quick summary:

[1] Applicability: The proposed text looks generally good, but the definition
	of "consent" needs a couple of clarifications.

[2] Security Considerations: The proposed text isn't sufficient.  In addition
	to the new applicability text's reference to the WebRTC security
	architecture draft, a reference to the WebRTC security considerations
	draft with specific section pointers needs to be added to the security
	considerations section of this draft.

> >> [1] The draft seems to be missing discussion of applicability - what
> >> environments and/or protocols is this mechanism intended for or applicable
> >> to?

> We will add a new section ³Applicability² after the introduction section.

I think that proposed applicability section will address most of the concern.
As part of this, the definition of consent (Section 2) needs elaboration:

   Consent:  The mechanism of obtaining permission to send to a remote
      transport address.  Initial consent is obtained using ICE.

Two important concepts should be clearer:
	- Permission to send is obtained *from the recipient* of the traffic.
	- The traffic to which permission to send applies is *non-ICE* traffic.

> >> [2] The security considerations appear to be incomplete.
> >> There should be an explanation of why cryptographically strong STUN
> >> transaction IDs are required (e.g., there are no cryptographically
> >> strong IDs in the TCP consent mechanism noted on p.4), and there should
> >> be a discussion of how and why replays of previous consent responses
> >> are harmless (will be ignored by the recipient).
> 
> Cryptographically strong STUN transaction IDs are required so that
> off-path attacker does not replay old consent responses.
> 
> 
> 
> >>The mechanism design
> >> appears to be ok, but this rationale should be provided in terms of
> >> attacks that are of concern and how they are prevented - a primary
> >> intent appears to be to resisting off-path attacks.
> 
> We will add the following line to Security Considerations section.
>
> NEW:
> 
> Consent requires 96 bits transaction ID to be uniformly and randomly
> chosen from the interval 0 .. 2**96-1, and be cryptographically strong.
> This is good enough security against an off-path attacker replaying old
> STUN consent responses.

That's good, but the actual problem is a missing reference.  The rationale
discussion is in draft-ietf-rtcweb-security, so that draft needs to be added
as a normative reference, plus text added to the security considerations
section of this consent draft to call attention to sections 3.3 and 4.2 of
that rtcweb-security draft.  This is in addition to the citation of sections
4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new
applicability text.

Thanks,
--David

> -----Original Message-----
> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> Sent: Tuesday, May 19, 2015 11:28 AM
> To: joel jaeggli; Black, David; [email-masked]; Dan Wing (dwing);
> Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
> 
> Hi David/Joel,
> 
> Please see inline for my responses.
> 
> 
> -----Original Message-----
> From: joel jaeggli <[email-masked]>
> Date: Friday, 15 May 2015 4:59 am
> To: "Black, David" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>, Cisco
> Employee <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>

> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
> 
> >Thanks David,
> >
> >I'll be looking with interest for the addressing of items 1/2.
> >
> >joel
> >
> >On 5/14/15 4:21 PM, Black, David wrote:
> >> I have reviewed this document as part of the Operational directorate's
> >> ongoing effort to review all IETF documents being processed by the IESG.
> >> These comments were written with the intent of improving the operational
> >> aspects of the IETF drafts. Comments that are not addressed in last call
> >> may be included in AD reviews during the IESG review.  Document editors
> >> and WG chairs should treat these comments just like any other last call
> >> comments.
> >>
> >> Document: draft-ietf-rtcweb-stun-consent-freshness-13
> >> Reviewer: David Black
> >> Review Date: May 14, 2015
> >> IETF LC End Date: May 15, 2015 (on -11)
> >>
> >> Summary: This draft is on the right track, but has open issues
> >>  		described in the review.
> >>
> >> This draft describes use of STUN to obtain ongoing consent to send in
> >> a fashion that is secured by the use of cryptographically strong nonces
> >> as STUN transaction IDs.
> >>
> >> -- Major issues --
> >>
> >> [1] The draft seems to be missing discussion of applicability - what
> >> environments and/or protocols is this mechanism intended for or applicable
> >> to?  Is this generally applicable wherever ICE and STUN are used?  I don't
> >> see any RFCs listed as updated by this draft, so I'm guessing that this
> >> is not intended to promulgate new requirements for all uses of ICE and
> >> STUN, but this should be clarified.  The shepherd writeup implies that
> >> this draft is intended primarily for WebRTC.
> 
> This document defines what it takes to obtain, maintain, and lose
>    consent to send using ICE. This draft does not restrict on what
> applications should use
> Consent. Currently on webRTC applications use Consent, however any other
> application that has
> Similar security requirements can use this mechanism. We will add a new
> section ³Applicability²
> after the introduction section.
> 
> <snip>
> 2. Applicability
> 
> 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.
> 
> 
> </snip>
> 
> 
> Also we will modify para 3 of Intro to make it clearer.
> 
> OLD:
> 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.
> 
> 
> 
> NEW:
> 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. The consent mechanism does not update the
> ICE procedures
> defined in [RFC 5245].
> 
> 
> 
> 
> 
> 
> >>
> >> [2] The security considerations appear to be incomplete.
> >> There should be an explanation of why cryptographically strong STUN
> >> transaction IDs are required (e.g., there are no cryptographically
> >> strong IDs in the TCP consent mechanism noted on p.4), and there should
> >> be a discussion of how and why replays of previous consent responses
> >> are harmless (will be ignored by the recipient).
> 
> Cryptographically strong STUN transaction IDs are required so that
> off-path attacker does not replay old consent responses.
> 
> 
> 
> >>The mechanism design
> >> appears to be ok, but this rationale should be provided in terms of
> >> attacks that are of concern and how they are prevented - a primary
> >> intent appears to be to resisting off-path attacks.
> 
> We will add the following line to Security Considerations section.
> 
> NEW:
> 
> Consent requires 96 bits transaction ID to be uniformly and randomly
> chosen from the interval 0 .. 2**96-1, and be cryptographically strong.
> This is good enough security against an off-path attacker replaying old
> STUN consent responses.
> 
> 
> 
> >>
> >> -- Minor Issues --
> >>
> >> [3] In Section 1, please explain what ICE-lite is.  A suitable reference
> >> should suffice.
> 
> Yes we will add reference to RFC5245 that describes ICE-lite
> 
> 
> 
> >>
> >> [4] In Section 4.1, please explain or provide a reference for what
> >>"paced"
> >> means in "paced STUN connectivity checks or responses."
> 
> Pacing is explained in the same section below. Let us know if this is not
> sufficient/not clear.
>  <snip>
>     To prevent expiry of consent, a STUN binding request can be sent
>     periodically.  To prevent synchronization of consent checks, each
>     interval MUST be randomized from between 0.8 and 1.2 times the basic
>     period.  Implementations SHOULD set a default interval of 5 seconds,
>     resulting in a period between checks of 4 to 6 seconds.
> </snip>
> 
> 
> 
> >>
> >> -- Nits/Editorial Comments --
> >>
> >> The SRTP paragraph in Section 8 (Security Considerations) feels out of
> >>place
> >> - this looks like design rationale material that would be better
> >>located in
> >> Section 3.
> 
> Okay, will move this paragraph to Section 3.
> 
> 
> 
> >>
> >> idnits 2.13.02 found an unused reference:
> >>
> >>   == Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on line
> >>320, but
> >>      no explicit reference was found in the text
> >>
> >> That reference is likely to be useful to address the absence of
> >>discussion of
> >> applicability (major issue [1], above).
> 
> This reference is not needed. Once we add applicability section we will
> reference rtcweb-security-arch draft.
> 
> >>
> >> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> >>
> >> This mechanism is an incremental modification to the STUN and ICE
> >>protocols,
> >> and can be implemented by one party to a communication session; ordinary
> >> response generation behavior (already required) reflects the
> >>cryptographically
> >> strong STUN transaction IDs on which the mechanism is based.  As a
> >>result, the
> >> mechanism can be deployed at one end of a two-party communication
> >>session
> >> without impact on the other party.  This is implied by section 3 of the
> >>draft,
> >> but would be useful to state explicitly.
> 
> We will add a new applicability section proposed above and also modified
> para 3 of Intro to make it clearer that this draft does not change ICE
> procedures. Please let us know if this solves the comment above.
> 
> 
> >>  [A.1.1 - deployment]
> >>
> >> The mechanism has been defined to limit the amount of added traffic and
> >>to
> >> shut down unwanted traffic, plus contains a facility to desynchronize
> >> independent users of this protocol.  Some rationale should be added for
> >> the choice of the 30 second timeout period.
> 
> 30 second timeout period was selected so that consent checks could be sent
> between 7 to 5 times (to handle packet loss).
> 
> 
> >> [A.1.5 - network impact]
> >>
> >> There is an obvious fault condition, namely that consent is lost or
> >>revoked
> >> causing immediate cessation of traffic.  While the details depend on the
> >> environment in which this mechanism is used, it'd be helpful to add a
> >>sentence
> >> or two on reporting of the state of STUN consent-based connectivity and
> >>how
> >> that reporting should or may relate to reporting of the state of other
> >>forms
> >> of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned in this
> >>draft.
> 
> We specifically discussed in WG about how applications should handle
> changes in Consent and it was decided to keep it outside the scope of this
> draft. Para 3 of introduction already has a text that says the same.
> There can be many possibilities if consent is lost or failed depending on
> what the application wants.
> 
> 
> >> [A.1.8 - fault and threshold conditions]
> >>
> >> This mechanism is a simple extension to existing protocols, and should
> >>fit
> >> into existing configuration and management for those protocols. [A.1.9 -
> >> configuration, A.2 - Management (in general)]
> >>
> >> It might be useful to mention the utility of tracking frequency and
> >>duration
> >> of loss and re-establishment of consent-based connectivity, as such
> >>information
> >> has operational value.  In particular, a discussion of how a server
> >>could infer
> >> loss of connectivity with a client that is using this mechanism might
> >>be useful
> >> to add, as the operational concerns may be more significant for servers
> >>and
> >> related networks than clients. [A.2.2 - management information, A.2.3 -
> >>fault
> >> management].
> 
> This again seems some thing outside the scope of this draft as it is
> trying to specify application behavior. Is there some thing that you want
> us to add in the draft for this?
> 
> Regards,
> Ram
> 
> >>
> >> The primary operational impact of this protocol should be reduction in
> >>unwanted
> >> traffic, which is a benefit - the consent check traffic added by this
> >>protocol
> >> should not have significant impacts.  The writeup indicates that
> >>implementers
> >> have reviewed the draft and implementations are in progress. [A.3 -
> >>Documentation]
> >>
> >> Thanks,
> >> --David
> >> ----------------------------------------------------
> >> David L. Black, Distinguished Engineer
> >> EMC Corporation, 176 South St., Hopkinton, MA  01748
> >> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> >> [email-masked]        Mobile: +1 (978) 394-7754
> >> ----------------------------------------------------
> >>
> >>
> >>
> >
> >

---

From: "Black, David" <[email-masked]>
Date: Wed, 27 May 2015 22:05:04 +0000

Unfortunately, one of the major issues just became much more serious.  As
part of my issue [1], I wrote:

   I don't
   see any RFCs listed as updated by this draft, so I'm guessing that this
   is not intended to promulgate new requirements for all uses of ICE and
   STUN, but this should be clarified.

Unfortunately, the required clarification is more than editorial, as upon
further reading, I see this sentence at the end of Section 3 in this draft:

   If consent is
   performed then there is no need to send keepalive messages.

However, the first sentence in section 10 of RFC 5245 says:

   All endpoints MUST send keepalives for each media session.

Therefore, this draft normatively modifies RFC 5245, but there was no
indication of that modification during IETF Last Call, as the draft
contains neither an Updates: header nor a summary description of changes
to RFC 5245.

This is a serious process problem; please work with your WG chairs and AD
to determine what to do, as your AD (Alissa) owns the decision about what
has to happen to correct this mistake in addition to correcting the text
in the draft.

----------

Moving on to concerns beyond the two major issues ... anything not
mentioned here (aside from [1] and [2] covered in my previous message, plus
the above missing info on the updates to RFC 5245) is ok with me.

> Yes we will add reference to RFC5245 that describes ICE-lite

Please add a sentence to summarize ICE-lite, not just the reference.

> >> [4] In Section 4.1, please explain or provide a reference for what "paced"

It's not clear - the word "paced" is absent, and that explanation shows up
in the middle of the next page after the use of "paced."  I suggest the
following two changes to the second paragraph in Section 4.1 for clarity:

First sentence:

   An endpoint MUST NOT send data other than paced STUN connectivity
   checks or responses toward any transport address unless the receiving
   endpoint consents to receive data.

a) Delete "paced" from the first line.
b) Add the following sentence immediately after that first sentence.

   Additional constraints apply to when these checks are allowed to be sent,
   including a minimum interval between checks, as further specified in this
   section.

-- Everything below here is editorial --

> >> This mechanism is an incremental modification to the STUN and ICE protocols,
> >> response generation behavior (already required) reflects the cryptographically
> >> strong STUN transaction IDs on which the mechanism is based.  As a result, the
> >> mechanism can be deployed at one end of a two-party communication session
> >> without impact on the other party.  This is implied by section 3 of the draft,

It does not.  Please add a sentence to say that consent
checks can be deployed via modifications solely to endpoints that send STUN
connectivity checks because implementations are already required to respond
to such checks.  A rephrasing of Section 3 would be a good means of adding this.

> between 7 to 5 times (to handle packet loss).

Please add that statement to the draft.

> >> [A.1.5 - network impact]
> >>
> >> There is an obvious fault condition, namely that consent is lost or revoked
> >> environment in which this mechanism is used, it'd be helpful to add a sentence
> >> or two on reporting of the state of STUN consent-based connectivity and how
> >> that reporting should or may relate to reporting of the state of other forms
> >> of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned in this draft.
> 

Ok, but .. this is not about "how applications should handle" loss of consent;
it's about "how implementations should report" loss of consent.  Part of this
is already in Section 7, which indicates how the application learns that
consent has expired.  It would suffice to add a sentence added to that section
to indicate that there are other reasons for loss of ability to transmit data,
and include an example of how at least one other is reported to applications.

> >> This mechanism is a simple extension to existing protocols, and should fit
> >> It might be useful to mention the utility of tracking frequency and duration
> >> of loss and re-establishment of consent-based connectivity, as such information
> >> has operational value.  In particular, a discussion of how a server could infer
> >> loss of connectivity with a client that is using this mechanism might be useful
> >> to add, as the operational concerns may be more significant for servers and
> >> related networks than clients. [A.2.2 - management information, A.2.3 - fault
> >> management].
> 

Nope, this is again about reporting information, not how applications respond to
the reports.  In addition, the consumer of this information may be a network
operation tool of some sort as opposed to a WebRTC application.  Specific details
of what to track and how to report it belong elsewhere, but it would be good to
at least add a sentence pointing out that it is useful to track frequency and
duration of loss of consent, e.g., to assist in troubleshooting application problems. 

Thanks,
--David

> From: Black, David
> Sent: Wednesday, May 27, 2015 3:17 AM
> To: Ram Mohan R (rmohanr); joel jaeggli; [email-masked]; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); [email-masked]; ops-
> [email-masked]; [email-masked]
> Cc: Black, David
> Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 28 May 2015 05:12:15 +0000

> From: Black, David [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2015 12:47 PM
> > >> [1] The draft seems to be missing discussion of applicability -
> > >> what environments and/or protocols is this mechanism intended for
> > >> or applicable to?
> 

NEW:
Consent:  The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address.  
Initial consent is obtained using ICE.

> > >> strong IDs in the TCP consent mechanism noted on p.4), and there
> > >> should be a discussion of how and why replays of previous consent
> > >> responses are harmless (will be ignored by the recipient).
> >
> > This is good enough security against an off-path attacker replaying
> > old STUN consent responses.
> 
> discussion is in draft-ietf-rtcweb-security, so that draft needs to be added as
> a normative reference, plus text added to the security considerations section
> of this consent draft to call attention to sections 3.3 and 4.2 of that rtcweb-
> security draft.  

Added the following line to security considerations section
NEW:
Consent Verification to avoid attacks using browser as an
   attack platform against machines is discussed in sections 3.2 and 4.2
   of [I-D.ietf-rtcweb-security].

> This is in addition to the citation of sections

Added draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security as normative references.

-Tiru

> > To: joel jaeggli; Black, David; [email-masked]; Dan Wing
> > (dwing); Tirumaleswar Reddy (tireddy); [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: OPS-Dir review of
> > draft-ietf-rtcweb-stun-consent-freshness-13
> >
> > Hi David/Joel,
> >
> > Subject: Re: OPS-Dir review of
> > draft-ietf-rtcweb-stun-consent-freshness-13
> >
> > >Thanks David,
> > >
> > >> I have reviewed this document as part of the Operational
> > >> directorate's ongoing effort to review all IETF documents being
> processed by the IESG.
> > >> These comments were written with the intent of improving the
> > >> operational aspects of the IETF drafts. Comments that are not
> > >> addressed in last call may be included in AD reviews during the
> > >> IESG review.  Document editors and WG chairs should treat these
> > >> comments just like any other last call comments.
> > >>
> > >> This draft describes use of STUN to obtain ongoing consent to send
> > >> in a fashion that is secured by the use of cryptographically strong
> > >> nonces as STUN transaction IDs.
> > >>
> > >> -- Major issues --
> > >>
> > >> [1] The draft seems to be missing discussion of applicability -
> > >> what environments and/or protocols is this mechanism intended for
> > >> or applicable to?  Is this generally applicable wherever ICE and
> > >> STUN are used?  I don't see any RFCs listed as updated by this
> > >> draft, so I'm guessing that this is not intended to promulgate new
> > >> requirements for all uses of ICE and STUN, but this should be
> > >> clarified.  The shepherd writeup implies that this draft is intended
> primarily for WebRTC.
> >
> > applications should use Consent. Currently on webRTC applications use
> > Consent, however any other application that has Similar security
> > requirements can use this mechanism. We will add a new section
> > ³Applicability² after the introduction section.
> >
> > <snip>
> > 2. Applicability
> >
> > 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.
> >
> > required to verify peer's consent before sending non-ICE packets can
> > use the consent mechanism described in this draft.
> >
> >
> > </snip>
> >
> >
> > applications react to changes in consent is not
> >   described in this document. The consent mechanism does not update
> > the ICE procedures defined in [RFC 5245].
> >
> >
> >
> >
> >
> >
> > >>
> > >> strong IDs in the TCP consent mechanism noted on p.4), and there
> > >> should be a discussion of how and why replays of previous consent
> > >> responses are harmless (will be ignored by the recipient).
> >
> > This is good enough security against an off-path attacker replaying
> > old STUN consent responses.
> >
> >
> >
> > >>
> > >> -- Minor Issues --
> > >>
> > >> [3] In Section 1, please explain what ICE-lite is.  A suitable
> > >> reference should suffice.
> >
> > Pacing is explained in the same section below. Let us know if this is
> > not sufficient/not clear.
> >  <snip>
> > >> The SRTP paragraph in Section 8 (Security Considerations) feels out
> > >>of place
> > >>located in  Section 3.
> > >>   == Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on
> > >>line 320, but
> > >>discussion of  applicability (major issue [1], above).
> >
> > This reference is not needed. Once we add applicability section we
> > will reference rtcweb-security-arch draft.
> >
> > >>
> > >>protocols,  and can be implemented by one party to a communication
> > >>session; ordinary  response generation behavior (already required)
> > >>reflects the cryptographically  strong STUN transaction IDs on which
> > >>the mechanism is based.  As a result, the  mechanism can be deployed
> > >>at one end of a two-party communication session  without impact on
> > >>the other party.  This is implied by section 3 of the draft,  but
> > >>would be useful to state explicitly.
> >
> > We will add a new applicability section proposed above and also
> > modified para 3 of Intro to make it clearer that this draft does not
> > change ICE procedures. Please let us know if this solves the comment
> above.
> >
> >
> > >>  [A.1.1 - deployment]
> > >>
> > >> The mechanism has been defined to limit the amount of added traffic
> > >>and to  shut down unwanted traffic, plus contains a facility to
> > >>desynchronize  independent users of this protocol.  Some rationale
> > >>should be added for  the choice of the 30 second timeout period.
> >
> > 30 second timeout period was selected so that consent checks could be
> > sent between 7 to 5 times (to handle packet loss).
> >
> >
> > >> [A.1.5 - network impact]
> > >>
> > >>revoked  causing immediate cessation of traffic.  While the details
> > >>depend on the  environment in which this mechanism is used, it'd be
> > >>helpful to add a sentence  or two on reporting of the state of STUN
> > >>consent-based connectivity and how  that reporting should or may
> > >>relate to reporting of the state of other forms  of connectivity
> > >>(e.g., TCP, SRTP/SRTCP) that are mentioned in this draft.
> >
> > changes in Consent and it was decided to keep it outside the scope of
> > this draft. Para 3 of introduction already has a text that says the same.
> > There can be many possibilities if consent is lost or failed depending
> > on what the application wants.
> >
> >
> > >> This mechanism is a simple extension to existing protocols, and
> > >>should fit  into existing configuration and management for those
> > >>protocols. [A.1.9 -  configuration, A.2 - Management (in general)]
> > >>
> > >>duration  of loss and re-establishment of consent-based
> > >>connectivity, as such information  has operational value.  In
> > >>particular, a discussion of how a server could infer  loss of
> > >>connectivity with a client that is using this mechanism might be
> > >>useful  to add, as the operational concerns may be more significant
> > >>for servers and  related networks than clients. [A.2.2 - management
> > >>information, A.2.3 - fault  management].
> >
> > trying to specify application behavior. Is there some thing that you
> > want us to add in the draft for this?
> >
> > Regards,
> > Ram
> >
> > >>
> > >> The primary operational impact of this protocol should be reduction
> > >>in unwanted  traffic, which is a benefit - the consent check traffic
> > >>added by this protocol  should not have significant impacts.  The
> > >>writeup indicates that implementers  have reviewed the draft and
> > >>implementations are in progress. [A.3 - Documentation]
> > >>
> > >> Thanks,
> > >> --David
> > >> David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > >> St., Hopkinton, MA  01748

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 May 2015 12:50:35 +0200

> Initial consent is obtained using ICE.

CLarity stickler: Delete "initial" above. As defined in this
specification, *all* consent is obtained using ICE.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 28 May 2015 10:55:03 +0000

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Thursday, May 28, 2015 4:21 PM
> To: Tirumaleswar Reddy (tireddy); Black, David; Ram Mohan R (rmohanr);
> joel jaeggli; [email-masked]; Dan Wing (dwing);
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-
> freshness-13
> 
> > Consent:  The mechanism of obtaining permission from the remote
> endpoint to send non-ICE traffic to a remote transport address.
> CLarity stickler: Delete "initial" above. As defined in this specification, *all*
> consent is obtained using ICE.

Fixed.

-Tiru

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2015 16:41:41 -0700

I apologize for not catching these, but I think that you are
collectively headed toward changing the intent of the draft in ways
that might not be good.  Unfortunately, I'm not always able to consume
the amount of email that is produced in relation to this draft.

> contains neither an Updates: header nor a summary description of changes

That's one interpretation.  Or, we could say - more explicitly - that
this is intentionally contrary to the advice in RFC 5245.  We're
overriding 5245, not patching it.  Other users of RFC 5245 can
continue to be bound by the restriction.

BTW, no ICE implementation I'm aware of follows the requirement to
send keep-alives (I'm certain that some compliant implementations
exist, just that my limited exposure hasn't included one).  That
reduces the risk that a recipient is checking and enforcing that peers
are sending keepalives to nil, in case you are concerned about the
interop risk.

>> Pacing is explained in the same section below. Let us know if this is not

Actually, "paced" has a specific meaning in ICE and the word was used
intentionally: https://tools.ietf.org/html/rfc5245#section-16

The intent is to permit ICE connectivity checking, no more, no less.
Absolutely not consent maintenance.

Perhaps something like:

   An endpoint MUST NOT send data toward any transport address unless
the receiving endpoint has consented to receive data, unless the
messages are those that are used to establish consent.  Connectivity
checks that are paced as described in Section 16 of [RFC5245] and
responses to connectivity checks are permitted.

---
I disagree with David about the editorial nature of some of the
changes he suggests, but I'm prepared to wait for proposals and
discuss them.  I'd be very happy if those changes manifested in the
form of pull requests.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 28 May 2015 06:29:56 +0000

> Sent: Thursday, May 28, 2015 3:35 AM
> [email-masked]; [email-masked]; Black, David
> Cc: Black, David; [email-masked]; Alissa Cooper
> ([email-masked])
> indication of that modification during IETF Last Call, as the draft contains
> neither an Updates: header nor a summary description of changes to RFC
> 5245.
> 
> has to happen to correct this mistake in addition to correcting the text in the
> draft.
> 
> ----------
> 
> mentioned here (aside from [1] and [2] covered in my previous message,
> plus the above missing info on the updates to RFC 5245) is ok with me.
> 

NEW:
ICE-lite agent defined in section 2.7 of [RFC5245] does not generate connectivity
   checks or runs the ICE state machine, it only needs to be able to
   respond to connectivity checks.  Hence an ICE-lite implementation
   will not generate consent checks, but will just respond to consent
   checks it receives.  No changes are required to ICE-lite
   implementations in order to respond to consent checks, as they are
   processed as normal ICE connectivity checks.

> It's not clear - the word "paced" is absent, and that explanation shows up in
> the middle of the next page after the use of "paced."  I suggest the following
> two changes to the second paragraph in Section 4.1 for clarity:
> 
> First sentence:
> 
> > >> the other party.  This is implied by section 3 of the draft, but would be
> useful to state explicitly.
> >
> It does not.  Please add a sentence to say that consent checks can be
> deployed via modifications solely to endpoints that send STUN connectivity
> checks because implementations are already required to respond to such
> checks.  A rephrasing of Section 3 would be a good means of adding this.

Section 3.

NEW:
The mechanism proposed in the document is an optional extension to the ICE protocol, it can be deployed at one end of the two-party communication session without impact on the other party.

> Please add that statement to the draft.

NEW:
30 second timeout period was selected so that consent checks could be sent between 7 to 5 times to handle packet loss.

> > >> relate to reporting of the state of other forms of connectivity (e.g., TCP,
> SRTP/SRTCP) that are mentioned in this draft.
> >
> consent has expired.  It would suffice to add a sentence added to that
> section to indicate that there are other reasons for loss of ability to transmit
> data, and include an example of how at least one other is reported to
> applications.

NEW:
The circuit breaker algorithm discussed in section 7.1 of [I-D.ietf-rtcweb-rtp-usage] could be one of the reasons for ceasing transmission of media and to notify the application about the loss of ability to transmit data.

> Nope, this is again about reporting information, not how applications
> respond to the reports.  In addition, the consumer of this information may
> be a network operation tool of some sort as opposed to a WebRTC
> application.  Specific details of what to track and how to report it belong
> elsewhere, but it would be good to at least add a sentence pointing out that
> it is useful to track frequency and duration of loss of consent, e.g., to assist in
> troubleshooting application problems.

NEW:
WebRTC client application may in-turn notify WebRTC server about loss of consent so that it can track frequency and duration of loss of consent , e.g., to assist in troubleshooting application problems.

Cheers,
-Tiru

> > To: Ram Mohan R (rmohanr); joel jaeggli; [email-masked]; Dan
> > Wing (dwing); Tirumaleswar Reddy (tireddy); [email-masked];
> > ops- [email-masked]; [email-masked]
> > Cc: Black, David
> > Subject: RE: OPS-Dir review of
> > > >> or
> > applicable
> > > >> There should be an explanation of why cryptographically strong
> > > >> STUN transaction IDs are required (e.g., there are no
> > > >> cryptographically strong IDs in the TCP consent mechanism noted
> > > >> on p.4), and there should be a discussion of how and why replays
> > > >> of previous consent responses are harmless (will be ignored by the
> recipient).
> > >
> > > >> appears to be ok, but this rationale should be provided in terms
> > > >>of  attacks that are of concern and how they are prevented - a
> > > >>primary  intent appears to be to resisting off-path attacks.
> > >
> > That's good, but the actual problem is a missing reference.  The
> > rationale discussion is in draft-ietf-rtcweb-security, so that draft
> > needs to be added as a normative reference, plus text added to the
> > security considerations section of this consent draft to call
> > attention to sections 3.3 and 4.2 of that rtcweb-security draft.  This
> > is in addition to the citation of sections
> > > Employee <[email-masked]>, "[email-masked]"
> > > <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> > > <[email-masked]>
> >
> > > >> This draft describes use of STUN to obtain ongoing consent to
> > > >> send in a fashion that is secured by the use of cryptographically
> > > >> strong nonces as STUN transaction IDs.
> > > >>
> > > >> -- Major issues --
> > > >>
> > > >> or
> > applicable
> > > >> to?  Is this generally applicable wherever ICE and STUN are used?
> > > >> I
> > don't
> > > >> see any RFCs listed as updated by this draft, so I'm guessing
> > > >> that this is not intended to promulgate new requirements for all
> > > >> uses of ICE and STUN, but this should be clarified.  The shepherd
> > > >> writeup implies that this draft is intended primarily for WebRTC.
> > >
> > > applications should use Consent. Currently on webRTC applications
> > > use Consent, however any other application that has Similar security
> > > 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
> > > 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.
> > >
> > >
> > > </snip>
> > >
> > >
> > > >> There should be an explanation of why cryptographically strong
> > > >> STUN transaction IDs are required (e.g., there are no
> > > >> cryptographically strong IDs in the TCP consent mechanism noted
> > > >> on p.4), and there should be a discussion of how and why replays
> > > >> of previous consent responses are harmless (will be ignored by the
> recipient).
> > >
> > > >> appears to be ok, but this rationale should be provided in terms
> > > >>of  attacks that are of concern and how they are prevented - a
> > > >>primary  intent appears to be to resisting off-path attacks.
> > >
> > > Pacing is explained in the same section below. Let us know if this
> > > is not sufficient/not clear.
> > >  <snip>
> > > >> The SRTP paragraph in Section 8 (Security Considerations) feels
> > > >>out of place
> > > >>reflects the cryptographically  strong STUN transaction IDs on
> > > >>which the mechanism is based.  As a result, the  mechanism can be
> > > >>deployed at one end of a two-party communication session  without
> > > >>impact on the other party.  This is implied by section 3 of the
> > > >>draft,  but would be useful to state explicitly.
> > >
> > > >> The mechanism has been defined to limit the amount of added
> > > >>traffic and to  shut down unwanted traffic, plus contains a
> > > >>facility to desynchronize  independent users of this protocol.
> > > >>Some rationale should be added for  the choice of the 30 second
> > > >>timeout period.
> > >
> > > 30 second timeout period was selected so that consent checks could
> > > be sent between 7 to 5 times (to handle packet loss).
> > >
> > >
> > > >> [A.1.5 - network impact]
> > > >>
> > > >> There is an obvious fault condition, namely that consent is lost
> > > >>or revoked  causing immediate cessation of traffic.  While the
> > > >>details depend on the  environment in which this mechanism is
> > > >>used, it'd be helpful to add a sentence  or two on reporting of
> > > >>the state of STUN consent-based connectivity and how  that
> > > >>reporting should or may relate to reporting of the state of other
> > > >>forms  of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned
> > > >>in this draft.
> > >
> > > changes in Consent and it was decided to keep it outside the scope
> > > of this draft. Para 3 of introduction already has a text that says the same.
> > > There can be many possibilities if consent is lost or failed
> > > depending on what the application wants.
> > >
> > >
> > > >> It might be useful to mention the utility of tracking frequency
> > > >>and duration  of loss and re-establishment of consent-based
> > > >>useful  to add, as the operational concerns may be more
> > > >>significant for servers and  related networks than clients. [A.2.2
> > > >>- management information, A.2.3 - fault  management].
> > >
> > > >> The primary operational impact of this protocol should be
> > > >>reduction in unwanted  traffic, which is a benefit - the consent
> > > >>check traffic added by this protocol  should not have significant
> > > >>impacts.  The writeup indicates that implementers  have reviewed
> > > >>the draft and implementations are in progress. [A.3 -
> > > >>Documentation]
> > > >>
> > > >> Thanks,
> > > >> --David

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 May 2015 19:36:54 +0000

Hi Martin,

> continue to be bound by the restriction.

That's fine, but something does have to be done about that RFC 5245 "MUST"
requirement, which is a "requirement" not just "advice" ;-).

I'd expect that even overriding RFC 5245 counts as an Update,
because the result would be that the original RFC 5245 "MUST" requirement
is no longer globally applicable to all uses of RFC 5245.  In other words,
overriding RFC 5245 effectively rewrites the "MUST" to become "MUST, except
as further specified by the consent RFC."

Sorry to put the emphasis on the "Update" process, but I've recently had a
*very* long discussion about whether or not it was ok for another draft to
modify an underlying RFC - the answer in that other case was "<bleep> NO!"
and some interesting text editing resulted.  In contrast, for the present
situation case, I would think that overriding RFC 5245 is ok, but that
change does need to be called out.

> responses to connectivity checks are permitted.

That new text looks good.

> discuss them.  I'd be very happy if those changes manifested in the

To the extent that my "editorial" suggestions aren't actually editorial,
the suggestions are probably wrong.  As they're intended to be editorial,
I'm ok with them being ignored or dealt with in some other fashion.

Thanks,
--David

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2015 7:42 PM
> To: Black, David
> Cc: Ram Mohan R (rmohanr); joel jaeggli; [email-masked]; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked];
> [email-masked]; Alissa Cooper ([email-masked])

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 May 2015 13:25:40 -0700

Hi David,

On Thu, May 28, 2015 at 12:36 PM, Black, David <[email-masked]>

> as further specified by the consent RFC."

​So I agree with you that this must be called out, but I think "Updates" is
wrong for the draft's current intent.  I think what Martin has said amounts
to "We have chosen to follow RFC 5245 except as detailed in sections X and
Y, where we use a different set of messages to optimize the combination of
heartbeat and consent."  We are not updating RFC 5245 thereby, because we
are neither changing its core semantics nor offering to add a new, general
semantic to RFC 5245 (we could have made that choice, but are not doing so
now).  Instead of updating RFC 5245, in other words, we are limiting our
reference to it.

That should be done explicitly, and I think it should be called it
suffiiciently that a new spin of the draft likely needs a new round of
review.  But I don't think we are required to update RFC 5245 to get that
done.

I've referred the matter to our friendly AD, and we await her reading on
next steps on this.  In either approach, however, this will get called out.

regards,

Ted HArdie​

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 May 2015 01:23:44 +0000

Hi,

Section 20.2.3 of RFC 5245 says:

“STUN keepalives (in the form of STUN Binding Indications) are sent in
              the middle of a media session.  However, they are sent only in the
              absence of actual media traffic.”

So, in the consent draft we could say that, from a keepalive perspective, consent requests are considered media traffic. That would then implicitly mean that actual keepalives aren’t sent when consent is used. That way, the consent spec would be compliant to 5245, and there would be no need for any update etc…

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 28 May 2015 23:26
To: Black, David
Cc: [email-masked]; joel jaeggli; [email-masked]; [email-masked]
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi David,

On Thu, May 28, 2015 at 12:36 PM, Black, David <[email-masked]<mailto:[email-masked]>>

​So I agree with you that this must be called out, but I think "Updates" is wrong for the draft's current intent.  I think what Martin has said amounts to "We have chosen to follow RFC 5245 except as detailed in sections X and Y, where we use a different set of messages to optimize the combination of heartbeat and consent."  We are not updating RFC 5245 thereby, because we are neither changing its core semantics nor offering to add a new, general semantic to RFC 5245 (we could have made that choice, but are not doing so now).  Instead of updating RFC 5245, in other words, we are limiting our reference to it.
That should be done explicitly, and I think it should be called it suffiiciently that a new spin of the draft likely needs a new round of review.  But I don't think we are required to update RFC 5245 to get that done.
I've referred the matter to our friendly AD, and we await her reading on next steps on this.  In either approach, however, this will get called out.
regards,
Ted HArdie​

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 29 May 2015 01:57:21 +0000

Good point. We discuss the following point in section 4.1 of the draft about keepalives:

   An endpoint that is not sending any application data does not need to
   maintain consent.  However, not sending any traffic could cause NAT
   or firewall mappings to expire.  Furthermore, having one peer unable
   to send is detrimental to many protocols.  Absent better information
   about the network, if an endpoint needs to ensure its NAT or firewall
   mappings do not expire, it can be done using keepalive or other
   techniques (see Section 10 of [RFC5245]<http://tools.ietf.org/html/rfc5245#section-10> and see [RFC6263<http://tools.ietf.org/html/rfc6263>]).

So there is no need to send keepalives because of the media traffic as it is pointed out in Section 20.2.3 of RFC 5245 irrespective of whether consent is used or not. I think we can remove the following line in “If consent is performed then there is no need to send keepalive messages." and avoid the confusion of updating RFC 5245.

-Tiru

From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, May 29, 2015 6:54 AM
To: Ted Hardie; Black, David
Cc: joel jaeggli; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi,

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 28 May 2015 23:26
To: Black, David
Cc: [email-masked]<mailto:[email-masked]>; joel jaeggli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi David,

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 May 2015 02:06:40 +0000

Hi,

> So there is no need to send keepalives because of the media traffic as it is pointed out in Section 20.2.3 of RFC 5245
> irrespective of whether consent is used or not. I think we can remove the following line in “If consent is performed then
> there is no need to send keepalive messages." and avoid the confusion of updating RFC 5245.

I agree that the current text can confuse people, but I still think it would be good to have explicit text saying that keepalives are not sent. Perhaps something like:

“From a keepalive perspective, consent requests are considered media traffic. Because of that, dedicated keepalives (e.g. STUN binding requests) are not sent on candidate pairs where consent requests are sent, in accordance with Section 20.2.3 of [RFC5245].”

Regards,

Christer

Cc: joel jaeggli; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi,

Regards,

Christer

Hi David,

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 29 May 2015 02:59:29 +0000

I am fine with the below proposed text from Christer. It indicates that  consent document does NOT update RFC 5245 which was the confusion we have with the existing text in the draft.

Ram

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday, 29 May 2015 7:36 am
To: "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>, Ted Hardie <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: joel jaeggli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi,

Regards,

Christer

Hi,

Regards,

Christer

Hi David,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 29 May 2015 03:19:56 +0000

From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, May 29, 2015 7:37 AM
To: Tirumaleswar Reddy (tireddy); Ted Hardie; Black, David
Cc: joel jaeggli; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi,

Works for me (Replaced STUN binding requests with STUN Binding Indications in the above line).

Cheers,
-Tiru

Regards,

Christer

Hi,

Regards,

Christer

Hi David,

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 May 2015 18:11:28 +0000

That also works for me, and neatly sidesteps the concern about
whether RFC 5245 is being updated.

Thanks,
--David

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Thursday, May 28, 2015 11:20 PM
To: Christer Holmberg; Ted Hardie; Black, David
Cc: joel jaeggli; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi,

Cheers,
-Tiru

Regards,

Christer

Hi,

Regards,

Christer

Hi David,