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

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 20 Jul 2005 17:37:14 -0700

All,
I have been looking at the base-03 (and esp-00, mm-02) draft more
carefully while upgrading our HIP implementation, and have some
comments. I have attempted to organize these few comments with numbers
and by category...

--- state machine ---
(1) What happened to the REKEYING state? It is mentioned once in base-03
and twice in mm-02. It seems that REKEYING was (mostly) stripped out
along with the ESP stuff starting with base-02, but never made a
reappearance into esp-00.

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

--- NOTIFY packets ---
(3) In 6.14, Processing CLOSE_ACK packets:
"...the state changes to UNASSOCIATED and, after that, NOTIFY is sent as
a response to a CLOSE message."
Do we really want to send NOTIFY here? Doesn't UNASSOCIATED mean that we
no longer really have any state with the peer? The draft (sect. 4.3)
mentions that NOTIFY should generally be used if there is an existing
HIP association. Maybe ICMP is more appropriate, or further CLOSE_ACKs
are simply dropped.

(4) Under the NOTIFY parameter with INVALID_SYNTAX 7, the draft says
"this status may only be returned for and in an encrypted packet if the
message ID and cryptographic checksum were valid". What is meant by
"message ID"? What about the "cryptographic checksum", is that the HIP
checksum? (nowhere is this referred to as a "cryptographic checksum")
Does this mean we need an ENCRYPTED TLV in the NOTIFY?

(5) It probably should be noted that the NOTIFY code
AUTHENTICATION_FAILED should not be sent in response to a failed
signature in another NOTIFY. This may be common sense. Imagine two
implementations and one has a bug in the RSA signing/verification that
crops up after the SA is established; the buggy host later sends an
UPDATE, the verify fails causing a NOTIFY to be sent, and a NOTIFY is
sent in response to that NOTIFY, etc., the two might potentially go back
and forth.

-Jeff

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

---

From: Miika Komu <[email-masked]>
Date: Thu, 21 Jul 2005 10:57:58 +0300 (EEST)

> 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

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Jul 2005 14:51:02 +0200

On Thursday 21 July 2005 09:57, Miika Komu 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:
>

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?

--julien

---

From: Kristian Slavov <[email-masked]>
Date: Thu, 21 Jul 2005 16:22:57 +0300

>>   User data to send, move to ESTABLISHED

[snip]

> That way the responder would not be stuck in R2_SENT. What does the WG 

Depending on the semantics of the HIP association, Miika's suggestion is 
valid too. I.e. if it is ok to just create a HIP association without 
actually transferring anything over the tunnel. In that case the responder 
might very well be the one who actually sends first data.
On the otherhand, if the initiator of the HIP association is always 
assumed to actually send some transport data, then Miika's suggestion is 
invalid.
So how about?

   If no packet is received nor sent in UAL minutes, send CLOSE and go to 
CLOSING, otherwise go to ESTABLISHED.

-- 
Kristian Slavov

---

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

On Thursday 21 July 2005 15:22, Kristian Slavov wrote:
> > After reading more carefully the HIP base specification and the
> > thread on "Recovery from state loss", I think it should be:
> >

(...)

> Depending on the semantics of the HIP association, Miika's
> suggestion is valid too. I.e. if it is ok to just create a HIP
> association without actually transferring anything over the tunnel.

This situation is possible with my proposal too, it is just that the 
initiator needs to send something before the association timeout. If 
it really want the association to stay without sending user data, it 
can sends "keepalive" HIP packets, for example empty UPDATEs.

> assumed to actually send some transport data, then Miika's
> suggestion is invalid.
> So how about?
>
>    If no packet is received nor sent in UAL minutes, send CLOSE and
> go to CLOSING, otherwise go to ESTABLISHED.

Actually what I was proposing was to remove the word "sent" from both 
R2_SENT _and_ ESTABLISHED descriptions. This is to avoid sending 
user-data in the void (e.g. other peer is dead).

--julien

---

From: Petri Jokela <[email-masked]>
Date: Fri, 29 Jul 2005 15:25:36 +0300

> reappearance into esp-00.

I'll remove the REKEYING-word from the base specification. In the ESP
draft, there is no state machine described, and it doesn't define a new
state related to rekeying. I think that it doesn't need that, but what
do others think?

> HIP association. Maybe ICMP is more appropriate, or further CLOSE_ACKs

NOTIFY seems to be unnecessary here. ICMP would (maybe) shorten the time
that the peer host stays at CLOSED state. Without any response to the
CLOSE_ACK, the host waits until timeout and moves to UNASSOCIATED.

I think that we should not send anything. Sending something would be
directly acking ot the ack (which could be defined as a new HIP message :-)

> sent in response to that NOTIFY, etc., the two might potentially go back

I'll change the text.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]