Re: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

Wesley Eddy <> Fri, 07 January 2022 20:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AACA33A12ED for <>; Fri, 7 Jan 2022 12:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sWAb1GNIqjHn for <>; Fri, 7 Jan 2022 12:12:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FB203A13C0 for <>; Fri, 7 Jan 2022 12:12:39 -0800 (PST)
Received: by with SMTP id 69so7062188qkd.6 for <>; Fri, 07 Jan 2022 12:12:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=HPejV5+BEeddHlytPviX74WcQ17Fmjn6HwdebLL2l3Q=; b=vUBz0STWjQsp4378IycHL8AVjgDlPspHgBf6JHoqVzawlgQxcPabX0eu/TfSypfuI9 Tx3wQrnvYnBfZnafOuYRw4ayhDUFCzH+OkX+hOByhgJii9ondeiUInikjeFI8IPAeWkw oGnOIjeAH/kWOOQ91pjbkDFX4yoNaqJvFYsPLQ+LNdevk/PIitutxOWrdLVDuo904+b1 H772xggURLn6Fx0q3Sudx+higaoNBiptGmaciUGguDhAm4pjvAzh62s9WcvQlzjtHeqH E5Pc7Mqvp27Jt/rDmaQOuU/pzVYaI8+9tb2N4RF4de04ly3Nb07A/cIIL8NDdUOtJJBk /WJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=HPejV5+BEeddHlytPviX74WcQ17Fmjn6HwdebLL2l3Q=; b=PE3jOl4G75vR9ujZeaj0UOVMVuj/h+qwCqaK7kM9pdToC0T6JrlFyqHdmsOXuY6U0/ 7sM9qmShe7QBhS21pPIYSN/zUxn4ZBc9now8kGShQUSFun3yTZiD9VrU0JfyQVHNqlX5 5UHY0JSOjULsO6oud2DKp1jLf8F/vctrOHTvXB+ikSS0W+oEBu+4HZIBeP2GYtseXqHa FE+VZiE06DEuPBwIMfzcKWjPbY8r6iwEM1y8pAsfG8bM5MGV1jiLZYSc3HvzoGYNFAsa uyhUyAScXYTE8g1efoFD9rwQIyNHIwjKh6NsABCbgZccBNHGhzGnWcEfvBOCEls2NwLH XWAQ==
X-Gm-Message-State: AOAM530ZIgJNs2XUerj+SulD5+WRpIRThe4lx7MMVdXY/YX3qDf5JcLG WrSKKVbm0QuqehAqSyIySbROLQ==
X-Google-Smtp-Source: ABdhPJznQp6RchWeyfikrmUiZWuA6W+VGQvxfriDi0b0ZCh4evZIBVqDMr2NxoNhicAg/UERByjGBw==
X-Received: by 2002:a05:620a:14c:: with SMTP id e12mr43111111qkn.503.1641586357028; Fri, 07 Jan 2022 12:12:37 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id a15sm4308033qtb.5.2022. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 12:12:36 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------eBDfcmH1lF3PikMBWdbuPI1e"
Message-ID: <>
Date: Fri, 07 Jan 2022 15:12:33 -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: Roman Danyliw <>, The IESG <>
Cc:,,, Michael Scharf <>
References: <>
From: Wesley Eddy <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)
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: Fri, 07 Jan 2022 20:12:44 -0000

Hello, at long last I've gone through these comments and have responses:

On 9/22/2021 11:59 PM, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-tcpm-rfc793bis-25: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you to Kyle Rose for the SECDIR review.
> I support Ben, Lars, Warren and Zahed’s DISCUSS positions.
> ** Appendix A.1 and the shepherd write-up which explains why the antiquated
> text around “security compartments” for multi-level systems is still in this
> draft.  It’s disappointing that there was no prior IETF consensus action to
> establish the basis of pruning it.  My suggested addition for Appendix A.1
> would be to make a much clearer statement than “the state of IP security
> options that may be used by MLS systems is not as clean”.  It isn’t clear what
> is meant by “clean” – is it intended to say that it is not in fact used?

I agree, this could be rephrased.  In the WG discussions, I think these 
are not known to be in current use, however, someone using them might 
not be participating in the WG (we are more concerned with typical 
Internet use, and not MLS systems).  The IETF has not got rid of these, 
though it could make sense to do so in the future.  Is there a specific 
way you'd like to see this described, or should I just take a stab at it?

> ** Section 3.1. Per “[TCP Option]; Options#Size == (DOffset-5)*32;”, I found
> this notation confusing. What does the “#” in “Options#Size” indicate?

Colin mentioned earlier that this is from 
draft-mcquistin-augmented-ascii-diagrams.  Based on your feedback, that 
'Options#Size' notation has been changed to a "size(Options)", and this 
is reflected in my working copy.

> ** Section 3.4.  Per “There are security issues that result if an off-path
> attacker is able to predict or guess ISN values”, a reference might be helpful
> for this statement.  Perhaps [41] or [Morris185] from [41].

ACK; Zahed also mentioned this and I think [41] is a good reference 
because it includes some more context beyond just [Morris1985] alone, 
and of course it includes reference to [Morris1985] itself as well.

> ** Section 3.9.2 and The text here discusses various IP options like
> timestamp, record route and source routing.  Either in this section or in the
> Security Considerations the security implications of these options should be
> highlights.  Specifically, Section 4.3 – 4.5 of RFC7126 outline these security
> issues and has normative guidance to treat these packets as default drop.
> ** Section 7.  Recommend being more precise on the lack of security services:
> but there are no built-in cryptographic capabilities
>     to support any form of privacy, authentication
> but there are no built-in cryptographic capabilities
>     to support any form of confidentiality, authentication

ACK.  This is updated in my working copy.

> ** Section 7.
>     In order to fully protect TCP connections (including their control
>     flags) IPsec or the TCP Authentication Option (TCP-AO) [36] are the
>     only current effective methods. Other methods discussed in this
>     section may protect the payload
> The text should be more precise on what “protect” means.  IPSec and TCP-AO
> provide different security services.  IPSec will provide confidentiality and
> integrity, but TCP-AO only provides the latter.
> Likewise, the reference to protect the payload needs to be clarified.  Which
> exact security service does “protect” align with?

Based on your exchange with Joe, I changed "protect" to "provide 
confidentiality and integrity for" in both places.

> ** Section 7.  Further discussion on TCP stack fingerprinting would be helpful.
>   RFC8546 notes that “In particular, the metadata, such as sequences of
> interpacket timing and packet sizes, can be used to    infer other parameters
> of the behavior of the protocols in use or to fingerprint protocols and/or
> specific implementations of those protocols.”  However, it’s more than that –
> it’s the specific choices of options, their sequence in the packets, etc.
> Pretty much everything a tool like nmap does to profile host OSes.

Good point.  In the working copy, I've added this below, though you 
might be able to suggest improvement:

  * There are also methods of "fingerprinting" that can be used to infer
    the host TCP implementation (operating system) version or platform
    information.  These collect observations of several aspects such as
    the options present in segments, the ordering of options, the
    specific behaviors in the case of various conditions, packet timing,
    packet sizing and other aspects of the protocol that are left to be
    determined by an implementer, and can use those observations to
    identify information about the host and implementation.