Subject: Re: [mobile-ip] deregistration from foreign link

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 22 Jan 2003 16:02:17 -0800 (PST)

> 
> No, this is not a bug in the spec.
> 
> See issue 98 for the discussion (particularly the later discussion
> by Gabriel).
> 

Thanks for pointing it out.  So the accepted Kbu for  *all* deletion is:

if ( lifetime == 0 || coa == hoa)
        Kbu = hash(home keygen token)

However, then section 5.2.6 is a bit misleading (see below). If deletion
Kbu is always calculated using home keygen, then we don't need to mention
"In this case..."

-Samita

> Samita Chakrabarti wrote:
> >>When a MN locates at a foreing link and sends a de-registration BU (the
> >>BU which lifetime set to zero), the MN must not use the Careof Keygen
> >>Token to calculate the authenticator according to the draft (section
> >>9.5.1).
> >>
> >>Since the MN is at the foreign link and uses CoA as the source address
> >>of the BU, MN should verify CoA of the BU as well as a normal BU.
> >>
> >>any comments?
> >>
> > 
> > 
> > It looks like a bug in the spec (from draft 19).  This item in section 9.5.1 
> > is valid  for only when COA=Home address. So, you are correct in saying that
> > both home keygen and care-of keygen need to be considered to calculate Kbm
> > when care-of-addr != home-addr of the BU.
> > 
> > Note, section 5.2.6 also confirms that:
> > 
> >    A Binding Update may also be used to delete a previously established
> >    binding by setting the care-of address equal to the home address
> >    (Section 6.1.7).  In this case, the care-of keygen token is not used.
> >    Instead, the binding management key is generated as follows:
> > 
> >     Kbm = SHA1(home keygen token)
> >     
> >  
> >  -Samita
> > 
> > 
> >>Section 9.5.1 said
> >>   o  If the Lifetime specified in the Binding Update is zero or the
> >>      specified care-of address matches the home address for the
> >>      binding, then this is a request to delete the mobile node's cached
> >>      binding.  In this case, the Binding Update MUST include a valid
> >>      home nonce index, and the care-of nonce index MUST be ignored by
> >>      the correspondent node.  The generation of the binding management
> >>      key depends then exclusively on the home keygen token (Section
> >>      5.2.5).  If the Home Registration (H) bit is set in the Binding
> >>      Update, the Binding Update is processed according to the procedure
> >>      specified in Section 10.3.2; otherwise, it is processed according
> >>      to the procedure specified in Section 9.5.3.
> >>
> >>regards,
> >>ryuji
> >>
> > 
> > 
> > 
> > 
> 
> 
> -- 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
> Hewlett Packard 		Tel: (603) 884-1079
> Nashua, NH 03062		ZKO3-3/T07
> 
>

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 23 Jan 2003 09:42:19 -0500

Samita

I haven't had a chance to read the spec yet, so I can't comment
on the misleading sentence.

-vlad

---

From: Jari Arkko <[email-masked]>
Date: Sat, 25 Jan 2003 02:00:23 +0200

> Kbu is always calculated using home keygen, then we don't need to mention

Lets see...

I think I agree that its misleading. New text below:

 >   binding (Section 6.1.7). In this case, the care-of
 >   keygen token is not used. Instead, the binding management key is
 >   generated as follows:
 >

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sun, 26 Jan 2003 15:22:46 +0200 (EET)

Speaking of which, this is one particular issue that bugged me when 
reading the draft.

Why are there 2 separate mechanisms for doing the same thing?  Shouldn't 
we just cope with one and leave the other out?  Is there something to be 
gained by this?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 27 Jan 2003 02:35:40 +0900

Hi Pekka

I agree with you.

when a MN deregister its binding from its home link, the two conditions
are satisfied. (i.e. lifetime == 0 and coa == hoa).
From the foreign link, the only one condition is satisfied. (i.e.
lifetime == 0).

Why not say like...
	For the deregistration, the lifetime MUST be always zero. (only
	one mechanism)
	MN can omit a home address option when it returns home.
	If the coa == hoa regardless of a home address option presence,
	the kbm MUST be calculated only by the hoa keygen token,
	otherwise the kbm MUST be calculated by both hoa and care-of
	keygen tokens.  

Since the de-registration BU is carried through a coa from a foreign
link, I think it is better to verify the CoA. 
Or, for deregistration, the MN does not need to send CoTI before sending
BU?!

regards,
ryuji

regards,
ryuji

---

From: Jari Arkko <[email-masked]>
Date: Sun, 26 Jan 2003 12:45:21 +0200

> we just cope with one and leave the other out?  Is there something to be 

There appears to be two methods because the packet formats have two
distinct fields, who both happen to have special values which imply
de-registration.

It isn't easy to avoid that. Also, be-conservative-what-you-send-and-
liberal-what-you-accept applies. So, I think we are going to have the
CNs interprete either "mechanism" as a de-registration.

However, what we can do is to make it clearer that when you send
you MUST set both. We already do that in 11.5.4 (returning home)
but in 6.1.7 and the rest of section 11 isn't clear about that.
I'll change that but keep 9.5.1 intact. The only drawback is that
if you de-register while away from home, alt-coa needs to be present.

OK?

Jari