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

Christian Huitema <huitema@huitema.net> Fri, 26 June 2020 04:04 UTC

Return-Path: <huitema@huitema.net>
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 871613A110A for <i2rs@ietfa.amsl.com>; Thu, 25 Jun 2020 21:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 yqc9LfLwLYwO for <i2rs@ietfa.amsl.com>; Thu, 25 Jun 2020 21:04:44 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 8C5B33A1106 for <i2rs@ietf.org>; Thu, 25 Jun 2020 21:04:44 -0700 (PDT)
Received: from xse70.mail2web.com ([66.113.196.70] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jofbR-0017HC-Aj for i2rs@ietf.org; Fri, 26 Jun 2020 06:04:42 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49tNYt4z0Wz2Csd for <i2rs@ietf.org>; Thu, 25 Jun 2020 21:04:34 -0700 (PDT)
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jofbO-0006IO-Iw for i2rs@ietf.org; Thu, 25 Jun 2020 21:04:34 -0700
Received: (qmail 29315 invoked from network); 26 Jun 2020 04:04:32 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <last-call@ietf.org>; 26 Jun 2020 04:04:32 -0000
To: Susan Hares <shares@ndzh.com>, 'Qin Wu' <bill.wu@huawei.com>, secdir@ietf.org
Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org, last-call@ietf.org
References: <B8F9A780D330094D99AF023C5877DABAAD7BAFD7@dggeml531-mbs.china.huawei.com> <002a01d64af8$f07320b0$d1596210$@ndzh.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <15aa8236-ce09-d0b4-5f12-31f10b32387c@huitema.net>
Date: Thu, 25 Jun 2020 21:04:32 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <002a01d64af8$f07320b0$d1596210$@ndzh.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 66.113.196.70
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.70/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.70/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDU1aob+exlALJps7Lzuw5NLgN zB/4Jkrw1eDLcif59fu8jKMpFnng60b5obnfgVz+U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/d/hBjqsxautjlVXfyJaQKbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilUN7TTX3qb0a 8RNcOLCOSd6whjgtKo9vvLdWvMqyXFm2EBrIrZARFugr7XDLx1AroVZb+TQLYJgqAcx9u1zs2n30 lSfuxANzRU5MAZzTOSGBRgFQq3c/LANVGGraFol5H/KY2AXNZGS5G93aGyH8MqMNONNOB63tZ91H 4Bn0Oix6pWbXRABfcPDKZLJzH8ecMJxMPnetLBJMh51NiRRoHIAjibDbwsd8mmY5aab3jt2omiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50sPpk7G/Hl2vUa2qJsqsk4i08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/3DVy4mq6BzBtc67LAwExWlM0JYs>
Subject: Re: [i2rs] [Last-Call] 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: Fri, 26 Jun 2020 04:04:47 -0000

How about adding something like this:

Privacy Considerations

The Yang model for layer 2 topology exposes privacy sensitive information,
for example the MAC addresses of devices. Unrestricted use of such
information
can lead to privacy violations. For example, listing MAC addresses in a
network
allows monitoring of devices and their movements. Location information can
be derived from MAC addresses of network devices, bypassing protection of
location information by the Operating System.

Deployments should mitigate this privacy concerns by limiting access to
the layer 2 topology information. Access to the information should be
restricted to a minimal list of authorized agents, and should require
proper authentication of these agents.

-- Christian Huitema

On 6/25/2020 7:00 AM, Susan Hares wrote:
> Qin and Christian: 
>
> Thank you for your prompt attention to the privacy issue.  
> I'm sure Christian will respond in a bit - since he might be in PDT time-zone. 
>
> Once you have a solution you both like, we should
> validate the privacy changes to the security considerations section with the 
> Yang-doctors, OPS-ADs, and Security-ADs.  
>
> Martin's watching this thread so I'm sure he'll help us out as well. 
>
> Sue 
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Qin Wu
> Sent: Thursday, June 25, 2020 9:25 AM
> To: Susan Hares; 'Christian Huitema'; secdir@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org; last-call@ietf.org
> Subject: Re: [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
>
> Sue and Christian:
> I have responded to Christian on privacy issue, my proposal is to add MAC address as another data node vulnerability example in our original security consideration section.
> But If Christian or security directorate has recommending text, we authors are happy to accept it.
>
> -Qin
> -----邮件原件-----
> 发件人: Susan Hares [mailto:shares@ndzh.com] 
> 发送时间: 2020年6月25日 21:04
> 收件人: 'Christian Huitema' <huitema@huitema.net>et>; secdir@ietf.org
> 抄送: draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org; i2rs@ietf.org; last-call@ietf.org
> 主题: RE: Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
>
> 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.
>
>
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>