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

[Chris Lonvick <[e-mail]>]

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 <[e-mail]>
> *Sent:* Monday, March 25, 2019 9:33 PM
> *To:* [e-mail]; 
> [e-mail]; [e-mail]
> *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
>