Subject: RE: [mobile-ip] Re: replacing IPsec's replay protection?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 1 Apr 2002 13:16:58 -0800

Erik,

> 
> 
> > 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.
> 
> 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.
> 
Are we sure we really want to allow this ? You may want to allow
the MN-HA to use pre-shared keys instead of certificates and
still use IKE. I don't understand why someone would want to
use manual keys.

> > Also: requiring home agent routers to store
> > *anything* on a per mobile node basis is going to
> > 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?
> 
Agreed, that HA needs to store some information per-MN.

-mohan

>   Erik
> 
> > 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: Uri Blumenthal <[email-masked]>
Date: Mon, 1 Apr 2002 17:29:15 -0500

> still use IKE. I don't understand why someone would want to

I think Erik meant "pre-shared" - how they got there is another story.

As for IKE - some people say it adds too much overhead (one of the 
reasons IKEv2 is being born :-).
-- 
Regards,
Uri
-=-=-<>-=-=-
<Disclaimer>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 2 Apr 2002 14:27:13 +0200 (CEST)

> still use IKE. I don't understand why someone would want to

I think there are people thinking about small mobile nodes
that might not want to require using IKE on those devices.
But I'm not one of them - perhaps they should speak
for themselves.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Apr 2002 17:08:26 -0800 (PST)

> But I'm not one of them - perhaps they should speak

Eric,

If people want a "light weight" keying scheme for
IPsec, it should either be pursued in IPsec WG, or
through a BOF. It most certainly should not be
done in MIP WG. As I've mentioned, there are some
of our folks who have some interest in this, and
their scheme doesn't require per node storage of
anything but the key and something akin to the
EngineBoots counter in SNMPv3. This would be a
much better solution to this problem.

	    Mike

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Apr 2002 20:02:52 +0300

Michael Thomas wrote:

> I honestly don't see why MIP needs to go beyond
> saying "use IPsec, beware manual keys". 

 > ...

> In any case, my larger point here is that a
> mandatory mechanism for MIP which requires per
> node consumption of NVRAM on a Home Agent as a
> MUST IMPLEMENT, where IKE, JFK, KINK, etc don't
> place any such requirements on IPsec seems
> onerous, and should be optional. Ideally, it
> would be one of a set of acceptible choices.

You may have a point here. How about this:

1. We require at least manual IPsec
2. We provide application layer sequence#
    in order to order BUs (not just prevent replay)
3. We point out that if the HA reboots and loses
    state when only manually keyed IPsec is used,
    replays become possible (vendors can still
    prevent losing state if they want to)

Jari