Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt
arno@natisbad.org (Arnaud Ebalard) Mon, 03 November 2008 20:22 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A783428C0FC; Mon, 3 Nov 2008 12:22:54 -0800 (PST)
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 D1AFD3A6A7D for <mext@core3.amsl.com>; Mon, 3 Nov 2008 12:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.955
X-Spam-Level:
X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=1.645, 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 SUN7UmqTjv7Z for <mext@core3.amsl.com>; Mon, 3 Nov 2008 12:22:50 -0800 (PST)
Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 3BF8B3A69C3 for <mext@ietf.org>; Mon, 3 Nov 2008 12:22:50 -0800 (PST)
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 1Kx5wg-00011Q-IW for mext@ietf.org; Mon, 03 Nov 2008 21:22:43 +0100
X-Hashcash: 1:20:081103:mext@ietf.org::y0/fZ5dNBmO9lRDD:0000DG8i
From: arno@natisbad.org
To: mext@ietf.org
References: <20081102223002.210293A69EB@core3.amsl.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:081103:internet-drafts@ietf.org::Xg1jOutlpwvV/Eq+:00000000000000000000000000000000000004fWt
X-Hashcash: 1:20:081103:i-d-announce@ietf.org::Wip9l8G8B8JRuDnG:0000000000000000000000000000000000000000ETnD
X-Hashcash: 1:20:081103:mip6@ietf.org::EjS7roLdI5yEeL5t:0000GUZE
Date: Mon, 03 Nov 2008 21:20:57 +0100
In-Reply-To: <20081102223002.210293A69EB@core3.amsl.com> (Internet-Drafts@ietf.org's message of "Sun, 2 Nov 2008 14:30:02 -0800 (PST)")
Message-ID: <87iqr4ims6.fsf@natisbad.org>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Subject: Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt
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, Some typos, while reading the document. Some questions too. Internet-Drafts@ietf.org writes: > 2. Introduction > > Mobile IPv6 relies on the IPsec Security Association between the > Mobile Node (MN) and the Home Agent (HA) for authentication of the MN > to its HA before a binding cache can be created at the HA. An > alternate mechanism that does not rely on the existence of the IPsec > SA between the MN and HA for authenticating the MN is needed in > certain deployment environments. This document captures the reasons > that were outlined, and explains why such a mechanism was considered > essential to ensure the applicability of MIP6 as a protocol for wider > deployment. It was noted that the alternate solution does not imply > that the IPsec based solution would be deprecated. It simply meant > that in certain deployment scenarios there was a need for supporting > MIP6 without an IPsec SA between the MN and HA. So the alternate > solution would be in addition to the IPsec based mechanism specified > in the base RFCs, RFC 3775 [RFC3775], RFC 3776 [RFC3776] and RFC 4877 > [RFC4877]. It was noted that some of the challenges of deploying > MIP6 in certain types of networks arose from the dependence on IKE > which did not integrate will with a AAA backend infrastructure. ^^^^ well > [snip] > > 3. Background > > Mobile IPv6 signaling involves several messages. These include: > > o The Binding update/Binding ACK between the mobile node and the Binding Update/Binding Ack > home agent. > > o The route optimization signaling messages which include HoTI/Hot, HoT ^^^ > [snip] > > 4. Applicability Statement > > The authentication option specified in the Authentication Protocol > for MIP6 [RFC4285] provides a solution for MIP6 deployment in > environments which an operator may not require IPsec based security > for the signaling. The reasons for an operator choosing to deploy > MIP6 without mandating IPsec based security for signaling messages > between the MN and HA could be many. Some of these are for example: > > 1. Operators deploying MIP6 in cellular networks may consider IPsec > and IKEv2 as adding overhead to the limited bandwidth over the > air interface. The overhead here is in terms of the bytes that > IPsec and IKEv2 introduce to the signaling. > > 2. Operators may consider the number of messages between the MN and > HA that are required to establish the IPsec SA as too many. The > number of transactions chew into the capacity of limited > bandwidth air interfaces when MIP6 is used in such environments. > It also adds additional latency to the establishment of the > binding. > > 3. In many deployments the authentication credentials already exist > in a AAA server. These credentials are used for authenticating a > user and authorizing network access. The same credentials and > security parameters can be reused for MIP6 security as well. > > 4. Dynamic assignment of home agents is needed in certain > deployments to minmize the latency of the backhaul. This is done ^^^^^^^ minimize > by allocating an HA in a visited network for example. Requiring > IPsec SAs with home agents that are dynamically assigned is an > overhead especially when the HA is in a visited network. > > 5. Signaling messages between the MN and HA may be in certain > deployments over secure link-layers. The lower layers provide > ciphering and security for the messages and hence the need for > IPsec to do the same for MIP6 messages does not exist. > > One such example of networks that have such characteristics are cdma > networks as defined in the 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] > specification. Mobile WiMAX (Worldwide interoperability for > Microwave Access) which is based on IEEE 802.16e also specifies in > the network architecture the use of MIP6, with the default security > for signaling being the authentication protocol (RFC4285). The WiMAX > network architecture specifications are available at: [WiMAX-NWG]. The pointer provided in the reference section gives me a 404. As I am not familiar with the document, can you just tell me if/how a MN moving from a WiMAX link to another link (ethernet, wifi, ...) can protect its data traffic to deal with the fact that previous point 5 does not hold anymore. Or is it just not expected, and the MN is stuck in some kind of closed domain (w/ secure link layer)? > 5. Justification for the use of the authentication option > > The following two sections provide the reasoning for standardizing > the authentication option based registration process for Mobile IPv6. > Section 5.1 provides the key arguments for the use of authentication > option. Section 5.2 provides further explanation and additional > motivations for the authentication option. > > 5.1. Motivation for use of authentication option in cdma2000 wireless > networks > > cdma2000 networks deployed and operational today use Mobile IPv4 for > IP mobility. Operators have gained a significant amount of > operational experience in the process of deploying and operating > these networks. 3GPP2 has specified Mobile IPv6 in Revision D of the > 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] specification (which > specifies the packet data architecture). The following are the > deployment constraints that existing CDMA networks have to deal with > when deploying Mobility service based on IPv6: > > o Operators intend to leverage the Mobile IPv4 deployment and > operational experience by ensuring that Mobile IPv6 has a similar > deployment and operating model. > > o Operators will have two parallel networks, one that offers IPv4 > mobility with MIP4 and another providing IPv6 mobility using MIP6. > > o The same backend subscriber profile database, security keys etc. > are intended to be used for both Mobile IPv4 and, Mobile IPv6 > service. However from a security standpoint, the reuse of the > same keys with multiple algorithms/protocols is a bad idea. > > o The same user configuration information, i.e the identity and keys > associated with a user will be used for IP mobility service in > IPv4 and/or IPv6 networks. The only security association that is > preconfigured is a shared secret between the mobile node and the > home-AAA server. This was in contrast with an earlier version of > the Mobile IPv6 model which required an IPsec SA between the MN > and HA. At the time of this writing the IKEV2 based solution for ^^^^^ IKEv2 > establishing an IPsec SA [RFC4877] was not available. IKEv2 does > enable integration with a a AAA backend. ^^^^^ > > o At the time of specifying the authentication protocol, the Mobile > IPv6 specification did not support the dynamic assignment of home > agent and home address. However work done in the MIP6 working > group on bootstrapping of Mobile IPv6 as specified in [RFC5026] > and MIP6-bootstrapping for the Integrated Scenario > [I-D.ietf-mip6-bootstrapping-integrated-dhc] addresses this > > > > Patil & Dommety Expires May 6, 2009 [Page 7] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > deficiency. The mechanism defined in Authentication protocol for > Mobile IPv6 [RFC4285] is capable of handling authentication even > in the case of dynamic assignments (and is similar to what is used > in current MIPv4 deployments). > > Consequently, MIP6 as specified at the time the authentication > protocol was being specifid did not satisfy many of the deployment > requirements. The Authentication protocol for MIP6 [RFC4285] along > with the MN Identifier option for MIP6 [RFC4283] are enabling the > deployment of Mobile IPv6 in a manner that is similar to what is > deployed in cdma2000 networks today. This authentication model is > very similar to the one adopted by the MIPv4 WG. This is explained > in detail in the 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] > specification. > > The earlier MIP6 deployment model which requires an IPsec SA which is > either configured manually or established using IKE does not have > synergy with the deployment models of 3GPP2 or WiMAX networks. This > issue has however been alleviated with the publication of RFC4877 > which enables the establishment of an IPsec SA using IKEv2 and is > also able to integrate with the backend AAA infrastrucuture that is > responsible for the authentication of the MN in 3GPP2 and WiMAX > networks. > > 5.2. Additional arguments for the use of Authentication option > > The use of IPsec for performing Registration with a home agent is not > always an optimal solution. While it is true that IPsec is an > integral part of the IPv6 stack, it is still a considerable overhead > from a deployment perspective of using IPsec as the security > mechanism for the signaling messages between the MN and HA. This > statement is a result of experience gained from deployment of Mobile > IPv4. Was IPsec the issue or IPsec in NAT environments? Can you be more specific on that point? > MIP4 does not rely on IPsec for securing the Registration > signaling messages. > > Deployment of Mobile IPv6 on a large scale is possible only when the > protocol is flexible for being adapted to various scenarios. The > scenario being considered is the deployment in cdma2000 net- works or ^^^^^^^^^^ > WiMAX networks. cdma2000 networks are currently deployed in many > countries today and WiMAX deployments are beginning. The packet data > network architecture of cdma2000 [3GPP2 X.S0011-002-D] includes a > MIP4 foreign agent/Home agent and a Radius based AAA infrastrucutre > for authentication, authorization and accounting purposes. The AAA > infrastructure provides the authentication capability in the case of > Mobile IPv4. > > Typically, the Mobile Node shares a security association with the > AAA-Home entity. This is the preferred mode of operation over having > > > > Patil & Dommety Expires May 6, 2009 [Page 8] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > a shared secret between the MN and HA because the AAA-Home entity > provides a central location for provisioning and administering the > shared secrets for a large number of mobiles (millions). This mode > of operation also makes dynamic home address and dynamic home agent > assignment easier. A similar approach is needed for the deployment > of Mobile IPv6 in these networks. There is no practical mechanism to > use IPsec directly with the AAA infrastructure with out the use of ^^^^^^^^ > IKE or some other mechanism that enables the establishment of the > IPsec SA between the MN and HA. > > Mobile IPv6 as specified in RFC3775 and RFC3776 is based on a very refs, i.e. [RFC3775] > specific model for deployment. It anticipates the Mobile nodes > having a static home IPv6 address and a designated home agent. This > is not practical in most deployment scenarios being considered. An > IPsec SA is expected to be created, either via manual keying or > established dynamically by using IKE or IKEv2. These assumptions do > not necessarily fit in very well for the deployment model envisioned > in cdma2000 or WiMAX networks. These limitations have however been > overcome as a result of the bootstrapping specifications as per > [RFC5026] and MIP6-bootstrapping for the Integrated Scenario > [I-D.ietf-mip6-bootstrapping-integrated-dhc] > > cdma2000 and WiMAX networks would prefer to allocate home addresses > to MNs on a dynamic basis. The advantage of doing so is the fact > that the HA can be assigned on a link that is close to the MNs point > of attachment. While route-optimization negates the benefit of > having a home-agent on a link close to the MN, it cannot be always > guaranteed that the MN and CN will use or support route optimization. > There may also be instances where the operator prefers to not allow > route optimization for various reasons such as accounting aggregation > or enforcing service contracts. In such cases an HA that is close to > the MNs point of attachment reduces the issues of latency etc. of > forward and reverse tunnelling of packets between the MN and HA. > > cdma2000 networks that are operational today have large numbers of > subscribers who are authenticated via the AAA infrastrucure. > Deployment of Mobile IPv6 should leverage the existing AAA > infrastructure. The security model needed in these networks is an SA > between the MN and AAA-Home entity. This is the primary security > association that should be used for authenticating and authorizing > users to utilize MIPv6 service. This SA is then used for > establishing session keys between the MN and the dynamically assigned > HA for authenticating subsequent binding updates and binding > acknowledgements between them. Establishing an IPsec SA between the > MN and HA using AAA infrastrucure was not specified for Mobile IPv6 > at the time the Authentication protocol was being specified. RFC3776 > explains how IKE is used for establishing the SA between the MN and > HA. [RFC4877] has been published subsequently and hence the issue of > > > > Patil & Dommety Expires May 6, 2009 [Page 9] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > establishing an IPsec SA dynamically between the MN and HA no longer > exists. cdma2000 network operators would prefer to assign home > addresses to the MN on a dynamic basis and do this preferably using > the AAA infrastrucutre which contains subscriber profile and > capability information. This was not possible prior to the > specification of the bootstrapping mechanism in [RFC5026]. > > A large subset of MNs in cdma2000 networks do not have IKE > capability. As a result the use of RFC3776 for setting up the MN-HA > IPsec SA is not an option. It should also be noted that IKE requires > several transactions before it is able to establish the IPsec SA. > [RFC4877] specifies the establishment of an IPsec SA between the MN > and HA using IKEv2. It is possible that not all MNs in a deployment > will support IKEv2 and hence an alternative mechanism provides the > needed flexibility. > > cdma2000 network operators are extremely conscious in terms of the > number of messages sent and received over the air-interface for > signaling. The overhead associated with sending/receiving a large > number of signaling messages over the air interface has a direct > impact on the overall capacity and cost for the operator. > Optimization of the number of messages needed for using a service > like Mobile IPv6 is of great concern. As a result the use of IKE for > Mobile IPv6 deployment is considered as being suboptimal in certain > network architectures and deployment scenarios from the perspective > of message overhead. > > Another downside of IKE for setting up the IPsec SA between the MN > and HA is that IKE does not integrate very well with the Radius based > AAA back-end. Since operators rely on the AAA infrastrucure to > provision subscribers as well as define profiles, keys etc. in the > AAA-Home, there is no getting away from the use of AAA in cdma2000 > networks. IKEv2 does address this problem. However from a timeline > perspective the availability of IKEv2 specifications for Mobile IPv6 > Operation with IKEv2 and the revised IPsec Architecture [RFC4877] and > implementations did not meet the need of operators that were relying > on 3GPP2 specifications. With the specification of IKEv2 and > publication of RFC4877 the integration with AAA backends is no longer > an issue. Is it just me or the same arguments are repeated multiple times? > In summary the model of Mobile IPv6 deployment which mandated the > existence of an IPsec SA between the MN and HA, as specified in RFCs > 3775 and 3776, was too rigid and did not meet the requirements of > operators building networks based on the cdma2000 [3GPP2 > X.S0011-002-D] specifications. To address this shortcoming, the > authentication protocol [RFC4285] was specified. > > > > > > Patil & Dommety Expires May 6, 2009 [Page 10] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > 6. Application of Mobile IPv6 in CDMA Networks I did not read that part, i.e. no comments. > 7. Limitations of the Authentication Protocol option > > While the authentication protocol as specified in [RFC4285] provides > Mobile IPv6 [RFC3775] deployments a certain degree of flexibility it > does have a few disadvantages as well. These are: > > (1) The route optimization feature specified in RFC3775 requires a > secure transport (IPsec/ESP mode) between the MN and HA. In > cases where the authentication protocol (RFC4285) is used as the > means for securing the MIP6 signaling between the MN and HA, > route optimization should be switched off unless the security of > the signaling between the MN and HA can be guaranteed via other > means (such as link layer security in the case of 3GPP2 > networks). > > (2) The MIP6 protocol is responsible for the security of the > signaling messages as opposed to relying on IPsec for providing > the security. > > (3) In 3GPP2 networks, link-layer security mechanisms, ingress > filtering at the PDSN, and various network domain security > mechanisms largely ensure that reverse tunnelled packets > received by the HA do not have spoofed source addresses, and > their contents have not been modified. This implies the HA can > determine the specific MN which sent the packet simply by > verifying the outer source IP address matches the currently > registered care-of address. Authentication of payload packets > can be necessary for e.g.: > > - Authenticating signalling messages other than BU/BAck > between the MN and HA, such as ICMPv6, MLD, and DHCPv6. > > - Enforcing access control to the network behind the HA. > > - Accounting or other flow-specific processing performed by > the HA. > > This means the authentication option is of limited > applicability in environments where the HA can received > reverse tunneled packets with spoofed source IP addresses > and/or modified contents. > > (4) As described in [RFC4285], the authentication option assumes > that the MN-AAA shared key and security association are created > by out-of-band mechanisms. These mechanisms are specific to > specific deployment environments. IKEv2, on the other hand, > supports a wide range of authentication mechanisms, such as > certificates and EAP methods, and is independent of the access > > > > Patil & Dommety Expires May 6, 2009 [Page 17] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > network technology being used. However, it would be possible to > specify a similar authentication and key management protocol for > the authentication option in the future. > > (5) Sending the long-term user identity (NAI) in clear raises > privacy concerns. These concerns are addressed by access > network and network domain security mechanisms in 3GPP2 > networks, but do limit the applicability in networks where > sniffing other users' traffic is possible. > > (6) RFC 4285 does not specify a mechanism for creating the MN-HA > shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4 > mechanisms defined in [RFC3957], and thus rely on deployment > specific mechanisms not standardized in IETF. > > (7) The authentication option does not support negotiation of > cryptographic algorithms. > > (8) The replay protection mechanisms in [RFC4285] rely on > timestamps, and thus requires reasonably synchronized clocks (by > default, +/- 7 seconds). This assumes the MN implements, and is > configured to use, some mechanism for synchronizing its clock. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Patil & Dommety Expires May 6, 2009 [Page 18] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > 8. Security Considerations > > When MIP6 signaling messages use IPsec with ESP encapsulation, they > are accorded privacy on the links over which the messages traverse. > When MIP6 signaling messages are secured using the authentication > protocol, such ciphering capability will have to be enabled by the > underlying link layers. It should be noted that the MIP6 signaling > messages are susceptible to snooping/sniffing when the authentication > protocol [RFC4285] is used. Route optimization messages need to be > secured between the MN and HA and this is not possible with the > authentication protocol. Howver route optimization is not supported ^^^^^^^ However > in the current specification of the authentication protocol in > [RFC4285]. > > Security issues with RFC4285 are specifically: > > 1. Key length. This is being addressed in the 4285bis I-D > [I-D.ietf-mip6-rfc4285bis] at the present time. > > 2. The keys used for securing the signaling between the MN and HA > are derived from a security association that exists between the > MN and AAA. The MIP6 keys which are bootstrapped from the MN-AAA > SA are transient. Limiting the lifetime of the keys to shorter > periods should be recommended. > > 3. Location privacy is an issue in the absence of lower layer > security in the case of shared links. > > > > 10. Conclusion > > Mobile IPv6 has been published as a standards track RFC [RFC3775] in > 2004. Deployment of this protocol on a large scale is in the > interest of the IETF and the working group as well as that of many > people who have worked on this. A rigid model for deployment will > cause the protocol to be limited to an academic exercise only. It is > extremely critical that the working group consider the needs of the > industry and the deployment scenarios and address them accordingly. > This document captures the reasoning behind the need for the > authentication protocol which has been published as RFC 4285. > RFC4877 has alleviated some of the issues that have been of primary > concern and motivators for the authentication protocol. However the > IETF should consider the architectures of networks such as 3GPP2 and > WiMAX and their security models and enable deployment of Mobile IPv6 > without requiring IPsec. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whya… Arnaud Ebalard
- Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whya… Basavaraj Patil
- Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whya… Arnaud Ebalard