One document matched: draft-patil-mext-mip6issueswithipsec-02.txt
Differences from draft-patil-mext-mip6issueswithipsec-01.txt
Mobility Extensions (MEXT) B. Patil
Internet-Draft Nokia
Intended status: Standards Track D. Premec
Expires: April 29, 2010 Unaffiliated
C. Perkins
WiChorus
H. Tschofenig
Nokia Siemens Networks
October 26, 2009
Problems with the use of IPsec as the security protocol for Mobile IPv6
draft-patil-mext-mip6issueswithipsec-02
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 April 29, 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.
Patil, et al. Expires April 29, 2010 [Page 1]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
Abstract
Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the
signaling messages and user plane traffic between the mobile node and
home agent. An IPsec SA between the mobile node and the home agent
provides security for the mobility signaling. Use of IPsec for
securing the data traffic between the mobile node and home agent is
optional. This document analyses the implications of the design
decision to mandate IPsec as the default security protocol for Mobile
IPv6 and consequently Dual-stack Mobile IPv6 and recommends
revisiting this decision in view of the experience gained from
implementation and adoption in other standards bodies.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. General issues with the use of IPsec for MIP6 security . . . . 6
6. Implementation Issues with IPsec . . . . . . . . . . . . . . . 8
6.1. Triggering IKEv2 on the MN . . . . . . . . . . . . . . . . 8
6.2. Instructing IKEv2 to ask for the MN HoA/prefix . . . . . . 9
6.3. Providing the MN prefix to the IKEv2 daemon . . . . . . . 9
6.4. Registering the MN's FQDN in DNS . . . . . . . . . . . . . 9
6.5. Providing the Home Network Prefix to the MIP6
application . . . . . . . . . . . . . . . . . . . . . . . 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.8. The K bit . . . . . . . . . . . . . . . . . . . . . . . . 11
6.9. UDP encapsulation of DSMIP6 signaling . . . . . . . . . . 11
6.10. Transport mode IPsec SAs and NATs . . . . . . . . . . . . 12
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Patil, et al. Expires April 29, 2010 [Page 2]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
1. Introduction
Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec
security association between the mobile node (MN) and home agent
(HA). The IPsec SA protects the mobility signaling messages between
the MN and HA. The user data may be optionally protected by the
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
in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6
working groups in the IETF chose to mandate IPsec as the default
security protocol for Mobile IPv6 based on various criteria and
lengthy discussions that occured between the years 2000 and 2004.
Implementation experience with Mobile IPv6 and the security variants
with which it has been specified in some SDOs indicates a need to
revisit the design choice for MIP6 signaling security. The analysis
and recommendation to revisit the security protocol architecture for
MIP6 should not be interpreted as a recommendation for Authentication
Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight
the misfit of IPsec and IKEv2 as the security protocol for MIP6 and
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
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].
This document refers to [RFC3775][RFC4877] for terminology.
3. Background
IP mobility support in IPv6 was considered to be an integral feature
of the IPv6 stack based on the experience gained from developing
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
publication as [RFC3775] in 2004.
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 protocol that needed security. Rather than design security into
Patil, et al. Expires April 29, 2010 [Page 3]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
every protocol feature, the intent was to reuse a well-defined
security protocol to meet the security needs. Hence Mobile IPv6 has
been designed with a security architecture that relies on reusing
IPsec.
The Mobile IPv6 specification [RFC3775] was published along with the
companion specification "Using IPsec to Protect Mobile IPv6 Signaling
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
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
complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG
completed the specification, Mobile IPv6 Operation with IKEv2 and the
Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877]
is considered as the default security protocol solution for MIP6 and
updates [RFC3776].
4. Problem Statement
Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an
implementation and deployment perspective. As a protocol solution
for host based mobility, MIP6 can be simpler without the IPsec
baggage. The issues with IPsec are even more exacerbated in the case
of dual-stack MIP6 [RFC5555].
IPsec SAs between the MN and HA are established either manually or
via the use of IKEv2 [RFC4306]. Manual SA configuration is not a
scalable solution and hence MIP6 hosts and Home agents rely on IKEv2
for establishing dynamically IPsec SAs. As a result MIP6 depends on
the existence of IPsec and IKEv2 for successful operation.
IPsec is unable to provide security protection for MIP6 in a
transparent way, and numerous interactions between the host's
security subsystems and the MIP6 application are needed in the course
of the regular operation of the MIP6 application. Besides requiring
an extensive communications channel between the security subsystems
and the MIP6 application, those interactions often also require
modification of the MNs security subsystems code. The situation
today is such that the communications channel between the IPsec
subsystems and the MIP6 application is non existent and this is
generally true for most of the commercially available platforms.
Even if such a channel were to be available, there does not exist a
standardized protocol over that channel which would enable the MIP6
application to communicate with the security modules in a non-
implementation specific way.
Considering a third party application developer who would like to
Patil, et al. Expires April 29, 2010 [Page 4]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
provide a MIP6 application for a particular platform, the need for
numerous interactions with the IPsec subsystem and the unavailability
of the standardized communications channel through which such
interactions could take place is a major obstacle to the
implementation of the mobility protocol. Without such a
communication channel being available it is not possible to implement
a MIP6 application as a third party developer.
Even if the platform would provide such a communication interface for
the MIP6 daemon, this is still insufficient as the MIP6 protocol
standardized today [RFC3775] requires numerous changes to the host's
IPsec and IKEv2 implementation. This document enumerates various
implementation issues related to the interactions between the MIP6
application and the host's security subsystems.
An argument can be made that the MIP6 application itself should
provide the required changes to the IPsec subsystems of the platform
(maybe in the form of patches). While this is possible at least for
some open source platforms to provide modifications to the host's
IPsec implementation as well as the key management application(s),
this is still an issue for several reasons:
o Target platform could be a commercial platform for which no source
code for the security modules (IPsec and IKEv2) is available.
o If the MIP6 application were to patch the IPsec subsystems, then
multiple MIP6 applications from different developers would
implement it in different ways, which would inevitably lead to
variations and problems with interoperability at a minimum, for
instance when the user tries to install several MIP6 applications
it is difficult to determine which one is the best suited for his/
her needs.
o Key management daemons are usually provided as third party
software for which no source code may be available, even if the
platform itself is available as open source.
o Even if the MIP6 application developer would be willing to provide
patches for the key management daemon to make it work with his
MIP6 application, how would the MIP6 application developer know
which of the several available key management daemons the user is
running?
o Each application would be able to work only with a single key
management daemon, namely the one for which the MIP6 application
provides the patches. The user may be running another key
management daemon and may be unwilling to change its daemon to the
one that comes as part of the MIP6 application.
o Patches for the IPsec part in the kernel and the key management
daemon would typically be valid only for the particular version of
the kernel and the key management daemon for which they were
written. This might prevent the user from upgrading the platform
Patil, et al. Expires April 29, 2010 [Page 5]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
or applying OS security patches that are provided as part of the
regular platform maintenance since this would in all probability
make the MIP6 application defunct.
o Modifying the security subsystems by a third party is a security
issue and users are generally advised to refrain from allowing the
security subsystems to be modified in any way.
o The developer may not have the knowledge or the time to modify the
platform's IKEv2 and IPsec subsystems, although it might be
perfectly capable to deliver the MIP6 application itself.
o There could be copyright issues as well that would prevent
modifications of the platform's security subsystems or the
delivery of the modifications by the third party.
o Even if the MIP6 application developer is able to come up with the
necessary patches for the security subsystem, it is not realistic
to expect the prospective user of MIPv6 to first patch the kernel
and the key management daemons before using the MIPv6 service.
The above discussion shows why it is unrealistic to expect that the
MIP6 application could provide the needed modifications to the IKEv2
and IPsec subsystems of the host. Section 6 presents a more
technical discussion of various implementation issues related to the
interworking between the MIP6 application and the IPsec/key
management modules.
The problem in a nutshell for MIP6 is the dependence on IPsec and
IKEv2 for successful operation.
5. General issues with the use of IPsec for MIP6 security
This section captures several issues with the use of IPsec by MIP6.
(1) The design of Mobile IPv6 emphasized the reuse of IPv6 features
such as IPsec. IPsec for IPv4 was a bolt-on solution. With the
increasing need for security, IPv6 designers chose to
incorporate IPsec as a default feature. There existed an
assumption in the MIP6 working group that every IPv6 host would
have IPsec capability as a standard feature. While this is true
in many host implementations today, the existence of IPsec in
every IPv6 stack is not a given. Hence a host which needs to
implement Mobile IPv6 must ensure that IPsec and IKEv2 are also
available. As a result of this dependence, MIP6 is no longer a
standalone host-based mobility protocol. A good example of a
host based mobility protocol that works as a self-sufficient
module is Mobile IPv4 [RFC3344]. The security associated with
MIP4 signaling is integrated into the protocol itself. MIP4 has
been successfully deployed on a large scale in several networks.
Patil, et al. Expires April 29, 2010 [Page 6]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
(2) IPsec use in most hosts is generally for the purpose of VPN
connectivity to enterprises. It has not evolved into a generic
security protocol that can be used by Mobile IPv6 easily. While
RFC4877 does specify the details which enable only the MIP6
signaling to be encapsulated with IPsec, the general method of
IPsec usage has been such that all traffic between a host and
the IPsec gateway is carried via the tunnel. Selective
application of IPsec to protocols is not the norm. Use of IPsec
with Mobile IPv6 requires configuration which in many cases is
not easily achievable because of reasons such as enterprise
environments preventing changes to IPsec policies.
(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
mobile nodes which could be in the hundreds of thousands to
millions. The ability to terminate a large number of IPsec SAs
(millions) requires signifiant hardware and platform capability.
The cost issues of such an HA are detrimental and hence act as a
barrier to deployment.
(4) The implementation complexity of Mobile IPv6 is greatly
increased because of the interaction with IKEv2. The complexity
of the protocol implementation is even more so in the case of
Dual stack MIP6 [RFC5555] wherein NAT traversal scenarios are
considered.
(5) IPsec and IKEv2 are not implemented or available by default in
every IPv6 or dual stack host. Mobile IPv6 support on such
devices is not an option. Many low-end cellular hosts have IP
stacks. The need for IPsec and IKEv2 in these devices is not
important whereas mobility support is needed in many cases. A
simpler security protocol than the use of IPsec/IKEv2 would make
MIP6 much more attractive to implement and deploy.
(6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile
IPv6 essentially results in a variant of IPsec which is specific
to Mobile IP. Hence this results in added complexity to
implementations.
(7) Mobile IPv6 needs to be capable of being deployed in situations
where alternative security mechanisms are already well-
understood by the network administration. It should be possible
to enable Mobile IPv6 to work in situations where alternative
security mechanisms already supply the necessary authentication
and privacy.
(8) IPsec has been successfully applied to VPN and other
infrastructure operations, but not for general end-to-end
applications. Thus, the granularity for selectors was
originally not at all sufficient for Mobile IPv6.
Patil, et al. Expires April 29, 2010 [Page 7]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
(9) The way that the IPsec code sits in the usual kernel, and the
access mechanisms for the SA database, are not very convenient
for use by straightforward implementations of Mobile IPv6.
Unusual calling sequences and parameter passing seems to be
required on many platforms.
(10) In certain environments the use of IPsec and IKEv2 for
establishing the SA is considered as an overhead. Bandwidth
constrained links such as cellular networks and air interfaces
which are in the licensed spectrum tend to be optimized for user
traffic. MIP6 signaling with the IPsec overhead and the IKEv2
messages are viewed negatively. It is more acceptable to have
signaling without IPsec encapsulation.
The issues listed above can be speculatively attributed as some of
the causes for MIP6 not being implemented widely.
6. Implementation Issues with IPsec
6.1. Triggering IKEv2 on the MN
When the MIP6 application is invoked on the MN, as part of the
initialization steps it is expected to install the appropriate SPD
entries for protecting the mobility management signaling. Creation
of the SPD entry works fine assuming that the MN is statically
preconfigured with the HoA information since the HoA address is
needed to create the SPD entries. Once the SPD entries are created,
the MIP6 application generates the BU message and sends it via the
socket. Based on the previously installed SPD entry the IP stack
detects that the BU message needs IPsec protection and since there is
no appropriate IPsec SA available, the OS kernel triggers the key
management daemon to establish the needed IPsec SA.
Things are not that straightforward when the HoA is assigned
dynamically. MIP6 allows the MN to obtain the HoA dynamically during
the establishment of the initial IPsec SA with the HA [RFC4877] and
in this case the HoA is provided in the CONF IKEv2 payload. How is
the key management daemon triggered to establish the IPsec SA with
the HA in this case? Normally there should be an SPD entry in the
SPD with the HoA address as part of the selector and the outgoing BU
message would be matched against that entry and this would trigger
the kernel to request the establishment of the IPsec SA. But the
MIP6 application is not able to install the appropriate SPD entry nor
to generate the BU message since it doesn't have yet the HoA that is
needed for this, the HoA becomes available only later as part of the
IPsec SA establishment. So this is sort of a chicken and egg
problem: the HoA is needed to trigger the establishment of the IPsec
SAs, but the HoA is not available prior to the IPsec SA being
Patil, et al. Expires April 29, 2010 [Page 8]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
established.
The solution to this issue could be an out-of-band communication
channel between the MIP6 application and the key management daemon
through which the MIP6 application could request the establishment of
the appropriate IPsec SA from the key management daemon without
having to install the appropriate SPD entries and generate the BU
message.
6.2. Instructing IKEv2 to ask for the MN HoA/prefix
In case of dynamic HoA assignment, the MIP6 application needs to
instruct the key management daemon to request the HoA information
from the HA. The MIP6 application must be able to tell whether it
would like to get the complete address or only the prefix [RFC5026]
from the HA, and also whether it would like to get the IPv4 HoA as
part of the IKEv2 exchange. This requires an interface between the
MIP6 application and the key management daemon.
6.3. Providing the MN prefix to the IKEv2 daemon
When the key management daemon on the HA side receives a request from
the initiator to allocate the MIP6_HOME_PREFIX it needs to get the
prefix from the MIP6 daemon running on the HA. Therefore there must
be a communication channel between the key management daemon and the
MIP6 application through which the key management daemon could
request the HoA/prefix information. Further, when assigning the
prefix, the MIP6 application needs to create state and save the
assigned address information and associate it with the MN which
created the IPsec SA. So this looks like at this point there is a
need to create the BCE in a some type of a "larval" state as a place
where to save this information on the HA side.
Request to assign an address (IPv6 and/or IPv4) via the CONF payload
raises an additional concern, namely, how does the key management
daemon know that it needs to obtain the address from the MIP6
application? A generic key management daemon would by default have
some other means to provide the addresses in the CONF payload without
consulting the MIP6 application, so there must be some method to tell
the key management daemon that it should request the addresses from
the MIP6 application. The author is not aware of any such method
being available currently.
6.4. Registering the MN's FQDN in DNS
[RFC4877] allows the HA to register the MN's FQDN in the DNS. In
this case the MN must provide the FQDN in the IDi payload in the
IKE_AUTH step of the IKEv2 exchange. Consequently, there must be
Patil, et al. Expires April 29, 2010 [Page 9]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
some interface between the key management daemon and the MIP6
application on the HA side through which the FQDN could be made
available to the MIP6 application so that it can register the FQDN in
DNS.
6.5. Providing the Home Network Prefix to the MIP6 application
When the key management daemon on the MN side obtains the home
network prefix information from the HA, it needs to relay this
information to the MIP6 application. This again requires a
communication channel between the key management daemon and the MIP6
application.
6.6. SPD Entry for the HoA on the MN side
Once the MIP6 application on the MN obtains the HoA (either assigned
via the CONF IKEv2 payload [RFC4877] or autoconfigured from the
MIP6_HOME_PREFIX [RFC5026]), the appropriate SPD entries need to be
created in the SPD. Some key management daemons may require that
they have full control of the SPD. In such cases the MIP6
application should not create the SPD entries by itself as this might
confuse the MIP6 daemon and cause inconsistent state. Instead, the
MIP6 application would need to instruct the key management daemon to
create the appropriate SPD entries. So depending on the expectations
of the key management daemon, the MIP6 application should either
instruct the key management daemon to create the SPD entries or the
MIP6 application should create them by itself at this point.
If the policy requires protection of the data traffic the SPD entries
for the data traffic would also need to be created at this point.
6.7. SPD Entry for the HoA on the HA side
The creation of the SPD entry on the HA side for protecting the MN's
mobility signaling is similar to what is happening on the MN side and
is described in the previous section. As soon as the HA assigns an
HoA it may proceed with the creation of the appropriate SPD entry.
The SPD entries for protecting the data traffic should also be
created at this time.
However, the issue gets more complicated in the case where the HA
provides the prefix to the MN and the MN autoconfigures the HoA. In
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
is in a position to install an appropriate SPD entry during (or
immediately after) the IKEv2 exchange. Even worse, since the
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
Patil, et al. Expires April 29, 2010 [Page 10]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
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
such a situation.
6.8. The K bit
The K bit [RFC3775] requires an interface between the IPsec subsystem
and the MIP6 application that is not available today, at least not in
a standardized form. Such an interface that would enable the support
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]
and [I-D.ebalard-mext-pfkey-enhanced-migrate]. However, those
proposals were not standardized and as such there is no publicly
available interface specification that could be used by the third
party MIP6 application developers to invoke the key management daemon
and IPsec kernel. Note also that the MIP6 application must have a
detailed knowledge about the established IPsec SAs (complete SPD
entries, old and new tunnel end points) in order to be able to
indicate to the key management daemon which SAs needs to be updated,
which is not in the spirit of the original IPsec intention to provide
security to the applications in a transparent manner.
6.9. UDP encapsulation of DSMIP6 signaling
The DSMIP6 specification enables the MIP6 enabled MN to roam in IPv4
networks [RFC5555]. To cope with NATs the DSMIP6 specification
introduces a UDP encapsulation feature for the MIP6 signaling
messages as well as for the data traffic. The UDP encapsulation
feature requires very tight coupling between the IPsec subsystems and
the MIP6 application.
To send the BU message the MIP6 daemon first needs to generate the BU
message and then hand it over to the IPsec subsystem which adds the
transport mode ESP protection. Then in the next step the message
must go back from the kernel to the MIP6 daemon in the user space
which adds DSMIP6 UDP encapsulation and then the packet is finally
sent out on the interface.
When the UDP encapsulated Binding Acknowledgment message is received
on the MN side, it is first delivered to the MIP6 application which
strips the UDP header and then somehow hands over the stripped
message to the kernel's IPsec subsystem. The IPsec subsystems takes
care of the transport mode ESP protecting the BU message and after
removing the ESP header delivers the BU message back to the MIP6
application.
Patil, et al. Expires April 29, 2010 [Page 11]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
6.10. Transport mode IPsec SAs and NATs
In order to establish an IPsec SA in the case of DSMIP6 when the MN
is behind a NAT, it is required to use transport mode SAs only.
Implementation experience at least has shown that it is not easily
done and the operation itself of establishing the IPsec SA is flaky
at best.
7. Conclusion
Examples in Section 6 show that there is a need for an extensive
communication between the MIP6 application and the IPsec subsystem on
the host. Standardizing such communication channel and having it
available in a commercial OS implementations is not a realistic
proposal in any practical time frame. On the technical side, this is
due to the fact that the IPsec is usually provided as part of the OS
kernel and it is always difficult to convince the OS vendor to change
the kernel and in particular the security related subsystems. The
other difficulty is that the key management is usually provided as
the user space service and as such there are multiple key management
daemons available. Convincing vendors of various key management
daemons to provide a unified or standardized communication channel
for the MIP6 application might prove equally difficult and is not a
realistic option either. Besides the technical reasons, there are
also other non-technical reasons of business or political nature why
such proposals would be unrealistic.
Therefore this draft recommends that an alternate security framework
be considered for MIP6. This alternate mechanism should be self
contained so that it can be developed and delivered as part of the
MIP6 application itself (from an implementation perspective analogous
to the way web browsers handle security today). This would enable
third party developers that have no access or are otherwise not in a
position to change the IPsec code of the platform they are developing
for to come up with a self contained and working MIP6 application.
Such alternative security mechanisms would remove one of the major
impediments, i.e the interactions with IPsec - why it is so difficult
today to implement a working MIP6 application. This would foster the
diversity of the MIP6 solutions and should therefore have beneficial
effects on the availability of MIP6 solutions and promote the
adoption of MIP6 in general.
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
simplify the protocol. The design or the security architecture for
MIP6 needs to be revisited and a solution that simplifies the
implementability of the protocol considered. The implementation
Patil, et al. Expires April 29, 2010 [Page 12]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
experience shows that a working solution of Mobile IPv6 is possible
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
This I-D discusses the security architecture of Mobile IPv6 which is
based on IPsec. The dependency on IPsec for security of MIP6
signaling is a detriment to the protocol implementation and
deployment. Hence the current security architecture needs to be
reconsidered.
The experience gained over the last few years indicates that IPsec
cannot necessarily be used as a generic solution for security. The
design choice made for MIP6 in the initial stages no longer are valid
and is hampering the implementation and use.
9. IANA Considerations
This document does not have any information which requires IANA
review.
10. Acknowledgements
Jouni Korhonen would like to point out the importance of sustained
supply of caffeine rich coffee when doing IETF work. Authors would
also like to recognize Satyabrata Sahu, NK Garg, Sandeep Minocha and
Harsh Verma for working on the implementation.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Patil, et al. Expires April 29, 2010 [Page 13]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
11.2. Informative References
[I-D.ebalard-mext-pfkey-enhanced-migrate]
Ebalard, A. and S. Decugis, "PF_KEY Extension as an
Interface between Mobile IPv6 and IPsec/IKE",
draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in
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]
Sugimoto, S., Dupont, F., and M. Nakamura, "PF_KEY
Extension as an Interface between Mobile IPv6 and IPsec/
IKE", draft-sugimoto-mip6-pfkey-migrate-04 (work in
progress), December 2007.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Patil, et al. Expires April 29, 2010 [Page 14]
Internet-Draft IPsec issues with Mobile IPv6 October 2009
Authors' Addresses
Basavaraj Patil
Nokia
6021 Connection Drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Domagoj Premec
Unaffiliated
Heinzelova 70a
Zagreb, 10000
CROATIA
Phone:
Fax:
Email: domagoj.premec.ext@gmail.com
Charles Perkins
WiChorus
3590 N. 1st Street, Suite 300
San Jose, CA 95134
USA
Email: charliep@wichorus.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Patil, et al. Expires April 29, 2010 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 05:59:59 |