Subject: Re: SPD issues

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Oct 2003 19:03:22 -0400

Mark,

>	<SNIP>
>
>
>>         - My previous proposal for a revised processing model, from 
>>a few weeks ago, retained the idea of multiple SPDs, allocating 
>>them to virtual interfaces, and introduced the notion of a 
>>forwarding function to select the right virtual interface, and thus 
>>SPD.  But, unless we feel a need to have different SPDs per 
>>interface, this seems like overkill. I think we do want to allow 
>>forwarding of outbound traffic to be independent of SPD selection, 
>>so some notion of an explicit forwarding function in the model 
>>still seems appropriate. but, as we discussed the model, there was 
>>a suggestion that we might need two such functions, one to select 
>>an SPD, and then one to be applied after IPsec processing. maybe, 
>>if we separate SPD selection from interface selection we can have 
>>two functions but only one of them is really for forwarding.
>
>I am all for separating the "SPD selection function" from the "IP 
>forwarding function".  (Once that is done though, I don't see why 
>the IP forwarding function is any concern of IPsec's.)

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.

>
>By using different SPD selection functions, different results can be obtained:
>
>The RFC 2401 behavior can be obtained by an SPD selection function 
>based on the output IP interface for outbound packets and the 
>receiving IP interface for inbound packets (i.e. the black side 
>interface).
>
>The behavior described above for different SPDs per subscriber can 
>be obtained by an SPD selection function based on the receiving IP 
>interface for outbound packets and the output IP interface for 
>inbound packets (i.e. the red side interface).

There is no need to select an SPD for inbound packets if they are 
IPsec-protected. We still envision just one SAD per IPsec 
implementation, and the revised processing model says that the 
relevant SPD info needed to check inbound packets after processing is 
bound to the SAD entries. That leaves the question of SPD info for 
inbound bypass/discard traffic.

>
>And the very simple case mentioned above can be handled by an SPD 
>selection function that just returns the same SPD in all cases.

yes, using just one SPD should be an option.

>
>
>>         - Along those lines, we could introduce an SPD selector 
>>function that, like the forwarding function, can use any info in a 
>>packet to select an SPD, but without associating the SPD with an 
>>interface per se.
>
>Yes, please!  But I would say that it should be able to use not only 
>"any info in a packet" but also meta-information associated with a 
>packet (e.g. the interface it arrived or will depart on) to select 
>an SPD.  Perhaps that's what you intended anyway.
>

yes, I did mean to include meta data, e.g., local interface via which 
the outbound packet was received.

Steve (still catching up on 2 weeks of e-mail)

---

From: Mark Duffy <[email-masked]>
Date: Tue, 14 Oct 2003 23:55:58 -0400

At 07:03 PM 10/14/2003 -0400, Stephen Kent wrote:
>Mark,
>
>>         <SNIP>
>>
>>
>>>         - My previous proposal for a revised processing model, from a 
>>> few weeks ago, retained the idea of multiple SPDs, allocating them to 
>>> virtual interfaces, and introduced the notion of a forwarding function 
>>> to select the right virtual interface, and thus SPD.  But, unless we 
>>> feel a need to have different SPDs per interface, this seems like 
>>> overkill. I think we do want to allow forwarding of outbound traffic to 
>>> be independent of SPD selection, so some notion of an explicit 
>>> forwarding function in the model still seems appropriate. but, as we 
>>> discussed the model, there was a suggestion that we might need two such 
>>> functions, one to select an SPD, and then one to be applied after IPsec 
>>> processing. maybe, if we separate SPD selection from interface 
>>> selection we can have two functions but only one of them is really for 
>>> forwarding.
>>
>>forwarding function".  (Once that is done though, I don't see why the IP 
>>forwarding function is any concern of IPsec's.)
>
>decisions can be made in the context of IPsec, especially in tunnel mode.

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.

And for packets that have a "drop" action selected, the document can remain 
silent.  After all, the world would be rendered uninteresting if all 
mystery were removed ;-)

Mark

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Oct 2003 12:56:04 -0400

Mark,

I like your suggested simple description of forwarding, especially 
because it gets rid of IPsec having to talk about the details.  My 
only concern, after a quick read, is that for outbound tunnel mode 
packets, this does require that only the outer header be employed to 
make a forwarding decision. If everyone is comfortable with that 
limitation (and I am not saying that it is a problem), then I think 
we may have a way to simplify this aspect of the processing model.

