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

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

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: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; Black, David; [e-mail]
> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>