idnits 2.17.1 draft-ietf-mif-problem-statement-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 date (May 9, 2011) is 4728 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4477' is defined on line 859, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-mif-current-practices-11 == Outdated reference: A later version (-05) exists of draft-ietf-mif-dhcpv6-route-option-01 == Outdated reference: A later version (-12) exists of draft-ietf-mif-dns-server-selection-02 == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-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 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Informational P. Seite 5 Expires: November 10, 2011 France Telecom - Orange 6 May 9, 2011 8 Multiple Interfaces and Provisioning Domains Problem Statement 9 draft-ietf-mif-problem-statement-15.txt 11 Abstract 13 This document describes issues encountered by a node attached to 14 multiple provisioning domains. This node receives configuration 15 information from each of its provisioning domains where some 16 configuration objects are global to the node, others are local to the 17 interface. Issues such as selecting the wrong interface to send 18 trafic happen when conflicting node-scoped configuration objects are 19 received and inappropriately used. Moreover, other issues are the 20 result of simulatenous attachment to multiple networks, such as 21 domain selection or addressing and naming space overlaps, regardless 22 of the provisioning mechanism. While multiple provisioning domains 23 are typically seen on nodes with multiple interfaces, this document 24 also discusses single interface nodes situation. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 10, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4 63 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4 64 3.2. MIF node Characterization . . . . . . . . . . . . . . . . 4 65 3.3. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Mobility and other IP protocols . . . . . . . . . . . . . 6 67 3.5. Address Selection . . . . . . . . . . . . . . . . . . . . 6 68 3.6. Finding and Sharing IP Addresses with Peers . . . . . . . 6 69 3.7. Provisioning domain selection . . . . . . . . . . . . . . 7 70 3.8. Session management . . . . . . . . . . . . . . . . . . . . 7 71 3.9. Socket API . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. MIF Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 9 74 4.2. Node Routing . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.3. Policies conflict . . . . . . . . . . . . . . . . . . . . 12 76 4.4. Session management . . . . . . . . . . . . . . . . . . . . 12 77 4.5. Single Interface on Multiple Provisioning Domains . . . . 13 78 5. Underlying problems and causes . . . . . . . . . . . . . . . . 13 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 83 10. Informative References . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 A multihomed node may have multiple provisioning domains (via 89 physical and/or virtual interfaces). For example, a node may be 90 simultaneously connected to a wired Ethernet LAN, a 802.11 LAN, a 3G 91 cell network, one or multiple VPN connections or one or multiple 92 tunnels(automatic or manual). Current laptops and smartphones 93 typically have multiple access network interfaces and, thus, are 94 often connected to different provisioning domains. 96 A multihomed node receives configuration information from each of its 97 attached networks, through various mechanisms such as DHCPv4 98 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router 99 Advertisements [RFC4861]. Some received configuration objects are 100 specific to an interface such as the IP address and the link prefix. 101 Others are typically considered by implementations as being global to 102 the node, such as the routing information (e.g. default gateway), DNS 103 servers IP addresses, and address selection policies, herein named 104 "node-scoped". 106 When the received node-scoped configuration objects have different 107 values from each provisioning domains, such as different DNS servers 108 IP addresses, different default gateways or different address 109 selection policies, the node has to decide which one to use or how it 110 will merge them. 112 Other issues are the result of simulatenous attachment to multiple 113 networks, such as addressing and naming space overlaps, regardless of 114 the provisioning mechanism. 116 The following sections define the multiple interfaces (MIF) node, the 117 scope of this work, describe related work, list issues and then 118 summarize the underlying problems. 120 A companion document [I-D.ietf-mif-current-practices] discusses some 121 current practices of various implementations dealing with MIF. 123 2. Terminology 125 Administrative domain 127 A group of hosts, routers, and networks operated and managed by a 128 single organization [RFC1136]. 130 Provisioning domain 131 A set of consistent configuration information (e.g. Default 132 router, Network prefixes, DNS,...) and the corresponding 133 interface. One administrative domain may have multiple 134 provisioning domains. Successful attachment to the provisioning 135 domain implies that the terminal attaches to the corresponding 136 interface with appropriate configuration information. 138 Reference to IP version 140 When a protocol keyword such as IP, PPP, DHCP is used in this 141 document without any reference to a specific IP version, then it 142 implies both IPv4 and IPv6. A specific IP version keyword such as 143 DHCPv4 or DHCPv6 is meant to be specific to that IP version. 145 3. Scope and Existing Work 147 This section describes existing related work and defines the scope of 148 the problem. 150 3.1. Below IP Interaction 152 Some types of interfaces have link layer characteristics which may be 153 used in determining how multiple provisioning domain issues will be 154 dealt with. For instance, link layers may have authentication and 155 encryption characteristics which could be used as criteria for 156 interface selection. However, network discovery and selection on 157 lower layers as defined by [RFC5113] is out of scope of this 158 document. Moreover, interoperability with lower layer mechanisms 159 such as services defined in IEEE 802.21, which aims at facilitating 160 handover between heterogeneous networks [MIH], is also out of scope. 162 Some mechanisms (e.g., based on a virtual IP interface) 163 allow sharing a single IP address over multiple 164 interfaces to networks with disparate access technologies. From the 165 IP stack view on the node, there is only a single interface and 166 single IP address. Therefore, this situation is out of scope of this 167 current problem statement. Furthermore, link aggregation done under 168 IP where a single interface is shown to the IP stack is also out of 169 scope. 171 3.2. MIF node Characterization 173 A MIF node has the following characteristics: 175 o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant node 176 o A MIF node is configured with more than one IP addresses 177 (excluding loopback and link-local) 178 o A MIF node can attach to more than one provisioning domains, as 179 presented to the IP stack. 180 o The interfaces may be virtual or physical. 181 o Configuration objects come from one or more administrative 182 domains. 183 o The IP addresses may be from the same or from different address 184 families, such as IPv4 and IPv6. 185 o Communications using these IP addresses may happen simultaneously 186 and independently. 187 o Some communications using these IP addresses are possible on all 188 the provisioning domains, while some are only possible on a 189 smaller set of the provisioning domains. 190 o While the MIF node may forward packets between its interfaces, 191 forwarding packets is not taken into account in this definition 192 and is out of scope for this document. 194 3.3. Hosts Requirements 196 The requirements for Internet Hosts [RFC1122] describe the multihomed 197 node as if it has multiple IP addresses, which may be associated with 198 one or more physical interfaces connected to the same or different 199 networks. 201 The requirements states that The node maintains a route cache table 202 where each entry contains the local IP address, the destination IP 203 address, Differentiated Services Code Point and Next-hop gateway IP 204 address. The route cache entry would have data about the properties 205 of the path, such as the average round-trip delay measured by a 206 transport protocol. Nowadays, implementations are not caching these 207 informations. 209 [RFC1122] defines two host models: 210 o The "Strong" host model defines a multihomed host as a set of 211 logical hosts within the same physical host. In this model a 212 packet must be sent on an interface that corresponds to the source 213 address of that packet. 214 o The "Weak" host model describes a host that has some embedded 215 gateway functionality. In the weak host model, the host can send 216 and receive packets on any interface. 218 The multihomed node computes routes for outgoing datagrams 219 differently depending on the model. Under the strong model, the 220 route is computed based on the source IP address, the destination IP 221 address and the Differentiated Services Code Point. Under the weak 222 model, the source IP address is not used, but only the destination IP 223 address and the Differentiated Services Code Point. 225 3.4. Mobility and other IP protocols 227 The scope of this document is only about nodes implementing [RFC1122] 228 for IPv4 and [RFC4294] for IPv6 without additional features or 229 special-purpose support for transport layers, mobility, multi-homing, 230 or identifier-locator split mechanisms. Dealing with multiple 231 interfaces with such mechanisms is related but considered as a 232 separate problem and is under active study elsewhere in the IETF 233 [RFC4960], [RFC5206], [RFC5533], [RFC5648], 234 [I-D.ietf-mptcp-architecture]. 236 When an application is using one interface while another interface 237 with better characteristics becomes available, the ongoing 238 application session could be transferred to the newly enabled 239 interface. However, in some cases, the ongoing session shall be kept 240 on the current interface while initiating the new sessions on the new 241 interface. The problem of the interface selection is within the MIF 242 scope and may leverage specific node functions (Section 3.8). 243 However, if transfer of IP session is required, IP mobility 244 mechanisms, such as [RFC3775], shall be used. 246 3.5. Address Selection 248 The Default Address Selection specification [RFC3484] defines 249 algorithms for source and destination IP address selections. It is 250 mandatory to be implemented in IPv6 nodes, which also means dual- 251 stack nodes. A node-scoped policy table managed by the IP stack is 252 defined. Mechanisms to update the policy table are being defined 253 [I-D.ietf-6man-addr-select-sol] to update the policy table. 255 Issues on using the Default Address Selection were found in [RFC5220] 256 and [RFC5221] in the context of multiple prefixes on the same link. 258 3.6. Finding and Sharing IP Addresses with Peers 260 Interactive Connectivity Establishment (ICE [RFC5245]) is a technique 261 for NAT traversal for UDP-based (and TCP) media streams established 262 by the offer/answer model. The multiplicity of IP addresses, ports 263 and transport in SDP offers are tested for connectivity by peer-to- 264 peer connectivity checks. The result is candidate IP addresses and 265 ports for establishing a connection with the other peer. However, 266 ICE does not solve issues when incompatible configuration objects are 267 received on different interfaces. 269 Some application protocols do referrals of IP addresses, port numbers 270 and transport for further exchanges. For instance, applications can 271 provide reachability information to itself or to a third party. The 272 general problem of referrals is related to the multiple interface 273 problem, since, in this context, referrals must provide consistent 274 information depending on which provisioning domain is used. 275 Referrals are discussed in [I-D.carpenter-referral-ps] and 276 [I-D.ietf-shim6-app-refer]. 278 3.7. Provisioning domain selection 280 In a MIF context, the node may handle simultaneously multiple domains 281 with disparate characteristics, especially when supporting multiple 282 access technologies. Selection is simple if the application is 283 restricted to one specific provisioning domain: the application must 284 start on the default provisioning domain if available, otherwise the 285 application does not start. However, if the application can be run 286 on several provisioning domains, the selection problem can be 287 difficult. 289 There is no standard method for selecting a provisioning domain but 290 some recommendation exist while restricting the scope to the 291 interface selection problem. For example, [TS23.234] proposes a 292 default mechanism for the interface selection. This method uses the 293 following information (non exhaustive list): 295 o preferences provided by the user, 296 o policies provided by network operator, 297 o quality of the radio link, 298 o network resource considerations (e.g. available QoS, IP 299 connectivity check,...), 300 o the application QoS requirements in order to map applications to 301 the best interface 303 However, [TS23.234] is designed for a specific multiple-interfaces 304 use-case. A generic way to handle these characteristics is yet to be 305 defined. 307 3.8. Session management 309 Some implementations, specially in the mobile world, rely on higher- 310 level session manager, also named connection manager, to deal with 311 issues brought by simultaneous attachment to multiple provisioning 312 domains. Typically, the session manager may deal with the selection 313 of the interface, and/or the provisioning domain, on behalf to the 314 applications, or tackle with complex issues such as policies conflict 315 resolution (Section 4.3). As discussed previously in Section 3.7, 316 the session manager may encounter difficulties because of multiple 317 and diverse criteria. 319 Session managers usually leverage the link-layer interface to gather 320 information (e.g lower layer authentication and encryption methods, 321 see Section 3.1) and/or for control purpose. Such link-layer 322 interface may not provide all required services to make a proper 323 decision (e.g. interface selection). Some OS, or terminals, already 324 implement session managers [I-D.ietf-mif-current-practices] and 325 vendor-specific platforms sometimes provides specific socket API 326 (Section 3.9) a session manager can use. However, the generic 327 architecture of a session manager and its associated API are not 328 currently standardized, so session management behavior may differ 329 between OS and platforms. 331 Multiple interfaces management sometimes relies on a virtual 332 interface. For instance, virtual interface allows to support multi- 333 homing, inter-technology handovers and IP flow mobility in a Proxy 334 Mobile IPv6 network [I-D.ietf-netext-logical-interface-support]. 335 This virtual interface allows a multiple-interfaces node sharing a 336 set of IP addresses on multiple physical interfaces and can also add 337 benefits to multi-access scenarios such as 3GPP Multi Access PDN 338 Connectivity [TS23.402]. In most cases, the virtual interface will 339 map several physical network interfaces and the session manager 340 should control both, the configuration of each one of these virtual 341 and physical interfaces, as well as the mapping between the virtual 342 and the sub-interfaces. 344 In multiple interfaces situation, active application sessions should 345 survive to path failures. Here, the session manager may come into 346 play but only relying on existing mechanisms to manage multipath 347 (MPTCP [I-D.ietf-mptcp-architecture]) or failover (MIP6 [RFC3775], 348 SHIM6 [RFC5533]). Description of interaction between these 349 mechanisms and the session manager is out of the scope of this 350 document. 352 3.9. Socket API 354 An Application Programming Interface (API) may expose objects that 355 user applications, or session managers, use for dealing with multiple 356 interfaces. For example, [RFC3542] defines how an application using 357 the Advanced sockets API specifies the interface or the source IP 358 address, through a simple bind() operation or with the IPV6_PKTINFO 359 socket option. 361 Other APIs have been defined to solve similar issues to MIF. For 362 instance, [RFC5014] defines an API to influence the default address 363 selection mechanism by specifying attributes of the source addresses 364 it prefers. [I-D.ietf-shim6-multihome-shim-api] gives another 365 example, in a multihoming context, by defining a socket API enabling 366 interactions between applications and the multihoming shim layer for 367 advanced locator management, and access to information about failure 368 detection and path exploration. 370 4. MIF Issues 372 This section describes the various issues when using a MIF node that 373 has already received configuration objects from its various 374 provisioning domains or when multiple interfaces are used and results 375 in wrong domain selection, addressing or naming space overlaps. They 376 occur, for example, when: 378 1. one interface is on the Internet and one is on a corporate 379 private network. The latter may be through VPN. 380 2. one interface is on one access network (i.e. wifi) and the other 381 one is on another access network (3G) with specific services. 383 4.1. DNS resolution issues 385 A MIF node (M1) has an active interface(I1) connected to a network 386 (N1) which has its DNS server (S1) and another active interface (I2) 387 connected to a network (N2) which has its DNS server (S2). S1 serves 388 with some private namespace "private.example.com". The user or the 389 application uses a name "a.private.example.com" which is within the 390 private namespace of S1 and only resolvable by S1. Any of the 391 following situations may occur: 393 1. M1 stack, based on its routing table, uses I2 to reach S1 to 394 resolve "a.private.example.com". M1 never reaches S1. The name 395 is not resolved. 396 2. M1 keeps only one set of DNS server addresses from the received 397 configuration objects and kept S2 address. M1 sends the forward 398 DNS query for a.private.example.com to S2. S2 responds with an 399 error for an non-existent domain (NXDOMAIN). The name is not 400 resolved. This issue also arises when performing reverse DNS 401 lookup. In the same situation, the reverse DNS query fails. 402 3. M1 keeps only one set of DNS server addresses from the received 403 configuration objects and kept S2 address. M1 sends the DNS 404 query for a.private.example.com to S2. S2 asks its upstream DNS 405 and gets an IP address for a.private.example.com. However, the 406 IP address is not the same one S1 would have given. Therefore, 407 the application tries to connect to the wrong destination node, 408 or to the wrong interface of the latter, which may imply security 409 issues or result in lack of service. 410 4. S1 or S2 has been used to resolve "a.private.example.com" to an 411 [RFC1918] address. Both N1 and N2 are [RFC1918] addressed 412 networks. If addresses overlap, traffic may be sent using the 413 wrong interface. This issue is not related to receiving multiple 414 configuration objects, but to an address overlap between 415 interfaces or attaching networks. 417 5. M1 has resolved an FQDN to locally valid IP address when 418 connected to N1. If the node looses connection to N1, the node 419 may try to connect, via N2, to the same IP address as earlier, 420 but as the address was only locally valid, connection setup 421 fails. Similarly, M1 may have received NXDOMAIN for an FQDN when 422 connected to N1. After detachment from N1, the node should not 423 assume the FQDN continues to be nonexistent on N2. 424 6. M1 requests AAAA record from a DNS server on a network that uses 425 protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the 426 M1 receives synthesized AAAA record, it is guaranteed to be valid 427 only on the network it was learned from. If the M1 uses 428 synthesized AAAA on any other network interface, traffic may be 429 lost, dropped or forwarded to the wrong network. 431 Some networks requires the user to authenticate on a captive web 432 portal before providing Internet connectivity. If this redirection 433 is achieved by modifying the DNS reply, specific issues may occur. 434 Consider a MIF node (M1) with an active interface(I1) connected to a 435 network (N1), which has its DNS server (S1), and another active 436 interface (I2) connected to a network (N2), which has its DNS server 437 (S2). Until the user has not authenticated, S1 is configured to 438 respond to any A or AAAA record query with the IP address of a 439 captive portal, so as to redirect web browsers to an access control 440 portal web page. This captive portal can be reached only via I1. 441 When the user has authenticated to the captive portal, M1 can resolve 442 an FQDN when connected to N1. However, if the address is only 443 locally valid on N1, any of the issue described above may occur. 444 When the user has not authenticated, any of the following situations 445 may occur: 447 1. M1 keeps only one set of DNS server addresses from the received 448 configuration objects and kept S2 address. M1 sends the forward 449 DNS query for a.example.com to S2. S2 responds with the correct 450 answer, R1. M1 attempts to contact R1 by way of I1. The 451 connection fails. Or, the connection succeeds, bypassing the 452 security policy on N1, possibly exposing the owner of M1 to 453 prosecution. 454 2. M1 keeps only one set of DNS server addresses from the received 455 configuration objects and kept S1 address. M1 sends the DNS 456 query for a.example.com to S1. S1 provides the address of its 457 captive portal. M1 attempts to contact this IP address using I1. 458 The application fails to connect, resulting in lack of service. 459 Or, the application succeeds in connecting, but connects to the 460 captive portal rather than the intended destination, resulting in 461 lack of service (i.e. IP connectivity check issue described in 462 Section 4.4). 464 4.2. Node Routing 466 A MIF node (M1) has an active interface(I1) connected to a network 467 (N1) and another active interface (I2) connected to a network (N2). 468 The user or the application is trying to reach an IP address (IP1). 469 Any of the following situations may occur: 471 1. For IP1, M1 has one default route (R1) via network (N1). To 472 reach IP1, M1 stack uses R1 and sends through I1. If IP1 is only 473 reachable by N2, IP1 is never reached or is not the right target. 474 2. For the IP1 address family, M1 has one default route (R1, R2) per 475 network (N1, N2). IP1 is reachable by both networks, but N2 path 476 has better characteristics, such as better round-trip time, least 477 cost, better bandwidth, etc.... These preferences could be 478 defined by user, provisioned by the network operator, or else. 479 M1 stack uses R1 and tries to send through I1. IP1 is reached 480 but the service would be better by I2. 481 3. For the IP1 address family, M1 has a default route (R1), a 482 specific X.0.0.0/8 route R1B (for example but not restricted to 483 RFC1918 prefix) to N1 and a default route (R2) to N2. IP1 is 484 reachable by N2 only, but the prefix (X.0.0.0/8) is used in both 485 networks. Because of the most specific route R1B, M1 stack sends 486 through I2 and never reach the target. 488 A MIF node may have multiple routes to a destination. However, by 489 default, it does not have any hint concerning which interface would 490 be the best to use for that destination. The first-hop selection may 491 leverage on local routing policy, allowing some actors (e.g. network 492 operator or service provider) to influence the routing table, i.e. 493 make decision regarding which interface to use. For instance, a user 494 on such multihomed node might want a local policy to influence which 495 interface will be used based on various conditions. Some SDOs have 496 defined policy-based routing selection mechanisms. For instance, the 497 Access Network Discovery and Selection Function (ANDSF) [TS23.402] 498 provides inter-systems routing policies to terminals with both a 3GPP 499 and non-3GPP interfaces. However, the routing selection may still be 500 difficult, due to disjoint criteria as discussed in Section 3.8. 501 Moreover, information required to make the right decision may not be 502 available. For instance, interfaces to lower layer may not provide 503 all required hints to the selection (e.g. information on interface 504 quality). 506 A node usually has a node-scoped routing table. However, a MIF node 507 is connected to multiple provisioning domains; if each of these 508 domains pushes routing policies to the node, then conflicts between 509 policies may happen and the node has no easy way to merge or 510 reconciliate them. 512 On a MIF node, some source addresses are not valid if used on some 513 interfaces. For example, an RFC1918 source address might be 514 appropriate on the VPN interface but not on the public interface of 515 the MIF node. If the source address is not chosen appropriately, 516 then packets may be filtered in the path if source address filtering 517 is in place ([RFC2827], [RFC3704]) and reply packets may never come 518 back to the source. 520 4.3. Policies conflict 522 The distribution of configuration policies (e.g. address selection, 523 routing, DNS selection...) to end nodes is being discussed (e.g. 524 ANDSF in [TS23.402], [I-D.ietf-mif-dhcpv6-route-option]). If 525 implemented in multiple provisioning domains, such mechanisms may 526 conflict and bring issues to the multihomed node. Considering a MIF 527 node (M1) with an active interface(I1) connected to a network (N1) 528 and another active interface (I2) connected to a network (N2), the 529 following conflicts may occur: 530 1. M1 receives from both networks (N1 and N2) an update of its 531 default address selection policy. However, the policies are 532 specific to each network. The policies are merged by M1 stack. 533 Based on the merged policy, the chosen source address is from N1 534 but packets are sent to N2. The source address is not reachable 535 from N2, therefore the return packet is lost. Merging address 536 selection policies may have important impacts on routing. 537 2. A node usually has a node-scoped routing table. However, each of 538 the connected provisioning domains (N1 and N2) may push routing 539 policies to the node, then conflicts between policies may happen 540 and the node has no easy way to merge or reconciliate them. 541 3. M1 receives from one of the network an update of its access 542 selection policy, e.g. via the 3GPP/ANDSF [TS23.402]. However, 543 the policy is in conflict with the local policy (e.g. user 544 defined, or default OS policy). Assuming that the network 545 provides list of overloaded access network, if the policy sent by 546 the network is ignored, packet may be sent to an access network 547 with poor quality of communication. 549 4.4. Session management 551 Consider that a node has selected an interface and managed to 552 configure it (i.e. the node obtained a valid IP address from the 553 network). However, the Internet connectivity is not available. The 554 problem could be due to the following reasons: 555 1. The network requires a web-based authentication (e.g. the access 556 network is a WiFi Hot Spot). In this case the user can only 557 access to a captive portal. For instance, the network may 558 perform HTTP redirection or modify DNS behaviour (Section 4.1) 559 until the user has not authenticated. 561 2. IP interface is configured active but layer 2 is so poor (e.g. 562 poor radio condition) that no layer 3 traffic can succeed. 564 In this situation, the session management should be able to perform 565 IP connectivity checks before selecting an interface. 567 Session issues may also arise when the node discovers a new 568 provisioning domain. Consider a MIF node (M1) has an active 569 interface(I1) connected to a network (N1) where an application is 570 running a TCP session. A new network (N2) becomes available. If N2 571 is selected (e.g. because of better quality of communication), M1 572 gets IP connectivity to N2 and updates the routing table priority. 573 So, if no specific route to the correspondent node and if the node 574 implements the weak host model [RFC1122], the TCP connection breaks 575 as next hop changes. In order to continue communicating with the 576 correspondent node, M1 should try to re-connect the server via N2. 577 In some situation, it could be preferable to maintain current 578 sessions on N1 while new sessions start on N2. 580 4.5. Single Interface on Multiple Provisioning Domains 582 When a node using a single interface is connected to multiple 583 networks, such as different default routers, similar issues as 584 described above happen. Even with a single interface, a node may 585 wish to connect to more than one provisioning domain: that node may 586 use more than one IP source address and may have more than one 587 default router. The node may want to access services that can only 588 be reached using one of the provisioning domain. In this case, it 589 needs to use the right outgoing source address and default gateway to 590 reach that service. In this situation, that node may also need to 591 use different DNS servers to get domain names in those different 592 provisioning domains. 594 5. Underlying problems and causes 596 This section lists the underlying problems, and their causes, which 597 lead to the issues discussed in the previous section. The problems 598 can be divided into five categories: 1) Configuration 2) DNS 599 resolution 3) Routing 4) Address selection and 5) session management 600 and API. They are shown as below: 602 1. Configuration. In a MIF context, configuration information 603 specific to a provisioning domain may be ignored because: 604 1. Configuration objects (e.g. DNS servers, NTP servers, ...) 605 are node-scoped. So the IP stack is not able to maintain the 606 mapping between information and corresponding provisioning 607 domain. 609 2. Same configuration objects (e.g. DNS server addresses, NTP 610 server addresses, ..) received from multiple provisioning 611 domains may be overwritten. 612 3. Host implementations usually do not keep separate network 613 configuration (such as DNS server addresses) per provisioning 614 domain. 615 2. DNS resolution 616 1. Some FQDN can be resolvable only by sending queries to the 617 right server (e.g. intranet services). However, DNS query 618 could be sent to the wrong interface because DNS server 619 addresses may be node-scoped. 620 2. A DNS answer may be only valid on a specific provisioning 621 domain but applications may not be aware of that mapping 622 because DNS answers may not be kept with the provisioning 623 from which the answer comes from. 624 3. Routing 625 1. In the MIF context, routing information could be specific to 626 each interface. This could lead to routing issue because, in 627 current node implementations, routing tables are node-scoped. 628 2. Current node implementations do not take into account the 629 Differentiated Services Code Point or path characteristics in 630 the routing table. 631 3. Even if implementations take into account path 632 characteristics, the node has no way to properly merge or 633 reconciliate the provisioning domain preferences. 634 4. a node attached to multiple provisioning domain could be 635 provided with incompatible selection policies. If the 636 different actors (e.g. user and network operator) are allowed 637 to provide their own policies, the node has no way to 638 properly merge or reconciliate multiple selection policies. 639 5. The problem of first hop selection could not be solved via 640 configuration (Section 3.7), and may leverage on 641 sophisticated and specific mechanisms (Section 3.8). 642 4. Address selection 643 1. Default Address Selection policies may be specific to their 644 corresponding provisioning domain. However, a MIF node may 645 not be able to manage per-provisioning domain address 646 selection policies because default Address Selection policy 647 is node-scoped. 648 2. On a MIF node, some source addresses are not valid if used on 649 some interfaces or even on some default routers on the same 650 interface. In this situation, the source address should be 651 taken into account in the routing table; but current node 652 implementations do not support such a feature. 653 3. Source address or address selection policies could be 654 specified by applications. However, there is no advanced 655 APIs to allow applications realizing such operations. 657 5. Session management and API 658 1. Some implementations, specially in the mobile world, have 659 higher-level API and/or session manager (aka connection 660 manager) to address MIF issues. These mechanisms are not 661 standardized and do not necessarily behave the same way 662 across different OS, and/or platforms, in the presence of the 663 MIF problems. This lack of consistency is an issue for user 664 and operator who could experience different session manager 665 behaviors depending on the terminal. 666 2. Session managers usually leverage on interface to link layer 667 to gather information (e.g lower layer authentication and 668 encryption methods) and/or for control purpose. However, 669 such link layer interface may not provide all required 670 services (e.g. may not provide all information allowing to 671 make a proper interface selection). 672 3. A MIF node can support different session managers, which may 673 have contradictory ways to solve the MIF issues. For 674 instance, because of different selection algorithms, two 675 different session managers could select different domains in 676 a same context. Or, when dealing with different domain 677 selection policies, a session manager may give precedence to 678 user policy while another could favor mobile operator policy. 679 4. When host routing is updated and if weak host model is 680 supported, ongoing TCP sessions may break if routes changes 681 for these sessions. When TCP sessions should be bound to the 682 interface, the strong host model should be used. 683 5. When provided by different actors (e.g. user, network, 684 default-OS), policies may conflict and, thus, need to be 685 reconciliated at the host level. Policy conflict resolution 686 may impact other functions (e.g. naming, routing). 687 6. Even if the node has managed to configure an interface, 688 Internet connectivity could be not available. It could be 689 due to an access control function coming into play above the 690 layer 3, or because of poor layer 2 conditions. IP 691 connectivity check should be performed before selecting an 692 interface. 694 6. Security Considerations 696 The problems discussed in this document have security implications, 697 such as when the packets sent on the wrong interface might be leaking 698 some confidential information. Configuration parameters from one 699 provisioning domain could cause a denial of service on another 700 provisioning domain (e.g. DNS issues). Moreover, the undetermined 701 behavior of IP stacks in the multihomed context bring additional 702 threats where an interface on a multihomed node might be used to 703 conduct attacks targeted to the networks connected by the other 704 interfaces.corrupted provisioning domain selection policy may induce 705 a node to make decisions causing certain traffic to be forwarded to 706 the attacker. 708 Additional security concerns are raised by possible future mechanisms 709 that provide additional information to the node so that it can make a 710 more intelligent decision with regards to the issues discussed in 711 this document. Such future mechanisms may themselves be vulnerable 712 and may not be easy to protect in the general case. 714 7. IANA Considerations 716 This document has no actions for IANA. 718 8. Authors 720 This document is a joint effort with authors of the MIF requirements 721 draft [I-D.yang-mif-req]. The authors of this document, in 722 alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick 723 Seite, Carl Williams and Peny Yang. 725 9. Acknowledgements 727 The initial Internet-Drafts prior to the MIF working group and the 728 discussions during the MIF BOF meeting and on the mailing list around 729 the MIF charter scope on the mailing list brought very good input to 730 the problem statement. This draft steals a lot of text from these 731 discussions and initial drafts (e.g. [I-D.yang-mif-req], 732 [I-D.hui-ip-multiple-connections-ps], 733 [I-D.ietf-mif-dns-server-selection]). Therefore, the editor would 734 like to acknowledge the following people (in no specific order), from 735 which some text has been taken from: Jari Arkko, Keith Moore, Sam 736 Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie Volz, Giyeong 737 Son, Gabriel Montenegro, Julien Laganier, Teemu Savolainen, Christian 738 Vogt, Lars Eggert, Margaret Wasserman, Hui Deng, Ralph Droms, Ted 739 Hardie, Christian Huitema, Remi Denis-Courmont, Alexandru Petrescu, 740 Zhen Cao, Gaetan Feige, Telemaco Melia and Juan-Carlos Zuniga. Sorry 741 if some contributors have not been named. 743 10. Informative References 745 [I-D.carpenter-referral-ps] 746 Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement 747 for Referral", draft-carpenter-referral-ps-02 (work in 748 progress), February 2011. 750 [I-D.hui-ip-multiple-connections-ps] 751 Hui, M. and H. Deng, "Problem Statement and Requirement of 752 Simple IP Multi-homing of the Host", 753 draft-hui-ip-multiple-connections-ps-02 (work in 754 progress), March 2009. 756 [I-D.ietf-6man-addr-select-sol] 757 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 758 approaches for address-selection problems", 759 draft-ietf-6man-addr-select-sol-03 (work in progress), 760 March 2010. 762 [I-D.ietf-behave-dns64] 763 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 764 "DNS64: DNS extensions for Network Address Translation 765 from IPv6 Clients to IPv4 Servers", 766 draft-ietf-behave-dns64-11 (work in progress), 767 October 2010. 769 [I-D.ietf-mif-current-practices] 770 Wasserman, M. and P. Seite, "Current Practices for 771 Multiple Interface Hosts", 772 draft-ietf-mif-current-practices-11 (work in progress), 773 April 2011. 775 [I-D.ietf-mif-dhcpv6-route-option] 776 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 777 Route Option", draft-ietf-mif-dhcpv6-route-option-01 (work 778 in progress), March 2011. 780 [I-D.ietf-mif-dns-server-selection] 781 Savolainen, T., Kato, J., and T. Lemon, "Improved DNS 782 Server Selection for Multi-Homed Nodes", 783 draft-ietf-mif-dns-server-selection-02 (work in progress), 784 April 2011. 786 [I-D.ietf-mptcp-architecture] 787 Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 788 Iyengar, "Architectural Guidelines for Multipath TCP 789 Development", draft-ietf-mptcp-architecture-05 (work in 790 progress), January 2011. 792 [I-D.ietf-netext-logical-interface-support] 793 Melia, T. and S. Gundavelli, "Logical Interface Support 794 for multi-mode IP Hosts", 795 draft-ietf-netext-logical-interface-support-02 (work in 796 progress), March 2011. 798 [I-D.ietf-shim6-app-refer] 799 Nordmark, E., "Shim6 Application Referral Issues", 800 draft-ietf-shim6-app-refer-00 (work in progress), 801 July 2005. 803 [I-D.ietf-shim6-multihome-shim-api] 804 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 805 "Socket Application Program Interface (API) for 806 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-17 807 (work in progress), April 2011. 809 [I-D.yang-mif-req] 810 Yang, P., Seite, P., Williams, C., and J. Qin, 811 "Requirements on multiple Interface (MIF) of simple IP", 812 draft-yang-mif-req-00 (work in progress), March 2009. 814 [MIH] IEEE, "IEEE Standard for Local and Metropolitan Area 815 Networks - Part 21: Media Independent Handover Services, 816 IEEE LAN/MAN Std 802.21-2008, January 2009.", 2010. 818 [RFC1122] Braden, R., "Requirements for Internet Hosts - 819 Communication Layers", STD 3, RFC 1122, October 1989. 821 [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing 822 Domains: A model for routing in the Internet", RFC 1136, 823 December 1989. 825 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 826 RFC 1661, July 1994. 828 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 829 E. Lear, "Address Allocation for Private Internets", 830 BCP 5, RFC 1918, February 1996. 832 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 833 RFC 2131, March 1997. 835 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 836 Defeating Denial of Service Attacks which employ IP Source 837 Address Spoofing", BCP 38, RFC 2827, May 2000. 839 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 840 and M. Carney, "Dynamic Host Configuration Protocol for 841 IPv6 (DHCPv6)", RFC 3315, July 2003. 843 [RFC3484] Draves, R., "Default Address Selection for Internet 844 Protocol version 6 (IPv6)", RFC 3484, February 2003. 846 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 847 "Advanced Sockets Application Program Interface (API) for 848 IPv6", RFC 3542, May 2003. 850 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 851 Networks", BCP 84, RFC 3704, March 2004. 853 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 854 in IPv6", RFC 3775, June 2004. 856 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 857 April 2006. 859 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 860 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 861 Issues", RFC 4477, May 2006. 863 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 864 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 865 September 2007. 867 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 868 RFC 4960, September 2007. 870 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 871 Socket API for Source Address Selection", RFC 5014, 872 September 2007. 874 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 875 Discovery and Selection Problem", RFC 5113, January 2008. 877 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 878 Host Mobility and Multihoming with the Host Identity 879 Protocol", RFC 5206, April 2008. 881 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 882 "Problem Statement for Default Address Selection in Multi- 883 Prefix Environments: Operational Issues of RFC 3484 884 Default Rules", RFC 5220, July 2008. 886 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 887 "Requirements for Address Selection Mechanisms", RFC 5221, 888 July 2008. 890 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 891 (ICE): A Protocol for Network Address Translator (NAT) 892 Traversal for Offer/Answer Protocols", RFC 5245, 893 April 2010. 895 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 896 Shim Protocol for IPv6", RFC 5533, June 2009. 898 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 899 and K. Nagami, "Multiple Care-of Addresses Registration", 900 RFC 5648, October 2009. 902 [TS23.234] 903 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 904 interworking; TS 23.234", 2009. 906 [TS23.402] 907 3GPP, "Architecture enhancements for non- 3GPP accesses; 908 TS 23.402", 2010. 910 Authors' Addresses 912 Marc Blanchet 913 Viagenie 914 2875 boul. Laurier, suite D2-630 915 Quebec, QC G1V 2M2 916 Canada 918 Email: Marc.Blanchet@viagenie.ca 919 URI: http://viagenie.ca 921 Pierrick Seite 922 France Telecom - Orange 923 4, rue du Clos Courtel, BP 91226 924 Cesson-Sevigne 35512 925 France 927 Email: pierrick.seite@orange-ftgroup.com