Date: Fri, 26 Jun 2020 15:11:45 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Susan Hares <shares@ndzh.com>
Cc: 'Christian Huitema' <huitema@huitema.net>,
 'Qin Wu' <bill.wu@huawei.com>, secdir@ietf.org, i2rs@ietf.org,
 draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org, last-call@ietf.org
Message-ID: <20200626131145.habw34iy5orl4d3m@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Susan Hares <shares@ndzh.com>,
 'Christian Huitema' <huitema@huitema.net>,
 'Qin Wu' <bill.wu@huawei.com>, secdir@ietf.org, i2rs@ietf.org,
 draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org,
 last-call@ietf.org
References: <B8F9A780D330094D99AF023C5877DABAAD7BAFD7@dggeml531-mbs.china.huawei.com>
 <002a01d64af8$f07320b0$d1596210$@ndzh.com>
 <15aa8236-ce09-d0b4-5f12-31f10b32387c@huitema.net>
 <006001d64bb6$68303850$3890a8f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <006001d64bb6$68303850$3890a8f0$@ndzh.com>
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/L-M3MgSIuMHkFRTtAuroVo8DcZQ>
Subject: Re: [i2rs] [Last-Call] Secdir last call review of
 draft-ietf-i2rs-yang-l2-network-topology-13
Precedence: list

But please s/agents/clients/ .

/js

On Fri, Jun 26, 2020 at 08:36:23AM -0400, Susan Hares wrote:
> Qin and Christian:=20
>=20
> This addition words for me.=20
>=20
> Sue=20
>=20
> -----Original Message-----
> From: Christian Huitema [mailto:huitema@huitema.net]=20
> Sent: Friday, June 26, 2020 12:05 AM
> To: Susan Hares; 'Qin Wu'; secdir@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology.all@ietf.or=
g; last-call@ietf.org
> Subject: Re: [Last-Call] [i2rs] Secdir last call review of draft-ietf-i=
2rs-yang-l2-network-topology-13
>=20
> How about adding something like this:
>=20
> Privacy Considerations
>=20
> The Yang model for layer 2 topology exposes privacy sensitive informati=
on, for example the MAC addresses of devices. Unrestricted use of such in=
formation can lead to privacy violations. For example, listing MAC addres=
ses in a network allows monitoring of devices and their movements. Locati=
on information can be derived from MAC addresses of network devices, bypa=
ssing protection of location information by the Operating System.
>=20
> Deployments should mitigate this privacy concerns by limiting access to=
 the layer 2 topology information. Access to the information should be re=
stricted to a minimal list of authorized agents, and should require prope=
r authentication of these agents.
>=20
> -- Christian Huitema
>=20
> On 6/25/2020 7:00 AM, Susan Hares wrote:
> > Qin and Christian:=20
> >
> > Thank you for your prompt attention to the privacy issue. =20
> > I'm sure Christian will respond in a bit - since he might be in PDT t=
ime-zone.=20
> >
> > Once you have a solution you both like, we should validate the privac=
y=20
> > changes to the security considerations section with the Yang-doctors,=
=20
> > OPS-ADs, and Security-ADs.
> >
> > Martin's watching this thread so I'm sure he'll help us out as well.=20
> >
> > Sue
> >
> > -----Original Message-----
> > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Qin Wu
> > Sent: Thursday, June 25, 2020 9:25 AM
> > To: Susan Hares; 'Christian Huitema'; secdir@ietf.org
> > Cc: i2rs@ietf.org;=20
> > draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org;=20
> > last-call@ietf.org
> > Subject: Re: [i2rs] Secdir last call review of=20
> > 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 s=
ecurity consideration section.
> > But If Christian or security directorate has recommending text, we au=
thors are happy to accept it.
> >
> > -Qin
> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: Susan Hares [mailto:shares@ndzh.com]
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B46=E6=9C=8825=E6=97=
=A5 21:04
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Christian Huitema' <huitema@huitema.net=
>; secdir@ietf.org
> > =E6=8A=84=E9=80=81: draft-ietf-i2rs-yang-l2-network-topology.all@ietf=
.org;=20
> > i2rs@ietf.org; last-call@ietf.org
> > =E4=B8=BB=E9=A2=98: RE: Secdir last call review of=20
> > draft-ietf-i2rs-yang-l2-network-topology-13
> >
> > Christian:
> >
> > Thank you for catching the privacy issues.     =20
> >
> > I've got a few questions to help the authors scope this change:=20
> >
> > 1) Since this is common to all L2 Topologies, can you or the security=
 directorate recommend some text that might be appropriate?=20
> >    If you have recommended text, has this text been reviewed by OPS-D=
IR and Yang doctors?=20
> >
> > 2) Will it be a problem If we write privacy considerations on IEEE sp=
ecifications?=20
> > 3) Do we need to consider the range of deployments of L2 (home,=20
> > enterprise,  public PBB service, national PBB service, Data centers)
> >
> >
> > Thank you,  Sue
> >
> >
> > -----Original Message-----
> > From: Christian Huitema via Datatracker [mailto:noreply@ietf.org]
> > Sent: Thursday, June 25, 2020 1:01 AM
> > To: secdir@ietf.org
> > Cc: draft-ietf-i2rs-yang-l2-network-topology.all@ietf.org;=20
> > i2rs@ietf.org; last-call@ietf.org
> > Subject: Secdir last call review of=20
> > 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 o=
ngoing effort to review all IETF documents being processed by the IESG.  =
These comments were written with the intent of improving security require=
ments and considerations in IETF drafts.  Comments not addressed in last =
call may be included in AD reviews during the IESG review.  Document edit=
ors and WG chairs should treat these comments just like any other last ca=
ll comments.
> >
> > This document describes a Yang model for representing Link Layer topo=
logies.
> > Representing such topologies is obviously useful for managing network=
.
> > The security section is focused on securing the usage of this informa=
tion for network management, but does not address potential privacy issue=
s.
> >
> > The security considerations explain correctly how altering the link l=
ayer information could enable attacks against the network. The proposed r=
emedy is access control, implemented using either SSH or TLS. This is fin=
e, although the discussion of TLS authorisation is a bit short. By defaul=
t, TLS verifies the identity of the server but not that of the client. RF=
C8040 section 2.5 specifies that "a RESTCONF server SHOULD require authen=
tication based on TLS client certificates. I assume that's the intent, bu=
t it might be useful to say so.
> >
> > On the other hand, the security considerations do not describe privac=
y issues, and I find that problematic. The proposed information model lis=
ts a number of sensitive data, such as for example the MAC addresses of d=
evices.
> > This information can be misused. For example, applications could asse=
ss device location fetching the MAC addresses of local gateways. Third pa=
rties could access link local information to gather identities of devices=
 accessing a particular network. Such information is often protected by p=
rivacy API in the Operating System, but accessing the Yang module over th=
e network might allow applications to bypass these controls.
> >
> > Client authentication alone does not necessarily protect against thes=
e privacy leaks. A classic configuration error would limit write access t=
o authorized users, but to allow read-only access to most users. This kin=
d of error would allow privacy leaks. Given the sensitive nature of MAC a=
ddresses and other identifiers, it is useful to warn against such errors.
> >
> >
> >
> >
> >
> > _______________________________________________
> > i2rs mailing list
> > i2rs@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2rs
> >
>=20
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--=20
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/>