[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, Oct 15, 2009 at 08:54:18PM -0400, Michael Richardson wrote:
> 
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> 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.

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

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.