Subject: [secdir] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

From: David Waltermire <[email-masked]>
Date: Tue, 25 Sep 2018 12:13:56 -0700

Reviewer: David Waltermire
Review result: Has Issues

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?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Sep 2018 20:45:03 +0000

David -

Thanx for the review.
A new version of the draft (17) has been published to address your comments - subject to my responses below.

> -----Original Message-----
> From: David Waltermire <[email-masked]>
> Sent: Tuesday, September 25, 2018 12:14 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-isis-segment-routing-
> [email-masked]
> Subject: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> 
>  Document editors and WG chairs should treat these comments just like any
> other last call 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.
> 
[Les:] Section 1.2 does include the standard boilerplate for RFC 2119/RFC8174.

I checked all the lower case uses of "may" and they are intentional.
There was one instance of "should" that I changed to uppercase.

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

> Para 1: s/to insure/to ensure/

[Les:] Done.

> 
> 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.
>
[Les:] I disagree. Section 6 is defining exactly what should go into the new IANA registry.
The definition of "absence" is something that will have to be provided in the documents which define new MSD-types, but that will NOT be captured in the registry so including this in Section 6 isn’t appropriate.

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

[Les:] Again - Section 6 is defining what will go into the registry. The registry will reference the document - not a specific section of the document.

> 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.
> 
[Les:] I have changed the text to "Experimental Use".
I think the rest of your comment is addressed by RFC 8126 - which is referenced.

> 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
[Les:] IS-IS registries are typically Expert Review. This derives from considerations related to the liason with ISO JTC 1/SC6 (RFC 3563).
OSPF registries are typically Standards Action.

As IGP Parameters was defined by draft-ietf-ospf-segment-routing-extensions, it is Standards Action.
But as MSD-Types is being defined in an IS-IS draft...

Please learn to live with this.
It isn’t a significant issue in my view.

> 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?
> 

[Les:] The integrity mechanism is (as you point out) discussed in the Security section of RFC 7981 - which is referenced in the Security Section of this document.
The introduction of a new TLV does not alter the integrity mechanism requirements.

    Les

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 16:11:04 -0500

> A new version of the draft (17) has been published to address your comments - subject to my responses below.

Just in time for me to see the updated version for my IESG review; thanks.

> The definition of "absence" is something that will have to be provided in the documents which define new MSD-types, but that will NOT be captured in the registry so including this in Section 6 isn’…

I think a good way to think about this is as giving guidance to the
Experts, that they should not approve registration requests that fail to
provide this information along with the request.  Guidance for the Experts
is appropriate in the IANA Considerations section.
(Also, my understanding is that IANA prefers to have a more explicit
template for new registrations to follow, though I should not try to speak
for them.)

> [Les:] Again - Section 6 is defining what will go into the registry. The registry will reference the document - not a specific section of the document.

The contents of the "Reference" column for Value 1 can refer to a specific
section of a document, surely?

> The introduction of a new TLV does not alter the integrity mechanism requirements.

My read of 7981 is that "there are these existing integrity protection
mechanisms; when the consequences of modification are bad, use them".
So there is not necessarily a need for each TLV to provide its own internal
integrity scheme, as Les notes.

-Benjamin

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Sep 2018 22:59:50 +0000

Benjamin -

Responses nline.

> From: Benjamin Kaduk <[email-masked]>
> Sent: Wednesday, September 26, 2018 2:11 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: David Waltermire <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> 
> > A new version of the draft (17) has been published to address your
> comments - subject to my responses below.
> 
> > > 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.
> > >
> > > My apologies for the late review on this draft. Overall I found this
> > > document to be well-written, and concise.
> > >
> > > General Comments:
> > >
> > > 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.
> > >
> > [Les:] Done
> >
> > > Specific comments:
> > >
> > > Section 1:
> > >
> > > 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.
> > >
> > The definition of "absence" is something that will have to be provided in
> the documents which define new MSD-types, but that will NOT be captured
> in the registry so including this in Section 6 isn’t appropriate.
> 
> I think a good way to think about this is as giving guidance to the Experts, that
> they should not approve registration requests that fail to provide this
> information along with the request.  Guidance for the Experts is appropriate
> in the IANA Considerations section.
> template for new registrations to follow, though I should not try to speak for
> them.)
> 

[Les:] The reason we use "experts" is because we know/expect them to be familiar with the documents which define the TLVs (unlike a "general IETF reader" whose familiarity with the subject matter may vary).
Repeating what is said in Section 4 in Section 6 only makes sense if you think the "expert" only reads IANA sections. Such a person would not be an expert IMO. :-)

   Les

> > [Les:] Again - Section 6 is defining what will go into the registry. The registry
> will reference the document - not a specific section of the 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.
> > >
> > > "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.
> > >
> > [Les:] IS-IS registries are typically Expert Review. This derives from
> considerations related to the liason with ISO JTC 1/SC6 (RFC 3563).
> > > 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?
> > >
> >
> > [Les:] The integrity mechanism is (as you point out) discussed in the
> Security section of RFC 7981 - which is referenced in the Security Section of
> this document.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 18:06:21 -0500

