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:[email protected]] > Sent: Friday, June 26, 2020 12:05 AM > To: Susan Hares; 'Qin Wu'; [email protected] > Cc: [email protected]; [email protected]; > [email protected] > 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:[email protected]] On Behalf Of Qin Wu > > Sent: Thursday, June 25, 2020 9:25 AM > > To: Susan Hares; 'Christian Huitema'; [email protected] > > Cc: [email protected]; > > [email protected]; > > [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]>; [email protected] > > 抄送: [email protected]; > > [email protected]; [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] > > Cc: [email protected]; > > [email protected]; [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] > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
