Last Call Review of draft-ietf-mmusic-sdp-miscellaneous-caps-05
review-ietf-mmusic-sdp-miscellaneous-caps-05-secdir-lc-meadows-2013-06-07-00

Request Review of draft-ietf-mmusic-sdp-miscellaneous-caps
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-04
Requested 2013-05-23
Authors Miguel García, Simo Veikkolainen, Robert Gilman
Draft last updated 2013-06-07
Completed reviews Genart Last Call review of -05 by Roni Even (diff)
Genart Telechat review of -06 by Roni Even (diff)
Secdir Last Call review of -05 by Catherine Meadows (diff)
Assignment Reviewer Catherine Meadows
State Completed
Review review-ietf-mmusic-sdp-miscellaneous-caps-05-secdir-lc-meadows-2013-06-07
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Review completed: 2013-06-07

Review
review-ietf-mmusic-sdp-miscellaneous-caps-05-secdir-lc-meadows-2013-06-07

I have 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.

This ID defines three new capabilities that can be negotiated in the Session Description Protocols (SDP) using the SDP offer/answer

procedure.  These are bandwidth capability (proposed bandwidth to be used by session or media), connection capability (network type, address

type, and address), and title capability (human-readable textual information about the session).

None of these are directly security-related, although the authors point out that an attacker who

is able to modify traffic could modify the bandwidth value so that then network winds up being under-utilized

or over-utilized.  They recommend using on of the security mechanisms recommended in RFC5939 (which defines SDP capability negotiation

in general) in case

it is necessary to protect the bandwidth value.  

I think this is a very appropriate recommendation for this ID, but perhaps the authors should consider offering similar recommendations

for the other capabilities.  For example, in the connection capability it is possible to offer an address together with a number of alternatives.

What happens if an attacker removes some or most of the addresses?  Could this lead to overuse of the remaining addresses?  Likewise, one of the reasons the human-readable

title capability is provided is so that a human can make choices about which media configurations to choose.  If the attacker tampers with a label so that the human is caused to make wrong choices, this could again

cause problems.  I think it could be worthwhile to point out that there may be cases for both connection and title capabilities where adversarial tampering could have harmful effects,

and if this is the case the security mechanisms in RFC5939 should be applied as well. 




Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email: 

catherine.meadows at nrl.navy.mil