[MEXT] re-review of draft-ietf-mip6-whyauthdataoption

I have re-reviewed this document, after a new version appeared to
address my earlier AD review comments.

Another revision will be needed. The new version is much better than the
previous one, but some issues still remain. I would also recommend doing
an additional editorial pass on the document.

Technical:

> Other networks which have similar deployment
>    requirements are IEEE 802.16e based Mobile WiMAX networks and
>    potentially 3GPP based HSPA (High speed Packet access) type of
>    networks.
The 3GPP2 case that you explained before had a use for this. Do we have
official specs from the other two (Wimax and 3GPP) that actually use the
authentication option? If not, I would suggest deleting the above text.

Also, if the situation in 3GPP2 has changed afterwards, stating this
would also be beneficial.

> This is in contrast with the currently specified
>       Mobile IPv6 model which requires an IPsec SA between the MN and
>       HA.  At the time of this writing the IKEV2 based solution for
>       establishing an IPsec SA [RFC4877 <http://tools.ietf.org/html/rfc4877>] was not available.  IKEv2 does
>       enable integration with a a AAA backend.

s/is in contrast with the currently specified/was in contrast with an
earlier version of the/

>    Hence, with the MIP6 specifications and architecture that relies on
>    IPsec as the sole means for securing the signaling between the MN and
>    HA, it is not possible to accomplish a deployment that mirrors that
>    of MIP4 for cdma deployments.
This seems false, given IKEv2's integration to AAA. Delete or rewrite as
"Before the publication RFC NNNN that allows integration of IKEv2 and
AAA with Mobile IPv6 home registrations, ..."

>    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.
This really says very little. Every new protocol bit in Mobile IPv6 is
going to be extra overhead if we start employing the above argument.
Delete paragraph.

> IKE does not integrate very well with the Radius
does not work at all with the Radius

(at least if we talk about standardized protocols)

> As a result the use of IKE for
>    Mobile IPv6 deployment is detrimental to the operators bottom line.
>   

I do not think this statement is of proper style for an RFC. The
previous text in the same paragraph should be sufficient to make the
point. In any case, you are making a value judgment that says very
little about the actual size of the impact (when you have to do this etc).

> 6. Solution Proposal

The title and first paragraphs of this section should be changed. The
section should indicate how 3GPP2 is actually using Mobile IPv6 rather
than suggesting any new solutions. Indeed, RFC 4285 already exists so
its not clear that we need anything new.

Suggested new text is:

6. Application of Mobile IP in CDMA Networks

  Sections 6.1 and 6.2 describe the IPv4 based mobility architecture in cdma networks and IPv6 based
   mobility architecture in cdma Net- works respectively.

6.1. ...

> Some of them are:
>
>    1.  Route optimization is not supported.  Since route optimization
>        signaling messages between the MN and HA are secured by IPsec ESP
>        an equivalent solution will have to be specfied or the deployment
>        will have to rely on link-layer security mechanisms.
>    2.  Bootstrapping of the MN home address is possible when using
>        IKEv2.  DHCPv6 or other mechanisms will have to be relied on in
>        the absence of IKEv2 with IPsec for MIP6 signaling.
Several problems with this. "Some" is not what I was looking for -- I'd
like to see the set of known issues, not some subset thereof.

Point 1 is incorrect. It should rephrased as route optimization having
to rely on link layer security mechanisms, or having to be turned off if
no such mechanisms exist. I believe route optimization is completely OK
in networks such as CDMA from the security perspective, because all of
these networks do have link layer security.

Point 2 does not seem to be a problem in RFC 4285 itself. As the
document has stated previously, many of these things can now be done
with bootstrapping and IKEv2 schemes. Suggest removing this.

You are missing security problems with RFC 4285 that Section 6 start
hinted at. Talk about that here. Please be specific.

> Howver route optimization is not supported
>    in the current specification of the authentication protocol in
>    [RFC4285 <http://tools.ietf.org/html/rfc4285>].

See above.

> It should be noted that the key length
>    proposed in RFC 4285 <http://tools.ietf.org/html/rfc4285> was 16 octets in length.  This was considered as
>    being weak.  The issue is being corrected by increasing the key
>    length to 20 octets at a minimum in Authentication Protocol for
>    Mobile IPv6 [I-D.ietf-mip6-rfc4285bis <http://tools.ietf.org/html/draft-ietf-mip6-whyauthdataoption-05#ref-I-D.ietf-mip6-rfc4285bis>].
This does not belong in the conclusion section. It belongs either in the
limitations or security considerations section.

> 10. Conclusions

I find it odd that the conclusions only argue for RFC 4285, but make no
mention of recommending new deployments to consider bootstrapping and
IKEv2 mechanisms developed in the WG.

Editorial:

>    In summary the model of Mobile IPv6 deployment which mandated the

the original model

> The only con- sideration is that the alternative
>    solution should not be vulner- able to attacks that are otherwise
>    prevented by the use of IPsec. 

extra dashes

> minmize
Typo

> of using IPsec
to use IPsec

> Operators may consider the number of messages between the MN and
>        HA that are required to establish the IPsec SA as too many.

Reads funny

> However at the time of discussion on the need for the
>    authentication protocol, the specification for using Mobile IPv6
>    Operation with IKEv2 and the revised IPsec Architecture [RFC4877 <http://tools.ietf.org/html/rfc4877>] was
>    still work in progress at the time of this writing and as a result an
>    alternative solution needed. 
s/at the time of this writing and as a result an alternative solution
needed//

s/discussion/discussion (2003?)/

> IKEV2
IKEv2

> with out
without

> Howver route optimization is not supported
>    in the current specification of the authentication protocol in
>    [RFC4285 <http://tools.ietf.org/html/rfc4285>].
However

>    Mobile IPv6 has been standardized only recently.  
This statement shows the age of the text.... its not so recently any more. Remove this.

Jari

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext