idnits 2.17.1 draft-handley-mptcp-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 19, 2009) is 5304 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Handley 3 Internet-Draft C. Raiciu 4 Intended status: Experimental University College London 5 Expires: April 22, 2010 M. Bagnulo 6 Universidad Carlos III de Madrid 7 Oct 19, 2009 9 Outgoing Packet Routing with MP-TCP 10 draft-handley-mptcp-routing-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 22, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Multipath TCP extends the TCP protocol to allow multiple paths to be 49 used simultaneously for the same TCP connection. The different paths 50 are typically provided using multiple IP addresses for the same end 51 system, each address taken from a subnet that is routed differently. 52 In this document we describe a set of conventions for how to ensure 53 that outgoing packets are routed in a manner consistent with the 54 network topology and constraints on use of that topology such as 55 those imposed by ingress filtering on IP address prefixes. 57 Table of Contents 59 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Multi-addressed Hosts . . . . . . . . . . . . . . . . . . . . 3 62 4. Idealized Host Routing Model . . . . . . . . . . . . . . . . . 5 63 4.1. Interaction with NATs . . . . . . . . . . . . . . . . . . 6 64 5. MP-TCP Interaction with Host Routing . . . . . . . . . . . . . 7 65 5.1. TCP Active End-System Behaviour . . . . . . . . . . . . . 7 66 5.2. Passive Open of MP-TCP Subflows . . . . . . . . . . . . . 8 67 6. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Multi-interface Host . . . . . . . . . . . . . . . . . . . 10 69 6.2. Single-interface Host at Multihomed Site . . . . . . . . . 10 70 6.2.1. Different Next-hop Routers . . . . . . . . . . . . . . 11 71 6.2.2. Single Next-hop Router . . . . . . . . . . . . . . . . 11 72 7. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [1]. 83 2. Introduction 85 Multipath TCP [2] is an extension to the regular TCP protocol to 86 allow multiple subflows to be established between the same pair of 87 end systems, and for a single TCP connection to stripe its data 88 across these subflows. The intended benefits are improved 89 performance, robustness, and pooling of network capacity. In 90 principle there are many ways to identify and distinguish the packets 91 of these subflows, and to guide them towards different paths through 92 the network. One simple way to do this is to use multiple IP 93 addresses at each endpoint. 95 If a host is on a multi-homed network, or if it has multiple 96 interfaces (e.g. 3G and WiFi on a smart phone), then each of these 97 addresses can be routed via a different network provider giving path 98 diversity. For incoming traffic to the multi-addressed host, 99 conventional IP routing will guide packets to the correct network 100 link. For outgoing traffic however, destination-based routing by 101 itself is insufficient to ensure that packets are sent over the 102 appropriate paths. Not only could this reduce the diversity of paths 103 available, but ingress filtering by ISPs may cause inappropriately 104 routed packets to be dropped. This document describes a set of 105 conventions that multipath-capable end-systems can follow to maximize 106 the probability that packets reach their destination and to ensure 107 that multiple paths can in fact be utilized. 109 In the sections that follow, we will assume a particular model for 110 how an end-system routing table should function. This is both a 111 strawman and an idealized model, and it is not necessarily expected 112 that hosts will directly implement this model. The intent though is 113 to describe what we believe to be reasonable behavior rather than how 114 to implement this behavior. 116 3. Multi-addressed Hosts 118 Consider a host that has more than one network interface and that 119 wishes to send and receive regular TCP flows over these interfaces. 120 To be able to receive packets on all of these interfaces, they are 121 given IP addresses from different IP subnets. These subnets will be 122 advertised via IP routing so that they are reachable by the host's 123 intended correspondents. 125 For outgoing packets a host typically has a host routing table that 126 defines which prefixes should be routed via each possible next hop 127 router, and the choice of next hop router then determines the network 128 interface used to reach that router. For a multi-addressed host this 129 can be problematic. For the sake of example, consider the following 130 network topology: 132 ____R1____ { } 133 /a1 { } 134 A { Internet }------ B 135 \____R2_____{ } 136 a2 { } 138 Host A is directly multihomed to two ISPs, and is given address a1 by 139 one ISP and a2 by the second ISP. Such a scenario might occur when A 140 is a smart phone connected simultaneously via a 3G network and via 141 WiFi. It is communicating with server B which has a single network 142 link and a single IP address. 144 If A initiates a TCP connection to B, A's IP stack will choose the 145 next hop router based on the best path to B as determined by the host 146 routing table (often this will be via a default route). If the 147 application does not bind the local IP address, then if R1 is chosen 148 as the next hop router then address a1 will be used as the source 149 address for this connection, otherwise a2 will be used. Under such 150 circumstances, the TCP connection functions correctly. 152 If B initiates a TCP connection to A and sends the SYN to address a1, 153 then routing will route the incoming packet via R1 and hence to a1. 154 If A's best route to B is via R1, then there is no problem. However, 155 if A's best route to B is via R2, then what happens next depends on 156 the host stack implementation. Two common models are in use: 158 o If A implements a strong host model, the connection will be 159 rejected because the incoming packet arrived on the incorrect 160 network interface. 162 o If A implements a weak host model, the connection will be accepted 163 and the SYN/ACK from A to be will be sent via router R2, but with 164 source address a1. As this address does not come from the address 165 prefix allocated by ISP 2, then there is a good chance that ISP 2 166 will drop the packet in its ingress filter, believing the source 167 address to be spoofed. 169 Clearly neither of these behaviors is desirable. As a result, 170 configurations such as that shown above are generally not configured 171 unless it is expected that host A will only act in the role of a 172 client. 174 Unfortunately the configuration shown above is also the simplest case 175 where Multipath TCP, using multiple addresses to distinguish its 176 subflows, will gain any significant benefit. Not only must the 177 configuration above work for a TCP flow that successfully negotiates 178 multipath capability, but also it must work for regular TCP flows to 179 and from that multi-addressed host. 181 In fact, for Multipath TCP to be effective, even as a client, 182 modifications to the local host routing mechanism will be needed. 183 Even if A initiates two subflows with B, addressed using a1 and a2 184 respectively, if the operating system determines the next-hop router 185 (R1 or R2) purely using the host routing table, then only one 186 outgoing path to B will be used. Suppose R1 is used. Not only does 187 this fail to load-balance across the two outgoing paths, packets from 188 the a2 subflow risk being dropped as spoofed by ISP 1's ingress 189 filters. 191 To summarise: it does not make sense to configure current hosts with 192 such an addressing scheme unless they are expected to only act as 193 clients. However, for Multipath TCP to be effective, such 194 configurations will be necessary. Thus hosts implementing Multipath 195 TCP will need to also implement modifications to the local host 196 routing mechanism, so as to avoid the undesirable scenario above. 198 4. Idealized Host Routing Model 200 The idealized host routing table assumed in this document changes the 201 model described above for hosts implementing MP-TCP. This model is 202 also safe for hosts that do not implememt MP-TCP, so it may make 203 sense to make it the default behavior on some operating systems, even 204 if MP-TCP is not implemented or not configured. 206 The main change is simple, and corresponds to common routing behavior 207 found in routers: an MP-TCP host MAY have more than one host routing 208 table entry for the same IP prefix (default is just a special case of 209 a very short prefix), so long as they specify different next hop 210 routers. Each routing table entry MAY have an associated metric, 211 where a lower metric indicates that routing table entry is preferred. 213 Packets from multipath and non-multipath flows are forwarded 214 identically. The following procedure SHOULD be followed: 216 1. Identify the set of routing table entries that match the 217 destination address. These main include default routes. Of 218 these, eliminate all that do not have the longest prefix length. 220 2. If no route matches, drop the packet and inform TCP of the loss. 221 MP-TCP may be able to re-send the packet's data to a different 222 destination address. 224 3. If none of the routing table entries has a next hop on the same 225 IP subnet as the source address TCP put in the packet, send the 226 packet using the route with the lowest metric. 228 4. Otherwise at least one routing table entry has a next hop on the 229 same IP subnet as the packet's source address. Of these routes, 230 send the packet using the route with the lowest metric. 232 The motivation is that a packet should only ever be sent via a next 233 hop that has a route to the destination, but where possible a packet 234 should be sent via a subnet that is compatible with the source 235 address in the packet. Sometimes though it may not be possible to do 236 this, and we discuss these cases below. 238 An alternate behaviour for rule 3 is also acceptable, and corresponds 239 to the strong host philsophy: 241 o If none of the routing table entries has a next hop on the same IP 242 subnet as the source address TCP put in the packet, drop the 243 packet and inform TCP of the loss. 245 This alternative rule only affects behavior in a corner case that can 246 be regarded as either misconfiguration or routing failure (depending 247 on whether or not the host runs a dynamic routing protocol), and so 248 does not substantially affect the overall behavior. 250 This section has presented a strawman for how host routing should 251 behave in an MP-TCP system. This behavior is not intended to be 252 definitive; other host behaviors can be devised that will have the 253 same or similar effects when paired with a multipath transport 254 protocol. Rather, the intent of this section is to define baseline 255 behavior within which we can then define how MP-TCP should behave. 257 4.1. Interaction with NATs 259 The existence of Network Address Translators (NATs) in the network 260 does not change the forwarding behavior described above. However, if 261 a NAT is present on one of the paths out of a site, it is important 262 that a subflow continues to traverse that NAT for its entire 263 lifetime, or else never traverses that NAT at all. Thus NATs provide 264 an additional constraint on the host routing rules: 266 The routing of an existing MP-TCP subflow should not be affected by 267 the subsequent establishment of additional subflows to the same 268 destination. 270 5. MP-TCP Interaction with Host Routing 272 Having defined a strawman for how host routing should behave in a MP- 273 TCP system, we can now define how MP-TCP should interact with that 274 host routing mechanism. 276 5.1. TCP Active End-System Behaviour 278 When a regular TCP connection sends the first SYN packet to a 279 destination, the application can either bind the socket to a local IP 280 address or leave it unbound. If it is bound, the source address of 281 the SYN is chosen by the application, and the TCP session is 282 subsequently bound to this IP address. If the application leaves the 283 source address unbound, the TCP implementation typically looks at the 284 routing table to determine the next-hop router, and chooses its local 285 IP address to be the one from the subnet of the next-hop router. The 286 TCP session is then bound to this dynamically chosen address, even if 287 the host routing changes and packets are subsequently sent from a 288 different interface. 290 When a multipath TCP connection sends the first SYN packet on the 291 first subflow to a destination address, it SHOULD follow precisely 292 the same procedure as for a regular TCP connection. This applies to 293 both bound and unbound sockets. 295 When a multipath TCP wishes to establish an additional subflow to the 296 same destination address, it MUST use a either a different local IP 297 address or a different port from those of its existing subflows on 298 that connection, otherwise the new subflow cannot be distinguished 299 from the existing subflows. MP-TCP SHOULD choose a different source 300 address, if one is available, as this maximises the path diversity 301 for incoming traffic. 303 It might also be possible to establish an additional subflow using an 304 existing source address, so a different route exists via a different 305 nexthop router on that subnet. Such behavior is OPTIONAL, and 306 requires additional state to be held that binds a subflow to a 307 particular next hop router. The rules below assume a new source 308 address is always used. 310 To establish a new subflow, MP-TCP will first examine the host 311 routing table to determine the set of routes to that destination. 312 The same basic procedure is followed, similar to that used by the 313 host routing: 315 1. Identify the set of routing table entries that match the 316 destination address. Of these eliminate all that do not have the 317 longest prefix length. 319 2. If no route matches, the destination is currently unreachable, 320 and the attempt to establish a new subflow fails. The MP-TCP 321 implementation SHOULD retry with a different destination address 322 if the other end has indicated more than one. 324 3. Take the set of local IP addresses already used by the subflows 325 of this connection to this destination address. Eliminate from 326 the remaining routing table entries those where the next-hop 327 router is on the same IP subnet as any of these addresses. 329 4. If no route remains, there are no more local addresses to try to 330 this destination address, and the attempt to establish a new 331 subflow fails. The MP-TCP MAY retry with a different destination 332 address if the other end has indicated more than one. 334 5. Of the remaining routes, choose the one with the lowest metric. 335 Bind the subflow to the host's local IP address on the subnet of 336 the next hop router from this route. 338 After a subflow has been established, the IP addresses it uses are 339 fixed. The source address of all packets sent by an established 340 subflow is set by TCP, and the packets are routed using the basic 341 procedure in Section 4. 343 5.2. Passive Open of MP-TCP Subflows 345 When a regular TCP passive listener receives a TCP SYN packet, if it 346 chooses to accept the connection, the destination address in the SYN 347 packet is bound to the connection. All subsequent packets the host 348 sends on this connection will use this IP address as the source 349 address. Routing for these outgoing packets is determined by the 350 usual unipath forwarding mechanisms. 352 An MP-TCP passive listener behaves in basically the same way. If the 353 subflow is accepted, the destination address of the incoming SYN 354 packet binds the subflow to that address. All subsequent packets on 355 that subflow will be sent with that source address. 357 With an active opener, the procedure in Section 5.1 ensures subflows 358 are only established with a source addresses for which there is an 359 active (i.e., longest prefix match) route that leaves via a subnet 360 with that source address. In other words, additional subflows will 361 only be established when the host believes it can use the source 362 address in a way that (from its point of view) is congruent with 363 routing. 365 A passive listener does not have this luxury. The destination 366 address of the incoming SYN packet determines the local IP address 367 bound to the subflow. There are two distinct cases to consider, 368 depending on the addresses in the SYN packet and the active routes on 369 the listening host. 371 o Congruent Routing: The incoming SYN binds the connection to a 372 local IP address, and there is an active route back to the 373 destination via a next-hop router on that subnet. In this case 374 the host routing is congruent with the local address chosen, so 375 the forwarding rules present no problem. 377 o Incongruent Routing: The incoming SYN binds the connection to a 378 local IP address, but there is no active route back to the 379 destination via any next-hop router on that subnet. If there is 380 no route to the destination at all, then the connection cannot be 381 established. However, if there is a route via some other subnet 382 then the OS has the option of using it, even though it knows the 383 routing is not congruent with the addressing. This is less than 384 ideal: although the OS knows that incoming packets can still reach 385 it at the address in question, it does not have the control it 386 would wish over outgoing packets, nor can it be sure that outgoing 387 packets will not be filtered by an ISP's ingress filtering. If 388 the incoming SYN packet is attempting to establish a new subflow 389 on an existing MP-TCP connection that already has a congruently 390 routed and active subflow, then MP-TCP SHOULD reject the new 391 subflow, as the connection is already functioning acceptably. If 392 there is no congruent active subflow, the OS has the option of 393 either dropping the connection or accepting it. If the OS chooses 394 to accept the connection, it SHOULD also immediately attempt to 395 establish a second subflow using the correct source address for 396 the route to the destination. 398 Discussion: the non-congruent routing case might be considered to be 399 a case of misconfigured routing on the host. It would also be 400 reasonable behavior to fail to establish such TCP connections, 401 multipath or otherwise. If the OS implementor chooses to allow such 402 connections, then it might also be reasonable to pin the connection 403 to the outgoing interface upon which the connection was successfully 404 established. There is a strict tradeoff here between fragility in 405 the presence of NATs and the ability for a host to re-route 406 connections based on dynamic routing information. This problem is 407 not specific to MP-TCP but occurs with regular TCP too. The behavior 408 above chooses neither to drop not to pin, and seems a reasonable 409 compromise in this tradeoff space. 411 Aside: depending on the final MP-TCP protocol spec, it may be 412 possible for an MP-TCP passive lister to send a SYN/ACK from an IP 413 address that is different from that in the initial SYN, and for the 414 client to correctly bind the subflow to the TCP state. If this is 415 possible, it solves the second scenario above. However it raises 416 security questions, as it may make it simpler to hijack TCP sessions, 417 and so we do not currently recommend such behavior. 419 6. Example Scenarios 421 The forwarding rules and MP-TCP behavior described above can be 422 applied, no matter what the configuration of the MP-TCP host. 423 However, it is worth examining several specific scenarios that are 424 likely to be common to examine how the routing can be applied. 426 6.1. Multi-interface Host 428 A common scenario is one where a host has more than one interface 429 over which it can route to the destination. This is typified by a 430 smart phone (or other wireless device) that has both 3G and WiFi 431 connectivity. 433 In such a case, it is expected that each interface is given a unique 434 address from the subnet on which that interface resides. If each 435 interface also has a route (of the same longest prefix length) that 436 allows the host to reach the destination, then MP-TCP can be applied 437 precisely as described in Section 4 and Section 5. 439 6.2. Single-interface Host at Multihomed Site 441 Another common usage scenario is where a host has only a single 442 interface, but it is located at a site that is multihomed to more 443 than one ISP. For MP-TCP to balance in-bound traffic across the 444 access links, the multiple links must be associated with different IP 445 prefixes, and the hosts within the site must have more than one IP 446 address. 448 There are two distinct scenarios to consider: 450 o Different next-hop IP routers on the host's LAN are associated 451 with each prefix. 453 o The same physical router on the host's LAN is associated with all 454 the prefixes. 456 For simplicity, it is worth considering these two cases separately. 458 6.2.1. Different Next-hop Routers 460 In this scenario the host has more than one IP address and logically 461 resides on more than one subnet. It sees different outgoing routers 462 on each of these subnets. These subnets behave as if they were 463 different virtual interfaces from the point of view of routing, then 464 MP-TCP can be applied precisely as described in Section 4 and 465 Section 5. 467 Although this scenario is quite limited, we believe it is also very 468 common. For flexibility reasons, it appears than many data centers 469 consist of a hierarchical L2 switch fabric on which the servers and 470 routers reside. 472 6.2.2. Single Next-hop Router 474 In this scenario the host also has more than one IP address and 475 logically resides on more than one subnet. However the topology is 476 such that only a single physical router is used to forward outgoing 477 traffic. The actual routers used to connect to the organization's 478 ISPs can be multiple IP hops away from the MP-TCP-capable server. 480 In such a scenario the host cannot itself directly control the path 481 taken by the outgoing traffic. If such a host naively uses the 482 forwarding rules from Section 4 and Section 5, then outgoing traffic 483 will not be balanced across the outgoing links, as it will all be 484 forwarded within the site purely on the destination address in the 485 packets. Perhaps worse, it is possible that packets with an IP 486 address from one ISP are sent via the link from the other ISP, and 487 that ISP implements ingress filtering and discards the packets. 489 We note that this scenario is actually worse with regular TCP, as 490 such a host cannot retry with a different address. Thus such 491 scenarios tend not to be configured in practice. However, it is 492 clearly desirable for such sites to be able to take advantage of the 493 benefits of MP-TCP; under such a scenario regular TCP must also work 494 well. A number of possibilities seem to be available: 496 o Deploy source-address-based routing within the site for outgoing 497 traffic. The normal MP-TCP host routing behavior can then be 498 used. 500 o Configure more than one virtual-router instance on the physical 501 router. From the host's point of view, the network then appears 502 to be one with multiple routers, one for each subnet, so normal 503 MP-TCP host routing behavior can be used. It then becomes the 504 router's responsibility to ensure that the packets reach the 505 correct outgoing routers. This is simple if the router is 506 directly connected to the exit routes, or if MPLS is used within 507 the site. Tunneling might also be used to direct the traffic to 508 the correct exit router. 510 o Configure the hosts to tunnel their outgoing traffic to the exit 511 routers. These tunnels would appear as virtual interfaces, so the 512 normal MP-TCP host routing behavior can be used over these virtual 513 interfaces. 515 o Use IP loose source routing to direct the traffic via the correct 516 exit router. This would require a configuration change on the 517 hosts. In addition, the LSRR option frequently causes traffic to 518 be dropped in firewalls. Thus if this option were used, it would 519 be advisable for the site exit routers to strip the option before 520 forwarding off-site. 522 It is not yet clear whether some of these options are preferable to 523 others. It is likely that different solutions may make most sense at 524 different sites. Some sites might even find it simplest to change 525 the topology so that the existing routers are on the same L2 526 infrastructure as the MP-TCP hosts. 528 7. IPv6 Considerations 530 The descriptions above are intended to be agnostic as to whether IPv4 531 or IPv6 is used. However, IPv6 adds some additional complexity. 533 In IPv6, router advertisement messages are sent using link-local IPv6 534 addresses. Thus even though a host may have a globally routable 535 address on an interface, and may know that this interface corresponds 536 to a particular IPv6 subnet, the router's address in the host routing 537 table is not useful to identify the subnet address and hence to 538 determine the choice of the host's routable address. 540 The solution to this problem is for the host to maintain a binding 541 table that maps the router's host address to the subnet's routable 542 prefix. This binding table MAY be filled in when the host receives a 543 router advertisement message from the router indicating the subnet 544 prefix. 546 We note that this slightly overloads the purpose of a router 547 advertisement message, to indicate that this router is a valid next 548 hop for packets sourced from this prefix. This does not seem to be a 549 significant departure from current practice, but it is possible that 550 it may change the outgoing routing on existing deployments. 552 8. Security Considerations 554 This document discusses the binding of TCP and MP-TCP connections to 555 IP addresses, which has the potential to change the way traffic is 556 routed in networks. This does not introduce any new security risks 557 per-se, but any change to how traffic is routed might cause network 558 administrators assumptions about where traffic flows to be incorrect. 559 However, the traffic only flows via routers for which the hosts have 560 route table entries, so the emphasis for administrators is to ensure 561 that host routing is configured in a way that matches security 562 assumptions. 564 The use of network-based mechansims to route outgoing traffic might 565 open up new avenues for attack. This document does not discuss these 566 mechanisms in sufficient detail to merit a discussion of their 567 security or other properties here. 569 9. Normative References 571 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 572 Levels", BCP 14, RFC 2119, March 1997. 574 [2] Ford, A. and C. Raiciu, "TCP Extenstions for Multipath Operation 575 with Multiple Addresses", draft-ford-mptcp-multiaddressed (work 576 in progress), July 2009. 578 Authors' Addresses 580 Mark Handley 581 University College London 582 Department of Computer Science 583 Gower St. 584 London WC1E 6BT 585 UK 587 Phone: +44 20 7679 7296 588 Email: m.handley@cs.ucl.ac.uk 589 Costin Raiciu 590 University College London 591 Department of Computer Science 592 Gower St. 593 London WC1E 6BT 594 UK 596 Phone: +44 20 7679 3666 597 Email: C.Raiciu@cs.ucl.ac.uk 599 Marcelo Bagnulo 600 Universidad Carlos III de Madrid 601 Av. Universidad 30 602 Leganes, Madrid 28911 603 Spain 605 Phone: +34 91 6248814 606 Email: marcelo@it.uc3m.es