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

[Michael Thomas <mat@cisco.com>]

Uri wrote:

> On Wednesday 03 April 2002 11:12, Michael Thomas wrote:
> > I honestly don't see why MIP needs to go beyond
> > saying "use IPsec, beware manual keys".=20
> 
> Because nobody really WANTS to use manual keys?
> And because while IKEv1 is a hog (and no real negotiation
> seems necessary),  something VERY light-weight is needed?
> 
> >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.
> 
> Don't you think there might be interoperability issues if the exact way=20
> of keying IPsec  is omitted?  Also, creating SA is *more* than just=20
> keying.=20

  I don't think that "interoperability" is quite
  the right word here. A mobile node and home agent
  which run IPsec/IKE could be interoperable.
  However, in practice unless I am part of that
  domain, know the right authentication
  mechanisms, etc, we might not be able to 
  mutually authenticate. This is a deployment
  issue, however, not an interoperability issue.

  Use of IKE, SOI, KINK, manualkey, manualkey+
  are all deployment isses, IMO. I don't think the
  IETF needs to be in the business of saying which
  choice to make here, and certainly not MIP WG.
  I think it's quite reasonable for MIP to say
  that something better than straight manual keys
  is needed, but specifying how it's accomplished 
  shouldn't be a requirement any more than MIP
  shouldn't be saying that you must implement IKE
  with certs or IKE with pre-shared keys, or IKE
  with AAA hacks, or whatever.

> 1. "Negotiate on paper" - i.e. define most if not all the attributes of=20
> SA that should satisfy usage criteriae (including the crypto suite).
> 2. Select a simple key agreement protocol (any Bellare-Rogaway=20
> derivative should do nicely) - such as *interlocked* CHAP or AKA.
> 3. Specify all of the above in a generic draft.

  IMO, at the point you have to put a shared key
  into both boxes, you might as well put the rest
  of the information in there too. At the point
  you want to start negotiating stuff, you've
  already gone beyond "lightweight" IMHO :-)

> > 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.
> 
> The above doesn't make sense, because you *have* to have something in=20
> NVRAM regardless. The question is - exactly what. And a simplified=20
> approach allows you to "memorize" less than IKE or JFK would=20
> require.=20

  You don't need *per node* permanent memory for
  IKE/KINK/SOI. That's the difference.

		       Mike