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]