[Scone] Re: New draft: scone-echo

[Lucas Pardue <[e-mail]>]

On Wed, Apr 22, 2026, at 02:59, Martin Duke wrote:
> Hi Lucas,
> 
> Replies inline.
> 
> On Tue, Apr 21, 2026 at 2:00 PM Lucas Pardue <[e-mail]> wrote:
>> __
>> I'm trying to get my head around the privacy considerations on this. The wording seems to suggest that a client QUIC implementation would, for an easy time, enable the echoing if a server advertised it. That seems to lower the barrier significantly to server "scanners" building up a detailed view of network topology with the need to expend much effort.
> 
> This is worth thinking about, though I don't believe the scone-protocol draft discusses network scanning at all. In fact Sec 10.1 says "QUIC implementations are therefore encouraged to make the feature available unconditionally. Endpoints might send SCONE packets whenever a peer can accept them.", which this draft would amplify.
Yeah, I won't profess to be an expert in core SCONE but the proposal in SCONE-Echo seems it might shift the stakes a bit from: client advertises support to receive and consume with some implied user consent invoked when crossing the transport->app layer, to: server can harvest information without application binding context to the consent. 

For example, if a client side API was available to access SCONE information in a browser, we might imagine it to be modelled around the approach in the Network Information API [1]. In particular, the Interface section defines some fields that might be used to echo information from the client to the server, with the statement 

> They can do that via the Client Hints infrastructure defined in [CLIENT-HINTS <https://wicg.github.io/netinfo/#bib-client-hints>] and bound by the processing model defined in [CLIENT-HINTS-INFRASTRUCTURE <https://wicg.github.io/netinfo/#bib-client-hints-infrastructure>].

Those docs describe some privacy considerations [3]. Some of which might not be relevant to this proposal. For instance, by only allowing a single connection to report information only about it's own connection, you narrow some of the cross origin concerns. 

Conversely, by pushing this so far down the stack, it would seem to be trivial for any party to gather SCONE information with minimal user context. Imagine a web page on example.org that gets some malicious JavaScript injected that connects to phonehome.net. Upon establishing a connection to it, SCONE echo allows a server to probe the client's path for SCONE information without having to do much other than send PING frames.

The client hints approach quoted above builds upon a sequence of interactions that attempt to address same origin and cross origin matters. Although I won't claim that its perfect.

To summarise, SCONE's concerns about consent to _receive_ data seems slightly different to SCONE echo's concerns about consent to beacon that data.

 
>  
>> 
>> Separately, its not 100% clear to me how many SCONE_ECHO frames are expected to be sent. Is it one per packet? If so, this risks being an attack vector where the remote endpoint spams small packets and 
>> refuses to acknowledge SCONE_ECHO frames, which could cause a backlog of retransmissions. Similar to some of the issues Martin Seemann disclosed a couple if years ago.
> 
> Can you point me to that disclosure? I'm having trouble seeing immediately how this is worse than not acknowledging data from an HTTP request, etc, though I'm sure there's something I'm missing. I'm happy to file an issue about it and add the appropriate mitigations.
> 
> But yes, once per packet.

Thanks for the clarification. I wont claim to have done a deep security analysis of your proposal but its probably worth reading Marten's blog post on DoS via CID management frame backlog [4]. The crux of the issue is that the attacker can manipulate the victim to respond with mandatory frames, together with the victim's ability to actually respond.

The difference with HTTP, to my mind at least, is that implementations already tend to have protections in place for monitoring state commitments to individual requests. For instance, the size of buffers or duration of a transaction. 

Marten's blog explores some of the potential mitigations. One difference with SCONE echo, I _think_, is that the QUIC-layer requirements to respond do not depend on the peers authenticated packet payload. Just the presence of a packet. This might make it easier to exploit. A more defensive approach might be to require the peer to actively request SCONE information and add flow control so the local endpoint has fine-grain control over the number of such requests that can be issued at any one time. 

Cheers
Lucas

[1] https://wicg.github.io/netinfo
[2] https://wicg.github.io/netinfo/#networkinformation-interface
[3] https://wicg.github.io/netinfo/#privacy-considerations
[4] https://seemann.io/posts/2024-03-19---exploiting-quics-connection-id-management/
>  
>> 
>> Cheers
>> Lucas
>> 
>> On Tue, Apr 21, 2026, at 21:39, Sri Gundavelli (sgundave) wrote:
>>> Hi Martin,
>>>  
>>> Thanks for writing this document. This was the missing piece.
>>>  
>>>  
>>> BR!
>>> Sri
>>>  
>>>  
>>> 
>>> Cisco Confidential
>>> 
>>> *From: *Martin Duke <[e-mail]>
>>> *Date: *Tuesday, April 21, 2026 at 1:28 PM
>>> *To: *"[e-mail]" <[e-mail]>
>>> *Cc: *Ian Swett <ianswett=[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
>>> *Subject: *[Scone] New draft: scone-echo
>>>  
>>> Hello SCONE,
>>>  
>>> I've published a new internet-draft:
>>> https://datatracker.ietf.org/doc/draft-duke-scone-scone-echo/
>>>  
>>> Basically, it's a QUIC extension to report bandwidth advice back to the SCONE sender in a QUIC frame. We have some edge cases where the sender can do useful things with this advice but the receiving application is unable to cooperate. See the intro for a somewhat more thorough discussion of that.
>>>  
>>> The relevant chairs/AD agreed this should sit in SCONE and not QUICWG, although it may need a recharter.
>>>  
>>> Anyway, if this interests you, take a look and file issues in the github <https://github.com/martinduke/scone-echo>.
>>>  
>>> Thanks,
>>> Martin
>>> _______________________________________________
>>> Scone mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>> 
>>