[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Checking incoming traffic against SPD
Fergus,
All SPDs are ordered. SAs may be part of SA bundles. This means that the
SAD entry for a given SA does not tell what other processing might have to
be performed on the packet, consistent with the SPD entry. That is what
motivates looking into the SPD to check and see that everything that should
be done has been done, after doing everything required by lookups into the
SAD based on SPIs and AH/ESP headers encountered during inbound processing.
Because SAs might be shared by more than one SA bundle (a complex feature
allowed by the architecture in response to concerns voice by implementors
and users who were concerned about creating largely duplicative SAs under
some circumstances), there may be a need to look at multiple (inbound) SPD
entries to ensure that the completed processing is consistent with at
least one of these entries. However, I defer to Charlie Lynn, who is
responsible for that particular piece of text. he may be able to provide a
better rationale.
The example you gave, re checking inbound traffic, omits the SAD check,
which is where on detects that a received packet does not match the
selectors for the SA in question, prior to looking at the SPD. The SPD
check is made after the SAD check, to ensure that all the processing
expected has been performed.
For example, if an SA bundle was established that called for tunnel mode AH
followed by transport mode ESP (looking at an end-to-end vs. SGW case). An
attacker could strip off AH and forward the packet to the destination. The
ESP header would find an appropriate match in the SAD, and the selectors
would match just fine. However, this would not be consistent with the
processing mandated when these SAs were negotiated, and so the SPD check
should discover that and reject the traffic.
Steve
Follow-Ups:
References: