Re: Move TS to optional (RE: Don't remove TS from IKEv2)

[Dan Harkins <dharkins@tibernian.com>]

On Mon, 01 Apr 2002 15:06:59 PST you wrote
> Dan Harkins <dharkins@tibernian.com> wrote:
> [ ... ]
> >			    If you can manually configure protection of some
> > service on a compliant device using RFC2401 selectors and have it interoper
>ate
> > with your non-compliant implementation then I maintain you can allow your
> > IKE implementation to use the TS information it receives to establish them
> > dynamically. If you can do it manually you should be able to write code to
> > do it dynamically.
> 
> No, the problem is that my definition of a service is translatable
> neither to, nor from, a bunch of port numbers.

So that means that your definition of a "service" is not translatable to
an IPsec selector.

>    .... as long as they both allow the desired traffic, things work
> with manual keying...

To manually configure an IPsec-compliant device to "allow the desired
traffic" you have to map your idea of this "service" into a set of selectors.
Since your definition of a "service" can not be translated into an IPsec
selector you are therefore unable to interoperate with an IPsec-compliant
device when IKE is removed from your problemspace. Therefore, as I've been
saying for quite some time now, it is not an IKE problem.

>                        and would work with IKE if IKE didn't require the
> ends to describe in advance what traffic each SA would carry.

Manually keyed SAs require you to describe the traffic for each SA in
advance too!

  Dan.