Re: Move TS to optional (RE: Don't remove TS from IKEv2)

["Scott G. Kelly" <skelly@SonicWALL.com>]

Hi Hilarie,

Comments inline below...

"The Purple Streak (Hilarie Orman)" wrote:
> I've found this use of the term "policy" confusing as well, but
> I've become accustomed to using a generalized notion.  In the generic
> meaning of policy, an SA represents a piece of policy, a rule,
> and changing anything about an SA constitutes a policy change.

I might go a bit further, and say that the SA represents a policy
instantiation: a particular instance of a policy as applied to a
particular class or set of traffic. Of course, this implies that I view
the policy as being spelled out in the SPD, and the instances as being
spelled out in the SAD, which sounds different than your view, based on
your comments above.

In any event, if the desired policy is to permit all FTP traffic between
two hosts to traverse a tunnel, and we cannot know the ports associated
with the data channel until after the session starts, are we changing
policy by dynamically associating the correct ports with the tunnel once
we know them? I don't think we're actually changing it; rather, I think
we are fulfilling it, assuming that we have provided a mechanism for
expressing such a policy in the SPD. This is very much like using a name
as a selector (e.g. a DN), and then associating numeric selectors with
the tunnel once the user is authenticated (i.e. once they are known).
And this would require no further protocol exchange, beyond the ability
to express the corresponding TS values in IKE.

> IKE is a key exchange protocol, not a policy manipulation protocol.
> I.e., if it doesn't involve the key, don't use IKE.

I appreciate the sentiment here, but I think people rightfully see IKE
as more than just a key exchange protocol, since it is an instance of
the Internet Security Association and Key Management Protocol. This
seems to imply that it should be used for SA management, along with key
exchange, and in fact, it is. I'm not sure at this point if I agree or
disagree with the need for a separate IPSP protocol for the
functionality we are discussing in this thread, but wanted to make this
point nonetheless.
 
> What I'd suggest instead is to define the requirements for SA, SAD, and
> SPD manipulation and use that as the start of a security policy
> protocol.  That is one of the goals of the IPSP group, and help with
> the requirements is definitely needed.  We have evidence from user
> protocols and routing showing the difficulty of the current IPsec
> methods.  It seems time to divide and conquer.

Scott