Internet Engineering Task Force  SIPPING
INTERNET-DRAFT  H. Schulzrinne
draft-ietf-sipping-rp-mechanisms-00.ps  Columbia U.

December 6, 2002 Expires: May 2003

Mechanisms for Resource Priority Mechanisms for the Session Initiation Protocol

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (c) The Internet Society (2002). All Rights Reserved.

Abstract This document summarizes how the Session Initiation Protocol (SIP) and possible extensions can meet the requirements enumerated in “Requirements for Resource Priority Mechanisms for the Session Initiation Protocol”.

1 Introduction

This document summarizes how the Session Initiation Protocol (SIP) and possible extensions can meet the requirements enumerated in “Requirements for Resource Priority Mechanisms for the Session Initiation Protocol” [1].

2 Addressing the IEPREP Requirements

For each requirement, we indicate what existing mechanism can be used or what candidate extensions might be suitable. In general, none of the currently standardized or proposed SIP features indicate whether a request makes special claims to SIP-mediated resources or not. (The Priority header indicates the urgency to the human recipient of the request and is orthogonal to this issue.)

In general, SIP offers four mechanisms to convey protocol semantics: URIs scheme (US) or parameter (UP), header fields (H), request methods (M), caller preferences (C) and body content (B).

Thus, there are three choices:

Deduce: Information in U, H, M, C or B is used to deduce the resource priority demand.

New: A new H, M, C or B is added.

INTERNET-DRAFT  draft-ietf-sipping-rp-mechanisms-00.ps  December 6, 2002

Out-of-band: Some other protocol indicates the choice.

Where applicable, we indicate which of these three approaches and which element might be suitable.

REQ-1: Not specific to one scheme or country: This requirement implies that any SIP indication is flexible enough to accomodate a variety of namespaces. There currently is no indication, so current SIP cannot satisfy the requirement.

REQ-2: Independent of particular network architecture: This requirement rules out use of a new URI type (U), since all SIP-addressable resources need to be included. It also makes an out-of-band protocol difficult, as that typically pre-supposes support from network elements such as firewalls.

REQ-3: Invisible to network (IP) layer: This requirement makes use of out-of-band mechanisms difficult. Out-of-band mechanisms also would have to be directed to the all the same locations that the SIP request travels, adding difficulty.

REQ-4: Mapping of existing schemes: This requirement has similar implications as REQ-1. It calls for the ability to accomodate multi-valued enumerations of priority levels.

REQ-5: No loss of information: This requirement stipulates that there cannot be a many-to-one mapping, e.g., from some scheme to a set of integers, since information about the original scheme would be lost.

REQ-6: Extensibility: This requirement indicates the need for an IANA registry to add additional items later.

REQ-7: Separation of policy and mechanism: The mechanism must be labels, not prescriptions for detailed call handling.

REQ-8: Method-neutral: This rules out adding a new method that calls for prioritized handling.

REQ-9: Default behavior: This requirement only indicates that the specification of any such scheme needs to address default behavior in elements that expect to receive such an indication.

REQ-10: Address-neutral: This requirement rules out the use of special URIs or a new URI type. It may, however, be satisfied with a new URI parameter on all URI schemes that may be carried in SIP. This requirement is satisfied by H, M, B, and C.

REQ-11: Identity-independent: This rules out the use of a special From value.

REQ-12: Independent of network location: This requirement rules out the use of the Contact header or Via information.

REQ-13: Multiple simultaneous schemes: This requirement mandates that the indication allow a list of names.

REQ-14: Discovery: This requirement argues for the use of standard SIP negotiation mechanisms to determine the capabilities of the other side, such as Require, Proxy-Require or OPTIONS.

REQ-15: Testing: It does not appear that this adds additional protocol requirements.

REQ-16: 3PCC: All mechanisms indicated appear to satisfy this requirement.

REQ-17: Proxy-visible: This requirement rules out the use of message bodies, since these are not meant to be inspected or modified by proxies.

Given, inter alia, REQ-8, REQ-10, REQ-11, there does not appear to be an existing indication from which a recipient can reliably deduce resource priority. In addition, mechanisms B, M, and US fail one or more requirements, leaving mechanisms H, C and UP.

