Hi Tero There’s many references to IKEv2 in the paper. E.g.
"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. cheers On 16/03/2016 00:51, "Tero Kivinen" <[email protected]> wrote: >Graham Bartlett (grbartle) writes: >> Hi >> >> Last night I noticed the following, >> >> https://community.akamai.com/docs/DOC-5289 >> >> It talks of various results when using a single packet to generate an >> amplification attack. (well worth a read..) > >And it does NOT talk about IKEv2 at all. The whole text is only >covering IKEv1, even if they claim to cover both IKE and IKEv2. > >RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers >IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies >completely different transmission policy, i.e. it does not use what is >defined in the RFC2408. > >This paper is just completely wrong and the conclusions for it is also >completely wrong for IKEv2. > >It should really say that everybody simply should DISABLE IKEv1 and >only enable IKEv2 in their configuration and that should fix the issue. > >The paper does not even have any kind of contact information, so there >is no way to send in comments to try to get them to understand that >their paper is completely wrong when related to the IKEv2. > >> As we discussed last week, all implementations that send multiple >>replies >> to a single SA_INIT would be broken in some form. Because of the impact >>of >> this (and these shocking results), I¹d like to add the following words >>to >> the security considerations around retransmissions with respect to >> amplification attacks using SA_INIT / IKE_AUTH; > >In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets >sent. All the frames used Exchange Type of 2 (Identity Protect == >IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH >etc). > >> "As described in RFC7296 Use of Retransmission Timers. For every pair of >> message it is the responsibility of the initiator to retransmit should a >> message be lost. A responder MUST only send a single reply to an SA_INIT >> or IKE_AUTH message and MUST never engage the retransmission mechanism, >> even if a reply is not received. This mitigates the chances that a >> response will become a victim of an amplification attack where a single >> packet is used to generate multiple replies." > >This requirement is already in the RFC7296 section 2.1, and there is >no point of say it again here. Even if we say it here, it does not >change the retransmissions for the IKEv1, as this draft does not cover >IKEv1. > >What we could say in the DDoS draft is to add saying that IKEv1 >protocol is obsoleted, and will be common avenue for the DDoS attacks, >and because of that it MUST be disabled. > >Or perhaps we need the IKEv1 considered harmful draft / >ikev1-diediediediedie... >-- >[email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
