A note about connection latchin.

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

Hmmm, never mind.  In model (a) connection latching is to be
enforced by
key management at latch and child SA creation time.  That is
what must
change in the processing model to allow a description of
model (a).
_______________________________________________

On Mon, Sep 10, 2007 at 01:44:32PM -0400, Stephen Kent
wrote:
> At 5:07 PM -0500 9/7/07, Nicolas Williams wrote:
> >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.
> 
> For SPD entries, the applicable term is "populate
from packet" and we 
> have a flag for that.  PAD entries don't have 5-tuples,
so did you 
> mean SPD above? If so, do you want to specify the
template PAD entry 
> separately above?

Although PFP seems appropriate, it's not quite sufficient. 
Since my
post on Friday I've realized just how best to describe
connection
latching as an extension of the IPsec child SA authorization
process.

As for what I meant by referenceing 5-tuples and PAD
entries, keep in
mind that I wrote "template PAD entries" -- which
in my I-D as it stood
on Friday (not submitted) referred to something somewhat
different from
PAD entries.  I'm abandoning that terminology; it's not just
confusing:
there's a better way to describe the state that is being
created.

Nico
-- 
_______________________________________________

At 3:22 PM -0500 9/10/07, Nicolas Williams wrote:
>On Mon, Sep 10, 2007 at 01:44:32PM -0400, Stephen Kent
wrote:
>>  At 5:07 PM -0500 9/7/07, Nicolas Williams wrote:
>>  >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.
>>
>>  For SPD entries, the applicable term is
"populate from packet" and we
>>  have a flag for that.  PAD entries don't have
5-tuples, so did you
>>  mean SPD above? If so, do you want to specify the
template PAD entry
>>  separately above?
>
>Although PFP seems appropriate, it's not quite
sufficient.  Since my
>post on Friday I've realized just how best to describe
connection
>latching as an extension of the IPsec child SA
authorization process.
>
>As for what I meant by referenceing 5-tuples and PAD
entries, keep in
>mind that I wrote "template PAD entries" --
which in my I-D as it stood
>on Friday (not submitted) referred to something somewhat
different from
>PAD entries.  I'm abandoning that terminology; it's not
just confusing:
>there's a better way to describe the state that is being
created.
>
>Nico
>--

never mind .... 

Steve
_______________________________________________