Skip to main content

Last Call Review of draft-ietf-karp-isis-analysis-04

Request Review of draft-ietf-karp-isis-analysis
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-07-07
Requested 2015-06-08
Authors Uma Chunduri , Albert Tian , Wenhu Lu
I-D last updated 2015-07-13
Completed reviews Genart Last Call review of -04 by Brian E. Carpenter (diff)
Genart Last Call review of -06 by Brian E. Carpenter (diff)
Secdir Last Call review of -04 by Takeshi Takahashi (diff)
Opsdir Last Call review of -04 by Tina Tsou (Ting ZOU) (diff)
Assignment Reviewer Tina Tsou (Ting ZOU)
State Completed
Request Last Call review on draft-ietf-karp-isis-analysis by Ops Directorate Assigned
Reviewed revision 04 (document currently at 07)
Result Not ready
Completed 2015-07-13

Dear all,

I was asked to do a OPSDIR review of 


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


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


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



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:


      Sequence Number packet

Should you s/packet/Packet/?

Thank you,