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

[Stephen Kent <kent@bbn.com>]

At 12:04 PM -0800 4/2/02, Mike Ditto wrote:
>Dan Harkins <dharkins@tibernian.com> wrote:
>  > All I'm saying is that if a certain set of selectors manually configured on
>  > one end corresponds to whatever it is you manually do on your end 
>then there
>  > is a mapping between a set of IPsec selectors, and therefore an equivalent
>  > set of TS payloads, and whatever your configuration looks like.
>
>But the two ends' configurations DON'T correspond to each other.  Each
>end has a policy that describes a superset of the traffic that will
>actually be sent.  Probably both ends have defined a policy that uses
>the smallest superset that their respective policy notations allow.  But
>they are in general not the same superset if they do not use the same
>notation.  To require them to use the same notation is an unnecessary
>constraint on the implementations, and an unclean overlapping of layers
>of the security "stack".

I have to disagree with this assertion. The language used to describe 
security policies could, as you note, be a purely local matter, but 
to do so invites trouble. Security policies applied to IPsec SAs, 
unlike in most firewall security policy descriptions, must be 
compatible with the policies of peer IPsec devices with which 
communication is enabled. Thus it is appropriate to adopt uniform 
means of describing that policy, to facilitate secure communication. 
Abesnt a uniform means of describing a policy, two peers trying to 
communicate have a lot of ways to miscommunicate the policy and thus 
waste lots of time debugging mysterious problems.

IPsec allows for the user interface to represent policy info to a 
user or administrator in any fashion that is powerful enough to 
represent what the SPD mandates as a minimal functionality. There is 
not standard imposed on representation at that interface, which is 
consistent with the way most IETF standards work. However, 
transmission of the policy info via IKE payloads provides the 
standard representation I alluded to above, to minimize the 
ambiguities that might otherwise arise. There is no layer violation 
here.

>
>  > So it should
>  > be very straightforward for you to write some code to do that mapping
>  > dynamically.
>
>It's not.  What you seem to keep missing is that it is possible and
>useful to classify packets by criteria that don't directly correspond to
>port numbers.  There is no translation from such a classifier to a list
>of IPsec-style selectors.  The only thing that my policy and the other
>end's 2401-style policy have in common is that they both describe a
>superset of the traffic that will actually be carried, and they can both
>answer the "does it match" question about a particular packet.

Ultimately, whatever policy you employ is reducible to a set of 
syntactic checks on packets (plus, if you want to get fancy, maybe 
other inputs like TOD). The current set of traffic selectors was 
designed to accommodate a range of policies and we are planning to 
expand that range, to better accommodate the needs of users. Are you 
suggesting that the policies you perceive as necessary to express 
cannot be translated into some form of selectors, not just the 
current set but a more extensive set that we can provide going 
forward? If so, some examples would be useful.

>I know that the problem I'm describing is not a problem that past IPsec
>work has aimed to solve.  I wouldn't be spending so much effort
>describing a new problem that future IPsec designs could solve except
>for the fact that there is probably a common solution to this one and
>the problem of "dynamic ports".  They are essentially the same problem,
>that the traffic selection description is not flexible enough to
>describe more complex services.  They are different in that the dynamic
>ports problem can be solved by a more complex TS agreement mechanism,
>while my problem can not be solved that way.  I think they can both be
>solved by avoiding TS agreement.  When I have a more concrete proposal
>I'll let the group know.

Dynamic ports can be accommodated, I think, based on comments we have 
received from other developers. So, yes, we need a better description 
of your problem in order to understand what the issues are.

Steve