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

[Basavaraj Patil <[e-mail]>]

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


Hi Jari,

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

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

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.

>
>Also, if the situation in 3GPP2 has changed afterwards, stating this
>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.

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

Okay.

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

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

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

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.

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

Yes. That being the case..

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

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

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

Okay. Will replace as suggested.

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

Okay. Will capture at least the known issues.

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

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

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

Okay.

>
>You are missing security problems with RFC 4285 that Section 6 start
>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.

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

Yes. Will delete the sentence.

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

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

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. 

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

Okay

>
>> minmize
>Typo

Ack.

>
>> of using IPsec
>to use IPsec

Ack.

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

Ack.. Will fix.

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

Ack.

>
>s/discussion/discussion (2003?)/

Ack

>
>> IKEV2
>IKEv2

Ack

>
>
>> with out
>without

Ack

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

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

-Raj


>
>Jari
>
>
>


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext