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

joel jaeggli <joelja@bogus.com> Tue, 19 April 2016 20:23 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B6012DA84; Tue, 19 Apr 2016 13:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level:
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWpXdIgKe8WR; Tue, 19 Apr 2016 13:23:23 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9124412B048; Tue, 19 Apr 2016 13:23:23 -0700 (PDT)
Received: from mb-2.local ([IPv6:2620:11a:c081:20:dd9e:698d:9698:e8a6]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u3JKNIXr021945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Apr 2016 20:23:19 GMT (envelope-from joelja@bogus.com)
To: Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>
References: <20160419171216.31521.25135.idtracker@ietfa.amsl.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <60449605-8547-4b73-e3aa-0c17c2c0a25e@bogus.com>
Date: Tue, 19 Apr 2016 13:23:16 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <20160419171216.31521.25135.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="JBHOUJDm6bKR7Gar74EnGCpbf7f8L7ubH"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/GXI_ntcoSCgIzTsFM7G8EL8EIr4>
Cc: tictoc-chairs@ietf.org, kodonog@pobox.com, tictoc@ietf.org, draft-ietf-tictoc-ptp-mib@ietf.org
Subject: Re: [TICTOC] Alissa Cooper's No Objection on draft-ietf-tictoc-ptp-mib-08: (with COMMENT)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2016 20:23:25 -0000

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,

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