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

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

> Steve Kent and I have talked this over off-line and come to 
> agreement. (Actually, I think we were already in agreement, 
> we just weren't communicating effectively via email.) We 
> agree on the following two points:
> 
> 1. A node will only process an ESP or AH header if it is 
> participating in the relevant security association. In 
> particular, a node processing a routing header will not 
> "snoop" into ESP & AH headers that are not associated with the node.
> 
> 2. In any case, an IPsec-enabled node that is processing a 
> routing header (with segs left != 0) and hence forwarding a 
> packet must perform inbound and outbound security policy 
> checks. The IPsec processing in this situation is the same as 
> the IPsec processing performed by a security gateway that is 
> forwarding a packet not destined for itself.

Well, it seems we have consensus on the above points. On to something more
interesting & perhaps more controversial: what IPsec processing should a
correspondent node perform when sending to a mobile node?

My first email on this subject suggested that a correspondent node should
perform outbound IPsec processing twice: first looking up a security policy
using the home address as the destination address selector and applying the
resulting security associations, and then doing another security policy
database lookup using the care-of address as the destination address
selector and applying the additional security associations.

However after thinking about more scenarios, it's clear that's too
simplistic. I still think two outbound SPD lookups are necessary, using the
home address and the care-of address as the destination address selectors,
but the results of the two lookups must be *spliced* instead of just
concatenated.

An assumption here: I believe that it's impractical for a correspondent node
to update its security policy database to handle the movement of mobile
nodes.

The way this works without IPsec: a correspondent node CN is sending to a
mobile node with a home address HA. CN looks in its Binding Cache and
discovers a care-of address CA associated with the home address. CN sends
the packet with a routing header:
	IPv6 hdr - src CN, dst CA
	Routing hdr - segs left = 1, HA
	Transport hdr

So let's consider two scenarios with IPsec. In the first scenario, the
correspondent node has a transport-mode AH association with the home
address. The correpondent node sends packets that look like
	IPv6 hdr - src CN, dst HA
	AH hdr - transport-mode SA CN -> HA
	Transport hdr

Then the correspondent node learns that the mobile node has moved. The SPD
in the correspondent says that the care-of address is behind a security
gateway SG. A tunnel-mode ESP association with SG is required to reach the
care-of address. Now the correspondent node sends packets that look like
	IPv6 hdr - src CN, dst SG
	ESP hdr - tunnel-mode SA CN -> SG
	IPv6 hdr - src CN, dst CA
	Routing hdr - segs left = 1, HA
	AH hdr - transport-mode SA CN -> HA
	Transport hdr

Note that the correspondent node must do two outbound SPD lookups - one
using HA as the destination address selector, and another using CA as the
destination address selector - to discover both of the security
associations.

In the second scenario, the mobile node's home address is behind a security
gateway SG1. The correspondent node uses a tunnel-mode ESP association with
SG1 to reach the home address. So the correspondent node sends packets that
look like
	IPv6 hdr - src CN, dst SG1
	ESP hdr - tunnel-mode SA CN -> SG1
	IPv6 hdr - src CN, dst HA
	Transport hdr

Then the correspondent node learns that the mobile node has moved. The SPD
in the correspondent says that the care-of address is behind a different
security gateway SG2. The correspondent node must use a tunnel-mode ESP
association with SG2 to reach the care-of address. So the correspondent node
sends packets that look like
	IPv6 hdr - src CN, dst SG2
	ESP hdr - tunnel-mode SA CN -> SG2
	IPv6 hdr - src CN, dst CA
	Routing hdr - segs left = 1, HA
	Transport hdr
 
In this scenario, the security policy used with the home address is not used
when sending to the care-of address, while in the first scenario it is.
What's the difference? The difference is that in the first scenario, the
correspondent node has a security association directly with the home
address, while in this second scenario the association is with a security
gateway.

I think the correspondent node must do two outbound SPD lookups, using both
the home address (lookup #1) and care-of address (lookup #2) as destination
address selectors. Then the results of the two lookups are combined.
Associations directly with the home address (might be transport-mode or
tunnel-mode) are taken from the first lookup, and associations with
intermediate security gateways (always tunnel-mode) are taken from the
second lookup.

Then the headers from the security associations are combined with a routing
header as follows:
	<headers from tunnel-mode associations with security gateways,
	 outbound SPD lookup done with care-of address as destination
selector>
	IPv6 hdr - src CN, dst CA
	Routing hdr - segs left = 1, HA
	<headers from transport and tunnel-mode associations with home
address,
	 outbound SPD lookup done with home address as destination selector>
	Transport hdr

How does this sound?

Rich
Follow-Ups: