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

Christian Huitema <huitema@xxxxxxxxxxx> · Fri, 26 Jun 2020 07:55:05 -0700



    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@xxxxxxxxxxx]
            

          发送时间: 2020年6月26日 12:05

          收件人: Susan Hares <shares@xxxxxxxx>; Qin Wu
            <bill.wu@xxxxxxxxxx>; secdir@xxxxxxxx

          抄送: i2rs@xxxxxxxx;
            draft-ietf-i2rs-yang-l2-network-topology.all@xxxxxxxx;
            last-call@xxxxxxxx

          主题: 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@xxxxxxxx]
            On Behalf Of Qin Wu
        > Sent: Thursday,
            June 25, 2020 9:25 AM
        > To: Susan Hares;
            'Christian Huitema';
            secdir@xxxxxxxx
        > Cc: i2rs@xxxxxxxx;
            
        > 
              draft-ietf-i2rs-yang-l2-network-topology.all@xxxxxxxx;
            
        > 
              last-call@xxxxxxxx
        > 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@xxxxxxxx]
        > 发送时间: 2020年6月25日 21:04
        > 收件人:
            'Christian Huitema' <huitema@xxxxxxxxxxx>;
            secdir@xxxxxxxx
        > 抄送:
            draft-ietf-i2rs-yang-l2-network-topology.all@xxxxxxxx;
            
        > i2rs@xxxxxxxx;
            last-call@xxxxxxxx
        > 主题: 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@xxxxxxxx]
        > Sent: Thursday,
            June 25, 2020 1:01 AM
        > To: 
              secdir@xxxxxxxx
        > Cc: 
              draft-ietf-i2rs-yang-l2-network-topology.all@xxxxxxxx;
            
        > i2rs@xxxxxxxx;
            last-call@xxxxxxxx
        > 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@xxxxxxxx
        > 
              https://www.ietf.org/mailman/listinfo/i2rs
        > 
      
    
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call