Steve

>
>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.
>
>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.
>
>And for packets that have a "drop" action selected, the document can 
>remain silent.  After all, the world would be rendered uninteresting 
>if all mystery were removed ;-)
>
>Mark

---

From: "Mike Taylor" <[email-masked]>
Date: Mon, 20 Oct 2003 10:09:07 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark Duffy
> Sent: Tuesday, October 14, 2003 8:56 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: SPD issues
>
>

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.

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.  Rather,
there should
be an appendix in 2401bis with suggested implementations such as the use of
virtual
interfaces, or what have you.  It should point out any known pitfalls
(security
issues) with various implementation choices.  But that's just my 2 cents
worth.

<soapbox>
It seems to me that the real issue here goes to the heart of the original
principals
of IP networking.  An IP network ideally ought to be a bunch of networks
connected
together by boxes whose sole function is to perform the forwarding function.
All
other processing really ought to be done by the hosts connected to those
networks,
just as the "forefathers" knew that reliable data exchange should be
accomplished
by the end-points using a transport level protocol (TCP) running over an
unreliable
best effort datagram delivery service, rather than by having per-link error
correction
as in X.25.  So (as the IPv6 folks have recognized) security must ultimately
also be
done end-to-end.  A security gateway is no more and no less an abomination
than a
NAT box and ideally should be viewed as a temporary solution until we have
full end-to-end
security.  But of course, it is very likely that this utopian vision won't
come to
pass in my lifetime.
</soapbox>

---

From: Mark Duffy <[email-masked]>
Date: Mon, 20 Oct 2003 14:38:29 -0400

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
> > [MD] How about:
>[MT] This wording is not sufficiently clear as their is quite a difference
>between

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.

>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?

--Mark

---

From: "Mike Taylor" <[email-masked]>
Date: Mon, 20 Oct 2003 12:51:09 -0700

> From: Mark Duffy [mailto:[email-masked]]
> Sent: Monday, October 20, 2003 11:38 AM
> To: Mike Taylor; Stephen Kent; [email-masked]
> Subject: RE: SPD issues
>
>
> Hi Mike,  see below...
>

Yes, absolutely.  That language should be sufficient.

Thanks Mark,

Mike

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Oct 2003 14:00:42 -0700

Mark Duffy wrote:

>> the
> 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.
> 
> 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.

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

---

From: "Mike Taylor" <[email-masked]>
Date: Mon, 20 Oct 2003 15:49:14 -0700

> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, October 20, 2003 2:01 PM
> To: Mark Duffy
> Cc: Mike Taylor; Stephen Kent; [email-masked]
> Subject: Re: SPD issues
>
>
>
>
> Mark Duffy wrote:
>
> > Hi Mike,  see below...
> >

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Oct 2003 16:57:15 -0700

Mike Taylor wrote:

...
> database changes? 

Yes. Even in embedded devices, unless the forwarding database is in ROM, 
it gets changed.

> Assuming so, then I hadn't thought much about that case
> yet

This has nothing to do (necessarily) with virtual routers, or even 
dynamic routing.

> 	    if the forwarding info changes after the policy is selected.
...

Agreed. If there's no SPD lookup, then this is not an issue.

> 	    possibly dropped, and perhaps retransmitted (if TCP or other reliable

Misrouting is an issue of the packet goes out on an interface with 
encryption that isn't appropriate for that interface. I.e., if I change 
the SPD and the forwarding table at the same time, and whether there are 
packets pending in IPsec inbetween - and there isn't any current rule 
that prohibits those two occurrances.

> 	    It will not be examined by IPSec again.

It might be. It's not clear that this matters for this situation, though.

However, if the SPD lookup in this case depends on forwarding, it's 
possible that packets will be emitted based on tunneling that is based 
on forwarding that is stale by the time they exit. Again, it's possible 
that packets could be sent in the wrong direction with weaker security 
than is intended.

If the SPD lookup MUST NOT depend on the forwarding table, then this is 
not an issue. If the SPD lookup MAY depend on the forwarding, then this 
needs to be considered.

> will work and is sufficient, if not very elegant.

I'm not advocating the requirement of virtual interfaces for this issue 
either; I'm just observing the a potential relationship between the SPD 
lookup and the forwarding operation afterwards.

> consider it further for my implementation.

This might work if there were no non-IPsec routes for a packet. That's a 
very special case, IMO.

Further, if the IPsec 'takes it from there' and then finds out that 
there is no SA, what is the ICMP error message? SA not found (or 
silent), or route not found?

> routed to it, and applying IPSec in *transport* mode to the datagrams that

(see draft-touch-ipsec-vpn-06.txt, or our ICNP paper from 2000 cited 
therein) ;-)
...

