Return-Path: 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 EBDBC3A0801 for ; Fri, 26 Jun 2020 08:54:38 -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 ZYeTlqroqFfC for ; Fri, 26 Jun 2020 08:54:35 -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 E2D1B3A07C0 for ; Fri, 26 Jun 2020 08:54:34 -0700 (PDT) Received: from xse500.mail2web.com ([66.113.197.246] helo=xse.mail2web.com) by mx166.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jopn7-000rKU-OY for i2rs@ietf.org; Fri, 26 Jun 2020 16:57:28 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49tg0W4T3Yz1kMM for ; Fri, 26 Jun 2020 07:55:07 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jopkx-0003cu-Ev for i2rs@ietf.org; Fri, 26 Jun 2020 07:55:07 -0700 Received: (qmail 15894 invoked from network); 26 Jun 2020 14:55:07 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jun 2020 14:55:06 -0000 To: Qin Wu , Susan Hares , "secdir@ietf.org" Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org" , "last-call@ietf.org" , NETMOD Group References: From: Christian Huitema 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: <34bbf063-7973-b7aa-c407-0ac9c071a648@huitema.net> Date: Fri, 26 Jun 2020 07:55:05 -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: Content-Type: multipart/alternative; boundary="------------D1256F2AD8D9EE12B56C05C7" Content-Language: en-US X-Originating-IP: 66.113.197.246 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@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/4Jkrw1eDLcif59ftj+vcRILgqLmGROorwAsJ/+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxph9w6EwXICYy0ePXtGEMhqrDaibB3uLat3zCZGq8cCma2U6UgOqKJ9sMwhVoOBGSAIboXtx P9OF0EfNs5TqNq2Yhy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8aIeAiT0zR0hZdGDzE20RPqIs2Wt13AFwj+mbBCp9AQapy0QmXh9uhfq6i5/bGl8Ngx iMxSpkvqIEtRL3s4ePxvne6Agjui5gKB/Byw/yqfyPKY2AXNZGS5G93aGyH8MqMlOQRMVMd0HCeT skOZ5TL8jLUw57aJSXIevh0x/9ZiDjXg724gFzhHYUe+7aKm0vV7rNsxpsot8b76lu8kLu8BTi+J 2sBvM/O0p+zizleC4va6FPcpDHjXMKZJK8+chia6s7QH5Aus1s4PLXq2tVdt7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 15:54:39 -0000 This is a multi-part message in MIME format. --------------D1256F2AD8D9EE12B56C05C7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NACM defined in RFC8341 has alre= ady 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.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Both NETCONF and RESTCONF will r= ely on transport protocol > such as TLS to provide client authentication and server > authentication, i.e., mutual authentication. > > 3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The YANG security guideline defi= ned 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: > > " > > =C2=A0=C2=A0 There are a number of data nodes defined in this YANG modu= le that are > > =C2=A0=C2=A0 writable/creatable/deletable (i.e., config true, which is = the > > =C2=A0=C2=A0 default).=C2=A0 These data nodes may be considered sensiti= ve or vulnerable > > =C2=A0=C2=A0 in some network environments.=C2=A0 Write operations (e.g.= , edit-config) > > =C2=A0=C2=A0 to these data nodes without proper protection can have a n= egative > > =C2=A0=C2=A0 effect on network operations.=C2=A0 These are the subtrees= and data nodes > > =C2=A0=C2=A0 and their sensitivity/vulnerability in the ietf-network mo= dule: > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-network-attributes: A malicious client could at= tempt to > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sabotage the configuration of any of the= contained attributes, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 such as the name or the flag data nodes.= > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-node-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important node attr= ibutes, such as the name > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or the management-address. > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-link-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important link attr= ibutes, such as the rate > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or the delay data nodes. > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-termination-point-attributes: A malicious clien= t could attempt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to sabotage the configuration of importa= nt termination point > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attributes, such as the maximum-frame-si= ze. > > " > > NEW TEXT: > > " > > =C2=A0=C2=A0 There are a number of data nodes defined in this YANG modu= le that are > > =C2=A0=C2=A0 writable/creatable/deletable (i.e., config true, which is = the > > =C2=A0=C2=A0 default).=C2=A0 These data nodes may be considered sensiti= ve or vulnerable > > =C2=A0=C2=A0 in some network environments.=C2=A0 Write operations (e.g.= , edit-config) > > =C2=A0=C2=A0 to these data nodes without proper protection can have a n= egative > > =C2=A0=C2=A0 effect on network operations.=C2=A0 These are the subtrees= and data nodes > > =C2=A0=C2=A0 and their sensitivity/vulnerability in the ietf-network mo= dule: > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-network-attributes: A malicious client could at= tempt to > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sabotage the configuration of any of the= contained attributes, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 such as the name or the flag data nodes.= > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-node-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important node attr= ibutes, such as the name > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,the management-address *or mac address = of the devices*. > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-link-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important link attr= ibutes, such as the rate > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or the delay data nodes. > > =C2=A0 > > =C2=A0=C2=A0o=C2=A0 l2-termination-point-attributes: A malicious client= could attempt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to sabotage the configuration of importa= nt termination point > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attributes, such as the maximum-frame-si= ze, *mac-address*. > > " > > =C2=A0 > > With your proposed text, we could have the following proposal changes > (Proposal B): > > OLD TEXT: > > " > > 6.=C2=A0 Security Considerations > > =C2=A0 > > =C2=A0=C2=A0 The YANG module specified in this document defines a schem= a for data > > =C2=A0=C2=A0 that is designed to be accessed via network management pro= tocols such > > =C2=A0=C2=A0 as NETCONF [RFC6241] or RESTCONF [RFC8040].=C2=A0 The lowe= st NETCONF layer > > =C2=A0=C2=A0 is the secure transport layer, and the mandatory-to-implem= ent secure > > =C2=A0=C2=A0 transport is Secure Shell (SSH) [RFC6242].=C2=A0 The lowes= t RESTCONF layer > > =C2=A0=C2=A0 is HTTPS, and the mandatory-to-implement secure transport = is TLS > > =C2=A0=C2=A0 [RFC8446]. > > =C2=A0 > > =C2=A0=C2=A0 The Network Configuration Access Control Model (NACM) [RFC= 8341] > > =C2=A0=C2=A0 provides the means to restrict access for particular NETCO= NF or > > =C2=A0 > > =C2=A0=C2=A0 RESTCONF users to a preconfigured subset of all available = NETCONF or > > =C2=A0=C2=A0 RESTCONF protocol operations and content. > > =C2=A0 > > =C2=A0=C2=A0 In general, Layer 2 network topologies are system-controll= ed and > > =C2=A0=C2=A0 provide ephemeral topology information.=C2=A0 In an NMDA-c= omplient server, > > =C2=A0=C2=A0 they are only part of which provides read-on= ly access > > =C2=A0=C2=A0 to clients, they are less vulnerable.=C2=A0 That said, the= YANG module > > =C2=A0=C2=A0 does in principle allow information to be configurable. > > =C2=A0 > > =C2=A0=C2=A0 The Layer 2 topology module define information that can be= > > =C2=A0=C2=A0 configurable in certain instances, for example in the case= of virtual > > =C2=A0=C2=A0 topologies that can be created by client applications.=C2=A0= In such > > =C2=A0=C2=A0 cases, a malicious client could introduce topologies that = are > > =C2=A0=C2=A0 undesired.=C2=A0 Specifically, a malicious client could at= tempt to remove > > =C2=A0=C2=A0 or add a node, a link, a termination point, by creating or= deleting > > =C2=A0=C2=A0 corresponding elements in the node, link, and termination = point > > =C2=A0=C2=A0 lists, respectively.=C2=A0 In the case of a topology that = is learned, the > > =C2=A0=C2=A0 server will automatically prohibit such misconfiguration a= ttempts. > > =C2=A0=C2=A0 In the case of a topology that is configured, i.e. whose o= rigin is > > =C2=A0=C2=A0 "intended", the undesired configuration could become effec= tive and be > > =C2=A0=C2=A0 reflected in the operational state datastore, leading to d= isruption > > =C2=A0=C2=A0 of services provided via this topology might be disrupted.= =C2=A0 For those > > =C2=A0=C2=A0 reasons, it is important that the NETCONF access control m= odel is > > =C2=A0=C2=A0 vigorously applied to prevent topology misconfiguration by= > > =C2=A0=C2=A0 unauthorized clients. > > =C2=A0 > > =C2=A0=C2=A0 There are a number of data nodes defined in this YANG modu= le that are > > =C2=A0=C2=A0 writable/creatable/deletable (i.e., config true, which is = the > > =C2=A0=C2=A0 default).=C2=A0 These data nodes may be considered sensiti= ve or vulnerable > > =C2=A0=C2=A0 in some network environments.=C2=A0 Write operations (e.g.= , edit-config) > > =C2=A0=C2=A0 to these data nodes without proper protection can have a n= egative > > =C2=A0=C2=A0 effect on network operations.=C2=A0 These are the subtrees= and data nodes > > =C2=A0=C2=A0 and their sensitivity/vulnerability in the ietf-network mo= dule: > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-network-attributes: A malicious client could at= tempt to > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sabotage the configuration of any of the= contained attributes, > > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0such as the name or the flag data nodes.= > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-node-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important node attr= ibutes, such as the name > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or the management-address. > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-link-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important link attr= ibutes, such as the rate > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or the delay data nodes. > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-termination-point-attributes: A malicious clien= t could attempt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to sabotage the configuration of importa= nt termination point > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attributes, such as the maximum-frame-si= ze. > > " > > NEW TEXT: > > " > > 6.=C2=A0 Security Considerations > > =C2=A0 > > =C2=A0=C2=A0 The YANG module specified in this document defines a schem= a for data > > =C2=A0=C2=A0 that is designed to be accessed via network management pro= tocols such > > =C2=A0=C2=A0 as NETCONF [RFC6241] or RESTCONF [RFC8040].=C2=A0 The lowe= st NETCONF layer > > =C2=A0 =C2=A0is the secure transport layer, and the mandatory-to-implem= ent secure > > =C2=A0=C2=A0 transport is Secure Shell (SSH) [RFC6242].=C2=A0 The lowes= t RESTCONF layer > > =C2=A0=C2=A0 is HTTPS, and the mandatory-to-implement secure transport = is TLS > > =C2=A0=C2=A0 [RFC8446]. > > =C2=A0 > > =C2=A0=C2=A0 The Network Configuration Access Control Model (NACM) [RFC= 8341] > > =C2=A0=C2=A0 provides the means to restrict access for particular NETCO= NF or > > =C2=A0=C2=A0 RESTCONF users to a preconfigured subset of all available = NETCONF or > > =C2=A0=C2=A0 RESTCONF protocol operations and content. > > =C2=A0 > > =C2=A0=C2=A0 In general, Layer 2 network topologies are system-controll= ed and > > =C2=A0=C2=A0 provide ephemeral topology information.=C2=A0 In an NMDA-c= omplient server, > > =C2=A0=C2=A0 they are only part of which provides read-on= ly access > > =C2=A0=C2=A0 to clients, they are less vulnerable.=C2=A0 That said, the= YANG module > > =C2=A0=C2=A0 does in principle allow information to be configurable. > > =C2=A0 > > =C2=A0=C2=A0 The Layer 2 topology module define information that can be= > > =C2=A0=C2=A0 configurable in certain instances, for example in the case= of virtual > > =C2=A0=C2=A0 topologies that can be created by client applications.=C2=A0= In such > > =C2=A0=C2=A0 cases, a malicious client could introduce topologies that = are > > =C2=A0=C2=A0 undesired.=C2=A0 Specifically, a malicious client could at= tempt to remove > > =C2=A0=C2=A0 or add a node, a link, a termination point, by creating or= deleting > > =C2=A0=C2=A0 corresponding elements in the node, link, and termination = point > > =C2=A0=C2=A0 lists, respectively.=C2=A0 In the case of a topology that = is learned, the > > =C2=A0=C2=A0 server will automatically prohibit such misconfiguration a= ttempts. > > =C2=A0=C2=A0 In the case of a topology that is configured, i.e. whose o= rigin is > > =C2=A0=C2=A0 "intended", the undesired configuration could become effec= tive and be > > =C2=A0=C2=A0 reflected in the operational state datastore, leading to d= isruption > > =C2=A0=C2=A0 of services provided via this topology might be disrupted.= =C2=A0 For those > > =C2=A0=C2=A0 reasons, it is important that the NETCONF access control m= odel is > > =C2=A0=C2=A0 vigorously applied to prevent topology misconfiguration by= > > =C2=A0=C2=A0 unauthorized clients. > > =C2=A0 > > *=C2=A0 The YANG model for layer 2 topology may expose sensitive inform= ation, * > > *=C2=A0=C2=A0for example the MAC addresses of devices. Unrestricted use= of such > information * > > *=C2=A0=C2=A0=C2=A0can lead to privacy violations. For example, listing= MAC addresses > in a network * > > *=C2=A0=C2=A0=C2=A0allows monitoring of devices and their movements. Lo= cation > information can be derived* > > *=C2=A0 =C2=A0from MAC addresses of network devices, bypassing protecti= on of > location information by * > > *=C2=A0=C2=A0=C2=A0the Operating System. Deployments should mitigate th= is privacy > concerns by limiting access * > > *=C2=A0=C2=A0=C2=A0to the layer 2 topology information. Access to the i= nformation > should be restricted to a * > > *=C2=A0=C2=A0=C2=A0minimal list of authorized clients, and should also = require proper > authentication of these clients.* > > =C2=A0 > > =C2=A0=C2=A0 There are a number of data nodes defined in this YANG modu= le that are > > =C2=A0=C2=A0 writable/creatable/deletable (i.e., config true, which is = the > > =C2=A0=C2=A0 default).=C2=A0 These data nodes may be considered sensiti= ve or vulnerable > > =C2=A0=C2=A0 in some network environments.=C2=A0 Write operations (e.g.= , edit-config) > > =C2=A0=C2=A0 to these data nodes without proper protection can have a n= egative > > =C2=A0=C2=A0 effect on network operations.=C2=A0 These are the subtrees= and data nodes > > =C2=A0=C2=A0 and their sensitivity/vulnerability in the ietf-network mo= dule: > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-network-attributes: A malicious client could at= tempt to > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sabotage the configuration of any of the= contained attributes, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 such as the name or the flag data nodes.= > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-node-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important node attr= ibutes, such as the name > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,the management-address, *mac-address of= the devices*. > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-link-attributes: A malicious client could attem= pt to sabotage > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the configuration of important link attr= ibutes, such as the rate > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or the delay data nodes. > > =C2=A0 > > =C2=A0=C2=A0 o=C2=A0 l2-termination-point-attributes: A malicious clien= t could attempt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to sabotage the configuration of importa= nt termination point > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attributes, such as the maximum-frame-si= ze, *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? > > =C2=A0 > > -Qin > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Christian Huitema [mailto:huitema@huitema.= net] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B46=E6=9C=8826=E6=97=A5= 12:05 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Susan Hares ; Qin Wu ; > secdir@ietf.org > =E6=8A=84=E9=80=81: i2rs@ietf.org; > draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org; last-call@ietf.o= rg > =E4=B8=BB=E9=A2=98: Re: [Last-Call] [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > =C2=A0 > > How about adding something like this: > > =C2=A0 > > Privacy Considerations > > =C2=A0 > > 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. > > =C2=A0 > > 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. > > =C2=A0 > > -- Christian Huitema > > =C2=A0 > > On 6/25/2020 7:00 AM, Susan Hares wrote: > > > Qin and Christian: > > >=C2=A0 > > > Thank you for your prompt attention to the privacy issue.=C2=A0 > > > I'm sure Christian will respond in a bit - since he might be in PDT t= ime-zone. > > >=C2=A0 > > > Once you have a solution you both like, we should validate the privac= y > > > changes to the security considerations section with the Yang-doctors,= > > > OPS-ADs, and Security-ADs. > > >=C2=A0 > > > Martin's watching this thread so I'm sure he'll help us out as well. > > >=C2=A0 > > > Sue > > >=C2=A0 > > > -----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 > > >=C2=A0 > > > 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 au= thors are happy > to accept it. > > >=C2=A0 > > > -Qin > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Susan Hares [mailto:shares@ndzh.com] > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B46=E6=9C=8825=E6=97= =A521:04 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Christian Huitema' >; secdir@ietf.org = > > > =E6=8A=84=E9=80=81: draft-ietf-i2rs-yang-l2-network-topology.all@ietf= =2Eorg > ; > > > i2rs@ietf.org ; last-call@ietf.org > > > > =E4=B8=BB=E9=A2=98: RE: Secdir last call review of > > > draft-ietf-i2rs-yang-l2-network-topology-13 > > >=C2=A0 > > > Christian: > > >=C2=A0 > > > Thank you for catching the privacy issues.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > > >=C2=A0 > > > I've got a few questions to help the authors scope this change: > > >=C2=A0 > > > 1) Since this is common to all L2 Topologies, can you or the security= directorate > recommend some text that might be appropriate? > > > =C2=A0=C2=A0=C2=A0If you have recommended text, has this text been re= viewed by OPS-DIR and Yang > doctors? > > >=C2=A0 > > > 2) Will it be a problem If we write privacy considerations on IEEE sp= ecifications? > > > 3) Do we need to consider the range of deployments of L2 (home, > > > enterprise,=C2=A0 public PBB service, national PBB service, Data cent= ers) > > >=C2=A0 > > >=C2=A0 > > > Thank you,=C2=A0 Sue > > >=C2=A0 > > >=C2=A0 > > > -----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 > > >=C2=A0 > > > Reviewer: Christian Huitema > > > Review result: Has Issues > > >=C2=A0 > > > I have reviewed this document as part of the security directorate's o= ngoing effort to > review all IETF documents being processed by the IESG.=C2=A0 These comm= ents > were written with the intent of improving security requirements and > considerations in IETF drafts.=C2=A0 Comments not addressed in last cal= l > may be included in AD reviews during the IESG review.=C2=A0 Document > editors and WG chairs should treat these comments just like any other > last call comments. > > >=C2=A0 > > > This document describes a Yang model for representing Link Layer topo= logies. > > > Representing such topologies is obviously useful for managing network= =2E > > > The security section is focused on securing the usage of this informa= tion for > network management, but does not address potential privacy issues. > > >=C2=A0 > > > The security considerations explain correctly how altering the link l= ayer > 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. > > >=C2=A0 > > > On the other hand, the security considerations do not describe privac= y 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 asse= ss 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. > > >=C2=A0 > > > Client authentication alone does not necessarily protect against thes= e > 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. > > >=C2=A0 > > >=C2=A0 > > >=C2=A0 > > >=C2=A0 > > >=C2=A0 > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > >=C2=A0 > --------------D1256F2AD8D9EE12B56C05C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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>; Qin Wu <bill.wu@huawei.com>; secdir@ietf.org
抄送: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org; 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

> 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>; 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

> 

--------------D1256F2AD8D9EE12B56C05C7--