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

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

Hi Steve,

Thanks for your response.  I think it clarifies some
things but I'm still not clear on some points.
See below.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent
> Sent: Friday, October 31, 2003 10:26 AM
> To: Mike Taylor
> Cc: ipsec@lists.tislabs.com
> Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt
>
>
> At 8:23 -0800 10/30/03, Mike Taylor wrote:
> >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?
>
> the first sentence should not have use the term "entries." the
> inbound and outbound traffic distinction is covered by the
> initiator/responder distinction i the entry.

I think what you're saying here is that there will no longer be
separate inbound and outbound policy databases?  Then much more
of 2401bis needs major rewriting.  Is this being imposed by changes
to IKE in IKEv2?  I am finding having the separate policies for
inbound and outbound very useful for debugging during development.
And I can even see an argument for one-way policies in general,
for example, perhaps some kind of remote sensor.  Who knows?
And of course, pragmatically its far too late to change my current
design now.  I have separate policies.  But I'm not really doing
an IPsec v3 implementation anyway.  I was only looking to 2401bis
to clarify some of the confusion I found in 2401.

>
> >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.
>
> Each SPD entry must contain selector values because that is how one
> searches for the right SPD entry.

If SAs all have selectors one can envision having an outbound SA
cache and 1st searching the SA cache before bothering to look at
the SPD.  After all, this would generally reduce the amount of
time wasted looking at the SPD which is primarily used to create
new SAs but presumably the creation of new SAs occurs far less frequently
than the transmission of a datagram in most systems.

Am I missing something?

> The SAD contains values for extant
> SAs, and we put selector values there because we need to check
> inbound traffic to ensure consistency with the selector values
> negotiated during SA establishment.

But in my implementation I have back pointers from all SAs to
the policy that spawned them.  So when I'm done processing an
inbound datagram through an SA the SA knows where to find the
policy that contains the selectors.  So unless this inheritance of
selectors by SAs provides some required functionality from a blackbox
perspective (improved security and/or interoperability) that cannot
be achieved just as well with multiple policies it seems like one
could just as well only have selectors in SPD entries and none in
SAs, thereby possibly saving significant RAM for a small system
especially with 128-bit IPv6 addresses.

>
> In Ikev1, you could establish two SAs at once, for the special case
> of AH + ESP.  IKEv2 removed this special case feature, so now two SAs
> must be negotiated separately. the only way you can nest the two SAs,
> and thus apply both AH and ESP, is via creation and processing for
> both SAs. As noted in the revised processing model, nesting requires
> careful configuration of both the SPD and the forwarding tables, to
> cause the traffic to pass through IPsec processing twice, for both
> outbound and inbound processing.
>
> Frankly, the question I would ask is why (when) do you plan to use
> both AH & ESP? Given the current capabilities of ESP, we don't tend
> to see a need to use both.

Well, the problem from my perspective is that 2401 has so much
implementation
detail that it is very hard for me remain clear on what are requirements
and what are just suggestions.  For example, see 4.5 Basic Combinations
of Security Associations.  It shows the case of ESP in AH in transport mode
and begins with the sentence:

	"This section describes four examples of combinations for security
	associations that MUST be supported by compliant IPsec hosts or
	security gateways."

Aside from that, I've seen other references to the fact that since ESP
doesn't authenticate the IP header AH may still be useful for that purpose.
I'm a programmer, not an IT person.  I don't really know what people think
is useful on the real world and I don't have much marketing input.  So
I try to conform to the RFC's requirements.  If ESP in AH isn't useful
then the 2401bis should certainly make it clear that it isn't a required
basic SA combination.

>
> >
> >	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?
>
> this text is left over from 2401 and needs to be updated. it should
> now refer to SPD caches

SPD caches?  Another implementation detail?

> as the first place to look for outbound
> traffic, with reference to the SPD only if the packet cannot be
> matched to the cache. for inbound IPsec traffic, one matches against
> the relevant SAD entry. for other inbound traffic, match against the
> inbound cache, and look at the inbound SPD only if there is a miss.
>
> <SNIP>
>
> >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?
>
> I though we had done that, but if not, we will make it clear in
> the next rev.

From 2401bis:

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

Now that I re-read this again I see that the keyword MUST is indeed missing
from
the above sentence.  My apologies.  I'm actually rather aggravated by this
since
I guess I've been under the impression for some time that this was a
requirement.
Clearly that is my own fault, but its very easy to become confused when
there
is such a mix of informal implementation suggestions/hints mixed in
intimately
with actual 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?
>
> No. think of the SPD as the reference database that describes all
> possible SAs that might be created, whereas the SAD and SPD caches
> represent the SAs that have been created.
>
> >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.
>
> we don't make those assumptions, but we do require that all
> implementations interoperate, and that they provide users
> with a
> uniform, minimum set of management capabilities for access control.
>
> Steve