idnits 2.17.1 draft-stewart-natsupp-tsvwg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (December 21, 2009) is 5239 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 392, 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: 4 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 24, 2010 I. Ruengeler 6 Muenster Univ. of Applied Sciences 7 December 21, 2009 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-stewart-natsupp-tsvwg-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 to IETF 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), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 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 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on June 24, 2010. 55 Copyright Notice 57 Copyright (c) 2009 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 4. Problem space overview . . . . . . . . . . . . . . . . . . . . 4 76 5. Handling of internal port number and verification tag 77 collisions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 6. Handling of internal port number collisions . . . . . . . . . . 6 79 7. Handling of missing state . . . . . . . . . . . . . . . . . . . 7 80 8. Multi Point Traversal considerations . . . . . . . . . . . . . 8 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Security considerations . . . . . . . . . . . . . . . . . . . . 9 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 Stream Control Transmission Protocol [RFC4960] provides a reliable 92 communications channel between two end-hosts in many ways similar to 93 TCP [RFC0793]. With the widespread deployment of Network Address 94 Translators (NAT), specialized code has been added to NAT for TCP 95 that allows multiple hosts to reside behind a NAT and yet use only a 96 single globally unique IPv4 address, even when two hosts (behind a 97 NAT) choose the same port numbers for their connection. This 98 additional code is sometimes classified as Network Address and Port 99 Translation or NAPT. To date, specialized code for SCTP has NOT yet 100 been added to most NATs so that only true NAT is available. The end 101 result of this is that only one SCTP capable host can be behind a 102 NAT. 104 This document describes an SCTP specific chunks and procedures to 105 help NAT's provide similar features of NAPT in the single point and 106 multi-point traversal scenario. An SCTP implementation supporting 107 this extension will follow these procedures to assure that in both 108 single homed and multi-homed cases a NAT will maintian the proper 109 state without needing to change port numbers. 111 A NAT will need to follow these proceedures for generating 112 appropriate SCTP packet formats. NAT's should refer to 113 xxxxbehavedraftxxx for the BCP in using these formats. 115 2. Conventions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Terminology 123 For this discussion we will use several terms, which we will define 124 and point out in a figure. 126 o Private-Address (Priv-Addr) - The private address that is known to 127 the internal host. 129 o Internal-Port (Int-Port) - The port number that is in use by the 130 host holding the Private-Address. 132 o Internal-VTag (Int-VTag) - The Verification Tag that the internal 133 host has chosen for its communication. The VTag is a unique 32 134 bit tag that must accompany any incoming SCTP packet for this 135 association to the Private-Address. 137 o External-Address (Ext-Addr) - The address that an internal host is 138 attempting to contact. 140 o External-Port (Ext-Port) - The port number of the peer process at 141 the External-Address. 143 o External-VTag (Ext-VTag) - The Verification Tag that the host 144 holding the External-Address has chosen for its communication. 145 The VTag is a unique 32 bit tag that must accompany any incoming 146 SCTP packet for this association to the External-Address. 148 o Public-Address (Pub-Addr) - The public address assigned to the NAT 149 box which it uses as a source address when sending packets towards 150 the External-Address. 152 Internal Network | External Network 153 | 154 Private | Public External 155 +---------+ Address | Address /--\/--\ Address +---------+ 156 | SCTP | +-----+ / \ | SCTP | 157 |end point|==========| NAT |======= | Internet | ========== |end point| 158 | A | +-----+ \ / | B | 159 +---------+ Internal | \--/\--/ External +---------+ 160 Internal Port | Port External 161 VTag | VTag 163 4. Problem space overview 165 When an SCTP endpoint is behind a NAT which supports xxxnatdraftxxx a 166 number of problems may arise as it trys to communicate with its peer. 168 o More than one server behind a NAT may pick the same V-Tag and 169 source port when talking to the same peer server. This creates a 170 situation where the NAT will not be able to tell the two 171 associations apart. This situation is discussed in Section 5 173 o When an SCTP endpoint is a server and talking with multiple peers 174 and the peers are behind the same NAT, to the server the two 175 endpoints cannot be distinguished. This case is discussed in 176 Section 6. 178 o A NAT could at one point during a conversation restart causing all 179 of its state to be lost. This problem and its solution is 180 discussed in Section 7. 182 o An SCTP endpoint may be behind two NAT's giving it redundancy. 183 The method to set up this scenario is discussed in Section 8. 185 Each of these solutions requires additional chunks and parameters, 186 defined in this document, and possibly modified handling procedures 187 from those specified in [RFC4960]. 189 5. Handling of internal port number and verification tag collisions 191 Consider the case where two hosts in the Private-Address space want 192 to set up an SCTP association with the same server running on the 193 same host in the Internet. This means that the External-Port and the 194 External-Address are the same. If they both choose the same 195 Internal-Port and Internal-VTag, the NAT box cannot distinguish 196 incoming packets anymore. But this is very unlikely. The Internal- 197 VTags are chosen at random and if the Internal-Ports are also chosen 198 from the ephemeral port range at random this gives a 46 bit random 199 number which has to match. In the TCP like NAPT case the NAT box can 200 control the 16 bit Natted Port. 202 However, in this unlikely event the NAT box MUST respond to the INIT 203 chunk by sending an ABORT chunk with the M-bit set. The M-bit is a 204 new bit defined by this document to express to SCTP that the source 205 of this packet is a "middle" box, not the peer SCTP endpoint. The 206 source address of the packet containing the ABORT chunk MUST be the 207 destination address of the SCTP packet containing the INIT chunk. 209 The sender of the packet containing the INIT chunk, upon reception of 210 an ABORT with M-bit set SHOULD reinitiate the association setup 211 procedure after choosing a new initiate tag. These proceedures 212 SHOULD be followed only if the appropriate error cause code for 213 colliding NAT table state is included AND the association is in the 214 COOKIE-WAIT state (i.e. it is awaiting a INIT-ACK). If the endpoint 215 is in any other state an SCTP endpoint SHOULD NOT respond. 217 The ABORT chunk defined in [RFC4960] is therefore extended by using 218 the following format: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type = 6 | Reserved |M|T| Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 \ \ 226 / zero or more Error Causes / 227 \ \ 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 The following error cause with cause code 0x00B0 (Colliding NAT table 231 entry) MUST be included in the ABORT chunk: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Cause Code=0x00B0 | Cause Length=Variable | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 \ INIT chunk / 239 / \ 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 6. Handling of internal port number collisions 244 When two SCTP hosts are behind a NAT and using the recommendations in 245 xxxxbehavexxx it is possible that two SCTP hosts in the Private- 246 Address space will want to set up an SCTP association with the same 247 server running on the same host in the Internet. For the NAT 248 appropriate tracking may be performed by assuring that the vtags are 249 unique between the two hosts as defined in xxxxbehavexxx. But for 250 the external SCTP server on the internet this means that the 251 External-Port and the External-Address are the same. If they both 252 have chosen the same Internal-Port the server cannot distinguish both 253 associations based on the address and port numbers. For the server 254 it looks like the association is being restarted. To overcome this 255 limitation the client sends a DISABLE_RESTART parameter in the INIT- 256 chunk which is defined as follows: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type = 0xC007 | Length=4 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 When the server receives this parameter it MUST do the following: 266 o Include in the INIT-ACK a DISABLE_RESTART parameter to inform the 267 client that it will support the feature. 269 o Disable the restart procdures defined in [RFC4960] for this 270 association. 272 Servers that support this feature will need to be capable of 273 maintaining multiple connections to what appears to be the same peer 274 (behind the NAT) differentiated only by the vtags. 276 7. Handling of missing state 278 If the NAT box receives a packet for which the lookup procedure does 279 not find an entry in the NAT table, a packet containing an ERROR 280 packet is sent back with the M-bit set. The source address of the 281 packet containing the ERROR chunk MUST be the destination address of 282 the incoming SCTP packet. The verification tag is reflected. 284 The ERROR chunk defined in [RFC4960] is therefore extended by using 285 the following format: 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 | Type = 9 | Reserved |M|T| Length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 \ \ 293 / zero or more Error Causes / 294 \ \ 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The following error cause with cause code 0x00B1 (Missing NAT table 298 entry) SHOULD be included in the ERROR chunk: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Cause Code=0x00B1 | Cause Length=Variable | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 \ Incoming Packet / 306 / \ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Upon reception by an SCTP end-point with this ERROR chunk the 310 receiver SHOULD take the following actions: 312 o Validate the verifcation tag is reflected by looking at the V-tag 313 that would have been included in the outgoing packet. 315 o Validate that the peer of the SCTP assocation supports the dynamic 316 address extension, if it does not discard the incoming ERROR 317 chunk. 319 o Generate a new ASCONF chunk as defined below including both sets 320 of V-tags so that the NAT may recover the appropriate state. The 321 procedures for generating an ASCONF can be found in [RFC5061] 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Parameter Type = 0xC008 | Parameter Length = 16 | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | ASCONF-Request Correlation ID | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Internal Verification Tag | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | External Verification Tag | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 If the NAT box receives a packet for which it has no NAT table entry 336 and the packet contains an ASCONF chunk with a vtag parameter, the 337 NAT box MUST update its NAT table according to the verification tags 338 in the vtag parameter. 340 The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either 341 add the address and respond with an acknowledgment, if the address is 342 new to the assocation (following all procedures defined in 343 [RFC5061]). Or, if the address is already part of the association, 344 the SCTP endpoint MUST NOT respond with an error, but instead should 345 respond with an ASCONF-ACK acknowledging the address but take no 346 action (since the address is already in the association). 348 8. Multi Point Traversal considerations 350 If a multi-homed SCTP end-point behind a NAT connects to a peer, it 351 SHOULD first set up the association single-homed with only one 352 address causing the first NAT to populate its state. Then it SHOULD 353 adds each IP address using ASCONF chunks sent via their respective 354 NATs. The address to add is the wildcard address and the lookup 355 address SHOULD also contain the vtag parameter pair illustrated 356 above. 358 9. IANA Considerations 360 TBD 362 10. Security considerations 364 TBD 366 11. Acknowledgments 368 The authors wish to thank Qiaobing Xie, Henning Peters, Bryan Ford, 369 David Hayes, Alfred Hines, Dan Wing, and Jason But for their 370 invaluable comments. 372 12. References 374 12.1. Normative References 376 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 377 RFC 793, September 1981. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 383 RFC 4960, September 2007. 385 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 386 Kozuka, "Stream Control Transmission Protocol (SCTP) 387 Dynamic Address Reconfiguration", RFC 5061, 388 September 2007. 390 12.2. Informative References 392 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 393 E. Lear, "Address Allocation for Private Internets", 394 BCP 5, RFC 1918, February 1996. 396 Authors' Addresses 398 Randall R. Stewart 399 Huawei 400 Chapin, SC 29036 401 USA 403 Phone: 404 Email: rstewart@huawei.com 406 Michael Tuexen 407 Muenster Univ. of Applied Sciences 408 Stegerwaldstr. 39 409 48565 Steinfurt 410 Germany 412 Email: tuexen@fh-muenster.de 414 Irene Ruengeler 415 Muenster Univ. of Applied Sciences 416 Stegerwaldstr. 39 417 48565 Steinfurt 418 Germany 420 Email: i.ruengeler@fh-muenster.de