idnits 2.17.1 draft-ietf-tsvwg-natsupp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC0793], [RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2010) is 4894 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) == Unused Reference: 'RFC1918' is defined on line 445, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Huawei 4 Intended status: Standards Track M. Tuexen 5 Expires: June 2, 2011 I. Ruengeler 6 Muenster Univ. of Applied Sciences 7 November 29, 2010 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-00.txt 13 Abstract 15 Stream Control Transmission Protocol [RFC4960] provides a reliable 16 communications channel between two end-hosts in many ways similar to 17 TCP [RFC0793]. With the widespread deployment of Network Address 18 Translators (NAT), specialized code has been added to NAT for TCP 19 that allows multiple hosts to reside behind a NAT and yet use only a 20 single globally unique IPv4 address, even when two hosts (behind a 21 NAT) choose the same port numbers for their connection. This 22 additional code is sometimes classified as Network Address and Port 23 Translation or NAPT. To date, specialized code for SCTP has NOT yet 24 been added to most NATs so that only pure NAT is available. The end 25 result of this is that only one SCTP capable host can be behind a 26 NAT. 28 This document describes an SCTP specific chunks and procedures to 29 help NAT's provide similar features of NAPT in the single point and 30 multi-point traversal scenario. 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 http://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 June 2, 2011. 49 Copyright Notice 51 Copyright (c) 2010 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 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Problem space overview . . . . . . . . . . . . . . . . . . . . 5 70 5. Handling of internal port number and verification tag 71 collisions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6. Handling of missing state . . . . . . . . . . . . . . . . . . 7 73 6.1. Multi Point Traversal considerations . . . . . . . . . . . 8 74 6.2. Handling of internal port number collisions . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 Stream Control Transmission Protocol [RFC4960] provides a reliable 86 communications channel between two end-hosts in many ways similar to 87 TCP [RFC0793]. With the widespread deployment of Network Address 88 Translators (NAT), specialized code has been added to NAT for TCP 89 that allows multiple hosts to reside behind a NAT and yet use only a 90 single globally unique IPv4 address, even when two hosts (behind a 91 NAT) choose the same port numbers for their connection. This 92 additional code is sometimes classified as Network Address and Port 93 Translation or NAPT. To date, specialized code for SCTP has NOT yet 94 been added to most NATs so that only true NAT is available. The end 95 result of this is that only one SCTP capable host can be behind a 96 NAT. 98 This document describes an SCTP specific chunks and procedures to 99 help NAT's provide similar features of NAPT in the single point and 100 multi-point traversal scenario. An SCTP implementation supporting 101 this extension will follow these procedures to assure that in both 102 single homed and multi-homed cases a NAT will maintian the proper 103 state without needing to change port numbers. 105 A NAT will need to follow these proceedures for generating 106 appropriate SCTP packet formats. NAT's should refer to 107 xxxxbehavedraftxxx for the BCP in using these formats. 109 When considering this feature it is possible to have multiple levels 110 of support. At each level, the Internal Host, External Host and NAT 111 may or may not support the features described in this document. The 112 following table illustrates the results of the various combinations 113 of support and if communications can occur between two endpoints. 115 +---------------+------------+---------------+---------------+ 116 | Internal Host | NAT | External Host | Communication | 117 +---------------+------------+---------------+---------------+ 118 | Supports | Supports | Supports | Yes | 119 | Support | No Support | No Support | None | 120 | Support | Support | No Support | Limited | 121 | No Support | No Support | Support | None | 122 | Support | No Support | Support | None | 123 | No Support | Support | Support | Limited | 124 | No Support | No Support | No Support | None | 125 +---------------+------------+---------------+---------------+ 127 From the table we can see that when a NAT does not support the 128 extension no communication can occur. This is for the most part the 129 current situation i.e. SCTP packets sent externally from behind a 130 NAT are discarded by the NAT. In some cases, where the NAT supports 131 the feature but one of the two external hosts does NOT support the 132 feature communication may occur but in a limited way. For example 133 only one host may be able to have a connection when a collision case 134 occurs. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Terminology 144 For this discussion we will use several terms, which we will define 145 and point out in a figure. 147 o Private-Address (Priv-Addr) - The private address that is known to 148 the internal host. 150 o Internal-Port (Int-Port) - The port number that is in use by the 151 host holding the Private-Address. 153 o Internal-VTag (Int-VTag) - The Verification Tag that the internal 154 host has chosen for its communication. The VTag is a unique 32 155 bit tag that must accompany any incoming SCTP packet for this 156 association to the Private-Address. 158 o External-Address (Ext-Addr) - The address that an internal host is 159 attempting to contact. 161 o External-Port (Ext-Port) - The port number of the peer process at 162 the External-Address. 164 o External-VTag (Ext-VTag) - The Verification Tag that the host 165 holding the External-Address has chosen for its communication. 166 The VTag is a unique 32 bit tag that must accompany any incoming 167 SCTP packet for this association to the External-Address. 169 o Public-Address (Pub-Addr) - The public address assigned to the NAT 170 box which it uses as a source address when sending packets towards 171 the External-Address. 173 Internal Network | External Network 174 | 175 Private | Public External 176 +---------+ Address | Address /--\/--\ Address +---------+ 177 | SCTP | +-----+ / \ | SCTP | 178 |end point|==========| NAT |======= | Internet | ========== |end point| 179 | A | +-----+ \ / | B | 180 +---------+ Internal | \--/\--/ External +---------+ 181 Internal Port | Port External 182 VTag | VTag 184 4. Problem space overview 186 When an SCTP endpoint is behind a NAT which supports xxxnatdraftxxx a 187 number of problems may arise as it trys to communicate with its peer. 189 o More than one server behind a NAT may pick the same V-Tag and 190 source port when talking to the same peer server. This creates a 191 situation where the NAT will not be able to tell the two 192 associations apart. This situation is discussed in Section 5 194 o When an SCTP endpoint is a server and talking with multiple peers 195 and the peers are behind the same NAT, to the server the two 196 endpoints cannot be distinguished. This case is discussed in 197 Section 6.2. 199 o A NAT could at one point during a conversation restart causing all 200 of its state to be lost. This problem and its solution is 201 discussed in Section 6. 203 o An SCTP endpoint may be behind two NAT's giving it redundancy. 204 The method to set up this scenario is discussed in Section 6.1. 206 Each of these solutions requires additional chunks and parameters, 207 defined in this document, and possibly modified handling procedures 208 from those specified in [RFC4960]. 210 5. Handling of internal port number and verification tag collisions 212 Consider the case where two hosts in the Private-Address space want 213 to set up an SCTP association with the same server running on the 214 same host in the Internet. This means that the External-Port and the 215 External-Address are the same. If they both choose the same 216 Internal-Port and Internal-VTag, the NAT box cannot distinguish 217 incoming packets anymore. But this is very unlikely. The Internal- 218 VTags are chosen at random and if the Internal-Ports are also chosen 219 from the ephemeral port range at random this gives a 46 bit random 220 number which has to match. In the TCP like NAPT case the NAT box can 221 control the 16 bit Natted Port. 223 However, in this unlikely event the NAT box MUST respond to the INIT 224 chunk by sending an ABORT chunk with the M-bit set. The M-bit is a 225 new bit defined by this document to express to SCTP that the source 226 of this packet is a "middle" box, not the peer SCTP endpoint. The 227 source address of the packet containing the ABORT chunk MUST be the 228 destination address of the SCTP packet containing the INIT chunk. 230 The sender of the packet containing the INIT chunk, upon reception of 231 an ABORT with M-bit set SHOULD reinitiate the association setup 232 procedure after choosing a new initiate tag. These proceedures 233 SHOULD be followed only if the appropriate error cause code for 234 colliding NAT table state is included AND the association is in the 235 COOKIE-WAIT state (i.e. it is awaiting a INIT-ACK). If the endpoint 236 is in any other state an SCTP endpoint SHOULD NOT respond. 238 The ABORT chunk defined in [RFC4960] is therefore extended by using 239 the following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type = 6 | Reserved |M|T| Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 \ \ 247 / zero or more Error Causes / 248 \ \ 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 The following error cause with cause code 0x00B0 (Colliding NAT table 252 entry) MUST be included in the ABORT chunk: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Cause Code=0x00B0 | Cause Length=Variable | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 \ INIT chunk / 260 / \ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 6. Handling of missing state 265 If the NAT box receives a packet for which the lookup procedure does 266 not find an entry in the NAT table, a packet containing an ERROR 267 packet is sent back with the M-bit set. The source address of the 268 packet containing the ERROR chunk MUST be the destination address of 269 the incoming SCTP packet. The verification tag is reflected. 271 The ERROR chunk defined in [RFC4960] is therefore extended by using 272 the following format: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type = 9 | Reserved |M|T| Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 \ \ 280 / zero or more Error Causes / 281 \ \ 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 The following error cause with cause code 0x00B1 (Missing NAT table 285 entry) SHOULD be included in the ERROR chunk: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Cause Code=0x00B1 | Cause Length=Variable | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 \ Incoming Packet / 293 / \ 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Upon reception by an SCTP end-point with this ERROR chunk the 297 receiver SHOULD take the following actions: 299 o Validate the verifcation tag is reflected by looking at the V-tag 300 that would have been included in the outgoing packet. 302 o Validate that the peer of the SCTP assocation supports the dynamic 303 address extension, if it does not discard the incoming ERROR 304 chunk. 306 o Generate a new ASCONF chunk as defined below including both sets 307 of V-tags so that the NAT may recover the appropriate state. The 308 procedures for generating an ASCONF can be found in [RFC5061] 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Parameter Type = 0xC008 | Parameter Length = 16 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | ASCONF-Request Correlation ID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Internal Verification Tag | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | External Verification Tag | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 If the NAT box receives a packet for which it has no NAT table entry 323 and the packet contains an ASCONF chunk with a vtag parameter, the 324 NAT box MUST update its NAT table according to the verification tags 325 in the vtag parameter. 327 The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either 328 add the address and respond with an acknowledgment, if the address is 329 new to the assocation (following all procedures defined in 330 [RFC5061]). Or, if the address is already part of the association, 331 the SCTP endpoint MUST NOT respond with an error, but instead should 332 respond with an ASCONF-ACK acknowledging the address but take no 333 action (since the address is already in the association). 335 6.1. Multi Point Traversal considerations 337 If a multi-homed SCTP end-point behind a NAT connects to a peer, it 338 SHOULD first set up the association single-homed with only one 339 address causing the first NAT to populate its state. Then it SHOULD 340 adds each IP address using ASCONF chunks sent via their respective 341 NATs. The address to add is the wildcard address and the lookup 342 address SHOULD also contain the vtag parameter pair illustrated 343 above. 345 6.2. Handling of internal port number collisions 347 When two SCTP hosts are behind a NAT and using the recommendations in 348 xxxxbehavexxx it is possible that two SCTP hosts in the Private- 349 Address space will want to set up an SCTP association with the same 350 server running on the same host in the Internet. For the NAT 351 appropriate tracking may be performed by assuring that the vtags are 352 unique between the two hosts as defined in xxxxbehavexxx. But for 353 the external SCTP server on the internet this means that the 354 External-Port and the External-Address are the same. If they both 355 have chosen the same Internal-Port the server cannot distinguish both 356 associations based on the address and port numbers. For the server 357 it looks like the association is being restarted. To overcome this 358 limitation the client sends a DISABLE_RESTART parameter in the INIT- 359 chunk which is defined as follows: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type = 0xC007 | Length=4 | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 When the server receives this parameter it MUST do the following: 369 o Include in the INIT-ACK a DISABLE_RESTART parameter to inform the 370 client that it will support the feature. 372 o Disable the restart procdures defined in [RFC4960] for this 373 association. 375 Servers that support this feature will need to be capable of 376 maintaining multiple connections to what appears to be the same peer 377 (behind the NAT) differentiated only by the vtags. 379 The NAT, when processing the INIT-ACK, should note in its internal 380 table that the external server supports the DISABLE_RESTART 381 extension. This note is used when establishing future associations 382 (i.e. when processing an INIT from an internal host) to decide if the 383 connection should be allowed. The NAT MUST do the following when 384 processing an INIT: 386 o If the INIT is destined to an external address and port for which 387 the NAT has no outbound connection, allow the INIT creating an 388 internal mapping table. 390 o If the INIT matches the external address and port of an already 391 existing connection, validate that the external server supports 392 the DISABLE_RESTART feature. If it does allow the INIT to be 393 forwarded. 395 o If the external server does NOT support the DISABLE_RESTART 396 extension the NAT MUST send an ABORT with the 'M' bit set. 398 The following error cause with cause code 0x00B2 (Duplicate Local 399 Port with DISABLE_RESTART not Supported) MUST be included in the 400 ABORT chunk: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Cause Code=0x00B2 | Cause Length=Variable | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 \ INIT chunk / 408 / \ 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 7. IANA Considerations 413 TBD 415 8. Security considerations 417 TBD 419 9. Acknowledgments 421 The authors wish to thank Qiaobing Xie, Henning Peters, Bryan Ford, 422 David Hayes, Alfred Hines, Dan Wing, and Jason But for their 423 invaluable comments. 425 10. References 427 10.1. Normative References 429 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 430 RFC 793, September 1981. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 436 RFC 4960, September 2007. 438 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 439 Kozuka, "Stream Control Transmission Protocol (SCTP) 440 Dynamic Address Reconfiguration", RFC 5061, 441 September 2007. 443 10.2. Informative References 445 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 446 E. Lear, "Address Allocation for Private Internets", 447 BCP 5, RFC 1918, February 1996. 449 Authors' Addresses 451 Randall R. Stewart 452 Huawei 453 Chapin, SC 29036 454 USA 456 Phone: 457 Email: randall@lakerest.net 459 Michael Tuexen 460 Muenster Univ. of Applied Sciences 461 Stegerwaldstr. 39 462 48565 Steinfurt 463 Germany 465 Email: tuexen@fh-muenster.de 467 Irene Ruengeler 468 Muenster Univ. of Applied Sciences 469 Stegerwaldstr. 39 470 48565 Steinfurt 471 Germany 473 Email: i.ruengeler@fh-muenster.de