|
RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-14
2015-06-10 10:14:07
-----Original Message-----
From: Black, David [mailto:david(_dot_)black(_at_)emc(_dot_)com]
Sent: Wednesday, June 10, 2015 12:39 AM
To: muthu(_dot_)arul(_at_)gmail(_dot_)com; Dan Wing (dwing); Ram Mohan R
(rmohanr);
Tirumaleswar Reddy (tireddy); martin(_dot_)thomson(_at_)gmail(_dot_)com;
ops-dir(_at_)ietf(_dot_)org
Cc: rtcweb(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 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(_dot_)arul(_at_)gmail(_dot_)com; dwing(_at_)cisco(_dot_)com;
rmohanr(_at_)cisco(_dot_)com;
tireddy(_at_)cisco(_dot_)com; martin(_dot_)thomson(_at_)gmail(_dot_)com;
ops-dir(_at_)ietf(_dot_)org
Cc: rtcweb(_at_)ietf(_dot_)org; Black, David; ietf(_at_)ietf(_dot_)org
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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
|
|