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

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 21:11 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03EA12F1A2; Wed, 26 Sep 2018 14:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM20XSbfzCWz; Wed, 26 Sep 2018 14:11:16 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF591294D7; Wed, 26 Sep 2018 14:11:12 -0700 (PDT)
X-AuditID: 1209190f-079ff7000000662b-35-5babf5ef0678
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B6.50.26155.FE5FBAB5; Wed, 26 Sep 2018 17:11:11 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w8QLB90J018021; Wed, 26 Sep 2018 17:11:10 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8QLB4NX017333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 17:11:07 -0400
Date: Wed, 26 Sep 2018 16:11:04 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: David Waltermire <david.waltermire@nist.gov>, "secdir@ietf.org" <secdir@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-isis-segment-routing-msd.all@ietf.org" <draft-ietf-isis-segment-routing-msd.all@ietf.org>
Message-ID: <20180926211104.GQ24695@kduck.kaduk.org>
References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <a3e1e6216dbc46db8c717d5dd2946ea0@XCH-ALN-001.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a3e1e6216dbc46db8c717d5dd2946ea0@XCH-ALN-001.cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrfv+6+pog66LihYbe/6xWXxfr2ix 4c9GdotnG+ezWJx4soLV4sPChywObB5Tfm9k9Viy5CeTx7WTf1kDmKO4bFJSczLLUov07RK4 Mra9O8BesMmoom/GJ/YGxv/qXYycHBICJhKH3mxg6mLk4hASWMwkcXreNlYIZyOjxLnntxlB qoQErjJJPOsPBbFZBFQlzp+Yww5iswmoSDR0X2buYuTgEBEwklj8XBukl1lgOpPEh4PT2EHi wgJ+ElPOiIGYvEDLdjeWQ0ysk/hychcTiM0rIChxcuYTFhCbWUBd4s+8S2ATmQWkJZb/44AI y0s0b53NDGJzCrhKvP+3BqxVVEBZYm/fIfYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXRC83s0QvNaV0EyM4AiT5dzDOafA+xCjAwajEw7th4+poIdbEsuLK 3EOMkhxMSqK8CnuBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4120HyvGmJFZWpRblw6SkOViU xHkntCyOFhJITyxJzU5NLUgtgsnKcHAoSfCe+wLUKFiUmp5akZaZU4KQZuLgBBnOAzT8AkgN b3FBYm5xZjpE/hSjMceLGR0zmDm2nemcwSzEkpeflyolzhsDUioAUppRmgc3DZTEJLL317xi FAd6TphXG5jShHiACRBu3iugVUxAqyb0rABZVZKIkJJqYJzC4LdeLpKxx3Or4JQn/pvKPLcs uXx19Z5Dol4y1nv66hfe9rz26Qlv843wtZsYymvkd2n/Mxfsa30XoTG3X4SRP27uig3L017O OOfqUXxf4BVTbZ9P8vn8rWI7XKe8W2HTVvtdMuiobmaS5qJvVp98xVjE6nZvvpe+pfBg4Yfn X2P9/BY8YVRiKc5INNRiLipOBADGFi5IPQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dHfSZip3YND8NR8r2ZkFtejXMJg>
Subject: Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 21:11:19 -0000

On Wed, Sep 26, 2018 at 08:45:03PM +0000, Les Ginsberg (ginsberg) wrote:
> David -
> 
> Thanx for the review.
> 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.

> > -----Original Message-----
> > From: David Waltermire <david.waltermire@nist.gov>;
> > Sent: Tuesday, September 25, 2018 12:14 PM
> > To: secdir@ietf.org
> > Cc: lsr@ietf.org; ietf@ietf.org; draft-ietf-isis-segment-routing-
> > msd.all@ietf.org
> > Subject: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> > 
> > 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.
> > 
> [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
> 
> > Specific comments:
> > 
> > Section 1:
> > 
> > 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.

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

>  
> > Section 6:
> > 
> > The "Base MPLS Imposition MSD" should reference section 5 of this
> > document.
> 
> [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 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.
> > 
> [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
> > 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).
> 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.

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