Is TS agreement necessary?

[Mike Ditto <ford@incog.com>]

Hypothesis:  If we were satisfied to let all traffic of equivalent
security characteristics (identities, transforms, etc.) share a single
SA (or to be distributed arbitrarily among multiple equivalent SAs), we
wouldn't need any traffic selector agreement (or negotiation, whatever)
protocol.  TS payloads tell the other end how you want your traffic
segregated between multiple equivalent SAs, and when it must negotiate a
new SA even though there already exists one with the right parameters.

In case I'm not being clear with terminology, by "traffic segregation" I
mean segregation of traffic from multiple sources (i.e. users) but
equivalent IPsec security parameters into different SAs to protect
mutually distrusting users against known-plaintext or DoS attacks from
other users of the same secure tunnel.

Eliminating TS agreement would solve the dynamic ports problem and
eliminate my other complaint about IKE, already much too verbosely
discussed recently here.  But then, how to solve the traffic segregation
problem?

What if this kind of traffic segregation was performed at the sender's
discretion?  I.e. each end independently decides how to segregate the
traffic it sends, and accepts the other end's choice as long as it meets
the general security parameters required by the policy.  During SA
establishment, the initiator specifies in an abstract way the degree of
sharing to apply to each proposed SA (pair).  I see three levels of
sharing being important: completely shared, unique address, and unique
session.  Unique address means that once the SA (pair) has been used to
talk to a particular remote address, it can't be used for sending to any
other remote address.  Unique session means the analogous thing with
session, where "session" is defined by the implementation.  A
recommended model for defining "session" would be based on the TCP/UDP
5-tuple, but implementations would be allowed to vary to some degree.

This way, if my implementation considers the control connection and the
data connections of an FTP session to be one "session", and the other
end considers those to be multiple distinct "sessions", there is still
interoperability.

It might be a good idea even to allow simple IPsec implementations
(e.g. for embedded use) not to implement traffic segregation, falling
back to "completely shared" SAs, in a transparently interoperable way.

Two questions:

Does this meet the requirements of those who strongly believe in the
importance of this kind of traffic segregation?  I'm not such a strong
believer; most of the scenarios I've heard where it's relevant seem to
have nearly identical weaknesses with and without traffic segregation,
or are better handled by assigning unique identities to the unique
users.  But I'll take others' word that it's an important capability,
and ask such people whether this proposal is sufficient.

Is this idea actually simpler than the workable alternatives?  I haven't
seen a concrete proposal for extending TS to handle dynamic ports, so I
can't offer an opinion on that alternative yet.


					-=] Mike [=-