Skip to main content

Last Call Review of draft-ietf-mmusic-sdp-bundle-negotiation-48
review-ietf-mmusic-sdp-bundle-negotiation-48-secdir-lc-kaufman-2018-02-16-00

Request Review of draft-ietf-mmusic-sdp-bundle-negotiation
Requested revision No specific revision (document currently at 54)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-02-14
Requested 2018-01-31
Authors Christer Holmberg , Harald T. Alvestrand , Cullen Fluffy Jennings
I-D last updated 2018-02-16
Completed reviews Secdir Last Call review of -48 by Charlie Kaufman (diff)
Genart Last Call review of -48 by Linda Dunbar (diff)
Genart Telechat review of -49 by Linda Dunbar (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Request Last Call review on draft-ietf-mmusic-sdp-bundle-negotiation by Security Area Directorate Assigned
Reviewed revision 48 (document currently at 54)
Result Has nits
Completed 2018-02-16
review-ietf-mmusic-sdp-bundle-negotiation-48-secdir-lc-kaufman-2018-02-16-00
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 specification defines an enhancement to the RTP Control Protocol (RTCP)
defined in RFC3264. The enhancement allows multiple items over a single RTP
channel with interleaved packets. This is harder than one would expect in part
because the protocol change has to deal with backward compatibility and
interoperability between implementations that include the enhancement and those
that don't.

While I can't claim to have understood the entire spec, I can confidently agree
with the authors that this enhancement does not change the security
considerations from those specified in RFCs 3264 and 5888.

Other thoughts:

The use of the term "Unique Address" for the combination of an IP address and a
port number is a little confusing, especially when interleaved with references
to 5-tuples as connection identifiers. Since this protocol is always (?)
transmitted over UDP, it would be good to mention somewhere that two unique
addresses together make a connection identifier (where UDP is implied) and that
a Unique Address is the combination of an IP address and a UDP port number.

Given the large numbers of NATs out there, I'm surprised the protocol does not
make itself a little more NAT friendly by allowing an address specification
with an ability to specify "The IP address from which this message is arriving"
so that NAT'd connections will be handled correctly (at least in the most
common case).

Section 18 (examples) is a very welcome addition that I wish were present in
more RFCs. It goes a long way toward making otherwise difficult to parse
sections of the document more comprehensible.

 --Charlie