[c-nsp] TCP MSS CLAMPING issue

[james list]

hi

> It's "the Internet".  Pointing at clients as being "non compliant" is
> not going to fix your server's operation - otherwise, all this fiddling
> with TCP/MSS would not even be necessary in the first place.

> (Another option would be, of course, to fix your network :-) - so 1500
> byte packets can get through, and no need to reduce the client's MSS)

I guess that nowadays almost all the companies (with a name) rely upon
antiDDOS systems using GRE hence I'm wondering why you say we need to fix
something on our side.

If there are RFC (=law) I'd expect those are followed, otherwise you cannot
complain, am I wrong ?

James





Il giorno dom 23 gen 2022 alle ore 18:37 Gert Doering <gert at greenie.muc.de>
ha scritto:

> Hi,
>
> On Sun, Jan 23, 2022 at 06:31:40PM +0100, james list wrote:
> > thanks for the feedback.
> >
> > Firewall vendor reports this:
> >
> > " When
> > SYN Cookies
> >  is activated, the firewall does not honor the TCP options that the
> server
> > sends because it does not know these values at the time that it proxies
> the
> > SYN/ACK. Therefore, values such as the TCP server???s window size and MSS
> > values cannot be negotiated during the TCP handshake and the firewall
> will
> > use its own default values. In the scenario where the MSS of the path to
> > the server is smaller than the firewall???s default MSS value, the packet
> > will need to be fragmented.  "
>
> It does not have to know what the server would send to always put in an
> MSS option of its own...  (but of course the vendor would tell you
> "this is not our fault").
>
> > Here we see the client seems not RFC compliant, since in RFC6691 (
> > https://datatracker.ietf.org/doc/html/rfc6691#appendix-A) is written:
> >
> > "If an MSS option is not received at connection setup, TCP MUST  assume a
> > default send MSS of 536 (576-40) [TCP:4]."
> >
> > As recap:
> >
> > 1) during no attack client send MSS 1460 with DF=1, server respond
> through
> > MSS 1436 (due to GRE), client uses 1436, connection is established
> > correctly with TLS exchange
> > 2) during attack client send MSS 1460 with DF = 1, server (=firewall in
> > this phase due to syn-challenge) respond without MSS, client uses 1460,
> TLS
> > exchange is broken
> >
> > From my point of view, since RFC6691 state "MUST use 536", the customer
> is
> > not compliant.
>
> It's "the Internet".  Pointing at clients as being "non compliant" is
> not going to fix your server's operation - otherwise, all this fiddling
> with TCP/MSS would not even be necessary in the first place.
>
> (Another option would be, of course, to fix your network :-) - so 1500
> byte packets can get through, and no need to reduce the client's MSS)
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
>  feed honest figures into a computer, honest figures come out. Never
> doubted
>  it myself till I met a computer with a sense of humor."
>                              Robert A. Heinlein, The Moon is a Harsh
> Mistress
>
> Gert Doering - Munich, Germany
> gert at greenie.muc.de
>