* Re: [PATCH] tcp: fix silent loss when syncookie is trigered [not found] <20210416105142.38149-1-zhaoya.gaius@bytedance.com> @ 2021-04-16 11:52 ` Eric Dumazet 2021-04-16 22:45 ` [External] " 赵亚 0 siblings, 1 reply; 3+ messages in thread From: Eric Dumazet @ 2021-04-16 11:52 UTC (permalink / raw) To: zhaoya.gaius Cc: David Miller, Hideaki YOSHIFUJI, netdev, LKML, Florian Westphal On Fri, Apr 16, 2021 at 12:52 PM zhaoya <zhaoya.gaius@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. 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) Your change would severely impair servers under DDOS ability to really establish flows. Now, if your patch is protected by a sysctl so that admins can choose the preferred behavior, then why not... ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [External] Re: [PATCH] tcp: fix silent loss when syncookie is trigered 2021-04-16 11:52 ` [PATCH] tcp: fix silent loss when syncookie is trigered Eric Dumazet @ 2021-04-16 22:45 ` 赵亚 2021-04-17 4:58 ` Eric Dumazet 0 siblings, 1 reply; 3+ messages in thread From: 赵亚 @ 2021-04-16 22:45 UTC (permalink / raw) To: Eric Dumazet Cc: David Miller, Hideaki YOSHIFUJI, netdev, LKML, Florian Westphal On Fri, Apr 16, 2021 at 7:52 PM Eric Dumazet <edumazet@google.com> wrote: > > On Fri, Apr 16, 2021 at 12:52 PM zhaoya <zhaoya.gaius@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? ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [External] Re: [PATCH] tcp: fix silent loss when syncookie is trigered 2021-04-16 22:45 ` [External] " 赵亚 @ 2021-04-17 4:58 ` Eric Dumazet 0 siblings, 0 replies; 3+ messages in thread From: Eric Dumazet @ 2021-04-17 4:58 UTC (permalink / raw) To: 赵亚 Cc: David Miller, Hideaki YOSHIFUJI, netdev, LKML, Florian Westphal On Sat, Apr 17, 2021 at 12:45 AM 赵亚 <zhaoya.gaius@bytedance.com> wrote: > > On Fri, Apr 16, 2021 at 7:52 PM Eric Dumazet <edumazet@google.com> wrote: > > > > On Fri, Apr 16, 2021 at 12:52 PM zhaoya <zhaoya.gaius@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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-04-17 4:59 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20210416105142.38149-1-zhaoya.gaius@bytedance.com> 2021-04-16 11:52 ` [PATCH] tcp: fix silent loss when syncookie is trigered Eric Dumazet 2021-04-16 22:45 ` [External] " 赵亚 2021-04-17 4:58 ` Eric Dumazet
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.