ietf-wg-ntp / draft-ietf-ntp-ntpv5-requirements

Other
1 stars 2 forks source link

Improving DDoS threat model point #24

Closed fiestajetsam closed 1 year ago

fiestajetsam commented 1 year ago

Ulrich write:

For " 3.1. Denial of Service and Amplification" I'd start the section with a sentence explaining that the UDP protocol can be misused for packet injection and packet redirection, and when a response is longer than a request it can be used as traffic amplification attack as well. Thus extra security measures have to be applied to prevent such (maybe also add a reference to some RFC dealing with that subject). Just listing "private mode" as culprit seems a bit biased IMHO.

This could be reworded a little bit better.

hart-NTP commented 1 year ago

For context, ntpdremoved the ntpd mode 7 monlist code entirely in 4.2.7p26 released in April 2010. That made it into the ntp-stable release 4.2.8 in December 2014. The ntpsec fork was after that. Also, in November 2011 4.2.7p230 disabled all mode 7 responses by ntpd by default, introducing a ntp.conf "enable mode7" override.

Even with the various bundled ntpd versions shipping for some time after those changes, it's been years since private mode has been a source of amplification. I don't think it is a good example of why NTPv5 needs to do things differently. Other mode 6 & mode 7 interactions are mild amplilfiers, but there are juicier targets to leverage.

fiestajetsam commented 1 year ago

@hart-NTP Which juicier targets are you thinking of specifically?

hart-NTP commented 1 year ago

Open DNS resolvers. There are so many to choose from, public and private. I'm guessing the big public resolvers have some mitigations to prevent sending too much via UDP to a single IP, but many ISPs have open resolvers as well.

fiestajetsam commented 1 year ago

Miroslav writes:

NTPv4 has previously suffered from DDoS amplification attacks using a combination of IP address spoofing and private mode commands used in many NTP implementations,

I suggest replacing "many" with "some". AFAIK only the ntp.org ntpd and its fork ntpsec have this issue.