Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

Wesley Eddy <wes@mti-systems.com> Fri, 07 January 2022 19:04 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CEF3A11E5 for <tcpm@ietfa.amsl.com>; Fri, 7 Jan 2022 11:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw3Cxk2P22HZ for <tcpm@ietfa.amsl.com>; Fri, 7 Jan 2022 11:04:29 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4FF3A11DD for <tcpm@ietf.org>; Fri, 7 Jan 2022 11:04:28 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id o10so6335833qvc.5 for <tcpm@ietf.org>; Fri, 07 Jan 2022 11:04:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=cq0RASIeVrTiIW9rI7fO+MjgezNl0VFnzEiPqBVgEf8=; b=6hAF0BdJsYGd35Os4IyPXr/yOda9O3D+4XijbpMc/tLjE6Z5qmHEYCahzr9K48FT4e LNrQ8FJTF8djkcf48vpwoEhqpDFReVEj24alVzIWGd3kjnalyRCcY0JjKFlVL8IUoihH 0IC5YeVpfeA8p5fonrussFe/KWq8V9sHJ6b2c1SluT6cWxrq0MQaq/7r64XAoNeIcSY9 Hwf7ZAXx4EdgCqN4UXr45cTweh2rfJEJKuxyWsg7DqumhfJY0FXk2H3BSVcXk/Pd2z0P pdCfMl5/TQd44UWSoYHAah/+On2uZxYwSq9F4TB/37nlgQymwkUbn+dXTuzEmMTXA2Fq C6SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=cq0RASIeVrTiIW9rI7fO+MjgezNl0VFnzEiPqBVgEf8=; b=n6A5bq5+4041Tm6KwBiEm/jYe9b6HXzohdWedeBp1xQvBi93xzy3jUxj2JKrM9/W8Y kg5+aCrzprvr6PClXjt4saisIc4ind5L4ObwHbECs7pigiOuIeCIxTFI8E2nEFhyYNxV b5FWDQFw4ehJZCUfzCbRAse3SwCNINuz+cE8klG3ybZDqw9P5KUKLuRJWeAiOm27gstH wtyaLaiT6IGU1fxNq4kLRMfh5q5CxF86wBZxI7bWDArM/7DgtNMXGFffNpD0UFQ/JRQZ o06dAfGVfqtDhwRdF9Pe2BMVVKYczuDcLWf514yESpfMeMcHLfkakBKlLvU3FvoQ2Gbe eEZw==
X-Gm-Message-State: AOAM5326AAr+xY0R7bFcuBKOvXe7fPCkHtnFJ/LOjqfVaHJl084PKKNl XwYfsZmU8PfR7Ma7d+ceTvP0lA==
X-Google-Smtp-Source: ABdhPJw46jFJBA7vTjY5ilab4IvuBPy+KpfRXs1t2ZKWkiL6H7n4ll+JFbYFIebfgDmpX6ed4OGCpA==
X-Received: by 2002:a05:6214:1c0d:: with SMTP id u13mr59787859qvc.46.1641582266721; Fri, 07 Jan 2022 11:04:26 -0800 (PST)
Received: from [192.168.1.17] (cpe-66-61-72-87.neo.res.rr.com. [66.61.72.87]) by smtp.gmail.com with ESMTPSA id s19sm4341519qtk.40.2022.01.07.11.04.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 11:04:26 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------RvBGTSB7O6L7J7GNuNZgUd2n"
Message-ID: <9e0080c6-8540-c145-2fa6-c8ba82bdabce@mti-systems.com>
Date: Fri, 7 Jan 2022 14:04:23 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: en-US
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-tcpm-rfc793bis@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Michael Scharf <michael.scharf@hs-esslingen.de>
References: <163234356267.14096.14587632428023214216@ietfa.amsl.com>
From: Wesley Eddy <wes@mti-systems.com>
In-Reply-To: <163234356267.14096.14587632428023214216@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ugUG0OZdD5ECYQde-2Dp-u7SbuU>
Subject: Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2022 19:04:32 -0000

Hello, we had corresponded about your DISCUSS points a bit earlier, but 
now I've also had the time to go through your other COMMENTs:


On 9/22/2021 4:46 PM, Zaheduzzaman Sarker via Datatracker wrote:
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-tcpm-rfc793bis-25: Discuss
> ...
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks a lot to the author and the TCPM working group to produce this document.
> It has been long since I read the whole TCP specification, I refreshed myself a
> lot when reviewing this. Thanks for that experience.

Thank you!


>
> I have some comments/questions below. By addressing those, I hope will improve
> the document even better:
>
> * Section 3.1 : says --
>       Note that the list of options may be shorter than the data offset field
>       might imply. The content of the header beyond the End-of-Option option
>       must be header padding (i.e., zero).
>
>     Should this be a normative MUST?

Great question ... The EOL option is a zero byte, and the first such 
option should signal that the option list is over.  So the receiver 
shouldn't need to process or check any further bytes of options to see 
if they're also properly zero'ed padding.

So, I wouldn't think this needs to be normative, since if it's not 
followed, no harm should result.  However, that leads to the question of 
why it says they must be set to zero then.  Maybe someone else from TCPM 
has a better answer than "that's just what it's always said" ... To me, 
it seems like it's a good thing to do, but maybe not really required.


>
> * Passive open and active open should be defined/described. Even if these are
> well known terms in the community, a verbose description of passive/active open
> will be much appreciated in this document context. if they are defined
> somewhere else then I have missed that, in that case a reference would be more
> appropriate.

This is a good point, and was clear in the original 793, so maybe we can 
just include the relevant text from there (pasted below). I'll try to 
find the best place to fit a slightly edited version of this in for -26, 
if you agree:

   The OPEN call also specifies
   whether the connection establishment is to be actively pursued, or to
   be passively waited for.

   A passive OPEN request means that the process wants to accept incoming
   connection requests rather than attempting to initiate a connection.
   Often the process requesting a passive OPEN will accept a connection
   request from any caller.  In this case a foreign socket of all zeros
   is used to denote an unspecified socket.  Unspecified foreign sockets
   are allowed only on passive OPENs.

   A service process that wished to provide services for unknown other
   processes would issue a passive OPEN request with an unspecified
   foreign socket.  Then a connection could be made with any process that
   requested a connection to this local socket.



> * Section 3.4 : says --
>      There are security issues that result if an off-path attacker is able to
>      predict or guess ISN values.
>
>     A reference to this claim would be highly appreciated. May be we can reuse
>     some ref from 41? I also think "Initial Sequence Number Selection", "Knowing
>     When to Keep Quiet" and "The TCP Quiet Time Concept" should be numbered
>     subtitles.

ACK, I'll add a reference here, and these sections are now numbered in 
my working copy.


>
> * Section 3.5 : can we put some reference for "security level or compartment"?
> A pointer to the appendix A.1 should be enough here.

ACK, this is now in my working copy.


>
> * Section 3.8.1 : says --
>
>     RFC 793 contains an early example procedure for computing the RTO. This was
>     then replaced by the algorithm described in RFC 1122, and subsequently
>     updated in RFC 2988, and then again in RFC 6298.
>
>    I am not sure what am I supposed to do with this information. Suggest to
>    remove this paragraph.

The intention was to make sure that it's clear 6298 is the place to 
look, and that the other descriptions have been replaced by it.  Maybe 
we used too many words for this small of a point though, and could say 
it more succinctly.


> * Section 3.8.5 : describes --
>
>      A TCP implementation MUST support a sequence of urgent data of any length
>      (MUST-31). [18]
>
>    I am not sure what is the reference for? if this is to say this MUST is taken
>    from [18] as described there then to me this reference also should be
>    normative.
>
It's only a reference to where that requirement originally appeared, and 
nothing further from [18] (RFC 1122) is needed to implement this properly.