[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: use of client IDs

	Scott, 
	could you please be a little clearer (or give examples) about
your statement:
	 
	" 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."

The question is about a gateway so the key neg has to be for tunnel
mode. 

-CJ


	-----Original Message-----
	From:	Scott G. Kelly [SMTP:skelly@redcreek.com]
	Sent:	Thursday, June 18, 1998 10:05 AM
	To:	Bryan Gleeson
	Cc:	ipsec@tis.com
	Subject:	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: