Nicolas Williams
2007-09-07 22:07:57 UTC
The connection latching I-D puts forward two informative models. The
next version, which I'm working on right now, will make one of those
models normative.
The two models, you might recall, are:
a) ULPs interface with IPsec via "template" PAD and SPD entries that get
"cloned" upon triggering events.
For example, a TCP connect() would create a template PAD entry with
the connection's 5-tuple as child SA constraints, prior to sending
the TCP SYN packet. A TCP listen() would create a template PAD entry
with the listener's 3-tuple as child SA constraints, prior to
accepting any TCP SYN packets.
There are other details, of course, but let's obviate them here. The
next version of the I-D will certainly have fleshed this model out a
lot more.
b) ULPs interface with IPsec by tagging packets as they go up or down
the stack. On input the IPsec layer tags the packet with the SAD
entry for the SA that protected it; the ULP checks that the SAD
matches the ULP's TCB latch and drops the packet if it does not. On
output the ULP tags the packet with its latched requirements and the
IPsec layer uses this to find an appropriate SA to protect the
outgoing packet with.
I'll make (a) the normative model, though (b) is much simpler to
implement (unless you have a NIC that can offload ESP/AH processing but
which cannot tag inbound packets with enough information).
Each model has some quirks though, and that's what I want to discuss
here.
The (a) model has the following quirks:
- synchronization
Packets race with changes to the IPsec PAD/SPD. This is a problem
that implementations of this model MUST overcome. One way to
overcome it is to create a barrier based on a timestamp: updates to
the PAD/SPD update the timestamp, the IPsec layer tags inbound
packets with the current timestamp, and the ULPs tag outbound packets
with the current timestamp, with the ULP layers dropping packets
whose timestamp tags are too old.
- ambiguous configurations
From what I can tell it is possible to configure IPsec so that
multiple peers can have access to overlapping traffic selectors, and
when this is the case we end up with a situation where:
- the ULP may not be able to determine the parameters to latch,
- and where even if the ULP could (e.g., because the ambiguous
configuration is created after a connection latch) the packets for
the given packet flow could be protected by one or more SA pairs
that do not match the latched parameters.
This is hard to detect and prevent. I think the right thing to do is
to document the problem and warn administrators not to create such
configurations if they would be problematic for them.
The (b) model has a single, minor quirk: if multiple peers can access
the same addresses then there may be multiple latched connections with
the same peer address, but each with a different peer ID.
Advice on the ambiguous configuration problem of model (a) is welcome.
Nico
--
next version, which I'm working on right now, will make one of those
models normative.
The two models, you might recall, are:
a) ULPs interface with IPsec via "template" PAD and SPD entries that get
"cloned" upon triggering events.
For example, a TCP connect() would create a template PAD entry with
the connection's 5-tuple as child SA constraints, prior to sending
the TCP SYN packet. A TCP listen() would create a template PAD entry
with the listener's 3-tuple as child SA constraints, prior to
accepting any TCP SYN packets.
There are other details, of course, but let's obviate them here. The
next version of the I-D will certainly have fleshed this model out a
lot more.
b) ULPs interface with IPsec by tagging packets as they go up or down
the stack. On input the IPsec layer tags the packet with the SAD
entry for the SA that protected it; the ULP checks that the SAD
matches the ULP's TCB latch and drops the packet if it does not. On
output the ULP tags the packet with its latched requirements and the
IPsec layer uses this to find an appropriate SA to protect the
outgoing packet with.
I'll make (a) the normative model, though (b) is much simpler to
implement (unless you have a NIC that can offload ESP/AH processing but
which cannot tag inbound packets with enough information).
Each model has some quirks though, and that's what I want to discuss
here.
The (a) model has the following quirks:
- synchronization
Packets race with changes to the IPsec PAD/SPD. This is a problem
that implementations of this model MUST overcome. One way to
overcome it is to create a barrier based on a timestamp: updates to
the PAD/SPD update the timestamp, the IPsec layer tags inbound
packets with the current timestamp, and the ULPs tag outbound packets
with the current timestamp, with the ULP layers dropping packets
whose timestamp tags are too old.
- ambiguous configurations
From what I can tell it is possible to configure IPsec so that
multiple peers can have access to overlapping traffic selectors, and
when this is the case we end up with a situation where:
- the ULP may not be able to determine the parameters to latch,
- and where even if the ULP could (e.g., because the ambiguous
configuration is created after a connection latch) the packets for
the given packet flow could be protected by one or more SA pairs
that do not match the latched parameters.
This is hard to detect and prevent. I think the right thing to do is
to document the problem and warn administrators not to create such
configurations if they would be problematic for them.
The (b) model has a single, minor quirk: if multiple peers can access
the same addresses then there may be multiple latched connections with
the same peer address, but each with a different peer ID.
Advice on the ambiguous configuration problem of model (a) is welcome.
Nico
--