Subject: nested SAs

From: [email-masked]
Date: Wed, 28 Mar 2001 15:08:00 -0600

Hi,

To continue our discussions about nested SAs, I am referring to RFC 2401
Section 4.5 case 4:

        ======================================================
        |                                                    |
        |==============================                      |
        ||                            |                      |
        ||                         ---|----------------------|---
        ||                         |  |                      |  |
        H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
              ^                    |           Intranet)        |
              |                    ------------------------------
        could be dialup              admin. boundary (optional)
        to PPP/ARA server
 
H1 and H2 are hosts and SG2 is a security gateway. Two SAs are shown between
H1 and H2 and between H1 and SG2.

For the time being, let's assume that both SAs are tunnels. Call the tunnel
between H1 and H2 T1 and between H1 and SG2 T2. 

From H1's point of view, it needs to take two actions for packets that go
from H1 to H2: wrap the packet inside tunnel T1 and then wrap it again
inside tunnel T2.

There seem to be two solutions for the policy in H1's SPD (hence the policy
pushed down from PDP):

Solution #1: Single rule with multiple actions:
  selector: src addr = H1, dst addr = H2
  actions: apply T1 and then apply T2

Solution #2: Multiple rules each with single action:
  rule #1 : 
           selector: src addr = H1, dst addr = H2
           action: apply T1
  rule #2 :
           selector: src addr = H1, dst addr = H2, protocol = T1's protocol
           action: apply T2

If I understand it correctly, RFC 2401 seems to suggest solution #1 and I
know that there are implementations out there for solution #1. It is also
the solution proposed in IPsec PIB.

The second solution is proposed in the ietf IPsec Information model. The
issue with solution #2 is that it forces the implementation to make multiple
searches of the SPD. In this case, the first search matches rule #1. After
the action of that rule is applied, another search (with the T1 wrapped
packet) of the SPD hits rule #2. After the action of rule #2 is applied,
another search is necessary to make sure that there is no more rules to be
applied before sending out this packet. 

This means that all SINGLE SA needs to go through two searches of the SPD in
order to accomodate possible nested SAs. Since nested SAs are not as common
as single SA, this does not seem to be an efficient solution. 

Let me know if I missed some important points.

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
[email-masked]
phone 1-781-993-3923
GSM 1-781-492-2850

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 29 Mar 2001 16:12:43 +0200

Man,

Your explanation is 100% correct.

After the IPSP WG session, Jamie, Lee and myself agreed to change the 
information model. The -03 draft will have multiple actions in one rule :-)

Regards

-eric

>To continue our discussions about nested SAs, I am referring to RFC 2401

Eric Vyncke
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778-4677             Fax:    +32-2-778-4300
E-mail: [email-masked]          Mobile: +32-475-312-458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141