Re: [Hipsec] Completing 5201 state machine

["Laganier, Julien" <[e-mail]>]

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

--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: [phone]
> web: http://ds.cs.rwth-aachen.de/members/heer
> blog: http://dtobi.wordpress.com/
> card: http://card.ly/dtobi
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec