[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On: Mon, 01 Apr 2002 12:14:16 PST you wrote
> Dan Harkins <dharkins@tibernian.com> wrote:
> > You would have this problem with SAs that were manually created that
> > segregated traffic between SAs based on port and protocol. This only
> > looks like an IKE issue because that is where your non-compliance is
> > first shown.
> 
> I don't think that's true, because with manual keying I can map services
> to SPIs with mutually agreed intended use.  It doesn't matter if the two
> implementations have totally different ways of representing policy if
> they are independently manually configured.  The problem is in trying to
> express "intended use" over the wire using a protocol that can't
> describe real services.

There is a one-to-one mapping between the selector parameters defined in
RFC2401 and the TS types. If you can manually configure protection of some
service on a compliant device using RFC2401 selectors and have it interoperate
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.

If the TS payload is incapable of describing the real service then so are
the selector parameters. And then, as I said, you would be unable to
interoperate with an IPsec-compliant device using manually-keyed SAs and
therefore this is not an IKE issue. It's an issue of your code not being
compliant.

  Dan.