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] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
