[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] Comments on hiccups draft
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