[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SPD issues





> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]
> Sent: Monday, October 20, 2003 11:38 AM
> To: Mike Taylor; Stephen Kent; ipsec@lists.tislabs.com
> Subject: RE: SPD issues
>
>
> 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.
>
> Makes sense?

Yes, absolutely.  That language should be sufficient.

Thanks Mark,

Mike

>
> --Mark
>
>