Re: Is TS agreement necessary?

[Stephen Kent <kent@bbn.com>]

At 2:34 PM -0800 4/3/02, 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, 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.

Which new transport protocol are you talking about?

We're making a number of changes to IPsec based on experience and on 
new requirements.  For example, the new ESP version allows for bigger 
sequence numbers (to accommodate faster interfaces), support for 
combined crypto modes, and facilities for better traffic flow 
confidentiality.  The replacement for IKE will significantly reduce 
complexity, offer better DoS resistance, etc.  If you are referring 
to changes to representation of traffic selectors in IKE payloads, I 
should point out that some of these changes are putting back what was 
in the document that became 2401, but had to be removed just before 
publication, to accommodate some limitations in the current IKE 
negotiation capabilities.  So, any changes to accommodate dynamic 
ports, etc., are an important but small part of the overall set of 
changes we will make to these protocols.

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

we designed IPsec to not have to trust peers to do the right thing. 
we adopted a defensive posture consistent with the security principle 
of least privilege.  I'm not sure how to interpret your comments 
relative to this well known security principle.

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

Whoops, terminology error.  UDP is the transport protocol here. What 
rides above it is an application. I have a hard time interpreting 
what you are proposing given the combination of terminology errors 
and what I perceive as persistent vagueness in the examples.

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

Your descriptions have not yet convinced me, and others, that 
interoperability is achieved and at no loss of access control 
granularity.

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

that's a good starting point for being defensive.

>   Because there would
>be a possibility that the other end's implementation would lump more
>things together than you expect?

another good reason.

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

Ah, maybe I am beginning to understand your perspective. You want to 
remove existing access control features which have well defined 
characteristics and replace them with more abstract facilities. The 
exact implications of these more abstract facilities are less clear, 
because they have to remain abstract in order to facilitate the 
"freedom of implementation choice."

This really is not about implementation choices, but about the 
functions that a user can expect from an IPsec implementation. Within 
the current IPsec specs, there is freedom for different 
implementations, but the services provided should be predictable, 
objectively verifiable, and not open to ambiguous interpretation.  I 
consider those to be hallmarks of a good security protocol 
specification and in revising 2401, I hope to improve how we 
communicate the services offered, as well as expanding some of them 
to better meet the needs of users.

Steve