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

["Black, David" <[e-mail]>]

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.

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

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

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

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.

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

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

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.

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

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

> -----Original Message-----
> From: Black, David
> Sent: Wednesday, May 27, 2015 3:17 AM
> To: Ram Mohan R (rmohanr); joel jaeggli; [e-mail]; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); [e-mail]; ops-
> [e-mail]; [e-mail]
> Cc: Black, David
> Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
> 
> 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:[e-mail]]
> > Sent: Tuesday, May 19, 2015 11:28 AM
> > To: joel jaeggli; Black, David; [e-mail]; Dan Wing (dwing);
> > Tirumaleswar Reddy (tireddy); [e-mail]; [e-mail];
> > [e-mail]
> > 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 <[e-mail]>
> > Date: Friday, 15 May 2015 4:59 am
> > To: "Black, David" <[e-mail]>, "[e-mail]"
> > <[e-mail]>, "[e-mail]" <[e-mail]>, Cisco
> > Employee <[e-mail]>, "[e-mail]" <[e-mail]>,
> > "[e-mail]" <[e-mail]>, "[e-mail]"
> > <[e-mail]>
> 
> > Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> > 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
> > >> [phone]             FAX: [phone]
> > >> [e-mail]        Mobile: [phone]
> > >> ----------------------------------------------------
> > >>
> > >>
> > >>
> > >
> > >