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

[Pekka Nikander <[e-mail]>]

> Note2: the state machine is simpler to design if we leave out the  
> peer initiated rekeying (section 3.2.1.2 in the draft). This way,  
> we can assume that the UPDATE exchange consists of three packets  
> and that each packet can be distinguished from each other by the  
> precence of LOCATOR, ECHO_REQUEST or ECHO_RESPONSE.

Unfortunately I don't have time to really consider this in detail,  
but my earlier understanding was that, at least in principle, you  
could make the mobility and re-keying state machines completely  
separate.

Anyway, from the overall architectural design point of view the idea  
was to use UPDATEs as a semi-reliable retransmission and  
acknowledgement sub-layer, on the top of which you can implement any  
state machine.  The UPDATE-layer would signal the state machine above  
about any eventual events where packets don't get acknowledged even  
after multiple retries.  Furthermore, the idea was that you could  
have multiple parallel state machines running at the same time.   
Their messages (payloads) would just be transmitted and acknowledged  
at once at the UPDATE layer, without needing any co-ordination  
between the above state machines.

Now, I agree that there might be problems if you want to synchronise  
these state machines, e.g., for privacy reasons.  However,  
fortunately or not, in the particular case of privacy you need to do  
also other tricks (such as having a changing HIT-blinding algorithm)  
that basically make the whole update mechanism half-unnecessary for  
the strong privacy case.

Some minor comments below, made without _proper_ understanding of the  
whole picture:

> Send UPDATE with LOCATOR:
>   - Triggered at the MN depending on changes in network attachments
>     and according to local policies
>   - Removed addresses are DEPRACATED (and not included in the
>     LOCATOR)
>   - All other addresses are UNVERIFIED (and included in the LOCATOR)

Why these need to be UNVERIFIED.  Maybe some of those have been  
verified earlier?

>   - Set preferred LOCATOR depending on local policies
>   - Send UPDATE with LOCATOR for the CN
>
> Receive HIP UPDATE:
> - 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)

I don't agree that only one of them can be included; see above.  You  
seem to be making unnecessary limitations.

> Received LOCATOR:
> - For each MN address in the received LOCATOR
>   - State is DEPRACATED or UNKNOWN

Why?  See above.

>     - Goto UNVERIFIED and send ECHO_REQUEST
>   - State is UNVERIFIED
>     - Resend ECHO_REQUEST and decrease retransmission timeout
>   - Any other state, DROP
>
> Received ECHO REQUEST:
> - For each MN address in the corresponding LOCATOR
>   - State is UNVERIFIED
>     - Goto ACTIVE and send ECHO_RESPONSE
>   - Any other state, DROP

I don't understand the logic here.  IMHO you should always answer  
with ECHO_RESPONSE when you get an ECHO_REQUEST on any of your  
addresses, independent of what you are doing with your peer's address  
verification.  Completely separate this out.

> Received ECHO_RESPONSE:
> - Goto DEPRACATED for all old addresses not present in LOCATOR

Hmm.  Sounds like a sensible place of doing that.  But there may be  
dragons around, beware.

> - For each MN address in the corresponding LOCATOR
>   - State is UNVERIFIED
>     - Otherwise goto ACTIVE

But you can't do that for other than the address that you just  
verified?  Are you saying that one ECHO pair is enough to make all  
addresses verified?  Definitely NOT!

>     - 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
>     - Change preferred LOCATOR when necessary

Did we specify this?  May make sense sometimes, but again,  
beware....  ESP doesn't protect IP source...

>     - Process ESP if there are credits left, and decrease credits.
>     - Otherwise DROP
>   - State is ACTIVE
>     - Process ESP
>   - Any other state, DROP
>
<no other comments, must run>

--Pekka


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