idnits 2.17.1 draft-blanchet-mif-problem-statement-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 5, 2009) is 5438 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-chown-addr-select-considerations-02 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet Ed. 3 Internet-Draft Viagenie 4 Intended status: Informational P. Seite 5 Expires: December 7, 2009 France Telecom 6 June 5, 2009 8 Multiple Interfaces Problem Statement 9 draft-blanchet-mif-problem-statement-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 7, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 A multihomed host receives node configuration information from each 58 of its access networks. Some configuration objects are global to the 59 node, some are local to the interface. Various issues arise when 60 multiple conflicting node-scoped configuration objects are received 61 on multiple interfaces. Similar situations also happen with single 62 interface host connected to multiple networks. This document 63 describes these issues. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4 70 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4 71 3.2. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 4 72 3.3. Mobility and other IP protocols . . . . . . . . . . . . . 5 73 3.4. Address Selection . . . . . . . . . . . . . . . . . . . . 5 74 3.5. Interactive Connectivity Establishment (ICE) . . . . . . . 5 75 3.6. Socket API . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.7. Above IP Layers . . . . . . . . . . . . . . . . . . . . . 6 77 4. Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 6 79 4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 8 81 4.4. Single Interface on Multiple Networks . . . . . . . . . . 8 82 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 87 10. Discussion home for this draft . . . . . . . . . . . . . . . . 10 88 11. Informative References . . . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 A multihomed host has multiple network interfaces (physical and/or 94 virtual). For example, a node may be simultaneously connected to a 95 wired Ethernet LAN, a 802.11 LAN, a 3G cell network, one or multiple 96 VPN connections or one or multiple automatic or manual tunnels. 97 Current laptops and smartphones typically have multiple access 98 network interfaces that are simultaneously connected to networks. 100 A multihomed host receives node configuration information from each 101 of its access networks, through various mechanims such as DHCPv4 102 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router 103 Advertisements [RFC4861]. Some received configuration objects are 104 specific to an interface such as the IP address and the link prefix. 105 Others are typically considered by implementations as being global to 106 the node, such as the routing information (e.g. default gateway), DNS 107 servers IP addresses and address selection policies. 109 When the received node-scoped configuration objects have different 110 values from each access network, such as different DNS servers IP 111 addresses, different default gateways or different address selection 112 policies, the node has to decide which it will use or how it will 113 merge them. 115 Several issues regarding how the node-scoped configuration objects 116 are used in a multihomed node environment have been raised. The 117 following sections define the MIF host and the scope of this 118 document, describe related work, list the symptoms and then the 119 underlying problems. 121 A companion document [I-D.mrw-mif-current-practices] discusses 122 current practices. 124 2. Terminology 126 A MIF host is defined as: 127 o a [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host 128 o configured with more than one IP addresses (excluding loopback, 129 link-local) 130 o on one or more active interfaces, as presented to the IP stack. 131 o The interfaces may be logical, virtual or physical. 132 o The IP addresses come from more than one administrative domains. 133 (Note to WG: some people say "one or more than one"; some say 134 "more than one". TBDiscussed) 135 o The IP addresses may be from the same or from different address 136 families, such as IPv4 and IPv6. 138 o Communications using these IP addresses may happen simultaneously 139 and independently. 140 o While the MIF host may forward packets between its interfaces, 141 forwarding packets is not taken into account in this definition. 143 When a protocol keyword such as IP, PPP, DHCP is used without any 144 reference to a specific IP version, then it implies both IPv4 and 145 IPv6. A specific IP version keyword such as DHCPv4 or DHCPv6 is 146 specific to that IP version. 148 3. Scope and Existing Work 150 This section describes existing related work and defines the scope of 151 the problem. 153 3.1. Below IP Interaction 155 Network discovery and selection on lower layers as defined by 156 [RFC5113] is out of scope of this document. Moreover, lower layer 157 interaction such as IEEE 802.21 is also out of scope. 159 Proxy MIP allows sharing a single IP address across multiple interfac 160 es (e.g., WiMAX and CDMA, LTE and HSPA, etc) to disparate networks. 161 From the IP stack view on the node, there is only a single interface 162 and single IP address. Therefore, this situation is out of scope. 163 Furthermore, link aggregation done under IP where a single interace 164 is shown to the IP stack is also out of scope. 166 3.2. Hosts Requirements 168 The requirements for Internet Hosts [RFC1122] describe the multihomed 169 host as if it has multiple IP addresses, which may be associated with 170 one or more physical interfaces connected to the same or different 171 networks. 173 The host maintains a route cache table where each entry contains the 174 local IP address, the destination IP address, Type-of-Service and 175 Next-hop gateway IP address. The route cache entry would have data 176 about the properties of the path, such as the average round-trip 177 delay measured by a transport protocol. 179 As per [RFC1122], two models are defined: 180 o The "Strong" host model defines a multihomed host as a set of 181 logical hosts within the same physical host. In this model a 182 packet must be sent on an interface that corresponds to the source 183 address of that packet. 185 o The "Weak" host model describes a host that has some embedded 186 gateway functionality. In the weak host model, the host can send 187 and receive packets on any interface. 189 The multihomed host computes routes for outgoing datagrams 190 differently depending on the model. Under the strong model, the 191 route is computed based on the source IP address, the destination IP 192 address and the Type-of-Service. Under the weak model, the source IP 193 address is not used, but only the destination IP address and the 194 Type-of-Service. 196 3.3. Mobility and other IP protocols 198 This document assumes hosts only implementing [RFC1122] for IPv4 and 199 [RFC4294] for IPv6, and not using any kind of new transport 200 protocols. It is not required for the host to support additional IP 201 mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP, 202 HIP, RRG, LISP or else. Moreover, the peer of the connection is also 203 not required to use these mechanisms. 205 3.4. Address Selection 207 The Default Address Selection [RFC3484] defines algorithms for source 208 and destination IP address selections. It is mandatory to be 209 implemented in IPv6 nodes, which also means dual-stack nodes. A 210 node-scoped policy table managed by the IP stack is defined. 211 Provisions are made to change or update the policy table, however, no 212 mechanism is defined. 214 Issues on using the Default Address Selection were found [RFC5112] in 215 the context of multiple prefixes on the same link. New work 216 [I-D.chown-addr-select-considerations] discusses the multiple 217 attached networks scenarios and how to update the policy table. 219 3.5. Interactive Connectivity Establishment (ICE) 221 Interactive Connectivity Establishment (ICE [I-D.ietf-mmusic-ice]) is 222 a technique for NAT traversal for UDP-based (and TCP) media streams 223 established by the offer/answer model. The multiplicity of IP 224 addresses and ports in SDP offers are tested for connectivity by 225 peer-to-peer connectivity checks. The result is candidate IP 226 addresses and ports for establishing a connection with the other 227 peer. 229 ICE does not solve the MIF issues, such as the incompatible 230 configuration objects received on different interfaces. However, ICE 231 may be of use for address selection if the application is ICE- 232 enabled. 234 3.6. Socket API 236 Application Programming Interface (API) may expose objects that user 237 applications may use for the MIF purpose. For example, [RFC3542] 238 shows how an application using the Advanced sockets API can specify 239 the interface or the source IP address, through simple bind() 240 operation or IPV6_PKTINFO socket option. 242 An API is also defined [RFC5014] to influence the default address 243 selection mechanism by specifying attributes of the source addresses 244 it prefers. 246 3.7. Above IP Layers 248 The MIF issues discussed in this document assume no changes in 249 transport protocols or applications. However, fixing the issues 250 might involve these layers. 252 4. Symptoms 254 This section describes the various symptoms found using a MIF host 255 that has already received configuration objects from its various 256 access networks. 258 These situations are also described in 259 [I-D.savolainen-6man-fqdn-based-if-selection], [I-D.yang-mif-req] and 260 [RFC4477]. They occur, for example, when: 261 1. one interface is on the Internet and one is on a corporate 262 private network. The latter may be through VPN. 263 2. one interface is on one access network (i.e. wifi) and the other 264 one is on another access network (3G) with specific services. 266 4.1. DNS resolution issues 268 A MIF host (H1) has an active interface(I1) connected to a network 269 (N1) which has its DNS server (S1) and another active interface (I2) 270 connected to a network (N2) which has its DNS server (S2). S1 serves 271 with some private namespace "private.example.com". The user or the 272 application uses a name "a.private.example.com" which is within the 273 private namespace of S1 and only resolvable by S1. Any of the 274 following situations may occur: 275 1. H1 stack, based on its routing table, uses I2 to reach S1 to 276 resolve "a.private.example.com". H1 never reaches S1. The name 277 is not resolved. 278 2. H1 keeps only one set of DNS server addresses from the received 279 configuration objects and kept S2 address. H1 sends the DNS A 280 query for a.private.example.com to S2. S2 responds with an error 281 for an non-existant domain (NXDOMAIN). The name is not resolved. 282 3. H1 keeps only one set of DNS server addresses from the received 283 configuration objects and kept S2 address. H1 sends the DNS A 284 query for a.private.example.com to S2. S2 asks its upstream DNS 285 and gets an IP address for a.private.example.com. However, the 286 IP address is not the right one S1 would have given. Therefore, 287 the application tries to connect to the wrong destination host, 288 which may imply security issues. 289 4. TBD: example with different address families. 291 4.2. Routing 293 A MIF host (H1) has an active interface(I1) connected to a network 294 (N1) and another active interface (I2) connected to a network (N2). 295 The user or the application is trying to reach an IP address (IP1). 296 Any of the following situations may occur: 297 1. For the IP1 address family, H1 has one default route (R1, R2) per 298 network (N1, N2). IP1 is only reachable by N2. H1 stack uses R1 299 and tries to send through I1. IP1 is never reached or is not the 300 right target. 301 2. For the IP1 address family, H1 has one default route (R1, R2) per 302 network (N1, N2). IP1 is reachable by both networks, but N2 path 303 has better characterictics, such as better round-trip time, least 304 cost, better bandwidth, etc.... These preferences could be 305 defined by user, by the provider, by discovery or else. H1 stack 306 uses R1 and tries to send through I1. IP1 is reached but the 307 service would be better by I2. 308 3. For the IP1 address family, H1 has a default route (R1), a 309 specific X.0.0.0/8 route R1B (eg. RFC1918 prefix) to N1 and a 310 default route (R2) to N2. IP1 is reachable by N2 only, but the 311 prefix (X.0.0.0/8) is used in both networks. Because of the most 312 specific route R1B, H1 stack sends through I2 and never reach the 313 target. 315 A MIF host may have multiple routes to a destination. However, by 316 default, it does not have any hint concerning which interface would 317 be the best to use for that destination. For example, as discussed 318 in [I-D.savolainen-6man-fqdn-based-if-selection], 319 [I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], a 320 service provider might want to influence the routing table of the 321 host connecting to its network. 323 A host usually has a node-scoped routing table. Therefore, when a 324 MIF host is connected to multiple networks and each service provider 325 wants to influence the routing table of the host, then conflicts 326 might arise from the multiple routing information being pushed to the 327 host. 329 A user on such multihomed host might want a local policy to influence 330 which interface will be used based on various conditions. 332 On a MIF host, some source addresses are not valid if used on some 333 interfaces. For example, an RFC1918 source address might be 334 appropriate on the VPN interface but not on the public interface of 335 the MIF host. If the source address is not chosen appropriately, 336 then sent packets might be filtered in the path if source address 337 filtering is in place ([RFC2827],[RFC3704]) and reply packets might 338 never come back to the source. 340 4.3. Address Selection Policy 342 A MIF host (H1) has an active interface(I1) connected to a network 343 (N1) and another active interface (I2) connected to a network (N2). 344 The user or the application is trying to reach an IP address (IP1). 345 Any of the following situations may occur: 346 1. H1 receives from both networks (N1 and N2) an update of its 347 default address selection policy. However, the policies are 348 specific to each network. The policies are merged by H1 stack. 349 Based on the merged policy, the chosen source address is from N1 350 but packets are sent to N2. The source address is not reachable 351 from N2, therefore the return packet is lost. 352 2. TBD: add more 354 Merging address selection policies may have important impacts on 355 routing. 357 4.4. Single Interface on Multiple Networks 359 When a MIF host using a single interface is connected to multiple 360 networks with different default routers, similar issues as described 361 above happen. 363 5. Problems 365 This section tries to list the underlying problems corresponding to 366 the issues discussed in the previous section. 367 1. Routing tables are usually node-scoped. 368 2. DNS server addresses and other configuration objects (NTP 369 servers, ...) are usually node-scoped. 370 3. Same configuration objects (eg DNS server addresses, NTP server 371 addresses, ..) received from multiple interfaces or networks are 372 usually overwritten. 373 4. Default Address Selection policies are usually node-scoped. 375 5. Default Address Selection policies may differ when received on 376 different interfaces. 377 6. Host implementations usually do not implement the [RFC1122] 378 strong model where the source address is in the routing table. 379 7. Host implementations usually do not implement the [RFC1122] 380 model where the Type-of-Service are in the routing table. 381 8. Host implementations usually do not keep path characteristics, 382 user or provider preferences in the routing table. 383 9. Applications usually do not use advanced APIs to specify the 384 source IP address or to set preferences on the address selection 385 policies. 386 10. DNS answers are usually not kept with the interface from which 387 the answer comes from. 388 11. Host implementations usually do not keep separate network 389 configuration (such as DNS server addresses) per interface. 391 6. Summary 393 A MIF host receives node configuration information from each of its 394 access networks. Some configuration objects are global to the node, 395 some are local to the interface. Various issues arise when multiple 396 conflicting node-scoped configuration objects are received on 397 multiple interfaces. Similar situations also happen with single 398 interface host connected to multiple networks. Therefore, there is a 399 need to define the appropriate behavior of an IP stack and possibly 400 define protocols to manage these cases. 402 7. Security Considerations 404 The problems discussed in this document have security implications, 405 such as when the packets sent on the wrong interface might be leaking 406 some confidential information. Moreover, the undetermined behavior 407 of IP stacks in the multihomed context bring additional threats where 408 an interface on a multihomed host might be used to conduct attacks 409 targeted to the networks connected by the other interfaces. 411 8. IANA Considerations 413 This document has no actions for IANA. 415 9. Acknowledgements 417 The initial Internet-Drafts prior to the MIF working group and the 418 discussions during the MIF BOF meeting and on the mailing list around 419 the MIF charter scope on the mailing list brought very good input to 420 the problem statement. This draft steals a lot of text from these 421 discussions and the initial drafts. Therefore, the editor would like 422 to acknowledge the following people (in no specific order), from 423 which some text has been taken from: Jari Arkko, Keith Moore, Sam 424 Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie Volz, Giyeong 425 Son, Gabriel Montenegro, Christian Vogt, Lars Eggert, Margaret 426 Wasserman, Hui Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi 427 Denis-Courmont, Carl Williams, Pierrick Seite. Sorry if some 428 contributors have not been named. 430 10. Discussion home for this draft 432 This document is intended to define the problem space discussed in 433 the mif@ietf.org mailing list. 435 11. Informative References 437 [I-D.chown-addr-select-considerations] 438 Chown, T., "Considerations for IPv6 Address Selection 439 Policy Changes", draft-chown-addr-select-considerations-02 440 (work in progress), March 2009. 442 [I-D.hui-ip-multiple-connections-ps] 443 Hui, M. and H. Deng, "Problem Statement and Requirement of 444 Simple IP Multi-homing of the Host", 445 draft-hui-ip-multiple-connections-ps-02 (work in 446 progress), March 2009. 448 [I-D.ietf-mmusic-ice] 449 Rosenberg, J., "Interactive Connectivity Establishment 450 (ICE): A Protocol for Network Address Translator (NAT) 451 Traversal for Offer/Answer Protocols", 452 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 454 [I-D.mrw-mif-current-practices] 455 Wasserman, M., "Current Practices for Multiple Interface 456 Hosts", draft-mrw-mif-current-practices-02 (work in 457 progress), March 2009. 459 [I-D.savolainen-6man-fqdn-based-if-selection] 460 Savolainen, T., "Domain name based network interface 461 selection", 462 draft-savolainen-6man-fqdn-based-if-selection-00 (work in 463 progress), October 2008. 465 [I-D.yang-mif-req] 466 Yang, P., Seite, P., Williams, C., and J. Qin, 467 "Requirements on multiple Interface (MIF) of simple IP", 468 draft-yang-mif-req-00 (work in progress), March 2009. 470 [RFC1122] Braden, R., "Requirements for Internet Hosts - 471 Communication Layers", STD 3, RFC 1122, October 1989. 473 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 474 RFC 1661, July 1994. 476 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 477 RFC 2131, March 1997. 479 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 480 Defeating Denial of Service Attacks which employ IP Source 481 Address Spoofing", BCP 38, RFC 2827, May 2000. 483 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 484 and M. Carney, "Dynamic Host Configuration Protocol for 485 IPv6 (DHCPv6)", RFC 3315, July 2003. 487 [RFC3484] Draves, R., "Default Address Selection for Internet 488 Protocol version 6 (IPv6)", RFC 3484, February 2003. 490 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 491 "Advanced Sockets Application Program Interface (API) for 492 IPv6", RFC 3542, May 2003. 494 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 495 Networks", BCP 84, RFC 3704, March 2004. 497 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 498 April 2006. 500 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 501 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 502 Issues", RFC 4477, May 2006. 504 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 505 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 506 September 2007. 508 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 509 Socket API for Source Address Selection", RFC 5014, 510 September 2007. 512 [RFC5112] Garcia-Martin, M., "The Presence-Specific Static 513 Dictionary for Signaling Compression (Sigcomp)", RFC 5112, 514 January 2008. 516 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 517 Discovery and Selection Problem", RFC 5113, January 2008. 519 Authors' Addresses 521 Marc Blanchet 522 Viagenie 523 2600 boul. Laurier, suite 625 524 Quebec, QC G1V 4W1 525 Canada 527 Email: Marc.Blanchet@viagenie.ca 528 URI: http://www.viagenie.ca 530 Pierrick Seite 531 France Telecom 533 Email: pierrick.seite@orange-ftgroup.com