Return-Path: X-Original-To: ipv6@mail2.ietf.org Delivered-To: ipv6@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 03C9194877B7 for ; Wed, 3 Dec 2025 05:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2hbrbfvHEI8 for ; Wed, 3 Dec 2025 05:54:19 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id F29B5948775A for ; Wed, 3 Dec 2025 05:54:10 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-bc0d7255434so277328a12.0 for ; Wed, 03 Dec 2025 05:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764770044; x=1765374844; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QZK4CUZbsrHZGtIQZjJgp3HzFtx/cqkSzP6p9A0wsCs=; b=gofLiDasF2jIkC43yOmZgxY0t6wqO70LgQxHGn8G46JPlVVPSB4vL6S+Y+ChWVjDXH f8rfxGnVTwNHN3r1XoWzM/gZzRoKhpgB5leSNzL+lmX6jHtBaPw/qW9GCMhxt5QaGkQ7 hFLFGy69u+LizrKtvDQv9zzy2cDkpRJ4xBqC/9LYOvFvmtsP7fP1eeE6t1SxoAMnd4nu bRabxqiBBnxCT998juC2lsGbQfmS7yHQNDAb59WJa1YltfoChHwPj6UR2nCT4f8SYUPh W0co8IBZEm1ydsnyQSo36VwcwFQEVHRrGANqn2TlM/bDO2u4I29oTsFWY9DpYwCDmqZL PsfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764770044; x=1765374844; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QZK4CUZbsrHZGtIQZjJgp3HzFtx/cqkSzP6p9A0wsCs=; b=HxqdB3VgtpNruPKJvT9+tIZfkAdrTYcsVdqShI6G+tUQaWwS2ukhqtVTn9zHoWTZ2j ifXa/WGpGehK9MsDc8FX9Uz6lCxxNdr0s+ena+257LV8JoH3WVsp5ApXk41ZezgFJ7bC ng10m++DEdS6dI1OzK97M6IAjMP1pecAb+0C2MEE67APBkcbQOMqB8VTGDb/4POrC63v i3TYxfR/NgrczLhGweh32Y0ah7v/bugoivzpbMJYF3ai1/Q459UxMGYqlQ2dwYeEfNQm DikivCOpWcWmsFaCiwaVa7DDTGXrooTFal2wPP2aIIoCLPYSeHBpTTuZ0NB9ZIoCN0Mz +qQQ== X-Forwarded-Encrypted: i=1; AJvYcCWtYqxJ8M/Ug556t5mjseG9D+ERFtmhObzsbwhrRsI8fHcsoTmdaW/9AHlCyWT0e0CTJLDh@ietf.org X-Gm-Message-State: AOJu0YzhlGmKxn+4aePgpjT+oqcRAwyi+cj97sypf5bf1+lJYjXUg01O 1XFe/7DKizViMi5n0tSqGTsIUiZCyh64yCupoD4l+WBKDN0FznYIDejqJZbLEVhF8FmTOy0MuGG 2U48DYBUq1rUmPeFp56sCiVAk3ooDNA== X-Gm-Gg: ASbGncsWi7Cyz+O+bQ4QkeGKcEfstMFxwP45llI3SYFdLxjZ9ArtyfPYxA47jZA7KMI h1dCCOJIssjX91TeffsBN8/9/hxVy+GPgX+TAnAZ6CLEWfBbZzRlSnE2tEh5aoDn6SCaxw/tCYL yP+oZRzPQ9+f/PIWOYnUqtvml7t6jkUL+usFdb6IGg77Rw4QkIueJvv9tcS9QznvjnLIPdP6MAP X2vGqRME7BqoTMttRzQcurSBWLKbCIpxrWkIvArQBxWQHbe1CQXcOTKy8sDFojgK2mUr9qHF3ns XRsXXMv7YrQpV5Y+VrOH0MVt0pQ= X-Google-Smtp-Source: AGHT+IFVTezCbNAlBzazF9Ef+/IGYeqFY4ZNS4jEthy8Ghyi3RwUOvbPoh7ZHN6Ohn9MDBL8S0NyduO1AJFaxPGC4Yo= X-Received: by 2002:a05:7301:fc83:b0:2a4:3593:4677 with SMTP id 5a478bee46e88-2ab92f09e55mr1442087eec.19.1764770043774; Wed, 03 Dec 2025 05:54:03 -0800 (PST) MIME-Version: 1.0 References: <176329456182.537904.482025678357762045@dt-datatracker-5bd94c585b-wk4l4> In-Reply-To: From: Deb Cooley Date: Wed, 3 Dec 2025 08:53:56 -0500 X-Gm-Features: AWmQ_bljLPKnajL3pMM7yfgAqM842dG2US-izhDPQCOXMyZz-l3ip0C7Vi_1Bb8 Message-ID: To: "Bonica, Ron" , "draft-ietf-6man-icmpv6-reflection@ietf.org" Content-Type: multipart/alternative; boundary="00000000000091cbc206450c8b60" Message-ID-Hash: TIFFLIL6735ND7N2ILQAK2WNBXD2AROI X-Message-ID-Hash: TIFFLIL6735ND7N2ILQAK2WNBXD2AROI X-MailFrom: debcooley1@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "ipv6@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIPv6=5DRe=3A_Deb_Cooley=27s_Discuss_on_draft-ietf-6man-icmpv6-r?= =?utf-8?q?eflection-12=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: "IPv6 Maintenance Working Group (6man)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000091cbc206450c8b60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies for the delay. I've looked at the changes in the v15 draft, and I think you have clarified, to the extent possible, the security concerns. I do agree that the baseline version of ICMP and ICMPv6 have vulnerabilities which lead to those protocols being blocked in many cases. This draft doesn't make these much worse, nor does it attempt to fix any of those issues. I expect that ICMP/ICMPv6 w/ this extension will be blocked just as often as the base protocols. I will clear my discuss. Deb On Fri, Nov 21, 2025 at 12:21=E2=80=AFPM Bonica, Ron wrote: > Deb, > > Responses inline..... > > Ron > > > ------------------------------ > *From:* Deb Cooley > *Sent:* Friday, November 21, 2025 6:55 AM > *To:* Bonica, Ron > *Cc:* The IESG ; 6man-chairs@ietf.org <6man-chairs@ietf.or= g>; > draft-ietf-6man-icmpv6-reflection@ietf.org < > draft-ietf-6man-icmpv6-reflection@ietf.org>; furry13@gmail.com < > furry13@gmail.com>; ipv6@ietf.org > *Subject:* Re: Deb Cooley's Discuss on > draft-ietf-6man-icmpv6-reflection-12: (with DISCUSS and COMMENT) > > If that is true, then what is the value add provided by this > specification. Specifically if ICMPv6 responses provide a copy of the > request in the reply, isn't that a 'reflection' already? no extension > required. > > RB> Ketan and I have discussed this issue at length. The IESG was copied. > > Currently, ICMP error messages include an "original data field." This > field contains an image of the eliciting packet, as it was when it arrive= d > at the node that sent the ICMP error message. As you point out, this is > exactly the information that the sender of the original packet requires. > > IETF RFCs instruct middle boxes (specifically NATs) to modify the ICMP > error message's original data field. So, when the ICMP error message > arrives at its destination, the original data field contents are > unreliable. If the ICMP error message traversed a NAT on route to its > destination, the original data field does contains an image of the > eliciting packet, as it was when it arrived at the node that sent the ICM= P > error message. > > The current draft addresses this problem by introducing a new ICMP > Extension Structure Object. This object, like the original data field, > contains an image of the eliciting packet, as it was when it arrived at t= he > node that sent the response. The IETF should never write an RFC instructi= ng > middle boxes to modify this object on route to its destination. Therefore= , > when this object arrives at its destination, its contents should be > reliable. > > > As has been said in other ballots, limiting the size of the response, and > possibly set patterns might reduce the ease of exploitation. > > RB> In order to prevent amplification attacks, the size of the response i= s > always equal to the size of the request. As with all ICMP messages, the > message size must not exceed 1280 bytes. As with all ICMP messages, this > one is rate-limited. > > In my mind, the existence of a linked bidirectional channel, and the > opportunity of malicious injection and/or modification into that channel > are the issues I would like to see addressed in a comprehensive fashion i= n > Sec Con. > > RB> I would be glad to write that section, but I need a little help. Am I > correct that I would have to begin by identifying the vulnerabilities > introduced by this draft that do not exist in plain old PING? If so, coul= d > you help me identify those vulnerabilities? > > I like the rewording of the Intro para and the removal of the last part o= f > Section 4. [middleboxes, i.e. firewalls and guards, will not be > adhering to your specification if there is a perceived security risk.] > > RB> Thanks. > > I also have little expectation that this mechanism will be allowed to > traverse the network unhindered. It is much easier to block it than to > actually filter to reduce the possibility of exfil. > > RB> Again, how is the possibility of exfiltration greater with the curren= t > draft than it is with plain old PING. > > I agree that some networks can't live with the exfiltration threats > introduced by PING and TRACEROUTE. Those networks filter appropriately at > their network edges. They could do likewise with the current draft. > > Ron > > > Deb > > > On Mon, Nov 17, 2025 at 10:30=E2=80=AFAM Bonica, Ron > wrote: > > Deb, > > Can all the same arguments be made regarding the data field in the ICMP > Echo/Echo Reply messages? > > Ron > > ------------------------------ > *From:* Deb Cooley via Datatracker > *Sent:* Sunday, November 16, 2025 7:02 AM > *To:* The IESG > *Cc:* 6man-chairs@ietf.org <6man-chairs@ietf.org>; > draft-ietf-6man-icmpv6-reflection@ietf.org < > draft-ietf-6man-icmpv6-reflection@ietf.org>; furry13@gmail.com < > furry13@gmail.com>; ipv6@ietf.org > *Subject:* Deb Cooley's Discuss on draft-ietf-6man-icmpv6-reflection-12: > (with DISCUSS and COMMENT) > > Deb Cooley has entered the following ballot position for > draft-ietf-6man-icmpv6-reflection-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statem= ents/handling-ballot-positions/__;!!NEt6yMaO-gk!A-y21fPp3fM-70EXPkJ6PnRmPa9= l_sIiN2oXRJq7Asbqqy-wNj1TeRYqTxpHYXQjqUA58w17X_HHgz4$ > > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6= man-icmpv6-reflection/__;!!NEt6yMaO-gk!A-y21fPp3fM-70EXPkJ6PnRmPa9l_sIiN2oX= RJq7Asbqqy-wNj1TeRYqTxpHYXQjqUA58w17Mw2Pn1A$ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > In my opinion, this is a dangerous extension that can be used for harm > without > detection. > > Prevention of modification: I don't see any way to determine if either t= he > request or the response has been modified. Any of the sender, recipient, > or > entities in-between can modify the contents to contain the information th= at > they want to convey. The recipient can lie about what has been received. > Middleboxes can modify any of the packets in either direction. > > Creating an unauthorized information channel: In addition, either > endpoint can > include 'arbitrary' data (as specified in Section 5, second to last > paragraph) > creating a channel to exfil (policy) prohibited information. The only > limit to > the size of the packet is a 'SHOULD NOT' to avoid fragmentation (Section = 4, > para 1). Only a soft 'must not' in Section 4 alludes to a middlebox > capability > to block attempted exfil. > > Possible ways forward: There has to be an allowance for a middlebox > (boundary > device) to protect the network by blocking exfil of policy prohibited dat= a. > There could be hard limits for packet size. And the allowance for the > inclusion of 'arbitrary data' in the request could be removed. There als= o > could to be strong wording in Security Considerations about how this > mechanism > can be abused. I'd be happy to help craft the Sec Consid part. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Robert Starks for their secdir review. > > > > --00000000000091cbc206450c8b60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the delay.=C2=A0 I've looked at the= changes in the v15 draft, and I think you have clarified, to the extent po= ssible, the security concerns.=C2=A0=C2=A0

I do ag= ree that the baseline version of ICMP and ICMPv6 have vulnerabilities which= lead to those protocols being blocked in many cases.=C2=A0 This draft does= n't make these much worse, nor does it attempt to fix any of those issu= es.=C2=A0 I expect that ICMP/ICMPv6 w/ this extension will be blocked just = as often as the base protocols.=C2=A0=C2=A0

I will= clear my discuss.

Deb

On Fri, Nov 21, 2025 at 12:21=E2=80=AFPM Bonica, Ron <ronald.bonica@hpe.com> wrote:
Deb,

Responses inline.....

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Ron


From:=C2=A0Deb Cooley <debcooley1@gmail.com>
Sent:=C2=A0Friday, November 21, 2025 6:55 AM
To:=C2=A0Bonica, Ron <ronald.bonica@hpe.com>
Cc:=C2=A0The IESG <iesg@ietf.org>; 6man-chairs@ietf.org <6man-chairs@ietf.org>; draft-ietf-6man-= icmpv6-reflection@ietf.org <draft-ietf-6man-icmpv6-reflection@i= etf.org>; fur= ry13@gmail.com <furry13@gmail.com>; ipv6@ietf.org <ipv6@ietf.org>
Subject:=C2=A0Re: Deb Cooley's Discuss on draft-ietf-6man-icmpv6= -reflection-12: (with DISCUSS and COMMENT)

If that is true, then what is the value add pr= ovided by this specification.=C2=A0 Specifically if ICMPv6 responses provid= e a copy of the request in the reply, isn't that a 'reflection'= already? no extension required.

RB> Ketan and I have discussed this issue at length. The IESG was copied= .=C2=A0

Currently, ICMP error messages include an "original data field." = This field contains an image of the eliciting packet, as it was when it arr= ived at the node that sent the ICMP error message. As you point out, this i= s exactly the information that the sender of the original packet requires.

IETF RFCs instruct middle boxes (specifically NATs) to modify the ICMP erro= r message's original data field. So, when the ICMP error message arrive= s at its destination,=C2=A0 the original data field contents are unreliable= . If the ICMP error message traversed a NAT on route to its destination, the original data field does contains an imag= e of the eliciting packet, as it was when it arrived at the node that sent = the ICMP error message.

The current draft addresses this problem by introducing a new ICMP Extensio= n Structure Object. This object, like the original data field, contains an = image of the eliciting packet, as it was when it arrived at the node that s= ent the response. The IETF should never write an RFC instructing middle boxes to modify this object on route= to its destination. Therefore, when this object arrives at its destination= , its contents should be reliable.


As has been said in other ballots, limiting th= e size of the response, and possibly set patterns might reduce the ease of = exploitation.

