[secdir] secdir review of draft-ietf-rtgwg-lne-model-05

Taylor Yu <tlyu@mit.edu> Wed, 07 February 2018 00:40 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024D512711A; Tue, 6 Feb 2018 16:40:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 sZ2QSShu3655; Tue, 6 Feb 2018 16:40:19 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 D45E8126DFB; Tue, 6 Feb 2018 16:40:15 -0800 (PST)
X-AuditID: 1209190e-449ff70000006d70-a3-5a7a4aedc1b3
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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 94.F9.28016.DEA4A7A5; Tue, 6 Feb 2018 19:40:14 -0500 (EST)
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 w170eCRN015137; Tue, 6 Feb 2018 19:40:13 -0500
Received: from localhost (nyc-02.triskelion.com [162.243.175.178]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w170eBYC011609; Tue, 6 Feb 2018 19:40:12 -0500
From: Taylor Yu <tlyu@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtgwg-lne-model.all@ietf.org
Date: Wed, 07 Feb 2018 00:40:10 +0000
Message-ID: <ldva7wl8wet.fsf@ubuntu-1gb-nyc1-01.localdomain>
Lines: 57
MIME-Version: 1.0
Content-Type: text/plain
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUixCmqrfvOqyrKYE2ExYfnuxgtZvyZyGzx YeFDFgdmjyVLfjIFMEZx2aSk5mSWpRbp2yVwZWxbt4itYL1oxZ+129gbGLcIdjFyckgImEgc WTiXvYuRi0NIYDGTxPNFH1kgnA2MEqcO9rJBOF8ZJZoXPQdyODjYBOQkLt8KBukWEfCWWH1g HyOILSxgLnF8+XkWEJtFQFWi6+BrVhCbV8BG4svkSWA1PAKcErOn9rBBxAUlTs58AlbPLCAh cfDFC+YJjDyzkKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGusl5tZopeaUrqJERwu knw7GCc1eB9iFOBgVOLhvbG2MkqINbGsuDL3EKMkB5OSKG/qlIooIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK8QZuAynlTEiurUovyYVLSHCxK4rzuJtpRQgLpiSWp2ampBalFMFkZDg4lCd54 z6ooIcGi1PTUirTMnBKENBMHJ8hwHqDhEiA1vMUFibnFmekQ+VOMxhw3XrxuY+aYtuxNG7MQ S15+XqqUOG+bB1CpAEhpRmke3DRQzC/6vH7TK0ZxoOeEeSeADOQBpgu4ea+AVjEBrboRBPJH cUkiQkqqgXFbbnFPwG73FQI+tvvWx1iU8M0N9Om+YSqlGnGx56vlxejfxzUZnGc+zXiSGfnI N+SfwpWmO/oRlQGqCbeTzm30y9DNaXAzfVPhcjOjMjLQKffHoyl6S9qaXfP5fzmaf2ctUXt8 cn3lNfuHJVqCn3+lidxt+1YrM7fzhN6+6ZKCEozC4frGSizFGYmGWsxFxYkA3EYdrNQCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_DgykCP7DJgFlDqbaRdpMlvExyU>
Subject: [secdir] secdir review of draft-ietf-rtgwg-lne-model-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2018 00:40:21 -0000

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

I agree somewhat with the Major Concerns in Russ Housley's Gen-ART
review
https://datatracker.ietf.org/doc/review-ietf-rtgwg-lne-model-05-genart-lc-housley-2018-01-20/
although I disagree that it makes the document Not Ready.

> Major Concerns:
>
> Section 4 listed three data nodes that are sensitive or vulnerable:
>    -  /logical-network-elements/logical-network-element
>    -  /logical-network-elements/logical-network-element/managed
>    -  /if:interfaces/if:interface/bind-lne-name
>
> All three of them deserve a bit more discussion, although the middle
> one is covered in much more detail than the other two.  If a bad actor
> gets "unauthorized access" is there something more specific about each
> of these that can be said?  The characterization of "network
> malfunctions, delivery of packets to inappropriate destinations, and
> other problems" seems very broad.  Consequences that are specific to
> these data nodes would be more helpful to the reader.

My limited understanding is that there is a lot of variation in the
security impact among specific equipment models and deployment
scenarios.  Therefore, they would likely need to be analyzed on a
case-by-case basis.  Perhaps there should be Security Considerations
text to this effect, maybe with some broad guidance about how to do such
an analysis?

For example, does changing the "bind-lne-name" of an interface have the
effect of making it unavailable to the LNE it was previously associated
with, while providing the new LNE with an unconfigured new interface?
Or does it also carry some configuration or routing state from the
former LNE with it to the new LNE?  The latter might have a greater
security impact.

This final paragraph in the Security Considerations of this document
seems copied almost verbatim from that of RFC 8022:

>    Unauthorized access to any of these lists can adversely affect the
>    security of both the local device and the network.  This may lead to
>    network malfunctions, delivery of packets to inappropriate
>    destinations, and other problems.

That seems to have been acceptable for RFC 8022, but perhaps we should
do better here?  Or do we follow the precedent that this level of
detail in the Security Considerations of YANG specifications is
acceptable?

Best regards,
-Taylor