Subject: [Hipsec] Improving the resiliency of HIP against packet loss

From: Robert Moskowitz <[email-masked]>
Date: Fri, 21 May 2010 01:00:57 -0400

Tobias pointed out to me that currently HIP "is rather slow in cases of 
packet loss".

What might we change to address this?

Consider standard Internet packet lose and separately high packet lose 
over lousy (eg 802.15.4) networks.

I should point out that the design for IEEE 11073 is that it will take a 
number of tries to get the data from a sensor to a controller.  This 
protocol just keeps on polling until it gets a response.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 21 May 2010 10:19:52 -0400

On 05/21/2010 01:00 AM, Robert Moskowitz wrote:
> Tobias pointed out to me that currently HIP "is rather slow in cases 
> of packet loss".
>

I think I have worked out a proposal. I will include it in DEX, but only 
BEX if there is a humm for it. See below.

> I should point out that the design for IEEE 11073 is that it will take 
> a number of tries to get the data from a sensor to a controller. This 

I sends I1 every n msec until it gets an R1 or ICMP error or some sec 
incase it is sending out to nothing.
R sends R1 every n msec until it gets an I2 or ICMP error or some sec 
incase it is sending out to nothing.
I sends I2 every n msec until it gets an R2 or some sec incase R 
disappeared.
R sends R2 every n msec until it gets an ESP payload using the SA or 
some sec incase I disappeared..

A very simple send/send/send, oh, ACK received.

Now there is an attack here. Malice can send an I1 to R with Q's HIT and 
IP addr. This then becomes a potential attack on Q's battery. But it is 
one of a lot of attacks where device M sends packets to sensor Q to wake 
it up and use up its battery.

If M sends an I1 to R with Q's HIT&IP, R will start sending R1's until 
either Q replies or R times out. Q can reply with an ICMP error (hey, I 
don't do HIP) or something else. Since Q never sent an I1, what is the 
state machine at? Does Q already have an SA with R and what does 
receiving an R1 without ever sending an I1? I think the R1 is ignored in 
all cases. Eventually R times out and stops sending R1s. Just one more 
battery draining attack.