idnits 2.17.1 draft-ietf-tsvwg-natsupp-20.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 (28 July 2020) is 1368 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 1941, 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: 29 January 2021 I. Rüngeler 6 Münster Univ. of Appl. Sciences 7 28 July 2020 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-20 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 29 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 . . . . . . . . . . . . . . . . . . . . . . . 50 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 SHOULD 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 SHOULD 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 be able to handle IP-level fragmented 1052 SCTP packets. The fragments may arrive in any order. 1054 When an SCTP packet can not be forwarded by the NAT function due to 1055 MTU issues and the IP header forbids fragmentation, the NAT MUST send 1056 back a "Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message 1057 to the internal host. This allows for a faster recovery from this 1058 packet drop. 1060 6.6. Multi Point Traversal Considerations for Endpoints 1062 If a multi-homed SCTP endpoint behind a NAT function connects to a 1063 peer, it MUST first set up the association single-homed with only one 1064 address causing the first NAT function to populate its state. Then 1065 it SHOULD add each IP address using packets containing ASCONF chunks 1066 sent via their respective NAT functions. The address to add is the 1067 wildcard address and the lookup address SHOULD also contain the VTags 1068 parameter and optionally the Disable Restart parameter. 1070 7. Various Examples of NAT Traversals 1072 Please note that this section is informational only. 1074 The addresses being used in the following examples are IPv4 addresses 1075 for private-use networks and for documentation as specified in 1076 [RFC6890]. However, the method described here is not limited to this 1077 NAT44 case. 1079 The NAT binding table entries shown in the following examples do not 1080 include the flag indicating whether the restart procedure is 1081 supported or not. This flag is not relevant for these examples. 1083 7.1. Single-homed Client to Single-homed Server 1085 The internal client starts the association with the remote server via 1086 a four-way-handshake. Host A starts by sending a packet containing 1087 an INIT chunk. 1089 /--\/--\ 1090 +--------+ +-----+ / \ +--------+ 1091 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1092 +--------+ +-----+ \ / +--------+ 1093 \--/\---/ 1094 +---------+--------+----------+--------+-----------+ 1095 NAT | Int | Int | Rem | Rem | Int | 1096 | VTag | Port | VTag | Port | Addr | 1097 +---------+--------+----------+--------+-----------+ 1099 INIT[Initiate-Tag = 1234] 1100 10.0.0.1:1 ------> 203.0.113.1:2 1101 Rem-VTtag = 0 1103 A NAT binding tabled entry is created, the source address is 1104 substituted and the packet is sent on: 1106 NAT function creates entry: 1107 +---------+--------+----------+--------+-----------+ 1108 NAT | Int | Int | Rem | Rem | Int | 1109 | VTag | Port | VTag | Port | Addr | 1110 +---------+--------+----------+--------+-----------+ 1111 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1112 +---------+--------+----------+--------+-----------+ 1114 INIT[Initiate-Tag = 1234] 1115 192.0.2.1:1 ------------------------> 203.0.113.1:2 1116 Rem-VTtag = 0 1118 Host B receives the packet containing an INIT chunk and sends a 1119 packet containing an INIT ACK chunk with the NAT's Remote-address as 1120 destination address. 1122 /--\/--\ 1123 +--------+ +-----+ / \ +--------+ 1124 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1125 +--------+ +-----+ \ / +--------+ 1126 \--/\---/ 1128 INIT ACK[Initiate-Tag = 5678] 1129 192.0.2.1:1 <----------------------- 203.0.113.1:2 1130 Int-VTag = 1234 1132 NAT function updates entry: 1133 +---------+--------+----------+--------+-----------+ 1134 NAT | Int | Int | Rem | Rem | Int | 1135 | VTag | Port | VTag | Port | Addr | 1136 +---------+--------+----------+--------+-----------+ 1137 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1138 +---------+--------+----------+--------+-----------+ 1140 INIT ACK[Initiate-Tag = 5678] 1141 10.0.0.1:1 <------ 203.0.113.1:2 1142 Int-VTag = 1234 1144 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1145 ACK. 1147 /--\/--\ 1148 +--------+ +-----+ / \ +--------+ 1149 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1150 +--------+ +-----+ \ / +--------+ 1151 \--/\---/ 1153 COOKIE ECHO 1154 10.0.0.1:1 ------> 203.0.113.1:2 1155 Rem-VTag = 5678 1157 COOKIE ECHO 1158 192.0.2.1:1 -----------------------> 203.0.113.1:2 1159 Rem-VTag = 5678 1161 COOKIE ACK 1162 192.0.2.1:1 <----------------------- 203.0.113.1:2 1163 Int-VTag = 1234 1165 COOKIE ACK 1166 10.0.0.1:1 <------ 203.0.113.1:2 1167 Int-VTag = 1234 1169 7.2. Single-homed Client to Multi-homed Server 1171 The internal client is single-homed whereas the remote server is 1172 multi-homed. The client (Host A) sends a packet containing an INIT 1173 chunk like in the single-homed case. 1175 +--------+ 1176 /--\/--\ /-|Router 1| \ 1177 +------+ +-----+ / \ / +--------+ \ +------+ 1178 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1179 | A | +-----+ \ / \ +--------+ / | B | 1180 +------+ \--/\--/ \-|Router 2|-/ +------+ 1181 +--------+ 1183 +---------+--------+----------+--------+-----------+ 1184 NAT | Int | Int | Rem | Rem | Int | 1185 | VTag | Port | VTag | Port | Addr | 1186 +---------+--------+----------+--------+-----------+ 1188 INIT[Initiate-Tag = 1234] 1189 10.0.0.1:1 ---> 203.0.113.1:2 1190 Rem-VTag = 0 1192 NAT function creates entry: 1194 +---------+--------+----------+--------+-----------+ 1195 NAT | Int | Int | Rem | Rem | Int | 1196 | VTag | Port | VTag | Port | Addr | 1197 +---------+--------+----------+--------+-----------+ 1198 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1199 +---------+--------+----------+--------+-----------+ 1201 INIT[Initiate-Tag = 1234] 1202 192.0.2.1:1 --------------------------> 203.0.113.1:2 1203 Rem-VTag = 0 1205 The server (Host B) includes its two addresses in the INIT ACK chunk. 1207 +--------+ 1208 /--\/--\ /-|Router 1| \ 1209 +------+ +-----+ / \ / +--------+ \ +------+ 1210 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1211 | A | +-----+ \ / \ +--------+ / | B | 1212 +------+ \--/\--/ \-|Router 2|-/ +------+ 1213 +--------+ 1215 INIT ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129] 1216 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1217 Int-VTag = 1234 1219 The NAT function does not need to change the NAT binding table for 1220 the second address: 1222 +---------+--------+----------+--------+-----------+ 1223 NAT | Int | Int | Rem | Rem | Int | 1224 | VTag | Port | VTag | Port | Addr | 1225 +---------+--------+----------+--------+-----------+ 1226 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1227 +---------+--------+----------+--------+-----------+ 1229 INIT ACK[Initiate-Tag = 5678] 1230 10.0.0.1:1 <--- 203.0.113.1:2 1231 Int-VTag = 1234 1233 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1234 ACK. 1236 +--------+ 1237 /--\/--\ /-|Router 1| \ 1238 +------+ +-----+ / \ / +--------+ \ +------+ 1239 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1240 | A | +-----+ \ / \ +--------+ / | B | 1241 +------+ \--/\--/ \-|Router 2|-/ +------+ 1242 +--------+ 1244 COOKIE ECHO 1245 10.0.0.1:1 ---> 203.0.113.1:2 1246 Rem-VTag = 5678 1248 COOKIE ECHO 1249 192.0.2.1:1 --------------------------> 203.0.113.1:2 1250 Rem-VTag = 5678 1252 COOKIE ACK 1253 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1254 Int-VTag = 1234 1256 COOKIE ACK 1257 10.0.0.1:1 <--- 203.0.113.1:2 1258 Int-VTag = 1234 1260 7.3. Multihomed Client and Server 1262 The client (Host A) sends a packet containing an INIT chunk to the 1263 server (Host B), but does not include the second address. 1265 +-------+ 1266 /--| NAT 1 |--\ /--\/--\ 1267 +------+ / +-------+ \ / \ +--------+ 1268 | Host |=== ====| Internet |====| Host B | 1269 | A | \ +-------+ / \ / +--------+ 1270 +------+ \--| NAT 2 |--/ \--/\--/ 1271 +-------+ 1273 +---------+--------+----------+--------+-----------+ 1274 NAT 1 | Int | Int | Rem | Rem | Int | 1275 | VTag | Port | VTag | Port | Addr | 1276 +---------+--------+----------+--------+-----------+ 1278 INIT[Initiate-Tag = 1234] 1279 10.0.0.1:1 --------> 203.0.113.1:2 1280 Rem-VTag = 0 1282 NAT function 1 creates entry: 1284 +---------+--------+----------+--------+-----------+ 1285 NAT 1 | Int | Int | Rem | Rem | Int | 1286 | VTag | Port | VTag | Port | Addr | 1287 +---------+--------+----------+--------+-----------+ 1288 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1289 +---------+--------+----------+--------+-----------+ 1291 INIT[Initiate-Tag = 1234] 1292 192.0.2.1:1 ---------------------> 203.0.113.1:2 1293 Rem-VTag = 0 1295 Host B includes its second address in the INIT ACK. 1297 +-------+ 1298 /--------| NAT 1 |--------\ /--\/--\ 1299 +------+ / +-------+ \ / \ +--------+ 1300 | Host |=== ====| Internet |===| Host B | 1301 | A | \ +-------+ / \ / +--------+ 1302 +------+ \--------| NAT 2 |--------/ \--/\--/ 1303 +-------+ 1305 INIT ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129] 1306 192.0.2.1:1 <----------------------- 203.0.113.1:2 1307 Int-VTag = 1234 1309 NAT function 1 does not need to update the NAT binding table for the 1310 second address: 1312 +---------+--------+----------+--------+-----------+ 1313 NAT 1 | Int | Int | Rem | Rem | Int | 1314 | VTag | Port | VTag | Port | Addr | 1315 +---------+--------+----------+--------+-----------+ 1316 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1317 +---------+--------+----------+--------+-----------+ 1319 INIT ACK[Initiate-Tag = 5678] 1320 10.0.0.1:1 <-------- 203.0.113.1:2 1321 Int-VTag = 1234 1323 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1324 ACK. 1326 +-------+ 1327 /--------| NAT 1 |--------\ /--\/--\ 1328 +------+ / +-------+ \ / \ +--------+ 1329 | Host |=== ====| Internet |===| Host B | 1330 | A | \ +-------+ / \ / +--------+ 1331 +------+ \--------| NAT 2 |--------/ \--/\--/ 1332 +-------+ 1334 COOKIE ECHO 1335 10.0.0.1:1 --------> 203.0.113.1:2 1336 Rem-VTag = 5678 1338 COOKIE ECHO 1339 192.0.2.1:1 ------------------> 203.0.113.1:2 1340 Rem-VTag = 5678 1342 COOKIE ACK 1343 192.0.2.1:1 <------------------ 203.0.113.1:2 1344 Int-VTag = 1234 1346 COOKIE ACK 1347 10.0.0.1:1 <------- 203.0.113.1:2 1348 Int-VTag = 1234 1350 Host A announces its second address in an ASCONF chunk. The address 1351 parameter contains an undefined address (0) to indicate that the 1352 source address should be added. The lookup address parameter within 1353 the ASCONF chunk will also contain the pair of VTags (remote and 1354 internal) so that the NAT function may populate its NAT binding table 1355 entry completely with this single packet. 1357 +-------+ 1358 /--------| NAT 1 |--------\ /--\/--\ 1359 +------+ / +-------+ \ / \ +--------+ 1360 | Host |=== ====| Internet |===| Host B | 1361 | A | \ +-------+ / \ / +--------+ 1362 +------+ \--------| NAT 2 |--------/ \--/\--/ 1363 +-------+ 1365 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Rem-VTag = 5678] 1366 10.1.0.1:1 --------> 203.0.113.129:2 1367 Rem-VTag = 5678 1369 NAT function 2 creates a complete entry: 1371 +---------+--------+----------+--------+-----------+ 1372 NAT 2 | Int | Int | Rem | Rem | Int | 1373 | VTag | Port | VTag | Port | Addr | 1374 +---------+--------+----------+--------+-----------+ 1375 | 1234 | 1 | 5678 | 2 | 10.1.0.1 | 1376 +---------+--------+----------+--------+-----------+ 1378 ASCONF [ADD-IP, Int-VTag=1234, Rem-VTag = 5678] 1379 192.0.2.129:1 -------------------> 203.0.113.129:2 1380 Rem-VTag = 5678 1382 ASCONF ACK 1383 192.0.2.129:1 <------------------- 203.0.113.129:2 1384 Int-VTag = 1234 1386 ASCONF ACK 1387 10.1.0.1:1 <----- 203.0.113.129:2 1388 Int-VTag = 1234 1390 7.4. NAT Function Loses Its State 1392 Association is already established between Host A and Host B, when 1393 the NAT function loses its state and obtains a new external address. 1394 Host A sends a DATA chunk to Host B. 1396 /--\/--\ 1397 +--------+ +-----+ / \ +--------+ 1398 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1399 +--------+ +-----+ \ / +--------+ 1400 \--/\--/ 1402 +---------+--------+----------+--------+-----------+ 1403 NAT | Int | Int | Rem | Rem | Int | 1404 | VTag | Port | VTag | Port | Addr | 1405 +---------+--------+----------+--------+-----------+ 1407 DATA 1408 10.0.0.1:1 ----------> 203.0.113.1:2 1409 Rem-VTag = 5678 1411 The NAT function cannot find an entry in the NAT binding table for 1412 the association. It sends a packet containing an ERROR chunk with 1413 the M-Bit set and the cause "NAT state missing". 1415 /--\/--\ 1416 +--------+ +-----+ / \ +--------+ 1417 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1418 +--------+ +-----+ \ / +--------+ 1419 \--/\--/ 1421 ERROR [M-Bit, NAT state missing] 1422 10.0.0.1:1 <---------- 203.0.113.1:2 1423 Rem-VTag = 5678 1425 On reception of the packet containing the ERROR chunk, Host A sends a 1426 packet containing an ASCONF chunk indicating that the former 1427 information has to be deleted and the source address of the actual 1428 packet added. 1430 /--\/--\ 1431 +--------+ +-----+ / \ +--------+ 1432 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1433 +--------+ +-----+ \ / +--------+ 1434 \--/\--/ 1436 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1437 10.0.0.1:1 ----------> 203.0.113.129:2 1438 Rem-VTag = 5678 1440 +---------+--------+----------+--------+-----------+ 1441 NAT | Int | Int | Rem | Rem | Int | 1442 | VTag | Port | VTag | Port | Addr | 1443 +---------+--------+----------+--------+-----------+ 1444 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1445 +---------+--------+----------+--------+-----------+ 1447 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1448 192.0.2.2:1 -----------------> 203.0.113.129:2 1449 Rem-VTag = 5678 1451 Host B adds the new source address to this association and deletes 1452 all other addresses from this association. 1454 /--\/--\ 1455 +--------+ +-----+ / \ +--------+ 1456 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1457 +--------+ +-----+ \ / +--------+ 1458 \--/\--/ 1460 ASCONF ACK 1461 192.0.2.2:1 <----------------- 203.0.113.129:2 1462 Int-VTag = 1234 1464 ASCONF ACK 1465 10.1.0.1:1 <---------- 203.0.113.129:2 1466 Int-VTag = 1234 1468 DATA 1469 10.0.0.1:1 ----------> 203.0.113.1:2 1470 Rem-VTag = 5678 1471 DATA 1472 192.0.2.2:1 -----------------> 203.0.113.129:2 1473 Rem-VTag = 5678 1475 7.5. Peer-to-Peer Communication 1477 If two hosts, each of them behind a NAT function, want to communicate 1478 with each other, they have to get knowledge of the peer's external 1479 address. This can be achieved with a so-called rendezvous server. 1480 Afterwards the destination addresses are external, and the 1481 association is set up with the help of the INIT collision. The NAT 1482 functions create their entries according to their internal peer's 1483 point of view. Therefore, NAT function A's Internal-VTag and 1484 Internal-Port are NAT function B's Remote-VTag and Remote-Port, 1485 respectively. The naming (internal/remote) of the verification tag 1486 in the packet flow is done from the sending host's point of view. 1488 Internal | External External | Internal 1489 | | 1490 | /--\/---\ | 1491 +--------+ +-------+ / \ +-------+ +--------+ 1492 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1493 +--------+ +-------+ \ / +-------+ +--------+ 1494 | \--/\---/ | 1496 NAT Binding Tables 1497 +---------+--------+----------+--------+-----------+ 1498 NAT A | Int | Int | Rem | Rem | Int | 1499 | VTag | Port | VTag | Port | Addr | 1500 +---------+--------+----------+--------+-----------+ 1502 +---------+--------+----------+--------+-----------+ 1503 NAT B | Int | Int | Rem | Rem | Int | 1504 | v-tag | port | v-tag | port | Addr | 1505 +---------+--------+----------+--------+-----------+ 1507 INIT[Initiate-Tag = 1234] 1508 10.0.0.1:1 --> 203.0.113.1:2 1509 Rem-VTag = 0 1511 NAT function A creates entry: 1513 +---------+--------+----------+--------+-----------+ 1514 NAT A | Int | Int | Rem | Rem | Int | 1515 | VTag | Port | VTag | Port | Addr | 1516 +---------+--------+----------+--------+-----------+ 1517 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1518 +---------+--------+----------+--------+-----------+ 1520 INIT[Initiate-Tag = 1234] 1521 192.0.2.1:1 ----------------> 203.0.113.1:2 1522 Rem-VTag = 0 1524 NAT function B processes the packet containing the INIT chunk, but 1525 cannot find an entry. The SCTP packet is silently discarded and 1526 leaves the NAT binding table of NAT function B unchanged. 1528 +---------+--------+----------+--------+-----------+ 1529 NAT B | Int | Int | Rem | Rem | Int | 1530 | VTag | Port | VTag | Port | Addr | 1531 +---------+--------+----------+--------+-----------+ 1533 Now Host B sends a packet containing an INIT chunk, which is 1534 processed by NAT function B. Its parameters are used to create an 1535 entry. 1537 Internal | External External | Internal 1538 | | 1539 | /--\/---\ | 1540 +--------+ +-------+ / \ +-------+ +--------+ 1541 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1542 +--------+ +-------+ \ / +-------+ +--------+ 1543 | \--/\---/ | 1545 INIT[Initiate-Tag = 5678] 1546 192.0.2.1:1 <-- 10.1.0.1:2 1547 Rem-VTag = 0 1549 +---------+--------+----------+--------+-----------+ 1550 NAT B | Int | Int | Rem | Rem | Int | 1551 | VTag | Port | VTag | Port | Addr | 1552 +---------+--------+----------+--------+-----------+ 1553 | 5678 | 2 | 0 | 1 | 10.1.0.1 | 1554 +---------+--------+----------+--------+-----------+ 1556 INIT[Initiate-Tag = 5678] 1557 192.0.2.1:1 <--------------- 203.0.113.1:2 1558 Rem-VTag = 0 1560 NAT function A processes the packet containing the INIT chunk. As 1561 the outgoing packet containing an INIT chunk of Host A has already 1562 created an entry, the entry is found and updated: 1564 Internal | External External | Internal 1565 | | 1566 | /--\/---\ | 1567 +--------+ +-------+ / \ +-------+ +--------+ 1568 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1569 +--------+ +-------+ \ / +-------+ +--------+ 1570 | \--/\---/ | 1572 VTag != Int-VTag, but Rem-VTag == 0, find entry. 1573 +---------+--------+----------+--------+-----------+ 1574 NAT A | Int | Int | Rem | Rem | Int | 1575 | VTag | Port | VTag | Port | Addr | 1576 +---------+--------+----------+--------+-----------+ 1577 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1578 +---------+--------+----------+--------+-----------+ 1580 INIT[Initiate-tag = 5678] 1581 10.0.0.1:1 <-- 203.0.113.1:2 1582 Rem-VTag = 0 1584 Host A sends a packet containing an INIT ACK chunk, which can pass 1585 through NAT function B: 1587 Internal | External External | Internal 1588 | | 1589 | /--\/---\ | 1590 +--------+ +-------+ / \ +-------+ +--------+ 1591 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1592 +--------+ +-------+ \ / +-------+ +--------+ 1593 | \--/\---/ | 1595 INIT ACK[Initiate-Tag = 1234] 1596 10.0.0.1:1 --> 203.0.113.1:2 1597 Rem-VTag = 5678 1599 INIT ACK[Initiate-Tag = 1234] 1600 192.0.2.1:1 ----------------> 203.0.113.1:2 1601 Rem-VTag = 5678 1603 NAT function B updates entry: 1605 +---------+--------+----------+--------+-----------+ 1606 NAT B | Int | Int | Rem | Rem | Int | 1607 | VTag | Port | VTag | Port | Addr | 1608 +---------+--------+----------+--------+-----------+ 1609 | 5678 | 2 | 1234 | 1 | 10.1.0.1 | 1610 +---------+--------+----------+--------+-----------+ 1612 INIT ACK[Initiate-Tag = 1234] 1613 192.0.2.1:1 --> 10.1.0.1:2 1614 Rem-VTag = 5678 1616 The lookup for COOKIE ECHO and COOKIE ACK is successful. 1618 Internal | External External | Internal 1619 | | 1620 | /--\/---\ | 1621 +--------+ +-------+ / \ +-------+ +--------+ 1622 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1623 +--------+ +-------+ \ / +-------+ +--------+ 1624 | \--/\---/ | 1626 COOKIE ECHO 1627 192.0.2.1:1 <-- 10.1.0.1:2 1628 Rem-VTag = 1234 1630 COOKIE ECHO 1631 192.0.2.1:1 <------------- 203.0.113.1:2 1632 Rem-VTag = 1234 1634 COOKIE ECHO 1635 10.0.0.1:1 <-- 203.0.113.1:2 1636 Rem-VTag = 1234 1638 COOKIE ACK 1639 10.0.0.1:1 --> 203.0.113.1:2 1640 Rem-VTag = 5678 1642 COOKIE ACK 1643 192.0.2.1:1 ----------------> 203.0.113.1:2 1644 Rem-VTag = 5678 1646 COOKIE ACK 1647 192.0.2.1:1 --> 10.1.0.1:2 1648 Rem-VTag = 5678 1650 8. SCTP NAT YANG Module 1652 This section defines a YANG module for SCTP NAT. 1654 The terminology for describing YANG data models is defined in 1655 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 1656 [RFC8340]. 1658 8.1. Tree Structure 1660 This module augments NAT YANG module [RFC8512] with SCTP specifics. 1661 The module supports both classical SCTP NAT (that is, rewrite port 1662 numbers) and SCTP-specific variant where the ports numbers are not 1663 altered. The YANG "feature" is used to indicate whether SCTP- 1664 specific variant is supported. 1666 The tree structure of the SCTP NAT YANG module is provided below: 1668 module: ietf-nat-sctp 1669 augment /nat:nat/nat:instances/nat:instance 1670 /nat:policy/nat:timers: 1671 +--rw sctp-timeout? uint32 1672 augment /nat:nat/nat:instances/nat:instance 1673 /nat:mapping-table/nat:mapping-entry: 1674 +--rw int-VTag? uint32 {sctp-nat}? 1675 +--rw rem-VTag? uint32 {sctp-nat}? 1677 Concretely, the SCTP NAT YANG module augments the NAT YANG module 1678 (policy, in particular) with the following: 1680 * The sctp-timeout is used to control the SCTP inactivity timeout. 1681 That is, the time an SCTP mapping will stay active without SCTP 1682 packets traversing the NAT. This timeout can be set only for 1683 SCTP. Hence, "/nat:nat/nat:instances/nat:instance/nat:policy/ 1684 nat:transport-protocols/nat:protocol-id" MUST be set to '132' 1685 (SCTP). 1687 In addition, the SCTP NAT YANG module augments the mapping entry with 1688 the following parameters defined in Section 3. These parameters 1689 apply only for SCTP NAT mapping entries (i.e., 1690 "/nat/instances/instance/mapping-table/mapping-entry/transport- 1691 protocol" MUST be set to '132'); 1693 * The Internal Verification Tag (Int-VTag) 1695 * The Remote Verification Tag (Rem-VTag) 1697 8.2. YANG Module 1699 file "ietf-nat-sctp@2020-07-13.yang" 1700 module ietf-nat-sctp { 1701 yang-version 1.1; 1702 namespace "urn:ietf:params:xml:ns:yang:ietf-nat-sctp"; 1703 prefix nat-sctp; 1705 import ietf-nat { 1706 prefix nat; 1707 reference 1708 "RFC 8512: A YANG Module for Network Address Translation 1709 (NAT) and Network Prefix Translation (NPT)"; 1710 } 1712 organization 1713 "IETF TSVWG Working Group"; 1715 contact 1716 "WG Web: 1717 WG List: 1719 Author: Mohamed Boucadair 1720 "; 1721 description 1722 "This module augments NAT YANG module with Stream Control 1723 Transmission Protocol (SCTP) specifics. The extension supports 1724 both a classical SCTP NAT (that is, rewrite port numbers) 1725 and a, SCTP-specific variant where the ports numbers are 1726 not altered. 1728 Copyright (c) 2020 IETF Trust and the persons identified as 1729 authors of the code. All rights reserved. 1731 Redistribution and use in source and binary forms, with or 1732 without modification, is permitted pursuant to, and subject 1733 to the license terms contained in, the Simplified BSD License 1734 set forth in Section 4.c of the IETF Trust's Legal Provisions 1735 Relating to IETF Documents 1736 (http://trustee.ietf.org/license-info). 1738 This version of this YANG module is part of RFC XXXX; see 1739 the RFC itself for full legal notices."; 1741 revision 2019-11-18 { 1742 description 1743 "Initial revision."; 1744 reference 1745 "RFC XXXX: Stream Control Transmission Protocol (SCTP) 1746 Network Address Translation Support"; 1747 } 1749 feature sctp-nat { 1750 description 1751 "This feature means that SCTP-specific variant of NAT 1752 is supported. That is, avoid rewriting port numbers."; 1753 reference 1754 "Section 4.3 of RFC XXXX."; 1755 } 1757 augment "/nat:nat/nat:instances/nat:instance" 1758 + "/nat:policy/nat:timers" { 1759 when "/nat:nat/nat:instances/nat:instance" 1760 + "/nat:policy/nat:transport-protocols" 1761 + "/nat:protocol-id = 132"; 1762 description 1763 "Extends NAT policy with a timeout for SCTP mapping 1764 entries."; 1766 leaf sctp-timeout { 1767 type uint32; 1768 units "seconds"; 1769 description 1770 "SCTP inactivity timeout. That is, the time an SCTP 1771 mapping entry will stay active without packets 1772 traversing the NAT."; 1773 } 1774 } 1776 augment "/nat:nat/nat:instances/nat:instance" 1777 + "/nat:mapping-table/nat:mapping-entry" { 1778 when "nat:transport-protocol = 132"; 1779 if-feature "sctp-nat"; 1780 description 1781 "Extends the mapping entry with SCTP specifics."; 1783 leaf int-VTag { 1784 type uint32; 1785 description 1786 "The Internal Verification Tag that the internal 1787 host has chosen for this communication."; 1788 } 1789 leaf rem-VTag { 1790 type uint32; 1791 description 1792 "The Remote Verification Tag that the remote 1793 peer has chosen for this communication."; 1794 } 1795 } 1796 } 1797 1799 9. Socket API Considerations 1801 This section describes how the socket API defined in [RFC6458] is 1802 extended to provide a way for the application to control NAT 1803 friendliness. 1805 Please note that this section is informational only. 1807 A socket API implementation based on [RFC6458] is extended by 1808 supporting one new read/write socket option. 1810 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 1812 This socket option uses the option_level IPPROTO_SCTP and the 1813 option_name SCTP_NAT_FRIENDLY. It can be used to enable/disable the 1814 NAT friendliness for future associations and retrieve the value for 1815 future and specific ones. 1817 struct sctp_assoc_value { 1818 sctp_assoc_t assoc_id; 1819 uint32_t assoc_value; 1820 }; 1822 assoc_id 1823 This parameter is ignored for one-to-one style sockets. For one- 1824 to-many style sockets the application may fill in an association 1825 identifier or SCTP_FUTURE_ASSOC for this query. It is an error to 1826 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 1828 assoc_value 1829 A non-zero value indicates a NAT-friendly mode. 1831 10. IANA Considerations 1833 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1834 you assign this document.] 1836 [NOTE to RFC-Editor: The requested values for the chunk type and the 1837 chunk parameter types are tentative and to be confirmed by IANA.] 1839 This document (RFCXXXX) is the reference for all registrations 1840 described in this section. The requested changes are described 1841 below. 1843 10.1. New Chunk Flags for Two Existing Chunk Types 1845 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1846 for the ERROR chunk. The requested value for the T bit is 0x01 and 1847 for the M bit is 0x02. 1849 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1851 ERROR Chunk Flags 1852 +==================+=================+===========+ 1853 | Chunk Flag Value | Chunk Flag Name | Reference | 1854 +==================+=================+===========+ 1855 | 0x01 | T bit | [RFCXXXX] | 1856 +------------------+-----------------+-----------+ 1857 | 0x02 | M bit | [RFCXXXX] | 1858 +------------------+-----------------+-----------+ 1859 | 0x04 | Unassigned | | 1860 +------------------+-----------------+-----------+ 1861 | 0x08 | Unassigned | | 1862 +------------------+-----------------+-----------+ 1863 | 0x10 | Unassigned | | 1864 +------------------+-----------------+-----------+ 1865 | 0x20 | Unassigned | | 1866 +------------------+-----------------+-----------+ 1867 | 0x40 | Unassigned | | 1868 +------------------+-----------------+-----------+ 1869 | 0x80 | Unassigned | | 1870 +------------------+-----------------+-----------+ 1872 Table 2 1874 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1875 the ABORT chunk. The requested value of the M bit is 0x02. 1877 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1879 ABORT Chunk Flags 1880 +==================+=================+===========+ 1881 | Chunk Flag Value | Chunk Flag Name | Reference | 1882 +==================+=================+===========+ 1883 | 0x01 | T bit | [RFC4960] | 1884 +------------------+-----------------+-----------+ 1885 | 0x02 | M bit | [RFCXXXX] | 1886 +------------------+-----------------+-----------+ 1887 | 0x04 | Unassigned | | 1888 +------------------+-----------------+-----------+ 1889 | 0x08 | Unassigned | | 1890 +------------------+-----------------+-----------+ 1891 | 0x10 | Unassigned | | 1892 +------------------+-----------------+-----------+ 1893 | 0x20 | Unassigned | | 1894 +------------------+-----------------+-----------+ 1895 | 0x40 | Unassigned | | 1896 +------------------+-----------------+-----------+ 1897 | 0x80 | Unassigned | | 1898 +------------------+-----------------+-----------+ 1900 Table 3 1902 10.2. Three New Error Causes 1904 Three error causes have to be assigned by IANA. It is requested to 1905 use the values given below. 1907 This requires three additional lines in the "Error Cause Codes" 1908 registry for SCTP: 1910 Error Cause Codes 1912 +=======+================================+===========+ 1913 | Value | Cause Code | Reference | 1914 +=======+================================+===========+ 1915 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1916 +-------+--------------------------------+-----------+ 1917 | 177 | Missing State | [RFCXXXX] | 1918 +-------+--------------------------------+-----------+ 1919 | 178 | Port Number Collision | [RFCXXXX] | 1920 +-------+--------------------------------+-----------+ 1922 Table 4 1924 10.3. Two New Chunk Parameter Types 1926 Two chunk parameter types have to be assigned by IANA. It is 1927 requested to use the values given below. IANA should assign these 1928 values from the pool of parameters with the upper two bits set to 1929 '11'. 1931 This requires two additional lines in the "Chunk Parameter Types" 1932 registry for SCTP: 1934 Chunk Parameter Types 1936 +==========+==========================+===========+ 1937 | ID Value | Chunk Parameter Type | Reference | 1938 +==========+==========================+===========+ 1939 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1940 +----------+--------------------------+-----------+ 1941 | 49160 | VTags (0xC008) | [RFCXXXX] | 1942 +----------+--------------------------+-----------+ 1944 Table 5 1946 10.4. One New URI 1948 An URI in the "ns" subregistry within the "IETF XML" registry has to 1949 be assigned by IANA ([RFC3688]): 1951 URI: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1952 Registrant Contact: The IESG. 1953 XML: N/A; the requested URI is an XML namespace. 1955 10.5. One New YANG Module 1957 An YANG module in the "YANG Module Names" subregistry within the 1958 "YANG Parameters" registry has to be assigned by IANA ([RFC6020]): 1960 Name: ietf-nat-sctp 1961 Namespace: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1962 Maintained by IANA: N 1963 Prefix: nat-sctp 1964 Reference: RFCXXXX 1966 11. Security Considerations 1968 State maintenance within a NAT function is always a subject of 1969 possible Denial Of Service attacks. This document recommends that at 1970 a minimum a NAT function runs a timer on any SCTP state so that old 1971 association state can be cleaned up. 1973 Generic issues related to address sharing are discussed in [RFC6269] 1974 and apply to SCTP as well. 1976 For SCTP endpoints not disabling the restart procedure, this document 1977 does not add any additional security considerations to the ones given 1978 in [RFC4960], [RFC4895], and [RFC5061]. 1980 SCTP endpoints disabling the restart procedure, should monitor the 1981 status of all associations to mitigate resource exhaustion attacks by 1982 establishing a lot of associations sharing the same IP addresses and 1983 port numbers. 1985 In any case, SCTP is protected by the verification tags and the usage 1986 of [RFC4895] against off-path attackers. 1988 For IP-level fragmentation and reassembly related issues see 1989 [RFC4963]. 1991 The YANG module specified in this document defines a schema for data 1992 that is designed to be accessed via network management protocols such 1993 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1994 is the secure transport layer, and the mandatory-to-implement secure 1995 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1996 is HTTPS, and the mandatory-to-implement secure transport is TLS 1997 [RFC8446]. 1999 The Network Configuration Access Control Model (NACM) [RFC8341] 2000 provides the means to restrict access for particular NETCONF or 2001 RESTCONF users to a preconfigured subset of all available NETCONF or 2002 RESTCONF protocol operations and content. 2004 All data nodes defined in the YANG module that can be created, 2005 modified, and deleted (i.e., config true, which is the default) are 2006 considered sensitive. Write operations (e.g., edit-config) applied 2007 to these data nodes without proper protection can negatively affect 2008 network operations. An attacker who is able to access the SCTP NAT 2009 function can undertake various attacks, such as: 2011 * Setting a low timeout for SCTP mapping entries to cause failures 2012 to deliver incoming SCTP packets. 2014 * Instantiating mapping entries to cause NAT collision. 2016 12. Normative References 2018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2019 Requirement Levels", BCP 14, RFC 2119, 2020 DOI 10.17487/RFC2119, March 1997, 2021 . 2023 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2024 DOI 10.17487/RFC3688, January 2004, 2025 . 2027 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 2028 "Authenticated Chunks for the Stream Control Transmission 2029 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2030 2007, . 2032 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2033 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2034 . 2036 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2037 Kozuka, "Stream Control Transmission Protocol (SCTP) 2038 Dynamic Address Reconfiguration", RFC 5061, 2039 DOI 10.17487/RFC5061, September 2007, 2040 . 2042 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2043 the Network Configuration Protocol (NETCONF)", RFC 6020, 2044 DOI 10.17487/RFC6020, October 2010, 2045 . 2047 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 2048 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 2049 DOI 10.17487/RFC6096, January 2011, 2050 . 2052 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2053 and A. Bierman, Ed., "Network Configuration Protocol 2054 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2055 . 2057 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2058 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2059 . 2061 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2062 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2063 . 2065 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2066 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2067 May 2017, . 2069 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2070 Access Control Model", STD 91, RFC 8341, 2071 DOI 10.17487/RFC8341, March 2018, 2072 . 2074 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2075 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2076 . 2078 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 2079 Vinapamula, S., and Q. Wu, "A YANG Module for Network 2080 Address Translation (NAT) and Network Prefix Translation 2081 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 2082 . 2084 13. Informative References 2086 [DOI_10.1145_1496091.1496095] 2087 Hayes, D., But, J., and G. Armitage, "Issues with network 2088 address translation for SCTP", ACM SIGCOMM Computer 2089 Communication Review Vol. 39, pp. 23-33, 2090 DOI 10.1145/1496091.1496095, December 2008, 2091 . 2093 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2094 RFC 793, DOI 10.17487/RFC0793, September 1981, 2095 . 2097 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2098 Address Translator (Traditional NAT)", RFC 3022, 2099 DOI 10.17487/RFC3022, January 2001, 2100 . 2102 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2103 Errors at High Data Rates", RFC 4963, 2104 DOI 10.17487/RFC4963, July 2007, 2105 . 2107 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2108 NAT64: Network Address and Protocol Translation from IPv6 2109 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2110 April 2011, . 2112 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2113 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2114 DOI 10.17487/RFC6269, June 2011, 2115 . 2117 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2118 Stack Lite Broadband Deployments Following IPv4 2119 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2120 . 2122 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2123 Yasevich, "Sockets API Extensions for the Stream Control 2124 Transmission Protocol (SCTP)", RFC 6458, 2125 DOI 10.17487/RFC6458, December 2011, 2126 . 2128 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 2129 "Special-Purpose IP Address Registries", BCP 153, 2130 RFC 6890, DOI 10.17487/RFC6890, April 2013, 2131 . 2133 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2134 Control Transmission Protocol (SCTP) Packets for End-Host 2135 to End-Host Communication", RFC 6951, 2136 DOI 10.17487/RFC6951, May 2013, 2137 . 2139 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2140 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2141 . 2143 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2144 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2145 . 2147 Acknowledgments 2149 The authors wish to thank Mohamed Boucadair, Gorry Fairhurst, Bryan 2150 Ford, David Hayes, Alfred Hines, Karen E. E. Nielsen, Henning 2151 Peters, Maksim Proshin, Timo Voelker, Dan Wing, and Qiaobing Xie for 2152 their invaluable comments. 2154 In addition, the authors wish to thank David Hayes, Jason But, and 2155 Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for 2156 their suggestions. 2158 The authors also wish to thank Mohamed Boucadair for contributing the 2159 text related to the YANG module. 2161 Authors' Addresses 2163 Randall R. Stewart 2164 Netflix, Inc. 2165 Chapin, SC 29036 2166 United States of America 2168 Email: randall@lakerest.net 2170 Michael Tüxen 2171 Münster University of Applied Sciences 2172 Stegerwaldstrasse 39 2173 48565 Steinfurt 2174 Germany 2176 Email: tuexen@fh-muenster.de 2178 Irene Rüngeler 2179 Münster University of Applied Sciences 2180 Stegerwaldstrasse 39 2181 48565 Steinfurt 2182 Germany 2184 Email: i.ruengeler@fh-muenster.de