< draft-patil-mext-mip6issueswithipsec-01.txt   draft-patil-mext-mip6issueswithipsec-02.txt >
Mobility Extensions (MEXT) B. Patil Mobility Extensions (MEXT) B. Patil
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track D. Premec Intended status: Standards Track D. Premec
Expires: January 14, 2010 Unaffiliated Expires: April 29, 2010 Unaffiliated
C. Perkins C. Perkins
WiChorus WiChorus
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
July 13, 2009 October 26, 2009
Problems with the use of IPsec as the security protocol for Mobile IPv6 Problems with the use of IPsec as the security protocol for Mobile IPv6
draft-patil-mext-mip6issueswithipsec-01 draft-patil-mext-mip6issueswithipsec-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 The list of current Internet-Drafts can be accessed at
http://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 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
Mobile IPv6 as specified in RFC3775 relies on IPsec for security. An Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the
IPsec SA between the mobile node and the home agent provides security signaling messages and user plane traffic between the mobile node and
for the mobility signaling. Use of IPsec for securing the data home agent. An IPsec SA between the mobile node and the home agent
traffic between the mobile node and home agent is optional. This provides security for the mobility signaling. Use of IPsec for
document analyses the implications of the design decision to mandate securing the data traffic between the mobile node and home agent is
IPsec as the default security protocol for Mobile IPv6 and optional. This document analyses the implications of the design
consequently Dual-stack Mobile IPv6 and recommends revisiting this decision to mandate IPsec as the default security protocol for Mobile
decision in view of the experience gained from implementation and IPv6 and consequently Dual-stack Mobile IPv6 and recommends
adoption in other standards bodies. revisiting this decision in view of the experience gained from
implementation and adoption in other standards bodies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. General issues with the use of IPsec for MIP6 security . . . . 6 5. General issues with the use of IPsec for MIP6 security . . . . 6
6. Implementation Issues with IPsec . . . . . . . . . . . . . . . 8 6. Implementation Issues with IPsec . . . . . . . . . . . . . . . 8
6.1. Triggering IKEv2 on the MN . . . . . . . . . . . . . . . . 8 6.1. Triggering IKEv2 on the MN . . . . . . . . . . . . . . . . 8
6.2. Instructing IKEv2 to ask for the MN HoA/prefix . . . . . . 9 6.2. Instructing IKEv2 to ask for the MN HoA/prefix . . . . . . 9
6.3. Providing the MN prefix to the IKEv2 daemon . . . . . . . 9 6.3. Providing the MN prefix to the IKEv2 daemon . . . . . . . 9
6.4. Registering the MN's FQDN in DNS . . . . . . . . . . . . . 9 6.4. Registering the MN's FQDN in DNS . . . . . . . . . . . . . 9
6.5. Providing the Home Network Prefix to the MIP6 6.5. Providing the Home Network Prefix to the MIP6
application . . . . . . . . . . . . . . . . . . . . . . . 9 application . . . . . . . . . . . . . . . . . . . . . . . 10
6.6. SPD Entry for the HoA on the MN side . . . . . . . . . . . 10 6.6. SPD Entry for the HoA on the MN side . . . . . . . . . . . 10
6.7. SPD Entry for the HoA on the HA side . . . . . . . . . . . 10 6.7. SPD Entry for the HoA on the HA side . . . . . . . . . . . 10
6.8. The K bit . . . . . . . . . . . . . . . . . . . . . . . . 11 6.8. The K bit . . . . . . . . . . . . . . . . . . . . . . . . 11
6.9. UDP encapsulation of DSMIP6 signaling . . . . . . . . . . 11 6.9. UDP encapsulation of DSMIP6 signaling . . . . . . . . . . 11
6.10. Transport mode IPsec SAs and NATs . . . . . . . . . . . . 11 6.10. Transport mode IPsec SAs and NATs . . . . . . . . . . . . 12
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec
security association between the mobile node (MN) and home agent security association between the mobile node (MN) and home agent
(HA). The IPsec SA protects the mobility signaling messages between (HA). The IPsec SA protects the mobility signaling messages between
the MN and HA. The user data may be optionally protected by the the MN and HA. The user data may be optionally protected by the
IPsec SA but is not required. IPsec SA but is not required. The use of IPsec by most hosts today
is primarily as a solution for enterprise connectivity through VPN
applications. IPsec has not evolved into a generic security
protocol.
The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified
in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6
working groups in the IETF chose to mandate IPsec as the default working groups in the IETF chose to mandate IPsec as the default
security protocol for Mobile IPv6 based on various criteria and security protocol for Mobile IPv6 based on various criteria and
lengthy discussions that occured between the years 2000 and 2004. lengthy discussions that occured between the years 2000 and 2004.
Implementation experience with Mobile IPv6 and the security variants Implementation experience with Mobile IPv6 and the security variants
with which it has been specified in some SDOs indicates a need to with which it has been specified in some SDOs indicates a need to
revisit the design choice for MIP6 signaling security. The analysis revisit the design choice for MIP6 signaling security. The analysis
and recommendation to revisit the security protocol architecture for and recommendation to revisit the security protocol architecture for
MIP6 should not be interpreted as a recommendation for Authentication MIP6 should not be interpreted as a recommendation for Authentication
Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight
the misfit of IPsec and IKEv2 as the security protocol for MIP6 and the misfit of IPsec and IKEv2 as the security protocol for MIP6 and
hence the need for considering alternatives. hence the need for considering alternatives. A simpler security
architecture for securing the signaling and traffic between the MN
and HA can co-exist with the IPsec based solution as well.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document refers to [RFC3775][RFC4877] for terminology. This document refers to [RFC3775][RFC4877] for terminology.
3. Background 3. Background
skipping to change at page 3, line 48 skipping to change at page 4, line 6
of the IPv6 stack based on the experience gained from developing of the IPv6 stack based on the experience gained from developing
mobility support for IPv4. The design of Mobile IPv6 was worked on mobility support for IPv4. The design of Mobile IPv6 was worked on
by the Mobile IP WG in the late 90s and by the MIP6 WG until its by the Mobile IP WG in the late 90s and by the MIP6 WG until its
publication as [RFC3775] in 2004. publication as [RFC3775] in 2004.
IPsec [RFC4301] was also intended to be a default component of the IPsec [RFC4301] was also intended to be a default component of the
IPv6 stack and was the preferred protocol choice for use by any other IPv6 stack and was the preferred protocol choice for use by any other
IPv6 protocol that needed security. Rather than design security into IPv6 protocol that needed security. Rather than design security into
every protocol feature, the intent was to reuse a well-defined every protocol feature, the intent was to reuse a well-defined
security protocol to meet the security needs. Hence Mobile IPv6 has security protocol to meet the security needs. Hence Mobile IPv6 has
been designed with the security architecture relying on IPsec. been designed with a security architecture that relies on reusing
IPsec.
The Mobile IPv6 specification [RFC3775] was published along with the The Mobile IPv6 specification [RFC3775] was published along with the
companion specification "Using IPsec to Protect Mobile IPv6 Signaling companion specification "Using IPsec to Protect Mobile IPv6 Signaling
Between Mobile Nodes and Home Agents", [RFC3776]. The establishment Between Mobile Nodes and Home Agents", [RFC3776]. The establishment
of the IPsec SA between the MN and HA as per RFC 3776 is based on the of the IPsec SA between the MN and HA as per RFC 3776 is based on the
use of IKE. The use of IKE in the context of Mobile IPv6 for IPsec use of IKE. The use of IKE in the context of Mobile IPv6 for IPsec
SA establishment did not gain traction because of factors such as SA establishment did not gain traction because of factors such as
complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG
completed the specification, Mobile IPv6 Operation with IKEv2 and the completed the specification, Mobile IPv6 Operation with IKEv2 and the
Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877]
skipping to change at page 5, line 21 skipping to change at page 5, line 27
application and the host's security subsystems. application and the host's security subsystems.
An argument can be made that the MIP6 application itself should An argument can be made that the MIP6 application itself should
provide the required changes to the IPsec subsystems of the platform provide the required changes to the IPsec subsystems of the platform
(maybe in the form of patches). While this is possible at least for (maybe in the form of patches). While this is possible at least for
some open source platforms to provide modifications to the host's some open source platforms to provide modifications to the host's
IPsec implementation as well as the key management application(s), IPsec implementation as well as the key management application(s),
this is still an issue for several reasons: this is still an issue for several reasons:
o Target platform could be a commercial platform for which no source o Target platform could be a commercial platform for which no source
code is available. code for the security modules (IPsec and IKEv2) is available.
o If the MIP6 application were to patch the IPsec subsystems, then o If the MIP6 application were to patch the IPsec subsystems, then
multiple MIP6 applications from different developers would multiple MIP6 applications from different developers would
implement it in different ways, which would inevitably lead to implement it in different ways, which would inevitably lead to
variations and problems with interoperability at a minimum, for variations and problems with interoperability at a minimum, for
instance when the user tries to install several MIP6 applications instance when the user tries to install several MIP6 applications
it is difficult to determine which one is the best suited for his/ it is difficult to determine which one is the best suited for his/
her needs. her needs.
o Key management daemons are usually provided as third party o Key management daemons are usually provided as third party
software for which no source code may be available, even if the software for which no source code may be available, even if the
platform itself is available as open source. platform itself is available as open source.
skipping to change at page 6, line 4 skipping to change at page 6, line 10
o Patches for the IPsec part in the kernel and the key management o Patches for the IPsec part in the kernel and the key management
daemon would typically be valid only for the particular version of daemon would typically be valid only for the particular version of
the kernel and the key management daemon for which they were the kernel and the key management daemon for which they were
written. This might prevent the user from upgrading the platform written. This might prevent the user from upgrading the platform
or applying OS security patches that are provided as part of the or applying OS security patches that are provided as part of the
regular platform maintenance since this would in all probability regular platform maintenance since this would in all probability
make the MIP6 application defunct. make the MIP6 application defunct.
o Modifying the security subsystems by a third party is a security o Modifying the security subsystems by a third party is a security
issue and users are generally advised to refrain from allowing the issue and users are generally advised to refrain from allowing the
security subsystems to be modified in any way. security subsystems to be modified in any way.
o The developer may not have the knowledge or the time to modify the o The developer may not have the knowledge or the time to modify the
platform's IPsec subsystems, although it might be perfectly platform's IKEv2 and IPsec subsystems, although it might be
capable to deliver the MIP6 application itself. perfectly capable to deliver the MIP6 application itself.
o There could be copyright issues as well that would prevent o There could be copyright issues as well that would prevent
modifications of the platform's security subsystems or the modifications of the platform's security subsystems or the
delivery of the modifications by the third party. delivery of the modifications by the third party.
o Even if the MIP6 application developer is able to come up with the o Even if the MIP6 application developer is able to come up with the
necessary patches for the security subsystem, it is not realistic necessary patches for the security subsystem, it is not realistic
to expect the prospective user of MIPv6 to first patch the kernel to expect the prospective user of MIPv6 to first patch the kernel
and the key management daemons before using the MIPv6 service. and the key management daemons before using the MIPv6 service.
The above discussion shows why it is unrealistic to expect that the The above discussion shows why it is unrealistic to expect that the
MIP6 application could provide the needed modifications to the IPsec MIP6 application could provide the needed modifications to the IKEv2
subsystems of the host. Section 6 presents a more technical and IPsec subsystems of the host. Section 6 presents a more
discussion of various implementation issues related to the technical discussion of various implementation issues related to the
interworking between the MIP6 application and the IPsec/key interworking between the MIP6 application and the IPsec/key
management modules. management modules.
The problem in a nutshell for MIP6 is the dependence on IPsec and The problem in a nutshell for MIP6 is the dependence on IPsec and
IKEv2 for successful operation. IKEv2 for successful operation.
5. General issues with the use of IPsec for MIP6 security 5. General issues with the use of IPsec for MIP6 security
This section captures several issues with the use of IPsec by MIP6. This section captures several issues with the use of IPsec by MIP6.
skipping to change at page 6, line 45 skipping to change at page 7, line 4
have IPsec capability as a standard feature. While this is true have IPsec capability as a standard feature. While this is true
in many host implementations today, the existence of IPsec in in many host implementations today, the existence of IPsec in
every IPv6 stack is not a given. Hence a host which needs to every IPv6 stack is not a given. Hence a host which needs to
implement Mobile IPv6 must ensure that IPsec and IKEv2 are also implement Mobile IPv6 must ensure that IPsec and IKEv2 are also
available. As a result of this dependence, MIP6 is no longer a available. As a result of this dependence, MIP6 is no longer a
standalone host-based mobility protocol. A good example of a standalone host-based mobility protocol. A good example of a
host based mobility protocol that works as a self-sufficient host based mobility protocol that works as a self-sufficient
module is Mobile IPv4 [RFC3344]. The security associated with module is Mobile IPv4 [RFC3344]. The security associated with
MIP4 signaling is integrated into the protocol itself. MIP4 has MIP4 signaling is integrated into the protocol itself. MIP4 has
been successfully deployed on a large scale in several networks. been successfully deployed on a large scale in several networks.
(2) IPsec use in most hosts is generally for the purpose of VPN (2) IPsec use in most hosts is generally for the purpose of VPN
connectivity to enterprises. It has not evolved into a generic connectivity to enterprises. It has not evolved into a generic
security protocol that can be used by Mobile IPv6 easily. While security protocol that can be used by Mobile IPv6 easily. While
RFC4877 does specify the details which enable only the MIP6 RFC4877 does specify the details which enable only the MIP6
signaling to be encapsulated with IPsec, the general method of signaling to be encapsulated with IPsec, the general method of
IPsec usage has been such that all traffic between a host and IPsec usage has been such that all traffic between a host and
the IPsec gateway is carried via the tunnel. Selective the IPsec gateway is carried via the tunnel. Selective
application of IPsec to protocols is not the norm. Use of IPsec application of IPsec to protocols is not the norm. Use of IPsec
with Mobile IPv6 requires configuration which in many cases is with Mobile IPv6 requires configuration which in many cases is
not easily done because of reasons such as enterprise not easily achievable because of reasons such as enterprise
environments preventing changes to IPsec policies or other. environments preventing changes to IPsec policies.
(3) A MIP6 home agent is one end of the IPsec SA in a many-to-one (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one
relationship. A MIP6 HA may support a very large number of relationship. A MIP6 HA may support a very large number of
mobile nodes which could be in the hundreds of thousands to mobile nodes which could be in the hundreds of thousands to
millions. The ability to terminate a large number of IPsec SAs millions. The ability to terminate a large number of IPsec SAs
(millions) requires signifiant hardware and platform capability. (millions) requires signifiant hardware and platform capability.
The cost issues of such an HA are detrimental and hence act as a The cost issues of such an HA are detrimental and hence act as a
barrier to deployment. barrier to deployment.
(4) The implementation complexity of Mobile IPv6 is greatly (4) The implementation complexity of Mobile IPv6 is greatly
increased because of the interaction with IPsec and IKEv2. A increased because of the interaction with IKEv2. The complexity
standalone MIP6 protocol is easier to implement and deploy (such of the protocol implementation is even more so in the case of
as MIP4 [RFC3344]). The complexity of the protocol Dual stack MIP6 [RFC5555] wherein NAT traversal scenarios are
implementation is even more so in the case of Dual stack MIP6 considered.
[RFC5555].
(5) IPsec and IKEv2 are not implemented or available by default in (5) IPsec and IKEv2 are not implemented or available by default in
every IPv6 or dual stack host. Mobile IPv6 support on such every IPv6 or dual stack host. Mobile IPv6 support on such
devices is not an option. Many low-end cellular hosts have IP devices is not an option. Many low-end cellular hosts have IP
stacks. The need for IPsec and IKEv2 in these devices is not stacks. The need for IPsec and IKEv2 in these devices is not
important whereas mobility support is needed in many cases. A important whereas mobility support is needed in many cases. A
simpler security protocol than the use of IPsec/IKEv2 would make simpler security protocol than the use of IPsec/IKEv2 would make
MIP6 much more attractive to implement and deploy. MIP6 much more attractive to implement and deploy.
(6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile
IPv6 essentially results in a variant of IPsec which is specific IPv6 essentially results in a variant of IPsec which is specific
to Mobile IP. Hence this results in added complexity to to Mobile IP. Hence this results in added complexity to
implementations. implementations.
(7) Mobile IPv6 needs to be capable of being deployed in situations (7) Mobile IPv6 needs to be capable of being deployed in situations
where alternative security mechanisms are already well- where alternative security mechanisms are already well-
understood by the network administration. It should be possible understood by the network administration. It should be possible
to enable Mobile IPv6 to work in situations where alternative to enable Mobile IPv6 to work in situations where alternative
security mechanisms already supply the necessary authentication security mechanisms already supply the necessary authentication
and privacy. and privacy.
(8) IPsec has been successfully applied to VPN and other (8) IPsec has been successfully applied to VPN and other
infrastructure operations, but less so for general end-to-end infrastructure operations, but not for general end-to-end
applications. Thus, the granularity for selectors was applications. Thus, the granularity for selectors was
originally not at all sufficient for Mobile IPv6. originally not at all sufficient for Mobile IPv6.
(9) The way that the IPsec code sits in the usual kernel, and the (9) The way that the IPsec code sits in the usual kernel, and the
access mechanisms for the SA database, are not very convenient access mechanisms for the SA database, are not very convenient
for use by straightforward implementations of Mobile IPv6. for use by straightforward implementations of Mobile IPv6.
Unusual calling sequences and parameter passing seems to be Unusual calling sequences and parameter passing seems to be
required on many platforms. required on many platforms.
(10) In certain environments the use of IPsec and IKEv2 for (10) In certain environments the use of IPsec and IKEv2 for
establishing the SA is considered as an overhead. Bandwidth establishing the SA is considered as an overhead. Bandwidth
constrained links such as cellular networks and air interfaces constrained links such as cellular networks and air interfaces
which are in the licensed spectrum tend to be optimized for user which are in the licensed spectrum tend to be optimized for user
traffic. MIP6 signaling with the IPsec overhead and the IKEv2 traffic. MIP6 signaling with the IPsec overhead and the IKEv2
messages are viewed negatively. It is more acceptable to have messages are viewed negatively. It is more acceptable to have
signaling without IPsec encapsulation. signaling without IPsec encapsulation.
The issues listed above can be attributed as some of the causes for The issues listed above can be speculatively attributed as some of
MIP6 not being implemented widely. the causes for MIP6 not being implemented widely.
6. Implementation Issues with IPsec 6. Implementation Issues with IPsec
6.1. Triggering IKEv2 on the MN 6.1. Triggering IKEv2 on the MN
When the MIP6 application is invoked on the MN, as part of the When the MIP6 application is invoked on the MN, as part of the
initialization steps it is expected to install the appropriate SPD initialization steps it is expected to install the appropriate SPD
entries for protecting the mobility management signaling. Creation entries for protecting the mobility management signaling. Creation
of the SPD entry works fine assuming that the MN is statically of the SPD entry works fine assuming that the MN is statically
preconfigured with the HoA information since the HoA address is preconfigured with the HoA information since the HoA address is
skipping to change at page 10, line 47 skipping to change at page 11, line 8
this case neither the key management daemon nor the MIP6 application this case neither the key management daemon nor the MIP6 application
on the HA are aware of the MN's autoconfigured HoA so neither of them on the HA are aware of the MN's autoconfigured HoA so neither of them
is in a position to install an appropriate SPD entry during (or is in a position to install an appropriate SPD entry during (or
immediately after) the IKEv2 exchange. Even worse, since the immediately after) the IKEv2 exchange. Even worse, since the
autoconfigured MN address is not known on the HA side it is not clear autoconfigured MN address is not known on the HA side it is not clear
what is the contents of the TSi and TSr payloads in the final what is the contents of the TSi and TSr payloads in the final
IKE_AUTH message sent by the HA. It is unclear whether or not the SA IKE_AUTH message sent by the HA. It is unclear whether or not the SA
for protecting the MN's mobility signaling gets established at all in for protecting the MN's mobility signaling gets established at all in
such a situation. such a situation.
TBD: verify whether this is really a problem...
6.8. The K bit 6.8. The K bit
The K bit [RFC3775] requires an interface between the IPsec subsystem The K bit [RFC3775] requires an interface between the IPsec subsystem
and the MIP6 application that is not available today, at least not in and the MIP6 application that is not available today, at least not in
a standardized form. Such an interface that would enable the support a standardized form. Such an interface that would enable the support
for the K bit has been proposed before and additional information how for the K bit has been proposed before and additional information how
it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate] it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate]
and [I-D.ebalard-mext-pfkey-enhanced-migrate]. However, those and [I-D.ebalard-mext-pfkey-enhanced-migrate]. However, those
proposals were not standardized and as such there is no publicly proposals were not standardized and as such there is no publicly
available interface specification that could be used by the third available interface specification that could be used by the third
skipping to change at page 13, line 5 skipping to change at page 13, line 7
adoption of MIP6 in general. adoption of MIP6 in general.
In order to make the Mobile IPv6 protocol a solution that is easy to In order to make the Mobile IPv6 protocol a solution that is easy to
implement and available in even low-end devices, it is necessary to implement and available in even low-end devices, it is necessary to
simplify the protocol. The design or the security architecture for simplify the protocol. The design or the security architecture for
MIP6 needs to be revisited and a solution that simplifies the MIP6 needs to be revisited and a solution that simplifies the
implementability of the protocol considered. The implementation implementability of the protocol considered. The implementation
experience shows that a working solution of Mobile IPv6 is possible experience shows that a working solution of Mobile IPv6 is possible
to build. However it is not easily done. to build. However it is not easily done.
The authors recommend that while Mobile IPv6 and Dual-stack Mobile
IPv6 implementations can indeed use IPsec and IKEv2 for the security,
it should also be possible to rely on an alternative security
framework. One such alternative security solution is proposed in
'Security architecture for Mobile IPv6 using TLS'
[I-D.korhonen-mext-mip6-altsec].
8. Security Considerations 8. Security Considerations
This I-D discusses the security architecture of Mobile IPv6 which is This I-D discusses the security architecture of Mobile IPv6 which is
based on IPsec. The dependency on IPsec for security of MIP6 based on IPsec. The dependency on IPsec for security of MIP6
signaling is a detriment to the protocol implementation and signaling is a detriment to the protocol implementation and
deployment. Hence the current security architecture needs to be deployment. Hence the current security architecture needs to be
reconsidered. reconsidered.
The experience gained over the last few years indicates that IPsec The experience gained over the last few years indicates that IPsec
cannot necessarily be used as a generic solution for security. The cannot necessarily be used as a generic solution for security. The
skipping to change at page 14, line 16 skipping to change at page 14, line 27
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
11.2. Informative References 11.2. Informative References
[I-D.ebalard-mext-pfkey-enhanced-migrate] [I-D.ebalard-mext-pfkey-enhanced-migrate]
Ebalard, A. and S. Decugis, "PF_KEY Extension as an Ebalard, A. and S. Decugis, "PF_KEY Extension as an
Interface between Mobile IPv6 and IPsec/IKE", Interface between Mobile IPv6 and IPsec/IKE",
draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in
progress), August 2008. progress), August 2008.
[I-D.korhonen-mext-mip6-altsec]
Korhonen, J., "Security architecture for Mobile IPv6 using
TLS", draft-korhonen-mext-mip6-altsec-02.txt (work in
progress), Ocober 2009.
[I-D.sugimoto-mip6-pfkey-migrate] [I-D.sugimoto-mip6-pfkey-migrate]
Sugimoto, S., Dupont, F., and M. Nakamura, "PF_KEY Sugimoto, S., Dupont, F., and M. Nakamura, "PF_KEY
Extension as an Interface between Mobile IPv6 and IPsec/ Extension as an Interface between Mobile IPv6 and IPsec/
IKE", draft-sugimoto-mip6-pfkey-migrate-04 (work in IKE", draft-sugimoto-mip6-pfkey-migrate-04 (work in
progress), December 2007. progress), December 2007.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
 End of changes. 24 change blocks. 
38 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/