Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 16 July 2020 13:21 UTC

Return-Path: <evoit@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 EBC4D3A00E4 for <netconf@ietfa.amsl.com>; Thu, 16 Jul 2020 06:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.621
X-Spam-Level:
X-Spam-Status: No, score=-9.621 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 header.b=P38X1are; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=lojCO8mE
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 qcqIEilb4CyZ for <netconf@ietfa.amsl.com>; Thu, 16 Jul 2020 06:21:00 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948523A003E for <netconf@ietf.org>; Thu, 16 Jul 2020 06:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11264; q=dns/txt; s=iport; t=1594905660; x=1596115260; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1UPCy8U4ufMqhUJbiRqG/GeTOhaRT/5Jw9XdMl5GCMM=; b=P38X1areJtqZki4k0OywgbgrT+zB/WdkLUN6pfjvq1yye+FBRZiPU+AK SRwxy1vVDJ1fOHt1rJDZeCrmitjsPv+nUsH81ZpVyptjdYflQ+vCB8fV1 Zpnwxas/fN6gw4LXiQJj1k4JHZ9/h78XsXMeLAFx6IOAymLni6Xdkkq76 I=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3A7y5j9B31xIOeeeWwsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dyhUPSUIOd7f9Y2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YldcBN3zYRvUr2HhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJCACZUxBf/4UNJK1XCR0BAQEBCQE?= =?us-ascii?q?SAQUFAYIKgVJRB28rLS8sCoQpg0YDjUeYXoFCgREDVQQHAQEBCQMBASUIAgQ?= =?us-ascii?q?BAYRMAoITAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFbwEBAQECARIRBBkBATA?= =?us-ascii?q?HAQQLAgEIFRAdAgICMCUCBA4NBhSDBYF+TQMOEQ8BDgOfNQKBOYhhdn8zgwE?= =?us-ascii?q?BAQWBMgGEARiCBwcDBoE4gVOBF4NVg2iCSxqBQT+BEUOCTT6CXAKBMxMBGoM?= =?us-ascii?q?UM4ItjzmCWD2GdppxgQQKgl2EMoJYgUuRLIJ4iT2TDJwjlFYCBAIEBQIOAQE?= =?us-ascii?q?FgWojgVdwFYMkUBcCDY4eDBeDToUUhUJ0NwIGAQcBAQMJfI17AYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.75,359,1589241600"; d="p7s'?scan'208";a="524795648"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2020 13:20:59 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 06GDKxIV016869 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jul 2020 13:20:59 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 08:20:59 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 09:20:58 -0400
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 16 Jul 2020 08:20:58 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hZmRxLSE6Zog7pWYSgI29mBarjPXaONGaz9EEUVQ44FpZaVOKBUTGMGA4hjcZOOtImt0wLr93np/55yQaOejAGPEPVIundeOwOh4p4WL9nD7pclGK6SHH2aBjPB1LoycJeqOlsybtnSKwRVgebXOhUhLS5DaeB/wMTAxvRSUpWg5GkwBw2D0YSzlnLwiWA4SapRtMoJrUGfBlYAIHct5ehDm+2UaeIKeTR6nBfD9X1h9On2/lQRCGef7CpLNzt6y29f+NuvMHF/ipbpvzFRjFBLgPDaiYU4cZGhmRlohO6rNfKCJM632vFIZe42vgwnTU9ml5HRG+HMWpETP+w3O+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3CCGF/epB8+3p1Yq1LHlHBKE0n0FtB0FgHaPmthEFHA=; b=IydjWiOcZNtf6XihMGQaQcz+tdJPPAe6FjCpTpqxsv80ZKxFPOXHHeyaw3CRZYw7RKb5bB+gD76JXwLCvrSjROWYD/SKSh7emsB25yfjyrlP0yr7EdZU06fjIbSUElJvliG2XoooSQFJ4bnsmQXNulG8bhWeJDTuHQ7k74MeU0U5YrNTg4zstlwH3qWovGrIoI8nM4k1DEovY/NiAA20lmXsIY47PYQfeOEzCEZ8lVLpOnyrE+3KTpGoTpqyZKF25k5BiyNPLu+K6KHEltcjQsLBkCG9rdPlSnQUPdDueAL29FMrk+yaU7DUEQAM/1MBrvIMdLuFhll9s4r0S/uSQA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3CCGF/epB8+3p1Yq1LHlHBKE0n0FtB0FgHaPmthEFHA=; b=lojCO8mEvgKhQhkqNIxFRiWdIAFKPfXyNdItQzGLsFufgJzoNh2hPug3ng+NduJz9y0W+uDW/18dnN1CB1gz9XqB/FSrIK6VXpx2zy1X7pT2q5mesCCbW1jkRRTUmbNROjy6Kfo44BXi3gMzahdwYk1ijXDcKqtyJuoSfc1gAaU=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB2946.namprd11.prod.outlook.com (2603:10b6:208:78::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Thu, 16 Jul 2020 13:20:57 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3195.018; Thu, 16 Jul 2020 13:20:57 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt
Thread-Index: AQHWVuGAMhvA4eAgHUC1kvcCfWaYoqkHQQNggAIOkwCAANYigIAAAF/w
Date: Thu, 16 Jul 2020 13:20:56 +0000
Message-ID: <BL0PR11MB3122F1243CF8BA2AE4AF4587A17F0@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <159440288260.29660.1882956283740039536@ietfa.amsl.com> <BL0PR11MB312248671AB8F1773295D357A1610@BL0PR11MB3122.namprd11.prod.outlook.com> <0100017354c87c8a-e19d1df5-0113-4b19-b6cd-9394c017b6ff-000000@email.amazonses.com> <BL0PR11MB312275EFCCE4266CFCA1194FA17F0@BL0PR11MB3122.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB312275EFCCE4266CFCA1194FA17F0@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.77]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 712154a6-82fe-4872-c9e5-08d8298b132a
x-ms-traffictypediagnostic: BL0PR11MB2946:
x-microsoft-antispam-prvs: <BL0PR11MB29464D2ECCD0966AFCEA1842A17F0@BL0PR11MB2946.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /+Hd3MSYpx8COmkh70/q0nTwWS+QxSK7dd7y/AVfbi/Da6sHC2POasmYAjlFSlXBcDiYcbi5SZ1F22qNSoV0whQxDQnzYnLadee1ioU4nam3n0NY9OWY/noO/YGnDSKe2Iet1+dHph5t3feMlpzMCPKt7A0qlgxagXdKP4Pd6FcOdcd1mrUIue/xvY2D1sBoxBMWEsQIxMjQSpTgtx9l7tlTBdhUi6G5xnM3Hy/UsgNapGIGICyohQ2SqVO1GbfCtptTwc8k4UtumYceG08AemJx4TzyedSCnY9BUXhc8D38TVbFddpZb/Myv5t7f237wFmygBNrLWXN3L2ERsd3P1C+bYKx3W7Ud9KPhZWjAAO2Y0StgMww6QWnVKHOMoWNZVllT16kPfosd4dkLd/ZUg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(366004)(136003)(396003)(376002)(2940100002)(66946007)(2906002)(66556008)(76116006)(66476007)(7696005)(5660300002)(52536014)(66616009)(6506007)(99936003)(478600001)(64756008)(33656002)(54906003)(71200400001)(26005)(9686003)(66446008)(55016002)(86362001)(316002)(8676002)(8936002)(4326008)(186003)(83380400001)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Hxfrwv8SsoKPd+IANkQvqkZGF0oxvw4LIoOfXLHae9iPygoLkE8h2My9Ts5pxPrQSQ3l2Gvjcz7wxh9W1ImNhGDUegeLHj8lw5dwkZAFPJ8XcLhr0Dno+bfa+ZAkRx6Wx37TqXV1pJYxoDAbLyoo5H6Lv5FQv5dDsFtxnenOfXNOXTcr+24xbTkgRf4qfUylqDENOHn2kGZequCyCRAuMZQ7T/dx0FAC95848wyO8Q9KtvV89N2OVMgWEn4JrvOOet3Z19iGOAYMoJtUAs0J4jxIzXEIOum1nEAaXlRFmkd/yZKiblC387xj+ku2SuCbMNSI2aWeJvpalmh+/ZPqWTUo+TGCDaSj57Mk1GbK9oEGDsrvjHWsiZTrG4ASwBx4ewbPnN1lO1D9y8qbEES2vPN7pdAzkKUPXGuj9ishsV4PqdpMePgWsLOog8kmLEVai5guPZYgoGuwuwGDVY+hOd8z9SIp4N+1ZBAlb/4wrLRrpWr4I+sPkTADZK5J9Dy0
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="----=_NextPart_000_049E_01D65B52.67AA0590"; protocol="application/x-pkcs7-signature"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 712154a6-82fe-4872-c9e5-08d8298b132a
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2020 13:20:56.9910 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dUNrxsW485Cqvktp9DdKqKQClVN6/UQawJa+CbPwhTqp5YacmGCVSJ40VHT9TxjD
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2946
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/1jv9x8KrVxztPQdRWk_TKnSj0tU>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt
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, 16 Jul 2020 13:21:04 -0000

