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]