RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt

["Mike Taylor" <mtaylor.eng@sbcglobal.net>]

Hi All,

Some comments about the 2401bis draft.

Section 4.4.1 The Security Policy Database

		"...In order to support this, the SPD requires
		distinct entries for inbound and outbound traffic."

	and a few paragraphs later

	   "- each SPD entry is a list of 1 or more selector set pairs - each
	   selector set pair consists of one selector set for the SA from the
	   initiator to the receiver and one selector set for the SA from the
	   receiver to the initiator."

	I don't understand (maybe because I don't yet understand IKE very well)
this
	second paragraph, especially given the prior sentence which indicates
	that the SPD entries for inbound and outbound are separate, as they
	were in 2401.  The second paragraph seems to suggest that an SPD
	entry is bidirectional.  What am I missing?

Section 4.4.2 Selectors

	Still requires that both SPD entries and SAs carry selectors,
	and still requires separate SAD entries for ESP and AH, so that
	if I have a incoming datagram which must be processed through both
	AH and ESP then I can't really make any use of the selectors in the
	AH SA because until the datagram has also gone through ESP the
	selectors are opaque.  From a practical implementation standpoint
	I certainly don't want to waste memory (in my embedded system)
	on information I can't use.

	And of course the RFC mandates that that after processing
	through the SAs the selectors in the datagram must be matched against
	the SPD entry:

	5. IP Traffic Processing

	   As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
	   the SPD must be consulted during the processing of all traffic
	   (INBOUND and OUTBOUND), including non-IPsec traffic.

	Why, if I really have the selectors stored in SAs, would I do this
	on the inbound side in particular?

	Not to mention the wasted CPU cycles matching the packet against
	selectors in the SA and then doing it again for an SPD entry.

	On the outbound side I have to match against the SPD 1st and then
	I guess I could conceivably have multiple SA bundles that have
	different selectors that could match the same policy based on the
	following from 4.4:

	   "For each selector, the policy entry specifies how to derive the
	   corresponding values for a new Security Association Database (SAD,
	   see Section 4.4.3) entry from those in the SPD and the packet (Note
	   that at present, ranges are only supported for IP addresses; but
	   wildcarding can be expressed for all selectors):

           a. use the value in the packet itself -- This will limit use of
the...."

	So I could look through that list to find the right one to use.  But that
would
	suggest some sort of best-fit matching which isn't mentioned anyplace, or,
	I could use the 1st matching SA bundle that I find, BUT, this would seem to
	require that the SAD also support total ordering of entries and only the
	SPD is required to support total ordering that way.


In summary, should any of these requirements, in particular the need to
allow
specification of how selectors for SAs get inherited from SPD entries,
really be
requirements?

Should it even really be a requirement to have separate SAD and SPD entries?
Couldn't adequate security and interoperability be achieved without this
requirement?


I guess I'm just begging for simplification.  Let's focus on getting the
true requirements for good security and interoperability spelled out very
clearly, and not keep all these implementation details from 2401 in 2401bis.
For small embedded systems its essential to clearly spell out the the
requirements rather than implementation details as there is always a desire
to conserve memory and CPU resources in such systems and yet be able to
comply
with the functionality that is truly required.  Please don't assume that
everyone
who implements code per RFCs is only interested in multi-user systems and
high-end workstations.


- Mike Taylor