Last Call Review of draft-ietf-dnsop-cookies-07
review-ietf-dnsop-cookies-07-opsdir-lc-romascanu-2015-12-22-00

Request Review of draft-ietf-dnsop-cookies
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-14
Requested 2015-12-04
Draft last updated 2015-12-22
Completed reviews Genart Last Call review of -07 by Peter Yee (diff)
Genart Telechat review of -09 by Peter Yee (diff)
Secdir Last Call review of -07 by Yoav Nir (diff)
Secdir Telechat review of -08 by Yoav Nir (diff)
Opsdir Last Call review of -07 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-dnsop-cookies-07-opsdir-lc-romascanu-2015-12-22
Reviewed rev. 07 (document currently at 10)
Review result Has Nits
Review completed: 2015-12-22

Review
review-ietf-dnsop-cookies-07-opsdir-lc-romascanu-2015-12-22






Hi,




 




I have reviewed draft-ietf-dnsop-cookies-07.txt as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational
 aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.




 




The I-D describes DNS cookies – a light DNS transaction security mechanism that provides improved but limited protection to DNS servers and clients against a number threats described in the document.





 




I believe the document is 'Almost Ready' for publication. The document is well-written, the content is clear and seems accurate. Better detailing some of the operational issues can improve the quality of the document, but none of the
 comments below is a show-stopper. 




 




Below please find my RFC 5706 review. 




 




1.  Has deployment been discussed?  See Section 2.1.




 




       *  Does the document include a description of how this protocol




          or technology is going to be deployed and managed?




 




       *  Is the proposed specification deployable?  If not, how could




          it be improved?




 




       *  Does the solution scale well from the operational and




          management perspective?  Does the proposed approach have any




          scaling issues that could affect usability for large-scale




          operation?




 




       *  Are there any coexistence issues?




 




Section 7 is named ‘Deployment;, but in fact it deals with interoperability and backward compatibility. I do not believe that there are deployment issues with DNS cookies (scalability, coexistence) but it would be good to explicitly state this. At the end of this review I am making a proposal concerning the re-editing of Section 7, including change of name. 




 




   2.  Has installation and initial setup been discussed?  See




       Section 2.2.




 




       *  Is the solution sufficiently configurable?




 




       *  Are configuration parameters clearly identified?




 




       *  Are configuration parameters normalized?




 




       *  Does each configuration parameter have a reasonable default




          value?




 




       *  Will configuration be pushed to a device by a configuration




          manager, or pulled by a device from a configuration server?




 




       *  How will the devices and managers find and authenticate each




          other?




 




No. Installation and initial setup are not explicitly described. I assume that the installation is no more complicated than an update of the DNS servers and clients software. There is no need for synchronization, as interoperability is ensured at lower security protection levels. It would be good to state these. I also assume that the configuration parameters and timers described in Section 5.5 are the ones recommended at initial setup. This is not described in the document either. 




 




   3.  Has the migration path been discussed?  See Section 2.3.




 




       *  Are there any backward compatibility issues?




 




This is not a new version of the protocol, but an optional incremental optimization. Backwards compatibility is described in Section 7. 




 




   4.  Have the Requirements on other protocols and functional




       components been discussed?  See Section 2.4.




 




       *  What protocol operations are expected to be performed relative




          to the new protocol or technology, and what protocols and data




          models are expected to be in place or recommended to ensure




          for interoperable management?




 




No such requirements are discussed – there does not seem to be issues.




 




   5.  Has the impact on network operation been discussed?  See




       Section 2.5.




 




       *  Will the new protocol significantly increase traffic load on




          existing networks?




 




       *  Will the proposed management for the new protocol




          significantly increase traffic load on existing networks?




 




       *  How will the new protocol impact the behavior of other




          protocols in the network?  Will it impact performance (e.g.,




          jitter) of certain types of applications running in the same




          network?




 




       *  Does the new protocol need supporting services (e.g., DNS or




          Authentication, Authorization, and Accounting - AAA) added to




          an existing network?




 




The impact on network performance is discussed in section 2 which describes the benefits of implementing DNS cookies in the context of specific threats. The impact of using simpler and more complex cookies mechanisms on clients and servers is not discussed, and it would be good to add such information as well as the possible trade-offs/ 




 




   6.  Have suggestions for verifying correct operation been discussed?




       See Section 2.6.




 




       *  How can one test end-to-end connectivity and throughput?




 




       *  Which metrics are of interest?




 




       *  Will testing have an impact on the protocol or the network?




 




There is one recommendation about including in implementations counters of occurrences of events like silence discards. The location of this recommendation is quite odd (section 1.2 – Terminology)




 




   7.  Has management interoperability been discussed?  See Section 3.1.




 




       *  Is a standard protocol needed for interoperable management?




 




       *  Is a standard information or data model needed to make




          properties comparable across devices from different vendors?




 




N/A




 




   8.  Are there fault or threshold conditions that should be reported?




       See Section 3.3.




 




       *  Does specific management information have time utility?




 




       *  Should the information be reported by notifications?  Polling?




          Event-driven polling?




 




       *  Is notification throttling discussed?




 




       *  Is there support for saving state that could be used for root




          cause analysis?




 




N/A




 




   9.  Is configuration discussed?  See Section 3.4.




 




       *  Are configuration defaults and default modes of operation




          considered?




 




       *  Is there discussion of what information should be preserved




          across reboots of the device or the management system?  Can




          devices realistically preserve this information through hard




          reboots where physical configuration might change (e.g., cards




          might be swapped while a chassis is powered down)?




 




Yes –  section 5.5




 




One more comment. There are a few places where information on operational issues can be found, and a few more may be missing as per the comments above. I suggest re-editing section 7 and changing its name from
 ‘Deployment’ to ‘Operational Considerations’. The current text can stay and other items be added (like event counters, initial set-up, configuration). Again, these edits are not show-stoppers from my perspective but introducing them can make the document easier
 to read and more useful to operators. 




 




I hope this helps. 




 




Regards,




 




Dan