Subject: [Mip6] AD review of draft-ietf-mip6-whyauthdataoption

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Sep 2007 22:12:48 +0300

I have reviewed this draft. Before I get to the results of my
review, let me state that I support publishing the rationale
for RFC 4285 and that I believe that RFC was necessary back
then for Mobile IPv6 (and may still be).

But unfortunately, this document has significant problems and
requires a fairly major rewrite, at least as far as Sections 4,
5 and 7 go. I liked Section 6. Fortunately, given the size
of the document and the relative simplicity of the topic,
I do not expect the rewrite to take a lot of time. But you have
to have a new approach to writing this document.

The first problem is that there a number of statements
in the document of the form "X is not supported in
Mobile IPv6" which are untrue. This may be in part
because of the desire to report the historical thinking.
This is a valid goal for the document, but at the same
time we are not publishing an RFC in 2007 that
makes incorrect statements. I would recommend
structuring these statements and perhaps even
the whole document more along the lines of
"At the time RFC 4285 was designed, X was not
supported. This has later changed when feature
Y was defined, and this is no longer a problem /
the remaining issues are ..."

I do not want to turn this document into a
description what to do instead of RFC 4285, but
it is currently too silent on how to use the
existing components (such as IKEv2 or EAP) to
achieve similar results.

There are a number of arguments in the document
that do not appear to have implications for the
selection of the authentication mechanism, some
that are weak, and as noted above, some that
are no longer true. I believe there are good
reasons, and I would suggest sticking to those
rather than try to argue the case with a large
number of arguments.

The document is almost completely silent on
the possible limitations and downsides of
the authentication option. You must mention
the downsides as well, be it lack of
encryption support for RO, the introduction
of additional modes which may affect
interoperability, etc. Again, being honest
about the arguments and limitations
not only helps people understand this
technology better, but will also aid you
in getting your document approved.

Details below:

Substantial:

>    1.  Networks in which the access authentication is separate from the
>        authentication of the mobile node to the home agent.  There
>        exists a security association between the mobile node and some
>        backend authentication server (eg.  AAA Home server) which is
>        used for access authentication.
>    2.  Networks in which the establishment of the security association
>        between the mobile node and the authentication server (AAA Home)
>        is established using an out-of-band mechanism and not by any key
>        exchange protocol.  Such networks will also rely on out-of-band
>        mechanisms to renew the security association (between MN and AAA
>        Home) when needed.
>    3.  Networks in which the home agent and home address needs to be
>        assigned on a dynamic basis.
>    4.  Networks which are bandwidth constrained (such as cellular
>        wireless networks) and there exists a need to minimize the number
>        of signaling messages sent over such interfaces.
This is not a very good list to differentiate the situations
where the auth option is needed. For some of the points
it is not clear why they imply anything for the selection
of the authentication mechanism. For instance, if item
1 condition about separate access / mobility auth
would not hold, there wouldn't be a Mobile IPv6
authentication mechanism at all. Item 2 appears to
merely a scoping question, i.e., whether we want to
talk about the keying or not. In some of the
other points, all currently defined Mobile IPv6
mechanisms are capable of satisfying the requirement,
e.g., 3 or 4. But maybe not both at the same time.

The list should be reformulated. E.g, something
along the following lines.

1. Authentication credentials already exist for some other
    purpose in a AAA server for the node.
2. Dynamic assignment of home agents is used and at the
    same time it is desired to avoid negotiating new IPsec
    SAs on every assignment.
3. Mobile nodes only move within networks that
    have sufficient link-layer encryption support
    to prevent problems with revealing RO-related
    signaling.

(But this isn't all that satisfactory either, presumably
dynamic HA assignment occurs rather infrequently,
not on every movement.)

> It can be argued that IKEv2 does provide the capability to be
>       integrated with a AAA backend.  However IKEv2 is not an option
>       that can be considered because of the deployment timelines of
>       operators relying on 3GPP2 standards.
This should be rewritten to make it clearer what the situation
was back in RFC 4285 timeframe vs. now.

>    o  The current Mobile IPv6 specification does not support the dynamic
>       assignment of home agent and home address.  Although there is on-
>       going work in the MIP6 WG to address this, the work is not yet
>       ready. 
The latter limitation (home address) is untrue, see RFC 4877.

