Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt

[[e-mail] (Arnaud Ebalard)]

Hi,

Some typos, while reading the document. Some questions too.

[e-mail] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/mext