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

[Jari Arkko <[e-mail]>]

Thanks for your review, Robert and the changes, Tal!

Jari

On 16 Sep 2015, at 14:38, Robert Sparks <[e-mail]> wrote:

> 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]>
>> To: General Area Review Team <[e-mail]>; "[e-mail]" <[e-mail]>; [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.
>> 
>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art