Subject: [Hipsec] miscellaneous comments on the drafts

From: [email-masked] (Miika Komu)
Date: Mon Oct 20 04:27:01 2003

Here are some miscellaneous comments on the drafts. They popped out
mostly when we begun to update our implementation to be in
sync with draft-08-pre.

The value of SPI_LSI type is zero in draft-08-pre. I'd recommend to change
this value non-zero, as zero is interpreted usually as "initialized but
not used yet" in data structures in C-language. This was the most
difficult type value to change in our implementation.

Critical flag in section is specified as "Zero if this parameter is
critical" in section 6.2.1 in 08-pre-Oct01. The natural way of generally
using flags is "one if the parameter is foobar".

There is a conflict in draft-08-pre and hip-mm-00. The type value for the
HMAC parameter is different. I guess draft-08-pre contains the up-to-date
value?

draft-08-pre describes the maximum value for a HIP parameter length in
section 6.1. Should the minimum value (zero?) specified also as a hint for
the developers to avoid buffer overflow issues in their implementation ?)

draft-08-pre state machine in section 5.4.2 specifies state transitions in
the order "first send packet x and then change state". We had to do that
in reverse order in our implementation in the case of E2 (Waiting to
finish HIP) because the response packet was received before the state was
changed! If we had followed the order of the draft, we would have had to
wait for the timeout and retransmission of packets. Should the ordering be
changed or are we doing something wrong (or too fast ;)?

The drafts do not make a specific statement about loop back support of
HIP. I mean about sending a packet from HIT1 to HIT2 where the HIT1 and
HIT2 are the same. The loop back support may sound silly but TCP/IP
supports it, so why shouldn't HIP? It is very useful for testing with a
single host.

However, the loopback HIP is a bit hard to implement, at least in our
implementation. We are currently using the destination HIT as the key to
the HIP database and obviously using the same HITs as source and
destination addresses won't just work. As I recall, none of the other
implementations does not support loopback HIP either?

What about the integration with the rest of the TCP/IP stack? Should there
be a explicit statement about this in arch-05-pre-Oct20? Here is a couple
of things that popped up in our (kernel module) implementation:

- Should TCP (or other transport layer) retransmissions be dropped by the
  implementation? HIP layer has seems to have its own timeouts.
- May the implementation cache packets (e.g. SYNs) during the base
  exchange or other HIP packet exchange? If the implementation just drops
  the packets during base exchange, it is subject to transport layer
  retransmission timeouts.
- If the implementation caches packets, should it cache them all? If it
  caches only one, should it cache only the first packet or the most
  recently sent?

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

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 04:42:01 2003

> using flags is "one if the parameter is foobar".

I am really open ended with regard to this.  If people feel
that parameter type 0 should be reserved for implementation internal
use, and that we should use odd parameters as critical instead of
odd ones, I can make the changes.

The reason for the current values was to minimize changes,
making my editing easier :-)

Opinions?  If no other opions appear before Thursday,
I guess we will adopt Miika's proposal.

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 04:51:01 2003

> HMAC parameter is different. I guess draft-08-pre contains the up-to-date

Yes.  Additionally, I'm afraid mm-01 will be considerably
different from mm-00, once I get it out.

> changed or are we doing something wrong (or too fast ;)?

The state machine and processing rules are hints for implementors.
I think Section 8 states this explicitly.  I added the following
statement to the beginning of Section 5.

	Implementors must understand that the state machine, as
	described here, is informational.  Specific implementations
	are free to implement the actual functions differently.

Ok?

> supports it, so why shouldn't HIP? It is very useful for testing with a

I think this is an implementation issue, and doesn't need to be
discussed in the draft.

> implementations does not support loopback HIP either?

Ours does, at least sort of, if I remember correctly.  We are using
the HITs as keys to a internal data structure too.  I don't understand
why it is hard to have both the src and dst equal?

>   implementation? HIP layer has seems to have its own timeouts.

Do you mean during the base exchange?  I think that is covered by
Section 8.2 bullet 3, isn't it?

>   the packets during base exchange, it is subject to transport layer

I think that is covered by Section 8.2 bullet 3, too?

>   caches only one, should it cache only the first packet or the most

I think that is covered by Section 8.2 bullet 3.

Basically, all the details are up to the implementation, at least
currently.  And they are definitely not architectural issues, IMHO.

--Pekka Nikander

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 04:54:00 2003

> the developers to avoid buffer overflow issues in their implementation ?)

I don't really understand.  What is the issue?  From my point of
view, it should be obvious (from the definition of I1) that the
minimum length of the HIP Parameters field is zero.

Why, exactly, should it be defined?  What was the difficulty
you encoutered?

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Mon Oct 20 07:03:01 2003

> why it is hard to have both the src and dst equal?

I guess it can be hard if the data structure storing the state associated with 
a given HITs pair doesn't record the {initiator|responder} quality of the 
node. 

If it is the case, while using loopbacks HITs, you end-up having only one 
state storing indeed two different states, one as an initiator and the other 
one as a responder. My implementation was doing this: It transitions to E3 
after having sent R2 (to itself), causing the subsequently received (from 
itself) R2 to be discarded, as per the state machine diagram... So I need to 
put an {Initiator|Responder} flag in the state data structure and use it as a 
part of the key to the HIP database.

Just my understanding...

--julien

---

From: [email-masked] (Miika Komu)
Date: Mon Oct 20 08:17:00 2003

> 	are free to implement the actual functions differently.

Ok.

> Section 8.2 bullet 3, isn't it?

You mean section 8.1. bullet 3?

   3.  If there no active HIP session with the given < source,
       destination > HIT pair, one must be created by running the base
       exchange.  The implementation SHOULD queue at least one packet
       per a HIP session to be formed, and it MAY queue more than one.

> currently.  And they are definitely not architectural issues, IMHO.

Yes, you're correct. I should have RTFM better.

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 10:52:03 2003

>>> However, the loopback HIP is a bit hard to implement...
>> 
>> the HITs as keys to a internal data structure too.  I don't
>> understand why it is hard to have both the src and dst equal?
> 
> I guess it can be hard if the data structure storing the state
> associated with a given HITs pair doesn't record the
> {initiator|responder} quality of the node.

You shouldn't need to do that.

> If it is the case, while using loopbacks HITs, you end-up having only
> one state storing indeed two different states, one as an initiator
> and the other one as a responder. 

Exactly.  That is what you should have, one state.

According to Section 5.4.2, if you receive an I2 in state E2,
you should process it, send an R2 and go to E3.  Then, in E3,
if you receive and R2, you should just drop it and remain in E3.

Hence, no special tricks are needed.  You just must be able to
receive and correctly process an I2 when in state E2.

Section 8.6 bullet 18 also explicitly mentions state E2 as
a possible state for processing an I2.  Section 8.7 is also
very clear.

--Pekka Nikander

---

From: [email-masked] (Miika Komu)
Date: Mon Oct 20 11:13:01 2003

> Why, exactly, should it be defined?  What was the difficulty

Sorry, I was a bit confused. The HIP header length is ok, I meant a
min/max value for any HIP parameter, such as DIFFIE_HELLMAN, CERT, etc.
But that depends on the number of existing parameters in a HIP message, so
I guess that can be left out of the draft. The implementation is
ultimately responsible of checking the validity of the lengths of HIP
parameters in a HIP packet.

(I encountered this issue when I was updating our HIP packet builder
library and I had to verify the minimum and maximum lengths of HIP
parameters in incoming HIP packets)

---

From: [email-masked] (Julien Laganier)
Date: Mon Oct 20 11:24:03 2003

> You shouldn't need to do that.

I agree.

> Exactly.  That is what you should have, one state.

Indeed.

> receive and correctly process an I2 when in state E2.

I concur. But as a possible goal of doing a loopback HIP exchange was to debug 
(It was mine), I wasn't satisfied in having R2 dropped because it doesn't 
allow me to debug the R2 input side ;-)

Thanks,

--julien