Re: [PATCH] tcp: fix silent loss when syncookie is trigered

Re: [PATCH] tcp: fix silent loss when syncookie is trigered

[Eric Dumazet]

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...

Re: [External] Re: [PATCH] tcp: fix silent loss when syncookie is trigered

[赵亚]

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?

Re: [External] Re: [PATCH] tcp: fix silent loss when syncookie is trigered

[Eric Dumazet]

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.