> -----Original Message----- > From: Black, David [mailto:david.black@xxxxxxx] > Sent: Wednesday, June 10, 2015 12:39 AM > To: muthu.arul@xxxxxxxxx; Dan Wing (dwing); Ram Mohan R (rmohanr); > Tirumaleswar Reddy (tireddy); martin.thomson@xxxxxxxxx; ops-dir@xxxxxxxx > Cc: rtcweb@xxxxxxxx; ietf@xxxxxxxx; 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: muthu.arul@xxxxxxxxx; dwing@xxxxxxxxx; rmohanr@xxxxxxxxx; > > tireddy@xxxxxxxxx; martin.thomson@xxxxxxxxx; ops-dir@xxxxxxxx > > Cc: rtcweb@xxxxxxxx; Black, David; ietf@xxxxxxxx > > 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 > > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > >