Subject: [tcpm] TCP mismatched sequence numbers issue

From: "Agarwal, Anil" <[email-masked]>
Date: Fri, 1 Nov 2013 12:31:47 +0000

Hi All,

Is the following behavior of TCP, relating to mismatched sequence numbers between TCP peers, correct?

Suppose host A opens a TCP connection to host B.

After the connection is successfully opened, let's suppose
that the TCP sequence numbers are as follows -

    A: snd_una = 1, snd_nxt = 1, rcv_nxt = 1
    B: snd_una = 1, snd_nxt = 1, rcv_nxt = 1

Now suppose, that TCP connection A, accidentally or maliciously, changes its
sequence numbers to the following values -
    A: snd_una = -4000, snd_nxt = -4000, rcv_nxt = +4000

(The send sequence number is retracted, the receive sequence number is advanced).

The TCP states at A and B are now -
    A: snd_una = -4000, snd_nxt = -4000, rcv_nxt = 4000
    B: snd_una = 1, snd_nxt = 1, rcv_nxt = 1

Next, A sends an ACK segment to B (or a data segment with < 4000 bytes of data)

    A->B segment: seq = -4000, ack = 4000, datalen < 4000

B, on receiving the segment, rejects the segment data since it
lies outside its receive window and sends an ACK segment back to A.

    B->A segment: seq = 1, ack = 1

    Note that B does not change rcv_nxt or snd_una.
    Even if B processes the ack field (4000), it will reject it as invalid
    and not update snd_una.

A ,on receiving the segment, rejects the segment data since it
lies outside its receive window and sends an ACK segment back to B.

    A->B segment: seq = -4000, ack = 4000

    Note that A does not change rcv_nxt or snd_una.
    Even if A processes the ack field (1), it will reject it as invalid
    and not update snd_una.

And a vicious cycle is started.
Each side sends an ACK packet to each other, at the rate of 1 segment per RTT.

A malicious host A might send a few extra ACK segments, for good measure,
and get multiple segments into the cycle.

The connection terminates after 15-20 minutes.

I have tried this against Linux 2.6.18 and 2.4.20 servers and
have observed the above behavior.
Hosts A and B on a gigabit LAN merrily exchange 40000 ACK segments per second.

Even if A changes either the send or the receive sequence numbers,
it results in the above cycle.
    A: snd_una = -4000, snd_nxt = -4000, rcv_nxt = 1
    or
    A: snd_una = 1, snd_nxt = 1, rcv_nxt = 4000

This behaviour can also occur due to a middle-box C that "spoofs" TCP connections
and TCP sequences numbers. C may use a locally generated iss towards A while B uses its
own iss value.  Subsequently, if A and B communicate directly due to a middle-box failure,
or a route change, similar conditions can arise.

Is the above behavior expected or well-known or did I get something wrong?
If the behavior is expected, then is there a need to detect and break the cycle?

Thanks,
Anil Agarwal
ViaSat Inc.

---

From: [email-masked]
Date: Sun, 3 Nov 2013 12:02:32 +0530 (IST)

Hi:

This behaviour is known and documented in "Simple Active Attack Against
TCP"  available at

https://www.usenix.org/legacy/publications/library/proceedings/security95/full_papers/joncheray.pdf

Pls. see section 2.2, 2.3 and 2.4 in this document (Desynchronised state
and TCP ACK Storm)

Why was the TCP connection terminated after 15-20 minutes. I guess this
might be due to the timeout of application layer protocol that you used in
your experiment. If so, you should be able to observer a consistency in
the timeout, but you mentioned a range of 15-20 minutes.

Regards,

Anil

On Fri, November 1, 2013 6:01 pm, Agarwal, Anil wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

-- 
V Anil Kumar
Principal Scientist
CSIR Fourth Paradigm Institute (CSIR-4PI)
NAL Belur Campus
Bangalore - 560037
E-mail: [email-masked]
Phone: +91 80 2505 1355