Subject: Re: PR #3547: community input needed

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 3 Apr 2020 07:29:18 +0200

Hi Martin, all,

so clearly the right way to solve this problem is #3557, if it needs solving, but it sounds like consensus among you is that it doesn’t need solving enough to do a breaking change to a frame definition at this stage in the game. FWIW this seems right to me.

ISTM Lag is a slightly more elegant solution here than Leak:

- Lag is a smaller tweak to the spec, and doesn’t carry additional connectivity risk (albeit minimal) as Leak does.
- The suggested implementation for Lag may be “cute” (no opinion here), but AIUI the space of possible solutions contains acceptable ways to achieve compliance with the spec + Lag beyond the suggestion. 

Cheers,

Brian

Sent from my iPhone

>> On 3 Apr 2020, at 02:17, Martin Duke <[email-masked]> wrote:
> 
> Hello QUIC,
> 
> We have had an endless discussion on #3547, and Kazuho, MT, and I have gotten to the point where everyone else is exhausted, the decision space is opaque to newcomers, and we're making value judgments about implementer pain. So I'd like to try to extract out the key issue and see if we can get some broader input about these value judgment.
> 
> Issue: in the current spec, there is a legal attack where the attacker sends NEW_CONNECTION_ID at a very high rate, with each frame increasing Retire Prior To enough to remain compliant with the victim's active_connection_id_limit. The victim is required to send a large number of RCIDs, some of which may be lost or not acked. There is essentially unbounded state at the victim to keep track of this, and this state is useless when the peer is not behaving pathologically. (There are other variants of this, but I'll keep it simple)
> 
> We are also trying to do this without breaking changes that make the coming draft-28 incompatible with draft-27, which is why we've ruled out a fix to the wire image that would comprehensively solve the problem.
> 
> We've converged on two tweaks to the spec, which I'll call "the leak" and "the lag".
> 
> "the lag": instead of telling the host to send all RCIDs right away, suggest that it can limit the number of RCIDs it sends per RTT to a small number that can easily fit in a packet. This comment has pseudocode that implements one way to do this where the required state is approximately constant for any number of RCIDs to retire.
> 
> Pro: a very subtle tweak to the spec that doesn't change anything about the contract with the peer -- it already has to handle the possibility that RCIDs might be delayed.
> Con: The low-state pseudocode is a little cute and may not mesh well with existing implementations.
> 
> "the leak": the other approach is to allow hosts in this situation to limit the number of RCIDs it has outstanding to a reasonable number and simply *never send* some RCIDs beyond this limit.
> 
> Pro: This is likely to be easier to retrofit onto existing implementations. It's also conceptually simpler to figure out how to do this while limiting state.
> Con: If the peer never receives some RCIDs, this will eventually starve its ability to provide new ones and may therefore force termination of the connection.
> 
> There is other stuff in here but this is the root of it. If there is a strong signal from the list I think Kazuho and I will stop arguing and ship it.
> 
> Martin Duke