idnits 2.17.1 draft-lowekamp-sipping-ice-for-sip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 479. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 11, 2007) is 6010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.matthews-p2psip-bootstrap-mechanisms' is defined on line 402, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-04 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-04) exists of draft-bryan-p2psip-reload-01 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-10 == Outdated reference: A later version (-09) exists of draft-ietf-sip-sips-06 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Lowekamp 3 Internet-Draft SIPeerior; William & Mary 4 Intended status: Standards Track D. Bryan 5 Expires: May 14, 2008 SIPeerior Technologies, Inc. 6 November 11, 2007 8 Using ICE to establish SIP Dialogs 9 draft-lowekamp-sipping-ice-for-sip-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 14, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This draft explores a way SIP can be extended to allow a new dialog 43 directly between the endpoints to replace an initial dialog that had 44 one or more proxies in the signalling path. This technique relies on 45 ICE to perform hole punching that allows a direct connection to be 46 used in deployments where a sip-outbound proxy or SBC is used to 47 establish SIP connections across NAT or firewall boundaries. It can 48 also be used to replace such a dialog with a secure connection 49 directly between the endpoints. This technique can be applied to 50 traditional proxy-based SIP routing as well as to emerging P2PSIP 51 deployments that lack centrally located proxies. 53 This draft describes early work that evolved from ideas initially 54 developed for P2PSIP that are no longer being pursued. We are 55 interested in feedback on whether there is broader interest in these 56 techniques. 58 Requirements Language 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. sip-outbound . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. B2BUA . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Secure Connection . . . . . . . . . . . . . . . . . . . . 5 70 1.4. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Extensions to SIP . . . . . . . . . . . . . . . . . . . . . . 6 72 3. ICE Negotiation . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 Intellectual Property and Copyright Statements . . . . . . . . . . 11 82 1. Overview 84 ICE is typically used to open media streams. This draft describes 85 how ICE can be used to open SIP signalling connections, thus "ICE for 86 SIP." This section describes scenarios showing how an ICE for SIP 87 extension can be used: 89 o Proxies can handle NAT traversal for SIP dialogs by inserting 90 themselves into the signalling path using sip-outbound and Record- 91 Route. ICE for SIP can be used to establish a direct connection 92 between the endpoints after the initial setup, thus reducing the 93 load on the proxy or proxies and the latency of the connection. 95 o Support from a B2BUA could allow it to remove itself from the 96 dialog path after it is no longer interested in future call 97 control or required for NAT traversal. 99 o Establishing a direct connection between the endpoints can allow 100 for end-to-end security, which is extremely difficult to guarantee 101 on paths where multiple proxies are involved. Here an initial 102 connection is made using the proxies, but the dialog is replaced 103 with a direct, secure dialog before any sensistive information is 104 exchanged. 106 o Replacing a dialog originally established across a P2PSIP overlay 107 with a direct IP connection between endpoints. 109 There may be other applications of this technique. In particular, if 110 a flow established directly between endpoints can be used for future 111 dialogs and other messages, then the proxies on the initial 112 signalling path can be left out of those connections as well. 114 1.1. sip-outbound 116 When an inbound INVITE arrives at a proxy that supports sip- 117 outbound[I-D.ietf-sip-outbound], the proxy is already aware that the 118 destination UA is behind a NAT and is associated with an established 119 flow. That edge proxy rewrites the Request-URI and forwards the 120 message along the flow previously opened through the NAT by the 121 client. The edge proxy adds a Record-Route header to force futher 122 mid-dialog requests to continue to be routed through the edge proxy 123 along the same flow. 125 To reduce the load on the edge proxy, ICE for SIP allows the two 126 endpoints (or other proxies along the path) to establish a direct 127 connection for further mid-dialog requests. When a UA sends a 128 request to open a dialog, it includes an ice-sip tag in its Via. 129 Similarly, the proxy adds the same tag to its Record-Route header. 131 After the initial dialog is established, the answering endpoints 132 inspects the components of the path. ICE for SIP may be used to 133 replace the initial dialog if the initial endpoint added an ice-sip 134 tag to its Via header and each proxy along the path that inserted a 135 Record-Route header indicated its support for ice-sip through a tag 136 in its Record-Route URI. Note that this requirement is to ensure 137 that policy enforced by intermediate proxies is not bypassed by the 138 replacement dialog rather than by a technical requirement that the 139 intermediate proxies must meet. A proxy that supports ICE for SIP 140 but is unwilling to allow the dialog to be replaced with a direct 141 path would not insert an ice-sip tag into its Record-Route header for 142 that particular dialog. 144 Open issue: should it be possible for intermediate proxies to make 145 use of this feature to remove other intermediate proxies from the 146 path even if the endpoints do not themselves support ice-sip, i.e. 147 shorten the path even if a direct connection is not possible? 149 To replace the initial dialog, the answering endpoint initiates a re- 150 INVITE with an ICE SDP that specifies a media type of control/sip. 151 The endpoints then perform ICE negotiation and, if successful, the 152 offerer sends an INVITE across the newly established end-to-end flow 153 with a Replaces header that indicates the original dialog is being 154 replaced[RFC3891]. 156 Open issue: what about dialogs not established by an INVITE? 158 Open issue: Could a flow established be use for future dialogs or 159 non-dialog use such as MESSAGE? Should it be possible to specify an 160 INVITE that specifically requests this behavior so that on-path 161 proxies can process/reject it if they want to be aware of future 162 dialogs? Technically this is rather simple once the direct flow is 163 open, it's just a question of whether it might violate a proxy's 164 policy requirements. Perhaps in addition to ice-sip there should be 165 another tag or the tag should have an option to indicate whether only 166 this or future dialogs may be directly routed? 168 1.2. B2BUA 170 In an SBC type deployment the endpoints are typically not aware that 171 there is a way the path could be optimized because they do not see 172 end-to-end headers. However, if the B2BUA indicates its support for 173 ice-sip as above, and all other elements on the path support ice-sip, 174 that B2BUA may initiate dialog replacement even if it appears to the 175 other endpoint that there are no other elements that inserted 176 themselves into the path with Record-Route headers. 178 Replacing the new dialog is conceptually simple, except that the 179 existing dialog presumably has a different dialog id (call-id, to- 180 tag, and from-tag) on either side of the B2BUA. Therefore, a direct 181 end-to-end INVITE with a Replaces header would not work. Instead, a 182 REFER has more appropriate semantics and could be used instead. 184 Open issue: it is unclear whether it would be worth specifying such 185 behavior for a B2BUA acting as an SBC because it might make more 186 sense for such a device to be redeployed as a sip-outbound capable 187 device that could more naturally implement ICE for SIP and not worry 188 about the complexity of addressing this situation. In particular, if 189 an SBC is used to provide demarcation and intended to hide the 190 internal network, rather than just facilitating NAT traversal, a 191 direct connection would not be appropriate. 193 Open issue: this technique could be used to bypass a Controller in 194 3pcc call flows. Is there interest in such a capability? 196 Open issue: Rather than using REFER, it might be better to provide a 197 technique where UAs implementing the ice-sip extension identify that 198 there is a B2BUA involved in the initial re-INVITE and rely on ICE's 199 authentication from the SDP in the re-INVITE to connect the old and 200 new dialogs. 202 1.3. Secure Connection 204 Ensuring the security of an end-to-end SIP dialog in the presence of 205 multiple proxies is a difficult challenge, and there is no way a UA 206 can be certain that a message was delivered securely along each hop 207 [I-D.ietf-sip-sips]. In this case, the techniques of 1.1 can be used 208 to ensure security by establishing a direct TLS or DTLS connection 209 between the endpoints. Rather than establishing an initial dialog 210 with an INVITE specifying media to be exchanged, the initial INVITE 211 can merely specify a control/sip media type, initiating the creation 212 of a direct, secure dialog that can be used for future exchanges and 213 real media. 215 1.4. P2PSIP 217 P2PSIP, by definition, relies on end-to-end connections between its 218 peers for SIP dialogs. Multiple mechanisms have been proposed for 219 establishing these dialogs, with some proposals suggesting multiple 220 methods [I-D.bryan-p2psip-reload][I-D.matthews-p2psip-hip-hop]: 222 1. Direct connection between peers, assuming that all peers will 223 accept direct incoming connections. 225 2. Indirect connection established through an intermediary, 226 typically using ICE. The intermediary could either be a single 227 entity, if one with appropriate connectivity can be located, or 228 the P2P overlay network itself. 230 3. Tunneled connection relying on the overlay for transport of SIP 231 datagrams. 233 4. HIP-HOP relies on an entirely different technique of using the 234 connectivity obtained by using HIP to route SIP messages. 236 The first technique is obviously of limited applicability in 237 scenarios that range beyond a single LAN. The second technique works 238 well, but imposes the ICE setup delay on the new connection before 239 the actual SIP message can be sent. The third technique avoids the 240 initial ICE setup delay, but establishes the dialog across the 241 overlay, resulting in the overlay's routing latency being added to 242 each message exchanged in the SIP dialog. 244 The tradeoff between the second and third technique is that the first 245 trades initial delay for a direct dialog connection, whereas the 246 third has lower initial delay, but an indirect connection for the 247 entire dialog. Although the second technique relies on the use of 248 ICE to establish a SIP dialog, it does not require use of the 249 specification in this draft because it concerns only establishing a 250 new dialog and is expected to be encoded in a custom representation, 251 rather than SDP. 253 The third technique's shortcoming of higher per-message latency can 254 be resolved by applying ICE for SIP to replace the initial overlay- 255 routed dialog with a direct dialog. Thus, the initial dialog can be 256 established quickly by routing across the overlay and deferring ICE 257 negotiation until the dialog is established. If ICE negotiation goes 258 slowly or fails, the overlay-routed dialog can continue to be used. 259 Otherwise, it will be replaced by the end-to-end dialog. 261 2. Extensions to SIP 263 The initial requester SHOULD include an ice-sip tag in their via to 264 indicate a willingness to accept ICE negotiation for a replacement 265 dialog. 267 Any proxy that inserts a Record-Route for itself SHOULD add ice-sip 268 tag to its URI in the Record-Route header if it wishes to allow the 269 dialog to be replaced with a direct dialog that bypasses itself. If 270 a proxy wishes to be involved in all future messages in the dialog, 271 it MUST NOT include an ice-sip tag in its Record-Route header. 273 The answerer MUST NOT initiate a request for a replacement dialog 274 unless the initial Via and all Record-Route URIs contain an ice-sip 275 tag. 277 3. ICE Negotiation 279 ICE negotiation is handled as described in ICE [I-D.ietf-mmusic-ice] 280 and ICE-TCP [I-D.ietf-mmusic-ice-tcp]. ICE for SIP uses SDP to 281 encode its ICE offers and answers because all SIP implementations 282 already implement SDP and those implementing ICE will support 283 encoding ICE offers in SDP. The following changes are made for ICE 284 for SIP negotiations from ICE for media: 286 o Timers will be set as specified in Section 16.2 of ICE 287 [I-D.ietf-mmusic-ice]for non-RTP sessions. 289 o The SDP's "m=" line will specify the media type as "control" and 290 the media format as "sip". The transport field will be either 291 "tcp" or "udp". SDP [RFC4566] 293 o Specification of encryption requirements in the SDP is an open 294 issue being addressed in the MMUSIC working group. We will use 295 those techniques when they are finalized. 297 o The SDP MUST NOT include an "a=recvonly", "a=sendonly", 298 "a=inactive", or a "0.0.0.0" specification. 300 o A relay candidate SHOULD NOT be included in the SDP. As the 301 dialog has an existing path through proxies, there should be no 302 reason to switch to a different method of relaying. 304 If ICE negotiation fails, then the re-INVITE has failed and the UAs 305 will continue to use the existing dialog. The UAs MUST NOT attempt 306 to use a default destination. 308 Open Issue: should a default destination of 0.0.0.0/0 be specified? 310 Open Issue: dsip-nat-traversal 311 [I-D.matthews-p2psip-dsip-nat-traversal] specified media type 312 application/sip, but this seems inappropriate as it doesn't meet the 313 definition of "application" data that is to be presented to a user 314 from SDP [RFC2327]. The former media type of "control" seems to be 315 more appropriate for a SIP signalling connection. 317 4. IANA Considerations 319 TBD 321 5. Security Considerations 323 The technique described in this draft poses policy issues in that it 324 allows SIP UAs to bypass proxies that would ordinarily be in the path 325 between those UAs. However, because the dialog will not be replaced 326 unless each proxy in the path that would be kept in the dialog 327 authorizes such a change by inserting an "ice-sip" tag, policy 328 requirements to keep a proxy in the path are maintained. 330 Attacks on the ICE negotiation are addressed in ICE 331 [I-D.ietf-mmusic-ice]. ICE is best secured by securing the initial 332 SIP dialog, which secures the initial SDP exchange. 334 The replacement dialog should also be secured as a sips connection 335 with TLS or DTLS. Because the endpoints have been authenticated with 336 ICE, Diffie-Hellman can be used or possibly TLS-PSK could be used 337 with the ice-pwd values from the SDP used to form the key. 339 There are likely other security risks that are have not yet been 340 considered. 342 6. Acknowledgements 344 The idea for using INVITE to establish a new SIP session originated 345 in the earliest work on P2PSIP [I-D.bryan-sipping-p2p] as a technique 346 for establishing connections between peers in the overlay. Further 347 work refined the concept for NAT traversal for a P2PSIP overlay 348 [I-D.matthews-p2psip-dsip-nat-traversal][I-D.matthews-p2psip-bootstra 349 p-mechanisms]. Jonathan Rosenberg pointed out that the technique 350 might have applications for regular SIP deployments in addition to 351 P2PSIP. Thanks to Alan Johnston and special thanks to Philip 352 Matthews for many conversations on NAT traversal for P2PSIP. 354 7. References 356 7.1. Normative References 358 [I-D.ietf-mmusic-ice] 359 Rosenberg, J., "Interactive Connectivity Establishment 360 (ICE): A Protocol for Network Address Translator (NAT) 361 Traversal for Offer/Answer Protocols", 362 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 364 [I-D.ietf-mmusic-ice-tcp] 365 Rosenberg, J., "TCP Candidates with Interactive 366 Connectivity Establishment (ICE", 367 draft-ietf-mmusic-ice-tcp-04 (work in progress), 368 July 2007. 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 374 Protocol (SIP) "Replaces" Header", RFC 3891, 375 September 2004. 377 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 378 Description Protocol", RFC 4566, July 2006. 380 7.2. Informative References 382 [I-D.bryan-p2psip-reload] 383 Bryan, D., "REsource LOcation And Discovery (RELOAD)", 384 draft-bryan-p2psip-reload-01 (work in progress), 385 July 2007. 387 [I-D.bryan-sipping-p2p] 388 Bryan, D., "A P2P Approach to SIP Registration and 389 Resource Location", draft-bryan-sipping-p2p-03 (work in 390 progress), October 2006. 392 [I-D.ietf-sip-outbound] 393 Jennings, C. and R. Mahy, "Managing Client Initiated 394 Connections in the Session Initiation Protocol (SIP)", 395 draft-ietf-sip-outbound-10 (work in progress), July 2007. 397 [I-D.ietf-sip-sips] 398 Audet, F., "The use of the SIPS URI Scheme in the Session 399 Initiation Protocol (SIP)", draft-ietf-sip-sips-06 (work 400 in progress), August 2007. 402 [I-D.matthews-p2psip-bootstrap-mechanisms] 403 Cooper, E., "Bootstrap Mechanisms for P2PSIP", 404 draft-matthews-p2psip-bootstrap-mechanisms-00 (work in 405 progress), February 2007. 407 [I-D.matthews-p2psip-dsip-nat-traversal] 408 Cooper, E., "NAT Traversal for dSIP", 409 draft-matthews-p2psip-dsip-nat-traversal-00 (work in 410 progress), February 2007. 412 [I-D.matthews-p2psip-hip-hop] 413 Cooper, E., "A Distributed Transport Function in P2PSIP 414 using HIP for Multi-Hop Overlay Routing", 415 draft-matthews-p2psip-hip-hop-00 (work in progress), 416 June 2007. 418 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 419 Protocol", RFC 2327, April 1998. 421 Authors' Addresses 423 Bruce B. Lowekamp 424 SIPeerior; William & Mary 425 3000 Easter Circle 426 Williamsburg, VA 23188 427 USA 429 Phone: +1 757 565 0101 430 Email: lowekamp@sipeerior.com 432 David A. Bryan 433 SIPeerior Technologies, Inc. 434 3000 Easter Circle 435 Williamsburg, VA 23188 436 USA 438 Phone: +1 757 565 0101 439 Email: dbryan@sipeerior.com 441 Full Copyright Statement 443 Copyright (C) The IETF Trust (2007). 445 This document is subject to the rights, licenses and restrictions 446 contained in BCP 78, and except as set forth therein, the authors 447 retain all their rights. 449 This document and the information contained herein are provided on an 450 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 451 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 452 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 453 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 454 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 457 Intellectual Property 459 The IETF takes no position regarding the validity or scope of any 460 Intellectual Property Rights or other rights that might be claimed to 461 pertain to the implementation or use of the technology described in 462 this document or the extent to which any license under such rights 463 might or might not be available; nor does it represent that it has 464 made any independent effort to identify any such rights. Information 465 on the procedures with respect to rights in RFC documents can be 466 found in BCP 78 and BCP 79. 468 Copies of IPR disclosures made to the IETF Secretariat and any 469 assurances of licenses to be made available, or the result of an 470 attempt made to obtain a general license or permission for the use of 471 such proprietary rights by implementers or users of this 472 specification can be obtained from the IETF on-line IPR repository at 473 http://www.ietf.org/ipr. 475 The IETF invites any interested party to bring to its attention any 476 copyrights, patents or patent applications, or other proprietary 477 rights that may cover technology that may be required to implement 478 this standard. Please address the information to the IETF at 479 ietf-ipr@ietf.org. 481 Acknowledgment 483 Funding for the RFC Editor function is provided by the IETF 484 Administrative Support Activity (IASA).