On Sat, Apr 17, 2021 at 12:45 AM 赵亚 <zhaoya.ga...@bytedance.com> wrote: > > On Fri, Apr 16, 2021 at 7:52 PM Eric Dumazet <eduma...@google.com> wrote: > > > > On Fri, Apr 16, 2021 at 12:52 PM zhaoya <zhaoya.ga...@bytedance.com> wrote: > > > > > > When syncookie is triggered, since $MSSID is spliced into cookie and > > > the legal index of msstab is 0,1,2,3, this gives client 3 bytes > > > of freedom, resulting in at most 3 bytes of silent loss. > > > > > > C ------------seq=12345-------------> S > > > C <------seq=cookie/ack=12346-------- S S generated the cookie > > > [RFC4987 Appendix A] > > > C ---seq=123456/ack=cookie+1-->X S The first byte was loss. > > > C -----seq=123457/ack=cookie+1------> S The second byte was received and > > > cookie-check was still okay and > > > handshake was finished. > > > C <--------seq=.../ack=12348--------- S acknowledge the second byte. > > > > > > I think this has been discussed in the past : > > https://kognitio.com/blog/syn-cookies-ate-my-dog-breaking-tcp-on-linux/ > > > > If I remember well, this can not be fixed "easily" > > > > I suspect you are trading one minor issue with another (which is > > considered more practical these days) > > Have you tried what happens if the server receives an out-of-order > > packet after the SYN & SYN-ACK ? > > The answer is : RST packet is sent, killing the session. > > > > That is the reason why sseq is not part of the hash key. > > Yes, I've tested this scenario. More sessions do get reset. > > If a client got an RST, it knew the session failed, which was clear. However, > if the client send a character and it was acknowledged, but the server did not > receive it, this could cause confusion. > > > > In practice, secure connexions are using a setup phase where more than > > 3 bytes are sent in the first packet. > > We recommend using secure protocols over TCP. (prefer HTTPS over HTTP, > > SSL over plaintext) > > Yes, i agree with you. But the basis of practice is principle. > Syncookie breaks the > semantics of TCP. > > > > Your change would severely impair servers under DDOS ability to really > > establish flows. > > Would you tell me more details. > > > > Now, if your patch is protected by a sysctl so that admins can choose > > the preferred behavior, then why not... > > The sysctl in the POC is just for triggering problems easily. > > So the question is, when syncookie is triggered, which is more important, > the practice or the principle?
SYNCOOKIES have lots of known limitations. You can disable them if you need. Or you can add a sysctl or socket options so that each listener can decide what they want. I gave feedback of why your initial patch was _not_ good. I think it can render a server under DDOS absolutely unusable. Exactly the same situation than _without_ syncookies being used. We do not want to go back to the situation wed had before SYNCOOKIES were invented. I think you should have put a big warning in the changelog to explain that you fully understood the risks. We prefer having servers that can still be useful, especially ones serving 100% HTTPS traffic. Thank you.
