Re: [Hipsec] Completing 5201 state machine

Hi Julien, 

Am 20.10.2010 um 19:04 schrieb Laganier, Julien:

> Hello Tobias,
> 
> I have no time to look into the details so I'm just asking here - sorry about that: 
> 
> While we're at moving HIP forward to standard track we're going to make a certain number of changes. Since experimental HIP already has a little brother that made it to Proposed Standard (SHIM6 in RFC 5533), could we simply replicate that state machine into our standard track HIP (v2)?

I'll investigate this. Maybe we can borrow this and that. However, the state machine is not wrong or shaky but merely did not mention a few corner cases which should be handled for completeness.
I assume that most implementation implement the suggested "new" behavior already.

However, thanks for the good suggestion!

Tobias

> 
> --julien
> 
> Tobias Heer wrote:
>> 
>> 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
>> 
>> 
>> 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
>> 
>> 
>> 3.) Receive CLOSE_ACK in state R2-sent
>> ------------------------------
>> Why can this happen?
>> - It shouldn't but there is nothing specified.
>> 
>> Proposed action: drop
>> 
>> 
>> 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
>> 
>> 
>> 5.) Receive CLOSE_ACK in state ESTABLISHED
>> ------------------------------
>> Why can this happen?
>> - It shouldn't but there is nothing specified.
>> 
>> Proposed action: drop
>> 
>> 
>> 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
>> 
>> 
>> I would appreciate if you could have a look at the proposed changes and
>> give feedback. None of the changes has dramatic effects on existing
>> implementations of HIPv1 but 1) and 2) might require some minor change
>> of code if the implementations don't handle (or handle differently) the
>> CLOSE messages in these states.
>> 
>> BR,
>> 
>> Tobias
>> 
>> --
>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>> Chair of Communication and Distributed Systems - comsys
>> RWTH Aachen University, Germany
>> tel: +49 241 80 207 76
>> web: http://ds.cs.rwth-aachen.de/members/heer
>> blog: http://dtobi.wordpress.com/
>> card: http://card.ly/dtobi
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi