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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Wednesday, June 10, 2015 12:39 AM
> To: [e-mail]; Dan Wing (dwing); Ram Mohan R (rmohanr);
> Tirumaleswar Reddy (tireddy); [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; 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 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"

Thanks, fixed in my local copy.

-Tiru

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