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

joel jaeggli <joelja@bogus.com> Wed, 20 April 2016 23:04 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 51D5612DC7A; Wed, 20 Apr 2016 16:04:41 -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 CqrMzNKxWNx5; Wed, 20 Apr 2016 16:04:39 -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 9634312DA0B; Wed, 20 Apr 2016 16:04:39 -0700 (PDT)
Received: from mb-2.local ([IPv6:2601:647:4204:51:bc83:5fac:994b:9466]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u3KN4YGP039901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Apr 2016 23:04:35 GMT (envelope-from joelja@bogus.com)
To: Alissa Cooper <alissa@cooperw.in>
References: <20160419171216.31521.25135.idtracker@ietfa.amsl.com> <60449605-8547-4b73-e3aa-0c17c2c0a25e@bogus.com> <0A8B7D71-8F40-420F-81B0-C1E109DD2D55@cooperw.in>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <bae007da-a3b0-c004-1db6-d376b6022f67@bogus.com>
Date: Wed, 20 Apr 2016 16:04:32 -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: <0A8B7D71-8F40-420F-81B0-C1E109DD2D55@cooperw.in>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="HeAlJdMjRJIpodamq8R4rDRAHUBar5PEb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/07z7kWNw0U3DgowEwB0QuwTHcNU>
Cc: draft-ietf-tictoc-ptp-mib@ietf.org, tictoc-chairs@ietf.org, kodonog@pobox.com, IESG <iesg@ietf.org>, tictoc@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: Wed, 20 Apr 2016 23:04:41 -0000

On 4/20/16 3:50 PM, Alissa Cooper wrote:
> 
>> On Apr 19, 2016, at 1:23 PM, joel jaeggli <joelja@bogus.com
>> <mailto:joelja@bogus.com>> 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?

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.

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