Netdev List
 help / color / mirror / Atom feed
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 --]

             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