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. > > [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 > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > >
Attachment:
signature.asc
Description: OpenPGP digital signature