Last Call Review of draft-ietf-mmusic-connectivity-precon-
review-ietf-mmusic-connectivity-precon-secdir-lc-kent-2009-10-08-00

Request Review of draft-ietf-mmusic-connectivity-precon
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-14
Requested 2009-09-30
Draft last updated 2009-10-08
Completed reviews Secdir Last Call review of -?? by Stephen Kent
Secdir Telechat review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-mmusic-connectivity-precon-secdir-lc-kent-2009-10-08
Review completed: 2009-10-08

Review
review-ietf-mmusic-connectivity-precon-secdir-lc-kent-2009-10-08

Title: 

review of
draft-ietf-mmusic-connectivity-precon-06




I reviewed this
document as part of the security directorate's ongoing effort to
review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.







The document
"draft-ietf-mmusic-connectivity-precon-06" defines "a new
connectivity precondition for the Session Description Protocol (SDP)
precondition framework." Connectivity preconditions are used to
delay session establishment (or modification) until media stream
connectivity has been verified. The use of preconditions represents an
interesting twist on the original SDP model, where the assumption was
that an SDP session would be established before media streams were
established! The use of preconditions is motivated in large part by
the need for media streams to traverse firewalls and NATs.





The Security Considerations section here starts by citing the Security
Considerations section from the base preconditions RFC (3312). It also
adds two paragraphs to discuss new considerations relevant to the
precondition types defined in this document. This is an appropriate
way to address new security issues that arise for extensions to
previously-defined functions. RFC 3312 has a two-paragraph Security
Considerations section, which identifies concerns, but make no
recommendations about security mechanisms to employ! This document has
a paragraph that RECOMMENDS use of integrity for the SDP traffic,
e.g., via RFC 3261, to counter attacks against this portion of the
system. This is a concrete recommendation that is appropriate for this
aspect of the security concerns cited, and is applicable to the 3312
security concerns as well.





The new security concerns that arise here result from reliance on
other protocols to detect successful media stream establishment. This
motivates concerns about two classes of DoS attacks: transient attacks
that cause session establishment to fail (when the media streams could
have been created) and transient attacks that make it appear that
media streams have been established, when in fact they have not.





TCP and ICE are the protocols cited specifically as one of interest.
The text RECOMMDNDS making use of suitable authentication and
integrity mechanisms for the relevant protocols to counter both forms
of attacks. The text also says that "the mechanisms SHOULD consider
how to prevent denial of service attacks."





I find this text to be too vague to be useful. It ought to cite
specific mechanisms in RFCs, at least as examples, preferably as
recommendations. The lack of specific, cited mechanisms makes this
section almost vacuous. I suggest that the authors revise the text
here to cite appropriate mechanisms.