[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: