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

[Dan Harkins <dharkins@tibernian.com>]

On Fri, 29 Mar 2002 19:18:12 PST you wrote
> 
> I'm speaking with knowledge of a particular implementation, a moderately
> successful commercial product that has implemented IP layer security for
> 6 years.  It does this without any need for "traffic selectors" because
> it was designed before IPsec was standardized and originally used SKIP,
> which does not support multiple equivalent SAs between the same
> endpoints.  We added IPsec protocols much later.  The version that
> supports IPsec is interoperable with (at least some) standard IPsec/IKE
> implementations when used in a single-tunnel-for-all-allowed-services
> style of operation.  It is, I believe, not interoperable with other IKE
> implementations configured to segregate traffic between SAs based on
> port number style selectors.  Why is this?  It is because IKE was
> designed with a concept of "service" that is not compatible with our
> basic design.  

No, it's because this is still not an IPsec-compliant implementation.
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.

The specification deals with more than producing and consuming packets
of a certain format. If you do not have any "traffic selectors" then
you are not RFC2401 compliant. It is not surprising that you're having
trouble interoperating with an IPsec compliant implementation that is
doing things which are completely valid according to the specification.

> > But if it's the term
> > "policy" that is causing this confusion then don't think of it as "policy".
> > It's the set of traffic selectors that specify "protect".
> 
> But again, I don't have those selectors, and I can't fabricate selectors
> that actually correspond to the policy, because I support services that
> do not correspond directly to port numbers or other things that the
> traffic selector notation can represent.

Again, then this is not an IPsec compliant device. You're asking for IPsec
to change so your non-compliant implementation which has some nebulous
classification scheme (that does not use RFC2401 selectors) can interoperate
with an IPsec compliant device. 

> > It actually does work in real life.
> 
> I'm sure it does with implementations that are designed from the start
> with the same limitations as IKEv1.  I'm hoping for something better.

If what you have today is so wonderous and does not suffer from these
"limitations" then don't just sit and snipe and hope. Write a draft that
specifies how traffic should be classified without selectors. Then once
you've done away with selectors there will be no need for an SA establishment
protocol to use them.

What you have proposed so far not only does not solve the problems with
the current approach (the desire to specify a protection of protocols that
float ports such that all the ports it uses are under the protection of a
single SA) it actually creates other problems (that have been discussed
earlier in this thread).

  Dan.