Mailing List Archive

TCP MSS CLAMPING issue
Dear experts,
I have tcp adjust-mss configured on an internet link with an ISP like
following:

interface GigabitEthernet0/0/0
description internet WAN link
ip address x.x.x.x 255.255.255.252
ip tcp adjust-mss 1436


During DDOS attacks our firewall starts SYN challenge (acting as a proxy)
and I see sniffing traffic over the WAN link that MSS is not adjusted
accordingly from the router.

I suspect the current Cisco implementation does not change MSS because the
syn-ack does not contain the MSS option.

Questions:
1) do you know if this is the correct behavior ? I do not find
anything official (ASR1k IOS 16.3.7) on www.cisco.com... in case please
share the URL
2) any suggestion if there is a way to set the MSS on ASR1k when not
received in the syn-ack from the server...

The impact is that then the client do not reduce the segment and at the end
the issue come once certificate is being exchanged in the TLS session...

Thanks in advance

Cheers
James
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: TCP MSS CLAMPING issue [ In reply to ]
Hi,

On Sun, Jan 23, 2022 at 05:10:42PM +0100, james list wrote:
> I suspect the current Cisco implementation does not change MSS because the
> syn-ack does not contain the MSS option.

If there is no MSS option, nothing can be adjusted - one would need extra
code to *add* such an option, which is more complex than "change one
number and adjust the checksum".

So, get your firewall vendor to fix their SYN-ACK-spoofing code.

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@greenie.muc.de
Re: TCP MSS CLAMPING issue [ In reply to ]
Hi Gert
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. "

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.

What do you think ?

Cheers



Il giorno dom 23 gen 2022 alle ore 17:40 Gert Doering <gert@greenie.muc.de>
ha scritto:

> Hi,
>
> On Sun, Jan 23, 2022 at 05:10:42PM +0100, james list wrote:
> > I suspect the current Cisco implementation does not change MSS because
> the
> > syn-ack does not contain the MSS option.
>
> If there is no MSS option, nothing can be adjusted - one would need extra
> code to *add* such an option, which is more complex than "change one
> number and adjust the checksum".
>
> So, get your firewall vendor to fix their SYN-ACK-spoofing code.
>
> 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@greenie.muc.de
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: TCP MSS CLAMPING issue [ In reply to ]
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@greenie.muc.de
Re: TCP MSS CLAMPING issue [ In reply to ]
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@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@greenie.muc.de
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: TCP MSS CLAMPING issue [ In reply to ]
Hi,

On Sun, Jan 23, 2022 at 06:58:29PM +0100, james list wrote:
> > 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.

Well. You could have direct connections to those AntiDDoS providers,
thus, no MTU issue. Or they could fragment inside the GRE tunnels,
or send ICMP packet too big back to the sender.

Lots of ways to deal with "reduced MTU" in IPv4 land, if you must have
a segment with reduced MTU.

We do not use AntiDDoS providers that can only do GRE, so, no, not
"all companies with a name". We have a direct handoff (using a DECIX
virtual service with 1500 MTU).

(Why does your firewall go into "must use SYN/ACK spoofing mode!!!" if
you have a DDoS provider in the path that should be dealing with that?)

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

This is The Internet. You will find any sort of non-compliant implementation
out there - and by deviating from commonly established behaviour ("send a
MSS value in SYN/ACK") you're triggering code paths in client implementations
that are less tested, and might be just buggy. Or rely on interface MTU
and PMTU detection (= ICMP packet too big).

But you can't fix the clients. They are what they are.

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@greenie.muc.de