On Wed, 24 Feb 2021 at 02:51, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > > Hi, Tom, > > On 23/2/21 11:34, Tom Herbert wrote: > [...] > >>From the draft: > > > > "Unless appropriate mitigations are put in place (e.g., packet > > dropping and/or rate- limiting), an attacker could simply send a large > > amount of IPv6 traffic employing IPv6 Extension Headers with the > > purpose of performing a Denial of Service (DoS) attack" > > > > That is clearly recommending a mitigation which is to drop packets or > > rate-limit. > > No, We're just stating the obvious. If we were performing a > recommendation, the text would be something like "IPv6 implementations > should". And we'd also be using RFC2119 speak... and the document would > be BCP. > It reads like an implied recommendation to me. It's stating possible prevention measures, and then the consequences of not doing them. That implies the stated prevention measures are recommended. (e.g. "If you aren't careful with a knife, you could cut yourself (so be careful with a knife)"). If you don't want it to read like a recommendation, the prevention measures should be taken out, and just state the action and the consequences e.g. something like: "It is possible for an attacker to send a large amount of IPv6 traffic employing IPv6 Extension Headers with the purpose of performing a Denial of Service (DoS) attack." That leaves it to the reader to work out how to prevent or mitigate the consequences if they consider it to be an issue. Regards, Mark. > > > Without any parameterization, this effectively justifies > > routers to arbitrarily drop all packets with any extension headers > > (rate-limiting packets makes the protocol effectively useless). Also, > > if mitigations are being mentioned then the draft should also mention > > the possibility that routers could be fixed, this is particularly > > apropos with regards to the "DoS due to implementation errors". > > Contemporary routers are trending towards being programmable so > > implementation errors should be more amendable to being fixed without > > hardware swap out. > > This is document does not provide any sort of advice. It's an analysis > of which packets may get dropped. > > What you are asking could indeed be interesting -- but it's certainly > out of the scope of this document. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@xxxxxxxxxxxxxxx > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@xxxxxxxx > https://www.ietf.org/mailman/listinfo/v6ops -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
