[IPv6]Re: Deb Cooley's Discuss on draft-ietf-6man-icmpv6-reflection-12: (with DISCUSS and COMMENT)

[Deb Cooley <[e-mail]>]

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 PM Bonica, Ron <[e-mail]> wrote:

> Deb,
>
> Responses inline.....
>
>                          Ron
>
>
> ------------------------------
> *From:* Deb Cooley <[e-mail]>
> *Sent:* Friday, November 21, 2025 6:55 AM
> *To:* Bonica, Ron <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>
> *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 arrived
> 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 ICMP
> 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 the
> node that sent 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 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 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
> 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 in
> 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, could
> you help me identify those vulnerabilities?
>
> I like the rewording of the Intro para and the removal of the last part of
> 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 current
> 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 AM Bonica, Ron <[e-mail]>
> 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 <[e-mail]>
> *Sent:* Sunday, November 16, 2025 7:02 AM
> *To:* The IESG <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>
> *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/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!A-y21fPp3fM-70EXPkJ6PnRmPa9l_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-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
> without
> detection.
>
> Prevention of modification:  I don't see any way to determine if either the
> request or the response has been modified.  Any of the sender, recipient,
> 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:  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 data.
> There could be hard limits for packet size.  And the allowance for the
> inclusion of 'arbitrary data' in the request could be removed.  There also
> 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.
>
>
>
>