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

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Mar 2008 13:56:48 +0200

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

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 25 Mar 2008 16:38:24 -0500

On 3/19/08 6:56 AM, "ext Jari Arkko" <[email-masked]> wrote:

Hi Jari,

Thanks for the review. Will revise the I-D and submit it. A few

>authentication option? If not, I would suggest deleting the above

The reason I mentioned WiMAX is because MIP6 as specified in Release 1
requires the use of the auth protocol. Use of the Auth protocol is the
default mode and IPsec/IKEv2 usage with MIP6 is optional.

So given the fact that you had suggested that this I-D capture current
usage of the auth protocol, I have mentioned WiMAX here. So I believe
it is okay to keep it in the document.

The 3GPP aspect is incorrect and I will delete it.

>would also be beneficial.

I believe this is indeed the case. I will check with the 3GPP2 people
to see the status of the auth protocol and capture it accordingly in
this I-D.

>>       establishing an IPsec SA [RFC4877
>>       <http://tools.ietf.org/html/rfc4877>] was not available.
>>       IKEv2 does

Okay.

>AAA with Mobile IPv6 home registrations, ..."

Will revise the statement. But basically the intent was to state that
with the MIP6 RFCs 3775/6, integration with AAA was not possible.

>going to be extra overhead if we start employing the above argument.

But the use of IPsec in the case of networks which aim to optimize the
air interface to a great extent is indeed an overhead. And this was an
argument which was used at the time the auth protocol was
discussed. The argument is valid today as well. We can argue about the
contents of the MIP6 messages and whether some bit, flag or option
adds overhead. But I do think that usage if IPsec to secure the MIP6
signaling messages, in a network which is inherently secure over the
air interface (via L2 means) and the links that transport the
signaling to the HA, is an overhead. Removing the paragraph would be
invalidating one of the arguments for specifying the auth protocol.

>(at least if we talk about standardized protocols)

Yes. That being the case..

>little about the actual size of the impact (when you have to do this

I agree about the style aspect. Will delete or rephrase as:
"As a result the use of IKE for Mobile IPv6 deployment is considered
as being suboptimal from the perspective of message overhead."

>  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. ...

Okay. Will replace as suggested.

>like to see the set of known issues, not some subset thereof.

Okay. Will capture at least the known issues.

>these networks do have link layer security.

Agree with what you say. Will revise text. Also noted that RFC4285
states:
"
Thus, unless the network can guarantee such protection (for instance,
like in 3GPP2 networks), Route Optimization and Mobile Prefix
Discovery should not be used when using the mobility message
authentication option.
"

Proposed text:
"
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).
"

>with bootstrapping and IKEv2 schemes. Suggest removing this.

Okay.

>hinted at. Talk about that here. Please be specific.

Security issues with RFC4285 are specifically:
1. Key length. This is being addressed in the 4285bis I-D 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.
4. Route optimization is limited to the case where the link between
   the MN and HA is assumed to be secure.

>>    [RFC4285 <http://tools.ietf.org/html/rfc4285>].

Yes. Will delete the sentence.

>>    Mobile IPv6 
[I-D.ietf-mip6-rfc4285bis><http://tools.ietf.org/html/draft-ietf-mip6-whyauthdat
aoption-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.

Okay. Will fix.

>IKEv2 mechanisms developed in the WG.

Agree. I can add the additional text indicating that IKEv2 and
bootstrapping mechanisms have been developed and specified by the WG
which can address many of the concerns that existed when the auth
protocol was specified. However I do believe (repeating myself) that
the auth protocol does have applicability in certain networks and
deployments. 

>>    prevented by the use of IPsec.

Okay

>Typo

Ack.

>to use IPsec

Ack.

>>        HA that are required to establish the IPsec SA as too many.

Ack.. Will fix.

>>    Operation with IKEv2 and the revised IPsec Architecture [RFC4877
>>    <http://tools.ietf.org/html/rfc4877>] was

Ack.

>s/discussion/discussion (2003?)/

Ack

>IKEv2

Ack

>without

Ack

>This statement shows the age of the text.... its not so recently any

I guess that is indeed the case :)
Will delete.

-Raj