TCP Connection tracking and SYN/ACK/PSH

TCP Connection tracking and SYN/ACK/PSH

[NIIBE Yutaka]

I got a problem with netfilter connection tracking for TCP.
Kernel version is 2.6.9 (of Debian sarge).

Linux 2.6 cannot connect to (a version of) MELCO Wireless Print
Server.  It is because MELCO Wireless Print Server responds SYN/ACK/PSH, 
when it gets SYN.  And Linux connection tracking for TCP cannot handle
SYN/ACK/PSH.

I found that there is a discussion about SYN/ACK/PSH:
http://www.linuxforum.com/forums/index.php?s=6af41cf69e81a2cde189f6b7168ed535&showtopic=137778&st=0&#entry600234

It seems that it is same issue.

I attach (formatted) output of tcpdump at the end of this message.
Please note the packets with flags SP and ack.

The model of MELCO Wireless Print Server was:
-------------------------------
Server Name    :  WS-363251
Server Model   :  LPV2-WS11GC
F/W Version    :  0.10
-------------------------------

The iptables were:
-------------------------------
# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            icmp echo-reply 
ACCEPT     icmp --  anywhere             anywhere            icmp destination-unreachable 
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
ACCEPT     icmp --  anywhere             anywhere            icmp time-exceeded 
ACCEPT     udp  --  anywhere             anywhere            udp spt:netbios-ns dpts:1024:65535 

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
-------------------------------

I think that the protocol stack of MELCO Wireless Print Server is
broken or at least, unusual.  But following patch fixes this issue...

--- net/ipv4/netfilter/ip_conntrack_proto_tcp.c~	2004-10-19 06:55:29.000000000 +0900
+++ net/ipv4/netfilter/ip_conntrack_proto_tcp.c	2005-04-17 18:06:10.000000000 +0900
@@ -754,6 +754,7 @@ static u8 tcp_valid_flags[(TH_FIN|TH_SYN
 {
 	[TH_SYN]			= 1,
 	[TH_SYN|TH_ACK]			= 1,
+	[TH_SYN|TH_PUSH|TH_ACK]		= 1,
 	[TH_RST]			= 1,
 	[TH_RST|TH_ACK]			= 1,
 	[TH_RST|TH_ACK|TH_PUSH]		= 1,
------------

Here is the output of tcpdump, 192.168.2.5 is Linux box,
192.168.2.70 is MELCO server.
-------------------------------
16:55:10.649183 IP (tos 0x10, ttl  64, id 26625, offset 0,
		flags [DF], length: 60)
	192.168.2.5.34139 > 192.168.2.70.telnet:
	S [tcp sum ok] 1185703014:1185703014(0) win 5840
	<mss 1460,sackOK,timestamp 277089383 0,nop,wscale 2>
16:55:10.657457 IP (tos 0x0, ttl  30, id 5214, offset 0,
		flags [none], length: 44)
	192.168.2.70.telnet > 192.168.2.5.34139:
	SP [tcp sum ok] 8419755:8419755(0) ack 1185703015 win 1024 <mss 1024>
16:55:11.829212 IP (tos 0x0, ttl  30, id 5215, offset 0,
		flags [none], length: 44)
	192.168.2.70.telnet > 192.168.2.5.34139:
	SP [tcp sum ok] 8419755:8419755(0) ack 1185703015 win 1024 <mss 1024>
16:55:13.648646 IP (tos 0x10, ttl  64, id 26627, offset 0,
		flags [DF], length: 60)
	192.168.2.5.34139 > 192.168.2.70.telnet:
	S [tcp sum ok] 1185703014:1185703014(0) win 5840
	<mss 1460,sackOK,timestamp 277092383 0,nop,wscale 2>
16:55:13.655225 IP (tos 0x0, ttl  30, id 5216, offset 0,
		flags [none], length: 40)
	192.168.2.70.telnet > 192.168.2.5.34139:
	. [tcp sum ok] 1:1(0) ack 1 win 1024
16:55:13.836717 IP (tos 0x0, ttl  30, id 5217, offset 0,
		flags [none], length: 44)
	192.168.2.70.telnet > 192.168.2.5.34139:
	SP [tcp sum ok] 8419755:8419755(0) ack 1185703015 win 1024 <mss 1024>
16:55:15.839199 IP (tos 0x0, ttl  30, id 5218, offset 0,
		flags [none], length: 44)
	192.168.2.70.telnet > 192.168.2.5.34139:
	SP [tcp sum ok] 8419755:8419755(0) ack 1185703015 win 1024 <mss 1024>
16:55:19.647731 IP (tos 0x10, ttl  64, id 26629, offset 0,
		flags [DF], length: 60)
	192.168.2.5.34139 > 192.168.2.70.telnet:
	S [tcp sum ok] 1185703014:1185703014(0) win 5840
	<mss 1460,sackOK,timestamp 277098383 0,nop,wscale 2>
16:55:19.655215 IP (tos 0x0, ttl  30, id 5220, offset 0,
		flags [none], length: 40)
	192.168.2.70.telnet > 192.168.2.5.34139:
	. [tcp sum ok] 1:1(0) ack 1 win 1024
16:55:19.837037 IP (tos 0x0, ttl  30, id 5222, offset 0,
		flags [none], length: 44)
	192.168.2.70.telnet > 192.168.2.5.34139:
	SP [tcp sum ok] 8419755:8419755(0) ack 1185703015 win 1024 <mss 1024>
16:55:27.830395 IP (tos 0x0, ttl  30, id 5228, offset 0,
		flags [none], length: 44)
	192.168.2.70.telnet > 192.168.2.5.34139:
	SP [tcp sum ok] 8419755:8419755(0) ack 1185703015 win 1024 <mss 1024>
16:55:31.645907 IP (tos 0x10, ttl  64, id 26631, offset 0,
		flags [DF], length: 60)
	192.168.2.5.34139 > 192.168.2.70.telnet:
	S [tcp sum ok] 1185703014:1185703014(0) win 5840
	<mss 1460,sackOK,timestamp 277110383 0,nop,wscale 2>
16:55:31.657868 IP (tos 0x0, ttl  30, id 5231, offset 0,
		flags [none], length: 40)
	192.168.2.70.telnet > 192.168.2.5.34139:
	. [tcp sum ok] 1:1(0) ack 1 win 1024
16:55:43.834948 IP (tos 0x0, ttl  30, id 5239, offset 0,
		flags [none], length: 44)
	192.168.2.70.telnet > 192.168.2.5.34139:
	SP [tcp sum ok] 8419755:8419755(0) ack 1185703015 win 1024 <mss 1024>
-------------------------------
-- 

Re: TCP Connection tracking and SYN/ACK/PSH

[Henrik Nordstrom]

On Sun, 17 Apr 2005, NIIBE Yutaka wrote:

> Linux 2.6 cannot connect to (a version of) MELCO Wireless Print
> Server.  It is because MELCO Wireless Print Server responds SYN/ACK/PSH,
> when it gets SYN.  And Linux connection tracking for TCP cannot handle
> SYN/ACK/PSH.

Just a small note to support this: SYN+ACK+PSH is a perfectly valid flags 
combination, even more so if there actually is data enclosed in the 
SYN+ACK (which is valid, only a little odd).

There is not really any good reason why conntrack should care in detail 
about the PSH flag. Most if not all valid flag combinations are good both 
with and without PSH (even SYN).

Regards
Henrik

Re: TCP Connection tracking and SYN/ACK/PSH

[Phil Oester]

On Mon, Apr 18, 2005 at 03:34:41AM +0200, Henrik Nordstrom wrote:
> Just a small note to support this: SYN+ACK+PSH is a perfectly valid flags 
> combination, even more so if there actually is data enclosed in the 
> SYN+ACK (which is valid, only a little odd).
> 
> There is not really any good reason why conntrack should care in detail 
> about the PSH flag. Most if not all valid flag combinations are good both 
> with and without PSH (even SYN).

Given that nmap's Xmas tree scan uses an invalid PSH flag combination to scan
for open ports, I'd suggest conntrack should care about the flag.

While the particular combination being seen here is likely always harmless,
perhaps netfilter should only allow RFC-defined handshakes as a general
rule.

Phil

Re: TCP Connection tracking and SYN/ACK/PSH

[Tim Burress]

Henrik Nordstrom wrote:

> Just a small note to support this: SYN+ACK+PSH is a perfectly valid 
> flags combination, even more so if there actually is data enclosed in 
> the SYN+ACK (which is valid, only a little odd).
>
> There is not really any good reason why conntrack should care in 
> detail about the PSH flag. Most if not all valid flag combinations are 
> good both with and without PSH (even SYN).

We recently had a similar issue, and initially I thought it was overly 
paranoid for Netfilter to mark these segments invalid, but after some 
digging I've changed my mind. The problem is that, even though there is 
no statement in the standards classifying SYN/ACK/PSH itself as invalid, 
the operation that PSH demands -- immediate transmission to the 
application -- is explicitly forbidden during the handshake [RFC 793, 
pg. 30]. In any other protocol, a request to perform a prohibited 
operation would, I think, be considered invalid, so in the end I think 
Netfilter is doing the right thing, inconvenient as it may be for a few 
devices.

In our case the device was a Panasonic WJ-NT104 interface/server for 
network cameras. Apparently there is an embedded TCP/IP stack making the 
rounds in Japan that sets the PSH flag on *every* segment. Panasonic's 
technical support have not yet replied to queries about the issue, but 
we're hoping they will issue a firmware upgrade to fix the problem. In 
the meantime, we modified our rules to allow INVALID traffic to/from the 
device. Obviously it's not ideal, but it gets the job done. If Panasonic 
is unable/unwilling to fix the TCP behavior, we would probably patch 
Netfilter to clear the PSH flag when it occurs in combination with SYN. 
That way we could accept the traffic without allowing invalid segments 
through to hosts on the other side.

Tim

Re[2]: TCP Connection tracking and SYN/ACK/PSH

[Maciej Soltysiak]

Hello Tim,

Wednesday, April 20, 2005, 3:30:31 AM, you wrote:
> the meantime, we modified our rules to allow INVALID traffic to/from the
> device. Obviously it's not ideal, but it gets the job done. If Panasonic
> is unable/unwilling to fix the TCP behavior, we would probably patch
> Netfilter to clear the PSH flag when it occurs in combination with SYN.
I guess this is material for a FAQ item...
And maybe for the INCOMPATIBILITIES file that sits around in /iptables

> Tim
Maciej

Re: TCP Connection tracking and SYN/ACK/PSH

[Henrik Nordstrom]

On Wed, 20 Apr 2005, Tim Burress wrote:

> explicitly forbidden during the handshake [RFC 793, pg. 30]. In any other 
> protocol, a request to perform a prohibited operation would, I think, be 
> considered invalid, so in the end I think Netfilter is doing the right thing, 
> inconvenient as it may be for a few devices.

I am of a slightly different opinion. These segments is not invalid (only 
odd) and won't cause any disturbance to the TCP protocol as long as the 
standard on how to process received segments is followed.

I am of the opinion that as long as the traffic is not explicitly 
violating the protocol conntrack should track it. Stricter checking 
belongs in a separate match such as unclean if desired imho.

Regards
Henrik

Re: TCP Connection tracking and SYN/ACK/PSH

[Tim Burress]

Hello!

Henrik Nordstrom wrote:

> On Wed, 20 Apr 2005, Tim Burress wrote:
>
>> explicitly forbidden during the handshake [RFC 793, pg. 30]. In any 
>> other protocol, a request to perform a prohibited operation would, I 
>> think, be considered invalid, so in the end I think Netfilter is 
>> doing the right thing, inconvenient as it may be for a few devices.
>
>
> I am of a slightly different opinion. These segments is not invalid 
> (only odd) and won't cause any disturbance to the TCP protocol as long 
> as the standard on how to process received segments is followed.
>
> I am of the opinion that as long as the traffic is not explicitly 
> violating the protocol conntrack should track it. Stricter checking 
> belongs in a separate match such as unclean if desired imho.

I think the segments are invalid (or at least in-something), but I agree 
with your second point. Since PSH has no bearing on TCP connection 
state, it seems like it might be better to treat PSH the same way as ECE 
and CWR, and have conntrack ignore it. Other layers could then decide 
whether to accept or drop combinations like SYN+ACK+PSH depending on how 
strictly they want to enforce protocol conventions in the firewall. It's 
not so much a question of whether the segments are valid or not as 
whether strict protocol enforcement (beyond what is needed for 
connection tracking) is really conntrack's job. And since I didn't 
design it, I'm not sure!

Tim

Re: TCP Connection tracking and SYN/ACK/PSH

[Jozsef Kadlecsik]

Hi,

On Fri, 22 Apr 2005, Tim Burress wrote:

> I think the segments are invalid (or at least in-something), but I agree
> with your second point. Since PSH has no bearing on TCP connection
> state, it seems like it might be better to treat PSH the same way as ECE
> and CWR, and have conntrack ignore it. Other layers could then decide
> whether to accept or drop combinations like SYN+ACK+PSH depending on how
> strictly they want to enforce protocol conventions in the firewall. It's
> not so much a question of whether the segments are valid or not as
> whether strict protocol enforcement (beyond what is needed for
> connection tracking) is really conntrack's job. And since I didn't
> design it, I'm not sure!

The sole task of conntrack is to keep track of the connections :-),
however it may flag packets as invalid (or even drop directly) in order to
preserve its sanity. It should not protect the communicating parties from
sending illegal packets, as far as the packets can be tracked. Such
protection should be configured in the raw/filter tables.

Patrick, could you submit NIIBE Yutaka's patch, which started this thread?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: TCP Connection tracking and SYN/ACK/PSH

[Patrick McHardy]

Jozsef Kadlecsik wrote:
> Patrick, could you submit NIIBE Yutaka's patch, which started this thread?

Sure, I'll pass it on to Dave this weekend.

Regards
Patrick