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

[Mike Ditto <ford@incog.com>]

> An implementation that has no need for selectors is not an IPsec
> implementation.

This discussion goes to one of the basic issues of IPsec use:  Why would
you want more than one SA between the same addresses and with identical
security parameters (identities, algorithms, etc.)?  Some people say
there is no need for such.  The alternative view says that it is useful
to segregate traffic by service or session between multiple equivalent
SAs, perhaps to prevent known plaintext attacks or denial of service
attacks between multiple users of a shared tunnel.  I concede that this
may be useful.  But what is a service, and what is a session?  Is it
reasonable to think that heterogeneous systems can describe services to
each other in an interoperable way?  If IPsec wants to support this
concept, shouldn't it do so in a way that allows each implementation to
implement reasonably complex services?  Or should it define an overly
simple concept of service segregation that may be difficult or
impossible to support in some implementations, and may be insecure?  I
claim that the current and proposed traffic selection concepts preclude
the secure use of some commonly used services, and preclude some
implementations that seem reasonable.

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.  I can't blame IPsec/IKE designers for this because I
don't think anyone (from this product's development group or elsewhere)
brought up this issue when IKE was standardized.  But now that the can
of worms is open again, I feel free to point out limitations that could
be avoided in the next go-around.


> > Traffic selectors as currently proposed are simple
> > sets of addresses, protocols, port numbers and the like.  My policy is,
> > in essence, a function that takes a packet as input and produces a
> > boolean output.  
> 
> No, it's a tertiary output. drop, bypass, or protect.

Not at this level of determining whether a packet is appropriate for a
given SA.  Only a binary classification is provided by the traffic
selectors; a packet either matches or it doesn't.


> 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.


> It's unnecessary to generate a set of selectors? How do you use IPsec then?

When an outgoing packet's policy (which is determined by a packet
classifier and policy database) specifies IPsec with particular security
parameters, I look for an SA with those parameters.  If there isn't one,
I negotiate for one.  The only information I have available to offer the
peer during this negotiation is information in the one particular packet
I have, and the security parameters from the policy.  (I also have a
list of abstract service names that have no portable meaning; some
people have suggested standardizing service tokens that could convey
this information.)  There are no "selectors" involved; the policy
database and packet classifier are opaque to the packet disposition
engine, and don't contain IPsec-style selectors even internally.

For incoming IPsec packets, I simply see if the SA's security parameters
match those of the decrypted packet's policy.  If I supported service-
based SA segregation, and IPsec provided a mechanism for me to do so,
this is where I would notify the other end of a policy mismatch, and
give it a hint how to resolve it (i.e., create a new SA, or use
such-and-such existing SA that is appropriate).


> 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.


					-=] Mike [=-