RE: [IPsec] Use of SPD in verifying incoming packets

At 12:25 PM +0100 11/28/07, <Inger.Bohlbro@tietoenator.com> wrote:
>Hi,
>
>The text in RFC4301 page 24-26 regarding IKE negotiation is not 
>clear to me. It says
>       "For example, suppose one starts
>       with an entry A (from an ordered SPD) that when decorrelated,
>       yields entries A1, A2, and A3.  When a packet comes along that
>       matches, say A2, and triggers the creation of an SA, the SA
>       management protocol (e.g., IKEv2) negotiates A."  ...
>       "Alternatively, the original entry from the (correlated) SPD may be
>       retained and passed to the SA management protocol."
>I read this as IKE is allowed as an initiator to propose A in a negotiation.
>
>However RFC4718 page 21 (section 4.12):
>       "the initiator should not propose traffic selectors that 
>violate its own policy. If this rule is not followed, valid traffic 
>may be dropped."
>
>Is RFC4718 overruling RFC4301 on this point ? Saying that A should 
>never be proposed, but "only" A1, A2, A3 proposed.
>
>If this is the case then I understand that inbound traffic arriving 
>on an SA need only be validated against the SA and need not be 
>verified against the access control policy expressed in the 
>(ordered) SPD.
>
>Regards
>Inger Bohlbro

Thw statements in 4301 and 4718 are not really contradictory.

Since A is in the SPD, it is allowed under the 4718 criteria you 
cited. It is preferable to pass A1, A2 and A3, because they allow the 
responder to more accurately match the initiator's policy to theirs, 
but either approach is allowed for the initiator.  The responder MUST 
respond with a TS set that reflects the intersection of the 
initiator's proposal and its SPD.

If an SPD is not de-correlated, then the access control check for 
received traffic is problematic. If the receiver caches the SPD entry 
A in the SAD, that may give a false acceptance for received traffic, 
which is not OK. To be secure, the receiver needs to process the 
received traffic against the ordered SPD, which is a slow process. 
That's why we specified proper operation for IPsec relative to a 
decorrelated SPD model.

Steve