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

[Robert Moskowitz <[e-mail]>]

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".
>
> What might we change to address this?

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.

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

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.