Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-14

From: "Black, David" <[email-masked]>
Date: Tue, 9 Jun 2015 19:09:23 +0000

As a result of lengthy ;-) discussion, the -14 version of this draft addresses all of the concerns in the OPS-Dir review of the -13 version, as well as the subsequent concern about whether this draft is an update to RFC 5245.  That latter update concern has been resolved with a conclusion that this draft does not update RFC 5245 - the keepalive material in this draft has been revised to explain how consent checks effectively serve as keepalives, removing any need to send separate keepalives in a fashion that's compatible with RFC 5245.

I noticed a minor editorial nit:

- Section 1, top of p.3

   Consent is obtained only by full ICE implementations.  An ICE-lite
   agent (as defined in Section 2.7 of [RFC5245]) does not generate
   connectivity checks or run the ICE state machine.  An ICE-lite agent
   does not generate consent checks, it will only respond to any checks
   that it receives.

I'd change the start of latter sentence to better connect it to the 
previous sentence:

   "An ICE-lite agent" -> "Hence, an ICE-lite agent"

also:

   "consent checks, it will" -> "consent checks and will"

idnits 2.13.02 ran clean.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Thursday, May 14, 2015 7:21 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; Black, David; [email-masked]
> Subject: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
> 
> 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.
> 
> [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).  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.
> 
> -- Minor Issues --
> 
> [3] In Section 1, please explain what ICE-lite is.  A suitable reference
> should suffice.
> 
> [4] In Section 4.1, please explain or provide a reference for what "paced"
> means in "paced STUN connectivity checks or responses."
> 
> -- 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.
> 
> 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).
> 
> --- 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.  [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.  [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.
> [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].
> 
> 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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 10 Jun 2015 15:13:33 +0000

> From: Black, David [mailto:[email-masked]]
> Sent: Wednesday, June 10, 2015 12:39 AM
> To: [email-masked]; Dan Wing (dwing); Ram Mohan R (rmohanr);
> Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Black, David
> Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-14
> 
> As a result of lengthy ;-) discussion, the -14 version of this draft addresses all of
> the concerns in the OPS-Dir review of the -13 version, as well as the subsequent
> concern about whether this draft is an update to RFC 5245.  That latter update
> concern has been resolved with a conclusion that this draft does not update
> RFC 5245 - the keepalive material in this draft has been revised to explain how
> consent checks effectively serve as keepalives, removing any need to send
> separate keepalives in a fashion that's compatible with RFC 5245.
> 
> I'd change the start of latter sentence to better connect it to the previous
> sentence:
> 

Thanks, fixed in my local copy.

-Tiru

> > 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.
> >
> > a fashion that is secured by the use of cryptographically strong
> > nonces as STUN transaction IDs.
> >
> > -- Major issues --
> >
> > 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.
> >
> > 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).  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.
> >
> > -- Minor Issues --
> >
> > [3] In Section 1, please explain what ICE-lite is.  A suitable
> > reference should suffice.
> >
> > - this looks like design rationale material that would be better
> > located in Section 3.
> >
> > That reference is likely to be useful to address the absence of
> > discussion of applicability (major issue [1], above).
> >
> > 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.  [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.
> > [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.
> > 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].
> >
> > 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