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

Christian Huitema <huitema@xxxxxxxxxxx> · Sat, 27 Jun 2020 09:17:39 -0700



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

              发送时间: 2020年6月26日 22:55

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

                抄送: i2rs@xxxxxxxx;
                  draft-ietf-i2rs-yang-l2-network-topology.all@xxxxxxxx;
                  last-call@xxxxxxxx; NETMOD Group
                  <netmod@xxxxxxxx>

                主题: 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@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