Re: [New Issue] CID based attacks

[Dmitri Tikhonov <[e-mail]>]

On Wed, Nov 25, 2020 at 02:29:55PM +0100, Kashyap Thimmaraju wrote:
> I was not part of the mailing list (but I am now :)) when you replied
> so I've had to manually copy your responses. Below I've included the
> person's name and replied to their comments/remarks.
> 
> > Dmitri Tikhonov
> > I ran some experiments myself and I realized that my original guess was
> > incorrect.  lsquic server retires the Initial DCID a short time after
> > handshake succeeds.  When a CID is retired, all incoming packets bearing
> > it are dropped.
> >
> > lsquic keeps CIDs retired for at least 30 seconds and at most forever
> > (old entries are purged opportunistically when new entries are added.)
> 
> Good to know. We did some experiments and it seemed to persist for over a
> day.  However, we did not try to connect with other CIDs so that could
> explain why they remained for so long.

Yes, that's exactly how it happened.  The underlying data structure's FIFO
component drops old entries after some threshold is reached.

> > I looked for guidance in the Transport Draft for how long a CID is to
> > stay retired (both Initial DCID and those retired via the
> > RETIRE_CONNECTION_ID frame), but found none.
> 
> So for lsquic, the problem is about a CID being stuck in the retired state?

Yes: there was no upper limit on the amount of time that a CID was retired.
This has been fixed in lsquic 2.24.4 [1].

Thank you again!

  - Dmitri.
     
1. https://github.com/litespeedtech/lsquic/releases/tag/v2.24.4