> Repeating what is said in Section 4 in Section 6 only makes sense if you think the "expert" only reads IANA sections. Such a person would not be an expert IMO. :-)

I suspect that the experts would prefer to receive a high proportion of
requests that meet the criteria the experts are going to apply, rather than
constantly telling people they need to go fix the same thing and come back.
It's best practice to be clear about what is required for a successful
registration.

-Benjamin

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Sep 2018 23:24:31 +0000

Benjamin -

Please review https://tools.ietf.org/html/rfc8126#section-1.1

In particular (emphasis added):

" The purpose of having a dedicated IANA Considerations section is to

   provide a single place to collect clear and concise information and

   instructions for IANA.  Technical documentation should reside in

   other parts of the document…”

I think what you propose is not consistent with the intent of the IANA section.

Thanx.

    Les

> Sent: Wednesday, September 26, 2018 4:06 PM

> > > From: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>

> > > To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>

> > > Cc: David Waltermire <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;

> > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> > > [email-masked]<mailto:[email-masked]>

> > > Subject: Re: Secdir last call review of

> > > draft-ietf-isis-segment-routing-msd-16

> > > On Wed, Sep 26, 2018 at 08:45:03PM +0000, Les Ginsberg (ginsberg)

> wrote:

> > > Just in time for me to see the updated version for my IESG review;

> thanks.

> > > > > From: David Waltermire <[email-masked]<mailto:[email-masked]>>

> > > > > To: [email-masked]<mailto:[email-masked]>

> > > > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> > > > > draft-ietf-isis-segment-routing- [email-masked]<mailto:[email-masked]>

> > > > > Subject: Secdir last call review of

> > > > > draft-ietf-isis-segment-routing-msd-16

> > > > > 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.

> > > > > My apologies for the late review on this draft. Overall I found

> > > > > this document to be well-written, and concise.

> > > > > 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.

> > > > [Les:] Section 1.2 does include the standard boilerplate for RFC

> > > 2119/RFC8174.

> > > > > Minor nit: There is some inconsistency in the use of "MSD-Type"

> > > > > (the

> > > > > The last paragraph establishes a requirement on the registration

> > > > > of an MSD Type to define what the absence of a given MSD Type

> means.

> > > > > echoed in the registration information in section 6 to make sure

> > > > > it is not

> > > > [Les:] I disagree. Section 6 is defining exactly what should go

> > > > into the new

> > > IANA registry.

> > > > The definition of "absence" is something that will have to be

> > > > provided in

> > > the documents which define new MSD-types, but that will NOT be

> > > captured in the registry so including this in Section 6 isn’t appropriate.

> > > Experts, that they should not approve registration requests that

> > > fail to provide this information along with the request.  Guidance

> > > for the Experts is appropriate in the IANA Considerations section.

> > > template for new registrations to follow, though I should not try to

> > > speak for

> > [Les:] The reason we use "experts" is because we know/expect them to be

> familiar with the documents which define the TLVs (unlike a "general IETF

> reader" whose familiarity with the subject matter may vary).

> > Repeating what is said in Section 4 in Section 6 only makes sense if

> > you think the "expert" only reads IANA sections. Such a person would

> > not be an expert IMO. :-)

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 20:20:52 -0500

> I think what you propose is not consistent with the intent of the IANA section.

What about Section 1.1, "guidance describing the conditions under which new
values should be assigned [...] is needed", or section 1.3's checklist:

   7.  If you're using a policy that requires a designated expert
       (Expert Review or Specification Required), understand Section 5
       and provide review guidance to the designated expert (see
       Section 5.3).

Section 4.5 (Expert Review) even goes into more detail, though I'll stop
quoting now.

-Benjamin

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Sep 2018 05:26:19 +0000

Benjamin -

It is not my intent to engage in a debate with you.

I serve as Designated Expert for a number of IS-IS registries. I consider it my responsibility to understand the technical content of the drafts which make changes to the registries for which I serve in this role. I do not look for or expect technical content in the IANA sections - I only expect them to be accurate in terms of the changes requested/completed to the registries.

I have no doubt that we still disagree. If there is some consensus to make changes I will certainly listen - but if left up to me I would leave the IANA section as is.

   Les

> Sent: Wednesday, September 26, 2018 6:21 PM
> What about Section 1.1, "guidance describing the conditions under which
> new values should be assigned [...] is needed", or section 1.3's checklist:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Sep 2018 06:41:18 -0500

Hi Les,

I'm happy to leave this question to Alvaro's judgment; as you know, I
included it in the non-blocking portion of my ballot position.

I appreciated the dedication and rigor you put into your service as a DE,
and hope that all DEs can do the same.

Thanks,

Benjamin