>
> Thanks for spelling out all the SPD entries. That clarifies the question.
>
> I'm afraid 2401 was not precise enough about this, and the text that
> describes how to match incoming traffic against the SPD in section
> 5.2.1 is poor and has been the source of confusion for many folks
> over the last few years.
>
> As you note in your example, if one merely checks inbound traffic
> against the SPD entry that was used to create the SAD entry, the
> intent of the inbound SPD may not be realized, because the SPD is
> ordered and allows overlapping entries.
>
> In revising 2401, we plan to use a different model for how one
> creates SAD entries from the SPD, and how one can use a cache of SPD
> entries to facilitate faster outbound processing. The concept that
> underlies this new model is that of a de-correlated SPD.
> De-correlation transforms overlapping entries into entries that no
> longer overlap, by creating additional, distinct entries.
> If one de-correlates an SPD, one can cache entries for outbound and
> inbound checks, because ordering no longer matters. That should avoid
> the problem you noted, since the de-correlated entries at SG1 for
> inbound traffic would include only one that covers traffic with
> source = officenetwork2, dest = offficenetwork1, protocol = TCP and
> dest port = 80, i.e., the one that calls for using ESP instead of AH.
>
> In IKE v2, because the headers from the packet that triggered the
> exchange are sent to the responder, the responder would create an SA
> that would be willing to receive traffic OTHER than the port 80
> traffic, avoiding the problem you noted.
>
> Steve