Re: Don't remove TS from IKEv2

[Mike Ditto <ford@incog.com>]

Bill Sommerfeld <sommerfeld@east.sun.com> wrote:
> > The point is that SOI should negotiate keys and SAs, but since each
> > endpoint already has a policy that it must apply on every packet
> > anyway, we don't need key management also to give policy
> > refinements.
> 
> As I've explained repeatedly, this is true only when there is
> centrally provisioned policy.

I don't think I understand this.  Why does it matter where the policy
comes from?

Each endpoint knows what traffic it is willing to accept and send on a
given SA.  Knowing in advance what your peer will or won't accept
isn't necessary, because the peer will let you know if you violate its
policy.  Telling your peer in advance what you will or won't accept
isn't helpful, because you still have to check to make sure that the
peer doesn't violate your policy.

Perhaps you're saying that centrally provisioned policy is another way
of avoiding mismatched policies, and traffic selector negotiation is
trying to solve the problem when there is no centrally provisioned
policy.  I claim that traffic selectors don't solve any real problem,
no matter how policy is derived.

> > Additionally, no existing or proposed traffic
> > selector notation can describe all commonly used services.
> 
> That's setting a rather high bar, isn't it?

I don't think so.

> The use of SA's at transport-connection granularity in conjunction
> with looser-grained policy will work for a very large proportion of
> services, and works today in Sun's implementation.

The question is:  Does the more complicated protocol make it work
better than it would otherwise?

					-=] Mike [=-