Subject: [Hipsec] registration protocol - reg_failed parameter and update

From: [email-masked]
Date: Wed, 27 Jul 2005 18:30:23 +0200

Dear all,

while implementing the registration protocol, I have found some problems which 
I would like to report.

DESCRIPTION:
Once the RVS sends the R2 packet with the REG_FAILED parameter, the RVS hip 
machine remains in R2-SENT state until:
- Some data is sent from the initiator. 
- Certain r2_sent_timeout has passed.
The INITIATOR tries to re-register after the REG_FAILED, sending an update 
packet with a REG_REQUEST parameter.

PROBLEM:
RVS doesn't accept any update packets during the R2_SENT state (only in 
ESTABLISHED state). Impossible finishing the registration properly.

SUGGESTION:
a) Create a new transition between the R2-SENT state and ESTABLISHED
state, when RVS receives an update packet.
It could be implemented that only a HIP node acting as a RVS could accept this 
update packet in a R2-SENT state (or being more precise, only update packet 
including a REG_REQUEST parameter). If not, being more general (an easier to 
implement), any node could have this new transition. Do you see any 
downside for the normal base exchange with this addition?
b) Forced the Initator to send some data so then RVS will move from R2-SENT to 
ESTABLISHED state. In this case, I don't see any downside will happen in the 
regular base exchange.

Any comments?

Thanks

Miriam

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

---

From: Julien Laganier <[email-masked]>
Date: Thu, 28 Jul 2005 09:15:27 +0200

Folks,

[Thanks Miriam for bringing this issue to the list!]

More below:

On Wednesday 27 July 2005 18:30, [email-masked] wrote:
>
> DESCRIPTION:
> Once the RVS sends the R2 packet with the REG_FAILED parameter, the
> RVS hip machine remains in R2-SENT state until:
> The INITIATOR tries to re-register after the REG_FAILED, sending an
> update packet with a REG_REQUEST parameter.
>
> PROBLEM:
> RVS doesn't accept any update packets during the R2_SENT state
> (only in ESTABLISHED state). Impossible finishing the registration
> properly.

After reading more [I-D.ietf-base], I'd suggest the WG to change, in 
the R2-SENT description, the sentence "Receive data, move to 
ESTABLISHED" into "Receive data or UPDATE, move to ESTABLISHED".

It doesn't seems no negatively impact the base exchange (R2_SENT was 
created to allow to retransmit R2 without dropping the current 
assoication, which is still possible with this addition) and allows 
to solve the issue Miriam found with the registration protocol (no 
user data is sent so the RVS is stuck in R2-SENT until timeout). 

Here is the modified text (along with the removal of UAL text in 
R2-SENT I proposed earlier in 
<http://www1.ietf.org/mail-archive/web/hipsec/current/msg01462.html> ):

-------------------------------------------------------------
   +---------+
   | R2-SENT | Waiting to finish HIP
   +---------+

   Receive I1, send R1 and stay at R2-SENT
   Receive I2, process,
      if successful, send R2, and cycle at R2-SENT
      if failed, stay at R2-SENT
   Receive R1, drop and stay at R2-SENT
   Receive R2, drop and stay at R2-SENT

   Receive data or UPDATE, move to ESTABLISHED
   Exchange Complete Timeout, transition to ESTABLISHED.
-------------------------------------------------------------

Opinions welcomed.

Thanks.

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Jul 2005 11:56:34 +0200

> ESTABLISHED" into "Receive data or UPDATE, move to ESTABLISHED".

Sounds fine to me.

--Pekka