Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt
Hi,
Some typos, while reading the document. Some questions too.
Internet-Drafts at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/mext
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
