MMUSIC Working Group F. Andreasen Internet-Draft Cisco Systems Intended Status: None June 7, 2007 Expires: December 2007 SDP Capability Negotiation: Deleting and Replacing Attributes draft-andreasen-mmusic-sdpcapneg-att-del-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The current SDP Capability Negotiation solution includes the ability for a potential configuration to delete and replace individual attributes from the actual configuration. This capability introduces some complexity into the SDP Capability Negotiation framework and this document examines the need for having this feature and proposes a way forward. Andreasen Expires December 7, 2007 [Page 1] Internet-Draft SDP Capability Negotiation June 2007 Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................2 3. To Add, Delete or Replace Attributes...........................2 3.1. Deleting Attributes.......................................3 3.1.1. 1) Unintended processing of a well-known attribute when parts of the SDP is changed.................................4 3.1.2. Unclear interactions between two different attributes (for example two different attribute names).................6 3.2. Replace Attributes........................................7 4. Conclusion.....................................................8 5. Security Considerations........................................9 6. IANA Considerations............................................9 7. References....................................................10 7.1. Normative References.....................................10 7.2. Informative References...................................10 Author's Addresses...............................................12 Intellectual Property Statement..................................13 Full Copyright Statement.........................................13 Acknowledgment...................................................13 1. Introduction The current SDP Capability Negotiation solution [sdpcapneg] includes the ability for a potential configuration to delete and replace individual attributes from the actual configuration. This capability introduces some complexity into the SDP Capability Negotiation framework. In this document, we examine the need for having this feature in Section 3. and then propose a way forward in Section 4. It is assumed that the reader is familiar with the [sdpcapneg]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. To Add, Delete or Replace Attributes In the SDP Capability Negotiation framework solution [sdpcapneg] the SDP provided includes attributes as part of the actual configuration in the offer (and answer) SDP. If one or more attributes are unknown Andreasen Expires December 7, 2007 [Page 2] Internet-Draft SDP Capability Negotiation June 2007 or unsupported, the answerer will ignore those attributes per normal SDP rules [RFC4566]. The SDP Capability Negotiation framework defines attribute capabilities, and enables one or more of those attribute capabilities to be used in one of the potential configuration SDPs, whereby it becomes part of the alternative offer. The potential configuration SDP is formed by taking the actual configuration SDP (the offer) and add the attribute capability values that are referenced by the potential configuration. The primary reason for doing this is to control which attribute capability values are part of a potential configuration SDP. This enables alternative attribute types and values to be ordered by preference and for different attributes (including different types, e.g. keying mechanisms) to be chosen for a particular potential configuration. The SDP Capability Negotiation framework currently also defines mechanisms for: 1) DELETING one or more attributes from the actual configuration SDP when forming the potential configuration SDP 2) REPLACING one or more attributes from the actual configuration SDP with an attribute capability value when forming the potential configuration SDP. The ability to delete and replace attributes from the actual configuration SDP adds some complexity to the SDP Capability Negotiation framework. The question has been raised whether these features are necessary. Below we provide motivation for each. 3.1. Deleting Attributes When it comes to the need for deleting attributes from the actual configuration SDP, the basic question is whether presence of a particular SDP attribute can cause unintended operation to occur, i.e., can an SDP attribute actually be harmful. Since SDP will always ignore unknown attributes, harmful operation can occur only when a particular attribute is supported by the recipient (answerer). At the heart of this issue is how SDP attributes are processed, and in particular whether presence of what appears to be a meaningless SDP attribute can interfere with normal or intended offer/answer processing. For example, if a UDP-based media stream is being established, and TCP-based parameters are included (e.g. per RFC Andreasen Expires December 7, 2007 [Page 3] Internet-Draft SDP Capability Negotiation June 2007 4145), will those parameters be ignored, or will the answerer instead view the SDP (or media stream) as malformed and reject it ? Since SDP requires unknown attributes to be ignored, and general IETF principles prescribe being liberal in what you receive, we will *assume*, that in the absence of specific rules to the contrary, an SDP implementation will indeed ignore not only unknown SDP attributes, but also SDP attributes that do not otherwise seem to apply to a given SDP. Without this assumption, the issue at hand is closed inasmuch as we clearly would need the ability to delete attributes. With the above assumption, we are left with two classes of problems for specific well-known attributes: 1) Unintended processing of a well-known attribute when parts of the SDP is changed. 2) Unclear interactions between two different attributes (for example two different attribute names). Below, we look at each of these separately and provide example scenarios 3.1.1. 1) Unintended processing of a well-known attribute when parts of the SDP is changed. An example of this is when the actual configuration offers an SRTP media stream, and the alternative potential configuration uses plain RTP. In the following example, the actual configuration includes keying material in a "crypto" attribute as illustrated below: v=0 o=alice 2891092738 2891092738 IN IP4 lost.example.com s= t=0 0 c=IN IP4 lost.example.com m=audio 59000 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=tcap RTP/SAVP RTP/AVP a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=pcfg:1 a=1 t=1 Andreasen Expires December 7, 2007 [Page 4] Internet-Draft SDP Capability Negotiation June 2007 The resulting potential configuration SDP for the plain RTP alternative (the actual configuration, which by default is the least preferred alternative) would look like this, if we don't delete the actual configuration attributes: v=0 o=alice 2891092738 2891092738 IN IP4 lost.example.com s= t=0 0 c=IN IP4 lost.example.com m=audio 59000 RTP/AVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 Note that we have a "crypto" attribute with a plain RTP media stream. When processing this potential configuration, it would be best to delete the "crypto" attribute from the configuration. Otherwise, the media stream could get rejected. From RFC 4568, Section 5.1.2: When the answerer receives the initial offer with one or more crypto attributes for a given unicast media stream, the answerer MUST either accept exactly one of the offered crypto attributes, or the offered stream MUST be rejected. Section 5 in RFC 4568 is transport protocol agnostic, with Section 7 providing the SRTP specific behavior. Section 7.1.2 says: When the initial answer is generated, the answerer MUST follow the steps in Section 5.1.2, as well as the following steps. For each unicast media line that uses the secure RTP transport and contains one or more "a=crypto" lines in the offer, the answerer MUST either accept one (and only one) of the crypto lines for that media stream, or it MUST reject the media stream. and later on If the answerer cannot find any valid crypto line that it supports, or if its configured policy prohibits any cryptographic key parameter e.g., key length) or cryptographic session parameter (e.g., KDR, Andreasen Expires December 7, 2007 [Page 5] Internet-Draft SDP Capability Negotiation June 2007 FEC_ORDER), it MUST reject the media stream, unless it is able to successfully negotiate use of SRTP by other means outside the scope of this document (e.g., by use of MIKEY [mikey]). It is somewhat open to interpretation whether Section 7.1.2 implies that the crypto operation will only happen if we actually have an SRTP stream in the "m=" line. However, if we want to be on the safe side, we should not provide any crypto attribute with a vanilla RTP stream, and that is part of the reason for having the "delete" semantics in the SDP Capability Negotiation. 3.1.2. Unclear interactions between two different attributes (for example two different attribute names). An example of this is the "keymgt" and "crypto" attributes used for SRTP keying. Assume the actual configuration offers an SRTP media stream using the "crypto" attribute as the keying mechanism, whereas an alternative potential configuration suggests use of MIKEY or DTLS- SRTP. The actual configuration SDP could look like this: v=0 o=alice 2891092738 2891092738 IN IP4 lost.example.com s= t=0 0 c=IN IP4 lost.example.com m=audio 59000 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=tcap:1 RTP/SAVP UDP/TLS/RTP/AVP a=acap:1 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=acap:2 a=setup:actpass a=acap:3 a=connection:new a=acap:4 a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:... a=pcfg:1 t=1 a=1 a=pcfg:2 t=2 a=2,3,4 The resulting potential configuration SDP for SRTP using MIKEY would look like this: v=0 o=alice 2891092738 2891092738 IN IP4 lost.example.com s= Andreasen Expires December 7, 2007 [Page 6] Internet-Draft SDP Capability Negotiation June 2007 t=0 0 c=IN IP4 lost.example.com m=audio 59000 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... There are two issues with this potential configuration SDP. First of all, it contains both a crypto and a key-mgmt attribute, however only one of these should be used for negotiating SRTP security parameters. Fortunately, RFC 4568 (Section 7.5) specifically addresses this interaction issue by mandating that only of them is actually processed, however it nevertheless illustrates the interaction issue. The resulting potential configuration SDP for DTLS-SRTP would look like this: v=0 o=alice 2891092738 2891092738 IN IP4 lost.example.com s= t=0 0 c=IN IP4 lost.example.com m=audio 59000 UDP/TLS/RTP/AVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=setup:actpass a=connection:new a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:... This potential configuration SDP suffers from the same issue as the plain RTP one in the previous scenario; presence of the crypto attribute with a transport protocol for which it is not to be used. 3.2. Replace Attributes Attribute replacement is similar deleting an attribute and then adding another one, however the issues behind this feature differ from that of simple deletion. The basic problems motivating this feature are: 1) An attribute value may conflict with another attribute value. Examples of this include "rtpmap" and "fmtp" parameters. If the SDP contains an "rtpmap:96 PCMU" and the potential configuration adds Andreasen Expires December 7, 2007 [Page 7] Internet-Draft SDP Capability Negotiation June 2007 "rtpmap:96 G729", then which mapping is actually the right one to use ? To avoid this ambiguity, RFC 4566 states that Up to one rtpmap attribute can be defined for each media format specified. The issue is similar for the "fmtp" parameter. A possible alternative solution to replacing attributes would be to define an order in which attributes are added to the potential configuration SDP, and then define conflict resolution for well - known attribute types (such as fmtp and rtpmap), however the concern with doing so is that it is not a general solution. We cannot specify rules for attributes that are yet to be defined, and we miss some attribute types. 4. Conclusion We have presented the rationale behind - deleting attributes in an actual configuration SDP - replacing attributes in an actual configuration SDP In terms of deleting attributes, we made an important assumption about implementations generally ignoring SDP attributes that do not seem to otherwise apply for a particular SDP. This left us with the problem of dealing only with attributes that may result in unintended processing when the SDP changes or attributes that have unclear interactions. We have looked at a variety of different SDP attributes for this class of problems, however our primary use cases seem to center around SRTP key management. This suggests that the problem is somewhat limited in scope when it comes to current SDP parameters. In terms of replacing attributes, there are clear use cases for this, notably in the areas of the "fmtp" and "rtpmap" attributes. Both of these are outside the scope of the core SDP capability negotiation document, however they are within scope of the media capabilities negotiation work. While there is little doubt (in the author's mind at least) that there is an important general problem here, it could be argued that it would be sufficient to provide a solution in the core document that does not define how individual attributes are deleted from the actual configuration. If that path is followed, it is the author's Andreasen Expires December 7, 2007 [Page 8] Internet-Draft SDP Capability Negotiation June 2007 opinion that we should still provide the ability to delete all attributes from the existing SDP (at the media and/or session-level) thereby providing a simple (albeit somewhat inefficient in terms of message size) solution to the general problem, that all implementations are guaranteed to support. 5. Security Considerations None. 6. IANA Considerations None. Andreasen Expires December 7, 2007 [Page 9] Internet-Draft SDP Capability Negotiation June 2007 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002. [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 7.2. Informative References [RFC2046] Freed, N., and N. Borensteain, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. Andreasen Expires December 7, 2007 [Page 10] Internet-Draft SDP Capability Negotiation June 2007 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework, RFC 4091, June 2005. [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", Work in Progress, August 2004. [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session Initiation Protocol (SIP) Offer/Answer with Multipart Alternative", Work in Progress, March 2006. [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Work in Progress, December 2005. [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", RFC 4568, July 2006. [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description and Capability Negotiation", Work in Progress, February 2005. [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol (SDP) Offer/Answer Negotiation for Best-Effort Secure Real- Time Transport Protocol, Work in progress, August 2006. [KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. Andreasen Expires December 7, 2007 [Page 11] Internet-Draft SDP Capability Negotiation June 2007 [SDPCapNegRqts] Andreasen, F. "SDP Capability Negotiation: Requirementes and Review of Existing Work", work in progress, December 2006. [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in progress, March 2007. [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", work in progress, January 2007. [ICETCP] J. Rosenberg, "TCP Candidates with Interactive Connectivity Establishment (ICE)", work in progress, October 2006. [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration of Resource Management and Session Initiatio Protocol (SIP)", RFC 3312, October 2002. [SMIME] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC4474] J. Peterson, and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [sprecon] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol Media Streams", Work in Progress, October 2006. Author's Addresses Flemming Andreasen Cisco Systems Edison, NJ Email: fandreas@cisco.com Andreasen Expires December 7, 2007 [Page 12] Internet-Draft SDP Capability Negotiation June 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Andreasen Expires December 7, 2007 [Page 13]