Re: [tcpm] Roman Danyliw's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and COMMENT)

"Scharf, Michael" <> Mon, 05 September 2022 09:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65B74C15257E; Mon, 5 Sep 2022 02:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mQPyzDo4fFJw; Mon, 5 Sep 2022 02:10:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 635A5C152586; Mon, 5 Sep 2022 02:09:33 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 81D6F25A4B; Mon, 5 Sep 2022 10:53:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1662368009; bh=Bu+UVwDr8V3/D7FLuUw2K/ofCi8jk88rfuarMay214k=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=k1gXsUT7IluKcEYK4FPZYj2PwqXp3p7xNWzR0gZPaK3zk6n3lNlPTvnNr6D5nZ5pI pKEk0k+QJdlvlxMh9e5nSSirldUL0vJ4OjaI1ZyY3uYyLSg5hB6XbeKBe7nHWIeNwY F4wo8/J2Geh/d3aDgPUb0RdDFUiuq9WdTVnJZjac=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RGZMr77aT0vI; Mon, 5 Sep 2022 10:53:28 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 5 Sep 2022 10:53:28 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 5 Sep 2022 10:53:27 +0200
Received: from ([fe80::aca4:171a:3ee1:57e0]) by ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2375.031; Mon, 5 Sep 2022 10:53:27 +0200
From: "Scharf, Michael" <>
To: Roman Danyliw <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and COMMENT)
Thread-Index: AQHYi8yWqpYxf/XurU6JgauzF7fgY63Ky2Cg
Date: Mon, 05 Sep 2022 08:53:27 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpm] Roman Danyliw's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.39
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: Mon, 05 Sep 2022 09:10:24 -0000

Hi Roman,

Thank you for this feedback and sorry for staying silent during the holiday season.

The authors have prepared a new version -08. Please refer to to see the changes.

Unfortunately, when preparing -08, one of the patches got lost, and therefore one change regarding one of your concerns is still missing in -08. Sorry! This was not intended, and this bug will be fixed in the next version -09. The suggested change for -09 is explained below.

> -----Original Message-----
> From: Roman Danyliw via Datatracker <>
> Sent: Wednesday, June 29, 2022 5:26 PM
> To: The IESG <>
> Cc:;;;
> Subject: Roman Danyliw's Discuss on draft-ietf-tcpm-yang-tcp-07: (with
> Roman Danyliw has entered the following ballot position for
> draft-ietf-tcpm-yang-tcp-07: Discuss
> 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
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ** B.2.  Thanks for providing an example of a TCP-AO configuration.
> Unfortunately, this isn't a valid example example and it seems to be making
> citations that don't match.  Specifically:
> -- "<crypto-algorithm>hmac-sha-256</crypto-algorithm>"
> The algorithms usable by TCP-AO come from
> parameters.xhtml#tcp-parameters-3.
>  Only SHA1 and AES128 are registered.  As far as I tell, the only work to add
> SHA256 is in an unadopted and expired draft
> (
> As aside, I think the algorithm name would have been SHA-256 or SHA256 (no
> HMAC).

Good catch. The examples now use AES-128 (BTW, an identifier for AES-128 is not defined in the YANG model in RFC 8177, but it is needed.)

There has been not much energy in TCPM to finalize draft-nayak-tcp-sha2 some years ago. Indeed, we should not use this algorithm in this document. In the meantime, further TCP-AO implementations have emerged. This may open an opportunity to standardize further TCP-AO algorithms. Yet, this discussion seems orthogonal to this YANG model.

> --    Per the link to RFC9235:
>     The following example demonstrates how to model a TCP-AO [RFC5925]
>    configuration for the example in TCP-AO Test Vectors [RFC9235].  The
>    IP addresses and other parameters are taken from the test vectors.
> RFC9235 doesn't use SHA256; and uses KeyID 61 and 84.  Different KeyIDs are
> used in this example.  Which parameters are being used from the test-
> vector?

Good catch. This mismatch was not intended, and we agree that this should be fixed. Yet, unfortunately, when preparing version -08, the authors messed up the corresponding patch, and version -08 still shows the old variant. The current proposal for the example in the next version -09 is:

This example sets TCP-AO configuration parameters similar to
the examples in RFC 9235.

    <description>"An example for TCP-AO configuration."</description>

As shown in the example, the suggestion is to use the key ideas from RFC 9235. I'd also simplify the example by using only one entry in the key-chain.

Unless somebody agrees, this example will be used in the next version -09, which will be published soon.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you to Hilarie Orman for the SECDIR review.
> I concur with the SECDIR observation that "there are no statistics kept for
> authentication failures.  If a shared key falls out of synch, the statistics
> might help detect that."  I appreciate the response
> (
> n0/)
> which recommends that this should be generically modeled.  I disagree that
> this
> should be deferred. There is a very specific TCP-level primitive being
> described here and it makes sense to me to provide a corresponding logging
> primitive.

Personally, I don't agree to that observation. For what it is worth, I have replied to this comment already with follow-up questions, as documented in Unfortunately, I am not aware of any reply.

Yet, that is my personal view only. Adding some counter to make everybody happy may not be a big deal. Therefore, the model now includes in -08 an additional counter:

         leaf auth-failures {	
 	           if-feature authentication;	
 	           type yang:counter64;	
 	             "The number of times that authentication has failed either	
 	              with TCP-AO or MD5.";	

This hopefully sorts out this issue.