[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is TS agreement necessary?



Mike,

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

we have adopted the selector mechanism, in part, to allow sites to 
make the decision of what granularity of traffic muxing on an SA is 
acceptable.  this proposal takes away that capability and tries to 
substitute three options.  It is not clear that this reduced 
flexibility will meet all requirements now and going forward.  Also, 
the suggestion that "session" would be an implementation defined 
concept could pose serious interoperability problems, and it leaves 
prospective users wondering what will happen when their 
implementation interacts with another.

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

How? if the other end wants them to be separate sessions, won't it 
reject data traffic you send over the SA that was established first 
for control traffic?

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

It's always easy to imagine limited functionality implementations of 
a protocol for restrictive environments that might otherwise have 
some difficulty implementing the full set of required functions for 
the protocol.  20 years ago we saw that in LANs, where some folks 
decided that computing the TCP checkusm was a waste of time for 
traffic that was local to their LAN. Adoption of standards always 
implies compromises; a standard is rarely the optimal way to 
implement a set of functions for the full range of environments in 
which it may be employed.

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

In short, no.

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

As you noted, we need to have concrete proposals on the table for 
other options.  I would not be surprised to see the alternatives be 
more complex, but if the result is also less ambiguous than what I 
understand from above, the comparison is inappropriate anyway.

Steve