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

[Stephen Kent <kent@bbn.com>]

Mike,
>
>
>I think what you're saying here is that there will no longer be
>separate inbound and outbound policy databases?

yes, that's what my revised processing model message said.

>Then much more
>of 2401bis needs major rewriting.

yes, we know, but Ted & Barbara wanted to have a version distributed 
to show what has been agreed to and updated so far.

>Is this being imposed by changes
>to IKE in IKEv2?

no. it's being done because if we think of the inbound and outbound 
databases as completely independent, we make it easier for folks to 
make errors in configuring them.

>I am finding having the separate policies for
>inbound and outbound very useful for debugging during development.

you still have to support separate inbound and outbound selector 
sets. However, you need to pair them.

>And I can even see an argument for one-way policies in general,
>for example, perhaps some kind of remote sensor.

then the part of the entry that deals with traffic in the other 
direction could be NULL.

>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.

Mike, the processing model does not mandate in detail how you 
implement the SPD. It provides a nominal model that your 
implementation should match, from an external perspective, with 
regard to management interfaces, etc.

>
>>
>>  >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?

yes, you are. unless one decorrelates the SPD, one cannot cache 
entries. 2401 did not discuss decorrelation and thus did not discuss 
caching, whereas 2401bis discusses both.

>
>>  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.

as noted above, you are free to implement these functions in any 
fashion you wish, so long as the externally visible operation matches 
what the model describes.

>
>>
>>  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.

A MUST is a pretty straightforward indication of a requirement, both 
here and in ALL IETF RFCs. Your cited text from 2401. We're writing 
2401bis now. If you want to be compliant with 2401, then you need to 
support the combination of AH + ESP. For 2401bis, you will NOT have 
to support this combination. If you have tracked the various 
discussion topics on the list, then you will note that we have 
proposed simplifying IPsec in 2401bis, removing support for certain 
features that were previously mandated.

>
>>
>>  >
>>  >	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?

Not exactly. As noted above, one cannot cache an SPD entry, unless 
the entry does not overlap with any other entry. Remember that the 
SPD is an order list and that entries may (and often do) overlap. So, 
taking an entry out of the SPD and putting it in a cache will not 
work, in general, unless the SPD is first decorrelated.

Steve