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

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



Erik asked about more cases where mobility and IPsec interact:

> What about the case when the correspondent doesn't have a 
> binding cache
> entries - perhaps due to transient behavior (the first few packets) or
> perhaps due to the mobile wanting location privacy.
> Does the policy have to be coordinated between the correspondent host
> and the home agent that will tunnel the packet in those cases?
> What about when the CH and the HA are part of different admin domains?

If the correspondent node doesn't have a binding cache entry for the mobile
- ie it doesn't know the mobile is mobile - I think the correspondent when
sending just needs to do IPsec processing as usual with the mobile's home
address as the destination address selector. No policy coordination between
the correspondent and the home agent is required.

This assumes that there is no security gateway between the mobile and its
home agent, so that when the home agent intercepts the packet destined for
the mobile, the only security associations remaining in the packet are those
directly with the mobile's home address.

For example, suppose the correspondent has a transport-mode AH association
with the mobile's home address. The correspondent sends packets like
	IPv6 hdr - src CN, dst HA
	AH hdr - transport-mode SA CN -> HA
	Transport hdr

The home agent intercepts these and sends them to the care-of address.
Suppose the care-of address is behind a security gateway. The home agent
sets up a tunnel-mode ESP assocation with the security gateway and sends
packets like
	IPv6 hdr - src Agent, dst SG
	ESP hdr - tunnel-mode SA Agent -> SG
	IPv6 hdr - src Agent, dst CA
	IPv6 hdr - src CN, dst HA
	AH hdr - transport-mode SA CN -> HA
	Transport hdr

In this situation the mobile will do a first inbound SPD check when it hits
the 3rd IPv6 header. The first policy check will use as selectors source
Agent and destination CA. (It will verify that no association exists between
the Agent and the care-of address.) It will do a second inbound SPD check
when it hits the transport header. The second policy check will use as
selectors source CN and destination HA. (It will verify the transport-mode
AH association between the correspondent and the home address.)

> When two mobile nodes communicate there are actually 4 IP addresses
> in use since each of them have a care-of-address and a home address.
> Does that mean you need to do 4 SPD lookups for the 4 combinations of
> source and destination?
> 	Source home address -> Destination home address
> 	Source home address -> Destination COA
> 	Source COA -> Destination home address
> 	Source COA -> Destination COA
> 

I think when two mobile nodes are communicating, you still only want two SPD
lookups. The two SPD lookups are first using the two home addresses as
destination and source selectors, and then second using the two care-of
addresses as destination and source selectors. The results of the two
lookups are spliced together. Associations directly with the destination
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 and destination options header as follows:
	<headers from tunnel-mode associations with security gateways,
	 outbound SPD lookup done with care-of addresses as selectors>
	IPv6 hdr - src care-of address, dst care-of address
	Routing hdr - segs left = 1, dst home address
	<headers from transport and tunnel-mode associations with home
address,
	 outbound SPD lookup done with home addresses as selectors>
	Destination options hdr - Home Address option, src home address
	Transport hdr

Looking at what I just wrote, I'm unclear on two things:

1. The desired placement of the Home Address option. Should it be
immediately before the transport header, or immediately after the Routing
header? (The draft tries to specify this in section 10.1, but I'm not sure
which alternative it means or which is correct.)

2. The processing of this packet when it gets to the destination mobile
node. Does the routing header processing require inbound and outbound
security policy checks before it is looped-back internally? This is the
consensus that we already reached for generic routing header processing -
it's like forwarding. But in this case the new destination address is
reached via loopback, not forwarding outside the node.

Rich