idnits 2.17.1 draft-ietf-tsvwg-natsupp-18.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 36 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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 July 2020) is 1361 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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 489, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1940, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 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. R. Stewart 3 Internet-Draft Netflix, Inc. 4 Intended status: Standards Track M. Tüxen 5 Expires: 29 January 2021 I. Rüngeler 6 Münster Univ. of Appl. Sciences 7 28 July 2020 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-18 13 Abstract 15 The Stream Control Transmission Protocol (SCTP) provides a reliable 16 communications channel between two end-hosts in many ways similar to 17 the Transmission Control Protocol (TCP). With the widespread 18 deployment of Network Address Translators (NAT), specialized code has 19 been added to NAT functions for TCP that allows multiple hosts to 20 reside behind a NAT function and yet share a single IPv4 address, 21 even when two hosts (behind a NAT function) choose the same port 22 numbers for their connection. This additional code is sometimes 23 classified as Network Address and Port Translation (NAPT). 25 This document describes the protocol extensions required for the SCTP 26 endpoints and the mechanisms for NAT functions necessary to provide 27 similar features of NAPT in the single point and multi point 28 traversal scenario. 30 Finally, a YANG module for SCTP NAT is defined. 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 https://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 29 January 2021. 49 Copyright Notice 51 Copyright (c) 2020 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 (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 70 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 7 71 4.1.2. Multi Point Traversal . . . . . . . . . . . . . . . . 7 72 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8 73 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 8 74 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 13 76 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 13 77 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 13 78 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 14 79 5.2.1. VTag and Port Number Collision Error Cause . . . . . 14 80 5.2.2. Missing State Error Cause . . . . . . . . . . . . . . 14 81 5.2.3. Port Number Collision Error Cause . . . . . . . . . . 15 82 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 16 83 5.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 16 84 5.3.2. VTags Parameter . . . . . . . . . . . . . . . . . . . 16 85 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 18 86 6.1. Association Setup Considerations for Endpoints . . . . . 18 87 6.2. Handling of Internal Port Number and Verification Tag 88 Collisions . . . . . . . . . . . . . . . . . . . . . . . 19 89 6.2.1. NAT Function Considerations . . . . . . . . . . . . . 19 90 6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 91 6.3. Handling of Internal Port Number Collisions . . . . . . . 20 92 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20 93 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 94 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 95 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 21 96 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 98 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 23 99 6.6. Multi Point Traversal Considerations for Endpoints . . . 24 100 7. Various Examples of NAT Traversals . . . . . . . . . . . . . 24 101 7.1. Single-homed Client to Single-homed Server . . . . . . . 24 102 7.2. Single-homed Client to Multi-homed Server . . . . . . . . 26 103 7.3. Multihomed Client and Server . . . . . . . . . . . . . . 28 104 7.4. NAT Function Loses Its State . . . . . . . . . . . . . . 31 105 7.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . 33 106 8. SCTP NAT YANG Module . . . . . . . . . . . . . . . . . . . . 38 107 8.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 38 108 8.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 39 109 9. Socket API Considerations . . . . . . . . . . . . . . . . . . 41 110 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 42 111 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 112 10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 42 113 10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 44 114 10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 45 115 10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 45 116 10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 45 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 118 12. Normative References . . . . . . . . . . . . . . . . . . . . 46 119 13. Informative References . . . . . . . . . . . . . . . . . . . 48 120 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 123 1. Introduction 125 Stream Control Transmission Protocol (SCTP) [RFC4960] provides a 126 reliable communications channel between two end-hosts in many ways 127 similar to TCP [RFC0793]. With the widespread deployment of Network 128 Address Translators (NAT), specialized code has been added to NAT 129 functions for TCP that allows multiple hosts to reside behind a NAT 130 functions using internal addresses (see [RFC6890]) and yet share 131 single IPv4 address, even when two hosts (behind a NAT function) 132 choose the same port numbers for their connection. This additional 133 code is sometimes classified as Network Address and Port Translation 134 (NAPT). Please note that this document focuses on the case where the 135 NAT function maps a single or multiple internal addresses to a single 136 external address and vice versa. To date, specialized code for SCTP 137 has not yet been added to most NAT functions so that only a 138 translation of IP addresses is supported. The end result of this is 139 that only one SCTP-capable host can successfully operate behind such 140 a NAT function and this host can only be single-homed. The only 141 alternative for supporting legacy NAT functions is to use UDP 142 encapsulation as specified in [RFC6951]. 144 The NAT function in the document refers to NAPT functions described 145 in Section 2.2 of [RFC3022], NAT64 [RFC6146], or DS-Lite [RFC6333]. 147 This document specifies procedures allowing a NAT function to support 148 SCTP by providing similar features to those provided by a NAPT for 149 TCP and other supported protocols. The document also specifies a set 150 of data formats for SCTP packets and a set of SCTP endpoint 151 procedures to support NAT traversal. An SCTP implementation 152 supporting these procedures can assure that in both single-homed and 153 multi-homed cases a NAT function will maintain the appropriate state 154 without the NAT function needing to change port numbers. 156 It is possible and desirable to make these changes for a number of 157 reasons: 159 * It is desirable for SCTP internal end-hosts on multiple platforms 160 to be able to share a NAT function's external IP address in the 161 same way that a TCP session can use a NAT function. 163 * If a NAT function does not need to change any data within an SCTP 164 packet it will reduce the processing burden of NAT'ing SCTP by not 165 needing to execute the CRC32c checksum required by SCTP. 167 * Not having to touch the IP payload makes the processing of ICMP 168 messages in NAT functions easier. 170 An SCTP-aware NAT function will need to follow these procedures for 171 generating appropriate SCTP packet formats. 173 When considering this feature it is possible to have multiple levels 174 of support. At each level, the Internal Host, Remote Host and NAT 175 function may or may not support the features described in this 176 document. The following table illustrates the results of the various 177 combinations of support and if communications can occur between two 178 endpoints. 180 +===============+==============+=============+===============+ 181 | Internal Host | NAT Function | Remote Host | Communication | 182 +===============+==============+=============+===============+ 183 | Support | Support | Support | Yes | 184 +---------------+--------------+-------------+---------------+ 185 | Support | Support | No Support | Limited | 186 +---------------+--------------+-------------+---------------+ 187 | Support | No Support | Support | None | 188 +---------------+--------------+-------------+---------------+ 189 | Support | No Support | No Support | None | 190 +---------------+--------------+-------------+---------------+ 191 | No Support | Support | Support | Limited | 192 +---------------+--------------+-------------+---------------+ 193 | No Support | Support | No Support | Limited | 194 +---------------+--------------+-------------+---------------+ 195 | No Support | No Support | Support | None | 196 +---------------+--------------+-------------+---------------+ 197 | No Support | No Support | No Support | None | 198 +---------------+--------------+-------------+---------------+ 200 Table 1: Communication possibilities 202 From the table it can be seen that when a NAT function does not 203 support the extension no communication can occur. This assumes that 204 the NAT function does not handle SCTP packets at all and all SCTP 205 packets sent externally from behind a NAT function are discarded by 206 the NAT function. In some cases, where the NAT function supports the 207 feature but one of the two hosts does not support the feature, 208 communication may occur but in a limited way. For example only one 209 host may be able to have a connection when a collision case occurs. 211 2. Conventions 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 215 "OPTIONAL" in this document are to be interpreted as described in BCP 216 14 [RFC2119] [RFC8174] when, and only when, they appear in all 217 capitals, as shown here. 219 3. Terminology 221 This document uses the following terms, which are depicted in 222 Figure 1. Familiarity with the terminology used in [RFC4960] and 223 [RFC5061] is assumed. 225 Internal-Address (Int-Addr) 226 The internal address that is known to the internal host. 228 Internal-Port (Int-Port) 229 The port number that is in use by the host holding the Internal- 230 Address. 232 Internal-VTag (Int-VTag) 233 The SCTP Verification Tag (VTag) (see Section 3.1 of [RFC4960]) 234 that the internal host has chosen for its communication. The VTag 235 is a unique 32-bit tag that must accompany any incoming SCTP 236 packet for this association to the Internal-Address. 238 Remote-Address (Rem-Addr) 239 The address that an internal host is attempting to contact. 241 Remote-Port (Rem-Port) 242 The port number of the peer process at the Remote-Address. 244 Remote-VTag (Rem-VTag) 245 The Verification Tag (VTag) (see Section 3.1 of [RFC4960]) that 246 the host holding the Remote-Address has chosen for its 247 communication. The VTag is a unique 32-bit tag that must 248 accompany any incoming SCTP packet for this association to the 249 Remote-Address. 251 External-Address (Ext-Addr) 252 The external address assigned to the NAT function, that it uses as 253 a source address when sending packets towards the Remote-Address. 255 Internal Network | External Network 256 | 257 Internal | External Remote 258 +--------+ Address | Address /--\/--\ Address +--------+ 259 | SCTP | +-----+ / \ | SCTP | 260 |endpoint|=========| NAT |=======| Internet |==========|endpoint| 261 | A | +-----+ \ / | B | 262 +--------+ Internal | \--/\--/ Remote +--------+ 263 Internal Port | Port Remote 264 VTag | VTag 266 Figure 1: Basic network setup 268 4. Motivation 270 4.1. SCTP NAT Traversal Scenarios 272 This section defines the notion of single and multi point NAT 273 traversal. 275 4.1.1. Single Point Traversal 277 In this case, all packets in the SCTP association go through a single 278 NAT function, as shown below: 280 Internal Network | External Network 281 | 282 +--------+ | /--\/--\ +--------+ 283 | SCTP | +-----+ / \ | SCTP | 284 |endpoint|=========| NAT |========= | Internet | ========|endpoint| 285 | A | +-----+ \ / | B | 286 +--------+ | \--/\--/ +--------+ 287 | 289 Figure 2: Single NAT scenario 291 A variation of this case is shown below, i.e., multiple NAT functions 292 in a single path: 294 Internal | External : Internal | External 295 | : | 296 +--------+ | : | /--\/--\ +--------+ 297 | SCTP | +-----+ : +-----+ / \ | SCTP | 298 |endpoint|==| NAT |=======:=======| NAT |==| Internet |==|endpoint| 299 | A | +-----+ : +-----+ \ / | B | 300 +--------+ | : | \--/\--/ +--------+ 301 | : | 303 Figure 3: Serial NAT Functions scenario 305 Although one of the main benefits of SCTP multi-homing is redundant 306 paths, in the single point traversal scenario the NAT function 307 represents a single point of failure in the path of the SCTP multi- 308 homed association. However, the rest of the path may still benefit 309 from path diversity provided by SCTP multi-homing. 311 The two SCTP endpoints in this case can be either single-homed or 312 multi-homed. However, the important thing is that the NAT function 313 in this case sees all the packets of the SCTP association. 315 4.1.2. Multi Point Traversal 317 This case involves multiple NAT functions and each NAT function only 318 sees some of the packets in the SCTP association. An example is 319 shown below: 321 Internal | External 322 +------+ /---\/---\ 323 +--------+ /=======|NAT A |=========\ / \ +--------+ 324 | SCTP | / +------+ \/ \ | SCTP | 325 |endpoint|/ ... | Internet |===|endpoint| 326 | A |\ \ / | B | 327 +--------+ \ +------+ / \ / +--------+ 328 \=======|NAT B |=========/ \---\/---/ 329 +------+ 330 | 332 Figure 4: Parallel NAT functions scenario 334 This case does not apply to a single-homed SCTP association (i.e., 335 both endpoints in the association use only one IP address). The 336 advantage here is that the existence of multiple NAT traversal points 337 can preserve the path diversity of a multi-homed association for the 338 entire path. This in turn can improve the robustness of the 339 communication. 341 4.2. Limitations of Classical NAPT for SCTP 343 Using classical NAPT may result in changing one of the SCTP port 344 numbers during the processing which requires the recomputation of the 345 transport layer checksum by the NAPT device. Whereas for UDP and TCP 346 this can be done very efficiently, for SCTP the checksum (CRC32c) 347 over the entire packet needs to be recomputed (see Appendix B of 348 [RFC4960] for details of the CRC32c computation). This would 349 considerably add to the NAT computational burden, however hardware 350 support may mitigate this in some implementations. 352 An SCTP endpoint may have multiple addresses but only has a single 353 port number. To make multipoint traversal work, all the NAT 354 functions involved must recognize the packets they see as belonging 355 to the same SCTP association and perform port number translation in a 356 consistent way. One possible way of doing this is to use a pre- 357 defined table of ports and addresses configured within each NAT 358 function. Other mechanisms could make use of NAT to NAT 359 communication. Such mechanisms have not been deployed on a wide 360 scale base and thus are not a recommended solution. Therefore an 361 SCTP variant of NAT function has been developed. 363 4.3. The SCTP-Specific Variant of NAT 365 In this section it is allowed that there are multiple SCTP capable 366 hosts behind a NAT function that has one Exernal-Address. 367 Furthermore this section focuses on the single point traversal 368 scenario. 370 The modification of SCTP packets sent to the Internet is simple: the 371 source address of the packet has to be replaced with the External- 372 Address. It may also be necessary to establish some state in the NAT 373 function to later handle incoming packets. 375 For the SCTP NAT processing the NAT function has to maintain a NAT 376 binding table of Internal-VTag, Internal-Port, Remote-VTag, Remote- 377 Port, Internal-Address, and whether the restart procedure is disabled 378 or not. An entry in that NAT binding table is called a NAT-State 379 control block. The function Create() obtains the just mentioned 380 parameters and returns a NAT-State control block. A NAT function MAY 381 allow creating NAT-State control blocks via a management interface. 383 For SCTP packets coming from the public Internet the destination 384 address of the packets has to be replaced with the Internal-Address 385 of the host to which the packet has to be delivered. The lookup of 386 the Internal-Address is based on the Remote-VTag, Remote-Port, 387 Internal-VTag and the Internal-Port. 389 The entries in the NAT binding table need to fulfill some uniqueness 390 conditions. There must not be more than one entry NAT binding table 391 with the same pair of Internal-Port and Remote-Port. This rule can 392 be relaxed, if all NAT binding table entries with the same Internal- 393 Port and Remote-Port have the support for the restart procedure 394 enabled. In this case there must be no more than one entry with the 395 same Internal-Port, Remote-Port and Remote-VTag and no more than one 396 NAT binding table entry with the same Internal-Port, Remote-Port and 397 Int-VTag. 399 The processing of outgoing SCTP packets containing an INIT chunk is 400 described in the following figure. The scenario shown is valid for 401 all message flows in this section. 403 /--\/--\ 404 +--------+ +-----+ / \ +--------+ 405 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 406 +--------+ +-----+ \ / +--------+ 407 \--/\---/ 409 INIT[Initiate-Tag] 410 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 411 Rem-VTag=0 413 Create(Initiate-Tag, Int-Port, 0, Rem-Port, Int-Addr, 414 RestartSupported) 415 Returns(NAT-State control block) 417 Translate To: 419 INIT[Initiate-Tag] 420 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 421 Rem-VTag=0 423 Normally a NAT binding table entry will be created. 425 However, it is possible that there is already a NAT binding table 426 entry with the same Remote-Port, Internal-Port, and Internal-VTag but 427 different Internal-Address. In this case the packet containing the 428 INIT chunk MUST be dropped by the NAT and a packet containing an 429 ABORT chunk SHOULD be sent to the SCTP host that originated the 430 packet with the M-Bit set and an appropriate error cause (see 431 Section 5.1.1 for the format). The source address of the packet 432 containing the ABORT chunk MUST be the destination address of the 433 packet containing the INIT chunk. 435 If an outgoing SCTP packet contains an INIT or ASCONF chunk and a 436 matching NAT binding table entry is found, the packet is processed as 437 a normal outgoing packet. 439 It is also possible that a connection to Remote-Address and Remote- 440 Port exists without an Internal-VTag conflict but there exists a NAT 441 binding table entry with the same port numbers but a different 442 Internal-Address. In such a case the packet containing the INIT 443 chunk MUST be dropped by the NAT function and a packet containing an 444 ABORT chunk SHOULD be sent to the SCTP host that originated the 445 packet with the M-Bit set and an appropriate error cause (see 446 Section 5.1.1 for the format). 448 The processing of outgoing SCTP packets containing no INIT chunks is 449 described in the following figure. 451 /--\/--\ 452 +--------+ +-----+ / \ +--------+ 453 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 454 +--------+ +-----+ \ / +--------+ 455 \--/\---/ 457 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 458 Rem-VTag 460 Translate To: 462 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 463 Rem-VTag 465 The processing of incoming SCTP packets containing an INIT ACK chunk 466 is described in the following figure. The Lookup() function getting 467 as input the Internal-VTag, Internal-Port, Remote-VTag, and Remote- 468 Port, returns the corresponding entry of the NAT binding table and 469 updates the Remote-VTag by substituting it with the value of the 470 Initiate-Tag of the INIT ACK chunk. The wildcard character signifies 471 that the parameter's value is not considered in the Lookup() function 472 or changed in the Update() function, respectively. 474 /--\/--\ 475 +--------+ +-----+ / \ +--------+ 476 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 477 +--------+ +-----+ \ / +--------+ 478 \--/\---/ 480 INIT ACK[Initiate-Tag] 481 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 482 Int-VTag 484 Lookup(Int-VTag, Int-Port, *, Rem-Port) 485 Update(*, *, Initiate-Tag, *) 487 Returns(NAT-State control block containing Int-Addr) 489 INIT ACK[Initiate-Tag] 490 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 491 Int-VTag 493 In the case Lookup fails, the SCTP packet is dropped. If it 494 succeeds, the Update routine inserts the Remote-VTag (the Initiate- 495 Tag of the INIT ACK chunk) in the NAT-State control block. 497 The processing of incoming SCTP packets containing an ABORT or 498 SHUTDOWN COMPLETE chunk with the T-Bit set is described in the 499 following figure. 501 /--\/--\ 502 +--------+ +-----+ / \ +--------+ 503 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 504 +--------+ +-----+ \ / +--------+ 505 \--/\---/ 507 Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port 508 Rem-VTag 510 Lookup(*, Int-Port, Rem-VTag, Rem-Port) 512 Returns(NAT-State control block containing Int-Addr) 514 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 515 Rem-VTag 517 For an incoming packet containing an INIT chunk a table lookup is 518 made only based on the addresses and port numbers. If an entry with 519 an Remote-VTag of zero is found, it is considered a match and the 520 Remote-VTag is updated. If an entry with a non-matching Remote-VTag 521 is found or no entry is found, the incoming packet is dropped. If an 522 entry with a matching Remote-VTag is found, the incoming packet is 523 forwarded. This allows the handling of INIT collision through NAT 524 functions. 526 The processing of other incoming SCTP packets is described in the 527 following figure. 529 /--\/--\ 530 +--------+ +-----+ / \ +--------+ 531 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 532 +--------+ +-----+ \ / +--------+ 533 \--/\---/ 535 Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port 536 Int-VTag 538 Lookup(Int-VTag, Int-Port, *, Rem-Port) 540 Returns(NAT-State control block containing Internal-Address) 542 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 543 Int-VTag 545 5. Data Formats 547 This section defines the formats used to support NAT traversal. 548 Section 5.1 and Section 5.2 describe chunks and error causes sent by 549 NAT functions and received by SCTP endpoints. Section 5.3 describes 550 parameters sent by SCTP endpoints and used by NAT functions and SCTP 551 endpoints. 553 5.1. Modified Chunks 555 This section presents existing chunks defined in [RFC4960] for which 556 additional flags are specified by this document. 558 5.1.1. Extended ABORT Chunk 560 0 1 2 3 561 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type = 6 | Reserved |M|T| Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 \ \ 566 / zero or more Error Causes / 567 \ \ 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 The ABORT chunk is extended to add the new 'M bit'. The M bit 571 indicates to the receiver of the ABORT chunk that the chunk was not 572 generated by the peer SCTP endpoint, but instead by a middle box. 574 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 576 5.1.2. Extended ERROR Chunk 578 0 1 2 3 579 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type = 9 | Reserved |M|T| Length | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 \ \ 584 / zero or more Error Causes / 585 \ \ 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 The ERROR chunk defined in [RFC4960] is extended to add the new 'M 589 bit'. The M bit indicates to the receiver of the ERROR chunk that 590 the chunk was not generated by the peer SCTP endpoint, but instead by 591 a middle box. 593 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 595 5.2. New Error Causes 597 This section defines the new error causes added by this document. 599 5.2.1. VTag and Port Number Collision Error Cause 601 0 1 2 3 602 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Cause Code = 0x00B0 | Cause Length = Variable | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 \ Chunk / 607 / \ 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Cause Code: 2 bytes (unsigned integer) 611 This field holds the IANA defined cause code for the 'VTag and 612 Port Number Collision' Error Cause. IANA is requested to assign 613 the value 0x00B0 for this cause code. 615 Cause Length: 2 bytes (unsigned integer) 616 This field holds the length in bytes of the error cause. The 617 value MUST be the length of the Cause-Specific Information plus 4. 619 Chunk: variable length 620 The Cause-Specific Information is filled with the chunk that 621 caused this error. This can be an INIT, INIT ACK, or ASCONF 622 chunk. Note that if the entire chunk will not fit in the ERROR 623 chunk or ABORT chunk being sent then the bytes that do not fit are 624 truncated. 626 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 627 IANA.] 629 5.2.2. Missing State Error Cause 631 0 1 2 3 632 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Cause Code = 0x00B1 | Cause Length = Variable | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 \ Incoming Packet / 637 / \ 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Cause Code: 2 bytes (unsigned integer) 641 This field holds the IANA defined cause code for the 'Missing 642 State' Error Cause. IANA is requested to assign the value 0x00B1 643 for this cause code. 645 Cause Length: 2 bytes (unsigned integer) 646 This field holds the length in bytes of the error cause. The 647 value MUST be the length of the Cause-Specific Information plus 4. 649 Incoming Packet: variable length 650 The Cause-Specific Information is filled with the IPv4 or IPv6 651 packet that caused this error. The IPv4 or IPv6 header MUST be 652 included. Note that if the packet will not fit in the ERROR chunk 653 or ABORT chunk being sent then the bytes that do not fit are 654 truncated. 656 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 657 IANA.] 659 5.2.3. Port Number Collision Error Cause 661 0 1 2 3 662 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Cause Code = 0x00B2 | Cause Length = Variable | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 \ Chunk / 667 / \ 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Cause Code: 2 bytes (unsigned integer) 671 This field holds the IANA defined cause code for the 'Port Number 672 Collision' Error Cause. IANA is requested to assign the value 673 0x00B2 for this cause code. 675 Cause Length: 2 bytes (unsigned integer) 676 This field holds the length in bytes of the error cause. The 677 value MUST be the length of the Cause-Specific Information plus 4. 679 Chunk: variable length 680 The Cause-Specific Information is filled with the chunk that 681 caused this error. This can be an INIT, INIT ACK, or ASCONF 682 chunk. Note that if the entire chunk will not fit in the ERROR 683 chunk or ABORT chunk being sent then the bytes that do not fit are 684 truncated. 686 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 687 IANA.] 689 5.3. New Parameters 691 This section defines new parameters and their valid appearance 692 defined by this document. 694 5.3.1. Disable Restart Parameter 696 This parameter is used to indicate that the restart procedure is 697 requested to be disabled. Both endpoints of an association MUST 698 include this parameter in the INIT chunk and INIT ACK chunk when 699 establishing an association and MUST include it in the ASCONF chunk 700 when adding an address to successfully disable the restart procedure. 702 0 1 2 3 703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Type = 0xC007 | Length = 4 | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Parameter Type: 2 bytes (unsigned integer) 709 This field holds the IANA defined parameter type for the Disable 710 Restart Parameter. IANA is requested to assign the value 0xC007 711 for this parameter type. 713 Parameter Length: 2 bytes (unsigned integer) 714 This field holds the length in bytes of the parameter. The value 715 MUST be 4. 717 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 718 IANA.] 720 This parameter MAY appear in INIT, INIT ACK and ASCONF chunks and 721 MUST NOT appear in any other chunk. 723 5.3.2. VTags Parameter 725 This parameter is used to help a NAT function to recover from state 726 loss. 728 0 1 2 3 729 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Parameter Type = 0xC008 | Parameter Length = 16 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | ASCONF-Request Correlation ID | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Internal Verification Tag | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Remote Verification Tag | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Parameter Type: 2 bytes (unsigned integer) 741 This field holds the IANA defined parameter type for the VTags 742 Parameter. IANA is requested to assign the value 0xC008 for this 743 parameter type. 745 Parameter Length: 2 bytes (unsigned integer) 746 This field holds the length in bytes of the parameter. The value 747 MUST be 16. 749 ASCONF-Request Correlation ID: 4 bytes (unsigned integer) 750 This is an opaque integer assigned by the sender to identify each 751 request parameter. The receiver of the ASCONF Chunk will copy 752 this 32-bit value into the ASCONF Response Correlation ID field of 753 the ASCONF ACK response parameter. The sender of the packet 754 containing the ASCONF chunk can use this same value in the ASCONF 755 ACK chunk to find which request the response is for. Note that 756 the receiver MUST NOT change this 32-bit value. 758 Internal Verification Tag: 4 bytes (unsigned integer) 759 The Verification Tag that the internal host has chosen for its 760 communication. The Verification Tag is a unique 32-bit tag that 761 must accompany any incoming SCTP packet for this association to 762 the Internal-Address. 764 Remote Verification Tag: 4 bytes (unsigned integer) 765 The Verification Tag that the host holding the Remote-Address has 766 chosen for its communication. The VTag is a unique 32-bit tag 767 that must accompany any incoming SCTP packet for this association 768 to the Remote-Address. 770 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 771 IANA.] 773 This parameter MAY appear in ASCONF chunks and MUST NOT appear in any 774 other chunk. 776 6. Procedures for SCTP Endpoints and NAT Functions 778 When an SCTP endpoint is behind an SCTP-aware NAT a number of 779 problems may arise as it tries to communicate with its peer: 781 * IP addresses can not be included in the SCTP packet. This is 782 discussed in Section 6.1. 784 * More than one host behind a NAT function could select the same 785 VTag and source port when talking to the same peer server. This 786 creates a situation where the NAT function will not be able to 787 tell the two associations apart. This situation is discussed in 788 Section 6.2. 790 * When an SCTP endpoint is a server communicating with multiple 791 peers and the peers are behind the same NAT function, then the two 792 endpoints cannot be distinguished by the server. This case is 793 discussed in Section 6.3. 795 * A restart of a NAT function during a conversation could cause a 796 loss of its state. This problem and its solution is discussed in 797 Section 6.4. 799 * NAT functions need to deal with SCTP packets being fragmented at 800 the IP layer. This is discussed in Section 6.5. 802 * An SCTP endpoint can be behind two NAT functions in parallel 803 providing redundancy. The method to set up this scenario is 804 discussed in Section 6.6. 806 Each of these mechanisms requires additional chunks and parameters, 807 defined in this document, and modified handling procedures from those 808 specified in [RFC4960] as described below. 810 6.1. Association Setup Considerations for Endpoints 812 The association setup procedure defined in [RFC4960] allows multi- 813 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 814 IPv6 address parameters in the INIT and INIT ACK chunks. However, 815 this does not work when NAT functions are present. 817 Every association setup from a host behind a NAT function MUST NOT 818 use multiple internal addresses. The INIT chunk MUST NOT contain an 819 IPv4 Address parameter, IPv6 Address parameter, or Supported Address 820 Types parameter. The INIT ACK chunk MUST NOT contain any IPv4 821 Address parameter or IPv6 Address parameter using non-global 822 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 823 any Host Name parameters. 825 If the association should finally be multi-homed, the procedure in 826 Section 6.6 MUST be used. 828 The INIT and INIT ACK chunk SHOULD contain the Disable Restart 829 parameter defined in Section 5.3.1. 831 6.2. Handling of Internal Port Number and Verification Tag Collisions 833 Consider the case where two hosts in the Internal-Address space want 834 to set up an SCTP association with the same service provided by some 835 hosts in the Internet. This means that the Remote-Port is the same. 836 If they both choose the same Internal-Port and Internal-VTag, the NAT 837 function cannot distinguish between incoming packets anymore. 838 However, this is unlikely. The Internal-VTags are chosen at random 839 and if the Internal-Ports are also chosen from the ephemeral port 840 range at random this gives a 46-bit random number that has to match. 841 A NAPT device can control the Port number and therefore avoid 842 collisions deterministically. 844 The same can happen with the Remote-VTag when a packet containing an 845 INIT ACK chunk or an ASCONF chunk is processed by the NAT function. 847 6.2.1. NAT Function Considerations 849 If the NAT function detects a collision of internal port numbers and 850 verification tags, it SHOULD send a packet containing an ABORT chunk 851 with the M bit set if the collision is triggered by a packet 852 containing an INIT or INIT ACK chunk. If such a collision is 853 triggered by a packet containing an ASCONF chunk, it SHOULD send a 854 packet containing an ERROR chunk with the M bit. The M bit is a new 855 bit defined by this document to express to SCTP that the source of 856 this packet is a "middle" box, not the peer SCTP endpoint (see 857 Section 5.1.1). If a packet containing an INIT ACK chunk triggers 858 the collision, the corresponding packet containing the ABORT chunk 859 MUST contain the same source and destination address and port numbers 860 as the packet containing the INIT ACK chunk. If a packet containing 861 an INIT chunk or an ASCONF chunk, the source and destination address 862 and port numbers MUST be swapped. 864 The sender of the packet containing an ERROR or ABORT chunk MUST 865 include the error cause with cause code 'VTag and Port Number 866 Collision' (see Section 5.2.1). 868 6.2.2. Endpoint Considerations 870 The sender of the packet containing the INIT chunk or the receiver of 871 a packet containing the INIT ACK chunk, upon reception of a packet 872 containign an ABORT chunk with M bit set and the appropriate error 873 cause code for colliding NAT binding table state is included, SHOULD 874 reinitiate the association setup procedure after choosing a new 875 initiate tag, if the association is in COOKIE-WAIT state. In any 876 other state, the SCTP endpoint MUST NOT respond. 878 The sender of packet containing the ASCONF chunk, upon reception of a 879 packet containing an ERROR chunk with M bit set, MUST stop adding the 880 path to the association. 882 6.3. Handling of Internal Port Number Collisions 884 When two SCTP hosts are behind an SCTP-aware NAT it is possible that 885 two SCTP hosts in the Internal-Address space will want to set up an 886 SCTP association with the same server running on the same host in the 887 Internet. If the two hosts choose the same internal port, this is 888 considered an internal port number collision. 890 For the NAT function, appropriate tracking may be performed by 891 assuring that the VTags are unique between the two hosts. 893 6.3.1. NAT Function Considerations 895 The NAT function, when processing the packet containing the INIT ACK 896 chunk, should note in its NAT binding table that the association 897 supports the disable restart extension. This note is used when 898 establishing future associations (i.e. when processing a packet 899 containing an INIT chunk from an internal host) to decide if the 900 connection should be allowed. The NAT function does the following 901 when processing a packet containing an INIT chunk: 903 * If the packet containing the INIT chunk is originating from an 904 internal port to an remote port for which the NAT function has no 905 matching NAT binding table entry, it MUST allow the packet 906 containing the INIT chunk creating an NAT binding table entry. 908 * If the packet containing the INIT chunk matches an existing NAT 909 binding table entry, it MUST validate that the disable restart 910 feature is supported and, if it does, allow the packet containing 911 the INIT chunk to be forwarded. 913 * If the disable restart feature is not supported, the NAT function 914 SHOULD send a packet containing an ABORT chunk with the M bit set. 916 The 'Port Number Collision' error cause (see Section 5.2.3) MUST be 917 included in the ABORT chunk sent in response to the packet containing 918 an INIT chunk. 920 If the collision is triggered by a packet containing an ASCONF chunk, 921 a packet containing an ERROR chunk with the 'Port Number Collision' 922 error cause MUST be sent in response to the packet containing the 923 ASCONF chunk. 925 6.3.2. Endpoint Considerations 927 For the remote SCTP server on the Internet this means that the 928 Remote-Port and the Remote-Address are the same. If they both have 929 chosen the same Internal-Port the server cannot distinguish between 930 both associations based on the address and port numbers. For the 931 server it looks like the association is being restarted. To overcome 932 this limitation the client sends a Disable Restart parameter in the 933 INIT chunk. 935 When the server receives this parameter it does the following: 937 * It MUST include a Disable Restart parameter in the INIT ACK to 938 inform the client that it will support the feature. 940 * It MUST disable the restart procedures defined in [RFC4960] for 941 this association. 943 Servers that support this feature will need to be capable of 944 maintaining multiple connections to what appears to be the same peer 945 (behind the NAT function) differentiated only by the VTags. 947 6.4. Handling of Missing State 949 6.4.1. NAT Function Considerations 951 If the NAT function receives a packet from the internal network for 952 which the lookup procedure does not find an entry in the NAT binding 953 table, a packet containing an ERROR chunk SHOULD be sent back with 954 the M bit set. The source address of the packet containing the ERROR 955 chunk MUST be the destination address of the incoming SCTP packet. 956 The verification tag is reflected and the T bit is set. Such a 957 packet containing an ERROR chunk SHOULD NOT be sent if the received 958 packet contains an ABORT, SHUTDOWN COMPLETE or INIT ACK chunk. A 959 packet containing an ERROR chunk MUST NOT be sent if the received 960 packet contains an ERROR chunk with the M bit set. In any case, the 961 packet SHOULD NOT be forwarded to the remote address. 963 When sending a packet containing an ERROR chunk, the error cause 964 'Missing State' (see Section 5.2.2) MUST be included and the M bit of 965 the ERROR chunk MUST be set (see Section 5.1.2). 967 If the NAT device receives a packet for which it has no NAT binding 968 table entry and the packet contains an ASCONF chunk with the VTags 969 parameter, the NAT function MUST update its NAT binding table 970 according to the verification tags in the VTags parameter and the 971 optional Disable Restart parameter. 973 6.4.2. Endpoint Considerations 975 Upon reception of this packet containing the ERROR chunk by an SCTP 976 endpoint the receiver takes the following actions: 978 * It SHOULD validate that the verification tag is reflected by 979 looking at the VTag that would have been included in the outgoing 980 packet. If the validation fails, discard the incoming packet 981 containing the ERROR chunk. 983 * It SHOULD validate that the peer of the SCTP association supports 984 the dynamic address extension. If the validation fails, discard 985 the incoming packet containing the ERROR chunk. 987 * It SHOULD generate a packet containing a new ASCONF chunk 988 containing the VTags parameter (see Section 5.3.2) and the Disable 989 Restart parameter (see Section 5.3.1) if the association is using 990 the disable restart feature. By processing this packet the NAT 991 function can recover the appropriate state. The procedures for 992 generating an ASCONF chunk can be found in [RFC5061]. 994 The peer SCTP endpoint receiving such a packet containing an ASCONF 995 chunk SHOULD either add the address and respond with an 996 acknowledgment, if the address is new to the association (following 997 all procedures defined in [RFC5061]). Or, if the address is already 998 part of the association, the SCTP endpoint MUST NOT respond with an 999 error, but instead SHOULD respond with packet containing an ASCONF 1000 ACK chunk acknowledging the address and take no action (since the 1001 address is already in the association). 1003 Note that it is possible that upon receiving a packet containing an 1004 ASCONF chunk containing the VTags parameter the NAT function will 1005 realize that it has an 'Internal Port Number and Verification Tag 1006 collision'. In such a case the NAT function SHOULD send a packet 1007 containing an ERROR chunk with the error cause code set to 'VTag and 1008 Port Number Collision' (see Section 5.2.1). 1010 If an SCTP endpoint receives a packet containing an ERROR chunk with 1011 'Internal Port Number and Verification Tag collision' as the error 1012 cause and the packet in the Error Chunk contains an ASCONF with the 1013 VTags parameter, careful examination of the association is required. 1014 The endpoint does the following: 1016 * It MUST validate that the verification tag is reflected by looking 1017 at the VTag that would have been included in the outgoing packet. 1018 If the validation fails, it MUST discard the packet. 1020 * It MUST validate that the peer of the SCTP association supports 1021 the dynamic address extension. If the peer does not support it, 1022 the NAT function MUST discard the incoming packet containing the 1023 ERROR chunk. 1025 * If the association is attempting to add an address (i.e. following 1026 the procedures in Section 6.6) then the endpoint MUST NOT consider 1027 the address part of the association and SHOULD make no further 1028 attempt to add the address (i.e. cancel any ASCONF timers and 1029 remove any record of the path), since the NAT function has a VTag 1030 collision and the association cannot easily create a new VTag (as 1031 it would if the error occurred when sending a packet containing an 1032 INIT chunk). 1034 * If the endpoint has no other path, i.e. the procedure was executed 1035 due to missing a state in the NAT function, then the endpoint MUST 1036 abort the association. This would occur only if the local NAT 1037 function restarted and accepted a new association before 1038 attempting to repair the missing state (Note that this is no 1039 different than what happens to all TCP connections when a NAT 1040 function looses its state). 1042 6.5. Handling of Fragmented SCTP Packets by NAT Functions 1044 SCTP minimizes the use of IP-level fragmentation. However, it can 1045 happen that using IP-level fragmentation is needed to continue an 1046 SCTP association. For example, if the path MTU is reduced and there 1047 are still some DATA chunk in flight, which require packets larger 1048 than the new path MTU. If IP-level fragmentation can not be used, 1049 the SCTP association will be terminated in a non-graceful way. 1051 Therefore, a NAT function MUST be able to handle IP-level fragmented 1052 SCTP packets. The fragments may arrive in any order. 1054 When an SCTP packet has to be fragmented by the NAT function and the 1055 IP header forbids fragmentation, the NAT MUST send back a 1056 corresponding ICMP message to the internal host. This allows for a 1057 faster recovery from this packet drop. 1059 6.6. Multi Point Traversal Considerations for Endpoints 1061 If a multi-homed SCTP endpoint behind a NAT function connects to a 1062 peer, it MUST first set up the association single-homed with only one 1063 address causing the first NAT function to populate its state. Then 1064 it SHOULD add each IP address using packets containing ASCONF chunks 1065 sent via their respective NAT functions. The address to add is the 1066 wildcard address and the lookup address SHOULD also contain the VTags 1067 parameter and optionally the Disable Restart parameter. 1069 7. Various Examples of NAT Traversals 1071 Please note that this section is informational only. 1073 The addresses being used in the following examples are IPv4 addresses 1074 for private-use networks and for documentation as specified in 1075 [RFC6890]. However, the method described here is not limited to this 1076 NAT44 case. 1078 The NAT binding table entries shown in the following examples do not 1079 include the flag indicating whether the restart procedure is 1080 supported or not. This flag is not relevant for these examples. 1082 7.1. Single-homed Client to Single-homed Server 1084 The internal client starts the association with the remote server via 1085 a four-way-handshake. Host A starts by sending a packet containing 1086 an INIT chunk. 1088 /--\/--\ 1089 +--------+ +-----+ / \ +--------+ 1090 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1091 +--------+ +-----+ \ / +--------+ 1092 \--/\---/ 1093 +---------+--------+----------+--------+-----------+ 1094 NAT | Int | Int | Rem | Rem | Int | 1095 | VTag | Port | VTag | Port | Addr | 1096 +---------+--------+----------+--------+-----------+ 1098 INIT[Initiate-Tag = 1234] 1099 10.0.0.1:1 ------> 203.0.113.1:2 1100 Rem-VTtag = 0 1102 A NAT binding tabled entry is created, the source address is 1103 substituted and the packet is sent on: 1105 NAT function creates entry: 1106 +---------+--------+----------+--------+-----------+ 1107 NAT | Int | Int | Rem | Rem | Int | 1108 | VTag | Port | VTag | Port | Addr | 1109 +---------+--------+----------+--------+-----------+ 1110 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1111 +---------+--------+----------+--------+-----------+ 1113 INIT[Initiate-Tag = 1234] 1114 192.0.2.1:1 ------------------------> 203.0.113.1:2 1115 Rem-VTtag = 0 1117 Host B receives the packet containing an INIT chunk and sends a 1118 packet containing an INIT ACK chunk with the NAT's Remote-address as 1119 destination address. 1121 /--\/--\ 1122 +--------+ +-----+ / \ +--------+ 1123 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1124 +--------+ +-----+ \ / +--------+ 1125 \--/\---/ 1127 INIT ACK[Initiate-Tag = 5678] 1128 192.0.2.1:1 <----------------------- 203.0.113.1:2 1129 Int-VTag = 1234 1131 NAT function updates entry: 1132 +---------+--------+----------+--------+-----------+ 1133 NAT | Int | Int | Rem | Rem | Int | 1134 | VTag | Port | VTag | Port | Addr | 1135 +---------+--------+----------+--------+-----------+ 1136 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1137 +---------+--------+----------+--------+-----------+ 1139 INIT ACK[Initiate-Tag = 5678] 1140 10.0.0.1:1 <------ 203.0.113.1:2 1141 Int-VTag = 1234 1143 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1144 ACK. 1146 /--\/--\ 1147 +--------+ +-----+ / \ +--------+ 1148 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1149 +--------+ +-----+ \ / +--------+ 1150 \--/\---/ 1152 COOKIE ECHO 1153 10.0.0.1:1 ------> 203.0.113.1:2 1154 Rem-VTag = 5678 1156 COOKIE ECHO 1157 192.0.2.1:1 -----------------------> 203.0.113.1:2 1158 Rem-VTag = 5678 1160 COOKIE ACK 1161 192.0.2.1:1 <----------------------- 203.0.113.1:2 1162 Int-VTag = 1234 1164 COOKIE ACK 1165 10.0.0.1:1 <------ 203.0.113.1:2 1166 Int-VTag = 1234 1168 7.2. Single-homed Client to Multi-homed Server 1170 The internal client is single-homed whereas the remote server is 1171 multi-homed. The client (Host A) sends a packet containing an INIT 1172 chunk like in the single-homed case. 1174 +--------+ 1175 /--\/--\ /-|Router 1| \ 1176 +------+ +-----+ / \ / +--------+ \ +------+ 1177 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1178 | A | +-----+ \ / \ +--------+ / | B | 1179 +------+ \--/\--/ \-|Router 2|-/ +------+ 1180 +--------+ 1182 +---------+--------+----------+--------+-----------+ 1183 NAT | Int | Int | Rem | Rem | Int | 1184 | VTag | Port | VTag | Port | Addr | 1185 +---------+--------+----------+--------+-----------+ 1187 INIT[Initiate-Tag = 1234] 1188 10.0.0.1:1 ---> 203.0.113.1:2 1189 Rem-VTag = 0 1191 NAT function creates entry: 1193 +---------+--------+----------+--------+-----------+ 1194 NAT | Int | Int | Rem | Rem | Int | 1195 | VTag | Port | VTag | Port | Addr | 1196 +---------+--------+----------+--------+-----------+ 1197 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1198 +---------+--------+----------+--------+-----------+ 1200 INIT[Initiate-Tag = 1234] 1201 192.0.2.1:1 --------------------------> 203.0.113.1:2 1202 Rem-VTag = 0 1204 The server (Host B) includes its two addresses in the INIT ACK chunk. 1206 +--------+ 1207 /--\/--\ /-|Router 1| \ 1208 +------+ +-----+ / \ / +--------+ \ +------+ 1209 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1210 | A | +-----+ \ / \ +--------+ / | B | 1211 +------+ \--/\--/ \-|Router 2|-/ +------+ 1212 +--------+ 1214 INIT ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129] 1215 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1216 Int-VTag = 1234 1218 The NAT function does not need to change the NAT binding table for 1219 the second address: 1221 +---------+--------+----------+--------+-----------+ 1222 NAT | Int | Int | Rem | Rem | Int | 1223 | VTag | Port | VTag | Port | Addr | 1224 +---------+--------+----------+--------+-----------+ 1225 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1226 +---------+--------+----------+--------+-----------+ 1228 INIT ACK[Initiate-Tag = 5678] 1229 10.0.0.1:1 <--- 203.0.113.1:2 1230 Int-VTag = 1234 1232 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1233 ACK. 1235 +--------+ 1236 /--\/--\ /-|Router 1| \ 1237 +------+ +-----+ / \ / +--------+ \ +------+ 1238 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1239 | A | +-----+ \ / \ +--------+ / | B | 1240 +------+ \--/\--/ \-|Router 2|-/ +------+ 1241 +--------+ 1243 COOKIE ECHO 1244 10.0.0.1:1 ---> 203.0.113.1:2 1245 Rem-VTag = 5678 1247 COOKIE ECHO 1248 192.0.2.1:1 --------------------------> 203.0.113.1:2 1249 Rem-VTag = 5678 1251 COOKIE ACK 1252 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1253 Int-VTag = 1234 1255 COOKIE ACK 1256 10.0.0.1:1 <--- 203.0.113.1:2 1257 Int-VTag = 1234 1259 7.3. Multihomed Client and Server 1261 The client (Host A) sends a packet containing an INIT chunk to the 1262 server (Host B), but does not include the second address. 1264 +-------+ 1265 /--| NAT 1 |--\ /--\/--\ 1266 +------+ / +-------+ \ / \ +--------+ 1267 | Host |=== ====| Internet |====| Host B | 1268 | A | \ +-------+ / \ / +--------+ 1269 +------+ \--| NAT 2 |--/ \--/\--/ 1270 +-------+ 1272 +---------+--------+----------+--------+-----------+ 1273 NAT 1 | Int | Int | Rem | Rem | Int | 1274 | VTag | Port | VTag | Port | Addr | 1275 +---------+--------+----------+--------+-----------+ 1277 INIT[Initiate-Tag = 1234] 1278 10.0.0.1:1 --------> 203.0.113.1:2 1279 Rem-VTag = 0 1281 NAT function 1 creates entry: 1283 +---------+--------+----------+--------+-----------+ 1284 NAT 1 | Int | Int | Rem | Rem | Int | 1285 | VTag | Port | VTag | Port | Addr | 1286 +---------+--------+----------+--------+-----------+ 1287 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1288 +---------+--------+----------+--------+-----------+ 1290 INIT[Initiate-Tag = 1234] 1291 192.0.2.1:1 ---------------------> 203.0.113.1:2 1292 Rem-VTag = 0 1294 Host B includes its second address in the INIT ACK. 1296 +-------+ 1297 /--------| NAT 1 |--------\ /--\/--\ 1298 +------+ / +-------+ \ / \ +--------+ 1299 | Host |=== ====| Internet |===| Host B | 1300 | A | \ +-------+ / \ / +--------+ 1301 +------+ \--------| NAT 2 |--------/ \--/\--/ 1302 +-------+ 1304 INIT ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129] 1305 192.0.2.1:1 <----------------------- 203.0.113.1:2 1306 Int-VTag = 1234 1308 NAT function 1 does not need to update the NAT binding table for the 1309 second address: 1311 +---------+--------+----------+--------+-----------+ 1312 NAT 1 | Int | Int | Rem | Rem | Int | 1313 | VTag | Port | VTag | Port | Addr | 1314 +---------+--------+----------+--------+-----------+ 1315 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1316 +---------+--------+----------+--------+-----------+ 1318 INIT ACK[Initiate-Tag = 5678] 1319 10.0.0.1:1 <-------- 203.0.113.1:2 1320 Int-VTag = 1234 1322 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1323 ACK. 1325 +-------+ 1326 /--------| NAT 1 |--------\ /--\/--\ 1327 +------+ / +-------+ \ / \ +--------+ 1328 | Host |=== ====| Internet |===| Host B | 1329 | A | \ +-------+ / \ / +--------+ 1330 +------+ \--------| NAT 2 |--------/ \--/\--/ 1331 +-------+ 1333 COOKIE ECHO 1334 10.0.0.1:1 --------> 203.0.113.1:2 1335 Rem-VTag = 5678 1337 COOKIE ECHO 1338 192.0.2.1:1 ------------------> 203.0.113.1:2 1339 Rem-VTag = 5678 1341 COOKIE ACK 1342 192.0.2.1:1 <------------------ 203.0.113.1:2 1343 Int-VTag = 1234 1345 COOKIE ACK 1346 10.0.0.1:1 <------- 203.0.113.1:2 1347 Int-VTag = 1234 1349 Host A announces its second address in an ASCONF chunk. The address 1350 parameter contains an undefined address (0) to indicate that the 1351 source address should be added. The lookup address parameter within 1352 the ASCONF chunk will also contain the pair of VTags (remote and 1353 internal) so that the NAT function may populate its NAT binding table 1354 entry completely with this single packet. 1356 +-------+ 1357 /--------| NAT 1 |--------\ /--\/--\ 1358 +------+ / +-------+ \ / \ +--------+ 1359 | Host |=== ====| Internet |===| Host B | 1360 | A | \ +-------+ / \ / +--------+ 1361 +------+ \--------| NAT 2 |--------/ \--/\--/ 1362 +-------+ 1364 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Rem-VTag = 5678] 1365 10.1.0.1:1 --------> 203.0.113.129:2 1366 Rem-VTag = 5678 1368 NAT function 2 creates a complete entry: 1370 +---------+--------+----------+--------+-----------+ 1371 NAT 2 | Int | Int | Rem | Rem | Int | 1372 | VTag | Port | VTag | Port | Addr | 1373 +---------+--------+----------+--------+-----------+ 1374 | 1234 | 1 | 5678 | 2 | 10.1.0.1 | 1375 +---------+--------+----------+--------+-----------+ 1377 ASCONF [ADD-IP, Int-VTag=1234, Rem-VTag = 5678] 1378 192.0.2.129:1 -------------------> 203.0.113.129:2 1379 Rem-VTag = 5678 1381 ASCONF ACK 1382 192.0.2.129:1 <------------------- 203.0.113.129:2 1383 Int-VTag = 1234 1385 ASCONF ACK 1386 10.1.0.1:1 <----- 203.0.113.129:2 1387 Int-VTag = 1234 1389 7.4. NAT Function Loses Its State 1391 Association is already established between Host A and Host B, when 1392 the NAT function loses its state and obtains a new external address. 1393 Host A sends a DATA chunk to Host B. 1395 /--\/--\ 1396 +--------+ +-----+ / \ +--------+ 1397 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1398 +--------+ +-----+ \ / +--------+ 1399 \--/\--/ 1401 +---------+--------+----------+--------+-----------+ 1402 NAT | Int | Int | Rem | Rem | Int | 1403 | VTag | Port | VTag | Port | Addr | 1404 +---------+--------+----------+--------+-----------+ 1406 DATA 1407 10.0.0.1:1 ----------> 203.0.113.1:2 1408 Rem-VTag = 5678 1410 The NAT function cannot find an entry in the NAT binding table for 1411 the association. It sends a packet containing an ERROR chunk with 1412 the M-Bit set and the cause "NAT state missing". 1414 /--\/--\ 1415 +--------+ +-----+ / \ +--------+ 1416 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1417 +--------+ +-----+ \ / +--------+ 1418 \--/\--/ 1420 ERROR [M-Bit, NAT state missing] 1421 10.0.0.1:1 <---------- 203.0.113.1:2 1422 Rem-VTag = 5678 1424 On reception of the packet containing the ERROR chunk, Host A sends a 1425 packet containing an ASCONF chunk indicating that the former 1426 information has to be deleted and the source address of the actual 1427 packet added. 1429 /--\/--\ 1430 +--------+ +-----+ / \ +--------+ 1431 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1432 +--------+ +-----+ \ / +--------+ 1433 \--/\--/ 1435 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1436 10.0.0.1:1 ----------> 203.0.113.129:2 1437 Rem-VTag = 5678 1439 +---------+--------+----------+--------+-----------+ 1440 NAT | Int | Int | Rem | Rem | Int | 1441 | VTag | Port | VTag | Port | Addr | 1442 +---------+--------+----------+--------+-----------+ 1443 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1444 +---------+--------+----------+--------+-----------+ 1446 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1447 192.0.2.2:1 -----------------> 203.0.113.129:2 1448 Rem-VTag = 5678 1450 Host B adds the new source address to this association and deletes 1451 all other addresses from this association. 1453 /--\/--\ 1454 +--------+ +-----+ / \ +--------+ 1455 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1456 +--------+ +-----+ \ / +--------+ 1457 \--/\--/ 1459 ASCONF ACK 1460 192.0.2.2:1 <----------------- 203.0.113.129:2 1461 Int-VTag = 1234 1463 ASCONF ACK 1464 10.1.0.1:1 <---------- 203.0.113.129:2 1465 Int-VTag = 1234 1467 DATA 1468 10.0.0.1:1 ----------> 203.0.113.1:2 1469 Rem-VTag = 5678 1470 DATA 1471 192.0.2.2:1 -----------------> 203.0.113.129:2 1472 Rem-VTag = 5678 1474 7.5. Peer-to-Peer Communication 1476 If two hosts, each of them behind a NAT function, want to communicate 1477 with each other, they have to get knowledge of the peer's external 1478 address. This can be achieved with a so-called rendezvous server. 1479 Afterwards the destination addresses are external, and the 1480 association is set up with the help of the INIT collision. The NAT 1481 functions create their entries according to their internal peer's 1482 point of view. Therefore, NAT function A's Internal-VTag and 1483 Internal-Port are NAT function B's Remote-VTag and Remote-Port, 1484 respectively. The naming (internal/remote) of the verification tag 1485 in the packet flow is done from the sending host's point of view. 1487 Internal | External External | Internal 1488 | | 1489 | /--\/---\ | 1490 +--------+ +-------+ / \ +-------+ +--------+ 1491 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1492 +--------+ +-------+ \ / +-------+ +--------+ 1493 | \--/\---/ | 1495 NAT Binding Tables 1496 +---------+--------+----------+--------+-----------+ 1497 NAT A | Int | Int | Rem | Rem | Int | 1498 | VTag | Port | VTag | Port | Addr | 1499 +---------+--------+----------+--------+-----------+ 1501 +---------+--------+----------+--------+-----------+ 1502 NAT B | Int | Int | Rem | Rem | Int | 1503 | v-tag | port | v-tag | port | Addr | 1504 +---------+--------+----------+--------+-----------+ 1506 INIT[Initiate-Tag = 1234] 1507 10.0.0.1:1 --> 203.0.113.1:2 1508 Rem-VTag = 0 1510 NAT function A creates entry: 1512 +---------+--------+----------+--------+-----------+ 1513 NAT A | Int | Int | Rem | Rem | Int | 1514 | VTag | Port | VTag | Port | Addr | 1515 +---------+--------+----------+--------+-----------+ 1516 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1517 +---------+--------+----------+--------+-----------+ 1519 INIT[Initiate-Tag = 1234] 1520 192.0.2.1:1 ----------------> 203.0.113.1:2 1521 Rem-VTag = 0 1523 NAT function B processes the packet containing the INIT chunk, but 1524 cannot find an entry. The SCTP packet is silently discarded and 1525 leaves the NAT binding table of NAT function B unchanged. 1527 +---------+--------+----------+--------+-----------+ 1528 NAT B | Int | Int | Rem | Rem | Int | 1529 | VTag | Port | VTag | Port | Addr | 1530 +---------+--------+----------+--------+-----------+ 1532 Now Host B sends a packet containing an INIT chunk, which is 1533 processed by NAT function B. Its parameters are used to create an 1534 entry. 1536 Internal | External External | Internal 1537 | | 1538 | /--\/---\ | 1539 +--------+ +-------+ / \ +-------+ +--------+ 1540 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1541 +--------+ +-------+ \ / +-------+ +--------+ 1542 | \--/\---/ | 1544 INIT[Initiate-Tag = 5678] 1545 192.0.2.1:1 <-- 10.1.0.1:2 1546 Rem-VTag = 0 1548 +---------+--------+----------+--------+-----------+ 1549 NAT B | Int | Int | Rem | Rem | Int | 1550 | VTag | Port | VTag | Port | Addr | 1551 +---------+--------+----------+--------+-----------+ 1552 | 5678 | 2 | 0 | 1 | 10.1.0.1 | 1553 +---------+--------+----------+--------+-----------+ 1555 INIT[Initiate-Tag = 5678] 1556 192.0.2.1:1 <--------------- 203.0.113.1:2 1557 Rem-VTag = 0 1559 NAT function A processes the packet containing the INIT chunk. As 1560 the outgoing packet containing an INIT chunk of Host A has already 1561 created an entry, the entry is found and updated: 1563 Internal | External External | Internal 1564 | | 1565 | /--\/---\ | 1566 +--------+ +-------+ / \ +-------+ +--------+ 1567 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1568 +--------+ +-------+ \ / +-------+ +--------+ 1569 | \--/\---/ | 1571 VTag != Int-VTag, but Rem-VTag == 0, find entry. 1572 +---------+--------+----------+--------+-----------+ 1573 NAT A | Int | Int | Rem | Rem | Int | 1574 | VTag | Port | VTag | Port | Addr | 1575 +---------+--------+----------+--------+-----------+ 1576 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1577 +---------+--------+----------+--------+-----------+ 1579 INIT[Initiate-tag = 5678] 1580 10.0.0.1:1 <-- 203.0.113.1:2 1581 Rem-VTag = 0 1583 Host A sends a packet containing an INIT ACK chunk, which can pass 1584 through NAT function B: 1586 Internal | External External | Internal 1587 | | 1588 | /--\/---\ | 1589 +--------+ +-------+ / \ +-------+ +--------+ 1590 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1591 +--------+ +-------+ \ / +-------+ +--------+ 1592 | \--/\---/ | 1594 INIT ACK[Initiate-Tag = 1234] 1595 10.0.0.1:1 --> 203.0.113.1:2 1596 Rem-VTag = 5678 1598 INIT ACK[Initiate-Tag = 1234] 1599 192.0.2.1:1 ----------------> 203.0.113.1:2 1600 Rem-VTag = 5678 1602 NAT function B updates entry: 1604 +---------+--------+----------+--------+-----------+ 1605 NAT B | Int | Int | Rem | Rem | Int | 1606 | VTag | Port | VTag | Port | Addr | 1607 +---------+--------+----------+--------+-----------+ 1608 | 5678 | 2 | 1234 | 1 | 10.1.0.1 | 1609 +---------+--------+----------+--------+-----------+ 1611 INIT ACK[Initiate-Tag = 1234] 1612 192.0.2.1:1 --> 10.1.0.1:2 1613 Rem-VTag = 5678 1615 The lookup for COOKIE ECHO and COOKIE ACK is successful. 1617 Internal | External External | Internal 1618 | | 1619 | /--\/---\ | 1620 +--------+ +-------+ / \ +-------+ +--------+ 1621 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1622 +--------+ +-------+ \ / +-------+ +--------+ 1623 | \--/\---/ | 1625 COOKIE ECHO 1626 192.0.2.1:1 <-- 10.1.0.1:2 1627 Rem-VTag = 1234 1629 COOKIE ECHO 1630 192.0.2.1:1 <------------- 203.0.113.1:2 1631 Rem-VTag = 1234 1633 COOKIE ECHO 1634 10.0.0.1:1 <-- 203.0.113.1:2 1635 Rem-VTag = 1234 1637 COOKIE ACK 1638 10.0.0.1:1 --> 203.0.113.1:2 1639 Rem-VTag = 5678 1641 COOKIE ACK 1642 192.0.2.1:1 ----------------> 203.0.113.1:2 1643 Rem-VTag = 5678 1645 COOKIE ACK 1646 192.0.2.1:1 --> 10.1.0.1:2 1647 Rem-VTag = 5678 1649 8. SCTP NAT YANG Module 1651 This section defines a YANG module for SCTP NAT. 1653 The terminology for describing YANG data models is defined in 1654 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 1655 [RFC8340]. 1657 8.1. Tree Structure 1659 This module augments NAT YANG module [RFC8512] with SCTP specifics. 1660 The module supports both classical SCTP NAT (that is, rewrite port 1661 numbers) and SCTP-specific variant where the ports numbers are not 1662 altered. The YANG "feature" is used to indicate whether SCTP- 1663 specific variant is supported. 1665 The tree structure of the SCTP NAT YANG module is provided below: 1667 module: ietf-nat-sctp 1668 augment /nat:nat/nat:instances/nat:instance 1669 /nat:policy/nat:timers: 1670 +--rw sctp-timeout? uint32 1671 augment /nat:nat/nat:instances/nat:instance 1672 /nat:mapping-table/nat:mapping-entry: 1673 +--rw int-VTag? uint32 {sctp-nat}? 1674 +--rw rem-VTag? uint32 {sctp-nat}? 1676 Concretely, the SCTP NAT YANG module augments the NAT YANG module 1677 (policy, in particular) with the following: 1679 * The sctp-timeout is used to control the SCTP inactivity timeout. 1680 That is, the time an SCTP mapping will stay active without SCTP 1681 packets traversing the NAT. This timeout can be set only for 1682 SCTP. Hence, "/nat:nat/nat:instances/nat:instance/nat:policy/ 1683 nat:transport-protocols/nat:protocol-id" MUST be set to '132' 1684 (SCTP). 1686 In addition, the SCTP NAT YANG module augments the mapping entry with 1687 the following parameters defined in Section 3. These parameters 1688 apply only for SCTP NAT mapping entries (i.e., 1689 "/nat/instances/instance/mapping-table/mapping-entry/transport- 1690 protocol" MUST be set to '132'); 1692 * The Internal Verification Tag (Int-VTag) 1694 * The Remote Verification Tag (Rem-VTag) 1696 8.2. YANG Module 1698 file "ietf-nat-sctp@2020-07-13.yang" 1699 module ietf-nat-sctp { 1700 yang-version 1.1; 1701 namespace "urn:ietf:params:xml:ns:yang:ietf-nat-sctp"; 1702 prefix nat-sctp; 1704 import ietf-nat { 1705 prefix nat; 1706 reference 1707 "RFC 8512: A YANG Module for Network Address Translation 1708 (NAT) and Network Prefix Translation (NPT)"; 1709 } 1711 organization 1712 "IETF TSVWG Working Group"; 1714 contact 1715 "WG Web: 1716 WG List: 1718 Author: Mohamed Boucadair 1719 "; 1720 description 1721 "This module augments NAT YANG module with Stream Control 1722 Transmission Protocol (SCTP) specifics. The extension supports 1723 both a classical SCTP NAT (that is, rewrite port numbers) 1724 and a, SCTP-specific variant where the ports numbers are 1725 not altered. 1727 Copyright (c) 2020 IETF Trust and the persons identified as 1728 authors of the code. All rights reserved. 1730 Redistribution and use in source and binary forms, with or 1731 without modification, is permitted pursuant to, and subject 1732 to the license terms contained in, the Simplified BSD License 1733 set forth in Section 4.c of the IETF Trust's Legal Provisions 1734 Relating to IETF Documents 1735 (http://trustee.ietf.org/license-info). 1737 This version of this YANG module is part of RFC XXXX; see 1738 the RFC itself for full legal notices."; 1740 revision 2019-11-18 { 1741 description 1742 "Initial revision."; 1743 reference 1744 "RFC XXXX: Stream Control Transmission Protocol (SCTP) 1745 Network Address Translation Support"; 1746 } 1748 feature sctp-nat { 1749 description 1750 "This feature means that SCTP-specific variant of NAT 1751 is supported. That is, avoid rewriting port numbers."; 1752 reference 1753 "Section 4.3 of RFC XXXX."; 1754 } 1756 augment "/nat:nat/nat:instances/nat:instance" 1757 + "/nat:policy/nat:timers" { 1758 when "/nat:nat/nat:instances/nat:instance" 1759 + "/nat:policy/nat:transport-protocols" 1760 + "/nat:protocol-id = 132"; 1761 description 1762 "Extends NAT policy with a timeout for SCTP mapping 1763 entries."; 1765 leaf sctp-timeout { 1766 type uint32; 1767 units "seconds"; 1768 description 1769 "SCTP inactivity timeout. That is, the time an SCTP 1770 mapping entry will stay active without packets 1771 traversing the NAT."; 1772 } 1773 } 1775 augment "/nat:nat/nat:instances/nat:instance" 1776 + "/nat:mapping-table/nat:mapping-entry" { 1777 when "nat:transport-protocol = 132"; 1778 if-feature "sctp-nat"; 1779 description 1780 "Extends the mapping entry with SCTP specifics."; 1782 leaf int-VTag { 1783 type uint32; 1784 description 1785 "The Internal Verification Tag that the internal 1786 host has chosen for this communication."; 1787 } 1788 leaf rem-VTag { 1789 type uint32; 1790 description 1791 "The Remote Verification Tag that the remote 1792 peer has chosen for this communication."; 1793 } 1794 } 1795 } 1796 1798 9. Socket API Considerations 1800 This section describes how the socket API defined in [RFC6458] is 1801 extended to provide a way for the application to control NAT 1802 friendliness. 1804 Please note that this section is informational only. 1806 A socket API implementation based on [RFC6458] is extended by 1807 supporting one new read/write socket option. 1809 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 1811 This socket option uses the option_level IPPROTO_SCTP and the 1812 option_name SCTP_NAT_FRIENDLY. It can be used to enable/disable the 1813 NAT friendliness for future associations and retrieve the value for 1814 future and specific ones. 1816 struct sctp_assoc_value { 1817 sctp_assoc_t assoc_id; 1818 uint32_t assoc_value; 1819 }; 1821 assoc_id 1822 This parameter is ignored for one-to-one style sockets. For one- 1823 to-many style sockets the application may fill in an association 1824 identifier or SCTP_FUTURE_ASSOC for this query. It is an error to 1825 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 1827 assoc_value 1828 A non-zero value indicates a NAT-friendly mode. 1830 10. IANA Considerations 1832 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1833 you assign this document.] 1835 [NOTE to RFC-Editor: The requested values for the chunk type and the 1836 chunk parameter types are tentative and to be confirmed by IANA.] 1838 This document (RFCXXXX) is the reference for all registrations 1839 described in this section. The requested changes are described 1840 below. 1842 10.1. New Chunk Flags for Two Existing Chunk Types 1844 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1845 for the ERROR chunk. The requested value for the T bit is 0x01 and 1846 for the M bit is 0x02. 1848 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1850 ERROR Chunk Flags 1851 +==================+=================+===========+ 1852 | Chunk Flag Value | Chunk Flag Name | Reference | 1853 +==================+=================+===========+ 1854 | 0x01 | T bit | [RFCXXXX] | 1855 +------------------+-----------------+-----------+ 1856 | 0x02 | M bit | [RFCXXXX] | 1857 +------------------+-----------------+-----------+ 1858 | 0x04 | Unassigned | | 1859 +------------------+-----------------+-----------+ 1860 | 0x08 | Unassigned | | 1861 +------------------+-----------------+-----------+ 1862 | 0x10 | Unassigned | | 1863 +------------------+-----------------+-----------+ 1864 | 0x20 | Unassigned | | 1865 +------------------+-----------------+-----------+ 1866 | 0x40 | Unassigned | | 1867 +------------------+-----------------+-----------+ 1868 | 0x80 | Unassigned | | 1869 +------------------+-----------------+-----------+ 1871 Table 2 1873 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1874 the ABORT chunk. The requested value of the M bit is 0x02. 1876 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1878 ABORT Chunk Flags 1879 +==================+=================+===========+ 1880 | Chunk Flag Value | Chunk Flag Name | Reference | 1881 +==================+=================+===========+ 1882 | 0x01 | T bit | [RFC4960] | 1883 +------------------+-----------------+-----------+ 1884 | 0x02 | M bit | [RFCXXXX] | 1885 +------------------+-----------------+-----------+ 1886 | 0x04 | Unassigned | | 1887 +------------------+-----------------+-----------+ 1888 | 0x08 | Unassigned | | 1889 +------------------+-----------------+-----------+ 1890 | 0x10 | Unassigned | | 1891 +------------------+-----------------+-----------+ 1892 | 0x20 | Unassigned | | 1893 +------------------+-----------------+-----------+ 1894 | 0x40 | Unassigned | | 1895 +------------------+-----------------+-----------+ 1896 | 0x80 | Unassigned | | 1897 +------------------+-----------------+-----------+ 1899 Table 3 1901 10.2. Three New Error Causes 1903 Three error causes have to be assigned by IANA. It is requested to 1904 use the values given below. 1906 This requires three additional lines in the "Error Cause Codes" 1907 registry for SCTP: 1909 Error Cause Codes 1911 +=======+================================+===========+ 1912 | Value | Cause Code | Reference | 1913 +=======+================================+===========+ 1914 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1915 +-------+--------------------------------+-----------+ 1916 | 177 | Missing State | [RFCXXXX] | 1917 +-------+--------------------------------+-----------+ 1918 | 178 | Port Number Collision | [RFCXXXX] | 1919 +-------+--------------------------------+-----------+ 1921 Table 4 1923 10.3. Two New Chunk Parameter Types 1925 Two chunk parameter types have to be assigned by IANA. It is 1926 requested to use the values given below. IANA should assign these 1927 values from the pool of parameters with the upper two bits set to 1928 '11'. 1930 This requires two additional lines in the "Chunk Parameter Types" 1931 registry for SCTP: 1933 Chunk Parameter Types 1935 +==========+==========================+===========+ 1936 | ID Value | Chunk Parameter Type | Reference | 1937 +==========+==========================+===========+ 1938 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1939 +----------+--------------------------+-----------+ 1940 | 49160 | VTags (0xC008) | [RFCXXXX] | 1941 +----------+--------------------------+-----------+ 1943 Table 5 1945 10.4. One New URI 1947 An URI in the "ns" subregistry within the "IETF XML" registry has to 1948 be assigned by IANA ([RFC3688]): 1950 URI: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1951 Registrant Contact: The IESG. 1952 XML: N/A; the requested URI is an XML namespace. 1954 10.5. One New YANG Module 1956 An YANG module in the "YANG Module Names" subregistry within the 1957 "YANG Parameters" registry has to be assigned by IANA ([RFC6020]): 1959 Name: ietf-nat-sctp 1960 Namespace: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1961 Maintained by IANA: N 1962 Prefix: nat-sctp 1963 Reference: RFCXXXX 1965 11. Security Considerations 1967 State maintenance within a NAT function is always a subject of 1968 possible Denial Of Service attacks. This document recommends that at 1969 a minimum a NAT function runs a timer on any SCTP state so that old 1970 association state can be cleaned up. 1972 Generic issues related to address sharing are discussed in [RFC6269] 1973 and apply to SCTP as well. 1975 For SCTP endpoints not disabling the restart procedure, this document 1976 does not add any additional security considerations to the ones given 1977 in [RFC4960], [RFC4895], and [RFC5061]. 1979 SCTP endpoints disabling the restart procedure, should monitor the 1980 status of all associations to mitigate resource exhaustion attacks by 1981 establishing a lot of associations sharing the same IP addresses and 1982 port numbers. 1984 In any case, SCTP is protected by the verification tags and the usage 1985 of [RFC4895] against off-path attackers. 1987 For IP-level fragmentation and reassembly related issues see 1988 [RFC4963]. 1990 The YANG module specified in this document defines a schema for data 1991 that is designed to be accessed via network management protocols such 1992 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1993 is the secure transport layer, and the mandatory-to-implement secure 1994 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1995 is HTTPS, and the mandatory-to-implement secure transport is TLS 1996 [RFC8446]. 1998 The Network Configuration Access Control Model (NACM) [RFC8341] 1999 provides the means to restrict access for particular NETCONF or 2000 RESTCONF users to a preconfigured subset of all available NETCONF or 2001 RESTCONF protocol operations and content. 2003 All data nodes defined in the YANG module that can be created, 2004 modified, and deleted (i.e., config true, which is the default) are 2005 considered sensitive. Write operations (e.g., edit-config) applied 2006 to these data nodes without proper protection can negatively affect 2007 network operations. An attacker who is able to access the SCTP NAT 2008 function can undertake various attacks, such as: 2010 * Setting a low timeout for SCTP mapping entries to cause failures 2011 to deliver incoming SCTP packets. 2013 * Instantiating mapping entries to cause NAT collision. 2015 12. Normative References 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2018 Requirement Levels", BCP 14, RFC 2119, 2019 DOI 10.17487/RFC2119, March 1997, 2020 . 2022 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2023 DOI 10.17487/RFC3688, January 2004, 2024 . 2026 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 2027 "Authenticated Chunks for the Stream Control Transmission 2028 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2029 2007, . 2031 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2032 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2033 . 2035 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2036 Kozuka, "Stream Control Transmission Protocol (SCTP) 2037 Dynamic Address Reconfiguration", RFC 5061, 2038 DOI 10.17487/RFC5061, September 2007, 2039 . 2041 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2042 the Network Configuration Protocol (NETCONF)", RFC 6020, 2043 DOI 10.17487/RFC6020, October 2010, 2044 . 2046 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 2047 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 2048 DOI 10.17487/RFC6096, January 2011, 2049 . 2051 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2052 and A. Bierman, Ed., "Network Configuration Protocol 2053 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2054 . 2056 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2057 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2058 . 2060 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2061 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2062 . 2064 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2065 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2066 May 2017, . 2068 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2069 Access Control Model", STD 91, RFC 8341, 2070 DOI 10.17487/RFC8341, March 2018, 2071 . 2073 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2074 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2075 . 2077 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 2078 Vinapamula, S., and Q. Wu, "A YANG Module for Network 2079 Address Translation (NAT) and Network Prefix Translation 2080 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 2081 . 2083 13. Informative References 2085 [DOI_10.1145_1496091.1496095] 2086 Hayes, D., But, J., and G. Armitage, "Issues with network 2087 address translation for SCTP", ACM SIGCOMM Computer 2088 Communication Review Vol. 39, pp. 23-33, 2089 DOI 10.1145/1496091.1496095, December 2008, 2090 . 2092 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2093 RFC 793, DOI 10.17487/RFC0793, September 1981, 2094 . 2096 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2097 Address Translator (Traditional NAT)", RFC 3022, 2098 DOI 10.17487/RFC3022, January 2001, 2099 . 2101 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2102 Errors at High Data Rates", RFC 4963, 2103 DOI 10.17487/RFC4963, July 2007, 2104 . 2106 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2107 NAT64: Network Address and Protocol Translation from IPv6 2108 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2109 April 2011, . 2111 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2112 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2113 DOI 10.17487/RFC6269, June 2011, 2114 . 2116 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2117 Stack Lite Broadband Deployments Following IPv4 2118 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2119 . 2121 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2122 Yasevich, "Sockets API Extensions for the Stream Control 2123 Transmission Protocol (SCTP)", RFC 6458, 2124 DOI 10.17487/RFC6458, December 2011, 2125 . 2127 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 2128 "Special-Purpose IP Address Registries", BCP 153, 2129 RFC 6890, DOI 10.17487/RFC6890, April 2013, 2130 . 2132 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2133 Control Transmission Protocol (SCTP) Packets for End-Host 2134 to End-Host Communication", RFC 6951, 2135 DOI 10.17487/RFC6951, May 2013, 2136 . 2138 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2139 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2140 . 2142 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2143 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2144 . 2146 Acknowledgments 2148 The authors wish to thank Mohamed Boucadair, Gorry Fairhurst, Bryan 2149 Ford, David Hayes, Alfred Hines, Karen E. E. Nielsen, Henning 2150 Peters, Maksim Proshin, Timo Voelker, Dan Wing, and Qiaobing Xie for 2151 their invaluable comments. 2153 In addition, the authors wish to thank David Hayes, Jason But, and 2154 Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for 2155 their suggestions. 2157 The authors also wish to thank Mohamed Boucadair for contributing the 2158 text related to the YANG module. 2160 Authors' Addresses 2162 Randall R. Stewart 2163 Netflix, Inc. 2164 Chapin, SC 29036 2165 United States of America 2167 Email: randall@lakerest.net 2169 Michael Tüxen 2170 Münster University of Applied Sciences 2171 Stegerwaldstrasse 39 2172 48565 Steinfurt 2173 Germany 2175 Email: tuexen@fh-muenster.de 2177 Irene Rüngeler 2178 Münster University of Applied Sciences 2179 Stegerwaldstrasse 39 2180 48565 Steinfurt 2181 Germany 2183 Email: i.ruengeler@fh-muenster.de