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

[Jari Arkko <jari.arkko@kolumbus.fi>]

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.