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

This is a discussion on SYN -> SYN/ACK -> ACK (LOST) - who should retry? - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

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

  1. 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


  2. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    Markus Zingg wrote:

    > 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?


    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:

    http://lists.freebsd.org/pipermail/f...er/011776.html

    Cheers

    Markus

  3. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    On Sun, 16 Sep 2007 23:18:25 +0200, Markus Rehbach
    wrote:

    >Markus Zingg wrote:
    >
    >> 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?

    >
    >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:
    >
    >http://lists.freebsd.org/pipermail/f...er/011776.html
    >
    >Cheers
    >
    >Markus


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

    Markus


  4. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    On Sep 16, 6:48 am, Markus Zingg wrote:
    > 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?


    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


  5. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    Markus Rehbach writes:

    > Syncookies are a problem if the 3rd packet of the tcp handshake is lost:
    >
    > http://lists.freebsd.org/pipermail/f...er/011776.html


    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

  6. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    In article ,
    don provan writes:
    > Markus Rehbach writes:
    >
    >> Syncookies are a problem if the 3rd packet of the tcp handshake is lost:
    >>
    >> http://lists.freebsd.org/pipermail/f...er/011776.html

    >
    > 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,


    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.

    > but lord knows
    > how many implementations would choke on a SYN reply with no ACK.


    If memory serves me well the MS TCP stack of that era (W95 ?) went
    bananas and other stacks worked.

    > Too
    > late to fix it now, though, with millions of SYN cookie
    > implementations already out in the field....
    >


    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.

  7. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    In article , dprovan@comcast.net (don provan) writes:
    | Markus Rehbach writes:
    |
    | > Syncookies are a problem if the 3rd packet of the tcp handshake is lost:
    | >
    | > http://lists.freebsd.org/pipermail/f...er/011776.html
    |
    | 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

  8. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    Markus Zingg wrote:

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


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

  9. Re: SYN -> SYN/ACK -> ACK (LOST) - who should retry?

    On Sep 17, 9:19 pm, ddl@danlan.*com (Dan Lanciani) wrote:

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


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

    DS


+ Reply to Thread