Subject: [Fwd: Re: [Mip6] Comments on draft-ietf-mip6-auth-protocol-01.txt]

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Dec 2004 20:03:15 -0800

Hello folks,

I am resending this, because the first time seems to have failed...

=========================================

Hello folks,

... by dialup ...

I'm hoping to get my comments typed in before the
telephone line crashes again...  I may have missed
some of the discussion since I'm not completely
caught up yet.

Jari Arkko wrote:

>
> But there are a few issues that need to be corrected. The most
> important issue is putting back the mandatory support for RO/RR.
>
Protecting RO/RR is a good idea, and I don't think it is too
hard.  However, I believe it is "highly recommended" and not
"mandated", and could be done later.  I'd hate to see that hold
up the progress of this draft.

>
>
>> MN MAY use Message Identifier option as defined in Section 6 for
>> replay protection.
>> ...
>> The format of the timestamp mobility option is as defined in Section
>> 6.  This option uses the subtype value of 1.  The Identification
>> field carries timestamp for replay protection.
>
>
> I am somewhat concerned about the extensive optionality and
> additional replay protection schemes, from a complexity point
> of view. Do we really expect that there is going to be yet
> another replay protection schemes? Is there a reason why
> we don't want to use the option all the time? Ease of analysis &
> implementation simplicity would be some of the benefits...

I am much opposed to making the extra timestamp scheme
mandatory.  It isn't needed in many or perhaps even most
cases, and it does impose additional implementation burden.
Plus it is extra baggage.

>
>
>
> A "security association" may be too general. Its a security
> association of a certain kind that you need, not others. For
> instance, if the MN has only an IPsec SA or a TLS association with
> the home agent, they should not attempt to use this option.
> Suggestion: give a name X for your authentication method and
> start referring to the "X security associations". Here X
> could be, say, "Shared-Key Mobile IPv6 Authentication".

I think it would be enough to say in the beginning of the
draft something along the lines:

   In this draft, a "security association" is understood to
   be a "Shared-Key Mobile IPv6 Authentication" security
   association.

>
>> The value 5 is reserved for use by 3GPP2.
>
>
> This seems strange. If 3GPP2 wants the IETF to define an
> RFC for a new feature within Mobile IPv6, you would expect
> the semantics of value 5 to be defined. Which algorithms
> are 3GPP2 actually using? Or is the value 5 just a relic
> from older systems, dealing with Mobile IPv4?

In fact, I believe the SPI field should be optional at best,
since almost always there is only one such security association
that would be used with the option.  It could be a different
subtype, or it could be omitted altogether.

................

More soon, not wanting to push my luck here...

Regards,
Charlie P.

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