Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Apr 2008 13:00:04 -0500

On Fri, Mar 14, 2008 at 06:53:24AM +0100, Daniel Migault wrote:
> Hi,
> 
> Here are my comments on the draft. I tried to sum up the exchange I had with
> Nico.

Thanks.  My comments follow as well.

> < Although it adds almost nothing to the introduction and it is mainly a
> re-writing of the introduction, it might bring some clarification to the
> paper and to the connection latching concept:

Your proposed new intro text seems to do three things: summarize the
IPsec architecture (RFC4301), restate part of the intro that's already
there and, importantly, restates a constraint that is not clearly stated
in the intro (though it is stated elsewhere).  That constraint is this:
that under no circumstance does connection latching cause persistent
changes to IPsec policy databases.

I don't think it's safe to try to summarize the IPsec architecture here,
so I will not take that text, but I think it's crucial that sa

So I will add text like this:

> < The changes are requested from applications and not from the network
> administrator, which means that the ULP must not systematically overwrite
> the IPsec policies established by the network administrator. For example
> policy requests must not survive to crash, must not establish lower security
> as defined by the network administrator. One way not to survive to crash is
> to disable any modification in the user land.
> <
> < This lead us to consider a new object that will define security rules with
> specific characteristics : the Connection Latching Objects.
> <
> < This document defines :
> <    - What is a connection latching object (Section 2 Introduction).
> <    - The behavior of a latching object (that is to say its state machine
> section 2.1).
> <    - The interface of the Latching object with key managers and ULP
> (section 2.2).
> <    - Interaction between LD and traditional IPsec databases (section 4).

to the intro.

I will also add a sentence to the abstract (I'll also delete a redundant
sentence from the abstract) to the same efffect:

    Connection latching is layered on top of IPsec and does not modify
    the underlying IPsec architecture.

Additionally I'll add text to the security considerations section about
this.  Something like:

   Connection latching adds a new, non-persisting database to IPsec and
   new functionality to the IPsec key manager.  Stripped of all optional
   features, connection latching is really about protecting established
   packet flows from SPD and SAD changes that are not consistent with
   what the application and/or ULP would like.  This protection is
   achieved by tracking latched connections and synchronizing changes to
   the SPD and SAD with alerts to the ULPs that are responsible for
   affected latched connections.

   Excluding all optional features connection latching is simply a
   passive feature bolted to the side of the IPsec key manager.  When a
   connection latch cannot be guaranteed the only action to be taken is
   to synchronously inform the affected ULPs and applications.
   
   Including all optional features connection latching also involves
   dynamic modifications to the "logical SPD," which do not persist
   across reboots nor past the lifetime of latched packet flows, and it
   also optionally involves IKEv2 CHILD SA narrowing.

   That connection latching state never persists beyond the lifetime of
   associated packet flows, nor across events which necessarily
   terminate such state (including reboots), derives from the fact that
   the very state of those packet flows is also non-persistent.

   We believe that this construction of connection latching achieves the
   desired goal -- protecting applications from dynamic IPsec policy or
   too permissive an IPsec policy -- without doing violence to the IPsec
   architecture.

> < The considered model can be thus represented by the figure below:

I like your ASCII art, but I'm going to modify it somewhat.

Following our conversation I think we need to clearly delineate "kernel"
and "user" mode execution, even though it's mostly irrelevant in a
document like this one, because it'd relevant to most implementors; your
figure almost does this.

Also I think the ULP needs to be a box, as should be the key manager.
And rather than refer to decorrelated and non-decorrelated SPD I'd
rather speak of SPD and "logical SPD," where the latter is in the
kernel.  This last change is important because we want to demonstrate
that connection latching, even with all OPTIONAL features, never
modifies persistent IPsec policy.

> <    The ULP interfaces to the IPsec LD database are as follows:
> ---
> >    The ULP interfaces to the IPsec PAD database are as follows:

Good catch.  I'll make it "The ULP interfaces to the key manager ..."

> 648,659d584
> <    The IPsec to ULP interfaces is as follows:
> <
> <    o  POP_MESSAGE(5-tuple, message) -> latch handle
> <
> <          Pop up a message (code) to the ULP.

Yes, I'd described the IPsec->ULP interface rather informally.

I think we want something like:

   o INFORM(5-tuple, BREAK | SUSPEND)

There's no return value for this function.

> < The State diagram with functions can be represented by the figure below:
> < [I removed mine]

Er, could you send it again?

I'll review your "Interaction between LD and other IPsec Databases"
section next.

Thanks!

Nico
-- 
_______________________________________________

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Apr 2008 14:38:11 -0500

> I like your ASCII art, but I'm going to modify it somewhat.

How about this (GIF version attached):

   +--------------------------------------------+
   |                       +--------------+     |
   |                       |Administrator |     |
   |                       |apps          |     |
   |                       +--------------+     |
   |                              ^             |
   |                              |             | user mode
   |                              v             |
   | +--------------+      +---------------+    |
   | |App           |      |IKEv2          |    |
   | |              |      | +---+  +----+ |    |
   | |              |      | |PAD|  |SPD | |    |
   | |              |      | +---+  +--^-+ |    |
   | +--------------+      +-----------|---+    |
   |   ^                               |        |
   +---|-------------------------------|--------+  user/kernel mode
   +---|-------------------------------|--------+  interface
   |   v                               |        |
   |+-------+   +----------------------|-------+|
   ||ULP    |   | IPsec key manager    |       ||
   |+-------+   |               +------v------+||
   | ^  ^       |               | Logical SPD |||
   | |  |       |               +-----------^-+||
   | |  |       | +----------+    +-----+   |  ||  kernel mode
   | |  +-------->| Latch DB |<-->| SAD |   |  ||
   | |          | +----------+    +--^--+   |  ||
   | |          +--------------------|------|--+|
   +-|-------------------------------v------v---+
   | | IPsec Layer  (ESP/AH)                    |
   | |                                          |
   +-v------------------------------------------+
   |   IP Layer                                 |
   +--------------------------------------------+
_______________________________________________

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Apr 2008 12:30:36 -0500

> Er, could you send it again?

Never mind.  I've written one:

           |
          CREATE_LISTENER_LATCH()
           |
           |
           v
      +--------+                  /
      |LISTENER|-------+     <CREATE_CONNECTION_LATCH()>
      +--------+       |        /
                       |       /
                       |      +
                       |      |
                       v      v
                    +-----------+
             +------|ESTABLISHED|<-------+
             |      +-----------+        |
        <conflict>      |    |         <conflict
             |          |    |          cleared>
             v          | <conflict>     |
           +------+     |    |      +---------+
           |BROKEN|     |    +----->|SUSPENDED|
           +------+     |           +---------+
             |     <RELEASE_LATCH()>         |
             |          |                    |
   <RELEASE_LATCH()>    v                <RELEASE_LATCH()>
             |         +------+              |
             +-------->|CLOSED|<-------------+
                       +------+

> I'll review your "Interaction between LD and other IPsec Databases"

I think your sections 4. and 4.1 mostly restate what a lot of the draft
already says, but section 4.2 inspires me to add an example section.

I think we need a section with a very simple sample PAD and SPD
configuration as follows:

 - The PAD shall have one entry specifying a PKI trust anchor that
   peers' certificates must validate to.

 - The SPD will have a single PROTECT entry with address and port ranges
   for traffic selectors, and a single BYPASS entry for another set of
   addresses and ports.  The protocol will be TCP in both cases.

Events in the example will include:

 - Creation of a TCP listener
    - receipt of a TCP SYN for that listener and completion of the TCP
      handshake

 - An attempt to do establish a TCP connection for a different
   application
    - sending a TCP SYN
    - completion of the TCP handshake

 - Connection closing

 - Network events that result in conflicting SAD updates
 - Local conflicting SPD updates

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 10:40:34 -0500

On Wed, Apr 09, 2008 at 04:55:26PM +0200, Daniel Migault wrote:
> If it means messages will be only "BREAK" or "SUSPEND", I don't see now 
> other kind of messages for now, but I am not absolutely certain there 
> will not be other kind of messages (informative, log  messages for 
> example....)

There's a third message: "restored" (for transitions from SUSPENDED to
ESTABLISHED).

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 10:51:39 -0500

On Wed, Apr 09, 2008 at 04:57:19PM +0200, Daniel Migault wrote:
> Here are my comments they might result from mis-interpretation of the 
> draft, but that how I understood it.
> 
> On the figure there is a transition from LISTEN to ESTABLISH state. I 
> might be wrong but I understood LISTEN state as an established state for 
> Listener connection Latch.  So I  would  not expect transition from 
> LISTEN to ESTABLISHED state. The only transition would be from LISTEN to 
> CLOSE state.

I didn't know how to draw this, but yes, LISTEN *spawns* ESTABLISHED
latches.  I thinkI'll just add text to the diagram, or use a different
style of line.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 10:50:05 -0500

On Wed, Apr 09, 2008 at 04:56:13PM +0200, Daniel Migault wrote:
> Your figure is probably clearer than mine, and it is better to separate 
> the esp/ah layer from the key management layer.
> The logical SPD is the combination of decorrelated SPD and ULP-driven 
> SPD.  The figure mentions interaction between IKEv2 and the Logical SPD, 
> but I don't see interaction between UPL and the logical SPD. Maybe one 
> could add one arrow between ULP and the logical SPD.

Yes, I need to fix that.  It needs to be more like this:
   +--------------------------------------------+
   |                       +--------------+     |
   |                       |Administrator |     |
   |                       |apps          |     |
   |                       +--------------+     |
   |                            ^      ^        |
   |                            |      |        | user mode
   |                            v      v        |
   | +--------------+      +-------++--------+  |
   | |App           |      |IKEv2  ||        |  |
   | |              |      | +---+ || +----+ |  |
   | |              |      | |PAD| || |SPD | |  |
   | |              |      | +---+ || +--^-+ |  |
   | +--------------+      +-+-----++----+---+  |
   |   ^                     |           |      |
   +---|---------------------|-----------|------+  user/kernel mode
   |   |syscalls             |  PF_KEY   |      |  interface
   +---|---------------------|-----------|------+
   |   v                     |           |      |
   |+-------+   +------------|-----------|-----+|
   ||ULP    |   | IPsec   key|manager    |     ||
   |+-------+   |            |  +--------v----+||
   | ^  ^       |            |  | Logical SPD |||
   | |  |       |            |  +-----------^-+||
   | |  |       |            +-------+      |  ||  kernel mode
   | |  |       |                    |      |  ||
   | |  |       | +----------+    +--v--+   |  ||
   | |  +-------->| Latch DB |<-->| SAD |   |  ||
   | |          | +----------+    +--^--+   |  ||
   | |          +--------------------|------|--+|
   +-|-------------------------------v------v---+
   | | IPsec Layer  (ESP/AH)                    |
   | |                                          |
   +-v------------------------------------------+
   |   IP Layer                                 |
   +--------------------------------------------+
_______________________________________________

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 12:00:22 -0500

> latches.  I thinkI'll just add text to the diagram, or use a different

OK, how about this:

                  |
          <CREATE_LISTENER_LATCH()>
                  |
                  v
             +--------+                  /
      +----..|LISTENER|........     <CREATE_CONNECTION_LATCH()>
      |    : +--------+       :        /
      |    <conn. trigger event>      /
      |   (e.g., TCP SYN receipt,    +
      |    : connect() call)  :      |
      |    :                  v      v
      |    :               +-----------+
      |    :        +------|ESTABLISHED|
      |    :        |      +--+-----^--+
      |    :    <conflict>    |     |
      |    :        |   <conflict> <conflict
      |    :        |         |     cleared>
      | <conflict>  |         v     |
      |    :        |  +------------+-------+
      |    :........|.>|SUSPENDED (OPTIONAL)|
      |    :        |  +---------+----------+
      |    :        v            |
      |    :      +------+       |
      |    :.....>|BROKEN|       |
      |           +-+----+   <RELEASE_LATCH()> +----------------------+
      |             |            |             |Legend:               |
      |   <RELEASE_LATCH()>      |             |  dotted lines denote |
      |             |            v             |     latch creation   |
   <RELEASE_LATCH()>|          +------+        |  solid lines denote  |
      +-------------+--------> |CLOSED|        |     state transition |
                               +------+        +----------------------+

PS: ASCII art drawing is fun!
_______________________________________________

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 12:36:33 -0500

On Wed, Apr 09, 2008 at 07:42:02PM +0200, Daniel Migault wrote:
> It sounds good for me, maybe we should also add dot lines with the 
> CREATE_CONNECTION_LATCH function.

Consider it done.

> Can the LISTEN state be considered as something like a "larval state"? 

Yes.

> Should we introduce in the same manner a CONNECTION state so that 
> listeners  and connections object have similar state architecture?

I guess I could.  I'll play with it.  This diagram is fairly busy though
and I want to keep it simple.  It needn't capture every subtlety :)

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 13:12:39 -0500

> and I want to keep it simple.  It needn't capture every subtlety :)

OK, here it is.  I think this is as busy as I want the state machine
diagram to be.

                  :
          <CREATE_LISTENER_LATCH()>
                  :                  :
                  v                 <CREATE_CONNECTION_LATCH()>
             +--------+              :
      +------|LISTENER|........      :     +----------------------+
      |    : +--------+       :      :     |Legend:               |
      |    <conn. trigger event>     :     |  dotted lines denote |
      |   (e.g., TCP SYN receipt,    :     |     latch creation   |
      |    : connect() call)  :      :     |                      |
      |    :                  v      v     |  solid lines denote  |
      |    :               +-----------+   |     state transition |
      |    :        +------|ESTABLISHED|   +----------------------+
      |    :        |      +-----------+
      |    :        |         |     ^
      |    :    <conflict>    |     |
      |    :        |   <conflict> <conflict
      |    :        |         |     cleared>
      | <conflict>  |         v     |
      |    :        |    +--------------------+
      |    :........|...>|SUSPENDED (OPTIONAL)|
      |    :        |    +--------------------+
      |    :        v            |
      |    :      +------+       |
      |    :.....>|BROKEN|       |
      |           +-+----+   <RELEASE_LATCH()>
      |             |            |
      |   <RELEASE_LATCH()>      |
      |             |            v
   <RELEASE_LATCH()>|          +---------------------------------+
      |             |          |CLOSED (common to LISTENER and   |
      +-------------+--------->|        CONNECTION latches both) |
                               +---------------------------------+
_______________________________________________

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Apr 2008 23:25:56 -0500

Thinking it over, the SUSPENDED and BROKEN states differ only in whether
an implementation supports transitioning from SUSPENDED to ESTABLISHED.

That difference is too small to warrant two states.

So I'm going to merge those two states.  That will make the state
diagram simpler.

Nico

---

From: "Daniel Migault" <[email-masked]>
Date: Thu, 10 Apr 2008 16:22:02 +0200

> an implementation supports transitioning from SUSPENDED to ESTABLISHED.

I personally like the idea of the SUSPEND state which is the state where
problems have to be solved, as opposed to the ESTABLISHED state where
Latched objects are running properly.
Maybe there is a solution to drop the  SUSPEND state and merge it with the
BROKEN state by  considering different transition condition from ESTABLISHED
to BROKEN.

I don't think we have too many states, and I eventually would add  CONECTION
larval state for LC objects. On the other hand, if I really had to drop one
state I would rather drop larval state like the LISTEN state.

> Nico

Daniel

-- 
Daniel Migault
Orange Labs / Security Lab
+33 (0) 1 45 29 60 52
+33 (0) 6 70 72 69 58
_______________________________________________

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Apr 2008 10:19:42 -0500

> BROKEN state by  considering different transition condition from ESTABLISHED

That's exactly what I did:

   <CREATE_LISTENER_LATCH(3-tuple, ...)>
                  :
                  v    <CREATE_CONNECTION_LATCH(5-tuple, ...)>
             /--------\           :   :
      +------|LISTENER|......     :   :
      |      \--------/     :     :   :   +--------------------+
      |        :            :     :   :   |Legend:             |
      |        :            :     :   :   | dotted lines denote|
      |  <conn. trigger event>    :   :   |    latch creation  |
      |      (e.g., TCP SYN :     :   :   |                    |
      |       received,     :     :   :   | solid lines denote |
      |       connect()     :     :   :   |    state transition|
      |       called, ...)  v     v   :   |                    |
      |        :        /-----------\ :   | semi-solid lines   |
      |        :        |ESTABLISHED| :   |    denote async    |
      |    <conflict>   \-----------/ :   |    notification    |
      |        :         ^       |    :   +--------------------+
      |        :         |      <conflict>
      |        :    <conflict    |    :
      |        :     cleared>    |    :
      |        :    (OPTIONAL)   |    :
      |        :         |       v    v
      |        :      /----------------\
      |        :.....>|     BROKEN     |.-.-.-.-.-> <ALERT()>
      |               \----------------/
      |                       |
   <RELEASE_LATCH()>   <RELEASE_LATCH()>
      |                       |
      |                       v
      |                    /------\
      +------------------->|CLOSED|
                           \------/

> state I would rather drop larval state like the LISTEN state.

Check out the above diagram.  I think it's simple enough now.

Nico

---

From: "Daniel Migault" <[email-masked]>
Date: Thu, 10 Apr 2008 18:10:57 +0200

This one is really great! Distinction of creation, state transition and
notification with different lines really helps to clarify it!
Daniel