Re: [tcpm] 793bis: TCP Quiet Time

Fernando Gont <> Thu, 23 January 2020 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83B8A120072 for <>; Wed, 22 Jan 2020 23:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EKSJPxY-Oa6t for <>; Wed, 22 Jan 2020 23:22:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28104120026 for <>; Wed, 22 Jan 2020 23:22:46 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B7B8082DC0; Thu, 23 Jan 2020 08:22:42 +0100 (CET)
To: Matt Mathis <>, Joe Touch <>
Cc: "" <>
References: <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Thu, 23 Jan 2020 04:20:08 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [tcpm] 793bis: TCP Quiet Time
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2020 07:22:48 -0000

On 23/1/20 03:59, Matt Mathis wrote:
> There are two other changes that have largely made this problem moot:
> a) ISS and ephemeral port randomization make it extremely unlikely that 
> segments delayed across a reboot will be in sequence for any connections 
> (at the time this was written, both ISS and ephemeral ports were 
> generated by counters starting from fixed integers).

FWIW, note in many of the randomization schemes (e.g. RFC6528) the 
resulting sequence still looks like a counter for each (src, dst). 
Still, I would expect the problem to be unlikely.

> b) Although not reflected in policy, the effective MSL of the internet 
> has been declining as it gets faster.   There are paths and devices that 
> can delay packets by more than 10 seconds but they don't normally cause 
> packets to be reordered by that much, so a new SYN can't pass an old 
> data segment, which is a requirement for triggering the hazard.


> I would suggest changing the text to say "a theoretical problem....  
> that could be fixed by...  but for the following reasons it is viewed as 
> being sufficiently unlikely to ignore.

I would agree with this. That aside, one might also consider than as 
encryption becomes more pervasive, even in the case the problem took 
place, the connection would be reset, and the application would recover. 
  -- so I guess it would be a hard case to make OSes implement this 
"quiet time".

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492