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

From: Erik Nordmark <[email-masked]>
Date: Mon, 1 Apr 2002 22:14:04 +0200 (CEST)

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

Stable storage at the HA for the seqno can presumably be a SHOULD, with
the ability to "lock in" on the first sequence number is receives from
a MN after rebooting.
But I thought the concerns were more on the MN side (where stable storage 
would often be implemented using NVram with a finite number of writes
during the lifetime of the memory.
We can't relax that constraint as far as I can tell.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Apr 2002 12:47:11 -0800 (PST)

> We can't relax that constraint as far as I can tell.

So, I'm pretty far behind here, but I'm having a
really hard time understanding why you'd want to
replace IPsec's replay protection when you have
key management. If it's there, it should be
used. Also: requiring home agent routers to store
*anything* on a per mobile node basis is going to
be unacceptible. Worse, the possibilities here of
missynchronized state seem really high. What
happens if they're out of sync?  How is it
corrected? Blech.

I really don't think we should be going here and
strongly object to making this a MUST. A SHOULD on
some form of key management (IKE, KINK, SOI) would
be a *much* better idea. Let us not forget that
keying is primarily a local policy issue, so
forcing a MUST IMPLEMENT here will not necessarily
get us any close to deployability.  Indeed, it
could delay it. Also: manual keying with IPsec is
a known problem, and should be addressed within
IPsec itself instead of special-casing mobile
IP. This would be a win-win. Some of our folks are
interested in this too, so contact me if you're
interested.

		Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 1 Apr 2002 22:52:46 +0200 (CEST)

> used. 

The issue on the table is based on the assumption that folks want to
secure the HA-MN using IPsec without IKE i.e. manual keys.
In that case IPsec doesn't provide replay protection as I understand.

> Also: requiring home agent routers to store
> be unacceptible.

With manual keys the HA must have a table with
	Home Address	Key(s)
With IKE the HA must have a table with e.g.
	Home Address	Certificate 
OR
	Home Address	CA+subject(alt)name in certificate
or
	Home Address	public key

Do you think you can avoid those and still get security for the home
registrations?

  Erik

> Worse, the possibilities here of

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Apr 2002 13:16:15 -0800 (PST)

> In that case IPsec doesn't provide replay protection as I understand.

   Correct. The better option here is to write a
   draft which solves this IPsec instead of
   doing a one-off for mobile IPv6. 

 > Do you think you can avoid those and still get security for the home

   Sorry, I meant storing stuff in non-volatile
   memory on a per mobile node basis. With key
   management, you don't need to store per MN
   data in non-volatile memory.

	   Mike

---

From: Brian Haley <[email-masked]>
Date: Wed, 03 Apr 2002 14:07:14 -0500

> the ability to "lock in" on the first sequence number is receives from

So how many MN/Seqno pairs does the HA need to store?  Seems like the number
could be quite large for HAs with lots of MNs (10K), which can be unwieldy,
since they can never be removed once created or we open a hole. And every time
the HA reboots it must re-load them from storage into some data structure -
yuck!
This looks more unattractive every time I think about it.

So is there a better way to solve this problem?  For manually keyed SAs between
a HA<->MN we could define a new sub-option that carries a timestamp (like
seconds since Mobile IPv6 became an RFC :), and the HA rejects BUs with the
timestamp out of a certain range.  Of course this would require synchronization,

but most MNs should know what time it is...

-Brian