[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Hipsec] Comments on hiccups draft



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.

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.

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.


Editorial comments:
-------------------

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

Best regards,
Tobias






--
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer