Re: [Hipsec] Completing 5201 state machine

[Miika Komu <[e-mail]>]

Hi,

On 19/10/10 02:41, Henderson, Thomas R wrote:
> 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.

HIPL also ignores this, i.e., drops the CLOSE packet.

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

HIPL currently ignores this, but I think it might be a good idea to 
process this.

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

Agred. Dropped by HIPL too.

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

Agree (processed and logged by HIPL).

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

Agree (dropped by HIPL).

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

Agree (processed and logged by HIPL).