idnits 2.17.1 draft-ietf-behave-sctpnat-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC0793], [RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 28 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 39 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (December 30, 2010) is 4859 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Initiate-Tag' is mentioned on line 361, but not defined == Unused Reference: 'RFC1918' is defined on line 1041, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Huawei 4 Intended status: BCP M. Tuexen 5 Expires: July 3, 2011 I. Ruengeler 6 Muenster Univ. of Applied Sciences 7 December 30, 2010 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 draft-ietf-behave-sctpnat-04.txt 12 Abstract 14 Stream Control Transmission Protocol [RFC4960] provides a reliable 15 communications channel between two end-hosts in many ways similar to 16 TCP [RFC0793]. With the widespread deployment of Network Address 17 Translators (NAT), specialized code has been added to NAT for TCP 18 that allows multiple hosts to reside behind a NAT and yet use only a 19 single globally unique IPv4 address, even when two hosts (behind a 20 NAT) choose the same port numbers for their connection. This 21 additional code is sometimes classified as Network Address and Port 22 Translation or NAPT. To date, specialized code for SCTP has NOT yet 23 been added to most NATs so that only pure NAT is available. The end 24 result of this is that only one SCTP capable host can be behind a 25 NAT. 27 This document describes an SCTP specific variant of NAT which 28 provides similar features of NAPT in the single point and multi-point 29 traversal scenario. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 3, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 4 68 4.1. Single Point Traversal . . . . . . . . . . . . . . . . . . 4 69 4.2. Multi Point Traversal . . . . . . . . . . . . . . . . . . 5 70 5. Limitations of classical NAPT for SCTP . . . . . . . . . . . . 6 71 6. The SCTP specific variant of NAT . . . . . . . . . . . . . . . 6 72 7. Nat to SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Handling of fragmented SCTP packets . . . . . . . . . . . . . 10 74 9. Simplification for small NATs . . . . . . . . . . . . . . . . 10 75 10. Various examples of NAT traversals . . . . . . . . . . . . . . 10 76 10.1. Single-homed client to single-homed server . . . . . . . . 10 77 10.2. Single-homed client to multi-homed server . . . . . . . . 13 78 10.3. Multihomed client and server . . . . . . . . . . . . . . . 15 79 10.4. NAT loses its state . . . . . . . . . . . . . . . . . . . 18 80 10.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . . 20 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 12. Security considerations . . . . . . . . . . . . . . . . . . . 24 83 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 86 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 91 Stream Control Transmission Protocol [RFC4960] provides a reliable 92 communications channel between two end-hosts in many ways similar to 93 TCP [RFC0793]. With the widespread deployment of Network Address 94 Translators (NAT), specialized code has been added to NAT for TCP 95 that allows multiple hosts to reside behind a NAT and yet use only a 96 single globally unique IPv4 address, even when two hosts (behind a 97 NAT) choose the same port numbers for their connection. This 98 additional code is sometimes classified as Network Address and Port 99 Translation or NAPT. To date, specialized code for SCTP has NOT yet 100 been added to most NATs so that only true NAT is available. The end 101 result of this is that only one SCTP capable host can be behind a 102 NAT. 104 This document proposes an SCTP specific variant NAT that provides the 105 NAPT functionality without changing SCTP port numbers. The authors 106 feel it is possible and desirable to make these changes for a number 107 of reasons. 109 o It is desirable for SCTP internal end-hosts on multiple platforms 110 to be able to share a NAT's public IP address, much as TCP does 111 today. 113 o If a NAT does not need to change any data within an SCTP packet it 114 will reduce the processing burden of NAT'ing SCTP by NOT needing 115 to execute the CRC32c checksum required by SCTP. 117 o Not having to touch the IP payload makes the processing of ICMP 118 messages in NATs easier. 120 2. Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Terminology 128 For this discussion we will use several terms, which we will define 129 and point out in a figure. 131 o Private-Address (Priv-Addr) - The private address that is known to 132 the internal host. 134 o Internal-Port (Int-Port) - The port number that is in use by the 135 host holding the Private-Address. 137 o Internal-VTag (Int-VTag) - The Verification Tag that the internal 138 host has chosen for its communication. The VTag is a unique 32 139 bit tag that must accompany any incoming SCTP packet for this 140 association to the Private-Address. 142 o External-Address (Ext-Addr) - The address that an internal host is 143 attempting to contact. 145 o External-Port (Ext-Port) - The port number of the peer process at 146 the External-Address. 148 o External-VTag (Ext-VTag) - The Verification Tag that the host 149 holding the External-Address has chosen for its communication. 150 The VTag is a unique 32 bit tag that must accompany any incoming 151 SCTP packet for this association to the External-Address. 153 o Public-Address (Pub-Addr) - The public address assigned to the NAT 154 box which it uses as a source address when sending packets towards 155 the External-Address. 157 Internal Network | External Network 158 | 159 Private | Public External 160 +---------+ Address | Address /--\/--\ Address +---------+ 161 | SCTP | +-----+ / \ | SCTP | 162 |end point|==========| NAT |======= | Internet | ========== |end point| 163 | A | +-----+ \ / | B | 164 +---------+ Internal | \--/\--/ External +---------+ 165 Internal Port | Port External 166 VTag | VTag 168 4. SCTP NAT Traversal Scenarios 170 This section defines the notion of single and multi-point NAT 171 traversal. 173 4.1. Single Point Traversal 175 In this case, all packets in the SCTP association go through a single 176 NAT, as shown below: 178 Internal Network | External Network 179 | 180 +---------+ | /--\/--\ +---------+ 181 | SCTP | +-----+ / \ | SCTP | 182 |end point|==========| NAT |========= | Internet | =========|end point| 183 | A | +-----+ \ / | B | 184 +---------+ | \--/\--/ +---------+ 185 | 187 A variation of this case is shown below, i.e., multiple NATs in a 188 single path: 190 Internal | External :: Internal | External 191 | :: | 192 +---------+ | :: | /--\/--\ +---------+ 193 | SCTP | +-----+ :: +-----+ / \ | SCTP | 194 |end point|===| NAT |=======::=======| NAT |==| Internet |==|end point| 195 | A | +-----+ :: +-----+ \ / | B | 196 +---------+ | :: | \--/\--/ +---------+ 197 | :: | 199 In this single point traversal scenario, we must acknowledge that 200 while one of the main benefits of SCTP multi-homing is redundant 201 paths, the NAT function represents a single point of failure in the 202 path of the SCTP multi-home association. However, the rest of the 203 path may still benefit from path diversity provided by SCTP multi- 204 homing. 206 The two SCTP endpoints in this case can be either single-homed or 207 multi-homed. However, the important thing is that the NAT (or NATs) 208 in this case sees ALL the packets of the SCTP association. 210 4.2. Multi Point Traversal 212 This case involves multiple NATs and each NAT only sees some of the 213 packets in the SCTP association. An example is shown below: 215 Internal | External 216 +------+ /---\/---\ 217 +---------+ /=======|NAT A |=========\ / \ +---------+ 218 | SCTP | / +------+ \/ \ | SCTP | 219 |end point|/ ... | Internet |=====|end point| 220 | A |\ \ / | B | 221 +---------+ \ +------+ / \ / +---------+ 222 \=======|NAT B |=========/ \---\/---/ 223 +------+ 224 | 226 This case does NOT apply to a single-homed SCTP association (i.e., 227 BOTH endpoints in the association use only one IP address). The 228 advantage here is that the existence of multiple NAT traversal points 229 can preserve the path diversity of a multi-homed association for the 230 entire path. This in turn can improve the robustness of the 231 communication. 233 5. Limitations of classical NAPT for SCTP 235 Using classical NAPT may result in changing one of the SCTP port 236 numbers during the processing which requires the recomputation of the 237 transport layer checksum. Whereas for UDP and TCP this can be done 238 very efficently, for SCTP the checksum (CRC32c) over the entire 239 packet needs to be recomputed. This would add considerable to the 240 NAT computational burden, however hardware support may mitigate this 241 in some implementations. 243 An SCTP endpoint may have multiple addresses but only has a single 244 port number. To make multipoint travesal work, all the NATs involved 245 must recognize the packets they see as belonging to the same SCTP 246 association and perform port number translation in a consistent way. 247 One possible way of doing this is to use pre-defined table of ports 248 and addresses configured within each NAT. Other mechanisms could 249 make use of NAT to NAT communcation. Such mechanisms are considered 250 by the authors to be undeployable on a wide scale base and thus not a 251 recommended solution. Therefore the SCTP variant of NAT has been 252 developed. 254 6. The SCTP specific variant of NAT 256 In this section we assume that we have multiple SCTP capable hosts 257 behind a NAT which has one Public-Address. Furthermore we are 258 focusing in this section on the single point traversal scenario. 260 The modification of SCTP packets sent to the public Internet is easy. 261 The source address of the packet has to be replaced with the Public- 262 Address. It may also be necessary to establish some state in the NAT 263 box to handle incoming packets, which is discussed later. 265 For SCTP packets coming from the public Internet the destination 266 address of the packets has to be replaced with the Private-Address of 267 the host the packet has to be delivered to. The lookup of the 268 Private-Address is based on the External-VTag, External-Port, 269 External-Address, Internal-VTag and the Internal-Port. 271 For the SCTP NAT processing the NAT box has to maintain a table of 272 Internal-VTag, Internal-Port, Private-Address, External-VTag, 273 External-Port and External-Address. An entry in that table is called 274 a NAT state control block. The function Create() obtains the just 275 mentioned parameters and returns a NAT-State control block. 277 The processing of outgoing SCTP packets containing an INIT-chunk is 278 described in the following figure. The scenario shown is valid for 279 all message flows in this section. 281 /--\/--\ 282 +--------+ +-----+ / \ +--------+ 283 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 284 +--------+ +-----+ \ / +--------+ 285 \--/\---/ 287 INIT[Initiate-Tag] 288 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 289 Ext-VTag=0 291 Create(Initiate-Tag,Internal-Port,Private-Address, 292 0,External-Port,External-Address) 293 Returns(NAT-State control block) 295 Translate To: 297 INIT[Initiate-Tag] 298 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 299 Ext-VTag=0 301 It should be noted that normally a NAT control block will be created. 302 However, it is possible that there is already a NAT control block 303 with the same External-Address, External-Port, Internal-Port, and 304 Internal-VTag but different Private-Address. In this case the INIT 305 SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the 306 SCTP host with the M-Bit set and an appropriate error cause [please 307 see xxx-tsvwg-document-xx for the format]. 309 It is also possible that a connection to External-Address and 310 External-Port exists without anInternal-VTag conflict but the 311 External-Address does not support the DISABLE_RESTART feature (noted 312 in the NAT control block when the prior connection was established). 313 In such a case the INIT SHOULD be dropped by the NAT and an ABORT 314 SHOULD be sent back to the SCTP host with the M-Bit set and an 315 appropriate error cause [please see xxx-tsvwg-document-xx for the 316 format]. 318 The processing of outgoing SCTP packets containing no INIT-chunk is 319 described in the following figure. 321 /--\/--\ 322 +--------+ +-----+ / \ +--------+ 323 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 324 +--------+ +-----+ \ / +--------+ 325 \--/\---/ 327 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 328 Ext-VTag 330 Translate To: 332 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 333 Ext-VTag 335 The processing of incoming SCTP packets containing INIT-ACK chunks is 336 described in the following figure. The Lookup() function getting as 337 input the Internal-VTag, Internal-Port, External-VTag (=0), External- 338 Port, and External-Address, returns the corresponding entry of the 339 NAT table and updates the External-VTag by substituting it with the 340 value of the Initiate-Tag of the INIT-ACK chunk. The wildcard 341 character signifies that the parameter's value is not considered in 342 the Lookup() function or changed in the Update() function, 343 respectively. 345 /--\/--\ 346 +--------+ +-----+ / \ +--------+ 347 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 348 +--------+ +-----+ \ / +--------+ 349 \--/\---/ 351 INIT-ACK[Initiate-Tag] 352 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 353 Int-VTag 355 Lookup(Internal-VTag,Internal-Port,*, 356 0,External-Port,External-Address) 357 Update(*, *, *, Initiate-Tag, *, *) 359 Returns(NAT-State control block containing Private-Address) 361 INIT-ACK[Initiate-Tag] 362 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 363 Int-VTag 365 In the case Lookup fails, the SCTP packet is dropped. The Update 366 routine inserts the External-VTag (the Initiate-Tag of the INIT-ACK 367 chunk) in the NAT state control block. 369 The processing of incoming SCTP packets containing an ABORT or 370 SHUTDOWN-COMPLETE chunk with the T-Bit set is described in the 371 following figure. 373 /--\/--\ 374 +--------+ +-----+ / \ +--------+ 375 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 376 +--------+ +-----+ \ / +--------+ 377 \--/\---/ 379 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 380 Ext-VTag 382 Lookup(0, Internal-Port, *,External-VTag, 383 External-Port, External-Address) 385 Returns(NAT-State control block containing Private-Address) 387 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 388 Ext-VTag 390 The processing of other incoming SCTP packets is described in the 391 following figure. 393 /--\/--\ 394 +--------+ +-----+ / \ +--------+ 395 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 396 +--------+ +-----+ \ / +--------+ 397 \--/\---/ 399 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 400 Int-VTag 402 Lookup(Internal-VTag, Internal-Port, *, 403 *, External-Port, External-Address) 405 Returns(NAT-State control block containing Local-Address) 407 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 408 Int-VTag 410 For an incoming packet containing an INIT-chunk a table lookup is 411 made only based on the addresses and port numbers. If an entry with 412 an External-VTag of zero is found, it is considered a match and the 413 External-VTag is updated. 415 This allows the handling of INIT-collision through NAT. 417 7. Nat to SCTP 419 This document at various places discusses the sending of specialized 420 SCTP chunks (e.g. an ABORT with M bit set). These chunks and 421 proceedures are not defined in this document, but instead are defined 422 in [xxxxx]. The NAT implementor should refer to [xxxx] for detailed 423 descriptions of packet format and procedures. 425 8. Handling of fragmented SCTP packets 427 A NAT box MUST support IP reassembly of received fragmented SCTP 428 packets. The fragments may arrive in any order. 430 When an SCTP packet has to be fragmented by the NAT box and the IP 431 header forbids fragmentation a corresponding ICMP packet SHOULD be 432 sent. 434 9. Simplification for small NATs 436 Small NAT boxes, i.e. NAT boxes which only have to support a small 437 number of concurrent SCTP associations, MAY not take the external 438 address into account when processing packets. Therefore the 439 External-Address could also be removed from the NAT table. 441 This simplification may make implementing a NAT box easier, however, 442 the collision probability is higher than using a mapping which takes 443 the external address into account. 445 10. Various examples of NAT traversals 447 10.1. Single-homed client to single-homed server 449 The internal client starts the association with the external server 450 via a four-way-handshake. Host A starts by sending an INIT chunk. 452 /--\/--\ 453 +--------+ +-----+ / \ +--------+ 454 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 455 +--------+ +-----+ \ / +--------+ 456 \--/\---/ 457 +---------+--------+-----------+----------+--------+-----------+ 458 NAT | Int | Int | Priv | Ext | Ext | Ext | 459 | VTag | Port | Addr | VTag | Port | Addr | 460 +---------+--------+--- -------+----------+--------+-----------+ 462 INIT[Initiate-Tag = 1234] 463 10.0.0.1:1 ------> 100.0.0.1:2 464 Ext-VTtag = 0 466 A NAT entry is created, the source address is substituted and the 467 packet is sent on: 469 NAT creates entry: 470 +---------+--------+-----------+----------+--------+-----------+ 471 NAT | Int | Int | Priv | Ext | Ext | Ext | 472 | VTag | Port | Addr | VTag | Port | Addr | 473 +---------+--------+-----------+----------+--------+-----------+ 474 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 475 +---------+--------+-----------+----------+--------+-----------+ 477 INIT[Initiate-Tag = 1234] 478 101.0.0.1:1 ---------------------------> 100.0.0.1:2 479 Ext-VTtag = 0 481 Host B receives the INIT and sends an INIT-ACK with the NAT's 482 external address as destination address. 484 /--\/--\ 485 +--------+ +-----+ / \ +--------+ 486 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 487 +--------+ +-----+ \ / +--------+ 488 \--/\---/ 490 INIT-ACK[Initiate-Tag = 5678] 491 101.0.0.1:1 <--------------------------- 100.0.0.1:2 492 Int-VTag = 1234 494 NAT updates entry: 495 +---------+--------+-----------+----------+--------+-----------+ 496 NAT | Int | Int | Priv | Ext | Ext | Ext | 497 | VTag | Port | Addr | VTag | Port | Addr | 498 +---------+--------+-----------+----------+--------+-----------+ 499 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 500 +---------+--------+-----------+----------+--------+-----------+ 502 INIT-ACK[Initiate-Tag = 5678] 503 10.0.0.1:1 <------ 100.0.0.1:2 504 Int-VTag = 1234 506 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 507 ACK. 509 /--\/--\ 510 +--------+ +-----+ / \ +--------+ 511 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 512 +--------+ +-----+ \ / +--------+ 513 \--/\---/ 515 COOKIE-ECHO 516 10.0.0.1:1 ------> 100.0.0.1:2 517 Ext-VTag = 5678 519 COOKIE-ECHO 520 101.0.0.1:1 ---------------------------> 100.0.0.1:2 521 Ext-VTag = 5678 523 COOKIE-ACK 524 101.0.0.1:1 <--------------------------- 100.0.0.1:2 525 Int-VTag = 1234 527 COOKIE-ACK 528 10.0.0.1:1 <------ 100.0.0.1:2 529 Int-VTag = 1234 531 10.2. Single-homed client to multi-homed server 533 The internal client is single-homed whereas the external server is 534 multi-homed. The client (Host A) sends an INIT like in the single- 535 homed case. 537 +--------+ 538 /--\/--\ /-|Router 1| \ 539 +------+ +-----+ / \ / +--------+ \ +------+ 540 | Host | <------> | NAT | <-> | Internet | == ==| Host | 541 | A | +-----+ \ / \ +--------+ / | B | 542 +------+ \--/\--/ \-|Router 2|-/ +------+ 543 +--------+ 545 +---------+--------+-----------+----------+--------+-----------+ 546 NAT | Int | Int | Priv | Ext | Ext | Ext | 547 | VTag | Port | Addr | VTag | Port | Addr | 548 +---------+--------+--- -------+----------+--------+-----------+ 550 INIT[Initiate-Tag = 1234] 551 10.0.0.1:1 ---> 100.0.0.1:2 552 Ext-VTag = 0 554 NAT creates entry: 556 +---------+--------+-----------+----------+--------+-----------+ 557 NAT | Int | Int | Priv | Ext | Ext | Ext | 558 | VTag | Port | Addr | VTag | Port | Addr | 559 +---------+--------+-----------+----------+--------+-----------+ 560 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 561 +---------+--------+-----------+----------+--------+-----------+ 563 INIT[Initiate-Tag = 1234] 564 101.0.0.1:1 ------------------------------> 100.0.0.1:2 565 Ext-VTag = 0 567 The server (Host B) includes its two addresses in the INIT-ACK chunk, 568 which results in two NAT entries. 570 +--------+ 571 /--\/--\ /-|Router 1| \ 572 +------+ +-----+ / \ / +--------+ \ +------+ 573 | Host | <------> | NAT | <-> | Internet | == ==| Host | 574 | A | +-----+ \ / \ +--------+ / | B | 575 +------+ \--/\--/ \-|Router 2|-/ +------+ 576 +--------+ 578 INIT-ACK[Initiate-tag = 5678, IP-Addr = 100.1.0.1] 579 101.0.0.1:1 <------------------------------ 100.0.0.1:2 580 Int-VTag = 1234 582 NAT updates first entry and creates entry for second address: 584 +---------+--------+-----------+----------+--------+-----------+ 585 NAT | Int | Int | Priv | Ext | Ext | Ext | 586 | VTag | Port | Addr | VTag | Port | Addr | 587 +---------+--------+-----------+----------+--------+-----------+ 588 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 589 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.1.0.1 | 590 +---------+--------+-----------+----------+--------+-----------+ 592 INIT-ACK[Initiate-Tag = 5678] 593 10.0.0.1:1 <--- 100.0.0.1:2 594 Int-VTag = 1234 596 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 597 ACK. 599 +--------+ 600 /--\/--\ /-|Router 1| \ 601 +------+ +-----+ / \ / +--------+ \ +------+ 602 | Host | <------> | NAT | <-> | Internet | == ==| Host | 603 | A | +-----+ \ / \ +--------+ / | B | 604 +------+ \--/\--/ \-|Router 2|-/ +------+ 605 +--------+ 607 COOKIE-ECHO 608 10.0.0.1:1 ---> 100.0.0.1:2 609 ExtVTag = 5678 611 COOKIE-ECHO 612 101.0.0.1:1 ------------------------------> 100.0.0.1:2 613 Ext-VTag = 5678 615 COOKIE-ACK 616 101.0.0.1:1 <------------------------------ 100.0.0.1:2 617 Int-VTag = 1234 619 COOKIE-ACK 620 10.0.0.1:1 <--- 100.0.0.1:2 621 Int-VTag = 1234 623 10.3. Multihomed client and server 625 The client (Host A) sends an INIT to the server (Host B), but does 626 not include the second address. 628 +-------+ 629 /--------| NAT 1 |--------\ /--\/--\ 630 +------+ / +-------+ \ / \ +--------+ 631 | Host |==== ====| Internet |====| Host B | 632 | A | \ +-------+ / \ / +--------+ 633 +------+ \--------| NAT 2 |--------/ \--/\--/ 634 +-------+ 636 +---------+--------+-----------+----------+--------+-----------+ 637 NAT 1 | Int | Int | Priv | Ext | Ext | Ext | 638 | VTag | Port | Addr | VTag | Port | Addr | 639 +---------+--------+--- -------+----------+--------+-----------+ 641 INIT[Initiate-Tag = 1234] 642 10.0.0.1:1 --------> 100.0.0.1:2 643 Ext-VTag = 0 645 NAT 1 creates entry: 647 +---------+--------+-----------+----------+--------+-----------+ 648 NAT 1 | Int | Int | Priv | Ext | Ext | Ext | 649 | VTag | Port | Addr | VTag | Port | Addr | 650 +---------+--------+-----------+----------+--------+-----------+ 651 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 652 +---------+--------+-----------+----------+--------+-----------+ 654 INIT[Initiate-Tag = 1234] 655 101.0.0.1:1 -------------------------> 100.0.0.1:2 656 ExtVTag = 0 658 Host B includes its second address in the INIT-ACK, which results in 659 two NAT entries in NAT 1. 661 +-------+ 662 /--------| NAT 1 |--------\ /--\/--\ 663 +------+ / +-------+ \ / \ +--------+ 664 | Host |==== ====| Internet |====| Host B | 665 | A | \ +-------+ / \ / +--------+ 666 +------+ \--------| NAT 2 |--------/ \--/\--/ 667 +-------+ 669 INIT-ACK[Initiate-Tag = 5678, IP-Addr = 100.1.0.1] 670 101.0.0.1:1 <------------------------- 100.0.0.1:2 671 Int-VTag = 1234 673 NAT 1 updates first entry and creates complete entry for second 674 address: 676 +---------+--------+-----------+----------+--------+-----------+ 677 NAT 1 | Int | Int | Priv | Ext | Ext | Ext | 678 | VTag | Port | Addr | VTag | Port | Addr | 679 +---------+--------+-----------+----------+--------+-----------+ 680 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 681 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.1.0.1 | 682 +---------+--------+-----------+----------+--------+-----------+ 684 INIT-ACK[Initiate-Tag = 5678] 685 10.0.0.1:1 <---------100.0.0.1:2 686 Int-VTag = 1234 688 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 689 ACK. 691 +-------+ 692 /--------| NAT 1 |--------\ /--\/--\ 693 +------+ / +-------+ \ / \ +--------+ 694 | Host |==== ====| Internet |====| Host B | 695 | A | \ +-------+ / \ / +--------+ 696 +------+ \--------| NAT 2 |--------/ \--/\--/ 697 +-------+ 699 COOKIE-ECHO 700 10.0.0.1:1 --------> 100.0.0.1:2 701 Ext-VTag = 5678 703 COOKIE-ECHO 704 101.0.0.1:1 ----------------------> 100.0.0.1:2 705 Ext-VTag = 5678 707 COOKIE-ACK 708 101.0.0.1:1 <---------------------- 100.0.0.1:2 709 Int-VTag = 1234 711 COOKIE-ACK 712 10.0.0.1:1 <------- 100.0.0.1:2 713 Int-VTag = 1234 715 Host A announces its second address in an ASCONF. The address 716 parameter contains an undefined address (0) to indicate that the 717 source address should be added. The lookup address pararmeter within 718 the ASCONF chunk will also contain the pair of Vtags (external and 719 internal) so that the NAT may populate its table completely with this 720 single packet. 722 +-------+ 723 /--------| NAT 1 |--------\ /--\/--\ 724 +------+ / +-------+ \ / \ +--------+ 725 | Host |==== ====| Internet |====| Host B | 726 | A | \ +-------+ / \ / +--------+ 727 +------+ \--------| NAT 2 |--------/ \--/\--/ 728 +-------+ 730 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] 731 10.1.0.1:1 --------> 100.1.0.1:2 732 Ext-VTag = 5678 734 NAT 2 creates complete entry: 736 +---------+--------+-----------+----------+--------+-----------+ 737 NAT 2 | Int | Int | Priv | Ext | Ext | Ext | 738 | VTag | Port | Addr | VTag | Port | Addr | 739 +---------+--------+-----------+----------+--------+-----------+ 740 | 1234 | 1 | 10.1.0.1 | 5678 | 2 | 100.1.0.1 | 741 +---------+--------+-----------+----------+--------+-----------+ 743 ASCONF [ADD-IP,Int-VTag=1234, Ext-VTag = 5678] 744 101.1.0.1:1 -------------------------> 100.1.0.1:2 745 Ext-VTag = 5678 747 ASCONF-ACK 748 101.1.0.1:1 <------------------------- 100.1.0.1:2 749 Int-VTag = 1234 751 ASCONF-ACK 752 10.1.0.1:1 <----- 100.1.0.1:2 753 Int-VTag = 1234 755 10.4. NAT loses its state 757 Assocation is already established between Host A and Host B, when the 758 NAT loses its state and obtains a new public address. Host A sends a 759 DATA chunk to Host B. 761 /--\/--\ 762 +--------+ +-----+ / \ +--------+ 763 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 764 +--------+ +-----+ \ / +--------+ 765 \--/\--/ 767 +---------+--------+-----------+----------+--------+-----------+ 768 NAT A | Int | Int | Priv | Ext | Ext | Ext | 769 | VTag | Port | Addr | VTag | Port | Addr | 770 +---------+--------+-----------+----------+--------+-----------+ 771 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 772 +---------+--------+-----------+----------+--------+-----------+ 774 DATA 775 10.0.0.1:1 ----------> 100.0.0.1:2 776 Ext-VTag = 5678 778 The NAT box cannot find entry for the association. It sends ERROR 779 message with the M-Bit set and the cause "NAT state missing". 781 /--\/--\ 782 +--------+ +-----+ / \ +--------+ 783 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 784 +--------+ +-----+ \ / +--------+ 785 \--/\--/ 787 ERROR [M-Bit, NAT state missing] 788 10.0.0.1:1 <---------- 100.0.0.1:2 789 Ext-VTag = 5678 791 On reception of the ERROR message, HOST A sends an ASCONF indicating 792 that the former information has to be deleted and the source address 793 of the actual packet added. 795 /--\/--\ 796 +--------+ +-----+ / \ +--------+ 797 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 798 +--------+ +-----+ \ / +--------+ 799 \--/\--/ 801 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 802 10.0.0.1:1 ----------> 100.1.0.1:2 803 Ext-VTag = 5678 805 +---------+--------+-----------+----------+--------+-----------+ 806 NAT A | Int | Int | Priv | Ext | Ext | Ext | 807 | VTag | Port | Addr | VTag | Port | Addr | 808 +---------+--------+-----------+----------+--------+-----------+ 809 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 810 +---------+--------+-----------+----------+--------+-----------+ 812 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 813 102.1.0.1:1 -----------------------> 100.1.0.1:2 814 Ext-VTag = 5678 816 Host B adds the new source address and deletes all former entries. 818 /--\/--\ 819 +--------+ +-----+ / \ +--------+ 820 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 821 +--------+ +-----+ \ / +--------+ 822 \--/\--/ 824 ASCONF-ACK 825 102.1.0.1:1 <----------------------- 100.1.0.1:2 826 Int-VTag = 1234 828 ASCONF-ACK 829 10.1.0.1:1 <---------- 100.1.0.1:2 830 Int-VTag = 1234 1 832 DATA 833 10.0.0.1:1 ----------> 100.0.0.1:2 834 Ext-VTag = 5678 835 DATA 836 102.1.0.1:1 -----------------------> 100.1.0.1:2 837 Ext-VTag = 5678 839 10.5. Peer-to-Peer Communication 841 If two hosts are behind NATs, they have to get knowledge of the 842 peer's public address. This can be achieved with a so-called 843 rendezvous server. Afterwards the destination addresses are public, 844 and the association is set up with the help of the INIT collision. 845 The NAT boxes create their entries according to their internal peer's 846 point of view. Therefore, NAT A's Internal-VTag and Internal-Port 847 are NAT B's External-VTag and External-Port, respectively. The 848 naming of the verification tag in the packet flow is done from the 849 sending peer's point of view. 851 Internal | External External | Internal 852 | | 853 | /--\/---\ | 854 +--------+ +-------+ / \ +-------+ +--------+ 855 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 856 +--------+ +-------+ \ / +-------+ +--------+ 857 | \--/\---/ | 859 NAT-Tables 860 +---------+--------+-----------+----------+--------+-----------+ 861 NAT A | Int | Int | Priv | Ext | Ext | Ext | 862 | VTag | Port | Addr | VTag | Port | Addr | 863 +---------+--------+--- -------+----------+--------+-----------+ 865 +---------+--------+-----------+----------+--------+-----------+ 866 NAT B | Int | Int | Priv | Ext | Ext | Ext | 867 | v-tag | port | addr | v-tag | port | addr | 868 +---------+--------+--- -------+----------+--------+-----------+ 870 INIT[Initiate-Tag = 1234] 871 10.0.0.1:1 --> 100.0.0.1:2 872 Ext-VTag = 0 874 NAT A creates entry: 876 +---------+--------+-----------+----------+--------+-----------+ 877 NAT A | Int | Int | Priv | Ext | Ext | Ext | 878 | VTag | Port | Addr | VTag | Port | Addr | 879 +---------+--------+-----------+----------+--------+-----------+ 880 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 881 +---------+--------+-----------+----------+--------+-----------+ 883 INIT[Initiate-Tag = 1234] 884 101.0.0.1:1 ----------------> 100.0.0.1:2 885 Ext-VTag = 0 887 NAT B processes INIT, but cannot find an entry. The SCTP packet is 888 silently discarded and leaves the NAT table of NAT B unchanged. 890 +---------+--------+-----------+----------+--------+-----------+ 891 NAT B | Int | Int | Priv | Ext | Ext | Ext | 892 | VTag | Port | Addr | VTag | Port | Addr | 893 +---------+--------+-----------+----------+--------+-----------+ 895 Now Host B sends INIT, which is processed by NAT B. Its parameters 896 are used to create an entry. 898 Internal | External External | Internal 899 | | 900 | /--\/---\ | 901 +--------+ +-------+ / \ +-------+ +--------+ 902 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 903 +--------+ +-------+ \ / +-------+ +--------+ 904 | \--/\---/ | 906 INIT[Initiate-Tag = 5678] 907 101.0.0.1:1 <-- 10.1.0.1:2 908 Ext-VTag = 0 910 +---------+--------+-----------+----------+--------+-----------+ 911 NAT B | Int | Int | Priv | Ext | Ext | Ext | 912 | VTag | Port | Addr | VTag | Port | Addr | 913 +---------+--------+-----------+----------+--------+-----------+ 914 | 5678 | 2 | 10.1.0.1 | 0 | 1 | 101.0.0.1 | 915 +---------+--------+-----------+----------+--------+-----------+ 917 INIT[Initiate-Tag = 5678] 918 101.0.0.1:1 <--------------- 100.0.0.1:2 919 Ext-VTag = 0 921 NAT A processes INIT. As the outgoing INIT of Host A has already 922 created an entry, the entry is found and updated: 924 Internal | External External | Internal 925 | | 926 | /--\/---\ | 927 +--------+ +-------+ / \ +-------+ +--------+ 928 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 929 +--------+ +-------+ \ / +-------+ +--------+ 930 | \--/\---/ | 932 VTag != Int-VTag, but Ext-VTag == 0, find entry. 933 +---------+--------+-----------+----------+--------+-----------+ 934 NAT A | Int | Int | Priv | Ext | Ext | Ext | 935 | VTag | Port | Addr | VTag | Port | Addr | 936 +---------+--------+-----------+----------+--------+-----------+ 937 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 938 +---------+--------+-----------+----------+--------+-----------+ 940 INIT[Initiate-tag = 5678] 941 10.0.0.1:1 <-- 100.0.0.1:2 942 Ext-VTag = 0 944 Host A send INIT-ACK, which can pass through NAT B: 946 Internal | External External | Internal 947 | | 948 | /--\/---\ | 949 +--------+ +-------+ / \ +-------+ +--------+ 950 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 951 +--------+ +-------+ \ / +-------+ +--------+ 952 | \--/\---/ | 954 INIT-ACK[Initiate-Tag = 1234] 955 10.0.0.1:1 --> 100.0.0.1:2 956 Ext-VTag = 5678 958 INIT-ACK[Initiate-Tag = 1234] 959 101.0.0.1:1 ----------------> 100.0.0.1:2 960 Ext-VTag = 5678 962 NAT B updates entry: 964 +---------+--------+-----------+----------+--------+-----------+ 965 NAT B | Int | Int | Priv | Ext | Ext | Ext | 966 | VTag | Port | Addr | VTag | Port | Addr | 967 +---------+--------+-----------+----------+--------+-----------+ 968 | 5678 | 2 | 10.1.0.1 | 1234 | 1 | 101.0.0.1 | 969 +---------+--------+-----------+----------+--------+-----------+ 971 INIT-ACK[Initiate-Tag = 1234] 972 101.0.0.1:1 --> 10.1.0.1:2 973 Ext-VTag = 5678 975 The lookup for COOKIE-ECHO and COOKIE-ACK is successful. 977 Internal | External External | Internal 978 | | 979 | /--\/---\ | 980 +--------+ +-------+ / \ +-------+ +--------+ 981 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 982 +--------+ +-------+ \ / +-------+ +--------+ 983 | \--/\---/ | 985 COOKIE-ECHO 986 101.0.0.1:1 <-- 10.1.0.1:2 987 Ext-VTag = 1234 989 COOKIE-ECHO 990 101.0.0.1:1 <------------- 100.0.0.1:2 991 Ext-VTag = 1234 993 COOKIE-ECHO 994 10.0.0.1:1 <-- 100.0.0.1:2 995 Ext-VTag = 1234 997 COOKIE-ACK 998 10.0.0.1:1 --> 100.0.0.1:2 999 Ext-VTag = 5678 1001 COOKIE-ACK 1002 101.0.0.1:1 ----------------> 100.0.0.1:2 1003 Ext-VTag = 5678 1005 COOKIE-ACK 1006 101.0.0.1:1 --> 10.1.0.1:2 1007 Ext-VTag = 5678 1009 11. IANA Considerations 1011 TBD 1013 12. Security considerations 1015 State maintenance within a NAT is always a subject of possible Denial 1016 Of Service attacks. This document recommends that at a minimum a NAT 1017 runs a timer on any SCTP state so that old association state can be 1018 cleaned up. 1020 13. Acknowledgments 1022 The authors wish to thank Qiaobing Xie, Henning Peters, Bryan Ford, 1023 David Hayes, Alfred Hines, Dan Wing, and Jason But for their 1024 invaluable comments. 1026 14. References 1028 14.1. Normative References 1030 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1031 RFC 793, September 1981. 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, March 1997. 1036 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1037 RFC 4960, September 2007. 1039 14.2. Informative References 1041 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1042 E. Lear, "Address Allocation for Private Internets", 1043 BCP 5, RFC 1918, February 1996. 1045 Authors' Addresses 1047 Randall R. Stewart 1048 Huawei 1049 Chapin, SC 29036 1050 USA 1052 Phone: 1053 Email: randall@lakerest.net 1055 Michael Tuexen 1056 Muenster Univ. of Applied Sciences 1057 Stegerwaldstr. 39 1058 48565 Steinfurt 1059 Germany 1061 Email: tuexen@fh-muenster.de 1062 Irene Ruengeler 1063 Muenster Univ. of Applied Sciences 1064 Stegerwaldstr. 39 1065 48565 Steinfurt 1066 Germany 1068 Email: i.ruengeler@fh-muenster.de