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

RE: inbound policy verification

Folks,

I'm sorry for any confusion resulting from the note in section 5.2.  The
inbound SPD is ordered, just like the outbound SPD.  The destination
address, SPI, and security protocol type are used to select the proper SAD
(not SPD) entry to process the packet, e.g., decryption and authentication.
Then the selectors are checked based on the SAD (not SPD) entry.  At this
point we know the packet is from an authorized origin (of auth has been
selected) and that the selectors in the appropriate header match those
specified for this SA.

Only after this processing is there an SPD check.  That check ensures that,
if multiple IPsec protocols have been applied, that they have all been
applied in the right order, and if only one was applied, then only one was
intended.  That way one can detect stripping off a tunnel mode AH, for
example. Note that almost all of the processing we see now is for single
layers of IPsec, in which this should not be an issue.

Only two cases of required configurations yields multiple IPsec headers
that are parsed at the same point: AH then ESP in transport mode or AH or
ESP in tunnel, followed by AH or ESP transport.  These are sufficiently
simple that one could express the required conbinations in the SAD, without
referebce to the SPD.  The searching or linking to the SPD supports more
elaborate protocol combinations, for which support is not required.

The text suggests back pointers to the SPD as a way to make the mapping
work quickly (in these later cases), and allows an ordered search as a
simplier but less efficient alternative.  Perhaps we need to revisit the
viability of this alternative.  In any case, the concerns cited in recent
messages don't seem to match the required processing, as described in 5.2.

Steve