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