[secdir] draft-ietf-6man-icmpv6-reflection-11 ietf last call Secdir review

[Robert Sparks via Datatracker <[e-mail]>]

Document: draft-ietf-6man-icmpv6-reflection
Title: Internet Control Message Protocol (ICMPv6) Reflection
Reviewer: Robert Sparks
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other review
comments.

This document is basically ready, but has issues to consider before publication
as a Proposed Standard RFC.

Primary Issues:

The figure makes it clear what a responder is intended to do, but the text does
not. At the bottom of page 6, the statement "it MUST copy the request message
into the object payload" is not what's intended. The intent is to only copy the
part of the request message the figure describes (headers up to a certain
point).

The document claims that "middle boxes are not intended to modify the Reflect
All object" and "Middle boxes must not modify the Reflect All extension
object." The use of lower case must not here is a warning sign. I think all you
can say in both cases is "If a middle box modifies the Reflect All extension
object, this mechanism does not work." and "There's no way to detect if a
middle box modifies the Reflect All extension object" (Unless there _is_, in
which case, the document should _definitely_ talk more about that.)

Consider discussing whether there's risk involved if a responder intentionally
misrepresents what it received in the Reflect All response. At least note the
possibility. Consider also discussing if there's any reason a responder and a
middlebox would collaborate to tell the requester something other than what
actually appeared at the responder.

I think it would be worth noting that a requester and responder could
collaborate to use this new payload space as a tunnel for arbitrary
communication (even using other extensions to make sure there was enough
_space_ needed for that collaboration) possibly circumventing security
mechanisms at, say, enterprise edges. Security ADs - note here that the doc
calls out the possibility of using this space for enabling round-trip time
calculations, for example.

Nits:

Page 3 2nd paragraph: s/as was when/as it was when/

Section 3 "Use Cases" doesn't look like use cases. It calls out some other
extensions and notes that the sender might be interested in what's received
when those extensions are used. Consider naming the section "Motivation".

Consider explicitly saying _why_ the Reflect All object MUST be the first
object in the Extension Structure.