TCP Fast Open? Not so fast(blog.apnic.net)
blog.apnic.net
TCP Fast Open? Not so fast
https://blog.apnic.net/2021/07/05/tcp-fast-open-not-so-fast/
20 comments
It’s a tricky issue to track down because it only adds latency on the first request to a new domain.
And the wonderful issues that can come with it sometimes. Although I suspect much less now that large responses are more common.
Back in the day a very popular registrar that included DNS service would have random issues with the size of DNS response when it switched over to TCP, returning servfail instead of answer.
I'm guessing it was a load balanced cluster and some of the servers were broken. We reported the issue a few times but never heard back, as expected.
Back in the day a very popular registrar that included DNS service would have random issues with the size of DNS response when it switched over to TCP, returning servfail instead of answer.
I'm guessing it was a load balanced cluster and some of the servers were broken. We reported the issue a few times but never heard back, as expected.
I ran a survey in 2017 and found that around 0.1% of the DNS servers we poked at would negotiate TFO and of those around 94% were Google's. It might be interesting to take another look at the deployment numbers at some point.
https://irl.xyz/stuff/pubs/PATHspiderEvolution2017.pdf
https://irl.xyz/stuff/pubs/PATHspiderEvolution2017.pdf
The author complains about slow adoption, lack of documentation and incomplete implementations of TFO.
But RFC7413 which describes TFO (https://datatracker.ietf.org/doc/html/rfc7413) still has an experimental status. This thing is not expected to be widely supported or work as production-quality feature, yet:
> Status of This Memo
> This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
But RFC7413 which describes TFO (https://datatracker.ietf.org/doc/html/rfc7413) still has an experimental status. This thing is not expected to be widely supported or work as production-quality feature, yet:
> Status of This Memo
> This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
I don't know if things have changed, but the Internet I grew up on was built entirely on RFCs with that status.
For a dns server this is irrelevant, but what impact do these cookies have on privacy if I'd use it while browsing? And how long are these cookies meant to be valid for? To have a speed-up effect, it needs to be long enough to cover two separate website visits, but to preserve privacy you might argue the requirement is exactly the opposite.
I would be curious if anyone knows if a scheme like Zcash was considered. No, not another shitcoin, it's from 1983 and uses RSA blind signatures:
> Blind signatures can also be used to provide unlinkability, which prevents the signer from linking the blinded message it signs to a later un-blinded version that it may be called upon to verify. In this case, the signer's response is first "un-blinded" prior to verification in such a way that the signature remains valid for the un-blinded message.
I guess the issue would be too large signature sizes are needed for RSA, and that the verification operation is asymmetrically slower than what a client has to do, leading to a denial of service attack? Maybe the server could have (configurably) a per-IP limit of, for example, 4 opens per 20 seconds (bursty) and a global limit of 10% of CPU time as measured over 10 seconds. Above those limits, clients just have to do a 3WHS as usual or re-use connections if the protocol allows (http does).
I'm probably overthinking this but without blind signatures, it seems like no browser would enable it for privacy reasons. Technically it's illegal to use this for tracking without a reason (such as user consent or fraud protection or so), but that won't stop everyone from doing it.
I would be curious if anyone knows if a scheme like Zcash was considered. No, not another shitcoin, it's from 1983 and uses RSA blind signatures:
> Blind signatures can also be used to provide unlinkability, which prevents the signer from linking the blinded message it signs to a later un-blinded version that it may be called upon to verify. In this case, the signer's response is first "un-blinded" prior to verification in such a way that the signature remains valid for the un-blinded message.
I guess the issue would be too large signature sizes are needed for RSA, and that the verification operation is asymmetrically slower than what a client has to do, leading to a denial of service attack? Maybe the server could have (configurably) a per-IP limit of, for example, 4 opens per 20 seconds (bursty) and a global limit of 10% of CPU time as measured over 10 seconds. Above those limits, clients just have to do a 3WHS as usual or re-use connections if the protocol allows (http does).
I'm probably overthinking this but without blind signatures, it seems like no browser would enable it for privacy reasons. Technically it's illegal to use this for tracking without a reason (such as user consent or fraud protection or so), but that won't stop everyone from doing it.
QUIC/HTTP/3 has a similar 0-RTT handshake that also leaves a privacy hole if used. Same for TLS/1.2/1.3 resume tickets.
All of those are fairly irrelevant because they don't give more information than first party cookies, first party cache presence or cache content...
I suspect the privacy advocates aren't looking deep enough in the stack...
All of those are fairly irrelevant because they don't give more information than first party cookies, first party cache presence or cache content...
I suspect the privacy advocates aren't looking deep enough in the stack...
TCP Fast Open has one difference that the cookie is system wide. So opening a Private Browsing window won't help.
They are between pairs of IP addresses ... so they contain the same information as the IP adress does.
But the server could theoretically add/save more information... like linking it to a user session.
Has anyone seen a good code example of sending server response data in a SYN+ACK packet on Linux? Last time I tried it didn't seem to work - I could only get data in the client's SYN, the server sends an empty SYN+ACK. Perhaps I'm mistaken in what Fast Open is mean to allow.
TCP_DEFER_ACCEPT is probably what you're looking for (SO_ACCEPTFILTER on BSD/macos) :
https://github.com/paraboul/libapenetwork/blob/6e5acac08467b...
https://github.com/paraboul/libapenetwork/blob/6e5acac08467b...
I don't think TCP_DEFER_ACCEPT does that - "Allow a listener to be awakened only when data arrives on" it just changes the timing of accept()? What you describe sounds more like TCP_CORK, but I don't think that'll work.
Looking a bit more at the network stack perhaps the SYN+ACK is sent straight from the SYN handler with no chance for userspace to pack any data in.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Edit: Ah, you are right about TCP_DEFER_ACCEPT putting data in the ACK on the client side, I'd forgotten about that. https://lore.kernel.org/netdev/CAK3+h2ydKQ15U1_2dqWsHAL_LKYm...
Looking a bit more at the network stack perhaps the SYN+ACK is sent straight from the SYN handler with no chance for userspace to pack any data in.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Edit: Ah, you are right about TCP_DEFER_ACCEPT putting data in the ACK on the client side, I'd forgotten about that. https://lore.kernel.org/netdev/CAK3+h2ydKQ15U1_2dqWsHAL_LKYm...
Oops my bad, indeed.
I wonder why client and server software needs to opt-in to TFO and it isn't just handled transparently by the kernel? Perhaps with a sysctl flag to enable or disable it globally.
There's a chance of a server receiving duplicate data from SYN packets, which some applications won't tolerate.
https://datatracker.ietf.org/doc/html/rfc7413#section-2.1
There are some extra tcp_fastopen sysctl values that do enable it transparently.
https://datatracker.ietf.org/doc/html/rfc7413#section-2.1
There are some extra tcp_fastopen sysctl values that do enable it transparently.
On the client side, unless the client knows about TFO it's not going to be set up to send data with the initial connection - it's going to use the standard BSD sockets flow of connect(); send();. To usefully use TFO you need to replace the connect() with a sendto() using MSG_FASTOPEN that requests sending of the data you want to send with the SYN.
It occurs to me that using TFO effectively with a TLS library like OpenSSL would be difficult.
Timely, I just updated our pdns recursors to the latest version yesterday and was staring at that config line. I think I'll hold off for a few months.
I did not know that was a thing!
https://serverfault.com/questions/698251/how-does-the-dns-pr...