idnits 2.17.1 draft-coene-sctp-multihome-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7620 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 section? 'RFC2960' on line 411 looks like a reference -- Missing reference section? 'IPsec-SCTP' on line 424 looks like a reference -- Missing reference section? 'RFC2663' on line 416 looks like a reference -- Missing reference section? 'RFC2694' on line 420 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT L. Coene 3 Internet Engineering Task Force Siemens 4 Issued: June 2003 5 Expires: December 2003 7 Multihoming issues in the Stream Control Transmission Protocol 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may 16 also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Abstract 30 This document describes issues of the Stream Control Transmission 31 Protocol (SCTP)[RFC2960] in regard to multihoming on the 32 Internet. It explores cases where through situations in the 33 internet, single points-of-failure can occur even when using 34 multihoming and what the impact is of multihoming on the routing 35 tables of the host. 37 Table of Contents 39 Multihoming issues in the Stream Control Transmission Protocol . ii 40 Chapter 1: Introduction ........................................ 2 41 Chapter 2: SCTP multihoming .................................... 3 42 Chapter 2.1: Architecture of SCTP multihoming .................. 3 43 Chapter 2.2: Interaction with routing .......................... 3 44 Chapter 2.3: SCTP multihoming and the size of routing tables ... 7 45 Chapter 2.4: SCTP multihoming and Network Adress 46 Translators(NAT) ............................................... 8 47 Chapter 2.5: SCTP multihoming and IPsec ........................ 9 48 Chapter 3: Security considerations ............................. 9 49 Chapter 4: References and related work ......................... 10 50 Chapter 5: Acknowledgments ..................................... 10 51 Chapter 6: Author's address .................................... 11 53 1 Introduction 55 SCTP[RFC2960] is a transport protocol that uses multihoming. This 56 draft is an attempt at identifying the issues that may arise in the 57 layers below SCTP when multihoming is used by SCTP. Some issues are 58 already being addresses in various other WGs and this document will 59 try to highlight them. If the solutions would resolve the issues 60 presented in this document then the problem presented is no longer 61 an issue. This document will also try to gauge the effectiveness of 62 the present multihoming architecture. 64 1.1 Terminology 66 The following terms are commonly identified in this work: 68 Association: SCTP connection between two endpoints. 70 Transport address: A combination of IP address and SCTP port number. 72 Multihoming: Assigning more than one IP network interface to a 73 single endpoint. 75 TLA: Top Level Aggregation 77 1.2 Contributors 79 The following people contributed to the document: L. Coene(Editor), 80 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 81 M. Holdrege, M.C. Belinchon, A. Jungmaier, and L. Ong. 83 2 SCTP multihoming 85 2.1 Architecture of SCTP multihoming 87 A single message transmitted over an SCTP association from the 88 originating host to the destination host will be sent using a single 89 destination IP address chosen from the set of destination IP 90 addresses available for that association. The paths used by the IP 91 packets across the network might be different depending on the 92 destination IP address. If a message fails to reach its 93 destination, SCTP may retransmit the message using a different 94 destination IP address. 96 SCTP does not have any way to determine whether two paths share 97 links and routers when traversing the network. 99 The route of a path through a network can be static(example manual 100 configuration) or dynamic(via routing protocols such as OSPF, 101 BGP...). The route that a path takes through the network will change 102 over time according to the routing protocols or routing decisions 103 employed by the IP network layer. 105 If somewhere along the path a link or/and router fails then SCTP can 106 detect the failure of the path via a heartbeat message(or in the 107 worst case by the halting of the regular traffic). These actions 108 done by SCTP are independant of the actions performed by the lower 109 layers for failure detection and restoration and might de done in 110 different timescales. 112 2.2 Interaction with routing 114 For fault resilient communication between two SCTP endpoints, the 115 multihoming feature needs more than one IP network interface for 116 each endpoint. The number of paths used is the minimum of network 117 interfaces used by any of the endpoints. It is recommended to bind 118 the association to all the IP source addresses of the endpoint. 119 Eeach network interface can have more than one IP address. 121 Under the assumption that every IP address will have a different, 122 seperate path towards the remote endpoint, (this is the 123 responsibility of the routing protocols or of manual configuration) 124 , if the transport to one of the IP addresses (= 1 particular path) 125 fails then the traffic can migrate to the other remaining IP address 126 (= other paths) within the SCTP association. 128 +------------+ *~~~~~~~~~* +------------+ 129 | Endpoint A | * Cloud * | Endpoint B | 130 | 1.2 +---------+ 1.1<--->3.1 +----------+ 3.2 | 131 | | | | | | 132 | 2.2 +---------+ 2.1<--->4.1 +----------+ 4.2 | 133 | | * * | | 134 +------------+ *~~~~~~~~~* +------------+ 136 Figure 2.1.1: Two hosts with redundant networks. 138 Consider figure 2.1.1, if the host routing tables look as follows 139 the endpoint will achieve maximum use of the multi-homing feature: 141 Endpoint A Endpoint B 142 Destination Gateway Destination Gateway 143 ------------------------ ------------------------- 144 3.0 1.1 1.0 3.1 145 4.0 2.1 2.0 4.1 147 Now if you consider figure 2.1.1, if the host routing table looks as 148 follows, the association is subject to a single point of failure in 149 that if any interface breaks, the whole association will break(See 150 figure 2.1.2). 152 Host A Host B 153 Destination Gateway Destination Gateway 154 ------------------------ ------------------------- 155 3.0 1.1 1.0 4.1 156 4.0 2.1 2.0 3.1 158 Example: link 4.2-4.1 fails 160 Primary path: link 1.2-1.1 - link 3.1-3.2 161 Second Path : Link 2.2-2.1 - link 4.1-4.2 163 Endpoint A 164 +-------+--------+------+ 165 |S= 1.2 | D= 3.2 | DATA | ------->----- Arrives at Endpoint B 166 +-------+--------+------+ 168 Endpoint B answers with SACK 169 +-------+--------+------+ 170 |S= 4.2 | D= 1.2 | SACK | Gets lost, because send out on the failed 171 +-------+--------+------+ 4.1-4.2 link 172 After X time, retransmit on the other path by endpoint A 174 Endpoint A 175 +-------+--------+------+ 176 |S= 2.2 | D= 4.2 | DATA | Is send out on link 2.2-2.1, but gets lost, 177 +-------+--------+------+ as msg has to pass via failed 4.1-4.2 link 179 The same scenario will play out for failures on the other links 181 Note : S = Source address 182 D = Destination address 184 Figure 2.1.2: Single point of failure case in redundant network 185 due to routing table in host B 187 When an endpoint selects its source address, careful consideration 188 must be taken. If the same source address is always used, then it is 189 possible that the endpoint will be subject to the same single point 190 of failure illustrated above. If possible the endpoint should always 191 select the source address of the packet to correspond to the IP 192 address of the Network interface where the packet will be emitted. 194 +------------+ *~~~~~~~~~* +------------+ 195 | Endpoint A | * Cloud * | Endpoint B | 196 | 1.2 +---------+ 1.1<--+ | | | 197 | | | |->3.1|----------+ 3.2 | 198 | 2.2 +---------+ 2.1<--+ | | | 199 | | * * | | 200 +------------+ *~~~~~~~~~* +------------+ 202 Figure 2.1.3: Two hosts with asymmetric networks. 204 In Figure 2.1.3 consider the following host routing table: 206 Endpoint A Endpoint B 207 Destination Gateway Destination Gateway 208 ------------------------ ------------------------- 209 3.0 1.1 1.0 3.1 210 2.0 3.1 212 In this case the fault tolerance becomes limited by two seperate 213 issues. If the path between 3.1 and 3.2 breaks in both directions 214 any association will break between endpoint A and endpoint B. The 215 second failure will occur for the whole the association as well due 216 to a breakage between 1.2 and 1.1 in both directions, since no 217 alternative route exists to 3.2 and all traffic is being routed 218 through one interface. 220 Now one of these issues can be remedied by the following: In Figure 221 2.1.3 consider the following host routing table: 223 Endpoint A Endpoint B 224 Destination Gateway Destination Gateway 225 ------------------------ ------------------------- 226 3.0 1.1 1.0 3.1 227 3.0 2.1 2.0 3.1 229 The SCTP implementation on Endpoint A needs to consider both the 230 source and destination address when identifying the transport. If 231 it treats 1.2/3.2 as a separate transport address from 2.2/3.2, 232 normal SCTP failover mechanisms work correctly. This mechanism is 233 suggested in RFC 2960. 235 If the underlying OS does not support multiple routes to the same 236 destination, or if the SCTP implementation can not control which 237 route gets used (as is typical for user space implementations), we 238 can still solve this issue by the following modification even when 239 only one interface exists on endpoint B. 241 +------------+ *~~~~~~~~~~* +------------+ 242 | Endpoint A | * Cloud * | Endpoint B | 243 | 1.2 +---------+ 1.1<---+ | | | 244 | | | +->3.1+----------+ 3.2 & 4.2 | 245 | 2.2 +---------+ 2.1<---+ | | | 246 | | * * | | 247 +------------+ *~~~~~~~~~~* +------------+ 249 Figure 2.1.4: Two hosts with asymmetric networks, but symmetric 250 addresses. 252 In Figure 2.1.4 consider the following host routing table: 254 Endpoint A Endpoint B 255 Destination Gateway Destination Gateway 256 ------------------------ ------------------------- 257 3.0 1.1 1.0 3.1 258 4.0 2.1 2.0 3.1 260 Now with the duplicate IP addresses assigned to the same interface 261 and the above routing tables, even if the interface between 1.1 and 262 1.2 breaks, an association will still survive this failure. 264 As a practical matter, it is recommended that IP addresses in a 265 multihomed endpoint be assigned IP endpoints from different TLA's to 266 ensure against network failure. 268 In IP implementations the outgoing interface of multihomed hosts is 269 often determined by the destination IP address. The mapping is done 270 by a lookup in a routing table maintained by the operating 271 system. Therefore the outgoing interface is not determined by SCTP. 272 Using such implementations, it should be noted that a multihomed 273 host cannot make use of the multiple local IP addresses if the peer 274 is singlehomed. The multihomed host has only one path and will 275 normally use only one of its interfaces to send the SCTP datagrams 276 to the peer. If this physical path fails, the IP routing table in 277 the multihome host has to be changed. This problem is out of scope 278 for SCTP. 280 SCTP will always send its traffic to a certain transport address (= 281 destination address + port number combination) for as long as the 282 transmission is uninterrupted (= primary). The other transport 283 addresses (secondary paths) will act as a backup in case the primary 284 path goes out of service. The changeover between primary and backup 285 will occur without packet loss and is completely transparent to the 286 application. The secondary path can also be used for 287 retransmissions(per section 6.4 of [RFC2960]). 289 The port number is the same for all transport addresses of that 290 specific association. 292 Applications directly using SCTP may choose to control the 293 multihoming service themselves. The applications have then to supply 294 the specific IP address to SCTP for each outbound user message. This 295 might be done for reasons of load-sharing and load-balancing across 296 the different paths. This might not be advisable as the throughput 297 of any of the paths is not known in advance and constantly changes 298 due to the actions of other associations and transport protocols 299 along that particular path, would require very tight feedback of 300 each of the paths to the loadsharing functions of the user. 302 By sending a heartbeat chunk/message (=SCTP internal keep alive 303 message) on all the multiple paths that are not used for active 304 transmission of messages across the association, it is possible for 305 SCTP to detect whether one or more paths have failed. SCTP will not 306 use these failed paths when a changeover is required. 308 The transmission rate of sending heartbeat messages should be 309 modifiable and the possible loss of the heartbeat message could be 310 used for the monitoring and measurements of the concerned paths. 312 2.3 SCTP multihoming and the size of routing tables 314 As multihoming means that more than one destination address is used 315 on the host, that would mean that a routing descision must be made 316 on the host in IP. The host does not know beforehand to which other 317 host it is going to send something, so that would in theory require 318 that all possible paths to all possible destinations should be known 319 on that host. This amounts to the host being a part of the 320 distribution of the routing information in the network. 322 Possible solutions would require to ask only for the paths to host 323 that are actually in use(meaning a association is about to be setup 324 with that particular host). This is a viable solution for hosts with 325 a small number of associations to different hosts. 327 If the host has many associations with a lot of different host then 328 then this becomes cumbersome(getting the specific paths from the 329 routers and the updates and all) and leads in practice to same 330 problem of distributing prefixes from the edge router(s) to the 331 host. 333 It might be useful to explore ways where no distribution of routing 334 information to the host for using multihoming is needed or where the 335 interface/link selection is not based on the use of different 336 prefixes. Not all hosts have facilities for containing possible 337 large routing tables/databases. 339 2.4 SCTP multihoming and Network Adress Translators(NAT) 341 For multihoming the NAT must have a public IP address for each 342 represented internal IP address. The host can preconfigure IP 343 address that the NAT can substitute. Or the NAT can have internal 344 Application Layer Gateway (ALG) which will intelligently translate 345 the IP addresses in the INIT and INIT ACK chunks. See Figure 1. 347 If Network Address Port Translation is used with a multihomed SCTP 348 endpoint, then any port translation must be applied on a 349 per-association basis such that an SCTP endpoint continues to 350 receive the same port number for all messages within a given 351 association. 353 +-------+ +----------+ *~~~~~~~~~~* +------+ 354 |Host A | | NAT | * Cloud * |Host B| 355 | 10.2 +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2 | 356 | 11.2 +---+ 11.1|6.2 | | +->4.2--+---------+ 2.2 | 357 | | | | * * | | 358 +-------+ +----------+ *~~~~~~~~~* +------+ 360 Fig 1: SCTP through NAT with multihoming 362 It should be noted that the NAT box becomes a single 363 point-of-failure in this case, as ALL the paths of the SCTP 364 association have to go through that single NAT box. 366 2.5 SCTP multihoming and IPsec 368 IPsec was not designed to support multihomed connections and that 369 imposes some difficulties when using IPsec with SCTP hosts that make 370 use of several addresses in a single association. 372 The Security Policy Database (SPD) entries should use as selectors, 373 among other fields of the IP header, the source and destination 374 address. The easy and expensive way to scale the SPD to multihomed 375 host, is simply creating a new entry for all the possible 376 combinations of source and a destination addresses. A much better 377 implementation approach is to simply use groups of addresses instead 378 of single ones. 380 The same problem arises when identifying a Security Association 381 (SA). An SA should be identified by the extended triplet ({set of 382 destination addresses}, Security Parameter Index, Security 383 Protocol). 385 Moreover, when exchanging keys using the Internet Key Exchange (IKE) 386 protocol there are some extra difficulties. IKE only allows the use 387 of a single source and destination address, and so the initial 388 solution to the problem would be creating a number S*D of SAs, where 389 S is the number of source addresses, and D the number of destination 390 addresses. This solution unnecessarily consumes both time and 391 resources. Other more complex and suitable approaches would need 392 modifications in IKE itself. 394 A specific discussion about the problems that crop up when using 395 IPsec with SCTP can be seen in [IPsec-SCTP]. All SCTP+IPSEC 396 implementations would have to do the above to be compatible 398 3 Security considerations 400 SCTP only tries to increase the availability of a network. SCTP does 401 not contain any protocol mechanisms which are directly related to 402 user message authentication, integrity and confidentiality 403 functions. For such features, it depends on the IPSEC protocols and 404 architecture and/or on security features of its user protocols. 406 The solutions needed for allowing multihoming may provide security 407 risks. 409 4 References and related work 411 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 412 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 413 L. and Paxson, V."Stream Control Transmission Protocol", RFC2960, 414 October 2000. 416 [RFC2663] Srisuresh, P. and Holdrege, M., "IP Network Address 417 Translator (NAT) Terminology and Considerations", RFC2663, August 418 1999 420 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and Heffernan, 421 A., "DNS extensions to Network Address Translators (DNS_ALG)", 422 RFC2694, September 1999 424 [IPsec-SCTP] Bellovin, S. M., Ioannidis, J., Keromytis, A. D. and 425 Stewart, R. R., "On the Use of SCTP with IPsec", 426 draft-ietf-ipsec-sctp-06.txt, work in progress 428 5 Acknowledgments 430 This document was initially developed by a design team consisting of 431 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, 432 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas 433 Jungmaier, Gery Verwimp and Lyndon Ong. 435 The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer, 436 J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, 437 T. George, M. Stillman, N. Makinae, S. Bradner, A. Mankin, 438 G. Camarillo, H. Schulzrinne, R. Kantola, J. Rosenberg, 439 I. Arias-Rodriguez, D. Lehmann, La Monte Henry Yaroll, P. Savola, 440 H. Alvestrand and many others for their invaluable comments. 442 6 Author's Address 444 The following authors have contributed to this document. 446 Lode Coene Phone: +32-14-252081 447 Siemens Atea EMail: lode.coene@siemens.com 448 Atealaan 34 449 B-2200 Herentals 450 Belgium 452 Expires: December 31, 2003 454 Full Copyright Statement 456 Copyright (C) The Internet Society (2003). All Rights Reserved. 458 This document and translations of it may be copied and furnished to 459 others, and derivative works that comment on or otherwise explain 460 it or assist in its implementation may be prepared, copied, published 461 and distributed, in whole or in part, without restriction of any 462 kind, provided that the above copyright notice and this paragraph 463 are included on all such copies and derivative works. However, this 464 document itself may not be modified in any way, such as by 465 removing the copyright notice or references to the Internet Society or 466 other Internet organizations, except as needed for the purpose of 467 developing Internet standards in which case the procedures for 468 copyrights defined in the Internet Standards process must be 469 followed, or as required to translate it into languages other than 470 English. 472 The limited permissions granted above are perpetual and will not 473 Be revoked by the Internet Society or its successors or assigns. 475 This document and the information contained herein is provided on 476 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 477 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 478 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 479 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 480 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.