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

Re: Is TS agreement necessary?



On Wed, 3 Apr 2002, Mike Ditto wrote:

> Stephen Kent <kent@bbn.com> wrote:
>  > 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,
>
> I agree.  But it's clear that the present model doesn't meet all
> requirements now and going forward,

Well from what I can tell not everyone agrees with your
requirements. If you have a set of requirements that aren't included in
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt
(which you of course have read, right?), then please write a new
section and post it to the list and let's discuss whether the group
agrees to these new requirements.

jan


> as demonstrated by the need to
> make significant changes to IPsec for a new transport protocol.  I
> think it's a serious design flaw that IPsec standards and
> implementations have to be changed to accomodate a new transport
> protocol.  My proposal would eliminate that dependency.
>
>
>  > 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.
>
> I don't think so; see below.
>
>  > >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?
>
> No, that's the core of this idea:  the receiver trusts the sender to
> make segregation decisions.  If the peer starts sending you stuff that
> your policy allows, but you weren't expecting to arrive on that
> particular SA, adjust your expectations to match the sender's choice.
> This guarantees interoperability even in the face of very different
> implementations and their ideas of service and session.
>
> Suppose my implementation supports a new transport protocol which is,
> say layered on top of UDP port 12345, and I want to segregate my
> different sessions within that protocol on different SAs.  It would be
> nice if I could do that without changing IPsec and IKE and waiting for
> the other end to upgrade its implementation.  Of course if the other
> end doesn't know about my special protocol, it won't do segregation
> beyond what it knows (lumping all of UDP port 12345 together), but it
> will interoperate and I can at least segregate my outbound traffic.
> And if the other end does know about my new transport protocol
> (perhaps it's running my implementation too), the desired behavior is
> achieved without having to violate or update the IPsec standards.
>
>
>  > >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.
>
> Right.  That's why I think it's a valuable property of my proposal
> that interoperability is maintained without having to negotiate the
> use of an optional feature... it just works if one side (or both)
> decides to use completely shared SAs.
>
>
>  > >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.
>
> OK, why?  Is it becuase you (as a user/policy administrator) really
> don't trust the other end to do as much segregation as you want, and
> you want it to be strictly enforced by your end?  Because there would
> be a possibility that the other end's implementation would lump more
> things together than you expect?  I can understand those complaints,
> but to me, some vagueness in the details of traffic segregation is
> a small price to pay for increased interoperability, simplicity, and
> freedom of implementation choice.
>
>
> 					-=] Mike [=-
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847