Re: [quicwg/base-drafts] Handling of duplicate packets (#1405)

[Kazuho Oku <[e-mail]>]

@gloinul 
>> As discussed in #1439 (comment), my understanding is that the ECN support in the form proposed in #1372 is the only issue that makes duplicate detection a requirement rather than an option.
> 
> So, do I assume correctly, that you will still throw away packets that are several RTTs old, i.e. that have a PN number older than any state? Or do you generate an ACK for that old packet that is so old, and try to find if there is any unconsumed buffers to put any data in?

My argument is that doing either would be fine.

> I looked through the frame types and the only ones that I think have some impact are:
> * Path_Challenge: A non duplication detecting receiver, will issue two Path_Response frames in response to a single PN. The sender of the Path_Challenge should not react badly to this.

My understanding is that the following statement in the transport draft section 5 covers this: "All QUIC frames are idempotent. That is, a valid frame does not cause undesirable side effects or errors when received more than once."

> I would note that AES-GCM do have this weakness (Fergueson http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf) that if one manage to know that one successfully forged a packet so that it passed the authentication verification, then one learns a number of bits of the authentication key, making the next forgery simpler. If it is possible to run such an attack by sending modified duplicates with forged authentication tags resulting in a response, then this can be exploited (https://link.springer.com/chapter/10.1007/978-3-319-31517-1_7)

If such attack is possible, it would be a vulnerability of the AEAD algorithm. It would be unrelated to if we detect duplicates. It is the task of the AEAD to provide authentication.

> I also noted that when we discussed this at the Interim it appeared that most, if not all except @kazuho was thinking that duplication suppression was expected in the receiver. If this is not required, then think the actual requirements on each frame type individually needs to be very clear.

My understanding is that the discussion was based on our understanding (at that point) that duplication detection on the receiver is a prerequisite for ECN to work, and that we did not agree on how strictly we should require that to be implemented on the receiver.

Considering that, I think that it would be fair to argue for looking into if duplication detection is actually required, considering the fact that now we now that ECN can be supported without it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1405#issuecomment-398041417