[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question on inbound IPSEC policy check


Shall we igonre the text note that i refered to in section 5.2.1 of rfc 2401.

And if that is the case, then   with the setup Jyothi has described the SA
negotiation should fail.


At 09:14 AM 5/2/03 -0700, Srinivasa Rao Addepalli wrote:
Hi Kent,
    Thank you for the clarification. As it stands today,
    implementations have to look for inbound SPD in their order
    and drop packets that don't match the policies.

> 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