Subject: RE: [Hipsec] base-03 state machine, notify

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 21 Jul 2005 07:39:27 -0700

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]
> Sent: Thursday, July 21, 2005 5:51 AM
> To: [email-masked]; Miika Komu; Ahrenholz, Jeffrey M
> Subject: Re: [Hipsec] base-03 state machine, notify
> 
> 
> On Thursday 21 July 2005 09:57, Miika Komu wrote:
> > On Wed, 20 Jul 2005, Ahrenholz, Jeffrey M wrote:
> > > (2) To transition out of the state R2-SENT you need to receive
> > > incoming data or timeout. In the conceptual state machine, it
> > > mentions that after "no packet sent/received during UAL minutes"
> > > (sect. 4.4.2) we transition to CLOSE. What about the case where
> > > we are sending data to the peer but receiving nothing? (Note that
> > > this is unlikely, since the Initiator usually sends something to
> > > trigger; but I do not think this is a requirement for the
> > > Initiator to have to send data.) If we are a Responder that is
> > > sending but not receiving, we will not time out of state R2-SENT
> > > (since packets are being sent) but we also will not transition
> > > out of R2-SENT (since no packets are received) and are stuck
> > > there. Maybe I'm misreading this, and "packet sent/received"
> > > doesn't refer to the user data packets.
> >
> > I found this out too when implementing and playing with CLOSE.
> > There are some use cases where the responder can be stuck to
> > R2-SENT, so there should be some text in R2-SENT:
> >
> >    User data to send, move to ESTABLISHED
> 
> Actually I think I made a mistake when I adapted the original 
> CLOSE/CLOSE-ACK handshake proposal from Erik; I managed somehow to 
> change Erik's sentence:
> 
>    When no packet has been received on the association for X minutes
>    the association transitions to "closing" state. A "close" message
>    is transmitted to the peer.
> 
> Into the sentence below, present in both R2_SENT and 
> ESTABLISHED state 
> desription:
> 
>    No packet sent/received during UAL minutes, send CLOSE and go to 
>    CLOSING
> 
> After reading more carefully the HIP base specification and 
> the thread 
> on "Recovery from state loss", I think it should be:
> 
>    No packet received during UAL minutes, send CLOSE and go 
> to CLOSING 
> 
> That way the responder would not be stuck in R2_SENT. What 
> does the WG 
> think?
> 

If you make that change, change also the definition of UAL in section 2.

I generally support your recommendation (of eliminating "send" from the criteria), but I think that transition out of R2_SENT to ESTABLISHED is a bit different case than transition out of ESTABLISHED to CLOSING.  
- in R2_SENT case, this is just a small substate for a short period of time (e.g., some multiple of (a conservative assumption of) the peer's retransmit timeout for I2) for which we will handle an I2 as a retransmission attempt and not as a new I2.  I don't think it has to be tied to UAL.  Instead, I would think that a conceptual "EXCHANGE_COMPLETE" timer could be implemented, and that transition from R2_SENT to ESTABLISHED happens when either this timer expires or some packet is received that implies that the peer got the R2.
- UAL timescale should be much larger than this

so maybe the above UAL sentence does not need to go in the state machine description of R2_SENT.

Tom    

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Jul 2005 17:17:35 +0200

On Thursday 21 July 2005 16:39, Henderson, Thomas R wrote:
> > > > (2) To transition out of the state R2-SENT you need to
> > > > receive incoming data or timeout. In the conceptual state
> > > > machine, it mentions that after "no packet sent/received
> > > > during UAL minutes" (sect. 4.4.2) we transition to CLOSE.
> > > > What about the case where we are sending data to the peer but
> > > > receiving nothing? (Note that this is unlikely, since the
> > > > Initiator usually sends something to trigger; but I do not
> > > > think this is a requirement for the Initiator to have to send
> > > > data.) If we are a Responder that is sending but not
> > > > receiving, we will not time out of state R2-SENT (since
> > > > packets are being sent) but we also will not transition out
> > > > of R2-SENT (since no packets are received) and are stuck
> > CLOSE/CLOSE-ACK handshake proposal from Erik; I managed somehow
> > to change Erik's sentence:
> >
> >    When no packet has been received on the association for X
> > minutes the association transitions to "closing" state. A "close"
> > message is transmitted to the peer.
> >
> >    No packet sent/received during UAL minutes, send CLOSE and go
> > to CLOSING
> >
> I generally support your recommendation (of eliminating "send" from
> the criteria), but I think that transition out of R2_SENT to
> ESTABLISHED is a bit different case than transition out of
> ESTABLISHED to CLOSING. - in R2_SENT case, this is just a small 
> substate for a short period of time (e.g., some multiple of (a
> conservative assumption of) the peer's retransmit timeout for I2)
> for which we will handle an I2 as a retransmission attempt and not
> as a new I2.  I don't think it has to be tied to UAL.  Instead, I
> would think that a conceptual "EXCHANGE_COMPLETE" timer could be
> implemented, and that transition from R2_SENT to ESTABLISHED
> happens when either this timer expires or some packet is received
> that implies that the peer got the R2. - UAL timescale should be
> much larger than this
>

I think you are right. The UAL sentence should be present only in 
ESTABLISHED. In R2_SENT we should have something along: 

    Exchange Complete Timeout, transition to ESTABLISHED.

And perhaps specifies that Exchange Complete Timeout = n * 
Retransmission Timeout, with n ~ I2_RETRIES_MAX ?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Jul 2005 17:17:35 +0200

--julien