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

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 28 Mar 2002 12:58:58 -0800 (PST)

Hi Jari,

As being discussed, section 4.5.4 "Securing Binding Updates to Hame Agents" 
needs some clarification on sequence number usage for HA and MN.

Vijay's description below clears concept for MN behavior in case it reboots.
As per Vijay's description on draft15, HA can accept BUs with any seq# after HA
 reboots as it does not keep the state upon reboot.

I am trying to understand how useful would it be to keep the seqno/MN 
information in HA's NV memory. If the HA reboots it looses all other
information including binding etc. But when the MN re-registers with HA
it'll use a seq#  higher than what's in the HA's NV ram.

Although, it adds extra replay protection at HA, I'd think, the
home-agent usage of NV memory could be optional. I'd like to know
how big is the threat in this particular case (i,e if HA reboots).
If we somehow decide that HA should preserve the bindings accross reboot,
then obviously, it makes sense to have all the information intact. 

Also this section mentions "The mobile node and homeagent MAY on a new key
for the security association before this many (2**31) BU have been sent if
this is an issue".
I wonder if we leave it as MAY, then there might be some interoperability issues
as MN and HA may have different expectations.

Please see my additional comments on draft 16 changes below.
       ==============================================

> 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?
> > 

<[email-masked]> wrote:

> 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.

More comments/questions on the new changes for draft16:

1. section 4.5.5, please clarify  in words how the Correspondent node
   secret key Kcn would be used. There is an example of MAC_Kcn in COT
   message processing, but that is not very clear.
   
2. In HOTI and COTI messages we use "nonce" index. What is "nonce" index?
   Is it a random number ? IBM has IPR on nonces, how different or same
   is this nonce index from IBM's nonces ? 
   
3. section 5.1.8 refers to "refresh" field. After last Connectathon and
   the followup discussion at IETF, I think we have decided to remove
   the "refresh" field as default and make it optional --correct ?
   
   More later.
   
   Thanks,
   -Samita

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 28 Mar 2002 17:11:49 -0500

I don't think it makes much sense storing the
BU sequence number in NV memory.  Since all BUs to
the home agent (home registrations) should be protected
by some kind of security (the latest specs mandates ESP),
then replay protection would be provided by ESP itself.

The home agent MAY store the key/cert in NV ram as Eric
suggested, but that completely depends on the configuration.

Just my thoughts.
-vlad 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		IPv6 Project Lead
Compaq Computer Corp.		
110 Spit Brook Rd ZK03-3/T07	Tel: (603) 884-1079
Nashua, NH 03062		Fax: (435) 514-6884

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Mar 2002 19:11:03 +0100 (CET)

> then replay protection would be provided by ESP itself.

My understanding is that ESP with manual keying can't provide replay
protection. Assuming we need this replay protection I think the choices
are
 - sequence numbers in nvram'
 - no manual keying - implement IKE (with at least pre-shared secrets) in
   all MNs and HAs

But I might be missing something.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Sat, 30 Mar 2002 17:51:21 +0200

>  reboots as it does not keep the state upon reboot.

Right, I believe what Vijay described does have a small vulnerability
in that after a reboot replays are possible.

> then obviously, it makes sense to have all the information intact. 

Yes. Why don't we use the -15 scheme, describe the remaining threat and
make the seqno-preservation through reboots a SHOULD (or a MAY).

> as MN and HA may have different expectations.

I don't think so. There has to be a key management scheme to change the key,
and I can only think of two: IKE and a manual change. In either case it will
be apparent if the other side does not support this activity. For instance, if
manual keying is used then the administrator either gets hold of the mobile node's
owner and asks him to change the key, or he doesn't ;-)

But perhaps we should clarify in the draft that the mobile IP protocol as such
will not start complaining about too old keys. So, as far as mobile IP concerned
this wrapping over is ok, and does not result in any error codes.

>    message processing, but that is not very clear.

This key is used by the correspondent node to accept only the use of cookies
which it has created itself. Adding some text...

>    is this nonce index from IBM's nonces ? 

It is just an efficient way to find the right nonce. Adding some text..

As for the IPRs, please tell me more! Do you have a pointer to IBM's
claim?

>    the "refresh" field as default and make it optional --correct ?

Jari