IETF Last Call Review of draft-ietf-scone-protocol-07
review-ietf-scone-protocol-07-secdir-lc-mihalcea-2026-09-03-00

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 last call comments.

The summary of the review is Almost Ready.

The SCONE protocol defined in this document allows network elements
to convey throughput advice to the recipients of QUIC streams, by
altering SCONE packets prepended to QUIC datagrams. The core
mechanics of the protocol seem straight-forward. The document does
a thorough job of defining how the participants should use and react
to the protocol messages.

I had no previous exposure to SCONE, some of the comments below may
well reflect this.

* In sec. 2, Overview, fig. 1 along with the text describing it use
the term "added", and show the advice as "+advice", in the same way
that SCONE is composed with QUIC. This is may be confusing, as it
could be interpreted that some other message or data is added to
the datagram. Perhaps "conveyed" instead of "added", and
"SCONE(unknown)" -> "SCONE(advice)"?

* In sec. 3.3, Per-Flow Signal, the last sentence alludes to "security
implications", and points to sec. 10.2. I believe that should be
"privacy implications" instead.

* In sec. 5, SCONE Packet, has the following text:
"If the next packet in the
datagram does not have a Source Connection ID field, which is the
case for packets with a short header (Section 5.2 of [INVARIANTS]),
the Source Connection ID field is empty and the Source Connection ID
Length field is set to 0."
The last part should use normative language: "the Source Connection
ID field MUST be empty and the Source Connection ID Length field MUST
be set to 0."

* In sec. 5.3, Endpoint Processing of SCONE Packets:
"A SCONE packet is discarded if the rate signal is unknown (127)."
This should be normative, "MUST be discarded...".

* In sec. 6.1, Indicating Support on New Flows, and 6.3, Indications
for Migrated Flows, the term "new flows" seems to be used to give
contradictory normative indications. 6.1 says indication MUST be offered
on new flows, but 6.3 says applications MAY indicate on new flows
(including when migrating). I get the sense the two uses of "new flows"
are actually be referring to different use-cases. It would be good to
clarify either way.

* Also in sec. 6.1, Indicating Support on New Flows:
"The SCONE indication bytes MUST be sent in every datagram until the
client receives any datagram from the server, at which point the
client can be confident that the indication was received."
Given that the SCONE indication can be stripped, and the received
datagram does not necessarily ACK the indication, "confident" seems to 
overstate. Perhaps "at which point the client can cease including the
indication bytes"?

* In sec. 9.3, Damage to Other Protocols, there is the following normative
text:
"To that end, network elements MUST only update the content of
datagrams on a given address tuple a few times each monitoring
period. Network elements MAY update more often immediately after a
change in their throughput advice, to reduce the reaction time from
senders."
This describes protocol mechanics that should probably be in sec. 7.1.
Sec. 9.3 could retain the justification, without the normative text:
"To mitigate damage to other protocols that might share the SCONE
identifier space, network elements can restrict the frequency of
datagram updates as specified in Section 7.1."