idnits 2.17.1 draft-porfiri-tsvwg-sctp-natsupp-01.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 (16 November 2021) is 892 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 510, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1209, 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 16 November 2021 5 Expires: 20 May 2022 7 Stream Control Transmission Protocol (SCTP) Network Address Translation 8 Support 9 draft-porfiri-tsvwg-sctp-natsupp-01 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 20 May 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 7 68 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8 69 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 9 70 4.4. Differences with Current NAT Support Draft . . . . . . . 13 71 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 14 73 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 14 74 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 14 75 5.1.3. Extended INIT-ACK Chunk . . . . . . . . . . . . . . . 15 76 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 15 77 5.2.1. Port Number Collision Error Cause . . . . . . . . . . 15 78 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 16 79 5.3.1. Repetita Juvant Parameter . . . . . . . . . . . . . . 16 80 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 16 81 6.1. Association Setup Considerations for Endpoints . . . . . 17 82 6.2. Association Setup Considerations for NAT . . . . . . . . 17 83 6.3. Handling of Internal Port Number Collisions . . . . . . . 18 84 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 19 85 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 19 86 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 19 87 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 20 88 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 89 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 20 90 6.6. Multipoint Traversal Considerations for Endpoints . . . . 21 91 6.6.1. NAT Function Considerations . . . . . . . . . . . . . 22 92 6.6.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 93 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 22 94 7.1. Single Homed Association Setup . . . . . . . . . . . . . 23 95 7.2. Single Homed Association Setup with Collision . . . . . . 23 96 7.3. Multi Homed Association Setup . . . . . . . . . . . . . . 24 97 7.4. Multi Homed Association Setup . . . . . . . . . . . . . . 25 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 100 8.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 26 101 8.2. Four New Error Causes . . . . . . . . . . . . . . . . . . 27 102 8.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 28 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 104 10. Normative References . . . . . . . . . . . . . . . . . . . . 29 105 11. Informative References . . . . . . . . . . . . . . . . . . . 29 106 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 109 1. Introduction 111 Stream Control Transmission Protocol (SCTP) [RFC4960] provides a 112 reliable communications channel between two end-hosts in many ways 113 similar to TCP [RFC0793] . With the widespread deployment of Network 114 Address Translators (NAT), specialized code has been added to NAT 115 functions for TCP that allows multiple hosts to reside behind a NAT 116 function using private-use addresses (see [RFC6890] ) and yet share a 117 single IPv4 address, even when two hosts (behind a NAT function) 118 choose the same port numbers for their connection. This additional 119 code is sometimes classified as Network Address and Port Translation 120 (NAPT). Please note that this document focuses on the case where the 121 NAT function maps a single or multiple internal addresses to a single 122 external address and vice versa. 124 To date, specialized code for SCTP has not yet been added to most NAT 125 functions so that only a translation of IP addresses is supported. 126 The end result of this is that only one SCTP-capable host can 127 successfully operate behind such a NAT function and this host can 128 only be single-homed. The only alternative for supporting legacy NAT 129 functions is to use UDP encapsulation as specified in [RFC6951] . 131 The NAT function in the document refers to NAPT functions described 132 in Section 2.2 of [RFC3022] , NAT64 [RFC6146] , or DS-Lite AFTR 133 [RFC6333] . 135 This document specifies procedures allowing a NAT function to support 136 SCTP by providing similar features to those provided by a NAPT for 137 TCP (see [RFC5382] and [RFC7857] ), UDP (see [RFC4787] and [RFC7857] 138 ), and ICMP (see [RFC5508] and [RFC7857] ). This document also 139 specifies a set of data formats for SCTP packets and a set of SCTP 140 endpoint procedures to support NAT traversal. An SCTP implementation 141 supporting these procedures can assure that in both single-homed and 142 multi-homed cases a NAT function will maintain the appropriate state 143 without the NAT function needing to change port numbers. 145 It is possible and desirable to make these changes for a number of 146 reasons: 148 * It is desirable for SCTP internal end-hosts on multiple platforms 149 to be able to share a NAT function's external IP address in the 150 same way that a TCP session can use a NAT function. 152 * If a NAT function does not need to change any data within an SCTP 153 packet, it will reduce the processing burden of NAT'ing SCTP by 154 not needing to execute the CRC32c checksum used by SCTP. 156 * Not having to touch the IP payload makes the processing of ICMP 157 messages by NAT functions easier. 159 An SCTP-aware NAT function will need to follow these procedures for 160 generating appropriate SCTP packet formats, this is needed under 161 circumstances detailed in this document and only triggered by the 162 detection of an SCTP packet containing an INIT chunk. 164 When considering SCTP-aware NAT it is possible to have multiple 165 levels of support. At each level, the Internal Host, Remote Host, 166 and NAT function does or does not support the procedures described in 167 this document. The following table illustrates the results of the 168 various combinations of support and if communications can occur 169 between two endpoints. 171 +===============+==============+=============+===============+ 172 | Internal Host | NAT Function | Remote Host | Communication | 173 +===============+==============+=============+===============+ 174 | Support | Support | Support | Yes | 175 +---------------+--------------+-------------+---------------+ 176 | Support | Support | No Support | Limited | 177 +---------------+--------------+-------------+---------------+ 178 | Support | No Support | Support | None | 179 +---------------+--------------+-------------+---------------+ 180 | Support | No Support | No Support | None | 181 +---------------+--------------+-------------+---------------+ 182 | No Support | Support | Support | Limited | 183 +---------------+--------------+-------------+---------------+ 184 | No Support | Support | No Support | Limited | 185 +---------------+--------------+-------------+---------------+ 186 | No Support | No Support | Support | None | 187 +---------------+--------------+-------------+---------------+ 188 | No Support | No Support | No Support | None | 189 +---------------+--------------+-------------+---------------+ 191 Table 1: Communication possibilities 193 From the table it can be seen that no communication can occur when a 194 NAT function does not support SCTP-aware NAT. This assumes that the 195 NAT function does not handle SCTP packets at all and all SCTP packets 196 sent from behind a NAT function are discarded by the NAT function. 197 In some cases, where the NAT function supports SCTP-aware NAT, but 198 one of the two hosts does not support the feature, communication can 199 possibly occur in a limited way. For example, only one host can have 200 a connection when a collision case occurs. 202 2. Conventions 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 3. Terminology 212 This document uses the following terms, which are depicted in 213 Figure 1 . Familiarity with the terminology used in [RFC4960] and 214 [RFC5061] is assumed. 216 Internal-Address (Int-Addr) 217 An internal address that is known to the internal host. 219 Internal-Port (Int-Port) 220 The port number that is in use by the host holding the Internal- 221 Address. 223 Internal-VTag (Int-VTag) 224 The SCTP Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) 225 that the internal host has chosen for an association. The VTag is 226 a unique 32-bit tag that accompanies any incoming SCTP packet for 227 this association to the Internal-Address. 229 Remote-Address (Rem-Addr) 230 The address that an internal host is attempting to contact. 232 Remote-Port (Rem-Port) 233 The port number used by the host holding the Remote-Address. 235 Remote-VTag (Rem-VTag) 236 The Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) that 237 the host holding the Remote-Address has chosen for an association. 238 The VTag is a unique 32-bit tag that accompanies any outgoing SCTP 239 packet for this association to the Remote-Address. 241 External-Address (Ext-Addr) 242 An external address assigned to the NAT function, that it uses as 243 a source address when sending packets towards a Remote-Address. 245 Internal Network | External Network 246 | 247 Internal | External Remote 248 Address | Address /--\/--\ Address 249 +--------+ +-----+ / \ +--------+ 250 | Host A |=========| NAT |=======| Network |==========| Host B | 251 +--------+ +-----+ \ / +--------+ 252 Internal | \--/\--/ Remote 253 Internal Port | Port Remote 254 VTag | VTag 256 Figure 1: Basic Network Setup 258 4. Motivation and Overview 260 4.1. SCTP NAT Traversal Scenarios 262 This section defines the notion of single and multipoint NAT 263 traversal. 265 4.1.1. Single Point Traversal 267 In this case, all packets in the SCTP association go through a single 268 NAT function, as shown in Figure 2 . 270 Internal Network | External Network 271 | 272 | /--\/--\ 273 +--------+ +-----+ / \ +--------+ 274 | Host A |=========| NAT |========= | Network | ========| Host B | 275 +--------+ +-----+ \ / +--------+ 276 | \--/\--/ 277 | 279 Figure 2: Single NAT Function Scenario 281 A variation of this case is shown in Figure 3 , i.e., multiple NAT 282 functions in the forwarding path between two endpoints. 284 Internal | External : Internal | External 285 | : | 286 | : | /--\/--\ 287 +--------+ +-----+ : +-----+ / \ +--------+ 288 | Host A |==| NAT |=======:=======| NAT |==| Network |==| Host B | 289 +--------+ +-----+ : +-----+ \ / +--------+ 290 | : | \--/\--/ 291 | : | 293 Figure 3: Serial NAT Functions Scenario 295 Another case where the Endpoint is ditributed among SCTP Hosts is 296 shown in Figure 4 where multiple Hosts behave as Server and share the 297 same Internal Port. A Load Balancer node supports NAT when a new 298 Association request comes. The description of the Load Balancer 299 function and its interwork with NAT function is out of the scope of 300 this document. 302 Internal Network | External Network 303 | 304 | /--\/--\ 305 +--------+ +-----+ / \ +--------+ 306 | Host A |====+====| NAT |========= | Network | ========| Host B | 307 +--------+ | +-----+ \ / +--------+ 308 | | \ \--/\--/ 309 +--------+ | | \ 310 | Host B |====+ | \ 311 +--------+ | | \ 312 | | +----------+ 313 +--------+ | | | Load | 314 | Host C |====+ | | Balancer | 315 +--------+ | +----------+ 317 Figure 4: Distributed Endpoint Scenario 319 Although one of the main benefits of SCTP multi-homing is redundant 320 paths, in the single point traversal scenario the NAT function 321 represents a single point of failure in the path of the SCTP multi- 322 homed association. However, the rest of the path can still benefit 323 from path diversity provided by SCTP multi-homing. 325 The two SCTP endpoints in this case can be either single-homed or 326 multi-homed. However, the important thing is that the NAT function 327 in this case sees all the packets of the SCTP association. 329 4.1.2. Multipoint Traversal 331 This case involves multiple NAT functions and each NAT function only 332 sees some of the packets in the SCTP association. An example is 333 shown in Figure 5 . 335 Internal | External 336 +------+ /---\/---\ 337 /=======|NAT A |=========\ / \ 338 +--------+ / +------+ \/ \ +--------+ 339 | Host A |/ | | Network |===| Host B | 340 +--------+\ | /\ / +--------+ 341 \ +------+ / \ / 342 \=======|NAT B |========/ \---\/---/ 343 +------+ 344 | 346 Figure 5: Parallel NAT Functions Scenario 348 This case does not apply to a single-homed SCTP association (i.e., 349 both endpoints in the association use only one IP address). The 350 advantage here is that the existence of multiple NAT traversal points 351 can preserve the path diversity of a multi-homed association for the 352 entire path. This in turn can improve the robustness of the 353 communication. 355 4.2. Limitations of Classical NAPT for SCTP 357 Using classical NAPT possibly results in changing one of the SCTP 358 port numbers during the processing, which requires the recomputation 359 of the transport layer checksum by the NAPT function. Whereas for 360 UDP and TCP this can be done very efficiently, for SCTP the checksum 361 (CRC32c) over the entire packet needs to be recomputed (see 362 Appendix B of [RFC4960] for details of the CRC32c computation). This 363 would considerably add to the NAT computational burden, even though 364 hardware support can mitigate this in some implementations. 366 An SCTP endpoint can have multiple addresses but only has a single 367 port number to use. To make multipoint traversal work, all the NAT 368 functions involved need to recognize the packets they see as 369 belonging to the same SCTP association and perform port number 370 translation in a consistent way. One possible way of doing this is 371 to use a pre-defined table of port numbers and addresses configured 372 within each NAT function. Other mechanisms could make use of NAT to 373 NAT communication. Such mechanisms have not been deployed on a wide 374 scale base and thus are not a preferred solution. Therefore an SCTP 375 variant of NAT function has been developed and is described in draft- 376 ietf-tsvwg-natsupp-23 that is the version at the current time. This 377 document describes an alternative to that function exploiting most of 378 the same principles. Rather than being radically different, it can 379 be seen as a subset with some limitations but less complex and 380 requiring minor computational effort at the SCTP Endpoints and at the 381 NAT functions (see Section 4.3 ). 383 4.3. The SCTP-Specific Variant of NAT 385 In this section it is allowed that there are multiple SCTP capable 386 hosts behind a NAT function that share one External-Address. This 387 section focuses on the single point traversal scenario (see 388 Section 4.1.1 ) as well as on the multipoint trasversal NAT (see 389 Section 4.1.2 ). 391 The modification of outgoing SCTP packets sent from an internal host 392 is simple: the source address of the packets has to be replaced with 393 the External-Address. It might also be necessary to establish some 394 state in the NAT function to later handle incoming packets. 396 Typically, the NAT function has to maintain a NAT binding table of 397 Internal-Port, Remote-Port, Internal-Address, Remote-Address. An 398 entry in that NAT binding table is called a NAT-State control block. 399 The function Create() obtains the just mentioned parameters and 400 returns a NAT-State control block. Create() instantiates a 401 supervision timer on the NAT-State control block that has duration 402 greather than 2 * HB.interval and lower than 4 * HB.interval (see 403 section 15 of [RFC4960] ). A NAT function MAY allow creating NAT- 404 State control blocks via a management interface. 406 For SCTP packets coming from the external realm of the NAT function 407 the destination address of the packets has to be replaced with the 408 Internal-Address of the host to which the packet has to be delivered, 409 if a NAT state entry is found. The lookup of the Internal-Address is 410 based on the Remote-Address, Remote-Port and the Internal-Port. The 411 lookup function retarts the Nat-State control block supervision 412 timer. 414 The entries in the NAT binding table need to fulfill some uniqueness 415 conditions. There can not be more than one entry NAT binding table 416 with the same 4-tuple of Internal-Address, Remote-Address, Internal- 417 Port and Remote-Port. 419 NAT is able understanding that the SCTP packet transports an INIT 420 chunk because the SCTP common header will have VTAG=0 (see section 421 3.1 of [RFC4960] ) 423 The processing of outgoing SCTP packets containing an INIT chunk is 424 illustrated in the following figure. This scenario is valid for all 425 message flows in this section. 427 /--\/--\ 428 +--------+ +-----+ / \ +--------+ 429 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 430 +--------+ +-----+ \ / +--------+ 431 \--/\---/ 433 INIT[Initiate-Tag] 434 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 435 Rem-VTag=0 437 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 438 sendAbort(Rem-Addr, Rem-Port, Int-Addr, Int-Port, M-bit) 439 else 440 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 441 Returns(control block) 442 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 444 Translates To: 446 INIT[Initiate-Tag] 447 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 448 Rem-VTag=0 450 In the normal case a NAT binding table entry will be created. 452 However, it is possible that there is already a NAT binding table 453 entry with the same Remote-Address, Internal-Port and Remote-Port but 454 different Internal-Address. In this case the packet containing the 455 INIT chunk MUST be dropped by the NAT and a packet containing an 456 ABORT chunk SHOULD be sent to the SCTP host that originated the 457 packet with the M bit set and 'Port Number Collision' error cause 458 (see Section 5.1.1 for the format). The source address of the packet 459 containing the ABORT chunk MUST be the destination address of the 460 packet containing the INIT chunk. 462 The processing of outgoing SCTP packets containing chunks other than 463 INIT is described in the following figure. 465 /--\/--\ 466 +--------+ +-----+ / \ +--------+ 467 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 468 +--------+ +-----+ \ / +--------+ 469 \--/\---/ 471 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 472 Rem-VTag 474 if lookup(Int-Port, Rem-Port, Rem-Addr) == false 475 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 476 Returns(control block) 477 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 479 Translates To: 481 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 482 Rem-VTag 484 The processing of incoming SCTP packets containing an INIT chunk is 485 illustrated in the following figure. This scenario is valid for all 486 message flows in this section. 488 /--\/--\ 489 +--------+ +-----+ / \ +--------+ 490 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 491 +--------+ +-----+ \ / +--------+ 492 \--/\---/ 494 INIT [Initiate-Tag] 495 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 496 Int-VTag=0 498 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 499 sendAbort(Ext-Addr, Int-Port, Rem-Addr, Rem-Port, M-bit) 500 else 501 if INIT contains RJ option 502 send INIT-ACK to the INIT source 503 else 504 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 505 Returns(control block) 506 forwardPkt(Rem-Addr, Rem-Port, Int-Addr, Int-Port) 508 Translates To: 510 INIT[Initiate-Tag] 511 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 512 Int-VTag=0 514 When INIT chunk contains the RJ option set, it's a duplicate of the 515 INIT used for establishing the association. In such case the reason 516 for RJ option is to be recognized by the NAT function that will reply 517 to the sender instead of the SCTP Host. This allows the SCTP 518 Endpoint to be distributed among hosts, and since the NAT function 519 cannot arbitraly choose among hosts, it takes the role of the unknown 520 host in answering to the INIT issuer so that it can proceed with the 521 ASCONF handshake and extend the association. The final step of 522 setting the path between the NAT function and the unknown host will 523 be completed by the host receiving ASCONF and sending an INIT with RJ 524 option towards the remote peer. 526 The processing of incoming SCTP packets containing chunk different 527 than INIT is illustrated in the following figure. The Lookup() 528 function has as input the Remote-Address, Remote-Port and the 529 Internal-Port. It returns the corresponding entry of the NAT binding 530 table. 532 /--\/--\ 533 +--------+ +-----+ / \ +--------+ 534 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 535 +--------+ +-----+ \ / +--------+ 536 \--/\---/ 538 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 539 Int-VTag 541 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 542 Returns(NAT-State control block containing Int-Addr) 543 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 545 Translates To: 547 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 548 Int-VTag 550 In the case where the Lookup function fails because it does not find 551 an entry, the SCTP packet is dropped. 553 4.4. Differences with Current NAT Support Draft 555 This section describes the differences with the existing draft-ietf- 556 tsvwg-natsupp. 558 The main difference is that the NAT function is simpler and doesn't 559 require explicit handling of NAT missing states. Actually in this 560 proposal NAT doesn't need to parse all the SCTP payloads. NAT only 561 parses INIT chunks, filtering of SCTP packets containing INIT chunks 562 is based on checking the SCTP Common Header and discriminate the 563 behavior based on Verification Tag = 0, that indicates the SCTP 564 packet contains an INIT chunk. The NAT supervises the association by 565 means of a timer, if no SCTP packets are seen within a certain time, 566 NAT assumes that the association is closed and will remove the 567 related NAT-entry. 569 The other difference is in the role of the SCTP User. In the current 570 proposal it's up to the SCTP User to change the originating Endpoint 571 (i.e. choose a different port number) if collision is detected. The 572 current proposal guarantees that at each node being in a path 573 belonging to an association, there will be only one 4-uple describing 574 that association, that means the NAT doesn't need to take care of 575 VTAG. 577 5. Data Formats 579 This section defines the formats used to support NAT traversal. 580 Section 5.1 and Section 5.2 describe chunks and error causes sent by 581 NAT functions and received by SCTP endpoints. Section 5.3 describes 582 parameters sent by SCTP endpoints and used by NAT functions and SCTP 583 endpoints. 585 5.1. Modified Chunks 587 This section presents existing chunks defined in [RFC4960] for which 588 additional flags are specified by this document. 590 5.1.1. Extended ABORT Chunk 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type = 6 | Reserved |M|T| Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 \ \ 598 / zero or more Error Causes / 599 \ \ 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 The ABORT chunk is extended to add the new 'M bit'. The M bit 603 indicates to the receiver of the ABORT chunk that the chunk was not 604 generated by the peer SCTP endpoint, but instead by a middle box 605 (e.g., NAT). 607 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 609 5.1.2. Extended ERROR Chunk 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Type = 9 | Reserved |M|T| Length | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 \ \ 617 / zero or more Error Causes / 618 \ \ 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 The ERROR chunk defined in [RFC4960] is extended to add the new 'M 622 bit'. The M bit indicates to the receiver of the ERROR chunk that 623 the chunk was not generated by the peer SCTP endpoint, but instead by 624 a middle box. 626 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 628 5.1.3. Extended INIT-ACK Chunk 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Type = 2 | Reserved |M|T| Length | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 \ \ 636 / zero or more Error Causes / 637 \ \ 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 The INIT ACK chunk defined in [RFC4960] is extended to add the new 'M 641 bit'. The M bit indicates to the receiver of the INIT-ACK chunk that 642 the chunk was not generated by the peer SCTP endpoint, but instead by 643 a middle box. 645 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 647 5.2. New Error Causes 649 This section defines the new error causes added by this document. 651 5.2.1. Port Number Collision Error Cause 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Cause Code = 0x00B2 | Cause Length = Variable | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 \ Chunk / 659 / \ 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Cause Code: 2 bytes (unsigned integer) 663 This field holds the IANA defined cause code for the 'Port Number 664 Collision' Error Cause. IANA is requested to assign the value 665 0x00B2 for this cause code. 667 Cause Length: 2 bytes (unsigned integer) 668 This field holds the length in bytes of the error cause. The 669 value MUST be the length of the Cause-Specific Information plus 4. 671 Chunk: variable length 672 The Cause-Specific Information is filled with the chunk that 673 caused this error. This can be an INIT, INIT ACK, or ASCONF 674 chunk. Note that if the entire chunk will not fit in the ERROR 675 chunk or ABORT chunk being sent then the bytes that do not fit are 676 truncated. 678 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 679 IANA.] 681 5.3. New Parameters 683 This section defines new parameters and their valid appearance 684 defined by this document. 686 5.3.1. Repetita Juvant Parameter 688 Repetita Juvant is a latin phase standing for "repeating does good". 689 It's sually said as a jocular remark to defend the speaker's (or 690 writer's) choice to repeat some important piece of information to 691 ensure reception by the audience. 693 The RJ Parameter is used as Optional Parameter in the INIT chunk. 694 The RJ parameter is used to indicate that INIT chunk is the 695 repetition of an already sent one even if it comes from a different 696 source address. It's used from either peers before sending ASCONF in 697 order to setup the NATs in the path. 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Type = 0xXXXX | Length = 8 | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 6. Procedures for SCTP Endpoints and NAT Functions 707 If an SCTP endpoint is behind an SCTP-aware NAT, a number of problems 708 can arise as it tries to communicate with its peers: 710 * IP addresses can not be included in the SCTP packet. This is 711 discussed in Section 6.1 . 713 * More than one host behind a NAT function could select the same 714 source port number when initiating an association with the same 715 peer server. This creates a situation where the NAT function will 716 not be able to forward the INIT chunk. This situation is 717 discussed in Section 6.3 . 719 * A restart of a NAT function during a conversation could cause a 720 loss of its state. This problem and its solution is discussed in 721 Section 6.4 . 723 * NAT functions need to deal with SCTP packets being fragmented at 724 the IP layer. This is discussed in Section 6.5 . 726 * An SCTP endpoint can be behind two NAT functions in parallel 727 providing redundancy. The method to set up this scenario is 728 discussed in Section 6.6 . 730 The mechanisms to solve these problems require additional chunks and 731 parameters, defined in this document, and modified handling 732 procedures from those specified in [RFC4960] as described below. 734 6.1. Association Setup Considerations for Endpoints 736 The association setup procedure defined in [RFC4960] allows multi- 737 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 738 IPv6 address parameters in the INIT and INIT ACK chunks. However, 739 this does not work when NAT functions are present. 741 Every association setup from a host behind a NAT function MUST NOT 742 use multiple internal addresses. The INIT chunk MUST NOT contain an 743 IPv4 Address parameter, IPv6 Address parameter, or Supported Address 744 Types parameter. The INIT ACK chunk MUST NOT contain any IPv4 745 Address parameter or IPv6 Address parameter using non-global 746 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 747 any Host Name parameters. 749 If the association is intended to be finally multi-homed, the 750 procedure in Section 6.6 MUST be used. 752 6.2. Association Setup Considerations for NAT 754 When Endpoint is Distributed, NAT needs the cooperation of a Load 755 Balancer function for handling incoming and outgoing Association 756 Requests. It's up to the Load Balancer internal design the strategy 757 for permitting a Distributed Endpoint to handle the traffic. 758 Functionally, it's important that Load Balancer provides NAT a way 759 for assigning Associations to multiple SCTP Hosts. 761 6.3. Handling of Internal Port Number Collisions 763 Consider the case where two hosts in the Internal-Address space want 764 to set up an SCTP association with the same service provided by some 765 remote host. This means that the Remote-Port is the same. If they 766 both choose the same Internal-Port the NAT function will experience 767 collision when receiving the INIT and trying to create an Entry in 768 the NAT Tables. In such case NAT will send an ABORT chunk with M-bit 769 set to the SCTP Client. Since it's up to the SCTP User Application 770 to choose the Internal Port, it may be that an Association chooses 771 the Internal Port from the ephemeral port range at random (see 772 [RFC6056] ), this would make the probability for Port Number 773 Collision low. 775 At the Association initialization, the Client will experience one out 776 of three alternative answers from the network: 778 * INIT-ACK from the peer, this means a viable path exists between 779 peers, all the involved NATs have NAT tables properly configured 780 and the Association can be established. 782 * ABORT with M-bit set from one of the NATs within the path, this 783 means that the Association cannot be established. The SCTP User 784 application SHOULD decide whether to retry with a different 785 Internal Port or to give up. The way SCTP and the SCTP User 786 interact in this case is implementation dependent. 788 * ABORT from the remote peer. 790 The way SCTP and SCTP User Application interact can be either: 792 * An application can request a specific local port number (in the 793 socket API, using bind() with a non-zero port number) and in case 794 of a local port number collision, the connection setup has to 795 fail. It is up to the application to close() the socket and 796 restart from the beginning. 798 * An application leaves the local port number selection up to the 799 SCTP stack (in the socket socket API by either calling bind() with 800 a zero port number or not calling bind() at all before calling 801 connect() or sendto()). However, once the port number is chosen, 802 it can not be changed. So in case of a local port number 803 collision, the association setup has to fail. It is up to the 804 application to close() the socket and restart from the beginning. 806 * An application leaves the local port number selection up to the 807 SCTP stack (in the socket socket API by either calling bind() with 808 a zero port number or not calling bind() at all before calling 809 connect() or sendto()). In addition, it indicates that the SCTP 810 can change the local port number over time (in the socket API this 811 would be calling an IPPROTO_SCTP level new socket option). In 812 this case, the SCTP stack can automatically retry a connection 813 setup in case of an local port number collision. 815 6.3.1. NAT Function Considerations 817 NAT function checks for collision only on packets containing INIT 818 chunk. If the NAT function detects a collision of internal port 819 numbers, it SHOULD send a packet containing an ABORT chunk with the M 820 bit set. The M bit is a new bit defined by this document to express 821 to SCTP that the source of this packet is a "middle" box, not the 822 peer SCTP endpoint (see Section 5.1.1 ). the source and destination 823 address and port numbers MUST be swapped. 825 The sender of the packet containing an ERROR or ABORT chunk MUST 826 include the error cause with cause code 'Port Number Collision' (see 827 Section 5.2.1 ). 829 If the INIT chunk contains the RJ option the NAT function MUST NOT 830 forward the INIT chunk to the SCTP Host but it MUST reply to the 831 remote peer with INIT-ACK chunk with the M bit set. The M bit is a 832 new bit defined by this document to express to SCTP that the source 833 of this packet is a "middle" box (see Section 5.1.3 ). The 834 information contained in INIT-ACK chunk SHOULD be copied from the 835 INIT chunk. The value for Initiate Tag and Initial TSN MAY be chosen 836 random. 838 6.3.2. Endpoint Considerations 840 The sender of the packet containing the INIT chunk upon reception of 841 a packet containing an ABORT chunk with M bit set and the appropriate 842 error cause code for colliding NAT binding table state is included, 843 SHOULD evaluate the reason for ABORT. If the reason is "Port Number 844 Collision" it SHOULD reinitiate the association setup procedure after 845 choosing a new Internal Port. 847 6.4. Handling of Missing State 848 6.4.1. NAT Function Considerations 850 When experiencing a restart, the NAT function will start handling 851 SCTP packets with time difference between the ones containing INIT 852 chunks and all the other ones. Handling of SCTP packets containing 853 INIT chunks will start at least 4 * HB.interval after handling other 854 SCTP packets (see section 15 of [RFC4960] ). This avoids race 855 condition between the recreation of existing Entries in the NAT 856 Table and the creation of new ones from new Association requests. 858 If the NAT function receives a packet not containing an INIT chunk 859 from the internal network for which the lookup procedure does not 860 find an entry in the NAT binding table, it must create an Entry for 861 that packet and forward it. If the NAT function receives a packet 862 not containing an INIT chunk from the external network for which the 863 lookup procedure does not find an entry in the NAT binding table, it 864 must silently drop it. 866 6.4.2. Endpoint Considerations 868 Upon restart of a NAT function, the endpoint will experience 869 connectivity interruption, depending on the Association state it will 870 keep on retrying sending SCTP packets containint DATA chunks or HB 871 chunks. Since the longest interval between SCTP packets is 872 HB.interval, it will be able restoring the connectivity at most 2 * 873 HB.interval after NAT function is back at work. 875 If the Endpoint is trying to establish an Association, it will 876 experience a longer connectivity unavalilability of more than 4 * 877 HB.interval as NAT needs to rebuild the NAT Table with the existing 878 Associations first. 880 6.5. Handling of Fragmented SCTP Packets by NAT Functions 882 SCTP minimizes the use of IP-level fragmentation. However, it can 883 happen that using IP-level fragmentation is needed to continue an 884 SCTP association. For example, if the path MTU is reduced and there 885 are still some DATA chunk in flight, which require packets larger 886 than the new path MTU. If IP-level fragmentation can not be used, 887 the SCTP association will be terminated in a non-graceful way. See 888 [RFC8900] for more information about IP fragmentation. 890 Therefore, a NAT function MUST be able to handle IP-level fragmented 891 SCTP packets. The fragments MAY arrive in any order. 893 When an SCTP packet can not be forwarded by the NAT function due to 894 MTU issues and the IP header forbids fragmentation, the NAT MUST send 895 back a "Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message 896 to the internal host. This allows for a faster recovery from this 897 packet drop. 899 6.6. Multipoint Traversal Considerations for Endpoints 901 If a multi-homed SCTP endpoint behind a NAT function connects to a 902 peer, it MUST first set up the association single-homed with only one 903 destination address causing the first NAT function to populate its 904 state. 906 Once an Association has been created, it's possible to add further 907 external IP addresses for the peer to use, but before adding each IP 908 address it must be created the needed set of Entries in all NAT 909 functions towards all the peer's IP addresses. An INIT chunk 910 containing a RJ option (see Section 5.3.1 ) SHOULD be sent towards 911 all peers IP addresses using a path selector that is expected to 912 result in another external addres than association creation. The 913 reason why an INIT chunk with RJ option set is to be used is for 914 permitting the remote to be able discriminating between a request for 915 a new Association in case of Distributed Endpoint. The result from 916 that INIT is according to the given rules for Association setup (see 917 Section 6.1 ) and can cause collision. The reception of INIT ACK 918 confirms that the path from the new IP address and the remote one is 919 available and that all the NATs involved are properly configured. In 920 case INIT ACK has M-bit set, the remote Endpoint is distributed. 922 After succefull confirmation, the Endpoint SHOULD add each IP address 923 using packets containing ASCONF chunks sent via their respective NAT 924 functions. The address used in the Add IP address parameter is the 925 wildcard address (0.0.0.0 or ::0) and the address parameter in the 926 ASCONF chunk SHOULD also contain the VTags parameter. 928 When an Endpoint gets a new Remote IP Address added to an 929 Association, it SHOULD send INIT chunks with RJ option towards from 930 all its own IP Addresses towards that address in order to properly 931 set all the NATs in the path. 933 6.6.1. NAT Function Considerations 935 NAT function differentiates the behavior towards INIT chunk depending 936 on the RJ option. If the RJ option exists and the packet contains an 937 incoming INIT chunk, the NAT function SHOULD NOT forward the INIT 938 chunk towards the SCTP Host, it shall reply instead with an INIT ACK 939 chunk with the M-bit set. Section 5.1.3 ). NAT function SHOULD 940 create INIT ACK data by using the parameters from the received INIT 941 chunk. 943 6.6.2. Endpoint Considerations 945 When the Endpoint receives an INIT chunk with RJ option set, it will 946 ignore the RJ option and handle INIT as in the legacy case. 948 The Endpoint originating INIT chunk with RJ option set can receive 949 different answers: 951 * When receiving INIT ACK, it will assume the NATs on the path are 952 properly set and the Endpoint can continue with the ASCONF 953 procedure. 955 * When receiving as ABORT with M-bit set, it shall assume that a 956 path is not possible to be established. The Endpoint SHOULD retry 957 after a time greather than 4 * HB.interval. 959 * When receiving an ABORT without M-bit set, it shall assume that 960 some temporary NAT configuration has led the INIT towards the 961 wrong SCTP Host. The Endpoint SHOULD retry after a time greather 962 than 4 * HB.interval. 964 7. Examples of Operation 966 This section describes examples of Association Establishements using 967 the reference scenario depicted in Figure 6. Hosts A1 and A2 968 implement a distributed client towards the same remote Host. Hosts 969 B1 and B2 implement a distributed Endpoint 'B' acting as Server. The 970 Load Balancer functionality is not shown as it doesn't affect SCTP 971 protocol. 973 Internal | External | Internal 974 +------+ +------+ 975 +==|NAT A |==\ /--\/--\ /==|NAT C |==+ 976 +--------+ | +------+ \ / \ / +------+ | +--------+ 977 |Host A1 +---+ | \/ \/ | +-----|Host B1 | 978 | +-+ | | | Network | | | +--+ | 979 +--------+ | | | /\ /\ | | | +--------+ 980 | | +------+ / \ / \ +------+ | | 981 +====|NAT B |==/ \--\/--/ \==|NAT D |=====+ 982 | | +------+ +------+ | | 983 +--------+ | | | | | | +--------+ 984 |Host A2 +-|-+ | | +--|--+Host B2 | 985 | +-+ | | +--+ | 986 +--------+ | | +--------+ 988 Figure 6: Parallel NAT with distributed endpoints Scenario 990 7.1. Single Homed Association Setup 992 This section describes a successfull Association Establishment from 993 A1 towards the distributed endpoint B. The sequence chart is shown 994 in Figure 7. 996 A1 A2 NAT A NAT B NAT C NAT D B1 B2 997 | | | | | | | | 998 +--------------}| INIT | | | | | 999 | | +----------------------}| | | | 1000 | | | | +----------------------}| | 1001 | | | | | | | | 1002 | | | | |{----------------------+ | 1003 | | |{----------------------+ | | | 1004 |{--------------+ INIT ACK | | | | | 1005 | | | | | | | | 1007 Figure 7: Single Homed successfull Association Setup 1009 7.2. Single Homed Association Setup with Collision 1011 This section describes a successfull Association Establishment from 1012 A2 towards the distributed endpoint B. The collision happens at NAT 1013 A. The sequence chart is shown in Figure 8 . 1015 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1016 | | | | | | | | 1017 | +------}| INIT | | | | | 1018 | |{------+ ABORT | | | | | 1019 | | | | | | | | 1020 | +------}| INIT | | | | | 1021 | | +----------------------}| | | | 1022 | | | | +----------------------------}| 1023 | | | | | | | | 1024 | | | | |{----------------------------+ 1025 | | |{----------------------+ | | | 1026 | {-------+ INIT ACK | | | | | 1027 | | | | | | | | 1029 Figure 8: Single Homed successfull Association Setup after congestion 1031 7.3. Multi Homed Association Setup 1033 This section describes how the single homed established at 1034 Section 7.1 becomes multihomed. Note that the decision for what peer 1035 has to handle the INIT message requires support of Load Balancer. 1036 It's assumed that a Load Balancer exists and provides NAT with the 1037 right information. Success happens at all steps. Figure 9 . 1039 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1040 | | | | | | | | 1041 +--------------------------}| INIT RJ | | | | 1042 | | | +----------}| | | | 1043 | | | |{----------+ | | | 1044 |{--------------------------+ INIT ACK | | | | 1045 | | | | | | | | 1046 +--------------------------}| ASCONF | | | | 1047 | | | +----------}| | | | 1048 | | | | +----------------------}| | 1049 | | | | |{----------------------+ | 1050 | | | |{----------+ | | | 1051 |{--------------------------+ ASCONF ACK| | | | 1052 | | | | | | | | 1053 | | | | INIT RJ |{----------------------+ | 1054 | | | |{----------+ | | | 1055 | | | +----------}| | | | 1056 | | | | INIT ACK +----------------------}| | 1057 | | | | | | | | 1059 Figure 9: Multi Homed successfull Association Setup 1061 7.4. Multi Homed Association Setup 1063 This section describes how the multihome homed established at 1064 Section 7.3 becomes multihomed from the other peer. Success happens 1065 at all steps. Figure 10 . 1067 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1068 | | | | | | | | 1069 | | | | INIT RJ | |{----------+ | 1070 | | |{----------------------------------+ | | 1071 | | +----------------------------------}| | | 1072 | | | | INIT ACK | +----------}| | 1073 | | | | INIT RJ | |{----------+ | 1074 | | | |{----------------------+ | | 1075 | | | +----------------------}| | | 1076 | | | | INIT ACK | +----------}| | 1077 | | | | | | | | 1078 | | | | ASCONF | |{----------+ | 1079 | | |{----------------------------------+ | | 1080 |{--------------+ | | | | | 1081 +--------------}| | ASCONF ACK| | | | 1082 | | +----------------------------------}| | | 1083 | | | | | +----------}| | 1084 | | | | | | | | 1085 +--------------}| | INIT RJ | | | | 1086 | | +----------------------------------}| | | 1087 | | |{----------------------------------+ | | 1088 |{--------------+ | INIT ACK | | | | 1089 | | | | | | | | 1090 +--------------------------}| INIT RJ | | | | 1091 | | | +----------------------}| | | 1092 | | | |{----------------------+ | | 1093 |{--------------------------+ INIT ACK | | | | 1094 | | | | | | | | 1096 Figure 10: Multi Homed successfull Association Setup 1098 8. IANA Considerations 1100 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1101 you assign this document.] 1103 [NOTE to RFC-Editor: The requested values for the chunk type and the 1104 chunk parameter types are tentative and to be confirmed by IANA.] 1105 This document (RFCXXXX) is the reference for all registrations 1106 described in this section. The requested changes are described 1107 below. 1109 8.1. New Chunk Flags for Two Existing Chunk Types 1111 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1112 for the ERROR chunk. The requested value for the T bit is 0x01 and 1113 for the M bit is 0x02. 1115 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1117 ERROR Chunk Flags 1119 +==================+=================+===========+ 1120 | Chunk Flag Value | Chunk Flag Name | Reference | 1121 +==================+=================+===========+ 1122 | 0x01 | T bit | [RFCXXXX] | 1123 +------------------+-----------------+-----------+ 1124 | 0x02 | M bit | [RFCXXXX] | 1125 +------------------+-----------------+-----------+ 1126 | 0x04 | Unassigned | | 1127 +------------------+-----------------+-----------+ 1128 | 0x08 | Unassigned | | 1129 +------------------+-----------------+-----------+ 1130 | 0x10 | Unassigned | | 1131 +------------------+-----------------+-----------+ 1132 | 0x20 | Unassigned | | 1133 +------------------+-----------------+-----------+ 1134 | 0x40 | Unassigned | | 1135 +------------------+-----------------+-----------+ 1136 | 0x80 | Unassigned | | 1137 +------------------+-----------------+-----------+ 1139 Table 2 1141 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1142 the ABORT chunk. The requested value of the M bit is 0x02. 1144 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1146 ABORT Chunk Flags 1147 +==================+=================+===========+ 1148 | Chunk Flag Value | Chunk Flag Name | Reference | 1149 +==================+=================+===========+ 1150 | 0x01 | T bit | [RFC4960] | 1151 +------------------+-----------------+-----------+ 1152 | 0x02 | M bit | [RFCXXXX] | 1153 +------------------+-----------------+-----------+ 1154 | 0x04 | Unassigned | | 1155 +------------------+-----------------+-----------+ 1156 | 0x08 | Unassigned | | 1157 +------------------+-----------------+-----------+ 1158 | 0x10 | Unassigned | | 1159 +------------------+-----------------+-----------+ 1160 | 0x20 | Unassigned | | 1161 +------------------+-----------------+-----------+ 1162 | 0x40 | Unassigned | | 1163 +------------------+-----------------+-----------+ 1164 | 0x80 | Unassigned | | 1165 +------------------+-----------------+-----------+ 1167 Table 3 1169 8.2. Four New Error Causes 1171 Four error causes have to be assigned by IANA. It is requested to 1172 use the values given below. 1174 This requires Four additional lines in the "Error Cause Codes" 1175 registry for SCTP: 1177 Error Cause Codes 1179 +=======+================================+===========+ 1180 | Value | Cause Code | Reference | 1181 +=======+================================+===========+ 1182 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1183 +-------+--------------------------------+-----------+ 1184 | 177 | Missing State | [RFCXXXX] | 1185 +-------+--------------------------------+-----------+ 1186 | 178 | Port Number Collision | [RFCXXXX] | 1187 +-------+--------------------------------+-----------+ 1188 | 179 | VTag Not Found | [RFCXXXX] | 1189 +-------+--------------------------------+-----------+ 1191 Table 4 1193 8.3. Two New Chunk Parameter Types 1195 Two chunk parameter types have to be assigned by IANA. IANA is 1196 requested to assign these values from the pool of parameters with the 1197 upper two bits set to '11' and to use the values given below. 1199 This requires two additional lines in the "Chunk Parameter Types" 1200 registry for SCTP: 1202 Chunk Parameter Types 1204 +==========+==========================+===========+ 1205 | ID Value | Chunk Parameter Type | Reference | 1206 +==========+==========================+===========+ 1207 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1208 +----------+--------------------------+-----------+ 1209 | 49160 | VTags (0xC008) | [RFCXXXX] | 1210 +----------+--------------------------+-----------+ 1212 Table 5 1214 9. Security Considerations 1216 State maintenance within a NAT function is always a subject of 1217 possible Denial Of Service attacks. This document recommends that at 1218 a minimum a NAT function runs a timer on any SCTP state so that old 1219 association state can be cleaned up. 1221 Generic issues related to address sharing are discussed in [RFC6269] 1222 and apply to SCTP as well. 1224 For SCTP endpoints not disabling the restart procedure, this document 1225 does not add any additional security considerations to the ones given 1226 in [RFC4960] , [RFC4895] , and [RFC5061] . 1228 SCTP endpoints disabling the restart procedure, need to monitor the 1229 status of all associations to mitigate resource exhaustion attacks by 1230 establishing a lot of associations sharing the same IP addresses and 1231 port numbers. 1233 In any case, SCTP is protected by the verification tags and the usage 1234 of [RFC4895] against off-path attackers. 1236 For IP-level fragmentation and reassembly related issues see 1237 [RFC4963] . 1239 * Setting a low timeout for SCTP mapping entries to cause failures 1240 to deliver incoming SCTP packets. 1242 * Instantiating mapping entries to cause NAT collision. 1244 10. Normative References 1246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1247 Requirement Levels", BCP 14, RFC 2119, 1248 DOI 10.17487/RFC2119, March 1997, 1249 . 1251 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1252 "Authenticated Chunks for the Stream Control Transmission 1253 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1254 2007, . 1256 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1257 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1258 . 1260 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1261 Kozuka, "Stream Control Transmission Protocol (SCTP) 1262 Dynamic Address Reconfiguration", RFC 5061, 1263 DOI 10.17487/RFC5061, September 2007, 1264 . 1266 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 1267 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 1268 DOI 10.17487/RFC6096, January 2011, 1269 . 1271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1273 May 2017, . 1275 11. Informative References 1277 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1278 RFC 793, DOI 10.17487/RFC0793, September 1981, 1279 . 1281 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1282 Address Translator (Traditional NAT)", RFC 3022, 1283 DOI 10.17487/RFC3022, January 2001, 1284 . 1286 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1287 Translation (NAT) Behavioral Requirements for Unicast 1288 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1289 2007, . 1291 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1292 Errors at High Data Rates", RFC 4963, 1293 DOI 10.17487/RFC4963, July 2007, 1294 . 1296 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1297 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1298 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1299 . 1301 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1302 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1303 DOI 10.17487/RFC5508, April 2009, 1304 . 1306 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1307 Protocol Port Randomization", BCP 156, RFC 6056, 1308 DOI 10.17487/RFC6056, January 2011, 1309 . 1311 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1312 NAT64: Network Address and Protocol Translation from IPv6 1313 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1314 April 2011, . 1316 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1317 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1318 DOI 10.17487/RFC6269, June 2011, 1319 . 1321 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1322 Stack Lite Broadband Deployments Following IPv4 1323 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1324 . 1326 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1327 "Special-Purpose IP Address Registries", BCP 153, 1328 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1329 . 1331 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1332 Control Transmission Protocol (SCTP) Packets for End-Host 1333 to End-Host Communication", RFC 6951, 1334 DOI 10.17487/RFC6951, May 2013, 1335 . 1337 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 1338 S., and K. Naito, "Updates to Network Address Translation 1339 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 1340 DOI 10.17487/RFC7857, April 2016, 1341 . 1343 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1344 and F. Gont, "IP Fragmentation Considered Fragile", 1345 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1346 . 1348 Acknowledgments 1350 The author wishes to thank Michael Tuxen , and Magnus Westerlund for 1351 their invaluable comments. 1353 In addition, the author wishes to thank , for their suggestions. 1355 The author also wishes to thank the authors of draft-ietf-tsvwg- 1356 natsupp-22 which this document is based. 1358 Author's Address 1360 Claudio Porfiri 1361 Ericsson AB 1362 Torshamnsgatan 21 1363 16440 Stockholm 1364 Sweden 1366 Email: claudio.porfiri@ericsson.com