idnits 2.17.1 draft-ietf-behave-sctpnat-09.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 37 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 (September 09, 2013) is 3882 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 379, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-natsupp-05 -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Adara Networks 4 Intended status: Best Current Practice M. Tuexen 5 Expires: March 13, 2014 I. Ruengeler 6 Muenster Univ. of Appl. Sciences 7 September 09, 2013 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 draft-ietf-behave-sctpnat-09.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 March 13, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . . . 4 69 4.1. Single Point Traversal . . . . . . . . . . . . . . . . . 4 70 4.2. Multi Point Traversal . . . . . . . . . . . . . . . . . . 5 71 5. Limitations of Classical NAPT for SCTP . . . . . . . . . . . 6 72 6. The SCTP Specific Variant of NAT . . . . . . . . . . . . . . 6 73 7. NAT to SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Handling of Fragmented SCTP Packets . . . . . . . . . . . . . 10 75 9. Various Examples of NAT Traversals . . . . . . . . . . . . . 10 76 9.1. Single-homed Client to Single-homed Server . . . . . . . 10 77 9.2. Single-homed Client to Multi-homed Server . . . . . . . . 12 78 9.3. Multihomed Client and Server . . . . . . . . . . . . . . 15 79 9.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 18 80 9.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . 20 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 86 13.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 use private 96 addresses (see [RFC5735]) and yet use only a single globally unique 97 IPv4 address, even when two hosts (behind a NAT) choose the same port 98 numbers for their connection. This additional code is sometimes 99 classified as Network Address and Port Translation or NAPT. To date, 100 specialized code for SCTP has not yet been added to most NATs so that 101 only true NAT is available. The end result of this is that only one 102 SCTP capable host can be behind a 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 Figure 1. 131 Private-Address (Priv-Addr): The private address that is known to 132 the internal host. 134 Internal-Port (Int-Port): The port number that is in use by the host 135 holding the Private-Address. 137 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 External-Address (Ext-Addr): The address that an internal host is 143 attempting to contact. 145 External-Port (Ext-Port): The port number of the peer process at the 146 External-Address. 148 External-VTag (Ext-VTag): The Verification Tag that the host holding 149 the External-Address has chosen for its communication. The VTag 150 is a unique 32 bit tag that must accompany any incoming SCTP 151 packet for this association to the External-Address. 153 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 Figure 1: Architecture 170 4. SCTP NAT Traversal Scenarios 172 This section defines the notion of single and multi-point NAT 173 traversal. 175 4.1. Single Point Traversal 177 In this case, all packets in the SCTP association go through a single 178 NAT, as shown below: 180 Internal Network | External Network 181 | 182 +---------+ | /--\/--\ +---------+ 183 | SCTP | +-----+ / \ | SCTP | 184 |end point|=========| NAT |========= | Internet | ========|end point| 185 | A | +-----+ \ / | B | 186 +---------+ | \--/\--/ +---------+ 187 | 189 Single NAT scenario 191 A variation of this case is shown below, i.e., multiple NATs in a 192 single path: 194 Internal | External : Internal | External 195 | : | 196 +---------+ | : | /--\/--\ +---------+ 197 | SCTP | +-----+ : +-----+ / \ | SCTP | 198 |end point|==| NAT |=======:=======| NAT |==| Internet |==|end point| 199 | A | +-----+ : +-----+ \ / | B | 200 +---------+ | : | \--/\--/ +---------+ 201 | : | 203 Serial NATs scenario 205 In this single point traversal scenario, we must acknowledge that 206 while one of the main benefits of SCTP multi-homing is redundant 207 paths, the NAT function represents a single point of failure in the 208 path of the SCTP multi-home association. However, the rest of the 209 path may still benefit from path diversity provided by SCTP multi- 210 homing. 212 The two SCTP endpoints in this case can be either single-homed or 213 multi-homed. However, the important thing is that the NAT (or NATs) 214 in this case sees all the packets of the SCTP association. 216 4.2. Multi Point Traversal 218 This case involves multiple NATs and each NAT only sees some of the 219 packets in the SCTP association. An example is shown below: 221 Internal | External 222 +------+ /---\/---\ 223 +---------+ /=======|NAT A |=========\ / \ +---------+ 224 | SCTP | / +------+ \/ \ | SCTP | 225 |end point|/ ... | Internet |===|end point| 226 | A |\ \ / | B | 227 +---------+ \ +------+ / \ / +---------+ 228 \=======|NAT B |=========/ \---\/---/ 229 +------+ 230 | 232 Parallel NATs scenario 234 This case does NOT apply to a single-homed SCTP association (i.e., 235 BOTH endpoints in the association use only one IP address). The 236 advantage here is that the existence of multiple NAT traversal points 237 can preserve the path diversity of a multi-homed association for the 238 entire path. This in turn can improve the robustness of the 239 communication. 241 5. Limitations of Classical NAPT for SCTP 243 Using classical NAPT may result in changing one of the SCTP port 244 numbers during the processing which requires the recomputation of the 245 transport layer checksum. Whereas for UDP and TCP this can be done 246 very efficiently, for SCTP the checksum (CRC32c) over the entire 247 packet needs to be recomputed. This would add considerable to the 248 NAT computational burden, however hardware support may mitigate this 249 in some implementations. 251 An SCTP endpoint may have multiple addresses but only has a single 252 port number. To make multipoint traversal work, all the NATs 253 involved must recognize the packets they see as belonging to the same 254 SCTP association and perform port number translation in a consistent 255 way. One possible way of doing this is to use pre-defined table of 256 ports and addresses configured within each NAT. Other mechanisms 257 could make use of NAT to NAT communication. Such mechanisms are 258 considered by the authors not to be deployable on a wide scale base 259 and thus not a recommended solution. Therefore the SCTP variant of 260 NAT has been developed. 262 6. The SCTP Specific Variant of NAT 264 In this section we assume that we have multiple SCTP capable hosts 265 behind a NAT which has one Public-Address. Furthermore we are 266 focusing in this section on the single point traversal scenario. 268 The modification of SCTP packets sent to the public Internet is easy. 269 The source address of the packet has to be replaced with the Public- 270 Address. It may also be necessary to establish some state in the NAT 271 box to handle incoming packets, which is discussed later. 273 For SCTP packets coming from the public Internet the destination 274 address of the packets has to be replaced with the Private-Address of 275 the host the packet has to be delivered to. The lookup of the 276 Private-Address is based on the External-VTag, External-Port, 277 External-Address, Internal-VTag and the Internal-Port. 279 For the SCTP NAT processing the NAT box has to maintain a table of 280 Internal-VTag, Internal-Port, Private-Address, External-VTag, 281 External-Port and whether the restart procedure is disabled or not. 282 An entry in that table is called a NAT state control block. The 283 function Create() obtains the just mentioned parameters and returns a 284 NAT-State control block. 286 The entries in this table fulfill some uniqueness conditions. There 287 must not be more than one entry with the same pair of Internal-Port 288 and External-Port. This rule can be relaxed, if all entries with the 289 same Internal-Port and External-Port have the support for the restart 290 procedure enabled. In this case there must be no more than one entry 291 with the same Internal-Port, External-Port and Ext-VTag and no more 292 than one entry with the same Internal-Port, External-Port and Int- 293 VTag. 295 The processing of outgoing SCTP packets containing an INIT-chunk is 296 described in the following figure. The scenario shown is valid for 297 all message flows in this section. 299 /--\/--\ 300 +--------+ +-----+ / \ +--------+ 301 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 302 +--------+ +-----+ \ / +--------+ 303 \--/\---/ 305 INIT[Initiate-Tag] 306 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 307 Ext-VTag=0 309 Create(Initiate-Tag, Int-Port, Priv-Addr, 0) 310 Returns(NAT-State control block) 312 Translate To: 314 INIT[Initiate-Tag] 315 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 316 Ext-VTag=0 318 It should be noted that normally a NAT control block will be created. 319 However, it is possible that there is already a NAT control block 320 with the same External-Address, External-Port, Internal-Port, and 321 Internal-VTag but different Private-Address. In this case the INIT 322 SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the 323 SCTP host with the M-Bit set and an appropriate error cause (see 324 [I-D.ietf-tsvwg-natsupp] for the format). The source address of the 325 packet containing the ABORT chunk MUST be the destination address of 326 the packet containing the INIT chunk. 328 It is also possible that a connection to External-Address and 329 External-Port exists without an Internal-VTag conflict but the 330 External-Address does not support the DISABLE_RESTART feature (noted 331 in the NAT control block when the prior connection was established). 332 In such a case the INIT SHOULD be dropped by the NAT and an ABORT 333 SHOULD be sent back to the SCTP host with the M-Bit set and an 334 appropriate error cause (see [I-D.ietf-tsvwg-natsupp] for the 335 format). 337 The processing of outgoing SCTP packets containing no INIT-chunk is 338 described in the following figure. 340 /--\/--\ 341 +--------+ +-----+ / \ +--------+ 342 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 343 +--------+ +-----+ \ / +--------+ 344 \--/\---/ 346 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 347 Ext-VTag 349 Translate To: 351 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 352 Ext-VTag 354 The processing of incoming SCTP packets containing INIT-ACK chunks is 355 described in the following figure. The Lookup() function getting as 356 input the Internal-VTag, Internal-Port, External-VTag (=0), External- 357 Port, and External-Address, returns the corresponding entry of the 358 NAT table and updates the External-VTag by substituting it with the 359 value of the Initiate-Tag of the INIT-ACK chunk. The wildcard 360 character signifies that the parameter's value is not considered in 361 the Lookup() function or changed in the Update() function, 362 respectively. 364 /--\/--\ 365 +--------+ +-----+ / \ +--------+ 366 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 367 +--------+ +-----+ \ / +--------+ 368 \--/\---/ 370 INIT-ACK[Initiate-Tag] 371 Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port 372 Int-VTag 374 Lookup(Int-VTag, Int-Port, *, 0, Ext-Port) 375 Update(*, *, *, Initiate-Tag, *) 377 Returns(NAT-State control block containing Private-Address) 379 INIT-ACK[Initiate-Tag] 380 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 381 Int-VTag 383 In the case Lookup fails, the SCTP packet is dropped. The Update 384 routine inserts the External-VTag (the Initiate-Tag of the INIT-ACK 385 chunk) in the NAT state control block. 387 The processing of incoming SCTP packets containing an ABORT or 388 SHUTDOWN-COMPLETE chunk with the T-Bit set is described in the 389 following figure. 391 /--\/--\ 392 +--------+ +-----+ / \ +--------+ 393 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 394 +--------+ +-----+ \ / +--------+ 395 \--/\---/ 397 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 398 Ext-VTag 400 Lookup(0, Int-Port, *, Ext-VTag, Ext-Port) 402 Returns(NAT-State control block containing Private-Address) 404 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 405 Ext-VTag 407 The processing of other incoming SCTP packets is described in the 408 following figure. 410 /--\/--\ 411 +--------+ +-----+ / \ +--------+ 412 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 413 +--------+ +-----+ \ / +--------+ 414 \--/\---/ 416 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 417 Int-VTag 419 Lookup(Int-VTag, Int-Port, *, *, Ext-Port) 421 Returns(NAT-State control block containing Local-Address) 423 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 424 Int-VTag 426 For an incoming packet containing an INIT-chunk a table lookup is 427 made only based on the addresses and port numbers. If an entry with 428 an External-VTag of zero is found, it is considered a match and the 429 External-VTag is updated. 431 This allows the handling of INIT-collision through NAT. 433 7. NAT to SCTP 435 This document at various places discusses the sending of specialized 436 SCTP chunks (e.g. an ABORT with M-Bit set). These chunks and 437 procedures are not defined in this document, but instead are defined 438 in [I-D.ietf-tsvwg-natsupp]. The NAT implementer should refer to 439 [I-D.ietf-tsvwg-natsupp] for detailed descriptions of packet formats 440 and procedures. 442 8. Handling of Fragmented SCTP Packets 444 A NAT box MUST support IP reassembly of received fragmented SCTP 445 packets. The fragments may arrive in any order. 447 When an SCTP packet has to be fragmented by the NAT box and the IP 448 header forbids fragmentation a corresponding ICMP packet SHOULD be 449 sent. 451 9. Various Examples of NAT Traversals 453 9.1. Single-homed Client to Single-homed Server 455 The internal client starts the association with the external server 456 via a four-way-handshake. Host A starts by sending an INIT chunk. 458 /--\/--\ 459 +--------+ +-----+ / \ +--------+ 460 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 461 +--------+ +-----+ \ / +--------+ 462 \--/\---/ 463 +---------+--------+-----------+----------+--------+ 464 NAT | Int | Int | Priv | Ext | Ext | 465 | VTag | Port | Addr | VTag | Port | 466 +---------+--------+--- -------+----------+--------+ 468 INIT[Initiate-Tag = 1234] 469 10.0.0.1:1 ------> 100.0.0.1:2 470 Ext-VTtag = 0 472 A NAT entry is created, the source address is substituted and the 473 packet is sent on: 475 NAT creates entry: 476 +---------+--------+-----------+----------+--------+ 477 NAT | Int | Int | Priv | Ext | Ext | 478 | VTag | Port | Addr | VTag | Port | 479 +---------+--------+-----------+----------+--------+ 480 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 481 +---------+--------+-----------+----------+--------+ 483 INIT[Initiate-Tag = 1234] 484 101.0.0.1:1 --------------------------> 100.0.0.1:2 485 Ext-VTtag = 0 487 Host B receives the INIT and sends an INIT-ACK with the NAT's 488 external address as destination address. 490 /--\/--\ 491 +--------+ +-----+ / \ +--------+ 492 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 493 +--------+ +-----+ \ / +--------+ 494 \--/\---/ 496 INIT-ACK[Initiate-Tag = 5678] 497 101.0.0.1:1 <------------------------- 100.0.0.1:2 498 Int-VTag = 1234 500 NAT updates entry: 501 +---------+--------+-----------+----------+--------+ 502 NAT | Int | Int | Priv | Ext | Ext | 503 | VTag | Port | Addr | VTag | Port | 504 +---------+--------+-----------+----------+--------+ 505 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 506 +---------+--------+-----------+----------+--------+ 508 INIT-ACK[Initiate-Tag = 5678] 509 10.0.0.1:1 <------ 100.0.0.1:2 510 Int-VTag = 1234 512 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 513 ACK. 515 /--\/--\ 516 +--------+ +-----+ / \ +--------+ 517 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 518 +--------+ +-----+ \ / +--------+ 519 \--/\---/ 521 COOKIE-ECHO 522 10.0.0.1:1 ------> 100.0.0.1:2 523 Ext-VTag = 5678 525 COOKIE-ECHO 526 101.0.0.1:1 -------------------------> 100.0.0.1:2 527 Ext-VTag = 5678 529 COOKIE-ACK 530 101.0.0.1:1 <------------------------- 100.0.0.1:2 531 Int-VTag = 1234 533 COOKIE-ACK 534 10.0.0.1:1 <------ 100.0.0.1:2 535 Int-VTag = 1234 537 9.2. Single-homed Client to Multi-homed Server 539 The internal client is single-homed whereas the external server is 540 multi-homed. The client (Host A) sends an INIT like in the single- 541 homed case. 543 +--------+ 544 /--\/--\ /-|Router 1| \ 545 +------+ +-----+ / \ / +--------+ \ +------+ 546 | Host | <-----> | NAT | <-> | Internet | == =| Host | 547 | A | +-----+ \ / \ +--------+ / | B | 548 +------+ \--/\--/ \-|Router 2|-/ +------+ 549 +--------+ 551 +---------+--------+-----------+----------+--------+ 552 NAT | Int | Int | Priv | Ext | Ext | 553 | VTag | Port | Addr | VTag | Port | 554 +---------+--------+-----------+----------+--------+ 556 INIT[Initiate-Tag = 1234] 557 10.0.0.1:1 ---> 100.0.0.1:2 558 Ext-VTag = 0 560 NAT creates entry: 562 +---------+--------+-----------+----------+--------+ 563 NAT | Int | Int | Priv | Ext | Ext | 564 | VTag | Port | Addr | VTag | Port | 565 +---------+--------+-----------+----------+--------+ 566 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 567 +---------+--------+-----------+----------+--------+ 569 INIT[Initiate-Tag = 1234] 570 101.0.0.1:1 ----------------------------> 100.0.0.1:2 571 Ext-VTag = 0 573 The server (Host B) includes its two addresses in the INIT-ACK chunk, 574 which results in two NAT entries. 576 +--------+ 577 /--\/--\ /-|Router 1| \ 578 +------+ +-----+ / \ / +--------+ \ +------+ 579 | Host | <-----> | NAT | <-> | Internet | == =| Host | 580 | A | +-----+ \ / \ +--------+ / | B | 581 +------+ \--/\--/ \-|Router 2|-/ +------+ 582 +--------+ 584 INIT-ACK[Initiate-tag = 5678, IP-Addr = 100.1.0.1] 585 101.0.0.1:1 <---------------------------- 100.0.0.1:2 586 Int-VTag = 1234 588 NAT does need to change the table for second address: 590 +---------+--------+-----------+----------+--------+ 591 NAT | Int | Int | Priv | Ext | Ext | 592 | VTag | Port | Addr | VTag | Port | 593 +---------+--------+-----------+----------+--------+ 594 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 595 +---------+--------+-----------+----------+--------+ 597 INIT-ACK[Initiate-Tag = 5678] 598 10.0.0.1:1 <--- 100.0.0.1:2 599 Int-VTag = 1234 601 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 602 ACK. 604 +--------+ 605 /--\/--\ /-|Router 1| \ 606 +------+ +-----+ / \ / +--------+ \ +------+ 607 | Host | <-----> | NAT | <-> | Internet | == =| Host | 608 | A | +-----+ \ / \ +--------+ / | B | 609 +------+ \--/\--/ \-|Router 2|-/ +------+ 610 +--------+ 612 COOKIE-ECHO 613 10.0.0.1:1 ---> 100.0.0.1:2 614 ExtVTag = 5678 616 COOKIE-ECHO 617 101.0.0.1:1 ----------------------------> 100.0.0.1:2 618 Ext-VTag = 5678 620 COOKIE-ACK 621 101.0.0.1:1 <---------------------------- 100.0.0.1:2 622 Int-VTag = 1234 624 COOKIE-ACK 625 10.0.0.1:1 <--- 100.0.0.1:2 626 Int-VTag = 1234 628 9.3. Multihomed Client and Server 630 The client (Host A) sends an INIT to the server (Host B), but does 631 not include the second address. 633 +-------+ 634 /--| NAT 1 |--\ /--\/--\ 635 +------+ / +-------+ \ / \ +--------+ 636 | Host |=== ====| Internet |====| Host B | 637 | A | \ +-------+ / \ / +--------+ 638 +------+ \--| NAT 2 |--/ \--/\--/ 639 +-------+ 641 +---------+--------+-----------+----------+--------+ 642 NAT 1 | Int | Int | Priv | Ext | Ext | 643 | VTag | Port | Addr | VTag | Port | 644 +---------+--------+--- -------+----------+--------+ 646 INIT[Initiate-Tag = 1234] 647 10.0.0.1:1 --------> 100.0.0.1:2 648 Ext-VTag = 0 650 NAT 1 creates entry: 652 +---------+--------+-----------+----------+--------+ 653 NAT 1 | Int | Int | Priv | Ext | Ext | 654 | VTag | Port | Addr | VTag | Port | 655 +---------+--------+-----------+----------+--------+ 656 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 657 +---------+--------+-----------+----------+--------+ 659 INIT[Initiate-Tag = 1234] 660 101.0.0.1:1 -----------------------> 100.0.0.1:2 661 ExtVTag = 0 663 Host B includes its second address in the INIT-ACK, which results in 664 two NAT entries in NAT 1. 666 +-------+ 667 /--------| NAT 1 |--------\ /--\/--\ 668 +------+ / +-------+ \ / \ +--------+ 669 | Host |=== ====| Internet |===| Host B | 670 | A | \ +-------+ / \ / +--------+ 671 +------+ \--------| NAT 2 |--------/ \--/\--/ 672 +-------+ 674 INIT-ACK[Initiate-Tag = 5678, IP-Addr = 100.1.0.1] 675 101.0.0.1:1 <------------------------- 100.0.0.1:2 676 Int-VTag = 1234 678 NAT 1 does not need to update the table for second address: 680 +---------+--------+-----------+----------+--------+ 681 NAT 1 | Int | Int | Priv | Ext | Ext | 682 | VTag | Port | Addr | VTag | Port | 683 +---------+--------+-----------+----------+--------+ 684 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 685 +---------+--------+-----------+----------+--------+ 687 INIT-ACK[Initiate-Tag = 5678] 688 10.0.0.1:1 <---------100.0.0.1:2 689 Int-VTag = 1234 691 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 692 ACK. 694 +-------+ 695 /--------| NAT 1 |--------\ /--\/--\ 696 +------+ / +-------+ \ / \ +--------+ 697 | Host |=== ====| Internet |===| Host B | 698 | A | \ +-------+ / \ / +--------+ 699 +------+ \--------| NAT 2 |--------/ \--/\--/ 700 +-------+ 702 COOKIE-ECHO 704 10.0.0.1:1 --------> 100.0.0.1:2 705 Ext-VTag = 5678 707 COOKIE-ECHO 708 101.0.0.1:1 --------------------> 100.0.0.1:2 709 Ext-VTag = 5678 711 COOKIE-ACK 712 101.0.0.1:1 <-------------------- 100.0.0.1:2 713 Int-VTag = 1234 715 COOKIE-ACK 716 10.0.0.1:1 <------- 100.0.0.1:2 717 Int-VTag = 1234 719 Host A announces its second address in an ASCONF chunk. The address 720 parameter contains an undefined address (0) to indicate that the 721 source address should be added. The lookup address parameter within 722 the ASCONF chunk will also contain the pair of VTags (external and 723 internal) so that the NAT may populate its table completely with this 724 single packet. 726 +-------+ 727 /--------| NAT 1 |--------\ /--\/--\ 728 +------+ / +-------+ \ / \ +--------+ 729 | Host |=== ====| Internet |===| Host B | 730 | A | \ +-------+ / \ / +--------+ 731 +------+ \--------| NAT 2 |--------/ \--/\--/ 732 +-------+ 734 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] 735 10.1.0.1:1 --------> 100.1.0.1:2 736 Ext-VTag = 5678 738 NAT 2 creates complete entry: 740 +---------+--------+-----------+----------+--------+ 741 NAT 2 | Int | Int | Priv | Ext | Ext | 742 | VTag | Port | Addr | VTag | Port | 743 +---------+--------+-----------+----------+--------+ 744 | 1234 | 1 | 10.1.0.1 | 5678 | 2 | 745 +---------+--------+-----------+----------+--------+ 747 ASCONF [ADD-IP,Int-VTag=1234, Ext-VTag = 5678] 748 101.1.0.1:1 -----------------------> 100.1.0.1:2 749 Ext-VTag = 5678 751 ASCONF-ACK 752 101.1.0.1:1 <----------------------- 100.1.0.1:2 753 Int-VTag = 1234 755 ASCONF-ACK 756 10.1.0.1:1 <----- 100.1.0.1:2 757 Int-VTag = 1234 759 9.4. NAT Loses Its State 761 Association is already established between Host A and Host B, when 762 the NAT loses its state and obtains a new public address. Host A 763 sends a DATA chunk to Host B. 765 /--\/--\ 766 +--------+ +-----+ / \ +--------+ 767 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 768 +--------+ +-----+ \ / +--------+ 769 \--/\--/ 771 +---------+--------+-----------+----------+--------+ 772 NAT | Int | Int | Priv | Ext | Ext | 773 | VTag | Port | Addr | VTag | Port | 774 +---------+--------+-----------+----------+--------+ 775 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 776 +---------+--------+-----------+----------+--------+ 778 DATA 779 10.0.0.1:1 ----------> 100.0.0.1:2 780 Ext-VTag = 5678 782 The NAT box cannot find entry for the association. It sends ERROR 783 message with the M-Bit set and the cause "NAT state missing". 785 /--\/--\ 787 +--------+ +-----+ / \ +--------+ 788 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 789 +--------+ +-----+ \ / +--------+ 790 \--/\--/ 792 ERROR [M-Bit, NAT state missing] 793 10.0.0.1:1 <---------- 100.0.0.1:2 794 Ext-VTag = 5678 796 On reception of the ERROR message, Host A sends an ASCONF chunk 797 indicating that the former information has to be deleted and the 798 source address of the actual packet added. 800 /--\/--\ 801 +--------+ +-----+ / \ +--------+ 802 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 803 +--------+ +-----+ \ / +--------+ 804 \--/\--/ 806 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 807 10.0.0.1:1 ----------> 100.1.0.1:2 808 Ext-VTag = 5678 810 +---------+--------+-----------+----------+--------+ 811 NAT | Int | Int | Priv | Ext | Ext | 812 | VTag | Port | Addr | VTag | Port | 813 +---------+--------+-----------+----------+--------+ 814 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 815 +---------+--------+-----------+----------+--------+ 817 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 818 102.1.0.1:1 ---------------------> 100.1.0.1:2 819 Ext-VTag = 5678 821 Host B adds the new source address and deletes all former entries. 823 /--\/--\ 824 +--------+ +-----+ / \ +--------+ 825 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 826 +--------+ +-----+ \ / +--------+ 827 \--/\--/ 828 ASCONF-ACK 829 102.1.0.1:1 <--------------------- 100.1.0.1:2 830 Int-VTag = 1234 832 ASCONF-ACK 833 10.1.0.1:1 <---------- 100.1.0.1:2 834 Int-VTag = 1234 836 DATA 837 10.0.0.1:1 ----------> 100.0.0.1:2 838 Ext-VTag = 5678 839 DATA 840 102.1.0.1:1 ---------------------> 100.1.0.1:2 841 Ext-VTag = 5678 843 9.5. Peer-to-Peer Communication 845 If two hosts are behind NATs, they have to get knowledge of the 846 peer's public address. This can be achieved with a so-called 847 rendezvous server. Afterwards the destination addresses are public, 848 and the association is set up with the help of the INIT collision. 849 The NAT boxes create their entries according to their internal peer's 850 point of view. Therefore, NAT A's Internal-VTag and Internal-Port 851 are NAT B's External-VTag and External-Port, respectively. The 852 naming of the verification tag in the packet flow is done from the 853 sending peer's point of view. 855 Internal | External External | Internal 856 | | 857 | /--\/---\ | 858 +--------+ +-------+ / \ +-------+ +--------+ 859 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 860 +--------+ +-------+ \ / +-------+ +--------+ 861 | \--/\---/ | 863 NAT-Tables 864 +---------+--------+-----------+----------+--------+ 865 NAT A | Int | Int | Priv | Ext | Ext | 866 | VTag | Port | Addr | VTag | Port | 867 +---------+--------+--- -------+----------+--------+ 869 +---------+--------+-----------+----------+--------+ 870 NAT B | Int | Int | Priv | Ext | Ext | 871 | v-tag | port | addr | v-tag | port | 872 +---------+--------+--- -------+----------+--------+ 874 INIT[Initiate-Tag = 1234] 875 10.0.0.1:1 --> 100.0.0.1:2 876 Ext-VTag = 0 878 NAT A creates entry: 880 +---------+--------+-----------+----------+--------+ 881 NAT A | Int | Int | Priv | Ext | Ext | 882 | VTag | Port | Addr | VTag | Port | 883 +---------+--------+-----------+----------+--------+ 884 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 885 +---------+--------+-----------+----------+--------+ 887 INIT[Initiate-Tag = 1234] 888 101.0.0.1:1 ----------------> 100.0.0.1:2 889 Ext-VTag = 0 891 NAT B processes INIT, but cannot find an entry. The SCTP packet is 892 silently discarded and leaves the NAT table of NAT B unchanged. 894 +---------+--------+-----------+----------+--------+ 895 NAT B | Int | Int | Priv | Ext | Ext | 896 | VTag | Port | Addr | VTag | Port | 897 +---------+--------+-----------+----------+--------+ 899 Now Host B sends INIT, which is processed by NAT B. Its parameters 900 are used to create an entry. 902 Internal | External External | Internal 903 | | 904 | /--\/---\ | 905 +--------+ +-------+ / \ +-------+ +--------+ 906 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 907 +--------+ +-------+ \ / +-------+ +--------+ 908 | \--/\---/ | 910 INIT[Initiate-Tag = 5678] 911 101.0.0.1:1 <-- 10.1.0.1:2 912 Ext-VTag = 0 914 +---------+--------+-----------+----------+--------+ 915 NAT B | Int | Int | Priv | Ext | Ext | 916 | VTag | Port | Addr | VTag | Port | 917 +---------+--------+-----------+----------+--------+ 918 | 5678 | 2 | 10.1.0.1 | 0 | 1 | 919 +---------+--------+-----------+----------+--------+ 921 INIT[Initiate-Tag = 5678] 922 101.0.0.1:1 <--------------- 100.0.0.1:2 923 Ext-VTag = 0 925 NAT A processes INIT. As the outgoing INIT of Host A has already 926 created an entry, the entry is found and updated: 928 Internal | External External | Internal 929 | | 930 | /--\/---\ | 931 +--------+ +-------+ / \ +-------+ +--------+ 932 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 933 +--------+ +-------+ \ / +-------+ +--------+ 934 | \--/\---/ | 936 VTag != Int-VTag, but Ext-VTag == 0, find entry. 937 +---------+--------+-----------+----------+--------+ 938 NAT A | Int | Int | Priv | Ext | Ext | 939 | VTag | Port | Addr | VTag | Port | 940 +---------+--------+-----------+----------+--------+ 941 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 942 +---------+--------+-----------+----------+--------+ 944 INIT[Initiate-tag = 5678] 945 10.0.0.1:1 <-- 100.0.0.1:2 946 Ext-VTag = 0 948 Host A send INIT-ACK, which can pass through NAT B: 950 Internal | External External | Internal 951 | | 952 | /--\/---\ | 953 +--------+ +-------+ / \ +-------+ +--------+ 954 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 955 +--------+ +-------+ \ / +-------+ +--------+ 956 | \--/\---/ | 958 INIT-ACK[Initiate-Tag = 1234] 959 10.0.0.1:1 -->; 100.0.0.1:2 960 Ext-VTag = 5678 962 INIT-ACK[Initiate-Tag = 1234] 963 101.0.0.1:1 ----------------> 100.0.0.1:2 964 Ext-VTag = 5678 966 NAT B updates entry: 968 +---------+--------+-----------+----------+--------+ 969 NAT B | Int | Int | Priv | Ext | Ext | 970 | VTag | Port | Addr | VTag | Port | 971 +---------+--------+-----------+----------+--------+ 972 | 5678 | 2 | 10.1.0.1 | 1234 | 1 | 973 +---------+--------+-----------+----------+--------+ 975 INIT-ACK[Initiate-Tag = 1234] 976 101.0.0.1:1 --> 10.1.0.1:2 977 Ext-VTag = 5678 979 The lookup for COOKIE-ECHO and COOKIE-ACK is successful. 981 Internal | External External | Internal 982 | | 983 | /--\/---\ | 984 +--------+ +-------+ / \ +-------+ +--------+ 985 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 986 +--------+ +-------+ \ / +-------+ +--------+ 987 | \--/\---/ | 989 COOKIE-ECHO 990 101.0.0.1:1 <-- 10.1.0.1:2 991 Ext-VTag = 1234 993 COOKIE-ECHO 994 101.0.0.1:1 <------------- 100.0.0.1:2 995 Ext-VTag = 1234 997 COOKIE-ECHO 998 10.0.0.1:1 <-- 100.0.0.1:2 999 Ext-VTag = 1234 1000 COOKIE-ACK 1001 10.0.0.1:1 --> 100.0.0.1:2 1002 Ext-VTag = 5678 1004 COOKIE-ACK 1005 101.0.0.1:1 ----------------> 100.0.0.1:2 1006 Ext-VTag = 5678 1008 COOKIE-ACK 1009 101.0.0.1:1 --> 10.1.0.1:2 1010 Ext-VTag = 5678 1012 10. IANA Considerations 1014 This document requires no actions from IANA. 1016 11. Security Considerations 1018 State maintenance within a NAT is always a subject of possible Denial 1019 Of Service attacks. This document recommends that at a minimum a NAT 1020 runs a timer on any SCTP state so that old association state can be 1021 cleaned up. 1023 12. Acknowledgments 1025 The authors wish to thank Jason But Bryan Ford, David Hayes, Alfred 1026 Hines, Henning Peters, Timo Voelker, Dan Wing, and Qiaobing Xie for 1027 their invaluable comments. 1029 13. References 1031 13.1. Normative References 1033 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1034 793, September 1981. 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", BCP 14, RFC 2119, March 1997. 1039 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1040 4960, September 2007. 1042 [I-D.ietf-tsvwg-natsupp] 1043 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 1044 Transmission Protocol (SCTP) Network Address Translation 1045 Support", draft-ietf-tsvwg-natsupp-05 (work in progress), 1046 February 2013. 1048 13.2. Informative References 1050 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 1051 RFC 5735, January 2010. 1053 Authors' Addresses 1055 Randall R. Stewart 1056 Adara Networks 1057 Chapin, SC 29036 1058 US 1060 Email: randall@lakerest.net 1062 Michael Tuexen 1063 Muenster University of Applied Sciences 1064 Stegerwaldstrasse 39 1065 48565 Steinfurt 1066 DE 1068 Email: tuexen@fh-muenster.de 1070 Irene Ruengeler 1071 Muenster University of Applied Sciences 1072 Stegerwaldstrasse 39 1073 48565 Steinfurt 1074 DE 1076 Email: i.ruengeler@fh-muenster.de