Re: [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13

Susan Hares <shares@ndzh.com> Thu, 25 June 2020 13:04 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA23A083A; Thu, 25 Jun 2020 06:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 0QtuJkV3EHlR; Thu, 25 Jun 2020 06:04:20 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3097E3A0833; Thu, 25 Jun 2020 06:04:19 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.22.63;
From: "Susan Hares" <shares@ndzh.com>
To: "'Christian Huitema'" <huitema@huitema.net>, <secdir@ietf.org>
Cc: <draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org>, <i2rs@ietf.org>, <last-call@ietf.org>
References: <159306126401.5613.2130163467049929604@ietfa.amsl.com>
In-Reply-To: <159306126401.5613.2130163467049929604@ietfa.amsl.com>
Date: Thu, 25 Jun 2020 09:04:15 -0400
Message-ID: <005401d64af1$2243a2c0$66cae840$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGr16bjpP16h1NZBzVaEcIfqcfi36k+Liig
Content-Language: en-us
X-Antivirus: AVG (VPS 200624-2, 06/24/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/q5xu2Ep7B_fGOOb_iZXG-RAkCAE>
Subject: Re: [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2020 13:04:22 -0000

Christian:

Thank you for catching the privacy issues.      

I've got a few questions to help the authors scope this change: 

1) Since this is common to all L2 Topologies, can you or the security directorate recommend some text that might be appropriate? 
   If you have recommended text, has this text been reviewed by OPS-DIR and Yang doctors? 

2) Will it be a problem If we write privacy considerations on IEEE specifications? 
3) Do we need to consider the range of deployments of L2
(home, enterprise,  public PBB service, national PBB service, Data centers)


Thank you,  Sue 


-----Original Message-----
From: Christian Huitema via Datatracker [mailto:noreply@ietf.org] 
Sent: Thursday, June 25, 2020 1:01 AM
To: secdir@ietf.org
Cc: draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org; i2rs@ietf.org; last-call@ietf.org
Subject: Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13

Reviewer: Christian Huitema
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 with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document describes a Yang model for representing Link Layer topologies.
Representing such topologies is obviously useful for managing network.
The security section is focused on securing the usage of this information for network management, but does not address potential privacy issues.

The security considerations explain correctly how altering the link layer information could enable attacks against the network. The proposed remedy is access control, implemented using either SSH or TLS. This is fine, although the discussion of TLS authorisation is a bit short. By default, TLS verifies the identity of the server but not that of the client. RFC8040 section 2.5 specifies that "a RESTCONF server SHOULD require authentication based on TLS client certificates. I assume that's the intent, but it might be useful to say so.

On the other hand, the security considerations do not describe privacy issues, and I find that problematic. The proposed information model lists a number of sensitive data, such as for example the MAC addresses of devices.
This information can be misused. For example, applications could assess device location fetching the MAC addresses of local gateways. Third parties could access link local information to gather identities of devices accessing a particular network. Such information is often protected by privacy API in the Operating System, but accessing the Yang module over the network might allow applications to bypass these controls.

Client authentication alone does not necessarily protect against these privacy leaks. A classic configuration error would limit write access to authorized users, but to allow read-only access to most users. This kind of error would allow privacy leaks. Given the sensitive nature of MAC addresses and other identifiers, it is useful to warn against such errors.