3 Apr 2002 19:33
Re: Is TS agreement necessary?
Scott G. Kelly <skelly <at> SonicWALL.com>
2002-04-03 17:33:02 GMT
2002-04-03 17:33:02 GMT
Hi Mike, Suppose, as you suggest, that we allowed negotiation of multiple SAs between two peers without specifying TS values. Ultimately, there must be *some* policy rule associated with each of these SAs since, as you suggest, the point is to somehow segregate traffic between them. That is, for a given SA, some traffic is allowed, and some is not. Please elaborate upon how we determine which traffic is appropriate for each SA once they are established. As an aside, can you tell us why wildcard TS values do not satisfy your requirements in the same way that omitting TS values would? Thanks, Scott Mike Ditto wrote: > > 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 [=-