From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Fiterau Brostean Subject: Inconsistency in ipv4/tcp_input regarding sequence number acceptability condition Date: Mon, 22 May 2017 17:24:55 +0200 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------06F8F3F168CEE82038D7C66D" To: netdev@vger.kernel.org Return-path: Received: from tortel.science.ru.nl ([131.174.16.137]:46994 "EHLO tortel.science.ru.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935334AbdEVPeE (ORCPT ); Mon, 22 May 2017 11:34:04 -0400 Received: from smtp2.science.ru.nl (smtp2.science.ru.nl [131.174.16.145]) by tortel.science.ru.nl (8.14.4/5.32) with ESMTP id v4MFOx3k019444 for ; Mon, 22 May 2017 17:24:59 +0200 Received: from [145.116.174.129] (ip-145-116-174-129.wlan-int.ru.nl [145.116.174.129]) (authen=pfiteraubrostean) by smtp2.science.ru.nl (8.14.4/5.32) with ESMTP id v4MFOuNp027334 for ; Mon, 22 May 2017 17:24:57 +0200 Sender: netdev-owner@vger.kernel.org List-ID: This is a multi-part message in MIME format. --------------06F8F3F168CEE82038D7C66D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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