Subject: Re: [Mip6] Preconfigured Kbm as working group document

From: "Charles E.Perkins" <[email-masked]>
Date: Tue, 06 Apr 2004 10:24:55 -0700

Hello Hesham,

I have made modifications to the draft according to
your suggestions, as part of the process of getting
it ready for submission as a working group document.

-------- Original Message --------
From: "Charles E. Perkins" <[email-masked]>
Subject: Re: [Mip6] Preconfigured Kbm as working group document
To: Soliman Hesham <[email-masked]>
CC: Mobile IPv6 Mailing List <[email-masked]>

Hello Hesham,

Soliman Hesham wrote:

>> No, because the correspondent node has to have some reason
>> to believe that the mobile node is trustworthy.  This is very
>> reasonable for many situations, like between you and your
>> co-workers for instance.  Or, since I actually don't know
>> about that, then between me and my co-workers, but I would
>> assume so for you also.
>
>=> If this is the intended scenario then it would be 
>helpful to say that in the draft to avoid mistaking it
>with other types of deployments. I don't have a problem
>with using it for this purpose.

Here is the new text:

    -  mobile node and correspondent node are administered within the
       same domain, and the correspondent node has good reason to trust
       the actions of the mobile node

>> There isn't any max lifetime defined for the BSA.
>
>=> I know, should there be one? or at least should 
>there be a statement that says there is no upper
>limit (except the size of the field) for the lifetime?
>If for nothing else, to distinguish this from RR based
>Kbms.

Here is the new text:

   There is no upper bound on the lifetime defined for the preconfigured
   Kbm.  As noted, the key is very, very likely to be quite secure
   over the lifetime of the security association and usefulness of 
   applications between a mobile node and correspondent node that fit
   the terms specified in section 2.

Regards,
Charlie P.

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

---

From: "Charles E.Perkins" <[email-masked]>
Date: Tue, 06 Apr 2004 15:20:49 -0700

Hello Jari,

Thanks for your comments.  I didn't take any action on
the suggestion for a feedback mechanism for the network
administration.  This sounds like a user interface
issue, which usually is not part of IETF specifications
that I am familiar with.  For instance, one might demand
that a DHCP server be equipped with various alarms, but
I would hope that such needs not be laid out as part of
the protocol specification.  I am thinking "on the wire"
for what needs to go into the specification.

I made some text for your other suggestions, as
noted inline below.

Jari Arkko wrote:

>       .........         It may be obvious, but the
> draft doesn't exactly say it outloud: Kbm is indexed by
> the home address.

I added the following sentence to section 1:
	The key is associated to the mobile node's home address.

>              Also, the replay protection appears
> to work only if the BCE is kept alive at all times.
> Did you intend to do this, or have another data
> structure that keeps some state when the BCE is
> not active for a given home address?

I added this text, with a new mandate, to section 1:

   Replay protection for Binding Update messages using
   the preconfigured Kbm depends upon the value of the
   sequence number field in the Binding Update.  If the
   correspondent node does not maintain information about
   the recently used values of that field, then there
   may be an opportunity for a malicious node to replay
   old Binding Update messages and fool the correspondent
   node into routing towards an old care-of address.
   For this reason, a correspondent node that uses a
   preconfigured Kbm also MUST keep track of the most
   recent value of the Sequence Number field of Binding
   Update messages using the preconfigured Kbm value.

And in the Security Considerations:

   If a correspondent node does NOT keep track of the Sequence
   Number for Binding Update messages from a particular mobile
   node, then the correspondent node could be fooled into 
   accepting an old value for the mobile node's care-of address.
   In the unlikely event that this address was reallocated to
   another IPv6 node in the meantime, that IPv6 node would
   then be vulnerable to unwanted traffic emanating from the
   correspondent node.  In order to circumvent this possibility,
   correspondent nodes are mandated to keep track of the most
   recent Sequence Number value in a Binding Update message   
   from the mobile node.  

Regards,
Charlie P.