Re: [Hipsec] Completing 5201 state machine

["Henderson, Thomas R" <[e-mail]>]

Tobias, I reviewed the OpenHIP behavior to these white spots, below:

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Tobias Heer
> Sent: Wednesday, October 13, 2010 9:13 AM
> To: HIP WG
> Subject: [Hipsec] Completing 5201 state machine
>
> Hello,
>
> the state machine of RFC5201 (not -bis) has some white spots
> which I try to cover now. Nothing essential is missing but it
> seems slightly underspecified the way it is now.
> Handling of the following packets is missing in some states:
> CLOSE, CLOSE_ACK, and NOTIFY. And it is not caught by the
> "handle ANYOTHER" rules that serve as catch-all.
>
> I'll list the changes that I'll make here and ask for
> feedback from the group and especially implementors.
>
> 1.) Receive CLOSE in state I2-sent:
> ------------------------------
> Why can this happen?
> - R2 is lost (maybe repeatedly), Responder transitions to
> from R2-SENT to ESTABLISHED because of timeout, Responder
> decides to close association (because of some reason)
>
> Proposed action: process packet
> - successful: transition to CLOSING
> - fail: drop and stay at I2-sent

OpenHIP allows CLOSE in states ESTABLISHED, CLOSING, CLOSED, and R2_SENT, but does not process it in this state.

Can you clarify what you want to happen here?  Usually, if peer sends a CLOSE, you send CLOSE_ACK and transition to CLOSED, not to CLOSING.

>
>
> 2.) Receive CLOSE in state R2-sent
> ------------------------------
> Why can this happen?
> - Responder cannot observe data packet flow (this is the case
> for some implementations), Responder timeout for transition
> from R2-SENT to ESTABLISHED has not fired yet, Initiator
> decides to close association (because of some reason)
>
> Proposed action: process packet
> - successful: transition to CLOSING
> - fail: drop and stay at R2-sent

OpenHIP accepts this packet, sends CLOSE_ACK, and transitions to CLOSED.  As in 1) above, are you suggesting state CLOSING or CLOSED?

>
>
> 3.) Receive CLOSE_ACK in state R2-sent
> ------------------------------
> Why can this happen?
> - It shouldn't but there is nothing specified.
>
> Proposed action: drop

Agree; in OpenHIP, CLOSE_ACK is only processed in state CLOSING or CLOSED.

>
>
> 4.) Receive NOTIFY in state R2-sent
> ------------------------------
> Why can this happen?
> - Responder cannot observe the data channel and timeout has
> not fired yet.
>
> Proposed action: process and stay in R2 sent

Agree; in OpenHIP, NOTIFY is processed in any state that has a valid association
>
>
> 5.) Receive CLOSE_ACK in state ESTABLISHED
> ------------------------------
> Why can this happen?
> - It shouldn't but there is nothing specified.
>
> Proposed action: drop

Agree; see 3) above.

>
>
> 6. Receive NOTIFY in state ESTABLISHED
> ------------------------------
> Why can this happen?
> - Well, there are many reasons for this. This is normal behavior.
>
> Proposed action: process and stay in ESTABLISHED

Agree.

- Tom