Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
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:huit...@huitema.net] 发送时间: 2020年6月26日 22:55 收件人: Qin Wu ; Susan Hares ; sec...@ietf.org 抄送: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; last-c...@ietf.org; NETMOD Group 主题: 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
Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
> 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:huit...@huitema.net] > 发送时间: 2020年6月26日12:05 > 收件人: Susan Hares ; Qin Wu ; > sec...@ietf.org > 抄送: i2rs@ietf.org; > draft-ietf-i2rs-yang-l2-network-topology@ietf.org; last-c...@ietf.org > 主题: Re: [Last-Call] [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > How about adding something like this: > > > > Privacy Considerations > > > > The Yang model for layer 2 topology exposes privacy sensitive > information, for example the MAC addresses of devices. Unrestricted > use of such information can lead to privacy violations. For example, > listing MAC addresses in a network allows monitoring of devices and > their movements. Location information can be derived from MAC > addresses of network devices, bypassing protection of location > information by the Operating System. > > >
Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Juergen: Good catch. Thanks. sue -Original Message- From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] Sent: Friday, June 26, 2020 9:12 AM To: Susan Hares Cc: 'Christian Huitema'; 'Qin Wu'; sec...@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; last-c...@ietf.org Subject: Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13 But please s/agents/clients/ . /js On Fri, Jun 26, 2020 at 08:36:23AM -0400, Susan Hares wrote: > Qin and Christian: > > This addition words for me. > > Sue > > -Original Message- > From: Christian Huitema [mailto:huit...@huitema.net] > Sent: Friday, June 26, 2020 12:05 AM > To: Susan Hares; 'Qin Wu'; sec...@ietf.org > Cc: i2rs@ietf.org; > draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > last-c...@ietf.org > Subject: 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-boun...@ietf.org] On Behalf Of Qin Wu > > Sent: Thursday, June 25, 2020 9:25 AM > > To: Susan Hares; 'Christian Huitema'; sec...@ietf.org > > Cc: i2rs@ietf.org; > > draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > > last-c...@ietf.org > > Subject: Re: [i2rs] Secdir last call review of > > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > Sue and Christian: > > I have responded to Christian on privacy issue, my proposal is to add MAC > > address as another data node vulnerability example in our original security > > consideration section. > > But If Christian or security directorate has recommending text, we authors > > are happy to accept it. > > > > -Qin > > -邮件原件- > > 发件人: Susan Hares [mailto:sha...@ndzh.com] > > 发送时间: 2020年6月25日 21:04 > > 收件人: 'Christian Huitema' ; sec...@ietf.org > > 抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > > i2rs@ietf.org; last-c...@ietf.org > > 主题: RE: Secdir last call review of > > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > Christian: > > > > Thank you for catching the privacy issues. > > > > I've got a few questions to help the authors scope this change: > > > > 1) Since this is common to all L2 Topologies, can you or the security > > directorate recommend some text that might be appropriate? > >If you have recommended text, has this text been reviewed by OPS-DIR and > > Yang doctors? > > > > 2) Will it be a problem If we write privacy considerations on IEEE > > specifications? > > 3) Do we need to consider the range of deployments of L2 (home, > > enterprise, public PBB service, national PBB service, Data centers) > > > > > > Thank you, Sue > > > > > > -Original Message- > > From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] > > Sent: Thursday, June 25, 2020 1:01 AM > > To: sec...@ietf.org > > Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > > i2rs@ietf.org; last-c...@ietf.org > > Subject: Secdir last call review of > > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > Reviewer: Christian Huitema > > Review result: Has Issues >
Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
But please s/agents/clients/ . /js On Fri, Jun 26, 2020 at 08:36:23AM -0400, Susan Hares wrote: > Qin and Christian: > > This addition words for me. > > Sue > > -Original Message- > From: Christian Huitema [mailto:huit...@huitema.net] > Sent: Friday, June 26, 2020 12:05 AM > To: Susan Hares; 'Qin Wu'; sec...@ietf.org > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > last-c...@ietf.org > Subject: 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-boun...@ietf.org] On Behalf Of Qin Wu > > Sent: Thursday, June 25, 2020 9:25 AM > > To: Susan Hares; 'Christian Huitema'; sec...@ietf.org > > Cc: i2rs@ietf.org; > > draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > > last-c...@ietf.org > > Subject: Re: [i2rs] Secdir last call review of > > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > Sue and Christian: > > I have responded to Christian on privacy issue, my proposal is to add MAC > > address as another data node vulnerability example in our original security > > consideration section. > > But If Christian or security directorate has recommending text, we authors > > are happy to accept it. > > > > -Qin > > -----邮件原件----- > > 发件人: Susan Hares [mailto:sha...@ndzh.com] > > 发送时间: 2020年6月25日 21:04 > > 收件人: 'Christian Huitema' ; sec...@ietf.org > > 抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > > i2rs@ietf.org; last-c...@ietf.org > > 主题: RE: Secdir last call review of > > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > Christian: > > > > Thank you for catching the privacy issues. > > > > I've got a few questions to help the authors scope this change: > > > > 1) Since this is common to all L2 Topologies, can you or the security > > directorate recommend some text that might be appropriate? > >If you have recommended text, has this text been reviewed by OPS-DIR and > > Yang doctors? > > > > 2) Will it be a problem If we write privacy considerations on IEEE > > specifications? > > 3) Do we need to consider the range of deployments of L2 (home, > > enterprise, public PBB service, national PBB service, Data centers) > > > > > > Thank you, Sue > > > > > > -Original Message- > > From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] > > Sent: Thursday, June 25, 2020 1:01 AM > > To: sec...@ietf.org > > Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > > i2rs@ietf.org; last-c...@ietf.org > > Subject: Secdir last call review of > > draft-ietf-i2rs-yang-l2-network-topology-13 > > > > Reviewer: Christian Huitema > > Review result: Has Issues > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written with the intent of improving security requirements > > and considerations in IETF drafts. Comments not addressed in last call may > > be included in AD reviews during the IESG review. Document editors and WG > &
Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
Qin and Christian: This addition words for me. Sue -Original Message- From: Christian Huitema [mailto:huit...@huitema.net] Sent: Friday, June 26, 2020 12:05 AM To: Susan Hares; 'Qin Wu'; sec...@ietf.org Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; last-c...@ietf.org Subject: 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-boun...@ietf.org] On Behalf Of Qin Wu > Sent: Thursday, June 25, 2020 9:25 AM > To: Susan Hares; 'Christian Huitema'; sec...@ietf.org > Cc: i2rs@ietf.org; > draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > last-c...@ietf.org > Subject: Re: [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Sue and Christian: > I have responded to Christian on privacy issue, my proposal is to add MAC > address as another data node vulnerability example in our original security > consideration section. > But If Christian or security directorate has recommending text, we authors > are happy to accept it. > > -Qin > -邮件原件- > 发件人: Susan Hares [mailto:sha...@ndzh.com] > 发送时间: 2020年6月25日 21:04 > 收件人: 'Christian Huitema' ; sec...@ietf.org > 抄送: draft-ietf-i2rs-yang-l2-network-topology....@ietf.org; > i2rs@ietf.org; last-c...@ietf.org > 主题: RE: Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Christian: > > Thank you for catching the privacy issues. > > I've got a few questions to help the authors scope this change: > > 1) Since this is common to all L2 Topologies, can you or the security > directorate recommend some text that might be appropriate? >If you have recommended text, has this text been reviewed by OPS-DIR and > Yang doctors? > > 2) Will it be a problem If we write privacy considerations on IEEE > specifications? > 3) Do we need to consider the range of deployments of L2 (home, > enterprise, public PBB service, national PBB service, Data centers) > > > Thank you, Sue > > > -Original Message- > From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] > Sent: Thursday, June 25, 2020 1:01 AM > To: sec...@ietf.org > Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; > i2rs@ietf.org; last-c...@ietf.org > Subject: Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements and > considerations in IETF drafts. Comments not addressed in last call may be > included in AD reviews during the IESG review. Document editors and WG > chairs should treat these comments just like any other last call comments. > > This document describes a Yang model for representing Link Layer topologies. > Representing such topologies is obviously useful for managing network. > The security section is focused on securing the usage of this information for > network management, but does not address potential privacy issues. > > The security considerations explain correctly how altering the link layer > information could enable attacks against the network. The proposed remedy is > access control, implemented using either SSH or TLS. This is fine, although > the dis
Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13
on 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:huit...@huitema.net] 发送时间: 2020年6月26日 12:05 收件人: Susan Hares ; Qin Wu ; sec...@ietf.org 抄送: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology....@ietf.org; last-c...@ietf.org 主题: Re: [Last-Call] [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13 How about adding something like this: Privacy Considerations The Yang model for layer 2 topology exposes privacy sensitive information, for example the MAC addresses of devices. Unrestricted use of such information can lead to privacy violations. For example, listing MAC addresses in a network allows monitoring of devices and their movements. Location information can be derived from MAC addresses of network devices, bypassing protection of location information by the Operating System. Deployments should mitigate this privacy concerns by limiting access to the layer 2 topology information. Access to the information should be restricted to a minimal list of authorized agents, and should require proper authentication of these agents. -- Christian Huitema On 6/25/2020 7:00 AM, Susan Hares wrote: > Qin and Christian: > > Thank you for your prompt attention to the privacy issue. > I'm sure Christian will respond in a bit - since he might be in PDT time-zone. > > Once you have a solution you both like, we should validate the privacy > changes to the security considerations section with the Yang-doctors, > OPS-ADs, and Security-ADs. > > Martin's watching this thread so I'm sure he'll help us out as well. > > Sue > > -Original Message- > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Qin Wu > Sent: Thursday, June 25, 2020 9:25 AM > To: Susan Hares; 'Christian Huitema'; sec...@ietf.org<mailto:sec...@ietf.org> > Cc: i2rs@ietf.org<mailto:i2rs@ietf.org>; > draft-ietf-i2rs-yang-l2-network-topology@ietf.org<mailto:draft-ietf-i2rs-yang-l2-network-topology....@ietf.org>; > last-c...@ietf.org<mailto:last-c...@ietf.org> > Subject: Re: [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Sue and Christian: > I have responded to Christian on privacy issue, my proposal is to add MAC > address as another data node vulnerability example in our original security > consideration section. > But If Christian or security directorate has recommending text, we authors > are happy to accept it. > > -Qin > -邮件原件- > 发件人: Susan Hares [mailto:sha...@ndzh.com] > 发送时间: 2020年6月25日 21:04 > 收件人: 'Christian Huitema' mailto:huit...@huitema.net>>; > sec...@ietf.org<mailto:sec...@ietf.org> > 抄送: > draft-ietf-i2rs-yang-l2-network-topology....@ietf.org<mailto:draft-ietf-i2rs-yang-l2-network-topology@ietf.org>; > i2rs@ietf.org<mailto:i2rs@ietf.org>; > last-c...@ietf.org<mailto:last-c...@ietf.org> > 主题: RE: Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Christian: > > Thank you for catching the privacy issues. > > I've got a few questions to help the authors scope this change: > > 1) Since this is common to all L2 Topologies, can you or the security > directorate recommend some text that might be appropriate? >If you have recommended text, has this text been reviewed by OPS-DIR and > Yang doctors? > > 2) Will it be a problem If we write privacy considerations on IEEE > specifications? > 3) Do we need to consider the range of deployments of L2 (home, > enterprise, public PBB service, national PBB service, Data centers) > > > Thank you, Sue > > > -Origina
Re: [i2rs] [Last-Call] 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-boun...@ietf.org] On Behalf Of Qin Wu > Sent: Thursday, June 25, 2020 9:25 AM > To: Susan Hares; 'Christian Huitema'; sec...@ietf.org > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology....@ietf.org; > last-c...@ietf.org > Subject: Re: [i2rs] Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Sue and Christian: > I have responded to Christian on privacy issue, my proposal is to add MAC > address as another data node vulnerability example in our original security > consideration section. > But If Christian or security directorate has recommending text, we authors > are happy to accept it. > > -Qin > -邮件原件- > 发件人: Susan Hares [mailto:sha...@ndzh.com] > 发送时间: 2020年6月25日 21:04 > 收件人: 'Christian Huitema' ; sec...@ietf.org > 抄送: draft-ietf-i2rs-yang-l2-network-topology....@ietf.org; i2rs@ietf.org; > last-c...@ietf.org > 主题: RE: Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13 > > Christian: > > Thank you for catching the privacy issues. > > I've got a few questions to help the authors scope this change: > > 1) Since this is common to all L2 Topologies, can you or the security > directorate recommend some text that might be appropriate? >If you have recommended text, has this text been reviewed by OPS-DIR and > Yang doctors? > > 2) Will it be a problem If we write privacy considerations on IEEE > specifications? > 3) Do we need to consider the range of deployments of L2 (home, enterprise, > public PBB service, national PBB service, Data centers) > > > Thank you, Sue > > > -Original Message- > From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] > Sent: Thursday, June 25, 2020 1:01 AM > To: sec...@ietf.org > Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; > last-c...@ietf.org > Subject: Secdir last call review of > draft-ietf-i2rs-yang-l2-network-topology-13 > > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements and > considerations in IETF drafts. Comments not addressed in last call may be > included in AD reviews during the IESG review. Document editors and WG > chairs should treat these comments just like any other last call comments. > > This document describes a Yang model for representing Link Layer topologies. > Representing such topologies is obviously useful for managing network. > The security section is focused on securing the usage of this information for > network management, but does not address potential privacy issues. > > The security considerations explain correctly how altering the link layer > information could enable attacks against the network. The proposed remedy is > access control, implemented using either SSH or TLS. This is fine, although > the discussion of TLS authorisation is a bit short. By default, TLS verifies > the identity of the server but not that of the client. RFC8040 section 2.5 > specifies that "a RESTCONF server SHOULD require authentication based on TLS > client certificates. I assume that's the intent, but it might be useful to > say so. > > On the other hand, the security considerations do not describe privacy > issues, and
