idnits 2.17.1 draft-porfiri-tsvwg-sctp-natsupp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 April 2022) is 722 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 536, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1288, 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 (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Porfiri 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track 29 April 2022 5 Expires: 31 October 2022 7 Stream Control Transmission Protocol (SCTP) Network Address Translation 8 Support 9 draft-porfiri-tsvwg-sctp-natsupp-03 11 Abstract 13 The Stream Control Transmission Protocol (SCTP) provides a reliable 14 communications channel between two end-hosts in many ways similar to 15 the Transmission Control Protocol (TCP). With the widespread 16 deployment of Network Address Translators (NAT), specialized code has 17 been added to NAT functions for TCP that allows multiple hosts to 18 reside behind a NAT function and yet share a single IPv4 address, 19 even when two hosts (behind a NAT function) choose the same port 20 numbers for their connection. This additional code is sometimes 21 classified as Network Address and Port Translation (NAPT). 23 This document describes the protocol extensions needed for the SCTP 24 endpoints and the mechanisms for NAT functions necessary to provide 25 similar features of NAPT in the single point and multipoint traversal 26 scenario. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 31 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Motivation and Overview . . . . . . . . . . . . . . . . . . . 6 65 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 66 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 6 67 4.1.2. Multipoint Traversal . . . . . . . . . . . . . . . . 8 68 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 9 69 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 9 70 4.4. Compatibility and increamental deployment . . . . . . . . 14 71 4.5. Differences with Current NAT Support Draft . . . . . . . 15 72 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 16 74 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 16 75 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 16 76 5.1.3. Extended INIT-ACK Chunk . . . . . . . . . . . . . . . 16 77 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 17 78 5.2.1. Port Number Collision Error Cause . . . . . . . . . . 17 79 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 18 80 5.3.1. Repetita Juvant Parameter . . . . . . . . . . . . . . 18 81 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 18 82 6.1. Association Setup Considerations for Endpoints . . . . . 19 83 6.2. Association Setup Considerations for NAT . . . . . . . . 19 84 6.3. Handling of Internal Port Number Collisions . . . . . . . 19 85 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20 86 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 87 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 88 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 21 89 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 90 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 22 91 6.6. Multipoint Traversal Considerations for Endpoints . . . . 22 92 6.6.1. NAT Function Considerations . . . . . . . . . . . . . 23 93 6.6.2. Endpoint Considerations . . . . . . . . . . . . . . . 23 94 6.7. Path Probing considerations . . . . . . . . . . . . . . . 24 95 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 24 96 7.1. Single Homed Association Setup . . . . . . . . . . . . . 25 97 7.2. Single Homed Association Setup with Collision . . . . . . 25 98 7.3. Multi Homed Association Setup . . . . . . . . . . . . . . 25 99 7.4. Multi Homed Association Setup . . . . . . . . . . . . . . 26 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 101 8.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 28 102 8.2. Four New Error Causes . . . . . . . . . . . . . . . . . . 29 103 8.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 30 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 105 10. Normative References . . . . . . . . . . . . . . . . . . . . 31 106 11. Informative References . . . . . . . . . . . . . . . . . . . 31 107 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 110 1. Introduction 112 Stream Control Transmission Protocol (SCTP) [RFC4960] provides a 113 reliable communications channel between two end-hosts in many ways 114 similar to TCP [RFC0793] . With the widespread deployment of Network 115 Address Translators (NAT), specialized code has been added to NAT 116 functions for TCP that allows multiple hosts to reside behind a NAT 117 function using private-use addresses (see [RFC6890] ) and yet share a 118 single IPv4 address, even when two hosts (behind a NAT function) 119 choose the same port numbers for their connection. This additional 120 code is sometimes classified as Network Address and Port Translation 121 (NAPT). Please note that this document focuses on the case where the 122 NAT function maps a single or multiple internal addresses to a single 123 external address and vice versa. 125 To date, specialized code for SCTP has not yet been added to most NAT 126 functions so that only a translation of IP addresses is supported. 127 The end result of this is that only one SCTP-capable host can 128 successfully operate behind such a NAT function and this host can 129 only be single-homed. The only alternative for supporting legacy NAT 130 functions is to use UDP encapsulation as specified in [RFC6951] . 132 The NAT function in the document refers to NAPT functions described 133 in Section 2.2 of [RFC3022] , NAT64 [RFC6146] , or DS-Lite AFTR 134 [RFC6333] . 136 This document specifies procedures allowing a NAT function to support 137 SCTP by providing similar features to those provided by a NAPT for 138 TCP (see [RFC5382] and [RFC7857] ), UDP (see [RFC4787] and [RFC7857] 139 ), and ICMP (see [RFC5508] and [RFC7857] ). This document also 140 specifies a set of data formats for SCTP packets and a set of SCTP 141 endpoint procedures to support NAT traversal. An SCTP implementation 142 supporting these procedures can assure that in both single-homed and 143 multi-homed cases a NAT function will maintain the appropriate state 144 without the NAT function needing to change port numbers. 146 It is possible and desirable to make these changes for a number of 147 reasons: 149 * It is desirable for SCTP internal end-hosts on multiple platforms 150 to be able to share a NAT function's external IP address in the 151 same way that a TCP session can use a NAT function. 153 * If a NAT function does not need to change any data within an SCTP 154 packet, it will reduce the processing burden of NAT'ing SCTP by 155 not needing to execute the CRC32c checksum used by SCTP. 157 * Not having to touch the IP payload makes the processing of ICMP 158 messages by NAT functions easier. 160 An SCTP-aware NAT function will need to follow these procedures for 161 generating appropriate SCTP packet formats, this is needed under 162 circumstances detailed in this document and only triggered by the 163 detection of an SCTP packet containing an INIT chunk. 165 When considering SCTP-aware NAT it is possible to have multiple 166 levels of support. At each level, the Internal Host, Remote Host, 167 and NAT function does or does not support the procedures described in 168 this document. 170 The reference configuration for NAT support is depicted in the 171 following figure: 173 Internal Network | External Network 174 | 175 Internal | External Remote 176 Address | Address /--\/--\ Address 177 +--------+ +-----+ / \ +--------+ 178 | Host A |=========| NAT |=======| Network |==========| Host B | 179 +--------+ +-----+ \ / +--------+ 180 Internal | \--/\--/ Remote 181 Internal Port | Port Remote 182 VTag | VTag 184 Figure 1: Basic Network Setup 186 In the above Figure 1 the NAT hides Host A whereas Host B is directly 187 connected to the public internet. Host A has a private IP address, 188 NAT and Host B have public IP addresses. 190 The following table illustrates the results of the various 191 combinations of support and if communications can occur between two 192 endpoints with reference to Figure 1, the NAT adaptation is the one 193 described in the current document. 195 +===============+==============+=============+===============+ 196 | Internal Host | NAT Function | Remote Host | Communication | 197 +===============+==============+=============+===============+ 198 | Support | Support | Support | Yes | 199 +---------------+--------------+-------------+---------------+ 200 | Support | Support | No Support | Yes | 201 +---------------+--------------+-------------+---------------+ 202 | Support | No Support | Support | None | 203 +---------------+--------------+-------------+---------------+ 204 | Support | No Support | No Support | None | 205 +---------------+--------------+-------------+---------------+ 206 | No Support | Support | Support | Limited | 207 +---------------+--------------+-------------+---------------+ 208 | No Support | Support | No Support | Limited | 209 +---------------+--------------+-------------+---------------+ 210 | No Support | No Support | Support | None | 211 +---------------+--------------+-------------+---------------+ 212 | No Support | No Support | No Support | None | 213 +---------------+--------------+-------------+---------------+ 215 Table 1: Communication possibilities 217 From the table it can be seen that no communication can occur when a 218 NAT function does not support SCTP-aware NAT. This assumes that the 219 NAT function does not handle SCTP packets at all and all SCTP packets 220 sent from behind a NAT function are discarded by the NAT function. 222 In some cases, where the NAT function supports SCTP-aware NAT but the 223 local host does not support the feature, communication can possibly 224 occur in a limited way. For example, only one host can have a 225 connection when a collision case occurs. 227 When a SCTP host is deployed behind a NAT and both support SCTP-aware 228 NAT, the communication will suceed independently from the remote 229 peer. 231 2. Conventions 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in BCP 236 14 [RFC2119] [RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 3. Terminology 241 This document uses the following terms, which are depicted in 242 Figure 1 . Familiarity with the terminology used in [RFC4960] and 243 [RFC5061] is assumed. 245 Internal-Address (Int-Addr) 246 An internal address that is known to the internal host. 248 Internal-Port (Int-Port) 249 The port number that is in use by the host holding the Internal- 250 Address. 252 Internal-VTag (Int-VTag) 253 The SCTP Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) 254 that the internal host has chosen for an association. The VTag is 255 a unique 32-bit tag that accompanies any incoming SCTP packet for 256 this association to the Internal-Address. 258 Remote-Address (Rem-Addr) 259 The address that an internal host is attempting to contact. 261 Remote-Port (Rem-Port) 262 The port number used by the host holding the Remote-Address. 264 Remote-VTag (Rem-VTag) 265 The Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) that 266 the host holding the Remote-Address has chosen for an association. 267 The VTag is a unique 32-bit tag that accompanies any outgoing SCTP 268 packet for this association to the Remote-Address. 270 External-Address (Ext-Addr) 271 An external address assigned to the NAT function, that it uses as 272 a source address when sending packets towards a Remote-Address. 274 4. Motivation and Overview 276 4.1. SCTP NAT Traversal Scenarios 278 This section defines the notion of single and multipoint NAT 279 traversal. 281 4.1.1. Single Point Traversal 283 In this case, all packets in the SCTP association go through a single 284 NAT function, as shown in Figure 2 . 286 Internal Network | External Network 287 | 288 | /--\/--\ 289 +--------+ +-----+ / \ +--------+ 290 | Host A |=========| NAT |========= | Network | ========| Host B | 291 +--------+ +-----+ \ / +--------+ 292 | \--/\--/ 293 | 295 Figure 2: Single NAT Function Scenario 297 A variation of this case is shown in Figure 3 , i.e., multiple NAT 298 functions in the forwarding path between two endpoints. 300 Internal | External : Internal | External 301 | : | 302 | : | /--\/--\ 303 +--------+ +-----+ : +-----+ / \ +--------+ 304 | Host A |==| NAT |=======:=======| NAT |==| Network |==| Host B | 305 +--------+ +-----+ : +-----+ \ / +--------+ 306 | : | \--/\--/ 307 | : | 309 Figure 3: Serial NAT Functions Scenario 311 Another case where the Endpoint is ditributed among SCTP Hosts is 312 shown in Figure 4 where multiple Hosts behave as Server and share the 313 same Internal Port. A Load Balancer node supports NAT when a new 314 Association request comes. The description of the Load Balancer 315 function and its interwork with NAT function is out of the scope of 316 this document. 318 Internal Network | External Network 319 | 320 | /--\/--\ 321 +--------+ +-----+ / \ +--------+ 322 | Host A |====+====| NAT |========= | Network | ========| Host B | 323 +--------+ | +-----+ \ / +--------+ 324 | | \ \--/\--/ 325 +--------+ | | \ 326 | Host B |====+ | \ 327 +--------+ | | \ 328 | | +----------+ 329 +--------+ | | | Load | 330 | Host C |====+ | | Balancer | 331 +--------+ | +----------+ 333 Figure 4: Distributed Endpoint Scenario 335 Although one of the main benefits of SCTP multi-homing is redundant 336 paths, in the single point traversal scenario the NAT function 337 represents a single point of failure in the path of the SCTP multi- 338 homed association. However, the rest of the path can still benefit 339 from path diversity provided by SCTP multi-homing. 341 The two SCTP endpoints in this case can be either single-homed or 342 multi-homed. However, the important thing is that the NAT function 343 in this case sees all the packets of the SCTP association. 345 4.1.2. Multipoint Traversal 347 This case involves multiple NAT functions and each NAT function only 348 sees some of the packets in the SCTP association. An example is 349 shown in Figure 5 . 351 Internal | External 352 +------+ /---\/---\ 353 /=======|NAT A |=========\ / \ 354 +--------+ / +------+ \/ \ +--------+ 355 | Host A |/ | | Network |===| Host B | 356 +--------+\ | /\ / +--------+ 357 \ +------+ / \ / 358 \=======|NAT B |========/ \---\/---/ 359 +------+ 360 | 362 Figure 5: Parallel NAT Functions Scenario 364 This case does not apply to a single-homed SCTP association (i.e., 365 both endpoints in the association use only one IP address). The 366 advantage here is that the existence of multiple NAT traversal points 367 can preserve the path diversity of a multi-homed association for the 368 entire path. This in turn can improve the robustness of the 369 communication. 371 4.2. Limitations of Classical NAPT for SCTP 373 Using classical NAPT possibly results in changing one of the SCTP 374 port numbers during the processing, which requires the recomputation 375 of the transport layer checksum by the NAPT function. Whereas for 376 UDP and TCP this can be done very efficiently, for SCTP the checksum 377 (CRC32c) over the entire packet needs to be recomputed (see 378 Appendix B of [RFC4960] for details of the CRC32c computation). This 379 would considerably add to the NAT computational burden, even though 380 hardware support can mitigate this in some implementations. 382 An SCTP endpoint can have multiple addresses but only has a single 383 port number to use. To make multipoint traversal work, all the NAT 384 functions involved need to recognize the packets they see as 385 belonging to the same SCTP association and perform port number 386 translation in a consistent way. One possible way of doing this is 387 to use a pre-defined table of port numbers and addresses configured 388 within each NAT function. Other mechanisms could make use of NAT to 389 NAT communication. Such mechanisms have not been deployed on a wide 390 scale base and thus are not a preferred solution. Therefore an SCTP 391 variant of NAT function has been developed and is described in draft- 392 ietf-tsvwg-natsupp-23 that is the version at the current time. This 393 document describes an alternative to that function exploiting most of 394 the same principles. Rather than being radically different, it can 395 be seen as a subset with some limitations but less complex and 396 requiring minor computational effort at the SCTP Endpoints and at the 397 NAT functions (see Section 4.3 ). 399 4.3. The SCTP-Specific Variant of NAT 401 In this section it is allowed that there are multiple SCTP capable 402 hosts behind a NAT function that share one External-Address. This 403 section focuses on the single point traversal scenario (see 404 Section 4.1.1 ) as well as on the multipoint trasversal NAT (see 405 Section 4.1.2 ). 407 The modification of outgoing SCTP packets sent from an internal host 408 is simple: the source address of the packets has to be replaced with 409 the External-Address. It might also be necessary to establish some 410 state in the NAT function to later handle incoming packets. 412 Typically, the NAT function has to maintain a NAT binding table of 413 Internal-Port, Remote-Port, Internal-Address, Remote-Address. An 414 entry in that NAT binding table is called a NAT-State control block. 415 The function Create() obtains the just mentioned parameters and 416 returns a NAT-State control block. Create() instantiates a 417 supervision timer on the NAT-State control block that has duration 418 greather than 2 * HB.interval and lower than 4 * HB.interval (see 419 section 15 of [RFC4960] ). A NAT function MAY allow creating NAT- 420 State control blocks via a management interface. 422 For SCTP packets coming from the external realm of the NAT function 423 the destination address of the packets has to be replaced with the 424 Internal-Address of the host to which the packet has to be delivered, 425 if a NAT state entry is found. The lookup of the Internal-Address is 426 based on the Remote-Address, Remote-Port and the Internal-Port. The 427 lookup function retarts the Nat-State control block supervision 428 timer. 430 The entries in the NAT binding table need to fulfill some uniqueness 431 conditions. There can not be more than one entry NAT binding table 432 with the same 4-tuple of Internal-Address, Remote-Address, Internal- 433 Port and Remote-Port. 435 NAT is able understanding that the SCTP packet transports an INIT 436 chunk because the SCTP common header will have VTAG=0 (see section 437 3.1 of [RFC4960] ) 439 The processing of outgoing SCTP packets containing an INIT chunk is 440 illustrated in the following figure. This scenario is valid for all 441 message flows in this section. 443 /--\/--\ 444 +--------+ +-----+ / \ +--------+ 445 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 446 +--------+ +-----+ \ / +--------+ 447 \--/\---/ 449 INIT[Initiate-Tag] 450 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 451 Rem-VTag=0 453 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 454 if lookup(Int-Addr, Int-Port, Rem-Port, Rem-Addr) == false 455 sendAbort(Rem-Addr, Rem-Port, Int-Addr, Int-Port, M-bit) 456 else 457 Returns(control block) 458 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 459 else 460 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 461 Returns(control block) 462 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 464 Translates To: 466 INIT[Initiate-Tag] 467 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 468 Rem-VTag=0 470 In the normal case a NAT binding table entry will be created. 472 However, it is possible that there is already a NAT binding table 473 entry with the same Remote-Address, Internal-Port and Remote-Port but 474 different Internal-Address. In this case the packet containing the 475 INIT chunk MUST be dropped by the NAT and a packet containing an 476 ABORT chunk SHOULD be sent to the SCTP host that originated the 477 packet with the M bit set and 'Port Number Collision' error cause 478 (see Section 5.1.1 for the format). The source address of the packet 479 containing the ABORT chunk MUST be the destination address of the 480 packet containing the INIT chunk. 482 In case that there's already a a NAT binding table entry with the 483 same Remote-Address, Internal-Port, Remote-Port and the same 484 Internal-Address, meaning that the INIT chunk is a new attempt for 485 the same Association, the NAT entry is reused. 487 The processing of outgoing SCTP packets containing chunks other than 488 INIT is described in the following figure. 490 /--\/--\ 491 +--------+ +-----+ / \ +--------+ 492 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 493 +--------+ +-----+ \ / +--------+ 494 \--/\---/ 496 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 497 Rem-VTag 499 if lookup(Int-Port, Rem-Port, Rem-Addr) == false 500 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 501 Returns(control block) 502 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 504 Translates To: 506 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 507 Rem-VTag 509 The processing of incoming SCTP packets containing an INIT chunk is 510 illustrated in the following figure. This scenario is valid for all 511 message flows in this section. 513 /--\/--\ 514 +--------+ +-----+ / \ +--------+ 515 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 516 +--------+ +-----+ \ / +--------+ 517 \--/\---/ 519 INIT [Initiate-Tag] 520 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 521 Int-VTag=0 523 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 524 Returns(control block) 525 forwardPkt(Rem-Addr, Rem-Port, Int-Addr, Int-Port) 526 else 527 if INIT contains RJ option 528 send INIT-ACK to the INIT source 529 else 530 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 531 Returns(control block) 532 forwardPkt(Rem-Addr, Rem-Port, Int-Addr, Int-Port) 534 Translates To: 536 INIT[Initiate-Tag] 537 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 538 Int-VTag=0 540 When INIT chunk contains the RJ option set, it's a duplicate of the 541 INIT used for establishing the association. In such case the reason 542 for RJ option is to be recognized by the NAT function that will reply 543 to the sender instead of the SCTP Host. This allows the SCTP 544 Endpoint to be distributed among hosts, and since the NAT function 545 cannot arbitraly choose among hosts, it takes the role of the unknown 546 host in answering to the INIT issuer so that it can proceed with the 547 ASCONF handshake and extend the association. The final step of 548 setting the path between the NAT function and the unknown host will 549 be completed by the host receiving ASCONF and sending an INIT with RJ 550 option towards the remote peer. 552 The processing of incoming SCTP packets containing chunk different 553 than INIT is illustrated in the following figure. The Lookup() 554 function has as input the Remote-Address, Remote-Port and the 555 Internal-Port. It returns the corresponding entry of the NAT binding 556 table. 558 /--\/--\ 559 +--------+ +-----+ / \ +--------+ 560 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 561 +--------+ +-----+ \ / +--------+ 562 \--/\---/ 564 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 565 Int-VTag 567 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 568 Returns(NAT-State control block containing Int-Addr) 569 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 571 Translates To: 573 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 574 Int-VTag 576 In the case where the Lookup function fails because it does not find 577 an entry, the SCTP packet is dropped. 579 4.4. Compatibility and increamental deployment 581 The current proposal for adding SCTP-capable NAT function is meant to 582 provide backwards compatibility in both involved functionality and 583 being compatible with legacy SCTP remote terminations that doesn't 584 implement it. 586 The compatibility at NAT tracking mechanism allows the NAT functionto 587 be able hiding also SCTP stack that doesn't implement the current 588 specfication, at the same time an SCTP stack implementing the current 589 specification canbe deployed in a NAT scenario where the NAT doesn't 590 implement it. In either cases the SCTP termination will be 591 accomplished with limitations as described earlier. 593 The compatibility at network level is proposed in a way that makes it 594 possible deploying a cluster of SCTP termination behind a NAT 595 function still with full compatibility towards legacy networking. As 596 an example, the scenario described in Figure 2 shows Host A being 597 hidden by NAT and Host B being directly connected to the internet. 599 In such case only Host A and NAT need to implement the current 600 specification whilst Host B can neglect it. The same applies to more 601 complex scenarios such as the ones shown in Figure 4 or in Figure 5. 603 4.5. Differences with Current NAT Support Draft 605 This section describes the differences with the existing draft-ietf- 606 tsvwg-natsupp. 608 From a functional perspective, the major difference between is in the 609 compatibility towards legacy SCTP hosts. The NAT-adaptation 610 specified in this document allows interoperability between SCTP hosts 611 even when the remote peer hasn't implemented it. Not even is 612 mandatory that all the NAT devices in the path do implement it as 613 long as they allow SCTP packets to pass through transparently. On 614 the existing draft-ietf-tsvwg-natsupp, the specification needs to be 615 implemented on all SCTP Hosts and all NAT devices in the network in 616 order to work. 618 The main technical difference is that the NAT function is simpler and 619 doesn't require explicit handling of NAT missing states. Actually in 620 this proposal NAT doesn't need to parse all the SCTP payloads. NAT 621 only parses INIT chunks, filtering of SCTP packets containing INIT 622 chunks is based on checking the SCTP Common Header and discriminate 623 the behavior based on Verification Tag = 0, that indicates the SCTP 624 packet contains an INIT chunk. The NAT supervises the association by 625 means of a timer, if no SCTP packets are seen within a certain time, 626 NAT assumes that the association is closed and will remove the 627 related NAT-entry. 629 The other difference is in the role of the SCTP User. In the current 630 proposal it's up to the SCTP User to change the originating Endpoint 631 (i.e. choose a different port number) if collision is detected. The 632 current proposal guarantees that at each node being in a path 633 belonging to an association, there will be only one 4-uple describing 634 that association, that means the NAT doesn't need to take care of 635 VTAG. 637 5. Data Formats 639 This section defines the formats used to support NAT traversal. 640 Section 5.1 and Section 5.2 describe chunks and error causes sent by 641 NAT functions and received by SCTP endpoints. Section 5.3 describes 642 parameters sent by SCTP endpoints and used by NAT functions and SCTP 643 endpoints. 645 5.1. Modified Chunks 647 This section presents existing chunks defined in [RFC4960] for which 648 additional flags are specified by this document. 650 5.1.1. Extended ABORT Chunk 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type = 6 | Reserved |M|T| Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 \ \ 658 / zero or more Error Causes / 659 \ \ 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 The ABORT chunk is extended to add the new 'M bit'. The M bit 663 indicates to the receiver of the ABORT chunk that the chunk was not 664 generated by the peer SCTP endpoint, but instead by a middle box 665 (e.g., NAT). 667 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 669 5.1.2. Extended ERROR Chunk 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Type = 9 | Reserved |M|T| Length | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 \ \ 677 / zero or more Error Causes / 678 \ \ 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 The ERROR chunk defined in [RFC4960] is extended to add the new 'M 682 bit'. The M bit indicates to the receiver of the ERROR chunk that 683 the chunk was not generated by the peer SCTP endpoint, but instead by 684 a middle box. 686 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 688 5.1.3. Extended INIT-ACK Chunk 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type = 2 | Reserved |M|T| Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 \ \ 695 / zero or more Error Causes / 696 \ \ 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 The INIT ACK chunk defined in [RFC4960] is extended to add the new 'M 700 bit'. The M bit indicates to the receiver of the INIT-ACK chunk that 701 the chunk was not generated by the peer SCTP endpoint, but instead by 702 a middle box. 704 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 706 5.2. New Error Causes 708 This section defines the new error causes added by this document. 710 5.2.1. Port Number Collision Error Cause 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Cause Code = 0x00B2 | Cause Length = Variable | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 \ Chunk / 718 / \ 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Cause Code: 2 bytes (unsigned integer) 722 This field holds the IANA defined cause code for the 'Port Number 723 Collision' Error Cause. IANA is requested to assign the value 724 0x00B2 for this cause code. 726 Cause Length: 2 bytes (unsigned integer) 727 This field holds the length in bytes of the error cause. The 728 value MUST be the length of the Cause-Specific Information plus 4. 730 Chunk: variable length 731 The Cause-Specific Information is filled with the chunk that 732 caused this error. This can be an INIT, INIT ACK, or ASCONF 733 chunk. Note that if the entire chunk will not fit in the ERROR 734 chunk or ABORT chunk being sent then the bytes that do not fit are 735 truncated. 737 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 738 IANA.] 740 5.3. New Parameters 742 This section defines new parameters and their valid appearance 743 defined by this document. 745 5.3.1. Repetita Juvant Parameter 747 Repetita Juvant is a latin phase standing for "repeating does good". 748 It's sually said as a jocular remark to defend the speaker's (or 749 writer's) choice to repeat some important piece of information to 750 ensure reception by the audience. 752 The RJ Parameter is used as Optional Parameter in the INIT chunk. 753 The RJ parameter is used to indicate that INIT chunk is the 754 repetition of an already sent one even if it comes from a different 755 source address. It's used from either peers before sending ASCONF in 756 order to setup the NATs in the path. 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type = 0xXXXX | Length = 8 | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 6. Procedures for SCTP Endpoints and NAT Functions 766 If an SCTP endpoint is behind an SCTP-aware NAT, a number of problems 767 can arise as it tries to communicate with its peers: 769 * IP addresses can not be included in the SCTP packet. This is 770 discussed in Section 6.1 . 772 * More than one host behind a NAT function could select the same 773 source port number when initiating an association with the same 774 peer server. This creates a situation where the NAT function will 775 not be able to forward the INIT chunk. This situation is 776 discussed in Section 6.3 . 778 * A restart of a NAT function during a conversation could cause a 779 loss of its state. This problem and its solution is discussed in 780 Section 6.4 . 782 * NAT functions need to deal with SCTP packets being fragmented at 783 the IP layer. This is discussed in Section 6.5 . 785 * An SCTP endpoint can be behind two NAT functions in parallel 786 providing redundancy. The method to set up this scenario is 787 discussed in Section 6.6 . 789 The mechanisms to solve these problems require additional chunks and 790 parameters, defined in this document, and modified handling 791 procedures from those specified in [RFC4960] as described below. 793 6.1. Association Setup Considerations for Endpoints 795 The association setup procedure defined in [RFC4960] allows multi- 796 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 797 IPv6 address parameters in the INIT and INIT ACK chunks. However, 798 this does not work when NAT functions are present. 800 Every association setup from a host behind a NAT function MUST NOT 801 use multiple internal addresses. The INIT chunk MUST NOT contain an 802 IPv4 Address parameter, IPv6 Address parameter, or Supported Address 803 Types parameter. The INIT ACK chunk MUST NOT contain any IPv4 804 Address parameter or IPv6 Address parameter using non-global 805 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 806 any Host Name parameters. 808 If the association is intended to be finally multi-homed, the 809 procedure in Section 6.6 MUST be used. 811 6.2. Association Setup Considerations for NAT 813 When Endpoint is Distributed, NAT needs the cooperation of a Load 814 Balancer function for handling incoming and outgoing Association 815 Requests. It's up to the Load Balancer internal design the strategy 816 for permitting a Distributed Endpoint to handle the traffic. 817 Functionally, it's important that Load Balancer provides NAT a way 818 for assigning Associations to multiple SCTP Hosts. 820 6.3. Handling of Internal Port Number Collisions 822 Consider the case where two hosts in the Internal-Address space want 823 to set up an SCTP association with the same service provided by some 824 remote host. This means that the Remote-Port is the same. If they 825 both choose the same Internal-Port the NAT function will experience 826 collision when receiving the INIT and trying to create an Entry in 827 the NAT Tables. In such case NAT will send an ABORT chunk with M-bit 828 set to the SCTP Client. Since it's up to the SCTP User Application 829 to choose the Internal Port, it may be that an Association chooses 830 the Internal Port from the ephemeral port range at random (see 831 [RFC6056] ), this would make the probability for Port Number 832 Collision low. 834 At the Association initialization, the Client will experience one out 835 of three alternative answers from the network: 837 * INIT-ACK from the peer, this means a viable path exists between 838 peers, all the involved NATs have NAT tables properly configured 839 and the Association can be established. 841 * ABORT with M-bit set from one of the NATs within the path, this 842 means that the Association cannot be established. The SCTP User 843 application SHOULD decide whether to retry with a different 844 Internal Port or to give up. The way SCTP and the SCTP User 845 interact in this case is implementation dependent. 847 * ABORT from the remote peer. 849 The way SCTP and SCTP User Application interact can be either: 851 * An application can request a specific local port number (in the 852 socket API, using bind() with a non-zero port number) and in case 853 of a local port number collision, the connection setup has to 854 fail. It is up to the application to close() the socket and 855 restart from the beginning. 857 * An application leaves the local port number selection up to the 858 SCTP stack (in the socket socket API by either calling bind() with 859 a zero port number or not calling bind() at all before calling 860 connect() or sendto()). However, once the port number is chosen, 861 it can not be changed. So in case of a local port number 862 collision, the association setup has to fail. It is up to the 863 application to close() the socket and restart from the beginning. 865 * An application leaves the local port number selection up to the 866 SCTP stack (in the socket socket API by either calling bind() with 867 a zero port number or not calling bind() at all before calling 868 connect() or sendto()). In addition, it indicates that the SCTP 869 can change the local port number over time (in the socket API this 870 would be calling an IPPROTO_SCTP level new socket option). In 871 this case, the SCTP stack can automatically retry a connection 872 setup in case of an local port number collision. 874 6.3.1. NAT Function Considerations 876 NAT function checks for collision only on packets containing INIT 877 chunk. If the NAT function detects a collision of internal port 878 numbers, it SHOULD send a packet containing an ABORT chunk with the M 879 bit set. The M bit is a new bit defined by this document to express 880 to SCTP that the source of this packet is a "middle" box, not the 881 peer SCTP endpoint (see Section 5.1.1 ). the source and destination 882 address and port numbers MUST be swapped. 884 The sender of the packet containing an ERROR or ABORT chunk MUST 885 include the error cause with cause code 'Port Number Collision' (see 886 Section 5.2.1 ). 888 If the INIT chunk contains the RJ option the NAT function MUST NOT 889 forward the INIT chunk to the SCTP Host but it MUST reply to the 890 remote peer with INIT-ACK chunk with the M bit set. The M bit is a 891 new bit defined by this document to express to SCTP that the source 892 of this packet is a "middle" box (see Section 5.1.3 ). The 893 information contained in INIT-ACK chunk SHOULD be copied from the 894 INIT chunk. The value for Initiate Tag and Initial TSN MAY be chosen 895 random. 897 6.3.2. Endpoint Considerations 899 The sender of the packet containing the INIT chunk upon reception of 900 a packet containing an ABORT chunk with M bit set and the appropriate 901 error cause code for colliding NAT binding table state is included, 902 SHOULD evaluate the reason for ABORT. If the reason is "Port Number 903 Collision" it SHOULD reinitiate the association setup procedure after 904 choosing a new Internal Port. 906 6.4. Handling of Missing State 908 6.4.1. NAT Function Considerations 910 When experiencing a restart, the NAT function will start handling 911 SCTP packets with time difference between the ones containing INIT 912 chunks and all the other ones. Handling of SCTP packets containing 913 INIT chunks will start at least 4 * HB.interval after handling other 914 SCTP packets (see section 15 of [RFC4960] ). This avoids race 915 condition between the recreation of existing Entries in the NAT 916 Table and the creation of new ones from new Association requests. 918 If the NAT function receives a packet not containing an INIT chunk 919 from the internal network for which the lookup procedure does not 920 find an entry in the NAT binding table, it must create an Entry for 921 that packet and forward it. If the NAT function receives a packet 922 not containing an INIT chunk from the external network for which the 923 lookup procedure does not find an entry in the NAT binding table, it 924 must silently drop it. 926 6.4.2. Endpoint Considerations 928 Upon restart of a NAT function, the endpoint will experience 929 connectivity interruption, depending on the Association state it will 930 keep on retrying sending SCTP packets containint DATA chunks or HB 931 chunks. Since the longest interval between SCTP packets is 932 HB.interval, it will be able restoring the connectivity at most 2 * 933 HB.interval after NAT function is back at work. 935 If the Endpoint is trying to establish an Association, it will 936 experience a longer connectivity unavalilability of more than 4 * 937 HB.interval as NAT needs to rebuild the NAT Table with the existing 938 Associations first. 940 6.5. Handling of Fragmented SCTP Packets by NAT Functions 942 SCTP minimizes the use of IP-level fragmentation. However, it can 943 happen that using IP-level fragmentation is needed to continue an 944 SCTP association. For example, if the path MTU is reduced and there 945 are still some DATA chunk in flight, which require packets larger 946 than the new path MTU. If IP-level fragmentation can not be used, 947 the SCTP association will be terminated in a non-graceful way. See 948 [RFC8900] for more information about IP fragmentation. 950 Therefore, a NAT function MUST be able to handle IP-level fragmented 951 SCTP packets. The fragments MAY arrive in any order. 953 When an SCTP packet can not be forwarded by the NAT function due to 954 MTU issues and the IP header forbids fragmentation, the NAT MUST send 955 back a "Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message 956 to the internal host. This allows for a faster recovery from this 957 packet drop. 959 6.6. Multipoint Traversal Considerations for Endpoints 961 If a multi-homed SCTP endpoint behind a NAT function connects to a 962 peer, it MUST first set up the association single-homed with only one 963 destination address causing the first NAT function to populate its 964 state. 966 Once an Association has been created, it's possible to add further 967 external IP addresses for the peer to use, but before adding each IP 968 address it must be created the needed set of Entries in all NAT 969 functions towards all the peer's IP addresses. An INIT chunk 970 containing a RJ option (see Section 5.3.1 ) SHOULD be sent towards 971 all peers IP addresses using a path selector that is expected to 972 result in another external addres than association creation. The 973 reason why an INIT chunk with RJ option set is to be used is for 974 permitting the remote to be able discriminating between a request for 975 a new Association in case of Distributed Endpoint. The result from 976 that INIT is according to the given rules for Association setup (see 977 Section 6.1 ) and can cause collision. The reception of INIT ACK 978 confirms that the path from the new IP address and the remote one is 979 available and that all the NATs involved are properly configured. In 980 case INIT ACK has M-bit set, the remote Endpoint is distributed. 982 After succefull confirmation, the Endpoint SHOULD add each IP address 983 using packets containing ASCONF chunks sent via their respective NAT 984 functions. The address used in the Add IP address parameter is the 985 wildcard address (0.0.0.0 or ::0) and the address parameter in the 986 ASCONF chunk SHOULD also contain the VTags parameter. 988 When an Endpoint gets a new Remote IP Address added to an 989 Association, it SHOULD send INIT chunks with RJ option towards from 990 all its own IP Addresses towards that address in order to properly 991 set all the NATs in the path. 993 6.6.1. NAT Function Considerations 995 NAT function differentiates the behavior towards INIT chunk depending 996 on the RJ option. If the RJ option exists and the packet contains an 997 incoming INIT chunk, the NAT function SHOULD NOT forward the INIT 998 chunk towards the SCTP Host, it shall reply instead with an INIT ACK 999 chunk with the M-bit set. Section 5.1.3 ). NAT function SHOULD 1000 create INIT ACK data by using the parameters from the received INIT 1001 chunk. 1003 6.6.2. Endpoint Considerations 1005 When the Endpoint receives an INIT chunk with RJ option set, it will 1006 ignore the RJ option and handle INIT as in the legacy case. 1008 The Endpoint originating INIT chunk with RJ option set can receive 1009 different answers: 1011 * When receiving INIT ACK, it will assume the NATs on the path are 1012 properly set and the Endpoint can continue with the ASCONF 1013 procedure. 1015 * When receiving as ABORT with M-bit set, it shall assume that a 1016 path is not possible to be established. The Endpoint SHOULD retry 1017 after a time greather than 4 * HB.interval. 1019 * When receiving an ABORT without M-bit set, it shall assume that 1020 some temporary NAT configuration has led the INIT towards the 1021 wrong SCTP Host. The Endpoint SHOULD retry after a time greather 1022 than 4 * HB.interval. 1024 6.7. Path Probing considerations 1026 The SCTP protocol relies on continous path probing by means of data 1027 sending or using the Heartbeat mechanism as specified in section 5.4 1028 of [RFC4960] The adoption of the NAT mechanisms as described in this 1029 document introduces a criticality in the Path Probing mechanism of 1030 SCTP. 1032 The problem happens when, due to network problem, one or more 1033 secondary paths belonging to an Association will experience timeout 1034 in Path probing so than in some of the NAT functions used in the path 1035 there's no SCTP traffic for the given Association, causing the NAT 1036 entry to be canceled because of supervision timeout. 1038 It is recommended that before sending HEARTBEAT to an UNCONFIRMED 1039 address, an INIT chunk with RJ paramter set is sent so that NAT 1040 functions in the path can setup entries in the NAT tables properly. 1042 7. Examples of Operation 1044 This section describes examples of Association Establishements using 1045 the reference scenario depicted in Figure 6 . Hosts A1 and A2 1046 implement a distributed client towards the same remote Host. Hosts 1047 B1 and B2 implement a distributed Endpoint 'B' acting as Server. The 1048 Load Balancer functionality is not shown as it doesn't affect SCTP 1049 protocol. 1051 Internal | External | Internal 1052 +------+ +------+ 1053 +==|NAT A |==\ /--\/--\ /==|NAT C |==+ 1054 +--------+ | +------+ \ / \ / +------+ | +--------+ 1055 |Host A1 +---+ | \/ \/ | +-----|Host B1 | 1056 | +-+ | | | Network | | | +--+ | 1057 +--------+ | | | /\ /\ | | | +--------+ 1058 | | +------+ / \ / \ +------+ | | 1059 +====|NAT B |==/ \--\/--/ \==|NAT D |=====+ 1060 | | +------+ +------+ | | 1061 +--------+ | | | | | | +--------+ 1062 |Host A2 +-|-+ | | +--|--+Host B2 | 1063 | +-+ | | +--+ | 1064 +--------+ | | +--------+ 1066 Figure 6: Parallel NAT with distributed endpoints Scenario 1068 7.1. Single Homed Association Setup 1070 This section describes a successfull Association Establishment from 1071 A1 towards the distributed endpoint B. The sequence chart is shown 1072 in Figure 7 . 1074 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1075 | | | | | | | | 1076 +--------------}| INIT | | | | | 1077 | | +----------------------}| | | | 1078 | | | | +----------------------}| | 1079 | | | | | | | | 1080 | | | | |{----------------------+ | 1081 | | |{----------------------+ | | | 1082 |{--------------+ INIT ACK | | | | | 1083 | | | | | | | | 1085 Figure 7: Single Homed successfull Association Setup 1087 7.2. Single Homed Association Setup with Collision 1089 This section describes a successfull Association Establishment from 1090 A2 towards the distributed endpoint B. The collision happens at NAT 1091 A. The sequence chart is shown in Figure 8 . 1093 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1094 | | | | | | | | 1095 | +------}| INIT | | | | | 1096 | |{------+ ABORT | | | | | 1097 | | | | | | | | 1098 | +------}| INIT | | | | | 1099 | | +----------------------}| | | | 1100 | | | | +----------------------------}| 1101 | | | | | | | | 1102 | | | | |{----------------------------+ 1103 | | |{----------------------+ | | | 1104 | {-------+ INIT ACK | | | | | 1105 | | | | | | | | 1107 Figure 8: Single Homed successfull Association Setup after congestion 1109 7.3. Multi Homed Association Setup 1111 This section describes how the single homed established at 1112 Section 7.1 becomes multihomed. Note that the decision for what peer 1113 has to handle the INIT message requires support of Load Balancer. 1114 It's assumed that a Load Balancer exists and provides NAT with the 1115 right information. Success happens at all steps. Figure 9 . 1117 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1118 | | | | | | | | 1119 +--------------------------}| INIT RJ | | | | 1120 | | | +----------}| | | | 1121 | | | |{----------+ | | | 1122 |{--------------------------+ INIT ACK | | | | 1123 | | | | | | | | 1124 +--------------------------}| ASCONF | | | | 1125 | | | +----------}| | | | 1126 | | | | +----------------------}| | 1127 | | | | |{----------------------+ | 1128 | | | |{----------+ | | | 1129 |{--------------------------+ ASCONF ACK| | | | 1130 | | | | | | | | 1131 | | | | INIT RJ |{----------------------+ | 1132 | | | |{----------+ | | | 1133 | | | +----------}| | | | 1134 | | | | INIT ACK +----------------------}| | 1135 | | | | | | | | 1137 Figure 9: Multi Homed successfull Association Setup 1139 7.4. Multi Homed Association Setup 1141 This section describes how the multihome homed established at 1142 Section 7.3 becomes multihomed from the other peer. Success happens 1143 at all steps. Figure 10 . 1145 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1146 | | | | | | | | 1147 | | | | INIT RJ | |{----------+ | 1148 | | |{----------------------------------+ | | 1149 | | +----------------------------------}| | | 1150 | | | | INIT ACK | +----------}| | 1151 | | | | INIT RJ | |{----------+ | 1152 | | | |{----------------------+ | | 1153 | | | +----------------------}| | | 1154 | | | | INIT ACK | +----------}| | 1155 | | | | | | | | 1156 | | | | ASCONF | |{----------+ | 1157 | | |{----------------------------------+ | | 1158 |{--------------+ | | | | | 1159 +--------------}| | ASCONF ACK| | | | 1160 | | +----------------------------------}| | | 1161 | | | | | +----------}| | 1162 | | | | | | | | 1163 +--------------}| | INIT RJ | | | | 1164 | | +----------------------------------}| | | 1165 | | |{----------------------------------+ | | 1166 |{--------------+ | INIT ACK | | | | 1167 | | | | | | | | 1168 +--------------------------}| INIT RJ | | | | 1169 | | | +----------------------}| | | 1170 | | | |{----------------------+ | | 1171 |{--------------------------+ INIT ACK | | | | 1172 | | | | | | | | 1174 Figure 10: Multi Homed successfull Association Setup 1176 8. IANA Considerations 1178 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1179 you assign this document.] 1181 [NOTE to RFC-Editor: The requested values for the chunk type and the 1182 chunk parameter types are tentative and to be confirmed by IANA.] 1184 This document (RFCXXXX) is the reference for all registrations 1185 described in this section. The requested changes are described 1186 below. 1188 8.1. New Chunk Flags for Two Existing Chunk Types 1190 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1191 for the ERROR chunk. The requested value for the T bit is 0x01 and 1192 for the M bit is 0x02. 1194 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1196 ERROR Chunk Flags 1198 +==================+=================+===========+ 1199 | Chunk Flag Value | Chunk Flag Name | Reference | 1200 +==================+=================+===========+ 1201 | 0x01 | T bit | [RFCXXXX] | 1202 +------------------+-----------------+-----------+ 1203 | 0x02 | M bit | [RFCXXXX] | 1204 +------------------+-----------------+-----------+ 1205 | 0x04 | Unassigned | | 1206 +------------------+-----------------+-----------+ 1207 | 0x08 | Unassigned | | 1208 +------------------+-----------------+-----------+ 1209 | 0x10 | Unassigned | | 1210 +------------------+-----------------+-----------+ 1211 | 0x20 | Unassigned | | 1212 +------------------+-----------------+-----------+ 1213 | 0x40 | Unassigned | | 1214 +------------------+-----------------+-----------+ 1215 | 0x80 | Unassigned | | 1216 +------------------+-----------------+-----------+ 1218 Table 2 1220 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1221 the ABORT chunk. The requested value of the M bit is 0x02. 1223 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1225 ABORT Chunk Flags 1226 +==================+=================+===========+ 1227 | Chunk Flag Value | Chunk Flag Name | Reference | 1228 +==================+=================+===========+ 1229 | 0x01 | T bit | [RFC4960] | 1230 +------------------+-----------------+-----------+ 1231 | 0x02 | M bit | [RFCXXXX] | 1232 +------------------+-----------------+-----------+ 1233 | 0x04 | Unassigned | | 1234 +------------------+-----------------+-----------+ 1235 | 0x08 | Unassigned | | 1236 +------------------+-----------------+-----------+ 1237 | 0x10 | Unassigned | | 1238 +------------------+-----------------+-----------+ 1239 | 0x20 | Unassigned | | 1240 +------------------+-----------------+-----------+ 1241 | 0x40 | Unassigned | | 1242 +------------------+-----------------+-----------+ 1243 | 0x80 | Unassigned | | 1244 +------------------+-----------------+-----------+ 1246 Table 3 1248 8.2. Four New Error Causes 1250 Four error causes have to be assigned by IANA. It is requested to 1251 use the values given below. 1253 This requires Four additional lines in the "Error Cause Codes" 1254 registry for SCTP: 1256 Error Cause Codes 1258 +=======+================================+===========+ 1259 | Value | Cause Code | Reference | 1260 +=======+================================+===========+ 1261 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1262 +-------+--------------------------------+-----------+ 1263 | 177 | Missing State | [RFCXXXX] | 1264 +-------+--------------------------------+-----------+ 1265 | 178 | Port Number Collision | [RFCXXXX] | 1266 +-------+--------------------------------+-----------+ 1267 | 179 | VTag Not Found | [RFCXXXX] | 1268 +-------+--------------------------------+-----------+ 1270 Table 4 1272 8.3. Two New Chunk Parameter Types 1274 Two chunk parameter types have to be assigned by IANA. IANA is 1275 requested to assign these values from the pool of parameters with the 1276 upper two bits set to '11' and to use the values given below. 1278 This requires two additional lines in the "Chunk Parameter Types" 1279 registry for SCTP: 1281 Chunk Parameter Types 1283 +==========+==========================+===========+ 1284 | ID Value | Chunk Parameter Type | Reference | 1285 +==========+==========================+===========+ 1286 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1287 +----------+--------------------------+-----------+ 1288 | 49160 | VTags (0xC008) | [RFCXXXX] | 1289 +----------+--------------------------+-----------+ 1291 Table 5 1293 9. Security Considerations 1295 State maintenance within a NAT function is always a subject of 1296 possible Denial Of Service attacks. This document recommends that at 1297 a minimum a NAT function runs a timer on any SCTP state so that old 1298 association state can be cleaned up. 1300 Generic issues related to address sharing are discussed in [RFC6269] 1301 and apply to SCTP as well. 1303 For SCTP endpoints not disabling the restart procedure, this document 1304 does not add any additional security considerations to the ones given 1305 in [RFC4960] , [RFC4895] , and [RFC5061] . 1307 SCTP endpoints disabling the restart procedure, need to monitor the 1308 status of all associations to mitigate resource exhaustion attacks by 1309 establishing a lot of associations sharing the same IP addresses and 1310 port numbers. 1312 In any case, SCTP is protected by the verification tags and the usage 1313 of [RFC4895] against off-path attackers. 1315 For IP-level fragmentation and reassembly related issues see 1316 [RFC4963] . 1318 * Setting a low timeout for SCTP mapping entries to cause failures 1319 to deliver incoming SCTP packets. 1321 * Instantiating mapping entries to cause NAT collision. 1323 10. Normative References 1325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1326 Requirement Levels", BCP 14, RFC 2119, 1327 DOI 10.17487/RFC2119, March 1997, 1328 . 1330 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1331 "Authenticated Chunks for the Stream Control Transmission 1332 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1333 2007, . 1335 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1336 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1337 . 1339 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1340 Kozuka, "Stream Control Transmission Protocol (SCTP) 1341 Dynamic Address Reconfiguration", RFC 5061, 1342 DOI 10.17487/RFC5061, September 2007, 1343 . 1345 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 1346 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 1347 DOI 10.17487/RFC6096, January 2011, 1348 . 1350 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1351 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1352 May 2017, . 1354 11. Informative References 1356 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1357 RFC 793, DOI 10.17487/RFC0793, September 1981, 1358 . 1360 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1361 Address Translator (Traditional NAT)", RFC 3022, 1362 DOI 10.17487/RFC3022, January 2001, 1363 . 1365 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1366 Translation (NAT) Behavioral Requirements for Unicast 1367 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1368 2007, . 1370 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1371 Errors at High Data Rates", RFC 4963, 1372 DOI 10.17487/RFC4963, July 2007, 1373 . 1375 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1376 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1377 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1378 . 1380 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1381 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1382 DOI 10.17487/RFC5508, April 2009, 1383 . 1385 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1386 Protocol Port Randomization", BCP 156, RFC 6056, 1387 DOI 10.17487/RFC6056, January 2011, 1388 . 1390 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1391 NAT64: Network Address and Protocol Translation from IPv6 1392 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1393 April 2011, . 1395 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1396 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1397 DOI 10.17487/RFC6269, June 2011, 1398 . 1400 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1401 Stack Lite Broadband Deployments Following IPv4 1402 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1403 . 1405 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1406 "Special-Purpose IP Address Registries", BCP 153, 1407 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1408 . 1410 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1411 Control Transmission Protocol (SCTP) Packets for End-Host 1412 to End-Host Communication", RFC 6951, 1413 DOI 10.17487/RFC6951, May 2013, 1414 . 1416 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 1417 S., and K. Naito, "Updates to Network Address Translation 1418 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 1419 DOI 10.17487/RFC7857, April 2016, 1420 . 1422 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1423 and F. Gont, "IP Fragmentation Considered Fragile", 1424 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1425 . 1427 Acknowledgments 1429 The author wishes to thank Michael Tuxen , and Magnus Westerlund for 1430 their invaluable comments. 1432 In addition, the author wishes to thank Sriram Yagnaraman , for their 1433 suggestions. 1435 The author also wishes to thank the authors of draft-ietf-tsvwg- 1436 natsupp-22 which this document is based. 1438 Author's Address 1440 Claudio Porfiri 1441 Ericsson AB 1442 Torshamnsgatan 21 1443 16440 Stockholm 1444 Sweden 1445 Email: claudio.porfiri@ericsson.com