[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.
> 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
> 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.
> 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.
> 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...
Follow-Ups:
References: