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

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

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
----- Original Message ----- 
From: "Stephen Kent" <kent@bbn.com>
To: "Francis Dupont" <Francis.Dupont@enst-bretagne.fr>; <ipsec@lists.tislabs.com>
Sent: Wednesday, June 25, 2003 4:18 PM
Subject: Re: issue with "per-interface SAD/SPD"


> >At 6:06 PM +0200 6/9/03, Francis Dupont wrote:
> >>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
> >>
> >>Francis.Dupont@enst-bretagne.fr
> >
> >Francis,
> >
> >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