[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Checking incoming traffic against SPD
> 3. Find an incoming policy in the SPD that matches the
> packet. This could be done, for example, by use of
> backpointers from the SAs to the SPD or by matching the
> packet's selectors (Inner Header if tunneled) against
> those of the policy entries in the SPD.
>
> 4. Check whether the required IPsec processing has been
> applied, i.e., verify that the SA's found in (1) and (2)
> match the kind and order of SAs required by the policy
> found in (3).
>
> NOTE: The correct "matching" policy will not necessarily
> be the first inbound policy found. If the check in (4)
> fails, steps (3) and (4) are repeated until all policy
> entries have been checked or until the check succeeds. "
>
>
> Question: How can the first inbound policy found not be
> -------- the correct policy, except when security
> gateways are inconsistently configured ?
>
>
This can occur because the inbound security policies (SP) are not required
to be in order. So if you do the inbound verification by matching the
selectors to the inbound SP list, you could hit a policy that matches but
the SA does not. You must keep checking to find the correct SP. An
alternative is to use the SA found during the inbound packet processing and
do a check of the SP (if the SA has a back pointer to the SP). However in
the case of bypass or drop, no SA is found and you still need to search the
inbound SPs.
A previous email mentioned this occurs due to the sharing of SAs. Can you
even share SAs since they are really instantiations of the SP entry (many
SAs to one SP)?
Aaron
Follow-Ups:
References: