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

[Robert Sparks <[e-mail]>]

Sorry - I didn't pick that up when I looked at the graphic -05 to -08 diff.
This text is ok, especially given (ii).

RjS

On 9/16/15 1:29 AM, Tal Mizrahi wrote:
>
> 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.
>