For the former limitation (home agent assignment), it is true
that the WG is still working on this. However, it is unclear why
this has anything to do with the selection of authentication
method. It seems that an operator or L2 SDO can define
their network access mechanisms so that proper home
agent address can be delivered to the mobile node. This needs
to be done anyway (RFC 4285 or something else), and from
that point onwards it does not matter what the authentication
mechanism does, as long as it is capable of authenticating
to a dynamically changing home agent.

> The identity of a user in MIP4-based cdma2000 networks is an MN
>       Identifier Option for MIP6 [RFC4283 <http://tools.ietf.org/html/rfc4283>].  Mobile IPv6 as per RFC3775 <http://tools.ietf.org/html/rfc3775>
>       specifies the IPv6 home address as the identity of the mobile
>       node.  Morever, the home address cannot be dynamically assigned in
>       such cases.
Again, untrue at the time of writing this, given RFC 4877.
NAIs are a perfectly fine identification option for both
IKEv2 and EAP (if run within IKEv2).

>    Consequently, MIP6 as specified today does not satisfy necessary
>    requirements. 

Back then -- yes. Now, its still a question mark for me. Please
make the distinction between the back-then and now in the
document.

Regarding the situation now, at the very least your list
of issues has been significantly shortened. Whether
there are items left depends a little bit on details that
I'm not fully aware of. For instance, an existing deployment
may use just MIP4 based AAA messaging that cannot
work with IKEv2's EAP-based AAA messaging. Or some
deployments might be; its these kinds of arguments that
are more substantial than the ones that I see above.

Suggest rewriting the list in Section 5.1 based on the
above comments.

>  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.
Again, untrue at the this is being written.

> Establishing an IPsec SA between the
>    MN and HA using AAA infrastrucure is not specified for Mobile IPv6
>    today.  RFC3776 <http://tools.ietf.org/html/rfc3776> explains how IKE is used for establishing the SA
>    between the MN and HA.  And even in this case, the MN has a
>    designated home address.
See above.

> 6. Solution Proposal

This section was very good.

> 7. Security Considerations
>
>
>    The security requirements for the signaling messages between the MN
>    and HA when using the authentication option mechanism are the same as
>    those when using IPsec to secure them.

This is not true, e.g., lack of ESP support means you have to
rely on link layer encryption to protect route optimization
packets.

>    It should be noted that the key length
>    proposed in RFC 4285 was 16 octets in length.  This was considered as
>    being weak.  The issue is being corrected by increasing the key
>    length to 20 octets in Authentication Protocol for Mobile IPv6
>    [I-D.ietf-mip6-rfc4285bis].

My recollection was that the issue was not so much the number
of bits and their lack of strength, but the actually delivering the
right number of bits for an algorithm. I may be wrong, please
check.

>    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.  MIP4 does not rely on IPsec for securing the Registration
>    signaling messages.
>   

I have a lot of sympathy for this statement, having attempted
to use IPsec for various purposes in different networks, and
often running into various problems of both technical and
other kinds.

However, this paragraph is not very descriptive. You have
to decide whether you want to make a technical argument,
but this requires a better argument than stating "X is overhead
if we want to do Y." There are technical arguments, but
frankly I'm not sure those are the compelling ones for
this particular part of the problem.

You might simply state that the operators are unwilling
to change anything (or change as little as possible) from
MIPv4. But you have this text earlier, already.

Editorial:

> So the alternate solution would be in
>    addition to the IPsec based mechanism specified in the base RFCs, RFC <http://tools.ietf.org/html/rfc3775>
>    3775 <http://tools.ietf.org/html/rfc3775> [RFC3775 <http://tools.ietf.org/html/rfc3775>] and RFC 3776 <http://tools.ietf.org/html/rfc3776> [RFC3776 <http://tools.ietf.org/html/rfc3776>].
Please include RFC 4877 here,too.

>    Mobile IPv6 as specified in RFC3775 <http://tools.ietf.org/html/rfc3775> and RFC3776 <http://tools.ietf.org/html/rfc3776> implies a very
>    specific model for deployment.  It anticipates the Mobile nodes
>    having a static home IPv6 address and a designated home agent.  An
>    IPsec SA is expected to be created, either via manual keying or
>    established dynamically by using IKE.  These assumptions do not
>    necessarily fit in very well for the deployment model envisioned in
>    cdma2000 networks.
This paragraph does not seem to add a lot of value over the
other statements in Section 5. Remove.

Jari

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6