Subject: Re: [core] Consensus on using Echo to mitigate NoSec amplification?

From: Christian Amsüss <[email-masked]>
Date: Mon, 2 Mar 2020 17:06:27 +0100

On Tue, Feb 25, 2020 at 02:19:33PM +0100, Carsten Bormann wrote:
> Would the CoRE WG be fine with expanding the “updates 7252” text in
> draft-ietf-core-echo-request-tag to also include recommending this
> mitigation?  If you have a position on this, please reply to the list
> (or to the chairs) by March 2nd.

The current version stays as vague on what a larger response is as
RFC7252, I'd like to sharpen that when incorporating the above. My
current corner points are "a TCP SYN+ACK is 3 byte larger than a SYN",
and that NTP had a factor-200 amplification built in earlier versions
(though that's probably UDP-only, and headers'd make that more like
factor-50).

Is there any guidance that could be referenced, eg. an RFC that puts a
number to what consitutes an amplification attack vector? Even [RFC4732]
only talks of "significantly greater" packages.

Thanks
Christian

[RFC4732]: https://tools.ietf.org/html/rfc4732#section-3.1

-- 
Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life.
  -- Terry Pratchett (attributed)

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 2 Mar 2020 16:15:57 +0000

Hi Christian,

> only talks of "significantly greater" packages.

QUIC seems to set the limit to 3x the request size [1].

[1] https://www.ietf.org/id/draft-ietf-quic-transport-27.html#section-10.3

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Achim Kraus <[email-masked]>
Date: Mon, 2 Mar 2020 20:43:32 +0100

Hi List,

> only talks of "significantly greater" packages.

FMPOV, not only the size of a response to an "unverfied peer" should be
considered to be limited, also the interval of consecutive responses to
such a peer should be throttled.
(For me this looks very similar to "DTLS 1.2 Connection ID". When a peer
seems to have a new ip-address, the traffic to that peer should be
limited in size and frequence, until the new address is verfied.)

Best regards
Achim Kraus

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>