Graham Bartlett (grbartle) writes: > There’s many references to IKEv2 in the paper. E.g.
There is references to the IKEv2, but the paper is not talking about the IKEv2. It is clear from the packet traces (see version number), and the retransmission behavior seen. In the IKEv2 the responder will NEVER retransmit the response unless initiator retransmits its request (provided the implementation folows what RFC mandates). > "Figure 1: Zmap scan using our IKEv2 payload”.. > > I’ve managed to track the author down and made contact. I’ll sync you in > on a mail and hopefully we can verify what was exactly was used. > > All I would ask is - if many IKEv2 implementation are vulnerable to an > amplification attack, I feel it would be prudent to add some words to > remind implementors of the risk. I do not know any IKEv2 implementations that would be vulnerable to this multiple responses attack, and if IKEv2 is implemented as specified in the RFC7296, they are not vulnerable. >From RFC7296: For every pair of IKE messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
