draft-ietf-mip6-ro-sec-01.txt   draft-ietf-mip6-ro-sec-02.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft J. Arkko Internet-Draft J. Arkko
Expires: January 17, 2005 Ericsson Research Nomadic Lab Expires: April 15, 2005 Ericsson Research Nomadic Lab
T. Aura T. Aura
Microsoft Research Microsoft Research
G. Montenegro G. Montenegro
Sun Microsystems Laboratories
E. Nordmark E. Nordmark
Sun Microsystems Sun Microsystems
July 19, 2004 October 15, 2004
Mobile IP version 6 Route Optimization Security Design Background Mobile IP version 6 Route Optimization Security Design Background
draft-ietf-mip6-ro-sec-01 draft-ietf-mip6-ro-sec-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005. This Internet-Draft will expire on April 15, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document is a succint account of the rationale behind the Mobile This document is a succint account of the rationale behind the Mobile
IPv6 (MIPv6) Route Optimization Security Design. The purpose of this IPv6 (MIPv6) Route Optimization Security Design. The purpose of this
document is to present the thinking and to preserve the reasoning document is to present the thinking and to preserve the reasoning
behind the Mobile IPv6 Security Design in 2001-2002. behind the Mobile IPv6 Security Design in 2001-2002.
The document has two target audiences: (1) MIPv6 implementors so that The document has two target audiences: (1) MIPv6 implementors so that
they can better understand the design choices in MIPv6 security they can better understand the design choices in MIPv6 security
skipping to change at page 34, line 11 skipping to change at page 34, line 11
so, it becomes obvious that the only residual attack against which so, it becomes obvious that the only residual attack against which
there is no clear-cut prevention (other than its severe limitation as there is no clear-cut prevention (other than its severe limitation as
currently specified) is the time shifting attack mentioned above. currently specified) is the time shifting attack mentioned above.
5.2 Interaction with IPsec 5.2 Interaction with IPsec
A major motivation behind the current binding update design was A major motivation behind the current binding update design was
scalability, the ability to run the protocol without any existing scalability, the ability to run the protocol without any existing
security infrastructure. An alternative would have been to rely on security infrastructure. An alternative would have been to rely on
existing trust relationships, perhaps in the form of a special existing trust relationships, perhaps in the form of a special
purpose Public Key Infrastructure and IPsec. That would have limited purpose Public Key Infrastructure in conjunction with IPsec. That
scalability, making route optimization available only in environments would have limited scalability, making route optimization available
where it is possible to create appropriately authorized IPsec only in environments where it is possible to create appropriate IPsec
security associations between the mobile nodes and the corresponding security associations between the mobile nodes and the corresponding
nodes. nodes.
There clearly are situations where there exists an appropriate There clearly are situations where there exists an appropriate
relationship between a mobile node and the correspondent node. For relationship between a mobile node and the correspondent node. For
example, if the correspondent node is a server that has example, if the correspondent node is a server that has
pre-established keys with the mobile node, that would be the case. pre-established keys with the mobile node, that would be the case.
However, entity authentication or an authenticated session key is not However, entity authentication or an authenticated session key is not
necessarily sufficient for accepting Binding Updates. necessarily sufficient for accepting Binding Updates.
skipping to change at page 34, line 49 skipping to change at page 34, line 49
Care-of Address Check: As for the care-of address check, in Care-of Address Check: As for the care-of address check, in
practice, it seems highly unlikely that nodes could completely practice, it seems highly unlikely that nodes could completely
replace the care-of address check with credentials. Since the replace the care-of address check with credentials. Since the
care-of addresses are ephemeral, in general it is very difficult care-of addresses are ephemeral, in general it is very difficult
for a mobile node to present credentials that taken at face value for a mobile node to present credentials that taken at face value
(by an arbitrary correspondent node) guarantee no misuse for, say, (by an arbitrary correspondent node) guarantee no misuse for, say,
flooding attacks (Section 3.2). As discussed before, a flooding attacks (Section 3.2). As discussed before, a
reachability check goes a long way to alleviate such attacks. reachability check goes a long way to alleviate such attacks.
Notice that, as part of the normal protocol exchange, establishing Notice that, as part of the normal protocol exchange, establishing
an IPsec security association via IKE includes one such IPsec security associations via IKE includes one such reachability
reachability test. However, as per the previous section, the test. However, as per the previous section, the natural IKE
natural IKE protocol exchange runs between the correspondent node protocol exchange runs between the correspondent node and the
and the mobile node's home address. Hence, another reachability mobile node's home address. Hence, another reachability check is
check is needed to check the care-of address at which the node is needed to check the care-of address at which the node is currently
currently reachable. If this address changes, such a reachability reachable. If this address changes, such a reachability test is
test is likewise necessary, and is included in ongoing work aimed likewise necessary, and is included in ongoing work aimed at
at securely updating the node's current address. securely updating the node's current address.
Nevertheless, the Mobile IPv6 base specification [7] does not specify Nevertheless, the Mobile IPv6 base specification [7] does not specify
how to use IPsec together with the mobility procedures between the how to use IPsec together with the mobility procedures between the
mobile node and correspondent node. On the other hand, the mobile node and correspondent node. On the other hand, the
specification is carefully written to allow the creation of the specification is carefully written to allow the creation of the
binding management key Kbm through some different means. binding management key Kbm through some different means.
Accordingly, where an appropriate relationship exists between a Accordingly, where an appropriate relationship exists between a
mobile node and a correspondent node, the use of IPsec is possible, mobile node and a correspondent node, the use of IPsec is possible,
and is, in fact, being pursued in more recent work. and is, in fact, being pursued in more recent work.
skipping to change at page 39, line 9 skipping to change at page 39, line 9
[11] Nikander, P., "Denial-of-Service, Address Ownership, and [11] Nikander, P., "Denial-of-Service, Address Ownership, and
Early Authentication in the IPv6 World", Security Protocols 9th Early Authentication in the IPv6 World", Security Protocols 9th
International Workshop, Cambridge, UK, April 25-27 2001, LNCS International Workshop, Cambridge, UK, April 25-27 2001, LNCS
2467, pages 12-26, Springer, 2002. 2467, pages 12-26, Springer, 2002.
[12] Chiappa, J., "Endpoints and Endpoint Names: A Proposed [12] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", date unknown. Enhancement to the Internet Architecture", date unknown.
[13] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, [13] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
(work in progress), April 2004. (work in progress), July 2004.
Authors' Addresses Authors' Addresses
Pekka Nikander Pekka Nikander
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com EMail: pekka.nikander@nomadiclab.com
Jari Arkko Jari Arkko
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
Tuomas Aura Tuomas Aura
Microsoft Research Microsoft Research
Gabriel Montenegro Gabriel Montenegro
Sun Microsystems Sun Microsystems Laboratories
Montbonnot 38240 16 Network Circle
France Menlo Park 94025
USA
Phone: Phone:
EMail: gab@sun.com EMail: gab@sun.com
Erik Nordmark Erik Nordmark
Sun Microsystems Sun Microsystems
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/