| Internet-Draft | SCONE Criticisms | February 2025 |
| Thomson | Expires 9 August 2025 | [Page] |
A merge of the rate availability signaling schemes in the SCONE and TRAIN proposals is analysed and found to be infeasible.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://martinthomson.github.io/scone-merge-criticisms/draft-thomson-scone-merge-criticisms.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-thomson-scone-merge-criticisms/.¶
Discussion of this document takes place on the Standard Communication with Network Elements mailing list (mailto:scone@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scone. Subscribe at https://www.ietf.org/mailman/listinfo/scone/.¶
Source for this draft and an issue tracker can be found at https://github.com/martinthomson/scone-merge-criticisms.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 9 August 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
There are a few items where we might need to discuss the advantages of SCONE [SCONE], but overall there are not a lot of advantages to the proposed design over the one that TRAIN [TRAIN] proposes.¶
The idea that these designs might be merged does not make a lot of sense. The two designs are largely incompatible, as each relies on a fundamentally different mechanism.¶
The one major question about the nature of the signal is separable from a decision about how to design the signaling mechanism.¶
TRAIN is symmetric. SCONE is initiated by a client only.¶
TRAIN is negotiated as part of a connection. SCONE is unilaterally implemented by clients.¶
TRAIN endpoints coalesce a carriage packet with other packets, network elements modify the payload of that carriage.¶
SCONE requires that clients announce their willingness to receive signals to network elements. Thereafter network elements can send a signal any time to that client.¶
Like ECN, TRAIN signals follow the flow in the direction in which it might be affected. SCONE signals flow in the reverse direction, which means that if flows take a different path in each direction, the wrong set of network elements are involved.¶
SCONE packets have far weaker authentication. Once a packet is captured, any entity can generate a packet that will be accepted. In comparison, a TRAIN packet is carried along with real packets and so is only good for approximately as long as it takes to get to its destination. Spoofing requires that the packet be raced.¶
The requirement for negotiation in TRAIN makes it a tiny bit more complex. However, it also means that both client and server agree to its use before it is used. Negotiation is necessary to enable coalescing in TRAIN. Whether this is an advantage to TRAIN or SCONE seems subjective.¶
Arguably that a network element can send an updated signal at any time is an advantage for SCONE.¶
TRAIN presently proposes a signal that carries a choice from an (as-yet-unspecified) selection of 64 options. That’s not a lot.¶
SCONE has a 32-bit rate (in kbps) and a window (in ms), which is massively more flexible.¶
TRAIN requires processing similar to ECN: network elements recognize opportunities to send signals when they receive packets for forwarding. Sending a signal involves the flipping of a few bits. This is designed to require no state and be as simple as possible to process, such that it could be done easily at line rate. This is a strong reason to limit the expressiveness of the signal: a more complex signal would be harder to apply.¶
SCONE involves establishing state at a network element, with the network element sending a signal any time it chooses. Generating the signal requires the use of an AEAD. In practice, this is likely a few packets for new flows, then a few any time the flow characteristics at the element change.¶
SCONE requires that network elements generate new packets, including spoofing the source IP address. TRAIN only depends on packet modification.¶
SCONE requires that network elements remember an address tuple and client connection ID so that they can provide updates. TRAIN can be processed without any state.¶
SCONE exposes network elements to weird attacks if they don’t maintain additional state. They can be sent SCONE packets without an associated QUIC flow, which might cause the network element to spend effort on sending packets to a spoofed source address. Given spoofed SCONE packets, those generated packets go to a destination of the attacker’s choice. The time frame over which those packets are likely spread means that this is unlikely to be a significant amplification in terms of packet rate. That might make DoS using this vulnerability less appealing, but it is worth noting as it has no upper bound in quantity.¶
There are a few things in SCONE that probably could be improved. None of these really have a bearing on the overall solution.¶
SCONE defines packet protection for the packet that a client sends. Network elements do not need to decrypt or authenticate packets – the information they need from that packet is not protected – but that’s not obvious from the specification.¶
Protection of signals from network elements provides no meaningful security value. The value is in resilience to accidentally interpreting garbage packets as a signal and the AEAD is definitely better than the UDP checksum at detecting transmission errors. However, those same benefits might be realized more cheaply by other means.¶
SCONE packets include a forward bit, which – if set – requests that network elements drop the packet. This requires exceptional processing by a network element, other than simply recognizing the packet. That requirement might take all SCONE packets of the fast path in elements.¶
It seems like the point of this is to enable the targeting of a first-hop network element. However, this assumes that the application of rate limits is done by something on that first network segment. That’s true in a lot of cases, but this is a bad assumption. The same might be more easily achieved by altering the IP TTL instead, with greater targeting precision.¶
Alternatively, this feature might be used to probe whether a path supports SCONE: if a forward=0 packet makes it to the other end, it might feed that information back. Two things though:¶
This feature on its own probably wouldn’t be enough to justify a server implementation.¶
Network elements aren’t required to drop these packets.¶
TRAIN gets this capability for free. An endpoint that receives an unmodified TRAIN packet might infer that the path doesn’t support TRAIN.¶
SCONE insists on a random source connection ID from network elements. To start with, this might cause things to drop the signals if they expect a particular source connection ID. Also, as there is no ongoing communication, this could just swap source and destination connection ID from the original. That would strengthen protection against spoofing (many clients do not use connection IDs for QUIC packets they receive) at a small cost in maintained state. However, any spoofing protection thus gained would not be assured, as there is no minimum entropy for connection IDs in either direction.¶
Requiring this section is perhaps no longer sensible, when due consideration is given to the topic of security throughout, as is the case with this document.¶
This document has no IANA actions.¶
Christian Huitema provided useful feedback, but does not necessarily endorse its message.¶