Subject: issue with "per-interface SAD/SPD"

From: Francis Dupont <[email-masked]>
Date: Mon, 09 Jun 2003 18:06:02 +0200

The RFC 2401 mandates (section 4.4, page 13) separate inbound and
outbound databases (SAD and SPD) for each IPsec-enabled interface.
This doesn't work in a dynamic environment where for instance dynamic
routing makes the arrival of a packet for an address of a node possible
on more than one interface in a long term, or where the peer is a mobile
node.
The problem exists at least in SAD lookup for incoming traffic and for
SPD matching in IKE... IMHO the simplest (so the best :-) solution is
to introduce an interface selector: the "firewall" properties are kept
but a SPD entry can be "shared" between some interfaces.
How this will be handled in the revision of RFC 2401?

Regards

[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jun 2003 09:47:48 -0700

> [email-masked]

FYI, we addressed this sort of issue in draft-touch-ipsec-vpn-05.txt, 
which was submitted independently as an Informational in April.

Introducing an interface selector is insufficient; the selector needs to 
indicate the next-hop IP address and interface, as both are required for 
IP forwarding. The details of this issue, and simpler alternatives are 
discussed in the draft.

Joe

---

From: Karen Seo <[email-masked]>
Date: Mon, 9 Jun 2003 23:49:39 -0400

Francis,

I see your point but am not sure how Steve (Kent) would propose to 
address this. He's on vacation until 6/17.  So I just wanted to let 
you know that we'll get back to you as soon as he returns (and has a 
chance to plow through his email backlog :-).)

Karen

---

From: Francis Dupont <[email-masked]>
Date: Tue, 10 Jun 2003 19:18:40 +0200

In your previous mail you wrote:

=> this is a very nice news!

=> the problem I tried to address is a bit different: for instance in
Mobile IPv6 only the packets with a Mobility Header must be protected,
so a transport interface over the IP-in-IP tunnel is too much...
In fact, my message was mainly for the 2401bis authors, as the "per
interface" stuff is clearly inadapted.

Thanks

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 19:18:10 -0400

>At 6:06 PM +0200 6/9/03, Francis Dupont wrote:
>Good points.  We'll be presenting a new IPsec processing model to 
>the list next week, and one facet of it will be a clarification of 
>the relationship between SPDs, SADs, interfaces and routing.  We 
>will be introducing an explicit forwarding function call, that will 
>select an interface prior to SPD lookup.
>
>Going forward, we still need per (logical) interface SPDs, but the 
>SAD is really per implementation, not per interface.  By this I mean 
>that if a  device centrally manages SPI assignment, then only one 
>SAD is needed. In contrast, if a router had one IPsec process on 
>each interface card, it would probably want an SAD per card (because 
>of the difficulties of coordination across interfaces) and that is a 
>reasonable implementation strategy as well.
>
>Steve

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Thu, 26 Jun 2003 16:58:58 -0700

Traditionally, IPSEC gateways are used to secure the traffic from
one corporate network to another corporate network via untrusted
media i.e public Internet. Also, traditionally IPSEC gateways are also used
for remote access. In these cases traffic going out onto the external
interfaces (interfaces of device towards Internet) is secured based
on outbound SPD. Any traffic received on external interfaces are checked against
the incoming SPD. 

Recently, wireless stations (PCs in WLAN) are becoming common
practice and IPSEC is being used to secure the traffic over the AIR.
Here two points to be noted
    - The traffic going from WLAN machines to wired corporate network
       need to be secured.
    -  The traffic among wireless stations should also need to be secured.
        There would be as many tunnels as number of wireless stations in 
        the WLAN network.

Typically, the whole WLAN is exposed as single interface in IPSEC gateway.
Traffic from one wireless stations is de-tunneled and tunneled again before
sending it to other wireless station. 

There could multiple WLANs and thereby multiple interfaces. Same device
also can be used to secure the traffic from internal networks to remote network.

- Security is not only required packets going onto the external interfaces, but also
   security is needed on internal interfaces - across interfaces and within interface.

Also, with the advent of Virtual Router and hotspot devices OR wireless security
switch routers, there are many instances of SPD, that is defined for each security
domain, for example SSID can be considered as security domain/network.
In case of data centers, each VLAN considered as Security network/domain.
In case of POP, each customer account can be considered as security network/domain.

I feel, it is better to leave  the way number of SPDs are defined to local decision 
You could have one global SPD for the traffic going onto the external network in traditional cases.
In wireless security switch routers OR Virtual routers, the SPD can be defined for
each security network/domain. 

To identify the SPD, first virtual router instance should be identified.
Virtual IPSEC router (Security network) instance can be identified by the 
unique IP address, when the packets come are received from external network. 
In case packets come from the non-external interfaces,  security network can
be identified by SSID, VLAN ID OR physical interface.
Once the instance is identified, appropriate SPD can be used for matching SP.

Security network (IPSEC Instance) is associated with one or more public IP
addresses OR one or more physical/logical interfaces.

Keeping the various scenarios in which IPSEC can be used, it may be better
to leave the decision of defining SPD on per interface basis/IPSEC router instance
basis or global basis to the implementations targeted for different market 
segments. It does not hamper the interoperability. But it would be very nice
to have explanations of various scenarios in the document.

Srini
Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Jun 2003 15:09:19 -0400

What we are envisioning for 2401bis is a virtual interface ID, which 
would allow a local administrator considerable flexibility in 
deciding the granularity at which SPDs are managed. One could map all 
traffic to on VID and have just one SPD instance, or one could map 
different SSIDs to different VIDs to address the WLAN scenario you 
described. Leaving this sort of thing completely undefined is not 
attractive to me, because such ambiguity creates possible interop 
problems. I'd like to think that the VID concept, which we will 
describe in greater detail in messages next week, is a good, uniform 
interface capability that can be adapted to a wide range of 
environments.

Steve

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 27 Jun 2003 13:32:16 -0700

Hi Steve,
     I was talking to my one of my colleagues on this and you are right that there may be need 
    for interoperability.  Today, implementations ( I am not sure of others, we do this way)
    identify the VID,during IKE  phase1 negotiations by the IP address on which 
    packets have come (Destination IP of phase1 messages). Due to this the system should 
    have as many   IP addresses as number of VIDs supported in the system. By having some
    interoperable way of sending VID as part of phase1 might solve this problem.

    If you think we should wait until details you plan to send by next week, then that
    is fine.

Thanks
Srini
Intoto Inc.