Yoav Nir writes:
> > I¹ve seen an amplification attack, where an implementation (as a
> > responder) would reply to a SA_INIT. If the responder did not receive a
> > reply to its SA_INIT it would re-transmit either 3 or 5 times (can¹t
> > remember exactly). (this seemed to not conform to 2.1 retransmission
> > timers..
>
> It doesn’t conform. I think this was more common in IKEv1, but I’m
> not sure why. Maybe because of the need to store a larger state for
> Main Mode.
It was because IKEv1 did not specify request response pairs. Every
message was fire and forget message, and the sender of the mssage was
supposed to take care whether it reached the other end or not. See
section 5.1 of RFC2408:
----------------------------------------------------------------------
When transmitting an ISAKMP message, the transmitting entity
(initiator or responder) MUST do the following:
1. Set a timer and initialize a retry counter.
NOTE: Implementations MUST NOT use a fixed timer. Instead,
transmission timer values should be adjusted dynamically based on
measured round trip times. In addition, successive
retransmissions of the same packet should be separated by
increasingly longer time intervals (e.g., exponential backoff).
2. If the timer expires, the ISAKMP message is resent and the retry
counter is decremented.
3. If the retry counter reaches zero (0), the event, RETRY LIMIT
REACHED, MAY be logged in the appropriate system audit file.
4. The ISAKMP protocol machine clears all states and returns to
IDLE.
----------------------------------------------------------------------
> In IKEv2 a Responder should only reply once, but store the reply for
> retransmission in case the request is received again.
Yep. See section 2.1 of RFC7296.
> 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.
The IKEv1 reflection attacks can be bad, as sending single packet, you
can generate 10 packets to be sent over several tens of seconds.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
