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

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