Network Working Group B. Lowekamp Internet-Draft SIPeerior; William & Mary Intended status: Standards Track D. Bryan Expires: May 14, 2008 SIPeerior Technologies, Inc. November 11, 2007 Using ICE to establish SIP Dialogs draft-lowekamp-sipping-ice-for-sip-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 May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This draft explores a way SIP can be extended to allow a new dialog directly between the endpoints to replace an initial dialog that had one or more proxies in the signalling path. This technique relies on ICE to perform hole punching that allows a direct connection to be used in deployments where a sip-outbound proxy or SBC is used to establish SIP connections across NAT or firewall boundaries. It can also be used to replace such a dialog with a secure connection Lowekamp & Bryan Expires May 14, 2008 [Page 1] Internet-Draft ICE for SIP November 2007 directly between the endpoints. This technique can be applied to traditional proxy-based SIP routing as well as to emerging P2PSIP deployments that lack centrally located proxies. This draft describes early work that evolved from ideas initially developed for P2PSIP that are no longer being pursued. We are interested in feedback on whether there is broader interest in these techniques. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. sip-outbound . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. B2BUA . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Secure Connection . . . . . . . . . . . . . . . . . . . . 5 1.4. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Extensions to SIP . . . . . . . . . . . . . . . . . . . . . . 6 3. ICE Negotiation . . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Lowekamp & Bryan Expires May 14, 2008 [Page 2] Internet-Draft ICE for SIP November 2007 1. Overview ICE is typically used to open media streams. This draft describes how ICE can be used to open SIP signalling connections, thus "ICE for SIP." This section describes scenarios showing how an ICE for SIP extension can be used: o Proxies can handle NAT traversal for SIP dialogs by inserting themselves into the signalling path using sip-outbound and Record- Route. ICE for SIP can be used to establish a direct connection between the endpoints after the initial setup, thus reducing the load on the proxy or proxies and the latency of the connection. o Support from a B2BUA could allow it to remove itself from the dialog path after it is no longer interested in future call control or required for NAT traversal. o Establishing a direct connection between the endpoints can allow for end-to-end security, which is extremely difficult to guarantee on paths where multiple proxies are involved. Here an initial connection is made using the proxies, but the dialog is replaced with a direct, secure dialog before any sensistive information is exchanged. o Replacing a dialog originally established across a P2PSIP overlay with a direct IP connection between endpoints. There may be other applications of this technique. In particular, if a flow established directly between endpoints can be used for future dialogs and other messages, then the proxies on the initial signalling path can be left out of those connections as well. 1.1. sip-outbound When an inbound INVITE arrives at a proxy that supports sip- outbound[I-D.ietf-sip-outbound], the proxy is already aware that the destination UA is behind a NAT and is associated with an established flow. That edge proxy rewrites the Request-URI and forwards the message along the flow previously opened through the NAT by the client. The edge proxy adds a Record-Route header to force futher mid-dialog requests to continue to be routed through the edge proxy along the same flow. To reduce the load on the edge proxy, ICE for SIP allows the two endpoints (or other proxies along the path) to establish a direct connection for further mid-dialog requests. When a UA sends a request to open a dialog, it includes an ice-sip tag in its Via. Similarly, the proxy adds the same tag to its Record-Route header. Lowekamp & Bryan Expires May 14, 2008 [Page 3] Internet-Draft ICE for SIP November 2007 After the initial dialog is established, the answering endpoints inspects the components of the path. ICE for SIP may be used to replace the initial dialog if the initial endpoint added an ice-sip tag to its Via header and each proxy along the path that inserted a Record-Route header indicated its support for ice-sip through a tag in its Record-Route URI. Note that this requirement is to ensure that policy enforced by intermediate proxies is not bypassed by the replacement dialog rather than by a technical requirement that the intermediate proxies must meet. A proxy that supports ICE for SIP but is unwilling to allow the dialog to be replaced with a direct path would not insert an ice-sip tag into its Record-Route header for that particular dialog. Open issue: should it be possible for intermediate proxies to make use of this feature to remove other intermediate proxies from the path even if the endpoints do not themselves support ice-sip, i.e. shorten the path even if a direct connection is not possible? To replace the initial dialog, the answering endpoint initiates a re- INVITE with an ICE SDP that specifies a media type of control/sip. The endpoints then perform ICE negotiation and, if successful, the offerer sends an INVITE across the newly established end-to-end flow with a Replaces header that indicates the original dialog is being replaced[RFC3891]. Open issue: what about dialogs not established by an INVITE? Open issue: Could a flow established be use for future dialogs or non-dialog use such as MESSAGE? Should it be possible to specify an INVITE that specifically requests this behavior so that on-path proxies can process/reject it if they want to be aware of future dialogs? Technically this is rather simple once the direct flow is open, it's just a question of whether it might violate a proxy's policy requirements. Perhaps in addition to ice-sip there should be another tag or the tag should have an option to indicate whether only this or future dialogs may be directly routed? 1.2. B2BUA In an SBC type deployment the endpoints are typically not aware that there is a way the path could be optimized because they do not see end-to-end headers. However, if the B2BUA indicates its support for ice-sip as above, and all other elements on the path support ice-sip, that B2BUA may initiate dialog replacement even if it appears to the other endpoint that there are no other elements that inserted themselves into the path with Record-Route headers. Replacing the new dialog is conceptually simple, except that the Lowekamp & Bryan Expires May 14, 2008 [Page 4] Internet-Draft ICE for SIP November 2007 existing dialog presumably has a different dialog id (call-id, to- tag, and from-tag) on either side of the B2BUA. Therefore, a direct end-to-end INVITE with a Replaces header would not work. Instead, a REFER has more appropriate semantics and could be used instead. Open issue: it is unclear whether it would be worth specifying such behavior for a B2BUA acting as an SBC because it might make more sense for such a device to be redeployed as a sip-outbound capable device that could more naturally implement ICE for SIP and not worry about the complexity of addressing this situation. In particular, if an SBC is used to provide demarcation and intended to hide the internal network, rather than just facilitating NAT traversal, a direct connection would not be appropriate. Open issue: this technique could be used to bypass a Controller in 3pcc call flows. Is there interest in such a capability? Open issue: Rather than using REFER, it might be better to provide a technique where UAs implementing the ice-sip extension identify that there is a B2BUA involved in the initial re-INVITE and rely on ICE's authentication from the SDP in the re-INVITE to connect the old and new dialogs. 1.3. Secure Connection Ensuring the security of an end-to-end SIP dialog in the presence of multiple proxies is a difficult challenge, and there is no way a UA can be certain that a message was delivered securely along each hop [I-D.ietf-sip-sips]. In this case, the techniques of 1.1 can be used to ensure security by establishing a direct TLS or DTLS connection between the endpoints. Rather than establishing an initial dialog with an INVITE specifying media to be exchanged, the initial INVITE can merely specify a control/sip media type, initiating the creation of a direct, secure dialog that can be used for future exchanges and real media. 1.4. P2PSIP P2PSIP, by definition, relies on end-to-end connections between its peers for SIP dialogs. Multiple mechanisms have been proposed for establishing these dialogs, with some proposals suggesting multiple methods [I-D.bryan-p2psip-reload][I-D.matthews-p2psip-hip-hop]: 1. Direct connection between peers, assuming that all peers will accept direct incoming connections. 2. Indirect connection established through an intermediary, typically using ICE. The intermediary could either be a single Lowekamp & Bryan Expires May 14, 2008 [Page 5] Internet-Draft ICE for SIP November 2007 entity, if one with appropriate connectivity can be located, or the P2P overlay network itself. 3. Tunneled connection relying on the overlay for transport of SIP datagrams. 4. HIP-HOP relies on an entirely different technique of using the connectivity obtained by using HIP to route SIP messages. The first technique is obviously of limited applicability in scenarios that range beyond a single LAN. The second technique works well, but imposes the ICE setup delay on the new connection before the actual SIP message can be sent. The third technique avoids the initial ICE setup delay, but establishes the dialog across the overlay, resulting in the overlay's routing latency being added to each message exchanged in the SIP dialog. The tradeoff between the second and third technique is that the first trades initial delay for a direct dialog connection, whereas the third has lower initial delay, but an indirect connection for the entire dialog. Although the second technique relies on the use of ICE to establish a SIP dialog, it does not require use of the specification in this draft because it concerns only establishing a new dialog and is expected to be encoded in a custom representation, rather than SDP. The third technique's shortcoming of higher per-message latency can be resolved by applying ICE for SIP to replace the initial overlay- routed dialog with a direct dialog. Thus, the initial dialog can be established quickly by routing across the overlay and deferring ICE negotiation until the dialog is established. If ICE negotiation goes slowly or fails, the overlay-routed dialog can continue to be used. Otherwise, it will be replaced by the end-to-end dialog. 2. Extensions to SIP The initial requester SHOULD include an ice-sip tag in their via to indicate a willingness to accept ICE negotiation for a replacement dialog. Any proxy that inserts a Record-Route for itself SHOULD add ice-sip tag to its URI in the Record-Route header if it wishes to allow the dialog to be replaced with a direct dialog that bypasses itself. If a proxy wishes to be involved in all future messages in the dialog, it MUST NOT include an ice-sip tag in its Record-Route header. The answerer MUST NOT initiate a request for a replacement dialog Lowekamp & Bryan Expires May 14, 2008 [Page 6] Internet-Draft ICE for SIP November 2007 unless the initial Via and all Record-Route URIs contain an ice-sip tag. 3. ICE Negotiation ICE negotiation is handled as described in ICE [I-D.ietf-mmusic-ice] and ICE-TCP [I-D.ietf-mmusic-ice-tcp]. ICE for SIP uses SDP to encode its ICE offers and answers because all SIP implementations already implement SDP and those implementing ICE will support encoding ICE offers in SDP. The following changes are made for ICE for SIP negotiations from ICE for media: o Timers will be set as specified in Section 16.2 of ICE [I-D.ietf-mmusic-ice]for non-RTP sessions. o The SDP's "m=" line will specify the media type as "control" and the media format as "sip". The transport field will be either "tcp" or "udp". SDP [RFC4566] o Specification of encryption requirements in the SDP is an open issue being addressed in the MMUSIC working group. We will use those techniques when they are finalized. o The SDP MUST NOT include an "a=recvonly", "a=sendonly", "a=inactive", or a "0.0.0.0" specification. o A relay candidate SHOULD NOT be included in the SDP. As the dialog has an existing path through proxies, there should be no reason to switch to a different method of relaying. If ICE negotiation fails, then the re-INVITE has failed and the UAs will continue to use the existing dialog. The UAs MUST NOT attempt to use a default destination. Open Issue: should a default destination of 0.0.0.0/0 be specified? Open Issue: dsip-nat-traversal [I-D.matthews-p2psip-dsip-nat-traversal] specified media type application/sip, but this seems inappropriate as it doesn't meet the definition of "application" data that is to be presented to a user from SDP [RFC2327]. The former media type of "control" seems to be more appropriate for a SIP signalling connection. 4. IANA Considerations TBD Lowekamp & Bryan Expires May 14, 2008 [Page 7] Internet-Draft ICE for SIP November 2007 5. Security Considerations The technique described in this draft poses policy issues in that it allows SIP UAs to bypass proxies that would ordinarily be in the path between those UAs. However, because the dialog will not be replaced unless each proxy in the path that would be kept in the dialog authorizes such a change by inserting an "ice-sip" tag, policy requirements to keep a proxy in the path are maintained. Attacks on the ICE negotiation are addressed in ICE [I-D.ietf-mmusic-ice]. ICE is best secured by securing the initial SIP dialog, which secures the initial SDP exchange. The replacement dialog should also be secured as a sips connection with TLS or DTLS. Because the endpoints have been authenticated with ICE, Diffie-Hellman can be used or possibly TLS-PSK could be used with the ice-pwd values from the SDP used to form the key. There are likely other security risks that are have not yet been considered. 6. Acknowledgements The idea for using INVITE to establish a new SIP session originated in the earliest work on P2PSIP [I-D.bryan-sipping-p2p] as a technique for establishing connections between peers in the overlay. Further work refined the concept for NAT traversal for a P2PSIP overlay [I-D.matthews-p2psip-dsip-nat-traversal][I-D.matthews-p2psip-bootstra p-mechanisms]. Jonathan Rosenberg pointed out that the technique might have applications for regular SIP deployments in addition to P2PSIP. Thanks to Alan Johnston and special thanks to Philip Matthews for many conversations on NAT traversal for P2PSIP. 7. References 7.1. Normative References [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.ietf-mmusic-ice-tcp] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE", Lowekamp & Bryan Expires May 14, 2008 [Page 8] Internet-Draft ICE for SIP November 2007 draft-ietf-mmusic-ice-tcp-04 (work in progress), July 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 7.2. Informative References [I-D.bryan-p2psip-reload] Bryan, D., "REsource LOcation And Discovery (RELOAD)", draft-bryan-p2psip-reload-01 (work in progress), July 2007. [I-D.bryan-sipping-p2p] Bryan, D., "A P2P Approach to SIP Registration and Resource Location", draft-bryan-sipping-p2p-03 (work in progress), October 2006. [I-D.ietf-sip-outbound] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-10 (work in progress), July 2007. [I-D.ietf-sip-sips] Audet, F., "The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", draft-ietf-sip-sips-06 (work in progress), August 2007. [I-D.matthews-p2psip-bootstrap-mechanisms] Cooper, E., "Bootstrap Mechanisms for P2PSIP", draft-matthews-p2psip-bootstrap-mechanisms-00 (work in progress), February 2007. [I-D.matthews-p2psip-dsip-nat-traversal] Cooper, E., "NAT Traversal for dSIP", draft-matthews-p2psip-dsip-nat-traversal-00 (work in progress), February 2007. [I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing", Lowekamp & Bryan Expires May 14, 2008 [Page 9] Internet-Draft ICE for SIP November 2007 draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Authors' Addresses Bruce B. Lowekamp SIPeerior; William & Mary 3000 Easter Circle Williamsburg, VA 23188 USA Phone: +1 757 565 0101 Email: lowekamp@sipeerior.com David A. Bryan SIPeerior Technologies, Inc. 3000 Easter Circle Williamsburg, VA 23188 USA Phone: +1 757 565 0101 Email: dbryan@sipeerior.com Lowekamp & Bryan Expires May 14, 2008 [Page 10] Internet-Draft ICE for SIP November 2007 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lowekamp & Bryan Expires May 14, 2008 [Page 11]