Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Christian Huitema <huitema@huitema.net> Sat, 27 June 2020 16:17 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 D04923A0821 for <i2rs@ietfa.amsl.com>; Sat, 27 Jun 2020 09:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4sVUbJzzZvhT for <i2rs@ietfa.amsl.com>; Sat, 27 Jun 2020 09:17:54 -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 5E2393A0802 for <i2rs@ietf.org>; Sat, 27 Jun 2020 09:17:53 -0700 (PDT)
Received: from xse254.mail2web.com ([66.113.196.254] helo=xse.mail2web.com) by mx14.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jpDWQ-0004Iv-QZ for i2rs@ietf.org; Sat, 27 Jun 2020 18:17:50 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49vJnK336Yz2ZRN for <i2rs@ietf.org>; Sat, 27 Jun 2020 09:17:41 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jpDWP-0006FU-7Z for i2rs@ietf.org; Sat, 27 Jun 2020 09:17:41 -0700
Received: (qmail 7994 invoked from network); 27 Jun 2020 16:17:40 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <last-call@ietf.org>; 27 Jun 2020 16:17:40 -0000
To: Qin Wu <bill.wu@huawei.com>, Susan Hares <shares@ndzh.com>, "secdir@ietf.org" <secdir@ietf.org>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, "draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org" <draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org>, NETMOD Group <netmod@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABAAD7BE6C3@dggeml531-mbs.china.huawei.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: <90a9ffa5-4db7-fdaf-5a55-48ed2745bde0@huitema.net>
Date: Sat, 27 Jun 2020 09:17:39 -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: <B8F9A780D330094D99AF023C5877DABAAD7BE6C3@dggeml531-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------A3510C022F77668DCEC42238"
Content-Language: en-US
X-Originating-IP: 66.113.196.254
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.254/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.254/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/4Jkrw1eDLcif59ftUjR6wuRiqVZ10mayu/1rZ+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxpgwWbxrOZCJSMpTl/yE2fo2wVN19L7+HpOQTYxMY+AoxQZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZEwWcPoaRBqQ28Cyw5TTd3Tznbr/iPR0U8WqNWDtD9jyfHFc9tVi614cnRbnL0tzV9X dU571qBU/d2sq9m7FB7HFod3/PybrGCFhu0/G2xhnGkvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulxl9HUMOvZkeNp2fpKbDmnVGre/hsBBxzR0ZxLcHZ9dOjYiLlGFZl9C5ThG9mlnyxnQzYz IE5q2+yrLuhv7kNPiAEH5tktsnhMr4gG+2qXrJ1naxDP6DybgbEEPGfx07Ug9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/IioQZaSf-CNFBME6_3X4sZD1wD4>
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: Sat, 27 Jun 2020 16:18:10 -0000
Works for me. Thank you. -- Christian Huitema On 6/26/2020 11:26 PM, Qin Wu wrote: > > Thanks Christian for clarification, here is the tweaked text to > address your comment, which is positioned right after the discussion > about writable/creatable/deletable attributes. > > *NEW TEXT:* > > “ > > 6. Security Considerations > > > > The YANG module specified in this document defines a schema for data > > that is designed to be accessed via network management protocols such > > as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer > > is the secure transport layer, and the mandatory-to-implement secure > > transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer > > is HTTPS, and the mandatory-to-implement secure transport is TLS > > [RFC8446]. > > > > The Network Configuration Access Control Model (NACM) [RFC8341] > > provides the means to restrict access for particular NETCONF or > > > > RESTCONF users to a preconfigured subset of all available NETCONF or > > RESTCONF protocol operations and content. > > > > The Layer 2 topology module define information that can be > > configurable in certain instances, for example in the case of virtual > > topologies that can be created by client applications. In such > > cases, a malicious client could introduce topologies that are > > undesired. Specifically, a malicious client could attempt to remove > > or add a node, a link, a termination point, by creating or deleting > > corresponding elements in the node, link, and termination point > > lists, respectively. In the case of a topology that is learned, the > > server will automatically prohibit such misconfiguration attempts. > > In the case of a topology that is configured, i.e. whose origin is > > "intended", the undesired configuration could become effective and be > > reflected in the operational state datastore, leading to disruption > > of services provided via this topology might be disrupted. For those > > reasons, it is important that the NETCONF access control model is > > vigorously applied to prevent topology misconfiguration by > > unauthorized clients. > > > > There are a number of data nodes defined in this YANG module that are > > writable/creatable/deletable (i.e., config true, which is the > > default). These data nodes may be considered sensitive or vulnerable > > in some network environments. Write operations (e.g., edit-config) > > to these data nodes without proper protection can have a negative > > effect on network operations. These are the subtrees and data nodes > > and their sensitivity/vulnerability in the ietf-network module: > > > > o l2-network-attributes: A malicious client could attempt to > > sabotage the configuration of any of the contained attributes, > > such as the name or the flag data nodes. > > > > o l2-node-attributes: A malicious client could attempt to sabotage > > the configuration of important node attributes, such as the name > > or the management-address. > > > > o l2-link-attributes: A malicious client could attempt to sabotage > > the configuration of important link attributes, such as the rate > > or the delay data nodes. > > > > o l2-termination-point-attributes: A malicious client could attempt > > to sabotage the configuration of important termination point > > attributes, such as the maximum-frame-size. > > > > *Some of the readable data nodes in this YANG module may be considered * > > *sensitive or vulnerable in some network environments. It is thus > important to control * > > *read access (e.g., via get, get-config, or notification) to these > data nodes. In particular, the * > > *YANG model for layer 2 topology may expose 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. * > > > > ” > > Thanks. > > > > -Qin > > *发件人:*Christian Huitema [mailto:huitema@huitema.net] > *发送时间:*2020年6月26日22:55 > *收件人:*Qin Wu <bill.wu@huawei.com>; Susan Hares <shares@ndzh.com>; > secdir@ietf.org > *抄送:*i2rs@ietf.org; > draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org; > last-call@ietf.org; NETMOD Group <netmod@ietf.org> > *主题:*Re: [Last-Call] [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > I like variant B better, although I would not single out the mac > addresses in the "sabotage" warning. > > My main concern is that network administrators will naturally be very > concerned about information that is writable/creatable/deletable, > because they understand the impact on the management of their network. > However, they are not so concerned with read-only access, because > reading information does not directly affect the operation of the > network. My whole point is telling them, "you are documenting your L2 > topology, it contains sensitive information, make sure that reading it > is protected, not just writing it". > > I agree that NETCONF and RESTCONF provide the right tools for > protecting the information. My request is just to clearly tell network > administrators to use these tools, do not leave read access wide open! > > -- Christian Huitema > > On 6/26/2020 4:37 AM, Qin Wu wrote: > > Hi, Christian: > > 1. NACM defined in RFC8341 has already provided mechanisms > to restrict access to sensitive information to a minimal list of > authorized client or agents and deal with privacy issue if my > understanding is correct. > > 2. Both NETCONF and RESTCONF will rely on transport protocol > such as TLS to provide client authentication and server > authentication, i.e., mutual authentication. > > 3. The YANG security guideline defined in > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > Provide perfect boilerplate to address both security consideration > and privacy consideration. > > My original proposal A to address your comments is: > > OLD TEXT: > > " > > There are a number of data nodes defined in this YANG module > that are > > writable/creatable/deletable (i.e., config true, which is the > > default). These data nodes may be considered sensitive or > vulnerable > > in some network environments. Write operations (e.g., edit-config) > > to these data nodes without proper protection can have a negative > > effect on network operations. These are the subtrees and data > nodes > > and their sensitivity/vulnerability in the ietf-network module: > > > > o l2-network-attributes: A malicious client could attempt to > > sabotage the configuration of any of the contained attributes, > > such as the name or the flag data nodes. > > > > o l2-node-attributes: A malicious client could attempt to sabotage > > the configuration of important node attributes, such as the name > > or the management-address. > > > > o l2-link-attributes: A malicious client could attempt to sabotage > > the configuration of important link attributes, such as the rate > > or the delay data nodes. > > > > o l2-termination-point-attributes: A malicious client could > attempt > > to sabotage the configuration of important termination point > > attributes, such as the maximum-frame-size. > > " > > NEW TEXT: > > " > > There are a number of data nodes defined in this YANG module > that are > > writable/creatable/deletable (i.e., config true, which is the > > default). These data nodes may be considered sensitive or > vulnerable > > in some network environments. Write operations (e.g., edit-config) > > to these data nodes without proper protection can have a negative > > effect on network operations. These are the subtrees and data > nodes > > and their sensitivity/vulnerability in the ietf-network module: > > > > o l2-network-attributes: A malicious client could attempt to > > sabotage the configuration of any of the contained attributes, > > such as the name or the flag data nodes. > > > > o l2-node-attributes: A malicious client could attempt to sabotage > > the configuration of important node attributes, such as the name > > ,the management-address *or mac address of the devices*. > > > > o l2-link-attributes: A malicious client could attempt to sabotage > > the configuration of important link attributes, such as the rate > > or the delay data nodes. > > > > o l2-termination-point-attributes: A malicious client could attempt > > to sabotage the configuration of important termination point > > attributes, such as the maximum-frame-size, *mac-address*. > > " > > > > With your proposed text, we could have the following proposal > changes (Proposal B): > > OLD TEXT: > > " > > 6. Security Considerations > > > > The YANG module specified in this document defines a schema for > data > > that is designed to be accessed via network management > protocols such > > as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF > layer > > is the secure transport layer, and the mandatory-to-implement > secure > > transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF > layer > > is HTTPS, and the mandatory-to-implement secure transport is TLS > > [RFC8446]. > > > > The Network Configuration Access Control Model (NACM) [RFC8341] > > provides the means to restrict access for particular NETCONF or > > > > RESTCONF users to a preconfigured subset of all available > NETCONF or > > RESTCONF protocol operations and content. > > > > In general, Layer 2 network topologies are system-controlled and > > provide ephemeral topology information. In an NMDA-complient > server, > > they are only part of <operational> which provides read-only access > > to clients, they are less vulnerable. That said, the YANG module > > does in principle allow information to be configurable. > > > > The Layer 2 topology module define information that can be > > configurable in certain instances, for example in the case of > virtual > > topologies that can be created by client applications. In such > > cases, a malicious client could introduce topologies that are > > undesired. Specifically, a malicious client could attempt to > remove > > or add a node, a link, a termination point, by creating or deleting > > corresponding elements in the node, link, and termination point > > lists, respectively. In the case of a topology that is > learned, the > > server will automatically prohibit such misconfiguration attempts. > > In the case of a topology that is configured, i.e. whose origin is > > "intended", the undesired configuration could become effective > and be > > reflected in the operational state datastore, leading to disruption > > of services provided via this topology might be disrupted. For > those > > reasons, it is important that the NETCONF access control model is > > vigorously applied to prevent topology misconfiguration by > > unauthorized clients. > > > > There are a number of data nodes defined in this YANG module > that are > > writable/creatable/deletable (i.e., config true, which is the > > default). These data nodes may be considered sensitive or > vulnerable > > in some network environments. Write operations (e.g., edit-config) > > to these data nodes without proper protection can have a negative > > effect on network operations. These are the subtrees and data > nodes > > and their sensitivity/vulnerability in the ietf-network module: > > > > o l2-network-attributes: A malicious client could attempt to > > sabotage the configuration of any of the contained attributes, > > such as the name or the flag data nodes. > > > > o l2-node-attributes: A malicious client could attempt to sabotage > > the configuration of important node attributes, such as the name > > or the management-address. > > > > o l2-link-attributes: A malicious client could attempt to sabotage > > the configuration of important link attributes, such as the rate > > or the delay data nodes. > > > > o l2-termination-point-attributes: A malicious client could > attempt > > to sabotage the configuration of important termination point > > attributes, such as the maximum-frame-size. > > " > > NEW TEXT: > > " > > 6. Security Considerations > > > > The YANG module specified in this document defines a schema for > data > > that is designed to be accessed via network management > protocols such > > as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF > layer > > is the secure transport layer, and the mandatory-to-implement > secure > > transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF > layer > > is HTTPS, and the mandatory-to-implement secure transport is TLS > > [RFC8446]. > > > > The Network Configuration Access Control Model (NACM) [RFC8341] > > provides the means to restrict access for particular NETCONF or > > RESTCONF users to a preconfigured subset of all available > NETCONF or > > RESTCONF protocol operations and content. > > > > In general, Layer 2 network topologies are system-controlled and > > provide ephemeral topology information. In an NMDA-complient > server, > > they are only part of <operational> which provides read-only access > > to clients, they are less vulnerable. That said, the YANG module > > does in principle allow information to be configurable. > > > > The Layer 2 topology module define information that can be > > configurable in certain instances, for example in the case of > virtual > > topologies that can be created by client applications. In such > > cases, a malicious client could introduce topologies that are > > undesired. Specifically, a malicious client could attempt to > remove > > or add a node, a link, a termination point, by creating or deleting > > corresponding elements in the node, link, and termination point > > lists, respectively. In the case of a topology that is > learned, the > > server will automatically prohibit such misconfiguration attempts. > > In the case of a topology that is configured, i.e. whose origin is > > "intended", the undesired configuration could become effective > and be > > reflected in the operational state datastore, leading to disruption > > of services provided via this topology might be disrupted. For > those > > reasons, it is important that the NETCONF access control model is > > vigorously applied to prevent topology misconfiguration by > > unauthorized clients. > > > > * The YANG model for layer 2 topology may expose 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 clients, and should also require > proper authentication of these clients.* > > > > There are a number of data nodes defined in this YANG module > that are > > writable/creatable/deletable (i.e., config true, which is the > > default). These data nodes may be considered sensitive or > vulnerable > > in some network environments. Write operations (e.g., edit-config) > > to these data nodes without proper protection can have a negative > > effect on network operations. These are the subtrees and data > nodes > > and their sensitivity/vulnerability in the ietf-network module: > > > > o l2-network-attributes: A malicious client could attempt to > > sabotage the configuration of any of the contained attributes, > > such as the name or the flag data nodes. > > > > o l2-node-attributes: A malicious client could attempt to sabotage > > the configuration of important node attributes, such as the name > > ,the management-address, *mac-address of the devices*. > > > > o l2-link-attributes: A malicious client could attempt to sabotage > > the configuration of important link attributes, such as the rate > > or the delay data nodes. > > > > o l2-termination-point-attributes: A malicious client could > attempt > > to sabotage the configuration of important termination point > > attributes, such as the maximum-frame-size, *mac-address*. > > " > > The question is do you think proposal with yang security > boilterplate has already addressed your comments > > Or you think we should emphasize how privacy issue can be > addressed by NACM and client authentication is needed? > > > > -Qin > > -----邮件原件----- > 发件人: Christian Huitema [mailto:huitema@huitema.net] > 发送时间: 2020年6月26日12:05 > 收件人: Susan Hares <shares@ndzh.com> <mailto:shares@ndzh.com>; Qin > Wu <bill.wu@huawei.com> <mailto:bill.wu@huawei.com>; > secdir@ietf.org <mailto:secdir@ietf.org> > 抄送: i2rs@ietf.org <mailto:i2rs@ietf.org>; > draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org > <mailto:draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org>; > last-call@ietf.org <mailto:last-call@ietf.org> > 主题: Re: [Last-Call] [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > 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 <mailto:secdir@ietf.org> > > > Cc: i2rs@ietf.org <mailto:i2rs@ietf.org>; > > > draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org > <mailto:draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org>; > > > last-call@ietf.org <mailto: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 > <mailto:huitema@huitema.net>>; secdir@ietf.org > <mailto:secdir@ietf.org> > > > 抄送: draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org > <mailto:draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org>; > > > i2rs@ietf.org <mailto:i2rs@ietf.org>; last-call@ietf.org > <mailto: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 <mailto:secdir@ietf.org> > > > Cc: draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org > <mailto:draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org>; > > > i2rs@ietf.org <mailto:i2rs@ietf.org>; last-call@ietf.org > <mailto: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 <mailto:i2rs@ietf.org> > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > >
- [i2rs] Secdir last call review of draft-ietf-i2rs… Christian Huitema via Datatracker
- Re: [i2rs] Secdir last call review of draft-ietf-… Susan Hares
- Re: [i2rs] Secdir last call review of draft-ietf-… Qin Wu
- Re: [i2rs] Secdir last call review of draft-ietf-… Qin Wu
- Re: [i2rs] Secdir last call review of draft-ietf-… Susan Hares
- Re: [i2rs] [Last-Call] Secdir last call review of… Christian Huitema
- Re: [i2rs] [Last-Call] Secdir last call review of… Qin Wu
- Re: [i2rs] [Last-Call] Secdir last call review of… Susan Hares
- Re: [i2rs] [Last-Call] Secdir last call review of… Juergen Schoenwaelder
- Re: [i2rs] [Last-Call] Secdir last call review of… Susan Hares
- Re: [i2rs] [Last-Call] Secdir last call review of… Christian Huitema
- Re: [i2rs] [Last-Call] Secdir last call review of… Qin Wu
- Re: [i2rs] [Last-Call] Secdir last call review of… Christian Huitema