Re: [secdir] Early secdir review of c-02 (draft-ietf-netconf-yang-push-00)

[Benoit Claise <[e-mail]>]

Thanks Take,

[bcc'ed the IESG, which was in the initial distribution]
I would like this discussion to take place on the NETCONF mailing list, 
which I added.

Note also that this draft is now a WG document: draft-ietf-netconf-yang-push

Regards, Benoit
> 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.
>
> [overall feeling on this draft]
>
> As an early review, this document is fine.
> I believe the topic is very important.
>
> [overview]
>
> This draft deals with the push mechanism of the YANG datastore's updats.
> The usability of push mechanism is obvious.
> The draft elaborates parameters needed for the mechanism, including filters
> and subscription-config.
>
> [questions]
>
> It was fun to read the article, though I am not that familiar with this
> area.
>
> Here are several clarification questions.
> I would appreciate if you could answer them to deepen my understanding.
>
> 1.
> Let me assue that I send a create-subscription message with the period=500
> parameter. If the server can only send updates with period=1000, what will
> happen?
> Is the subscription declined? Or is the subscription accepted with
> period=1000?
>
> If it is declined, how can I know the supported period value?
> I guess the error response message does not explain the minimum value for
> the period.
>
> 2.
> I guess arbitrary value can be set for stop-time.
> Then, the updates will be sent periodically for very long time, once the
> subscription is accepted.
> I am wondering if we need to check whether the subscriber is still alive
> (whether the subscriber is still the authorized one).
> Would you have any means to check the subscriber status ? (I guess no)
> Or, do we need to specify stop-time that is not that far from now to avoid
> any accident?
>
> I am not sure how sensitive the update information is, so it could be a
> nonsense question...
>
> 3.
> Are you going to use the IANA tables for the values, such as the "encoding"
> field?
>
> 4.
> Regarding the security consideration, I have got the impression that the
> current text focuses on DDoS scenarios.
> How about the false update?
> Malicious entity may send false update to the subscriber.
> The false update may let the subscriber mis-judge the situation and initiate
> some operations.
> Is it going to be a viable concern?
>
>
> Thanks, and kind regards,
> Take
>
>
>
> .
>