Subject: [Hipsec] Completing 5201 state machine

From: Tobias Heer <[email-masked]>
Date: Wed, 13 Oct 2010 18:12:55 +0200

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 18 Oct 2010 16:41:50 -0700

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] 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.
>
> - 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)
>

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.

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

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

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

> 4.) Receive NOTIFY in state R2-sent

Agree; in OpenHIP, NOTIFY is processed in any state that has a valid association
> 5.) Receive CLOSE_ACK in state ESTABLISHED

Agree; see 3) above.

> 6. Receive NOTIFY in state ESTABLISHED

Agree.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Tue, 19 Oct 2010 12:01:55 +0300

Hi,

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

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

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

Agred. Dropped by HIPL too.

> Agree; in OpenHIP, NOTIFY is processed in any state that has a valid association

Agree (processed and logged by HIPL).

>> - It shouldn't but there is nothing specified.

Agree (dropped by HIPL).

>> Proposed action: process and stay in ESTABLISHED

Agree (processed and logged by HIPL).

---

From: Tobias Heer <[email-masked]>
Date: Tue, 19 Oct 2010 11:45:21 +0200

Hi Tom, 

thanks for your review of this!

>> Subject: [Hipsec] Completing 5201 state machine
[...]
> 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.
Good catch. Indeed I mean CLOSED. The host should send a CLOSE_ACK and transition to CLOSED.

I guess this case will only happen rarely - maybe never for some implementations. 

How do we end up here?

0.) I1, R1
1.) Initiator sends I2. 
2.) Responder sends R2
3.) R2 is lost or delayed
4.) Timeout at Responder fires: Responder transitions to ESTABLISHED
5.) Further I2 messages from Initiator are lost
6.) Responder decides to close the ESTABLISHED connection, sends CLOSE and transitions to CLOSING
7.) Now the Initiator receives the CLOSE message while in state I2-sent

I admit that the case is somewhat constructed but possible nonetheless.

> OpenHIP accepts this packet, sends CLOSE_ACK, and transitions to CLOSED.  As in 1) above, are you suggesting state CLOSING or CLOSED?
Same as 1). Process, if valid: send CLOSE_ACK and transition to CLOSED.

Above you said that OpenHIP wouldn't process CLOSE messages in state R2_SENT. What do you mean by that? Isn't sending a CLOSE_ACK (as you mention for 2.) such processing? Am I confusing something here?

[...]

Tobias

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 19 Oct 2010 07:04:32 -0700

> From: Tobias Heer [mailto:[email-masked]]
> Sent: Tuesday, October 19, 2010 2:45 AM
> To: Henderson, Thomas R
> Cc: HIP WG
> Subject: Re: [Hipsec] Completing 5201 state machine
>
> Hi Tom,
>
<snip>
> >
> > OpenHIP allows CLOSE in states ESTABLISHED, CLOSING,
> CLOSED, and R2_SENT, but does not process it in this state.
> >

<snip>

>
> Above you said that OpenHIP wouldn't process CLOSE messages
> in state R2_SENT. What do you mean by that? Isn't sending a
> CLOSE_ACK (as you mention for 2.) such processing? Am I
> confusing something here?
>

Sorry for not being clear; the "this state" in the above explanation refers to state I2-sent, not R2-sent.

- Tom

---

From: Tobias Heer <[email-masked]>
Date: Tue, 19 Oct 2010 16:25:18 +0200

Hi Tom,

thanks for the clarification.

Am 19.10.2010 um 16:04 schrieb Henderson, Thomas R:

[...]
> Sorry for not being clear; the "this state" in the above explanation refers to state I2-sent, not R2-sent.
What is your opinion on processing CLOSE messages in state I2-sent? Do you have reasons why you don't process it in that state?

Tobias

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 20 Oct 2010 10:04:09 -0700

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.
> 
> - 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)
> 
> - 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)
> 
> 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
> 
> --
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: Tobias Heer <[email-masked]>
Date: Thu, 21 Oct 2010 14:41:25 +0200

Hi Julien, 

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

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

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 21 Oct 2010 09:16:35 -0700

Tobias Heer wrote:
> > 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.

No need to investigate, I checked RFC 5533 and it doesn't have the CLOSE / CLOSE ACK handshake that Erik originally proposed for HIP. For those interested, more details here:

<http://tools.ietf.org/html/rfc5533#appendix-D.7>

--julien