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 <[email protected]> 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 > [email protected] > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
