MARTINI WG A. B. Roach Internet-Draft Tekelec Intended status: Standards Track January 6, 2010 Expires: July 10, 2010 A Unified Proposal for Multiple AOR Registrations in the Session Initiation Protocol (SIP) draft-roach-martini-up-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 10, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document contains a unified proposal for solving the problems related to providing dynamic SIP routing information for multiple Roach Expires July 10, 2010 [Page 1] Internet-Draft SIP HTTP Subscriptions January 2010 AORs with a single SIP transaction. The proposed solution is designed to work both for subsets of URIs within a domain, and for entire domains. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Publisher Behavior . . . . . . . . . . . . . . . . . . . . 4 4.2. Dynamic Routing Server Behavior . . . . . . . . . . . . . 5 5. Alternate Body Type for 'reg' Event Package . . . . . . . . . 5 6. Body Type for Indication of Allowed URIs . . . . . . . . . . . 8 7. Comparison of Simple Regular Expressions . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Range of E.164 numbers . . . . . . . . . . . . . . . . . . 10 8.2. Entire Domain . . . . . . . . . . . . . . . . . . . . . . 10 8.3. Many Discrete AORs . . . . . . . . . . . . . . . . . . . . 11 9. Issues Solved . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Roach Expires July 10, 2010 [Page 2] Internet-Draft SIP HTTP Subscriptions January 2010 1. Introduction One of SIP's primary functions is providing rendezvous between users. By design, this rendezvous has been provided through a combination of the server look-up procedures defined in RFC 3263 [2], and the registrar procedures described in RFC 3261 [1]. The intention of the original protocol design was that any user's AOR would be handled by the authority indicated by the hostport portion of the AOR. The users registered individual reachability information with the this authority, which would then route incoming requests accordingly. In actual deployments, some SIP servers have been deployed in architectures that, for various reasons, have requirements to provide dynamic routing information for large blocks of AORs, where all of the AORs in the block were to be handled by the same server. For purposes of efficiency, many of these deployments do not wish to maintain separate registrations for each of the AORs in the block. This leads to the desire for an alternate mechanism for providing dynamic routing information for blocks of AORs. Because this problem has certain similarities with the REGISTER operation, several non-standard, ad hoc extensions to REGISTER have been developed to address this desire. The document "SIP IP-PBX Registration Problems" [8] describes several deployed IP PBX registration techniques, along with a number of problems that arise from the approaches that have been implemented to date. It should be noted that the similarities between bulk AOR dynamic routability and the REGISTER operation are somewhat superficial. In particular, with a REGISTER request, a UAC is establishing a binding for a single user. Intermediaries (between the UAC and the registrar) can make decisions about how to treat the request based on the identity of that user. Extending the REGISTER method to operate outside of this model -- as has been done by the ad hoc solutions mentioned earlier -- can cause issues at such intermediaries that assume the standard SIP registration model. 2. Terminology This document uses the terms defined in section 2 of "SIP IP-PBX Registration Problems" [8]. Roach Expires July 10, 2010 [Page 3] Internet-Draft SIP HTTP Subscriptions January 2010 3. Mechanism Overview The mechanism defined in this document takes advantage of the observation that there are already two defined means for accessing the Location Service Database defined by RFC 3261: the REGISTER mechanism (also defined by RFC 3261) as well as the SIP Registrations Event Package, defined in RFC 3680 [4]. Of these two mechanisms, REGISTER is designed to operate on a single AOR at a time. By contrast, the SIP Registrations Event Package was fundamentally designed to carry registration information for potentially several AORs simultaneously. This makes it a near perfect match for the problem of maintaining dynamic routing information for multiple AORs. Consumers of state information for event packages make use of the SUBSCRIBE and NOTIFY methods, defined in RFC 3265 [3], to receive updates whenever the state changes. Similarly, producers of state information for event packages can use the PUBLISH method, defined in RFC 3903 [5], to inform the network when state has been updated. Based on the foregoing, we define a procedure whereby the node responsible for registering dynamic routing information for several AORs uses a PUBLISH request with the 'reg' event package. This PUBLISH request indicates the AORs the dynamic routing information applies to, as well as the routing URI associated with each AOR. While the XML body defined in RFC 3680 is semantically suitable for this use, it is somewhat cumbersome in practice to use for, e.g., large contiguous blocks of numbers. For example, if a PBX were responsible for a block of 10,000 E.164-addressed endpoints, it would require a application/reginfo+xml document containing 10,000 individual elements. To address this issue, we propose an alternate body type for the 'reg' event package, which allows for concise expression of this kind of AOR aggregation. This alternate body type is described in Section 5. 4. Protocol In general, the behavior for the elements involved in maintaining dynamic routing information is that defined for maintaining event state with the PUBLISH request, as described in RFC 3903. Behavior specific to this specification is described below. 4.1. Publisher Behavior This section describes behavior for the UAC responsible for maintaining dynamic routing information. Note that this may or may not be the element that the AORs will be associated with (such as an Roach Expires July 10, 2010 [Page 4] Internet-Draft SIP HTTP Subscriptions January 2010 IP PBX or a PSTN gateway) -- it might be an arbitrary third party responsible for advertising dynamic routes associated with groups of AORs. To advertise a dynamic route associated with an AOR, the publisher sends a PUBLISH request to the dynamic routing server. This PUBLISH contains a body that conveys the AORs for which dynamic routing information is being conveyed. This body may use either the application/reginfo+xml format defined by RFC 3680, or using the compact format defined in Section 5. A successful (200-class) response to the PUBLISH indicates to the publisher that the AOR dynamic routes have been successfully updated. Any failure response indicates that none of the routes have been accepted. If the failure response code is "403," then the body of the response will contain a document indicating the AORs that the publisher is authorized to provide dynamic routing information for. This document is in the format described in Section 6. 4.2. Dynamic Routing Server Behavior When a Dynamic Routing Server (such as a proxy/registrar found within an SSP) receives a PUBLISH request for for the 'reg' event package, it first authenticates the sending entity. This authentication may be via Digest authentication, mutual TLS authentication, or some other mechanism. After the sender is authenticated, the Dynamic Routing Server validates the body of the PUBLISH request, by making certain that the entries present are syntactically valid, complete, and within any applicable policies. It then updates its local routing tables with the information present in the body. The Dynamic Routing Server applies the rules defined in Section 7 to determine whether the requested AORs are within the set of AORs that the publisher is authorized to provide routing information for. Semantically, updating the local routing tables is identical to updating a Location Service database (as RFC 3261 defines that term). After updating its local routing tables with the information present in the PUBLISH message, it responds to the PUBLISH request with a 200 (OK) response. 5. Alternate Body Type for 'reg' Event Package To allow for compact specification of several AORs in a single "reg" event package body, we define a new MIME body type. This MIME type is designated "application/reginfo-bulk." Except as noted, the Roach Expires July 10, 2010 [Page 5] Internet-Draft SIP HTTP Subscriptions January 2010 meaning of the fields in this MIME body are identical to the fields defined in RFC 3680. If omitted, the "state" field is assumed to have the value of "active," and the "expires" field is assumed to be identical to the "Expires" header value in the PUBLISH message header. This body is specified using the ABNF format defined in RFC 5234 [6]. reginfo-bulk-body = version HTAB doc-state CR *reginfo-bulk-entry reginfo-bulk-entry = delim-char simple-regex delim-char contact delim-char HTAB id HTAB event [ HTAB state [ HTAB expires [ HTAB [ qvalue ] [ HTAB [ retry-after ] [ HTAB [ callid ] [ HTAB [ cseq ] [ HTAB [ duration-reg] [ HTAB [ unknown-params ] [ HTAB display-name ] ] ] ] ] ] ] ] ] CR version = 1 * DIGIT doc-state = "full" / "partial" delim-char = "/" / "!" / ... utf8-display-str = * ( %x20-7F / ( %xC2-DF %x80-BF ) / ( %xE0-EF 2 ( %x80-BF ) ) / ( %xF0-F4 3 ( %x80-BF ) ) ) simple-regex = 1 * ( OCTET ) contact = 1 * ( OCTET / backref ) backref = "\" %x31-39 id = display-char event = "registered" / "created" / "refreshed" / "shortened" / "expired" / "deactivated" / "probation" / "unregistered" / "rejected" state = "init" / "active" / "terminated" expires = 1 * DIGIT qvalue = "1.0" / ( "0." 1*4 DIGIT) retry-after = 1 * DIGIT callid = 1 * VCHAR cseq = 1 * DIGIT duration-reg = 1 * DIGIT unknown-params = 1 * VCHAR display-name = utf8-display-str The "simple-regex" field is used to indicate one or more AORs to which the entry applies, and the "contact" field indicates the Roach Expires July 10, 2010 [Page 6] Internet-Draft SIP HTTP Subscriptions January 2010 routing information to be associated with the AORs that are matched by the entry. The "simple-regex" is similar in spirit to POSIX regular expressions (as defined in IEEE 1003-2 [7]). However, to allow for trivial comparison between requested AORs and allowed AORs, the syntax is intentionally very limited. Characters in the simple-regex have the following properties: o The regex characters "(" and ")" are used to indicate sections of the matched string that can be used for backrefs. They are ignored for the purposes of matching. o The regex character "\" is used to escape the immediately following character. Instead of taking its normal meaning, the character simply matches itself. This includes the ability to escape the delim-char. o The regex sequence "[" followed by one or more characters and "]" matches any of the characters between the "[" and "]" symbols. o The regex character "." matches any character. o The regex sequence "{" followed by one or more digits and "}" indicates that the preceding character must be repeated exactly the number of times indicated by the digit. o As a special case, if a simple regex contains an "@" character, then the portion of the regex preceding the first "@" character may use the character "*" to mean "zero or more instances of the preceding character." However, Dynamic Routing Servers MUST NOT accept regular expressions of this format unless their policy allows the authenticated publisher to control the routing of all requests for the domain on the right-hand-side of the "@" character. An unescaped "*" character after the first "@" character in the simple regex is a syntax error. o As with normal regular expressions, any other character matches itself. The simple regexes defined in this document must match a string in its entirety -- that is, the matching string may not contain any leading or trailing characters. For example, the simple regex "x...y" would not match the string "axabcy," since the leading "a" is not represented in the simple regex. The preceding rules are carefully crafted to allow trivial expansion of all simple regexes to a complete, exhaustive list of strings that the regex can possibly match. In particular, they intentionally omit Roach Expires July 10, 2010 [Page 7] Internet-Draft SIP HTTP Subscriptions January 2010 the ability to indicate an arbitrary number of characters, as with the POSIX regex "*" character (except in the special case of domain registration). OPEN ISSUE: we can achieve the same property even if we include ranges of characters -- e.g., ".{2,4}" -- with a moderate increase in the complexity of the operation. Do we want to do this? The "contact" field contains a URI that the Location Service should associate with the AOR. The "contact" field in this document format may contain backref expressions of the form "\1" through "\9". If present, these are replaced by the string of characters enclosed by "(" and ")" in the simple regex portion of the reginfo-bulk-entry. The string "\1" matches the first backref expression in the simple regex (i.e., the one starting with the first parenthesis); the string "\2" matches the second; and so on. For example, the simple regex: (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression 6. Body Type for Indication of Allowed URIs This needs more fleshing out. Basically, the format is a list of simple-regexes that indicate which AORs the authenticated publisher is authorized to provide routing information for. reginfo-err-body = 1 * ( simple-regex CR ) 7. Comparison of Simple Regular Expressions In order to make policy decisions, a Dynamic Routing Server must be able to trivially examine the simple regexes provided in a application/reginfo-bulk body and determine whether they are a proper subset of the AORs the publisher is authorized to publish. To determine whether a first simple regex (e.g., from a publisher) is a subset of second simple regex (e.g., a policy rule at a Dynamic Routing Server), a server performs the following processing: Roach Expires July 10, 2010 [Page 8] Internet-Draft SIP HTTP Subscriptions January 2010 1. All unescaped instances of "(" and ")" are discarded from both expressions. 2. All unescaped sequences of "{" followed by one or more digits followed by "}" are expanded by repeating the preceding character the number of times indicated by the digits (treating any sequence of "[" .. "]" as a single character). 3. The two expressions are then compared character-by-character (again treating any sequence of "[" .. "]" as a single character), checking that each character in the first expression is a subset of the corresponding character in the second expression, using the following rules for determining subsets: * An unescaped "." character is a subset only of an unescaped character ".". * A bracketed sequence is a subset of another bracketed sequence containing the same list of characters (and potentially others), or an unescaped character ".". * Any other character is a subset of itself, a bracketed sequence containing itself, or an unescaped character ".". 4. As a special case: if the first expression contains an unescaped "*" character preceding the first "@" character in the expression, then it is can only be a subset of a second expression beginning with the character sequence ".*@". If the second expression begins with ".*@", then the first expression is a subset of the second expression if and only if the portion of the first expression following the first "@" character is a subset of the portion of the second expression following its first "@" character (as determined by the foregoing rules). The Dynamic Routing Server communicates policy regarding allowed AORs using the format defined in Section 6. The matching steps defined above are performed pairwise on each of the requested AORs (from the publisher) and the allowed AORs (from the Dynamic Routing Server policy). If each of the requested AORs are subsets of at least one of the allowed AORs, then the request is within policy. Otherwise, the request exceeds the authorization granted to the publisher, and the Dynamic Routing Server MUST reject the PUBLISH with a 403 response. Roach Expires July 10, 2010 [Page 9] Internet-Draft SIP HTTP Subscriptions January 2010 8. Examples Note that, for the sake of readability, these examples use sequences of spaces instead of VTAB characters to delimit fields. 8.1. Range of E.164 numbers The following request registers the sequence of E.164 numbers from +12143290000@example.com through +12143290999@example.com. It associates the AOR "sip:+12143290000@example.com" with the Contact "sip:0000@pbx.example.net," the AOR "sip:+12143290001@example.com" with the Contact "sip:0001@pbx.example.net," and so on. PUBLISH sip:company@routing-server.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:pbx.example.com;tag=xyzygg To: sip:company@routing-server.example.com Call-ID: 9987@app.example.com CSeq: 1288 PUBLISH Max-Forwards: 70 Expires: 3600 Event: reg Content-Type: application/reginfo-bulk Content-Length: ... 1 full /sip:+1214329(0...)@example.com/sip:\1@pbx.example.net/ 14 registered 8.2. Entire Domain The following request associates all URIs in the domain "example.net" with the IP address "192.0.2.5". PUBLISH sip:company@routing-server.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:pbx.example.com;tag=xyzygg To: sip:routing-server.example.com Call-ID: 9987@app.example.com CSeq: 1288 PUBLISH Max-Forwards: 70 Expires: 3600 Event: reg Content-Type: application/reginfo-bulk Content-Length: ... 1 full /sip:(.*)@example.net/sip:\1@192.0.2.5/ 14 registered Roach Expires July 10, 2010 [Page 10] Internet-Draft SIP HTTP Subscriptions January 2010 8.3. Many Discrete AORs The following request associates several named URIs with the a set of named URIs. PUBLISH sip:company@routing-server.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:pbx.example.com;tag=xyzygg To: sip:company@routing-server.example.com Call-ID: 9987@app.example.com CSeq: 1288 PUBLISH Max-Forwards: 70 Expires: 3600 Event: reg Content-Type: application/reginfo-bulk Content-Length: ... 1 full /sip:fsmith@example.net/sip:fsmith@192.0.2.5/ 1 registered /sip:zjohnson@example.net/sip:zjohnson@192.0.2.5/ 2 registered /sip:lwilliams@example.net/sip:lwilliams@192.0.2.5/ 3 registered /sip:fjones@example.net/sip:fjones@192.0.2.5/ 4 registered /sip:tbrown@example.net/sip:tbrown@192.0.2.5/ 5 registered /sip:qdavis@example.net/sip:qdavis@192.0.2.5/ 6 registered /sip:imiller@example.net/sip:imiller@192.0.2.5/ 7 registered /sip:vwilson@example.net/sip:vwilson@192.0.2.5/ 8 registered /sip:gmoore@example.net/sip:gmoore@192.0.2.5/ 9 registered /sip:ataylor@example.net/sip:ataylor@192.0.2.5/ 10 registered /sip:randerson@example.net/sip:randerson@192.0.2.5/ 11 registered /sip:bthomas@example.net/sip:bthomas@192.0.2.5/ 12 registered /sip:qjackson@example.net/sip:qjackson@192.0.2.5/ 13 registered /sip:pwhite@example.net/sip:pwhite@192.0.2.5/ 14 registered /sip:wharris@example.net/sip:wharris@192.0.2.5/ 15 registered /sip:wmartin@example.net/sip:wmartin@192.0.2.5/ 16 registered 9. Issues Solved The document "SIP IP-PBX Registration Problems" [8] describes a number of problems that arise in the ad hoc solutions currently deployed. This section evaluates these issues against the mechanism proposed in this document. No Explicit Indicator: The mechanism in this document cannot be confused with the normal registration mechanism defined in RFC 3261, as it does not attempt to overload REGISTER to convey bulk dynamic routing information. Roach Expires July 10, 2010 [Page 11] Internet-Draft SIP HTTP Subscriptions January 2010 Undefined Behavior on PAU Mismatch: By shifting the task of specifying the AORs being registered from the server to the client, there is no opportunity for mismatch. Policy errors may arise when the client attempts to register for AORs other than those it is authorized to register; however, procedures for detecting and addressing these conditions are provided. REGISTER Response Growth: By shifting the task of specifying the AORs being registered from the server to the client, normal response size is maintained. Circumstances under which a UDP response is required, but size precludes sending a response, are precluded. Illegal Wildcarding Syntax: By defining a wildcarding syntax outside the strictures of SIP, the issue of valid SIP syntax is sidestepped. Loss of Target Info: Because the binding from AOR to Contact URI is under complete control of the requestor, and because the model of proxy/registrar routing defined in RFC 3261 is maintained, the system exhibits the same properties as it would if each user were registered individually. Target information is preserved. Request-URI vs. Loose-Route Mismatches: As before: because the binding from AOR to Contact URI is under complete control of the requestor, and because the model of proxy/registrar routing defined in RFC 3261 is maintained, the system exhibits the same properties as it would if each user were registered individually. Loose routing and Request-URI handling are kept consistent with proxy/registrar handling described in RFC 3261, so no mismatches can arise. Authorization Policy Mismatches: Because the binding from AOR to Contact URI is under control of the publisher, it can ensure that the Contact URI associated with an AOR matches the Contact URIs it uses for outgoing calls. This eliminates the authorization policy mismatches described. P-Asserted-Identity Mismatches: Because the information published by this mechanism inherently mimics individual registration for each of the associated AORs, the expectation that each of these AORs can be used as a P-Asserted-Identity is preserved, avoiding any implementation confusion regarding valid values for this field. Roach Expires July 10, 2010 [Page 12] Internet-Draft SIP HTTP Subscriptions January 2010 Trust Domain Mismatches for Privacy/Identity: The MARTINI working group appears to be reaching rough consensus that this issue is out of scope and out of charter for solutions it is responsible for considering. It is not analyzed with respect to the proposed solution. 10. References 10.1. Normative References [1] 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. [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [5] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [7] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2, 1992. 10.2. Informative References [8] Kaplan, H., "SIP IP-PBX Registration Problems", draft-kaplan-martini-mixing-problems-00 (work in progress), December 2009. Roach Expires July 10, 2010 [Page 13] Internet-Draft SIP HTTP Subscriptions January 2010 Author's Address Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US Email: adam@nostrum.com Roach Expires July 10, 2010 [Page 14]