idnits 2.17.1 draft-ietf-behave-sctpnat-07.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 (October 9, 2012) is 4210 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 376, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-natsupp-02 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: BCP M. Tuexen 5 Expires: April 12, 2013 I. Ruengeler 6 Muenster Univ. of Appl. Sciences 7 October 9, 2012 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 draft-ietf-behave-sctpnat-07.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 April 12, 2013. 48 Copyright Notice 49 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8. Handling of Fragmented SCTP Packets . . . . . . . . . . . . . 11 74 9. Various Examples of NAT Traversals . . . . . . . . . . . . . . 11 75 9.1. Single-homed Client to Single-homed Server . . . . . . . . 11 76 9.2. Single-homed Client to Multi-homed Server . . . . . . . . 13 77 9.3. Multihomed Client and Server . . . . . . . . . . . . . . . 15 78 9.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 19 79 9.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . . 21 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 82 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 85 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 88 1. Introduction 90 Stream Control Transmission Protocol [RFC4960] provides a reliable 91 communications channel between two end-hosts in many ways similar to 92 TCP [RFC0793]. With the widespread deployment of Network Address 93 Translators (NAT), specialized code has been added to NAT for TCP 94 that allows multiple hosts to reside behind a NAT and use private 95 addresses (see [RFC5735]) and yet use only a single globally unique 96 IPv4 address, even when two hosts (behind a NAT) choose the same port 97 numbers for their connection. This additional code is sometimes 98 classified as Network Address and Port Translation or NAPT. To date, 99 specialized code for SCTP has not yet been added to most NATs so that 100 only true NAT is available. The end result of this is that only one 101 SCTP capable host can be behind a NAT. 103 This document proposes an SCTP specific variant NAT that provides the 104 NAPT functionality without changing SCTP port numbers. The authors 105 feel it is possible and desirable to make these changes for a number 106 of reasons. 108 o It is desirable for SCTP internal end-hosts on multiple platforms 109 to be able to share a NAT's public IP address, much as TCP does 110 today. 112 o If a NAT does not need to change any data within an SCTP packet it 113 will reduce the processing burden of NAT'ing SCTP by NOT needing 114 to execute the CRC32c checksum required by SCTP. 116 o Not having to touch the IP payload makes the processing of ICMP 117 messages in NATs easier. 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Terminology 127 For this discussion we will use several terms, which we will define 128 and point out in Figure 1. 130 Private-Address (Priv-Addr): The private address that is known to 131 the internal host. 133 Internal-Port (Int-Port): The port number that is in use by the host 134 holding the Private-Address. 136 Internal-VTag (Int-VTag): The Verification Tag that the internal 137 host has chosen for its communication. The VTag is a unique 32 138 bit tag that must accompany any incoming SCTP packet for this 139 association to the Private-Address. 141 External-Address (Ext-Addr): The address that an internal host is 142 attempting to contact. 144 External-Port (Ext-Port): The port number of the peer process at the 145 External-Address. 147 External-VTag (Ext-VTag): The Verification Tag that the host holding 148 the External-Address has chosen for its communication. The VTag 149 is a unique 32 bit tag that must accompany any incoming SCTP 150 packet for this association to the External-Address. 152 Public-Address (Pub-Addr): The public address assigned to the NAT 153 box which it uses as a source address when sending packets towards 154 the External-Address. 156 Internal Network | External Network 157 | 158 Private | Public External 159 +---------+ Address | Address /--\/--\ Address +---------+ 160 | SCTP | +-----+ / \ | SCTP | 161 |end point|==========| NAT |======= | Internet | ======== |end point| 162 | A | +-----+ \ / | B | 163 +---------+ Internal | \--/\--/ External +---------+ 164 Internal Port | Port External 165 VTag | VTag 167 Figure 1: Architecture 169 4. SCTP NAT Traversal Scenarios 171 This section defines the notion of single and multi-point NAT 172 traversal. 174 4.1. Single Point Traversal 176 In this case, all packets in the SCTP association go through a single 177 NAT, as shown below: 179 Internal Network | External Network 180 | 181 +---------+ | /--\/--\ +---------+ 182 | SCTP | +-----+ / \ | SCTP | 183 |end point|=========| NAT |========= | Internet | ========|end point| 184 | A | +-----+ \ / | B | 185 +---------+ | \--/\--/ +---------+ 186 | 188 Single NAT scenario 190 A variation of this case is shown below, i.e., multiple NATs in a 191 single path: 193 Internal | External : Internal | External 194 | : | 195 +---------+ | : | /--\/--\ +---------+ 196 | SCTP | +-----+ : +-----+ / \ | SCTP | 197 |end point|==| NAT |=======:=======| NAT |==| Internet |==|end point| 198 | A | +-----+ : +-----+ \ / | B | 199 +---------+ | : | \--/\--/ +---------+ 200 | : | 202 Serial NATs scenario 204 In this single point traversal scenario, we must acknowledge that 205 while one of the main benefits of SCTP multi-homing is redundant 206 paths, the NAT function represents a single point of failure in the 207 path of the SCTP multi-home association. However, the rest of the 208 path may still benefit from path diversity provided by SCTP multi- 209 homing. 211 The two SCTP endpoints in this case can be either single-homed or 212 multi-homed. However, the important thing is that the NAT (or NATs) 213 in this case sees all the packets of the SCTP association. 215 4.2. Multi Point Traversal 217 This case involves multiple NATs and each NAT only sees some of the 218 packets in the SCTP association. An example is shown below: 220 Internal | External 221 +------+ /---\/---\ 222 +---------+ /=======|NAT A |=========\ / \ +---------+ 223 | SCTP | / +------+ \/ \ | SCTP | 224 |end point|/ ... | Internet |===|end point| 225 | A |\ \ / | B | 226 +---------+ \ +------+ / \ / +---------+ 227 \=======|NAT B |=========/ \---\/---/ 228 +------+ 229 | 231 Parallel NATs scenario 233 This case does NOT apply to a single-homed SCTP association (i.e., 234 BOTH endpoints in the association use only one IP address). The 235 advantage here is that the existence of multiple NAT traversal points 236 can preserve the path diversity of a multi-homed association for the 237 entire path. This in turn can improve the robustness of the 238 communication. 240 5. Limitations of Classical NAPT for SCTP 242 Using classical NAPT may result in changing one of the SCTP port 243 numbers during the processing which requires the recomputation of the 244 transport layer checksum. Whereas for UDP and TCP this can be done 245 very efficiently, for SCTP the checksum (CRC32c) over the entire 246 packet needs to be recomputed. This would add considerable to the 247 NAT computational burden, however hardware support may mitigate this 248 in some implementations. 250 An SCTP endpoint may have multiple addresses but only has a single 251 port number. To make multipoint traversal work, all the NATs 252 involved must recognize the packets they see as belonging to the same 253 SCTP association and perform port number translation in a consistent 254 way. One possible way of doing this is to use pre-defined table of 255 ports and addresses configured within each NAT. Other mechanisms 256 could make use of NAT to NAT communication. Such mechanisms are 257 considered by the authors not to be deployable on a wide scale base 258 and thus not a recommended solution. Therefore the SCTP variant of 259 NAT has been developed. 261 6. The SCTP Specific Variant of NAT 263 In this section we assume that we have multiple SCTP capable hosts 264 behind a NAT which has one Public-Address. Furthermore we are 265 focusing in this section on the single point traversal scenario. 267 The modification of SCTP packets sent to the public Internet is easy. 268 The source address of the packet has to be replaced with the Public- 269 Address. It may also be necessary to establish some state in the NAT 270 box to handle incoming packets, which is discussed later. 272 For SCTP packets coming from the public Internet the destination 273 address of the packets has to be replaced with the Private-Address of 274 the host the packet has to be delivered to. The lookup of the 275 Private-Address is based on the External-VTag, External-Port, 276 External-Address, Internal-VTag and the Internal-Port. 278 For the SCTP NAT processing the NAT box has to maintain a table of 279 Internal-VTag, Internal-Port, Private-Address, External-VTag, 280 External-Port and whether the restart procedure is disabled or not. 281 An entry in that table is called a NAT state control block. The 282 function Create() obtains the just mentioned parameters and returns a 283 NAT-State control block. 285 The entries in this table fulfill some uniqueness conditions. There 286 must not be more than one entry with the same pair of Internal-Port 287 and External-Port. This rule can be relaxed, if all entries with the 288 same Internal-Port and External-Port have the support for the restart 289 procedure enabled. In this case there must be no more than one entry 290 with the same Internal-Port, External-Port and Ext-VTag and no more 291 than one entry with the same Internal-Port, External-Port and Int- 292 VTag. 294 The processing of outgoing SCTP packets containing an INIT-chunk is 295 described in the following figure. The scenario shown is valid for 296 all message flows in this section. 298 /--\/--\ 299 +--------+ +-----+ / \ +--------+ 300 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 301 +--------+ +-----+ \ / +--------+ 302 \--/\---/ 304 INIT[Initiate-Tag] 305 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 306 Ext-VTag=0 308 Create(Initiate-Tag, Int-Port, Priv-Addr, 0) 309 Returns(NAT-State control block) 311 Translate To: 313 INIT[Initiate-Tag] 314 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 315 Ext-VTag=0 317 It should be noted that normally a NAT control block will be created. 318 However, it is possible that there is already a NAT control block 319 with the same External-Address, External-Port, Internal-Port, and 320 Internal-VTag but different Private-Address. In this case the INIT 321 SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the 322 SCTP host with the M-Bit set and an appropriate error cause (see 323 [I-D.ietf-tsvwg-natsupp] for the format). 325 It is also possible that a connection to External-Address and 326 External-Port exists without an Internal-VTag conflict but the 327 External-Address does not support the DISABLE_RESTART feature (noted 328 in the NAT control block when the prior connection was established). 329 In such a case the INIT SHOULD be dropped by the NAT and an ABORT 330 SHOULD be sent back to the SCTP host with the M-Bit set and an 331 appropriate error cause (see [I-D.ietf-tsvwg-natsupp] for the 332 format). 334 The processing of outgoing SCTP packets containing no INIT-chunk is 335 described in the following figure. 337 /--\/--\ 338 +--------+ +-----+ / \ +--------+ 339 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 340 +--------+ +-----+ \ / +--------+ 341 \--/\---/ 343 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 344 Ext-VTag 346 Translate To: 348 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 349 Ext-VTag 351 The processing of incoming SCTP packets containing INIT-ACK chunks is 352 described in the following figure. The Lookup() function getting as 353 input the Internal-VTag, Internal-Port, External-VTag (=0), External- 354 Port, and External-Address, returns the corresponding entry of the 355 NAT table and updates the External-VTag by substituting it with the 356 value of the Initiate-Tag of the INIT-ACK chunk. The wildcard 357 character signifies that the parameter's value is not considered in 358 the Lookup() function or changed in the Update() function, 359 respectively. 361 /--\/--\ 362 +--------+ +-----+ / \ +--------+ 363 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 364 +--------+ +-----+ \ / +--------+ 365 \--/\---/ 367 INIT-ACK[Initiate-Tag] 368 Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port 369 Int-VTag 371 Lookup(Int-VTag, Int-Port, *, 0, Ext-Port) 372 Update(*, *, *, Initiate-Tag, *) 374 Returns(NAT-State control block containing Private-Address) 376 INIT-ACK[Initiate-Tag] 377 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 378 Int-VTag 380 In the case Lookup fails, the SCTP packet is dropped. The Update 381 routine inserts the External-VTag (the Initiate-Tag of the INIT-ACK 382 chunk) in the NAT state control block. 384 The processing of incoming SCTP packets containing an ABORT or 385 SHUTDOWN-COMPLETE chunk with the T-Bit set is described in the 386 following figure. 388 /--\/--\ 389 +--------+ +-----+ / \ +--------+ 390 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 391 +--------+ +-----+ \ / +--------+ 392 \--/\---/ 394 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 395 Ext-VTag 397 Lookup(0, Int-Port, *, Ext-VTag, Ext-Port) 399 Returns(NAT-State control block containing Private-Address) 401 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 402 Ext-VTag 404 The processing of other incoming SCTP packets is described in the 405 following figure. 407 /--\/--\ 408 +--------+ +-----+ / \ +--------+ 409 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 410 +--------+ +-----+ \ / +--------+ 411 \--/\---/ 413 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 414 Int-VTag 416 Lookup(Int-VTag, Int-Port, *, *, Ext-Port) 418 Returns(NAT-State control block containing Local-Address) 420 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 421 Int-VTag 423 For an incoming packet containing an INIT-chunk a table lookup is 424 made only based on the addresses and port numbers. If an entry with 425 an External-VTag of zero is found, it is considered a match and the 426 External-VTag is updated. 428 This allows the handling of INIT-collision through NAT. 430 7. NAT to SCTP 432 This document at various places discusses the sending of specialized 433 SCTP chunks (e.g. an ABORT with M-Bit set). These chunks and 434 procedures are not defined in this document, but instead are defined 435 in [I-D.ietf-tsvwg-natsupp]. The NAT implementer should refer to 436 [I-D.ietf-tsvwg-natsupp] for detailed descriptions of packet formats 437 and procedures. 439 8. Handling of Fragmented SCTP Packets 441 A NAT box MUST support IP reassembly of received fragmented SCTP 442 packets. The fragments may arrive in any order. 444 When an SCTP packet has to be fragmented by the NAT box and the IP 445 header forbids fragmentation a corresponding ICMP packet SHOULD be 446 sent. 448 9. Various Examples of NAT Traversals 450 9.1. Single-homed Client to Single-homed Server 452 The internal client starts the association with the external server 453 via a four-way-handshake. Host A starts by sending an INIT chunk. 455 /--\/--\ 456 +--------+ +-----+ / \ +--------+ 457 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 458 +--------+ +-----+ \ / +--------+ 459 \--/\---/ 460 +---------+--------+-----------+----------+--------+ 461 NAT | Int | Int | Priv | Ext | Ext | 462 | VTag | Port | Addr | VTag | Port | 463 +---------+--------+--- -------+----------+--------+ 465 INIT[Initiate-Tag = 1234] 466 10.0.0.1:1 ------> 100.0.0.1:2 467 Ext-VTtag = 0 469 A NAT entry is created, the source address is substituted and the 470 packet is sent on: 472 NAT creates entry: 473 +---------+--------+-----------+----------+--------+ 474 NAT | Int | Int | Priv | Ext | Ext | 475 | VTag | Port | Addr | VTag | Port | 476 +---------+--------+-----------+----------+--------+ 477 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 478 +---------+--------+-----------+----------+--------+ 480 INIT[Initiate-Tag = 1234] 481 101.0.0.1:1 --------------------------> 100.0.0.1:2 482 Ext-VTtag = 0 484 Host B receives the INIT and sends an INIT-ACK with the NAT's 485 external address as destination address. 487 /--\/--\ 488 +--------+ +-----+ / \ +--------+ 489 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 490 +--------+ +-----+ \ / +--------+ 491 \--/\---/ 493 INIT-ACK[Initiate-Tag = 5678] 494 101.0.0.1:1 <------------------------- 100.0.0.1:2 495 Int-VTag = 1234 497 NAT updates entry: 498 +---------+--------+-----------+----------+--------+ 499 NAT | Int | Int | Priv | Ext | Ext | 500 | VTag | Port | Addr | VTag | Port | 501 +---------+--------+-----------+----------+--------+ 502 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 503 +---------+--------+-----------+----------+--------+ 505 INIT-ACK[Initiate-Tag = 5678] 506 10.0.0.1:1 <------ 100.0.0.1:2 507 Int-VTag = 1234 509 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 510 ACK. 512 /--\/--\ 513 +--------+ +-----+ / \ +--------+ 514 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 515 +--------+ +-----+ \ / +--------+ 516 \--/\---/ 518 COOKIE-ECHO 519 10.0.0.1:1 ------> 100.0.0.1:2 520 Ext-VTag = 5678 522 COOKIE-ECHO 523 101.0.0.1:1 -------------------------> 100.0.0.1:2 524 Ext-VTag = 5678 526 COOKIE-ACK 527 101.0.0.1:1 <------------------------- 100.0.0.1:2 528 Int-VTag = 1234 530 COOKIE-ACK 531 10.0.0.1:1 <------ 100.0.0.1:2 532 Int-VTag = 1234 534 9.2. Single-homed Client to Multi-homed Server 536 The internal client is single-homed whereas the external server is 537 multi-homed. The client (Host A) sends an INIT like in the single- 538 homed case. 540 +--------+ 541 /--\/--\ /-|Router 1| \ 542 +------+ +-----+ / \ / +--------+ \ +------+ 543 | Host | <-----> | NAT | <-> | Internet | == =| Host | 544 | A | +-----+ \ / \ +--------+ / | B | 545 +------+ \--/\--/ \-|Router 2|-/ +------+ 546 +--------+ 548 +---------+--------+-----------+----------+--------+ 549 NAT | Int | Int | Priv | Ext | Ext | 550 | VTag | Port | Addr | VTag | Port | 551 +---------+--------+-----------+----------+--------+ 553 INIT[Initiate-Tag = 1234] 554 10.0.0.1:1 ---> 100.0.0.1:2 555 Ext-VTag = 0 557 NAT creates entry: 559 +---------+--------+-----------+----------+--------+ 560 NAT | Int | Int | Priv | Ext | Ext | 561 | VTag | Port | Addr | VTag | Port | 562 +---------+--------+-----------+----------+--------+ 563 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 564 +---------+--------+-----------+----------+--------+ 566 INIT[Initiate-Tag = 1234] 567 101.0.0.1:1 ----------------------------> 100.0.0.1:2 568 Ext-VTag = 0 570 The server (Host B) includes its two addresses in the INIT-ACK chunk, 571 which results in two NAT entries. 573 +--------+ 574 /--\/--\ /-|Router 1| \ 575 +------+ +-----+ / \ / +--------+ \ +------+ 576 | Host | <-----> | NAT | <-> | Internet | == =| Host | 577 | A | +-----+ \ / \ +--------+ / | B | 578 +------+ \--/\--/ \-|Router 2|-/ +------+ 579 +--------+ 581 INIT-ACK[Initiate-tag = 5678, IP-Addr = 100.1.0.1] 582 101.0.0.1:1 <---------------------------- 100.0.0.1:2 583 Int-VTag = 1234 585 NAT does need to change the table for second address: 587 +---------+--------+-----------+----------+--------+ 588 NAT | Int | Int | Priv | Ext | Ext | 589 | VTag | Port | Addr | VTag | Port | 590 +---------+--------+-----------+----------+--------+ 591 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 592 +---------+--------+-----------+----------+--------+ 594 INIT-ACK[Initiate-Tag = 5678] 595 10.0.0.1:1 <--- 100.0.0.1:2 596 Int-VTag = 1234 598 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 599 ACK. 601 +--------+ 602 /--\/--\ /-|Router 1| \ 603 +------+ +-----+ / \ / +--------+ \ +------+ 604 | Host | <-----> | NAT | <-> | Internet | == =| Host | 605 | A | +-----+ \ / \ +--------+ / | B | 606 +------+ \--/\--/ \-|Router 2|-/ +------+ 607 +--------+ 609 COOKIE-ECHO 610 10.0.0.1:1 ---> 100.0.0.1:2 611 ExtVTag = 5678 613 COOKIE-ECHO 614 101.0.0.1:1 ----------------------------> 100.0.0.1:2 615 Ext-VTag = 5678 617 COOKIE-ACK 618 101.0.0.1:1 <---------------------------- 100.0.0.1:2 619 Int-VTag = 1234 621 COOKIE-ACK 622 10.0.0.1:1 <--- 100.0.0.1:2 623 Int-VTag = 1234 625 9.3. Multihomed Client and Server 627 The client (Host A) sends an INIT to the server (Host B), but does 628 not include the second address. 630 +-------+ 631 /--| NAT 1 |--\ /--\/--\ 632 +------+ / +-------+ \ / \ +--------+ 633 | Host |=== ====| Internet |====| Host B | 634 | A | \ +-------+ / \ / +--------+ 635 +------+ \--| NAT 2 |--/ \--/\--/ 636 +-------+ 638 +---------+--------+-----------+----------+--------+ 639 NAT 1 | Int | Int | Priv | Ext | Ext | 640 | VTag | Port | Addr | VTag | Port | 641 +---------+--------+--- -------+----------+--------+ 643 INIT[Initiate-Tag = 1234] 644 10.0.0.1:1 --------> 100.0.0.1:2 645 Ext-VTag = 0 646 647 648 NAT 1 creates entry: 649
650 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 703 10.0.0.1:1 --------> 100.0.0.1:2 704 Ext-VTag = 5678 706 COOKIE-ECHO 707 101.0.0.1:1 --------------------> 100.0.0.1:2 708 Ext-VTag = 5678 710 COOKIE-ACK 711 101.0.0.1:1 <-------------------- 100.0.0.1:2 712 Int-VTag = 1234 714 COOKIE-ACK 715 10.0.0.1:1 <------- 100.0.0.1:2 716 Int-VTag = 1234 718 Host A announces its second address in an ASCONF chunk. The address 719 parameter contains an undefined address (0) to indicate that the 720 source address should be added. The lookup address parameter within 721 the ASCONF chunk will also contain the pair of VTags (external and 722 internal) so that the NAT may populate its table completely with this 723 single packet. 725 +-------+ 726 /--------| NAT 1 |--------\ /--\/--\ 727 +------+ / +-------+ \ / \ +--------+ 728 | Host |=== ====| Internet |===| Host B | 729 | A | \ +-------+ / \ / +--------+ 730 +------+ \--------| NAT 2 |--------/ \--/\--/ 731 +-------+ 733 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] 734 10.1.0.1:1 --------> 100.1.0.1:2 735 Ext-VTag = 5678 737 NAT 2 creates complete entry: 739 +---------+--------+-----------+----------+--------+ 740 NAT 2 | Int | Int | Priv | Ext | Ext | 741 | VTag | Port | Addr | VTag | Port | 742 +---------+--------+-----------+----------+--------+ 743 | 1234 | 1 | 10.1.0.1 | 5678 | 2 | 744 +---------+--------+-----------+----------+--------+ 746 ASCONF [ADD-IP,Int-VTag=1234, Ext-VTag = 5678] 747 101.1.0.1:1 -----------------------> 100.1.0.1:2 748 Ext-VTag = 5678 750 ASCONF-ACK 751 101.1.0.1:1 <----------------------- 100.1.0.1:2 752 Int-VTag = 1234 754 ASCONF-ACK 755 10.1.0.1:1 <----- 100.1.0.1:2 756 Int-VTag = 1234 758 9.4. NAT Loses Its State 760 Association is already established between Host A and Host B, when 761 the NAT loses its state and obtains a new public address. Host A 762 sends a DATA chunk to Host B. 764 /--\/--\ 765 +--------+ +-----+ / \ +--------+ 766 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 767 +--------+ +-----+ \ / +--------+ 768 \--/\--/ 770 +---------+--------+-----------+----------+--------+ 771 NAT | Int | Int | Priv | Ext | Ext | 772 | VTag | Port | Addr | VTag | Port | 773 +---------+--------+-----------+----------+--------+ 774 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 775 +---------+--------+-----------+----------+--------+ 777 DATA 778 10.0.0.1:1 ----------> 100.0.0.1:2 779 Ext-VTag = 5678 781 The NAT box cannot find entry for the association. It sends ERROR 782 message with the M-Bit set and the cause "NAT state missing". 784 /--\/--\ 785 +--------+ +-----+ / \ +--------+ 786 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 787 +--------+ +-----+ \ / +--------+ 788 \--/\--/ 790 ERROR [M-Bit, NAT state missing] 791 10.0.0.1:1 <---------- 100.0.0.1:2 792 Ext-VTag = 5678 794 On reception of the ERROR message, Host A sends an ASCONF chunk 795 indicating that the former information has to be deleted and the 796 source address of the actual packet added. 798 /--\/--\ 799 +--------+ +-----+ / \ +--------+ 800 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 801 +--------+ +-----+ \ / +--------+ 802 \--/\--/ 804 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 805 10.0.0.1:1 ----------> 100.1.0.1:2 806 Ext-VTag = 5678 808 +---------+--------+-----------+----------+--------+ 809 NAT | Int | Int | Priv | Ext | Ext | 810 | VTag | Port | Addr | VTag | Port | 811 +---------+--------+-----------+----------+--------+ 812 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 813 +---------+--------+-----------+----------+--------+ 815 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 816 102.1.0.1:1 ---------------------> 100.1.0.1:2 817 Ext-VTag = 5678 819 Host B adds the new source address and deletes all former entries. 821 /--\/--\ 822 +--------+ +-----+ / \ +--------+ 823 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 824 +--------+ +-----+ \ / +--------+ 825 \--/\--/ 827 ASCONF-ACK 828 102.1.0.1:1 <--------------------- 100.1.0.1:2 829 Int-VTag = 1234 831 ASCONF-ACK 832 10.1.0.1:1 <---------- 100.1.0.1:2 833 Int-VTag = 1234 835 DATA 836 10.0.0.1:1 ----------> 100.0.0.1:2 837 Ext-VTag = 5678 838 DATA 839 102.1.0.1:1 ---------------------> 100.1.0.1:2 840 Ext-VTag = 5678 842 9.5. Peer-to-Peer Communication 844 If two hosts are behind NATs, they have to get knowledge of the 845 peer's public address. This can be achieved with a so-called 846 rendezvous server. Afterwards the destination addresses are public, 847 and the association is set up with the help of the INIT collision. 848 The NAT boxes create their entries according to their internal peer's 849 point of view. Therefore, NAT A's Internal-VTag and Internal-Port 850 are NAT B's External-VTag and External-Port, respectively. The 851 naming of the verification tag in the packet flow is done from the 852 sending peer's point of view. 854 Internal | External External | Internal 855 | | 856 | /--\/---\ | 857 +--------+ +-------+ / \ +-------+ +--------+ 858 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 859 +--------+ +-------+ \ / +-------+ +--------+ 860 | \--/\---/ | 862 NAT-Tables 863 +---------+--------+-----------+----------+--------+ 864 NAT A | Int | Int | Priv | Ext | Ext | 865 | VTag | Port | Addr | VTag | Port | 866 +---------+--------+--- -------+----------+--------+ 868 +---------+--------+-----------+----------+--------+ 869 NAT B | Int | Int | Priv | Ext | Ext | 870 | v-tag | port | addr | v-tag | port | 871 +---------+--------+--- -------+----------+--------+ 873 INIT[Initiate-Tag = 1234] 874 10.0.0.1:1 --> 100.0.0.1:2 875 Ext-VTag = 0 877 NAT A creates entry: 879 +---------+--------+-----------+----------+--------+ 880 NAT A | Int | Int | Priv | Ext | Ext | 881 | VTag | Port | Addr | VTag | Port | 882 +---------+--------+-----------+----------+--------+ 883 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 884 +---------+--------+-----------+----------+--------+ 886 INIT[Initiate-Tag = 1234] 887 101.0.0.1:1 ----------------> 100.0.0.1:2 888 Ext-VTag = 0 890 NAT B processes INIT, but cannot find an entry. The SCTP packet is 891 silently discarded and leaves the NAT table of NAT B unchanged. 893 +---------+--------+-----------+----------+--------+ 894 NAT B | Int | Int | Priv | Ext | Ext | 895 | VTag | Port | Addr | VTag | Port | 896 +---------+--------+-----------+----------+--------+ 898 Now Host B sends INIT, which is processed by NAT B. Its parameters 899 are used to create an entry. 901 Internal | External External | Internal 902 | | 903 | /--\/---\ | 904 +--------+ +-------+ / \ +-------+ +--------+ 905 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 906 +--------+ +-------+ \ / +-------+ +--------+ 907 | \--/\---/ | 909 INIT[Initiate-Tag = 5678] 910 101.0.0.1:1 <-- 10.1.0.1:2 911 Ext-VTag = 0 913 +---------+--------+-----------+----------+--------+ 914 NAT B | Int | Int | Priv | Ext | Ext | 915 | VTag | Port | Addr | VTag | Port | 916 +---------+--------+-----------+----------+--------+ 917 | 5678 | 2 | 10.1.0.1 | 0 | 1 | 918 +---------+--------+-----------+----------+--------+ 920 INIT[Initiate-Tag = 5678] 921 101.0.0.1:1 <--------------- 100.0.0.1:2 922 Ext-VTag = 0 924 NAT A processes INIT. As the outgoing INIT of Host A has already 925 created an entry, the entry is found and updated: 927 Internal | External External | Internal 928 | | 929 | /--\/---\ | 930 +--------+ +-------+ / \ +-------+ +--------+ 931 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 932 +--------+ +-------+ \ / +-------+ +--------+ 933 | \--/\---/ | 935 VTag != Int-VTag, but Ext-VTag == 0, find entry. 936 +---------+--------+-----------+----------+--------+ 937 NAT A | Int | Int | Priv | Ext | Ext | 938 | VTag | Port | Addr | VTag | Port | 939 +---------+--------+-----------+----------+--------+ 940 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 941 +---------+--------+-----------+----------+--------+ 943 INIT[Initiate-tag = 5678] 944 10.0.0.1:1 <-- 100.0.0.1:2 945 Ext-VTag = 0 947 Host A send INIT-ACK, which can pass through NAT B: 949 Internal | External External | Internal 950 | | 951 | /--\/---\ | 952 +--------+ +-------+ / \ +-------+ +--------+ 953 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 954 +--------+ +-------+ \ / +-------+ +--------+ 955 | \--/\---/ | 957 INIT-ACK[Initiate-Tag = 1234] 958 10.0.0.1:1 -->; 100.0.0.1:2 959 Ext-VTag = 5678 961 INIT-ACK[Initiate-Tag = 1234] 962 101.0.0.1:1 ----------------> 100.0.0.1:2 963 Ext-VTag = 5678 965 NAT B updates entry: 967 +---------+--------+-----------+----------+--------+ 968 NAT B | Int | Int | Priv | Ext | Ext | 969 | VTag | Port | Addr | VTag | Port | 970 +---------+--------+-----------+----------+--------+ 971 | 5678 | 2 | 10.1.0.1 | 1234 | 1 | 972 +---------+--------+-----------+----------+--------+ 974 INIT-ACK[Initiate-Tag = 1234] 975 101.0.0.1:1 --> 10.1.0.1:2 976 Ext-VTag = 5678 978 The lookup for COOKIE-ECHO and COOKIE-ACK is successful. 980 Internal | External External | Internal 981 | | 982 | /--\/---\ | 983 +--------+ +-------+ / \ +-------+ +--------+ 984 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 985 +--------+ +-------+ \ / +-------+ +--------+ 986 | \--/\---/ | 988 COOKIE-ECHO 989 101.0.0.1:1 <-- 10.1.0.1:2 990 Ext-VTag = 1234 992 COOKIE-ECHO 993 101.0.0.1:1 <------------- 100.0.0.1:2 994 Ext-VTag = 1234 996 COOKIE-ECHO 997 10.0.0.1:1 <-- 100.0.0.1:2 998 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, 1034 RFC 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", 1040 RFC 4960, September 2007. 1042 13.2. Informative References 1044 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 1045 BCP 153, RFC 5735, January 2010. 1047 [I-D.ietf-tsvwg-natsupp] 1048 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 1049 Transmission Protocol (SCTP) Network Address Translation 1050 Support", draft-ietf-tsvwg-natsupp-02 (work in progress), 1051 March 2012. 1053 Authors' Addresses 1055 Randall R. Stewart 1056 Adara Networks 1057 Chapin, SC 29036 1058 US 1060 Email: randall@lakerest.net 1061 Michael Tuexen 1062 Muenster University of Applied Sciences 1063 Stegerwaldstrasse 39 1064 48565 Steinfurt 1065 DE 1067 Email: tuexen@fh-muenster.de 1069 Irene Ruengeler 1070 Muenster University of Applied Sciences 1071 Stegerwaldstrasse 39 1072 48565 Steinfurt 1073 DE 1075 Email: i.ruengeler@fh-muenster.de