Thanks for your review, Robert and the changes, Tal! Jari
On 16 Sep 2015, at 14:38, Robert Sparks <rjspa...@nostrum.com> 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:deweast...@yahoo.com] >> 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 <rjspa...@nostrum.com> >> To: General Area Review Team <gen-art@ietf.org>; "i...@ietf.org" >> <i...@ietf.org>; draft-mm-netconf-time-capability....@ietf.org >> 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 > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
