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