idnits 2.17.1 draft-porfiri-tsvwg-sctp-natsupp-00.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 (27 August 2021) is 965 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 501, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1227, 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 27 August 2021 5 Expires: 28 February 2022 7 Stream Control Transmission Protocol (SCTP) Network Address Translation 8 Support 9 draft-porfiri-tsvwg-sctp-natsupp-00 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 Finally, a YANG module for SCTP NAT is defined. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 28 February 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Motivation and Overview . . . . . . . . . . . . . . . . . . . 6 67 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 68 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 7 69 4.1.2. Multipoint Traversal . . . . . . . . . . . . . . . . 8 70 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 9 71 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 9 72 4.4. Differences with Current NAT Support Draft . . . . . . . 14 73 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 15 75 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 15 76 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 15 77 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 15 78 5.2.1. Port Number Collision Error Cause . . . . . . . . . . 16 79 5.2.2. VTag Not Found Error Cause . . . . . . . . . . . . . 16 80 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 17 81 5.3.1. Repetita Juvant Parameter . . . . . . . . . . . . . . 17 82 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 17 83 6.1. Association Setup Considerations for Endpoints . . . . . 18 84 6.2. Association Setup Considerations for NAT . . . . . . . . 19 85 6.3. Handling of Internal Port Number Collisions . . . . . . . 19 86 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20 87 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 88 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 89 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 21 90 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 91 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 22 92 6.6. Multipoint Traversal Considerations for Endpoints . . . . 22 93 6.6.1. NAT Function Considerations . . . . . . . . . . . . . 23 94 6.6.2. Endpoint Considerations . . . . . . . . . . . . . . . 23 96 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 24 97 7.1. Single Homed Association Setup . . . . . . . . . . . . . 24 98 7.2. Single Homed Association Setup with Congestion . . . . . 25 99 7.3. Multi Homed Association Setup . . . . . . . . . . . . . . 25 100 7.4. Multi Homed Association Setup . . . . . . . . . . . . . . 26 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 102 8.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 28 103 8.2. Four New Error Causes . . . . . . . . . . . . . . . . . . 29 104 8.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 30 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 106 10. Normative References . . . . . . . . . . . . . . . . . . . . 31 107 11. Informative References . . . . . . . . . . . . . . . . . . . 32 108 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 111 1. Introduction 113 Stream Control Transmission Protocol (SCTP) [RFC4960] provides a 114 reliable communications channel between two end-hosts in many ways 115 similar to TCP [RFC0793] . With the widespread deployment of Network 116 Address Translators (NAT), specialized code has been added to NAT 117 functions for TCP that allows multiple hosts to reside behind a NAT 118 function using private-use addresses (see [RFC6890] ) and yet share a 119 single IPv4 address, even when two hosts (behind a NAT function) 120 choose the same port numbers for their connection. This additional 121 code is sometimes classified as Network Address and Port Translation 122 (NAPT). Please note that this document focuses on the case where the 123 NAT function maps a single or multiple internal addresses to a single 124 external address and vice versa. 126 To date, specialized code for SCTP has not yet been added to most NAT 127 functions so that only a translation of IP addresses is supported. 128 The end result of this is that only one SCTP-capable host can 129 successfully operate behind such a NAT function and this host can 130 only be single-homed. The only alternative for supporting legacy NAT 131 functions is to use UDP encapsulation as specified in [RFC6951] . 133 The NAT function in the document refers to NAPT functions described 134 in Section 2.2 of [RFC3022] , NAT64 [RFC6146] , or DS-Lite AFTR 135 [RFC6333] . 137 This document specifies procedures allowing a NAT function to support 138 SCTP by providing similar features to those provided by a NAPT for 139 TCP (see [RFC5382] and [RFC7857] ), UDP (see [RFC4787] and [RFC7857] 140 ), and ICMP (see [RFC5508] and [RFC7857] ). This document also 141 specifies a set of data formats for SCTP packets and a set of SCTP 142 endpoint procedures to support NAT traversal. An SCTP implementation 143 supporting these procedures can assure that in both single-homed and 144 multi-homed cases a NAT function will maintain the appropriate state 145 without the NAT function needing to change port numbers. 147 It is possible and desirable to make these changes for a number of 148 reasons: 150 * It is desirable for SCTP internal end-hosts on multiple platforms 151 to be able to share a NAT function's external IP address in the 152 same way that a TCP session can use a NAT function. 154 * If a NAT function does not need to change any data within an SCTP 155 packet, it will reduce the processing burden of NAT'ing SCTP by 156 not needing to execute the CRC32c checksum used by SCTP. 158 * Not having to touch the IP payload makes the processing of ICMP 159 messages by NAT functions easier. 161 An SCTP-aware NAT function will need to follow these procedures for 162 generating appropriate SCTP packet formats, this is needed under 163 circumstances detailed in this document and only triggered by the 164 detection of an SCTP packet containing an INIT chunk. 166 When considering SCTP-aware NAT it is possible to have multiple 167 levels of support. At each level, the Internal Host, Remote Host, 168 and NAT function does or does not support the procedures described in 169 this document. The following table illustrates the results of the 170 various combinations of support and if communications can occur 171 between two endpoints. 173 +===============+==============+=============+===============+ 174 | Internal Host | NAT Function | Remote Host | Communication | 175 +===============+==============+=============+===============+ 176 | Support | Support | Support | Yes | 177 +---------------+--------------+-------------+---------------+ 178 | Support | Support | No Support | Limited | 179 +---------------+--------------+-------------+---------------+ 180 | Support | No Support | Support | None | 181 +---------------+--------------+-------------+---------------+ 182 | Support | No Support | No Support | None | 183 +---------------+--------------+-------------+---------------+ 184 | No Support | Support | Support | Limited | 185 +---------------+--------------+-------------+---------------+ 186 | No Support | Support | No Support | Limited | 187 +---------------+--------------+-------------+---------------+ 188 | No Support | No Support | Support | None | 189 +---------------+--------------+-------------+---------------+ 190 | No Support | No Support | No Support | None | 191 +---------------+--------------+-------------+---------------+ 193 Table 1: Communication possibilities 195 From the table it can be seen that no communication can occur when a 196 NAT function does not support SCTP-aware NAT. This assumes that the 197 NAT function does not handle SCTP packets at all and all SCTP packets 198 sent from behind a NAT function are discarded by the NAT function. 199 In some cases, where the NAT function supports SCTP-aware NAT, but 200 one of the two hosts does not support the feature, communication can 201 possibly occur in a limited way. For example, only one host can have 202 a connection when a collision case occurs. 204 2. Conventions 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 208 "OPTIONAL" in this document are to be interpreted as described in BCP 209 14 [RFC2119] [RFC8174] when, and only when, they appear in all 210 capitals, as shown here. 212 3. Terminology 214 This document uses the following terms, which are depicted in 215 Figure 1 . Familiarity with the terminology used in [RFC4960] and 216 [RFC5061] is assumed. 218 Internal-Address (Int-Addr) 219 An internal address that is known to the internal host. 221 Internal-Port (Int-Port) 222 The port number that is in use by the host holding the Internal- 223 Address. 225 Internal-VTag (Int-VTag) 226 The SCTP Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) 227 that the internal host has chosen for an association. The VTag is 228 a unique 32-bit tag that accompanies any incoming SCTP packet for 229 this association to the Internal-Address. 231 Remote-Address (Rem-Addr) 232 The address that an internal host is attempting to contact. 234 Remote-Port (Rem-Port) 235 The port number used by the host holding the Remote-Address. 237 Remote-VTag (Rem-VTag) 238 The Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) that 239 the host holding the Remote-Address has chosen for an association. 240 The VTag is a unique 32-bit tag that accompanies any outgoing SCTP 241 packet for this association to the Remote-Address. 243 External-Address (Ext-Addr) 244 An external address assigned to the NAT function, that it uses as 245 a source address when sending packets towards a Remote-Address. 247 Internal Network | External Network 248 | 249 Internal | External Remote 250 Address | Address /--\/--\ Address 251 +--------+ +-----+ / \ +--------+ 252 | Host A |=========| NAT |=======| Network |==========| Host B | 253 +--------+ +-----+ \ / +--------+ 254 Internal | \--/\--/ Remote 255 Internal Port | Port Remote 256 VTag | VTag 258 Figure 1: Basic Network Setup 260 4. Motivation and Overview 262 4.1. SCTP NAT Traversal Scenarios 264 This section defines the notion of single and multipoint NAT 265 traversal. 267 4.1.1. Single Point Traversal 269 In this case, all packets in the SCTP association go through a single 270 NAT function, as shown in Figure 2 . 272 Internal Network | External Network 273 | 274 | /--\/--\ 275 +--------+ +-----+ / \ +--------+ 276 | Host A |=========| NAT |========= | Network | ========| Host B | 277 +--------+ +-----+ \ / +--------+ 278 | \--/\--/ 279 | 281 Figure 2: Single NAT Function Scenario 283 A variation of this case is shown in Figure 3 , i.e., multiple NAT 284 functions in the forwarding path between two endpoints. 286 Internal | External : Internal | External 287 | : | 288 | : | /--\/--\ 289 +--------+ +-----+ : +-----+ / \ +--------+ 290 | Host A |==| NAT |=======:=======| NAT |==| Network |==| Host B | 291 +--------+ +-----+ : +-----+ \ / +--------+ 292 | : | \--/\--/ 293 | : | 295 Figure 3: Serial NAT Functions Scenario 297 Another case where the Endpoint is ditributed among SCTP Hosts is 298 shown in Figure 4 where multiple Hosts behave as Server and share the 299 same Internal Port. A Load Balancer node supports NAT when a new 300 Association request comes. . 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, however 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 (see Section 4.3 ). 377 4.3. The SCTP-Specific Variant of NAT 379 In this section it is allowed that there are multiple SCTP capable 380 hosts behind a NAT function that share one External-Address. This 381 section focuses on the single point traversal scenario (see 382 Section 4.1.1 ) as well as on the multipoint trasversal NAT (see 383 Section 4.1.2 ). 385 The modification of outgoing SCTP packets sent from an internal host 386 is simple: the source address of the packets has to be replaced with 387 the External-Address. It might also be necessary to establish some 388 state in the NAT function to later handle incoming packets. 390 Typically, the NAT function has to maintain a NAT binding table of 391 Internal-Port, Remote-Port, Internal-Address, Remote-Address. An 392 entry in that NAT binding table is called a NAT-State control block. 393 The function Create() obtains the just mentioned parameters and 394 returns a NAT-State control block. Create() instantiates a 395 supervision timer on the NAT-State control block that has duration 396 greather than 2 * HB.interval and lower than 4 * HB.interval (see 397 section 15 of [RFC4960] ). A NAT function MAY allow creating NAT- 398 State control blocks via a management interface. 400 For SCTP packets coming from the external realm of the NAT function 401 the destination address of the packets has to be replaced with the 402 Internal-Address of the host to which the packet has to be delivered, 403 if a NAT state entry is found. The lookup of the Internal-Address is 404 based on the Remote-Address, Remote-Port and the Internal-Port. The 405 lookup function retarts the Nat-State control block supervision 406 timer. 408 The entries in the NAT binding table need to fulfill some uniqueness 409 conditions. There can not be more than one entry NAT binding table 410 with the same 4-tuple of Internal-Address, Remote-Address, Internal- 411 Port and Remote-Port. 413 NAT is able understanding that the SCTP packet transports an INIT 414 chunk because the SCTP common header will have VTAG=0 (see section 415 3.1 of [RFC4960] 417 The processing of outgoing SCTP packets containing an INIT chunk is 418 illustrated in the following figure. This scenario is valid for all 419 message flows in this section. 421 /--\/--\ 422 +--------+ +-----+ / \ +--------+ 423 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 424 +--------+ +-----+ \ / +--------+ 425 \--/\---/ 427 INIT[Initiate-Tag] 428 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 429 Rem-VTag=0 431 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 432 sendAbort(Rem-Addr, Rem-Port, Int-Addr, Int-Port, M-bit) 433 else 434 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 435 Returns(control block) 436 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 438 Translates To: 440 INIT[Initiate-Tag] 441 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 442 Rem-VTag=0 444 Normally a NAT binding table entry will be created. 446 However, it is possible that there is already a NAT binding table 447 entry with the same Remote-Address, Internal-Port and Remote-Port but 448 different Internal-Address. In this case the packet containing the 449 INIT chunk MUST be dropped by the NAT and a packet containing an 450 ABORT chunk SHOULD be sent to the SCTP host that originated the 451 packet with the M bit set and 'Port Number Collision' error cause 452 (see Section 5.1.1 for the format). The source address of the packet 453 containing the ABORT chunk MUST be the destination address of the 454 packet containing the INIT chunk. 456 The processing of outgoing SCTP packets containing chunks other than 457 INIT is described in the following figure. 459 /--\/--\ 460 +--------+ +-----+ / \ +--------+ 461 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 462 +--------+ +-----+ \ / +--------+ 463 \--/\---/ 465 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 466 Rem-VTag 468 if lookup(Int-Port, Rem-Port, Rem-Addr) == false 469 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 470 Returns(control block) 471 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 473 Translates To: 475 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 476 Rem-VTag 478 The processing of incoming SCTP packets containing an INIT chunk is 479 illustrated in the following figure. This scenario is valid for all 480 message flows in this section. 482 /--\/--\ 483 +--------+ +-----+ / \ +--------+ 484 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 485 +--------+ +-----+ \ / +--------+ 486 \--/\---/ 488 INIT [Initiate-Tag] 489 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 490 Int-VTag=0 492 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 493 sendAbort(Ext-Addr, Int-Port, Rem-Addr, Rem-Port, M-bit) 494 else 495 Create(Int-Port, Rem-Port, Int-Addr, Rem-Addr) 496 Returns(control block) 497 forwardPkt(Rem-Addr, Rem-Port, Int-Addr, Int-Port) 499 Translates To: 501 INIT[Initiate-Tag] 502 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 503 Int-VTag=0 505 The processing of incoming SCTP packets containing chunk different 506 than INIT is illustrated in the following figure. The Lookup() 507 function has as input the Remote-Address, Remote-Port and the 508 Internal-Port. It returns the corresponding entry of the NAT binding 509 table. 511 /--\/--\ 512 +--------+ +-----+ / \ +--------+ 513 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 514 +--------+ +-----+ \ / +--------+ 515 \--/\---/ 517 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 518 Int-VTag 520 if lookup(Int-Port, Rem-Port, Rem-Addr) == true 521 Returns(NAT-State control block containing Int-Addr) 522 forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) 524 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 525 Int-VTag 527 In the case where the Lookup function fails because it does not find 528 an entry, the SCTP packet is dropped. 530 4.4. Differences with Current NAT Support Draft 532 This section describes the differences with the existing draft-ietf- 533 tsvwg-natsupp. 535 The main difference is in the NAT to be stateless rather than 536 following the status of the association. Actually in this proposal 537 NAT doesn't need to parse the SCTP payloads, it only needs to check 538 the SCTP Common Header and discriminate the behavior based on 539 Verification Tag = 0, that indicates the SCTP packet contains an INIT 540 chunk. The NAT supervises the association by means of a timer, if no 541 SCTP packets are seen within a certain time, the association is 542 closed. 544 The other difference is in the role of the SCTP User. In the current 545 proposal it's the SCTP User to change the originating Endpoint (i.e. 546 choose a different port number) if collision is detected. The 547 current proposal guarantees that at each node being in a path 548 belonging to an association, there will be only one 4-uple describing 549 an association, that means the NAT doesn't need to take care of VTAG. 551 5. Data Formats 553 This section defines the formats used to support NAT traversal. 554 Section 5.1 and Section 5.2 describe chunks and error causes sent by 555 NAT functions and received by SCTP endpoints. Section 5.3 describes 556 parameters sent by SCTP endpoints and used by NAT functions and SCTP 557 endpoints. 559 5.1. Modified Chunks 561 This section presents existing chunks defined in [RFC4960] for which 562 additional flags are specified by this document. 564 5.1.1. Extended ABORT Chunk 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type = 6 | Reserved |M|T| Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 \ \ 572 / zero or more Error Causes / 573 \ \ 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 The ABORT chunk is extended to add the new 'M bit'. The M bit 577 indicates to the receiver of the ABORT chunk that the chunk was not 578 generated by the peer SCTP endpoint, but instead by a middle box 579 (e.g., NAT). 581 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 583 5.1.2. Extended ERROR Chunk 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type = 9 | Reserved |M|T| Length | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 \ \ 591 / zero or more Error Causes / 592 \ \ 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 The ERROR chunk defined in [RFC4960] is extended to add the new 'M 596 bit'. The M bit indicates to the receiver of the ERROR chunk that 597 the chunk was not generated by the peer SCTP endpoint, but instead by 598 a middle box. 600 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 602 5.2. New Error Causes 604 This section defines the new error causes added by this document. 606 5.2.1. Port Number Collision Error Cause 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Cause Code = 0x00B2 | Cause Length = Variable | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 \ Chunk / 614 / \ 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Cause Code: 2 bytes (unsigned integer) 618 This field holds the IANA defined cause code for the 'Port Number 619 Collision' Error Cause. IANA is requested to assign the value 620 0x00B2 for this cause code. 622 Cause Length: 2 bytes (unsigned integer) 623 This field holds the length in bytes of the error cause. The 624 value MUST be the length of the Cause-Specific Information plus 4. 626 Chunk: variable length 627 The Cause-Specific Information is filled with the chunk that 628 caused this error. This can be an INIT, INIT ACK, or ASCONF 629 chunk. Note that if the entire chunk will not fit in the ERROR 630 chunk or ABORT chunk being sent then the bytes that do not fit are 631 truncated. 633 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 634 IANA.] 636 5.2.2. VTag Not Found Error Cause 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Cause Code = 0x00B3 | Cause Length = Variable | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 \ Chunk / 644 / \ 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Cause Code: 2 bytes (unsigned integer) 648 This field holds the IANA defined cause code for the 'Port Number 649 Collision' Error Cause. IANA is requested to assign the value 650 0x00B2 for this cause code. 652 Cause Length: 2 bytes (unsigned integer) 653 This field holds the length in bytes of the error cause. The 654 value MUST be the length of the Cause-Specific Information plus 4. 656 Chunk: variable length 657 The Cause-Specific Information is filled with the chunk that 658 caused this error. This can be an INIT chunk. Note that if the 659 entire chunk will not fit in the ERROR chunk or ABORT chunk being 660 sent then the bytes that do not fit are truncated. 662 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 663 IANA.] 665 5.3. New Parameters 667 This section defines new parameters and their valid appearance 668 defined by this document. 670 5.3.1. Repetita Juvant Parameter 672 Repetita Juvant is a latin phase standing for "repeating does good". 673 It's sually said as a jocular remark to defend the speaker's |or 674 writer's| choice to repeat some important piece of information to 675 ensure reception by the audience. 677 The RJ parameter is used to indicate that INIT chunk is the 678 repetition of an already sent one even if it comes from a different 679 source address. It's used from either peers before sending ASCONF in 680 order to setup the NATs in the path. This parameter holds the 681 Internal as well as the Remote verification Tags that will be used by 682 the remote peer for validation. 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Type = 0xXXXX | Length = 12 | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Internal Verification Tag | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Remote Verification Tag | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 6. Procedures for SCTP Endpoints and NAT Functions 696 If an SCTP endpoint is behind an SCTP-aware NAT, a number of problems 697 can arise as it tries to communicate with its peers: 699 * IP addresses can not be included in the SCTP packet. This is 700 discussed in Section 6.1 . 702 * More than one host behind a NAT function could select the same 703 source port number when initiating an association with the same 704 peer server. This creates a situation where the NAT function will 705 not be able to forward the INIT chunk. This situation is 706 discussed in Section 6.3 . 708 * A restart of a NAT function during a conversation could cause a 709 loss of its state. This problem and its solution is discussed in 710 Section 6.4 . 712 * NAT functions need to deal with SCTP packets being fragmented at 713 the IP layer. This is discussed in Section 6.5 . 715 * An SCTP endpoint can be behind two NAT functions in parallel 716 providing redundancy. The method to set up this scenario is 717 discussed in Section 6.6 . 719 The mechanisms to solve these problems require additional chunks and 720 parameters, defined in this document, and modified handling 721 procedures from those specified in [RFC4960] as described below. 723 6.1. Association Setup Considerations for Endpoints 725 The association setup procedure defined in [RFC4960] allows multi- 726 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 727 IPv6 address parameters in the INIT and INIT ACK chunks. However, 728 this does not work when NAT functions are present. 730 Every association setup from a host behind a NAT function MUST NOT 731 use multiple internal addresses. The INIT chunk MUST NOT contain an 732 IPv4 Address parameter, IPv6 Address parameter, or Supported Address 733 Types parameter. The INIT ACK chunk MUST NOT contain any IPv4 734 Address parameter or IPv6 Address parameter using non-global 735 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 736 any Host Name parameters. 738 If the association is intended to be finally multi-homed, the 739 procedure in Section 6.6 MUST be used. 741 6.2. Association Setup Considerations for NAT 743 When Endpoint is Distributed, NAT needs the cooperation of a Load 744 Balancer function for handling incoming and outgoing Association 745 Requests. It's up to the Load Balancer internal design the strategy 746 for permitting a Distributed Endpoint to handle the traffic. 747 Functionally, it's important that Load Balancer provides NAT a way 748 way for assigning Associations to multiple SCTP Hosts and being able 749 recognizing whether an Association Request with RJ Option set belongs 750 to and existing Association and what SCTP Host is in charge for that. 752 6.3. Handling of Internal Port Number Collisions 754 Consider the case where two hosts in the Internal-Address space want 755 to set up an SCTP association with the same service provided by some 756 remote hosts. This means that the Remote-Port is the same. If they 757 both choose the same Internal-Port the NAT function will experience 758 collision when receiving the INIT and trying to create an Entry in 759 the NAT Tables. In such case NAT will send an ABORT chunk with M-bit 760 set to the SCTP Client. Since it's up to the SCTP User Application 761 to choose the Internal Port, it may be that an Association chooses 762 the Internal Port from the ephemeral port range at random (see 763 [RFC6056] ), this would make the probability for Port Number 764 Collision low. 766 At the Association initialization, the Client will experience one out 767 of three alternative answers from the network: 769 * INIT-ACK from the peer, this means a viable path exists between 770 peers, all the involved NATs have NAT tables properly configured 771 and the Association can be established. 773 * ABORT with M-bit set from one of the NATs within the path, this 774 means that one Association cannot be established. The SCTP User 775 application SHOULD decide whether to retry with a different 776 Internal Port or to give up. The way SCTP and the SCTP User 777 interact in this case is implementation dependent. 779 * ABORT from the remote peer. 781 The way SCTP and SCTP User Application interact can be either: 783 * An application can request a specific local port number (in the 784 socket API, using bind() with a non-zero port number), ), and in 785 case of a local port number collision, the connection setup has to 786 fail. It is up to the application to close() the socket and 787 restart from the beginning. 789 * An application leaves the local port number selection up to the 790 SCTP stack (in the socket socket API by either calling bind() with 791 a zero port number or not calling bind() at all before calling 792 connect() or sendto(). However, once the port number is chosen, 793 it can not be changed. So in case of a local port number 794 collision, the association setup has to fail. It is up to the 795 application to close() the socket and restart from the beginning. 797 * An application leaves the local port number selection up to the 798 SCTP stack (in the socket socket API by either calling bind() with 799 a zero port number or not calling bind() at all before calling 800 connect() or sendto(). In addition, it indicates the the SCTP can 801 change the local port number over time (in the socket API this 802 would be calling an IPPROTO_SCTP level new socket option). In 803 this case, the SCTP stack can automatically retry a connection 804 setup in case of an local port number collision. 806 6.3.1. NAT Function Considerations 808 NAT function checks for collision only on packets containing INIT 809 chunk. If the NAT function detects a collision of internal port 810 numbers, it SHOULD send a packet containing an ABORT chunk with the M 811 bit set. The M bit is a new bit defined by this document to express 812 to SCTP that the source of this packet is a "middle" box, not the 813 peer SCTP endpoint (see Section 5.1.1 ). the source and destination 814 address and port numbers MUST be swapped. 816 The sender of the packet containing an ERROR or ABORT chunk MUST 817 include the error cause with cause code 'Port Number Collision' (see 818 Section 5.2.1 ). 820 If the INIT chunk contains the RJ option and the Endpoint is 821 Distributed, NAT will involve the Load Balancer function for 822 retrieving the Internal-Address of the SCTP Host handling the 823 Association. If the Load Balancer cannot relate the INIT chunk to an 824 existing Association, NAT function SHOULD send a packet containing an 825 ABORT chunk with the M bit set. The M bit is a new bit defined by 826 this document to express to SCTP that the source of this packet is a 827 "middle" box, not the peer SCTP endpoint (see Section 5.1.1 ). the 828 source and destination address and port numbers MUST be swapped. 830 The sender of the packet containing an ERROR or ABORT chunk MUST 831 include the error cause with cause code 'VTag Not Found' (see 832 Section 5.2.2 ). 834 6.3.2. Endpoint Considerations 836 The sender of the packet containing the INIT chunk upon reception of 837 a packet containing an ABORT chunk with M bit set and the appropriate 838 error cause code for colliding NAT binding table state is included, 839 SHOULD evaluate the reason for ABORT. If the reason is "Port Number 840 Collision" it SHOULD reinitiate the association setup procedure after 841 choosing a new Internal Port. If the reason is "Vtag Not Found", the 842 remote IP Address is to be considered not reacheable and a new 843 attempt SHOULD be tried after a time that is grather than 4 * 844 HB.interval. 846 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 result from that INIT is according to the given rules for Association 914 setup (see Section 6.1 ) and can cause collision. The reception of 915 INIT ACK with the same VTAG as the existing Association confirms that 916 the path from the new IP address and the remote one is available and 917 that all the NATs involved are properly configured. 919 After succefull confirmation, the Endpoint SHOULD add each IP address 920 using packets containing ASCONF chunks sent via their respective NAT 921 functions. The address used in the Add IP address parameter is the 922 wildcard address (0.0.0.0 or ::0) and the address parameter in the 923 ASCONF chunk SHOULD also contain the VTags parameter. 925 When an Endpoint gets a new Remote IP Address added to an 926 Association, it SHOULD send INIT chunks with RJ option towards from 927 all its own IP Addresses towards that address in order to properly 928 set all the NATs in the path. 930 6.6.1. NAT Function Considerations 932 NAT function will threat the INIT chunk containing a RJ option in the 933 same way as it does with INIT without RJ option. NAT doesn't 934 differentiate between paths and has no knowledge about the 935 Association. NAT function applies the same rules in case of 936 collision (see Section 6.3 ) 938 6.6.2. Endpoint Considerations 940 When the Endpoint receives an INIT chunk with RJ option set, it MUST 941 check that the included parameters Internal-Port, Remote-Port, 942 Internal-VTag and Remote-VTag belong to an existing Association, in 943 that case it MUST reply with INIT ACK specifying the existing Remote- 944 VTag, no other actions SHOULD be performed. If the parameters are 945 not identified, the Endpoint SHOULD reply with ABORT. 947 The Endpoint originating INIT chunk with RJ option set can receive 948 different answers: 950 * When receiving INIT ACK, it will check that the Remote-VTag is the 951 same as the Remote-VTag being used for the current Association. 952 In this case the path probing is complete, the NATs on the path 953 are properly set and the Endpoint can continue with the ASCONF 954 procedure. 956 * When receiving as ABORT with M-bit set, it shall assume that a 957 path is not possible to be established. The Endpoint SHOULD retry 958 after a time greather than 4 * HB.interval. 960 * When receiving an ABORT without M-bit set, it shall assume that 961 some temporary NAT configuration has led the INIT towards the 962 wrong SCTP Host. The Endpoint SHOULD retry after a time greather 963 than 4 * HB.interval. 965 * When receiving an INIT ACK with Remote-VTag different from the one 966 used in the current Association, it will send an ABORT message 967 towards the source IP address by specifying the Internal-VTag as 968 well as the Remote-VTag received and wait for ABORT procedure to 969 be completed. Then the Endpoint SHOULD retry after a time 970 greather than 4 * HB.interval. 972 7. Examples of Operation 974 This section describes examples of Association Establishements using 975 the reference scenario depicted in Figure 6. Hosts A1 and A2 976 implement a distributed client towards the same remote Host. Hosts 977 B1 and B2 implement a distributed Endpoint 'B' acting as Server. The 978 Load Balancer functionality is not shown as it doesn't affect SCTP 979 protocol. 981 Internal | External | Internal 982 +------+ +------+ 983 +==|NAT A |==\ /--\/--\ /==|NAT C |==+ 984 +--------+ | +------+ \ / \ / +------+ | +--------+ 985 |Host A1 +---+ | \/ \/ | +-----|Host B1 | 986 | +-+ | | | Network | | | +--+ | 987 +--------+ | | | /\ /\ | | | +--------+ 988 | | +------+ / \ / \ +------+ | | 989 +====|NAT B |==/ \--\/--/ \==|NAT D |=====+ 990 | | +------+ +------+ | | 991 +--------+ | | | | | | +--------+ 992 |Host A2 +-|-+ | | +--|--+Host B2 | 993 | +-+ | | +--+ | 994 +--------+ | | +--------+ 996 Figure 6: Parallel NAT with distributed endpoints Scenario 998 7.1. Single Homed Association Setup 1000 This section describes a successfull Association Establishment from 1001 A1 towards the distributed endpoint B. The sequence chart is shown 1002 in Figure 7. 1004 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1005 | | | | | | | | 1006 +--------------}| INIT | | | | | 1007 | | +----------------------}| | | | 1008 | | | | +----------------------}| | 1009 | | | | | | | | 1010 | | | | |{----------------------+ | 1011 | | |{----------------------+ | | | 1012 |{--------------+ INIT ACK | | | | | 1013 | | | | | | | | 1015 Figure 7: Single Homed successfull Association Setup 1017 7.2. Single Homed Association Setup with Congestion 1019 This section describes a successfull Association Establishment from 1020 A2 towards the distributed endpoint B. The congestion happens at NAT 1021 A. The sequence chart is shown in Figure 8 . 1023 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1024 | | | | | | | | 1025 | +------}| INIT | | | | | 1026 | |{------+ ABORT | | | | | 1027 | | | | | | | | 1028 | +------}| INIT | | | | | 1029 | | +----------------------}| | | | 1030 | | | | +----------------------------}| 1031 | | | | | | | | 1032 | | | | |{----------------------------+ 1033 | | |{----------------------+ | | | 1034 | {-------+ INIT ACK | | | | | 1035 | | | | | | | | 1037 Figure 8: Single Homed successfull Association Setup after congestion 1039 7.3. Multi Homed Association Setup 1041 This section describes how the single homed established at 1042 Section 7.1 becomes multihomed. Success happens at all steps. 1043 Figure 9 . 1045 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1046 | | | | | | | | 1047 +--------------------------}| INIT RJ | | | | 1048 | | | +----------}| | | | 1049 | | | | +----------------------}| | 1050 | | | | |{----------------------+ | 1051 | | | |{----------+ | | | 1052 |{--------------------------+ INIT ACK | | | | 1053 | | | | | | | | 1054 +--------------------------}| ASCONF | | | | 1055 | | | +----------}| | | | 1056 | | | | +----------------------}| | 1057 | | | | |{----------------------+ | 1058 | | | |{----------+ | | | 1059 |{--------------------------+ ASCONF ACK| | | | 1060 | | | | | | | | 1061 | | | | INIT RJ |{----------------------+ | 1062 | | | |{----------+ | | | 1063 |{--------------------------+ | | | | 1064 +--------------------------}| | | | | 1065 | | | +----------}| | | | 1066 | | | | INIT ACK +----------------------}| | 1067 | | | | | | | | 1069 Figure 9: Multi Homed successfull Association Setup 1071 7.4. Multi Homed Association Setup 1073 This section describes how the multihome homed established at 1074 Section 7.3 becomes multihomed from the other peer. Success happens 1075 at all steps. Figure 10 . 1077 A1 A2 NAT A NAT B NAT C NAT D B1 B2 1078 | | | | | | | | 1079 | | | | INIT RJ | |{----------+ | 1080 | | |{----------------------------------+ | | 1081 |{--------------+ | | | | | 1082 +--------------}| | INIT ACK | | | | 1083 | | +----------------------------------}| | | 1084 | | | | | +----------}| | 1085 | | | | INIT RJ | |{----------+ | 1086 | | | |{----------------------+ | | 1087 |{--------------------------+ | | | | 1088 +--------------------------}| INIT ACK | | | | 1089 | | | +----------------------}| | | 1090 | | | | | +----------}| | 1091 | | | | | | | | 1092 | | | | ASCONF | |{----------+ | 1093 | | |{----------------------------------+ | | 1094 |{--------------+ | | | | | 1095 +--------------}| | ASCONF ACK| | | | 1096 | | +----------------------------------}| | | 1097 | | | | | +----------}| | 1098 | | | | | | | | 1099 +--------------}| | INIT RJ | | | | 1100 | | +----------------------------------}| | | 1101 | | | | | +----------}| | 1102 | | | | INIT ACK | |{----------+ | 1103 | | |{----------------------------------+ | | 1104 |{--------------+ | | | | | 1105 | | | | | | | | 1106 +--------------------------}| INIT RJ | | | | 1107 | | | +----------------------}| | | 1108 | | | | | +----------}| | 1109 | | | | INIT ACK | |{----------+ | 1110 | | | |{----------------------+ | | 1111 |{--------------------------+ | | | | 1112 | | | | | | | | 1114 Figure 10: Multi Homed successfull Association Setup 1116 8. IANA Considerations 1118 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1119 you assign this document.] 1121 [NOTE to RFC-Editor: The requested values for the chunk type and the 1122 chunk parameter types are tentative and to be confirmed by IANA.] 1123 This document (RFCXXXX) is the reference for all registrations 1124 described in this section. The requested changes are described 1125 below. 1127 8.1. New Chunk Flags for Two Existing Chunk Types 1129 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1130 for the ERROR chunk. The requested value for the T bit is 0x01 and 1131 for the M bit is 0x02. 1133 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1135 ERROR Chunk Flags 1137 +==================+=================+===========+ 1138 | Chunk Flag Value | Chunk Flag Name | Reference | 1139 +==================+=================+===========+ 1140 | 0x01 | T bit | [RFCXXXX] | 1141 +------------------+-----------------+-----------+ 1142 | 0x02 | M bit | [RFCXXXX] | 1143 +------------------+-----------------+-----------+ 1144 | 0x04 | Unassigned | | 1145 +------------------+-----------------+-----------+ 1146 | 0x08 | Unassigned | | 1147 +------------------+-----------------+-----------+ 1148 | 0x10 | Unassigned | | 1149 +------------------+-----------------+-----------+ 1150 | 0x20 | Unassigned | | 1151 +------------------+-----------------+-----------+ 1152 | 0x40 | Unassigned | | 1153 +------------------+-----------------+-----------+ 1154 | 0x80 | Unassigned | | 1155 +------------------+-----------------+-----------+ 1157 Table 2 1159 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1160 the ABORT chunk. The requested value of the M bit is 0x02. 1162 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1164 ABORT Chunk Flags 1165 +==================+=================+===========+ 1166 | Chunk Flag Value | Chunk Flag Name | Reference | 1167 +==================+=================+===========+ 1168 | 0x01 | T bit | [RFC4960] | 1169 +------------------+-----------------+-----------+ 1170 | 0x02 | M bit | [RFCXXXX] | 1171 +------------------+-----------------+-----------+ 1172 | 0x04 | Unassigned | | 1173 +------------------+-----------------+-----------+ 1174 | 0x08 | Unassigned | | 1175 +------------------+-----------------+-----------+ 1176 | 0x10 | Unassigned | | 1177 +------------------+-----------------+-----------+ 1178 | 0x20 | Unassigned | | 1179 +------------------+-----------------+-----------+ 1180 | 0x40 | Unassigned | | 1181 +------------------+-----------------+-----------+ 1182 | 0x80 | Unassigned | | 1183 +------------------+-----------------+-----------+ 1185 Table 3 1187 8.2. Four New Error Causes 1189 Four error causes have to be assigned by IANA. It is requested to 1190 use the values given below. 1192 This requires Four additional lines in the "Error Cause Codes" 1193 registry for SCTP: 1195 Error Cause Codes 1197 +=======+================================+===========+ 1198 | Value | Cause Code | Reference | 1199 +=======+================================+===========+ 1200 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1201 +-------+--------------------------------+-----------+ 1202 | 177 | Missing State | [RFCXXXX] | 1203 +-------+--------------------------------+-----------+ 1204 | 178 | Port Number Collision | [RFCXXXX] | 1205 +-------+--------------------------------+-----------+ 1206 | 179 | VTag Not Found | [RFCXXXX] | 1207 +-------+--------------------------------+-----------+ 1209 Table 4 1211 8.3. Two New Chunk Parameter Types 1213 Two chunk parameter types have to be assigned by IANA. IANA is 1214 requested to assign these values from the pool of parameters with the 1215 upper two bits set to '11' and to use the values given below. 1217 This requires two additional lines in the "Chunk Parameter Types" 1218 registry for SCTP: 1220 Chunk Parameter Types 1222 +==========+==========================+===========+ 1223 | ID Value | Chunk Parameter Type | Reference | 1224 +==========+==========================+===========+ 1225 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1226 +----------+--------------------------+-----------+ 1227 | 49160 | VTags (0xC008) | [RFCXXXX] | 1228 +----------+--------------------------+-----------+ 1230 Table 5 1232 9. Security Considerations 1234 State maintenance within a NAT function is always a subject of 1235 possible Denial Of Service attacks. This document recommends that at 1236 a minimum a NAT function runs a timer on any SCTP state so that old 1237 association state can be cleaned up. 1239 Generic issues related to address sharing are discussed in [RFC6269] 1240 and apply to SCTP as well. 1242 For SCTP endpoints not disabling the restart procedure, this document 1243 does not add any additional security considerations to the ones given 1244 in [RFC4960] , [RFC4895] , and [RFC5061] . 1246 SCTP endpoints disabling the restart procedure, need to monitor the 1247 status of all associations to mitigate resource exhaustion attacks by 1248 establishing a lot of associations sharing the same IP addresses and 1249 port numbers. 1251 In any case, SCTP is protected by the verification tags and the usage 1252 of [RFC4895] against off-path attackers. 1254 For IP-level fragmentation and reassembly related issues see 1255 [RFC4963] . 1257 The YANG module specified in this document defines a schema for data 1258 that is designed to be accessed via network management protocols such 1259 as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer 1260 is the secure transport layer, and the mandatory-to-implement secure 1261 transport is Secure Shell (SSH) [RFC6242] . The lowest RESTCONF layer 1262 is HTTPS, and the mandatory-to-implement secure transport is TLS 1263 [RFC8446] . 1265 The Network Configuration Access Control Model (NACM) [RFC8341] 1266 provides the means to restrict access for particular NETCONF or 1267 RESTCONF users to a preconfigured subset of all available NETCONF or 1268 RESTCONF protocol operations and content. 1270 All data nodes defined in the YANG module that can be created, 1271 modified, and deleted (i.e., config true, which is the default) are 1272 considered sensitive. Write operations (e.g., edit-config) applied 1273 to these data nodes without proper protection can negatively affect 1274 network operations. An attacker who is able to access the SCTP NAT 1275 function can undertake various attacks, such as: 1277 * Setting a low timeout for SCTP mapping entries to cause failures 1278 to deliver incoming SCTP packets. 1280 * Instantiating mapping entries to cause NAT collision. 1282 10. Normative References 1284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1285 Requirement Levels", BCP 14, RFC 2119, 1286 DOI 10.17487/RFC2119, March 1997, 1287 . 1289 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1290 "Authenticated Chunks for the Stream Control Transmission 1291 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1292 2007, . 1294 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1295 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1296 . 1298 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1299 Kozuka, "Stream Control Transmission Protocol (SCTP) 1300 Dynamic Address Reconfiguration", RFC 5061, 1301 DOI 10.17487/RFC5061, September 2007, 1302 . 1304 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 1305 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 1306 DOI 10.17487/RFC6096, January 2011, 1307 . 1309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1311 May 2017, . 1313 11. Informative References 1315 [DOI_10.1145_1496091.1496095] 1316 Hayes, D., But, J., and G. Armitage, "Issues with network 1317 address translation for SCTP", ACM SIGCOMM Computer 1318 Communication Review Vol. 39, pp. 23-33, 1319 DOI 10.1145/1496091.1496095, December 2008, 1320 . 1322 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1323 RFC 793, DOI 10.17487/RFC0793, September 1981, 1324 . 1326 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1327 Address Translator (Traditional NAT)", RFC 3022, 1328 DOI 10.17487/RFC3022, January 2001, 1329 . 1331 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1332 Translation (NAT) Behavioral Requirements for Unicast 1333 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1334 2007, . 1336 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1337 Errors at High Data Rates", RFC 4963, 1338 DOI 10.17487/RFC4963, July 2007, 1339 . 1341 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1342 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1343 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1344 . 1346 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1347 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1348 DOI 10.17487/RFC5508, April 2009, 1349 . 1351 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1352 Protocol Port Randomization", BCP 156, RFC 6056, 1353 DOI 10.17487/RFC6056, January 2011, 1354 . 1356 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1357 NAT64: Network Address and Protocol Translation from IPv6 1358 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1359 April 2011, . 1361 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1362 and A. Bierman, Ed., "Network Configuration Protocol 1363 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1364 . 1366 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1367 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1368 . 1370 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1371 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1372 DOI 10.17487/RFC6269, June 2011, 1373 . 1375 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1376 Stack Lite Broadband Deployments Following IPv4 1377 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1378 . 1380 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1381 "Special-Purpose IP Address Registries", BCP 153, 1382 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1383 . 1385 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1386 Control Transmission Protocol (SCTP) Packets for End-Host 1387 to End-Host Communication", RFC 6951, 1388 DOI 10.17487/RFC6951, May 2013, 1389 . 1391 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 1392 S., and K. Naito, "Updates to Network Address Translation 1393 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 1394 DOI 10.17487/RFC7857, April 2016, 1395 . 1397 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1398 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1399 . 1401 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1402 Access Control Model", STD 91, RFC 8341, 1403 DOI 10.17487/RFC8341, March 2018, 1404 . 1406 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1407 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1408 . 1410 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1411 and F. Gont, "IP Fragmentation Considered Fragile", 1412 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1413 . 1415 Acknowledgments 1417 The author wishes to thank Michael Tuxen , and Magnus Westerlund for 1418 their invaluable comments. 1420 In addition, the author wishes to thank , for their suggestions. 1422 The author also wishes to thank the authors of draft-ietf-tsvwg- 1423 natsupp-22 which this document is based. 1425 Author's Address 1427 Claudio Porfiri 1428 Ericsson AB 1429 Torshamnsgatan 21 1430 16440 Stockholm 1431 Sweden 1433 Email: claudio.porfiri@ericsson.com