One document matched: draft-haddad-mext-mobisoc-00.txt
Mobility Extensions for IPv6 W. Haddad
(Mext) Ericsson
Internet-Draft July 2, 2009
Intended status: Standards Track
Expires: January 3, 2010
Enhancing Mobile IPv6 Route Optimization Mode with Secure Social
Dimension
draft-haddad-mext-mobisoc-00
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 January 3, 2010.
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Haddad Expires January 3, 2010 [Page 1]
Internet-Draft MIPv6 RO Mode Optimization July 2009
Abstract
This memo describes an enhancement to Mobile IPv6 route optimization
mode which is derived from introducing a social dimension within the
home network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation and Goal . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6
5. New Options, Bits and Messages Formats . . . . . . . . . . . . 8
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Haddad Expires January 3, 2010 [Page 2]
Internet-Draft MIPv6 RO Mode Optimization July 2009
1. Introduction
We suggest an enhancement to Mobile IPv6 protocol ([MIPv6]) 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).
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 January 3, 2010 [Page 3]
Internet-Draft MIPv6 RO Mode Optimization July 2009
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 [TERM].
Haddad Expires January 3, 2010 [Page 4]
Internet-Draft MIPv6 RO Mode Optimization July 2009
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. m
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!
While such goal may not be attainable in all situation, we limit our
scope in this version to the case of two mobile nodes sharing the
same HA or cluster of HAs.
Haddad Expires January 3, 2010 [Page 5]
Internet-Draft MIPv6 RO Mode Optimization July 2009
4. Protocol Description
Our proposal enables two mobile nodes which have established mutual
social bonds, e.g., two "buddies", to translate such relationship
into a bidirectional 'symbiotic' relationship on a network and
cryptographic levels. At some particular point, the two "buddies"
will confidentially disclose their 'symbiotic' relationship to their
home agent, in order to request implementing a "zero signaling
message" RO mode.
To 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 step
outside the home network. It follows that our proposal requires both
mobile nodes to use the "cryptographically generated addresses"
technique, defined in [CGA], in order to compute and auto-configure
their IPv6 home addresses. Establishing their mutual symbiotic
relationship can be achieved using for example, the "Secure Neighbor
Discovery" protocol (described in [SeND]).
The required mutual, i.e.. bidirectional, relationship between the
two mobile nodes is of cryptographic nature (please refer to
[SYMBIO]) and is supposed to be established as a consequence of a
mutual social relationship. When MN2 establishes a unidirectional
'symbiotic' 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 use of a 'symbiotic'
relationship, the same crypto relationship should be established in
the opposite direction, i.e., from MN1 to MN2. Since the crypto
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 is used and the "proof of relationship" is inserted in the
first BU message sent by MN1 to its HA. After validation, the HA
Haddad Expires January 3, 2010 [Page 6]
Internet-Draft MIPv6 RO Mode Optimization July 2009
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 'symbiotic' 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 enjoys the same security
level than a classic BU message sent by a MN to its HA. This means
that the same IPsec tunnel established between the MN and its HA can
be used to secure the NBU message transmission as well as the
acknowledgement message called "Neighbor Binding Acknowledgement
(NBA)". 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
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 January 3, 2010 [Page 7]
Internet-Draft MIPv6 RO Mode Optimization July 2009
5. New Options, Bits and Messages Formats
TBD
Haddad Expires January 3, 2010 [Page 8]
Internet-Draft MIPv6 RO Mode Optimization July 2009
6. Future Work
Future work includes widening the scope of the suggested mechanism to
enable mobile "buddies" attached to different home networks to
benefit from the suggested mechanism and avoid exchanging any extra
mobility signaling messages prior to switching to the RO mode.
Haddad Expires January 3, 2010 [Page 9]
Internet-Draft MIPv6 RO Mode Optimization July 2009
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
related threats and thus, contributes to further improving the
overall security. However, it should be noted again that this
proposal is limited in its applicability to mobile nodes using the
same home agent (or cluster of home agents).
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 January 3, 2010 [Page 10]
Internet-Draft MIPv6 RO Mode Optimization July 2009
8. References
8.1. Normative References
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3792, March 2005.
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
for IPv6", Internet
Draft, draft-ietf-mext-rfc3775bis-03.txt, June 2004.
[SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P.
Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971,
March 2005.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
8.2. Informative References
[SYMBIO] Haddad, W. and M. Naslund, "On Secure Neighbor Discovery
Proxying Using 'Symbiotic' Relationship", Internet
Draft, draft-haddad-csi-symbiotic-sendproxy-00.txt,
October 2008.
Haddad Expires January 3, 2010 [Page 11]
Internet-Draft MIPv6 RO Mode Optimization July 2009
Author's Address
Wassim Haddad
Ericsson
6210 Spine Rd
Boulder, CO 80301
US
Phone: +1 303 473 6963
Email: Wassim.Haddad@ericsson.com
Haddad Expires January 3, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:14 |