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

RE: Last Call: Mobility Support in IPv6 to Proposed Standard



(Is the draft
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-07.txt still
under consideration by the IESG?)

One of my concerns with the draft is that the interaction between mobility
and IPsec is barely mentioned (one paragraph at the end of section 10.1) -
not nearly enough is said to ensure interoperability, I think. And yet the
spec requires the use of IPsec for mobility.

At the interim WG meeting in Grenoble I got into a discussion with Brian
Zill, Allison Mankin, Aaron Griggs, & others about the mobility/IPsec
interaction. I think it's fairly complex.

I'm hoping to start a discussion by looking at routing headers. I couldn't
find anything in the IPsec architecture spec mentioning interactions with v6
routing headers or the source routing option in v4. Mobility uses routing
headers. How should routing headers interact with IPsec?

I believe that an IPsec-enabled node that is processing a routing header
with non-zero Segments Left should do inbound IPsec processing (SPD lookup &
policy verification) when it gets to the routing header and outbound IPsec
processing before sending the updated packet. This should be just the same
as a security gateway that is forwarding a packet. The routing header should
not make it possible to bypass security policies.

Carrying forward the analogy with security gateways, the IPsec processing
associated with a routing header should only support tunnel-mode
associations. Otherwise it makes life too difficult for the node processing
the routing header, because it would have to be finding & removing &
inserting headers in strange places. Security gateways must only support
tunnel-mode associations.

To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a
packet with a routing header through nodes B and C to node D. Node A can
have tunnel and/or transport mode associations with node D, say for example
transport-mode AH. Node A can only have a tunnel mode association with node
B, say for example tunnel-mode ESP.

The packets sent by node A will look like
	IPv6 hdr - dst B, src A
	ESP
	IPv6 hdr - dst B, src A
	Routing hdr, segments left = 2, addrs C, D
	AH
	Transport hdr

There might be further tunnel-mode associations between nodes B & C, nodes C
& D but node A won't know about that.

Note that this means that outbound IPsec processing on node A has to happen
*twice*, first for the final destination node D, and then again for the
first intermediate destination node B.

Does this sound reasonable?

Applying this to the mobility case, there's only one intermediate
destination address and the final destination and the intermediate
destination address happen to both be assigned to the mobile node.

Suppose the correspondent node has an active transport-mode AH association
for a TCP connection with the mobile node. Then the mobile node wanders off
and acquires a care-of address behind a security gateway. The correspondent
node needs to use tunnel-mode ESP to the security gateway to reach the
care-of address, and then transport-mode AH for the home address.

This demonstrates the example above: when the correspondent node sends to
the mobile node, it needs to do outbound IPsec processing twice, first for
the home address, then for the care-of address.

Thanks,
Rich


Follow-Ups: