Subject: [btns] Minor connection-latch problem in AUTH48

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Oct 2009 17:16:08 -0500

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Oct 2009 20:58:40 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> The third highlighted sentence is the correct one: the IKE
    Nicolas> exchange need not be triggered until the ULP sends a
    Nicolas> packet.  The IKE exchange _can_ be triggered before then
    Nicolas> (since the key manager knows, from the fact that
    Nicolas> CREATE_CONNECTION_LATCH() was used, that that packet is
    Nicolas> coming, but it doesn't need to be.

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

Right.

    Nicolas> Comments?

I have no other solution.  It all makes sense to me.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Oct 2009 20:54:18 -0400

Right.

    Nicolas> Comments?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Oct 2009 12:25:42 -0500

> I have no other solution.  It all makes sense to me.

Thanks!

I've beautified the state machine figure a bit (no arrows cross now),
clarified the trigger events in the figure, and restored dotted lines
that I'd accidentally made non-dotted.  The new figure is below.

Anyone else have comments?

   <CREATE_LISTENER_LATCH(3-tuple, ...)>
                 :
                 :    <CREATE_CONNECTION_LATCH(5-tuple, ...)>
                 V          :     :       :
            /--------\      :     :       :
      +-----|LISTENER|--+   :     :       :
      |     \--------/  |   :     :       :
      |       |         |   :     :       :
      |       |         |   :  /------\   :
      |       |         |   :  |LARVAL|   :  +--------------------+
      |       |         |   :  \------/   :  |Legend:             |
      |       |         |   :   |   |     :  | dotted lines denote|
      |    <matching child  : <matching   :  |    latch creation  |
      |      SAs installed> :  child SAs  :  |                    |
      |     [e.g., for TCP] : installed>  :  | solid lines denote |
      |     [ SYN soon to ] : [e.g., TCP] :  |    state transition|
      |     [ be received ] : [ SYN sent] :  |                    |
      |       |         |   :   |   |     :  | semi-solid lines   |
      |       |         v   v   v   |     :  |    denote async    |
      |       |       /-----------\ |     :  |    notification    |
      |       |       |ESTABLISHED| |     :  +--------------------+
      |   <conflict>  \-----------/ |     :
      |       |         ^       |   |     :
      |       |         |     <conflict   :
      |       |    <conflict   or DPD>    :
      |       |     cleared>    |   |     :
      |       |         |       |   |     :
      |       |         |       v   v     v
      |       |       /---------------------\
      |       +------>|       BROKEN        |-.-.-.-> <ALERT()>
      |               \---------------------/
      |                      |
   <RELEASE_LATCH()>   <RELEASE_LATCH()>
      |                      |
      |                      v
      |                    /------\
      +------------------->|CLOSED|
                           \------/

Nico
--

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 16 Oct 2009 12:48:16 -0700

Hi Nico,

I understand your proposal below tries to removes some sort of chicken-and-egg problem with the ULP creating the latch before sending a packet, the latch creation triggering key management to create an SA if there's none, and the packet being sent triggering the key management.

I'd like to make sure I understand the issue and your proposal, and in particular why we can't have the latch DB triggering directly the key manager: The existing text you have quoted below says "... if there exist no child SAs that match the given 5-tuple, and if local policy permits it", which implies that the 5-tuple is matched against the SPD. Couldn't this action trigger the key manager to establish a child SA without having to be triggered by an actual packet?

Since the ULP trying to create a latch presumably implies that the ULP has a packet to transmit, when it is the case that the ULP tries to latch the 5-tuple, an SPD entry is matched by the 5-tuple but no child SA is found, I'd like to understand what's the value of:

(1) latching the ULP on a larval latch, wait for the actual packet to be transmitted by the ULP to trigger IKEv2 after an SPD entry is matched but no child SA is found, establish the SA, and transition the latch to established

vs. 

(2) triggering IKEv2 based on the 5-tuple, establish the SA, latch the ULP on it.

To me it seems that your proposal (1) above simply implies delaying latching on the final SA (and performing an additional SPD match on the real packet but that's negligible), while I see no problem with (2)...

Am I missing something?

--julien

Nicolas Williams wrote:
> _______________________________________________
> btns mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/btns

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Oct 2009 15:39:53 -0500

On Fri, Oct 16, 2009 at 12:48:16PM -0700, Laganier, Julien wrote:
> I understand your proposal below tries to removes some sort of
> chicken-and-egg problem with the ULP creating the latch before sending
> a packet, the latch creation triggering key management to create an SA
> if there's none, and the packet being sent triggering the key
> management.

Actually, I was just trying to resolve a three-way conflict in the
text.  As a secondary goal I thought it would be a good idea to not
REQUIRE that the key manager initiate IKE/child SAs just because a ULP
is expected soon to send a packet that will require child SAs.  I think
that should be at least a MAY, and at most a SHOULD.

Perhaps the WG would say that we should REQUIRE that the key manager
initiate IKE/child SAs ahead of any triggering packet as a
simplification of the model (then we don't need a LARVAL state).  But I
could certainly see implementors not wanting to do that (for one it
makes the CREATE_CONNECTION_LATCH() call slow).

An alternative would be to say "must" instead of "MUST" and then explain
that if the key manager does not initiate IKE/child SAs as part of the
CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that we
have not defined.

You can see why I think this is a minor problem, but also why it'd be
better to address it.

> I'd like to make sure I understand the issue and your proposal, and in
> particular why we can't have the latch DB triggering directly the key
> manager: The existing text you have quoted below says "... if there
> exist no child SAs that match the given 5-tuple, and if local policy
> permits it", which implies that the 5-tuple is matched against the
> SPD. Couldn't this action trigger the key manager to establish a child
> SA without having to be triggered by an actual packet?

Indeed.  We don't absolutely need the LARVAL state.  Perhaps we should
describe it as an OPTIONAL state, since an implementation might not have
such a state at all.

Nico
--

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 16 Oct 2009 14:13:13 -0700

Nicolas Williams wrote
> makes the CREATE_CONNECTION_LATCH() call slow).

I think this is the external behavior that we want to capture. The specifics of how a given implementation achieves that need not to be specified in the RFC as long as the conceptual behavior is clear and guarantees interoperability.

Both style of implementation would conform to that behavior, whether or not the triggering occurs directly as a result of latch creation, or indirectly via triggering by the first packet.
 
> An alternative would be to say "must" instead of "MUST" and then
> explain that if the key manager does not initiate IKE/child SAs as part of the
> CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that
> we have not defined.

FWIW - from my perspective there's no difference between "must" and "MUST", RFC 2119 says about key word that "These words are often capitalized", but does not make it a must.

> > SPD. Couldn't this action trigger the key manager to establish a
> > child SA without having to be triggered by an actual packet?
> 
> describe it as an OPTIONAL state, since an implementation might not
> have such a state at all.

I tend to think that we do not need the state at all. It is a valid implementation strategy, but it does not need to be captured in the standard since there are as-valid alternatives (e.g., Latch Manager triggers key Management directly)_

--julien

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Oct 2009 16:16:52 -0500

On Fri, Oct 16, 2009 at 02:13:13PM -0700, Laganier, Julien wrote:
> I think this is the external behavior that we want to capture. The
> specifics of how a given implementation achieves that need not to be
> specified in the RFC as long as the conceptual behavior is clear and
> guarantees interoperability.

Let me re-think the text.  Perhaps I'll simply add a note that an
implementor whose key manager does not immediately initiake IKE/child
SAs on CREATE_CONNECTION_LATCH() must have a larval state that we don't
describe.

Would that work?

> Both style of implementation would conform to that behavior, whether
> or not the triggering occurs directly as a result of latch creation,
> or indirectly via triggering by the first packet.

The external behavior will only show differences in timing.

> FWIW - from my perspective there's no difference between "must" and
> "MUST", RFC 2119 says about key word that "These words are often
> capitalized", but does not make it a must.

When those terms are used in capitals I think the intent is clear; when
they are not the intent may be clear from the fact that the same
document also uses those terms in capitalized form.

> I tend to think that we do not need the state at all. It is a valid
> implementation strategy, but it does not need to be captured in the
> standard since there are as-valid alternatives (e.g., Latch Manager
> triggers key Management directly)_

OK.  I'll propose new text later today.

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 16 Oct 2009 15:49:41 -0700

> SAs on CREATE_CONNECTION_LATCH() must have a larval state that we don't

Yup - sounds good. (and maybe transient or intermediate is better than larval to describe that state...)

--julien

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Oct 2009 11:40:14 -0500

OK, this way the changes are much smaller and localized -- only the
description of CREATE_CONNECTION_LATCH() changes, to:

         If a) the requested latch does not exist (or exists, but is in
         the CLOSED state), b) all the latch parameters are provided, or
         if suitable SAs exist in the SAD from which to derive them, and
         c) if there are no conflicts with the SPD and SAD, then this
         creates a connection latch in the ESTABLISHED state.  If the
         latch parameters are not provided and no suitable SAs exist in
         the SAD from which to derive those parameters, then the key
         manager MUST initiate child SAs, and if need be, IKE_SA, from
         which to derive those parameters.

         The key manager MAY delay the child SA setup and return
         immediately after the policy check, knowing that the ULP that
         requested the latch will subsequently output a packet that will
         trigger the SA establishment.  Such an implementation may
         require an additional state in the connection latch state
         machine, a "LARVAL" state, that is not described herein.

         If the connection latch ultimately cannot be established,
         either because of conflicts or because no SAs can be
         established with the peer at the destination address, then an
         error is returned to the ULP.  (If the key manager delayed SA
         establishment, and SA establishment ultimately fails, then the
         key manager has to inform the ULP, possibly asynchornously.
         This is one of several details that implementors who use a
         LARVAL state must take care of.)

How's that?

This way the change is small enough that it wouldn't have required WG
discussion.  I should have thought of this.  Thanks Julien!

Nico
--

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 19 Oct 2009 14:59:31 -0700

Hi Nico,

Nicolas Williams wrote:
>          requested the latch will subsequently output a packet that
>          will trigger the SA establishment.  Such an implementation may

Hmm. Better, but somehow I'd rather take the 2 last paragraphs about the "larval" state completely out, because right now it IMHO says either too much or too less. It's not precise enough to tell an implementer who hasn't followed that discussion what to do yet it outlines at alternative to the key manager establishing the SA straight and the ULP latching the connection on the SA.

If you want to keep the "larval" text in, I've did some wordsmithing below that you might want to consider:
 
>          requested the latch will subsequently output a packet that
>          will trigger the SA establishment.  Such an implementation may
>          require an additional transient state in the connection latch state
>          machine, a "LARVAL" state, to which the connection is latched pending
>          establishment of the SA. The "LARVAL" state is not described further herein.
> 
>          error is returned to the ULP.  (Note that if the key manager delayed SA
>          key manager has to inform the ULP, possibly asynchronously.
>          This is one of several details that implementers who use a

--julien

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Oct 2009 17:14:10 -0500

On Mon, Oct 19, 2009 at 02:59:31PM -0700, Laganier, Julien wrote:
> Hmm. Better, but somehow I'd rather take the 2 last paragraphs about
> the "larval" state completely out, because right now it IMHO says
> either too much or too less. It's not precise enough to tell an
> implementer who hasn't followed that discussion what to do yet it
> outlines at alternative to the key manager establishing the SA
> straight and the ULP latching the connection on the SA.

I really want to leave the MAY in, as well as the note that that implies
a state that we're not describing.  I'm willing to remove the
parenthetical note, since that's really informative of something that
implementors, who chose to implement that MAY, would figure out on their
own anyways.

> below that you might want to consider:

I can't tell what's particularly different in your text.  You did split
a sentence, but I think I'll just re-write that sentence this way:

"Such an implementation may require an additional state in the
connection latch state machine: a "LARVAL" state, so to speak, that is
not described herein."

I think the colon helps more than either the comma I had written
originally, or than a period.

Nico
--

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Oct 2009 09:30:08 -0700

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Monday, October 19, 2009 3:14 PM
> To: Laganier, Julien
> Cc: [email-masked]
> Subject: Re: [btns] Minor connection-latch problem in AUTH48
> 

> originally, or than a period.

So how about:

Such an implementation may require an additional transient state in the connection latch state machine: a "LARVAL" state, so to speak, to which the connection is latched pending
establishment of the SA. Such a "LARVAL" state is not described further herein.

--julien

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Oct 2009 13:07:23 -0500

On Tue, Oct 20, 2009 at 09:30:08AM -0700, Laganier, Julien wrote:
> So how about:
> 
> Such an implementation may require an additional transient state in
> the connection latch state machine: a "LARVAL" state, so to speak, to
> which the connection is latched pending establishment of the SA. Such
> a "LARVAL" state is not described further herein.

"transient" seems confusable/redundant to me: all these states are
transient, in a way, since a latch is never permanently in one state.

In the case of the CLOSED state I used the word "fleeting"; "ephemeral"
would work just as well.  I will use the word "fleeting", since I've
already used it to the same effect.  I'll send an updated .xml file to
the RFC-Editor later today.

Thanks!

Nico
--

---

From: "DB" <[email-masked]>
Date: Thu, 22 Oct 2009 07:51:33 +1100

I dont know how this WG works, but could this be included in your next 
agenda?
I need your inputs and comments,

http://tools.ietf.org/html/draft-d-sec-udt-00

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Oct 2009 17:29:21 -0400

Seems out of scope for BTNS. See our charter. You might try SAAG.

Joe

On Oct 21, 2009, at 4:51 PM, "DB" <[email-masked]> wrote:

> I dont know how this WG works, but could this be included in your  
> next agenda?