idnits 2.17.00 (12 Aug 2021) /tmp/idnits38541/draft-martin-nsis-nslp-natfw-sip-01.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 549), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 19, 2004) is 6515 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '2' is defined on line 467, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 476, but no explicit reference was found in the text == Outdated reference: draft-ietf-nsis-threats has been published as RFC 4081 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-threats (ref. '1') -- No information found for draft-martin-nsis-nslp-natfw-security - is the name correct? == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group M. Martin 3 Internet-Draft M. Brunner 4 Expires: January 17, 2005 M. Stiemerling 5 NEC 6 July 19, 2004 8 SIP NSIS Interactions for NAT/Firewall Traversal 9 draft-martin-nsis-nslp-natfw-sip-01 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 17, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 The NSIS NAT/FW NSLP provides traversal facilities for other 45 application layer protocols. This document describes the 46 interactions between SIP and NSIS signaling, to enable two NSIS aware 47 SIP end applications to communicate normally through a network of 48 NSIS Aware nodes, in a variety of NAT topologies. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 4 56 3. NSIS Signaling for the Caller behind a NAT case . . . . . . . 6 58 4. NSIS Signaling for the Callee behind the NAT case . . . . . . 8 60 5. NSIS Signaling for the Caller and the Callee behind a NAT 61 case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 69 8.2 Informative References . . . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . . 17 75 1. Introduction 77 The NSIS NAT/FW NSLP allows other application layer protocols to 78 establish tunnels through aribtrarily complex NAT and Firewall 79 network deployments. This means the applications themselves have to 80 know NSIS and its abilities, in order to request such tunnels at the 81 appropiate time, for the appropiate flows. 83 In the case of SIP, several parameters are to be taken into 84 consideration. The nature of the SIP signaling flow results in 85 precise slots where NSIS signaling should take place. This good 86 timing will allow us to minimize the creation of useless pinholes and 87 reduce the waiting times, both before and after the receiver has 88 accepted the SIP call. 90 This draft discusses the necessary interleaving between the SIP and 91 NSIS Signaling messages, in a combination of network topologies, 92 based on the presence of Middleboxes along the data path. 94 The draft is meant as a usage recommendation. As such, it starts 95 with a description of the problems, and a case by case solution 96 analysis, ended with a comparison of the obtained results and a final 97 flow recommendation 99 2. Problem Description 101 Figure 1 shows a typical network scenario. The Caller, from now on, 102 A, sits behind a NAT, with private IP 1, and has NAT as a gateway, 103 through the private address 2. The NAT has a public interface, with 104 address 3, and B (from now on, the Callee) awaits the call using the 105 public IP 4. Note how addresses prefixed with * (*1, *2) denote 106 private addresses which can not be reached from the internet unless a 107 NAT binding state is installed in the NAT. CA represents the instant 108 in which B accepts the call. 110 A(*1) (*2)NAT(3) B(4) 111 | | | 112 | #1 SIP INVITE | | 113 +-------------------->| | 114 | |----------------->| 115 | | | 116 | | #2 SIP Ringing | 117 | |<-----------------+ 118 |<--------------------| | 119 | | | 120 | | #3 SIP OK |<-CA 121 | |<-----------------+ 122 |<--------------------| | 123 | | | 124 | #4 SIP ACK | | 125 +-------------------->| | 126 | |----------------->| 127 | | | 128 | | | 129 |=====================| #5 DATA A->B | 130 | |=================>| 131 | | | 132 | | #6 DATA B->A | 133 | | ?<=============| 134 | | | 136 Figure 1: SIP signaling without NSIS 138 The message flow is described now using the message numbers in the 139 figure. The syntax "(U:V->X:Y): message" denotes a message from 140 address U (or box U), port V, towards address X (or box X), port Y, 141 with the literarily translated meaning "message" 143 #1 SIP INVITE (A:? -> B:SIP): I await data on *1, port x 144 This packet contains the information regarding what ports A will 145 expect to receive data on. Notice that the packet is being sent to 146 B, a public IP, with listening information regarding *1, a private IP 147 address. Notice also that A sends a packet from *1 towards 4, but it 148 is intercepted by the NAT, which changes the original address *1 for 149 3, and remembers the connection to reroute returning packets. 151 #2 SIP Ringing (B:SIP -> 2:?): Ringing B's phone 152 The ringing simply inplies that there's something SIP aware on B, and 153 that it's ringing B's phone. Notice that, from B's point of view, 154 the packet came from 2, and not from *1, and so, that's where it will 155 send it's reply. Still, that's the IP layer. The SIP layer will 156 still think that the adta must be sent to *1. When the packet 157 reaches 2, the NAT will remember the binding and change the 158 destination address back to *1. It will then forward the packet back 159 to *1. 161 #3 SIP OK (B:SIP -> 2:?): Call accepted, I listen on 4:y 162 This OK means that the user accepted the call. It also informs A on 163 where to send his data: towards 4:y. Note that now 4 is a public 164 address, so both the ip header address (4) and the application layer 165 address (also 4) are reachable. 167 4# SIP ACK (A:? -> B:SIP): All is fine, start transmitting. 168 ACK means the ports are accepted and the call can start in the 169 slected data ports on both sides. 171 5# DATA (A:? -> B:y) and 6# DATA (B:? -> *1:x): Voice,image, video.. 172 This is the actual data being transmited. It is sent to the 173 addresseses specified in packets numer #1 abd #3, which means B is 174 trying to connect to a private address in #6. Either #6 will not be 175 routable to its destination, or will be sent to the private address, 176 but in B's private network. Either way, #5 succeeds but #6 never 177 arrives. 179 This simple example shows how the presence of a NAT breaks the data 180 flow and prevents SIP initiated sessions to succeed. Had the NAT 181 been on the receiver's side, we would not have known where to send 182 #1, as we would not know B's public address withouth the mediation of 183 a proxy. Still, even in the case of using a proxy, SIP does not 184 currently cover this situation. 186 3. NSIS Signaling for the Caller behind a NAT case 188 This section shows how the NAT/FW traversal NSLP can be used to 189 enable communications in the problem scenario of Section 2. 191 The following message flow shows the SIP-NSIS Interactions: 193 A(*1) (*2)NAT(3) B(4) 194 | | | 195 | #1 NSIS REA | | 196 +-------------------->| | 197 | #2 NSIS RETADDR | | 198 |<--------------------+ | 199 | | | 200 | #3 SIP INVITE | | 201 +-------------------->| | 202 | +----------------->| 203 | | | 204 | | #4 SIP Ringing | 205 | |<-----------------+ 206 |<--------------------+ | 207 | | #5 NSIS CREATE |<-CA 208 | |<-----------------+ 209 |<--------------------+ #6 SIP OK | 210 | |<-----------------+ 211 |<--------------------+ | 212 | | | 213 | #7 NSIS Create | | 214 |-------------------->| | 215 | |----------------->| 216 | #8 SIP ACK | | 217 +-------------------->| | 218 | +----------------->| 219 | | | 220 |====================>| #9 DATA A->B | 221 | |=================>| 222 | | | 223 | | #10 DATA NAT<-B | 224 | #10 DATA A<-B |<=================| 225 |<====================| | 226 | | | 228 Figure 2: Caller behind a NAT 230 Because A wants to call B, it first sends a RESERVE-EXTERNAL-ADDRESS 231 (REA) NSIS message. If there is a NAT, as is the case, it will 232 reply with the allocated public address, using am NSIS RETADDR 233 RESPONSE message. If there was no NAT, A continues its normal 234 operation after a timeout. Normal SIP behavior follows, except that 235 the source address in the SIP INVITE packet has been changed by the 236 one provided by the NSIS RETADDR packet. 238 When B receives the SIP INVITE message, it assumes there might be 239 middleboxes in the path, so it tries to open a path by sending an 240 NSIS Create message to the address provided in the SIP INVITE which 241 is were it will eventually send the voice stream. 243 The NSIS CREATE message reaches the NAT and activates the state that 244 the NSIS RESERVE previously provided, and the message is forwarded 245 inside, in case there where other middleboxes that needed to be open. 246 At this stage, B might or might not want to wait for the NSIS success 247 RESPONSE message, issued by A as a reply to the NSIS CREATE. This 248 message is not shown in the figure. 250 Once the path has been created, normal SIP behavior follows, and the 251 communication succeeds. 253 This scheme scales to several middleboxes, since the NSIS REA 254 messages reserve states in all the middleboxes until an edge NAT is 255 encountered. 257 4. NSIS Signaling for the Callee behind the NAT case 259 For the callee to be able to receive calls, there has to be a SIP 260 Proxy that forwards the signaling messages from the public internet 261 into the private network. For this reason, it is a safe assumption 262 that A and B will be able to communicate signaling messages 263 independently of the scenario. 265 With that in mind, the scenario becomes practically symetrical to the 266 one with the caller behind a NAT. The message flow follows. Notice 267 that SIP messages ignore proxies, since they are routed through the 268 proxy, not shown in the diagram. 270 A(1) (2)NAT(*3) B(*4) 271 | | | 272 | #1 SIP INVITE | | 273 |---------------------o----------------->| 274 | | | 275 | | #2 SIP Ringing | 276 |<--------------------o------------------| 277 | | |<-CA 278 | | | 279 | | #3 NSIS REA | 280 | |<-----------------| 281 | | #4 NSIS RETADDR | 282 | |----------------->| 283 | | #5 NSIS CREATE | 284 | |<-----------------+ 285 |<--------------------+ | 286 | | #6 SIP OK | 287 |<--------------------o------------------| 288 | | | 289 | #7 NSIS CREATE | | 290 |-------------------->| | 291 | |----------------->| 292 | | | 293 | #8 SIP ACK | | 294 |<--------------------o------------------| 295 | | | 296 | #9 DATA | | 297 |====================>| | 298 | |=================>| 299 | | | 300 | | #8 DATA | 301 | |<=================| 302 |<====================| | 303 | | | 304 Figure 3: Callee behind a NAT 306 5. NSIS Signaling for the Caller and the Callee behind a NAT case 308 Even though this case seems similar, or a simmple summation at least, 309 of the two previous cases, there are some specific issues that need 310 to be looked at carefully. We will start with the message flow, as a 311 prior step to the discussion. Again, notice that the SIP messages 312 reach A and B thanks to the SIP proxy that has to be installed at the 313 edge of the network. This proxy is not shown in the figure. 315 A(*1) (*2)NAT(3) (4)NAT(5*) B(*5) 316 | | | | 317 | #1 NSIS REA | | | 318 |-------------------->| | | 319 | #2 NSIS RETADDR | | | 320 |<--------------------| | | 321 | | | | 322 | #3 SIP INVITE | | | 323 |---------------------o------------------o---------------->| 324 | | | | 325 | | #4 SIP Ringing | | 326 |<--------------------o------------------o-----------------| 327 | | | |<-CA 328 | | | #5 NSIS REA | 329 | | |<----------------| 330 | | | #6 NSIS RETADDR | 331 | | |---------------->| 332 | | | #7 NSIS CREATE | 333 | | |<----------------| 334 | |<-----------------| | 335 |<--------------------| | | 336 | | | #9 SIP OK | 337 |<--------------------o------------------o-----------------| 338 | | | | 339 | #10 NSIS CREATE | | | 340 |-------------------->| | | 341 | |----------------->| | 342 | | |---------------->| 343 | #11 SIP ACK | | | 344 |---------------------o------------------o---------------->| 345 | | | | 346 | #12 DATA | | | 347 |====================>| | | 348 | |=================>| | 349 | | |================>| 350 | | | #13 DATA | 351 | | |<================| 352 | |<=================| | 353 |<====================| | | 354 | | | | 356 Figure 4: Caller and Callee behind a NAT 358 Everything works as expected, but there is a hidden pitfall in the 359 above diagram: When A first makes its reservation, it does not know 360 where to send that packet. If the objective is to get out of the 361 NAT, any public IP would do, but that might lead to route 362 optimization problems in certain scenarios 364 Let's consider the scenario in Figure 5, where A is in a multihomed 365 network that can access the internet through different NATs: 367 +--------------+ 368 | Remote Proxy | 369 | Server | 370 +--------------+ 371 | | 372 | | 373 ******************* | | ******************** 374 * Network A * | | * Network B * 375 * +-------+ | | +-------+ * 376 * /---->| Proxy |----/ \-->| Proxy |---\ * 377 +------+ +---+ +-------+ +-------+ +---+ * 378 | NAT2 | | A | * * | B | * 379 +------+ +---+ +-------+ +-------+ +---+ * 380 * \=====| NAT1 |<============| NAT1' |===/ * 381 * +-------+ +-------+ * 382 * * * * 383 ******************* ********************* 385 ---- : SIP Signalization 386 ==== : NSIS Signaling and Data transfer 388 Figure 5: Optimization scenario 390 The figure shows the route that the SIP packets will follow, through 391 the SIP proxies, and the optimal route for the DATA arriving at A, 392 which is from NAT1' to NAT. This would be the case if the NSIS REA 393 message had originally gone out NAT1, because the public address 394 would be allocated there. 396 On the other hand, if the NSIS REA mesage went out NAT2, the 397 communication paths would become: 399 +--------------+ 400 | Remote Proxy | 401 | Server | 402 +--------------+ 403 | | 404 | | 405 ******************** | | ********************* 406 * * | | * * 407 * +-------+ | | +-------+ * 408 * /-----| Proxy |--/ \--->| Proxy |---\ * 409 +------+ +---+ +-------+ +-------+ +---+ +-------+ 410 | NAT2 |---| A | * * | B | | NAT2' | 411 +------+ +---+ +-------+ +-------+ +---+ +-------+ 412 = * \=====| NAT1 | ====| NAT1' |===/ * 413 = * +-------+ = +-------+ * 414 = * * = * * 415 = ******************** = ********************** 416 = = 417 ==================================== 419 ---- : SIP Signalization 420 ==== : NSIS Signaling and Data transfer 422 Figure 6: Sub optimal route 424 This comes to show that the "Blind shot" that A performs when first 425 reserving the address has a severe impact on the choosen path in 426 multihomed scenarios, and might lead to longer or less efficient 427 routes. 429 If we assume that routers are able to calculate the most optimal 430 routes, then the solution is in sending the NSIS REA message on the 431 path to B, but that is unkown at that moment. Still, we do have the 432 SIP Proxy of B. Note that this would be the first Via Header in the 433 SIP OK message, since there is no way we can communicate with B if 434 there is not a SIP Proxy in its network. 436 Thus, by pointing the NSIS REA message towards B, we have a pretty 437 good assurance that the optimal path (as calculated by the routers) 438 will be chosen. 440 6. Conclusions 442 This draft proposes the mechanisms required to use SIP with NSIS, in 443 order to enable the communication through scenarios with obstructing 444 Middleboxes. 446 Although further analisys is still required to fine tune this 447 interactions, a first valuable result arises: the use of the SIP 448 Proxy as a target for NSIS REA messages is very likely to aid in the 449 coice of the optimal route in the multihomed scenario. 451 7. Security Considerations 453 The NAT/Firewall traversal NSLP deals with very security sensitive 454 issues, and a good security infrastructure is required. An 455 evaluation of the possible threads can be found in [1] and a securit 456 proposal is available at [3]. 458 8. References 460 8.1 Normative References 462 [1] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 463 DRAFT draft-ietf-nsis-threats-05.txt, June 2004. 465 8.2 Informative References 467 [2] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. 468 Schulzrinne, "NSIS Authentication, Authorization and Accounting 469 Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress), 470 March 2003. 472 [3] Martin, M., Brunner, M., Stiemerling, M., Girao, J. and C. Aoun, 473 "A NAT/Firewall NSLP security infrastructure", DRAFT 474 draft-martin-nsis-nslp-natfw-security-01.txt, February 2004. 476 [4] Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "A NAT/ 477 Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT 478 draft-ietf-nsis-nslp-natfw-03.txt, July 2004. 480 Authors' Addresses 482 Miquel Martin 483 Network Laboratories, NEC Europe Ltd. 484 Kurfuersten-Anlage 36 485 Heidelberg 69115 486 Germany 488 Phone: +49 (0) 6221 905 11 16 489 EMail: miquel.martin@netlab.nec.de 490 URI: 492 Marcus Brunner 493 Network Laboratories, NEC Europe Ltd. 494 Kurfuersten-Anlage 36 495 Heidelberg 69115 496 Germany 498 Phone: +49 (0) 6221 905 11 29 499 EMail: brunner@ccrle.nec.de 500 URI: http://www.brubers.org/marcus 501 Martin Stiemerling 502 Network Laboratories, NEC Europe Ltd. 503 Kurfuersten-Anlage 36 504 Heidelberg 69115 505 Germany 507 Phone: +49 (0) 6221 905 11 13 508 EMail: stiemerling@netlab.nec.de 509 URI: 511 Intellectual Property Statement 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Disclaimer of Validity 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 540 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 541 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 542 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Copyright Statement 547 Copyright (C) The Internet Society (2004). This document is subject 548 to the rights, licenses and restrictions contained in BCP 78, and 549 except as set forth therein, the authors retain all their rights. 551 Acknowledgment 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.