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

Re: Question on inbound IPSEC policy check



Hi Ramana,
    As Kent mentioned, in quick mode, implementations send selectors
    defined in the SPD policies. Due to this, quick mode initiation by
    SG2 will succeed as SG1 has policy associated with these selectors.
    But,  HTTP packets will be dropped by SG1 as it does not match 
    SAs in SP with HTTP selectors. It is configuration issue between
    two administrators and for now, it has to be resolved out of band way.
Srini

Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com
----- Original Message ----- 
From: "Ramana Yarlagadda" <ramana.yarlagadda@analog.com>
To: "Srinivasa Rao Addepalli" <srao@intotoinc.com>; "Jyothi" <vjyothi@intotoinc.com>; "Stephen Kent" <kent@bbn.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Friday, May 02, 2003 11:38 AM
Subject: Re: Question on inbound IPSEC policy check


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