UP requires that all SIP schemes be fitted with this parameter and thus may make satisfying REQ-10 difficult.

Caller preferences describe desired capabilities and properties of the end system and are used to select among a set of candidate locations. This does not match the semantics desired here.

Thus, we will focus our attention below on the H and UP mechanisms.

The information that needs to be conveyed according to REQ-1, REQ-4, REQ-5, REQ-10, REQ-11, and REQ-12 appears to be more suitable for a request header. It logically does not describe the destination or source, but rather a property of the request. URI parameters are meant to describe properties of the

Also, there is currently no mechanism in place to negotiate support for URI parameters.

3 Security Requirements

SEC-1: More rigorous: SIP-related mechanisms, such as Digest authentication and hop-by-hop authentication, offer suitably strong authentication mechanisms.

However, Digest authentication can currently only provide integrity of the method, request URI and body, not header fields. Thus, an adversary could remove the indication header without detection. However, that is not likely to be more disruptive than simply removing the whole request or modifying the destination address.

Modification of the indication is not likely to be useful to an adversary unless some form of trust domain [3] is used where one element authenticates the request at a lower priority, the adversary modifies it to a higher one and then abuses those privileges in later SIP elements that trust the first element. Otherwise, increasing the priority will only incur additional authentication requirements and likely cause the request to fail.

The discussion in [4] investigates how signed SIP message bodies may be used to address this issue.

SEC-2: Attack protection: This is a generic SIP requirement. Denial of service issues are discussed at length in [2]. The reader is referred to that document for further details.

SEC-3: Independent of mechanism: The candidate mechanisms work with all existing SIP security techniques.

SEC-4: Non-trusted end systems: This requirement suggests the use of one-time passwords in SIP. This may be implementable on top of the existing Digest mechanism, but no such specification exists.

SEC-5: Replay: The approved SIP authentication mechanisms address this concern.

SEC-6: Cut-and-paste: The approved SIP authentication mechanisms address this concern.

SEC-7: Bid-down: This concern is addressed by [stalled Digest draft].

SEC-8: Confidentiality: If H or UP are used, body encryption is not effective, so that channel security is called for. Currently, SIP offers the use of IPsec and TLS.

SEC-9: Anonymity: The network-asserted identity and general privacy mechanisms [5, 6] are applicable.

SEC-10: Denial-of-service: See SEC-2.

SEC-11: Minimize resource use by unauthorized users: See SEC-2.

SEC-12: Avoid amplification: See SEC-2.

4 Security Considerations

Section 3 discusses the security issues related to priority indication for SIP in detail and derives requirements for the SIP indicator.

5 Conclusion

From the general requirements, we conclude that only mechanism H and possibly UP are suitable candidates that satisfy all requirements. No new security-related protocol features are needed, with the possible exception of the use of one-time passwords.

6 Acknowledgements

Your name here.

Normative References

[1] H. Schulzrinne, “Requirements for resource priority mechanisms for the session initiation protocol,” Internet Draft, Internet Engineering Task Force, Dec. 2002. Work in progress.

[2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: session initiation protocol,” RFC 3261, Internet Engineering Task Force, June 2002.

Informative References

[3] M. Watson, “Short term requirements for network asserted identity,” RFC 3324, Internet Engineering Task Force, Nov. 2002.

[4] R. Mahy, “Discussion of suitability: S/MIME instead of digest authentication in the session initiation protocol (SIP),” Internet Draft, Internet Engineering Task Force, Oct. 2002. Work in progress.

[5] J. Peterson, “A privacy mechanism for the session initiation protocol (SIP),” RFC 3323, Internet Engineering Task Force, Nov. 2002.

[6] C. Jennings, J. Peterson, and M. Watson, “Private extensions to the session initiation protocol (SIP) for asserted identity within trusted networks,” RFC 3325, Internet Engineering Task Force, Nov. 2002.

7 Authors’ Address

Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu

Full Copyright Statement

Copyright (c) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an ”AS IS” basis and THE IN-TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-RANTIES, 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.