idnits 2.17.1 draft-ietf-tsvwg-natsupp-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (9 March 2020) is 1509 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 479, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1887, 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 (~~), 4 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. Tuexen 5 Expires: 10 September 2020 I. Ruengeler 6 Muenster Univ. of Appl. Sciences 7 9 March 2020 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-16 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 for TCP that allows multiple hosts to reside behind 20 a NAT and yet share a single IPv4 address, even when two hosts 21 (behind a NAT) choose the same port numbers for their connection. 22 This additional code is sometimes classified as Network Address and 23 Port Translation (NAPT). 25 This document describes the protocol extensions required for the SCTP 26 endpoints and the mechanisms for NAT devices 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 10 September 2020. 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 . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 15 83 5.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 16 84 5.3.2. VTags Parameter . . . . . . . . . . . . . . . . . . . 16 85 6. Procedures for SCTP Endpoints and NAT Devices . . . . . . . . 17 86 6.1. Association Setup Considerations for Endpoints . . . . . 18 87 6.2. Handling of Internal Port Number and Verification Tag 88 Collisions . . . . . . . . . . . . . . . . . . . . . . . 18 89 6.2.1. NAT Device Considerations . . . . . . . . . . . . . . 19 90 6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 19 91 6.3. Handling of Internal Port Number Collisions . . . . . . . 19 92 6.3.1. NAT Device Considerations . . . . . . . . . . . . . . 20 93 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 94 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 95 6.4.1. NAT Device Considerations . . . . . . . . . . . . . . 21 96 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 98 6.5. Handling of Fragmented SCTP Packets by NAT Devices . . . 22 99 6.6. Multi Point Traversal Considerations for Endpoints . . . 23 100 7. Various Examples of NAT Traversals . . . . . . . . . . . . . 23 101 7.1. Single-homed Client to Single-homed Server . . . . . . . 23 102 7.2. Single-homed Client to Multi-homed Server . . . . . . . . 25 103 7.3. Multihomed Client and Server . . . . . . . . . . . . . . 27 104 7.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 30 105 7.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . 32 106 8. SCTP NAT YANG Module . . . . . . . . . . . . . . . . . . . . 36 107 8.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 36 108 8.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 37 109 9. Socket API Considerations . . . . . . . . . . . . . . . . . . 39 110 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 40 111 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 112 10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 40 113 10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 42 114 10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 43 115 10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 43 116 10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 43 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 118 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 119 13. Normative References . . . . . . . . . . . . . . . . . . . . 44 120 14. Informative References . . . . . . . . . . . . . . . . . . . 46 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 123 1. Introduction 125 Stream Control Transmission Protocol [RFC4960] provides a reliable 126 communications channel between two end-hosts in many ways similar to 127 TCP [RFC0793]. With the widespread deployment of Network Address 128 Translators (NAT), specialized code has been added to NAT for TCP 129 that allows multiple hosts to reside behind a NAT using private 130 addresses (see [RFC6890]) and yet share single IPv4 address, even 131 when two hosts (behind a NAT) choose the same port numbers for their 132 connection. This additional code is sometimes classified as Network 133 Address and Port Translation (NAPT). Please note that this document 134 focuses on the case where the NAT maps a single or multiple private 135 addresses to a single public address and vice versa. To date, 136 specialized code for SCTP has not yet been added to most NAT devices 137 so that only a translation of IP addresses is supported. The end 138 result of this is that only one SCTP-capable host can successfully 139 operate behind such a NAT and this host can only be single-homed. 140 The only alternative for supporting legacy NAT devices is to use UDP 141 encapsulation as specified in [RFC6951]. 143 This document specifies procedures allowing a NAT to support SCTP by 144 providing similar features to those provided by a NAPT for TCP and 145 other supported protocols. The document also specifies a set of data 146 formats for SCTP packets and a set of SCTP endpoint procedures to 147 support NAT traversal. An SCTP implementation supporting these 148 procedures can assure that in both single-homed and multi-homed cases 149 a NAT will maintain the appropriate state without the NAT needing to 150 change port numbers. 152 It is possible and desirable to make these changes for a number of 153 reasons: 155 * It is desirable for SCTP internal end-hosts on multiple platforms 156 to be able to share a NAT's public IP address in the same way that 157 a TCP session can use a NAT. 159 * If a NAT does not need to change any data within an SCTP packet it 160 will reduce the processing burden of NAT'ing SCTP by not needing 161 to execute the CRC32c checksum required by SCTP. 163 * Not having to touch the IP payload makes the processing of ICMP 164 messages in NAT devices easier. 166 An SCTP-aware NAT will need to follow these procedures for generating 167 appropriate SCTP packet formats. 169 When considering this feature it is possible to have multiple levels 170 of support. At each level, the Internal Host, External Host and NAT 171 may or may not support the features described in this document. The 172 following table illustrates the results of the various combinations 173 of support and if communications can occur between two endpoints. 175 +---------------+------------+---------------+---------------+ 176 | Internal Host | NAT Device | External Host | Communication | 177 +===============+============+===============+===============+ 178 | Support | Support | Support | Yes | 179 +---------------+------------+---------------+---------------+ 180 | Support | Support | No Support | Limited | 181 +---------------+------------+---------------+---------------+ 182 | Support | No Support | Support | None | 183 +---------------+------------+---------------+---------------+ 184 | Support | No Support | No Support | None | 185 +---------------+------------+---------------+---------------+ 186 | No Support | Support | Support | Limited | 187 +---------------+------------+---------------+---------------+ 188 | No Support | Support | No Support | Limited | 189 +---------------+------------+---------------+---------------+ 190 | No Support | No Support | Support | None | 191 +---------------+------------+---------------+---------------+ 192 | No Support | No Support | No Support | None | 193 +---------------+------------+---------------+---------------+ 195 Table 1: Communication possibilities 197 From the table it can be seen that when a NAT device does not support 198 the extension no communication can occur. This assumes that the NAT 199 device does not handle SCTP packets at all and all SCTP packets sent 200 externally from behind a NAT device are discarded by the NAT. In 201 some cases, where the NAT device supports the feature but one of the 202 two hosts does not support the feature, communication may occur but 203 in a limited way. For example only one host may be able to have a 204 connection when a collision case occurs. 206 2. Conventions 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in BCP 211 14 [RFC2119] [RFC8174] when, and only when, they appear in all 212 capitals, as shown here. 214 3. Terminology 216 This document uses the following terms, which are depicted in 217 Figure 1. Familiarity with the terminology used in [RFC4960] and 218 [RFC5061] is assumed. 220 Private-Address (Priv-Addr) The private address that is known to the 221 internal host. 223 Internal-Port (Int-Port) The port number that is in use by the host 224 holding the Private-Address. 226 Internal-VTag (Int-VTag) The SCTP Verification Tag (VTag) (see 227 Section 3.1 of [RFC4960]) that the internal host has chosen for 228 its communication. The VTag is a unique 32-bit tag that must 229 accompany any incoming SCTP packet for this association to the 230 Private-Address. 232 External-Address (Ext-Addr) The address that an internal host is 233 attempting to contact. 235 External-Port (Ext-Port) The port number of the peer process at the 236 External-Address. 238 External-VTag (Ext-VTag) The Verification Tag that the host holding 239 the External-Address has chosen for its communication. The VTag 240 is a unique 32-bit tag that must accompany any incoming SCTP 241 packet for this association to the External-Address. 243 Public-Address (Pub-Addr) The public address assigned to the NAT 244 device that it uses as a source address when sending packets 245 towards the External-Address. 247 Internal Network | External Network 248 | 249 Private | Public External 250 +--------+ Address | Address /--\/--\ Address +--------+ 251 | SCTP | +-----+ / \ | SCTP | 252 |endpoint|=========| NAT |=======| Internet |==========|endpoint| 253 | A | +-----+ \ / | B | 254 +--------+ Internal | \--/\--/ External+--------+ 255 Internal Port | Port External 256 VTag | VTag 258 Figure 1: Basic network setup 260 4. Motivation 262 4.1. SCTP NAT Traversal Scenarios 264 This section defines the notion of single and multi point NAT 265 traversal. 267 4.1.1. Single Point Traversal 269 In this case, all packets in the SCTP association go through a single 270 NAT, as shown below: 272 Internal Network | External Network 273 | 274 +--------+ | /--\/--\ +--------+ 275 | SCTP | +-----+ / \ | SCTP | 276 |endpoint|=========| NAT |========= | Internet | ========|endpoint| 277 | A | +-----+ \ / | B | 278 +--------+ | \--/\--/ +--------+ 279 | 281 Figure 2: Single NAT scenario 283 A variation of this case is shown below, i.e., multiple NAT devices 284 in a single path: 286 Internal | External : Internal | External 287 | : | 288 +--------+ | : | /--\/--\ +--------+ 289 | SCTP | +-----+ : +-----+ / \ | SCTP | 290 |endpoint|==| NAT |=======:=======| NAT |==| Internet |==|endpoint| 291 | A | +-----+ : +-----+ \ / | B | 292 +--------+ | : | \--/\--/ +--------+ 293 | : | 295 Figure 3: Serial NAT Devices scenario 297 Although one of the main benefits of SCTP multi-homing is redundant 298 paths, in the single point traversal scenario the NAT function 299 represents a single point of failure in the path of the SCTP multi- 300 homed association. However, the rest of the path may still benefit 301 from path diversity provided by SCTP multi-homing. 303 The two SCTP endpoints in this case can be either single-homed or 304 multi-homed. However, the important thing is that the NAT device (or 305 NAT devices) in this case sees all the packets of the SCTP 306 association. 308 4.1.2. Multi Point Traversal 310 This case involves multiple NAT devices and each NAT device only sees 311 some of the packets in the SCTP association. An example is shown 312 below: 314 Internal | External 315 +------+ /---\/---\ 316 +--------+ /=======|NAT A |=========\ / \ +--------+ 317 | SCTP | / +------+ \/ \ | SCTP | 318 |endpoint|/ ... | Internet |===|endpoint| 319 | A |\ \ / | B | 320 +--------+ \ +------+ / \ / +--------+ 321 \=======|NAT B |=========/ \---\/---/ 322 +------+ 323 | 325 Figure 4: Parallel NAT devices scenario 327 This case does not apply to a single-homed SCTP association (i.e., 328 both endpoints in the association use only one IP address). The 329 advantage here is that the existence of multiple NAT traversal points 330 can preserve the path diversity of a multi-homed association for the 331 entire path. This in turn can improve the robustness of the 332 communication. 334 4.2. Limitations of Classical NAPT for SCTP 336 Using classical NAPT may result in changing one of the SCTP port 337 numbers during the processing which requires the recomputation of the 338 transport layer checksum by the NAPT device. Whereas for UDP and TCP 339 this can be done very efficiently, for SCTP the checksum (CRC32c) 340 over the entire packet needs to be recomputed. See Appendix B of 341 [RFC4960] for details of the CRC32c computation. This would 342 considerably add to the NAT computational burden, however hardware 343 support may mitigate this in some implementations. 345 An SCTP endpoint may have multiple addresses but only has a single 346 port number. To make multipoint traversal work, all the NAT devices 347 involved must recognize the packets they see as belonging to the same 348 SCTP association and perform port number translation in a consistent 349 way. One possible way of doing this is to use a pre-defined table of 350 ports and addresses configured within each NAT. Other mechanisms 351 could make use of NAT to NAT communication. Such mechanisms have not 352 been deployed on a wide scale base and thus are not a recommended 353 solution. Therefore an SCTP variant of NAT has been developed. 355 4.3. The SCTP-Specific Variant of NAT 357 In this section it is allowed that there are multiple SCTP capable 358 hosts behind a NAT that has one Public-Address. Furthermore this 359 section focuses on the single point traversal scenario. 361 The modification of SCTP packets sent to the Internet is simple: the 362 source address of the packet has to be replaced with the Public- 363 Address. It may also be necessary to establish some state in the NAT 364 device to later handle incoming packets. 366 For the SCTP NAT processing the NAT device has to maintain a NAT 367 binding table of Internal-VTag, Internal-Port, External-VTag, 368 External-Port, Private-Address, and whether the restart procedure is 369 disabled or not. An entry in that NAT binding table is called a NAT 370 state control block. The function Create() obtains the just 371 mentioned parameters and returns a NAT-State control block. A NAT 372 device MAY allow creating NAT-State control blocks via a management 373 interface. 375 For SCTP packets coming from the public Internet the destination 376 address of the packets has to be replaced with the Private-Address of 377 the host the packet has to be delivered to. The lookup of the 378 Private-Address is based on the External-VTag, External-Port, 379 Internal-VTag and the Internal-Port. 381 The entries in the NAT binding table need to fulfill some uniqueness 382 conditions. There must not be more than one entry NAT binding table 383 with the same pair of Internal-Port and External-Port. This rule can 384 be relaxed, if all NAT binding table entries with the same Internal- 385 Port and External-Port have the support for the restart procedure 386 enabled. In this case there must be no more than one entry with the 387 same Internal-Port, External-Port and Ext-VTag and no more than one 388 NAT binding table entry with the same Internal-Port, External-Port 389 and Int-VTag. 391 The processing of outgoing SCTP packets containing an INIT chunk is 392 described in the following figure. The scenario shown is valid for 393 all message flows in this section. 395 /--\/--\ 396 +--------+ +-----+ / \ +--------+ 397 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 398 +--------+ +-----+ \ / +--------+ 399 \--/\---/ 401 INIT[Initiate-Tag] 402 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 403 Ext-VTag=0 405 Create(Initiate-Tag, Int-Port, 0, Ext-Port, Priv-Addr, 406 RestartSupported) 407 Returns(NAT-State control block) 409 Translate To: 411 INIT[Initiate-Tag] 412 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 413 Ext-VTag=0 415 Normally a NAT binding table entry will be created. 417 However, it is possible that there is already a NAT binding table 418 entry with the same External-Port, Internal-Port, and Internal-VTag 419 but different Private-Address. In this case the INIT MUST be dropped 420 by the NAT and an ABORT MUST be sent back to the SCTP host with the 421 M-Bit set and an appropriate error cause (see Section 5.1.1 for the 422 format). The source address of the packet containing the ABORT chunk 423 MUST be the destination address of the packet containing the INIT 424 chunk. 426 If an outgoing SCTP packet contains an INIT or ASCONF chunk and a 427 matching NAT binding table entry is found, the packet is processed as 428 a normal outgoing packet. 430 It is also possible that a connection to External-Address and 431 External-Port exists without an Internal-VTag conflict but there 432 exists a NAT binding table entry with the same port numbers but a 433 different Private-Address. In such a case the INIT MUST be dropped 434 by the NAT and an ABORT SHOULD be sent back to the SCTP host with the 435 M-Bit set and an appropriate error cause (see Section 5.1.1 for the 436 format). 438 The processing of outgoing SCTP packets containing no INIT chunks is 439 described in the following figure. 441 /--\/--\ 442 +--------+ +-----+ / \ +--------+ 443 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 444 +--------+ +-----+ \ / +--------+ 445 \--/\---/ 447 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 448 Ext-VTag 450 Translate To: 452 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 453 Ext-VTag 455 The processing of incoming SCTP packets containing an INIT ACK chunk 456 is described in the following figure. The Lookup() function getting 457 as input the Internal-VTag, Internal-Port, External-VTag, and 458 External-Port, returns the corresponding entry of the NAT binding 459 table and updates the External-VTag by substituting it with the value 460 of the Initiate-Tag of the INIT ACK chunk. The wildcard character 461 signifies that the parameter's value is not considered in the 462 Lookup() function or changed in the Update() function, respectively. 464 /--\/--\ 465 +--------+ +-----+ / \ +--------+ 466 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 467 +--------+ +-----+ \ / +--------+ 468 \--/\---/ 470 INIT ACK[Initiate-Tag] 471 Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port 472 Int-VTag 474 Lookup(Int-VTag, Int-Port, *, Ext-Port) 475 Update(*, *, Initiate-Tag, *) 477 Returns(NAT-State control block containing Priv-Addr) 479 INIT ACK[Initiate-Tag] 480 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 481 Int-VTag 483 In the case Lookup fails, the SCTP packet is dropped. If it 484 succeeds, the Update routine inserts the External-VTag (the Initiate- 485 Tag of the INIT ACK chunk) in the NAT state control block. 487 The processing of incoming SCTP packets containing an ABORT or 488 SHUTDOWN COMPLETE chunk with the T-Bit set is described in the 489 following figure. 491 /--\/--\ 492 +--------+ +-----+ / \ +--------+ 493 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 494 +--------+ +-----+ \ / +--------+ 495 \--/\---/ 497 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 498 Ext-VTag 500 Lookup(*, Int-Port, Ext-VTag, Ext-Port) 502 Returns(NAT-State control block containing Priv-Addr) 504 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 505 Ext-VTag 507 For an incoming packet containing an INIT chunk a table lookup is 508 made only based on the addresses and port numbers. If an entry with 509 an External-VTag of zero is found, it is considered a match and the 510 External-VTag is updated. If an entry with a non-matching External- 511 VTag is found or no entry is found, the incoming packet is dropped. 512 If an entry with a matching External-VTag is found, the incoming 513 packet is forwarded. This allows the handling of INIT collision 514 through NAT. 516 The processing of other incoming SCTP packets is described in the 517 following figure. 519 /--\/--\ 520 +--------+ +-----+ / \ +--------+ 521 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 522 +--------+ +-----+ \ / +--------+ 523 \--/\---/ 525 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 526 Int-VTag 528 Lookup(Int-VTag, Int-Port, *, Ext-Port) 530 Returns(NAT-State control block containing Private-Address) 532 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 533 Int-VTag 535 5. Data Formats 537 This section defines the formats used to support NAT traversal. 538 Section 5.1 and Section 5.2 describe chunks and error causes sent by 539 NAT devices and received by SCTP endpoints. Section 5.3 describes 540 parameters sent by SCTP endpoints and used by NAT devices and SCTP 541 endpoints. 543 5.1. Modified Chunks 545 This section presents existing chunks defined in [RFC4960] that are 546 modified by this document. 548 5.1.1. Extended ABORT Chunk 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type = 6 | Reserved |M|T| Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 \ \ 556 / zero or more Error Causes / 557 \ \ 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 The ABORT chunk is extended to add the new 'M bit'. The M bit 561 indicates to the receiver of the ABORT chunk that the chunk was not 562 generated by the peer SCTP endpoint, but instead by a middle box. 564 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 566 5.1.2. Extended ERROR Chunk 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type = 9 | Reserved |M|T| Length | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 \ \ 574 / zero or more Error Causes / 575 \ \ 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 The ERROR chunk defined in [RFC4960] is extended to add the new 'M 579 bit'. The M bit indicates to the receiver of the ERROR chunk that 580 the chunk was not generated by the peer SCTP endpoint, but instead by 581 a middle box. 583 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 585 5.2. New Error Causes 587 This section defines the new error causes added by this document. 589 5.2.1. VTag and Port Number Collision Error Cause 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Cause Code = 0x00B0 | Cause Length = Variable | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 \ Chunk / 597 / \ 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Cause Code: 2 bytes (unsigned integer) This field holds the IANA 601 defined cause code for the 'VTag and Port Number Collision' Error 602 Cause. IANA is requested to assign the value 0x00B0 for this 603 cause code. 605 Cause Length: 2 bytes (unsigned integer) This field holds the length 606 in bytes of the error cause. The value MUST be the length of the 607 Cause-Specific Information plus 4. 609 Chunk: variable length The Cause-Specific Information is filled with 610 the chunk that caused this error. This can be an INIT, INIT ACK, 611 or ASCONF chunk. Note that if the entire chunk will not fit in 612 the ERROR chunk or ABORT chunk being sent then the bytes that do 613 not fit are truncated. 615 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 616 IANA.] 618 5.2.2. Missing State Error Cause 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Cause Code = 0x00B1 | Cause Length = Variable | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 \ Incoming Packet / 626 / \ 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Cause Code: 2 bytes (unsigned integer) This field holds the IANA 630 defined cause code for the 'Missing State' Error Cause. IANA is 631 requested to assign the value 0x00B1 for this cause code. 633 Cause Length: 2 bytes (unsigned integer) This field holds the length 634 in bytes of the error cause. The value MUST be the length of the 635 Cause-Specific Information plus 4. 637 Incoming Packet: variable length The Cause-Specific Information is 638 filled with the IPv4 or IPv6 packet that caused this error. The 639 IPv4 or IPv6 header MUST be included. Note that if the packet 640 will not fit in the ERROR chunk or ABORT chunk being sent then the 641 bytes that do not fit are truncated. 643 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 644 IANA.] 646 5.2.3. Port Number Collision Error Cause 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Cause Code = 0x00B2 | Cause Length = Variable | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 \ Chunk / 654 / \ 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Cause Code: 2 bytes (unsigned integer) This field holds the IANA 658 defined cause code for the 'Port Number Collision' Error Cause. 659 IANA is requested to assign the value 0x00B2 for this cause code. 661 Cause Length: 2 bytes (unsigned integer) This field holds the length 662 in bytes of the error cause. The value MUST be the length of the 663 Cause-Specific Information plus 4. 665 Chunk: variable length The Cause-Specific Information is filled with 666 the chunk that caused this error. This can be an INIT, INIT ACK, 667 or ASCONF chunk. Note that if the entire chunk will not fit in 668 the ERROR chunk or ABORT chunk being sent then the bytes that do 669 not fit are truncated. 671 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 672 IANA.] 674 5.3. New Parameters 676 This section defines new parameters and their valid appearance 677 defined by this document. 679 5.3.1. Disable Restart Parameter 681 This parameter is used to indicate that the restart procedure is 682 requested to be disabled. Both endpoints of an association MUST 683 include this parameter in the INIT chunk and INIT ACK chunk when 684 establishing an association and MUST include it in the ASCONF chunk 685 when adding an address to successfully disable the restart procedure. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type = 0xC007 | Length = 4 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Parameter Type: 2 bytes (unsigned integer) This field holds the IANA 694 defined parameter type for the Disable Restart Parameter. IANA is 695 requested to assign the value 0xC007 for this parameter type. 697 Parameter Length: 2 bytes (unsigned integer) This field holds the 698 length in bytes of the parameter. The value MUST be 4. 700 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 701 IANA.] 703 This parameter MAY appear in INIT, INIT ACK and ASCONF chunks and 704 MUST NOT appear in any other chunk. 706 5.3.2. VTags Parameter 708 This parameter is used to help a NAT recover from state loss. 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Parameter Type = 0xC008 | Parameter Length = 16 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | ASCONF-Request Correlation ID | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Internal Verification Tag | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | External Verification Tag | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Parameter Type: 2 bytes (unsigned integer) This field holds the IANA 723 defined parameter type for the VTags Parameter. IANA is requested 724 to assign the value 0xC008 for this parameter type. 726 Parameter Length: 2 bytes (unsigned integer) This field holds the 727 length in bytes of the parameter. The value MUST be 16. 729 ASCONF-Request Correlation ID: 4 bytes (unsigned integer) This is an 730 opaque integer assigned by the sender to identify each request 731 parameter. The receiver of the ASCONF Chunk will copy this 32-bit 732 value into the ASCONF Response Correlation ID field of the ASCONF 733 ACK response parameter. The sender of the ASCONF can use this 734 same value in the ASCONF ACK to find which request the response is 735 for. Note that the receiver MUST NOT change this 32-bit value. 737 Internal Verification Tag: 4 bytes (unsigned integer) The 738 Verification Tag that the internal host has chosen for its 739 communication. The Verification Tag is a unique 32-bit tag that 740 must accompany any incoming SCTP packet for this association to 741 the Private-Address. 743 External Verification Tag: 4 bytes (unsigned integer) The 744 Verification Tag that the host holding the External-Address has 745 chosen for its communication. The VTag is a unique 32-bit tag 746 that must accompany any incoming SCTP packet for this association 747 to the External-Address. 749 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 750 IANA.] 752 This parameter MAY appear in ASCONF chunks and MUST NOT appear in any 753 other chunk. 755 6. Procedures for SCTP Endpoints and NAT Devices 757 When an SCTP endpoint is behind an SCTP-aware NAT a number of 758 problems may arise as it tries to communicate with its peer: 760 * IP addresses can not be included in the SCTP packet. This is 761 discussed in Section 6.1. 763 * More than one host behind a NAT device could select the same VTag 764 and source port when talking to the same peer server. This 765 creates a situation where the NAT will not be able to tell the two 766 associations apart. This situation is discussed in Section 6.2. 768 * When an SCTP endpoint is a server communicating with multiple 769 peers and the peers are behind the same NAT, then the two 770 endpoints cannot be distinguished by the server. This case is 771 discussed in Section 6.3. 773 * A restart of a NAT during a conversation could cause a loss of its 774 state. This problem and its solution is discussed in Section 6.4. 776 * NAT devices need to deal with SCTP packets being fragmented at the 777 IP layer. This is discussed in Section 6.5. 779 * An SCTP endpoint may be behind two NAT devices providing 780 redundancy. The method to set up this scenario is discussed in 781 Section 6.6. 783 Each of these mechanisms requires additional chunks and parameters, 784 defined in this document, and possibly modified handling procedures 785 from those specified in [RFC4960]. 787 6.1. Association Setup Considerations for Endpoints 789 The association setup procedure defined in [RFC4960] allows multi- 790 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 791 IPv6 address parameters in the INIT and INIT ACK chunks. However, 792 this doesn't work when NAT devices are present. 794 Every association setup from a host behind a NAT MUST NOT use 795 multiple private addresses. There MUST NOT be any IPv4 Address 796 parameter, IPv6 Address parameter, or Supported Address Types 797 parameter in the INIT chunk. The INIT ACK chunk MUST NOT contain any 798 IPv4 Address parameter or IPv6 Address parameter using non-global 799 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 800 any Host Name parameters. 802 If the association should finally be multi-homed, the procedure in 803 Section 6.6 MUST be used. 805 The INIT and INIT ACK chunk SHOULD contain the Disable Restart 806 parameter defined in Section 5.3.1. 808 6.2. Handling of Internal Port Number and Verification Tag Collisions 810 Consider the case where two hosts in the Private-Address space want 811 to set up an SCTP association with the same service provided by some 812 hosts in the Internet. This means that the External-Port is the 813 same. If they both choose the same Internal-Port and Internal-VTag, 814 the NAT device cannot distinguish between incoming packets anymore. 815 But this is very unlikely. The Internal-VTags are chosen at random 816 and if the Internal-Ports are also chosen from the ephemeral port 817 range at random this gives a 46-bit random number that has to match. 818 A NAPT device can control the 16-bit Natted Port and therefore avoid 819 collisions deterministically. 821 The same can happen with the External-VTag when an INIT ACK chunk or 822 an ASCONF chunk is processed by the NAT. 824 6.2.1. NAT Device Considerations 826 If the NAT device detects a collision of internal port numbers and 827 verification tags, it MUST send an ABORT chunk with the M bit set if 828 the collision is triggered by an INIT or INIT ACK chunk. If such a 829 collision is triggered by an ASCONF chunk, it MUST send an ERROR 830 chunk with the M bit. The M bit is a new bit defined by this 831 document to express to SCTP that the source of this packet is a 832 "middle" box, not the peer SCTP endpoint (see Section 5.1.1). If a 833 packet containing an INIT ACK chunk triggers the collision, the 834 corresponding packet containing the ABORT chunk MUST contain the same 835 source and destination address and port numbers as the packet 836 containing the INIT ACK chunk. In the other two cases, the source 837 and destination address and port numbers MUST be swapped. 839 The sender of the ERROR or ABORT chunk MUST include the error cause 840 with cause code 'VTag and Port Number Collision' (see Section 5.2.1). 842 6.2.2. Endpoint Considerations 844 The sender of the packet containing the INIT chunk or the receiver of 845 the INIT ACK chunk, upon reception of an ABORT chunk with M bit set 846 and the appropriate error cause code for colliding NAT binding table 847 state is included, SHOULD reinitiate the association setup procedure 848 after choosing a new initiate tag, if the association is in COOKIE- 849 WAIT state. In any other state, the SCTP endpoint MUST NOT respond. 851 The sender of the ASCONF chunk, upon reception of an ERROR chunk with 852 M bit set, MUST stop adding the path to the association. 854 6.3. Handling of Internal Port Number Collisions 856 When two SCTP hosts are behind an SCTP-aware NAT it is possible that 857 two SCTP hosts in the Private-Address space will want to set up an 858 SCTP association with the same server running on the same host in the 859 Internet. If the two hosts choose the same internal port, this is 860 considered an internal port number collision. 862 For the NAT, appropriate tracking may be performed by assuring that 863 the VTags are unique between the two hosts. 865 6.3.1. NAT Device Considerations 867 The NAT, when processing the INIT ACK, should note in its NAT binding 868 table that the association supports the disable restart extension. 869 This note is used when establishing future associations (i.e. when 870 processing an INIT from an internal host) to decide if the connection 871 should be allowed. The NAT device does the following when processing 872 an INIT: 874 * If the INIT is originating from an internal port to an external 875 port for which the NAT device has no matching NAT binding table 876 entry, it MUST allow the INIT creating an NAT binding table entry. 878 * If the INIT matches an existing NAT binding table entry, it MUST 879 validate that the disable restart feature is supported and, if it 880 does, allow the INIT to be forwarded. 882 * If the disable restart feature is not supported, the NAT device 883 MUST send an ABORT with the M bit set. 885 The 'Port Number Collision' error cause (see Section 5.2.3) MUST be 886 included in the ABORT chunk sent in response to the INIT chunk. 888 If the collision is triggered by an ASCONF chunk, a packet containing 889 an ERROR chunk with the 'Port Number Collision' error cause MUST be 890 sent in response to the ASCONF chunk. 892 6.3.2. Endpoint Considerations 894 For the external SCTP server on the Internet this means that the 895 External-Port and the External-Address are the same. If they both 896 have chosen the same Internal-Port the server cannot distinguish 897 between both associations based on the address and port numbers. For 898 the server it looks like the association is being restarted. To 899 overcome this limitation the client sends a Disable Restart parameter 900 in the INIT chunk. 902 When the server receives this parameter it does the following: 904 * It MUST include a Disable Restart parameter in the INIT ACK to 905 inform the client that it will support the feature. 907 * It MUST disable the restart procedures defined in [RFC4960] for 908 this association. 910 Servers that support this feature will need to be capable of 911 maintaining multiple connections to what appears to be the same peer 912 (behind the NAT) differentiated only by the VTags. 914 6.4. Handling of Missing State 916 6.4.1. NAT Device Considerations 918 If the NAT device receives a packet from the internal network for 919 which the lookup procedure does not find an entry in the NAT binding 920 table, a packet containing an ERROR chunk is sent back with the M bit 921 set. The source address of the packet containing the ERROR chunk 922 MUST be the destination address of the incoming SCTP packet. The 923 verification tag is reflected and the T bit is set. Such a packet 924 containing an ERROR chunk SHOULD NOT be sent if the received packet 925 contains an ABORT, SHUTDOWN COMPLETE or INIT ACK chunk. An ERROR 926 chunk MUST NOT be sent if the received packet contains an ERROR chunk 927 with the M bit set. In any case, the packet SHOULD NOT be forwarded 928 to the external address. 930 When sending the ERROR chunk, the error cause 'Missing State' (see 931 Section 5.2.2) MUST be included and the M bit of the ERROR chunk MUST 932 be set (see Section 5.1.2). 934 If the NAT device receives a packet for which it has no NAT binding 935 table entry and the packet contains an ASCONF chunk with the VTags 936 parameter, the NAT device MUST update its NAT binding table according 937 to the verification tags in the VTags parameter and the optional 938 Disable Restart parameter. 940 6.4.2. Endpoint Considerations 942 Upon reception of this ERROR chunk by an SCTP endpoint the receiver 943 takes the following actions: 945 * It SHOULD validate that the verification tag is reflected by 946 looking at the VTag that would have been included in the outgoing 947 packet. If the validation fails, discard the incoming ERROR 948 chunk. 950 * It SHOULD validate that the peer of the SCTP association supports 951 the dynamic address extension. If the validation fails, discard 952 the incoming ERROR chunk. 954 * It SHOULD generate a new ASCONF chunk containing the VTags 955 parameter (see Section 5.3.2) and the Disable Restart parameter 956 (see Section 5.3.1) if the association is using the disable 957 restart feature. By processing this packet the NAT device can 958 recover the appropriate state. The procedures for generating an 959 ASCONF chunk can be found in [RFC5061]. 961 The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either 962 add the address and respond with an acknowledgment, if the address is 963 new to the association (following all procedures defined in 964 [RFC5061]). Or, if the address is already part of the association, 965 the SCTP endpoint MUST NOT respond with an error, but instead SHOULD 966 respond with an ASCONF ACK chunk acknowledging the address and take 967 no action (since the address is already in the association). 969 Note that it is possible that upon receiving an ASCONF chunk 970 containing the VTags parameter the NAT will realize that it has an 971 'Internal Port Number and Verification Tag collision'. In such a 972 case the NAT MUST send an ERROR chunk with the error cause code set 973 to 'VTag and Port Number Collision' (see Section 5.2.1). 975 If an SCTP endpoint receives an ERROR with 'Internal Port Number and 976 Verification Tag collision' as the error cause and the packet in the 977 Error Chunk contains an ASCONF with the VTags parameter, careful 978 examination of the association is required. The endpoint does the 979 following: 981 * It MUST validate that the verification tag is reflected by looking 982 at the VTag that would have been included in the outgoing packet. 983 If the validation fails, it MUST discard the packet. 985 * It MUST validate that the peer of the SCTP association supports 986 the dynamic address extension. If the peer does not support it, 987 the NAT Device MUST discard the incoming ERROR chunk. 989 * If the association is attempting to add an address (i.e. following 990 the procedures in Section 6.6) then the endpoint MUST NOT consider 991 the address part of the association and SHOULD make no further 992 attempt to add the address (i.e. cancel any ASCONF timers and 993 remove any record of the path), since the NAT device has a VTag 994 collision and the association cannot easily create a new VTag (as 995 it would if the error occurred when sending an INIT). 997 * If the endpoint has no other path, i.e. the procedure was executed 998 due to missing a state in the NAT device, then the endpoint MUST 999 abort the association. This would occur only if the local NAT 1000 device restarted and accepted a new association before attempting 1001 to repair the missing state (Note that this is no different than 1002 what happens to all TCP connections when a NAT device looses its 1003 state). 1005 6.5. Handling of Fragmented SCTP Packets by NAT Devices 1007 A NAT device MUST support IP reassembly of received fragmented SCTP 1008 packets. The fragments may arrive in any order. 1010 When an SCTP packet has to be fragmented by the NAT device and the IP 1011 header forbids fragmentation a corresponding ICMP packet SHOULD be 1012 sent. 1014 6.6. Multi Point Traversal Considerations for Endpoints 1016 If a multi-homed SCTP endpoint behind a NAT connects to a peer, it 1017 MUST first set up the association single-homed with only one address 1018 causing the first NAT to populate its state. Then it SHOULD add each 1019 IP address using ASCONF chunks sent via their respective NAT devices. 1020 The address to add is the wildcard address and the lookup address 1021 SHOULD also contain the VTags parameter and optionally the Disable 1022 Restart parameter. 1024 7. Various Examples of NAT Traversals 1026 Please note that this section is informational only. 1028 The addresses being used in the following examples are IPv4 addresses 1029 for private-use networks and for documentation as specified in 1030 [RFC6890]. However, the method described here is not limited to this 1031 NAT44 case. 1033 The NAT binding table entries shown in the following examples do not 1034 include the flag indicating whether the restart procedure is 1035 supported or not. This flag is not relevant for these examples. 1037 7.1. Single-homed Client to Single-homed Server 1039 The internal client starts the association with the external server 1040 via a four-way-handshake. Host A starts by sending an INIT chunk. 1042 /--\/--\ 1043 +--------+ +-----+ / \ +--------+ 1044 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1045 +--------+ +-----+ \ / +--------+ 1046 \--/\---/ 1047 +---------+--------+----------+--------+-----------+ 1048 NAT | Int | Int | Ext | Ext | Priv | 1049 | VTag | Port | VTag | Port | Addr | 1050 +---------+--------+----------+--------+-----------+ 1052 INIT[Initiate-Tag = 1234] 1053 10.0.0.1:1 ------> 203.0.113.1:2 1054 Ext-VTtag = 0 1056 A NAT binding tabled entry is created, the source address is 1057 substituted and the packet is sent on: 1059 NAT creates entry: 1060 +---------+--------+----------+--------+-----------+ 1061 NAT | Int | Int | Ext | Ext | Priv | 1062 | VTag | Port | VTag | Port | Addr | 1063 +---------+--------+----------+--------+-----------+ 1064 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1065 +---------+--------+----------+--------+-----------+ 1067 INIT[Initiate-Tag = 1234] 1068 192.0.2.1:1 ------------------------> 203.0.113.1:2 1069 Ext-VTtag = 0 1071 Host B receives the INIT and sends an INIT ACK with the NAT's 1072 external address as destination address. 1074 /--\/--\ 1075 +--------+ +-----+ / \ +--------+ 1076 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1077 +--------+ +-----+ \ / +--------+ 1078 \--/\---/ 1080 INIT ACK[Initiate-Tag = 5678] 1081 192.0.2.1:1 <----------------------- 203.0.113.1:2 1082 Int-VTag = 1234 1084 NAT updates entry: 1085 +---------+--------+----------+--------+-----------+ 1086 NAT | Int | Int | Ext | Ext | Priv | 1087 | VTag | Port | VTag | Port | Addr | 1088 +---------+--------+----------+--------+-----------+ 1089 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1090 +---------+--------+----------+--------+-----------+ 1092 INIT ACK[Initiate-Tag = 5678] 1093 10.0.0.1:1 <------ 203.0.113.1:2 1094 Int-VTag = 1234 1096 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1097 ACK. 1099 /--\/--\ 1100 +--------+ +-----+ / \ +--------+ 1101 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1102 +--------+ +-----+ \ / +--------+ 1103 \--/\---/ 1105 COOKIE ECHO 1106 10.0.0.1:1 ------> 203.0.113.1:2 1107 Ext-VTag = 5678 1109 COOKIE ECHO 1110 192.0.2.1:1 -----------------------> 203.0.113.1:2 1111 Ext-VTag = 5678 1113 COOKIE ACK 1114 192.0.2.1:1 <----------------------- 203.0.113.1:2 1115 Int-VTag = 1234 1117 COOKIE ACK 1118 10.0.0.1:1 <------ 203.0.113.1:2 1119 Int-VTag = 1234 1121 7.2. Single-homed Client to Multi-homed Server 1123 The internal client is single-homed whereas the external server is 1124 multi-homed. The client (Host A) sends an INIT like in the single- 1125 homed case. 1127 +--------+ 1128 /--\/--\ /-|Router 1| \ 1129 +------+ +-----+ / \ / +--------+ \ +------+ 1130 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1131 | A | +-----+ \ / \ +--------+ / | B | 1132 +------+ \--/\--/ \-|Router 2|-/ +------+ 1133 +--------+ 1135 +---------+--------+----------+--------+-----------+ 1136 NAT | Int | Int | Ext | Ext | Priv | 1137 | VTag | Port | VTag | Port | Addr | 1138 +---------+--------+----------+--------+-----------+ 1140 INIT[Initiate-Tag = 1234] 1141 10.0.0.1:1 ---> 203.0.113.1:2 1142 Ext-VTag = 0 1144 NAT creates entry: 1146 +---------+--------+----------+--------+-----------+ 1147 NAT | Int | Int | Ext | Ext | Priv | 1148 | VTag | Port | VTag | Port | Addr | 1149 +---------+--------+----------+--------+-----------+ 1150 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1151 +---------+--------+----------+--------+-----------+ 1153 INIT[Initiate-Tag = 1234] 1154 192.0.2.1:1 --------------------------> 203.0.113.1:2 1155 Ext-VTag = 0 1157 The server (Host B) includes its two addresses in the INIT ACK chunk. 1159 +--------+ 1160 /--\/--\ /-|Router 1| \ 1161 +------+ +-----+ / \ / +--------+ \ +------+ 1162 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1163 | A | +-----+ \ / \ +--------+ / | B | 1164 +------+ \--/\--/ \-|Router 2|-/ +------+ 1165 +--------+ 1167 INIT ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129] 1168 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1169 Int-VTag = 1234 1171 The NAT device does not need to change the NAT binding table for the 1172 second address: 1174 +---------+--------+----------+--------+-----------+ 1175 NAT | Int | Int | Ext | Ext | Priv | 1176 | VTag | Port | VTag | Port | Addr | 1177 +---------+--------+----------+--------+-----------+ 1178 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1179 +---------+--------+----------+--------+-----------+ 1181 INIT ACK[Initiate-Tag = 5678] 1182 10.0.0.1:1 <--- 203.0.113.1:2 1183 Int-VTag = 1234 1185 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1186 ACK. 1188 +--------+ 1189 /--\/--\ /-|Router 1| \ 1190 +------+ +-----+ / \ / +--------+ \ +------+ 1191 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1192 | A | +-----+ \ / \ +--------+ / | B | 1193 +------+ \--/\--/ \-|Router 2|-/ +------+ 1194 +--------+ 1196 COOKIE ECHO 1197 10.0.0.1:1 ---> 203.0.113.1:2 1198 ExtVTag = 5678 1200 COOKIE ECHO 1201 192.0.2.1:1 --------------------------> 203.0.113.1:2 1202 Ext-VTag = 5678 1204 COOKIE ACK 1205 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1206 Int-VTag = 1234 1208 COOKIE ACK 1209 10.0.0.1:1 <--- 203.0.113.1:2 1210 Int-VTag = 1234 1212 7.3. Multihomed Client and Server 1214 The client (Host A) sends an INIT to the server (Host B), but does 1215 not include the second address. 1217 +-------+ 1218 /--| NAT 1 |--\ /--\/--\ 1219 +------+ / +-------+ \ / \ +--------+ 1220 | Host |=== ====| Internet |====| Host B | 1221 | A | \ +-------+ / \ / +--------+ 1222 +------+ \--| NAT 2 |--/ \--/\--/ 1223 +-------+ 1225 +---------+--------+----------+--------+-----------+ 1226 NAT 1 | Int | Int | Ext | Ext | Priv | 1227 | VTag | Port | VTag | Port | Addr | 1228 +---------+--------+----------+--------+-----------+ 1230 INIT[Initiate-Tag = 1234] 1231 10.0.0.1:1 --------> 203.0.113.1:2 1232 Ext-VTag = 0 1234 NAT 1 creates entry: 1236 +---------+--------+----------+--------+-----------+ 1237 NAT 1 | Int | Int | Ext | Ext | Priv | 1238 | VTag | Port | VTag | Port | Addr | 1239 +---------+--------+----------+--------+-----------+ 1240 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1241 +---------+--------+----------+--------+-----------+ 1243 INIT[Initiate-Tag = 1234] 1244 192.0.2.1:1 ---------------------> 203.0.113.1:2 1245 ExtVTag = 0 1247 Host B includes its second address in the INIT ACK. 1249 +-------+ 1250 /--------| NAT 1 |--------\ /--\/--\ 1251 +------+ / +-------+ \ / \ +--------+ 1252 | Host |=== ====| Internet |===| Host B | 1253 | A | \ +-------+ / \ / +--------+ 1254 +------+ \--------| NAT 2 |--------/ \--/\--/ 1255 +-------+ 1257 INIT ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129] 1258 192.0.2.1:1 <----------------------- 203.0.113.1:2 1259 Int-VTag = 1234 1261 NAT 1 does not need to update the NAT binding table for the second 1262 address: 1264 +---------+--------+----------+--------+-----------+ 1265 NAT 1 | Int | Int | Ext | Ext | Priv | 1266 | VTag | Port | VTag | Port | Addr | 1267 +---------+--------+----------+--------+-----------+ 1268 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1269 +---------+--------+----------+--------+-----------+ 1271 INIT ACK[Initiate-Tag = 5678] 1272 10.0.0.1:1 <-------- 203.0.113.1:2 1273 Int-VTag = 1234 1275 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1276 ACK. 1278 +-------+ 1279 /--------| NAT 1 |--------\ /--\/--\ 1280 +------+ / +-------+ \ / \ +--------+ 1281 | Host |=== ====| Internet |===| Host B | 1282 | A | \ +-------+ / \ / +--------+ 1283 +------+ \--------| NAT 2 |--------/ \--/\--/ 1284 +-------+ 1286 COOKIE ECHO 1287 10.0.0.1:1 --------> 203.0.113.1:2 1288 Ext-VTag = 5678 1290 COOKIE ECHO 1291 192.0.2.1:1 ------------------> 203.0.113.1:2 1292 Ext-VTag = 5678 1294 COOKIE ACK 1295 192.0.2.1:1 <------------------ 203.0.113.1:2 1296 Int-VTag = 1234 1298 COOKIE ACK 1299 10.0.0.1:1 <------- 203.0.113.1:2 1300 Int-VTag = 1234 1302 Host A announces its second address in an ASCONF chunk. The address 1303 parameter contains an undefined address (0) to indicate that the 1304 source address should be added. The lookup address parameter within 1305 the ASCONF chunk will also contain the pair of VTags (external and 1306 internal) so that the NAT may populate its NAT binding table entry 1307 completely with this single packet. 1309 +-------+ 1310 /--------| NAT 1 |--------\ /--\/--\ 1311 +------+ / +-------+ \ / \ +--------+ 1312 | Host |=== ====| Internet |===| Host B | 1313 | A | \ +-------+ / \ / +--------+ 1314 +------+ \--------| NAT 2 |--------/ \--/\--/ 1315 +-------+ 1317 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] 1318 10.1.0.1:1 --------> 203.0.113.129:2 1319 Ext-VTag = 5678 1321 NAT 2 creates a complete entry: 1323 +---------+--------+----------+--------+-----------+ 1324 NAT 2 | Int | Int | Ext | Ext | Priv | 1325 | VTag | Port | VTag | Port | Addr | 1326 +---------+--------+----------+--------+-----------+ 1327 | 1234 | 1 | 5678 | 2 | 10.1.0.1 | 1328 +---------+--------+----------+--------+-----------+ 1330 ASCONF [ADD-IP, Int-VTag=1234, Ext-VTag = 5678] 1331 192.0.2.129:1 -------------------> 203.0.113.129:2 1332 Ext-VTag = 5678 1334 ASCONF ACK 1335 192.0.2.129:1 <------------------- 203.0.113.129:2 1336 Int-VTag = 1234 1338 ASCONF ACK 1339 10.1.0.1:1 <----- 203.0.113.129:2 1340 Int-VTag = 1234 1342 7.4. NAT Loses Its State 1344 Association is already established between Host A and Host B, when 1345 the NAT loses its state and obtains a new public address. Host A 1346 sends a DATA chunk to Host B. 1348 /--\/--\ 1349 +--------+ +-----+ / \ +--------+ 1350 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1351 +--------+ +-----+ \ / +--------+ 1352 \--/\--/ 1354 +---------+--------+----------+--------+-----------+ 1355 NAT | Int | Int | Ext | Ext | Priv | 1356 | VTag | Port | VTag | Port | Addr | 1357 +---------+--------+----------+--------+-----------+ 1359 DATA 1360 10.0.0.1:1 ----------> 203.0.113.1:2 1361 Ext-VTag = 5678 1363 The NAT device cannot find an entry in the NAT binding table for the 1364 association. It sends ERROR an message with the M-Bit set and the 1365 cause "NAT state missing". 1367 /--\/--\ 1368 +--------+ +-----+ / \ +--------+ 1369 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1370 +--------+ +-----+ \ / +--------+ 1371 \--/\--/ 1373 ERROR [M-Bit, NAT state missing] 1374 10.0.0.1:1 <---------- 203.0.113.1:2 1375 Ext-VTag = 5678 1377 On reception of the ERROR message, Host A sends an ASCONF chunk 1378 indicating that the former information has to be deleted and the 1379 source address of the actual packet added. 1381 /--\/--\ 1382 +--------+ +-----+ / \ +--------+ 1383 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1384 +--------+ +-----+ \ / +--------+ 1385 \--/\--/ 1387 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Ext-VTag = 5678] 1388 10.0.0.1:1 ----------> 203.0.113.129:2 1389 Ext-VTag = 5678 1391 +---------+--------+----------+--------+-----------+ 1392 NAT | Int | Int | Ext | Ext | Priv | 1393 | VTag | Port | VTag | Port | Addr | 1394 +---------+--------+----------+--------+-----------+ 1395 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1396 +---------+--------+----------+--------+-----------+ 1398 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Ext-VTag = 5678] 1399 192.0.2.2:1 -----------------> 203.0.113.129:2 1400 Ext-VTag = 5678 1402 Host B adds the new source address to this association and deletes 1403 all other addresses from this association. 1405 /--\/--\ 1406 +--------+ +-----+ / \ +--------+ 1407 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1408 +--------+ +-----+ \ / +--------+ 1409 \--/\--/ 1411 ASCONF ACK 1412 192.0.2.2:1 <----------------- 203.0.113.129:2 1413 Int-VTag = 1234 1415 ASCONF ACK 1416 10.1.0.1:1 <---------- 203.0.113.129:2 1417 Int-VTag = 1234 1419 DATA 1420 10.0.0.1:1 ----------> 203.0.113.1:2 1421 Ext-VTag = 5678 1422 DATA 1423 192.0.2.2:1 -----------------> 203.0.113.129:2 1424 Ext-VTag = 5678 1426 7.5. Peer-to-Peer Communication 1428 If two hosts are behind NAT devices and want to communicate with each 1429 other, they have to get knowledge of the peer's public address. This 1430 can be achieved with a so-called rendezvous server. Afterwards the 1431 destination addresses are public, and the association is set up with 1432 the help of the INIT collision. The NAT devices create their entries 1433 according to their internal peer's point of view. Therefore, NAT A's 1434 Internal-VTag and Internal-Port are NAT B's External-VTag and 1435 External-Port, respectively. The naming (internal/external) of the 1436 verification tag in the packet flow is done from the sending host's 1437 point of view. 1439 Internal | External External | Internal 1440 | | 1441 | /--\/---\ | 1442 +--------+ +-------+ / \ +-------+ +--------+ 1443 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1444 +--------+ +-------+ \ / +-------+ +--------+ 1445 | \--/\---/ | 1447 NAT Binding Tables 1448 +---------+--------+----------+--------+-----------+ 1449 NAT A | Int | Int | Ext | Ext | Priv | 1450 | VTag | Port | VTag | Port | Addr | 1451 +---------+--------+----------+--------+-----------+ 1453 +---------+--------+----------+--------+-----------+ 1454 NAT B | Int | Int | Ext | Ext | Priv | 1455 | v-tag | port | v-tag | port | Addr | 1456 +---------+--------+----------+--------+-----------+ 1458 INIT[Initiate-Tag = 1234] 1459 10.0.0.1:1 --> 203.0.113.1:2 1460 Ext-VTag = 0 1462 NAT A creates entry: 1464 +---------+--------+----------+--------+-----------+ 1465 NAT A | Int | Int | Ext | Ext | Priv | 1466 | VTag | Port | VTag | Port | Addr | 1467 +---------+--------+----------+--------+-----------+ 1468 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1469 +---------+--------+----------+--------+-----------+ 1471 INIT[Initiate-Tag = 1234] 1472 192.0.2.1:1 ----------------> 203.0.113.1:2 1473 Ext-VTag = 0 1475 NAT B processes INIT, but cannot find an entry. The SCTP packet is 1476 silently discarded and leaves the NAT binding table of NAT B 1477 unchanged. 1479 +---------+--------+----------+--------+-----------+ 1480 NAT B | Int | Int | Ext | Ext | Priv | 1481 | VTag | Port | VTag | Port | Addr | 1482 +---------+--------+----------+--------+-----------+ 1484 Now Host B sends INIT, which is processed by NAT B. Its parameters 1485 are used to create an entry. 1487 Internal | External External | Internal 1488 | | 1489 | /--\/---\ | 1490 +--------+ +-------+ / \ +-------+ +--------+ 1491 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1492 +--------+ +-------+ \ / +-------+ +--------+ 1493 | \--/\---/ | 1495 INIT[Initiate-Tag = 5678] 1496 192.0.2.1:1 <-- 10.1.0.1:2 1497 Ext-VTag = 0 1499 +---------+--------+-----------+----------+--------+ 1500 NAT B | Int | Int | Priv | Ext | Ext | 1501 | VTag | Port | Addr | VTag | Port | 1502 +---------+--------+-----------+----------+--------+ 1503 | 5678 | 2 | 10.1.0.1 | 0 | 1 | 1504 +---------+--------+-----------+----------+--------+ 1506 INIT[Initiate-Tag = 5678] 1507 192.0.2.1:1 <--------------- 203.0.113.1:2 1508 Ext-VTag = 0 1510 NAT A processes INIT. As the outgoing INIT of Host A has already 1511 created an entry, the entry is found and updated: 1513 Internal | External External | Internal 1514 | | 1515 | /--\/---\ | 1516 +--------+ +-------+ / \ +-------+ +--------+ 1517 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1518 +--------+ +-------+ \ / +-------+ +--------+ 1519 | \--/\---/ | 1521 VTag != Int-VTag, but Ext-VTag == 0, find entry. 1522 +---------+--------+----------+--------+-----------+ 1523 NAT A | Int | Int | Ext | Ext | Priv | 1524 | VTag | Port | VTag | Port | Addr | 1525 +---------+--------+----------+--------+-----------+ 1526 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1527 +---------+--------+----------+--------+-----------+ 1529 INIT[Initiate-tag = 5678] 1530 10.0.0.1:1 <-- 203.0.113.1:2 1531 Ext-VTag = 0 1533 Host A sends INIT ACK, which can pass through NAT B: 1535 Internal | External External | Internal 1536 | | 1537 | /--\/---\ | 1538 +--------+ +-------+ / \ +-------+ +--------+ 1539 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1540 +--------+ +-------+ \ / +-------+ +--------+ 1541 | \--/\---/ | 1543 INIT ACK[Initiate-Tag = 1234] 1544 10.0.0.1:1 --> 203.0.113.1:2 1545 Ext-VTag = 5678 1547 INIT ACK[Initiate-Tag = 1234] 1548 192.0.2.1:1 ----------------> 203.0.113.1:2 1549 Ext-VTag = 5678 1551 NAT B updates entry: 1553 +---------+--------+----------+--------+-----------+ 1554 NAT B | Int | Int | Ext | Ext | Priv | 1555 | VTag | Port | VTag | Port | Addr | 1556 +---------+--------+----------+--------+-----------+ 1557 | 5678 | 2 | 1234 | 1 | 10.1.0.1 | 1558 +---------+--------+----------+--------+-----------+ 1560 INIT ACK[Initiate-Tag = 1234] 1561 192.0.2.1:1 --> 10.1.0.1:2 1562 Ext-VTag = 5678 1564 The lookup for COOKIE ECHO and COOKIE ACK is successful. 1566 Internal | External External | Internal 1567 | | 1568 | /--\/---\ | 1569 +--------+ +-------+ / \ +-------+ +--------+ 1570 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1571 +--------+ +-------+ \ / +-------+ +--------+ 1572 | \--/\---/ | 1574 COOKIE ECHO 1575 192.0.2.1:1 <-- 10.1.0.1:2 1576 Ext-VTag = 1234 1578 COOKIE ECHO 1579 192.0.2.1:1 <------------- 203.0.113.1:2 1580 Ext-VTag = 1234 1582 COOKIE ECHO 1583 10.0.0.1:1 <-- 203.0.113.1:2 1584 Ext-VTag = 1234 1586 COOKIE ACK 1587 10.0.0.1:1 --> 203.0.113.1:2 1588 Ext-VTag = 5678 1590 COOKIE ACK 1591 192.0.2.1:1 ----------------> 203.0.113.1:2 1592 Ext-VTag = 5678 1594 COOKIE ACK 1595 192.0.2.1:1 --> 10.1.0.1:2 1596 Ext-VTag = 5678 1598 8. SCTP NAT YANG Module 1600 This section defines a YANG module for SCTP NAT. 1602 The terminology for describing YANG data models is defined in 1603 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 1604 [RFC8340]. 1606 8.1. Tree Structure 1608 This module augments NAT YANG module [RFC8512] with SCTP specifics. 1609 The module supports both classical SCTP NAT (that is, rewrite port 1610 numbers) and SCTP-specific variant where the ports numbers are not 1611 altered. The YANG "feature" is used to indicate whether SCTP- 1612 specific variant is supported. 1614 The tree structure of the SCTP NAT YANG module is provided below: 1616 module: ietf-nat-sctp 1617 augment /nat:nat/nat:instances/nat:instance 1618 /nat:policy/nat:timers: 1619 +--rw sctp-timeout? uint32 1620 augment /nat:nat/nat:instances/nat:instance 1621 /nat:mapping-table/nat:mapping-entry: 1622 +--rw int-VTag? uint32 {sctp-nat}? 1623 +--rw ext-VTag? uint32 {sctp-nat}? 1625 Concretely, the SCTP NAT YANG module augments the NAT YANG module 1626 (policy, in particular) with the following: 1628 * The sctp-timeout is used to control the SCTP inactivity timeout. 1629 That is, the time an SCTP mapping will stay active without SCTP 1630 packets traversing the NAT. This timeout can be set only for 1631 SCTP. Hence, "/nat:nat/nat:instances/nat:instance/nat:policy/ 1632 nat:transport-protocols/nat:protocol-id" MUST be set to '132' 1633 (SCTP). 1635 In addition, the SCTP NAT YANG module augments the mapping entry with 1636 the following parameters defined in Section 3. These parameters 1637 apply only for SCTP NAT mapping entries (i.e., 1638 "/nat/instances/instance/mapping-table/mapping-entry/transport- 1639 protocol" MUST be set to '132'); 1641 * The Internal Verification Tag (Int-VTag) 1643 * The External Verification Tag (Ext-VTag) 1645 8.2. YANG Module 1647 1648 module ietf-nat-sctp { 1649 yang-version 1.1; 1650 namespace "urn:ietf:params:xml:ns:yang:ietf-nat-sctp"; 1651 prefix nat-sctp; 1653 import ietf-nat { 1654 prefix nat; 1655 reference 1656 "RFC 8512: A YANG Module for Network Address Translation 1657 (NAT) and Network Prefix Translation (NPT)"; 1658 } 1660 organization 1661 "IETF TSVWG Working Group"; 1663 contact 1664 "WG Web: 1665 WG List: 1667 Author: Mohamed Boucadair 1668 "; 1669 description 1670 "This module augments NAT YANG module with Stream Control 1671 Transmission Protocol (SCTP) specifics. The extension supports 1672 both a classical SCTP NAT (that is, rewrite port numbers) 1673 and a, SCTP-specific variant where the ports numbers are 1674 not altered. 1676 Copyright (c) 2019 IETF Trust and the persons identified as 1677 authors of the code. All rights reserved. 1679 Redistribution and use in source and binary forms, with or 1680 without modification, is permitted pursuant to, and subject 1681 to the license terms contained in, the Simplified BSD License 1682 set forth in Section 4.c of the IETF Trust's Legal Provisions 1683 Relating to IETF Documents 1684 (http://trustee.ietf.org/license-info). 1686 This version of this YANG module is part of RFC XXXX; see 1687 the RFC itself for full legal notices."; 1689 revision 2019-11-18 { 1690 description 1691 "Initial revision."; 1692 reference 1693 "RFC XXXX: Stream Control Transmission Protocol (SCTP) 1694 Network Address Translation Support"; 1695 } 1697 feature sctp-nat { 1698 description 1699 "This feature means that SCTP-specific variant of NAT 1700 is supported. That is, avoid rewriting port numbers."; 1701 reference 1702 "Section 4.3 of RFC XXXX."; 1703 } 1705 augment "/nat:nat/nat:instances/nat:instance" 1706 + "/nat:policy/nat:timers" { 1707 when "/nat:nat/nat:instances/nat:instance" 1708 + "/nat:policy/nat:transport-protocols" 1709 + "/nat:protocol-id = 132"; 1710 description 1711 "Extends NAT policy with a timeout for SCTP mapping 1712 entries."; 1714 leaf sctp-timeout { 1715 type uint32; 1716 units "seconds"; 1717 description 1718 "SCTP inactivity timeout. That is, the time an SCTP 1719 mapping entry will stay active without packets 1720 traversing the NAT."; 1721 } 1722 } 1724 augment "/nat:nat/nat:instances/nat:instance" 1725 + "/nat:mapping-table/nat:mapping-entry" { 1726 when "nat:transport-protocol = 132"; 1727 if-feature "sctp-nat"; 1728 description 1729 "Extends the mapping entry with SCTP specifics."; 1731 leaf int-VTag { 1732 type uint32; 1733 description 1734 "The Internal Verification Tag that the internal 1735 host has chosen for this communication."; 1736 } 1737 leaf ext-VTag { 1738 type uint32; 1739 description 1740 "The External Verification Tag that the remote 1741 peer has chosen for this communication."; 1742 } 1743 } 1744 } 1745 1747 9. Socket API Considerations 1749 This section describes how the socket API defined in [RFC6458] is 1750 extended to provide a way for the application to control NAT 1751 friendliness. 1753 Please note that this section is informational only. 1755 A socket API implementation based on [RFC6458] is extended by 1756 supporting one new read/write socket option. 1758 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 1760 This socket option uses the option_level IPPROTO_SCTP and the 1761 option_name SCTP_NAT_FRIENDLY. It can be used to enable/disable the 1762 NAT friendliness for future associations and retrieve the value for 1763 future and specific ones. 1765 struct sctp_assoc_value { 1766 sctp_assoc_t assoc_id; 1767 uint32_t assoc_value; 1768 }; 1770 assoc_id This parameter is ignored for one-to-one style sockets. 1771 For one-to-many style sockets the application may fill in an 1772 association identifier or SCTP_FUTURE_ASSOC for this query. It is 1773 an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 1775 assoc_value A non-zero value indicates a NAT-friendly mode. 1777 10. IANA Considerations 1779 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1780 you assign this document.] 1782 [NOTE to RFC-Editor: The requested values for the chunk type and the 1783 chunk parameter types are tentative and to be confirmed by IANA.] 1785 This document (RFCXXXX) is the reference for all registrations 1786 described in this section. The requested changes are described 1787 below. 1789 10.1. New Chunk Flags for Two Existing Chunk Types 1791 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1792 for the ERROR chunk. The requested value for the T bit is 0x01 and 1793 for the M bit is 0x02. 1795 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1797 ERROR Chunk Flags 1798 +------------------+-----------------+-----------+ 1799 | Chunk Flag Value | Chunk Flag Name | Reference | 1800 +==================+=================+===========+ 1801 | 0x01 | T bit | [RFCXXXX] | 1802 +------------------+-----------------+-----------+ 1803 | 0x02 | M bit | [RFCXXXX] | 1804 +------------------+-----------------+-----------+ 1805 | 0x04 | Unassigned | | 1806 +------------------+-----------------+-----------+ 1807 | 0x08 | Unassigned | | 1808 +------------------+-----------------+-----------+ 1809 | 0x10 | Unassigned | | 1810 +------------------+-----------------+-----------+ 1811 | 0x20 | Unassigned | | 1812 +------------------+-----------------+-----------+ 1813 | 0x40 | Unassigned | | 1814 +------------------+-----------------+-----------+ 1815 | 0x80 | Unassigned | | 1816 +------------------+-----------------+-----------+ 1818 Table 2 1820 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1821 the ABORT chunk. The requested value of the M bit is 0x02. 1823 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1825 ABORT Chunk Flags 1826 +------------------+-----------------+-----------+ 1827 | Chunk Flag Value | Chunk Flag Name | Reference | 1828 +==================+=================+===========+ 1829 | 0x01 | T bit | [RFC4960] | 1830 +------------------+-----------------+-----------+ 1831 | 0x02 | M bit | [RFCXXXX] | 1832 +------------------+-----------------+-----------+ 1833 | 0x04 | Unassigned | | 1834 +------------------+-----------------+-----------+ 1835 | 0x08 | Unassigned | | 1836 +------------------+-----------------+-----------+ 1837 | 0x10 | Unassigned | | 1838 +------------------+-----------------+-----------+ 1839 | 0x20 | Unassigned | | 1840 +------------------+-----------------+-----------+ 1841 | 0x40 | Unassigned | | 1842 +------------------+-----------------+-----------+ 1843 | 0x80 | Unassigned | | 1844 +------------------+-----------------+-----------+ 1846 Table 3 1848 10.2. Three New Error Causes 1850 Three error causes have to be assigned by IANA. It is requested to 1851 use the values given below. 1853 This requires three additional lines in the "Error Cause Codes" 1854 registry for SCTP: 1856 Error Cause Codes 1858 +-------+--------------------------------+-----------+ 1859 | Value | Cause Code | Reference | 1860 +=======+================================+===========+ 1861 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1862 +-------+--------------------------------+-----------+ 1863 | 177 | Missing State | [RFCXXXX] | 1864 +-------+--------------------------------+-----------+ 1865 | 178 | Port Number Collision | [RFCXXXX] | 1866 +-------+--------------------------------+-----------+ 1868 Table 4 1870 10.3. Two New Chunk Parameter Types 1872 Two chunk parameter types have to be assigned by IANA. It is 1873 requested to use the values given below. IANA should assign these 1874 values from the pool of parameters with the upper two bits set to 1875 '11'. 1877 This requires two additional lines in the "Chunk Parameter Types" 1878 registry for SCTP: 1880 Chunk Parameter Types 1882 +----------+--------------------------+-----------+ 1883 | ID Value | Chunk Parameter Type | Reference | 1884 +==========+==========================+===========+ 1885 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1886 +----------+--------------------------+-----------+ 1887 | 49160 | VTags (0xC008) | [RFCXXXX] | 1888 +----------+--------------------------+-----------+ 1890 Table 5 1892 10.4. One New URI 1894 An URI in the "ns" subregistry within the "IETF XML" registry has to 1895 be assigned by IANA ([RFC3688]): 1897 URI: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1898 Registrant Contact: The IESG. 1899 XML: N/A; the requested URI is an XML namespace. 1901 10.5. One New YANG Module 1903 An YANG module in the "YANG Module Names" subregistry within the 1904 "YANG Parameters" registry has to be assigned by IANA ([RFC6020]): 1906 Name: ietf-nat-sctp 1907 Namespace: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1908 Maintained by IANA: N 1909 Prefix: nat-sctp 1910 Reference: RFCXXXX 1912 11. Security Considerations 1914 State maintenance within a NAT is always a subject of possible Denial 1915 Of Service attacks. This document recommends that at a minimum a NAT 1916 runs a timer on any SCTP state so that old association state can be 1917 cleaned up. 1919 Generic issues related to address sharing are discussed in [RFC6269] 1920 and apply to SCTP as well. 1922 For SCTP endpoints, this document does not add any additional 1923 security considerations to the ones given in [RFC4960], [RFC4895], 1924 and [RFC5061]. In particular, SCTP is protected by the verification 1925 tags and the usage of [RFC4895] against off-path attackers. 1927 The YANG module specified in this document defines a schema for data 1928 that is designed to be accessed via network management protocols such 1929 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1930 is the secure transport layer, and the mandatory-to-implement secure 1931 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1932 is HTTPS, and the mandatory-to-implement secure transport is TLS 1933 [RFC8446]. 1935 The Network Configuration Access Control Model (NACM) [RFC8341] 1936 provides the means to restrict access for particular NETCONF or 1937 RESTCONF users to a preconfigured subset of all available NETCONF or 1938 RESTCONF protocol operations and content. 1940 All data nodes defined in the YANG module that can be created, 1941 modified, and deleted (i.e., config true, which is the default) are 1942 considered sensitive. Write operations (e.g., edit-config) applied 1943 to these data nodes without proper protection can negatively affect 1944 network operations. An attacker who is able to access the SCTP NAT 1945 function can undertake various attacks, such as: 1947 * Setting a low timeout for SCTP mapping entries to cause failures 1948 to deliver incoming SCTP packets. 1950 * Instantiating mapping entries to cause NAT collision. 1952 12. Acknowledgments 1954 The authors wish to thank Mohamed Boucadair, Gorry Fairhurst, Bryan 1955 Ford, David Hayes, Alfred Hines, Karen E. E. Nielsen, Henning 1956 Peters, Maksim Proshin, Timo Voelker, Dan Wing, and Qiaobing Xie for 1957 their invaluable comments. 1959 In addition, the authors wish to thank David Hayes, Jason But, and 1960 Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for 1961 their suggestions. 1963 The authors also wish to thank Mohamed Boucadair for contributing the 1964 text related to the YANG module. 1966 13. Normative References 1968 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1969 Requirement Levels", BCP 14, RFC 2119, 1970 DOI 10.17487/RFC2119, March 1997, 1971 . 1973 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1974 DOI 10.17487/RFC3688, January 2004, 1975 . 1977 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1978 "Authenticated Chunks for the Stream Control Transmission 1979 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1980 2007, . 1982 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1983 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1984 . 1986 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1987 Kozuka, "Stream Control Transmission Protocol (SCTP) 1988 Dynamic Address Reconfiguration", RFC 5061, 1989 DOI 10.17487/RFC5061, September 2007, 1990 . 1992 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1993 the Network Configuration Protocol (NETCONF)", RFC 6020, 1994 DOI 10.17487/RFC6020, October 2010, 1995 . 1997 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 1998 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 1999 DOI 10.17487/RFC6096, January 2011, 2000 . 2002 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2003 and A. Bierman, Ed., "Network Configuration Protocol 2004 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2005 . 2007 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2008 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2009 . 2011 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2012 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2013 . 2015 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2016 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017 May 2017, . 2019 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2020 Access Control Model", STD 91, RFC 8341, 2021 DOI 10.17487/RFC8341, March 2018, 2022 . 2024 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2025 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2026 . 2028 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 2029 Vinapamula, S., and Q. Wu, "A YANG Module for Network 2030 Address Translation (NAT) and Network Prefix Translation 2031 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 2032 . 2034 14. Informative References 2036 [DOI_10.1145_1496091.1496095] 2037 Hayes, D., But, J., and G. Armitage, "Issues with network 2038 address translation for SCTP", ACM SIGCOMM Computer 2039 Communication Review Vol. 39, pp. 23, 2040 DOI 10.1145/1496091.1496095, December 2008, 2041 . 2043 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2044 RFC 793, DOI 10.17487/RFC0793, September 1981, 2045 . 2047 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2048 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2049 DOI 10.17487/RFC6269, June 2011, 2050 . 2052 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2053 Yasevich, "Sockets API Extensions for the Stream Control 2054 Transmission Protocol (SCTP)", RFC 6458, 2055 DOI 10.17487/RFC6458, December 2011, 2056 . 2058 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 2059 "Special-Purpose IP Address Registries", BCP 153, 2060 RFC 6890, DOI 10.17487/RFC6890, April 2013, 2061 . 2063 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2064 Control Transmission Protocol (SCTP) Packets for End-Host 2065 to End-Host Communication", RFC 6951, 2066 DOI 10.17487/RFC6951, May 2013, 2067 . 2069 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2070 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2071 . 2073 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2074 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2075 . 2077 Authors' Addresses 2079 Randall R. Stewart 2080 Netflix, Inc. 2081 Chapin, SC 29036 2082 United States of America 2084 Email: randall@lakerest.net 2086 Michael Tuexen 2087 Muenster University of Applied Sciences 2088 Stegerwaldstrasse 39 2089 48565 Steinfurt 2090 Germany 2092 Email: tuexen@fh-muenster.de 2094 Irene Ruengeler 2095 Muenster University of Applied Sciences 2096 Stegerwaldstrasse 39 2097 48565 Steinfurt 2098 Germany 2100 Email: i.ruengeler@fh-muenster.de