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 rev. | 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 Alvestrand, Cullen Jennings | |
| Draft 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 | |
| Review | review-ietf-mmusic-sdp-bundle-negotiation-48-secdir-lc-kaufman-2018-02-16 | |
| Reviewed rev. | 48 (document currently at 54) | |
| Review result | Has Nits | |
| Review completed: | 2018-02-16 |
Review
review-ietf-mmusic-sdp-bundle-negotiation-48-secdir-lc-kaufman-2018-02-16
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