Last Call Review of draft-ietf-karp-isis-analysis-04
review-ietf-karp-isis-analysis-04-opsdir-lc-tsou-2015-07-13-00

Dear all,










I was asked to do a OPSDIR review of 

draft-ietf-karp-isis-analysis-06.
















I've read this document. However, I'm not sure it's ready for




publication. More specifically,  most of the document (pages 1-7,




sections 1-2.3.3 seen to be an overview of existing documents) -- and ne




might say that part of the rest of the document still is kind of a




discussion of existing documents. Section 3, which is where the "meat"




is supposed to be, doesn't seem to contain much information, other than




some high level discussion. So I wonder if the contents of this document




warrant the publication of an RFC in the first place. I'd note that if




this document is supposed to be a security assessment of IS-IS, I'd




expect it to be way more lengthy, and more specific when it comes to the




attack vectors (again, this I-D seems to be very/too high-level in this




respect)







That said, below you'll find some technical comments and nits. If we




proceed with the publication process for this document, I'd expect at




least the comments flagged as technical to be discussed/addressed prior




to publication.










**** Technical ****







* Meta: Is there any reason why this document is not e.g. a BCP?







* Section 2.1.1, page 4:




  Since authentication is performed on the LSPs transmitted by an IS,







  rather than on the LSP packets transmitted to a specific neighbor,










Not sure what you mean... Do you mean all nodes must authenticate all




LSPs? -- i.e., it's not clear what you mean.










* Sections 2.3.2 and 2.3.3







Most of the attacks that you describe in Section 2.3.2 are actually DoS




attacks (that's the actual goal). I'd probably even say that spoofing is




usually not a goal in itself, but actually the means for achieving other




goals (whether exploiting IP-address-based trust relationships, or




something else).







* Section 3.1:




This Section contains some "requirements" with RFC2119 keywords.




However, this document is an Informational document, so it shouldn't be




using RFC2119 keywords.













**** Nits ****







* Section 1, page 2:




  This draft summarizes the current state of cryptographic key usage in







  IS-IS protocol and several previous efforts to analyze IS-IS







  security.










s/in IS-IS/in the IS-IS/










* Section 1, page 2:




This includes base IS-IS specification [RFC1195],







  [RFC5304], [RFC5310] and the OPSEC working group document [RFC6039].










s/base IS-IS/the base IS-IS/







Besides, "the opsec wg document" doesn't sound right. PLease refer to




RFC6039 in a different way.










* Section 1, page 3:




  Authors would like to acknowledge all the previous work done in the







  above documents.










Not sure what this means here. I'd say you should probably remove this




sentence. If there's any credit to be give, please do it in the




"Acknowledgements" section.










* Section 1, page 3:




  This document also analyzes applicability of various threats as







  described in [RFC6862] to IS-IS, lists gaps and provide specific










This should be rephrased to:







  This document also analyzes applicability of various threats to




  IS-IS (as described in [RFC6862]), lists gaps and provide specific










* Section 2.1, page 4:




  IS-IS can be provisioned with a per interface, peer-to-peer key for







  IS-IS HELLO PDUs (IIH)










Please s/IS-IS HELLO PDUs (IIH)(IS-IS HELLO (IIH) PDUs/







Besides, "PDU" is not listed in Section 1.2.










* Section 2.1.1 page 4:




with in an area or domain.










s/with in/within/







(there's another instance of this in the same paragraph)










* Section 2.3.1,  page 6:




Partial







      Sequence Number packet










Should you s/packet/Packet/?













Thank you,




Tina