Mipshop WG T. Melia, Ed. Internet-Draft CISCO Intended status: Standards Track G. Bajko Expires: August 15, 2008 Nokia S. Das Telcordia N. Golmie NIST S. Xia Huawei JC. Zuniga InterDigital February 12, 2008 Mobility Services Framework Design draft-ietf-mipshop-mstp-solution-01 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 August 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Melia, et al. Expires August 15, 2008 [Page 1] Internet-Draft MSFD February 2008 Abstract This document describes a design solution for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document describes mechanisms for mobility service (MoS) discovery and transport layer mechanisms for the reliable delivery of MIH messages. Requirements Language 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 7 3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 7 3.3. Scenario S3: Roaming MoS . . . . . . . . . . . . . . . . . 8 3.4. Scenario S4: Third party MoS . . . . . . . . . . . . . . . 8 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 11 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 12 5.2. MoS Discovery when MIN is in visited network and MoSv is also in visited network (Scenario S2) . . . . . . . . . 13 5.3. MOS Discovery when the MN is in a visited Network and Services are at the Home network (Scenario S3) . . . . . . 14 5.4. MoS discovery when MIH services are in a 3rd party remote network (scenario S4) . . . . . . . . . . . . . . . 17 6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 18 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 19 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 19 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 20 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 20 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 21 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 Melia, et al. Expires August 15, 2008 [Page 2] Internet-Draft MSFD February 2008 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 29 Melia, et al. Expires August 15, 2008 [Page 3] Internet-Draft MSFD February 2008 1. Introduction This document proposes a solution to the issues identified in the problem statement document [I-D.ietf-mipshop-mis-ps] for the layer 3 transport of IEEE 802.21 MIH protocols. The MIH Layer 3 transport problem is divided in two main parts: the discovery of a node that supports specific Mobility Services (MoS) and the transport of the information between a mobile node (MN) and the discovered node. The discovery process is required for the MN to obtain the information needed for MIH protocol communication with a peer node. The information includes the transport address (e.g., the IP address) of the peer node and the types of MoS provided by the peer node. This document lists the major MoS deployment scenarios. It next describes the solution architecture, including the MSTP reference model and MIHF identifiers. A description follows of MoS discovery procedures when the MN is in a home or remote network. The remainder of the document describes the MIH transport architecture, example message flows for several signaling scenarios, and security issues. 2. Terminology The following acronyms and terminology are used in this document: MIH Media Independent Handover: the handover support architecture defined by the IEEE 802.21 working group that consists of the MIH Function (MIHF), MIH Network Entities, MIH Event messages, and MIH command messages. MIHF Media Independent Handover Function: a cross-layer function that provides handover services including the Event Service (ES), Information Service (IS), and Command Service (CS), through service access points (SAPs) defined by the IEEE 802.21 working group. MIHF User an MIH client that uses the MIH SAPs to access MIHF services, and which is responsible for initiating and terminating MIH signaling MIHFID Media Independent Handover Function Identifier: an identifier required to uniquely identify the MIHF endpoints for delivering mobility services (MoS); it is implemented as either a FQDN or NAI. Melia, et al. Expires August 15, 2008 [Page 4] Internet-Draft MSFD February 2008 MoS Mobility Services: those services, as defined in the MIH problem statement document [I-D.ietf-mipshop-mis-ps] , which include the MIH IS, CS, and ES services defined by the IEEE 802.21 standard. MoSh Mobility Services assigned in the mobile node's Home Network MoSv Mobility Services assigned in the Visited Network, which is any network other than the mobile node's home network MoS3 Mobility Services assigned in a 3rd Party Network, which is a network that is neither the Home Network nor the current Visited Network. MN Mobile Node: an Internet device whose location changes, along with its point of connection to the network. NN Network Node: an Internet device whose location and network point of attachment do not change MSTP Mobility Services Transport Protocol: a protocol that is used to deliver MIH signaling messages from an MIHF to other MIH-aware nodes in a network. IS Information Service: a MoS that originates at the lower or upper layers and sends information to the local or remote upper or lower layers. It can use secure or insecure ports to transport information elements (IEs) and information about various neighboring nodes. Its architecture is outside the scope of the IEEE 802.21 draft document. ES Event Service: a MoS that originates at a remote MIHF or the lower layers and sends information to the local MIHF or local higher layers. The purpose of the ES is to report changes in link status (e.g. Link Going Down messages) and transmission status. CS Command Service: a MoS that sends commands from the remote MIHF or local upper layers to the local lower layers to switch links or to get link status. FQDN Fully-Qualified Domain Name: a complete domain name for a host on the Internet, consisting of a host name followed by a domain name (e.g. hostname.domain.org) NAI Network Access Identifier: the user ID that a user submits during PPP authentication. For mobile users, the NAI identifies the user and helps to route the authentication request message. Melia, et al. Expires August 15, 2008 [Page 5] Internet-Draft MSFD February 2008 NAT Network Address Translator: A device that implements the Network Address Translation function described in [RFC3022], in which local or private network layer addresses are mapped to valid network addresses and port numbers. DHCP Dynamic Host Configuration Protocol: a protocol described in [RFC2131] that allows Internet devices to obtain IP addresses, subnet masks, default gateway addresses, and other IP configuration information from DHCP servers. DNS Domain Name System: a protocol described in [RFC1035] that translates domain names to IP addresses. AAA Authentication, Authorization and Accounting: a set of network management services that respectively determine the validity of a user's ID, determine whether a user is allowed to use network resources, and track users' use of network resources. AAA home AAA server: an AAA server located on the MN's home network AAA visited AAA server: an AAA server located a visited network that is not the MN's home network MIH ACK MIH Acknowledgement Message: a MIH signaling message that a MIHF sends in response to an MIH message from a sending MIHF, when UDP is used as the MSTP. PoS Point of Service, a network-side MIHF instance that exchanges MIH messages with a MN-based MIHF NAS Network Access Server: a server to which a MN initially connects when it is trying to gain a connection to a network and which determines whether the MN is allowed to connect to the NAS's network UDP Network Access Server: a server to which a MN initially connects when it is trying to gain a connection to a network and which determines whether the MN is allowed to connect to the NAS's network TCP Transmission Control Protocol: a stream-oriented transport layer protocol that provides a reliable delivery service with congestion control, defined in RFC 793. RTT Round-Trip Time: a estimation of the time required for a segment to travel from a source to a destination and an acknowledgement to return to the source that is used by TCP in connection with timer expirations to determine when a segment is considered lost and Melia, et al. Expires August 15, 2008 [Page 6] Internet-Draft MSFD February 2008 should be resent. MTU Maximum Transmission Unit: the largest size packet that can be sent on a network without requiring fragmentation [RFC1191]. TLS Transport Layer Security Protocol: an application layer protocol that assures privacy and data integrity between two communicating network entities [RFC4346]. 3. Deployment Scenarios This section describes the various possible deployment scenarios for the MN and the MoS. The relative positioning of MN and MoS affects resource discovery as well as the performance of the MIH signaling service. 3.1. Scenario S1: Home Network MoS In this scenario, the MN and the services are located in the home network. We refer to this set of services as MoSh as in Figure 1. The MoSh can be located at the access point the MN uses to connect to the home network, or it can be located elsewhere. +--------------+ +====+ | HOME NETWORK | |MoSh| +--------------+ +====+ /\ || \/ +--------+ | MN | +--------+ Figure 1: MoS in the Home network 3.2. Scenario S2: Visited Network MoS In this scenario, the MN is in the visited network and mobility services are provided by the visited network. We refer to this as MoSv as shown in Figure 2. Melia, et al. Expires August 15, 2008 [Page 7] Internet-Draft MSFD February 2008 +--------------+ | HOME NETWORK | +--------------+ /\ || \/ +====+ +-----------------+ |MoSv| | VISITED NETWORK | +====+ +-----------------+ /\ || \/ +--------+ | MN | +--------+ Figure 2: MoSV in the Visited Network 3.3. Scenario S3: Roaming MoS In this scenario, the MN is located in the visited network and all MIH services are provided by the home network, as shown in Figure 3. +====+ +--------------+ |MoSh| | HOME NETWORK | +====+ +--------------+ /\ || \/ +-----------------+ | VISITED NETWORK | +-----------------+ /\ || \/ +--------+ | MN | +--------+ Figure 3: MoS provided by the home while in visited 3.4. Scenario S4: Third party MoS In this scenario, the MN is in its home network or in a visited network and services are provided by a 3rd party network. We refer to this situation as MoS3 as shown in Figure 4. (Note that MoS can exist both in hom enad in visited). Melia, et al. Expires August 15, 2008 [Page 8] Internet-Draft MSFD February 2008 +--------------+ | HOME NETWORK | +====+ +--------------+ +--------------+ |MoS3| | THIRD PARTY | <===> /\ +====+ +--------------+ || \/ +-----------------+ | VISITED NETWORK | +-----------------+ /\ || \/ +--------+ | MN | +--------+ Figure 4: MoS form a third party Different types of MoS can be provided independently of other types and there is no strict relationship between ES, CS and IS, nor is there a requirement that the entities that provide these types be co- located. However, while IS tends to involve large amounts of static information, ES and CS are dynamic services and some relationship between them can be expected, e.g. a handover command (CS) could be issued upon reception of a link event (ES). Hence, while in theory MoS can be implemented in different locations, it is expected that ES and CS will be co-located, whereas IS can be co-located with ES/CS or located elsewhere. Therefore, having the flexibility at the MSTP to discover different services in different locations is an important feature that can be used to optimize handover performance. Resource discovery is discussed in more detail in Section 5. 4. Solution Overview As mentioned in Section 1 the solution space is being divided into two functional domains: discovery and transport. The following assumptions have been made: o The solution is aimed at supporting IEEE 802.21 MIH services, namely Information Service (IS), Event Service (ES), and Command Service (CS). o If the MIHFID is available, FQDN or NAI's realm is used for mobility service discovery. Melia, et al. Expires August 15, 2008 [Page 9] Internet-Draft MSFD February 2008 o The solutions are chosen to cover all possible deployment scenarios as described in Section 3. o MoS discovery can be performed during initial network attachment or thereafter. The MN could know or not the realm of the MoS to be discovered. In any case after the acquisition of the target realm (e.g. via Information Server or statically configured) the MN could either be pre-configured with the address of the MoS, or this address could be obtained through DHCP or DNS. The dynamic assignation methods are described in Section 5. The configuration of the MoS could be executed either upon network attachment or after successful IP configuration. The methodology to be used depends on the considered deployment scenario. Once the MIHF peer has been discovered, MIH information can be exchanged between MIH peers over a trasnport protocol such as UDP or TCP. The usage of transport protocols is described in Section 6. 4.1. Architecture Figure 5 depicts the MSTP reference model and its components within a node. The topmost layer is the MIHF user. This set of applications consists of one or more MIH clients that are responsible for such operations as maintaining MIH databases associated with the IS, processing Layer 2 triggers as part of the ES, and initiating and carrying out handover operations as part of the CS. Beneath the MIHF user set is the MIHF itself. This function is responsible for MoS discovery, as well as creating, maintaining, modifying, and destroying MIH signaling associations with other MIHFs located in MIH peer nodes. Below the MIHF are various transport layer protocols as well as address resolution functions. Melia, et al. Expires August 15, 2008 [Page 10] Internet-Draft MSFD February 2008 +--------------------------+ | MIHF User | +--------------------------+ || +--------------------------+ | MIHF | +--------------------------+ || || || +---------+ +------+ +-----+ | TCP/UDP | | DHCP | | DNS | +---------+ +------+ +-----+ Figure 5: MN stack The MIHF relies on the services provided by TCP and UDP for transporting MIH messages, and relies on DHCP and DNS for peer discovery. In cases where the peer MIHF IP address is not pre- configured, the source MIHF needs to discover it either via DHCP or DNS or a combination of both as described in Section 5. Once the peer MIHF is discovered, MIHF must exchange messages with its peer over either UDP or TCP. Specific recommendations regarding the choice of transport protocols are provided in Section 6. The above reference architecture however does not include other services such as message fragmentation and security. Depending upon the MIH service type (e.g., ES, CS and IS) the message size can be very large. In case where the underlying layers do not support fragmentation, this may be an issue. There are no security features currently defined as part of the MIH protocol level. However, security can be provided either at the transport or IP layer where it is necessary. Section 8 provides some guidelines and recommendations for security. 4.2. MIHF Identifiers (FQDN, NAI) An MIHFID is an identifier required to uniquely identify the MIHF end points for delivering the mobility services (MoS). Thus an MIHF identifier needs to be unique within a domain where mobility services are provided and invariant to interface IP addresses. An MIHFID MUST be represented either in the form of an FQDN [RFC2181] or NAI [RFC4282]. An MIHFID can be pre-configured or discovered through the discovery methods described in Section 5. 5. MoS Discovery The MoS discovery method depends on whether the MN attempts to discover an MoS in the home network, in the visited network, or in a Melia, et al. Expires August 15, 2008 [Page 11] Internet-Draft MSFD February 2008 3rd party remote network that is neither the home network nor the visited network. In case MoS is provided locally (scenarios S1 and S2) , the discovery techniques described in [I-D.bajko-mos-dhcp-options] and [I-D.bajko-mos-dns-discovery] are both applicable and either one MAY be used to discover the MoS. In case MoS is provided in the home network while the MN is in the visited network (scenario S3), the DNS based discovery described in [I-D.bajko-mos-dns-discovery] is applicable, while the DHCP based discovery method would require an interaction between the DHCP and the AAA infrastructure, similarly to what specified in [I-D.ietf-mip6-bootstrapping-integrated-dhc] . This latter case assumes that MoS assignment is performed during access authentication and authorization. In case MoS is provided in a remote network other than visited or home network (scenario S4), only the DNS based discovery method described in [I-D.bajko-mos-dns-discovery] is applicable. 5.1. MoS Discovery when MN and MoSh are in the home network (Scenario S1) To discover an MoS in the home network, the MN SHOULD use the DNS based MoS discovery method described in [I-D.bajko-mos-dns-discovery]. In order to use that mechanism, the MN MUST first find out the domain name of its home network. Home domains are usually pre-configured in the MNs, thus the MN can simply read its configuration data to find out the home domain name (scenario S1). The DNS query option is shown in Figure 6b. Alternatively, the MN MAY use the DHCP options for MoS discovery[I-D.bajko-mos-dhcp-options] as shown inFigure 6a. Melia, et al. Expires August 15, 2008 [Page 12] Internet-Draft MSFD February 2008 +-------+ +----+ |Domain | | MN |-------->|Name | +----+ |Server | +-------+ MN@xyz.com (a) using DNS Query +-----+ +------+ +----+ | | |DHCP | | MN |<----->| DHCP|<---->|Server| +----+ |Relay| | | +-----+ +------+ (b) Using DHCP Option Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option 5.2. MoS Discovery when MIN is in visited network and MoSv is also in visited network (Scenario S2) To discover an MoS in the visited network, the MN SHOULD attempt to use the DHCP options for MoS discovery [I-D.bajko-mos-dhcp-options] as shown in Figure 7a. If the DHCP method fails, the MN SHOULD attempt to use the DNS based MoS discovery method described in [[I-D.bajko-mos-dns-discovery] as shown in Figure 7b. In order to use that, the MN MUST first learn the domain name of the local network. There are a number of ways how the domain name of a network can be learned: DHCP -- In order to find out the domain name of the local network, the MN SHOULD use the dhcpv4 option 15 for learning the domain name [RFC1533]. A similar solution is available for dhcpv6 [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] . Reverse dns query -- When DHCP does not provide the required domain name, the MN MAY use reverse DNS (DNS PTR record) to find the domain name associated with the IP address it is using in the visited network. Note, that when a NAT device exists between the MN and the visited network, the MN will first need to find out the external IP address of the NAT device. Some possible methods for determining the NAT's external IP address are STUN [RFC3849] or UPnP [UPnP_IDG_DCP]. Once the MN has determined the external IP address of the NAT device, it MUST use that address in the reverse Melia, et al. Expires August 15, 2008 [Page 13] Internet-Draft MSFD February 2008 DNS query. +-----+ +------+ +----+ | | |DHCP | | MN |<----->| DHCP|<---->|Server| +----+ |Relay| | | +-----+ +------+ (a) MOS Discovery using DHCP options +-------+ +----+ |Domain | | MN |-------->|Name | +----+ |Server | +-------+ (b) Reverse DNS Query (starting from the IP address) Figure 7: Discovery (a) using DHCP option, (b) Using DNS It should be noted, that the usage of DHCP options to discover an MoS in this particular scenario is recommended because of its simplicity over the DNS based discovery method: the DNS discovery method requires the MN to learn the domain name of the local network first, possibly using DHCP, and then perform the DNS query. The usage of the DHCP based discovery method does not require any additional procedure. 5.3. MOS Discovery when the MN is in a visited Network and Services are at the Home network (Scenario S3) To discover an MoS in the visited network when MIH services are provided by the home network, both the DNS based discovery method described in [I-D.bajko-mos-dns-discovery] and the DHCP based discovery method described in [I-D.bajko-mos-dhcp-options] are applicable. To discover the MoS at home while in a visited network using DNS, the MN SHOULD use the procedures described in section Section 5.1 Alternatively, the MN MAY also use the DHCP based discovery method. Using the DHCP based discovery may be required in deployments where the usage of MoS located in the home network is enforced and included in the subscription profile. Similarly to Melia, et al. Expires August 15, 2008 [Page 14] Internet-Draft MSFD February 2008 [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated scenario the mobile node is required to perform network access authentication before it can bootstrap MoS information. This allows for MoS discovery at the time of access authentication and authorization. Also, the mechanism defined in this document requires the NAS to support MIH specific AAA attributes and a collocated DHCP relay agent. In order to provide the mobile node with information about the assigned MoS, the AAAh conveys the assigned MoS's information to the NAS via AAA protocol similarly to [I-D.ietf-dime-mip6-integrated] and described in [REF TO NEW DOC]. In these deployment scenarios the AAAh sends the MoS address at home to the AAAv during the network access authentication. The relation beween functional components supporting such procedure is shown in Figure 8. The mobile node executes the network access authentication procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. The NAS is in the visited and it interacts with the AAAh to authenticate the mobile node. In the process of authorizing the mobile node, the AAAh verifies in the AAA profile that the mobile node is allowed to use MoS services. The AAAh assigns the MoS in the home and returns this information to the NAS. The NAS may keep the received information for a configurable duration or it may keep the information for as long as the MN is connected to the NAS. The mobile node sends a DHCPv6 Information Request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message the mobile node (DHCP client) MUST include the Option Code for MoS Identifier Option [I-D.bajko-mos-dhcp-options] in the OPTION_ORO. The mobile node MUST also include the OPTION_CLIENTID to identify itself to the DHCP server. The Relay Agent intercepts the Information-request from the mobile node and forwards it to the DHCP server. The Relay Agent also includes the received MoS information from the AAAh in the IPv6 Relay Agent MoS Option [I-D.bajko-mos-dhcp-options]. If a NAS implementation does not store the received information as long as the MN's session remains in the visited, and if the MN delays sending DHCP request, the NAS/DHCP relay does not include the IPv6 Relay Agent MoS Option in the Relay Forward message. The DHCP server identifies the client by looking at the DUID for the client in the OPTION_CLIENTID. The DHCP server determines that the home agent is allocated by the AAAh by looking at the IPv6 Relay Agent Sub-Option in the IPv6 Relay Agent MoS Option. The DHCP server extracts the allocated home agent information from the IPv6 Relay Agent Sub-Option and includes it in the MoS Information Option Melia, et al. Expires August 15, 2008 [Page 15] Internet-Draft MSFD February 2008 [I-D.bajko-mos-dhcp-options] in the Reply Message. If the requested information is not available in the DHCP server, it follows the behavior described in [RFC3315]. The Relay Agent relays the Reply Message from the DHCP server to the mobile node. At this point, the mobile node has the MoS information that it requested. In should be noted, that using the DHCP Options and procedures defined in [I-D.bajko-mos-dhcp-options] the MN can not specify the network (local or home) where it wants the MoS address from. Whether the MN receives an MoS address from local or home network will depend on the actual network deployment (scenario S2 or S3). In an integrated scenario, where the network access authentication is performed by the home network the MoS information will anyway be sent to the AAAV, then stored in the relay agent and ultimately sent to the MN if the MN asks for it, using the procedures defined in [I-D.bajko-mos-dhcp-options]. Melia, et al. Expires August 15, 2008 [Page 16] Internet-Draft MSFD February 2008 Visited | Home | | +-------+ | +-------+ | | | | | |AAAV |-----------|--------|AAAH | | | | | | | | | | | +-------+ | +-------+ | | | | | | | | | | +--------+ | | | | | | | MoSh | +-----+ +------+ | +--------+ +----+ | | |DHCP | | | MN |------| NAS/|----|Server| | +----+ | DHCP| | | | |Relay| | | | +-----+ +------+ | | AAAv -- Visited AAA AAAH -- Home AAA NAS -- Network Access Server Figure 8: MOS Discovery using Network Access Authentication and DHCP options 5.4. MoS discovery when MIH services are in a 3rd party remote network (scenario S4) To discover an MoS in a remote network other than home network, the MN MUST use the DNS based MoS discovery method described in [I-D.bajko-mos-dns-discovery]. The MN MUST first learn the domain name of the network containing the MoS it is searching for. If the MN does not yet know the domain name of the network, learning it may require more than one operation, as pre-configuration and DHCP methods can not be used. The MN MAY attempt to first discover an MoS in either the local or home network (as in Figure 9 part (a)) and query that MoS to find out the domain name of a specific network or the domain name of a network at a specific location (as in Figure 9 part (b)). Alternatively, the MN MAY query an MoS previously known to learn the domain name of the desired network (e.g., via an IS Query). Finally the MN MUST use DNS queries to find MoS in the Melia, et al. Expires August 15, 2008 [Page 17] Internet-Draft MSFD February 2008 remote network as inFigure 9 part(c). It should be noted that step c can only be performed upon obtaining the domain name of the remote network. +-------+ +----+ |DHCP | | MN |-------->| | +----+ |Server | +-------+ MN@xyz.com (a) Discover MoS in local network with DHCP +------------+ +----+ | | | | |Information | | MN |-------->| Server | | | |(previously | +----+ |discovered) | +------------+ (b) Using IS query to find the FQDN on the remote network +-------+ +----+ |Domain | | MN |-------->|Name | +----+ |Server | +-------+ MN@xyz.com (c) using DNS Query in the remote network Figure 9: MOS Discovery using (a) DHCP Options, (b) IS Query to a known Server, (c) DNS Query 6. MIH Transport Options Once the Mobility Services have been discovered, MIH peers MAY exchange information over TCP, UDP or any other transport supported by both the server and client, as described in [I-D.rahman-mipshop-mih-transport]. The client MAY use the DNS discovery mechanism to discover which transport protocols are supported by the server in addition to TCP and UDP. While either protocol can provide the basic transport functionality required, there are performance trade-offs and unique characteristics associated with each that need to be considered in the context of the MIH services for different network loss and congestion conditions. The objectives of this section are to discuss these trade-offs for Melia, et al. Expires August 15, 2008 [Page 18] Internet-Draft MSFD February 2008 different MIH settings such as the MIH message size and rate, and the retransmission parameters. In addition, factors such as NAT traversal are also discussed. Given the reliability requirements for the MIH transport, it is assumed in this discussion that the MIH ACK mechanism is to be used in conjunction with UDP, while it is preferred to avoid using MIH ACKs with TCP since TCP includes acknowledgement and retransmission functionality 6.1. MIH Message size Although the MIH message size varies widely from about 30 bytes (for a broadcast capability discovery request) to around 65000 bytes (for an IS MIH_Get_Information response primitive), a typical MIH message size for the ES/CS service ranges between 50 to100 bytes [IEEE80221]. Thus, considering the effects of the MIH message size on the performance of the transport protocol brings us to discussing two main issues, related to fragmentation of long messages in the context of UDP and the concatenation of short messages in the context of TCP. Since transporting long MIH messages may require fragmentation that is not available in UDP, if MIH is using UDP a limit MUST be set on the size of the MIH message, unless fragmentation functionality is added to the MIH layer or IP layer fragmentation is used instead. In this latter case, the loss of an IP fragment leads to the retransmission of an entire MIH message, which in turn leads to poor end-to-end delay performance in addition to wasted bandwidth utilization. Additional recommendations in [I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the MIH message when using UDP and assuming IP layer fragmentation. In terms of dealing with short messages, TCP has the capability to concatenate very short messages in order to reduce the overall bandwidth overhead. However, this reduced overhead comes at the cost of additional delay to complete an MIH transaction, which may not be acceptable for CS and ES services. Note also that TCP is a stream oriented protocol and measures data flow in terms of bytes, not messages. Thus it is possible to split messages across multiple TCP segments if they are long enough. Even short messages can be split across two segments. This can also cause unacceptable delays, especially if the link quality is severely degraded as is likely to happen when the MN is exiting a wireless access coverage area. 6.2. MIH Message rate The frequency of MIH messages varies according to the MIH service type. It is expected that CS/ES message arrive at a rate of one in hundreds of milliseconds in order to capture quick changes in the environment and/ or process handover commands. On the other hand, IS messages are exchanged mainly every time a new network is visited which may be in order of hours or days. Therefore a burst of either Melia, et al. Expires August 15, 2008 [Page 19] Internet-Draft MSFD February 2008 short CS/ES messages or long IS message exchanges (in the case of multiple MIH nodes requesting information) may lead to network congestion. While the built-in rate-limiting controls available in TCP may be well suited for dealing with these congestion conditions, this may result in large transmission delays that may be unacceptable for the timely delivery of ES/CS messages. On the other hand, if UDP is used, a rate-limiting effect similar to the one obtained with TCP may be obtained by adequately adjusting the parameters of a token bucket regulator as defined in the MIH specifications [IEEE80221]. Recommendations for tocken bucket parameter settings are specific to the scenario considered. 6.3. Retransmission For TCP, the retransmission timeout is adjusted according to the measured RTT. However due to the exponential backoff mechanism, the delay associated with retransmission timeouts may increase significantly with increased packet loss. If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs. An MIH message is retransmitted if its corresponding MIH ACK is not received by the generating node within a timeout interval set by the MIHF. This approach does not include an exponential backoff and therefore tends to degrade more gracefully than TCP when the packet loss rate becomes large, in the sense that the expected delay does not increase exponentially. The number of retransmissions is limited, which reduces head-of-line blocking of other MIH messages, but this can cause important ES/CS messages to be lost. Additionally, instead of retransmitting an unacknowledged message, the MIH may choose to update the information and transmit a new message. 6.4. NAT Traversal There are no known issues for NAT traversal when using TCP. The default connection timeout of 24 hours is considered adequate for MIH transport purposes. However, issues with NAT traversal using UDP are documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication failures are experienced when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Hence, communication between the MN and the MoS SHOULD be able to gracefully handle such failures and implement mechanisms to re-establish their UDP sessions. In addition and in order to avoid such failures, MIH messages MAY be sent periodically, similarly to keep-alive messages, to attempt to refresh middlebox state (e.g. ES reports could be used for this purpose). As [RFC4787] requires a minimum state timeout of two Melia, et al. Expires August 15, 2008 [Page 20] Internet-Draft MSFD February 2008 minutes or more, MIH messages using UDP as transport SHOULD be sent once every two minutes. 6.5. General guidelines Since ES and CS messages are small in nature and have tight latency requirements, UDP in combination with MIH acknowledgement SHOULD be used for transporting ES and CS messages. On the other hand, IS messages are more resilient in terms of latency constraints and some long IS messages could exceed the MTU of the path to the destination. Therefore, TCP SHOULD be used for transporting IS messages. For both UDP and TCP cases, if a port number is not explicitly assigned (e.g. by the DNS SRV), MIH messages sent over UDP, TCP or other supported transport MUST use the default port number defined for that particular transport.. MOS server MUST support both UDP and TCP for MIH transport and the MN MUST support TCP. Additionally, the server and MN MAY support additional transport mechanisms. The MN MAY use the procedures defined in [I-D.bajko-mos-dns-discovery] to discover additional transport protocols supported by the server. 7. Operation Flows Figure 10 gives an example operation flow between MIHF peers when an MIH user requests for an IS service. Scenario 1 is in effect, i.e. the MoS and the MN are both in the MN's home network. Thus DHCP is used for MoS discovery and TCP is used for establishing a transport connection to carry the IS messages. When MOS is not pre-configured, the MIH user needs to discover the IP address of MOS to communicate with the remote MIHF. Therefore the MIH user sends a discovery request message to the local MIHF as defined in [IEEE80221] In this example, we assume that MoS discovery is performed before a transport connection is established with the remote MIHF, and the DHCP client process is invoked via some internal APIs. DHCP Client sends DHCP INFORM message according to standard DHCP and with the MoS option as defined in [I-D.bajko-mos-dhcp-options]. DHCP server replies via DHCP ACK message with the IP address of the MoS. The MOS address is then passed to the MIHF locally via some internal APIs. MIHF generates the discovery response message and passes it on to the corresponding MIH user. The MIH user generates an IS query addressed to the remote MoS. MIHF invokes the underlying TCP client which establishes a transport connection with the remote peer. Once the transport connection is established, MIHF sends the IS query via MIH protocol REQUEST message. The message and query arrive at the destination MIHF and MIH user respectively. The MoS MIH user Melia, et al. Expires August 15, 2008 [Page 21] Internet-Draft MSFD February 2008 responds to the corresponding IS query and the MoS MIHF sends the IS response via MIH protocol RESPONSE message. The message arrives to the source MIHF which passes the IS response on to the corresponding MIH user. MN MoS |====================================| |======| |===================| + ---------+ + ---------+ | MIH USER | +------+ +------+ +------+ +------+ | MIH USER | | +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ | | | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | | +----------+ +------+ +------+ +------+ +------+ +----------+ | | | | | | |MIH Discovery | | | | | |Request | | | | | |(MIH User-> MIHF)| | | | | |======> | | | | | | | | | | | |Invoke DHCP Client | | | | |(Internal process with MoS)|DHCP INFORM| | | |==========================>|==========>| | | | | | | | | | | | | | | | | | DHCP ACK | | | | | |<==========| | | | Inform MoS address | | | | |<==========================| | | | | (internal process) | | | | | | | | | |Discovery | | | | | |Response | | | | | |<====== | | | | | |(MIH User<- MIHF)| | | | | | | | | | | |IS Query | | | | | |=======> | | | | | |(MIH User-> MIHF)| | | | | | | | | | | |Invoke TCP Client| | | | | |================>| | | | | |(Internal process| | | | | |with MOS) | | | | | | | | | | | | | TCP connection established | | | |<==============================>| | | | | | | | | | | | | | | | | | | | Melia, et al. Expires August 15, 2008 [Page 22] Internet-Draft MSFD February 2008 | IS QUERY REQUEST (via MIH protocol) | |============================================================>| | | | | | | | | | | | | | | | | | | | | | | | IS QUERY| | | | | | REQUEST| | | | | |=========>| | | | | (MIHF-> MIH User)| | | | | | | | | | | | QUERY| | | | | | RESPONSE| | | | | | <======| | | | | |(MIHF <-MIH User) | | | | | | | | | IS QUERY RESPONSE (via MIH protoco | |<============================================================| | | | | | | | IS | | | | | |RESPONSE | | | | | |<======== | | | | | |(MIH User <-MIHF)| | | | | | | | | | | Figure 10: Example Flow of Operation Involving MIH User 8. Security Considerations There are a number of security issues that need to be taken into account during node discovery and information exchange via a transport connection [I-D.ietf-mipshop-mis-ps] In case where DHCP is used for node discovery and authentication of the source and content of DHCP messages are required, it is recommended that network administrators should use DHCP authentication option described in [RFC3118], where available or rely upon link layer security. This will also protect the denial of service attacks to DHCP server.[RFC3118] provides mechanisms for both entity authentication and message authentication. In case where DNS is used for discovering MoS, fake DNS requests and responses may cause DoS and the inability of the MN to perform a proper handover, respectively. Where networks are exposed to such DoS, it is recommended that DNS service providers use the Domain Name System Security Extensions (DNSSEC) as described in [RFC4033]. Readers may also refer to [RFC4641] to consider the aspects of DNSSEC Operational Practices. Melia, et al. Expires August 15, 2008 [Page 23] Internet-Draft MSFD February 2008 In case where reliable transport protocol such as TCP is used for transport connection between two MIHF peers, TLS [RFC4346] should be used for message confidentiality and data integrity. In particular, TLS is designed for client/server applications and to prevent eavesdropping, tampering, or message forgery. Readers should also follow the recommendations in [RFC4366] that provides generic extension mechanisms for the TLS protocol suitable for wireless environments. In case where unreliable transport protocol such as UDP is used for transport connection between two MIHF peers, DTLS [RFC4347] should be used for message confidentiality and data integrity. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Alternatively, generic IP layer security, such as IPSec [RFC2401] may be used where neither transport layer security for a specific > transport is available nor server only authentication is required. 9. IANA Considerations This document registers the following TCP and UDP port(s) with IANA: Keyword Decimal Description ------- ------- ----------- ieee-mih-IS XXX/tcp Media Independent Handover Information Services ieee-mih-IS XXX/udp Media Independent Handover Information Services ieee-mih-ES XXX/tcp Media Independent Handover Event Services ieee-mih-ES XXX/udp Media Independent Handover Event Services ieee-mih-CS XXX/tcp Media Independent Handover Command Services ieee-mih-CS XXX/udp Media Independent Handover Command Services 10. Acknowledgements The authors would like to thank Patrick Stupar for his valuable comments and fruitful discussions. 11. References 11.1. Normative References [I-D.bajko-mos-dhcp-options] Bajko, G., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Mobility Servers (MoS)", draft-bajko-mos-dhcp-options-00 (work in progress), Melia, et al. Expires August 15, 2008 [Page 24] Internet-Draft MSFD February 2008 August 2007. [I-D.bajko-mos-dns-discovery] Bajko, G., "Locating Mobility Servers", draft-bajko-mos-dns-discovery-00 (work in progress), August 2007. [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] Yan, R., "Domain Suffix Option for DHCPv6", draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress), June 2007. [I-D.ietf-dime-mip6-integrated] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", draft-ietf-dime-mip6-integrated-07 (work in progress), November 2007. [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), July 2007. [I-D.ietf-mip6-hiopt] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Option for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-10 (work in progress), January 2008. [I-D.ietf-mipshop-mis-ps] Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y., Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services Transport: Problem Statement", draft-ietf-mipshop-mis-ps-05 (work in progress), November 2007. [I-D.ietf-tsvwg-udp-guidelines] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work in progress), February 2008. [IEEE80221] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Servicesinnn", IEEE LAN/MAN Draft IEEE P802.21/D07.00, July 2007. [RFC1533] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Melia, et al. Expires August 15, 2008 [Page 25] Internet-Draft MSFD February 2008 Extensions", RFC 1533, October 1993. [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. Melia, et al. Expires August 15, 2008 [Page 26] Internet-Draft MSFD February 2008 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. 11.2. Informative References [I-D.rahman-mipshop-mih-transport] Rahman, A., "Transport of Media Independent Handover Messages Over IP", draft-rahman-mipshop-mih-transport-03 (work in progress), July 2007. Authors' Addresses Telemaco Melia (editor) CISCO Email: tmelia@cisco.com Gabor Bajko Nokia Email: Gabor.Bajko@nokia.com Subir Das Telcordia Email: subir@research.telcordia.com Nada Golmie NIST Email: nada.golmie@nist.gov Sam Xia Huawei Email: xiazhongqi@huawei.com Melia, et al. Expires August 15, 2008 [Page 27] Internet-Draft MSFD February 2008 Juan Carlos Zuniga InterDigital Email: j.c.zuniga@ieee.org Melia, et al. Expires August 15, 2008 [Page 28] Internet-Draft MSFD February 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). Melia, et al. Expires August 15, 2008 [Page 29]