Subject: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard

From: Richard Draves <[email-masked]>
Date: Mon, 22 Feb 1999 18:14:36 -0800

> I would think that if the intermediate dest (defined per the routing
> hdr) gets an IP packet, it should not do inbound IPsec processing, as
> it is not the final dest for the packet, i.e it is not one of the
> endpoints of the IPSEC session. On the otherhand, if the packet was
> tunnelled to it then it would make sense to do inbound IPSEC
> processing.

See example below arguing that inbound IPsec processing should be required
for intermediate destinations.

> Security gateways only operate on tunnelled packets, destined to it.
> I agree that it is not the final destination, but is in the sense
> of the IPSEC session.
> 
> Yes if the intermediate dest (one of the intermediate IP addresses in
> the routing header) is a security gateway, it should do the outbound
> IPSEC processing.

There are two approaches to my questions about the interaction of routing
headers and IPsec - the first is to think generically about routing headers,
and the second is to think specifically about mobility scenarios. The
mobility scenarios are good because they are very concrete, but they use the
routing header in a very stylized way.

In a later message I'll examine some more mobility scenarios. To get back to
this particular thread, which is about more generic routing header
scenarios:

I don't understand how it can be legitimate for an IPsec-enabled node that
is receiving a packet with a routing header to bypass inbound IPsec
processing.

A very concrete, simple example: consider a node SG. SG has two interfaces,
an interface to the public network and an interface on a private network.
Node A is on the public network and node B is on the private network. The
SPD on SG requires all traffic through it to & from the public network to be
protected with tunnel-mode ESP. This is a classic security gateway scenario.
So in the normal case when node A sends a packet to node B, it will look
like
	IPv6 hdr - src A, dst SG
	ESP
	IPv6 hdr - src A, dst B
	Transport hdr

This packet will arrive at SG. The outer IPv6 header will be processed. The
ESP header will be processed. The inner IPv6 header will be processed and SG
will realize it needs to forward the packet. It will do an inbound SPD
lookup and verify that the packet was protected with the appopriate
tunnel-mode ESP security association, which it was. Then it will do outbound
SPD processing, which will find a policy allowing the packet to be sent
without further protection, and it will send the packet as
	IPv6 hdr - src A, dst B
	Transport hdr

That's all well and good and I hope we are in agreement so far.
Now suppose SG receives a packet that looks like
	IPv6 hdr - src A, dst SG
	Routing hdr - segs left = 1, B
	Transport hdr

Now you are saying that SG should not perform any inbound IPsec
processing?!? This would mean that SG will send the packet on to B without
having verified that it was properly protected, bypassing the intended
security policy.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Feb 1999 18:41:45 -0800 (PST)

> having verified that it was properly protected, bypassing the intended

Presumably SG will do the same checks as when it receives a packet without
a routing header:
	IPv6 hdr - src A, dst B
	Transport hdr

If the SPD says that packets arriving on that interface must be protected with 
tunnel-mode ESP the SG would drop both the routed and source routed packets.

Thus as far as I understand there isn't anything specific to source routing
here other than an implementation having to perform the checks both
in the normal forwarding path and when processing a routing header (which
might be the same code on some implementations).

   Erik

---

From: Quaizar Vohra <[email-masked]>
Date: Mon, 22 Feb 1999 19:45:33 -0800 (PST)

> having verified that it was properly protected, bypassing the intended

I am sorry I was unclear in my last mail. When I said that SG will not
do inbound IPSEC processing, I did not mean that it will not check its
policies to see if the packet should have come encrypted to it
If it has such a policy, it should drop the packet.

Eric already clarified this.

The intention of my previous mail was to say that the presence
of source routing header in a packet should not change the IPSEC
behavior either at the inbound or outbound. While a routing
header might be considered as part of policy lookup, if an
implementation allowed defining IPsec policies filtering on
intermediate destination.

Quaizar

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Feb 1999 12:48:35 -0500

Richard,

	<snip>
>is receiving a packet with a routing header to bypass inbound IPsec

There is no contradiction here if the node is not a party to an SA
associated with the IPsec headers in the packet in question.  A security
policy at an intermediate node could allow traffic to transit without Ipsec
processing, if it "appeared" that such processing had been applied already.
I'm not suggesting that this is good or bad, just making an observation
about what it means to implement IPsec at an SG vs. what it implies for
processing of transit traffic.  I don'ty necessarily think we're in
disagreement here, but I didn't agree with your characterization of the
situation, in the cited paragraph.

Steve