Hi, David, Christian,
Thank you for your comments.
2021年4月21日(水) 23:48 David Schinazi :
> Hi Kazuho,
>
> First, to confirm: your characterization of compatible VN matches my
> understanding.
>
> Then, on the topic of what we need, let's start with basics. Your point
> that QUICv1 has extension p
I'll note that there are many ways for an attacker to close
a QUIC connection during the handshake:
- send ICMP port unreachable
- send a version negotiation packet with no real versions
- send an initial with a ServerHello of the attacker's choosing
- send a retry with a token of the attacker's ch
Maybe the first question is, do we need to support what you call
"incompatible" version negotiation, i.e., the original design from 4
years ago. It was taken off the spec for a number of reasons, of which I
remember two:
1) VN packets are easy to spoof by ill-intended third parties. We can
pr
Hi Kazuho,
First, to confirm: your characterization of compatible VN matches my
understanding.
Then, on the topic of what we need, let's start with basics. Your point
that QUICv1 has extension points is true,
but we've designed QUIC as a versioned protocol to allow innovation outside
of the confi
Please correct me if I'm wrong, but it seems to me that people are using
"compatible version" as a term to describe packets carrying first-flight
initial data (e.g., ClientHello) using QUIC version X to which servers
might respond with something other than Version Negotiation packets _nor_
QUIC ver
