SYN,URG combination considered INVALID by tcp conntrack

SYN,URG combination considered INVALID by tcp conntrack

[Martijn Posthuma]

We have been experiencing problems with tcp connection establishment  when (for some reason) the URG flag and pointer were set in the SYN segment. The problem did not affect all machines that were contacted but a subset. All affected machines were using netfilter-conntrack and firewalling.
Inspection of the conntrack code (on a 2.6 linux kernel source) reveiled that the above mentioned combination of flags is not considered valid. The code I am referring to is in  nf_conntrack_proto_tcp.c version 2.2, lines 768 to 795:

#define TH_FIN  0x01
#define TH_SYN  0x02
#define TH_RST  0x04
#define TH_PUSH 0x08
#define TH_ACK  0x10
#define TH_URG  0x20
#define TH_ECE  0x40
#define TH_CWR  0x80

/* table of valid flag combinations - ECE and CWR are always valid */
static u8 tcp_valid_flags[(TH_FIN|TH_SYN|TH_RST|TH_PUSH|TH_ACK|TH_URG) + 1] =
{
    [TH_SYN]            = 1,
    [TH_SYN|TH_ACK]         = 1,
    [TH_SYN|TH_PUSH]        = 1,
    [TH_SYN|TH_ACK|TH_PUSH]     = 1,
    [TH_RST]            = 1,
    [TH_RST|TH_ACK]         = 1,
    [TH_RST|TH_ACK|TH_PUSH]     = 1,
    [TH_FIN|TH_ACK]         = 1,
    [TH_ACK]            = 1,
    [TH_ACK|TH_PUSH]        = 1,
    [TH_ACK|TH_URG]         = 1,
    [TH_ACK|TH_URG|TH_PUSH]     = 1,
    [TH_FIN|TH_ACK|TH_PUSH]     = 1,
    [TH_FIN|TH_ACK|TH_URG]      = 1,
    [TH_FIN|TH_ACK|TH_URG|TH_PUSH]  = 1,
};

As you can see the SYN,URG combination is not considered valid. I can not find any justification for this in RFC793. I do realize that it is a rare combination of flags, but legal none the less. (In the RFC there is even a explicit mention of the fact that a SYN segment can contain data, so a URG flag is perfectly feasible in that case).

Does someone know of a good reason that this flag combination is excluded?

-- 
Martijn Posthuma - software engineer Sangine
www.sangine.com t:+32 (0)14 472 576 f:+32 (0)14 472 582

Re: SYN,URG combination considered INVALID by tcp conntrack

[Patrick McHardy]

Martijn Posthuma wrote:
> We have been experiencing problems with tcp connection establishment  when (for some reason) the URG flag and pointer were set in the SYN segment. The problem did not affect all machines that were contacted but a subset. All affected machines were using netfilter-conntrack and firewalling.
> Inspection of the conntrack code (on a 2.6 linux kernel source) reveiled that the above mentioned combination of flags is not considered valid. The code I am referring to is in  nf_conntrack_proto_tcp.c version 2.2, lines 768 to 795:
> 
> [..]
> 
> As you can see the SYN,URG combination is not considered valid. I can not find any justification for this in RFC793. I do realize that it is a rare combination of flags, but legal none the less. (In the RFC there is even a explicit mention of the fact that a SYN segment can contain data, so a URG flag is perfectly feasible in that case).
> 
> Does someone know of a good reason that this flag combination is excluded?

No reason, I've added SYN|URG and SYN|PUSH|URG to the valid flag
combinations, thanks.

Re: SYN,URG combination considered INVALID by tcp conntrack

[Patrick McHardy]

Martijn Posthuma wrote:
>>>Does someone know of a good reason that this flag combination is excluded?
>>
>>No, I guess it should be considered valid. Out of interest, did the
>>SYN packets actually carry data?
> 
> 
> Not in this case (it turned out to be a non initialized variable). We are hoping to be able to do this in the future to ie speed up the restart of a interrupted ftp-session.

