Network Working Group R. Sparks Internet-Draft Tekelec Intended status: Informational Jul 2, 2008 Expires: January 3, 2009 Moving the Session Initiation Protocol (SIP) Towards Draft Standard draft-sparks-sip-steps-to-draft-00 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 January 3, 2009. Abstract This document is intended to stimulate discussion and progress towards advancing SIP to Draft Standard. It points to some of the issues the working group will need to work through and proposes an approach for creating an interoperability statement. Sparks Expires January 3, 2009 [Page 1] Internet-Draft SIP to DS Jul 2008 Table of Contents 1. What will be required to take SIP to Draft Standard . . . . . 3 1.1. Deciding on the size of the package to try to progress . . 3 1.2. Understanding and adjusting to the dependencies . . . . . 4 1.3. Choosing to advance rather than revise . . . . . . . . . . 4 1.4. Prepare one or more implementation reports . . . . . . . . 5 2. Survey of RFC3261 Normative References . . . . . . . . . . . . 5 3. A strawman implementation report format for RFC3261 . . . . . 7 4. Strawman discussion points . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Informative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Sparks Expires January 3, 2009 [Page 2] Internet-Draft SIP to DS Jul 2008 1. What will be required to take SIP to Draft Standard [RFC2026] defines IETF standards maturity levels and what's required to progress between them. In short, to progress a standard from Proposed (where [RFC3261] is now) to Draft, we will need to show that it is reasonably stable, implemented, and interoperable. At the highest level, the activities required to advance SIP to Draft Standard will involve: o Creating one or more RFCs reflecting the subset of the standard that actually is stable, implemented, and provably interoperable. o Preparing an implementation report evidencing that implementation and interoperability o Establishing that the protocols SIP builds on are also of at least Draft quality. Each of these activities involve a number of decisions and issues to discuss in addition to a significant writing and testing effort. A competing, necessary, and conflicting activity is adding to and refining the specifications. Changes other than removing what we know is not working and interoperating adds additional effort before we can progress those changes to Draft. 1.1. Deciding on the size of the package to try to progress The level of effort required to take some part of the body of SIP documents to Draft Standard depends significantly on how much of that body we take on at a time. We have a wide range of options: o Trying to progress everything we can build an interoperability report against o Trying to progress everything we think is "core" (as indicated in the hitch-hiker's guide [I-D.ietf-sip-hitchhikers-guide]) o Trying to progress everything we can agree is "core" to the "core" (3261 plus extensions like [RFC3262]) -> Trying to progress 3261 and dependencies including widely implemented small updates (such as rport [RFC3581] and the non- INVITE fixes [RFC4320]) Sparks Expires January 3, 2009 [Page 3] Internet-Draft SIP to DS Jul 2008 o Trying to progress the absolute minimum of things required to take as much of 3261 itself to Draft as possible. The optimal choice probably lies somewhere near the option labeled with the "->" in the above list. It is a portion of work that we can reasonably complete and the result would actually be useful to the overall community. 1.2. Understanding and adjusting to the dependencies RFC 2026 states: Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. In other words, any normative references from a Draft Standard will need to be to other Draft or full Standard documents, or come with a strong explanation of why a "downref" or an external reference is acceptable [RFC3967]. RFC 3261 normatively depends on SDP (literally [RFC2327], but we'll be working against [RFC4566]). This is likely to be one of the harder dependencies to resolve. We will either have to progress SDP as a prerequisite, find a way to construct the documents to avoid a normative reference to SDP, or discover some sort of compromise between those extremes. RFC 3261 also normatively depends on TLS (again the literal reference, [RFC2246], no longer makes sense - we'll be working against [RFC4346]). There is precedent for a downref in cases where the parts of the referenced documents that are used by the standard are believed to be of adequate quality. In this case, we can make the argument that the parts of TLS that are used by this specification are well enough specified and of adequate quality to qualify for draft standard. Furthermore, we anticipate being able to demonstrate interoperability of SIP's use of TLS with entirely discrete implementations (including the implementation of TLS). Section 2 surveys the normative references in RFC3261. 1.3. Choosing to advance rather than revise To succeed in advancing SIP to draft, we will have to be very careful to concentrate on identifying and documenting what is, and isn't, currently implemented and interoperable. There will be very strong pressure to "fix" or improve the protocol along the way. There may Sparks Expires January 3, 2009 [Page 4] Internet-Draft SIP to DS Jul 2008 be similar strong pressure to rewrite, reorganize, and otherwise clarify the existing requirements without changing them. If we decide that giving in to those pressures is the right thing to do, we have evidence that what we really need to be doing is revising with a goal of recycling at Proposed. We can optimize for progressing to Draft at the next cycle, but we need to recognize doing so is a different activity than attempting to progress to draft now. If we choose to push to Draft at this point, the changes to the specification will be primarily to remove things, not fix or clarify them. (Some fixes and clarifications, specifically those that are already provably reflected in implementation will, of course, make sense - but we will need to be wary of being at the top of a long and very slippery slope). 1.4. Prepare one or more implementation reports RFC 2026 requires a report on the implementation and interoperability of the features in a standard before advancing it to Draft. [I-D.dusseault-impl-reports] clarifies and refines that requirement. SIP has a very large number of normative statements in its specification (RFC 3261 alone has over one thousand [RFC2119] keyword-based requirements). Most of those statements interact. It is simply infeasible to produce a detailed checklist of every combination of every requirement along with a pair of implementations that have proven that configuration works. Rather, following the guidelines in [I-D.dusseault-impl-reports], what we can do is capture a set of higher level feature descriptions and agree that testing to those features will cover the full set of combinations of requirements. The interoperability report would capture pairs of implementations where that feature worked and call out any exceptions (requirements that were not met). A strawman example of what such a set of features for RFC3261 would look like appears in Section 3. A similar approach was taken for the interoperability report for RTP/ RTCP (see http://www.ietf.org/IESG/Implementations/ RTP-RTCP-Implementation.txt). Additional reports may be required for some of the normatively referenced documents. It might be possible to cover some of those (particularly [RFC3263]) simply by including them in this report. 2. Survey of RFC3261 Normative References RFC 3261 has 26 direct normative references in the categories detailed below. We will, as part of this exercise, also need to understand the indirect references (the normative references in the documents below that are not at Draft or above, and the normative references those references contain and so on), but this version of Sparks Expires January 3, 2009 [Page 5] Internet-Draft SIP to DS Jul 2008 this document does not attempt to enumerate that closure. o Items already at Draft or above - RFC 2396 : (as RFC 3986 aka STD 66) : Uniform Resource Identifier (URI): Generic Syntax - RFC 2279 : (as RFC 3629 aka STD 63) : UTF-8 - RFC 2616 : (at Draft) : HTTP - RFC 2234 : (as RFC 5234 aka STD 68) : ABNF - RFC 2046 : (at Draft) : MIME Part Two - RFC 768 : STD 6 : UDP - RFC 761 : (Did we mean to point at RFC793 : STD 7?): TCP - RFC 2617 : (at Draft) : Digest authentication - RFC 1123 : STD 3 : Requirements for Internet Hosts - Application and Support o Items at Proposed - RFC 2327 : SDP - RFC 2822 : Internet Message Format - this may be on its way to draft - see draft-resnick-2822upd-06.txt - RFC 3263 : Locating SIP Servers - RFC 3268 : Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) - RFC 2806 : (now RFC 3966) : tel URIs - RFC 3264 : Offer/Answer - RFC 2960 : (now RFC 4960) : SCTP - RFC 2183 : Content-Disposition - RFC 3204 : MIME for ISUP and QSIG - RFC 1847 : Security Multiparts for MIME - RFC 2630 : (now RFC 3370 and 3852) : Cryptographic Message Syntax - RFC 2633 : (now RFC 3851) : S/MIME Message Specification - RFC 2246 : (now RFC 4346) : TLS - RFC 2401 : (now RFC 4301) : IPSec Architecture o Items at BCP - RFC 2119: BCP 14: Key words for use in RFCs - RFC 1750: (now RFC 4086 aka BCP 106) : Randomness Recommendations for Security - RFC 2277: BCP 18 : IETF Policy on Character Sets and Languages Sparks Expires January 3, 2009 [Page 6] Internet-Draft SIP to DS Jul 2008 3. A strawman implementation report format for RFC3261 WARNING WARNING WARNING WARNING WARNING WARNING WARNW W W W The following list is an initial strawman. W W It has not received any review. W W W W DO NOT USE W W W W this list for any purpose other than W W discussing what should be in this list. W W It is incomplete, probably wrong and W W it WILL change. W W W W If you think you have a use for this W W list outside this draft, please participate W W in the upcoming discussion and use some W W future version of the list that results. W W Do not use this one. W W W WARNING WARNING WARNING WARNING WARNING WARNING WARNW - Basic mechanics - Interoperable completion of a non-INVITE transaction over an unreliable transport - Interoperable completion of an INVITE transaction over a reliable transport - Interoperable completion of an INVITE/200 through proxies with a mix of reliable and unreliable transport hops - Interoperable completion of a SIP transaction over - UDP - TCP - TLS - SCTP - Interoperable completion of SIP transactions over IPv6 - Interoperable completion of a SIP transaction using non-default transaction state machine timers - Demonstrate correct implementation of handling "stray" responses - Demonstrate correct implementation of CANCEL at an endpoint (UAS and UAC) - Interoperable completion of a SIP transaction with messages using non-ascii UTF8 - Demonstrate correct implementation of detection and recovery from INVITE glare - Demonstrate completion of a SIP transaction with messages using a mix of multiple comma-separated values after a header Sparks Expires January 3, 2009 [Page 7] Internet-Draft SIP to DS Jul 2008 name vs multiple instances of the header name - Demonstrate successful completion of a SIP transaction using the "received" and "rport" mechanisms - Demonstrate correct recognition and handling of merged requests at an endpoint - Demonstrate correct recognition and handling of transport errors occurring during a transaction - Demonstrate interoperable implementation of the entity type negotiation mechanisms (Accept, Accept-encoding, 415 Unsupported Media Type) - Mechanisms for locating next destination - Demonstrate correct implementation of RFC3263 "locating a SIP server" - Demonstrate correct implementation of sending to a URI that utilizes explicit or default address, port, or transport attributes. - Redirection mechanisms - Demonstrate successful redirection of a request (including having the redirected request succeed). - Dialog mechanisms - Interoperable establishment and termination of a session-usage dialog - Interoperable establishment and termination of a session-usage dialog set up through a forking proxy. - Interoperable establishment and termination of multiple session-usages dialogs resulting from a single INVITE forking at a forking proxy. - Demonstrate ability to update a remote target using a re-INVITE - Demonstrate correct implementation of Route/Record-Route mechanism. - Authentication mechanisms - Demonstrate successful authentication using SIP Digest - Correct implementation of 2069/2617 negotiation - Successful use of auth and auth-int using MD5 - Correct implementation of rejecting unknown algorithms - Demonstrate successful authentication through multiple proxies, placed both in series and in parallel on different branches of a forked request - Demonstrate successful exchange of S/MIME protected entities - Demonstrate correct implementation of identifying a SIP peer using a TLS connection (mutual and server only auth) - Extensibility mechanisms - Demonstrate correct implementation of rejecting unknown methods at endpoints - Demonstrate correct implementation of forwarding unknown methods at proxies - Demonstrate correct implementation of rejecting unknown Sparks Expires January 3, 2009 [Page 8] Internet-Draft SIP to DS Jul 2008 "Require"d extensions - Demonstrate successful negotiation and exercise of some "Require"d extension - Demonstrate correct implementation of ignoring unknown header fields at endpoints - Demonstrate correct implementation of forwarding unknown header fields at proxies - Demonstrate correct implementation of rejecting unknown SIP versions - Demonstrate correct implementation of handling requests with unknown schemes in the RURI - Demonstrate correct handling of unknown responses - Demonstrate correct implementation of ignoring unknown header field parameters at endpoints, and forwarding at proxies. - URI specific features - Demonstrate successful transaction using a Request-URI containing escaped and non-ascii UTF8 characters - Demonstrate correct implementation of request generation based on a SIP URI containing embedded header fields - Demonstrate correct implementation of request generation based on a SIP URI containing an embedded entity (body) - Demonstrate correct implementation of SIP URI comparison - Demonstrate correct implementation of recommendations for constructing sip: URIs from tel: URIs - Application-level features - Demonstrate successful offer/answer exchange using SIP - in INVITE/200 - in 200/ACK - Demonstrate successful registration of an endpoint (creation, refreshing, and removal of a binding) - Demonstrate correct implementation of a "query" register - Demonstrate correct implementation of "soft-state" removal of unrefreshed bindings - Demonstrate correct manipulation of a single binding at an AoR with several bindings in place - Demonstrate correct implementation of wildcard de-registration - Demonstrate that someone will cut and paste this list into some inappropriate place without reading it before it's had review - Demonstrate successful query for capabilities (correct implementation of OPTIONS) - Proxy application-level features - Demonstrate correct implementation of specified behavior upon receiving a CANCEL request - Demonstrate correct implementation of the Timer-C based mechanism for terminating an INVITE transaction - Demonstrate correct implementation of the Max-Forwards mechanism - Demonstrate correct implementation of loop-detection Sparks Expires January 3, 2009 [Page 9] Internet-Draft SIP to DS Jul 2008 (what about the rest of fork-loop-fix) - Demonstrate correct implementation of merging challenges received from multiple responses to a forked request - Demonstrate correct implementation of merging multiple contacts received in redirect responses to a forked request - Demonstrate correct implementation of recursing on redirections responses at proxies - 2543-compatibility (that we might be able to drop?) - Successful exchange of messages without a Content-Length header over UDP - Successful transaction without a z9Gh4bK style transaction identifier - Other unusual things (will we be able to find implementations?) - Demonstrate correct implementation of stateless UASs - Demonstrate correct implementation of stateless proxies - Demonstrate successfully setting an internal clock based on a Date header field returned in a REGISTER response. - Demonstrate successful discovery of a registrar through multicast to (224.0.1.72) 4. Strawman discussion points Choosing the correct level of detail for the interoperability statements in Section 3 is a balancing act. As [I-D.dusseault-impl-reports] recommends, some of these statements make other statements by implication. For instance, we are not (yet) explicitly calling out testing case-sensitivity, multipart-mime, provisional responses, or exercise of the registration duration negotiation mechanisms. Instead, those are each already contained in one or more of the statements made above and it is expected that the report will call out any problems with these features at the appropriate statement. Thus, we need to review the statements we plan to make carefully to make sure they are fine enough to convince ourselves that we have an opportunity to capture when things don't work without becoming so fine that the sheer level of detail hides the real statement of interoperability that we're trying to make. It is certain that the list as presented so far is not complete. Here are a few seed questions for exploring how well the statements so far cover the specification (this is not intended to be exhaustive): o Right now there is nothing covering sips:. What do those statements need to look like? Sparks Expires January 3, 2009 [Page 10] Internet-Draft SIP to DS Jul 2008 o What kind of statement will capture that we've ensured more than one implementation exercises 413 Request Entity too large and that clients do the right thing on receiving it? o Do we want to dive deeper into q-value processing at registrars and proxies? o How do we make a statement that captures we've found two implementations that discover their registrar through configuration rather than using URI resolution. o Do we dive any deeper than the statements above into proxy rewriting of Record-Route header field values in responses? (I propose no, that this a contained case as discussed above, but its less obvious that we'll be sure to remember to check and comment on problems if we can't find two independent implementations). o How do we make a statement that captures that we've verified independent implementation of the correct behavior for request timeouts at endpoints and proxies? The list here _is_ intended to be mostly complete, however. Please review it carefully from that perspective and help identify what needs to be added and removed to take it all the way to complete. 5. Security Considerations This document is not known to introduce any new security issues for consideration. 6. Informative References [I-D.dusseault-impl-reports] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports", draft-dusseault-impl-reports-00 (work in progress), July 2008. [I-D.ietf-sip-hitchhikers-guide] Rosenberg, J., "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", draft-ietf-sip-hitchhikers-guide-05 (work in progress), February 2008. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Sparks Expires January 3, 2009 [Page 11] Internet-Draft SIP to DS Jul 2008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2327] Handley, M. and V. Jacobson, "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. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Sparks Expires January 3, 2009 [Page 12] Internet-Draft SIP to DS Jul 2008 Author's Address Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA Email: RjS@nostrum.com Sparks Expires January 3, 2009 [Page 13] Internet-Draft SIP to DS Jul 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Intellectual Property 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. Sparks Expires January 3, 2009 [Page 14]