Re: Question on inbound IPSEC policy check

[Ramana Yarlagadda <ramana.yarlagadda@analog.com>]

Hi,

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.

-ramana

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






> >
> > 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
>
>
>