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

From: Richard Draves <[email-masked]>
Date: Thu, 18 Feb 1999 14:05:40 -0800

> > 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?
> 
> 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.

I'm sorry, I wasn't clear. I understand that the AH header's ICV calculation
includes the routing header, so it provides end-to-end authentication of the
routing header contents.

The interaction between routing headers & IPsec & mobility that I'm
concerned with is:
- what kind of IPsec processing should a node processing a router header do?

I think the answer is, it should be analogous to the processing done by a
security gateway that is forwarding a packet.

- what kind of IPsec processing should a node sending a packet with a
routing header do?

I think the answer is there should be an outbound SPD lookup based on the
final destination address, and the appropriate SAs should be applied to the
packet, then there should be another outbound SPD lookup based on the first
intermediate destination address, and this could result in additional
tunnel-mode SAs that should be applied to the packet.

> > 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.
> 
> 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.

But suppose the outbound SPD in node A says that when A sends a packet to B,
it should be sent via tunnel-mode ESP to a security gateway SG. Then the
packet sent by A will look like:

	IPv6 hdr dst SG, src A
	ESP (SA between A and SG)
	IPv6 hdr dst B, src A
	AH (SA between A and D)
	Transport hdr

The point being that node A will need to do two separate lookups in its
outbound SPD when it sends a packet with a routing header.

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 14:29:05 -0800 (PST)

Sorry for my misunderstanding the question, Richard.

> security gateway that is forwarding a packet.

I can understand sometimes wanting to do this.  But do you want this to
happen all of the time?

> tunnel-mode SAs that should be applied to the packet.

Are you sure you want to do this?  What problem does protecting the packet a
second time solve?  If you have IPsec end-to-end, it is supposed to protect
you against bad guys along your path, even if the bad guys are explicitly
stated in a routing header (or are between your paths in an explicitly stated
routing header).

> outbound SPD when it sends a packet with a routing header.

I understand why you'd want to default to a self-encapsulation if you need to
doubly-protect the packet.  One _could_, however, do something like:

	 IPv6 hdr dst B, src A
	 ESP (SA dst B)
	 Routing Hdr  (B, C, D)
	 AH (SA dst D)
	 Transport

but that would get really confusing in an implementation.  I may have policy
that says protect traffix between A and B with transport ESP (or
none-specified, which could default to transport).

Let's hear more on this one, folks.  Thanks to Richard for bringing it up!

Dan

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Feb 1999 10:13:50 -0500

Rich,

The IPsec architecture does not envision processing by intermediate nodes
in the fashion you allude to. Only end systems and security gateways
perform IPsec processing, and they are arranged in pairs to bracket SAs.

Steve