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

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

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Sunday, November 16, 2025 7:02 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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.