RE: [MIPSHOP-MIH-DT] PS doc -- 01 version
"Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com> Fri, 27 April 2007 17:29 UTC
Return-path: <mipshop-mih-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUGa-0006W3-BN; Fri, 27 Apr 2007 13:29:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUGY-0006Vx-U0 for mipshop-mih-dt@ietf.org; Fri, 27 Apr 2007 13:29:54 -0400
Received: from idcexmail.interdigital.com ([12.32.197.135] helo=sahara.InterDigital.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUGR-0000eg-LC for mipshop-mih-dt@ietf.org; Fri, 27 Apr 2007 13:29:54 -0400
Received: from interdigital.com ([10.0.128.11]) by sahara.InterDigital.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:29:09 -0400
Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:29:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version
Date: Fri, 27 Apr 2007 13:29:06 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C72798C@SAM.InterDigital.com>
In-reply-to: <01f801c788e1$246f1fb0$0100c80a@comm.ad.roke.co.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MIPSHOP-MIH-DT] PS doc -- 01 version
Thread-Index: AceIm55F8ap0xNr0Tv+mYy9gEZmo4wAMeSNgAATk47AAA2ewUA==
From: "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com>
To: Robert Hancock <robert.hancock@roke.co.uk>, Sam Xia <xiazhongqi@huawei.com>, Telemaco Melia <telemaco.melia@netlab.nec.de>
X-OriginalArrivalTime: 27 Apr 2007 17:29:08.0012 (UTC) FILETIME=[8F8B5EC0:01C788F1]
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 1e977eeb463e2e97d47b6bab2baa20d6
Cc: mipshop-mih-dt@ietf.org
X-BeenThere: mipshop-mih-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <mipshop-mih-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/mipshop-mih-dt>
List-Post: <mailto:mipshop-mih-dt@ietf.org>
List-Help: <mailto:mipshop-mih-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0895792181=="
Errors-To: mipshop-mih-dt-bounces@ietf.org
Hello,
Thanks for the good work Tele.
The only question that I have is if we could relax the security
requirements from "must" to "could or may".
In 802.21 there are talks about carrying out some security tasks in the
future, so I think that is best if we do not reinforce it here, in case
that the function is carried out elsewhere (i.e. in the MIH itself).
This is how it reads now:
In 5.2:
The security mechanism must provide mutual authentication of MN
and NN
and it may provide one way authentication of either of MN and NN.
In 6:
Information Services may not require authorization of the client, but
both event and command services must authenticate message sources,
particularly if they are mobile.
Anyone else from 21 would like to comment on this?
Besides that, it looks fine to me.
Regards,
Jc
________________________________
From: Robert Hancock [mailto:robert.hancock@roke.co.uk]
Sent: April 27, 2007 11:32 AM
To: 'Sam Xia'; 'Telemaco Melia'
Cc: mipshop-mih-dt@ietf.org
Subject: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version
tele,
we have some minor comments. i can't formalise them right now but will
try to send something over the weekend.
r.
________________________________
From: Sam Xia [mailto:xiazhongqi@huawei.com]
Sent: 27 April 2007 14:19
To: 'Telemaco Melia'
Cc: mipshop-mih-dt@ietf.org
Subject: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version
hi, tele,
i have 3 comments as follows:
1: there is typos error in the paragraph about discovery
requirement. "dscovery" is duplicated.
2: i think that the list of requirements is not arranged in
order. for example, we should put transportation requirements togeter,
security requirements together, discovery requriement togethter, just as
.21 does.
3:
Secure delivery: The Mobility Service information must be
delivered
securely (integrity and confidentiality) between trusted
peers,
where the transport may pass though untrusted intermediate
nodes
and networks.
i think how to deliver the mobility service information is
determined by the MIH user. the MSTP must provide security mechanism to
protect service information. but this does not mean that the mobility
service information must be delivered securely.
Best Regards, Sam Xia
________________________________
From: Telemaco Melia
[mailto:telemaco.melia@netlab.nec.de]
Sent: Friday, April 27, 2007 3:13 PM
To: mipshop-mih-dt@ietf.org
Subject: Re: [MIPSHOP-MIH-DT] PS doc -- 01 version
Hi folks,
Sorry to insist but we need to push this forward.
Can we get consensus soon (today?) about the introduced
changes, especially section 5.2?
telemaco
Telemaco Melia wrote:
Hi all,
Please find attached a revised version of the PS
document. Comments from people should be hopefully reflected.
I told Stefano that a final version for submission will
be ready by Friday, so please send comments with proposed text to avoid
lengthly discussions.
Please pay particular attention to section 5.2 (see
Yoshi's email). Also the title of the doc is changed according to
Alper's comment (it is in line with the terminology agreed in Prague).
cheers,
telemaco
________________________________
MIPSHOP
T. Melia
Internet-Draft
NEC
Intended status: Informational
E. Hepworth
Expires: October 27, 2007 Siemens
Roke Manor Research
S. Sreemanthula
Nokia
Research Center
Y. Ohba
Toshiba
G. Vivek
Intel
J. Korhonen
TeliaSonera
R. Aguiar
IT
Sam(Zhongqi). Xia
HUAWEI
April 25, 2007
Mobility Services Transport: Problem
Statement
draft-ietf-mipshop-mis-ps-01
Status of this Memo
By submitting this Internet-Draft, each author
represents that any
applicable patent or other IPR claims of which he or
she is aware
have been or will be disclosed, and any of which he
or she becomes
aware will be disclosed, in accordance with Section 6
of BCP 79.
Internet-Drafts are working documents of the Internet
Engineering
Task Force (IETF), its areas, and its working groups.
Note that
other groups may also distribute working documents as
Internet-
Drafts.
Internet-Drafts are draft documents valid for a
maximum of six months
and may be updated, replaced, or obsoleted by other
documents at any
time. It is inappropriate to use Internet-Drafts as
reference
material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed
at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 27, 2007.
Copyright Notice
Melia, et al. Expires October 27, 2007
[Page 1]
Internet-Draft Mobility Services Transport
April 2007
Copyright (C) The IETF Trust (2007).
Abstract
There are on-going activities in the networking
community to develop
solutions that aid in IP handover mechanisms between
heterogeneous
wired and wireless access systems including, but not
limited to, IEEE
802.21. Intelligent access selection, taking into
account link layer
attributes, requires the delivery of a variety of
different
information types to the terminal from different
sources within the
network and vice-versa. The protocol requirements
for this
signalling have both transport and security issues
that must be
considered. The signalling must not be constrained
to specific link
types, so there is at least a common component to the
signalling
problem which is within the scope of the IETF. This
draft presents a
problem statement for this core problem.
Melia, et al. Expires October 27, 2007
[Page 2]
Internet-Draft Mobility Services Transport
April 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . .
. . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . .
. . . . . . . 4
3. Definition of Mobility Services . . . . . . . .
. . . . . . . 5
4. Deployment Scenarios for MoS . . . . . . . . . .
. . . . . . . 5
4.1. End-to-End Signalling and Transport over IP
. . . . . . . 6
4.2. End-to-End Signalling and Partial Transport
over IP . . . 6
4.3. End-to-End Signalling with a Proxy . . . . .
. . . . . . . 7
4.4. End-to-End Network-to-Network Signalling . .
. . . . . . . 7
5. MoS Transport Protocol Splitting . . . . . . . .
. . . . . . . 8
5.1. Payload Formats and Extensibility
Considerations . . . . . 9
5.2. Requirements on the Mobility Service
Transport Layer . . . 9
6. Security Considerations . . . . . . . . . . . .
. . . . . . . 14
7. Conclusions . . . . . . . . . . . . . . . . . .
. . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . .
. . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . .
. . . . . . . 16
Intellectual Property and Copyright Statements . . .
. . . . . . . 18
Melia, et al. Expires October 27, 2007
[Page 3]
Internet-Draft Mobility Services Transport
April 2007
1. Introduction
This Internet Draft provides a problem statement for
the exchange of
information to support handover in heterogeneous link
environments.
This mobility support service allows more
sophisticated handover
operations by making available information about
network
characteristics, neighboring networks and associated
characteristics,
indications that a handover should take place, and
suggestions for
suitable target networks to which to handover. The
mobility support
services work complementarily with IP mobility
mechanisms to enhance
the overall performance and usability perception.
There are two key attributes to the handover support
service problem
for inter-technology handovers:
1. The Information: the information elements being
exchanged. The
messages could be of different nature, such as
Information,
Command or Event, potentially being defined
following a common
structure.
2. The Underlying Transport: the transport mechanism
to support
exchange of the information elements mentioned
above. This
transport mechanism includes information
transport, discovery of
peers, and the securing of this information over
the network.
This draft has been motivated by on-going work within
IEEE 802.21
[1], but the following description intentionally
describes the
problem from a more general perspective. This
document represents
the views of the authors, and does not represent the
official view of
IEEE 802.21.
The structure of this document is as follows.
Section 3 defines
mobility services. Section 4 provides a simple model
for the
protocol entities involved in the signalling and
their possible
relationships. Section 5 describes a decomposition
of the signalling
problem into service specific parts and a generic
transport part.
Section 5.2 describes more detailed requirements for
the transport
component. Section 6 provides security
considerations, and Section 7
summarizes the conclusions and open issues.
2. Terminology
The following abbreviations are used in the document:
o MIH: media independent handover
Melia, et al. Expires October 27, 2007
[Page 4]
Internet-Draft Mobility Services Transport
April 2007
o MN: mobile node
o NN: network node, intended to represent some
device in the network
(the location of the node e.g. in the access
network, home network
is not specified, and for the moment it is assumed
that they can
reside anywhere).
o EP: endpoint, intended to represent the
terminating endpoints of
the transport protocol used to support the
signalling exchanges
between nodes.
3. Definition of Mobility Services
As mentioned in the introduction mobility (handover)
support in
heterogeneous wireless environments requires
functional components
located either in the mobile terminal or in the
(access) network to
exchange information and eventually to take decisions
upon this
information exchange. For instance traditional
host-based handover
solutions could be complemented with more
sophisticated network-
centric solutions reducing terminal complexity.
Also, neighborhood
discovery, potentially a complex operation in
heterogeneous wireless
scenarios, can result in a more simple step if
implemented with an
unified interface towards the access network.
In this document the different supporting functions
for media
independent handover (MIH) management are generally
referred as
Mobility Services (MoS) having in common different
requirements for
the transport protocol. These requirements and
associated
functionalities are the focus of this document
4. Deployment Scenarios for MoS
The deployment scenarios are outlined in the
following sections.
Note: while MN-to-MN signalling exchanges are
theoretically possible,
these are not currently being considered.
The following scenarios are discussed for
understanding the overall
problem of transporting MIH protocol. Although these
are all
possible scenarios and MIH services can be delivered
through link-
layer specific solutions and/or through a "layer 3 or
above"
protocol, this problem statement focuses on the
delivery of
information for MIH services for the latter case
only.
Melia, et al. Expires October 27, 2007
[Page 5]
Internet-Draft Mobility Services Transport
April 2007
4.1. End-to-End Signalling and Transport over IP
In this case, the end-to-end signalling used to
exchange the handover
information elements (the Information Exchange) runs
end-to-end
between MN and NN. The underlying transport is also
end-to-end
+------+
+------+
| MN | | NN
|
| (EP) | | (EP)
|
+------+
+------+
Information Exchange
<------------------------------------>
/------------------------------------\
< Transport over IP >
\------------------------------------/
Figure 1: End-to-end Signalling and
Transport
4.2. End-to-End Signalling and Partial Transport over
IP
As before, the Information Exchange runs end-to-end
between the MN
and the second NN. However, in this scenario, some
other transport
means than IP is used from the MN to the first NN,
and the transport
over IP is used only between NNs. This is analogous
to the use of
EAP end-to-end between Supplicant and Authentication
Server, with an
upper-layer multihop protocol such as RADIUS used as
a backhaul
transport protocol between an Access Point and the
Authentication
Server.
+------+ +------+
+------+
| MN | | NN | | NN
|
| | | (EP) | | (EP)
|
+------+ +------+
+------+
Information Exchange
<------------------------------------>
(Transport over /------------------\
<--------------->< Transport over IP >
e.g. L2) \------------------/
Figure 2: Partial Transport
Melia, et al. Expires October 27, 2007
[Page 6]
Internet-Draft Mobility Services Transport
April 2007
4.3. End-to-End Signalling with a Proxy
In the final case, a number of proxies are inserted
along the path
between the two transport endpoints. The use of
proxies is possible
in both cases 1 and 2 above, but distinguished here
as there are a
number of options as to how the proxy may behave with
regard to the
transport and end-to-end signalling exchange.
In this case, the proxy performs some processing on
the Information
Exchange before forwarding the information on. This
can be viewed as
concatenating signalling exchanges between a number
of EPs.
+------+ +---------+
+------+
| MN | | ProxyNN | | NN
|
| (EP) | | (EP) | | (EP)
|
+------+ +---------+
+------+
Information Exchange
------------------>
------------------->
<-------------------
<------------------
/---------------\ /----------------\
< Transport > < Transport >
\---------------/ \----------------/
Figure 3: Information Exchange
Approach
The Proxy NN might process all layers of the protocol
suite in the
same way as an ordinary EP.
There is a possibility for realizing other proxy
scenarios.
4.4. End-to-End Network-to-Network Signalling
In this case NN to NN signalling is envisioned. Such
model should
allow different network components to gather
information from each
other. This is useful for instance in conditions
where network
components need to take decisions and instruct mobile
terminals of
operation to be executed.
Melia, et al. Expires October 27, 2007
[Page 7]
Internet-Draft Mobility Services Transport
April 2007
+------+ +------+
| NN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
------------------->
<-------------------
/----------------\
< Transport >
\----------------/
Figure 4: Information Exchange between
different NN
Network nodes exchange information about connected
terminals status.
5. MoS Transport Protocol Splitting
Figure 5 shows a model where the Information
Exchanges are
implemented by a signalling protocol specific to a
particular
mobility service, and these are relayed over a
generic transport
layer (the Mobility Service Transport Layer).
+----------------+ ^
|Mobility Support| |
| Service 2 | |
+----------------+ | | |
Mobility Service
|Mobility Support| +----------------+ |
Signaling
| Service 1 | +----------------+ |
Layer
| | |Mobility Support| |
+----------------+ | Service 3 | |
| | |
+----------------+ V
================================================
+---------------------------------------+ ^
Mobility Service
| Mobility Service Transport Protocol | |
Transport
+---------------------------------------+ V
Layer
================================================
+---------------------------------------+
| IP |
+---------------------------------------+
Figure 5: Handover Services over IP
The Mobility Service Transport Layer provides certain
functionality
(outlined in Section 5.2) to the higher layer
mobility support
Melia, et al. Expires October 27, 2007
[Page 8]
Internet-Draft Mobility Services Transport
April 2007
services in order to support the exchange of
information between
communicating mobility service functions. The
transport layer
effectively provides a container capability to
mobility support
services, as well as any required transport and
security operations
required to provide communication without regard to
the protocol
semantics and data carried in the specific mobility
services.
The Mobility Support Services themselves may also
define certain
protocol exchanges to support the exchange of service
specific
Information Elements. It is likely that the
responsibility for
defining the contents and significance of the
Information Elements is
the responsibility of other standards bodies other
than the IETF.
Example mobility services include the Information
Services, Event and
Command services.
5.1. Payload Formats and Extensibility Considerations
The format of the Mobility Service Transport Protocol
is as follows:
+----------------+----------------------------------------+
|Mobility Service| Opaque Payload
|
|Transport Header| (Mobility Support Service)
|
+----------------+----------------------------------------+
Figure 6: Protocol Structure
The opaque payload encompasses the Mobility Support
Service
information that is to be transported. The
definition of the
Mobility Service Transport Header is something that
is best addressed
within the IETF. MSTP does not inspect the payload
and any required
information will be provided by the MSTP users.
5.2. Requirements on the Mobility Service Transport
Layer
The following section outlines some of the general
transport
requirements that should be supported by the Mobility
Service
Transport Protocol. Analysis has suggested that at
least the
following need to be taken into account:
Discovery: Discovery: MNs need the ability to either
discover nodes
that support certain services, or discover
services provided by a
certain node. The service discovery can be dealt
with messages as
defined in [1]. This section refers to
node-discovery in either
scenario. There are no assumptions about the
location of these
mobility services within the network, therefore
the discovery
mechanism needs to operate across administrative
boundaries.
Issues such as speed of discovery, protection
against spoofing,
when discovery needs to take place, and the length
of time over
Melia, et al. Expires October 27, 2007
[Page 9]
Internet-Draft Mobility Services Transport
April 2007
which the discovery information may remain valid
all need to be
considered. Approaches include:
* Hard coding information into the MN, indicating
either the IP
address of the NN, or information about the NN
that can be
resolved onto an IP address. The configuration
information
could be managed dynamically, but assumes that
the NN is
independent of the access network to which the
MN is currently
attached.
* Pushing information to the MN, where the
information is
delivered to the MN as part of other
configuration operations,
for example, in a Router Discovery exchange.
The benefit of
this approach is that no additional exchanges
with the network
would be required, but the limitations
associated with
modifying these protocols may limit
applicability of the
solution.
* MN dynamically requesting information about a
node, which may
require both MN and NN support for a particular
service
discovery mechanism. This may require
additional support by
the access network (e.g. multicast or anycast)
even when it may
not be supporting the service directly itself.
Numerous directory and configuration services
already exist, and
reuse of these mechanisms may be appropriate.
There is an open
question about whether multiple methods of
discovery would be
needed, and whether NNs would also need to
discover other NNs.
The definition of a service also needs to be
determined, including
the granularity of the description (for example,
should the MN
look for an "IS" service, or "IS-local
information", and "IS-home
network information" services.
Information from a trusted source: The MN uses the
Mobility Service
information to make decisions about what steps to
take next. It
is essential that there is some way to ensure that
the information
received is from a trustworthy source. This
requirement should
reuse trust relationships that have already been
established in
the network, for example, on the relationships
established by the
AAA infrastructure after a mutual authentication,
or on the
certificate infrastructure required to support
SEND [9]. The
security mechanism must provide mutual
authentication of MN and NN
and it may provide one way authentication of
either of MN and NN.
Security association management: A common security
association
negotiation method, independent of any specific
MSTP user, must be
implemented. The solution must also work in case
on MN mobility.
Melia, et al. Expires October 27, 2007
[Page 10]
Internet-Draft Mobility Services Transport
April 2007
Low latency: Some of the Mobility Services generate
time sensitive
information. Therefore, there is a need to
deliver the
information over quite short timescales, and the
required lifetime
of a connection might be quite short lived. For
reliable
delivery, short-lived connections could be set up
as and when
needed, although there is a connection setup
latency associated
with this approach. Alternatively, a long-lived
connection could
be used, but this requires advanced warning of
being needed and
some way to maintain the state associated with the
connection. It
also assumes that the relationships between
devices supporting the
mobility service are fairly stable. Another
alternative is
connectionless operation, but this has
interactions with other
requirements such as reliable delivery.
Reliability: Reliable delivery for some of the
mobility services may
be essential, but it is difficult to trade this
off against the
low latency requirement. It is also quite
difficult to design a
robust, high performance mechanism that can
operate in
heterogeneous environments, especially one where
the link
characteristics can vary quite dramatically.
There are two main
approaches that could be adopted:
1. Assume the transport cannot be guaranteed to
support reliable
delivery. In this case, the Mobility Support
Service itself
will have to provide some sort of reliability
mechanism to
allow communicating endpoints to acknowledge
receipt of
information.
2. Assume the underlying transport will deal with
most error
situations, and provide a very basic
acknowledgement mechanism
that (if no acknowledgement is received) will
indicate that
something more serious has occurred than a
packet drop (since
these other types of error conditions are
dealt with at the
transport layer).
Congestion Control: A Mobility Service may
optionally wish to
transfer large amounts of data, placing a
requirement for
congestion control in the transport. There is an
interaction
between this requirement and that of the
requirement for low
latency since ways to deal with timely delivery of
smaller
asynchronous messages around the larger datagrams
is required
(mitigation of head of line blocking etc.).
Secure delivery: The Mobility Service information
must be delivered
securely (integrity and confidentiality) between
trusted peers,
where the transport may pass though untrusted
intermediate nodes
and networks. The Mobility Service information
must also be
protected against replay attacks and denial of
service attacks.
Melia, et al. Expires October 27, 2007
[Page 11]
Internet-Draft Mobility Services Transport
April 2007
Multiplexing: The transport service needs to be able
to support
different mobility services. This may require
multiplexing and
the ability to manage multiple discovery
operations and peering
relationships in parallel.
Multihoming: For some information services exchanged
with the MN,
there is a possibility that the request and
response messages can
be carried over two different links e.g. a
handover command
request is on the current link while the response
could be
delivered on the new link. Depending on the IP
mobility
mechanism, there is some impact on the transport
option for the
mobility information services. This may
potentially have some
associated latency and security issues, for
example, if the
transport is over IP there is some transparency
but Mobile IP may
introduce additional delay and both TCP and UDP
must use the
permanent address of the MN.
IPv4 and IPv6 support: The MSTP must support both
IPv4 and IPv6
including NAT traversal for IPv4 networks and
firewall pass-
through for IPv4 and IPv6 networks.
In addition to the above, it may be necessary for the
transport to
support multiple applications (or modes of operation)
to support the
particular requirements of the Information Exchange
being carried out
between nodes. This may require the ability to
multiplex multiple
information exchanges into a single transport
exchange (see figure
Figure 7) .
Melia, et al. Expires October 27, 2007
[Page 12]
Internet-Draft Mobility Services Transport
April 2007
+==================================+
| |
| +------------+ +-----------+ |
| | MIH | | MIH | |
| | User 1 | | User 2 |... |
| | e.g. MIP | | e.g. SIP | |
| ++++++++++++++ +++++++++++++ | _
..............
| \ / | \__ : MIH
:
| \ / | _/
:Multiplexing:
| +++++++++++++++++++++ |
:............:
| | MIH Function | |
| | (e.g. MIS) | |
| +++++++++++++++++++++ |
| /\ |
| || |
..............
| || | :
Transport :
| \/ |
:Multiplexing:
| +++++++++++++++++++++ |
:............: +---------+
| | Transport | |
____/\____ | MIH |
| | (e.g. TCP, UDP) | | /
\ |.........|
| +++++++++++++++++++++ |
|Transport|
| /\ |
|.........|
| || |
_____| IP |
| || |
/ +=========+
| || |
/
| \/ | ^+++++++++^
/ +---------+
| +++++++++++++++++++++ | / \ /
| MIH |
| | IP |--------|--< Internet >
----- |.........|
| +++++++++++++++++++++ | \ / |
\ |Transport|
| | v+++++++++v |
\ |.........|
| | |
\__| IP |
+==================================+ |
+=========+
|
:
|
:
|
+---------+
|
| MIH |
|
|.........|
|
|Transport|
|
|.........|
|________| IP |
+=========+
Figure 7: Multiplexing examples
Melia, et al. Expires October 27, 2007
[Page 13]
Internet-Draft Mobility Services Transport
April 2007
6. Security Considerations
Network supported mobility services aim at improving
decision making
and management of dynamically connected hosts. The
control and
maintenance of mobile nodes becomes challenging where
authentication
and authorization credentials used to access a
network are
unavailable for the purpose of bootstrapping a
security association
for handover services.
Information Services may not require authorization of
the client, but
both event and command services must authenticate
message sources,
particularly if they are mobile. Network side
service entities will
typically need to provide proof of authority to serve
visiting
devices. Where signalling or radio operations can
result from
received messages, significant disruption may result
from processing
bogus or modified messages. The effect of processing
bogus messages
depends largely upon the content of the message
payload, which is
handled by the handover services application.
Regardless of the
variation in effect, message delivery mechanisms need
to provide
protection against tampering, and spoofing.
Sensitive and identifying information about a mobile
device may be
exchanged during handover service message exchange.
Since handover
decisions are to be made based upon message
exchanges, it may be
possible to trace an user's movement between cells,
or predict future
movements, by inspecting handover service messages.
In order to
prevent such tracking, message confidentiality should
be available.
This is particularly important since many mobile
devices are
associated with only one user, as divulgence of such
information may
violate the user's privacy. Additionally,
identifying information
may be exchanged during security association
construction. As this
information may be used to trace users across cell
boundaries,
identity protection should be available if possible,
when
establishing SAs.
In addition, the user should not have to disclose its
identity to the
network (any more than it needed to during
authentication) in order
to access the Mobility Support Services. For
example, if the local
network is just aware that an anonymous user with a
subscription to
operatorXYX.com is accessing the network, the user
should not have to
divulge their true identity in order to access the
Mobility Support
Services available locally.
Finally, the network nodes themselves will
potentially be subject to
denial of service attacks from MNs and these problems
will be
exacerbated if operation of the mobility service
protocols imposes a
heavy computational load on the NNs. The overall
design has to
consider at what stage (e.g. discovery, transport
layer
Melia, et al. Expires October 27, 2007
[Page 14]
Internet-Draft Mobility Services Transport
April 2007
establishment, service specific protocol exchange)
denial of service
prevention or mitigation should be built in.
7. Conclusions
This Internet draft outlined a broad problem
statement for the
signalling of information elements across a network
to support media
independent handover services. In order to enable
this type of
signalling service, a need for a generic transport
solution with
certain transport and security properties were
outlined. Whilst the
motivation for considering this problem has come from
work within
IEEE 802.21, a desirable goal is to ensure that
solutions to this
problem are applicable to a wider range of mobility
services.
It would be valuable to establish realistic
performance goals for the
solution to this common problem (i.e. transport and
security aspects)
using experience from previous IETF work in this area
and knowledge
about feasible deployment scenarios. This
information could then be
used as an input to other standards bodies in
assisting them to
design mobility services with feasible performance
requirements.
Much of the functionality required for this problem
is available from
existing IETF protocols or combination thereof. This
document takes
no position on whether an existing protocol can be
adapted for the
solution or whether new protocol development is
required. In either
case, we believe that the appropriate skills for
development of
protocols in this area lie in the IETF.
8. References
[1] "Draft IEEE Standard for Local and Metropolitan
Area Networks:
Media Independent Handover Services", IEEE
LAN/MAN Draft IEEE
P802.21/D05.00, April 2007.
[2] Aboba, B., "Architectural Implications of Link
Indications",
draft-iab-link-indications-10 (work in
progress), March 2007.
[3] Perkins, C., "IP Mobility Support for IPv4", RFC
3344,
August 2002.
[4] Johnson, D., Perkins, C., and J. Arkko,
"Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Moskowitz, R. and P. Nikander, "Host Identity
Protocol (HIP)
Architecture", RFC 4423, May 2006.
Melia, et al. Expires October 27, 2007
[Page 15]
Internet-Draft Mobility Services Transport
April 2007
[6] Eronen, P., "IKEv2 Mobility and Multihoming
Protocol (MOBIKE)",
RFC 4555, June 2006.
[7] 3GPP, "3GPP system architecture evolution (SAE):
Report on
technical options and conclusions", 3GPP TR
23.882 0.10.1,
February 2006.
[8] Koodli, R., "Fast Handovers for Mobile IPv6",
RFC 4068,
July 2005.
[9] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure
Neighbor Discovery (SEND)", RFC 3971, March
2005.
Authors' Addresses
Telemaco Melia
NEC Europe Network Laboratories
Kufuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511 42
Email: telemaco.melia@netlab.nec.de
Eleanor Hepworth
Siemens Roke Manor Research
Roke Manor
Romsey, SO51 5RE
UK
Email: eleanor.hepworth@roke.co.uk
Srivinas Sreemanthula
Nokia Research Center
6000 Connection Dr.
Irving, TX 75028
USA
Email: srinivas.sreemanthula@nokia.com
Melia, et al. Expires October 27, 2007
[Page 16]
Internet-Draft Mobility Services Transport
April 2007
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway NJ 08854
USA
Email: yohba@tari.toshiba.com
Vivek Gupta
Intel Corporation
2111 NE 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503 712 1754
Email: vivek.g.gupta@intel.com
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FIN-00051 Sonera
FINLAND
Phone: +358 40 534 4455
Email: jouni.korhonen@teliasonera.com
Rui L.A. Aguiar
Instituto de Telecomunicacoes Universidade de Aveiro
Aveiro 3810
Portugal
Phone: +351 234 377900
Email: ruilaa@det.ua.pt
Sam(Zhongqi) Xia
Huawei Technologies Co.,Ltd
HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information
Industry Base,Hai-Dian District Beijing
100085
P.R. China
Phone: +86-10-82836136
Email: xiazhongqi@huawei.com
Melia, et al. Expires October 27, 2007
[Page 17]
Internet-Draft Mobility Services Transport
April 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 October 27, 2007
[Page 18]
________________________________
_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
--
Dr. Telemaco Melia
telemaco.melia@netlab.nec.de
Senior Research Staff Member Tel: +49 (0)
6221 4342- 142
NEC Europe Ltd. Fax: +49 (0)
6221 4342- 155
Network Laboratories Web:
http://www.netlab.nec.de
Kurfuersten-Anlage 36
69115 Heidelberg
GERMANY
NEC Europe Limited | Registered Office: NEC House, 1
Victoria Road, London W3 6BL | Registered in England 2832014
_______________________________________________ MIPSHOP-MIH-DT mailing list MIPSHOP-MIH-DT@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
- [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Sam Xia
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Robert Hancock
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Zuniga, Juan Carlos
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Subir Das
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- Re: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Heejin Jang
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia