Return-Path: 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 234AA12019F; Mon, 25 Mar 2019 18:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 q7ElKtvdKsHt; Mon, 25 Mar 2019 18:32:48 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BA8120193; Mon, 25 Mar 2019 18:32:48 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id z9so5019621ywd.6; Mon, 25 Mar 2019 18:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=gCx5+1cUo0j1TmAOqIJrVI6zsFf9SMD0rk6YTl6bCi0=; b=qnaAnr+CXExtegDVvom+CElwXvWY7h8imDHhtLwL3fseIuIJBpAazl1QZDRSjoa4o0 I2BIJ7X4wXNW5SgNnA0aFJkNAEJARIh6QFsfFVESEZEbfaBEKj6NCi6XTjWApWFSuDax cE7b0WICMkQpsE0t10LdVlfltUzU6sJ71iNT13xBH5aNWPxoY27s7P1ckk0w3/2slLmu VJJ8FtubaqjRn2VD6ynzkELKN+RZlf39ZrfJHtKgzso+ccorRo3gMDQGsAygPsrm/3Cw JtSIIuTInYNeQXaFKzY2VyFs/L25Xh+fZoDOB2M/G2z+9wOlwQjq1uzCHkBWfiBQv1Qz D6Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=gCx5+1cUo0j1TmAOqIJrVI6zsFf9SMD0rk6YTl6bCi0=; b=m4zpa742RO+TDFXzP2cS2TpGADqSr7MAcE8sOLRfkSEceqQcLfAD7Ub/AVFMaw/KJo VQ+Em3SNlbpwexXDK/7vDmgbNOgMq0N/rzL8W7tyPOuXOrV7eS+iNQB8+8iVIsz0ClXb GGTE752cxNL4pzV/cz2UmbxNEMUVL0VxbHCk01GOqdDWO6UXqnC186LYnkNNuN9nhDuD nCxmEBkQTERPwecD//dsLHB54Ke8bJSZelw1P6Am9U00tPMciMoCORkLZVwgffFl7FHw eF3w8+TlPdHsqzieKq/WuGeluOyLnB4W2IfA/Vj+lq3L6J1vR7mJ/C8oiaY1QrFNvpKr JvRg== X-Gm-Message-State: APjAAAUdQCcfATixxlI08IG3fdf41C8xev1NtwPKzojzpFqbUQ2ZJxeU ro5ilAiT4PG9T1pNQb0wYwLTb9XI X-Google-Smtp-Source: APXvYqz7GWreWaqUrV9l54MpJ5ahzKRd4aGsLuT1Lmj9IpVFOILY/4EVYS8SQQgJhme3xSP8Uwki8A== X-Received: by 2002:a81:2257:: with SMTP id i84mr24293541ywi.394.1553563967045; Mon, 25 Mar 2019 18:32:47 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:993a:88b0:80cf:2de1]) by smtp.googlemail.com with ESMTPSA id 142sm6013712ywl.31.2019.03.25.18.32.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 18:32:46 -0700 (PDT) To: draft-ietf-netconf-subscribed-notifications.all@ietf.org, "secdir@ietf.org" , "iesg@ietf.org" From: Chris Lonvick Message-ID: <5C99813D.9070401@gmail.com> Date: Mon, 25 Mar 2019 20:32:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060709000504010808020407" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 01:32:50 -0000 This is a multi-part message in MIME format. --------------060709000504010808020407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. 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. 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. The rest of the security considerations section is appropriately describing protections for data nodes that may be susceptible to misuse. Best regards, Chris --------------060709000504010808020407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 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.
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.
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.
The rest of the security considerations section is appropriately describing protections for data nodes that may be susceptible to misuse. Best regards, Chris --------------060709000504010808020407--