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

From: Richard Draves <[email-masked]>
Date: Wed, 17 Feb 1999 21:26:03 -0800

(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
--------------------------------------------------------------------
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: Dan McDonald <[email-masked]>
Date: Thu, 18 Feb 1999 09:12:25 -0800 (PST)

> headers. How should routing headers interact with IPsec?

See the AH spec.  Unfortunately, the precise wording of the LSRR option for
IPv4 exempts it from inclusion in AH's ICV, but the IPv6 routing header 0 is
perfect for AH inclusion.

> not make it possible to bypass security policies.

Why?  The proper use of AH allows authenticated source routes.  This is why
AH still exists, even after ESP had an ICV added to it.

Also, how?  Are you going to distribute keys along each hop?  That's
a lot of IKE negotiations.  You can do end-to-end AH on a source routed
packet in IPv6.  It's why we still HAVE AH, y'know.

> tunnel-mode associations.

If you wish to have every intermediate node process the packet, yes, you'll
_probably_ need tunnel mode.

> transport-mode AH.

Great example!  The packet would look like:

	IPv6 hdr dst B, src A
	Routing hdr, segments left = 2, addrs C, D
	AH (with SA residing on D)
	Transport hdr

That's all you need to do!  The source route in question can be authenticated
using AH.

> Does this sound reasonable?

It sounds like you're adding levels of complexity where you don't need any.

Dan