[Int-area] Re: [IPv6]ICMP Query and ICMP Query for IOAM
"Bonica, Ron" <[email protected]> Wed, 25 Feb 2026 15:23:33 +0000
| Newsgroups | gmane.ietf.int,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <DM4PR84MB2310AE9F14DE6E87A36021FEF475A@DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM> |
--===============7184724526906797389==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_DM4PR84MB2310AE9F14DE6E87A36021FEF475ADM4PR84MB2310NAMP_"
--_000_DM4PR84MB2310AE9F14DE6E87A36021FEF475ADM4PR84MB2310NAMP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
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 recommende=
d in RFC 1812 and widely deployed).
*
A more strict rate limit, applied to some informational messages (e.g., Ech=
o, 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] <int-are=
[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=97it causes not just lack of amplification, but als=
o an actual reduction in traffic volume compared with what an attacker coul=
d achieve by sending the packets directly. Just as importantly, this attenu=
ation 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 cap=
acity as processing a larger packet.>>
https://queue.acm.org/detail.cfm?id=3D2578510
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 in=
hibits denial of service attacks... How well this lends itself to denial of=
service attacks (on the queried host), IMHO, depends more on how costly th=
e requested pieces of information are to gather... and since the draft refe=
rs 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 requi=
red to create a denial of service attack. So I would just rephrase that sen=
tence from "To prevent denial of service attacks,..." to "To remove to pote=
ntial 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 dra=
ft introduces two new ICMP messages (ICMP Query Request/Response) for the p=
urpose 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-inta=
rea-icmp-query-00__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1Z=
C2_Or5zb9hhYJyuGpNyIHc7_RAoQQw$> https://datatracker.ietf.org/doc/html/draf=
t-ietf-6man-icmpv6-ioam-conf-state-10<https://urldefense.com/v3/__https://d=
atatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-state-10__;!!=
NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc=
7mgrouEQ$>
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_Or5zb9hhYJyuGp=
NyIHc6nqx4i7w$>
--------------------------------------------------------------------
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--_000_DM4PR84MB2310AE9F14DE6E87A36021FEF475ADM4PR84MB2310NAMP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Hi Paul,</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
I think that your statement applies even more globally.</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
Would it make sense to apply the following rate limits:</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<br>
</div>
<ul style=3D"margin-top: 0px; margin-bottom: 0px;" data-editing-info=3D"{&q=
uot;applyListStyleFromLevel":false,"unorderedStyleType":2}">
<li style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C=
alibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-s=
tyle-type: "- ";">
<div role=3D"presentation" class=3D"elementToProof">A less strict rate limi=
t, applied to all ICMP messages. (Already recommended in RFC 1812 and widel=
y deployed).</div>
</li><li style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontServi=
ce, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); l=
ist-style-type: "- ";">
<div role=3D"presentation" class=3D"elementToProof">A more strict rate limi=
t, applied to some informational messages (e.g., Echo, Extended Echo, Query=
)</div>
</li></ul>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
 =
; &nb=
sp; &=
nbsp; =
Ron</div>
<div id=3D"appendonsend"></div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Paul Vixie <paul@r=
edbarn.org><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]>; int-area@ietf=
.org <[email protected]>; [email protected] <[email protected]><br>
<b>Subject:</b> [Int-area] Re: [IPv6]ICMP Query and ICMP Query for IOAM</fo=
nt>
<div> </div>
</div>
<div><span dir=3D"ltr" style=3D"margin-top:0; margin-bottom:0">I think rela=
tive request to response size is the wrong control point. Here's how we rea=
soned it for DNS RRL:</span>
<br>
<br>
<span dir=3D"ltr" style=3D"margin-top:0; margin-bottom:0"><<One impor=
tant principle of DNS RRL's design is that it makes a DNS server into a DDo=
S attenuator=97it 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 importa=
ntly, this attenuation is not only in the number of bits per second, but al=
so 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 process=
ing a larger packet.>></span>
<br>
<br>
<span dir=3D"ltr" style=3D"margin-top:0; margin-bottom:0"><a href=3D"https:=
//queue.acm.org/detail.cfm?id=3D2578510">https://queue.acm.org/detail.cfm?i=
d=3D2578510</a></span>
<br>
<div class=3D"x_fairemail_signature"><span dir=3D"ltr" style=3D"margin-top:=
0; margin-bottom:0">Paul Vixie</span>
<br>
</div>
<div class=3D"x_fairemail_quote">
<div dir=3D"ltr">
<p>Feb 25, 2026 11:14:06 Sebastian Moeller <[email protected]=
tf.org>:</p>
</div>
<blockquote style=3D"margin:0; border-left:3px solid #ccc; padding-left:10p=
x">
<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 in=
hibits denial of service attacks... How well this lends itself to denial of=
service attacks (on the queried host), IMHO, depends more on how costly th=
e 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 requi=
red to create a denial of service
attack. So I would just rephrase that sentence from "To prevent denia=
l of service attacks,..." to "To remove to potential of abusing t=
his as a means of attack amplification,..."
<br>
<br>
Regards <br>
Sebastian <br>
<br>
<br>
<br>
<br>
<blockquote style=3D"margin:0; border-left:3px solid #ccc; padding-left:10p=
x">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 dra=
ft introduces two new ICMP messages (ICMP Query Request/Response) for the p=
urpose 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=3D"https://urldefense.com/v3/__https://datatracker.ietf.org/doc/htm=
l/draft-xbm-intarea-icmp-query-00__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiT=
wk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc7_RAoQQw$">https://datatracker.ietf.o=
rg/doc/html/draft-xbm-intarea-icmp-query-00</a>
<a href=3D"https://urldefense.com/v3/__https://datatracker.ietf.org/doc/htm=
l/draft-ietf-6man-icmpv6-ioam-conf-state-10__;!!NpxR!jcvjxz74Nqli0wiCVJeYtl=
GyloSUFmiTwk2Hkfe5eSG0Xi1ZC2_Or5zb9hhYJyuGpNyIHc7mgrouEQ$">
https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-stat=
e-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=3D"https://urldefense.com/v3/__https://mailman3.ietf.org=
/mailman3/lists/[email protected]/__;!!NpxR!jcvjxz74Nqli0wiCVJeYtlGyloSUFmiTwk2=
Hkfe5eSG0Xi1ZC2_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>
</body>
</html>
--_000_DM4PR84MB2310AE9F14DE6E87A36021FEF475ADM4PR84MB2310NAMP_--
--===============7184724526906797389==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50LWFyZWEg
bWFpbGluZyBsaXN0IC0tIGludC1hcmVhQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4g
ZW1haWwgdG8gaW50LWFyZWEtbGVhdmVAaWV0Zi5vcmcK
--===============7184724526906797389==--