Re: [ipsec] Nested SAs in 2401bis

[Stephen Kent <kent@bbn.com>]

At 7:32 PM +0100 8/4/04, Michael Roe wrote:
>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.

thanks for constructing an example. we'll incorporate it, with some
minor changes, into an appendix.

>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

I would change this entry to make the protocol field = ESP, to keep it
tightly constrained, and to make it clear that what we want is to loop back
packets that have already had ESP applied.

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

as noted above, if the goal is to bypass ONLY the packets from C that 
are being protected via this nesting, I'd construct a more 
restrictive SPD entry for #1, one that requires the packet to have 
ESP as the declared protocol.

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

Need to say why the protected side forwarding table loops it back,
e.g., because the protocol is ESP, indicative of nesting.

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

yes. as I said, I'd make a minor change to the first SPD entry, and I'd
add in a description of forwarding table entries on each side to make it
as clear as possible, but this is a good example and I agree that it will
help explain how to achieve nesting.

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

agreed.

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