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

[Christian Huitema <[e-mail]>]

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:[e-mail]]
> *发送时间:*2020年6月26日22:55
> *收件人:*Qin Wu <[e-mail]>; Susan Hares <[e-mail]>;
> [e-mail]
> *抄送:*[e-mail];
> [e-mail];
> [e-mail]; NETMOD Group <[e-mail]>
> *主题:*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:[e-mail]]
>     发送时间: 2020年6月26日12:05
>     收件人: Susan Hares <[e-mail]> <mailto:[e-mail]>; Qin
>     Wu <[e-mail]> <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     抄送: [e-mail] <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     主题: 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:[e-mail]] On Behalf Of Qin Wu
>
>     > Sent: Thursday, June 25, 2020 9:25 AM
>
>     > To: Susan Hares; 'Christian Huitema'; [e-mail] <mailto:[e-mail]>
>
>     > Cc: [e-mail] <mailto:[e-mail]>;
>
>     > [e-mail]
>     <mailto:[e-mail]>;
>
>     > [e-mail] <mailto:[e-mail]>
>
>     > 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:[e-mail]]
>
>     > 发送时间: 2020年6月25日21:04
>
>     > 收件人: 'Christian Huitema' <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>
>     > 抄送: [e-mail]
>     <mailto:[e-mail]>;
>
>     > [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>
>     > 主题: 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:[e-mail]]
>
>     > Sent: Thursday, June 25, 2020 1:01 AM
>
>     > To: [e-mail] <mailto:[e-mail]>
>
>     > Cc: [e-mail]
>     <mailto:[e-mail]>;
>
>     > [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>
>     > 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
>
>     > [e-mail] <mailto:[e-mail]>
>
>     > https://www.ietf.org/mailman/listinfo/i2rs
>
>     > 
>
>