[Hipsec] Completing 5201 state machine

[Tobias Heer <[e-mail]>]

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