SYN -> SYN/ACK -> ACK (LOST) - who should retry?

Hi Group

I have the following situation with a POP3 server:

Client sends SYN
Server replies with SYN/ACK
Clinet sends ACK, but this ACK does not make it to the server (due to
whatever reason)

The client now seems to wait for the servers welcome string, but since
the server does not got the ACK, it does not go into established state
and as such the POP3 application protocol obviousely does not start.

Should the server resend a SYN/ACK (kind of unlikely given wide
implementation of SYN cookies right?) or should the client resend the
ACK?

TIA

Markus

Markus Zingg wrote:
[color=blue]
> Hi Group
>
> I have the following situation with a POP3 server:
>
> Client sends SYN
> Server replies with SYN/ACK
> Clinet sends ACK, but this ACK does not make it to the server (due to
> whatever reason)
>
> The client now seems to wait for the servers welcome string, but since
> the server does not got the ACK, it does not go into established state
> and as such the POP3 application protocol obviousely does not start.
>
> Should the server resend a SYN/ACK (kind of unlikely given wide
> implementation of SYN cookies right?) or should the client resend the
> ACK?[/color]

IMHO not retransmitting syn/ack packets will break tcp behaviour. From
RFC793:

The TCP must recover from data that is damaged, lost, duplicated, or
delivered out of order by the internet communication system. This
is achieved by assigning a sequence number to each octet
transmitted, and requiring a positive acknowledgment (ACK) from the
receiving TCP. If the ACK is not received within a timeout
interval, the data is retransmitted.

Syncookies are a problem if the 3rd packet of the tcp handshake is lost:

[url]http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011776.html[/url]

Cheers

Markus

On Sun, 16 Sep 2007 23:18:25 +0200, Markus Rehbach
<Markus.Rehbach@gmx.de> wrote:
[color=blue]
>Markus Zingg wrote:
>[color=green]
>> Hi Group
>>
>> I have the following situation with a POP3 server:
>>
>> Client sends SYN
>> Server replies with SYN/ACK
>> Clinet sends ACK, but this ACK does not make it to the server (due to
>> whatever reason)
>>
>> The client now seems to wait for the servers welcome string, but since
>> the server does not got the ACK, it does not go into established state
>> and as such the POP3 application protocol obviousely does not start.
>>
>> Should the server resend a SYN/ACK (kind of unlikely given wide
>> implementation of SYN cookies right?) or should the client resend the
>> ACK?[/color]
>
>IMHO not retransmitting syn/ack packets will break tcp behaviour. From
>RFC793:
>
> The TCP must recover from data that is damaged, lost, duplicated, or
> delivered out of order by the internet communication system. This
> is achieved by assigning a sequence number to each octet
> transmitted, and requiring a positive acknowledgment (ACK) from the
> receiving TCP. If the ACK is not received within a timeout
> interval, the data is retransmitted.
>
>Syncookies are a problem if the 3rd packet of the tcp handshake is lost:
>
>[url]http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011776.html[/url]
>
>Cheers
>
>Markus[/color]

This to 100% describes the situation here. Thanks. I have to
investigate then what syncache is...

Markus

On Sep 16, 6:48 am, Markus Zingg <m.zi...@nct.ch> wrote:[color=blue]
> Hi Group
>
> I have the following situation with a POP3 server:
>
> Client sends SYN
> Server replies with SYN/ACK
> Clinet sends ACK, but this ACK does not make it to the server (due to
> whatever reason)
>
> The client now seems to wait for the servers welcome string, but since
> the server does not got the ACK, it does not go into established state
> and as such the POP3 application protocol obviousely does not start.
>
> Should the server resend a SYN/ACK (kind of unlikely given wide
> implementation of SYN cookies right?) or should the client resend the
> ACK?[/color]

A SYN or FIN is treated as data. If you send data and do not get an
ACK, you must retransmit the data. So the server has failed to
retransmit its SYN.

The problem is that the initial SYN could be forged. Responding with
multiple packets breaks the rules required to avoid magnification
attacks.

I think this is an inherent flaw in TCP with no good fix.

DS

Markus Rehbach <Markus.Rehbach@gmx.de> writes:
[color=blue]
> Syncookies are a problem if the 3rd packet of the tcp handshake is lost:
>
> [url]http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011776.html[/url][/color]

How did *that* get missed?

Anyway, I think the solution is for SYN cookies to be send in a SYN
packet *without* an ACK. I'm pretty sure TCP could handle it, and I
think the SYN cookie defense itself would still work, but lord knows
how many implementations would choke on a SYN reply with no ACK. Too
late to fix it now, though, with millions of SYN cookie
implementations already out in the field....

-don

In article <uejgxck5r.fsf@comcast.net>,
don provan <dprovan@comcast.net> writes:[color=blue]
> Markus Rehbach <Markus.Rehbach@gmx.de> writes:
>[color=green]
>> Syncookies are a problem if the 3rd packet of the tcp handshake is lost:
>>
>> [url]http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011776.html[/url][/color]
>
> How did *that* get missed?
>
> Anyway, I think the solution is for SYN cookies to be send in a SYN
> packet *without* an ACK. I'm pretty sure TCP could handle it, and I
> think the SYN cookie defense itself would still work,[/color]

I played with this back when SYN cookies were new. Sending a SYN without
an ACK emulates a simultaneous connection, something which TCP is supposed
to handle. The nice thing about this approach is that the other side will
retransmit all of its TCP options so there is no need to encode these in
the cookie.
[color=blue]
> but lord knows
> how many implementations would choke on a SYN reply with no ACK.[/color]

If memory serves me well the MS TCP stack of that era (W95 ?) went
bananas and other stacks worked.
[color=blue]
> Too
> late to fix it now, though, with millions of SYN cookie
> implementations already out in the field....
>[/color]

The problem is not the millions of SYN cookie implementations, but the
millions of dumb firewalls that do not recognize a SYN without ACK as
a simultaneous connection.

In article <uejgxck5r.fsf@comcast.net>, [email]dprovan@comcast.net[/email] (don provan) writes:
| Markus Rehbach <Markus.Rehbach@gmx.de> writes:
|
| > Syncookies are a problem if the 3rd packet of the tcp handshake is lost:
| >
| > [url]http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011776.html[/url]
|
| How did *that* get missed?

Was it really missed or was it just considered acceptable collateral
damage?

| Anyway, I think the solution is for SYN cookies to be send in a SYN
| packet *without* an ACK. I'm pretty sure TCP could handle it, and I
| think the SYN cookie defense itself would still work, but lord knows
| how many implementations would choke on a SYN reply with no ACK.

To the initiator of the connection this is going to look like a
concurrent connect attempt. We already know that a lot of older
implementations didn't get that right. Perhaps worse, stateless
firewalls that block "incoming" connections will likely drop the
ACKless SYN packet. Clever stateful firewalls might drop it as
well on general correctness principles. After all, how can the
server be "responding" with a SYN while not being able to ack the
thing to which it is responding?

Dan Lanciani
ddl@danlan.*com

Markus Zingg wrote:
[color=blue]
> Should the server resend a SYN/ACK (kind of unlikely given wide
> implementation of SYN cookies right?) or should the client resend the
> ACK?[/color]

Syncache, syncookies ....... there is an informational RFC-4987 out since
August named 'TCP SYN Flooding Attacks and Common Mitigations'.

On Sep 17, 9:19 pm, ddl@danlan.*com (Dan Lanciani) wrote:
[color=blue]
> Was it really missed or was it just considered acceptable collateral
> damage?[/color]

Exactly. It's one of the reasons implementations only switch to SYN
cookies when it is necessary to preserve availability.

DS