Joe

---

From: "Mike Taylor" <[email-masked]>
Date: Mon, 20 Oct 2003 17:26:34 -0700

Hi Joe,

See my comments below.  I don't pretend to know the answers.
In fact, these issues seem quite thorny to me.

> Sent: Monday, October 20, 2003 4:57 PM
> To: Mike Taylor
> Cc: Mark Duffy; Stephen Kent; [email-masked]
> Subject: Re: SPD issues
>
>
>
>
> Mike Taylor wrote:
>
> ...

I see your point in that if I have two different policies for the same
source address (the red network) but different destination addresses
(maybe one is the public internet and another is for some other subnet
in my domain).  Perhaps the latter has weaker security (none at all even)
than the former and because routing gets messed up datagrams could go
out the wrong interface, perhaps a public one, with no protection at all.

This may well be what the original authors of 2401 were thinking about
when they created a per-interface SPD concept.  However, I'm not sure
I see how that really solves the problem either.  It just seems moves it
from getting the routing correct to getting the assignment of policies to
physical interfaces correct.

In other words, perhaps the two problems really aren't separable at all.
Thus,
perhaps IPSec requires a fundamental change to IP in that it must be
incorporated into routing.  Perhaps in an IPSec box it should be impossible
to create a route without specifying an IPSec policy to go with it.  Would
that solve the problems? Hmmm...... It certainly causes a problem for
BITS/BITW
implementations.  But if such solutions are really hacks then perhaps we
shouldn't give them any official blessing.  The whole issue of security is
so important that we can't afford not to get it right this time around.

> This might work if there were no non-IPsec routes for a packet. That's a

But in this concept there are no non-IPSec routes because there is only
a single SPD.  So there is no way for a datagram to exit the box
without IPSec getting a look at it.  This idea is only one possible way
to avoid creating "fake" routes for the datagrams destined to some remote
private network that are going to be tunneled and for which there cannot
be any real route.  Another way to avoid the fake route issue is by
creating some sort of virtual interface to which routes point.  But what
if there are also routes to "real" interfaces for the same destination?
Again, having per-interface outbound SPDs won't help that in a stack that
supports multiple routes for a single destination.

---

From: Mark Duffy <[email-masked]>
Date: Tue, 21 Oct 2003 00:25:01 -0400

>>[MD] 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 
>[JT] 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 
>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.
>

No.  But it isolates the problems of which SPD to use, and which interface/ 
next hop to send the packet to.  Whoever feels that these are or need to be 
entwined for their application is free to do so.  Those solving simpler 
problems can avoid that.  And 2401bis can take itself out of the business 
of IP forwarding decisions.

Mark

---

From: [email-masked] (Joshua D. Guttman)
Date: 21 Oct 2003 10:40:39 -0400

Mike --

"Mike Taylor" <[email-masked]> writes:

>   > Again, it's possible that packets could be sent in the wrong
>   > direction with weaker security than is intended.
>   
>   I see your point in that if I have two different policies for the
>   same source address (the red network) but different destination
>   addresses (maybe one is the public internet and another is for
>   some other subnet in my domain).  Perhaps the latter has weaker
>   security (none at all even) than the former and because routing
>   gets messed up datagrams could go out the wrong interface, perhaps
>   a public one, with no protection at all.

The paper "Rigorous Automated Network Security Management" available
at http://www.ccs.neu.edu/home/guttman seems (to me) to give ways to
ensure that a given IPsec set-up has no problems of this kind.  

        Joshua 

-- 
	Joshua D. Guttman		<[email-masked]>
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Fax:	+1 781 271 8953
	Bedford, MA 01730-1420 USA	Cell:	+1 781 526 5713

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2003 10:00:51 -0700

