[ipsec] Nested SAs in 2401bis

["Michael Roe" <mroe@microsoft.com>]

Steve, Karen,

I've been trying to understand how nested SAs work in 2401bis,
now that it doesn’t have SA bundles. I think it would make the
document easier to understand if there was a worked example of
an SPD with nested SAs.

Here's how I *think* it's suppsoed to work. Suppose we have a
transport mode SA from A to C, which is carried over a tunnel
mode SA from A to B. (e.g. A is a laptop on the public internet,
B is a firewall that protects a corporate network, C is a server
on the corporate network that demands end-to-end authentication
of A; alternatively, A is a MIPV6 mobile node and B is a home
agent)


+---+     +---+  +---+
| A |=====| B |  | C |
|   |------------|   |
|   |=====|   |  |   |
+---+     +---+  +---+

Then A's SPD looks like this:

   local remote protocol action
1  C     A      *        BYPASS
2  A     C      ICMP,ESP,IKE PROTECT(ESP, tunnel, A to B, auth+conf)
3  A     C      *        PROTECT(ESP, transport, auth)
4  A     B      ICMP,IKE BYPASS

A's unprotected-side forwarding table is set so that outbound packets destined
for C are looped back to the protected side. A's protected side forwarding table
is set so that inbound ESP packets are looped back to the unprotected side.

An outbound TCP packet from A to C would match rule 3 and have a transport-mode
header prepended to it. The unprotected-side forwarding table would then loop
back the packet. The packet is compared against SPD-I (see fig. 2 in 2401bis),
matches rule 1, and so is allowed back in. The packet is compared against the
SPD for a third time, and this time it matches rule 2, so that it gets a
tunnel mode header appended to it. This time the forwarding table doesn't
loop back the packet, because the outer source address is B, so the packet
goes out onto the wire.

An inbound TCP packet from C to A, wrapped in two ESP headers, would first
match 2 and have the tunnel mode header removed. The protected-side forwarding
function would then send it back to the unprotected side. It is compared against
SPD-O (see fig. 3 in 2401bis) and found to match rule 1, so it is allowed back
out. The packet is compared against the SPD for the third time. This time it
matches rule 3 and has the transport-mode ESP header removed. The forwarding
fucntion passes it up to the next layer, because it isn’t an ESP packet.

Is this right?

Thanks,
Mike

PS. It would appear that in a high-assurance implementation, the forwarding function
on the unprotected side is part of the trusted computing base. It is trusted to loop
back packets destined for C; if it doesn't, they won't get the second layer of crypto
applied to them and will be visible to an eavesdropper on the link between A and B.

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec