[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
use of client IDs
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.
>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. Is
this the case or am I way off in the weeds here ? 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 ?
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 ?
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 ?
Thanks in advance for any clarifications ...
Bryan Gleeson
Shasta Networks.
Follow-Ups: