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

[Deb Cooley <[e-mail]>]

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.

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

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.

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.]

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.

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.
>
>
>
>