Hi Graham,
I don't think it is necessary, since RFC7296 already has
the requirement in Section 2.1:
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.
So, such implementations are obviously broken, and I don't
think we need to duplicate the RFC2119 requirements from IKEv2 spec.
If you think it's worth to emphasize this requirement, then, I think,
it must be re-worded without using RFC2119 words,
and must refer to the RFC7296 as the source of requirement.
Something like that:
To prevent amplification attacks the Responder must
retransmit the response message only if it receives a
retransmitted request from Initiator, and must not do it
under any other circumstances. Note, that this behaviour
is already prescribed in Section 2.1 of RFC7296.
Regards,
Valery.
----- Original Message -----
From: "Graham Bartlett (grbartle)" <grbar...@cisco.com>
To: "Yoav Nir" <ynir.i...@gmail.com>
Cc: "Valery Smyslov" <sva...@gmail.com>; "Paul Wouters" <p...@nohats.ca>;
<ipsec@ietf.org>
Sent: Tuesday, March 15, 2016 6:25 PM
Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
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..)
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;
"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."
Thoughts?
cheers
On 06/03/2016 17:09, "Yoav Nir" <ynir.i...@gmail.com> wrote:
IMHO even in that case this is not an interesting attack. We should be
worried about amplification attacks where little traffic causes a lot of
traffic, not a case where I send a 200-byte packet which results in a
250-byte packet, and not even a 5 250-byte packets. Sending a request and
directing a server to send an entire movie in 4K quality using RTP in an
interesting amplification attack. Using a 10-Mbps uplink to generate
12-Mbps of traffic is not.
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
