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 at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------