2

If a server receives a fresh SYN packet for a connection that is already established, what should it do?

I have already seen What will happen at server side if it received 2 SYN packet from the same client application?. The example there covers a different case: a server receiving a duplicate previous session SYN before the 'correct' SYN. In that case, the server SYNACK's the wrong session back to the client, which then RSTs the bad session.

The answer does briefly mention this alternative case, but doesn't cover the details:

If the SYN at line 6 had arrived before the RST, a more complex exchange might have occurred with RST's sent in both directions.

What exactly happens in that more complex case? Does the server reply with a RST immediately, or re-ack the existing session, or something else?

More specifically, what happens here:

    TCP A                                                TCP B

1.  CLOSED                                               LISTEN

2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED

3.  SYN-SENT    <-- <SEQ=400><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED

4.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>      --> ESTABLISHED

5.              ... <SEQ=200><CTL=SYN>               --> ???

                              ???
  • 2
    For questions like this, you should always go to the source: RFC 793 – Ron Trunk Aug 31 at 13:16
  • @RonTrunk 100% agree, but the above quote that doesn't fully specify this is originally from that RFC. I'm not clear from the RFC exactly what the correct 'more complex' behaviour that it's referencing is. – Tim Perry Aug 31 at 13:42
1

I did some more reading, and I found an equivalent case that's covered in more detail elsewhere in the RFC, under "Half-Open Connections and Other Anomalies".

After TCP A crashes, the user attempts to re-open the connection. TCP B, in the meantime, thinks the connection is open:


      TCP A                                           TCP B

  1.  (CRASH)                               (send 300,receive 100)

  2.  CLOSED                                           ESTABLISHED

  3.  SYN-SENT --> <SEQ=400><CTL=SYN>              --> (??)

  4.  (!!)     <-- <SEQ=300><ACK=100><CTL=ACK>     <-- ESTABLISHED

  5.  SYN-SENT --> <SEQ=100><CTL=RST>              --> (Abort!!)

  6.  SYN-SENT                                         CLOSED

  7.  SYN-SENT --> <SEQ=400><CTL=SYN>              -->

                     Half-Open Connection Discovery

                               Figure 10.

When the SYN arrives at line 3, TCP B, being in a synchronized state, and the incoming segment outside the window, responds with an acknowledgment indicating what sequence it next expects to hear (ACK 100). TCP A sees that this segment does not acknowledge anything it sent and, being unsynchronized, sends a reset (RST) because it has detected a half-open connection. TCP B aborts at line 5.

The rules that cause this are described in more detail later on:

If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state.

So, to explicitly answer my original question: when an unexpected SYN arrives, its sequence number will be outside the connection window and it will lack the appropriate ack number for the existing connection, so the server should (re)send an ACK confirming the existing connection state, and not ack or handle the unexpected packet at all.

| improve this answer | |
  • That is actually different than what you have in the question. Remember that in real life, a host will establish multiple connections between it and the peer on the other end. Your question deals with an established connection, then another SYN, but your answer is dealing with a half-open connection. You are trying to compare two completely different things. – Ron Maupin Aug 31 at 15:22
  • 1
    The connection is 'half-open' only in that in the described example the client has crashed, silently lost its connection state, and sent a fresh SYN from scratch. There's no FIN packet, and from the server's point of view, it's still firmly ESTABLISHED. I'm fairly confident that the traffic on the wire is byte-identical to any other unexpected SYN, this is just one example of how such a SYN packet could appear. If there is a separate case, how would the packets differ? – Tim Perry Aug 31 at 16:26
  • 1
    I think perhaps you've misunderstood my question somewhere? I've added a comment on the other answer to clarify that part. Here the RFC explicitly describes a peer in the ESTABLISHED state for a connection, which then receives a new SYN packet for the same connection. I think that's exactly "what will happen if a server receives a duplicate SYN for an existing connection". I'm very very interested if there are other series of TCP states & packets that describe similar behaviour (I'd love to see an example sequence!) but I don't think opening a separate connection is it. – Tim Perry Aug 31 at 17:06
  • 1
    I appreciate you're trying to help, but you're not, and you're ignoring what I'm saying. My question is not about intentional separate 2nd connections. A half-open connection like as described here is a real example of how the packets shown in my question could happen, so it's very relevant. I even included a packet sequence in the question that the sequence in the quote here follows from! The RFC quote here also fully describes the general rule, which is unrelated to half-open connections, and answers the question explicitly. – Tim Perry Aug 31 at 17:39
  • 1
    My question is asking for more detail about a specific series of packets on a single conection, quoted directly from the RFC's description of an error scenario. It's clearly not a correctly opened new connection. I'm going to leave now, this is not a constructive discussion. – Tim Perry Aug 31 at 17:58
1

That happens all the time in order for a host to establish multiple connections to another host (remember that TCP does not have clients or servers; client/server is an application layer concept that is off-topic here). As RFC 793, Transmission Control Protocol explains:

The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection.

Because you have a new SYN with a different sequence number, you are creating a new connection. Things like web browsers regularly do that in order to get different parts of a web page to load at the same time.

All your example is doing is trying to create a second connection.


Edit based on your comments and answer:

The sequence of events in your question cannot be in the same connection because you have a different initial sequence number. As it explains in the RFC quote above in my answer, the sequence number is a critical part of the connection, and you are changing the initial sequence number, so it cannot be part of the same connection. The only possible explanations are that this is a new connection, which is common, or the host has a bad TCP implementation or there is some programming on the host that is purposely trying to mess up TCP, neither of those are on topic or part of the TCP protocol theory.

If the next SYN was part of the same connection, it must have the same initial sequence number, meaning your question would be the same question as the question you linked. A different initial sequence number means it is a different connection, and that happens just about every time you load a web page.

Your answer actually deals with a different question, which is about a half-open connection. Your question, based on its sequence of events, is actually about a fully open connection, and the host starting a new connection.

The TCP protocol theory is on-topic here, but a question asking an extra-theoretical question is off-topic. What a buggy host-specific implementation (a proper TCP implementation would not have a different initial sequence number for the same connection), or a purposeful attempt to disrupt TCP, does is something for a different SE site (either a host OS-specific site or Information Security).

| improve this answer | |
  • 1
    I think that's only true if the new SYN packet comes from a different source port, right? Browsers use different outgoing sockets, for example. If not, it is the same connection. I think the sentence after your quote implies this: "Each connection is uniquely specified by a pair of sockets identifying its two sides". – Tim Perry Aug 31 at 13:38
  • To send a SYN with a different sequence number (randomly chosen), the source host would need to try to create a new connection with a different ephemeral port number. TCP will not use a different initial sequence number for the same connection. – Ron Maupin Aug 31 at 13:40
  • I agree, it's incorrect client behaviour. Nonetheless, it's clearly possible to send a new SYN packet with the same source & target as an existing establish socket, either by error or maliciously. What should the server do in that case? – Tim Perry Aug 31 at 13:43
  • It would still be a different connection. As the RFC explains, the connection depends on several factors, including the sequence number. The destination host will see it as a different connection because the initial sequence number is different. – Ron Maupin Aug 31 at 13:46
  • 1
    I want to add a note on this, since I think we're talking past each other. This answer is not correct. A TCP connection is identified only & uniquely by source & destination port & address (4 values). The other values are part of the connection, but do not identify it. Thus a packet with the same ports & addresses but a new sequence value is an invalid packet on the same connection. See stackoverflow.com/a/3329672/68051 or books.google.com/…. If this weren't true, it would be impossible to handle missing/duplicate packets. – Tim Perry Aug 31 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.