Hi Kent,

> From: Kent Watsen, July 15, 2020 7:22 PM
> 
> Hi Eric,
> 
> 
> (1) For ietf-https-notif.yang why did you choose "uses x509c2n:cert-to-name"
> rather than linking to ietf-truststore.yang's
>      grouping truststore-grouping
>        +-- certificate-bags! {certificates}?
>           +-- certificate-bag* [name]
>              +-- name?          string
>              +-- certificate* [name]
>                 +-- name?                            string
> 
> I’m unclear about the issue.  Cert-to-name performs a mapping that doesn't
> exist anywhere else...

No action is needed on this one, but let me give you my original thinking.  I was trying to understand the relationship between  RFC7407 certificate names 

       (below is an the extract from RFC7405, Appx A.7)
             <cert-to-name>
               <id>2</id>
               <fingerprint>11:0A:05:11:00</fingerprint>
               <map-type>x509c2n:specified</map-type>
               <name>
                 Joe Cool
               </name>
            </cert-to-name>

and the certificate name ietf-truststore.yang's certificate name (per above).   It took me a while, but I found the relationship by drilling down through the client/server drafts to the example of draft-ietf-netconf-restconf-client-server, Section 3.1.2.1:

     grouping restconf-server-grouping
       +-- client-identity-mappings
          +---u x509c2n:cert-to-name


> (2) Do you plan any functionality which inter-related with the receiver action
> 'reset' from SN?  Right now this SN action resets the subscription.  Whether
> this actually does anything to any underlying connection is undefined in SN.
> So I think what you have is fine as you define no actions on receiver-
> instances.  But I figured I would ask: is there anything connection related
> which you might expose for the receiver as a whole?
> 
> No SN-relation is planned. I’m unsure exactly what the ask is.  Please advise.

SN allows a configured subscription to be reset.   Will there be anything in https-receiver to reset a type of transport connection to a receiver?  Based on the current model, I am assuming no.    

> (3) I have a question on receiver capability discovery prior to sending
> notifications.  Section 2.1 says that a publisher 'can' issue an HTTP GET for
> the capabilities.  This also suggests that it can choose not to send such a
> request.  What is the required behavior for an HTTPS publisher and receiver
> when the targeted receiver doesn't support the expected capabilities?
> 
> IIRC, the encoding MAY be configured in the SN model.  If it is not *and* the
> publisher doesn’t probe the receiver’s capabilities, and thus blindly sends
> whatever it wants, it risks the receiver returning an HTTP 4xx error.  Makes
> sense?

Let's say that IP addresses change, and there is an unintentionally targeted receiver which can accept a TLS connection, but cannot/will not reply with an HTTP error.  Are there scenarios where this could be used as a DOS attack?

>  (4) Extending the question (3), the  <subscription-started> notification from
> SN can be used for this functionality.   Looking at the example you have in
> pipelining Section 1.5.1, the second POST of a YANG notification occurs is
> shown before the "Send 204 (No Content) is returned" for the first
> notification.   Could you explicitly add the <subscription-started>
> notification to section 1.5.1 to disambiguate things?  For example:
> 
>        -------------                               --------------
>        | Publisher |                               | Receiver   |
>        -------------                               --------------
> 
>        Establish TCP             ------>
> 
>        Establish TLS             ------>
> 
>        Send HTTPS POST message
>        with <subscription-       ------>
>        started> notification
>                                                    Send 200 (OK)
>                                  <------           for <subscription-started>
> 
> 
>        Send HTTPS POST message
>        with YANG defined         ------>
>        notification #1
> 
>        Send HTTPS POST message
>        with YANG defined         ------>
>        notification #2
>                                                    Send 204 (No Content)
>                                  <------           for notification #1
> 
>                                                    Send 204 (No Content)
>                                  <------           for notification #2
> 
> I think that this is proper.  Guidance welcomed.  But not that, beyond HTTP
> [N}ACKs, this is a one-way flow of content, so whatever needs to fit into
> those HTTP responses.

This works for me.  I believe it helpful to show the <subscription-started> in the diagram: SN says that the <subscription-started> needs to be confirmed before other notifications are pushed.

Eric
 
> Kent // as co-author
> 
> 
> 
> There were some earlier discussions on these overall interactions in threads
> like:
> https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRc
> A/
> 
> Thanks,
> Eric
>