SIPPING WG V. Gurbani, Ed. Internet-Draft Lucent Technologies/Bell Expires: November 19, 2006 Laboratories C. Boulton Ubiquity Software Corporation R. Sparks Estacado Systems May 18, 2006 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) draft-gurbani-sipping-ipv6-sip-03.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 November 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This informational document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the IPv6 portions of a SIP implementation. Gurbani, et al. Expires November 19, 2006 [Page 1] Internet-Draft SIP IPv6 Torture Tests May 2006 This work is being discussed on the sipping@ietf.org mailing list. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SIP and IPv6 Network Configuration . . . . . . . . . . . . . . 3 3. Parser Torture Tests . . . . . . . . . . . . . . . . . . . . . 3 3.1 Valid SIP request with raw IPv6 addresses . . . . . . . . 4 3.2 Which port should I knock on? . . . . . . . . . . . . . . 4 3.3 Knock on this port, please . . . . . . . . . . . . . . . . 5 3.4 SIP request with IPv6 in Via received parameter . . . . . 5 3.4.1 SIP request with delimiting tokens in Via received parameter . . . . . . . . . . . . . . . . . . . . . . 6 3.4.2 SIP request without the delimiter tokens in the Via received parameter . . . . . . . . . . . . . . . . 6 3.5 SIP request with IPv6 identifiers in SDP body . . . . . . 7 3.6 Via headers from different networks in a request . . . . . 8 3.7 SIP request with multiple network identifiers in SDP . . . 8 3.8 More test cases . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 7.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 A. Bit-exact archive of each test message . . . . . . . . . . . . 11 A.1 Encoded Reference Messages . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Gurbani, et al. Expires November 19, 2006 [Page 2] Internet-Draft SIP IPv6 Torture Tests May 2006 1. Overview This document is informational, and is NOT NORMATIVE on any aspect of SIP. This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as defined in [1]. This document is expected to be used as a companion document to the more general SIP torture test document [3], which does not include specific tests for IPv6 network identifiers. This document does not attempt to catalog every way to make an invalid message, nor does it attempt to be comprehensive in exploring unusual, but valid, messages. Instead, it tries to focus on areas that may cause interoperability problems in IPv6 deployments. The messages are presented in the text using a set of markup conventions to avoid ambiguity and meet Internet-Draft layout requirements. To resolve any remaining ambiguity, a bit-accurate version of each message is encapsulated in an appendix. 2. SIP and IPv6 Network Configuration System-level issues like deploying a dual-stack proxy server, populating DNS with A and AAAA RRs, zero-configuration discovery of outbound proxies for IPv4 and IPv6 networks, when should a dual-stack proxy Record-Route itself, and media issues also play a major part in the transition to IPv6. This document does not, however, address these issues. Instead, a companion document [2] provides more guidance on these. 3. Parser Torture Tests The test messages are organized into several sections. Some stress only a SIP parser and others stress both the parser and the application above it. Some messages are valid, and some are not. Each example clearly calls out what makes any invalid messages incorrect. Please refer to the ABNF in [1] on representing IPv6 addresses in SIP. IPv6 addresses are delimited by a '[' and ']'. The appendix contains an encoded binary form of all the messages and the algorithm needed to decode them into files. Gurbani, et al. Expires November 19, 2006 [Page 3] Internet-Draft SIP IPv6 Torture Tests May 2006 3.1 Valid SIP request with raw IPv6 addresses This REGISTER request is well-formatted per the grammar in [1]. An IPv6 address in presentation form appears in the Request-URI (R-URI), Via header, and Contact header. Message Details: reg-good REGISTER sip:[2001:db8::10] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" CSeq: 98176 REGISTER Content-Length: 0 3.2 Which port should I knock on? IPv6 uses the colon to delimit octets. This may lead to ambiguity if the port number on which to contact a SIP server is inadverdently conflated with the IPv6 address. Consider the REGISTER request below. The sender of the request intended to specify a port number (5070). Unfortunately, however, since the IPv6 address in the R-URI is compressed, it makes it hard to tell whether the 5070 is a port number or the last octet in the address. From a pure parsing point of view, the REGISTER request is well- formed. However, from a semantic point of view, it will not yield the desired result. Implementations must take care to ensure that when a raw IPv6 address appears in a SIP URI, then any port number must appear outside the closing '[' of the URI. Message Details: reg-ambigous REGISTER sip:[2001:db8::10:5070] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" CSeq: 98176 REGISTER Content-Length: 0 Gurbani, et al. Expires November 19, 2006 [Page 4] Internet-Draft SIP IPv6 Torture Tests May 2006 3.3 Knock on this port, please In contrast to the example in Section 3.2, the following REGISTER request leaves no ambiguity whatsover on where the IPv6 address begins and where it ends. This REGISTER request is well formatted per the grammar in [1]. Message Details: reg-good-port REGISTER sip:[2001:db8::10]:5070 SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" CSeq: 98176 REGISTER Content-Length: 0 3.4 SIP request with IPv6 in Via received parameter There currently exists an ambiguity on whether the received parameter of the Via header that contains an IPv6 address should have the delimiting '[' and ']' tokens. The RFC3261 ABNF indicates that this is not the case, however it makes the implementation of the parser more optimized if it was to recognize the '[' token as a beginning of an IPv6 address. In all the other instances where an IPv6 address is used in SIP, it is delimited by the '[' and ']' tokens. Thus, for the sake of orthogonality as well as optimized parsing, it seems appropriate that the IPv6 addresses in the received parameter be delimited by '[' and ']'. Some additional analysis on why the form that includes the delimiters is desirable is included in the following reference [7]. More specifically, RFC3261 ABNF defines the via-received production rule as follows: via-received = "received" EQUAL (IPv4address / IPv6address) IPv6address production rule is then defined to hold an IPv6 address without the delimiting '[' and ']' tokens. There is also an IPv6reference production rule in RFC3261 that yields the following: IPv6reference = "[" IPv6address "]" Thus, to allow the delimiting '[' and ']' tokens in the received Gurbani, et al. Expires November 19, 2006 [Page 5] Internet-Draft SIP IPv6 Torture Tests May 2006 parameter, all that would need to be done is to amend the RFC3261 via-received production rule as follows: via-received = "received" EQUAL (IPv4address / IPv6reference) However, strong consensus has not yet emerged on this (the issue is documented on the SIPPING WG mailing list; see [6] for a link to the start of the discussion thread). At the 18th SIPit, it was observed that [5]: Those testing IPv6 made different assumptions about enclosing literal v6 addresses in Vias in []. By the end of the event, most implementations were accepting either. Its about 50/50 on what gets sent. Consequently, as it now stands, implementations must follow the Robustness Principle [4] and be liberal in accepting a received parameter with or without the delimiting '[' and ']' tokens. When sending a request, implementations must not put the delimiting '[' and ']' tokens. The two test cases that follow, should thus be acceptable to any SIP implementation that supports IPv6. 3.4.1 SIP request with delimiting tokens in Via received parameter This REGISTER request contains an IPv6 address in the Via received parameter. The IPv6 address is delimited by '[' and ']'. Even though this is not a well-formatted request based on a strict interpretation of the grammar in [1], robust implementations should nonetheless be able to parse the topmost Via header. Message Details: reg-param REGISTER sip:[2001:db8::10] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];received=[2001:db8::9:255]; branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" CSeq: 98176 REGISTER Content-Length: 0 3.4.2 SIP request without the delimiter tokens in the Via received parameter Gurbani, et al. Expires November 19, 2006 [Page 6] Internet-Draft SIP IPv6 Torture Tests May 2006 This OPTIONS request contains an IPv6 address in the Via received paramter without the adorning '[' and ']'. This OPTIONS request is valid and well-formatted. Message Details: opt-param OPTIONS sip:[2001:db8::10] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];received=2001:db8::9:255; branch=z9hG4bKas3 Call-ID: SSG95523997077@hlau_4100 Contact: "Caller" CSeq: 921 OPTIONS Content-Length: 0 3.5 SIP request with IPv6 identifiers in SDP body This INVITE request is valid and well-formed. Notice the IPv6 addresses in the SDP body. Message Details: inv-good INVITE sip:user@[2001:db8::10] SIP/2.0 To: sip:user@[2001:db8::10] From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" CSeq: 8612 INVITE Content-Type: application/sdp Content-Length: 268 v=0 o=assistant 971731711378798081 0 IN IP6 2001:db8::20 s=Live video feed for today's meeting c=IN IP6 2001:db8::1 t=3338481189 3370017201 m=audio 6000 RTP/AVP 2 a=rtpmap:2 G726-32/8000 m=video 6024 RTP/AVP 107 a=rtpmap:107 H263-1998/90000 Gurbani, et al. Expires November 19, 2006 [Page 7] Internet-Draft SIP IPv6 Torture Tests May 2006 3.6 Via headers from different networks in a request This BYE request is valid and well-formed. The Via list contains a mix of IPv4 and IPv6 addresses. Message Details: bye-good BYE sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP [2001:db8::9:1]:6050;branch=z9hG4bKas3-111 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKjhja8781hjuaij65144 Via: SIP/2.0/TCP [2001:db8::9:255];branch=z9hG4bK451jj; received=192.0.2.200 Call-ID: 997077@lau_4100 CSeq: 89187 BYE To: sip:user@example.net;tag=9817--94 From: sip:user@example.com;tag=81x2 3.7 SIP request with multiple network identifiers in SDP This INVITE request is valid and well-formed. It contains multiple network identifiers in the SDP body. Message Details: inv-mult-sdp INVITE sip:user@[2001:db8::10] SIP/2.0 To: sip:user@[2001:db8::10] From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" CSeq: 8912 INVITE Content-Type: application/sdp Content-Length: 181 v=0 o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 m=audio 22334 RTP/AVP 0 c=IN IP4 192.0.2.1 m=video 6024 RTP/AVP 107 c=IN IP6 2001:db8::1 a=rtpmap:107 H263-1998/90000 Gurbani, et al. Expires November 19, 2006 [Page 8] Internet-Draft SIP IPv6 Torture Tests May 2006 3.8 More test cases TBD. Looking for more test cases...suggestions welcome. 4. Security Considerations This document presents NON NORMATIVE examples of SIP session establishment. The security considerations in [1] apply. Parsers must carefully consider edge conditions and malicious input as part of their design. Attacks on many Internet systems use crafted input to cause implementations to behave in undesirable ways. Many of the messages in this draft are designed to stress a parser implementation at points traditionally used for such attacks. This document does not, however, attempt to be comprehensive. It contains some common pitfalls that the authors have discovered while parsing IPv6 identifiers in SIP implementations. 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgments The authors acknowledge Jeroen van Bemmel, Dennis Bijwaard, Gonzalo Camarillo, Bob Gilligan, Larry Kollasch, Erik Nordmark, Kumiko Ono and Pekka Pessi for input provided during the construction of the document and discussion of the test cases. The appendix contains a bit-exact archive of each message following the convention established by Robert Sparks. 7. References 7.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] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", draft-ietf-sipping-v6-transition-02.txt (work in progress), October 2005. Gurbani, et al. Expires November 19, 2006 [Page 9] Internet-Draft SIP IPv6 Torture Tests May 2006 7.2 Informative References [3] Sparks, R., Hawrylyshen, A., Hawrylyshen, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol Torture Test Messages", draft-ietf-sipping-torture-tests-09 (work in progress), November 2005. [4] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [5] Sparks, R., "preliminary report: SIPit 18", Electronic Mail archived at http://www1.ietf.org/mail-archive/web/sip/current/ msg14103.html, April 2006. [6] Gurbani, V., "SIP/IPv6 torture test and possible interaction with rfc3261 ABNF", Electronic Mail archived at http:// www1.ietf.org/mail-archive/web/sipping/current/msg10341.html, February 2006. [7] van Bemmel, J., "[Sipping] Re: [Sip-implementors] SIP/IPv6 torture test and possible interaction with rfc3261 ABNF", Electronic Mail archived at http://www1.ietf.org/mail-archive/ web/sipping/current/msg10373.html, February 2006. Authors' Addresses Vijay Gurbani (editor) Lucent Technologies/Bell Laboratories 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA Phone: +1 630 224 0216 Email: vkg@lucent.com Chris Boulton Ubiquity Software Corporation Building 3 West Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@ubiquitysoftware.com Gurbani, et al. Expires November 19, 2006 [Page 10] Internet-Draft SIP IPv6 Torture Tests May 2006 Robert J. Sparks Estacado Systems Email: RjS@estacado.net Appendix A. Bit-exact archive of each test message The following text block is an encoded, gzip compressed TAR archive of files that represent each of the example messages discussed in Section 4. To recover the compressed archive file intact, the text of this document may be passed as input to the following Perl script (the output should be redirected to a file or piped to "tar -xzvf -"). #!/usr/bin/perl use strict; my $bdata = ""; use MIME::Base64; while(<>) { if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { if ( m/^\s*[^\s]+\s*$/) { $bdata = $bdata . $_; } } } print decode_base64($bdata); Alternatively, the base-64 encoded block can be edited by hand to remove document structure lines and fed as input to any base-64 decoding utility. A.1 Encoded Reference Messages Gurbani, et al. Expires November 19, 2006 [Page 11] Internet-Draft SIP IPv6 Torture Tests May 2006 -- BEGIN MESSAGE ARCHIVE -- H4sICEzabEQAA2RhdGEudGFyAO2Z72/iNhjH+zp/hXVv9irgxz/jdJlu63Ud2ukOFVZpm qrJgA/CCMmSgK776+eQBgq0pTs1VGvzFRBCbOzYz+frHxncGHccx6OTGoUBY8HYif3ElI k7x1KcihPAlABhggK1vwMhgE9wnZWqtMhyndoil3+NH0136HpxI5SQ4igxEc9ZxTr10+/ nKAsTf5GZ9P0kzvKW+aqjZGZawzhCvU63TVrYuQq1X520f/vQRX8Q20n+aOD5vvLh2heY 49NBqufDSfCPmlywwa86oy4A7OcF3LIv0qI7GaaTqfakB5PpQodTwYGx7cz9s52CCefXO 3/COEynp6kZmnBpRkFVFhDsnOnZzO188JFSEkv5fqYXfzIbms5Zz/ztI0+BJ5FtD6cf+5 s2qZpjbvLTXI8D5YF0XcWcn9M4uiedbbZVOg++Euele/ewwvnypfkHGzsl/5jZNy/5x6L h/wjqfLrq9O9YwB2+AF+vDWALie00TwLhkIE84B1rZHu9C8W5UphzQm/5nWwAjue5HuY+ eldkMOk79H1RneHqZKu61z9UtAsgqLz5VXYzz93+TWJ8pJNkFg51HsbzdjZK1lc/mvk4n /iICM9xlgF24kBnWWjDZ54jJUFSkABUelJ52AOE7d+jTlegTfHWhLLgozUmtAxHJkZfjB mhL3GK8nikb77LUGRMHs7HzjDYywtOHlBKPeYBeApRKu0lSTA4UaAXozBGwoYeuux32z9 edRFxdJDmSaQTn6ALSYRLSduzKWzysnCBCVsnByw3GewJ+oUI2wVKeW1VRPb/wMkafYsK /48Ws9y1oV5XGYfmf5Kz0v85I5hD4f/UDgWN/x9Bb9b/1bf6P3hQ+f8gHiDiYcmYpNh+U 1LaBUzp+wztzqat91sPxwivHZsQSjcejCvbZwiUbadi2vqwW987RDxm4eheD4+T3E10qq MaY+wQ/4wV6z9GKXCOoZz/sWIeWGOd1nrj/H/u9jufP/VW+D6F/bvx/Czgr5dqOwu7Uwe ttGcMu6bwPH6gCKDbttgj/jXPflIzdnU0CMeLeJHVVMZB/ims13+43P+hhDbj/zF0eX7R 6fXPL/cNwOf2Ro7lAsce/otdHIGqm7+H+FeM/JYK/l96/5cRVvFvewXf7v9Aw/8R9DD/D fpvQRX/bhKneU1l/Kfxn7LV+A+cNfwfQY/wv5oANCbwulXw/+Lrf7F5/oPFav+PUNbwfw zVPv6jp+8AHHq229hCo0aNGj2f/gWwk3L/ACYAAA== -- END MESSAGE ARCHIVE -- Gurbani, et al. Expires November 19, 2006 [Page 12] Internet-Draft SIP IPv6 Torture Tests May 2006 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gurbani, et al. Expires November 19, 2006 [Page 13]