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>om>; Susan Hares <shares@ndzh.com>om>;
> 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
>
>     > 
>
>