Re: [netconf] ietf crypto types - permanently hidden

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 04 April 2019 16:51 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C00120121 for <netconf@ietfa.amsl.com>; Thu, 4 Apr 2019 09:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ODinFP50MhlZ for <netconf@ietfa.amsl.com>; Thu, 4 Apr 2019 09:51:36 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADBB120117 for <netconf@ietf.org>; Thu, 4 Apr 2019 09:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13190; q=dns/txt; s=iport; t=1554396696; x=1555606296; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sn8gwfCvtpgHO+46jmJ++O+LI3iPLCvAfr1kVLIuIhk=; b=lNy6YmfxvvFhSk9YXhsOpHSwV3Wgo/XPDm5Cdu90uzPoXd+cKWOvfmZO VL4d5HAsIl4NzH7Cwh5Cs1l4q+WcfbVaFLwpeZ5vtACgCHm6oSg1Pd51X j3oTzgk03/WK9U242yJOnT/nZH+38Um3Ygc/dFYG+IP2MPPFJg5XX3/LR g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAoNaZc/4cNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ6BAmiBAycKmUiSS4YMgWcOAQGEbAK?= =?us-ascii?q?FTSI3Bg0BAQMBAQkBAwJtKIVKAQEBAQMtTBACAQgRBAEBFhkyHQgCBAENBQg?= =?us-ascii?q?TgwiBEWSvaYozgTABiW6BRBeBQD+BEYMSPoN/L1WFIgOKU4ZhHpQYCQKTcCK?= =?us-ascii?q?CBYlwiFqDVod5k3ACERWBMDUigVZwFYMnghYXjh9BMY9JgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,308,1549929600"; d="scan'208,217";a="253885208"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Apr 2019 16:51:34 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x34GpYBb010117 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Apr 2019 16:51:34 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Apr 2019 11:51:33 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 4 Apr 2019 11:51:33 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAB55r2AAFc4f4AA2LGYAAAA+NoAAOhJxAAAPAjogAAJwD2w
Date: Thu, 4 Apr 2019 16:51:33 +0000
Message-ID: <a668ce8a370049769a82eb1250f139e3@XCH-RCD-007.cisco.com>
References: <VI1PR07MB47351FF76BBF6C56AC6E64B5835E0@VI1PR07MB4735.eurprd07.prod.outlook.com> <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com>
In-Reply-To: <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.177]
Content-Type: multipart/alternative; boundary="_000_a668ce8a370049769a82eb1250f139e3XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Bewy-cC4XUlPv5XdwHjrh-LMk3M>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 16:51:39 -0000

Hi Kent,

Inline with [RW]

From: netconf <netconf-bounces@ietf.org>; On Behalf Of Kent Watsen
Sent: 04 April 2019 17:23
To: Martin Bjorklund <mbj@tail-f.com>;
Cc: netconf@ietf.org
Subject: Re: [netconf] ietf crypto types - permanently hidden




and the creation of a private key that becomes (protected)
configuration is similar to the creation of a user account, where an
unused uid is allocated that becomes configuration.

AFAIK there is no standard model defined that actually do this.

Mostly true, though one might claim that <edit-config> is an example
of an RPC that modifies configuration.

[RW]
But in this case, the updated configuration is provided by the client, not the server.  I.e. it is clear which entity owns the configuration, and is the "source of truth".


The closest thing we have is the "type" of an interface:

          When an interface entry is created, a server MAY
          initialize the type leaf with a valid value, e.g., if it
          is possible to derive the type from the name of the
          interface.

If private keys are handled like this, then I can accept it.

This is not what is being asked for here.



But we
should NOT introduce special actions/rpcs that manipulate the
configuration.

Why not?  Not that it's a valid justification, but vendors do it already.
What would it take to make it be not "special"?   Would adding a
standard (yang-next?) "modifies-configuration" leaf to the action/rpc
definition suffice?

FWIW, I do agree with Balazs, and argued as much a couple years
ago, that the current approach is not best practice.  That said, I'm
more interested in the general-purpose use of rpcs/actions this way.

We have always said no, but the reasoning is unclear.  What are the
specific objections and is there anyway to alleviate them?

[RW]
I think that is bad practice for a server to inject configuration into <running>.  It makes it ambiguous as to which entity really owns the configuration.   I think that what is in <running> should be owned by the client, not the server.  I'm not saying that nobody does this, but I don't believe that it is the cleanest solution.

I'm OK with a server injecting configuration between <running> and <intended>, and using NACM to prevent that value from being read back from <intended>.

I'm OK with the server just reporting the default system allocated value in <operational>, again protected by NACM if appropriate.

Thanks,
Rob



Kent // contributor