[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: use of client IDs
On Mon 22-June, Bryan Gleeson wrote (id <EBE4A6EB7EB0D1118D1C00A0C98313321D84D7@shasta-pc.shastanets.com>):
%Chris,
%
%> In the mean time, for the ID, why not use as many of the selector
%> values as are needed to match your local policy for which you are
%> trying to build an SA. Of course this implies the policies are
%> similar on both sides. This way, the responder of the IKE negotiation
%> would use the ID to do a policy lookup. The SA negotiated would be
%> used for that policy.
%>
%> One outcome of this approach is that address ranges and subnets as
%> IDs would lead to ambiguous policy to ID mappings. But, if you ask
%> me, ranges and subnets seem an attempt to accomplish partial policy
%> negotiation anyway.
%
%Yes, and I think a general purpose policy exchange protocol, which is
%capable of representing the set of IP packets that will be transmitted
%onto an SA, is a difficult problem to solve. Because an SPD is an
%ordered list of selectors, you need to able to represent "the set
%of packets selected by entry 10, except for those selected by entries
%1 to 9".
I don't think this is a concern as long as the src outgoing policies
match one for one to the destinations incoming policy. The fact that
they match implies the ordering is correct. If a packet I send
matches my local policy which is different than the policy on the
receiving end the packet will not be accepted anyway. (Assuming the
two different policies are using different SA's.)
My main point is that in the absence of a complete policy exchanges
protocol, we should not try to convey policy information in IKE.
In the absence of policy exchange, it is up the people configuring
the devices to ensure outgoing policies on one end match incoming
policies on the other. Given his, IKE IDs should only contain the
information necessary to find that policy.
- chrisb
References: