Subject: RE: [mobile-ip] Comments on Draft 16

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 27 Mar 2002 10:57:21 -0800

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, March 26, 2002 2:24 PM
> To: [email-masked]
> Subject: Re: [mobile-ip] Comments on Draft 16
> 
> 
> Jari Arkko wrote:
> > 
> > Thanks Brian for your comments! Some answer below:
> > 
> > >>Both the mobile node and the home agent MUST use 
> non-volatile memory 
> > >>to store the sequence number so that a reboot does not 
> prevent the 
> > >>acceptance of new Binding Updates.
> > >
> > > Why is this a MUST and not a SHOULD (or MAY)
> > 
> > The nv memory allows for protection against replays. If 
> there's no nv 
> > memory, we'll have to provide a resynch procedure, which 
> could be used 
> > by attackers in a replay too.
> > 
> > But I'm not sure either whether this should be a MUST. Perhaps a 
> > SHOULD would be sufficient?
> > 
> 
> There was something in draft 15 to handle the case when the 
> MN reboots. If the MN sends a BU with a sequence number 
> smaller than the one it had sent before the reboot, the HA 
> rejects the BU and sends a BAck with error status 141 
> (sequence number too 
> small). In addition to this, the HA includes the sequence number 
> from its binding cache in the BAck. For the next BU, the MN 
> chooses a sequence number greater than the sequence number in 
> the returned BAck.
> 
> When the HA reboots and comes up, it accepts whatever 
> sequence number the MN sends.
> 
Or if the binding cache entry is removed/expired, a replayed binding
update
will be accepted (assuming nonces are still valid). I am not sure
how bad is this. But requiring the implementors to store it in NV might
be a overkill because you have to store one per MN plus the home
address and how do you know when to ever remove them from NV ?

-mohan

> We have tested this.
> Vijay

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 27 Mar 2002 17:26:00 -0800 (PST)

> Hesham Soliman (ERA) wrote:
> 
> 
> > => Does it matter? I mean if the COTI is always 
> > done on the intended CoA then wouldn't it always 
> > work? So if a BU is sent with an Alt-CoA then 
> > the COTI is done on the Alt-CoA. 
> 
> 
> Ah, if this is done then it does indeed work.
> 
> (But see also below.)
>

I agree. Alt-COA should correspond with COTI COA.
May be we should clarify that in the draft, if not
done yet.
 
> 
> > As for the use, well a multihomed MN may choose 
> > (for whatever reason) to send a BU from one interface
> > to forward traffic to another interface. 
> > I can't think of a good case right now (apart from
> > HMIPv6 :) ). 
> 
> 
> So, in the multihomed case you'd still have to send
> the COT/COTI from the real interface, even if the BU
> could be sent from elsewhere. Ok for everybody?

IMHO, HMIPV6 example seems more real when src-addr of
BU is not same as the COA (alt-COA) addr. In that case,
the above COTI rule applies.
The other example of multihomed hosts seem to be implementation
specific. A implementation may choose to set a particular source
address corresponding to it's transmitting interface. 
But the COT message is always sent to the COA of the MN, so the
receiving physical interface must have the COA or it could be
one of the interfaces of a multihomed MN. Is that what you mean ?

Thanks,
-Samita

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 28 Mar 2002 08:56:08 +0100

> could be sent from elsewhere. Ok for everybody?

=> Yes I think you would have to. 

Hesham

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 28 Mar 2002 10:15:25 -0800

> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Thursday, March 28, 2002 10:10 AM
> To: Mohan Parthasarathy
> Cc: Erik Nordmark; [email-masked]
> Subject: RE: [mobile-ip] Comments on Draft 16
> 
> 
> > I don't think I have spent enough time reading the latest 
> (146 pages 
> > ?) MIPv6 draft I guess :-) So, for the HA case, as there are no 
> > cookies we need to store it in NV for preventing replay 
> attacks. I am 
> > not able to see how you can ever remove this entry from NV. 
> As soon as 
> > you remove it, a old binding update can be replayed and will be 
> > accepted I guess.
> 
> Yes, but a home agent also need to permanently retain 
> information about the MNs it is serving such as
> 	home address		manual IPsec key	# if manual keys
> 	home address		certficate		# if IKE is used
> [IKE could presumably use pre-shared keys etc. as well.]
> 
> The only additional requirement due to the sequence number is 
> that it will change as bindings are processed.
> 
Ok, that puts things in perspective :-) But may be I am reading into
what NV memory is i.e the above are generally not stored in NV memory.
That sort of strikes as a new and different requirement which in
practice
is not. So, perhaps it can be reworded or just state what you have said
above which makes it very clear.

-mohan

>   Erik