Re: Question on inbound IPSEC policy check

["Srinivasa Rao Addepalli" <srao@intotoinc.com>]

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
Srini

Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com
----- Original Message ----- 
From: "Stephen Kent" <kent@bbn.com>
To: "Jyothi" <vjyothi@intotoinc.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Friday, May 02, 2003 8:13 AM
Subject: Re: Question on inbound IPSEC policy check


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