Re: [secdir] SECDIR Review of draft-ietf-netconf-subscribed-notifications

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 29 March 2019 20:28 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7163C1202FF; Fri, 29 Mar 2019 13:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.49
X-Spam-Level:
X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, T_KAM_HTML_FONT_INVALID=0.01, 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 QhjbxQKQ-raA; Fri, 29 Mar 2019 13:28:40 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68840120302; Fri, 29 Mar 2019 13:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18336; q=dns/txt; s=iport; t=1553891320; x=1555100920; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5JRmgXGZmbGv3arILk2CFNWYChescsmd8UbQY355ZEw=; b=LHUJRi6JndHWiZLPy/kT/5SSJ9uOTgS2eY7aOwjqLYeEKaJQ7ffyT4FI wVkA5NmFvaZNp/iMI06S8UgPVX5UJ9dVu4CkUYeko2K5O2Av1dAycbi7E ZNqrhECwtIBd/nWogH1iQ/PY+t3zpqp27o0V6zkd/ZYicXmLSBxgqIrU4 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAXf55c/49dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDlgqgWsnjCqKe4IOCCWJOYkNhXeBew4BAYR?= =?us-ascii?q?sAoU3IjQJDQEBAwEBCQEDAm0ohUoBAQEBA3cCEAIBCBEEAQEOGgchERQJCAI?= =?us-ascii?q?EDgWCV0uBEkwDFapwH4dhDYIfgS8BhF2GVReBQD+BEScMgWF+PoIagmCFKwO?= =?us-ascii?q?KUoZPk2s2CQKHIYhygzkGGpQokwOLfQIRFYEuHziBVnAVgyeQSgFBMZBbAQE?=
X-IronPort-AV: E=Sophos;i="5.60,285,1549929600"; d="scan'208,217";a="254754552"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 20:28:37 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2TKSY4c002722 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 20:28:36 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 16:28:33 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Fri, 29 Mar 2019 16:28:33 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Chris Lonvick <lonvick.ietf@gmail.com>
CC: "draft-ietf-netconf-subscribed-notifications.all@ietf.org" <draft-ietf-netconf-subscribed-notifications.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: SECDIR Review of draft-ietf-netconf-subscribed-notifications
Thread-Index: AQHU43PW5soMZq4crkeR6IEFuDhoW6Yd3mfggAVvWgD//8dN9Q==
Date: Fri, 29 Mar 2019 20:28:33 +0000
Message-ID: <1e8e012b-4917-482e-bfad-8c834e1cb503@email.android.com>
References: <5C99813D.9070401@gmail.com> <56b8c323f2284ce1bee2d6083898b017@XCH-RTP-013.cisco.com>, <5C9E7742.2080701@gmail.com>
In-Reply-To: <5C9E7742.2080701@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_1e8e012b4917482ebfad8c834e1cb503emailandroidcom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0xQxsNaJdnJnAjZ83LHFNMezPs4>
Subject: Re: [secdir] SECDIR Review of draft-ietf-netconf-subscribed-notifications
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 20:28:44 -0000

Hi Chris,
I will make the two tweaks as you requested.
Eric

On Mar 29, 2019 3:51 PM, Chris Lonvick <lonvick.ietf@gmail.com>; wrote:
Hi Eric,

On 3/26/19 8:35 AM, Eric Voit (evoit) wrote:
Hi Chris,

Thanks very much for the review and comments.  Some thoughts in-line...

From: Chris Lonvick <lonvick.ietf@gmail.com><mailto:lonvick.ietf@gmail.com>
Sent: Monday, March 25, 2019 9:33 PM
To: draft-ietf-netconf-subscribed-notifications.all@ietf.org<mailto:draft-ietf-netconf-subscribed-notifications.all@ietf.org>; secdir@ietf.org<mailto:secdir@ietf.org>; iesg@ietf.org<mailto:iesg@ietf.org>
Subject: SECDIR Review of draft-ietf-netconf-subscribed-notifications

Hello,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready With Nits.

This is not an area that I'm very familiar with so I skimmed the draft and reviewed the Security Considerations section. Overall, the document appears to be well constructed and well written.

RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct thought about a Security Considerations section is that it should describe threats to the protocol and/or the implementation, and either ways to thwart them, or state that some threats are beyond the scope of the threat model. While the authors of the ID have been thorough in the rest of the specification, they may have gone a bit outside what is needed for a Security Considerations section. Below are some comments that the authors may wish to consider. And it's OK with me if they disregard my comments as I think the document is Ready anyway.



5.4.  Security Considerations
CML>>> I'm not sure that the following paragraph is describing a threat or mitigation. While it is good information, perhaps it belongs elsewhere? Or, if there's a threat there, could it be specifically described?

   One subscription "id" can be used for two or more receivers of the

   same configured subscription.  But due to the possibility of

   different access control permissions per receiver, it cannot be

   assumed that each receiver is getting identical updates.
<eric> It is neither a threat, nor a mitigation.  It is actually implementation guidance that different access control permissions for different configured receivers will result in a different experience for each receiver.  If you think that this guidance is preferable within Section 5.2 "Implementation Considerations", we can move it there.
CML>>> I think it would be better there.


CML>>> In the following paragraph, I think you're describing a threat and a remedy tactic. Perhaps you could delineate them by adding, "To counter this," as the start to the second sentence.

   With configured subscriptions, one or more publishers could be used

   to overwhelm a receiver.  Notification messages SHOULD NOT be sent to

   any receiver which does not support this specification.  Receivers

   that do not want notification messages need only terminate or refuse

   any transport sessions from the publisher.
<eric> This is a good suggestion.  The proposed text has been added.


CML>>> Again, I'm not sure that the following paragraph is describing a threat or a remedy.

   When a receiver of a configured subscription gets a new

   "subscription-started" message for a known subscription where it is

   already consuming events, the receiver SHOULD retrieve any event

   records generated since the last event record was received.  This can

   be accomplish by establishing a separate dynamic replay subscription

   with the same filtering criteria with the publisher, assuming the

   publisher supports the "replay" feature.
<eric> How about the following text to address your threat/remedy comment...

CML>>> Very small changes to the below just for clarification.
When a receiver of a configured subscription gets a new "subscription-started" message for a known subscription where it is already consuming events, it may indicate that an attacker has done something that has momentarily disrupted receiver connectivity. To acquire events lost during this interval, the receiver SHOULD retrieve any event records generated since the last event record was received.  This can be accomplished by establishing a separate dynamic replay subscription with the same filtering criteria with the publisher, assuming the publisher supports the "replay" feature.

Looks good.
Best regards,
Chris

Eric


The rest of the security considerations section is appropriately describing protections for data nodes that may be susceptible to misuse. Best regards, Chris