RB> In order to prevent amplification attacks, the size of the response = is always equal to the size of the request. As with all ICMP messages, the = message size must not exceed 1280 bytes. As with all ICMP messages, this on= e is rate-limited.

In my mind, the existence of a linked bidirect= ional channel, and the opportunity of malicious injection and/or modificati= on into that channel are the issues I would like to see addressed in a comp= rehensive fashion in Sec Con.=C2=A0

RB> I would be glad to write that section, but I need a little help. Am = I correct that I would have to begin by identifying the vulnerabilities int= roduced by this draft that do not exist in plain old PING? If so, could you= help me identify those vulnerabilities?=C2=A0

I like the rewording of the Intro para and the= removal of the last part of Section 4.=C2=A0 [middleboxes, i.e. firewalls = and guards, will not be adhering=C2=A0to your specification if there is a p= erceived security risk.]

RB> Thanks.

I also have little expectation that this mecha= nism will be allowed to traverse the network unhindered.=C2=A0 It is much e= asier to block it than to actually filter to reduce the possibility of exfi= l.=C2=A0=C2=A0

RB> Again, how is the possibility of exfiltration greater with the curre= nt draft than it is with plain old PING.

I agree that some networks can't live with the exfiltration threats int= roduced by PING and TRACEROUTE. Those networks filter appropriately at thei= r network edges. They could do likewise with the current draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ro= n


Deb


On Mon, Nov 17, 2025 at 10:30=E2=80=AFAM Bonic= a, Ron <ronald.bonic= a@hpe.com> wrote:
Deb,

Can all the same arguments be made regarding the data field in the ICMP Ech= o/Echo Reply messages?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Ron

From:=C2=A0Deb Cooley via Datatracker <noreply@ietf.org>
Sent:=C2=A0Sunday, November 16, 2025 7:02 AM
To:=C2=A0The IESG <ie= sg@ietf.org>
Cc: 6man-chairs@ietf.org=C2=A0<6man-chairs@ietf.org>; draft-ietf-6man-icmpv6-reflection@ietf.org=C2=A0<draft-ietf-6man-icmpv= 6-reflection@ietf.org>; furry13@gmail.com=C2=A0<furry13@gmail.com>; ipv6@ietf.org=C2=A0<ipv6= @ietf.org>
Subject:=C2=A0Deb Cooley's Discuss on draft-ietf-6man-icmpv6-ref= lection-12: (with DISCUSS and COMMENT)
=C2=A0
Deb Cooley has entered the foll= owing ballot position for
draft-ietf-6man-icmpv6-reflection-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statemen= ts/handling-ballot-positions/__;!!NEt6yMaO-gk!A-y21fPp3fM-70EXPkJ6PnRmPa9l_= sIiN2oXRJq7Asbqqy-wNj1TeRYqTxpHYXQjqUA58w17X_HHgz4$=C2=A0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://u= rldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-icmpv6-= reflection/__;!!NEt6yMaO-gk!A-y21fPp3fM-70EXPkJ6PnRmPa9l_sIiN2oXRJq7Asbqqy-= wNj1TeRYqTxpHYXQjqUA58w17Mw2Pn1A$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In my opinion, this is a dangerous extension that can be used for harm with= out
detection.

Prevention of modification:=C2=A0 I don't see any way to determine if e= ither the
request or the response has been modified.=C2=A0 Any of the sender, recipie= nt, or
entities in-between can modify the contents to contain the information that=
they want to convey. The recipient can lie about what has been received. Middleboxes can modify any of the packets in either direction.

Creating an unauthorized information channel:=C2=A0 In addition, either end= point can
include 'arbitrary' data (as specified in Section 5, second to last= paragraph)
creating a channel to exfil (policy) prohibited information.=C2=A0 The only= limit to
the size of the packet is a 'SHOULD NOT' to avoid fragmentation (Se= ction 4,
para 1).=C2=A0 Only a soft 'must not' in Section 4 alludes to a mid= dlebox capability
to block attempted exfil.

Possible ways forward:=C2=A0 There has to be an allowance for a middlebox (= boundary
device) to protect the network by blocking exfil of policy prohibited data.=
There could be hard limits for packet size.=C2=A0 And the allowance for the=
inclusion of 'arbitrary data' in the request could be removed.=C2= =A0 There also
could to be strong wording in Security Considerations about how this mechan= ism
can be abused.=C2=A0 I'd be happy to help craft the Sec Consid part.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Robert Starks for their secdir review.



--00000000000091cbc206450c8b60--