idnits 2.17.1 draft-ietf-behave-sctpnat-05.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 (June 26, 2011) is 4688 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 363, but not defined == Unused Reference: 'RFC1918' is defined on line 1043, 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 Adara Networks 4 Intended status: BCP M. Tuexen 5 Expires: December 28, 2011 I. Ruengeler 6 Muenster Univ. of Applied 7 Sciences 8 June 26, 2011 10 Stream Control Transmission Protocol (SCTP) Network Address Translation 11 draft-ietf-behave-sctpnat-05.txt 13 Abstract 15 Stream Control Transmission Protocol [RFC4960] provides a reliable 16 communications channel between two end-hosts in many ways similar to 17 TCP [RFC0793]. With the widespread deployment of Network Address 18 Translators (NAT), specialized code has been added to NAT for TCP 19 that allows multiple hosts to reside behind a NAT and yet use only a 20 single globally unique IPv4 address, even when two hosts (behind a 21 NAT) choose the same port numbers for their connection. This 22 additional code is sometimes classified as Network Address and Port 23 Translation or NAPT. To date, specialized code for SCTP has NOT yet 24 been added to most NATs so that only pure NAT is available. The end 25 result of this is that only one SCTP capable host can be behind a 26 NAT. 28 This document describes an SCTP specific variant of NAT which 29 provides similar features of NAPT in the single point and multi-point 30 traversal scenario. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 28, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 4 70 4.1. Single Point Traversal . . . . . . . . . . . . . . . . . . 4 71 4.2. Multi Point Traversal . . . . . . . . . . . . . . . . . . 5 72 5. Limitations of classical NAPT for SCTP . . . . . . . . . . . . 6 73 6. The SCTP specific variant of NAT . . . . . . . . . . . . . . . 6 74 7. Nat to SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Handling of fragmented SCTP packets . . . . . . . . . . . . . 10 76 9. Simplification for small NATs . . . . . . . . . . . . . . . . 10 77 10. Various examples of NAT traversals . . . . . . . . . . . . . . 10 78 10.1. Single-homed client to single-homed server . . . . . . . . 10 79 10.2. Single-homed client to multi-homed server . . . . . . . . 13 80 10.3. Multihomed client and server . . . . . . . . . . . . . . . 15 81 10.4. NAT loses its state . . . . . . . . . . . . . . . . . . . 18 82 10.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . . 20 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 84 12. Security considerations . . . . . . . . . . . . . . . . . . . 24 85 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 88 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 Stream Control Transmission Protocol [RFC4960] provides a reliable 94 communications channel between two end-hosts in many ways similar to 95 TCP [RFC0793]. With the widespread deployment of Network Address 96 Translators (NAT), specialized code has been added to NAT for TCP 97 that allows multiple hosts to reside behind a NAT and yet use only a 98 single globally unique IPv4 address, even when two hosts (behind a 99 NAT) choose the same port numbers for their connection. This 100 additional code is sometimes classified as Network Address and Port 101 Translation or NAPT. To date, specialized code for SCTP has NOT yet 102 been added to most NATs so that only true NAT is available. The end 103 result of this is that only one SCTP capable host can be behind a 104 NAT. 106 This document proposes an SCTP specific variant NAT that provides the 107 NAPT functionality without changing SCTP port numbers. The authors 108 feel it is possible and desirable to make these changes for a number 109 of reasons. 111 o It is desirable for SCTP internal end-hosts on multiple platforms 112 to be able to share a NAT's public IP address, much as TCP does 113 today. 115 o If a NAT does not need to change any data within an SCTP packet it 116 will reduce the processing burden of NAT'ing SCTP by NOT needing 117 to execute the CRC32c checksum required by SCTP. 119 o Not having to touch the IP payload makes the processing of ICMP 120 messages in NATs easier. 122 2. Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 3. Terminology 130 For this discussion we will use several terms, which we will define 131 and point out in a figure. 133 o Private-Address (Priv-Addr) - The private address that is known to 134 the internal host. 136 o Internal-Port (Int-Port) - The port number that is in use by the 137 host holding the Private-Address. 139 o Internal-VTag (Int-VTag) - The Verification Tag that the internal 140 host has chosen for its communication. The VTag is a unique 32 141 bit tag that must accompany any incoming SCTP packet for this 142 association to the Private-Address. 144 o External-Address (Ext-Addr) - The address that an internal host is 145 attempting to contact. 147 o External-Port (Ext-Port) - The port number of the peer process at 148 the External-Address. 150 o External-VTag (Ext-VTag) - The Verification Tag that the host 151 holding the External-Address has chosen for its communication. 152 The VTag is a unique 32 bit tag that must accompany any incoming 153 SCTP packet for this association to the External-Address. 155 o Public-Address (Pub-Addr) - The public address assigned to the NAT 156 box which it uses as a source address when sending packets towards 157 the External-Address. 159 Internal Network | External Network 160 | 161 Private | Public External 162 +---------+ Address | Address /--\/--\ Address +---------+ 163 | SCTP | +-----+ / \ | SCTP | 164 |end point|==========| NAT |======= | Internet | ========== |end point| 165 | A | +-----+ \ / | B | 166 +---------+ Internal | \--/\--/ External +---------+ 167 Internal Port | Port External 168 VTag | VTag 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 A variation of this case is shown below, i.e., multiple NATs in a 190 single path: 192 Internal | External :: Internal | External 193 | :: | 194 +---------+ | :: | /--\/--\ +---------+ 195 | SCTP | +-----+ :: +-----+ / \ | SCTP | 196 |end point|===| NAT |=======::=======| NAT |==| Internet |==|end point| 197 | A | +-----+ :: +-----+ \ / | B | 198 +---------+ | :: | \--/\--/ +---------+ 199 | :: | 201 In this single point traversal scenario, we must acknowledge that 202 while one of the main benefits of SCTP multi-homing is redundant 203 paths, the NAT function represents a single point of failure in the 204 path of the SCTP multi-home association. However, the rest of the 205 path may still benefit from path diversity provided by SCTP multi- 206 homing. 208 The two SCTP endpoints in this case can be either single-homed or 209 multi-homed. However, the important thing is that the NAT (or NATs) 210 in this case sees ALL the packets of the SCTP association. 212 4.2. Multi Point Traversal 214 This case involves multiple NATs and each NAT only sees some of the 215 packets in the SCTP association. An example is shown below: 217 Internal | External 218 +------+ /---\/---\ 219 +---------+ /=======|NAT A |=========\ / \ +---------+ 220 | SCTP | / +------+ \/ \ | SCTP | 221 |end point|/ ... | Internet |=====|end point| 222 | A |\ \ / | B | 223 +---------+ \ +------+ / \ / +---------+ 224 \=======|NAT B |=========/ \---\/---/ 225 +------+ 226 | 228 This case does NOT apply to a single-homed SCTP association (i.e., 229 BOTH endpoints in the association use only one IP address). The 230 advantage here is that the existence of multiple NAT traversal points 231 can preserve the path diversity of a multi-homed association for the 232 entire path. This in turn can improve the robustness of the 233 communication. 235 5. Limitations of classical NAPT for SCTP 237 Using classical NAPT may result in changing one of the SCTP port 238 numbers during the processing which requires the recomputation of the 239 transport layer checksum. Whereas for UDP and TCP this can be done 240 very efficently, for SCTP the checksum (CRC32c) over the entire 241 packet needs to be recomputed. This would add considerable to the 242 NAT computational burden, however hardware support may mitigate this 243 in some implementations. 245 An SCTP endpoint may have multiple addresses but only has a single 246 port number. To make multipoint travesal work, all the NATs involved 247 must recognize the packets they see as belonging to the same SCTP 248 association and perform port number translation in a consistent way. 249 One possible way of doing this is to use pre-defined table of ports 250 and addresses configured within each NAT. Other mechanisms could 251 make use of NAT to NAT communcation. Such mechanisms are considered 252 by the authors to be undeployable on a wide scale base and thus not a 253 recommended solution. Therefore the SCTP variant of NAT has been 254 developed. 256 6. The SCTP specific variant of NAT 258 In this section we assume that we have multiple SCTP capable hosts 259 behind a NAT which has one Public-Address. Furthermore we are 260 focusing in this section on the single point traversal scenario. 262 The modification of SCTP packets sent to the public Internet is easy. 263 The source address of the packet has to be replaced with the Public- 264 Address. It may also be necessary to establish some state in the NAT 265 box to handle incoming packets, which is discussed later. 267 For SCTP packets coming from the public Internet the destination 268 address of the packets has to be replaced with the Private-Address of 269 the host the packet has to be delivered to. The lookup of the 270 Private-Address is based on the External-VTag, External-Port, 271 External-Address, Internal-VTag and the Internal-Port. 273 For the SCTP NAT processing the NAT box has to maintain a table of 274 Internal-VTag, Internal-Port, Private-Address, External-VTag, 275 External-Port and External-Address. An entry in that table is called 276 a NAT state control block. The function Create() obtains the just 277 mentioned parameters and returns a NAT-State control block. 279 The processing of outgoing SCTP packets containing an INIT-chunk is 280 described in the following figure. The scenario shown is valid for 281 all message flows in this section. 283 /--\/--\ 284 +--------+ +-----+ / \ +--------+ 285 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 286 +--------+ +-----+ \ / +--------+ 287 \--/\---/ 289 INIT[Initiate-Tag] 290 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 291 Ext-VTag=0 293 Create(Initiate-Tag,Internal-Port,Private-Address, 294 0,External-Port,External-Address) 295 Returns(NAT-State control block) 297 Translate To: 299 INIT[Initiate-Tag] 300 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 301 Ext-VTag=0 303 It should be noted that normally a NAT control block will be created. 304 However, it is possible that there is already a NAT control block 305 with the same External-Address, External-Port, Internal-Port, and 306 Internal-VTag but different Private-Address. In this case the INIT 307 SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the 308 SCTP host with the M-Bit set and an appropriate error cause [please 309 see xxx-tsvwg-document-xx for the format]. 311 It is also possible that a connection to External-Address and 312 External-Port exists without an Internal-VTag conflict but the 313 External-Address does not support the DISABLE_RESTART feature (noted 314 in the NAT control block when the prior connection was established). 315 In such a case the INIT SHOULD be dropped by the NAT and an ABORT 316 SHOULD be sent back to the SCTP host with the M-Bit set and an 317 appropriate error cause [please see xxx-tsvwg-document-xx for the 318 format]. 320 The processing of outgoing SCTP packets containing no INIT-chunk is 321 described in the following figure. 323 /--\/--\ 324 +--------+ +-----+ / \ +--------+ 325 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 326 +--------+ +-----+ \ / +--------+ 327 \--/\---/ 329 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 330 Ext-VTag 332 Translate To: 334 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 335 Ext-VTag 337 The processing of incoming SCTP packets containing INIT-ACK chunks is 338 described in the following figure. The Lookup() function getting as 339 input the Internal-VTag, Internal-Port, External-VTag (=0), External- 340 Port, and External-Address, returns the corresponding entry of the 341 NAT table and updates the External-VTag by substituting it with the 342 value of the Initiate-Tag of the INIT-ACK chunk. The wildcard 343 character signifies that the parameter's value is not considered in 344 the Lookup() function or changed in the Update() function, 345 respectively. 347 /--\/--\ 348 +--------+ +-----+ / \ +--------+ 349 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 350 +--------+ +-----+ \ / +--------+ 351 \--/\---/ 353 INIT-ACK[Initiate-Tag] 354 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 355 Int-VTag 357 Lookup(Internal-VTag,Internal-Port,*, 358 0,External-Port,External-Address) 359 Update(*, *, *, Initiate-Tag, *, *) 361 Returns(NAT-State control block containing Private-Address) 363 INIT-ACK[Initiate-Tag] 364 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 365 Int-VTag 367 In the case Lookup fails, the SCTP packet is dropped. The Update 368 routine inserts the External-VTag (the Initiate-Tag of the INIT-ACK 369 chunk) in the NAT state control block. 371 The processing of incoming SCTP packets containing an ABORT or 372 SHUTDOWN-COMPLETE chunk with the T-Bit set is described in the 373 following figure. 375 /--\/--\ 376 +--------+ +-----+ / \ +--------+ 377 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 378 +--------+ +-----+ \ / +--------+ 379 \--/\---/ 381 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 382 Ext-VTag 384 Lookup(0, Internal-Port, *,External-VTag, 385 External-Port, External-Address) 387 Returns(NAT-State control block containing Private-Address) 389 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 390 Ext-VTag 392 The processing of other incoming SCTP packets is described in the 393 following figure. 395 /--\/--\ 396 +--------+ +-----+ / \ +--------+ 397 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 398 +--------+ +-----+ \ / +--------+ 399 \--/\---/ 401 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 402 Int-VTag 404 Lookup(Internal-VTag, Internal-Port, *, 405 *, External-Port, External-Address) 407 Returns(NAT-State control block containing Local-Address) 409 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 410 Int-VTag 412 For an incoming packet containing an INIT-chunk a table lookup is 413 made only based on the addresses and port numbers. If an entry with 414 an External-VTag of zero is found, it is considered a match and the 415 External-VTag is updated. 417 This allows the handling of INIT-collision through NAT. 419 7. Nat to SCTP 421 This document at various places discusses the sending of specialized 422 SCTP chunks (e.g. an ABORT with M-Bit set). These chunks and 423 proceedures are not defined in this document, but instead are defined 424 in [xxxxx]. The NAT implementor should refer to [xxxx] for detailed 425 descriptions of packet format and procedures. 427 8. Handling of fragmented SCTP packets 429 A NAT box MUST support IP reassembly of received fragmented SCTP 430 packets. The fragments may arrive in any order. 432 When an SCTP packet has to be fragmented by the NAT box and the IP 433 header forbids fragmentation a corresponding ICMP packet SHOULD be 434 sent. 436 9. Simplification for small NATs 438 Small NAT boxes, i.e. NAT boxes which only have to support a small 439 number of concurrent SCTP associations, MAY not take the external 440 address into account when processing packets. Therefore the 441 External-Address could also be removed from the NAT table. 443 This simplification may make implementing a NAT box easier, however, 444 the collision probability is higher than using a mapping which takes 445 the external address into account. 447 10. Various examples of NAT traversals 449 10.1. Single-homed client to single-homed server 451 The internal client starts the association with the external server 452 via a four-way-handshake. Host A starts by sending an INIT chunk. 454 /--\/--\ 455 +--------+ +-----+ / \ +--------+ 456 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 457 +--------+ +-----+ \ / +--------+ 458 \--/\---/ 459 +---------+--------+-----------+----------+--------+-----------+ 460 NAT | Int | Int | Priv | Ext | Ext | Ext | 461 | VTag | Port | Addr | VTag | Port | Addr | 462 +---------+--------+--- -------+----------+--------+-----------+ 464 INIT[Initiate-Tag = 1234] 465 10.0.0.1:1 ------> 100.0.0.1:2 466 Ext-VTtag = 0 468 A NAT entry is created, the source address is substituted and the 469 packet is sent on: 471 NAT creates entry: 472 +---------+--------+-----------+----------+--------+-----------+ 473 NAT | Int | Int | Priv | Ext | Ext | Ext | 474 | VTag | Port | Addr | VTag | Port | Addr | 475 +---------+--------+-----------+----------+--------+-----------+ 476 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 477 +---------+--------+-----------+----------+--------+-----------+ 479 INIT[Initiate-Tag = 1234] 480 101.0.0.1:1 ---------------------------> 100.0.0.1:2 481 Ext-VTtag = 0 483 Host B receives the INIT and sends an INIT-ACK with the NAT's 484 external address as destination address. 486 /--\/--\ 487 +--------+ +-----+ / \ +--------+ 488 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 489 +--------+ +-----+ \ / +--------+ 490 \--/\---/ 492 INIT-ACK[Initiate-Tag = 5678] 493 101.0.0.1:1 <--------------------------- 100.0.0.1:2 494 Int-VTag = 1234 496 NAT updates entry: 497 +---------+--------+-----------+----------+--------+-----------+ 498 NAT | Int | Int | Priv | Ext | Ext | Ext | 499 | VTag | Port | Addr | VTag | Port | Addr | 500 +---------+--------+-----------+----------+--------+-----------+ 501 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 502 +---------+--------+-----------+----------+--------+-----------+ 504 INIT-ACK[Initiate-Tag = 5678] 505 10.0.0.1:1 <------ 100.0.0.1:2 506 Int-VTag = 1234 508 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 509 ACK. 511 /--\/--\ 512 +--------+ +-----+ / \ +--------+ 513 | Host A | <-------> | NAT | <------> | Internet | <-------> | Host B | 514 +--------+ +-----+ \ / +--------+ 515 \--/\---/ 517 COOKIE-ECHO 518 10.0.0.1:1 ------> 100.0.0.1:2 519 Ext-VTag = 5678 521 COOKIE-ECHO 522 101.0.0.1:1 ---------------------------> 100.0.0.1:2 523 Ext-VTag = 5678 525 COOKIE-ACK 526 101.0.0.1:1 <--------------------------- 100.0.0.1:2 527 Int-VTag = 1234 529 COOKIE-ACK 530 10.0.0.1:1 <------ 100.0.0.1:2 531 Int-VTag = 1234 533 10.2. Single-homed client to multi-homed server 535 The internal client is single-homed whereas the external server is 536 multi-homed. The client (Host A) sends an INIT like in the single- 537 homed case. 539 +--------+ 540 /--\/--\ /-|Router 1| \ 541 +------+ +-----+ / \ / +--------+ \ +------+ 542 | Host | <------> | NAT | <-> | Internet | == ==| Host | 543 | A | +-----+ \ / \ +--------+ / | B | 544 +------+ \--/\--/ \-|Router 2|-/ +------+ 545 +--------+ 547 +---------+--------+-----------+----------+--------+-----------+ 548 NAT | Int | Int | Priv | Ext | Ext | Ext | 549 | VTag | Port | Addr | VTag | Port | Addr | 550 +---------+--------+--- -------+----------+--------+-----------+ 552 INIT[Initiate-Tag = 1234] 553 10.0.0.1:1 ---> 100.0.0.1:2 554 Ext-VTag = 0 556 NAT creates entry: 558 +---------+--------+-----------+----------+--------+-----------+ 559 NAT | Int | Int | Priv | Ext | Ext | Ext | 560 | VTag | Port | Addr | VTag | Port | Addr | 561 +---------+--------+-----------+----------+--------+-----------+ 562 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 563 +---------+--------+-----------+----------+--------+-----------+ 565 INIT[Initiate-Tag = 1234] 566 101.0.0.1:1 ------------------------------> 100.0.0.1:2 567 Ext-VTag = 0 569 The server (Host B) includes its two addresses in the INIT-ACK chunk, 570 which results in two NAT entries. 572 +--------+ 573 /--\/--\ /-|Router 1| \ 574 +------+ +-----+ / \ / +--------+ \ +------+ 575 | Host | <------> | NAT | <-> | Internet | == ==| Host | 576 | A | +-----+ \ / \ +--------+ / | B | 577 +------+ \--/\--/ \-|Router 2|-/ +------+ 578 +--------+ 580 INIT-ACK[Initiate-tag = 5678, IP-Addr = 100.1.0.1] 581 101.0.0.1:1 <------------------------------ 100.0.0.1:2 582 Int-VTag = 1234 584 NAT updates first entry and creates entry for second address: 586 +---------+--------+-----------+----------+--------+-----------+ 587 NAT | Int | Int | Priv | Ext | Ext | Ext | 588 | VTag | Port | Addr | VTag | Port | Addr | 589 +---------+--------+-----------+----------+--------+-----------+ 590 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 591 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.1.0.1 | 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 10.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 | Ext | 640 | VTag | Port | Addr | VTag | Port | Addr | 641 +---------+--------+--- -------+----------+--------+-----------+ 643 INIT[Initiate-Tag = 1234] 644 10.0.0.1:1 --------> 100.0.0.1:2 645 Ext-VTag = 0 647 NAT 1 creates entry: 649 +---------+--------+-----------+----------+--------+-----------+ 650 NAT 1 | Int | Int | Priv | Ext | Ext | Ext | 651 | VTag | Port | Addr | VTag | Port | Addr | 652 +---------+--------+-----------+----------+--------+-----------+ 653 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 654 +---------+--------+-----------+----------+--------+-----------+ 656 INIT[Initiate-Tag = 1234] 657 101.0.0.1:1 -------------------------> 100.0.0.1:2 658 ExtVTag = 0 660 Host B includes its second address in the INIT-ACK, which results in 661 two NAT entries in NAT 1. 663 +-------+ 664 /--------| NAT 1 |--------\ /--\/--\ 665 +------+ / +-------+ \ / \ +--------+ 666 | Host |==== ====| Internet |====| Host B | 667 | A | \ +-------+ / \ / +--------+ 668 +------+ \--------| NAT 2 |--------/ \--/\--/ 669 +-------+ 671 INIT-ACK[Initiate-Tag = 5678, IP-Addr = 100.1.0.1] 672 101.0.0.1:1 <------------------------- 100.0.0.1:2 673 Int-VTag = 1234 675 NAT 1 updates first entry and creates complete entry for second 676 address: 678 +---------+--------+-----------+----------+--------+-----------+ 679 NAT 1 | Int | Int | Priv | Ext | Ext | Ext | 680 | VTag | Port | Addr | VTag | Port | Addr | 681 +---------+--------+-----------+----------+--------+-----------+ 682 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 683 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.1.0.1 | 684 +---------+--------+-----------+----------+--------+-----------+ 686 INIT-ACK[Initiate-Tag = 5678] 687 10.0.0.1:1 <---------100.0.0.1:2 688 Int-VTag = 1234 690 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 691 ACK. 693 +-------+ 694 /--------| NAT 1 |--------\ /--\/--\ 695 +------+ / +-------+ \ / \ +--------+ 696 | Host |==== ====| Internet |====| Host B | 697 | A | \ +-------+ / \ / +--------+ 698 +------+ \--------| NAT 2 |--------/ \--/\--/ 699 +-------+ 701 COOKIE-ECHO 702 10.0.0.1:1 --------> 100.0.0.1:2 703 Ext-VTag = 5678 705 COOKIE-ECHO 706 101.0.0.1:1 ----------------------> 100.0.0.1:2 707 Ext-VTag = 5678 709 COOKIE-ACK 710 101.0.0.1:1 <---------------------- 100.0.0.1:2 711 Int-VTag = 1234 713 COOKIE-ACK 714 10.0.0.1:1 <------- 100.0.0.1:2 715 Int-VTag = 1234 717 Host A announces its second address in an ASCONF. The address 718 parameter contains an undefined address (0) to indicate that the 719 source address should be added. The lookup address pararmeter within 720 the ASCONF chunk will also contain the pair of Vtags (external and 721 internal) so that the NAT may populate its table completely with this 722 single packet. 724 +-------+ 725 /--------| NAT 1 |--------\ /--\/--\ 726 +------+ / +-------+ \ / \ +--------+ 727 | Host |==== ====| Internet |====| Host B | 728 | A | \ +-------+ / \ / +--------+ 729 +------+ \--------| NAT 2 |--------/ \--/\--/ 730 +-------+ 732 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] 733 10.1.0.1:1 --------> 100.1.0.1:2 734 Ext-VTag = 5678 736 NAT 2 creates complete entry: 738 +---------+--------+-----------+----------+--------+-----------+ 739 NAT 2 | Int | Int | Priv | Ext | Ext | Ext | 740 | VTag | Port | Addr | VTag | Port | Addr | 741 +---------+--------+-----------+----------+--------+-----------+ 742 | 1234 | 1 | 10.1.0.1 | 5678 | 2 | 100.1.0.1 | 743 +---------+--------+-----------+----------+--------+-----------+ 745 ASCONF [ADD-IP,Int-VTag=1234, Ext-VTag = 5678] 746 101.1.0.1:1 -------------------------> 100.1.0.1:2 747 Ext-VTag = 5678 749 ASCONF-ACK 750 101.1.0.1:1 <------------------------- 100.1.0.1:2 751 Int-VTag = 1234 753 ASCONF-ACK 754 10.1.0.1:1 <----- 100.1.0.1:2 755 Int-VTag = 1234 757 10.4. NAT loses its state 759 Assocation is already established between Host A and Host B, when the 760 NAT loses its state and obtains a new public address. Host A sends a 761 DATA chunk to Host B. 763 /--\/--\ 764 +--------+ +-----+ / \ +--------+ 765 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 766 +--------+ +-----+ \ / +--------+ 767 \--/\--/ 769 +---------+--------+-----------+----------+--------+-----------+ 770 NAT A | Int | Int | Priv | Ext | Ext | Ext | 771 | VTag | Port | Addr | VTag | Port | Addr | 772 +---------+--------+-----------+----------+--------+-----------+ 773 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 774 +---------+--------+-----------+----------+--------+-----------+ 776 DATA 777 10.0.0.1:1 ----------> 100.0.0.1:2 778 Ext-VTag = 5678 780 The NAT box cannot find entry for the association. It sends ERROR 781 message with the M-Bit set and the cause "NAT state missing". 783 /--\/--\ 784 +--------+ +-----+ / \ +--------+ 785 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 786 +--------+ +-----+ \ / +--------+ 787 \--/\--/ 789 ERROR [M-Bit, NAT state missing] 790 10.0.0.1:1 <---------- 100.0.0.1:2 791 Ext-VTag = 5678 793 On reception of the ERROR message, HOST A sends an ASCONF indicating 794 that the former information has to be deleted and the source address 795 of the actual packet added. 797 /--\/--\ 798 +--------+ +-----+ / \ +--------+ 799 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 800 +--------+ +-----+ \ / +--------+ 801 \--/\--/ 803 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 804 10.0.0.1:1 ----------> 100.1.0.1:2 805 Ext-VTag = 5678 807 +---------+--------+-----------+----------+--------+-----------+ 808 NAT A | Int | Int | Priv | Ext | Ext | Ext | 809 | VTag | Port | Addr | VTag | Port | Addr | 810 +---------+--------+-----------+----------+--------+-----------+ 811 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 812 +---------+--------+-----------+----------+--------+-----------+ 814 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 815 102.1.0.1:1 -----------------------> 100.1.0.1:2 816 Ext-VTag = 5678 818 Host B adds the new source address and deletes all former entries. 820 /--\/--\ 821 +--------+ +-----+ / \ +--------+ 822 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 823 +--------+ +-----+ \ / +--------+ 824 \--/\--/ 826 ASCONF-ACK 827 102.1.0.1:1 <----------------------- 100.1.0.1:2 828 Int-VTag = 1234 830 ASCONF-ACK 831 10.1.0.1:1 <---------- 100.1.0.1:2 832 Int-VTag = 1234 1 834 DATA 835 10.0.0.1:1 ----------> 100.0.0.1:2 836 Ext-VTag = 5678 837 DATA 838 102.1.0.1:1 -----------------------> 100.1.0.1:2 839 Ext-VTag = 5678 841 10.5. Peer-to-Peer Communication 843 If two hosts are behind NATs, they have to get knowledge of the 844 peer's public address. This can be achieved with a so-called 845 rendezvous server. Afterwards the destination addresses are public, 846 and the association is set up with the help of the INIT collision. 847 The NAT boxes create their entries according to their internal peer's 848 point of view. Therefore, NAT A's Internal-VTag and Internal-Port 849 are NAT B's External-VTag and External-Port, respectively. The 850 naming of the verification tag in the packet flow is done from the 851 sending peer's point of view. 853 Internal | External External | Internal 854 | | 855 | /--\/---\ | 856 +--------+ +-------+ / \ +-------+ +--------+ 857 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 858 +--------+ +-------+ \ / +-------+ +--------+ 859 | \--/\---/ | 861 NAT-Tables 862 +---------+--------+-----------+----------+--------+-----------+ 863 NAT A | Int | Int | Priv | Ext | Ext | Ext | 864 | VTag | Port | Addr | VTag | Port | Addr | 865 +---------+--------+--- -------+----------+--------+-----------+ 867 +---------+--------+-----------+----------+--------+-----------+ 868 NAT B | Int | Int | Priv | Ext | Ext | Ext | 869 | v-tag | port | addr | v-tag | port | addr | 870 +---------+--------+--- -------+----------+--------+-----------+ 872 INIT[Initiate-Tag = 1234] 873 10.0.0.1:1 --> 100.0.0.1:2 874 Ext-VTag = 0 876 NAT A creates entry: 878 +---------+--------+-----------+----------+--------+-----------+ 879 NAT A | Int | Int | Priv | Ext | Ext | Ext | 880 | VTag | Port | Addr | VTag | Port | Addr | 881 +---------+--------+-----------+----------+--------+-----------+ 882 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 100.0.0.1 | 883 +---------+--------+-----------+----------+--------+-----------+ 885 INIT[Initiate-Tag = 1234] 886 101.0.0.1:1 ----------------> 100.0.0.1:2 887 Ext-VTag = 0 889 NAT B processes INIT, but cannot find an entry. The SCTP packet is 890 silently discarded and leaves the NAT table of NAT B unchanged. 892 +---------+--------+-----------+----------+--------+-----------+ 893 NAT B | Int | Int | Priv | Ext | Ext | Ext | 894 | VTag | Port | Addr | VTag | Port | Addr | 895 +---------+--------+-----------+----------+--------+-----------+ 897 Now Host B sends INIT, which is processed by NAT B. Its parameters 898 are used to create an entry. 900 Internal | External External | Internal 901 | | 902 | /--\/---\ | 903 +--------+ +-------+ / \ +-------+ +--------+ 904 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 905 +--------+ +-------+ \ / +-------+ +--------+ 906 | \--/\---/ | 908 INIT[Initiate-Tag = 5678] 909 101.0.0.1:1 <-- 10.1.0.1:2 910 Ext-VTag = 0 912 +---------+--------+-----------+----------+--------+-----------+ 913 NAT B | Int | Int | Priv | Ext | Ext | Ext | 914 | VTag | Port | Addr | VTag | Port | Addr | 915 +---------+--------+-----------+----------+--------+-----------+ 916 | 5678 | 2 | 10.1.0.1 | 0 | 1 | 101.0.0.1 | 917 +---------+--------+-----------+----------+--------+-----------+ 919 INIT[Initiate-Tag = 5678] 920 101.0.0.1:1 <--------------- 100.0.0.1:2 921 Ext-VTag = 0 923 NAT A processes INIT. As the outgoing INIT of Host A has already 924 created an entry, the entry is found and updated: 926 Internal | External External | Internal 927 | | 928 | /--\/---\ | 929 +--------+ +-------+ / \ +-------+ +--------+ 930 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 931 +--------+ +-------+ \ / +-------+ +--------+ 932 | \--/\---/ | 934 VTag != Int-VTag, but Ext-VTag == 0, find entry. 935 +---------+--------+-----------+----------+--------+-----------+ 936 NAT A | Int | Int | Priv | Ext | Ext | Ext | 937 | VTag | Port | Addr | VTag | Port | Addr | 938 +---------+--------+-----------+----------+--------+-----------+ 939 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 100.0.0.1 | 940 +---------+--------+-----------+----------+--------+-----------+ 942 INIT[Initiate-tag = 5678] 943 10.0.0.1:1 <-- 100.0.0.1:2 944 Ext-VTag = 0 946 Host A send INIT-ACK, which can pass through NAT B: 948 Internal | External External | Internal 949 | | 950 | /--\/---\ | 951 +--------+ +-------+ / \ +-------+ +--------+ 952 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 953 +--------+ +-------+ \ / +-------+ +--------+ 954 | \--/\---/ | 956 INIT-ACK[Initiate-Tag = 1234] 957 10.0.0.1:1 --> 100.0.0.1:2 958 Ext-VTag = 5678 960 INIT-ACK[Initiate-Tag = 1234] 961 101.0.0.1:1 ----------------> 100.0.0.1:2 962 Ext-VTag = 5678 964 NAT B updates entry: 966 +---------+--------+-----------+----------+--------+-----------+ 967 NAT B | Int | Int | Priv | Ext | Ext | Ext | 968 | VTag | Port | Addr | VTag | Port | Addr | 969 +---------+--------+-----------+----------+--------+-----------+ 970 | 5678 | 2 | 10.1.0.1 | 1234 | 1 | 101.0.0.1 | 971 +---------+--------+-----------+----------+--------+-----------+ 973 INIT-ACK[Initiate-Tag = 1234] 974 101.0.0.1:1 --> 10.1.0.1:2 975 Ext-VTag = 5678 977 The lookup for COOKIE-ECHO and COOKIE-ACK is successful. 979 Internal | External External | Internal 980 | | 981 | /--\/---\ | 982 +--------+ +-------+ / \ +-------+ +--------+ 983 | Host A |<---->| NAT A |<-->| Internet |<-->| NAT B |<---->| Host B | 984 +--------+ +-------+ \ / +-------+ +--------+ 985 | \--/\---/ | 987 COOKIE-ECHO 988 101.0.0.1:1 <-- 10.1.0.1:2 989 Ext-VTag = 1234 991 COOKIE-ECHO 992 101.0.0.1:1 <------------- 100.0.0.1:2 993 Ext-VTag = 1234 995 COOKIE-ECHO 996 10.0.0.1:1 <-- 100.0.0.1:2 997 Ext-VTag = 1234 999 COOKIE-ACK 1000 10.0.0.1:1 --> 100.0.0.1:2 1001 Ext-VTag = 5678 1003 COOKIE-ACK 1004 101.0.0.1:1 ----------------> 100.0.0.1:2 1005 Ext-VTag = 5678 1007 COOKIE-ACK 1008 101.0.0.1:1 --> 10.1.0.1:2 1009 Ext-VTag = 5678 1011 11. IANA Considerations 1013 TBD 1015 12. Security considerations 1017 State maintenance within a NAT is always a subject of possible Denial 1018 Of Service attacks. This document recommends that at a minimum a NAT 1019 runs a timer on any SCTP state so that old association state can be 1020 cleaned up. 1022 13. Acknowledgments 1024 The authors wish to thank Qiaobing Xie, Henning Peters, Bryan Ford, 1025 David Hayes, Alfred Hines, Dan Wing, and Jason But for their 1026 invaluable comments. 1028 14. References 1030 14.1. Normative References 1032 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1033 RFC 793, September 1981. 1035 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1036 Requirement Levels", BCP 14, RFC 2119, March 1997. 1038 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1039 RFC 4960, September 2007. 1041 14.2. Informative References 1043 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1044 E. Lear, "Address Allocation for Private Internets", 1045 BCP 5, RFC 1918, February 1996. 1047 Authors' Addresses 1049 Randall R. Stewart 1050 Adara Networks 1051 Chapin, SC 29036 1052 USA 1054 Phone: 1055 Email: randall@lakerest.net 1057 Michael Tuexen 1058 Muenster Univ. of Applied Sciences 1059 Stegerwaldstr. 39 1060 48565 Steinfurt 1061 Germany 1063 Email: tuexen@fh-muenster.de 1064 Irene Ruengeler 1065 Muenster Univ. of Applied Sciences 1066 Stegerwaldstr. 39 1067 48565 Steinfurt 1068 Germany 1070 Email: i.ruengeler@fh-muenster.de