Internet Engineering Task Force Z. Cao Internet-Draft China Mobile Intended status: Informational A. Ding Expires: February 28, 2014 Cambridge University / Helsinki University August 27, 2013 Service Discovery in a Multiple Connection Environment: Problem Statement draft-cao-mif-srv-dis-ps-03 Abstract This document analyzes the problems of service discovery in a multiple connection environment. A multiple connection environment consists of multiple-interfaced nodes connecting to multiple networks or multiple provisioning domains. Given a type of service a multiple-interfaced client is looking for, the discovery progress ought to return a correct pointer to the service instance that the client is able to access without trying every available channel. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 28, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Cao & Ding Expires February 28, 2014 [Page 1] Internet-Draft MIF SRV Discovery August 2013 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements and Terminology . . . . . . . . . . . . . . . . 3 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Mif Scenario . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Homenet Scenario . . . . . . . . . . . . . . . . . . . . 5 4. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A multihomed host has multiple provisioning domains via physical and/ or virtual interfaces. A multihomed host receives node configuration information from each of its access networks, through various mechanisms such as DHCP, PPP and IPv6 Router Advertisements. When the received node-scoped configuration objects have different values from each administration domains, such as different DNS servers IP addresses, different default gateways or different address selection policies, the node has to decide which it will use or how it will merge them. Issues regarding how the multi-homed host uses the configuration objects have been addresses in [RFC6418]. Current practices of how the various implementations handle these problems are introduced in [RFC6419]. [RFC6731] extends DHCPv6 to inform the host which DNS server it ought to select to send the query request, and DNS based Service Discovery (DNS-SD) has been specified in [RFC6763]. This document analyzes the problem of service discovery in a multiple connection environment. A multiple connection environment consists of multiple-interfaces nodes connecting to multiple networks or multiple provisioning domains. Given a type of service a multiple- interfaced client is looking for, the discovery progress ought to return a correct pointer to the service instance that the a client is able to access. Cao & Ding Expires February 28, 2014 [Page 2] Internet-Draft MIF SRV Discovery August 2013 2. Requirements and Terminology 2.1. Requirements 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 [RFC2119]. 2.2. Terminology Service Domain A set of services that can be accessed by users. Besides providing services, a service domain is responsible for delivering configuration and pointers that ensure a guaranteed service access. Service Discovery Procedure to acquire information that is necessary to access service. Multiple Connection Environment Consists of multiple-interfaced nodes that connect to multiple networks or multiple provisioning domains. 3. Scenarios We describe two scenarios in this section, one related to Multiple Interfaces, and the other one related to Home Networks (homenet). 3.1. Mif Scenario The service discovery process can be summarized as the following five steps. 1. Service Discovery Preparation: the host determines which interface it should send a query request based on the configuration information. 2. Service Query Request: the host sends a query request to find a service. The query should include a description of the service, for example, a full-qualified domain name, a URI, or an application-specific naming of the service. 3. Service Request Handling: any entity that receives the query request should handle the request. The entity should understand Cao & Ding Expires February 28, 2014 [Page 3] Internet-Draft MIF SRV Discovery August 2013 the meaning of the request, and check the semantics of the request language before giving an answer back. 4. Service Query Response: the entity that receives the query request should reply with an answer to the query. The answer should include a pointer to the service. 5. Service Access: the host accesses the service via the pointer provided in the query response. The host is supposed to be able to get the service instance via the pointer under a successful and efficient service discovery mechanism, unless the servers in such service domain encounter problems e.g. a web server is down. Figure 1 shows a typical scenario for service discovery in a multiple connection environment. It is common in today's mobile Internet that a host is equipped with multiple network interfaces. On the service domain, different services are deployed and some services may not be accessible to a certain interface on the host due to security concern or access policy. The connectivity each interface provides may not be restricted to Internet access. For instance, WLAN and bluetooth can offer direct access to potential services e.g. printers via local ad-hoc connectivity. In such multiple connection environment, the service discovery process should return a correct point to the host and ensure that the host can access the service via this pointer. This situation makes the multiple interface service discovery different from the typical one-interface Internet access scenario. Furthermore, the growing usage of IPv6 in the homenet environment has made service discovery more challenging that requires thorough investigation. +-------------------------------------------+ | Host with multiple interfaces | | | | | | +---+ +---+ +---+ ... +---+ | | | | | | | | ... | | | +-----+--------+--------+-------------+-----+ | | | | 3G WLAN__ Bluetooth ... Wired / \________ \__ \ / \____ \ \ ---------------------------------------------------------------------- +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ Service Domain ( Service ) ( Service ) \________________/ \_______________/ Cao & Ding Expires February 28, 2014 [Page 4] Internet-Draft MIF SRV Discovery August 2013 Figure 1: Multiple Interface Host with Multiple Available Services 3.2. Homenet Scenario We also describe the issues related to the homenet architecture [I-D.ietf-homenet-arch], as depicted in Figure 2. Suppose one MIF host is connected to three domains: homenet domain, 3gpp domain and a WiFi or enterprise domain. There is one service that is named with the private domain name, say 'temperature.ietf', which is only resolvable via the domain name service residing inside the homenet and is supported by the multicast dns service [RFC6762]. There are several problems in this scenario. First of all, since the host has two unicast dns domains configured over the 3GPP and WiFi, and as well as a multicast service discovery domain within the homenet, the host does not know which domain it should send a dns resolution request. Secondly, even if coupled with the split dns solution [RFC6731], the configuration information obtained from DHCP supports only those two unicast dns domains, but not the homenet domain which is normally considered as 'zero-configuration'. Third, the service discovery problem will become more complicated if the host is connecting to more than one home networks, i.e., multiple multicast dns domains. +--------------+ | 3GPP Domain | +--------------+ | +--------------+ +---+ | |Homenet Domain|------| H |----------------+ +--------------+ +---+ | | +--------------+ | Wi-Fi | | Domain | +--------------+ Figure 2: Homenet Scenario 4. Problem Analysis The problems that a multiple-interfaced host may meet during the service discovery include: 1. How the query requests are sent? Because there are multiple interfaces available and multiple service rendezvous existing, Cao & Ding Expires February 28, 2014 [Page 5] Internet-Draft MIF SRV Discovery August 2013 the host should decide which destination it ought to send the query to. And if there is a round-robin mechanism, the host should determine the order of the query request. 2. How to handle the query and reply? Some pointers to the service are restricted to a local scope or a certain interface, e.g., an office printer may not be accessible to the 3G-interface. The service discovery process is supposed to return a pointer that is accessible to the host. 3. How to access the service? Given the pointer to the service, the host should be able to determine from which interface it can access the service. The existing work of [RFC6418] and [RFC6419] have covered the general problems encountered by hosts accessing multiple provisioning domains, but the focus is on connectivity and configuration. Proposal of Happy Eyeball in [I-D.ietf-mif-happy-eyeballs-extension] allows a host with multiple interfaces to pick a suitable one for access and enables automatic fallback. In a DNS based service discovery [RFC6763], the problem of domain split is analyzed in the [RFC6731]. The document defines an extension to the DHCPv4 and DHCPv6 to inform the MIF host which domain scope the Recursive DNS Server(RDNSS) is serving for, so that the "service query request" can be sent to the correct RDNSS to get an answer. The existing proposals resolve the partial problem in the service discovery process mentioned above. To highlight the missing blocks, Figure 3 provides a 'gap' analysis. In the figure, we compare three existing solutions on service discovery, DNS-SD[RFC6763], DNS-Server- Selection [RFC6731], and MIF Happy Eyeball [I-D.ietf-mif-happy-eyeballs-extension], from three aspects as mentioned above. The DNS-Srv-Sel solution uses the defined DHCP option for the MIF host to select the corresponding DNS Server, and MIF-HE inherits this method in its most updated version. The MIF-HE can help host failover to the workable interface during service access while DNS-Srv-Sel does not handle this particular issue. The DNS-SD is not designed for a multiple interfaces environment and DNS server selection and request handling are based on standard DNS behaviors. +-------------+----------------+----------------+----------------+ |Aspects \Sol | DNS-SD | DNS-Srv-Sel | MIF-HE | +-------------+----------------+----------------+----------------+ |How to | Std. DNS | DHCP Option | Same as | |Send Query | behavior | informed | DNS-Srv-Sel | +-------------+----------------+----------------+----------------+ Cao & Ding Expires February 28, 2014 [Page 6] Internet-Draft MIF SRV Discovery August 2013 |How to Handle| Std. DNS server| selection based| Same as | |Queries | behavior | on option | DNS-Srv-Sel | +-------------+----------------+----------------+----------------+ |How to Access|no guarantee | not possible if| Failover to the| |service |of connectivity | ports rejected | Happiest one | +-------------+----------------+----------------+----------------+ Figure 3: Gap Analysis of Existing Service Discovery Methods In a complicated network as shown in Figure 4 , the host connects to the enterprise network via the wired interface, a WLAN network with the 802.11 interface, and an operator's network via the cellular interface. The three intranets have their own Firewall policies to the global Internet. On the enterprise network, many outgoing ports are restricted, and on the WLAN and operator's public network, there is more freedom. If the MIF host makes a DNS-SRV query to a service in a global domain, all the RDNS servers have the corresponding records. But say the service port number has been blocked by the enterprise network administrator, the DNS has no such information. Even if the DNS returns a pointer to the MIF host, the MIF host cannot access this service via the wired interface. +---------------+ | RDNSS with | | Enterprise +------+ | public + |----| Intranet | | | enterprise's | | | |------Wired -----| private names | | | | +---------------+ +----------+----+ | MIF | | FW | | node | +----+ | | +---------------+ +----+ | | |----- WLAN ------| RDNSS with |--| FW |-----| Public | | | public names | +----+ | Internet | | +---------------+ | | | +----+ | | | FW | | | +---------------+ +----------+----+ | |---- Cellular ---| RDNSS with | | +------+ | public + | | Operator | operator's |----| Intranet | private names | | +---------------+ Figure 4: Scenario of Multiple Interface DNS Service Discovery Cao & Ding Expires February 28, 2014 [Page 7] Internet-Draft MIF SRV Discovery August 2013 CoAP [I-D.ietf-core-coap] is an IETF designed RESTful protocol for constrianed environment. CoAP defines a link-format for service discovery of the particular CoAP server, i.e., "/.well-known/core". If the CoAP client has multiple access networks as shown in Figure 5, the situation turns to be more complex. For instance, if the MIF client wants to find a humidity sensing resource, but does not know which domain contains the information, it basically needs to send multiple CoAP GET requests with the well-known URL. Once it gets a response for the required resource, it can send the corresponding request to get the information. However this way is sub-optimal especially for constrained devices. MIF service discovery SHOULD consider the efficiency of the service discovery process. +---------------+ +--------+ +----------+ | Internal |________| MIF |__________| External | | Domain | | Host | | Domain | +---------------+ +--------+ +----------+ | GET /.well-known/core | | |<------------------------| GET /.well-known/core | | |----------------------->| | ACK CON | ACK CON | |------------------------>|<-----------------------| | | GET ~/hum | | |----------------------->| Figure 5: CoAP Service Discovery for a MIF Host As a summary of the above analysis, the general problems and requirements of service discovery in a MIF environment can be summarized as follows: Service Directory Service Configuration: Service directory is the entity that stores or can get the stored relationship between service names and service pointers. Different interfaces or provisioning domains have their different service directories. How to configure them on the MIF host and how the MIF host utilizes the configured information are important for the service discovery process to behave correctly. Service Directory Selection: After the service directory information is configured on the host, the host is able to select the correct directory to send the query. The host can utilize auxiliary information available or send the query to all the directories that have been configured. The behavior of MIF host to select a correct directory is also important for a stable system. Cao & Ding Expires February 28, 2014 [Page 8] Internet-Draft MIF SRV Discovery August 2013 Service Pointer/Address Resolution: The same service may have different available addresses and pointers, and some service has limited connectivity. So the resolution process should be able to return to the MIF host a record that is accessible from at least one of the interfaces. Efficiency SHOULD be taken into consideration in this phase. Service Route Selection: With the pointers returned, the host should route the service level data to the service instance identified by the returned pointers. 5. IANA Considerations This document has no IANA requests. 6. Security Considerations The query response exchanges should be protected by security mechanisms. If the response contains invalid information, e.g. a pointer to a worm website, it harms. As a consequence, the service discovery should protect bogus information injected by attackers or intruders. The security consideration ought to be made by the underlining protocols, and it is out the scope of this problem statement document. 7. References 7.1. Normative References [I-D.ietf-mif-happy-eyeballs-extension] Chen, G., Williams, C., Wing, D., and A. Yourtchenko, "Happy Eyeballs Extension for Multiple Interfaces", draft- ietf-mif-happy-eyeballs-extension-02 (work in progress), February 2013. [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, December 2012. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. 7.2. Informative References [I-D.ietf-core-coap] Cao & Ding Expires February 28, 2014 [Page 9] Internet-Draft MIF SRV Discovery August 2013 Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18 (work in progress), June 2013. [I-D.ietf-homenet-arch] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, "Home Networking Architecture for IPv6", draft-ietf- homenet-arch-10 (work in progress), August 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011. [RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011. Authors' Addresses Zhen Cao China Mobile Xuanwumenxi Ave. No. 32 Beijing 100871 China Phone: +86-10-52686688 Email: zehn.cao@gmail.com, caozhen@chinamobile.com Aaron Yi Ding Cambridge University / Helsinki University William Gates Building, 15 JJ Thomson Ave CB3 0FD Cambridge United Kingdom Phone: +44-7934034801; +358-9-19151296 Email: Aaron.Ding@cl.cam.ac.uk Cao & Ding Expires February 28, 2014 [Page 10]