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

[Michael Thomas <mat@cisco.com>]

I honestly don't see why MIP needs to go beyond
saying "use IPsec, beware manual keys". That is,
so long as there is a viable way of keying IPsec
which enables replay protection -- and there is --
MIP doesn't need to be any more specific *how* to
do that. If people want a lighter weight option
than either IKE, JFK, KINK etc, than that is a
IPsec WG problem. But MIP, IMO, doesn't need to
boil the ocean here. If it's an interesting
problem to solve for MIP, it's an equally
interesting problem to solve for a whole slew of
other protocols which might be protected by IPsec.
That is, generality good, one-off bad.

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.

		Mike

Jari Arkko writes:
 > Uri Blumenthal wrote:
 > 
 > > On Tuesday 02 April 2002 20:08, Michael Thomas wrote:
 > >  >
 > >  > If people want a "light weight" keying scheme for
 > >  > IPsec, it should either be pursued in IPsec WG, or
 > >  > through a BOF......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.
 > > 
 > > Actually, this is interesting - because indeed there are applications 
 > > and protocols that want to use IPsec for protection, but don't want
 > > to use IKE for key negotiation.
 > 
 > 
 > This is true, but from the point of view of Mobile IPv6, we didn't
 > really want to enter the discussion of key management protocols. (I'm
 > personally sure that Son-of-IKE will solve many of the problems IKE has,
 > though I haven't checked lately to verify this.)
 > 
 > Instead, what the Mobile IPv6 folks wanted to do was to use IPsec as-is
 > for certain tasks. One of these tasks was protection of BUs between the
 > MN and the CN. Now, our options in regards to this are as follows:
 > 
 > 1. Require IPsec + IKE. No replay problem.
 > 2. Require at least IPsec, but keep IKE as optional. Don't add
 >     any features for replay protection. Folks who don't use IKE
 >     will suffer from the replay vulnerability.
 > 3. Require at least IPsec, optional IKE but add an application
 >     layer feature for replay protection to prevent replays if
 >     you happened to not have IKE. This was the DT-recommended
 >     approach.
 > 4. Require at least IPSec and a TBD light weight key management
 >     scheme, perhaps optional IKE in some cases. No application
 >     layer features. Replay protection works perfectly for everyone.
 > 
 > Somehow I think that if we are targeting RFC in about a month or so
 > option #4 isn't going to give us that. However, this discussion has
 > caused me to rethink some of the reasons on why we recommended
 > option #3. Option #2 might also be quite reasonable, and would have
 > the added benefit that whatever the IETF keeps generating on the
 > key management front could easily be adopted whenever it becomes
 > available. KINK could be used in environments where it is available,
 > for instance, and Son-of-IKE when it gets ready. OTOH, the application
 > layer replay protection has* been in the mobile ipv6 drafts from the
 > stone age so I don't think that it's such a bad idea either.
 > 
 > Comments?
 > 
 > Jari
 > *) We have been discussing a modification of the replay protection
 > on the list, to require NV memory to be used or not.
 >