Subject: [TICTOC] Alissa Cooper's No Objection on draft-ietf-tictoc-ptp-mib-08: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 19 Apr 2016 10:12:16 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-tictoc-ptp-mib-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-mib/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) The ClockIdentity is described as being generated based on an EUI-64
address as described in IEEE 1588-2008 Section 7.5.2.2.2. But in IEEE
1588-2008, there are two different ways the clock identifier can be
generated, the other being a non-EUI-64 address defined in 7.5.2.2.3. Why
is that option left out of the ClockIdentity description?

In general I was dismayed to see the re-use of EUI-64 for clock identity
for the security and privacy drawbacks, since it's not particularly clear
that re-using those identifiers is necessary here. But if such a fix is
warranted this MIB is not the place to do it in any event.

(2) Looking at
https://trac.tools.ietf.org/area/ops/trac/wiki/mib-security I recall that
other MIB documents we've reviewed recently have listed out the specific
tables/objects that may be considered vulnerable or sensitive, even if
those objects are read-only. Why doesn't this document do that? I would
think all of the clock identity objects would belong in that bucket at a
minimum.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Apr 2016 19:40:56 +0100

Good catch wrt the EUI. I missed that.

S.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Apr 2016 13:23:16 -0700

> https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-mib/

I don't see a whole lot wrong with using a mac address as an identifier
in a management system. 1588 speakers are frequently adjecent to each
other and almost always within the same management domain,

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 20 Apr 2016 15:50:46 -0700

> On Apr 19, 2016, at 1:23 PM, joel jaeggli <[email-masked]> wrote:
> 

Are you saying you don’t see a problem with not reflecting the mechanisms from 7.5.2.2.3 here? Or just generally that you don’t see a problem with using a MAC address as an identifier in this case?

Alissa

---

From: joel jaeggli <[email-masked]>
Date: Wed, 20 Apr 2016 16:04:32 -0700

On 4/20/16 3:50 PM, Alissa Cooper wrote:
> 
>> On Apr 19, 2016, at 1:23 PM, joel jaeggli <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> Are you saying you don’t see a problem with not reflecting the
> mechanisms from 7.5.2.2.3 here? Or just generally that you don’t see a
> problem with using a MAC address as an identifier in this case?

I don't see a problem generally with using a mac address as a unique
identifier in a management system. sources of actual genuine uniqueness
that are preserved across firmware upgrades, reboots and config wipes
and which are common across all platforms are hard enough to come by
without ruling them out. they're not of course immutable if you're
disinclined to expose them.

Are they appropriate in general for exposure on the internet or in local
but untrusted environments? No; 1588 master-slave relationships  are
also inappropriate under such circumstances.

---

From: Rodney Cummings <[email-masked]>
Date: Thu, 21 Apr 2016 09:02:01 +0000

Please keep in mind that this MIB is based on IEEE Std 1588-2008, and as such, the description of data set members like clockIdentity was copied from that standard.

There is ongoing work in the revision of IEEE 1588 to update clockIdentity to align with current IEEE RA rules. Although this project could certainly attempt to make similar updates, that runs the risk of contradicting the future IEEE 1588 revision.

I recommend to stay with IEEE Std 1588-2008 text.

Rodney Cummings
Co-chair of Architecture subcommittee, IEEE 1588 Working Group

> -----Original Message-----
> From: TICTOC [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Sent: Tuesday, April 19, 2016 12:12 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-tictoc-ptp-
> [email-masked]; [email-masked]
> Subject: [TICTOC] Alissa Cooper's No Objection on draft-ietf-tictoc-ptp-
> mib-08: (with COMMENT)
> 
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc

---

From: Tim Frost <[email-masked]>
Date: Fri, 22 Apr 2016 15:18:18 +0000

I agree with Rodney, since the MIB is based on IEEE1588-2008, we should stick with the methods adopted there, and that today means EUI-64.

As for the non-EUI-64 methods in 7.5.2.2.3, I don't remember consciously rejecting these, but they are for use with non-Ethernet networks, e.g. DeviceNet, ControlNet, PROFINet etc.
I'm not really familiar with the architectures of these networks.  Would such devices have IP connectivity and use SNMP to access management information? If so we should probably include these, if not, then I'm comfortable with restricting it to devices with an Ethernet-style MAC address.

Best regards,
Tim

Tim Frost   |   Calnex Solutions Ltd.   |   +44 (0) 7825 706 952   |   www.calnexsol.com

-----Original Message-----
From: Rodney Cummings [mailto:[email-masked]] 
Sent: 21 April 2016 10:02
To: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [TICTOC] Alissa Cooper's No Objection on draft-ietf-tictoc-ptp-mib-08: (with COMMENT)

Rodney Cummings

> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> (1) The ClockIdentity is described as being generated based on an 
> EUI-64 address as described in IEEE 1588-2008 Section 7.5.2.2.2. But 
> in IEEE 1588-2008, there are two different ways the clock identifier 
> can be generated, the other being a non-EUI-64 address defined in 
> 7.5.2.2.3. Why is that option left out of the ClockIdentity description?
> 
> In general I was dismayed to see the re-use of EUI-64 for clock 
> identity for the security and privacy drawbacks, since it's not 
> particularly clear that re-using those identifiers is necessary here. 
> But if such a fix is warranted this MIB is not the place to do it in any event.
> 
> (2) Looking at
> https://trac.tools.ietf.org/area/ops/trac/wiki/mib-security I recall 
> that other MIB documents we've reviewed recently have listed out the 
> specific tables/objects that may be considered vulnerable or 
> sensitive, even if those objects are read-only. Why doesn't this 
> document do that? I would think all of the clock identity objects 
> would belong in that bucket at a minimum.
> 
>