idnits 2.17.1 draft-ietf-tsvwg-natsupp-22.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 8 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 (16 November 2020) is 1258 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 493, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1944, 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: 20 May 2021 I. Rüngeler 6 Münster Univ. of Appl. Sciences 7 16 November 2020 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-22 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 needed for the SCTP 26 endpoints and the mechanisms for NAT functions necessary to provide 27 similar features of NAPT in the single point and multipoint traversal 28 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 20 May 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 and Overview . . . . . . . . . . . . . . . . . . . 6 69 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 70 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 7 71 4.1.2. Multipoint 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 . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 17 85 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 18 86 6.1. Association Setup Considerations for Endpoints . . . . . 19 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 . . . . . . . . . . . . . 22 96 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 98 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 24 99 6.6. Multi Point Traversal Considerations for Endpoints . . . 24 100 7. SCTP NAT YANG Module . . . . . . . . . . . . . . . . . . . . 24 101 7.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 24 102 7.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 103 8. Various Examples of NAT Traversals . . . . . . . . . . . . . 27 104 8.1. Single-homed Client to Single-homed Server . . . . . . . 28 105 8.2. Single-homed Client to Multi-homed Server . . . . . . . . 30 106 8.3. Multihomed Client and Server . . . . . . . . . . . . . . 32 107 8.4. NAT Function Loses Its State . . . . . . . . . . . . . . 35 108 8.5. Peer-to-Peer Communications . . . . . . . . . . . . . . . 37 109 9. Socket API Considerations . . . . . . . . . . . . . . . . . . 42 110 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 43 111 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 112 10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 43 113 10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 45 114 10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 46 115 10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 46 116 10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 46 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 118 12. Normative References . . . . . . . . . . . . . . . . . . . . 47 119 13. Informative References . . . . . . . . . . . . . . . . . . . 48 120 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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 function using private-use addresses (see [RFC6890]) and yet share a 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. 138 To date, specialized code for SCTP has not yet been added to most NAT 139 functions so that only a translation of IP addresses is supported. 140 The end result of this is that only one SCTP-capable host can 141 successfully operate behind such a NAT function and this host can 142 only be single-homed. The only alternative for supporting legacy NAT 143 functions is to use UDP encapsulation as specified in [RFC6951]. 145 The NAT function in the document refers to NAPT functions described 146 in Section 2.2 of [RFC3022], NAT64 [RFC6146], or DS-Lite AFTR 147 [RFC6333]. 149 This document specifies procedures allowing a NAT function to support 150 SCTP by providing similar features to those provided by a NAPT for 151 TCP (see [RFC5382] and [RFC7857]), UDP (see [RFC4787] and [RFC7857]), 152 and ICMP (see [RFC5508] and [RFC7857]). This document also specifies 153 a set of data formats for SCTP packets and a set of SCTP endpoint 154 procedures to support NAT traversal. An SCTP implementation 155 supporting these procedures can assure that in both single-homed and 156 multi-homed cases a NAT function will maintain the appropriate state 157 without the NAT function needing to change port numbers. 159 It is possible and desirable to make these changes for a number of 160 reasons: 162 * It is desirable for SCTP internal end-hosts on multiple platforms 163 to be able to share a NAT function's external IP address in the 164 same way that a TCP session can use a NAT function. 166 * If a NAT function does not need to change any data within an SCTP 167 packet, it will reduce the processing burden of NAT'ing SCTP by 168 not needing to execute the CRC32c checksum used by SCTP. 170 * Not having to touch the IP payload makes the processing of ICMP 171 messages by NAT functions easier. 173 An SCTP-aware NAT function will need to follow these procedures for 174 generating appropriate SCTP packet formats. 176 When considering SCTP-aware NAT it is possible to have multiple 177 levels of support. At each level, the Internal Host, Remote Host, 178 and NAT function does or does not support the procedures described in 179 this document. The following table illustrates the results of the 180 various combinations of support and if communications can occur 181 between two endpoints. 183 +===============+==============+=============+===============+ 184 | Internal Host | NAT Function | Remote Host | Communication | 185 +===============+==============+=============+===============+ 186 | Support | Support | Support | Yes | 187 +---------------+--------------+-------------+---------------+ 188 | Support | Support | No Support | Limited | 189 +---------------+--------------+-------------+---------------+ 190 | Support | No Support | Support | None | 191 +---------------+--------------+-------------+---------------+ 192 | Support | No Support | No Support | None | 193 +---------------+--------------+-------------+---------------+ 194 | No Support | Support | Support | Limited | 195 +---------------+--------------+-------------+---------------+ 196 | No Support | Support | No Support | Limited | 197 +---------------+--------------+-------------+---------------+ 198 | No Support | No Support | Support | None | 199 +---------------+--------------+-------------+---------------+ 200 | No Support | No Support | No Support | None | 201 +---------------+--------------+-------------+---------------+ 203 Table 1: Communication possibilities 205 From the table it can be seen that no communication can occur when a 206 NAT function does not support SCTP-aware NAT. This assumes that the 207 NAT function does not handle SCTP packets at all and all SCTP packets 208 sent from behind a NAT function are discarded by the NAT function. 209 In some cases, where the NAT function supports SCTP-aware NAT, but 210 one of the two hosts does not support the feature, communication can 211 possibly occur in a limited way. For example, only one host can have 212 a connection when a collision case occurs. 214 2. Conventions 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 3. Terminology 224 This document uses the following terms, which are depicted in 225 Figure 1. Familiarity with the terminology used in [RFC4960] and 226 [RFC5061] is assumed. 228 Internal-Address (Int-Addr) 229 An internal address that is known to the internal host. 231 Internal-Port (Int-Port) 232 The port number that is in use by the host holding the Internal- 233 Address. 235 Internal-VTag (Int-VTag) 236 The SCTP Verification Tag (VTag) (see Section 3.1 of [RFC4960]) 237 that the internal host has chosen for an association. The VTag is 238 a unique 32-bit tag that accompanies any incoming SCTP packet for 239 this association to the Internal-Address. 241 Remote-Address (Rem-Addr) 242 The address that an internal host is attempting to contact. 244 Remote-Port (Rem-Port) 245 The port number used by the host holding the Remote-Address. 247 Remote-VTag (Rem-VTag) 248 The Verification Tag (VTag) (see Section 3.1 of [RFC4960]) that 249 the host holding the Remote-Address has chosen for an association. 250 The VTag is a unique 32-bit tag that accompanies any outgoing SCTP 251 packet for this association to the Remote-Address. 253 External-Address (Ext-Addr) 254 An external address assigned to the NAT function, that it uses as 255 a source address when sending packets towards a Remote-Address. 257 Internal Network | External Network 258 | 259 Internal | External Remote 260 Address | Address /--\/--\ Address 261 +--------+ +-----+ / \ +--------+ 262 | Host A |=========| NAT |=======| Network |==========| Host B | 263 +--------+ +-----+ \ / +--------+ 264 Internal | \--/\--/ Remote 265 Internal Port | Port Remote 266 VTag | VTag 268 Figure 1: Basic Network Setup 270 4. Motivation and Overview 272 4.1. SCTP NAT Traversal Scenarios 274 This section defines the notion of single and multipoint NAT 275 traversal. 277 4.1.1. Single Point Traversal 279 In this case, all packets in the SCTP association go through a single 280 NAT function, as shown in Figure 2. 282 Internal Network | External Network 283 | 284 | /--\/--\ 285 +--------+ +-----+ / \ +--------+ 286 | Host A |=========| NAT |========= | Network | ========| Host B | 287 +--------+ +-----+ \ / +--------+ 288 | \--/\--/ 289 | 291 Figure 2: Single NAT Function Scenario 293 A variation of this case is shown in Figure 3, i.e., multiple NAT 294 functions in the forwarding path between two endpoints. 296 Internal | External : Internal | External 297 | : | 298 | : | /--\/--\ 299 +--------+ +-----+ : +-----+ / \ +--------+ 300 | Host A |==| NAT |=======:=======| NAT |==| Network |==| Host B | 301 +--------+ +-----+ : +-----+ \ / +--------+ 302 | : | \--/\--/ 303 | : | 305 Figure 3: Serial NAT Functions Scenario 307 Although one of the main benefits of SCTP multi-homing is redundant 308 paths, in the single point traversal scenario the NAT function 309 represents a single point of failure in the path of the SCTP multi- 310 homed association. However, the rest of the path can still benefit 311 from path diversity provided by SCTP multi-homing. 313 The two SCTP endpoints in this case can be either single-homed or 314 multi-homed. However, the important thing is that the NAT function 315 in this case sees all the packets of the SCTP association. 317 4.1.2. Multipoint Traversal 319 This case involves multiple NAT functions and each NAT function only 320 sees some of the packets in the SCTP association. An example is 321 shown in Figure 4. 323 Internal | External 324 +------+ /---\/---\ 325 /=======|NAT A |=========\ / \ 326 +--------+ / +------+ \/ \ +--------+ 327 | Host A |/ | | Network |===| Host B | 328 +--------+\ | \ / +--------+ 329 \ +------+ / \ / 330 \=======|NAT B |=========/ \---\/---/ 331 +------+ 332 | 334 Figure 4: Parallel NAT Functions Scenario 336 This case does not apply to a single-homed SCTP association (i.e., 337 both endpoints in the association use only one IP address). The 338 advantage here is that the existence of multiple NAT traversal points 339 can preserve the path diversity of a multi-homed association for the 340 entire path. This in turn can improve the robustness of the 341 communication. 343 4.2. Limitations of Classical NAPT for SCTP 345 Using classical NAPT possibly results in changing one of the SCTP 346 port numbers during the processing, which requires the recomputation 347 of the transport layer checksum by the NAPT function. Whereas for 348 UDP and TCP this can be done very efficiently, for SCTP the checksum 349 (CRC32c) over the entire packet needs to be recomputed (see 350 Appendix B of [RFC4960] for details of the CRC32c computation). This 351 would considerably add to the NAT computational burden, however 352 hardware support can mitigate this in some implementations. 354 An SCTP endpoint can have multiple addresses but only has a single 355 port number to use. To make multipoint traversal work, all the NAT 356 functions involved need to recognize the packets they see as 357 belonging to the same SCTP association and perform port number 358 translation in a consistent way. One possible way of doing this is 359 to use a pre-defined table of port numbers and addresses configured 360 within each NAT function. Other mechanisms could make use of NAT to 361 NAT communication. Such mechanisms have not been deployed on a wide 362 scale base and thus are not a preferred solution. Therefore an SCTP 363 variant of NAT function has been developed (see Section 4.3). 365 4.3. The SCTP-Specific Variant of NAT 367 In this section it is allowed that there are multiple SCTP capable 368 hosts behind a NAT function that share one External-Address. 369 Furthermore, this section focuses on the single point traversal 370 scenario (see Section 4.1.1). 372 The modification of outgoing SCTP packets sent from an internal host 373 is simple: the source address of the packets has to be replaced with 374 the External-Address. It might also be necessary to establish some 375 state in the NAT function to later handle incoming packets. 377 Typically, the NAT function has to maintain a NAT binding table of 378 Internal-VTag, Internal-Port, Remote-VTag, Remote-Port, Internal- 379 Address, and whether the restart procedure is disabled or not. An 380 entry in that NAT binding table is called a NAT-State control block. 381 The function Create() obtains the just mentioned parameters and 382 returns a NAT-State control block. A NAT function MAY allow creating 383 NAT-State control blocks via a management interface. 385 For SCTP packets coming from the external realm of the NAT function 386 the destination address of the packets has to be replaced with the 387 Internal-Address of the host to which the packet has to be delivered, 388 if a NAT state entry is found. The lookup of the Internal-Address is 389 based on the Remote-VTag, Remote-Port, Internal-VTag and the 390 Internal-Port. 392 The entries in the NAT binding table need to fulfill some uniqueness 393 conditions. There can not be more than one entry NAT binding table 394 with the same pair of Internal-Port and Remote-Port. This rule can 395 be relaxed, if all NAT binding table entries with the same Internal- 396 Port and Remote-Port have the support for the restart procedure 397 disabled (see Section 5.3.1). In this case there can not be no more 398 than one entry with the same Internal-Port, Remote-Port and Remote- 399 VTag and no more than one NAT binding table entry with the same 400 Internal-Port, Remote-Port, and Int-VTag. 402 The processing of outgoing SCTP packets containing an INIT chunk is 403 illustrated in the following figure. This scenario is valid for all 404 message flows in this section. 406 /--\/--\ 407 +--------+ +-----+ / \ +--------+ 408 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 409 +--------+ +-----+ \ / +--------+ 410 \--/\---/ 412 INIT[Initiate-Tag] 413 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 414 Rem-VTag=0 416 Create(Initiate-Tag, Int-Port, 0, Rem-Port, Int-Addr, 417 IsRestartDisabled) 418 Returns(NAT-State control block) 420 Translate To: 422 INIT[Initiate-Tag] 423 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 424 Rem-VTag=0 426 Normally a NAT binding table entry will be created. 428 However, it is possible that there is already a NAT binding table 429 entry with the same Remote-Port, Internal-Port, and Internal-VTag but 430 different Internal-Address and the restart procedure is disabled. In 431 this case the packet containing the INIT chunk MUST be dropped by the 432 NAT and a packet containing an ABORT chunk SHOULD be sent to the SCTP 433 host that originated the packet with the M bit set and 'VTag and Port 434 Number Collision' error cause (see Section 5.1.1 for the format). 435 The source address of the packet containing the ABORT chunk MUST be 436 the destination address of the packet containing the INIT chunk. 438 If an outgoing SCTP packet contains an INIT or ASCONF chunk and a 439 matching NAT binding table entry is found, the packet is processed as 440 a normal outgoing packet. 442 It is also possible that a NAT binding table entry with the same 443 Remote-Port and Internal-Port exists without an Internal-VTag 444 conflict but there exists a NAT binding table entry with the same 445 port numbers but a different Internal-Address and the restart 446 procedure is not disabled. In such a case the packet containing the 447 INIT chunk MUST be dropped by the NAT function and a packet 448 containing an ABORT chunk SHOULD be sent to the SCTP host that 449 originated the packet with the M bit set and 'Port Number Collision' 450 error cause (see Section 5.1.1 for the format). 452 The processing of outgoing SCTP packets containing no INIT chunks is 453 described in the following figure. 455 /--\/--\ 456 +--------+ +-----+ / \ +--------+ 457 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 458 +--------+ +-----+ \ / +--------+ 459 \--/\---/ 461 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 462 Rem-VTag 464 Translate To: 466 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 467 Rem-VTag 469 The processing of incoming SCTP packets containing an INIT ACK chunk 470 is illustrated in the following figure. The Lookup() function has as 471 input the Internal-VTag, Internal-Port, Remote-VTag, and Remote-Port. 472 It returns the corresponding entry of the NAT binding table and 473 updates the Remote-VTag by substituting it with the value of the 474 Initiate-Tag of the INIT ACK chunk. The wildcard character signifies 475 that the parameter's value is not considered in the Lookup() function 476 or changed in the Update() function, respectively. 478 /--\/--\ 479 +--------+ +-----+ / \ +--------+ 480 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 481 +--------+ +-----+ \ / +--------+ 482 \--/\---/ 484 INIT ACK[Initiate-Tag] 485 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 486 Int-VTag 488 Lookup(Int-VTag, Int-Port, *, Rem-Port) 489 Update(*, *, Initiate-Tag, *) 491 Returns(NAT-State control block containing Int-Addr) 493 INIT ACK[Initiate-Tag] 494 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 495 Int-VTag 497 In the case where the Lookup function fails because it does not find 498 an entry, the SCTP packet is dropped. If it succeeds, the Update 499 routine inserts the Remote-VTag (the Initiate-Tag of the INIT ACK 500 chunk) in the NAT-State control block. 502 The processing of incoming SCTP packets containing an ABORT or 503 SHUTDOWN COMPLETE chunk with the T bit set is illustrated in the 504 following figure. 506 /--\/--\ 507 +--------+ +-----+ / \ +--------+ 508 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 509 +--------+ +-----+ \ / +--------+ 510 \--/\---/ 512 Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port 513 Rem-VTag 515 Lookup(*, Int-Port, Rem-VTag, Rem-Port) 517 Returns(NAT-State control block containing Int-Addr) 519 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 520 Rem-VTag 522 For an incoming packet containing an INIT chunk a table lookup is 523 made only based on the addresses and port numbers. If an entry with 524 a Remote-VTag of zero is found, it is considered a match and the 525 Remote-VTag is updated. If an entry with a non-matching Remote-VTag 526 is found or no entry is found, the incoming packet is silently 527 dropped. If an entry with a matching Remote-VTag is found, the 528 incoming packet is forwarded. This allows the handling of INIT 529 collision through NAT functions. 531 The processing of other incoming SCTP packets is described in the 532 following figure. 534 /--\/--\ 535 +--------+ +-----+ / \ +--------+ 536 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 537 +--------+ +-----+ \ / +--------+ 538 \--/\---/ 540 Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port 541 Int-VTag 543 Lookup(Int-VTag, Int-Port, *, Rem-Port) 545 Returns(NAT-State control block containing Internal-Address) 547 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 548 Int-VTag 550 5. Data Formats 552 This section defines the formats used to support NAT traversal. 553 Section 5.1 and Section 5.2 describe chunks and error causes sent by 554 NAT functions and received by SCTP endpoints. Section 5.3 describes 555 parameters sent by SCTP endpoints and used by NAT functions and SCTP 556 endpoints. 558 5.1. Modified Chunks 560 This section presents existing chunks defined in [RFC4960] for which 561 additional flags are specified by this document. 563 5.1.1. Extended ABORT Chunk 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type = 6 | Reserved |M|T| Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 \ \ 571 / zero or more Error Causes / 572 \ \ 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 The ABORT chunk is extended to add the new 'M bit'. The M bit 576 indicates to the receiver of the ABORT chunk that the chunk was not 577 generated by the peer SCTP endpoint, but instead by a middle box 578 (e.g., NAT). 580 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 582 5.1.2. Extended ERROR Chunk 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type = 9 | Reserved |M|T| Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 \ \ 590 / zero or more Error Causes / 591 \ \ 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 The ERROR chunk defined in [RFC4960] is extended to add the new 'M 595 bit'. The M bit indicates to the receiver of the ERROR chunk that 596 the chunk was not generated by the peer SCTP endpoint, but instead by 597 a middle box. 599 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 601 5.2. New Error Causes 603 This section defines the new error causes added by this document. 605 5.2.1. VTag and Port Number Collision Error Cause 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Cause Code = 0x00B0 | Cause Length = Variable | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 \ Chunk / 613 / \ 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Cause Code: 2 bytes (unsigned integer) 617 This field holds the IANA defined cause code for the 'VTag and 618 Port Number Collision' Error Cause. IANA is requested to assign 619 the value 0x00B0 for this cause code. 621 Cause Length: 2 bytes (unsigned integer) 622 This field holds the length in bytes of the error cause. The 623 value MUST be the length of the Cause-Specific Information plus 4. 625 Chunk: variable length 626 The Cause-Specific Information is filled with the chunk that 627 caused this error. This can be an INIT, INIT ACK, or ASCONF 628 chunk. Note that if the entire chunk will not fit in the ERROR 629 chunk or ABORT chunk being sent then the bytes that do not fit are 630 truncated. 632 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 633 IANA.] 635 5.2.2. Missing State Error Cause 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Cause Code = 0x00B1 | Cause Length = Variable | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 \ Original Packet / 643 / \ 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Cause Code: 2 bytes (unsigned integer) 647 This field holds the IANA defined cause code for the 'Missing 648 State' Error Cause. IANA is requested to assign the value 0x00B1 649 for this cause code. 651 Cause Length: 2 bytes (unsigned integer) 652 This field holds the length in bytes of the error cause. The 653 value MUST be the length of the Cause-Specific Information plus 4. 655 Original Packet: variable length 656 The Cause-Specific Information is filled with the IPv4 or IPv6 657 packet that caused this error. The IPv4 or IPv6 header MUST be 658 included. Note that if the packet will not fit in the ERROR chunk 659 or ABORT chunk being sent then the bytes that do not fit are 660 truncated. 662 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 663 IANA.] 665 5.2.3. Port Number Collision Error Cause 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Cause Code = 0x00B2 | Cause Length = Variable | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 \ Chunk / 672 / \ 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Cause Code: 2 bytes (unsigned integer) 676 This field holds the IANA defined cause code for the 'Port Number 677 Collision' Error Cause. IANA is requested to assign the value 678 0x00B2 for this cause code. 680 Cause Length: 2 bytes (unsigned integer) 681 This field holds the length in bytes of the error cause. The 682 value MUST be the length of the Cause-Specific Information plus 4. 684 Chunk: variable length 685 The Cause-Specific Information is filled with the chunk that 686 caused this error. This can be an INIT, INIT ACK, or ASCONF 687 chunk. Note that if the entire chunk will not fit in the ERROR 688 chunk or ABORT chunk being sent then the bytes that do not fit are 689 truncated. 691 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 692 IANA.] 694 5.3. New Parameters 696 This section defines new parameters and their valid appearance 697 defined by this document. 699 5.3.1. Disable Restart Parameter 701 This parameter is used to indicate that the restart procedure is 702 requested to be disabled. Both endpoints of an association MUST 703 include this parameter in the INIT chunk and INIT ACK chunk when 704 establishing an association and MUST include it in the ASCONF chunk 705 when adding an address to successfully disable the restart procedure. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Type = 0xC007 | Length = 4 | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Parameter Type: 2 bytes (unsigned integer) 714 This field holds the IANA defined parameter type for the Disable 715 Restart Parameter. IANA is requested to assign the value 0xC007 716 for this parameter type. 718 Parameter Length: 2 bytes (unsigned integer) 719 This field holds the length in bytes of the parameter. The value 720 MUST be 4. 722 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 723 IANA.] 725 The Disable Restart Parameter MAY appear in INIT, INIT ACK and ASCONF 726 chunks and MUST NOT appear in any other chunk. 728 5.3.2. VTags Parameter 730 This parameter is used to help a NAT function to recover from state 731 loss. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Parameter Type = 0xC008 | Parameter Length = 16 | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | ASCONF-Request Correlation ID | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Internal Verification Tag | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Remote Verification Tag | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Parameter Type: 2 bytes (unsigned integer) 746 This field holds the IANA defined parameter type for the VTags 747 Parameter. IANA is requested to assign the value 0xC008 for this 748 parameter type. 750 Parameter Length: 2 bytes (unsigned integer) 751 This field holds the length in bytes of the parameter. The value 752 MUST be 16. 754 ASCONF-Request Correlation ID: 4 bytes (unsigned integer) 755 This is an opaque integer assigned by the sender to identify each 756 request parameter. The receiver of the ASCONF Chunk will copy 757 this 32-bit value into the ASCONF Response Correlation ID field of 758 the ASCONF ACK response parameter. The sender of the packet 759 containing the ASCONF chunk can use this same value in the ASCONF 760 ACK chunk to find which request the response is for. The receiver 761 MUST NOT change the value of the ASCONF-Request Correlation ID. 763 Internal Verification Tag: 4 bytes (unsigned integer) 764 The Verification Tag that the internal host has chosen for the 765 association. The Verification Tag is a unique 32-bit tag that 766 accompanies any incoming SCTP packet for this association to the 767 Internal-Address. 769 Remote Verification Tag: 4 bytes (unsigned integer) 770 The Verification Tag that the host holding the Remote-Address has 771 chosen for the association. The VTag is a unique 32-bit tag that 772 accompanies any outgoing SCTP packet for this association to the 773 Remote-Address. 775 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 776 IANA.] 778 The VTags Parameter MAY appear in ASCONF chunks and MUST NOT appear 779 in any other chunk. 781 6. Procedures for SCTP Endpoints and NAT Functions 783 If an SCTP endpoint is behind an SCTP-aware NAT, a number of problems 784 can arise as it tries to communicate with its peers: 786 * IP addresses can not be included in the SCTP packet. This is 787 discussed in Section 6.1. 789 * More than one host behind a NAT function could select the same 790 VTag and source port number when communicating with the same peer 791 server. This creates a situation where the NAT function will not 792 be able to tell the two associations apart. This situation is 793 discussed in Section 6.2. 795 * If an SCTP endpoint is a server communicating with multiple peers 796 and the peers are behind the same NAT function, then the these 797 peers cannot be distinguished by the server. This case is 798 discussed in Section 6.3. 800 * A restart of a NAT function during a conversation could cause a 801 loss of its state. This problem and its solution is discussed in 802 Section 6.4. 804 * NAT functions need to deal with SCTP packets being fragmented at 805 the IP layer. This is discussed in Section 6.5. 807 * An SCTP endpoint can be behind two NAT functions in parallel 808 providing redundancy. The method to set up this scenario is 809 discussed in Section 6.6. 811 The mechanisms to solve these problems require additional chunks and 812 parameters, defined in this document, and modified handling 813 procedures from those specified in [RFC4960] as described below. 815 6.1. Association Setup Considerations for Endpoints 817 The association setup procedure defined in [RFC4960] allows multi- 818 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 819 IPv6 address parameters in the INIT and INIT ACK chunks. However, 820 this does not work when NAT functions are present. 822 Every association setup from a host behind a NAT function MUST NOT 823 use multiple internal addresses. The INIT chunk MUST NOT contain an 824 IPv4 Address parameter, IPv6 Address parameter, or Supported Address 825 Types parameter. The INIT ACK chunk MUST NOT contain any IPv4 826 Address parameter or IPv6 Address parameter using non-global 827 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 828 any Host Name parameters. 830 If the association is intended to be finally multi-homed, the 831 procedure in Section 6.6 MUST be used. 833 The INIT and INIT ACK chunk SHOULD contain the Disable Restart 834 parameter defined in Section 5.3.1. 836 6.2. Handling of Internal Port Number and Verification Tag Collisions 838 Consider the case where two hosts in the Internal-Address space want 839 to set up an SCTP association with the same service provided by some 840 remote hosts. This means that the Remote-Port is the same. If they 841 both choose the same Internal-Port and Internal-VTag, the NAT 842 function cannot distinguish between incoming packets anymore. 843 However, this is unlikely. The Internal-VTags are chosen at random 844 and if the Internal-Ports are also chosen from the ephemeral port 845 range at random (see [RFC6056]) this gives a 46-bit random number 846 that has to match. 848 The same can happen with the Remote-VTag when a packet containing an 849 INIT ACK chunk or an ASCONF chunk is processed by the NAT function. 851 6.2.1. NAT Function Considerations 853 If the NAT function detects a collision of internal port numbers and 854 verification tags, it SHOULD send a packet containing an ABORT chunk 855 with the M bit set if the collision is triggered by a packet 856 containing an INIT or INIT ACK chunk. If such a collision is 857 triggered by a packet containing an ASCONF chunk, it SHOULD send a 858 packet containing an ERROR chunk with the M bit. The M bit is a new 859 bit defined by this document to express to SCTP that the source of 860 this packet is a "middle" box, not the peer SCTP endpoint (see 861 Section 5.1.1). If a packet containing an INIT ACK chunk triggers 862 the collision, the corresponding packet containing the ABORT chunk 863 MUST contain the same source and destination address and port numbers 864 as the packet containing the INIT ACK chunk. If a packet containing 865 an INIT chunk or an ASCONF chunk, the source and destination address 866 and port numbers MUST be swapped. 868 The sender of the packet containing an ERROR or ABORT chunk MUST 869 include the error cause with cause code 'VTag and Port Number 870 Collision' (see Section 5.2.1). 872 6.2.2. Endpoint Considerations 874 The sender of the packet containing the INIT chunk or the receiver of 875 a packet containing the INIT ACK chunk, upon reception of a packet 876 containing an ABORT chunk with M bit set and the appropriate error 877 cause code for colliding NAT binding table state is included, SHOULD 878 reinitiate the association setup procedure after choosing a new 879 initiate tag, if the association is in COOKIE-WAIT state. In any 880 other state, the SCTP endpoint MUST NOT respond. 882 The sender of the packet containing the ASCONF chunk, upon reception 883 of a packet containing an ERROR chunk with M bit set, MUST stop 884 adding the path to the association. 886 6.3. Handling of Internal Port Number Collisions 888 When two SCTP hosts are behind an SCTP-aware NAT it is possible that 889 two SCTP hosts in the Internal-Address space will want to set up an 890 SCTP association with the same server running on the same remote 891 host. If the two hosts choose the same internal port, this is 892 considered an internal port number collision. 894 For the NAT function, appropriate tracking can be performed by 895 assuring that the VTags are unique between the two hosts. 897 6.3.1. NAT Function Considerations 899 The NAT function, when processing the packet containing the INIT ACK 900 chunk, SHOULD note in its NAT binding table if the association 901 supports the disable restart extension. This note is used when 902 establishing future associations (i.e. when processing a packet 903 containing an INIT chunk from an internal host) to decide if the 904 connection can be allowed. The NAT function does the following when 905 processing a packet containing an INIT chunk: 907 * If the packet containing the INIT chunk is originating from an 908 internal port to a remote port for which the NAT function has no 909 matching NAT binding table entry, it MUST allow the packet 910 containing the INIT chunk creating an NAT binding table entry. 912 * If the packet containing the INIT chunk matches an existing NAT 913 binding table entry, it MUST validate that the disable restart 914 feature is supported and, if it does, allow the packet containing 915 the INIT chunk to be forwarded. 917 * If the disable restart feature is not supported, the NAT function 918 SHOULD send a packet containing an ABORT chunk with the M bit set. 920 The 'Port Number Collision' error cause (see Section 5.2.3) MUST be 921 included in the ABORT chunk sent in response to the packet containing 922 an INIT chunk. 924 If the collision is triggered by a packet containing an ASCONF chunk, 925 a packet containing an ERROR chunk with the 'Port Number Collision' 926 error cause SHOULD be sent in response to the packet containing the 927 ASCONF chunk. 929 6.3.2. Endpoint Considerations 931 For the remote SCTP server this means that the Remote-Port and the 932 Remote-Address are the same. If they both have chosen the same 933 Internal-Port the server cannot distinguish between both associations 934 based on the address and port numbers. For the server it looks like 935 the association is being restarted. To overcome this limitation the 936 client sends a Disable Restart parameter in the INIT chunk. 938 When the server receives this parameter it does the following: 940 * It MUST include a Disable Restart parameter in the INIT ACK to 941 inform the client that it will support the feature. 943 * It MUST disable the restart procedures defined in [RFC4960] for 944 this association. 946 Servers that support this feature will need to be capable of 947 maintaining multiple connections to what appears to be the same peer 948 (behind the NAT function) differentiated only by the VTags. 950 6.4. Handling of Missing State 951 6.4.1. NAT Function Considerations 953 If the NAT function receives a packet from the internal network for 954 which the lookup procedure does not find an entry in the NAT binding 955 table, a packet containing an ERROR chunk SHOULD be sent back with 956 the M bit set. The source address of the packet containing the ERROR 957 chunk MUST be the destination address of the packet received from the 958 internal network. The verification tag is reflected and the T bit is 959 set. Such a packet containing an ERROR chunk SHOULD NOT be sent if 960 the received packet contains an ASCONF chunk with the VTags parameter 961 or an ABORT, SHUTDOWN COMPLETE or INIT ACK chunk. A packet 962 containing an ERROR chunk MUST NOT be sent if the received packet 963 contains an ERROR chunk with the M bit set. In any case, the packet 964 SHOULD NOT be forwarded to the remote address. 966 If the NAT function receives a packet from the internal network for 967 which it has no NAT binding table entry and the packet contains an 968 ASCONF chunk with the VTags parameter, the NAT function MUST update 969 its NAT binding table according to the verification tags in the VTags 970 parameter and, if present, the Disable Restart parameter. 972 When sending a packet containing an ERROR chunk, the error cause 973 'Missing State' (see Section 5.2.2) MUST be included and the M bit of 974 the ERROR chunk MUST be set (see Section 5.1.2). 976 6.4.2. Endpoint Considerations 978 Upon reception of this packet containing the ERROR chunk by an SCTP 979 endpoint the receiver takes the following actions: 981 * It SHOULD validate that the verification tag is reflected by 982 looking at the VTag that would have been included in an outgoing 983 packet. If the validation fails, discard the received packet 984 containing the ERROR chunk. 986 * It SHOULD validate that the peer of the SCTP association supports 987 the dynamic address extension. If the validation fails, discard 988 the received packet containing the ERROR chunk. 990 * It SHOULD generate a packet containing a new ASCONF chunk 991 containing the VTags parameter (see Section 5.3.2) and the Disable 992 Restart parameter (see Section 5.3.1) if the association is using 993 the disable restart feature. By processing this packet the NAT 994 function can recover the appropriate state. The procedures for 995 generating an ASCONF chunk can be found in [RFC5061]. 997 The peer SCTP endpoint receiving such a packet containing an ASCONF 998 chunk SHOULD add the address and respond with an acknowledgment if 999 the address is new to the association (following all procedures 1000 defined in [RFC5061]). If the address is already part of the 1001 association, the SCTP endpoint MUST NOT respond with an error, but 1002 instead SHOULD respond with a packet containing an ASCONF ACK chunk 1003 acknowledging the address and take no action (since the address is 1004 already in the association). 1006 Note that it is possible that upon receiving a packet containing an 1007 ASCONF chunk containing the VTags parameter the NAT function will 1008 realize that it has an 'Internal Port Number and Verification Tag 1009 collision'. In such a case the NAT function SHOULD send a packet 1010 containing an ERROR chunk with the error cause code set to 'VTag and 1011 Port Number Collision' (see Section 5.2.1). 1013 If an SCTP endpoint receives a packet containing an ERROR chunk with 1014 'Internal Port Number and Verification Tag collision' as the error 1015 cause and the packet in the Error Chunk contains an ASCONF with the 1016 VTags parameter, careful examination of the association is necessary. 1017 The endpoint does the following: 1019 * It MUST validate that the verification tag is reflected by looking 1020 at the VTag that would have been included in the outgoing packet. 1021 If the validation fails, it MUST discard the packet. 1023 * It MUST validate that the peer of the SCTP association supports 1024 the dynamic address extension. If the peer does not support this 1025 extension, it MUST discard the received packet containing the 1026 ERROR chunk. 1028 * If the association is attempting to add an address (i.e. following 1029 the procedures in Section 6.6) then the endpoint MUST NOT consider 1030 the address part of the association and SHOULD make no further 1031 attempt to add the address (i.e. cancel any ASCONF timers and 1032 remove any record of the path), since the NAT function has a VTag 1033 collision and the association cannot easily create a new VTag (as 1034 it would if the error occurred when sending a packet containing an 1035 INIT chunk). 1037 * If the endpoint has no other path, i.e. the procedure was executed 1038 due to missing a state in the NAT function, then the endpoint MUST 1039 abort the association. This would occur only if the local NAT 1040 function restarted and accepted a new association before 1041 attempting to repair the missing state (Note that this is no 1042 different than what happens to all TCP connections when a NAT 1043 function looses its state). 1045 6.5. Handling of Fragmented SCTP Packets by NAT Functions 1047 SCTP minimizes the use of IP-level fragmentation. However, it can 1048 happen that using IP-level fragmentation is needed to continue an 1049 SCTP association. For example, if the path MTU is reduced and there 1050 are still some DATA chunk in flight, which require packets larger 1051 than the new path MTU. If IP-level fragmentation can not be used, 1052 the SCTP association will be terminated in a non-graceful way. See 1053 [RFC8900] for more information about IP fragmentation. 1055 Therefore, a NAT function MUST be able to handle IP-level fragmented 1056 SCTP packets. The fragments MAY arrive in any order. 1058 When an SCTP packet can not be forwarded by the NAT function due to 1059 MTU issues and the IP header forbids fragmentation, the NAT MUST send 1060 back a "Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message 1061 to the internal host. This allows for a faster recovery from this 1062 packet drop. 1064 6.6. Multi Point Traversal Considerations for Endpoints 1066 If a multi-homed SCTP endpoint behind a NAT function connects to a 1067 peer, it MUST first set up the association single-homed with only one 1068 address causing the first NAT function to populate its state. Then 1069 it SHOULD add each IP address using packets containing ASCONF chunks 1070 sent via their respective NAT functions. The address used in the Add 1071 IP address parameter is the wildcard address (0.0.0.0 or ::0) and the 1072 address parameter in the ASCONF chunk SHOULD also contain the VTags 1073 parameter and optionally the Disable Restart parameter. 1075 7. SCTP NAT YANG Module 1077 This section defines a YANG module for SCTP NAT. 1079 The terminology for describing YANG data models is defined in 1080 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 1081 [RFC8340]. 1083 7.1. Tree Structure 1085 This module augments NAT YANG module [RFC8512] with SCTP specifics. 1086 The module supports both classical SCTP NAT (that is, rewrite port 1087 numbers) and SCTP-specific variant where the ports numbers are not 1088 altered. The YANG "feature" is used to indicate whether SCTP- 1089 specific variant is supported. 1091 The tree structure of the SCTP NAT YANG module is provided below: 1093 module: ietf-nat-sctp 1094 augment /nat:nat/nat:instances/nat:instance 1095 /nat:policy/nat:timers: 1096 +--rw sctp-timeout? uint32 1097 augment /nat:nat/nat:instances/nat:instance 1098 /nat:mapping-table/nat:mapping-entry: 1099 +--rw int-VTag? uint32 {sctp-nat}? 1100 +--rw rem-VTag? uint32 {sctp-nat}? 1102 Concretely, the SCTP NAT YANG module augments the NAT YANG module 1103 (policy, in particular) with the following: 1105 * The sctp-timeout is used to control the SCTP inactivity timeout. 1106 That is, the time an SCTP mapping will stay active without SCTP 1107 packets traversing the NAT. This timeout can be set only for 1108 SCTP. Hence, "/nat:nat/nat:instances/nat:instance/nat:policy/ 1109 nat:transport-protocols/nat:protocol-id" MUST be set to '132' 1110 (SCTP). 1112 In addition, the SCTP NAT YANG module augments the mapping entry with 1113 the following parameters defined in Section 3. These parameters 1114 apply only for SCTP NAT mapping entries (i.e., 1115 "/nat/instances/instance/mapping-table/mapping-entry/transport- 1116 protocol" MUST be set to '132'); 1118 * The Internal Verification Tag (Int-VTag) 1120 * The Remote Verification Tag (Rem-VTag) 1122 7.2. YANG Module 1124 file "ietf-nat-sctp@2020-11-02.yang" 1125 module ietf-nat-sctp { 1126 yang-version 1.1; 1127 namespace "urn:ietf:params:xml:ns:yang:ietf-nat-sctp"; 1128 prefix nat-sctp; 1130 import ietf-nat { 1131 prefix nat; 1132 reference 1133 "RFC 8512: A YANG Module for Network Address Translation 1134 (NAT) and Network Prefix Translation (NPT)"; 1135 } 1137 organization 1138 "IETF TSVWG Working Group"; 1139 contact 1140 "WG Web: 1141 WG List: 1143 Author: Mohamed Boucadair 1144 "; 1145 description 1146 "This module augments NAT YANG module with Stream Control 1147 Transmission Protocol (SCTP) specifics. The extension supports 1148 both a classical SCTP NAT (that is, rewrite port numbers) 1149 and a, SCTP-specific variant where the ports numbers are 1150 not altered. 1152 Copyright (c) 2020 IETF Trust and the persons identified as 1153 authors of the code. All rights reserved. 1155 Redistribution and use in source and binary forms, with or 1156 without modification, is permitted pursuant to, and subject 1157 to the license terms contained in, the Simplified BSD License 1158 set forth in Section 4.c of the IETF Trust's Legal Provisions 1159 Relating to IETF Documents 1160 (http://trustee.ietf.org/license-info). 1162 This version of this YANG module is part of RFC XXXX; see 1163 the RFC itself for full legal notices."; 1165 revision 2019-11-18 { 1166 description 1167 "Initial revision."; 1168 reference 1169 "RFC XXXX: Stream Control Transmission Protocol (SCTP) 1170 Network Address Translation Support"; 1171 } 1173 feature sctp-nat { 1174 description 1175 "This feature means that SCTP-specific variant of NAT 1176 is supported. That is, avoid rewriting port numbers."; 1177 reference 1178 "Section 4.3 of RFC XXXX."; 1179 } 1181 augment "/nat:nat/nat:instances/nat:instance" 1182 + "/nat:policy/nat:timers" { 1183 when "/nat:nat/nat:instances/nat:instance" 1184 + "/nat:policy/nat:transport-protocols" 1185 + "/nat:protocol-id = 132"; 1186 description 1187 "Extends NAT policy with a timeout for SCTP mapping 1188 entries."; 1190 leaf sctp-timeout { 1191 type uint32; 1192 units "seconds"; 1193 description 1194 "SCTP inactivity timeout. That is, the time an SCTP 1195 mapping entry will stay active without packets 1196 traversing the NAT."; 1197 } 1198 } 1200 augment "/nat:nat/nat:instances/nat:instance" 1201 + "/nat:mapping-table/nat:mapping-entry" { 1202 when "nat:transport-protocol = 132"; 1203 if-feature "sctp-nat"; 1204 description 1205 "Extends the mapping entry with SCTP specifics."; 1207 leaf int-VTag { 1208 type uint32; 1209 description 1210 "The Internal Verification Tag that the internal 1211 host has chosen for this communication."; 1212 } 1213 leaf rem-VTag { 1214 type uint32; 1215 description 1216 "The Remote Verification Tag that the remote 1217 peer has chosen for this communication."; 1218 } 1219 } 1220 } 1221 1223 8. Various Examples of NAT Traversals 1225 Please note that this section is informational only. 1227 The addresses being used in the following examples are IPv4 addresses 1228 for private-use networks and for documentation as specified in 1229 [RFC6890]. However, the method described here is not limited to this 1230 NAT44 case. 1232 The NAT binding table entries shown in the following examples do not 1233 include the flag indicating whether the restart procedure is 1234 supported or not. This flag is not relevant for these examples. 1236 8.1. Single-homed Client to Single-homed Server 1238 The internal client starts the association with the remote server via 1239 a four-way-handshake. Host A starts by sending a packet containing 1240 an INIT chunk. 1242 /--\/--\ 1243 +--------+ +-----+ / \ +--------+ 1244 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 1245 +--------+ +-----+ \ / +--------+ 1246 \--/\---/ 1247 +---------+--------+----------+--------+-----------+ 1248 NAT | Int | Int | Rem | Rem | Int | 1249 | VTag | Port | VTag | Port | Addr | 1250 +---------+--------+----------+--------+-----------+ 1252 INIT[Initiate-Tag = 1234] 1253 10.0.0.1:1 ------> 203.0.113.1:2 1254 Rem-VTtag = 0 1256 A NAT binding tabled entry is created, the source address is 1257 substituted and the packet is sent on: 1259 NAT function creates entry: 1260 +---------+--------+----------+--------+-----------+ 1261 NAT | Int | Int | Rem | Rem | Int | 1262 | VTag | Port | VTag | Port | Addr | 1263 +---------+--------+----------+--------+-----------+ 1264 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1265 +---------+--------+----------+--------+-----------+ 1267 INIT[Initiate-Tag = 1234] 1268 192.0.2.1:1 ------------------------> 203.0.113.1:2 1269 Rem-VTtag = 0 1271 Host B receives the packet containing an INIT chunk and sends a 1272 packet containing an INIT ACK chunk with the NAT's Remote-address as 1273 destination address. 1275 /--\/--\ 1276 +--------+ +-----+ / \ +--------+ 1277 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 1278 +--------+ +-----+ \ / +--------+ 1279 \--/\---/ 1281 INIT ACK[Initiate-Tag = 5678] 1282 192.0.2.1:1 <----------------------- 203.0.113.1:2 1283 Int-VTag = 1234 1285 NAT function updates entry: 1286 +---------+--------+----------+--------+-----------+ 1287 NAT | Int | Int | Rem | Rem | Int | 1288 | VTag | Port | VTag | Port | Addr | 1289 +---------+--------+----------+--------+-----------+ 1290 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1291 +---------+--------+----------+--------+-----------+ 1293 INIT ACK[Initiate-Tag = 5678] 1294 10.0.0.1:1 <------ 203.0.113.1:2 1295 Int-VTag = 1234 1297 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1298 ACK. 1300 /--\/--\ 1301 +--------+ +-----+ / \ +--------+ 1302 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 1303 +--------+ +-----+ \ / +--------+ 1304 \--/\---/ 1306 COOKIE ECHO 1307 10.0.0.1:1 ------> 203.0.113.1:2 1308 Rem-VTag = 5678 1310 COOKIE ECHO 1311 192.0.2.1:1 -----------------------> 203.0.113.1:2 1312 Rem-VTag = 5678 1314 COOKIE ACK 1315 192.0.2.1:1 <----------------------- 203.0.113.1:2 1316 Int-VTag = 1234 1318 COOKIE ACK 1319 10.0.0.1:1 <------ 203.0.113.1:2 1320 Int-VTag = 1234 1322 8.2. Single-homed Client to Multi-homed Server 1324 The internal client is single-homed whereas the remote server is 1325 multi-homed. The client (Host A) sends a packet containing an INIT 1326 chunk like in the single-homed case. 1328 +--------+ 1329 /--\/--\ /-|Router 1| \ 1330 +------+ +-----+ / \ / +--------+ \ +------+ 1331 | Host | <-----> | NAT | <-> | Network | == =| Host | 1332 | A | +-----+ \ / \ +--------+ / | B | 1333 +------+ \--/\--/ \-|Router 2|-/ +------+ 1334 +--------+ 1336 +---------+--------+----------+--------+-----------+ 1337 NAT | Int | Int | Rem | Rem | Int | 1338 | VTag | Port | VTag | Port | Addr | 1339 +---------+--------+----------+--------+-----------+ 1341 INIT[Initiate-Tag = 1234] 1342 10.0.0.1:1 ---> 203.0.113.1:2 1343 Rem-VTag = 0 1345 NAT function creates entry: 1347 +---------+--------+----------+--------+-----------+ 1348 NAT | Int | Int | Rem | Rem | Int | 1349 | VTag | Port | VTag | Port | Addr | 1350 +---------+--------+----------+--------+-----------+ 1351 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1352 +---------+--------+----------+--------+-----------+ 1354 INIT[Initiate-Tag = 1234] 1355 192.0.2.1:1 --------------------------> 203.0.113.1:2 1356 Rem-VTag = 0 1358 The server (Host B) includes its two addresses in the INIT ACK chunk. 1360 +--------+ 1361 /--\/--\ /-|Router 1| \ 1362 +------+ +-----+ / \ / +--------+ \ +------+ 1363 | Host | <-----> | NAT | <-> | Network | == =| Host | 1364 | A | +-----+ \ / \ +--------+ / | B | 1365 +------+ \--/\--/ \-|Router 2|-/ +------+ 1366 +--------+ 1368 INIT ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129] 1369 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1370 Int-VTag = 1234 1372 The NAT function does not need to change the NAT binding table for 1373 the second address: 1375 +---------+--------+----------+--------+-----------+ 1376 NAT | Int | Int | Rem | Rem | Int | 1377 | VTag | Port | VTag | Port | Addr | 1378 +---------+--------+----------+--------+-----------+ 1379 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1380 +---------+--------+----------+--------+-----------+ 1382 INIT ACK[Initiate-Tag = 5678] 1383 10.0.0.1:1 <--- 203.0.113.1:2 1384 Int-VTag = 1234 1386 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1387 ACK. 1389 +--------+ 1390 /--\/--\ /-|Router 1| \ 1391 +------+ +-----+ / \ / +--------+ \ +------+ 1392 | Host | <-----> | NAT | <-> | Network | == =| Host | 1393 | A | +-----+ \ / \ +--------+ / | B | 1394 +------+ \--/\--/ \-|Router 2|-/ +------+ 1395 +--------+ 1397 COOKIE ECHO 1398 10.0.0.1:1 ---> 203.0.113.1:2 1399 Rem-VTag = 5678 1401 COOKIE ECHO 1402 192.0.2.1:1 --------------------------> 203.0.113.1:2 1403 Rem-VTag = 5678 1405 COOKIE ACK 1406 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1407 Int-VTag = 1234 1409 COOKIE ACK 1410 10.0.0.1:1 <--- 203.0.113.1:2 1411 Int-VTag = 1234 1413 8.3. Multihomed Client and Server 1415 The client (Host A) sends a packet containing an INIT chunk to the 1416 server (Host B), but does not include the second address. 1418 +-------+ 1419 /--| NAT 1 |--\ /--\/--\ 1420 +------+ / +-------+ \ / \ +--------+ 1421 | Host |=== ====| Network |====| Host B | 1422 | A | \ +-------+ / \ / +--------+ 1423 +------+ \--| NAT 2 |--/ \--/\--/ 1424 +-------+ 1426 +---------+--------+----------+--------+-----------+ 1427 NAT 1 | Int | Int | Rem | Rem | Int | 1428 | VTag | Port | VTag | Port | Addr | 1429 +---------+--------+----------+--------+-----------+ 1431 INIT[Initiate-Tag = 1234] 1432 10.0.0.1:1 --------> 203.0.113.1:2 1433 Rem-VTag = 0 1435 NAT function 1 creates entry: 1437 +---------+--------+----------+--------+-----------+ 1438 NAT 1 | Int | Int | Rem | Rem | Int | 1439 | VTag | Port | VTag | Port | Addr | 1440 +---------+--------+----------+--------+-----------+ 1441 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1442 +---------+--------+----------+--------+-----------+ 1444 INIT[Initiate-Tag = 1234] 1445 192.0.2.1:1 ---------------------> 203.0.113.1:2 1446 Rem-VTag = 0 1448 Host B includes its second address in the INIT ACK. 1450 +-------+ 1451 /--------| NAT 1 |--------\ /--\/--\ 1452 +------+ / +-------+ \ / \ +--------+ 1453 | Host |=== ====| Network |===| Host B | 1454 | A | \ +-------+ / \ / +--------+ 1455 +------+ \--------| NAT 2 |--------/ \--/\--/ 1456 +-------+ 1458 INIT ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129] 1459 192.0.2.1:1 <----------------------- 203.0.113.1:2 1460 Int-VTag = 1234 1462 NAT function 1 does not need to update the NAT binding table for the 1463 second address: 1465 +---------+--------+----------+--------+-----------+ 1466 NAT 1 | Int | Int | Rem | Rem | Int | 1467 | VTag | Port | VTag | Port | Addr | 1468 +---------+--------+----------+--------+-----------+ 1469 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1470 +---------+--------+----------+--------+-----------+ 1472 INIT ACK[Initiate-Tag = 5678] 1473 10.0.0.1:1 <-------- 203.0.113.1:2 1474 Int-VTag = 1234 1476 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1477 ACK. 1479 +-------+ 1480 /--------| NAT 1 |--------\ /--\/--\ 1481 +------+ / +-------+ \ / \ +--------+ 1482 | Host |=== ====| Network |===| Host B | 1483 | A | \ +-------+ / \ / +--------+ 1484 +------+ \--------| NAT 2 |--------/ \--/\--/ 1485 +-------+ 1487 COOKIE ECHO 1488 10.0.0.1:1 --------> 203.0.113.1:2 1489 Rem-VTag = 5678 1491 COOKIE ECHO 1492 192.0.2.1:1 ------------------> 203.0.113.1:2 1493 Rem-VTag = 5678 1495 COOKIE ACK 1496 192.0.2.1:1 <------------------ 203.0.113.1:2 1497 Int-VTag = 1234 1499 COOKIE ACK 1500 10.0.0.1:1 <------- 203.0.113.1:2 1501 Int-VTag = 1234 1503 Host A announces its second address in an ASCONF chunk. The address 1504 parameter contains a wildcard address (0.0.0.0 or ::0) to indicate 1505 that the source address has to be be added. The address parameter 1506 within the ASCONF chunk will also contain the pair of VTags (remote 1507 and internal) so that the NAT function can populate its NAT binding 1508 table entry completely with this single packet. 1510 +-------+ 1511 /--------| NAT 1 |--------\ /--\/--\ 1512 +------+ / +-------+ \ / \ +--------+ 1513 | Host |=== ====| Network |===| Host B | 1514 | A | \ +-------+ / \ / +--------+ 1515 +------+ \--------| NAT 2 |--------/ \--/\--/ 1516 +-------+ 1518 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Rem-VTag = 5678] 1519 10.1.0.1:1 --------> 203.0.113.129:2 1520 Rem-VTag = 5678 1522 NAT function 2 creates a complete entry: 1524 +---------+--------+----------+--------+-----------+ 1525 NAT 2 | Int | Int | Rem | Rem | Int | 1526 | VTag | Port | VTag | Port | Addr | 1527 +---------+--------+----------+--------+-----------+ 1528 | 1234 | 1 | 5678 | 2 | 10.1.0.1 | 1529 +---------+--------+----------+--------+-----------+ 1531 ASCONF [ADD-IP, Int-VTag=1234, Rem-VTag = 5678] 1532 192.0.2.129:1 -------------------> 203.0.113.129:2 1533 Rem-VTag = 5678 1535 ASCONF ACK 1536 192.0.2.129:1 <------------------- 203.0.113.129:2 1537 Int-VTag = 1234 1539 ASCONF ACK 1540 10.1.0.1:1 <----- 203.0.113.129:2 1541 Int-VTag = 1234 1543 8.4. NAT Function Loses Its State 1545 Association is already established between Host A and Host B, when 1546 the NAT function loses its state and obtains a new external address. 1547 Host A sends a DATA chunk to Host B. 1549 /--\/--\ 1550 +--------+ +-----+ / \ +--------+ 1551 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1552 +--------+ +-----+ \ / +--------+ 1553 \--/\--/ 1555 +---------+--------+----------+--------+-----------+ 1556 NAT | Int | Int | Rem | Rem | Int | 1557 | VTag | Port | VTag | Port | Addr | 1558 +---------+--------+----------+--------+-----------+ 1560 DATA 1561 10.0.0.1:1 ----------> 203.0.113.1:2 1562 Rem-VTag = 5678 1564 The NAT function cannot find an entry in the NAT binding table for 1565 the association. It sends a packet containing an ERROR chunk with 1566 the M bit set and the cause "NAT state missing". 1568 /--\/--\ 1569 +--------+ +-----+ / \ +--------+ 1570 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1571 +--------+ +-----+ \ / +--------+ 1572 \--/\--/ 1574 ERROR [M bit, NAT state missing] 1575 10.0.0.1:1 <---------- 203.0.113.1:2 1576 Rem-VTag = 5678 1578 On reception of the packet containing the ERROR chunk, Host A sends a 1579 packet containing an ASCONF chunk indicating that the former 1580 information has to be deleted and the source address of the actual 1581 packet added. 1583 /--\/--\ 1584 +--------+ +-----+ / \ +--------+ 1585 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1586 +--------+ +-----+ \ / +--------+ 1587 \--/\--/ 1589 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1590 10.0.0.1:1 ----------> 203.0.113.129:2 1591 Rem-VTag = 5678 1593 +---------+--------+----------+--------+-----------+ 1594 NAT | Int | Int | Rem | Rem | Int | 1595 | VTag | Port | VTag | Port | Addr | 1596 +---------+--------+----------+--------+-----------+ 1597 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1598 +---------+--------+----------+--------+-----------+ 1600 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1601 192.0.2.2:1 -----------------> 203.0.113.129:2 1602 Rem-VTag = 5678 1604 Host B adds the new source address to this association and deletes 1605 all other addresses from this association. 1607 /--\/--\ 1608 +--------+ +-----+ / \ +--------+ 1609 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1610 +--------+ +-----+ \ / +--------+ 1611 \--/\--/ 1613 ASCONF ACK 1614 192.0.2.2:1 <----------------- 203.0.113.129:2 1615 Int-VTag = 1234 1617 ASCONF ACK 1618 10.1.0.1:1 <---------- 203.0.113.129:2 1619 Int-VTag = 1234 1621 DATA 1622 10.0.0.1:1 ----------> 203.0.113.1:2 1623 Rem-VTag = 5678 1624 DATA 1625 192.0.2.2:1 -----------------> 203.0.113.129:2 1626 Rem-VTag = 5678 1628 8.5. Peer-to-Peer Communications 1630 If two hosts, each of them behind a NAT function, want to communicate 1631 with each other, they have to get knowledge of the peer's external 1632 address. This can be achieved with a so-called rendezvous server. 1633 Afterwards the destination addresses are external, and the 1634 association is set up with the help of the INIT collision. The NAT 1635 functions create their entries according to their internal peer's 1636 point of view. Therefore, NAT function A's Internal-VTag and 1637 Internal-Port are NAT function B's Remote-VTag and Remote-Port, 1638 respectively. The naming (internal/remote) of the verification tag 1639 in the packet flow is done from the sending host's point of view. 1641 Internal | External External | Internal 1642 | | 1643 | /--\/---\ | 1644 +--------+ +-------+ / \ +-------+ +--------+ 1645 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1646 +--------+ +-------+ \ / +-------+ +--------+ 1647 | \--/\---/ | 1649 NAT Binding Tables 1650 +---------+--------+----------+--------+-----------+ 1651 NAT A | Int | Int | Rem | Rem | Int | 1652 | VTag | Port | VTag | Port | Addr | 1653 +---------+--------+----------+--------+-----------+ 1655 +---------+--------+----------+--------+-----------+ 1656 NAT B | Int | Int | Rem | Rem | Int | 1657 | v-tag | port | v-tag | port | Addr | 1658 +---------+--------+----------+--------+-----------+ 1660 INIT[Initiate-Tag = 1234] 1661 10.0.0.1:1 --> 203.0.113.1:2 1662 Rem-VTag = 0 1664 NAT function A creates entry: 1666 +---------+--------+----------+--------+-----------+ 1667 NAT A | Int | Int | Rem | Rem | Int | 1668 | VTag | Port | VTag | Port | Addr | 1669 +---------+--------+----------+--------+-----------+ 1670 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1671 +---------+--------+----------+--------+-----------+ 1673 INIT[Initiate-Tag = 1234] 1674 192.0.2.1:1 ----------------> 203.0.113.1:2 1675 Rem-VTag = 0 1677 NAT function B processes the packet containing the INIT chunk, but 1678 cannot find an entry. The SCTP packet is silently discarded and 1679 leaves the NAT binding table of NAT function B unchanged. 1681 +---------+--------+----------+--------+-----------+ 1682 NAT B | Int | Int | Rem | Rem | Int | 1683 | VTag | Port | VTag | Port | Addr | 1684 +---------+--------+----------+--------+-----------+ 1686 Now Host B sends a packet containing an INIT chunk, which is 1687 processed by NAT function B. Its parameters are used to create an 1688 entry. 1690 Internal | External External | Internal 1691 | | 1692 | /--\/---\ | 1693 +--------+ +-------+ / \ +-------+ +--------+ 1694 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1695 +--------+ +-------+ \ / +-------+ +--------+ 1696 | \--/\---/ | 1698 INIT[Initiate-Tag = 5678] 1699 192.0.2.1:1 <-- 10.1.0.1:2 1700 Rem-VTag = 0 1702 +---------+--------+----------+--------+-----------+ 1703 NAT B | Int | Int | Rem | Rem | Int | 1704 | VTag | Port | VTag | Port | Addr | 1705 +---------+--------+----------+--------+-----------+ 1706 | 5678 | 2 | 0 | 1 | 10.1.0.1 | 1707 +---------+--------+----------+--------+-----------+ 1709 INIT[Initiate-Tag = 5678] 1710 192.0.2.1:1 <--------------- 203.0.113.1:2 1711 Rem-VTag = 0 1713 NAT function A processes the packet containing the INIT chunk. As 1714 the outgoing packet containing an INIT chunk of Host A has already 1715 created an entry, the entry is found and updated: 1717 Internal | External External | Internal 1718 | | 1719 | /--\/---\ | 1720 +--------+ +-------+ / \ +-------+ +--------+ 1721 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1722 +--------+ +-------+ \ / +-------+ +--------+ 1723 | \--/\---/ | 1725 VTag != Int-VTag, but Rem-VTag == 0, find entry. 1726 +---------+--------+----------+--------+-----------+ 1727 NAT A | Int | Int | Rem | Rem | Int | 1728 | VTag | Port | VTag | Port | Addr | 1729 +---------+--------+----------+--------+-----------+ 1730 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1731 +---------+--------+----------+--------+-----------+ 1733 INIT[Initiate-tag = 5678] 1734 10.0.0.1:1 <-- 203.0.113.1:2 1735 Rem-VTag = 0 1737 Host A sends a packet containing an INIT ACK chunk, which can pass 1738 through NAT function B: 1740 Internal | External External | Internal 1741 | | 1742 | /--\/---\ | 1743 +--------+ +-------+ / \ +-------+ +--------+ 1744 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1745 +--------+ +-------+ \ / +-------+ +--------+ 1746 | \--/\---/ | 1748 INIT ACK[Initiate-Tag = 1234] 1749 10.0.0.1:1 --> 203.0.113.1:2 1750 Rem-VTag = 5678 1752 INIT ACK[Initiate-Tag = 1234] 1753 192.0.2.1:1 ----------------> 203.0.113.1:2 1754 Rem-VTag = 5678 1756 NAT function B updates entry: 1758 +---------+--------+----------+--------+-----------+ 1759 NAT B | Int | Int | Rem | Rem | Int | 1760 | VTag | Port | VTag | Port | Addr | 1761 +---------+--------+----------+--------+-----------+ 1762 | 5678 | 2 | 1234 | 1 | 10.1.0.1 | 1763 +---------+--------+----------+--------+-----------+ 1765 INIT ACK[Initiate-Tag = 1234] 1766 192.0.2.1:1 --> 10.1.0.1:2 1767 Rem-VTag = 5678 1769 The lookup for COOKIE ECHO and COOKIE ACK is successful. 1771 Internal | External External | Internal 1772 | | 1773 | /--\/---\ | 1774 +--------+ +-------+ / \ +-------+ +--------+ 1775 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1776 +--------+ +-------+ \ / +-------+ +--------+ 1777 | \--/\---/ | 1779 COOKIE ECHO 1780 192.0.2.1:1 <-- 10.1.0.1:2 1781 Rem-VTag = 1234 1783 COOKIE ECHO 1784 192.0.2.1:1 <------------- 203.0.113.1:2 1785 Rem-VTag = 1234 1787 COOKIE ECHO 1788 10.0.0.1:1 <-- 203.0.113.1:2 1789 Rem-VTag = 1234 1791 COOKIE ACK 1792 10.0.0.1:1 --> 203.0.113.1:2 1793 Rem-VTag = 5678 1795 COOKIE ACK 1796 192.0.2.1:1 ----------------> 203.0.113.1:2 1797 Rem-VTag = 5678 1799 COOKIE ACK 1800 192.0.2.1:1 --> 10.1.0.1:2 1801 Rem-VTag = 5678 1803 9. Socket API Considerations 1805 This section describes how the socket API defined in [RFC6458] is 1806 extended to provide a way for the application to control NAT 1807 friendliness. 1809 Please note that this section is informational only. 1811 A socket API implementation based on [RFC6458] is extended by 1812 supporting one new read/write socket option. 1814 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 1816 This socket option uses the option_level IPPROTO_SCTP and the 1817 option_name SCTP_NAT_FRIENDLY. It can be used to enable/disable the 1818 NAT friendliness for future associations and retrieve the value for 1819 future and specific ones. 1821 struct sctp_assoc_value { 1822 sctp_assoc_t assoc_id; 1823 uint32_t assoc_value; 1824 }; 1826 assoc_id 1827 This parameter is ignored for one-to-one style sockets. For one- 1828 to-many style sockets the application can fill in an association 1829 identifier or SCTP_FUTURE_ASSOC for this query. It is an error to 1830 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 1832 assoc_value 1833 A non-zero value indicates a NAT-friendly mode. 1835 10. IANA Considerations 1837 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1838 you assign this document.] 1840 [NOTE to RFC-Editor: The requested values for the chunk type and the 1841 chunk parameter types are tentative and to be confirmed by IANA.] 1843 This document (RFCXXXX) is the reference for all registrations 1844 described in this section. The requested changes are described 1845 below. 1847 10.1. New Chunk Flags for Two Existing Chunk Types 1849 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1850 for the ERROR chunk. The requested value for the T bit is 0x01 and 1851 for the M bit is 0x02. 1853 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1855 ERROR Chunk Flags 1856 +==================+=================+===========+ 1857 | Chunk Flag Value | Chunk Flag Name | Reference | 1858 +==================+=================+===========+ 1859 | 0x01 | T bit | [RFCXXXX] | 1860 +------------------+-----------------+-----------+ 1861 | 0x02 | M bit | [RFCXXXX] | 1862 +------------------+-----------------+-----------+ 1863 | 0x04 | Unassigned | | 1864 +------------------+-----------------+-----------+ 1865 | 0x08 | Unassigned | | 1866 +------------------+-----------------+-----------+ 1867 | 0x10 | Unassigned | | 1868 +------------------+-----------------+-----------+ 1869 | 0x20 | Unassigned | | 1870 +------------------+-----------------+-----------+ 1871 | 0x40 | Unassigned | | 1872 +------------------+-----------------+-----------+ 1873 | 0x80 | Unassigned | | 1874 +------------------+-----------------+-----------+ 1876 Table 2 1878 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1879 the ABORT chunk. The requested value of the M bit is 0x02. 1881 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1883 ABORT Chunk Flags 1884 +==================+=================+===========+ 1885 | Chunk Flag Value | Chunk Flag Name | Reference | 1886 +==================+=================+===========+ 1887 | 0x01 | T bit | [RFC4960] | 1888 +------------------+-----------------+-----------+ 1889 | 0x02 | M bit | [RFCXXXX] | 1890 +------------------+-----------------+-----------+ 1891 | 0x04 | Unassigned | | 1892 +------------------+-----------------+-----------+ 1893 | 0x08 | Unassigned | | 1894 +------------------+-----------------+-----------+ 1895 | 0x10 | Unassigned | | 1896 +------------------+-----------------+-----------+ 1897 | 0x20 | Unassigned | | 1898 +------------------+-----------------+-----------+ 1899 | 0x40 | Unassigned | | 1900 +------------------+-----------------+-----------+ 1901 | 0x80 | Unassigned | | 1902 +------------------+-----------------+-----------+ 1904 Table 3 1906 10.2. Three New Error Causes 1908 Three error causes have to be assigned by IANA. It is requested to 1909 use the values given below. 1911 This requires three additional lines in the "Error Cause Codes" 1912 registry for SCTP: 1914 Error Cause Codes 1916 +=======+================================+===========+ 1917 | Value | Cause Code | Reference | 1918 +=======+================================+===========+ 1919 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1920 +-------+--------------------------------+-----------+ 1921 | 177 | Missing State | [RFCXXXX] | 1922 +-------+--------------------------------+-----------+ 1923 | 178 | Port Number Collision | [RFCXXXX] | 1924 +-------+--------------------------------+-----------+ 1926 Table 4 1928 10.3. Two New Chunk Parameter Types 1930 Two chunk parameter types have to be assigned by IANA. IANA is 1931 requested to assign these values from the pool of parameters with the 1932 upper two bits set to '11' and to use the values given below. 1934 This requires two additional lines in the "Chunk Parameter Types" 1935 registry for SCTP: 1937 Chunk Parameter Types 1939 +==========+==========================+===========+ 1940 | ID Value | Chunk Parameter Type | Reference | 1941 +==========+==========================+===========+ 1942 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1943 +----------+--------------------------+-----------+ 1944 | 49160 | VTags (0xC008) | [RFCXXXX] | 1945 +----------+--------------------------+-----------+ 1947 Table 5 1949 10.4. One New URI 1951 An URI in the "ns" subregistry within the "IETF XML" registry has to 1952 be assigned by IANA ([RFC3688]): 1954 URI: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1955 Registrant Contact: The IESG. 1956 XML: N/A; the requested URI is an XML namespace. 1958 10.5. One New YANG Module 1960 An YANG module in the "YANG Module Names" subregistry within the 1961 "YANG Parameters" registry has to be assigned by IANA ([RFC6020]): 1963 Name: ietf-nat-sctp 1964 Namespace: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1965 Maintained by IANA: N 1966 Prefix: nat-sctp 1967 Reference: RFCXXXX 1969 11. Security Considerations 1971 State maintenance within a NAT function is always a subject of 1972 possible Denial Of Service attacks. This document recommends that at 1973 a minimum a NAT function runs a timer on any SCTP state so that old 1974 association state can be cleaned up. 1976 Generic issues related to address sharing are discussed in [RFC6269] 1977 and apply to SCTP as well. 1979 For SCTP endpoints not disabling the restart procedure, this document 1980 does not add any additional security considerations to the ones given 1981 in [RFC4960], [RFC4895], and [RFC5061]. 1983 SCTP endpoints disabling the restart procedure, need to monitor the 1984 status of all associations to mitigate resource exhaustion attacks by 1985 establishing a lot of associations sharing the same IP addresses and 1986 port numbers. 1988 In any case, SCTP is protected by the verification tags and the usage 1989 of [RFC4895] against off-path attackers. 1991 For IP-level fragmentation and reassembly related issues see 1992 [RFC4963]. 1994 The YANG module specified in this document defines a schema for data 1995 that is designed to be accessed via network management protocols such 1996 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1997 is the secure transport layer, and the mandatory-to-implement secure 1998 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1999 is HTTPS, and the mandatory-to-implement secure transport is TLS 2000 [RFC8446]. 2002 The Network Configuration Access Control Model (NACM) [RFC8341] 2003 provides the means to restrict access for particular NETCONF or 2004 RESTCONF users to a preconfigured subset of all available NETCONF or 2005 RESTCONF protocol operations and content. 2007 All data nodes defined in the YANG module that can be created, 2008 modified, and deleted (i.e., config true, which is the default) are 2009 considered sensitive. Write operations (e.g., edit-config) applied 2010 to these data nodes without proper protection can negatively affect 2011 network operations. An attacker who is able to access the SCTP NAT 2012 function can undertake various attacks, such as: 2014 * Setting a low timeout for SCTP mapping entries to cause failures 2015 to deliver incoming SCTP packets. 2017 * Instantiating mapping entries to cause NAT collision. 2019 12. Normative References 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2022 Requirement Levels", BCP 14, RFC 2119, 2023 DOI 10.17487/RFC2119, March 1997, 2024 . 2026 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2027 DOI 10.17487/RFC3688, January 2004, 2028 . 2030 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 2031 "Authenticated Chunks for the Stream Control Transmission 2032 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2033 2007, . 2035 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2036 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2037 . 2039 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2040 Kozuka, "Stream Control Transmission Protocol (SCTP) 2041 Dynamic Address Reconfiguration", RFC 5061, 2042 DOI 10.17487/RFC5061, September 2007, 2043 . 2045 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2046 the Network Configuration Protocol (NETCONF)", RFC 6020, 2047 DOI 10.17487/RFC6020, October 2010, 2048 . 2050 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 2051 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 2052 DOI 10.17487/RFC6096, January 2011, 2053 . 2055 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2056 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2057 May 2017, . 2059 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 2060 Vinapamula, S., and Q. Wu, "A YANG Module for Network 2061 Address Translation (NAT) and Network Prefix Translation 2062 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 2063 . 2065 13. Informative References 2067 [DOI_10.1145_1496091.1496095] 2068 Hayes, D., But, J., and G. Armitage, "Issues with network 2069 address translation for SCTP", ACM SIGCOMM Computer 2070 Communication Review Vol. 39, pp. 23-33, 2071 DOI 10.1145/1496091.1496095, December 2008, 2072 . 2074 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2075 RFC 793, DOI 10.17487/RFC0793, September 1981, 2076 . 2078 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2079 Address Translator (Traditional NAT)", RFC 3022, 2080 DOI 10.17487/RFC3022, January 2001, 2081 . 2083 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 2084 Translation (NAT) Behavioral Requirements for Unicast 2085 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2086 2007, . 2088 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2089 Errors at High Data Rates", RFC 4963, 2090 DOI 10.17487/RFC4963, July 2007, 2091 . 2093 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 2094 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 2095 RFC 5382, DOI 10.17487/RFC5382, October 2008, 2096 . 2098 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 2099 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 2100 DOI 10.17487/RFC5508, April 2009, 2101 . 2103 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2104 Protocol Port Randomization", BCP 156, RFC 6056, 2105 DOI 10.17487/RFC6056, January 2011, 2106 . 2108 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2109 NAT64: Network Address and Protocol Translation from IPv6 2110 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2111 April 2011, . 2113 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2114 and A. Bierman, Ed., "Network Configuration Protocol 2115 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2116 . 2118 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2119 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2120 . 2122 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2123 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2124 DOI 10.17487/RFC6269, June 2011, 2125 . 2127 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2128 Stack Lite Broadband Deployments Following IPv4 2129 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2130 . 2132 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2133 Yasevich, "Sockets API Extensions for the Stream Control 2134 Transmission Protocol (SCTP)", RFC 6458, 2135 DOI 10.17487/RFC6458, December 2011, 2136 . 2138 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 2139 "Special-Purpose IP Address Registries", BCP 153, 2140 RFC 6890, DOI 10.17487/RFC6890, April 2013, 2141 . 2143 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2144 Control Transmission Protocol (SCTP) Packets for End-Host 2145 to End-Host Communication", RFC 6951, 2146 DOI 10.17487/RFC6951, May 2013, 2147 . 2149 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2150 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2151 . 2153 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 2154 S., and K. Naito, "Updates to Network Address Translation 2155 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 2156 DOI 10.17487/RFC7857, April 2016, 2157 . 2159 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2160 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2161 . 2163 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2164 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2165 . 2167 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2168 Access Control Model", STD 91, RFC 8341, 2169 DOI 10.17487/RFC8341, March 2018, 2170 . 2172 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2173 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2174 . 2176 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 2177 and F. Gont, "IP Fragmentation Considered Fragile", 2178 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 2179 . 2181 Acknowledgments 2183 The authors wish to thank Mohamed Boucadair, Gorry Fairhurst, Bryan 2184 Ford, David Hayes, Alfred Hines, Karen E. E. Nielsen, Henning Peters, 2185 Maksim Proshin, Timo Völker, Dan Wing, and Qiaobing Xie for their 2186 invaluable comments. 2188 In addition, the authors wish to thank David Hayes, Jason But, and 2189 Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for 2190 their suggestions. 2192 The authors also wish to thank Mohamed Boucadair for contributing the 2193 text related to the YANG module. 2195 Authors' Addresses 2197 Randall R. Stewart 2198 Netflix, Inc. 2199 Chapin, SC 29036 2200 United States of America 2202 Email: randall@lakerest.net 2203 Michael Tüxen 2204 Münster University of Applied Sciences 2205 Stegerwaldstrasse 39 2206 48565 Steinfurt 2207 Germany 2209 Email: tuexen@fh-muenster.de 2211 Irene Rüngeler 2212 Münster University of Applied Sciences 2213 Stegerwaldstrasse 39 2214 48565 Steinfurt 2215 Germany 2217 Email: i.ruengeler@fh-muenster.de