[Int-area] Re: [IPv6]ICMP Query and ICMP Query for IOAM
Paul Vixie <[email protected]> Thu, 26 Feb 2026 09:20:56 +0100
| Newsgroups | gmane.ietf.int,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <[email protected]> |
--===============4111477892918242189== Content-Type: multipart/alternative; boundary="----=_Part_4_199314355.1772094056452" ------=_Part_4_199314355.1772094056452 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Yes, at a minimum. Paul Vixie Feb 25, 2026 16:23:33 Bonica, Ron <[email protected]>: > Hi Paul, > > I think that your statement applies even more globally. > > Would it make sense to apply the following rate limits: > > * A less strict rate limit, applied to all ICMP messages. (Already recommended in RFC 1812 and widely deployed). > * A more strict rate limit, applied to some informational messages (e.g., Echo, Extended Echo, Query) > > Ron > ---------------------------------------- > *From:* Paul Vixie <[email protected]> > *Sent:* Wednesday, February 25, 2026 7:47 AM > *To:* Sebastian Moeller <[email protected]> > *Cc:* [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> > *Subject:* [Int-area] Re: [IPv6]ICMP Query and ICMP Query for IOAM > > I think relative request to response size is the wrong control point. Here's how we reasoned it for DNS RRL: > > <<One important principle of DNS RRL's design is that it makes a DNS server into a DDoS attenuator—it causes not just lack of amplification, but also an actual reduction in traffic volume compared with what an attacker could achieve by sending the packets directly. Just as importantly, this attenuation is not only in the number of bits per second, but also in the number of packets per second. That's important in a world full of complex stateful firewalls where the bottleneck is often in the number of packets, not bits, and processing a small packet costs just as much in terms of firewall capacity as processing a larger packet.>> > > https://queue.acm.org/detail.cfm?id=2578510 > Paul Vixie > Feb 25, 2026 11:14:06 Sebastian Moeller <[email protected]>: >> Hi, >> >> quick note: >> >> The draft states: >> To prevent denial of service attacks, the ICMP Query Response message MUST NOT be longer than the corresponding ICMP Query Request message. >> >> IMHO this reasonable requirement does prevent amplification more than it inhibits denial of service attacks... How well this lends itself to denial of service attacks (on the queried host), IMHO, depends more on how costly the requested pieces of information are to gather... and since the draft refers to another (not yet written?) draft for the actual queries this is hard to assess. >> For using this to create reflection attacks on other hosts this size limit really also only affects the effective amplification when using that attack vector, but if an attacker commands enough nodes no amplification is required to create a denial of service attack. So I would just rephrase that sentence from "To prevent denial of service attacks,..." to "To remove to potential of abusing this as a means of attack amplification,..." >> >> Regards >> Sebastian >> >> >> >> >>> On 25. Feb 2026, at 09:10, [email protected] wrote: >>> >>> Dear all, >>> >>> A new document draft-xbm-intarea-icmp-query-00 has been submitted. This draft introduces two new ICMP messages (ICMP Query Request/Response) for the purpose of IP node information query. >>> After that, draft-ietf-6man-icmpv6-conf-state was updated and its basis was changed from RFC 4620 to draft-xbm-intarea-icmp-query. >>> Links for the two drafts are as below. >>> https://datatracker.ietf.org/doc/html/draft-xbm-intarea-icmp-query-00[https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-xbm-intarea-icmp-query-00__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc7_RAoQQw$] https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-state-10[https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-state-10__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc7mgrouEQ$] >>> Looking forward to your review and comments. >>> >>> Cheers, >>> Xiao Min >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [email protected] >>> List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/[https://urldefense.com/v3/__https://mailman3.ietf.org/mailman3/lists/[email protected]/__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc6nqx4i7w$] >>> -------------------------------------------------------------------- >> >> _______________________________________________ >> Int-area mailing list -- [email protected] >> To unsubscribe send an email to [email protected] ------=_Part_4_199314355.1772094056452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta name="viewport" content="width=device-width, initial-scale=1.0"> </head> <body> <span dir="ltr" style="margin-top:0; margin-bottom:0;">Yes, at a minimum.</span> <br> <div class="fairemail_signature"> <span dir="ltr" style="margin-top:0; margin-bottom:0;">Paul Vixie</span> <br> </div> <div class="fairemail_quote"> <div dir="ltr"> <p>Feb 25, 2026 16:23:33 Bonica, Ron <[email protected]>:</p> </div> <blockquote dir="ltr" style="margin:0;border-left:3px solid #ccc; padding-left:10px;"> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof"> Hi Paul, </div> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof"> <br> </div> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof"> I think that your statement applies even more globally. </div> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof"> <br> </div> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof"> Would it make sense to apply the following rate limits: </div> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof"> <br> </div> <ul style="margin-top: 0px; margin-bottom: 0px;" data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":2}"> <li style=" color: rgb(0, 0, 0); list-style-type: "- "; font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;"> <div role="presentation" class="elementToProof"> A less strict rate limit, applied to all ICMP messages. (Already recommended in RFC 1812 and widely deployed). </div></li> <li style=" color: rgb(0, 0, 0); list-style-type: "- "; font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;"> <div role="presentation" class="elementToProof"> A more strict rate limit, applied to some informational messages (e.g., Echo, Extended Echo, Query) </div></li> </ul> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;"> <br> </div> <div style=" color: rgb(0, 0, 0); font-size: 12pt;font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof"> Ron </div> <div id="appendonsend"></div> <hr style="display:inline-block;width:98%;" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr"> <font face="Calibri, sans-serif" style="font-size:11pt;" color="#000000"><b>From:</b> Paul Vixie <[email protected]><br><b>Sent:</b> Wednesday, February 25, 2026 7:47 AM<br><b>To:</b> Sebastian Moeller <[email protected]><br><b>Cc:</b> [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]><br><b>Subject:</b> [Int-area] Re: [IPv6]ICMP Query and ICMP Query for IOAM</font> <div> </div> </div> <div> <span dir="ltr" style="margin-top:0; margin-bottom:0;">I think relative request to response size is the wrong control point. Here's how we reasoned it for DNS RRL:</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;"><<One important principle of DNS RRL's design is that it makes a DNS server into a DDoS attenuator—it causes not just lack of amplification, but also an actual reduction in traffic volume compared with what an attacker could achieve by sending the packets directly. Just as importantly, this attenuation is not only in the number of bits per second, but also in the number of packets per second. That's important in a world full of complex stateful firewalls where the bottleneck is often in the number of packets, not bits, and processing a small packet costs just as much in terms of firewall capacity as processing a larger packet.>></span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;"><a href="https://queue.acm.org/detail.cfm?id=2578510">https://queue.acm.org/detail.cfm?id=2578510</a></span> <br> <div class="x_fairemail_signature"> <span dir="ltr" style="margin-top:0; margin-bottom:0;">Paul Vixie</span> <br> </div> <div class="x_fairemail_quote"> <div dir="ltr"> <p style="margin-top: 0; margin-bottom: 0;">Feb 25, 2026 11:14:06 Sebastian Moeller <[email protected]>:</p> </div> <blockquote style="margin:0; border-left:3px solid #ccc; padding-left:10px;"> <div> Hi, <br> <br> quick note: <br> <br> The draft states: <br> To prevent denial of service attacks, the ICMP Query Response message MUST NOT be longer than the corresponding ICMP Query Request message. <br> <br> IMHO this reasonable requirement does prevent amplification more than it inhibits denial of service attacks... How well this lends itself to denial of service attacks (on the queried host), IMHO, depends more on how costly the requested pieces of information are to gather... and since the draft refers to another (not yet written?) draft for the actual queries this is hard to assess. <br> For using this to create reflection attacks on other hosts this size limit really also only affects the effective amplification when using that attack vector, but if an attacker commands enough nodes no amplification is required to create a denial of service attack. So I would just rephrase that sentence from "To prevent denial of service attacks,..." to "To remove to potential of abusing this as a means of attack amplification,..." <br> <br> Regards <br> Sebastian <br> <br> <br> <br> <br> <blockquote style="margin:0; border-left:3px solid #ccc; padding-left:10px;"> On 25. Feb 2026, at 09:10, [email protected] wrote: <br> <br> Dear all, <br> <br> A new document draft-xbm-intarea-icmp-query-00 has been submitted. This draft introduces two new ICMP messages (ICMP Query Request/Response) for the purpose of IP node information query. <br> After that, draft-ietf-6man-icmpv6-conf-state was updated and its basis was changed from RFC 4620 to draft-xbm-intarea-icmp-query. <br> Links for the two drafts are as below. <br><a href="https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-xbm-intarea-icmp-query-00__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc7_RAoQQw$">https://datatracker.ietf.org/doc/html/draft-xbm-intarea-icmp-query-00</a> <a href="https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-state-10__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc7mgrouEQ$"> https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-state-10</a> <br> Looking forward to your review and comments. <br> <br> Cheers, <br> Xiao Min <br> -------------------------------------------------------------------- <br> IETF IPv6 working group mailing list <br> [email protected] <br> List Info: <a href="https://urldefense.com/v3/__https://mailman3.ietf.org/mailman3/lists/[email protected]/__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc6nqx4i7w$"> https://mailman3.ietf.org/mailman3/lists/[email protected]/</a> <br> -------------------------------------------------------------------- <br> </blockquote> <br> _______________________________________________ <br> Int-area mailing list -- [email protected] <br> To unsubscribe send an email to [email protected] <br> </div> </blockquote> </div> </div> </blockquote> </div> </body> </html> ------=_Part_4_199314355.1772094056452-- --===============4111477892918242189== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50LWFyZWEg bWFpbGluZyBsaXN0IC0tIGludC1hcmVhQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4g ZW1haWwgdG8gaW50LWFyZWEtbGVhdmVAaWV0Zi5vcmcK --===============4111477892918242189==--