RE: Is TS agreement necessary?

["Rajesh Mohan" <Rajesh.Mohan@nexsi.com>]

> -----Original Message-----
> From: Scott G. Kelly [mailto:skelly@SonicWALL.com]
> Sent: Wednesday, April 03, 2002 9:33 AM
> To: Mike Ditto
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Is TS agreement necessary?
> 
> 
> 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.

In my case, on the sender side, I would decide on a tunnel based on VLAN ID or the port from which the packet was received. The selectors in IPSec makes it less flexible for applications like these.

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

0.0.0.0/0 is used to mean "allow tunnel traffic only". Something like "allow all traffic from tunnel" will be useful. A tunnel without selectors can be used for that.


> 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 [=-
>