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

RE: draft-ietf-ipsec-arch-sec-02.txt and last call

Stephen,

I have a question on the third paragraph of page 14, "The SPD contains
an ordered list of policy entries." Does this imply that the SPD entry
ordering defined by the administrator through the administrative
interface is the sequence used in searching for the right SPD entry ? 

Let me give an example here. If a firewall has the SPD entries defined
as the following:

1. Host A -> Subnet B, discard
2. Subnet A -> Host B, bypass
3. Host A -> Host B, IPSEC ESP 3DES-CBC w/ HMAC MD5 
(Assuming each host is in its respective subnet, i.e., Host A in Subnet
A.)

If implementation is IPSEC compliant then all traffic from host A to
host B will be discarded (matching the first entry). Right ? 

If an implementation can ensure that the search will always produce a
consistent and predictable result without imposing the canonical
ordering of the SPD entries then is it IPSEC compliant ? For example, if
my search is based on the explicitness of the selectors and always
locates the entry that has the most explicit selectors first, then is it
IPSEC compliant ? 
(A host is considered more explicit than a subnet and a subnet is more
explicit than a wild card.) In the example above, the search will locate
the third entry as matching instead.

It seems to me that if imposing the canonical ordering on the SPD
entries then for every packet there is an overhead which on the average
is proportional (linearly) to the number of entries in SPD because the
search is sequential. 

-Brian

	-----Original Message-----
	From:	Stephen Kent [SMTP:kent@bbn.com]
	Sent:	Friday, November 21, 1997 8:10 AM
	To:	Michael Richardson
	Cc:	ipsec@tis.com
	Subject:	Re: draft-ietf-ipsec-arch-sec-02.txt and last
call

	Mike,

		Having watched the reverse chronological Seinfield
episode last
	night, I'll respond to your final observation first; the
ordering
	requirement for SPD entries is not new.  It was  present in the
7/30
	version of the security architecture document as well as the
current
	version.   If an administrator cannot determine the order for
SPD entries,
	then it will not be possible to express some policies, because
of overlaps
	in selectors and an inability to impose a canonical ordering on
the
	selectors.  Hence the motivation for that requirement.

		As for the question of the level of administrative
control required
	by the arch doc, you are right that it requires the ability to
specify
	packet processing, incluidng discard, at the granularity of
ports, etc.
	For example, a  user of a security gateway might want to allow
SMTP traffic
	through (w/o IPsec processing) if addressed to a mail server
behind the
	gateway, but require IPsec for other traffic to that or other
hosts behind
	the gateway.  That level of control will be available only if
port-level
	SAs are supported.  The question is whether the WG wants
compliant
	implementations to offer only a subset of possible, reasonable
policies.
	Unfortunately, this is an interoperability issue, not just a
local matter,
	in that both ends of an SA need to be able to offer the same
granularity of
	selection.  Hence the inclusion in this document.

		Ultimately, the WG must decide what set of policies are
of
	sufficiently  general interest to warrent mandatory inclusion.
We did
	receive some private feedback on the 7/30 version of the
document and made
	changes to reflect those comments. Other than your recent
comments, we have
	received almost no feedback on this version, and the SPD
requirements have
	not changed substantively sibce then.  (The main change to that
portion of
	the document was to remove the notion of the SAM, an eficiency
hack that
	was not essential to explaining the administrative interface and
one that
	also had some technical problems!)

	Steve
Follow-Ups: