Last Call Review of draft-ietf-isis-segment-routing-msd-16
review-ietf-isis-segment-routing-msd-16-secdir-lc-waltermire-2018-09-25-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is Ready with (minor) issues

My apologies for the late review on this draft. Overall I found this document
to be well-written, and concise.

General Comments:

This document uses a mix of case around RFC2119 language (e.g., MAY may). You
should use text from RFC8174 to indicate that lowercase versions of the
keywords are not normative, or adjust the case of the lowercase words to ensure
there is no confusion.

Minor nit: There is some inconsistency in the use of "MSD-Type" (the value) and
"MSD type" (the concept). Suggest cleaning this up.

Specific comments:

Section 1:

Para 1: s/to insure/to ensure/

Section 4:

The last paragraph establishes a requirement on the registration of an MSD Type
to define what the absence of a given MSD Type means. This is an important
requirement that must be addressed during registration of new MSD Types. IMHO,
this requirement should be echoed in the registration information in section 6
to make sure it is not overlooked.

Section 6:

The "Base MPLS Imposition MSD" should reference section 5 of this document.

The registration for "Experimental" should be marked as "Reserved for
Experimental Use" or just "Experimental Use" to align with RFC8126. RFC8126
states that "it is not appropriate for documents to select explicit values from
registries or ranges with this policy". It might be good to add a note
alongside the one on "Designated Experts" indicating that values from this
range are not assignable.

The "Interior Gateway Protocol (IGP) Parameters" registry has the "Standards
Action" policy assigned. The new "IGP MSD Types" sub-registry does not have the
"Standards Action" policy. Was this intentional? If so, this should be
explained. This is also confusing since the guidance for expert reviewers in
RFC7370 implies that registrations are based on the "RFC Required" or
"Standards Action" policies.

Section 7:

The security considerations in RFC7981 ask that security considerations around
the disclosure and modification of this type of information is described in
extensions. This has been done, but RFC7981 also asks that an integrity
mechanism be provided if there is a high risk resulting from modification of
capability information. There is no discussion in the document's security
consideration about the nature of risk in this case and why an integrity
mechanism is not needed. It seems like false information can be used to cause a
denial of service regarding computed paths. This sounds like having this happen
could be bad. I am not an expert on routing protocols, so I am not sure if this
is an issue. How bad and likely is such a risk?