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

RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Proposed Standard

> 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
Follow-Ups: