idnits 2.17.1 draft-cao-mif-srv-dis-ps-03.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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2013) is 3895 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-mif-happy-eyeballs-extension-02 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Z. Cao 3 Internet-Draft China Mobile 4 Intended status: Informational A. Ding 5 Expires: February 28, 2014 Cambridge University / Helsinki University 6 August 27, 2013 8 Service Discovery in a Multiple Connection Environment: Problem 9 Statement 10 draft-cao-mif-srv-dis-ps-03 12 Abstract 14 This document analyzes the problems of service discovery in a 15 multiple connection environment. A multiple connection environment 16 consists of multiple-interfaced nodes connecting to multiple networks 17 or multiple provisioning domains. Given a type of service a 18 multiple-interfaced client is looking for, the discovery progress 19 ought to return a correct pointer to the service instance that the 20 client is able to access without trying every available channel. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 28, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements and Terminology . . . . . . . . . . . . . . . . 3 58 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Mif Scenario . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Homenet Scenario . . . . . . . . . . . . . . . . . . . . 5 63 4. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 A multihomed host has multiple provisioning domains via physical and/ 74 or virtual interfaces. A multihomed host receives node configuration 75 information from each of its access networks, through various 76 mechanisms such as DHCP, PPP and IPv6 Router Advertisements. When 77 the received node-scoped configuration objects have different values 78 from each administration domains, such as different DNS servers IP 79 addresses, different default gateways or different address selection 80 policies, the node has to decide which it will use or how it will 81 merge them. 83 Issues regarding how the multi-homed host uses the configuration 84 objects have been addresses in [RFC6418]. Current practices of how 85 the various implementations handle these problems are introduced in 86 [RFC6419]. [RFC6731] extends DHCPv6 to inform the host which DNS 87 server it ought to select to send the query request, and DNS based 88 Service Discovery (DNS-SD) has been specified in [RFC6763]. 90 This document analyzes the problem of service discovery in a multiple 91 connection environment. A multiple connection environment consists 92 of multiple-interfaces nodes connecting to multiple networks or 93 multiple provisioning domains. Given a type of service a multiple- 94 interfaced client is looking for, the discovery progress ought to 95 return a correct pointer to the service instance that the a client is 96 able to access. 98 2. Requirements and Terminology 100 2.1. Requirements 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2.2. Terminology 108 Service Domain 110 A set of services that can be accessed by users. Besides 111 providing services, a service domain is responsible for delivering 112 configuration and pointers that ensure a guaranteed service 113 access. 115 Service Discovery 117 Procedure to acquire information that is necessary to access 118 service. 120 Multiple Connection Environment 122 Consists of multiple-interfaced nodes that connect to multiple 123 networks or multiple provisioning domains. 125 3. Scenarios 127 We describe two scenarios in this section, one related to Multiple 128 Interfaces, and the other one related to Home Networks (homenet). 130 3.1. Mif Scenario 132 The service discovery process can be summarized as the following five 133 steps. 135 1. Service Discovery Preparation: the host determines which 136 interface it should send a query request based on the 137 configuration information. 139 2. Service Query Request: the host sends a query request to find a 140 service. The query should include a description of the service, 141 for example, a full-qualified domain name, a URI, or an 142 application-specific naming of the service. 144 3. Service Request Handling: any entity that receives the query 145 request should handle the request. The entity should understand 146 the meaning of the request, and check the semantics of the 147 request language before giving an answer back. 149 4. Service Query Response: the entity that receives the query 150 request should reply with an answer to the query. The answer 151 should include a pointer to the service. 153 5. Service Access: the host accesses the service via the pointer 154 provided in the query response. The host is supposed to be able 155 to get the service instance via the pointer under a successful 156 and efficient service discovery mechanism, unless the servers in 157 such service domain encounter problems e.g. a web server is down. 159 Figure 1 shows a typical scenario for service discovery in a multiple 160 connection environment. It is common in today's mobile Internet that 161 a host is equipped with multiple network interfaces. On the service 162 domain, different services are deployed and some services may not be 163 accessible to a certain interface on the host due to security concern 164 or access policy. The connectivity each interface provides may not 165 be restricted to Internet access. For instance, WLAN and bluetooth 166 can offer direct access to potential services e.g. printers via local 167 ad-hoc connectivity. In such multiple connection environment, the 168 service discovery process should return a correct point to the host 169 and ensure that the host can access the service via this pointer. 170 This situation makes the multiple interface service discovery 171 different from the typical one-interface Internet access scenario. 172 Furthermore, the growing usage of IPv6 in the homenet environment has 173 made service discovery more challenging that requires thorough 174 investigation. 176 +-------------------------------------------+ 177 | Host with multiple interfaces | 178 | | 179 | | 180 | +---+ +---+ +---+ ... +---+ | 181 | | | | | | | ... | | | 182 +-----+--------+--------+-------------+-----+ 183 | | | | 184 3G WLAN__ Bluetooth ... Wired 185 / \________ \__ \ 186 / \____ \ \ 187 ---------------------------------------------------------------------- 188 +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ Service Domain 189 ( Service ) ( Service ) 190 \________________/ \_______________/ 192 Figure 1: Multiple Interface Host with Multiple Available Services 194 3.2. Homenet Scenario 196 We also describe the issues related to the homenet architecture 197 [I-D.ietf-homenet-arch], as depicted in Figure 2. 199 Suppose one MIF host is connected to three domains: homenet domain, 200 3gpp domain and a WiFi or enterprise domain. There is one service 201 that is named with the private domain name, say 'temperature.ietf', 202 which is only resolvable via the domain name service residing inside 203 the homenet and is supported by the multicast dns service [RFC6762]. 205 There are several problems in this scenario. First of all, since the 206 host has two unicast dns domains configured over the 3GPP and WiFi, 207 and as well as a multicast service discovery domain within the 208 homenet, the host does not know which domain it should send a dns 209 resolution request. Secondly, even if coupled with the split dns 210 solution [RFC6731], the configuration information obtained from DHCP 211 supports only those two unicast dns domains, but not the homenet 212 domain which is normally considered as 'zero-configuration'. Third, 213 the service discovery problem will become more complicated if the 214 host is connecting to more than one home networks, i.e., multiple 215 multicast dns domains. 217 +--------------+ 218 | 3GPP Domain | 219 +--------------+ 220 | 221 +--------------+ +---+ | 222 |Homenet Domain|------| H |----------------+ 223 +--------------+ +---+ | 224 | 225 +--------------+ 226 | Wi-Fi | 227 | Domain | 228 +--------------+ 230 Figure 2: Homenet Scenario 232 4. Problem Analysis 234 The problems that a multiple-interfaced host may meet during the 235 service discovery include: 237 1. How the query requests are sent? Because there are multiple 238 interfaces available and multiple service rendezvous existing, 239 the host should decide which destination it ought to send the 240 query to. And if there is a round-robin mechanism, the host 241 should determine the order of the query request. 243 2. How to handle the query and reply? Some pointers to the service 244 are restricted to a local scope or a certain interface, e.g., an 245 office printer may not be accessible to the 3G-interface. The 246 service discovery process is supposed to return a pointer that is 247 accessible to the host. 249 3. How to access the service? Given the pointer to the service, the 250 host should be able to determine from which interface it can 251 access the service. 253 The existing work of [RFC6418] and [RFC6419] have covered the general 254 problems encountered by hosts accessing multiple provisioning 255 domains, but the focus is on connectivity and configuration. 256 Proposal of Happy Eyeball in [I-D.ietf-mif-happy-eyeballs-extension] 257 allows a host with multiple interfaces to pick a suitable one for 258 access and enables automatic fallback. In a DNS based service 259 discovery [RFC6763], the problem of domain split is analyzed in the 260 [RFC6731]. The document defines an extension to the DHCPv4 and 261 DHCPv6 to inform the MIF host which domain scope the Recursive DNS 262 Server(RDNSS) is serving for, so that the "service query request" can 263 be sent to the correct RDNSS to get an answer. 265 The existing proposals resolve the partial problem in the service 266 discovery process mentioned above. To highlight the missing blocks, 267 Figure 3 provides a 'gap' analysis. In the figure, we compare three 268 existing solutions on service discovery, DNS-SD[RFC6763], DNS-Server- 269 Selection [RFC6731], and MIF Happy Eyeball 270 [I-D.ietf-mif-happy-eyeballs-extension], from three aspects as 271 mentioned above. The DNS-Srv-Sel solution uses the defined DHCP 272 option for the MIF host to select the corresponding DNS Server, and 273 MIF-HE inherits this method in its most updated version. The MIF-HE 274 can help host failover to the workable interface during service 275 access while DNS-Srv-Sel does not handle this particular issue. The 276 DNS-SD is not designed for a multiple interfaces environment and DNS 277 server selection and request handling are based on standard DNS 278 behaviors. 280 +-------------+----------------+----------------+----------------+ 281 |Aspects \Sol | DNS-SD | DNS-Srv-Sel | MIF-HE | 282 +-------------+----------------+----------------+----------------+ 283 |How to | Std. DNS | DHCP Option | Same as | 284 |Send Query | behavior | informed | DNS-Srv-Sel | 285 +-------------+----------------+----------------+----------------+ 286 |How to Handle| Std. DNS server| selection based| Same as | 287 |Queries | behavior | on option | DNS-Srv-Sel | 288 +-------------+----------------+----------------+----------------+ 289 |How to Access|no guarantee | not possible if| Failover to the| 290 |service |of connectivity | ports rejected | Happiest one | 291 +-------------+----------------+----------------+----------------+ 293 Figure 3: Gap Analysis of Existing Service Discovery Methods 295 In a complicated network as shown in Figure 4 , the host connects to 296 the enterprise network via the wired interface, a WLAN network with 297 the 802.11 interface, and an operator's network via the cellular 298 interface. The three intranets have their own Firewall policies to 299 the global Internet. On the enterprise network, many outgoing ports 300 are restricted, and on the WLAN and operator's public network, there 301 is more freedom. If the MIF host makes a DNS-SRV query to a service 302 in a global domain, all the RDNS servers have the corresponding 303 records. But say the service port number has been blocked by the 304 enterprise network administrator, the DNS has no such information. 305 Even if the DNS returns a pointer to the MIF host, the MIF host 306 cannot access this service via the wired interface. 308 +---------------+ 309 | RDNSS with | | Enterprise 310 +------+ | public + |----| Intranet 311 | | | enterprise's | | 312 | |------Wired -----| private names | | 313 | | +---------------+ +----------+----+ 314 | MIF | | FW | 315 | node | +----+ 316 | | +---------------+ +----+ | 317 | |----- WLAN ------| RDNSS with |--| FW |-----| Public 318 | | | public names | +----+ | Internet 319 | | +---------------+ | 320 | | +----+ 321 | | | FW | 322 | | +---------------+ +----------+----+ 323 | |---- Cellular ---| RDNSS with | | 324 +------+ | public + | | Operator 325 | operator's |----| Intranet 326 | private names | | 327 +---------------+ 329 Figure 4: Scenario of Multiple Interface DNS Service Discovery 331 CoAP [I-D.ietf-core-coap] is an IETF designed RESTful protocol for 332 constrianed environment. CoAP defines a link-format for service 333 discovery of the particular CoAP server, i.e., "/.well-known/core". 334 If the CoAP client has multiple access networks as shown in Figure 5, 335 the situation turns to be more complex. For instance, if the MIF 336 client wants to find a humidity sensing resource, but does not know 337 which domain contains the information, it basically needs to send 338 multiple CoAP GET requests with the well-known URL. Once it gets a 339 response for the required resource, it can send the corresponding 340 request to get the information. However this way is sub-optimal 341 especially for constrained devices. MIF service discovery SHOULD 342 consider the efficiency of the service discovery process. 344 +---------------+ +--------+ +----------+ 345 | Internal |________| MIF |__________| External | 346 | Domain | | Host | | Domain | 347 +---------------+ +--------+ +----------+ 348 | GET /.well-known/core | | 349 |<------------------------| GET /.well-known/core | 350 | |----------------------->| 351 | ACK CON | ACK CON | 352 |------------------------>|<-----------------------| 353 | | GET ~/hum | 354 | |----------------------->| 356 Figure 5: CoAP Service Discovery for a MIF Host 358 As a summary of the above analysis, the general problems and 359 requirements of service discovery in a MIF environment can be 360 summarized as follows: 362 Service Directory Service Configuration: Service directory is the 363 entity that stores or can get the stored relationship between 364 service names and service pointers. Different interfaces or 365 provisioning domains have their different service directories. 366 How to configure them on the MIF host and how the MIF host 367 utilizes the configured information are important for the service 368 discovery process to behave correctly. 370 Service Directory Selection: After the service directory 371 information is configured on the host, the host is able to select 372 the correct directory to send the query. The host can utilize 373 auxiliary information available or send the query to all the 374 directories that have been configured. The behavior of MIF host 375 to select a correct directory is also important for a stable 376 system. 378 Service Pointer/Address Resolution: The same service may have 379 different available addresses and pointers, and some service has 380 limited connectivity. So the resolution process should be able to 381 return to the MIF host a record that is accessible from at least 382 one of the interfaces. Efficiency SHOULD be taken into 383 consideration in this phase. 385 Service Route Selection: With the pointers returned, the host should 386 route the service level data to the service instance identified by 387 the returned pointers. 389 5. IANA Considerations 391 This document has no IANA requests. 393 6. Security Considerations 395 The query response exchanges should be protected by security 396 mechanisms. If the response contains invalid information, e.g. a 397 pointer to a worm website, it harms. As a consequence, the service 398 discovery should protect bogus information injected by attackers or 399 intruders. The security consideration ought to be made by the 400 underlining protocols, and it is out the scope of this problem 401 statement document. 403 7. References 405 7.1. Normative References 407 [I-D.ietf-mif-happy-eyeballs-extension] 408 Chen, G., Williams, C., Wing, D., and A. Yourtchenko, 409 "Happy Eyeballs Extension for Multiple Interfaces", draft- 410 ietf-mif-happy-eyeballs-extension-02 (work in progress), 411 February 2013. 413 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 414 Recursive DNS Server Selection for Multi-Interfaced 415 Nodes", RFC 6731, December 2012. 417 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 418 February 2013. 420 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 421 Discovery", RFC 6763, February 2013. 423 7.2. Informative References 425 [I-D.ietf-core-coap] 426 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 427 Application Protocol (CoAP)", draft-ietf-core-coap-18 428 (work in progress), June 2013. 430 [I-D.ietf-homenet-arch] 431 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 432 "Home Networking Architecture for IPv6", draft-ietf- 433 homenet-arch-10 (work in progress), August 2013. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 439 Provisioning Domains Problem Statement", RFC 6418, 440 November 2011. 442 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 443 Multiple-Interface Hosts", RFC 6419, November 2011. 445 Authors' Addresses 447 Zhen Cao 448 China Mobile 449 Xuanwumenxi Ave. No. 32 450 Beijing 100871 451 China 453 Phone: +86-10-52686688 454 Email: zehn.cao@gmail.com, caozhen@chinamobile.com 456 Aaron Yi Ding 457 Cambridge University / Helsinki University 458 William Gates Building, 15 JJ Thomson Ave 459 CB3 0FD Cambridge 460 United Kingdom 462 Phone: +44-7934034801; +358-9-19151296 463 Email: Aaron.Ding@cl.cam.ac.uk