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

[Pekka Nikander <[e-mail]>]

Miika,

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.

For example, a minimal implementation might do as follows:

- When a host gets a new local address or deprecates an old one, it  
simply sends an update to its active peers (if it can) and lets the  
UPDATE layer to take care of ACKs and retransmission.  If one peer  
does not get the info, let it be in that way, do not try any harder.   
If there is active communication with the peer, it will get the new  
address later on, or resort to using RVS.

- When a host receives a new peer address, it simply enters it into  
its local database.  Only if it needs to use it, e.g. due to that new  
address being the new preferred one or the old preferred one failing,  
initiate reachability check (with CBA).

I'd rather keep those two "state machines" completely separate.

It is a well known fact that when you combine multiple simple  
parallel state machines into a single one you get a complicated one;  
google e.g. for "state space explosion".  Hence, in implementation  
terms, it is much better to implement several parallel state machines  
than a single big one.

> "Note3: reusing the same state variables on both hosts. At the mobile
> host (the sender of LOCATOR) it is related to the data structures of
> the source IP. On the corresponding node (receiver of LOCATOR), it is
> related to the destination IP."

See above.  That assumption is unnecessary and likely to complicate  
your design.

> See my comment in the other email:
>
> * Mainly, no new features. In fact, I suggest removing one feature /
>   use-case (readdress with peer-initiated rekey) in favour of
>   simplifying state machine, interaction with middle-boxes and
>   interoperable implementations. Suggest removal of it from this  
> draft and
>   adding to a follow-up draft.

See above.  Decomposing your big state machine into several parallel  
ones is likely to simplify your design more than sufficiently.

> I am proposing the "artificial" restrictions on the draft to make  
> it more
> concrete and to support interoperable implementations in the very near
> future. I think it is just too modular as it is now :)

I think the reverse.  In this case I think complete state-machine  
modularity is good; see the argumentation above.

> In addition, I
> think the explicit state machine for m&m could make a security  
> analysis of
> the UPDATE easier in the future.

I agree, but OTOH such a explicit complete state machine should be  
composed by an analysis tool that is able to automatically generate  
the compound state machine from the multiple parallel ones.

> Received ECHO REQUEST:
>   - Goto ACTIVE and send echo response

See above.  There is no need to keep track what the other end thinks  
about the state of your addresses.  That only complicates things.   
Furthermore, there is a strong theoretical result that says that it  
is _impossible_ to have complete synchrony between states in an  
asynchronous system.  Google e.g. for "common knowledge" and "modal  
logic".

>
>>> Receive ESP:
>>> - For the ESP address
>>>   - State is UNVERIFIED
>>>     - Verify ESP validity. Goto DROP if failed
>>>     - Change preferred LOCATOR when necessary
>>
>> Did we specify this?  May make sense sometimes, but again,
>> beware....  ESP doesn't protect IP source...
>
> This was the CBA optimization. Maybe it should be mentioned  
> explicitly.

OK; I haven't been following the details of CBA.  I thought it was  
being applied only for new preferred address candidates as  
_indicated_ by the peer (or necessitated by the previous peer  
address'es failure.)

--Pekka


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