Mark Duffy wrote:

>>> 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.
>>
>>
>> [JT] 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.
>>
> No.  But it isolates the problems of which SPD to use, and which 
> interface/ next hop to send the packet to.  Whoever feels that these are 
> or need to be entwined for their application is free to do so.. Those
> solving simpler problems can avoid that.  And 2401bis can take itself 
> out of the business of IP forwarding decisions.
> 
> Mark

I'm in favor of those last two observations, but it's the "whoever feels
.. is free to do so" that worries me. I.e., this gives enough freedom to
end up with a nasty loophole, e.g., "SPD selection can be supported, but
how is up to the implementer, and whether it is secure depends on the
implementation".

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2003 10:16:40 -0700

> In fact, these issues seem quite thorny to me.

agreed.

>>>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
>>
>>>(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
>>>	1.  If SPD selection for outbound datagrams is based on a
>>
>>single outbound
>>
>>>	2.  In transport mode at present my implementation
>>
>>intercepts red datagrams
>>
>>>	    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,
>>>	    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.
>>

Yeah - that's why I'm wondering if the "use external SPD lookup" might 
be a security hole per se. Pushing it to an external, unspecified 
function certainly has that flavor.

>>>noted in #1 above, there is this whole pretty ugly issue of
>>
>>where should a
>>
>>>route for
>>>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
>>>I believe that is why many folks might like to see virtual
>>
>>interfaces play a
>>
>>>role in the
>>>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
>>>I was writing this email might be simply be to add code to the
>>
>>processing of
>>
>>>outbound IP datagrams
>>>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
> a single SPD.

In that case, there would need to be an SPD entry that says "don't 
IPsec"; that was the case I was thinking of, but I agree that this 
should be in the SPD at that point.

> So there is no way for a datagram to exit the box

Yes - that's a can of worms of a different color (to mix metaphors).

>>>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
>>>routed to it, and applying IPSec in *transport* mode to the
>>
>>datagrams that
>>
>>>exit the gif device.
>>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2003 13:10:23 -0400

At 10:00 -0700 10/21/03, Joe Touch wrote:
>Mark Duffy wrote:
>
>>
>>>>[MD] 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.
>>>
>>>
>>>[JT] 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.
>>>
>>>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.
>>>
>>interface/ next hop to send the packet to.  Whoever feels that 
>>these are or need to be entwined for their application is free to 
>>do so.. Those
>>solving simpler problems can avoid that.  And 2401bis can take 
>>itself out of the business of IP forwarding decisions.
>>
>>Mark
>

Joe,

We have enough variation in how different contexts want to select 
SPDs (when more than one is needed) that I don't think we can do more 
than say that there is a lookup function which takes the outbound 
packet and local metadata as inputs.  This seems analogous to your 
earlier suggestion to allow a forwarding function to have access to 
the whole outbound packet to support an unspecified forwarding 
lookup, when we were thinking of having an explicit forwarding 
function as part of IPsec.

Many IPsec implementations will need only one SPD, so this whole 
issue is a no-op in those cases.  In cases where multiple SPDs are 
appropriate, then yes, the implementor and the admin will have to 
exercise caution in these contexts.  Generally, we cannot have it 
both ways.  if we keep things simple, we can have more confidence in 
their security, but we loose flexibility.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2003 13:40:35 -0400

Folks

There may be some misunderstanding about what holes an SPD selection 
function creates.

If there is more than one SPD (per interface or whatever) and if the 
same destination is represented in more than one SPD, and if these 
entries offer different choices for the security services to be 
applied, where one of the choices may be less secure than the others, 
then you have a problem, period.  This is because many factors could 
cause the traffic be be processed against the SPD that results in 
applying a less secure set of services, e.g., bypass. For example, a 
Trojan Horse in the net behind the IPsec device might deliberately 
alter packet headers in an effort to cause the traffic to be mapped 
to a different SPD. When we had per-interface SPDs, it was possible 
that traffic destined for one outbound interface (that was deemed 
secure) might be misrouted by the forwarding software after IPsec 
processing is completed. There are many other examples.

The only way to be really confident about the security services being 
provided for traffic is to have just one SPD, or to make sure that 
the multiple SPDs are not overlapping in terms of the destination 
addresses (for outbound traffic), or that the security services 
offered in any overlapping entries are equivalent.

That's why I cannot get too excited about the residual 
vulnerabilities associated with these options.

maybe we should taje a hint from the automotive industry and add the 
following waring to the RFC:

"your actual security may vary"  :-)

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2003 10:18:42 -0700

Stephen Kent wrote:

>>>>> forward a datagram to.  And the two may be comepletely independent 
>>>>> or completely entwined, depending on the nature of the device.
>>>>
>>>>
>>>>
>>>> changes by the time the subsequently tunneled (or not tunneled) 
>>>> packet is emitted from IPsec.
>>>>
>>>> issue is flux in the forwarding table and whether it is _allowed_ to 
>>>> affect SPD selection.
>>>>
>>> interface/ next hop to send the packet to.  Whoever feels that these 
>>> are or need to be entwined for their application is free to do so.. 
>>> Those
> We have enough variation in how different contexts want to select SPDs 
> (when more than one is needed) that I don't think we can do more than 
> say that there is a lookup function which takes the outbound packet and 
> local metadata as inputs.  This seems analogous to your earlier 
> suggestion to allow a forwarding function to have access to the whole 
> outbound packet to support an unspecified forwarding lookup, when we 
> were thinking of having an explicit forwarding function as part of IPsec.

That was a straw-man intended to demonstrate that having a forwarding 
function inside IPsec would create a security hole. This creates the 
same hole, by analogy.

> Many IPsec implementations will need only one SPD, so this whole issue 
> is a no-op in those cases. 

Agreed.

> In cases where multiple SPDs are 
> exercise caution in these contexts.  Generally, we cannot have it both 
> ways.  if we keep things simple, we can have more confidence in their 
> security, but we loose flexibility.
> 
> Steve

This level of 'flexibility' opens a large door, especially if there are 
no constraints on that function. If such a door is unspecified, how can 
we trust a particular implementation?

Joe

---

From: "Mike Taylor" <[email-masked]>
Date: Tue, 21 Oct 2003 10:34:11 -0700

See my comments below.

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2003 10:10 AM
> To: Joe Touch
> Cc: Mark Duffy; Mike Taylor; [email-masked]
> Subject: Re: SPD issues
>
>

Bear in mind that it doesn't really matter if there is only one SPD.
Because even a single SPD can have multiple policies for outbound
red datagrams that match the source address of a particular sender,
and provide different levels of security (perhaps none at all) depending
on the destination address.

So it isn't really a no-op just because there is only one SPD.

Believe me, I'm in favor of keeping the RFC as simple as possible, and
ideally would like to see forwarding and IPSec SPD lookup divorced from
one another.  But it isn't yet clear that truly solid security can be
provided that way.

Its all got me wondering if there really is a fool-proof solution to
this problem other than specifying that the level of protection afforded
to any given outbound datagram should be based solely on the source
of the datagram, and not on the destination.  In other words, in the real
world if I am transmitting sensitive information then effectivly all
networks are untrusted.

But if we want to continue with the notion that some networks are trusted
more
than others, then perhaps (and I recognize that it would be fairly radical
change) the correct model for IPSec is that there MUST be an outbound SPD
per-interface (becaues we view security as inherently being tied to the
trustworthiness of different interfaces) and that the security afforded
a datagram is based strictly on the source of the datagram and the interface
that it exits, rather than the source and the destination addresses.

