[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