[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use of client IDs
>
> Bryan Gleeson wrote:
> >
> > I'm new to the list and am unclear on when client IDs in a
> > Quick Mode exchange initiated by a security gateway are
> > mandatory and when they are optional, when establishing
> > an IPSEC SA.
>
> The ID payload is optional when the sender and receiver are to be
> considered to be the conversation endpoints. In that case, the IDs are
> implicit.
I believe, Client ID is mandatory when IKE key negotiator and the
client node for which it is negotiating are not the same.
Given that the ID payload serves the dual role of providing
identification as well as policy, this would become a requirement
when the policy specification is expanded to include trasport level
and other types of services.
>
> > From reading some of the specs it seems that for a security
> > gateway, the ID payload has been pressed into service as a
> > way of identifying the type of traffic that the gateway
> > intends to pump down an SA that it initiates (e.g. identifying
> > the source IP addresses of the traffic that will use the SA)
> > and so is in effect being used to convey selector information
> > between IPSEC nodes. This can then be used by the responder to
> > dynamically create an SPD entry corresponding to the new SA.
>
> I guess it's a matter of semantics, but personally, I would say that the
> responder would use the selector information to select an *existing* SPD
> policy entry from which to derive(i.e. dynamically create) the SA
>
I agree with what Bryan is saying here. But, SPD entries on a node cannot
be allowed to be dictated by the peering external node. I would state that
the responder would be expected to choose one of an existing matching SPD
entries or a subset of a matching SPD entry to correspond to the new SA.
Ideally, when the two parties have exact SPD entries (as far as traffic
between the two parties are concerned) on either side, there is no problem.
But, in the case where the SPDs do not match, the ID payload is supposed
to automate the policy selection criteria.
> > If it is the
> > case and a security gateway has multiple disjoint IP subnets
> > behind it, all of which could source packets to be sent on the
> > IPSEC SA, how should the client ID be set - use multiple ID
> > payloads, a different SA for each disjoint subnet, or something
> > else ?
>
> This isn't currently supported, but it has been discussed off the list.
> That was during last call for the current document set, so it wasn't
> proposed to the list. I will continue to hold off on posting the
> suggested mechanism to this list until the chairs release the finalized
> agenda for ipsecond.
>
Fair enough. I agree, it is important to have the drafts progressed into
RFC status.
When a secure gateway has multiple disjoint subnet or discrete hosts in
the policy, you could setup multiple SAs to accomodate them. In the
future, we need a way to clearly state the security policies; I.e., one
that would allow you to specify discrete hosts, range of hosts, protocols,
TCP/UDP ports etc. Otherwise, packets could get black-holed.
> > Another question is how optional the use of client IDs is for a
> > security gateway doing an IPSEC SA establishment. Is it ever
> > necessary to be able to use client IDs in order to interoperate
> > with another security gateway ? Put another way is a security
> > gateway acting as a client negotiator an optional feature, or
> > is "security gateway = client negotiator" always true ?
>
> It depends on the granularity of policy you would like to exercise, and
> on the policy configuration of the remote gateway. If you (and the
> other gateway) don't mind having all the traffic from one net to the
> other being funneled into one tunnel (using the same keys, etc), then
> you don't need to use client IDs. If you want finer control, with
> different policies applied to different hosts/protocols/ports, then you
> need client IDs.
>
Here is my thinking on this.
An IKE negotiator is an entity by itself, independent of whether it
is negotiating on behalf of a transport mode client (i.e., end host)
or a tunnel mode client(say, VPN gateway). The IKE negotiator entity
could be on the same node as the client for which it is negotiating
or it could be on an entirely different node.
So, it is important for the negotiator to identify the client for which
it is negotiating, especially when the client is different node/address
from that of the negotiator.
The ID payload semantics seems overloaded to carry both the client ID and
the security policy applicable to client.
> > Lastly the architecture draft models both an SPD entry and an SAD
> > entry as having a selector field. I'm a bit unclear on the need
> > for this. If an SPD entry points to a list of SADs (and the SADs
> > have backpointers to SPDs) wouldn't one selector associated with
> > the SPD do the job ? Under what circumstances would the SAD
> > selectors be different from their linked SPD selectors ?
>
> The line between the SPD/SAD is a bit blurred in this respect, and I
> personally would say this is an implementation detail. However, there
> are others here who might disagree...
>
Well, there are many cases where an SPD selector could differ from an
SAD selector. If the selection criteria is set to be based on packet
(as opposed to policy), every new packet matching the same policy but
differing in one regard(say, IP address or TCP/UDP port) would require
a new SA.
In the case where selection criteria is set to be based on policy,
the SA selection would match the selection of an SP. It is also
possible for an SA to match multiple policies.
Hope this helps.
cheers,
suresh
Follow-Ups:
References: