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