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

[Alissa Cooper <[e-mail]>]

> On Apr 19, 2016, at 1:23 PM, joel jaeggli <[e-mail]> wrote:
> 
> On 4/19/16 10:12 AM, Alissa Cooper wrote:
>> 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.
> 
> 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,

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

> 
>> (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.