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

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 10 Mar 2004 21:38:57 -0500

I have a couple of questions:

- We discussed this before for the base spec and 
I believe it was suggested that a CoA test would 
be needed, thoughts?

- What's the max lifetime for the BSA in this scenario?
I didn't see anything in the draft about that.

- Why does the draft say that if nonces exist the "MAY be
ignored" ? shouldn't they just be ignored? under what circumstances
are the nonces acceptable?

Thanks,
Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On Behalf Of
 > Charles E. Perkins
 > Sent: Wednesday, March 10, 2004 5:23 PM
 > To: Mobile IPv6 Mailing List
 > Cc: Basavaraj Patil (NTC/Dallas); Gopal Dommety
 > Subject: [Mip6] Preconfigured Kbm as working group document
 > 
 > 
 > 
 > Hello folks,
 > 
 > I would like to request that the following document
 > be considered as a working group document:
 >    "Preconfigured Binding Management Keys for Mobile IPv6"
 > 	  draft-perkins-mip6-precfgKbm-00.txt
 > 
 > This short document was discussed at the recent
 > IETF meeting, and the basic idea has been discussed
 > sporadically several times in the past.
 > 
 > Regards,
 > Charlie P.
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/mip6
 > 

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Mar 2004 18:56:59 -0800

hi Hesham,

> I believe it was suggested that a CoA test would 

did you see the Security Considerations section of the draft?

>    A correspondent node and a mobile node MAY use a preconfigured
>    binding management key (Kbm) to manage the authentication
>    requirements for binding cache management messages.  Such keys must
>    be handled carefully to avoid inadvertent exposure to the threats
>    outlined in [2].

>    A mobile node MUST use a different binding management key (Kbm)
>    for each node in its Binding Update List.  This ensures that the
>    sender of a Binding Update can always be uniquely determined.  This
>    is necessary, as this authorization method does not provide any
>    guarantee that the given care-of address is legitimate.

>    For the same
>    reason, this method SHOULD only be applied between nodes that are
>    under the same administration.  The return routability procedure is
>    RECOMMENDED for all general use and MUST be the default, unless the
>    user explicitly overrides this by entering a key for a particular
>    peer.

if the CN does not trust the MN not to misbehave, then it
shouldnt use this mechanism. it should use return routability.

> are the nonces acceptable?

the actual text says

> The Nonce Indices option SHOULD NOT
>    be present.  If it is present, the nonce indices supplied MAY be
>    ignored

do you want the packet dropped and an ICMP error generated?

Vijay

ps: the draft is available at 
http://people.nokia.net/charliep/txt/mobilev6/precfg.txt

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 11 Mar 2004 09:29:12 -0800

Hello Hesham,

>I believe it was suggested that a CoA test would 
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.

>I didn't see anything in the draft about that.
There isn't any max lifetime defined for the BSA.

>are the nonces acceptable?
According to the standards language conventions, "MAY" does not
presuppose a list of conditions.  It means that the protocol partner
must be prepared for the possibility that they be ignored.  It means
that the sender doesn't have any particularly good reason to include
the nonces, but it is not an error to do so.

Regards,
Charlie P.