Re: [Gen-art] Gen-art Telechat review: draft-mm-netconf-time-capability-08

[Tal Mizrahi <[e-mail]>]

Hi Robert,

> The document doesn't reflect the email discussion we had around how
> certain 3rd parties can cancel commands. I encourage adding at least a
> sentence reminding implementers and experimenting operators to remember
> that they can.

Based on this email discussion we have added the last paragraph of Section 6.2 (see below). Please let us know if you believe this issue should be discussed further.


   This YANG module defines the <cancel-schedule> RPC. This RPC may be
   considered sensitive or vulnerable in some network environments.
   Since the value of the <schedule-id> is known to all the clients that
   are subscribed to notifications from the server, the <cancel-
   schedule> RPC may be used maliciously to attack servers by canceling
   their pending RPCs. This attack is addressed in two layers: (i)
   security at the transport layer, limiting the attack only to clients
  that have successfully initiated a secure session with the server,
   and (ii) the authorization level required to cancel an RPC should be
   the same as the level required to schedule it, limiting the attack
   only to attackers with an authorization level that is equal to or
   higher than that of the client that initiated the scheduled RPC.


Thanks,
Tal.




From: Tal Mizrahi [mailto:[e-mail]]
Sent: Wednesday, September 16, 2015 9:21 AM
To: Tal Mizrahi
Subject: Fw: Gen-art Telechat review: draft-mm-netconf-time-capability-08


----- Forwarded Message -----
From: Robert Sparks <[e-mail]<mailto:[e-mail]>>
To: General Area Review Team <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Sent: Monday, September 14, 2015 11:30 PM
Subject: Gen-art Telechat review: draft-mm-netconf-time-capability-08

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-mm-netconf-time-capability-08
Reviewer: Robert Sparks
Review Date: 14 Sep 2015
IETF LC End Date: past
IESG Telechat date: 17 Sep 2015

Summary: Ready for publication as an Experimental RFC

The changes since -05 address my concerns with allowing cancels to be
scheduled, and dealing with cancels not being processed in time.

The added discussion on how to choose a max-sched-future value is good.
I still would have preferred a hard limit for this experimental period.

The addition of cancelling all pending commands when the submitters
connection closes is a good one.

The document doesn't reflect the email discussion we had around how
certain 3rd parties can cancel commands. I encourage adding at least a
sentence reminding implementers and experimenting operators to remember
that they can.

RjS


On 7/8/15 4:39 PM, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-mm-netconf-time-capability-05
> Reviewer: Robert Sparks
> Review Date: 8 Jul 2015
> IETF LC End Date: 29 Jul 2015
> IESG Telechat date: not yet scheduled
>
> Summary: This draft has open issues to address before publication
>
> This draft adds two separable concepts to netconf
> * Asking for and receiving knowledge of when a command was executed
> * Requesting that a command be executed at a particular time
>
> The utility of the first is obvious, and I have no problems with the
> specification of that part of this extension. Would it be better to
> pull these apart and progress them separately?
>
> The utility of the second would be more obvious if the draft didn't
> limit the time to be "near future scheduling". It punts on most of the
> hard problems with scheduling things outside a very tight range (15
> seconds in the future by default), without motivating the advantages
> of saying "wait until 5 seconds from now before you do this".
>
> So:
>
> Why was 15 seconds chosen? Could you add a motivating example that
> shows why being able to say "now is not good, but 5 seconds from now
> is better" is useful? (Something like having a series of things happen
> as close to simultaneously without the network delay of sending the
> requests impacting how they are separated perhaps?)
>
> Given the punt, why isn't there a statement that sched-max-future MUST
> NOT be configured for more than some small value (twice the default,
> or 30 seconds, perhaps), especially while this is targeted for
> Experimental? Without something like that, I think the document needs
> to talk about more of the issues it is trying to avoid with longer
> term scheduling, even if it doesn't solve those issues. (If I have a
> fast pipe, I can make a server keep a lot of queued requests, eating a
> lot of state, even if the window is only 15 seconds. Pointing to how
> netconf protects against state-exhaustion abuse might be useful).
>
> The security considerations section talks about malicious parties
> attempting to cause sched-max-future to be configured to "a small
> value". Could you more clearly characterize  "small", given that the
> default is 15 seconds?
>
> Even with the near-future limit, there are issues to discuss
> introduced with the ability to cancel a request:
>
> * What prevents a 3rd party from cancelling a request? I think it's
> only that the 3rd party would have to obtain the right id to put in
> the cancel message. If so, the document should talk about how you keep
> eavesdroppers from seeing those ids, and that the servers that
> generate them should make ids that are hard to guess.
>
> * Especially given the near-future limitation, you run a high risk
> that the cancel arrives after the identified request has been
> executed. It's not clear in the current text what the server should
> do. I assume you want the server to reply to the cancel with a "I
> couldn't cancel that" rather than to do something like try to undo the
> request. The document should be explicit.
>
> * The document should explicitly disallow adding <scheduled-time> to
> <cancel-schedule>
>
> One editorial comment: It would help to move the concept of the
> near-future limitation much earlier in the document, perhaps even into
> the introduction and abstract.
>
> And for the shepherding AD: The document has no shepherd or shepherd
> writeup. While a writeup is not required, one would have been useful
> in this case to discuss the history of (lack of) discussion of the
> document on the group's list and the group's reaction to progressing
> as Experimental as an Individual Submission.