Re: [tcpm] Comments for draft-ietf-tcpm-yang-tcp-00

Joseph Touch <touch@strayalpha.com> Wed, 04 November 2020 21:36 UTC

Return-Path: <touch@strayalpha.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 266EE3A0B86 for <tcpm@ietfa.amsl.com>; Wed, 4 Nov 2020 13:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 BDlPhix_RdaD for <tcpm@ietfa.amsl.com>; Wed, 4 Nov 2020 13:36:09 -0800 (PST)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A6D3A05DF for <tcpm@ietf.org>; Wed, 4 Nov 2020 13:36:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IIQURh6Po+QX1K5eX40F+Uybw9ykpelTi2CLzuqYOu4=; b=23ptU7U9GwkM/m6RGK4/7wWmk grjfdJ6hgnMqilKZmWYLxdeet8MP0aOHATBsPLHscaBswR/0ecKNBgRA8TajK+3Ygkr+PmnOnpEYo U8kX7ZbmYBUrYs5/E+HXDw3COXZAb2N/st4VMi7+gmfB6EMdqdhVwv6B8DUS+vYzgNrczzx0IyJGK qcQBVbnTIEMcBZMKNRD84LtJoVvL9+Wc/nNv6f9ML1keY0Yt0PqHo9fXbE3I/FkZLAo0hTp8TYDAy J2YZOhO+8y4K1Xolxe/XcLqUGrKcd5OyKg5PNvd3zznb+bC/CwH6m6d4FPhXSmQQhLKOvbougmEos RuRWUSxSg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61168 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1kaQRo-00319D-Ur; Wed, 04 Nov 2020 16:36:09 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CACS3ZpCj+1XZC+RkQcGUaC90XcGBUF_OR_qor8V4Zn0nTSGrRg@mail.gmail.com>
Date: Wed, 04 Nov 2020 13:36:04 -0800
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, tcpm IETF list <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <340D363A-3C02-4A64-9DF4-A335B69CC87F@strayalpha.com>
References: <CACS3ZpBJOfctZjW0qUD+2p1vw63p9KeJ+ie15SHE=k_fk6suTw@mail.gmail.com> <CACS3ZpD7dL=gbZd_mqA21+qX2nvKh7TDj3cx3xJvEUc_bnRZfg@mail.gmail.com> <EB42CDCE-2BF5-462D-8CBF-0589998AC883@gmail.com> <CACS3ZpCj+1XZC+RkQcGUaC90XcGBUF_OR_qor8V4Zn0nTSGrRg@mail.gmail.com>
To: Juhamatti Kuusisaari <juhamatk@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=0.3
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Fs26_Im3bbBhp9NtCb-GWC7ShzE>
Subject: Re: [tcpm] Comments for draft-ietf-tcpm-yang-tcp-00
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: Wed, 04 Nov 2020 21:36:11 -0000

Is there a convention in YANG for such situations?

I personally would not expect all values to have “default=true” or “on" everywhere. Sometimes you’re actively turning on something that is typically disabled (default=false or off).

I think the “include-tcp-options” matches the way it’s described in the doc (TCP option flag, where true implies includdd) and the default=true would match better.

Joe

> On Nov 3, 2020, at 9:11 PM, Juhamatti Kuusisaari <juhamatk@gmail.com> wrote:
> 
> Hello Mahesh,
> 
>> Would it not be simple to add a ‘default true’ to ‘include-tcp-options’ to achieve the same result? Somehow my head does not comprehend a double negative very well :-).
> 
> Yes, ‘default true’ to ‘include-tcp-options’ would achieve the same
> end result. However, I think it would guide implementers to have a
> special "include"-mode for options in the TCP AO implementation,
> especially as TCP MD5 does not have options included. There should be
> nothing special about including options, the special part is to ignore
> them. Thus, I think 'ignore-tcp-options' is the way to go. Then again,
> having 'default true' with ‘include-tcp-options’ is certainly an
> improvement and another valid choice.
> 
> --
> Juhamatti
> 
> On Tue, 3 Nov 2020 at 19:11, Mahesh Jethanandani
> <mjethanandani@gmail.com> wrote:
>> 
>> Hi Juhamatti,
>> 
>> On Nov 1, 2020, at 1:06 AM, Juhamatti Kuusisaari <juhamatk@gmail.com> wrote:
>> 
>> Hello,
>> 
>> My comments included below apply also to draft-ietf-tcpm-yang-tcp-00.
>> 
>> In brief:
>> * include-tcp-options -> ignore-tcp-options with default false
>> * accept-ao-mismatch -> accept-key-mismatch
>> 
>> BR,
>> --
>> Juhamatti
>> 
>> 
>> ---------- Forwarded message ---------
>> From: Juhamatti Kuusisaari <juhamatk@gmail.com>
>> Date: Fri, 18 Sep 2020 at 11:53
>> Subject: [tcpm] Comments for draft-scharf-tcpm-yang-tcp-06
>> To: tcpm IETF list <tcpm@ietf.org>, Scharf, Michael
>> <Michael.Scharf@hs-esslingen.de>
>> 
>> 
>> Hello,
>> 
>> I read through draft-scharf-tcpm-yang-tcp-06 and overall it looks fine to me.
>> 
>> Nevertheless, there are a couple of items that may need
>> clarifications/improvements.
>> 
>> (1) I believe "leaf include-tcp-options" should be "leaf
>> ignore-tcp-options" with a false default as the options are included
>> by default in the RFC 5925. In my opinion, this would better emphasize
>> the fact that options really should be included by default and not
>> including them should be a special case. Change suggestion in detail
>> below:
>> 
>>     leaf include-tcp-options {
>>       type boolean;
>>       must "../enable-ao = 'true'";
>>       description
>>         "Include TCP options in HMAC calculation.";
>>     }
>> =>
>>     leaf ignore-tcp-options {
>>       type boolean;
>>       default "false";
>>       must "../enable-ao = 'true'";
>>       description
>>         "Ignore TCP options in MAC calculation.";
>>     }
>> 
>> 
>> Would it not be simple to add a ‘default true’ to ‘include-tcp-options’ to achieve the same result? Somehow my head does not comprehend a double negative very well :-).
>> 
>> Please also note the "HMAC"->"MAC" change suggestion. And yes, I do
>> realize that a default could be added to the original "include" leaf.
>> After pondering about this, I do think "ignore" leaf would be a better
>> end result for the reasons I mentioned above.
>> 
>> (2) There is now a leaf that says:
>> 
>>     leaf accept-ao-mismatch {
>>       type boolean;
>>       must "../enable-ao = 'true'";
>>       description
>>         "Accept packets with HMAC mismatch.";
>>     }
>> 
>> It is true that RFC 5925 allows non-existing MKT connections that
>> should be accepted. Then again, the above configuration and its
>> description looks to me that any mismatch would be accepted. So, maybe
>> a configuration setting better reflecting RFC 5925 would be something
>> on the lines of
>> 
>>     leaf accept-key-mismatch {
>>       type boolean;
>>       must "../enable-ao = 'true'";
>>       description
>>         "Accept TCP segments with a Master Key Tuple (MKT) that is
>> not configured.";
>>     }
>> 
>> As this configuration option does not have such a strong default as
>> the former one, I do not see a need to change its logic otherwise nor
>> add a default. I would assume that most security aware users would
>> have "false" there as a setting - especially those users that would
>> use a YANG model to do the configuration.
>> 
>> 
>> I am fine with making this change.
>> 
>> Thanks
>> 
>> 
>> Best regards,
>> --
>> Juhamatti
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>> 
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm