Re: [Hipsec] Comments on hiccups draft

[Jan Melen <[e-mail]>]

Hi,

Tobias Heer wrote:
> Some comments on the hiccups draft. In general I find the approach 
> interesting and worth pursuing. Below are some questions that mostly 
> focus on security:
>
> Conceptual comments and questions:
> ----------------------------------
>
> Section 3: Existence of the HMAC in the packet:
> The hiccups draft states that "[the payload is] protected by a 
> PAYLOAD_HMAC parameter". To me it is unclear how such protection can 
> possibly work. Since there is no previous handshake there are no keys 
> for use in the HMAC. Jan explained that the HMAC is merely used as a 
> way to create a digest over the packet for making the signature more 
> efficient. However, if it is only used for creating the digest, I 
> wonder why it is actually transmitted in the packet because without a 
> secret included in the packet, the digest can easily be calculated and 
> transmitting the digest in a packet seems to be a unnecessary waste of 
> space. Am I missing something here? It would be nice if the draft was 
> more precise about the nature and the use of the HMAC.
>

Yes, it is only a message authentication code of the packet and I know 
that you don't have to send it but it is less prone to errors if you do 
send it as the receiving end doesn't have to generate the actual 
parameter that was used to create MAC code in order to verify the signature.

> Section 4.3: Sending R1 if receiver suspects an attack:
> I guess that in this case, the receiver drops the data packet and its 
> content should be retransmitted (by a higher-layer mechanism?)? If 
> yes, this could be mentioned somewhere.

Yes, I will add that to the draft.

>
> Replay protection:
> The draft talks about a immediate replays of DATA packets in the 
> context of DoS attacks targeted at ACK signature generation. However, 
> it does not talk about replays after a longer time (e.g. to mess with 
> upper-layer state machines).
> How can hosts shelter against replays of valid but old hiccups 
> packets? The sequence number only works from the second packet on and 
> still complete sequences of HIP DATA packets can be replayed. Caching 
> packets or keeping state for every ever-received packet is probably 
> not feasible. Is there a solution? If not, this should also be stated 
> in the text and the security considerations.
>
> Various sections: DoS resistance:
> The draft briefly mentions that the protocol is susceptible to DoS 
> attacks. This statement is rather vague and only mentions the absence 
> of "half-stateless DoS protection nature of the base exchange" and 
> immediate replays. However, CPU targeted DoS attacks (verification of 
> PK-sigantures without a puzzle or working HMAC to shelter against 
> floods of HIP DATA packets - not necessarily replays) seem much more 
> realistic to me than state a space exhaustion attacks. Using HIP DATA 
> packet creates a computational asymmetry between the attacker and the 
> victim (receiver). This imbalance could be mentioned in a more 
> explicit way.

These are known attacks and that is why we have said in the security 
considerations section that host should consider carefully when to 
accept HIP data packets.


> Editorial comments:
> -------------------
>
> Section 4.3: "The host MAY responds" -> "The host MAY respond"

Thanks for the comments
Jan