One document matched: draft-haddad-mipv6-omipv6-00.txt
Internet Engineering Task Force Wassim Haddad
Internet Draft Helsinki University of Technology
Expires in February 2004 Ericsson Research Canada
Suresh Krishnan
Ericsson Research Canada
September 2003
Optimizing Mobile IPv6 (OMIPv6)
<draft-haddad-mipv6-omipv6-00.txt>
Status of this memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. 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.
Distribution of this memo is unlimited
Abstract
Mobile IPv6 [1] is supposed to solve the mobility problem and
offers a new mode, which allows the flows of data packets
between a mobile node (MN) and a correspondent node (CN) to be
exchanged via the direct path between them. However this
efficiency comes at high price in terms of security needs and
excessive mobility signaling messages.
This draft introduces a proposal to make Mobile IPv6 more
optimized with regards to security needs and less redundant in
signaling messages.
Haddad, Krishnan Expires February 2004 [Page 1]
INTERNET-DRAFT OMIPv6 September 2003
1. Introduction
Mobile IPv6 defines the route optimization (RO) mode as one way
of exchanging data packets between a mobile node and a
correspondent node, via the direct path between them. While this
mode is very efficient, it raises many security concerns and
leads to high redundancy in mobility signaling messages.
According to [1], these signaling messages are needed to keep
creating shared secrets between the two entities talking to each
other and testing the reachability of MN's IP addresses.
This draft suggests an optimization to the RO mode, which aims
to enhance its efficiency by making it less vulnerable and
reducing the high number of signaling messages involved in the
session.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
in this document are to be interpreted as described in RFC 2219
[2].
3. Motivation
The RO mode allows one MN to talk directly to the CN, i.e, by
using the direct path between them. For this to happen, the MN
needs to create a shared secret (i.e., Kbm) with the CN in order
to authenticate the binding updates (BUs) messages and let the
CN authenticates the binding acknowledgements (BAs) messages
with the same shared key. For security reasons, it is required
that the lifetime of the shared secret be reduced to few
minutes, thus obliging both entities to re-create a new Kbm at
a high frequency. For more information about the security
concerns related to the RO mode, please refer to [3].
Each time the MN needs to update its Kbm, it needs to exchange
four messages with the CN (i.e., the return routability (RR)
procedure). Note that for security reasons, the MN's home agent
(HA)must get involved each time the RR test is launched. The
loss of any of the four messages requires the MN to exchange at
least two additional messages with the CN.
If the RR test succeeds (i.e., the MN and the CN compute a
shared secret), the MN must send a BU message to its HA and
waits for a BA. Upon receiving a BA from its HA, the MN sends a
BU to its CN to update its binding cache entry (BCE) about its
new location (i.e., care-of address (Co@)) and waits for a BA.
Haddad, Krishnan Expires February 2004 [Page 2]
INTERNET-DRAFT OMIPv6 September 2003
Note that authenticating BUs requires approximately 1.5 round
trip times between the mobile node and each correspondent node
(for the entire RR procedure in a best case scenario, i.e, no
packet losses) and one round trip time between the MN and the
HA. Such redundancy is not acceptable for time sensitive
applications.
It becomes clear from the above that the RO mode introduces an
expensive efficiency in terms of excessive mobility messages,
high latency and many security concerns.
This draft describes one way to make the exchange of BUs/BAs
more safe and substantially reduce the number of mobility
signaling messages as well as the latency of the handover.
4. Overview of OMIPv6
The suggested solution does not introduce nor replace any new or
existing signaling messages. It is to be implemented on top of
what has been accepted as the most efficient solution to the
mobility problem. OMIPv6 exploits the RR test procedure, which
has been designed in [1]. OMIPv6 MUST NOT be used alone.
One of the main advantages behind using OMIPv6 is that it gives
a malicious node only "one" chance to exploit spoofing, if and
when it is possible, the HoT and CoT messages together, thus
narrowing the window of vulnerability to the minimum. The second
advantage of OMIPv6 is that it does not require the deployment
of an infrastructure to distribute keys, thus eliminating any
scalability problems.
Another advantage behind using OMIPv6 lies in the possibility of
deriving a longer shared secret key making it more difficult to
crack.
Finally, OMIPv6 substantially reduces the amount of mobility
signaling messages and makes the exchange, if and when needed,
of the HoTI/HoT and CoTI/CoT messages independant from the
handover process.
OMIPv6 consists on deriving a long shared secret key which will
be used by both entities to authenticate the BUs/BAs messages.
The new shared secret is derived from a DH exchange, which will
be launched by the MN after successfully testing its new and
home IP addresses with the CN's address (i.e., the RR test).
The DH messages exchanged between the CN and the MN MUST BE
authenticated by the Kbm key derived from the latest RR test.
Haddad, Krishnan Expires February 2004 [Page 3]
INTERNET-DRAFT OMIPv6 September 2003
The DH exchange will allow both entities to establish a
bidirectional security association (SA) between them without the
need to rely on any exisiting public key infrastructure.
The DH messages MUST BE exchanged on the same paths used to
exchange the RR test messages. For this purpose, the MN MUST use
the Kbm to sign the first DH message and send it to the CN via
the direct path. The MN MUST include its home address by using a
home address option (HAO). The CN's reply to the first message
MUST be signed with the Kbm and duplicated. One copy of the
second DH message MUST BE send via the direct path and the
second copy via the path going through the MN's HA. If the two
messages are identical, the MN pursues the DH exchange and sends
the third message via the direct path. The CN replies by sending
the fourth DH message on the same path.
Note that the main objective of duplicating the second message
is the potential ability to reveal a possible MiTM attack on the
first one (i.e., the malicious node knows the Kbm).
By duplicating the second DH message, a successful MiTM attack
will consist on attacking two duplicated messages sent on two
different paths at the same time, which probably makes such kind
of attack more difficult.
The DH process will enable both entities (i.e., the MN and the
CN) to compute a long shared secret called "authenticated
binding management key" (Kabm). The Kabm will be used to
authenticate the BU/BA messages exchanged via the direct path
between the MN and the CN. In this case, the exchange of BU/BA
messages will allow the two endpoints to test the reachability
of the new direct path in both directions prior to injecting any
new data packets on the new path.
The DH exchange can be launched at any time during the ongoing
session. In order to reduce the amount of signaling messages to
the minimum, it MAY be launched, for example, immediately after
running the first RR test.
After running the DH procedure, any new mobility signaling
message MUST be signed with the new Kabm computed from the DH
exchange. The two endpoints SHOULD silently drop any mobility
message related to the MN's home/care-of address or the CN's
address and not signed with the Kabm.
If the MN needs to exchange CoTI/CoT messages with the CN, it may
be possible to send the CoTI message in parallel with the BU.
The scheme below shows the different paths taken by the four
messages of a DH exchange between a MN and the CN:
Haddad, Krishnan Expires February 2004 [Page 4]
INTERNET-DRAFT OMIPv6 September 2003
+------------+ +------+
| | | |
| MN |<----------------------| HA |
| | DH2 | |
+------------+ +------+
| ^ ^ | ^
| | DH2| |DH1 /
| | | | /
DH3| |DH4 | | /
V | | V /
+------------+ /
| | /
| CN |-------------------/
| | DH2
+------------+
As it has been mentioned, the DH messages MUST be authenticated
from both sides by using the Kbm. The contents and the signature
associated with each DH message has been detailed in [4].
In OMIPv6, the DH messages exchanged between the two MNs are
described in the following:
sid , gX, N , info
MN MN MN MN CN
--------------------------------------------------------------->
sid , sid , gY, N , info
MN MN CN CN CN CN
<---------------------------------------------------------------
sid ,sid ,MN, SIG (N , sid ,gX, info , info ), MAC(MN)
MN CN Kbm CN MN MN CN Km CN
--------------------------------------------------------------->
sid ,sid, ,info ,CN, SIG (N ,sid ,gY,info, info), MAC(CN)
MN CN CN Kbm MN CN CN MN Km CN
<---------------------------------------------------------------
In the above scheme, the following abbreviations have been
adopted:
Haddad, Krishnan Expires February 2004 [Page 5]
INTERNET-DRAFT OMIPv6 September 2003
-gX = shared part of MN's secret
-gY = shared part of CN's secret
-sid = session identifier used to specify the ongoing session.
-N = nonce
-info = additional information carried in the protocol
messages
-MN = Identity of MN (e.g., MN's Home IP address)
-CN = Identity of CN (e.g., CN's IP address)
-Kbm = key generated from the RR test
-SIG(msg) = denotes the signature of "msg" using the Kbm.
-Km = key generated from DH (known only by the MN and the CN)
-MAC(msg) = denotes a message authenticated code computed from
Km "msg" and signed by Km.
5. Security considerations
The draft describes a method to make the route optimization mode
more efficient.
6. Acknowledgements
Authors would like to thank Laurent Marchand for reviewing the
draft. Many thanks for Francis Dupont, Erik Nordmark, and Yuri
Ismailov for their inputs on the idea.
7. Normative References
[1] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-24.txt, June 2003.
[2] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119.
Haddad, Krishnan Expires February 2004 [Page 6]
INTERNET-DRAFT OMIPv6 September 2003
8. Informative References
[3] P. Nikander, T. Aura, J. Arkko, G.Montenegro and E. Nordmark
"Mobile IP version 6 Route Optimization Security Design
Background", draft-nikander-mobileip-v6-ro-sec-01.
[4] Krawczyk, H., "SIGMA: the 'SIGn-and-MAC'Approach to
Authenticated Diffie-Hellman and its use in the IKE
Protocols", in Advanceds in Cryptography - CRYPTO 2003
Proceedings, LNCS 2729, Springer, 2003. Available at:
http://www.ee.technion.ac.il/~hugo/sigma.html
9. Author's Addresses
Wassim Haddad
Ericsson Research Canada
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
Canada
Tel: +1 514 345 7900
Fax: +1 514 345 7900
E-mail: Wassim.Haddad@lmc.ericsson.se
Suresh Krishnan
Ericsson Research Canada
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
Canada
Tel: +1 514 345 7900
Fax: +1 514 345 7900
E-mail: Suresh.Krishnan@lmc.ericsson.se
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
Haddad, Krishnan Expires February 2004 [Page 7]
INTERNET-DRAFT OMIPv6 September 2003
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or
assignees.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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.
Haddad, Krishnan Expires February 2004 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 01:48:56 |