Mipshop WG T. Melia, Ed.
Internet-Draft Alcatel-Lucent
Intended status: Standards Track G. Bajko
Expires: August 1, 2009 Nokia
S. Das
Telcordia Technologies Inc.
N. Golmie
NIST
JC. Zuniga
InterDigital Communications, LLC
January 28, 2009
IEEE 802.21 Mobility Services Framework Design (MSFD)
draft-ietf-mipshop-mstp-solution-12
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 1, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Melia, et al. Expires August 1, 2009 [Page 1]
Internet-Draft MSFD January 2009
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This document describes a mobility services framework design (MSFD)
for the IEEE 802.21 Media Independent Handover (MIH) protocol that
addresses identified issues associated with the transport of MIH
messages. The document also describes mechanisms for mobility
service (MoS) discovery and transport layer mechanisms for the
reliable delivery of MIH messages. This document does not provide
mechanisms for securing the communication between a mobile node (MN)
and the mobility service (MoS). Instead, it is assumed that either
lower layer (e.g., link layer) security mechanisms, or overall
system-specific proprietary security solutions, are used.
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].
Melia, et al. Expires August 1, 2009 [Page 2]
Internet-Draft MSFD January 2009
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 . . . . . . . . . . . . . 8
3.3. Scenario S3: Third party MoS . . . . . . . . . . . . . . . 8
3.4. Scenario S4: Roaming MoS . . . . . . . . . . . . . . . . . 9
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 12
5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. MoS Discovery when MN and MoSh are in the home network
(Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 13
5.2. MoS Discovery when MN and MoSv both are in visited
network (Scenario S2) . . . . . . . . . . . . . . . . . . 14
5.3. MoS Discovery when MIH services are in a 3rd party
remote network (Scenario S3) . . . . . . . . . . . . . . . 14
5.4. MoS Discovery when the MN is in a visited Network and
Services are at the Home network . . . . . . . . . . . . . 15
6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 15
6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 16
6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 17
6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 17
6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18
6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 18
7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Security Considerations for MoS Discovery . . . . . . . . 21
8.2. Security Considerations for MIH Transport . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Melia, et al. Expires August 1, 2009 [Page 3]
Internet-Draft MSFD January 2009
1. Introduction
This document proposes a solution to the issues identified in the
problem statement document [RFC5164] for the layer 3 transport of
IEEE 802.21 MIH protocols.
The MIH Layer 3 transport problem is divided into 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 describes
the solution architecture, including the MSFD reference model and
MIHF identifiers. MoS discovery procedures explain how the MN
discovers MoS in its home network, in a visited network or in a third
party network. The remainder of this document describes the MIH
transport architecture, example message flows for several signaling
scenarios, and security issues.
This document does not provide mechanisms for securing the
communication between a mobile node and the mobility service.
Instead, it is assumed that either lower layer (e.g., link layer)
security mechanisms, or overall system-specific proprietary security
solutions, are used. The details of such lower layer and/or
proprietary mechanisms are beyond the scope of this document. It is
RECOMMENDED against using this protocol without careful analysis that
these mechanisms meet the desired requirements, and encourages future
standardization work in this area. The IEEE 802.21a Task Group has
recently started work on MIH security issues that may provide some
solution in this area. For further information, please refer to
Section 8.
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 and MIH protocol messages.
Melia, et al. Expires August 1, 2009 [Page 4]
Internet-Draft MSFD January 2009
MIHF Media Independent Handover Function: a switching 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 [IEEE80221].
MIHF User An entity 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.
MoS Mobility Services: those services, as defined in the MIH problem
statement document [RFC5164] , which includes 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.
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.
MSTP Mobility Services Transport Protocol: a protocol that is used
to deliver MIH protocol 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 of the protocol stack and sends information to the local or
remote upper or lower layers of the protocol stack. The purpose
of IS is to exchange information elements (IEs) relating to
various neighboring network information.
ES Event Service: a MoS that originates at a remote MIHF or the lower
layers of the local protocol stack 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
various lower layer events.
Melia, et al. Expires August 1, 2009 [Page 5]
Internet-Draft MSFD January 2009
CS Command Service: MoS that sends commands from the remote MIHF or
local upper layers to the remote or local lower layers of the
protocol stack to switch links or to get link status.
FQDN: Fully-Qualified Domain Name: a complete domain name for a host
on the Internet, showing (in reverse order) the full delegation
path from the DNS root and top level domain down to the host name
(e.g. myexample.example.org).
NAI Network Access Identifier: the user ID that a user submits
during network access authentication [RFC4282]. For mobile users,
the NAI identifies the user and helps to route the authentication
request message.
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 routable
(outside the NAT domain) network addresses and port numbers.
DHCP Dynamic Host Configuration Protocol: protocols described in
[RFC2131] and [RFC3315] that allow Internet devices to obtain
respectively IPv4 and IPv6 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.
Home AAA AAAh: an AAA server located on the MN's home network.
Visited AAA AAAv: an AAA server located in 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.
Melia, et al. Expires August 1, 2009 [Page 6]
Internet-Draft MSFD January 2009
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 User Datagram Protocol: a connectionless transport layer
protocol used to send datagrams between a source and a destination
at a given port, defined in RFC 768.
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: an 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 should be resent.
MTU Maximum Transmission Unit: the largest size of an IP packet that
can be sent on a network segment without requiring fragmentation
[RFC1191].
PMTU Path MTU: the largest size of an IP packet that can be sent on
an end-to-end network path without requiring IP fragmentation.
TLS Transport Layer Security Protocol: an application layer protocol
that primarily assures privacy and data integrity between two
communicating network entities [RFC5246].
SMSS Sender Maximum Segment Size: size of the largest segment that
the sender can transmit as per [RFC2581].
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
MoS discovery as well as the performance of the MIH signaling
service. This document addresses the scenarios listed in [RFC5164]
and specifies transport options to carry the MIH protocol over IP.
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 network the MN uses to connect
to the home network, or it can be located elsewhere.
Melia, et al. Expires August 1, 2009 [Page 7]
Internet-Draft MSFD January 2009
+--------------+ +====+
| 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.
+--------------+
| HOME NETWORK |
+--------------+
/\
||
\/
+====+ +-----------------+
|MoSv| | VISITED NETWORK |
+====+ +-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 2: MoSv in the visited network
3.3. Scenario S3: 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 3. (Note that MoS can
exist both in home and in visited networks).
Melia, et al. Expires August 1, 2009 [Page 8]
Internet-Draft MSFD January 2009
+--------------+
| HOME NETWORK |
+====+ +--------------+ +--------------+
|MoS3| | THIRD PARTY | <===> /\
+====+ +--------------+ ||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 3: MoS from a third party
3.4. Scenario S4: 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 4.
+====+ +--------------+
|MoSh| | HOME NETWORK |
+====+ +--------------+
/\
||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 4: MoS provided by the home while in visited
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 services
should be co-located. However, while IS tends to involve a large
amount of static information, ES and CS are dynamic services and some
relationships between them can be expected, e.g., a handover command
Melia, et al. Expires August 1, 2009 [Page 9]
Internet-Draft MSFD January 2009
(CS) could be issued upon reception of a link event (ES). This
document does not make any assumption on the location of the MoS
(although there might be some preferred configurations), and aims at
flexible MSFD to discover different services in different locations
to optimize handover performance. MoS 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 primarily 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.
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 at any time thereafter.
The MN may know the realm of the MoS to be discovered. The MN may
also be pre-configured with the address of the MoS to be used. In
case the MN does not know what realm/MoS to query, dynamic assignment
methods are described in Section 5.
The discovery of the MoS (and the related configuration at MIHF
level) is required to bind two MIHF peers (e.g. MN and MoS) with
their respective IP addresses. Discovery MUST be executed in the
following conditions:
o Bootstrapping: upon successful layer 2 network attachment the MN
MAY be required to use DHCP for address configuration. These
procedures can carry the required information for MoS
configuration in specific DHCP options.
o If the MN does not receive MoS information during network
attachment and the MN does not have a pre-configured MoS, it MUST
run a discovery procedure upon initial IP address configuration.
Melia, et al. Expires August 1, 2009 [Page 10]
Internet-Draft MSFD January 2009
o If the MN changes its IP address (e.g. upon handover) it MUST
refresh MIHF peer bindings (i.e., MIHF registration process). In
case the MoS used is not suitable anymore (e.g. too large RTT
experienced) the MN MAY need to perform a new discovery procedure.
o If the MN is a multi-homed device and it communicates with the
same MoS via different IP addresses it MAY run discovery
procedures if one of the IP addresses changes.
Once the MIHF peer has been discovered, MIH information can be
exchanged between MIH peers over a transport protocol such as UDP or
TCP. The usage of transport protocols is described in Section 6 and
packing of the MIH messages does not require extra framing since the
MIH protocol defined in [IEEE80221] already contains a length field.
4.1. Architecture
Figure 5 depicts the MSFD 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
operations such as generating query and response, 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 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
discovery functions.
Melia, et al. Expires August 1, 2009 [Page 11]
Internet-Draft MSFD January 2009
+--------------------------+
| MIHF User |
+--------------------------+
||
+--------------------------+
| MIHF |
+--------------------------+
|| || ||
|| +------+ +-----+
|| | DHCP | | DNS |
|| +------+ +-----+
|| || ||
+--------------------------+
| TCP/UDP |
+--------------------------+
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 as described in Section 5. Once the peer MIHF is discovered, the
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.
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
guidelines and recommendations for security.
4.2. MIHF Identifiers (FQDN, NAI)
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 independent of the configured IP addresse(s). 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
3rd party remote network that is neither the home network nor the
Melia, et al. Expires August 1, 2009 [Page 12]
Internet-Draft MSFD January 2009
visited network. In the case the MN has already a MoS address pre-
configured it is not necessary to run the discovery procedure. If
the MN does not have pre-configured MoS the following procedure
applies.
In the case where MoS is provided locally (scenarios S1 and S2) , the
discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options]
and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable as
described in Section 5.1 and Section 5.2.
In the case where MoS is provided in the home network while the MN is
in the visited network (scenario S4), the DNS based discovery
described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable.
In the case where MoS is provided by a third party network which is
different from the current visited network (scenario S3), only the
DNS based discovery method described in
[I-D.ietf-mipshop-mos-dns-discovery] is applicable.
It should be noted that authorization of a MN to use a specific MoS
server is neither in scope of this document nor is currently
specified in IEEE80221. We further assume all devices can access
discovered MoS. In case future deployments will implement
authorization policies the mobile nodes should fall back to other
learned MoS if authorization is denied.
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.ietf-mipshop-mos-dns-discovery]. In order to use that
mechanism, the MN MUST have its home domain pre-configured (i.e.,
subscription is tied to a network). The DNS query option is shown in
Figure 6a. Alternatively, the MN MAY use the DHCP options for MoS
discovery [I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 6b
(in some deployments, a DHCP relay may not be present).
Melia, et al. Expires August 1, 2009 [Page 13]
Internet-Draft MSFD January 2009
(a) +-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
(b)
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 6: MOS Discovery (a) using DNS query, (b) using DHCP option
5.2. MoS Discovery when MN and MoSv both are 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.ietf-mipshop-mos-dhcp-options] as shown in Figure 7.
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 7: MoS Discovery using DHCP options
5.3. MoS Discovery when MIH services are in a 3rd party remote network
(Scenario S3)
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.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the
domain name of the network containing the MoS it is searching for.
The MN can query its current 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 8a, IEEE 802.21 defines information elements
such as OPERATOR ID and SERVICE PROVIDER ID which can be a domain
name. An IS query can provide this information, see [IEEE80221]).
Alternatively, the MN MAY query a MoS previously known to learn the
domain name of the desired network . Finally, the MN MUST use DNS
based discovery mechanisms to find MoS in the remote network as in
Figure 8b. It should be noted that step b can only be performed upon
obtaining the domain name of the remote network.
Melia, et al. Expires August 1, 2009 [Page 14]
Internet-Draft MSFD January 2009
(a)
+------------+
+----+ | |
| | |Information |
| MN |-------->| Server |
| | |(previously |
+----+ |discovered) |
+------------+
(b)
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
Figure 8: MOS Discovery using (a) IS Query to a known IS Server, (b)
DNS Query
5.4. MoS Discovery when the MN is in a visited Network and Services are
at the Home network
To discover an MoS in the visited network when MIH services are
provided by the home network, the DNS based discovery method
described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable. To
discover the MoS at home while in a visited network using DNS, the MN
SHOULD use the procedures described in Section 5.1.
6. MIH Transport Options
Once the Mobility Services have been discovered, MIH peers run a
capability discovery and subscription procedure as specified in
[IEEE80221]. MIH peers MAY exchange information over TCP, UDP or any
other transport supported by both the server and the client. The
client MAY use the DNS discovery mechanism to discover which
transport protocols are supported by the server in addition to TCP
and UDP that are recommended in this document. 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 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 MUST NOT be
Melia, et al. Expires August 1, 2009 [Page 15]
Internet-Draft MSFD January 2009
used 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 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 to 100 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 based on the path MTU to destination (or
the Minimum MTU where PMTU is not implemented). The Minimum MTU
depends on the IP version used for transmission, and is the lesser of
the first hop MTU, and 576 or 1280 bytes for IPv4 [RFC1122] or for
IPv6 [RFC2460], respectively, although applications may reduce these
values to guard against the presence of tunnels.
According to[IEEE80221] when MIH message is sent using an L3 or
higher layer transport, L3 takes care of any fragmentation issue and
the MIH protocol does not handle fragmentation in such cases. Thus,
MIH layer fragmentation MUST NOT be used together with IP layer
framentation and MUST not be used when MIH packets are carried over
TCP.
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. Additional recommendations in
[RFC5405] 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. The use of the TCP_NODELAY
option can alleviate this problem by triggering transmission of a
segment less than the SMSS. (It should be noted that [RFC4960]
Melia, et al. Expires August 1, 2009 [Page 16]
Internet-Draft MSFD January 2009
addresses both of these problems, but discussion of SCTP is omitted
here, as it is generally not used for the mobility services discussed
in this document.).
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 where
multiple MIH nodes request 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
SHOULD be obtained by adequately adjusting the parameters of a token
bucket regulator as defined in the MIH specifications [IEEE80221].
Recommendations for token bucket parameter settings are as follow:
o If the MIHF knows the RTT (e.g., based on the request/response MIH
protocol exchange between two MIH peers), the rate can be based
upon this as specified in [IEEE80221].
o If not, then on average it SHOULD NOT send more than one UDP
message every 3 seconds.
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 MUST 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. The maximum number of retransmissions is configurable and the
value of the retransmission timer is computed according to the
algorithm defined in [RFC2988]. The default maximum number of
retransmissions is set to 2 and the initial retransmission timer
(TMO) is set to 3s when RTT is not known. The maximum TMO is set to
30s.
Melia, et al. Expires August 1, 2009 [Page 17]
Internet-Draft MSFD January 2009
6.4. NAT Traversal
There are no known issues for NAT traversal when using TCP. The
default connection timeout of 2 hours 4 minutes [RFC5382] (assuming a
2 hours TCP keep-alive) is considered adequate for MIH transport
purposes. However, issues with NAT traversal using UDP are
documented in [RFC5405]. 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, in an attempt to refresh middlebox state. 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. Re-registration or Event indication messages as defined in
[IEEE80221] MAY be used for this purpose.
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.
TCP SHOULD be used to transport 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 in
Section 9 for that particular transport.
A 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.ietf-mipshop-mos-dns-discovery] to discover
additional transport protocols supported by the server (e.g. SCTP).
7. Operation Flows
Figure 9 gives an example operation flow between MIHF peers when a
MIH user requests an IS service and both the MN and the MoS are in
the MN's home network. 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.
Melia, et al. Expires August 1, 2009 [Page 18]
Internet-Draft MSFD January 2009
Therefore the MIH user sends a discovery request message to the local
MIHF as defined in [IEEE80221].
In this example (one could draw similar mechanisms with DHCPv6), 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. The DHCP Client sends a DHCP INFORM
message according to standard DHCP and with the MoS option as defined
in [I-D.ietf-mipshop-mos-dhcp-options]. The DHCP server replies via
a DHCP ACK message with the IP address of the MoS. The MoS address
is then passed to the MIHF locally via some internal APIs. The 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. The MIHF invokes the underlying TCP client which
establishes a transport connection with the remote peer. Once the
transport connection is established, the MIHF sends the IS query via
a MIH protocol REQUEST message. The message and query arrive at the
destination MIHF and MIH user respectively. The MoS MIH user
responds to the corresponding IS query and the MoS MIHF sends the IS
response via a MIH protocol RESPONSE message. The message arrives at
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 | | | | |
| | | | | |
|Invoke DHCP Client | | | |
|(Internal process with MoS)|DHCP INFORM| | |
|==========================>|==========>| | |
| | | | | |
| | | DHCP ACK | | |
| | |<==========| | |
| Inform MoS address | | | |
|<==========================| | | |
| (internal process) | | | |
| | | | | |
MIH Discovery | | | | |
Response | | | | |
| | | | | |
IS Query | | | | |
Melia, et al. Expires August 1, 2009 [Page 19]
Internet-Draft MSFD January 2009
MIH User-> MIHF | | | | |
| | | | | |
|Invoke TCP Client| | | | |
|================>| | | | |
Internal process | | | | |
| | TCP connection established | |
| |<=============================>| |
| | | | | |
| IS QUERY REQUEST (via MIH protocol) |
|===========================================================>|
| | | | | |
| | | | | IS QUERY|
| | | | | REQUEST|
| | | | MIHF-> MIH User |
| | | | | |
| | | | | QUERY|
| | | | | RESPONSE|
| | | | MIHF <-MIH User |
| | | | | |
| | IS QUERY RESPONSE (via MIH protocol) |
|<===========================================================|
| | | | | |
IS RESPONSE | | | | |
MIH User <-MIHF | | | | |
| | | | | |
Figure 9: Example Flow of Operation Involving MIH User
8. Security Considerations
There are two components to the security considerations: MoS
Discovery and MIH Transport. For MoS Discovery, DHCP and DNS
recommendations are hereby provided per IETF guidelines. For MIH
Transport, we describe the security threats and expect that the
system deployment will have means to mitigate such threats when
sensitive information is being exchanged between the mobile node and
MoS. Since IEEE 802.21 base specification does not provide MIH
protocol level security, it is assumed that either lower layer
security (e.g., link layer), or overall system specific (e.g.
proprietary) security solutions are available. The present document
does not provide any guidelines in this regard. It is should be
stressed that the IEEE 802.21a Task Group has recently started work
on MIH security issues that may provide some solution in this area.
Finally authorization of a MN to use a specific MoS, as stated in
Section 5, is neither in scope of this document nor is currently
specified in [IEEE80221].
Melia, et al. Expires August 1, 2009 [Page 20]
Internet-Draft MSFD January 2009
8.1. Security Considerations for MoS Discovery
There are a number of security issues that need to be taken into
account during node discovery. In the case where DHCP is used for
node discovery and authentication of the source and content of DHCP
messages is required, network administrators SHOULD use the DHCP
authentication option described in [RFC3118], where available, or
rely upon link layer security. [RFC3118] provides mechanisms for
both entity authentication and message authentication. In case where
the DHCP authentication mechanism is not available administrators may
need to rely upon the underlying link layer security. In such cases
the link between DHCP client and layer-2 termination point may be
protected but the DHCP message source and its messages can not be
authenticated or the integrity of the latter checked unless there
exits a security binding between link layer and DHCP layer.
In the 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.
8.2. Security Considerations for MIH Transport
The communication between an MN and an MoS is exposed to a number of
security threads:
o MoS Identity spoofing. A fake MoS could provide the MNs with
bogus data and force them to select the wrong network or to make a
wrong handover decision.
o Tampering. Tampering with the information provided by an MoS may
result in the MN making wrong network selection or handover
decisions
o Replay attack. Since MoSs as defined in [IEEE80221] support a
'PUSH model', they can send bulk of data to the MNs whenever the
MoSs think that the data is relevant for the MN. An attacker may
intercept the data sent my the MoSs to the MNs and replay it at a
later time, causing the MNs to make network selection or handover
decisions which are not valid at that point in time.
o Eavesdropping. By snooping the communication between an MN and an
MoS, an attacker may be able to trace a user's movement between
networks or cells, or predict future movements, by inspecting
handover service messages.
Melia, et al. Expires August 1, 2009 [Page 21]
Internet-Draft MSFD January 2009
There are many deployment specific system security solutions
available and can be used to countermeasure the above mentioned
threats. For example, for the MoSh and MoSv scenarios (including
roaming scenarios), link layer security may be sufficient to protect
the communication between MN and MoS. This is a typical mobile
operator environment where link layer security provides
authentication, data confidentiality and integrity. In other
scenarios, such as the third party MoS, link layer security solutions
may not be sufficient to protect the communication path between the
MN and the MoS. The communication channel between MN and MoS needs
to be secured by other means.
The present document does not provide any specific guidelines about
the way these security solutions should be deployed. However, if in
future the IEEE 802.21 Working Group amends the specification with
MIH protocol level security or recommends the deployment scenarios,
IETF may revisit the security considerations and recommend specific
transport layer security as appropriate.
9. IANA Considerations
This document registers the following TCP and UDP port(s) with IANA:
Keyword Decimal Description
-------- --------------- ------------
ieee-mih TBD_BY_IANA/tcp MIH Services
ieee-mih TBD_BY_IANA/udp MIH Services
10. Acknowledgements
The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin
Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their
valuable comments, reviews and fruitful discussions.
11. References
11.1. Normative References
[I-D.ietf-mipshop-mos-dhcp-options]
Bajko, G. and S. Das, "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility
Server (MoS) discovery",
draft-ietf-mipshop-mos-dhcp-options-10 (work in progress),
January 2009.
Melia, et al. Expires August 1, 2009 [Page 22]
Internet-Draft MSFD January 2009
[I-D.ietf-mipshop-mos-dns-discovery]
Bajko, G., "Locating IEEE 802.21 Mobility Servers using
DNS", draft-ietf-mipshop-mos-dns-discovery-04 (work in
progress), October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[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.
[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.
11.2. Informative References
[IEEE80221]
"Draft IEEE Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services", IEEE LAN/
MAN Draft IEEE P802.21/D13.00, August 2008.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Melia, et al. Expires August 1, 2009 [Page 23]
Internet-Draft MSFD January 2009
Control", RFC 2581, April 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5164] Melia, T., "Mobility Services Transport: Problem
Statement", RFC 5164, March 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
Authors' Addresses
Telemaco Melia (editor)
Alcatel-Lucent
Route de Villejust
Nozay 91620
France
Email: telemaco.melia@alcatel-lucent.com
Melia, et al. Expires August 1, 2009 [Page 24]
Internet-Draft MSFD January 2009
Gabor Bajko
Nokia
Email: Gabor.Bajko@nokia.com
Subir Das
Telcordia Technologies Inc.
Email: subir@research.telcordia.com
Nada Golmie
NIST
Email: nada.golmie@nist.gov
Juan Carlos Zuniga
InterDigital Communications, LLC
Email: j.c.zuniga@ieee.org
Melia, et al. Expires August 1, 2009 [Page 25]