On 19 Mar 2021, at 02:42, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Mon, Mar 15, 2021 at 05:38:40PM +0000, Jim Reid wrote: > >> Measuring the MTU to well-known locations on the Internet won’t be >> appropriate for some use cases. For instance inside private nets that >> aren’t connected to the Internet or for forwarding-only servers that >> never query an authoritatve server. > > Right, the forwarding-mostly (or only) servers should just measure the > PMTU to the relevant upstream(s).
The current draft says nothing about this. I’m suggesting it should. >> IMO it’s a bad idea to recommend specific servers that could be the >> target for those PMTU probes. [Suppose those names change one day - >> unlikely for the above but you never know.] That could become a vector >> of (D)DoS attacks - probably not on the above name servers themselves >> but on the access routers in front of them that might well be >> rate-limiting ICMP packets. > > I don't see the DDoS, such measurements should be rather infrequent, in > particular, I don't see why these would be much more frequent than root > zone priming queries, which full service resolvers do routinely at > startup. The PMTU probing rate could well end up being broadly similar to the rate of priming queries to the root. However those priming queries are almost certainly not going to result in ICMP responses. Which usually take a different code path through routers and get rate-limited. Which means PMTU probing could be a vector for (D)DoS attacks: not on the well-known authoriatative name servers but the access routers and firewalls in front of them. >> This could get nasty with icky CPE >> firmware: imagine every home router in (say) Comcast’s net doing PMTU >> to the same root server. > > These would generally not all boot up at the same time, and would be > expected to be configured in forward-only mode to the relevant Comcast > iterators. It’s unwise to make these assumptions. Besides, Comcast’s net and CPE configuration isn’t the only game in town. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
