Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt
Basavaraj Patil <basavaraj.patil@nokia.com> Tue, 04 November 2008 19:36 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FF73A6C1C; Tue, 4 Nov 2008 11:36:29 -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 E05C23A69EC for <mext@core3.amsl.com>; Tue, 4 Nov 2008 11:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 pQciB4jaiXjh for <mext@core3.amsl.com>; Tue, 4 Nov 2008 11:36:25 -0800 (PST)
Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id AB9003A696F for <mext@ietf.org>; Tue, 4 Nov 2008 11:36:24 -0800 (PST)
Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA4JIlB0013895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mext@ietf.org>; Tue, 4 Nov 2008 21:18:49 +0200
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA4JEoL6001630; Tue, 4 Nov 2008 13:15:36 -0600
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 21:15:18 +0200
Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 21:15:18 +0200
Received: from 172.19.60.170 ([172.19.60.170]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Nov 2008 19:15:15 +0000
User-Agent: Microsoft-Entourage/12.13.0.080930
Date: Tue, 04 Nov 2008 13:15:18 -0500
From: Basavaraj Patil <basavaraj.patil@nokia.com>
To: ext Arnaud Ebalard <arno@natisbad.org>, mext@ietf.org
Message-ID: <C535FB66.1CF9F%basavaraj.patil@nokia.com>
Thread-Topic: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt
Thread-Index: Ack+saxxg9ENKjzR80ysDUqYEwLdrg==
In-Reply-To: <87iqr4ims6.fsf@natisbad.org>
Mime-version: 1.0
X-OriginalArrivalTime: 04 Nov 2008 19:15:18.0562 (UTC) FILETIME=[ACC6E820:01C93EB1]
X-Nokia-AV: Clean
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
Hello, Responses inline: On 11/3/08 3:20 PM, "ext Arnaud Ebalard" <arno@natisbad.org> wrote: > 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 Ack. > >> [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 > Ack. >> home agent. >> >> o The route optimization signaling messages which include HoTI/Hot, > > HoT ^^^ Ack. > >> [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 Ack. > >> 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. I should have checked the pointer. I guess it has changed. The correct pointer is : http://www.wimaxforum.org/documents/documents/WiMAX_Forum_Network_Architectu re_Stage_2-3_Rel_1v1.2.zip Will fix it in the revised I-D. > 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)? There is no expectation that the data traffic is secured when the MN moves to a link which may not provide link-layer security. Security for data traffic is optional. If the MN desires data traffic security, the MN would not do a handover to an access which does not provide link-layer security (as an example). Or alternatively a solution that is used in networks such as 3GPP is to establish an Ipsec SA with an intermediate gateway, refered to as PDG [Packet Data Gateway], and tunnel data traffic over the Ipsec SA to the gateway in the home network. > >> 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 Ack. > >> establishing an IPsec SA [RFC4877] was not available. IKEv2 does >> enable integration with a a AAA backend. > > ^^^^^ Ack. >> >> 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? The use of IPsec itself is/was the issue. Basically operators who deployed MIP4 have not really had concerns w.r.t security. And given that MIP4 works without any IPsec SAs, there was at least a view to have MIP6 operate with a similar model. > >> 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 > > ^^^^^^^^^^ > Ack. >> 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 > > ^^^^^^^^ > Ack. >> 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] > Ack. >> 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? > Let me check.... >> 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 Ack. > >> 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. Thanks for the review and comments. Will revise the I-D with the corrections. -Raj > > Cheers, > > a+ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ 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