[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPD issues
Hi,
IPSEC VPN is being used in two different ways - Policy based VPN and
Route/Interface based VPN. But, in both cases, the steps given by Steve are valid.
In policy based VPN, SPD selection process selects the SPD. Security policy
is chosen based on traffic selectors. Once the security is applied on the packet,
the packet is forwarded based on the destination IP address of the outer IP header.
In route based VPN, packet is traversed twice through the IP stack.
- Here too, the SPD is selected as per SPD selection process. Security policy is chosen
based on packet selectors. Action (Bypass/Discard/Apply) is applied on the
packet and forwarding interface is chosen based on the destination IP address
of the transformed packet. In Route based VPN, these forwarding interfaces are either
L2TPoIPSEC or IPinIPoIPSEC interfaces.
- L2TP or IPinIP tunnel headers are applied on the packet.
- One more SPD selection occurs at this time. Security policy within SPD is chosen based on
L2TP or IPinIP tunnel selectors. Security is applied as per Security Policy and then packet
is forwarded.
Route based VPN is similar to policy based VPN except that the packet is traversed twice (or more) through
SPD Selection and forwarding process. Typically, in this case, first SPD security policy action would
be 'Bypass' and second SPD security policy action would be 'Apply'.
I feel 'SPD selection' process and 'forwarding' in the process flow are generic enough and
provide enough flexibility for different implementations.
Srini
Intoto Inc.
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com
----- Original Message -----
From: "Mike Taylor" <mtaylor.eng@sbcglobal.net>
To: "Joe Touch" <touch@ISI.EDU>; "Mark Duffy" <mduffy@quarrytech.com>
Cc: "Mike Taylor" <mtaylor.eng@sbcglobal.net>; "Stephen Kent" <kent@bbn.com>; <ipsec@lists.tislabs.com>
Sent: Monday, October 20, 2003 3:49 PM
Subject: RE: SPD issues
>
>
> > -----Original Message-----
> > From: Joe Touch [mailto:touch@ISI.EDU]
> > Sent: Monday, October 20, 2003 2:01 PM
> > To: Mark Duffy
> > Cc: Mike Taylor; Stephen Kent; ipsec@lists.tislabs.com
> > Subject: Re: SPD issues
> >
> >
> >
> >
> > Mark Duffy wrote:
> >
> > > Hi Mike, see below...
> > >
> > > At 10:09 AM 10/20/2003 -0700, Mike Taylor wrote:
> > > [...]
> > >
> > >> > > [SK] I think we have to say something about options for how
> > >> forwarding
> > >> > >decisions can be made in the context of IPsec, especially in tunnel
> > >> mode.
> > >> >
> > >> > [MD] How about:
> > >> >
> > >> > For packets that "bypass" IPsec processing, and for packets
> > that arrive
> > >> > with IPsec protection which is removed at the device, the IP output
> > >> > interface and next hop are selected by the normal IP forwarding
> > >> mechanism
> > >> > of the device [which would be beyond the scope of 2401bis] applied
> > >> to the
> > >> > plaintext packet.
> > >> >
> > >> > For packets that have IPsec applied to them by the device (tunnel or
> > >> > transport mode) the IP output interface and next hop are selected by
> > >> the
> > >> > normal IP forwarding mechanism of the device applied to the IPsec
> > >> packet.
> > >>
> > >> [MT] This wording is not sufficiently clear as their is quite a
> > >> difference
> > >> between
> > >> the routing applied *after* IPSec processing in tunnel mode, and the
> > >> routing
> > >> required to get a red datagram to IPSec, i.e., either to some
> > virtual or
> > >> real
> > >> interface to which an SPD is attached that has a policy relevant to the
> > >> datagram.
> > >> In the latter, the route may very well not be "real" in the
> > sense that it
> > >> may
> > >> exist solely for the purpose of getting the red datagram to
> > IPSec, and in
> > >> fact the
> > >> destination IP address may be some private address (with IPSec
> > in tunnel
> > >> mode)
> > >> that couldn't possibly be reached via the public Internet by a
> > >> conventional
> > >> (non-VPN) forwarding decision.
> > >
> > >
> > > My understanding of the proposed model is that the IPsec device has an
> > > "SPD selection function" that choses the SPD to use; how the choice is
> > > made is implementation dependent. This replaces (or rather, enlarges
> > > on) the SPD-per-interface model of 2401. I believe that that SPD
> > > selection function fills the role of the "routing required to get a red
> > > datagram to IPSec" in your message above.
> > >
> > >> In a purist sense the solution to these issues falls into the realm of
> > >> implementation
> > >> details that don't really need to be specified in 2401bis. I
> > don't think
> > >> 2401bis
> > >> should require, for example, virtual interfaces as a solution.
> > >
> > > Nor do I. Which is why I personally find the idea of an "SPD selection
> > > function" attractive. Trying to disguise the SPD selection function as
> > > a "forwarding decision" just adds confusion.
> > >
> > > So, there is an SPD selection function that chooses an SPD. And there
> > > is an IP forwarding function that selects a next hop to forward a
> > > datagram to. And the two may be comepletely independent or completely
> > > entwined, depending on the nature of the device.
> >
> > It's the entwined case that presents the largest problem. I.e., if the
> > SPD selection is based on forwarding information that then changes by
> > the time the subsequently tunneled (or not tunneled) packet is emitted
> > from IPsec.
>
> By the forwarding information changing do you really mean that the
> forwarding
> database changes? Assuming so, then I hadn't thought much about that case
> yet
> but here's how I see it so far. This description refers to a native IPSec
> implementation which is what I'm working on. I haven't though much about
> BITS/BITW. I am attempting to create a fairly basic, small footprint
> implementation
> (for small embedded systems) and am not looking at more advanced issues like
> multiple
> virtual routers in one box at this time. That is one reason I don't want to
> see
> too many implementation details turning up as requirements in 2401bis.
>
> 1. If SPD selection for outbound datagrams is based on a single outbound
> SPD rather than an SPD per interface then it doesn't much matter
> if the forwarding info changes after the policy is selected.
> In fact, the selection of the policy has little to do with the
> IP forwarding function, other than that a route must exist for
> that chooses some interface on which to send the datagram (and
> maybe
> even that can be made irrelevant - see below).
>
> Of course, in transport mode the route better point to the correct
> interface,
> but in tunnel mode it doesn't really much matter with a single outbound
> SPD.
> However, using a "normal" route this way in tunnel mode seems to me so
> far to be the ugliest aspect of the IPSec/forwarding interaction,
> see below.
>
> 2. In transport mode at present my implementation intercepts red datagrams
> after the forwarding function has chosen and outbound interface,
> performs
> IPSec processing, marks that as complete, then sends the datagram back
> out on
> the wire via the interface originally chosen by the IP forwarding
> function
> (possibly after fragmentation although naturally I am attempting to
> avoid that).
> If in reality the interface has changed in the few milliseconds since
> the original
> routing decision was made this isn't any more serious a problem, nor
> any more solvable,
> than if the forwarding database changes a microsecond after the
> datagram
> has been sent out already. One, or a few, datagrams would be
> misrouted,
> possibly dropped, and perhaps retransmitted (if TCP or other reliable
> transport).
>
> 3. In tunnel mode after the policy is located all IPSec processing is
> completed
> included addition of the new tunnel outer IP header. Then the datagram
> is marked
> as having been through IPSec and given to the IP forwarding function
> to route (to the tunnel endpoint) as it sees fit. It may well exit a
> different
> interface than the one pointed to by the routing of the inner header.
> It will not be examined by IPSec again.
>
> This seems to me to cleanly divorce IP forwarding issues from IPSec.
> However, as
> noted in #1 above, there is this whole pretty ugly issue of where should a
> route for
> red datagrams point? After all, if we are tunneling between two private
> networks
> then in reality the inner red IP datagram probably (because of the use of
> private address
> space) couldn't really be delivered to the destination via the Internet. So
> the route
> that has to be added just to get the red datagram to IPSec is completely
> artificial in
> that case. Yuck.
>
> I believe that is why many folks might like to see virtual interfaces play a
> role in the
> new IPSec processing model. That way, the routes for red datagrams can
> point to a
> virtual interface rather than to some real physical interface out of which
> the datagram
> should never exit without 1st having been through IPSec processing, and in
> fact, from
> which the datagram may *never* exit if it is wrapped in an IPSec tunnel and
> IP forwarding
> ends up sending out some other interface. So I'm considering now whether to
> implement virtual
> interfaces. But I don't want it to be mandated in a specification. It is
> an implementation
> issue and the more kludgey approach of just point the route for red
> datagrams at whatever
> interface (in tunnel mode that is, in transport it better point to the
> correct one of course)
> will work and is sufficient, if not very elegant.
>
> In fact, another approach for a native IPSec implementation which I only
> just thought of as
> I was writing this email might be simply be to add code to the processing of
> outbound IP datagrams
> such that if the forwarding function reports that no route exists to the
> destination then invoke
> IPSec outbound processing to see if the datagram is covered by an IPSec
> policy (presumably a
> tunnel mode policy) and if so then let IPSec take it from there, rather than
> dropping the datagram
> because the destination is unreachable. Hmmm.. I sort of like this idea and
> will certainly
> consider it further for my implementation.
>
> I also believe that this issue of having an "artificial" route for tunnel
> mode is why many folks
> want to see the requirement that Security Gateways operate in tunnel mode
> only (unless they're
> acting as hosts) removed from 2401bis, or at least clarified. Because, for
> example, in the
> FreeBSD world it looks to me like many administrators implement IPSec
> tunnels by actually using a
> "gif" interface, which is a virtual interface that performs IP-in-IP
> tunneling on the datagrams
> routed to it, and applying IPSec in *transport* mode to the datagrams that
> exit the gif device.
> At least, that's my take from researching the issue some. This does seem
> like a perfectly effective
> way of creating a tunnel using IPSec in transport mode only. In fact, its
> even gotten me to
> wondering whether IPSec tunnel mode should ever have been invented! Perhaps
> even IPSec tunnel
> mode itself is an example of putting too much implementation detail in a
> specification!
> Because perhaps the very same problem can be solved more elegantly the way
> many users
> of FreeBSD seem to solving it. And if that is true, then the layering
> principals of good protocol
> design would seem to dictate that there is no real need to mandate "native"
> IPSec tunnels in
> the specifications.
>
> I'm still in the fairly early stages of the implementation although I do
> have running code.
> Am I misunderstanding some of these issues? I'm late to the whole 2401bis
> discussion.
> I wasn't even aware a 2401bis effort was underway until I had already
> started coding from 2401
> and pondering these issues. I was glad to see that a 2401bis effort was
> underway and that
> attempts were being made to address some of the very same issues that had me
> perplexed after having
> studied 2401. But I am also anxious to see the issues I found with 2401
> fixed in an elegant,
> and implementation independent way in 2401bis.
>
> - Mike
>
>
> >
> > This could happen whether dynamic or static routing is used; the issue
> > is flux in the forwarding table and whether it is _allowed_ to affect
> > SPD selection.
> >
> > Calling the function "SPD selection" doesn't absolve the problem.
> >
> > Joe
> >