MIPSHOP WG G. Bajko Internet Draft Nokia Intended Status: Proposed Standard October 17, 2008 Expires: April 16, 2009 Locating IEEE 802.21 Mobility Servers using DNS draft-ietf-mipshop-mos-dns-discovery-04 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. 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 16, 2009. Abstract This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers which provide IEEE 802.21 [IEEE802.21] defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21 [IEEE802.21], in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [IEEE802.21]. 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. G. Bajko Expires 04/16/09 [Page 1] Locating Mobility Servers using DNS October 2008 Terminology and abbreviations used in this document Mobility Services: comprises of a set of different services provided by the network to mobile nodes to facilitate handover preparation and handover decision, as described in [IEEE802.21]. Mobility Server: a network node providing IEEE 802.21 Mobility Services. MIH: Media Independent Handover, as defined in [IEEE802.21]. MIH Service: IS, ES or CS type of service, as defined in [IEEE802.21]. Application service: is a generic term for some type of application, independent of the protocol that may be used to offer it. Each application service will be associated with an IANA- registered tag. Application protocol: is used to implement the application service. These are also associated with IANA-registered tags. Table of Content 1. Introduction....................................................2 2. Discovering a Mobility Server...................................3 2.1 Selecting a Mobility Service..............................3 2.2 Selecting the transport protocol..........................4 2.3 Determining the IP address and port.......................5 3. IANA Considerations.............................................6 4. Security Considerations.........................................6 5. Normative References............................................6 6. Informative References..........................................7 7. Author's Address................................................7 1. Introduction IEEE 802.21 [IEEE802.21] defines three distinct service types to facilitate link layer handovers across heterogeneous technologies: a) Information Services (IS) IS provides a unified framework to the higher layer entities across the heterogeneous network environment to facilitate discovery and selection of multiple types of networks existing within a geographical area, with the objective to help the higher layer mobility protocols to acquire a global view of the heterogeneous networks and perform seamless handover across these networks. b) Event Services (ES) Events may indicate changes in state and transmission behavior of the physical, data link and logical link layers, or predict G. Bajko Expires 04/16/09 [Page 2] Locating Mobility Servers using DNS October 2008 state changes of these layers. The Event Service may also be used to indicate management actions or command status on the part of the network or some management entity. c) Command Services (CS) The command service enables higher layers to control the physical, data link, and logical link layers. The higher layers may control the reconfiguration or selection of an appropriate link through a set of handover commands. In IEEE terminology these services are called Media Independent Handover (MIH) services. While these services may be co-located, the different pattern and type of information they provide does not necessitate the co- location. "Service Management" service messages, i.e., MIH registration, MIH capability discovery and MIH event subscription messages, are considered as ES and CS when transporting MIH messages over L3 transport. An MN may make use of any of these MIH service types separately or any combination of them. It is anticipated that a Mobility Server will not necessarily host all three of these MIH Services together, thus there is a need to discover the MIH Service types separately. This document defines a number of application service tags that allow service location without relying on rigid domain naming conventions. 2. Discovering a Mobility Server The procedures defined here assume that the MN knows the domain name of the network where it wants to locate a Mobility Server. The domain name of the network can either be pre-configured, discovered using DHCP or learned from a previous Information Service (IS) query [IEEE802.21] as described in [ID.ietf-mipshop-mstp-solution]. The procedures defined here result in an IP address, port and transport protocol where the MN can contact the Mobility Server which hosts the service the MN is looking for. 2.1 Selecting a Mobility Service The MN should know the characteristics of the Mobility Services defined in [IEEE802.21] and based on that it should be able to select the service it wants to use to facilitate its handover. The services it can choose from are: - Information Service (IS) - Information Service over a secure connection (ISs) - Event Service (ES) G. Bajko Expires 04/16/09 [Page 3] Locating Mobility Servers using DNS October 2008 - Event Service over a secure connection (ESs) - Command Service (CS) - Command Service over a secure connection (CSs) The service identifiers for the services are "IS","ISs", "ES", "ESs", "CS" and "CSs" respectively. The server supporting any of the above services MUST support at least UDP and TCP as transport, as described in [ID.ietf-mipshop- mstp-solution]. SCTP and other transport protocols MAY also be supported. 2.2 Selecting the transport protocol After the desired service has been chosen, the client selects the transport protocol it prefers to use. Note, that transport selection may impact the handover performance. The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "ID+M2X", where ID is the service identifier defined in the previous section and X is a letter that corresponds to a transport protocol supported by the domain. This specification defines M2U for UDP, M2T for TCP and M2S for SCTP. This document also establishes an IANA registry for NAPTR service name to transport protocol mappings. These NAPTR [RFC3403] records provide a mapping from a domain to the SRV [RFC2782] record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record will contain an empty regular expression and a replacement value, which indicates the domain name where the SRV record for that particular transport protocol can be found. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per [RFC3403], the client discards any records whose services fields are not applicable. The MN MUST discard any service fields that identify a resolution service whose value is not "M2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 3403 will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. As an example, consider a client that wishes to find IS service in the example.com domain. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: order pref flags service regexp replacement IN NAPTR 50 50 "s" "IS+M2T" "" _IS._tcp.example.com IN NAPTR 90 50 "s" "IS+M2U" "" _IS._udp.example.com This indicates that the domain does have a server providing IS services over TCP and UDP, in that order of preference. Since the G. Bajko Expires 04/16/09 [Page 4] Locating Mobility Servers using DNS October 2008 client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of _IS._tcp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 XXXX server1.example.com IN SRV 0 2 XXXX server2.example.com If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier "_IS" for the Information Service, "_ES" for the Event Service and "_CS" for Command Service. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. Note, that the regexp field in the NAPTR example above is empty. This document discourages the use of this field as its usage can be complex and error prone; and the discovery of the MIH services do not require the flexibility provided by this field over a static target present in the TARGET field. As another example, consider a client which wishes to find ES service over a secure connection. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: order pref flags service regexp replacement IN NAPTR 50 50 "s" "ESs+M2T" "" _ESs._tcp.example.com IN NAPTR 90 50 "s" "ESs+M2U" "" _ESs._udp.example.com This indicates that the domain does have a server providing ES services over a secure connection, in the above case TLSoverTCP and DTLSoverUDP. When a transport protocol is specified explicitly, the client will perform an SRV query for that specific transport using the service identifier of the Mobility Service. 2.3 Determining the IP address and port Once the server providing the desired service and the transport protocol has been determined, the next step is to determine the IP address and port. If TARGET is a numeric IP address, the MN uses that IP address and the already chosen transport to contact the server providing the desired service. If the TARGET was not a numeric IP address, then the MN performs an A and/or AAAA record lookup of the domain name, as appropriate. The G. Bajko Expires 04/16/09 [Page 5] Locating Mobility Servers using DNS October 2008 result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously. If the result of the SRV query contains a port number, then the MN SHOULD contact the server at that port number. If the SRV record did not contain a port number then the MN SHOULD contact the server at the default port number of that particular service. A default port number for MIH services is requested from IANA in [ID.ietf-mipshop- mstp-solution]. 3. IANA considerations The usage of NAPTR records described here requires well known values for the service fields for each transport supported by Mobility Services. The table of mappings from service field values to transport protocols is to be maintained by IANA. The registration in the RFC MUST include the following information: Service Field: The service field being registered. Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with reference to a document that describes the transport protocol. Name and Contact Information: The name, address, email address and telephone number for the person performing the registration. The following values have been placed into the registry: Service Fields Protocol IS+M2T TCP ISs+M2T TLSoverTCP (RFC 5246) IS+M2U UDP ISs+M2U DTLSoverUDP (RFC 4347) IS+M2S SCTP ISs+M2S TSLoverSCTP (RFC 3436) ES+M2T TCP ESs+M2T TLSoverTCP (RFC 5246) ES+M2U UDP ESs+M2U DTLSoverUDP (RFC 4347) ES+M2S SCTP ESs+M2S TLSoverSCTP (RFC 3436) CS+M2T TCP CSs+M2T TLSoverTCP (RFC 5246) CS+M2U UDP CSs+M2U DTLSoverUDP (RFC 4347) CS+M2S SCTP CSs+M2S TLSoverSCTP (RFC 3436) G. Bajko Expires 04/16/09 [Page 6] Locating Mobility Servers using DNS October 2008 New Service Fields are to be added via Standards Action as defined in [RFC5226]. New entries to the table that specify additional transport protocols for the existing Service Fields may be registered by IANA on a First Come First Served' basis [RFC5226]. 4. Security considerations A list of known threats to services using DNS is documented in [RFC3833]. For most of those identified threats, the DNS Security Extensions [RFC4033] does provide protection. It is therefore recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC4641] when deploying IEEE 802.21 Mobility Services. In deployments where DNSSEC usage is not feasible, measures should be taken to protect against forged DNS responses and cache poisoning as much as possible. Efforts in this direction are documented in [ID.ietf-dnsext-forgery-resilience]. 5. Normative References [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 6. Informative References [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area Networks: Media Independent Handover Services [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. G. Bajko Expires 04/16/09 [Page 7] Locating Mobility Servers using DNS October 2008 [ID.ietf-mipshop-mstp-solution] Mobility Services Transport Protocol Design, Melia et al, April 2008, work in progress [ID.ietf-dnsext-forgery-resilience] Measures for making DNS more resilient against forged answers, Hubert et al, August 2008, work in progress 7. Author's Addresses Gabor Bajko gabor(dot)bajko(at)nokia(dot)com G. Bajko Expires 04/16/09 [Page 8] Locating Mobility Servers using DNS 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). G. Bajko Expires 04/16/09 [Page 9]