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

From: Joy Latten <[email-masked]>
Date: Fri, 09 Nov 2007 12:17:12 -0600

RFC 4301 Section 5.2 describes processing inbound IP traffic. 
After applying AH or ESP processing, the packet is matched against the
selectors of SA used to verify appropriate SA was used. Then 
handed up to transport model, forwarded, etc.. 
There is no mention of SPD needing to be consulted also for
this verification. 

RFC's 2401 description of inbound processing
found in section 5.2.1 included finding an incoming policy in 
SPD that matched the packet as part of verification process. 

In rfc 4301 in section 13 describing differences from 2401, I did 
not see anything stating this difference. 

Thus I am not sure if I am interpreting correctly and would like 
some clarification so I'll know if I need to modify existing
implementation to comply?

regards,
Joy   

_______________________________________________
IPsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Fri, 9 Nov 2007 13:34:09 -0500

> There is no mention of SPD needing to be consulted also for
<SNIP!>

That's gotta be an oversight.  Either that, or it assumes Key Management is
infallible when it comes to setting up SAs that correspond precisely with the
state of the SPD.

Dan

---

From: Joy Latten <[email-masked]>
Date: Fri, 09 Nov 2007 14:11:20 -0600

> infallible when it comes to setting up SAs that correspond precisely with the

Ok, thanks, I was wondering. But then while implementing Name selector,
I thought, how would inbound ipsec packet verify against a named SPD
entry? I mean, for named spd entries as described in case 1, 
would not the responder have a named spd entry, such that when it
receives an inbound packet, it would not match...

I did see the following on pages 24 & 25 in rfc 4301,
  
  If the SPD is not decorrelated, caching is not allowed and an ordered
  search of SPD MUST be performed to verify that inbound traffic
  arriving on an SA is consistent with the access control policy
  expressed in the SPD.

However, since not mentioned in description for inbound processing,
became somewhat confused.  Especially when I started trying to 
understand how to implement named spd entries as in case 1.

regards,
Joy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Nov 2007 17:28:59 -0500

Joy,

The inbound processing diagram (Figue 3) shows how to process traffic 
in the context of a decorrelated SPD. That is a major improvement 
that we made in going from 2401 to 4301.  For traffic not protected 
by IPsec, there is an SPD-I cache that either allows traffic to 
bypass IPsec, or discards the traffic. For traffic that arrives via 
an SA, the diagram shows an SAD check in the lower right corner. That 
check replaces the SPD search that was described in 2301. Step 4 of 
the inbound processing description calls for IPsec traffic to be 
checked against the SAD entry for the SA via which the traffic was 
processed. The traffic selectors here should be the ones negotiated 
for the SA, whether the SPD was de-correlated or not.

I fear the text you cited on page 25-26 (not 24-25) is in error.  If 
one looks at the whole paragraph is says:

In all cases, when a decorrelated SPD is available, the decorrelated 
entries are used to populate the SPD-S cache.  If the SPD is not 
decorrelated, caching is not allowed and an ordered search of SPD 
MUST be performed to verify that inbound traffic arriving on an SA is 
consistent with the access control policy expressed in the SPD.

Note that his text refers to the SPD-S cache, a cache that is used 
only for outbound traffic, not inbound traffic. So the last sentence 
is a carryover from the old, 2401 inbound processing description, 
which we know to be deficient.

Sorry 'bout that.

Steve

---

From: Joy Latten <[email-masked]>
Date: Fri, 09 Nov 2007 17:09:46 -0600

On Fri, 2007-11-09 at 17:28 -0500, Stephen Kent wrote:
> in the context of a decorrelated SPD. That is a major improvement that
> we made in going from 2401 to 4301.  For traffic not protected by
> IPsec, there is an SPD-I cache that either allows traffic to bypass
> IPsec, or discards the traffic. For traffic that arrives via an SA,
> the diagram shows an SAD check in the lower right corner. That check
> replaces the SPD search that was described in 2301. Step 4 of the
> inbound processing description calls for IPsec traffic to be checked
> against the SAD entry for the SA via which the traffic was processed.
> The traffic selectors here should be the ones negotiated for the SA,
> whether the SPD was de-correlated or not.
> 
> decorrelated, caching is not allowed and an ordered search of SPD MUST
> be performed to verify that inbound traffic arriving on an SA is
Ok, thanks. That clears it all up for me.
Now the named spd entries also make sense to me. :-)

regards,
Joy

---

From: <[email-masked]>
Date: Wed, 28 Nov 2007 13:05:07 +0100

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

________________________________

From: Stephen Kent [mailto:[email-masked]] 
Sent: 9. november 2007 23:29
To: Joy Latten
Cc: [email-masked]; Dan McDonald
Subject: Re: [IPsec] Use of SPD in verifying incoming packets

Joy,

The inbound processing diagram (Figue 3) shows how to process traffic in
the context of a decorrelated SPD. That is a major improvement that we
made in going from 2401 to 4301.  For traffic not protected by IPsec,
there is an SPD-I cache that either allows traffic to bypass IPsec, or
discards the traffic. For traffic that arrives via an SA, the diagram
shows an SAD check in the lower right corner. That check replaces the
SPD search that was described in 2301. Step 4 of the inbound processing
description calls for IPsec traffic to be checked against the SAD entry
for the SA via which the traffic was processed. The traffic selectors
here should be the ones negotiated for the SA, whether the SPD was
de-correlated or not.

I fear the text you cited on page 25-26 (not 24-25) is in error.  If one
looks at the whole paragraph is says:

Note that his text refers to the SPD-S cache, a cache that is used only
for outbound traffic, not inbound traffic. So the last sentence is a
carryover from the old, 2401 inbound processing description, which we
know to be deficient.

Sorry 'bout that.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Nov 2007 17:55:16 -0500

At 12:25 PM +0100 11/28/07, <[email-masked]> wrote:
>Hi,
>
>The text in RFC4301 page 24-26 regarding IKE negotiation is not 
>clear to me. It says
>       "Alternatively, the original entry from the (correlated) SPD may be
>I read this as IKE is allowed as an initiator to propose A in a negotiation.
>
>       "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