idnits 2.17.1 draft-ietf-mipshop-mos-dns-discovery-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE802.21]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 254 has weird spacing: '...f flags servi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ID.ietf-mipshop-mos-dhcp-options' is defined on line 406, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.ietf-mipshop-mstp-solution' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.ietf-mipshop-mos-dhcp-options' -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP WG G. Bajko 3 Internet Draft Nokia 4 Intended Status: Proposed Standard July 12, 2009 5 Expires: January 11, 2010 7 Locating IEEE 802.21 Mobility Servers using DNS 8 draft-ietf-mipshop-mos-dns-discovery-07 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 11, 2010. 33 Copyright and License Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your 42 rights and restrictions with respect to this document. 44 Abstract 46 This document defines application service tags that allow service 47 location without relying on rigid domain naming conventions, and DNS 48 procedures for discovering servers which provide IEEE 802.21 49 [IEEE802.21] defined Mobility Services. Such Mobility Services are 50 used to assist a Mobile Node (MN) supporting IEEE 802.21 51 [IEEE802.21], in handover preparation (network discovery) and 52 handover decision (network selection). The services addressed by 53 this document are the Media Independent Handover Services defined in 54 [IEEE802.21]. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in RFC-2119. 62 Terminology and abbreviations used in this document 64 Mobility Services: comprises of a set of different services provided 65 by the network to mobile nodes to facilitate handover preparation 66 and handover decision, as described in [IEEE802.21]. 68 Mobility Server: a network node providing IEEE 802.21 Mobility 69 Services. 71 MIH: Media Independent Handover, as defined in [IEEE802.21]. 73 MIH Service: MIHIS, MIHES or MIHCS type of service, as defined in 74 [IEEE802.21]. 76 Application service: is a generic term for some type of 77 application, independent of the protocol that may be used to offer 78 it. Each application service will be associated with an IANA- 79 registered tag. 81 Application protocol: is used to implement the application service. 82 These are also associated with IANA-registered tags. 84 Home domain: the DNS suffix of the operator with which the Mobile 85 Node has a subscription service. The suffix is usually stored in the 86 Mobile Node as part of the subscription. 88 Table of Content 90 1. Introduction....................................................2 91 2. Discovering a Mobility Server...................................3 92 2.1 Selecting a Mobility Service..............................4 93 2.2 Selecting the transport protocol..........................4 94 2.3 Determining the IP address and port.......................6 95 3. IANA Considerations.............................................6 96 4. Security Considerations.........................................7 97 5. Normative References............................................8 98 6. Informative References..........................................8 99 7. Author's Address................................................9 101 1. Introduction 102 IEEE 802.21 [IEEE802.21] defines three distinct service types to 103 facilitate link layer handovers across heterogeneous technologies: 105 a) MIH Information Services (MIHIS) 106 IS provides a unified framework to the higher layer entities 107 across the heterogeneous network environment to facilitate 108 discovery and selection of multiple types of networks existing 109 within a geographical area, with the objective to help the 110 higher layer mobility protocols to acquire a global view of the 111 heterogeneous networks and perform seamless handover across 112 these networks. 114 b) MIH Event Services (MIHES) 115 Events may indicate changes in state and transmission behavior 116 of the physical, data link and logical link layers, or predict 117 state changes of these layers. The Event Service may also be 118 used to indicate management actions or command status on the 119 part of the network or some management entity. 121 c) MIH Command Services (MIHCS) 122 The command service enables higher layers to control the 123 physical, data link, and logical link layers. The higher layers 124 may control the reconfiguration or selection of an appropriate 125 link through a set of handover commands. 127 In IEEE terminology these services are called Media Independent 128 Handover (MIH) services. 129 While these services may be co-located, the different pattern and 130 type of information they provide does not necessitate the co- 131 location. 133 "Service Management" service messages, i.e., MIH registration, MIH 134 capability discovery and MIH event subscription messages, are 135 considered as MIHES and MIHCS when transporting MIH messages over L3 136 transport. 138 An Mobile Node (MN) may make use of any of these MIH service types 139 separately or any combination of them. 141 It is anticipated that a Mobility Server will not necessarily host 142 all three of these MIH Services together, thus there is a need to 143 discover the MIH Service types separately. 145 This document defines a number of application service tags that 146 allow service location without relying on rigid domain naming 147 conventions. 149 2. Discovering a Mobility Server 151 The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to 152 implement lazy binding of strings to data, in order to support 153 dynamically configured delegation systems. The DDDS functions by 154 mapping some unique string to data stored within a DDDS Database by 155 iteratively applying string transformation rules until a terminal 156 condition is reached. When DDDS uses DNS as a distributed database 157 of Rules, these Rules are encoded using the Naming Authority Pointer 158 (NAPTR) Resource Record (RR). One of these Rules is the First Well 159 Known Rule, which says where the process starts. 161 In current specifications, the First Well Known Rule in a DDDS 162 application [RFC3403] is assumed to be fixed, ie the domain in the 163 tree where the lookups are to be routed to, is known. This document 164 proposes the input to the First Well Known Rule to be dynamic, based 165 on the search path the resolver discovers or is configured with. 167 The search path of the resolver can either be pre-configured, 168 discovered using DHCP or learned from a previous MIH Information 169 Service (IS) query [IEEE802.21] as described in 170 [ID.ietf-mipshop-mstp-solution]. 172 When the MN needs to discover Mobility Services in its home domain, 173 the input to the First Well Known Rule MUST be the MN's home domain, 174 which is assumed to be pre-configured in the MN. 176 When the MN needs to discover Mobility Services in a local (visited) 177 domain, it SHOULD use DHCP as described in [ID.ietf-mipshop-mos- 178 dhcp-options] to discover the IP address of the server hosting the 179 desired service, and contact it directly. In some instances, the 180 discovery may result in a per protocol/application list of domain 181 names which are then to be used as starting points for the 182 subsequent NAPTR lookups. If neither IP address or domain name can 183 be discovered with the above procedure, the MN MAY request for a 184 domain search list, as described in [RFC3397] and [RFC3646], and use 185 it as input to the DDDS application. 187 The MN may also have a list of cached domain names of Service 188 Providers, learned from a previous MIH Information Service (IS) 189 query [IEEE802.21]. If the cache entries have not expired, they can 190 be used as input to the DDDS application. 192 When the MN does not find valid domain names using the procedures 193 above, it MUST stop any attempt to discover MIH Services. 195 The dynamic rule described above SHOULD NOT be used for discovering 196 services other than MIH Services described in this document, unless 197 stated otherwise by a future specification. 199 The procedures defined here result in an IP address, port and 200 transport protocol where the MN can contact the Mobility Server 201 which hosts the service the MN is looking for. 203 2.1 Selecting a Mobility Service 204 The MN should know the characteristics of the Mobility Services 205 defined in [IEEE802.21] and based on that it should be able to 206 select the service it wants to use to facilitate its handover. The 207 services it can choose from are: 208 - Information Service (MIHIS) 209 - Event Service (MIHES) 210 - Command Service (MIHCS) 212 The service identifiers for the services are "MIHIS", "MIHES", and 213 "MIHCS" respectively. 214 The server supporting any of the above services MUST support at 215 least UDP and TCP as transport, as described in [ID.ietf-mipshop- 216 mstp-solution]. SCTP and other transport protocols MAY also be 217 supported. 219 2.2 Selecting the transport protocol 221 After the desired service has been chosen, the client selects the 222 transport protocol it prefers to use. Note, that transport selection 223 may impact the handover performance. 225 The services relevant for the task of transport protocol selection 226 are those with NAPTR service fields with values "ID+M2X", where ID 227 is the service identifier defined in the previous section and X is a 228 letter that corresponds to a transport protocol supported by the 229 domain. This specification defines M2U for UDP, M2T for TCP and M2S 230 for SCTP. This document also establishes an IANA registry for 231 NAPTR service name to transport protocol mappings. 233 These NAPTR [RFC3403] records provide a mapping from a domain to the 234 SRV [RFC2782] record for contacting a server with the specific 235 transport protocol in the NAPTR services field. The resource record 236 MUST contain an empty regular expression and a replacement value, 237 which indicates the domain name where the SRV record for that 238 particular transport protocol can be found. If the server supports 239 multiple transport protocols, there will be multiple NAPTR records, 240 each with a different service value. As per [RFC3403], the client 241 discards any records whose services fields are not applicable. 243 The MN MUST discard any service fields that identify a resolution 244 service whose value is not "M2X", for values of X that indicate 245 transport protocols supported by the client. The NAPTR processing 246 as described in RFC 3403 will result in the discovery of the most 247 preferred transport protocol of the server that is supported by the 248 client, as well as an SRV record for the server. 250 As an example, consider a client that wishes to find MIHIS service 251 in the example.com domain. The client performs a NAPTR query for 252 that domain, and the following NAPTR records are returned: 254 order pref flags service regexp replacement 255 IN NAPTR 50 50 "s" "MIHIS+M2T" "" _MIHIS._tcp.example.com 256 IN NAPTR 90 50 "s" "MIHIS+M2U" "" _MIHIS._udp.example.com 258 This indicates that the domain does have a server providing MIHIS 259 services over TCP and UDP, in that order of preference. Since the 260 client supports TCP and UDP, TCP will be used, targeted to a host 261 determined by an SRV lookup of _MIHIS._tcp.example.com. That lookup 262 would return: 264 ;; Priority Weight Port Target 265 IN SRV 0 1 XXXX server1.example.com 266 IN SRV 0 2 XXXX server2.example.com 268 If no NAPTR records are found, the client constructs SRV queries for 269 those transport protocols it supports, and does a query for each. 270 Queries are done using the service identifier "_MIHIS" for the MIH 271 Information Service, "_MIHES" for the MIH Event Service and "_MIHCS" 272 for the MIH Command Service. A particular transport is supported if 273 the query is successful. The client MAY use any transport protocol 274 it desires which is supported by the server. 276 Note, that the regexp field in the NAPTR example above is empty. The 277 regexp field MUST NOT be used when discovering MIH services, as its 278 usage can be complex and error prone; and the discovery of the MIH 279 services do not require the flexibility provided by this field over 280 a static target present in the TARGET field. 282 If the client is already configured with the information about which 283 transport protocol is used for a mobility service in a particular 284 domain, it can directly perform an SRV query for that specific 285 transport using the service identifier of the Mobility Service. For 286 example, if the client knows that it should be using TCP for MIH IS 287 service, it can perform a SRV query directly for 288 _MIHIS._tcp.example.com. 290 2.3 Determining the IP address and port 292 Once the server providing the desired service and the transport 293 protocol has been determined, the next step is to determine the IP 294 address and port. 296 The response to the SRV DNS query contains the port number in the 297 Port field of the SRV RDATA. 299 According to the specification of SRV RRs in [RFC2782], the TARGET 300 field is a fully qualified domain name (FQDN) which MUST have one or 301 more address records; the FQDN must not be an alias, i.e., there 302 MUST NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS 303 query already has reported a sufficient number of these address 304 records in the Additional Data section of the DNS response (as 305 recommended by [RFC2782]), the MN needs to perform A and/or AAAA 306 record lookup(s) of the domain name, as appropriate. The result will 307 be a list of IP addresses, each of which can be contacted using the 308 transport protocol determined previously. 310 If the result of the SRV query contains a port number, then the MN 311 SHOULD contact the server at that port number. If the SRV record did 312 not contain a port number then the MN SHOULD contact the server at 313 the default port number of that particular service. A default port 314 number for MIH services is requested from IANA in [ID.ietf-mipshop- 315 mstp-solution]. 317 3. IANA considerations 319 The usage of NAPTR records described here requires well known values 320 for the service fields for each transport supported by Mobility 321 Services. The table of mappings from service field values to 322 transport protocols is to be maintained by IANA. 324 The registration in the RFC MUST include the following information: 326 Service Field: The service field being registered. 328 Protocol: The specific transport protocol associated with that 329 service field. This MUST include the name and acronym for the 330 protocol, along with reference to a document that describes the 331 transport protocol. 333 Name and Contact Information: The name, address, email address 334 and telephone number for the person performing the 335 registration. 337 The following values have been placed into the registry: 339 Service Fields Protocol 340 MIHIS+M2T TCP 341 MIHIS+M2U UDP 342 MIHIS+M2S SCTP 343 MIHES+M2T TCP 344 MIHES+M2U UDP 345 MIHES+M2S SCTP 346 MIHCS+M2T TCP 347 MIHCS+M2U UDP 348 MIHCS+M2S SCTP 350 New Service Fields are to be added via Standards Action as defined 351 in [RFC5226]. 353 New entries to the table that specify additional transport protocols 354 for the existing Service Fields may similarly be registered by IANA 355 through Standards Action [RFC5226]. 357 IANA is also requested to register MIHIS, MIHES, MIHCS as service 358 names in the port registry. 360 4. Security considerations 362 A list of known threats to services using DNS is documented in 363 [RFC3833]. For most of those identified threats, the DNS Security 364 Extensions [RFC4033] does provide protection. It is therefore 365 recommended to consider the usage of DNSSEC [RFC4033] and the 366 aspects of DNSSEC Operational Practices [RFC4641] when deploying 367 IEEE 802.21 Mobility Services. 369 In deployments where DNSSEC usage is not feasible, measures should 370 be taken to protect against forged DNS responses and cache poisoning 371 as much as possible. Efforts in this direction are documented in 372 [ID.ietf-dnsext-forgery-resilience]. 374 Where inputs to the procedure described in this document are fed via 375 DHCP, DHCP vulnerabilities can also cause issues. For instance, the 376 inability to authenticate DHCP discovery results may lead to the 377 mobility service results also being incorrect, even if the DNS 378 process was secured. 380 5. Normative References 382 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 383 specifying the location of services (DNS SRV)", RFC 2782, 384 February 2000. 386 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 387 Part Three: The Domain Name System (DNS) Database", RFC 3403, 388 October 2002. 390 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 391 Rose, "DNS Security Introduction and Requirements", RFC 4033, 392 March 2005. 394 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 395 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 396 2008. 397 [RFC3397] B. Aboba and S. Cheshire, "DHCP Domain Search Option", RFC 398 3397, November 2002. 400 [RFC3646] R. Droms, "DNS Configuration options for DHCPv6", RFC 401 3646, December 2003. 403 [ID.ietf-mipshop-mstp-solution] Mobility Services Transport Protocol 404 Design, Melia et al, April 2008, work in progress 406 [ID.ietf-mipshop-mos-dhcp-options] DHCP Options for IEEE 802.21 407 Mobility Services (MoS) Discovery, Bajko et al, May 2009, work 408 in progress 410 6. Informative References 412 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 413 Networks: Media Independent Handover Services 414 http://www.ieee802.org/21/private/Published%20Spec/802.21- 415 2008.pdf (access to the document requires membership) 417 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 418 RFC 4641, September 2006. 420 [RFC3401] M. Mealling, "Dynamic Delegation Discovery System (DDDS) 421 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 423 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 424 Name System (DNS)", RFC 3833, August 2004. 426 [ID.ietf-dnsext-forgery-resilience] Measures for making DNS more 427 resilient against forged answers, Hubert et al, August 2008, 428 work in progress 430 7. Author's Addresses 432 Gabor Bajko 433 gabor(dot)bajko(at)nokia(dot)com