xt_TCPMSS: SYN packets are allowed to contain data
in [Kernel]
|
From: Amos Jeffries on 20 Jan 2010 17:30 On Wed, 20 Jan 2010 21:51:33 +0000, Simon Arlott <simon(a)fire.lp0.eu> wrote: > On 20/01/10 21:41, Jan Engelhardt wrote: >> On Wednesday 2010-01-20 22:39, Jan Engelhardt wrote: >> >>>On Wednesday 2010-01-20 22:21, Simon Arlott wrote: >>> >>>>The TCPMSS target is dropping SYN packets where: >>>> 1) There is data, or >>>> 2) The data offset makes the TCP header larger than >>>> the packet. >>>> >>>>Both of these result in an error level printk. >>>> >>>>This change fixes the drop of SYN packets with data >>>>(because the MSS option can safely be modified) and >>>>passes packets with no MSS option instead of adding >>>>one (which is not valid). >>> >>>Can you explain why the automatic addition of a MSS option is removed? >> >> That is, of course, for the git log. If I followed the thread right, it >> was that adding the option could exceed the MTU. Well, can't we check >> for the outgoing MTU? > > The MSS option is for the MRU of whoever sent the SYN packet. There's no > way of knowing this information so it's not possible to avoid using an > MSS that is too large. With no option, "any" segment size could be used, > which implies 536 to match the MRU of 576. > > The other reason for not being able to add it is that it may increase the > packet size beyond an MRU/MTU limit if there is data. There's no guarantee > we'll see an ICMP error message if this occurs, because the limit doesn't > have to be local and the return path does not need to be the same. The > original host won't know that the packet is going to be increased in size. (I know little, so just my 2c) So... packets are 'tunneled' down a link where MSS is required/added. However packets which will not fit into the MTU of that 'tunnel' are send down it without MSS and without fragmentation? I wonder what would happen if all TCP MTUs worked that way... Maybe I've misunderstood how path MTU discovery works. But is it and TCP not built on the premise that the origin source host always receives the ACKs regardless of reverse route? With PMTU discovery built on that guarantee, to return the ICMP error to the same source the ACK would go? If ICMP is administrively crippled to break TCP its not iptables fault, nor the admin who is using TCP/ICMP correctly to signal available MTU. AYJ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Patrick McHardy on 20 Jan 2010 18:20 Jan Engelhardt wrote: > On Wednesday 2010-01-20 22:39, Jan Engelhardt wrote: > >> On Wednesday 2010-01-20 22:21, Simon Arlott wrote: >> >>> The TCPMSS target is dropping SYN packets where: >>> 1) There is data, or >>> 2) The data offset makes the TCP header larger than >>> the packet. >>> >>> Both of these result in an error level printk. >>> >>> This change fixes the drop of SYN packets with data >>> (because the MSS option can safely be modified) and >>> passes packets with no MSS option instead of adding >>> one (which is not valid). >> Can you explain why the automatic addition of a MSS option is removed? > > That is, of course, for the git log. If I followed the thread right, it > was that adding the option could exceed the MTU. Well, can't we check > for the outgoing MTU? We certainly can, and in fact the packet would get fragmented by the IP layer in case we would exceed the PMTU. Additionally we currently check that the packet contains no data, even with the first version of this patch, so there's no way the packet could exceed the MTU. This feature has been there from day one since the TCPMSS target has been merged and people are using this with knowledge of their MTUs to work around broken ISPs. I'm not apply this. The first version seemed fine to me though :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Simon Arlott on 21 Jan 2010 07:50 On Wed, January 20, 2010 23:14, Patrick McHardy wrote: > Jan Engelhardt wrote: >> On Wednesday 2010-01-20 22:39, Jan Engelhardt wrote: >>> On Wednesday 2010-01-20 22:21, Simon Arlott wrote: >>>> The TCPMSS target is dropping SYN packets where: >>>> 1) There is data, or >>>> 2) The data offset makes the TCP header larger than >>>> the packet. >>>> >>>> Both of these result in an error level printk. >>>> >>>> This change fixes the drop of SYN packets with data >>>> (because the MSS option can safely be modified) and >>>> passes packets with no MSS option instead of adding >>>> one (which is not valid). >>> Can you explain why the automatic addition of a MSS option is removed? >> >> That is, of course, for the git log. If I followed the thread right, it >> was that adding the option could exceed the MTU. Well, can't we check >> for the outgoing MTU? > > We certainly can, and in fact the packet would get fragmented > by the IP layer in case we would exceed the PMTU. Additionally > we currently check that the packet contains no data, even with > the first version of this patch, so there's no way the packet > could exceed the MTU. If DF is set and the MTU is exceeded (for the SYN packet) at a hop further away, the original host will not understand that it needs to allow for the MSS option being added. (Header + Data + New MSS Option) can't exceed 576 bytes and there's no way to know that more than 576 bytes is allowed because the ICMP error message may not go via the same host that is mangling the packet. Of course, it could just allow fragmentation for this one SYN packet but that doesn't work for IPv6. > This feature has been there from day one since the TCPMSS target > has been merged and people are using this with knowledge of their > MTUs to work around broken ISPs. I'm not apply this. The TCPMSS target can be applied to more than just one direction of traffic. I'm modifying incoming traffic too, so adding the MSS option and setting it to over 536 is wrong (although the first ICMP error will fix it). Existing users use this target precisely because their hosts are sending an unwanted MSS value, so it will never need to be added. > The first version seemed fine to me though :) The first version is ok with me. Only SYN packets with data and no MSS option will be dropped. William objects to ever adding the MSS option. Although ideally SYN packets with data and no MSS option should be accepted without adding an option. Dropping arbitrary traffic (especially when new kernels allow data to be sent with SYN packets) is not a good idea. If that is ok with you then I'll make another patch to do it and update the comments. -- Simon Arlott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Engelhardt on 21 Jan 2010 08:00 On Thursday 2010-01-21 13:47, Simon Arlott wrote: > >The TCPMSS target can be applied to more than just one direction >of traffic. I'm modifying incoming traffic too, so adding the MSS >option and setting it to over 536 is wrong (although the first ICMP >error will fix it). > >Existing users use this target precisely because their hosts are >sending an unwanted MSS value, so it will never need to be added. Ah, so they should be using TCPOPTSTRIP ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Patrick McHardy on 21 Jan 2010 08:10 Simon Arlott wrote: > On Wed, January 20, 2010 23:14, Patrick McHardy wrote: >> Jan Engelhardt wrote: >>>> Can you explain why the automatic addition of a MSS option is removed? >>> That is, of course, for the git log. If I followed the thread right, it >>> was that adding the option could exceed the MTU. Well, can't we check >>> for the outgoing MTU? >> We certainly can, and in fact the packet would get fragmented >> by the IP layer in case we would exceed the PMTU. Additionally >> we currently check that the packet contains no data, even with >> the first version of this patch, so there's no way the packet >> could exceed the MTU. > > If DF is set and the MTU is exceeded (for the SYN packet) at a > hop further away, the original host will not understand that it > needs to allow for the MSS option being added. Yes, but we don't add it for SYNs containing data. > (Header + Data + New MSS Option) can't exceed 576 bytes and > there's no way to know that more than 576 bytes is allowed > because the ICMP error message may not go via the same host that > is mangling the packet. > > Of course, it could just allow fragmentation for this one SYN > packet but that doesn't work for IPv6. > >> This feature has been there from day one since the TCPMSS target >> has been merged and people are using this with knowledge of their >> MTUs to work around broken ISPs. I'm not apply this. > > The TCPMSS target can be applied to more than just one direction > of traffic. I'm modifying incoming traffic too, so adding the MSS > option and setting it to over 536 is wrong (although the first ICMP > error will fix it). It might be wrong, but so is dropping ICMP fragmentation required packets. This is a workaround for broken behaviour and you should of course only use MSS values that you know are valid. > Existing users use this target precisely because their hosts are > sending an unwanted MSS value, so it will never need to be added. Its mainly used for ISPs surpressing ICMP fragmentation required messages. That affects hosts not adding an MSS option as well. >> The first version seemed fine to me though :) > > The first version is ok with me. Only SYN packets with data and > no MSS option will be dropped. William objects to ever adding the > MSS option. Well, he's about 10 years late. > Although ideally SYN packets with data and no MSS option should > be accepted without adding an option. Dropping arbitrary traffic > (especially when new kernels allow data to be sent with SYN > packets) is not a good idea. If that is ok with you then I'll > make another patch to do it and update the comments. I agree, it shouldn't drop packets unless it really has to. Please go ahead with a new patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: loan at 2% interest rate Next: cmd64x: fix PIO and MWDMA timings calculations |