Re: [secdir] Secdir review of draft-ietf-mmusic-sdp-bundle-negotiation-48

[Christer Holmberg <[e-mail]>]

Hi Charlie,

Thanks for your review! Please see inline.


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



"Unique Address" will be changed to "Unique Address:Port", similar to e.g., "BUNDLE Address:Port". The definition already indicates that it includes the port:



      "Unique address: An address:port combination that is assigned to only one "m=" section in an offer or answer."



> 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).



In SDP Offer/Answer (RFC 3264) you always indicate the address:port where you will RECEIVE media. That has caused some problems every now and then, but it's not within the scope of the draft to change that.



However, BUNDLE actually mandates usage of the SAME address:port for both sending AND receiving media, so in practise you DO indicate from where media will be sent :)



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



Good :)



It is also worth noting that, as BUNDLE is an extension to RFC 3264 (SDP Offer/Answer), one needs to be familiar with that specification in order to fully understand BUNDLE.



Regards,



Christer