Internet Engineering Task Force Z. Cao Internet-Draft China Mobile Intended status: Informational October 15, 2012 Expires: April 18, 2013 Service Discovery in a Multiple Connection Environment: Problem Statement draft-cao-mif-srv-dis-ps-00 Abstract 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 mutliple provisioning domains. Given a type of service a mutliple- 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. 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 April 18, 2013. Copyright Notice Copyright (c) 2012 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 to this document. Code Components extracted from this document must Cao Expires April 18, 2013 [Page 1] Internet-Draft MIF SRV Discovery October 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Cao Expires April 18, 2013 [Page 2] Internet-Draft MIF SRV Discovery October 2012 1. Introduction A multihomed host have 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]. DNS based Service Discovery (DNS-SD) has been specified in [I-D.cheshire-dnsext-dns-sd]. And [I-D.ietf-mif-dns-server-selection] extends DHCPv6 to inform the host which DNS server it ought to select to send the query request. 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 mutliple provisioning domains. Given a type of service a mutliple- 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. 1.1. 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 [RFC2119] 2. Problem Analysis The following figure shows where and how the problem arises. The host with multiple interfaces is a common case in today's mobile internet. On the service domain, different services are deployed and some services may not be accessible to a certain interface on the host. The service discovery process should return a correct point to the host and makes sure that the host can access the service via this pointer. This situation makes the multiple interface service discovery different from the one-interface scenario. Cao Expires April 18, 2013 [Page 3] Internet-Draft MIF SRV Discovery October 2012 +-------------------------------------------+ | Host with multiple interfaces | | | | | | +---+ +---+ +---+ ... +---+ | | | | | | | | ... | | | +-----+--------+--------+-------------+-----+ | | | ... | 3G Wifi__ Wired ... ... / \________ \__ \ / \____ \ \ ------------------------------------------------------------------------ +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ Service Domain ( Service ) ( Service ) \________________/ \_______________/ Figure 1: Multiple Interface Host with Multiple Available Services The serivce discovery process can be summarized as query request, query handling and reponse, and service access. 1. Service Query Request: the host send a query request to find a service. The query should includes a description of the service, for example, the full-qualified domain name, URI, or application- specific naming of the service. 2. Service Request Handling: any entity that receives the query request should handle the request. The entity should understand the meaning of the request, and check the semantics of the request language before giving an answer back. 3. 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. 4. 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 it is the service domain that has met a problem. 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 mutliple service rendezvous existing, Cao Expires April 18, 2013 [Page 4] Internet-Draft MIF SRV Discovery October 2012 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. In a DNS based service discovery, the problem of domain split is analyzed in the MIF-DNS-Selection document [I-D.ietf-mif-dns-server-selection]. The MIF-DNS-Selection document actually 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. This method resolves the partial problem in the service discovery process mentioned above. In a more complicated network, as what is shown inFigure 2 , 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. Cao Expires April 18, 2013 [Page 5] Internet-Draft MIF SRV Discovery October 2012 +---------------+ | 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 2: Scenario of Multiple Interface DNS Service Discovery 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 store 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 utilize 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. Service Pointer/Address Resolution: The same service may have different available addresses and pionters, 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 Cao Expires April 18, 2013 [Page 6] Internet-Draft MIF SRV Discovery October 2012 one of the interfaces. Service Route Selection: With the pointers returned, the host should route the service level data to the service instance identified by the return pointers. 3. IANA Considerations This document has no IANA requests. 4. 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 of scope of this problem statement document. 5. References 5.1. Normative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-11 (work in progress), December 2011. [I-D.ietf-mif-dns-server-selection] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", draft-ietf-mif-dns-server-selection-12 (work in progress), August 2012. 5.2. Informative References [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 Cao Expires April 18, 2013 [Page 7] Internet-Draft MIF SRV Discovery October 2012 Multiple-Interface Hosts", RFC 6419, November 2011. Author's Address Zhen Cao China Mobile Xuanwumenxi Ave. No. 32 Beijing, 100871 China Phone: +86-10-52686688 Email: zehn.cao@gmail.com, caozhen@chinamobile.com Cao Expires April 18, 2013 [Page 8]