Mhh .. we can certainly change it (I don't see any harm in this), but
I don't think you will have much success with this. Linux for example
will simple ignore the data and wait for the sender to retransmit.
According to this comment solaris will even give you an error:


/* Now we have several options: In theory there is
 * nothing else in the frame. KA9Q has an option to
 * send data with the syn, BSD accepts data with the
 * syn up to the [to be] advertised window and
 * Solaris 2.1 gives you a protocol error. For now
 * we just ignore it, that fits the spec precisely
 * and avoids incompatibilities. It would be nice in
 * future to drop through and process the data.
 *
 * Now that TTCP is starting to be used we ought to
 * queue this data.
 * But, this leaves one open to an easy denial of
 * service attack, and SYN cookies can't defend

 * against this problem. So, we drop the data
 * in the interest of security over speed.
 */

Re: SYN,URG combination considered INVALID by tcp conntrack

[Martijn Posthuma]

On Wed, 06 Sep 2006 20:20:58 +0200
Patrick McHardy <kaber@trash.net> wrote:

> Please break your lines at 72 characters ..
> 
> Martijn Posthuma wrote:
> > We have been experiencing problems with tcp connection establishment  when (for some reason) the URG flag and pointer were set in the SYN segment. The problem did not affect all machines that were contacted but a subset. All affected machines were using netfilter-conntrack and firewalling. Inspection of the conntrack code (on a 2.6 linux kernel source) reveiled that the above mentioned combination of flags is not considered valid. The code I am referring to is in  nf_conntrack_proto_tcp.c version 2.2, lines 768 to 795:
> 
> Not sure if I understand you correctly, did the machines running
> connection tracking emit these packets?

Nope, these packets were not accepted on boxes using a statefull firewall. The INPUT filter contained lines like this:
ACCEPT tcp 0.0.0.0/0 0.0.0.0/0 -m state --state ESTABLISHED
ACCEPT tcp 0.0.0.0/0 0.0.0.0/0 --dport 22 -m state --state NEW
The firewall uses the conntrack state to filter packets. A segment containing SYN and URG won't get us a connection in state NEW but INVALID, thus the packet is dropped..

[snip]
> > Does someone know of a good reason that this flag combination is excluded?
> 
> No, I guess it should be considered valid. Out of interest, did the
> SYN packets actually carry data?

Not in this case (it turned out to be a non initialized variable). We are hoping to be able to do this in the future to ie speed up the restart of a interrupted ftp-session.

-- 
Martijn Posthuma - software engineer Sangine
www.sangine.com t:+32 (0)14 472 576 f:+32 (0)14 472 582

Re: SYN,URG combination considered INVALID by tcp conntrack

[Patrick McHardy]

Please break your lines at 72 characters ..

Martijn Posthuma wrote:
> We have been experiencing problems with tcp connection establishment  when (for some reason) the URG flag and pointer were set in the SYN segment. The problem did not affect all machines that were contacted but a subset. All affected machines were using netfilter-conntrack and firewalling. Inspection of the conntrack code (on a 2.6 linux kernel source) reveiled that the above mentioned combination of flags is not considered valid. The code I am referring to is in  nf_conntrack_proto_tcp.c version 2.2, lines 768 to 795:

Not sure if I understand you correctly, did the machines running
connection tracking emit these packets?

> As you can see the SYN,URG combination is not considered valid. I can not find any justification for this in RFC793. I do realize that it is a rare combination of flags, but legal none the less. (In the RFC there is even an explicit mention of the fact that a SYN segment can contain data, so an URG flag is perfectly feasible in that case).
> 
> Does someone know of a good reason that this flag combination is excluded?

No, I guess it should be considered valid. Out of interest, did the
SYN packets actually carry data?

SYN,URG combination considered INVALID by tcp conntrack

[Martijn Posthuma]

We have been experiencing problems with tcp connection establishment  when (for some reason) the URG flag and pointer were set in the SYN segment. The problem did not affect all machines that were contacted but a subset. All affected machines were using netfilter-conntrack and firewalling. Inspection of the conntrack code (on a 2.6 linux kernel source) reveiled that the above mentioned combination of flags is not considered valid. The code I am referring to is in  nf_conntrack_proto_tcp.c version 2.2, lines 768 to 795:

#define TH_FIN  0x01
#define TH_SYN  0x02
#define TH_RST  0x04
#define TH_PUSH 0x08
#define TH_ACK  0x10
#define TH_URG  0x20
#define TH_ECE  0x40
#define TH_CWR  0x80

/* table of valid flag combinations - ECE and CWR are always valid */
static u8 tcp_valid_flags[(TH_FIN|TH_SYN|TH_RST|TH_PUSH|TH_ACK|TH_URG) + 1] =
{
    [TH_SYN]            = 1,
    [TH_SYN|TH_ACK]         = 1,
    [TH_SYN|TH_PUSH]        = 1,
    [TH_SYN|TH_ACK|TH_PUSH]     = 1,
    [TH_RST]            = 1,
    [TH_RST|TH_ACK]         = 1,
    [TH_RST|TH_ACK|TH_PUSH]     = 1,
    [TH_FIN|TH_ACK]         = 1,
    [TH_ACK]            = 1,
    [TH_ACK|TH_PUSH]        = 1,
    [TH_ACK|TH_URG]         = 1,
    [TH_ACK|TH_URG|TH_PUSH]     = 1,
    [TH_FIN|TH_ACK|TH_PUSH]     = 1,
    [TH_FIN|TH_ACK|TH_URG]      = 1,
    [TH_FIN|TH_ACK|TH_URG|TH_PUSH]  = 1,
};

As you can see the SYN,URG combination is not considered valid. I can not find any justification for this in RFC793. I do realize that it is a rare combination of flags, but legal none the less. (In the RFC there is even an explicit mention of the fact that a SYN segment can contain data, so an URG flag is perfectly feasible in that case).

Does someone know of a good reason that this flag combination is excluded?

-- 
Martijn Posthuma - software engineer Sangine
www.sangine.com t:+32 (0)14 472 576 f:+32 (0)14 472 582