yes, it's right +1
On Wed, Mar 16, 2016 at 6:21 AM, 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] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > -- Best Regards Dr. Karan Verma Assistant Professor Computer Science and Engineering Dept. Central University Rajasthan, India Website: www.drkaranverma.com Phone: +917568169258
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