Because I think the issue we're dancing around here is that while I might
think its OK to send a red datagram to a given destination with possibly
no protection at all, I only belive that because I believe that the
destintation
is connected to some trusted network where security isn't needed.
Otherwise,
I'd be pretty crazy to do it.  But this ignores the fact that due to routing
errors or misconfiguration, or a bad implementation, the datagram might
actually
escape onto a network I don't trust.  This doesn't have to be the public
internet.
It might just be, for example, that a datagram from accounting to HR
gets misrouted into an engineering lab where it is captured by some
engineer's packet
sniffer and he sees that the big layoff is coming.  Gee, wonder why I
thought of
that example.  Must be the times. :(

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Mon, 20 Oct 2003 22:59:23 -0700

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2003 17:05:46 -0400

At 13:53 -0700 10/21/03, Joe Touch wrote:
>Stephen Kent wrote:
>
>>Folks
>>
>>There may be some misunderstanding about what holes an SPD 
>>selection function creates.
>
>
>...
>>The only way to be really confident about the security services 
>>being provided for traffic is to have just one SPD, or to make sure 
>>that the multiple SPDs are not overlapping in terms of the 
>>destination addresses (for outbound traffic), or that the security 
>>services offered in any overlapping entries are equivalent.
>
>Steve,
>
>Is it possible that this paragraph ("The only way...") should be 
>added as the caveat? I.e., the concern I had was that SPD indexing 
>could be an open loophole; this closes it sufficiently.
>
>Feel free to forward this suggestion to the list if you feel it 
>would be useful.
>
>Joe
Joe,

Good point.  I think it is fair to warn folks about the need to pay 
very close attention to config mgmt issues when multiple SPDs are 
employed. A reference to Peter's paper might also be relevant.

Steve

---

From: "Mike Taylor" <[email-masked]>
Date: Tue, 21 Oct 2003 18:37:20 -0700

> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Tuesday, October 21, 2003 2:06 PM
> To: [email-masked]
> Subject: Re: SPD issues
>
>

I don't see how having a single SPD helps.  Even with a single
SPD I can have two outbound policies for the datagrams that match a given
source address where different levels of protection are applied based
on the destination address.  Suppose, for example, that I have an SG
with 3 interfaces, one to an untrusted network, 192.168.0.0/24,
and the other two to trusted private networks 10.240.1.0/24 and
10.240.2.0/24.
And furthermore, there is a 3rd trusted subnet, 10.240.3.0, reachable
via the router 10.240.1.1.

Now I could have two policies in my one SPD for datagrams from source
addresses on 10.240.2.0/24.  If they're going to 192.168.0.0/24 then I want
ESP encryption and authentication.  If they're going to 10.240.3.0/24 then
I just bypass IPSec.

Then if routing gets messed up and a datagram from 10.240.2.0 and destined
to 10.240.3.0 gets no IPSec applied but ends up being sent out of the
192.168.0.0/24 interface instead of 10.240.1.0 I have sent sensitive
information
in plaintext format onto an untrusted network.

Still, I admit that I'm not sure this is something that can be dealt with
easily by IPSec.  It would seem to require that IPSec always be built
natively
into an IP stack, and that it is somehow tied very tightly to the forwarding
database such that routes are essentially owned by IPSec and must have a
policy,
and furthermore, the interface to which the route points cannot be changed
without
the policy explicitly being redefined, in other words, delete the route and
re-enter
with a new policy.  Of course, a human adminstrator could still very well
make an error and
point the route and the wrong interface.

It seems to me that the ultimate problem is that it really isn't
possible to provide rock solid security unless applications are aware of it,
and
it is provided end-to-end (i.e. no tunnel mode, SGs etc.)  Ultimately this
is the only model that properly fits the original concept of IP as an
unreliable
best-effort datagram delivery service.  In an ideal world (that probably
won't
ever exist even after IPv6 becomes predominant) there would be nothing
between
hosts except pure routers.  No NAT, no SGs, no proxies, etc. etc.  As the
forefathers
knew, this is the only way to achieve a highly robust, self-healing Internet
topology.  Of course, this model would likely put a lot of us out of
business. :(

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Oct 2003 11:37:01 +0300

> processing is completed. There are many other examples.

This actually brings one question I had earlier up. In IPv6 which
addresses is used when matching against SPD in case there are routing
headers in the packet? Final destination, next hop destination etc. I
think the current RFC does not say anything about those, and some
implementations might check only the routing header final destination
address and some might use the next hop destination. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Markku Savela <[email-masked]>
Date: Wed, 22 Oct 2003 15:13:29 +0300

> From: Tero Kivinen <[email-masked]>

> address and some might use the next hop destination. 

For me, it is the next hop destination. Note, however that if SG is
also a router, there will be two cases for incoming packet with
routing header:

a) ip dst = routers own address => process routing header, IPSEC will
apply to next hop. (which may be the router itself again). 

b) ip dst != routers own address, routing header is NOT processed,
next hop is searched based on the ip dst address. Again, IPSEC apply
to next hop.

This is as it should be. Do not mess with it!

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Oct 2003 09:16:41 -0400

>and the other two to trusted private networks 10.240.1.0/24 and

