Individual Submission T. Savolainen Internet Draft Nokia Intended status: Experimental October 23, 2008 Expires: April 2009 Domain name based network interface selection draft-savolainen-6man-fqdn-based-if-selection-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 23, 2009. Savolainen Expires April 23, 2009 [Page 1] Internet-Draft FQDN based interface selection October 2008 Abstract A multi-homed host with multiple physical and/or virtual network interfaces has to select which one of the network interfaces to use for a new outgoing IPv4 or IPv6 connection. This document describes a method to select an interface by using destination's fully qualified domain name and DNS suffix information received dynamically for each network interface. The method is useful, for example, in split horizon DNS and walled garden scenarios, where right network interface has to be selected even before DNS resolution is conducted. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Problem descriptions...........................................4 3.1. Split horizon DNS.........................................4 3.2. Firewalled walled gardens.................................5 3.3. Seemingly equal interfaces................................5 4. DNS suffix based interface selection...........................6 4.1. Learning of the DNS suffixes..............................6 4.2. Changes to DNS resolution procedures......................8 4.3. Changes to host's address selection procedures............9 5. Network operator considerations...............................10 6. Further considerations........................................10 7. Security Considerations.......................................10 8. IANA Considerations...........................................11 9. Acknowledgments...............................................11 10. References...................................................11 10.1. Normative References....................................11 10.2. Informative References..................................12 Author's Address.................................................12 Savolainen Expires April 23, 2009 [Page 2] Internet-Draft FQDN based interface selection October 2008 1. Introduction A host initiating an IP connection commonly uses destination's fully qualified domain name (FQDN). The FQDN has to be first resolved into an IP address with help of DNS, and afterwards the connection is created to one of the resolved IP addresses. The source and destination IP addresses that are used for the connection are determined by host's address selection algorithms, like the one defined for IPv6 in [RFC3484]. A multi-homed host may do network interface selection as part of host's source address selection algorithm. A host may also be configured to use only single network interface at any given time or for a given application. This document identifies three problematic scenarios a multi-homed host may encounter and for which solutions are needed. The problems are listed below and described in detail in chapter 3: 1. Split horizon DNS 2. Firewalled walled gardens 3. Seemingly equal interfaces An example of an application facing these problems is a web browser, which in multi-homed environments may need to dynamically access content over different network interfaces. As a possible solution for these problems a method is described in chapter 4 that uses DNS suffixes for determining the best network interface for DNS resolution and for connecting to a given FQDN. The solution presented in this memo is intended to be fully backwards compatible and one that can be fully ignored by hosts and networks that are not experiencing the described problem scenarios. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Savolainen Expires April 23, 2009 [Page 3] Internet-Draft FQDN based interface selection October 2008 3. Problem descriptions This chapter describes three multi-homing related problem scenarios for which the DNS suffix based network interface selection solution described in chapter 4 is targeted at. The scenarios are not excluding each other, but shown separately for sake of simplicity. 3.1. Split horizon DNS A multi-homed host may be connecting to one or more networks that are using private fully qualified domain names. For example, the host may have simultaneously open a wireless LAN (WLAN) connection to open Internet, cellular (3GPP) connection to an operator network, and virtual private network (VPN) connection to a corporate network. When an application initiates connection to a FQDN, the host needs to be able to choose the right network interface for making successful DNS query. This is illustrated in figure 1. If the FQDN is for a public name, in figure 1 scenario it could be resolved with any DNS server in any network interface, but if the FQDN would be corporation's or operator's service's private name, the host would need to be able to correctly select the right network interface for DNS procedures, i.e. already before destination's IP address is known. +---------------+ | | DNS server w/ | | Corporate +---------+ | public + |----| Intranet | | | corporation's | | | |===== VPN =======| private names | | | | +---------------+ +---+ |A multi- | |FW | | homed | +---+ | host | +---------------| | | |----- WLAN ------| DNS server w/ |----| Public | | | public names | | Internet | | +---------------+ +---+ | | |FW | | | +---------------+ +---+ | |----- 3GPP ------| DNS server w/ | | +---------+ | public + | | Operator | operator's |----| Intranet | private names | | +---------------+ | Figure 1 Split horizon DNS and firewalled walled gardens scenarios illustrated Savolainen Expires April 23, 2009 [Page 4] Internet-Draft FQDN based interface selection October 2008 3.2. Firewalled walled gardens The firewalled walled gardens scenario is similar to what was described in 3.1 and figure 1, except that all DNS resolutions could be conducted with any DNS server over any network interface. However, for the actual IP connection creation to succeed right interface must be chosen, as otherwise firewalls at the edge of walled garden would block the incoming connection request. For example, a name of a server in operator's private network could be resolved to an IP address with any DNS server, but it could be contacted only over direct access to operator's network. 3.3. Seemingly equal interfaces In third problematic scenario there are no firewalls and all DNS servers have all information, but traffic for certain destinations are preferred to be transmitted over certain network interface rather than others. The reasons can be, for example, route optimization or quality of service related. For example, if a host has two seemingly equal network interfaces from its point of view, the network operator(s) of both or one of the network(s) may be interested to guide a host to make better network interface selection decisions. Figure 2 illustrates an example case where a multi-homed host should choose network interface A for contacting server 1 but interface B for contacting server 2, in order to select shortest path. This can be important e.g. if the two paths have significant geographical distance differences and thus different cost incurred for the network operator(s). A host sticking to using only interface A would be able to access both servers 1 and 2, but it would be suboptimal performance and network load/cost-wise. ----+------Internet--------+---- | | "costly hop"->| |<- "costly hop" | | +----------+ | | +----------+ | Server 1 +----+-- --+------+ Server 2 | +----------+ | | +----------+ -+---+-- --+---+-- (A)| +------+ |(B) +---+ host +---+ +------+ Figure 2 A multi-homed host with two seemingly equal network interfaces (from IP point of view) Savolainen Expires April 23, 2009 [Page 5] Internet-Draft FQDN based interface selection October 2008 Figure 3 illustrates case where a multi-homed host should choose network interface A for contacting real-time service 1 but interface B for non-real-time service 2. A host could contact service 1 via either interface, but using interface A provides better experience for real-time services (e.g. low latency) while interface B provides better experience for non-real-time services (e.g. high bandwidth). Real-time service 1 Non-real-time service 2 | | ---+----+-------Internet-------+------+--- | | low latency (A) | +------+ | (B) high latency low bandwidth +-------+ host +-------+ high bandwidth higher cost/bit +------+ lower cost/bit Figure 3 A multi-homed host with two network interfaces having different characteristics It is worth noting that in IPv4 domain both A and B network interfaces, of figures 2 and 3, may be using private IPv4 [RFC1918] addresses, which makes IPv4 address based interface selection difficult. In IPv6 domain source address selection mechanisms such as defined in [RFC3484] and worked on e.g. in [MATS2008] and [FUJI2008] can be used to tackle seemingly equal interfaces problem. 4. DNS suffix based interface selection This chapter contains a solution approach and a solution for the problems described in chapter 3. A host SHOULD learn which DNS suffixes in particular are resolvable, and accessible, via each network interface. By default a host MUST assume all FQDNs can be resolved and accessed via any network interface. When a connection is to be created to a FQDN, a host SHOULD prioritize available network interfaces for DNS resolution and address selection purposes based on possibly matching DNS suffix information. This document describes how existing DHCP(v6) DNS search list options can be used for this purpose. 4.1. Learning of the DNS suffixes A host can learn the DNS suffixes of attached network interfaces from DHCP search list options; DHCPv4 Domain Search Option number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. Savolainen Expires April 23, 2009 [Page 6] Internet-Draft FQDN based interface selection October 2008 This is illustrated in example message flow 1 below. Application Host DHCP server of DHCP server of WLAN interface cellular interface | | | | +-----------+ | (1) | | open | | | | interface | | | +-----------+ | | | | (2) | |---option REQ-->| | |<--option RESP--| | | | | +-----------+ | (3) | | store | | | | suffixes | | | +-----------+ | | | | | +-----------+ | (4) | | open | | | | interface | | | +-----------+ | | | | | (5) | |---option REQ------------------->| | |<--option RESP-------------------| | | | | | +----------+ | | (6) | | store | | | | | suffixes | | | | +----------+ | | | | | | Message flow 1: Learning DNS suffixes Flow explanations: (1) A host opens its first network interface, say WLAN (2) The host obtains DNS suffix information for the new WLAN interface from DHCP server (3) The host stores the learned DNS suffixes for later use (4) The host opens its seconds network interface, say cellular Savolainen Expires April 23, 2009 [Page 7] Internet-Draft FQDN based interface selection October 2008 (5) The host obtains DNS suffix, say "operator.com" information for the new cellular interface from DHCP server (6) The host stores the learned DNS suffixes for later use 4.2. Changes to DNS resolution procedures When a DNS resolver in a host is requested by an application to do DNS resolution for a FQDN to an IP address, the host SHOULD look if any of the available network interfaces is known to advertise DNS suffix matching to the FQDN. If there is a matching DNS suffix, then that particular interface should be used for name resolution procedures. This is illustrated in example message flow 2 below. Application Host DHCP server of DHCP server of WLAN interface cellular interface | | | | (1) |--Name REQ-->| | | | | | | | +-----------+ | | (2) | | Choose | | | | | interface | | | | +-----------+ | | | | | | (3) | |------------DNS resolution------>| | |<--------------------------------| | | | | (4) |<--Name resp-| | | | | | | Message flow 2: Choosing interface based on DNS suffix Flow explanations: (1) An application makes a request for resolving a FQDN, e.g. "private.operator.com" (2) A host looks at stored DNS suffix information and chooses interface to use for DNS resolution (3) The host has chosen cellular interface, as from DHCP it was learned that the cellular interface has DNS suffix "operator.com", and resolves the requested name using cellular interface's DNS server to IP 192.0.2.1 (4) The host replies to application with resolved address 192.0.2.1 Savolainen Expires April 23, 2009 [Page 8] Internet-Draft FQDN based interface selection October 2008 4.3. Changes to host's address selection procedures To avoid problems described in chapter 3, in addition to logic for conducting successful DNS query, the host's source IP address selection algorithms must be able to choose the IP address of the right network interface when application is providing only a destination IP address to connect to. The source address selection algorithm SHOULD do either or both of the following procedures: A) The algorithm to make reverse DNS lookup for the destination IP address on host's own DNS cache, which should contain corresponding record if the IP address was earlier resolved from a FQDN. From this record FQDN matching the IP address is learned, and based on that FQDN network interface with corresponding DNS suffix can be chosen. B) The algorithm to consult host's address selection policy table, which may have been dynamically received as described in [MATS2008] and [FUJI2008]. This is illustrated in example message flow 3 below. Application Host DHCP server of DHCP server of WLAN interface cellular interface | | | | (1) |--Connect--->| | | | | | | | +-----------+ | | (2) | | Choose | | | | | interface | | | | +-----------+ | | | | | | (3) | |------------Connect------------->| | |<--------------------------------| | | | | (4) |<--Con resp--| | | | | | | Message flow 3: Choosing interface for outgoing connection Flow explanations: (1) An application initiates new connection to an IP address, e.g. 192.0.2.1 Savolainen Expires April 23, 2009 [Page 9] Internet-Draft FQDN based interface selection October 2008 (2) The host either: a. Consults host's internal DNS cache with reverse DNS lookup query and learns that FQDN "private.operator.com" is matching IP 192.0.2.1 and therefore cellular network interface with matching DNS suffix "operator.com" shall be selected b. Consults dynamically received address selection policy table and learns that for destination IP 192.0.2.1 cellular interface should be used (3)and (4) Connection is established over selected network interface 5. Network operator considerations An operator of a network can continue to use DHCP DNS search list options as before, but the operator should take into account that multi-homed hosts may use the DNS suffix information also for interface selection purposes. An operator wishing to assist hosts in network interface selection should configure DHCP servers with proper DNS suffix information, which hosts then can use as hints for improved operation. Furthermore, the operator should configure DHCP servers with IP address selection policies ([MATS2008], [FUJI2008]) that are corresponding to the configured DNS suffix information. 6. Further considerations Overloading of existing DNS search list options is not without problems, though: hosts would obviously use the DNS suffixes learned from search lists also for name resolution purposes. This may not be a problem in deployment cases where DNS search list options already contain few DNS suffixes like "intranet.corporation.com", but can become a problem in other deployment scenarios. An obvious alternative would be to define new DHCP options for distributing DNS suffix information designed only for network interface selection purposes. 7. Security Considerations An attacker may try to lure traffic from multi-homed host to his network by advertising DNS suffixes attacker wishes to intercept or deny service. The host's security should not be based on correct functionality of source/destination address selection, but risks of this attack can be mitigated by properly prioritizing network Savolainen Expires April 23, 2009 [Page 10] Internet-Draft FQDN based interface selection October 2008 interfaces with conflicting DNS suffix advertisements. The prioritization can be based on trust level of a network interface over which DNS suffix was learned from: o VPN interfaces being most trustworthy o Managed networks being on the middle o Unmanaged networks having lowest priority Now, for example, if all of the three abovementioned networks would indicate access for "corporation.com", the host would choose to use the VPN for connections destined to "corporation.com" domain. 8. IANA Considerations No considerations identified at this point. TBD: if new DHCP options are defined instead, situation changes. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3397] Aboba, B., Cheshire, S., "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002 [RFC3646] Ed., Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, G., Lear, E., "Address Allocation for Private Internets", RFC1918, February 1996 [MATS2008] Matsumoto, A., Fujisaki, T., Hiromi, R., Kanayama, K., "Solution approaches for address-selection problems", June 2008, draft-ietf-6man-addr-select-sol-01.txt Savolainen Expires April 23, 2009 [Page 11] Internet-Draft FQDN based interface selection October 2008 [FUJI2008] Fujisaki, T., Niinobe, S., Hiromi, R., Kanayama, K., " Distributing Address Selection Policy using DHCPv6", June 2008, draft-fujisaki-dhc-addr-select-opt-06.txt 10.2. Informative References [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003 Author's Address Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 TAMPERE FINLAND Email: teemu.savolainen@nokia.com Savolainen Expires April 23, 2009 [Page 12] Internet-Draft FQDN based interface selection October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Savolainen Expires April 23, 2009 [Page 13]