Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00
arno@natisbad.org (Arnaud Ebalard) Mon, 27 October 2008 21:42 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: mext-archive@optimus.ietf.org
Delivered-To: ietfarch-mext-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2765828C146; Mon, 27 Oct 2008 14:42:17 -0700 (PDT)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1360828C16E for <mext@core3.amsl.com>; Mon, 27 Oct 2008 14:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.69
X-Spam-Level:
X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[AWL=3.289, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lET8alfHnwc for <mext@core3.amsl.com>; Mon, 27 Oct 2008 14:42:14 -0700 (PDT)
Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 28AB13A6943 for <mext@ietf.org>; Mon, 27 Oct 2008 14:42:14 -0700 (PDT)
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <arno@natisbad.org>) id 1KuZqM-0000gO-H0; Mon, 27 Oct 2008 22:41:47 +0100
From: arno@natisbad.org
To: Basavaraj Patil <basavaraj.patil@nokia.com>
References: <C52B6435.1C272%basavaraj.patil@nokia.com>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
X-Hashcash: 1:20:081027:mext@ietf.org::91teDr/04/Pe57PK:00004uAu
X-Hashcash: 1:20:081027:basavaraj.patil@nokia.com::riCZ3KyQHmhCjCHH:0000000000000000000000000000000000005Z+V
Date: Mon, 27 Oct 2008 22:40:03 +0100
In-Reply-To: <C52B6435.1C272%basavaraj.patil@nokia.com> (Basavaraj Patil's message of "Mon, 27 Oct 2008 12:27:33 -0500")
Message-ID: <87iqrdvhsc.fsf@natisbad.org>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Cc: "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hi, Comments inline below. I am certainly biased on the topic but I try to keep my comments below objective. Don't take the ones with smileys too seriously. > Abstract > > Mobile IPv6 as specified in RFC3775 relies on IPsec for security. 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 recommends > revisiting this decision At least, this will not fit in the scope of 3775bis ;-) > in view of the experience gained from implementation That is fair! > and adoption in other standards bodies. Is that fair? > 2. 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 ^^^ another > IPsec SA but is not required. > > 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 > discussions 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. > > This document discusses the issues and concerns with the use of IPsec > for MIP6 security and proposes revisiting the security design for > MIP6 protocol. > > 3. Terminology > > This document refers to [RFC3775][RFC4877] for terminology. > > 4. 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 was also intended to be a default component of the IPv6 stack > and was the preferred protocol choice for use by any other IPv6 > protocols that needed security. Rather than design security into > every protocol feature the intent was to reuse a well-defined > security protocol to meet security needs. Hence Mobile IPv6 has been > designed with a direct dependency on 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 ^^^^^^^^^ IMHO, it is not complete. > Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] > is considered as the default security protocol solution for MIP6 and > updates [RFC3776]. > > 5. Problem Statement > > Mobile IPv6 is encumbered by its reliance on IPsec 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 [DSMIP6]. The problem of IPsec and DSMIPv6 is NAT, which is an IPv4 issue. > IPsec SAs between the MN and HA are established either manually or by > the use of IKEv2. 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. yes. > The problem in summary for MIP6 is the dependence on IPsec and IKEv2 > for operation. You see it as a problem instead of seeing it as a *global* *solution* for IPv6 security. IPsec is usable and used on IPv6 networks. > 6. Issues with the use of IPsec > > This section captures several issues with the use of IPsec by MIP6. > > (1) The design of Mobile IPv6 emphasized on 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. As you say, it is true in many host implementation today; including many mobile devices. It seems you want to remove IPsec/IKEv2 from IPv6 devices, use a different solution for protecting MIPv6 signaling. Let's say you have managed to do that: any solution for data protection? any solution for protecting common IPv6 traffic to/from those nodes? Specific solutions too? > 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. The security associated with MIP4 > signaling is integrated into the protocol itself. MIP4 has been > successfully deployed on large scale in several networks. No sarcasm at all: large scale public or *private* network? Can you give examples? Another note: I don't know any administrator that can give the udp port number for MIP4. They all know IPsec and may even be able to give protocol numbers for AH and ESP. > (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. That's not true. See draft-ebalard-mext-pfkey-enhanced-migrate-00. This is the only need from an interface perspective between IPsec/IKE and MIPv6. There are public implementations available: - Linux 2.6.28 will be fully compliant with the feature - Patches for racoon have recently been posted. They are currently being reviewed. - patches for Linux MIPv6 implementation maintained by USAGI people are available. The only problem is the lack of traction in mext and the lack of coordination with IPsec WG. > 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 done because of reasons such as enterprise > environments preventing changing to IPsec policies or other. I do not fully understand the argument. > (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 of mobile > nodes which could number 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. IPsec is efficient. What would you propose as an equivalent solution (security wise) that would be more scalable than IPsec? > (4) The implementation complexity of Mobile IPv6 is greatly > increased because of the interaction with IPsec and IKEv2. This is just false. Please, just take a look at previous draft. Look at the additional amount of code added in Linux kernel to support the feature, for instance. > A > standalone MIP6 protocol is easier to implement and deploy (such > as MIP4 [RFC3344]). The complexity of the protocol > implementation is even more so in the case of [DSMIP6]. Are you trying to remove IPsec/IKE of the picture with the hope that DSMIPv6 issues will also disappear? > (5) IPsec and IKEv2 is not implemented in every IPv6 or dual stack > host. Not in all, but most stacks. > 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. MIP6 without any dependencies > on protocols for security is easier to implement and has wider > applicability. The idea of having every specific protocol specify its own security mechanism is just the worst idea ever: interoperability issues, more flaws, more code, ... > (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. Can you be more specific and give some example? > (8) IPsec has been successfully applied to VPN and other > infrastructure operations, but less so for general end-to-end > applications. Thus, the granularity for selectors was > originally not at all sufficient for Mobile IPv6. That issue was solved. I don't see the point. > (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. True. > (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. I must be missing something. Are you removing the security or are you considering another mechanism when doing such a comparsion? The former does not make sense, in the case of the latter, which one? > The issues listed above have been a cause for MIP6 not being > implemented widely or adopted by other SDOs which are considering IP > mobility solutions. Which ones? What did they choose? What provides security for the mobile solution's traffic? What provides data security? > 7. MIP6 evolution > > 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. True. RO would look better with IPsec ;-) > The design or the security architecture for MIP6 needs to be > revisited and a solution that does not rely on other components > developed. MIPv6v2 ? ;-) At least, with the generic notification, this will be easier to distinguish. > 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 security architecture needs to be revisited. > > 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. What is hampering the implementation and use is the lack of IPv6 deployment and the decision of the WG not to complete IPsec/IKE integration and spend time on additional *features*. At the end, security work is not complete and you have many features that are now in the way. This is not an argument but it is worth mentioning: at some point, MS had a (experimental) MIPv6 implementation on their OS. This has been removed from latest versions of the OS while the IPv6 stack was promoted. From a discussion with a developer of the stack, *one* of the reason was that security work was not over. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- [MEXT] FW: New Version Notification for draft-pat… Basavaraj Patil
- Re: [MEXT] FW: New Version Notification for draft… Behcet Sarikaya
- Re: [MEXT] FW: New Version Notification for draft… Arnaud Ebalard
- Re: [MEXT] FW: New Version Notification for draft… Basavaraj Patil
- Re: [MEXT] FW: New Version Notification fordraft-… Davis, Terry L
- Re: [MEXT] FW: New Version Notification fordraft-… Hannes Tschofenig
- Re: [MEXT] FW: New Version Notification fordraft-… Hannes Tschofenig
- Re: [MEXT] FW: New Version Notification for draft… Frank Xia
- Re: [MEXT] FW: New Version Notification for draft… Basavaraj Patil
- Re: [MEXT] FW: New Version Notification for draft… Arnaud Ebalard
- Re: [MEXT] FW: New Version Notification for draft… Ryuji Wakikawa
- Re: [MEXT] FW: New Version Notification for draft… Arnaud Ebalard
- Re: [MEXT] FW: New Version Notification for draft… Ryuji Wakikawa
- Re: [MEXT] FW: New Version Notification for draft… Arnaud Ebalard