Subject: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 15 May 2019 12:38:33 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Per Section 9, [draft-ietf-netconf-netconf-event-notifications] and
[draft-ietf-netconf-subscribed-notifications] mention concerns about a
“malicious or buggy subscriber sends a number of establish-subscription
requests” in their Security Considerations.  Is that not a concern here too?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 3.1.  “A subscriber can then attempt to re-establish the dynamic
subscription by using the procedure described in Section 3.”  This seems like a
circular reference.  This guidance (to go read Section 3) is being given in
Section 3.1 (which is inside Section 3).

(2) Section 3.3.  Missing word.
s/requests with publisher/requests with the publisher/

(3) Section 3.4.  “This initiates the publisher to initiate the flow …”.  I
stumbled over the double use of “initiate”.  Do you mean “This signals to the
publisher to initiate the flow …”?

(4) Section 3.4 suggests that NACM/related methods should be used to authorize
“modify-subscription, resync-subscription and delete-subscription” RPCs. 
Section 9, Security Considerations, says “Therefore, even if an attacker
succeeds in guessing the subscription URI, a RESTCONF username [RFC8040] with
the required administrative permissions must be used to be able to access or  
modify that subscription.”  Is there a reason not to say the obvious thing in
the Security Considerations that these particular RPCs should be protected
(with NACM/related methods like was stated in Section 3.4).

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 16 May 2019 17:47:32 +0000

Hi,

Thank you for the review, please see inline.

On 2019-05-15, 3:38 PM, "Roman Danyliw via Datatracker" <[email-masked]> wrote:

    
    
    Per Section 9, [draft-ietf-netconf-netconf-event-notifications] and
    [draft-ietf-netconf-subscribed-notifications] mention concerns about a
    “malicious or buggy subscriber sends a number of establish-subscription
    requests” in their Security Considerations.  Is that not a concern here too?
<RR> Good catch. I can add similar text to the Security Considerations of this draft, would the following text be satisfactory?
    If a buggy or
    compromised RESTCONF subscriber sends a number of "establish-
    subscription" requests, then these subscriptions accumulate and may
    use up system resources.  In such a situation, the
    publisher MAY also suspend or terminate a subset of the active
    subscriptions from that RESTCONF subscriber in order to reclaim resources
    and preserve normal operation for the other subscriptions.    

<RR> Ack, will change reference to 3.4.
    
<RR> Ok.
    
<RR> Yes, will make the change.    
<RR> We got similar comments from another reviewer. We will be adding text to the Security Considerations.

Regards,
Reshad.