Re: Is TS agreement necessary?

[Mike Ditto <ford@incog.com>]

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

Any transport protocol for which traffic segregation is desired.
IPsec is currently specified with special case handling for TCP and
UDP.  A clean network-layer security protocol would not overflow into
the transport layer like that.

I think it's great that the IPsec documents give special emphasis to TCP
and UDP when explaining processing or describing a model implementation
or policy notation, but the protocols and the normative behavior
specification should have stayed cleanly within the network layer.


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

 >From a security point of view, traffic segregation inherently assumes
a degree of trust of the peer.  You can't enforce that the peer or
something beyond it doesn't leak everything between the SAs.  You can
still fully enforce access control, and my proposal doesn't reduce
that.


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

My mistake there is related to a part of my point:  policy enforcement
should not always be focused at the transport layer.  As for the
specific example, call it an application protocol, or modify my example
to say "IP protocol 234" instead.  The point is that locking the
definition of a session into the SA establishment protocol, based on
two specific transport protocols, is constraining on implementation
choices, on growth, and on the actual functionality that the system can
provide.  Current network security products classify traffic into
sessions by many criteria other than TCP/UDP port numbers, and future
ones will want to do things that haven't been thought of yet.


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

I haven't suggested any change to access control granularity.  The
policy is still applied to every packet, and if you like, you can still
implement that policy using RFC2401-style selectors.

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

Defensive against what?  As I said, traffic segregation already assumes
some trust of the peer.  Is there a vulnerability or not?

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

Again, I have to point out that the peer has full access to and control
over the data flows at the other end.  If your end considers two packets
to belong to two different sessions, and the other end considers them to
be part of the same session, your expectation that the other end will
respect your segregation desires seems misplaced.


					-=] Mike [=-