Mipshop WG T. Melia, Ed. Internet-Draft NEC Intended status: Standards Track G. Bajko Expires: March 21, 2008 Nokia S. Das Telcordia N. Golmie NIST S. Xia Huawei JC. Zuniga InterDigital September 18, 2007 Mobility Services Transport Protocol Design draft-melia-mipshop-mstp-solution-00 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 March 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Melia, et al. Expires March 21, 2008 [Page 1] Internet-Draft MSTP September 2007 Abstract To be edited. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 7 5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. MoS Discovery in the home network while attached to the home link . . . . . . . . . . . . . . . . . . . . . . 8 5.2. MoS Discovery in the local network and Services are local . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. MOS Discovery in a roaming Network and Services are at Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. MoS discovery in a remote network . . . . . . . . . . . . 11 6. MIH Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 13 6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 13 6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 14 6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14 6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 14 7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Melia, et al. Expires March 21, 2008 [Page 2] Internet-Draft MSTP September 2007 1. Introduction This document proposes a solution to the issues identified in the problem statement document [I-D.ietf-mipshop-mis-ps] for the transport of IEEE 802.21 MIH protocols. The MIH Layer 3 transport problem is divided in two main parts: the discovery of mobility services (MoS) and the transport of the information between MN and MoS. The discovery process is required for MIH function located in the MN to discover the peer MIHF (e.g. the IP address) of the MoS in the network (e.g. the Point of Service, PoS) either during attachment or during handover. Upon successful discovery, the MIH peers can then exchange information in the form of MIH messages. This document considers firstly standard track IETF-based solutions for the design and recommendations of the discovery and transport protocol components. 2. Terminology The following terminology is being used: MIH Media Independent Handover MIHF Media Independent Handover Function MIHF USER MIH client initiating and terminating MIH signalling MIHFID Media Independent Handover Function Identifier MoS As defined in the problem statement document it includes IS, CS, ES services defined by the IEEE 802.21 standard. MoSh Mobility Services assigned in the Home Network MoSv Mobility Services assigned in the Visited Network MoS3 Mobility Services assigned in a 3rd Party Network MN Mobile Node NN Network Node Melia, et al. Expires March 21, 2008 [Page 3] Internet-Draft MSTP September 2007 3. Deployment Scenarios The following scenarios have been identified: S1 Home Network MoS, the MN and the services are located in the home network. We refer to this as MoSh as in Figure 1. +--------------+ +====+ | HOME NETWORK | |MoSh| +--------------+ +====+ /\ || \/ +--------+ | MN | +--------+ Figure 1: MoS in the Home network S2 Visited Network MoS, MN is in the visited network and mobility services are also provided by the visited network. We refer to this as MoSv ans in Figure 2. +--------------+ | HOME NETWORK | +--------------+ /\ || \/ +====+ +-----------------+ |MoSv| | VISITED NETWORK | +====+ +-----------------+ /\ || \/ +--------+ | MN | +--------+ Figure 2: MoSV in the Visited Network S3 Roaming MoS, MN is in the visited network and all services are provided by the home network. Melia, et al. Expires March 21, 2008 [Page 4] Internet-Draft MSTP September 2007 +====+ +--------------+ |MoSh| | HOME NETWORK | +====+ +--------------+ /\ || \/ +-----------------+ | VISITED NETWORK | +-----------------+ /\ || \/ +--------+ | MN | +--------+ Figure 3: MoS provided by the home while in visited S4 Third party MoS, MN is in home or visited network and services are provided by a 3rd party network. We refer to this as MoS3 as in Figure 4 +--------------+ | HOME NETWORK | +====+ +--------------+ +--------------+ |MoS3| | THIRD PARTY | <===> /\ +====+ +--------------+ || \/ +-----------------+ | VISITED NETWORK | +-----------------+ /\ || \/ +--------+ | MN | +--------+ Figure 4: MoS form a third party MoS can be provided independently and there is no strict relationship between ES, CS and IS. However, while IS contain more a static sort of information, ES and CS are services of a dynamic nature and sometimes some relationships between them could be expected, e.g. a handover command could be issued upon reception of a link event. Hence, while in theory services can be implemented in different locations, it is expected that ES and CS will be collocated, whereas IS can either be collocated with ES/CS or not. Therefore, having the Melia, et al. Expires March 21, 2008 [Page 5] Internet-Draft MSTP September 2007 flexibility at the MSTP to discover different services in different locations is an important feature 4. Solution Overview As mentioned in Section 1 the solution space is being divided in discovery and transport. The following assumptions have been made: o The solution is aimed at supporting 802.21 MIH services, namely Information Services (IS), Event Services (ES), and Command Services (CS). o If the MIHFID is available, FQDN or NAI's realm is used for mobility service discovery. The recommendation to the IEEE 802.21 WG is to restrict to only these two. o The solutions are chosen to cover all possible deployment scenarios as described in Section 3. o MIHF discovery can be performed during initial network attachment or thereafter. For the discovering the location of an MoS, the MN could either be pre-configured with the address of the MoS, or this address could be dynamically assigned through DHCP or DNS by the network. 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 peers over UDP and TCP. The usage of these protocols is described in Section 6. 4.1. Architecture The following Figure 5 depicts the MSTP reference model and its components within a node. Melia, et al. Expires March 21, 2008 [Page 6] Internet-Draft MSTP September 2007 +--------------------------+ | MIHF USER | +--------------------------+ || +--------------------------+ | MIHF | +--------------------------+ || || || +---------+ +------+ +-----+ | TCP/UDP | | DHCP | | DNS | +---------+ +------+ +-----+ Figure 5: MN stack As it can be seen, the MIHF relies on the services provided by TCP and UDP for transport, as well as DHCP and DNS for peer discovery. In cases where peer MIHF IP address is not pre-configured, source MIHF needs to discover it either via DHCP or DNS or using a combination of both as described in Section 5. Once peer MIHF is discovered, MIHF must exchange messages with its peer over either UDP or TCP. Specific recommendations on choice of transport protocols are provided in Section 6. The above reference architecture however does not provide the model for other services such as, fragmentation and security. Depending upon the MIH services (e.g., ES, CS and IS) the message size can be very large. In cases where underlying layer does not support fragmentation, this may be an issue. There is no security available currently at 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 whereby 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 [RFC2486]. An MIHFID can be pre-configured or discovered through the discovery methods as described in Section 5. 5. MoS Discovery The MoS discovery method depends on whether the MN wants to discover an MoS in the local network, home network or a remote network other than home network. Melia, et al. Expires March 21, 2008 [Page 7] Internet-Draft MSTP September 2007 In case MoS is provided locally (scenarios S1 and S2) [I-D.bajko-mos-dhcp-options] and [I-D.bajko-mos-dns-discovery] could be used to transfer MoS information from the network to the MN (via DHCP or DNS). In case MoS is provided in the home while the MN is attached in visited (scenario S3) an interaction between the DHCP and AAA infrastructure is required similarly to what specified in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. It is assumed therefore that MoS assignment is performed during access authentication and authorization. In case MoS is provided in a remote network other than visited or home (scenario S4) only DNS based methods apply. 5.1. MoS Discovery in the home network while attached to the home link 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, 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). Alternatively, the MN MAY use the DHCP options for MoS discovery[I-D.bajko-mos-dhcp-options]. Figure 6 provides such model. Melia, et al. Expires March 21, 2008 [Page 8] Internet-Draft MSTP September 2007 +-------+ +----+ |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 in the local network and Services are local 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]. 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]. 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]. 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 local network. Note, that when a NAT device exists between the MN and the local 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 determined the external IP address of the NAT device, it MUST use that address in the reverse DNS query. Melia, et al. Expires March 21, 2008 [Page 9] Internet-Draft MSTP September 2007 Figure 7 provides such model. +-----+ +------+ +----+ | | |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 5.3. MOS Discovery in a roaming Network and Services are at Home To discover an MoS in the roaming network when services are provided by the home network MN SHOULD use the DHCP option along with network access authentication. Upon network access authentication and interaction with the NAS the AAAh verifies in the AAA profile that the MN is allowed to use the MoS in home. The AAAh assigns the MoS in the home and sends back the information to the NAS. MN sends a DHCP information request as per [RFC3315] containing Home Network Identifier Option indicating the need to allocate the MoS in the home. The relay agent intercepts the Information request from the MN and it forwards to the DHCP server inserting the MIH Relay Agent Option containing the info received by the AAAh. The DHCP server can then reply to the MN by sending the Home Network Information Option. The MN receives the MoS address. It should be noted that the AAAh does not know what are the preferences of the MN, i.e. whether the MoS should be allocated in the home or in visited. The MoS info is stored at the relay agent and forwarded to the MN according to the flags in the Home Network Identifier Option. Figure 8 describes such a model. Melia, et al. Expires March 21, 2008 [Page 10] Internet-Draft MSTP September 2007 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 in a remote network 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]. In order to use that, the MN MUST first learn the domain name of the network it is looking for an MoS in. 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 can use DNS queries to find MoS in the remote network as inFigure 9 part(c). It should Melia, et al. Expires March 21, 2008 [Page 11] Internet-Draft MSTP September 2007 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) DNS Query, (b) IS Query to a known Server 6. MIH Transport Once the Mobility Services have been discovered, MIH peers MUST exchange information over either TCP or UDP. While either protocol can provide the basic transport functionality required, there are performance trade-offs and unique characteristics with each that need to be considered in the context of the MIH services for different network loss and congestion conditions. Thus, the objectives of this section are to discuss these trade-offs for 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 Melia, et al. Expires March 21, 2008 [Page 12] Internet-Draft MSTP September 2007 with TCP since TCP includes a similar 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. 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, 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. 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 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 token bucket parameters defined in the MIH specifications. Recommendations for parameter settings are specific to the scenario considered. Melia, et al. Expires March 21, 2008 [Page 13] Internet-Draft MSTP September 2007 6.3. Retransmission For TCP, the retransmission timeout is adjusted according to the measured RTT. However due to the exponential backoff mechanism, the retransmission timeouts may increase significantly with increased packet loss. 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 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 or TCP MUST use the default port number. 7. Operation Flows Following Figure 10 gives an example operation flow between MIHF peers when an MIH user requests for an IS service. Scenario 1 is chosen whereby DHCP is used for MoS discovery and TCP is used for establishing a transport connection. When MOS is not pre-configured, MIH user needs to discover the IP address of MOS to communicate with the remote MIHF. Therefore MIH user requests the local MIHF via a discovery message as defined in IEEE 802.21. Melia, et al. Expires March 21, 2008 [Page 14] Internet-Draft MSTP September 2007 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 defines 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. MIH user then generates an IS query addressed to the remote MoS. MIHF invokes the underlying TCP client which then establishes a transport connection with the remote peer. Once transport connection is available, MIHF sends the IS query via MIH protocol REQUEST message. The message arrives to the destination MIHF and MIH user respectively. MIH user responds to the corresponding IS query and the remote MIHF sends the IS response via MIH protocol RESPONSE message. Thus it arrives to the source MIHF which passes it on to the corresponding MIH user. MN MoS |======================================| |======| |======================| +------+ +-----+ +------+ +------+ +------+ +------+ +----+ +----+ | MIH | |MIHF | | TCP | |DHCP | |DHCP | | TCP | |MIHF| |MIH | | User | | | |Client| |Client| |Server| |Server| | | |User| +------+ +-----+ +------+ +------+ +------+ +------+ +----+ +----+ | | | | | | | | |Discovery| | | | | | | | Request |Invoke DHCP Client |DHCP INFORM | | | | |========>|===================>|===========>| | | | | | (internal process)| with MOS | | | | | | | | option | | | | | | | | | | | | | | | | DHCP ACK | | | | | | | |<===========| | | | | | Inform MoS address | | | | | | |<===================| | | | | | | (internal process) | | | | | |Discovery| | | | | | | |response | | | | | | | |<========| | | | | | | | | | | | | | | |IS Query | | | | | | | |========>| | | | | | | | | | | | | | | | |Invoke TCP| | | | | | | |=========>| | | | | | | | client | TCP connection established | | | | | |<===============================>| | | | | | | | | | | Melia, et al. Expires March 21, 2008 [Page 15] Internet-Draft MSTP September 2007 | | | | | | | | | | | | | | | | | | | IS QUERY REQUEST (via MIH protocol) | | | |====================================================>| | | | | | | | |IS | | | | | | | |QUERY | | | | | | | |REQUEST| | | | | | | |======>| | | | | | | | | | | | | | | |QUERY | | | | | | | |RESPONSE | | | | | | |<======| | | | | | | | | | | | IS QUERY RESPONSE (via MIH protocol) | | | |<====================================================| | | | | | | | | | | IS | | | | | | | |RESPONSE | | | | | | | |<========| | | | | | | | | | | | | | | | | | | | | | | 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]. 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 [I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects of DNSSEC Operational Practices. In case where reliable transport protocol such as TCP is used for Melia, et al. Expires March 21, 2008 [Page 16] Internet-Draft MSTP September 2007 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 instead of a specific transport layer secuity for a specific transport. 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), August 2007. Melia, et al. Expires March 21, 2008 [Page 17] Internet-Draft MSTP September 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-dnsop-dnssec-operational-practices] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices", draft-ietf-dnsop-dnssec-operational-practices-08 (work in progress), March 2006. [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-mipshop-mis-ps] Melia, T., "Mobility Services Transport: Problem Statement", draft-ietf-mipshop-mis-ps-03 (work in progress), August 2007. [I-D.ietf-tsvwg-udp-guidelines] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", draft-ietf-tsvwg-udp-guidelines-03 (work in progress), September 2007. [RFC1533] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 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 Melia, et al. Expires March 21, 2008 [Page 18] Internet-Draft MSTP September 2007 Internet Protocol", RFC 2401, November 1998. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [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. [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. [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 Authors' Addresses Telemaco Melia (editor) NEC Email: telemaco.melia@nw.neclab.eu Melia, et al. Expires March 21, 2008 [Page 19] Internet-Draft MSTP September 2007 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 Juan Carlos Zuniga InterDigital Email: j.c.zuniga@ieee.org Melia, et al. Expires March 21, 2008 [Page 20] Internet-Draft MSTP September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 March 21, 2008 [Page 21]