SYN/ACK/PSH

Hello,

Recently I noticed that in connecting to a web server on a remote
system, the server is responding to my SYN with SYN/ACK/PSH. Netfilter
considers this an invalid combination (which it is, sort of), so the
packet is dropped by my firewall:

2005-04-05 11:33:19 ip_conntrack_tcp: INVALID: invalid TCP flag
combination SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=44 TOS=0x00
PREC=0x00 TTL=52 ID=62896 PROTO=TCP SPT=80 DPT=36211 SEQ=1053431614
ACK=69666177 WINDOW=11680 RES=0x00 ACK PSH SYN URGP=0 OPT (02040578)

I'm looking at ways to deal with this on my side, but I just wondered
if other people have seen this problem? Does anyone know what operating
system(s) respond to a SYN with SYN/ACK/PSH?

It seems like it must be something really unusual or I would have seen
this before.

Thanks!

<gg-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...

> Recently I noticed that in connecting to a web server on a remote
> system, the server is responding to my SYN with SYN/ACK/PSH. Netfilter
> considers this an invalid combination (which it is, sort of), so the
> packet is dropped by my firewall:

I think your firewall is broken or misconfigured. I can see no reason
why this is illegal.

DS

Illegal, hmmm... No, not so much illegal as nonsensical, and from a
couple of different points of view:

(1) There is no data piggybacked on the SYN/ACK, so PSH is pointless.

(2) RFC 793 requires data piggybacked on handshake segments to be
buffered and not delivered to the application until the connection is
ESTABLISHED. Thus, PSH at this time makes no sense.

I think the firewall is doing the right thing, though it may be the
case that Netfilter is being a little overly conservative. Also note
that no OS we know of exhibits this behavior... I suspect it may be an
embedded server on a small device and the implementors took what they
thought was the easy way out by setting PSH on everything. But I*d sure
like to know for sure!

Anyway thanks for your note. It made me go look at the RFC.

G

<gg-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...

> I think the firewall is doing the right thing, though it may be the
> case that Netfilter is being a little overly conservative. Also note
> that no OS we know of exhibits this behavior... I suspect it may be an
> embedded server on a small device and the implementors took what they
> thought was the easy way out by setting PSH on everything. But I*d sure
> like to know for sure!

Should a firewall filter non-standard things when it's clear what they
mean and that they're harmless?

DS

David Schwartz wrote:
> Should a firewall filter non-standard things when it's clear what
they
> mean and that they're harmless?

Perhaps there is some confusion. Netfilter is marking the segments
invalid because they have a nonsensical combination of TCP flags. But
it marks segments invalid for other reasons as well, such as bad
checksums, incorrect TCP state transitions, window errors, etc. The
firewall, which lives at a higher layer, sees only that the segment is
invalid, and has no way of knowing exactly which criteria a segment
failed. Still, given the range of possible problems, I think dropping
it is the right thing to do.

You could argue that Netfilter is being overly conservative when it
marks such segments invalid, but that is a slippery slope. I think
deciding with certainty what a given set of nonstandard flags means,
and whether they are harmless for all possible recipient hosts, is
nontrivial. But in any case it appears that the design decision was to
be restrictive about what would be accepted, and probably the best
place to argue about that would be netfilter-devel.

Really what I'm after here is to see if anyone else has seen TCP stacks
that respond in this way, and if they can identify them.

Thanks!

G

<gg-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...

> You could argue that Netfilter is being overly conservative when it
> marks such segments invalid, but that is a slippery slope. I think
> deciding with certainty what a given set of nonstandard flags means,
> and whether they are harmless for all possible recipient hosts, is
> nontrivial. But in any case it appears that the design decision was to
> be restrictive about what would be accepted, and probably the best
> place to argue about that would be netfilter-devel.

They are not invalid and their meaning is well-defined. They are
non-standard in the sense that most systems don't generate them, but they're
not non-standard in the sense that they're not defined by a standard. The
meaning of the flags is defined by the TCP standard.

DS

The meaning of the individual flags is well-defined, and the meaning of
some combinations are well-defined, but there are a large number of
combinations that are not defined at all.

What does PSH on a SYN/ACK with no piggybacked data mean? Given that
the most charitable interpretation is that it's pointless, does it mean
that the stack designer was lazy? Or could it mean that a scanner is
trying to slip packets through to a host behind the firewall? Or is it
an attempt to crash some version of Windows (there must be one) that
dies if you send it that particular combination? Who can say?

But in any case, we seem to be drifting toward one of those Usenet
discussions where the main topic is lost and focus shifts to a side
issue. If you feel strongly about this, it would probably be best to
raise it with the Netfilter development team. My primary interest at
this point is just trying to identify the OS sending that combination.
Any ideas?

G

gg-(E-Mail Removed) wrote:
> Hello,
>
> Recently I noticed that in connecting to a web server on a remote
> system, the server is responding to my SYN with SYN/ACK/PSH. Netfilter
> considers this an invalid combination (which it is, sort of), so the
> packet is dropped by my firewall:
>
> 2005-04-05 11:33:19 ip_conntrack_tcp: INVALID: invalid TCP flag
> combination SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=44 TOS=0x00
> PREC=0x00 TTL=52 ID=62896 PROTO=TCP SPT=80 DPT=36211 SEQ=1053431614
> ACK=69666177 WINDOW=11680 RES=0x00 ACK PSH SYN URGP=0 OPT (02040578)
>
> I'm looking at ways to deal with this on my side, but I just wondered
> if other people have seen this problem? Does anyone know what operating
> system(s) respond to a SYN with SYN/ACK/PSH?
>
> It seems like it must be something really unusual or I would have seen
> this before.
>

Would you please identify the system or give an URL?

IMHO, this is proper behaviour: the segment is a relative
of the nastygram alias Christmas tree segment.

--

Tauno Voipio
tauno voipio (at) iki fi

<gg-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...

> The meaning of the individual flags is well-defined, and the meaning of
> some combinations are well-defined, but there are a large number of
> combinations that are not defined at all.

The combination doesn't have to be deifined.

> What does PSH on a SYN/ACK with no piggybacked data mean?

The same thing PSH means on any other datagram, that any data should be
passed to the application on the other side immediately. If there is no
data, it means nothing. Since PSH is requires in some cases and prohibited
in none, it could just mean that the stack always sets the PSH bit.

> Given that
> the most charitable interpretation is that it's pointless, does it mean
> that the stack designer was lazy?

It could, since the PSH bit is not prohibited under any circumstances.

> Or could it mean that a scanner is
> trying to slip packets through to a host behind the firewall? Or is it
> an attempt to crash some version of Windows (there must be one) that
> dies if you send it that particular combination? Who can say?

If you want to reject perfectly valid packets on the grounds that they
might trigger bugs you aren't aware of, then don't be surprised when you
fail to interoperate with some hosts.

> But in any case, we seem to be drifting toward one of those Usenet
> discussions where the main topic is lost and focus shifts to a side
> issue. If you feel strongly about this, it would probably be best to
> raise it with the Netfilter development team. My primary interest at
> this point is just trying to identify the OS sending that combination.
> Any ideas?

I don't feel strongly about it. You make your choices and you pay the
price. If you choose to reject some perfectly valid combinations of flags
because you've never seen them, then you can't complain when you fail to
interoperate.

DS

Hi David,

David Schwartz wrote:
> The same thing PSH means on any other datagram, that any data should
be
> passed to the application on the other side immediately. If there is
no
> data, it means nothing. Since PSH is requires in some cases and
prohibited
> in none, it could just mean that the stack always sets the PSH bit.

Yes, taken out of context, that is what PSH means. But context matters,
and in the context of SYN/ACK, the operation being requested by setting
the PSH flag is explicitly forbidden.

> > Given that
> > the most charitable interpretation is that it's pointless, does it
mean
> > that the stack designer was lazy?
>
> It could, since the PSH bit is not prohibited under any
circumstances.

You seem to be confusing the bit with what the bit means. Given that
the operation requested by the bit is prohibited during the handshake,
I think it's appropriate for Netfilter to mark the segment invalid.
Your mileage may vary.

But if you or anyone else happens to know of an OS or embedded TCP
stack that exhibits this behavior, please let me know.

Thanks!

G