Re: Specification of tunnel/transport attribute in IKEv2

[Markku Savela <msa@burp.tkv.asdf.org>]

> From: Dan Harkins <dharkins@tibernian.com>
> Sender: owner-ipsec@lists.tislabs.com
> Precedence: bulk
> 
> On Wed, 22 May 2002 09:17:00 +0300 you wrote
> > 
> > The original IKEv1 actually had almost sufficient fields for the
> > "TS-like" information, except when implementations tried to
> > re-interpret them as policy selectors, everything went horribly
> > wrong... 
> 
> Horribly wrong? The only trouble that is caused seems to be some
> affront to your religous sensibilities. But when everyone else is
> the heretic in your eyes maybe it's time to reevaluate your dogma.

Ok, I admit that saying "went horribly wrong" was a bit sentimental,
but pulling in term "religious" and "dogma" is not appropriate.

This is supposed to be technical discussion and I consider a
non-policy checking IKE technically a better solution to the problem.

- I believe it is a good architecture to clearly separate RFC-2401
  part of IPSEC from the key management,

- and implementation claiming to do RFC-2401, does all the necessary
  policy checks. IKE doing policy check is unnecessary overhead and
  makes IKE dependent on the policy data base.

- IKEv1 and v2 still cause unnecessary limitations to the
  possibilities that RFC-2401 allows (and removing these limitations
  from IKE by making it just a key negotiation, does not make IPSEC
  any more complex, as RFC-2401 compliant implementation will handle
  them automaticly):

  - shared SA's between bundles,
  - does not need to worry if one SA of a bundle expires before some
    other (it just gets re-negotiated on its own, if needed)
  - asymmetric SA's
  - separating policy selectors from those selector like constructs
    that differentiate SA's allows independent implementations and
    developement of SPD and SAD.

What I think needs to be done is

- phase 1 would be as is
- specify IKEv2 phase 2 negotiation to be just SA negotiation,
- you can optimize and have multiple SA's negotiated at same time
  (e.g. you can keep most of the current message formats, just don't
  put any significance to the ordering, just treat it as a collection
  of SA's to be instantiated)
- basic assumption is to negotiate uni-directional SA's. Again, as
  optimization, one could negotiate two-way SA's. But, for this to
  work, a new payload is required: it would contain the explicit
  selector information for the return traffic.
- the "TS" information only differentiates SA's (and is only remotely
  related with the policy selectors)