One document matched: draft-haddad-mext-mobisoc-03.txt
Differences from draft-haddad-mext-mobisoc-02.txt
Mobility Extensions for IPv6 W. Haddad
(Mext) Ericsson
Internet-Draft August 18, 2010
Intended status: Standards Track
Expires: February 19, 2011
Enhancing Mobile IPv6 Route Optimization Mode with Secure Social
Dimension
draft-haddad-mext-mobisoc-03
Abstract
This memo describes an enhancement to Mobile IPv6 route optimization
mode which is derived from introducing a social dimension within the
home network.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 19, 2011.
Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Haddad Expires February 19, 2011 [Page 1]
Internet-Draft MIPv6 RO Mode Optimization August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation and Goal . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6
5. Dual Mobility With Different Home Networks . . . . . . . . . . 9
6. New Options, Bits and Messages Formats . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Haddad Expires February 19, 2011 [Page 2]
Internet-Draft MIPv6 RO Mode Optimization August 2010
1. Introduction
We suggest an enhancement to Mobile IPv6 protocol
([I-D.ietf-mext-rfc3775bis]) based on introducing a social dimension
within the home network. Consequently, our mechansim is currently
limited to mobile nodes using the same HA (or cluster of HAs).
The proposed enhancement enables two mobile nodes which know each
other "fairly well" to "switch on" the RO mode without the need for
any mobility signaling messages.
Haddad Expires February 19, 2011 [Page 3]
Internet-Draft MIPv6 RO Mode Optimization August 2010
2. Conventions used in this document
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 [RFC2119].
Haddad Expires February 19, 2011 [Page 4]
Internet-Draft MIPv6 RO Mode Optimization August 2010
3. Motivation and Goal
We start by highlighting first that the stunning rapid growth of
social networks is by itself a great motivation to investigate how to
adapt such highly successful "trend" on current protocols which will
sooner or later impact social networking technologies.
It is also well known that the RO mode enables a more efficient data
packets exchange than the bidirectional tunneling and thus, should be
used whenever possible unless the mobile node is not interested in
disclosing its topological location, i.e., care-of address, for the
CN (e.g., for privacy reasons). However, MIPv6 RO mode requires
exchanging a significant amount of signaling messages in order to
establish, and periodically refresh a bidirectional security
association (BSA) between the mobile node and the correspondent node
(CN). While the mobility signaling exchange severely impacts the
handoff latency, the BSA is needed to authenticate one particular
message only, namely the binding update (it can be argued that two
messages are authenticated with the BSA but we note that sending a
binding acknowledgement is not mandatory). Last but not least, note
that the amount of mobility signaling messages gets a boost when both
endpoints are mobile.
Our goal is to enable the RO mode between two mobile endpoints at
minimum or no cost. This means that two mobile nodes should be able
-if they both explicitly ask for it- to switch from BT mode to RO
mode without any signaling message exchange (i.e., in which case,
there won't be any need for establishing a BSA). Our optimization
results in a much lower handoff latency when switching to the RO
mode, the absence of BSA and all accompanying security concerns!
Haddad Expires February 19, 2011 [Page 5]
Internet-Draft MIPv6 RO Mode Optimization August 2010
4. Protocol Description
Our proposal considers that two mobile nodes which have established
mutual social bonds, e.g., two "buddies", are capable of translating
such relationship into a bidirectional cryptographic relationship on
a network level. At some particular point, the two "buddies" will
confidentially disclose their crypto-relationship to their home
agent, in order to request implementing a fast "zero signaling
message" RO mode.
However, it is important to mention that expressing mutual friendship
is not limited to establishing crypto-relationships between two or
more buddies. In this proposal, we use the crypto-relationship only
as an example, to demonstrate the effect of introducing a social
dimension in optimizing dual mobility.
To better clarify our ideas, we consider in the following a pair of
mobile nodes, MN1 and MN2, which fulfills our requirement, then
follow their movements outside their shared home network. We
consider that MN1 and MN2 have established a session and MN1 is the
first to move outside the home network. It follows that our proposal
requires both mobile nodes to use the "cryptographically generated
addresses" technique (described in [RFC3972]), in order to compute
and auto-configure their IPv6 home addresses. Establishing mutual
cryptographic relationships can be achieved using for example, the
"Secure Neighbor Discovery" protocol ([RFC3971]).
The required mutual, i.e., bidirectional, cryptographic relationships
between the two mobile nodes can be implemented following the
description in [I-D.haddad-csi-symbiotic-sendproxy], and is supposed
to be established only as a consequence of a mutual social
relationship. When MN2 establishes a unidirectional crypto-
relationship with MN1, it generates a 128-bit modifier from hashing
MN1's public key together with a 128-bit random number (RAN):
Modifier = First [128, SHA-2(PK(MN1) | RAN) ]
MN2 confidentially notifies MN1 about the RAN used to generate its
CGA address and MN1 stores the RAN together with MN2's CGA address.
As mentioned earlier, such unidirectional crypto-relationship can be
seen as the translation of the social relationship into a network and
security layer parameters. This means that when using its CGA
feature with other "stranger" nodes, MN2 does not need to disclose
the roots of the modifier used to configure its CGA address.
It becomes clear that in order to make full use of a crypto-
relationship in our context, then it should also be established in
the opposite direction, i.e., from MN1 to MN2. Since the crypto-
Haddad Expires February 19, 2011 [Page 6]
Internet-Draft MIPv6 RO Mode Optimization August 2010
relationship is secure and unidirectional, each mobile node can
confidentially share its own part of the bidirectional relationship
with its HA whenever needed. For this purpose, the IPsec tunnel
established between the MN and its HA in order to encrypt the BU
messages (and the data packets) is used and the "proof of
relationship" is inserted in the first BU message sent by MN1 to its
HA. After validation, the HA stores the crypto-relationship in the
binding cache entry (BCE) created for MN1. No further action is
taken until the other part of the crypto-relationship is also
disclosed to the HA (i.e., recall that a crypto-relationship is
unidirectional which means that a mutual one requires both parties to
disclose each other's RAN and their signatures).
At some point in time, MN2 decides also to move outside the home
network and sends its first BU message to update its HA with its new
CoA. Since MN2 is still exchanging data packets with MN1, it inserts
in the BU message the crypto-relationship it has established earlier
with MN1. When validating the BU message sent by MN2, the HA checks
if the claimed crypto-relationship with MN1 is reciprocal, i.e., if
the one between MN1 and MN2 is already stored in MN1's corresponding
BCE, before sending a BA message to MN2. In case a bidirectional
relationship is confirmed, then and only then, can the HA send in
parallel a BA message to MN2 in which, it includes MN1's CoA and
another new message to MN1 (called "Neighbor Binding Update (NBU)")
which carries MN2's freshly stored CoA.
It follows immediately that the NBU message will enjoy the same
security level than a classic BU message sent by a MN to its HA.
This means that it can also be injected in the same IPsec tunnel
already established between the MN and its HA. The acknowledgement
message called "Neighbor Binding Acknowledgement (NBA)" is also
secured in the same way. Note that the HA SHOULD set a new bit
(called "Buddy" (B) bit) in the BA message sent to MN2, in order to
notify it about a parallel update of MN1.
The inclusion of MN1's CoA in the BA message together with sending an
NBU message to MN1 allow both mobile nodes to quickly learn each
other's current topological location from a "trusted" source, and to
create the necessary binding in order to redirect their data packets
on the optimized path.
Note that in order to increase the overall performance, the HA can
send multiple consecutive copies of the NBU messages until it
receives the NBA message.
Subsequent BU messages sent to the HA and carrying new CoAs are
processed in the same way as the first one. This means that the HA
should always update the other mobile node and acknowledge the BU
Haddad Expires February 19, 2011 [Page 7]
Internet-Draft MIPv6 RO Mode Optimization August 2010
message at the same time.
The suggested proposal can be extended to include multiple mobile
nodes in which case the update would consist of sending one or
multiple NBU message to the ones located outside the home network.
Haddad Expires February 19, 2011 [Page 8]
Internet-Draft MIPv6 RO Mode Optimization August 2010
5. Dual Mobility With Different Home Networks
In this section, we look at the scenario where the mobile "buddies",
i.e., MN1 and MN2, have two different HAs, i.e., they belong to
different home networks. In order to enable implementing a
simplified "zero signaling" RO mode between the two mobile nodes, we
make the following two assumptions:
- Each of the two HAs has an up-to-date list of other HAs IPv6
addresses as well as their advertised prefix(es) and public keys.
Consequently, when MN1 requests RO mode service from its own HA
(i.e., by sending a BU message to HA1) for MN2's IPv6 address, then
HA1 can lookup MN2's prefix and obtain HA2's corresponding
parameters.
- The two HAs can set up an IPsec tunnel between them.
Note that the first assumption does not hint/imply that each HA
should have a list of all available HAs around the globe. In fact,
the selected HAs are to be agreed upon between operators. It follows
that the RO mode service cannot be provided via an HA which is not
included in the list stored by the other MN's HA.
We consider in the following that the IPsec tunnel is already in
place and we don't worry about how it is set up. In the following
scenario, MN1 sends the first BU message to its HA (i.e., HA1) while
MN2 is still attached to its home network. In the BU message sent to
HA1, MN1 discloses its crypto-relationship with MN2 as an implicit
request for enabling RO mode between the two mobile endpoints. On
HA1 side, the first step after creating a binding cache entry for MN1
is to look-up parameters related to MN2's HA (i.e., HA2).
After obtaining HA2's IPv6 address and public key, HA1 triggers the
RO mode service by sending a new message to HA2 (called "RO Neighbor
Solicitation (RNS)") in which, it requests confirmation for the
mutual relationship between MN1 and MN2. RNS message must carry
MN1's HoA and CoA and the same associated binding lifetime stored by
HA1. Being sent through the IPsec tunnel, the RNS message is
encrypted and integrity protected. In addition, the HA may sign the
message.
When receiving a valid RNS message, HA2 checks its binding cache
table for MN2's HoA. If the binding is not found, e.g., MN2 is still
attached to its home network, then HA2 stores the RNS parameters
until the expiration of the lifetime suggested in the RNS message.
This means that as long as MN1 keeps mentioning MN2's HoA in the BU
messages sent to HA1, the latter must make sure that HA2 has also a
valid request for enabling RO mode between MN1 and MN2. After
Haddad Expires February 19, 2011 [Page 9]
Internet-Draft MIPv6 RO Mode Optimization August 2010
storing the RNS parameters, HA2 sends another new message called "RO
Neighbor Present (RNP)" to HA1 in order to clarify MN2 status. The
RNP message is also encrypted and integrity protected as it is sent
in the IPsec tunnel. Note that HA1 does not need to wait for the RNP
message before acknowledging the BU message from MN1. In fact, as
long as HA1 does not have any parameters related to MN2 stored in its
cache memory, it can send the BA message immediately to MN1 and
without carrying any additional information.
When MN2 moves outside its home network, it sends a BU message to HA2
in which, it discloses its relationship with MN1. Such message
triggers a lookup of MN1's HoA in HA2 cache memory which will
ultimately return MN1's RNS parameters. Following the lookup, HA2
replies first to HA1 by sending an "RO Neighbor Update (RNU)" message
which carries MN2's new CoA and HoA, then replies to MN2 with a BA
message which carries MN1's CoA. In the meantime, HA1 updates MN1
with MN2's new CoA by sending an NBU message. Note that HA2 may wait
for an acknowledgement message from HA1, prior to sending the BA
message with MN1's CoA. The RNU message must be sent in the IPsec
tunnel between the two HAs. HA2 may also sign the message.
It should also be mentioned that the above mechanism remains highly
efficient in a "double jumping" scenario, at the potential cost of
sending two NBU messages (one for each MN), which remains negligible.
Note that an HA should always send the RNU message to the other HA
before sending the BA message to its mobile node.
Haddad Expires February 19, 2011 [Page 10]
Internet-Draft MIPv6 RO Mode Optimization August 2010
6. New Options, Bits and Messages Formats
TBD
Haddad Expires February 19, 2011 [Page 11]
Internet-Draft MIPv6 RO Mode Optimization August 2010
7. Security Considerations
This proposal aims to enhance the RO mode efficiency by removing the
need for the return routability procedure. Consequently, RO mode
related mobility signaling messages exchange between the mobile node
and the correspondent node are no more required. Removing the RR and
its justification, i.e., the BU/BA exchange, quickly eliminates the
related threats and thus, contributes to further improving the
overall security.
Our suggested mechanism introduces two new signaling messages which
are exchanged between the MN and its HA. These two messages do not
introduce any new threats nor amplify existing ones as they are
exchanged within the IPsec ESP tunnel established between the MN and
its HA. In addition to the tunnel encryption and integrity
protection between the MN and the HA, there is also a mutual trust
between the two nodes which provide enough insurance about the
validity of the message content. This in turn, positively impacts
the overall security of the procedure. However, it should be
highlighted that the mutual trust between the MN and the HA does not
propagate among mobile nodes sharing the same HA.
In fact, it can be argued that a simpler way to implement our
protocol would be to let the mobile node update its HA with the list
of IPv6 addresses which are used by his/her buddies. In this case,
the HA would consider an IPv6 address as a "proof of friendship" if
it is sent by the first MN and also by the owner of the address. We
argue that such approach is flawed as it can disturb the mutual trust
between the HA and MN by allowing the latter to claim fake
relationship with the list of selected targets' IPv6 addresses
without any additional proof. Opening such hole would immediately
raise doubts about why the HA and the MN should trust each other in
the first place! Furthermore, having multiple mobile nodes playing
the same trick with the HA would increase the chances of assembling a
fake bidirectional relationship between two mobile nodes which are
only curious about each other's current location and would lead at
least one of them to disclose its location to the other.
Haddad Expires February 19, 2011 [Page 12]
Internet-Draft MIPv6 RO Mode Optimization August 2010
8. References
8.1. Normative References
[I-D.ietf-mext-rfc3775bis]
Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mext-rfc3775bis-06 (work in
progress), July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
8.2. Informative References
[I-D.haddad-csi-symbiotic-sendproxy]
Haddad, W. and M. Naslund, "On Secure Neighbor Discovery
Proxying Using 'Symbiotic' Relationship",
draft-haddad-csi-symbiotic-sendproxy-01 (work in
progress), July 2009.
Haddad Expires February 19, 2011 [Page 13]
Internet-Draft MIPv6 RO Mode Optimization August 2010
Author's Address
Wassim Michel Haddad
Ericsson
300 Holger Dr
San Jose, CA 95134
US
Phone: +1 646 256 2030
Email: Wassim.Haddad@ericsson.com
Haddad Expires February 19, 2011 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:32 |