From: Paul Fiterau Brostean <p.fiterau-brostean@science.ru.nl>
To: netdev@vger.kernel.org
Subject: Inconsistency in ipv4/tcp_input regarding sequence number acceptability condition
Date: Mon, 22 May 2017 17:24:55 +0200 [thread overview]
Message-ID: <f209ec7a-7d14-0112-e906-69c016298aa5@science.ru.nl> (raw)
[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]
Hello esteemed Linux Developers,
My name is Paul, I am a PhD student. I sent a different question a while
back to the netdev mailing list, and never got a response. This question
should be a lot easier to address. While doing experiments on the Linux
TCP stack as part of a research project, I have stumbled upon a
potential inconsistency with the RFC specification.
The Linux TCP stack considers a received sequence number as in-window or
acceptable, if the sequence number of the segment is between the
expected sequence number and the expected sequence number plus the size
of the receive window. Naturally, the lower bound is included in the
range. What's a bit weird is that the upper bound of this range is also
considered in-window. This is evident both from my experiments and from
the code
(http://elixir.free-electrons.com/linux/v4.11/source/net/ipv4/tcp_input.c#L3985).
The RFC states that the upper bound shouldn't be considered. If we look
at: https://tools.ietf.org/html/rfc793#page-26 the acceptability
conditions exclude RCV.NXT+RCV.WND (where applicable). Is there a
reason for Linux including the upper bound? Or can this be fixed?
Analyzing FreeBSD, they seem to have adopted the RFC standard, and have
not included the upper bound.
As an aside, my work involves automatic inference of models from
software components. We obtained models for FreeBSD and Linux TCP
clients and comparing them we were able to spot this minor difference.
The models we can obtain automatically abstract away from many
complexities (like timing, re-transmissions), and only consider socket
calls and flags/seq/ack numbers (payloads are 0). I attached a Linux
model to give you an example. If you look at the ESTABLISHED state,
receiving a RST segment (R), prompts the Linux system to respond with a
challenge ACK segment (A) if the sequence number (p1) satisfies the
condition: 'r1+win >=p1 && r1<p1' where 'r1' is the expected sequence
number and 'win' is the receive window size.
Thanks for your attention, Paul.
[-- Attachment #2: linux_model.pdf --]
[-- Type: application/pdf, Size: 216985 bytes --]
next reply other threads:[~2017-05-22 15:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 15:24 Paul Fiterau Brostean [this message]
2017-05-22 17:00 ` Inconsistency in ipv4/tcp_input regarding sequence number acceptability condition Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f209ec7a-7d14-0112-e906-69c016298aa5@science.ru.nl \
--to=p.fiterau-brostean@science.ru.nl \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox