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

["Bonica, Ron" <[e-mail]>]

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.