[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Mobility Support in IPv6 to Proposed Standard
> 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.
<SNIP!>
Okay, you got me there...
> 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.
Okay. Your example below...
> 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
Was different from your previous example where the inner and outer IPv6
headers had the same destination. I was assuming you were focussing on that
case. When you have to transit via a security gateway, you have no choice
but to tunnel.
> 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.
<SNIP!>
> 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.
For dst SG != dst CA, you're right, and even dst SG == dst CA, it works.
> 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.
I know it runs counter to the IPv6 arch spec, but that spec says that the
order is a suggested one, not a mandatory one.
Dan
References: