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

["Laganier, Julien" <[e-mail]>]

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:
> 
> 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
> --
> _______________________________________________
> btns mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/btns