IPsec really defines a boundary (what we woulkd traditionally call a 
red/black boundary) that packets traverse. if you decide that the 
interfaces to the trusted nets are on the red side of an IPsec device 
with multiple interfaces, then IPsec would not be invoked at all. if 
you put interfaces on the black side, you have made a mistake, 
because you are explicitly relying on the routing/forwarding on the 
black side to do the right thing.

>point the route and the wrong interface.

see comments above

>topology.  Of course, this model would likely put a lot of us out of

I think you are overstating the problem a bit. IPsec is designed to 
that one can deploy it in a variety of configurations without 
requiring applications to be aware of its presence. However, one can 
certainly misconfigure SPDs to undermine the security offered, and if 
one allows bypass of certain traffic, then there will always be 
channels that can be used to exfiltrate data from a host or site.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Oct 2003 16:34:31 +0300

> This is as it should be. Do not mess with it!

That interpretation is fine as long as there is nothing that looks
like firewall there. In the IPsec there are drop rules so it have a
minimal firewall inside of the IPsec implementation. Using the routing
header allows users to bypass the restrictions created by the
adminstrator.

I.e Adminstrator defines policy of the SGW in the remote office:

	Host - SGW - Internet - SGW ----+--- internal net
				        |
					+--- smtp server
					|
					+--- www-proxy
					|
					+--- news server

	1) Any traffic to www-proxy is allowed (bypass)
	2) Any traffic to smtp server is protected by IPsec
	3) Drop all other traffic.

Now if users want to use some other services, like news server they
can send the packet to the www-proxy with routing header forwarding
the traffic to the news server, and that will go through even when we
have the rule 3, that says that traffic should be dropped.

They can also use the www-proxy to send traffic to the smtp-server,
which will now go through the internet in clear instead of using IPsec
protection as specified in rule 2. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 23 Oct 2003 17:09:57 +0200

>header allows users to bypass the restrictions created by the

Tero,

I tend to agree with your interpretation, the decision should be based on the final destination and not on the next hop. This is clear for the bypass/drop 'firewall' SPD entry.

AFAIK with the existing IPv4 implementations, the source routing option has been ignored by IPSec (it looked only to the IP destination address).

Of course, IPv6 is much more complex; specifically since Mobile IPv6 is also using RH. And, there you probably want to make your decision on the next hop... Contracdicting my first paragraph ;-)

Perhaps, the decision should be made if either the destination IP or any RH next-hop IP are matching the selector?

-eric

---

From: Stephen Kent <[email-masked]>
Date: Sun, 26 Oct 2003 19:39:56 -0500

At 17:09 +0200 10/23/03, Eric Vyncke wrote:
>I tend to agree with your interpretation, the decision should be 
>based on the final destination and not on the next hop. This is 
>clear for the bypass/drop 'firewall' SPD entry.
>
>AFAIK with the existing IPv4 implementations, the source routing 
>option has been ignored by IPSec (it looked only to the IP 
>destination address).
>
>Of course, IPv6 is much more complex; specifically since Mobile IPv6 
>is also using RH. And, there you probably want to make your decision 
>on the next hop... Contracdicting my first paragraph ;-)
>
>Perhaps, the decision should be made if either the destination IP or 
>any RH next-hop IP are matching the selector?

We did overlook this in 2401, and we ought to be more precise in 2401bis.

The IPv6 destination is what I expect folks would use for selector 
checking, for both outbound and inbound traffic.

We might add a flag that explicitly disallows traffic with routing 
headers, as a local admin control for SPD entries.  In the IPv4 case, 
we could to do the same  re the source route option.

What do folks think?

Steve

---

From: Francis Dupont <[email-masked]>
Date: Mon, 27 Oct 2003 12:38:03 +0100

>any RH next-hop IP are matching the selector?
   
=> it should be the IP address in the destination field of the IP header
when the policy is evaluated.

   
=> I agree. In fact, this is part of the multi-protocol selector issue
(which we decided against) as RHs are extension headers.

   What do folks think?
   
=> I don't believe this is a good idea because it is the first step towards
the transformation of SPD entries into firewall rules, i.e., someone can
propose this in his implementation but this should not be in the standard.

Regards   

[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 27 Oct 2003 11:35:36 -0500

> > headers, as a local admin control for SPD entries.  
> 
> I think this is a bad idea. the local admin should use a firewall
> to restrict traffic with routing headers if needed. he shouldnt
> use the SPD to do this. we might accidentaly turn off protocols
> which make use of routing headers.

Huh?  You might accidentally disable stuff you need at an SPD-based
policy enforcment point, or accidentally disable stuff you need with a
"firewall".  What's the difference?

Any code which consults the SPD to do policy enforcement can be
thought of as a "firewall".

						- Bill

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Oct 2003 08:20:15 -0800

hi,

also routing headers come in different flavors. there is a type 2
routing header whose semantics are differnt. in type 2 routing
headers you can only specify one address (segmentsLeft is always
1) and packets with this routing header are never forwarded by a
node which processes the routing header. both the destination
address and the address inside the routing header should belong to
the same node. there is no security concerns with the use of this
routing header.

Vijay

---

From: Henry Spencer <[email-masked]>
Date: Mon, 27 Oct 2003 12:02:25 -0500 (EST)

On Mon, 27 Oct 2003, Bill Sommerfeld wrote:
> > use the SPD to do this...
> 

The SPD *is* a firewall.  One serious flaw of RFC 2401 was that it did not
make this clear.  The 2401bis draft does (section 2.1, second paragraph). 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Oct 2003 11:10:41 -0500

>propose this in his implementation but this should not be in the standard.

Francis,

SPD entries ARE firewall rules.  We are only debating how fancy they 
need to be.

Steve

---

From: Eric Vyncke <[email-masked]>
Date: Tue, 28 Oct 2003 10:16:32 +0100

At 19:39 26/10/2003 -0500, Stephen Kent wrote:
>The IPv6 destination is what I expect folks would use for selector checking, for both outbound and inbound traffic.

It does make sense to ignore the RH (43 type 1) and only base the SPD on source and destination.

>We might add a flag that explicitly disallows traffic with routing headers, as a local admin control for SPD entries.  In the IPv4 case, we could to do the same  re the source route option.

I would leave this as an implementation detail.

But, as it has been pointed by someone else, with mobile IPv6 there are two different IPv6 headers:
- Destination Option (60) which is used by a mobile node to indicate its 'permanent' (= home) address (as opposed to its care-of-address which is in the source address field of the IPv6 header)
- Routing Header (53 type 2) of second kind which is used by packets sent to the mobile node to indicate the 'permanent' address of the mobile node (as opposed to the care-of address which is in the destination address field of the IPv6 header)

This is very close to yet another tunnel in disguise. And there are good arguments to apply the SPD on two points:
- plain source and destination field of the IPv6 address: e.g., to protect the payload during the transit over the public network at the expense of a new IKE renegotiation during roaming
- permanent addresses (i.e. DO for packets sent by the mobile node and RH for packets sent to the mobile node): end to end protection

I'm mostly ignorant regarding MIPv6... and it would probably be safer and easier to state in RFC2401bis that the SPD for MIP (v4 and v6) will be defined in the framework of MIP4 and MIP6 WG. This means that the processing of RH type 2 and DO are explicitly not defined in rfc2401bis.

Cfr: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-03.html

-eric

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Oct 2003 10:48:56 +0100

=> we should make a distinction between a filtering mechanism and what is
sold as a firewall: Vijay and me share the opinion that the SPD belongs to
the first category and the RH stuff should be done by a device from
the second one. Of course, on a SG which is also a firewall, the SPD can
be extended in order to include plain firewall capabilities (this is better
than to fight against the firewall part :-).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Oct 2003 12:10:08 +0100

This is very close to yet another tunnel in disguise.

=> yes, draft-deering-ipv6-encap-addr-deletion-00.txt develops
this argument. But can we conclude that mobile IPv6 should be
considered as tunneled traffic, i.e., an IPsec node which is
not one of the end-points of the tunnel should only look at
the external IP header?

Regards

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 28 Oct 2003 11:35:33 -0500

> sold as a firewall

Any attempt to draw a clear distinction between "packet filtering" and
"firewall" will be doomed to failure.  

In this case, if you can subvert the intent of IPsec by adding routing
headers to packets, then we should consider independantly whether it
makes sense to add the ability to filter them to the SPD, not on
whether this is "packet filtering" or "firewalling"..

						- Bill