[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: use of client IDs
This seems reasonable. But, I would like to add the following. It
seems like there is a disconnect between IPSEC policies, and IKE IDs.
Here is what I see.
The IPSEC Arch draft specifies selectors which should be used in
policy lookup, and says that policies should be ordered and searched
in order. Also, the policy determines what action to take: apply
IPSEC (using an SA), discard, or bypass.
In IKE the IDs try to determine which IPSEC packets should be
protected by the SA being negotiated.
But, the mapping between these IDs and the policies seems to be
muddled.
It seems to me that the ID should be a special Policy ID which is
negotiated. But, since there isn't currently a current way to
negotiate policies or even inform the other side about our policies,
this wouldn't work.
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.
Does this make sense, or am I missing something fundamental here?
- chrisb
On Sun 21-June, Bryan Gleeson wrote (id <EBE4A6EB7EB0D1118D1C00A0C98313321D846F@shasta-pc.shastanets.com>):
%
%correcting my previous post ...
%
%> ... Thus the semantics of an absent client ID are "anyone
%> behind this trusted gateway", not "anyone".
%
%Dan pointed out that this is completely wrong. What I meant
%to say was "the semantics of an absent client ID *should be*
%anyone behind this trusted gatway ..."
%
%Bryan
%
References: