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

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

> > 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.
> 
> I can understand sometimes wanting to do this.  But do you 
> want this to
> happen all of the time?

Yes I think an IPsec-enabled node should do inbound & outbound IPsec
processing when it hits a routing header. Otherwise the routing header will
be a mechanism for bypassing the security policies on the node. For example
if the node is a security gateway connecting an internal net and an external
net, and the security gateway receives a packet with a routing header that
directs the packet from the external net to the internal net, then security
processing should happen! Just the same as security processing when
forwarding packets.

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

Yes I'm sure :-)

Go back to the mobility example: I (node A) have a security association with
a mobile node using its home address HA. My SPD tells me to use
transport-mode AH when talking to HA. I have a TCP connection in progress to
the mobile node, protected by transport-mode AH.

Now the mobile node moves. It goes behind a security gateway SG. It has a
care-of address CA. My SPD tells me to use tunnel-mode ESP via SG when
talking to address CA.

When I send a packet to the mobile node, it needs to look like
	IPv6 hdr, dst SG, src A
	ESP (SA with SG)
	IPv6 hdr, dst CA, src A
	routing hdr, segments left = 1, addr HA
	AH (SA with HA)
	TCP hdr

Otherwise the scenario will break. Now how do I generate this packet? The
only thing that makes sense to me is to do the outbound IPsec processing
twice, first with destination address HA and then with destination address
CA.

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

Yes, this would be awful to implement. It would be like having a
transport-mode SA with a security gateway, which is a painful for a security
gateway to support and hence the IPsec arch spec disallows it. I think for
the same reason, only tunnel-mode SAs with the intermediate destination
should be supported. Note also that this arrangement of headers runs counter
to the preferred ordering in the IPv6 arch spec.

Rich
Follow-Ups: