Subject: Re: Question on inbound IPSEC policy check

From: Jyothi <[email-masked]>
Date: Fri, 02 May 2003 11:05:04 +0530

Hi,

I had a doubt in the following scenario:

>>Office1Network-----SG1---------Internet------------SG2-------Office2Network.

SG1 has two outbound and two inbound policies of auto key management

outbound policies:
1. source as office1network, destination as office2network, protocol as TCP,
    source port and destination port 80. IPSEC attributes: ESP, DES.
    This policy is configured with higher priority.

2. source as office1network, destination as office2network, protocol as ANY,
    IPSEC attributes: AH, MD5.
    This policy is configured with low priority.

inbound policies:
1. source as office2network, destination as office1network, protocol as TCP,
    source port and destination port 80. IPSEC attributes: ESP, DES.
    This policy is configured with higher priority.

2. source as office2network, destination as office1network, protocol as ANY,
    IPSEC attributes: AH, MD5.
    This policy is configured with low priority.

SG2 has one outbound and one inbound policy of auto key management:

outbound policy:
1. source as office2network, destination as office1network, protocol as ANY,
    IPSEC attributes: AH, MD5.

inbound policy:
1. source as office1network, destination as office2network, protocol as ANY,
    IPSEC attributes: AH, MD5.

SG2 started IKE negotiation with its configured IPSEC policy.

After IKE negotiation , IPSEC SAs will be created both sides with IPSEC 
attributes : AH and MD5.

When SG2 sends the HTTP traffic with the using above SAs,
SG1 process the inbound IPSEC packets, after processing it finds the IPSEC 
policy with the packet selectors.

In this case SG1 has separate IPSEC policy is configured for HTTP traffic 
(IPSEC attributes ESP,DES) with higher priority.

My doubt was "Should we need to drop such inbound traffic in SG1 side???"

As per Ramana's mail I have gone through the RFC 2401 section 5.2.1.

Now my understanding is that we should not drop such traffic.

I hope the above description is clear.

Please let me know if my understanding is correct.

Thanks
Jyothi

At 05:14 PM 4/30/03 -0400, Stephen Kent wrote:
>At 9:58 AM +0530 4/29/03, Jyothi wrote:
>>Hi,
>>
>>Office1Network-----SG1---------Internet------------SG2-------Office2Network.
>>
>>SG1 contains the 2 IPSEC policies:
>>     1. protocol TCP and port 80
>>     2. protocol ANY
>>
>>SG2 contains the one IPSEC policy of protocol ANY.
>>
>>Office2Network starts the IKE negotiation for protocol ANY, after the 
>>negotiation SG2 will send the HTTP traffic with SAs created.
>>
>>In IKE negotiation, we are informing the allowable traffic as protocol ANY.
>>  In this case, HTTP is part of protocol ANY.
>>
>>So, if SG1 rejects inbound traffic coming from SG2,  then how SG2 knows??
>>
>>Thanks
>>Jyothi
>
>I don't understand all of the assumptions underlying your example. Note 
>that SPD entries are directional, and thus must be separately defined for 
>inbound and outbound traffic flows. So, please restate your example in 
>those terms, and let's see if there is a problem. Ramana's message 
>indicated why this might not be a problem, but until you state the full 
>set of assumptions about the SPDs at each end, I don't know how to 
>interpret the example.
>
>Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 May 2003 11:13:40 -0400

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

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 2 May 2003 09:14:19 -0700

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

---

From: Ramana Yarlagadda <[email-masked]>
Date: Fri, 02 May 2003 11:38:51 -0700

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

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 2 May 2003 11:56:53 -0700

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.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 May 2003 15:22:18 -0400

>And if that is the case, then   with the setup Jyothi has described the SA

As I mentioned, the text needs to be fixed and I described how I plan 
to fix it, in general terms.  I can't fault anyone for interpreting 
the text in different ways, but I do believe that our goal should be 
to prevent IPsec from behaving in a "surprising" fashion. Use that as 
your guide, and you have a defensible position.

Steve