[btns] Minor connection-latch problem in AUTH48

[Nicolas Williams <[e-mail]>]

During AUTH48 review I noticed this:

   o  CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection
      parameters], [peer ID], [local ID]) -> latch handle | error

-------->If no connection latch exists in the ESTABLISHED states with
-------->the same 5-tuple, and if there exist no child SAs that match
-------->the given 5-tuple, and if local policy permits it, then the
-------->system MUST initiate an IKE exchange to set up child SAs for
-------->this 5-tuple.  Otherwise, an error is returned to the ULP.
         Once one or more applicable SAs exist in the SAD and all such
         SAs share the same type and quality-of-protection parameters
         and the same peer, then this operation creates a connection
         latch object in the ESTABLISHED state for the given 5-tuple.
         If the caller provided all the optional arguments to this
         operation, then the resulting connection latch can be created
         in the ESTABLISHED state directly.

-------->If there exist no child SAs matching the given 5-tuple, then
-------->the key manager SHOULD try to create a pair of child SAs for
         that 5-tuple.  In any case, the key manager can expect that the
-------->ULP will send a packet that would trigger the creation of such
-------->SAs.

There are two conflicts here.  The first and second highlighted
sentences conflict in that one says "MUST" while the other says
"SHOULD".  The third highlighted sentence conflicts with the first two
highlighted sentences.

The third highlighted sentence is the correct one: the IKE exchange need
not be triggered until the ULP sends a packet.  The IKE exchange _can_
be triggered before then (since the key manager knows, from the fact
that CREATE_CONNECTION_LATCH() was used, that that packet is coming, but
it doesn't need to be.

Now, if the key manager waits for the ULP to send a packet then the
latch that gets created cannot have all parameters filled in.  That is,
we have a "larval" state to consider.

IMO this is a fairly minor editing issue, but nonetheless it should be
fixed.  And though minor, the amount of change involved (a new state!)
definitely requires review by the WG.  (I've also asked Tim, and he
concurs.)

My proposed resolution is to add a new state, called "LARVAL", a
description of that state in section 2.2, update the state diagram in
figure 1, and update the description of CREATE_CONNECTION_LATCH().

Section 2.2 now reads:

2.2.  Connection Latch State Machine

   Connection latches can exist in any of the following five states:

   o  LISTENER

   o  LARVAL

   o  ESTABLISHED

   o  BROKEN (there exist SAs that conflict with the given connection
      latch, conflicting SPD changes have been made, or DPD has been
      triggered and the peer is considered dead or restarted)

   o  CLOSED (by the ULP, the application or administratively)

   and always have an associated owner, or holder, such as a ULP
   transmission control block (TCB).

   A connection latch can be born in the LISTENER state, which can
   transition only to the CLOSED state.  The LISTENER state corresponds
   to LISTEN state of TCP (and other ULPs) and is associated with IP
   3-tuples, and can give rise to new connection latches in the
   ESTABLISHED state.

   A connection latch can also be born in the LARVAL, ESTABLISHED and
   BROKEN states, either through the direct initiative of a ULP or when
   an event occurs that causes a LISTENER latch to create a new latch
   (in either ESTABLISHED or BROKEN states).  These states represent an
   active connection latch for a traffic flow's 5-tuple.  Connection
   latches in the LARVAL state can transition to the ESTABLISHED and
   BROKEN states.  Connection latches in the ESTABLISHED state can
   transition to the BROKEN and CLOSED states.  Connection latches in
   the BROKEN state can transition to the the LARVAL state if and only
   if the latch had been in the LARVAL state before and never in the
   ESTABLISHED state.  Connection latches in the BROKEN state can
   transition to the ESTABLISHED states as well as to the CLOSED state.

   The LARVAL state is used when not all the parameters to be latched
   are known; a future IKE exchange may fill them in.  Connection
   latches remain in the LARVAL state until a child SA appears in the
   the SAD from which all the missing parameters can be obtained, in
   which case it transitions to the ESTABLISHED state.  If it is
   possible that conflicting SAs can appear in the SAD before a latch in
   the LARVAL state can be changed to the ESTABLISHED state, then the
   latch will transition to the BROKEN state, and may later transition
   back to LARVAL or ESTABLISHED when the conflict clears up.

   Connection latches remain in the CLOSED state until...
   ...

The state diagram now looks like:

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

And the description of CREATE_CONNECTION_LATCH() now reads:

   o  CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection
      parameters], [peer ID], [local ID]) -> latch handle | error

         If no connection latch exists with the same 5-tuple, and if
         local policy (i.e., the SPD) permits it, then a latch is
         created in either the LARVAL, ESTABLISHED, or BROKEN states.
         Otherwise, an error is returned to the ULP.  If one or more
         applicable SA pairs exist in the SAD, and all such SAs share
         the same type- and quality-of-protection parameters and the
         same peer, then this operation creates a connection latch
         object in the ESTABLISHED state for the given 5-tuple.  If more
         than one applicable SA pair exists in the SAD that do not agree
         on type-, quality-of-protection parameters and peer IDs, then
         this operation creates a connection latch object in the BROKEN
         state.  If no SA pairs exists in the SAD then this operation
         creates a connection latch object in the LARVAL state.  If the
         caller provided all the optional arguments to this operation,
         then the resulting connection latch can be created in the
         ESTABLISHED state even if there are no applicable SA pairs in
         the SAD.

         If there exist no child SAs matching the given 5-tuple, then
         the key manager MAY try to create a pair of child SAs for that
         5-tuple.  In any case, the key manager can expect that the ULP
         will send a packet that would trigger the creation of such SAs.
         Either way, and assuming no conflicts arise, the necessary
         child SA pairs should eventually be created, causing a latch in
         the LARVAL state to transition to the ESTABLISHED state.


Comments?

Nico
--