121–130 of 246 posts
Earlier quoted context omitted.
There are less than 100 Internet Standards ( https://www.rfc-editor.org/standards ).
With hindsight, it's kind of funny that 8 of them are about telnet.
After all the TCP and UDP specific attacks (SYN Floods and Reflection-Amplification), I am really curious which QUIC-specific DoS attacks will be created by some talented hackers. At least the security considerations of the QUIC RFC are ~18 pages long, so this might take some time.
† What WireGuard does here is just ignore everything that doesn't authenticate. This makes diagnostics tricky. Why doesn't it work? No idea. Maybe try again?
Earlier quoted context omitted.
Curious, why isn't it numbered the other way? My programming brain is telling me that if you're reading rfc9000 you can't reference rfc9001 because it hasn't been initialized yet. :D
It's in a lot of ways more about not being defined (but possibly declared) yet, rather than initialized. You'd be super sad if you could not reference a function defined later in a source file. Yeah, I'm absolutely great at parties!
Would you? Most of the environments I'm in requires you to define the thing before you can use it, I'm not that sad about that. In fact, that seems to make a lot more sense than that you can define something after you use it, I'd expect that to lead to a compiler/interpreter error.
Earlier quoted context omitted.
It's in a lot of ways more about not being defined (but possibly declared) yet, rather than initialized. You'd be super sad if you could not reference a function defined later in a source file. Yeah, I'm absolutely great at parties!
> You'd be super sad if you could not reference a function defined later in a source file. Would you? Most of the environments I'm in requires you to define the thing before you can use it, I'm not that sad about that. In fact, that seems to make a lot more sense than that you can define something after you use it, I'd expect that to lead to a compiler/interpreter error.
Earlier quoted context omitted.
The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…
> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.
I am still wondering, isn't TCP hardware accelerated? Maybe QUIC would also mean the CPU working harder, but I'm not really sure. I would be nice to have a thoughtful conversation about the security implication of QUIC: Wikipedia says packets are encrypted individually. I'm also curious: is QUIC exclusively aimed towards HTTP2 or can it be used for real time applications, like real time gaming or video conferencing?
> QUIC was developed through a collaborative and iterative standardization process at the IETF after almost five years, 26 face-to-face meetings, 1,749 issues, and many thousands of emails. 26 face-to-face meeting in 5 years is an extremely low number; I'm glad to see that the developers of the Internet embrace remote work :)
Earlier quoted context omitted.
The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…
> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.
>NAT
Oh, didn't you know, IPv6 was going to solve everything. No more NAT. We're just going to assign everyone an IP at birth so people can continue to ignore the User-Agent/User distinction.
Earlier quoted context omitted.
Is QUIC really worthy of the over 9000 meme? I can’t help but feel we wasted a once in a lifetime opportunity.
To be used as 9000 meme it should have been "over 9000" https://en.wikipedia.org/wiki/It%27s_Over_9000 !
Earlier quoted context omitted.
I would start by: - Not allocating giant slices of IPv6/4 space to corporations or government agencies. Everything must be IPv6. - Adding proper authentication to BGP. - Taking off the super powers of CAs - Not piling up standards on DNS. - Killing ICANN because it turned out to be a greedy senseless organization. - HTTPS is the standard, and email servers just follow the auth/encryption just like HTTPS. - Curve/Ed25…
Well, I expected more radical/foundational changes than "upgrade to $modern standards" :P e.g change TCP to $YOLO PROTOCOL, get rid of OSI for something different
1. Change the order of the header fields to have the destination first, then the source;
2. Make the behavior on too large packets be "truncate but still forward" (setting a flag saying this was done), instead of fragmenting or dropping with an ICMP message.