Re: [Hipsec] a state machine proposal for mm-03

[Miika Komu <[e-mail]>]

> I have a feeling that you are imposing the complexity on the design
> yourself.  You seem to be making assumptions that seem unnecessary and
> complicating to me.  For example, why do you attempt to have some kind
> of mirrored and identical state machines at both ends?  I see no need
> for that.  You also seem to try too hard or achieve a too strong
> consistency between the hosts.  Try to think simple, and have address-
> based rather than host-based state machines.

Maybe the state machines are now perhaps separated now better. I revised
it based your nits online and also Tobias Heer gave some offline comments.
They could be used even as simplified, example models instead of forcing
them to be mandatory if the flebility/parallelity is the issue. For
example, the processing rules of section 5 could be illustrated and
summarized in section 5.7 with the simplified state machine.

Pekka, thanks for references. I have some background reading to do. Please
decide as you think is best for the draft. Other tasks await me already.

== Common state machine ==

Receive HIP UPDATE in ESTABLISHED:
- Verify the HIP packet: HMAC, SIG, the presence, dependencies and
  validity of the parameters.
  - If the result is failure, goto DROP.
  - If success, proceed based on presence of LOCATOR, ECHO_REQUEST or
    ECHO_RESPONSE (only one of them can be contained in the packet)

== MN example state machine ==

Send UPDATE with LOCATOR:
  - Triggered at the MN depending on changes in network attachments
    and according to local policies
  - Removed addresses are DEPRECATED (and not included in the
    LOCATOR)
  - All other addresses are ACTIVE
  - Set preferred LOCATOR depending on local policies
  - Send UPDATE with LOCATOR for the CN

Received ECHO REQUEST:
    - Send ECHO_RESPONSE

UPDATE retransmission timeout for LOCATOR:
  - State is UNVERIFIED
    - Resend and decrease retransmission counter
  - Any other state
    - DROP and zero retransmission counter

== CN example mobility state machine ===

Received LOCATOR:
- For each MN address not present anymore in the locator
  - Goto DEPRECATED
- For each old MN address (already known) in the received LOCATOR
  - State is DEPRECATED
    - Goto UNVERIFIED and send ECHO_REQUEST
  - State is ACTIVE
    - Stay in ACTIVE
- For each new MN address in the received LOCATOR
  - State is UNVERIFIED
    - Send ECHO_REQUEST

Received ECHO_RESPONSE:
- For each MN address in the corresponding LOCATOR
  - State is UNVERIFIED or ACTIVE
    - Goto ACTIVE
    - Change preferred LOCATOR when necessary
  - Any other state, DROP

Receive ESP:
- For the ESP address
  - State is UNVERIFIED
    - Verify ESP validity. Goto DROP if failed
    - Process ESP if there are credits left, and decrease credits.
    - Otherwise DROP
  - State is ACTIVE
    - Process ESP
  - Any other state, DROP

Send ESP:
  - Increase credits

UPDATE retransmission timeout for ECHO_REQUEST (at CN):
  - State is UNVERIFIED
    - If retransmission counter is zero, goto DEPRECATED
    - Otherwise, resend and decrease retransmission counter
  - Any other state
    - DROP and zero retransmission counter

====

-- 
Miika Komu              [e-mail]          http://www.iki.fi/miika/

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec