IETF Logo Mail Archive

Re: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

"Mark Atwood" <mark.atwood@ntpsec.org> Mon, 16 September 2019 22:35 UTC

Return-Path: <mark.atwood@ntpsec.org>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB421200C4 for <ntp@ietfa.amsl.com>; Mon, 16 Sep 2019 15:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ntpsec.org
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 05tj5xIEOkB0 for <ntp@ietfa.amsl.com>; Mon, 16 Sep 2019 15:35:48 -0700 (PDT)
Received: from mx.ntpsec.org (mx.ntpsec.org [IPv6:2605:bc80:3010:104:0:2:0:4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1A512006D for <ntp@ietf.org>; Mon, 16 Sep 2019 15:35:47 -0700 (PDT)
Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: markatwood@ntpsec.org) by mx.ntpsec.org (Postfix) with ESMTPSA id 8A642286A7B; Mon, 16 Sep 2019 22:35:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ntpsec.org; s=dkim; t=1568673346; bh=LGbkbvVj7pO+XqUPIOi/kd/xqkXi8CReFi0EkPzkqhY=; h=In-Reply-To:References:Date:From:To:Subject; z=In-Reply-To:=20<20190916063649.3343940605C@ip-64-139-1-69.sjc.meg apath.net>|References:=20<20190916063649.3343940605C@ip-64-139-1-6 9.sjc.megapath.net>|Date:=20Mon,=2016=20Sep=202019=2015:35:25=20-0 700|From:=20"Mark=20Atwood"=20<mark.atwood@ntpsec.org>|To:=20ntp@i etf.org|Subject:=20=3D?UTF-8?Q?Re:_[Ntp]_Antw:_Re:_Antw:_Re:_Calls _for_Adoption_--_NTP_Extens?=3D=0D=0A=20=3D?UTF-8?Q?ion_Field_draf ts_--_Four_separate_drafts?=3D; b=P370AsvqNN2EHp61ZdPDBYPYurPDnJB72me29U8D52gEjfekSwtqMb+BGtNOPuCqM Z4RC9IxY46SKE2P0YcfCK0zbdzzWffr+SaXe+zjZDqp1rj+On1kn/c+G7KiZOOWvUa TAX4sGIbUGOCStKtc2xrZwLVI2dpSuHb5s0YPe6Y=
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 88F0221368; Mon, 16 Sep 2019 18:35:46 -0400 (EDT)
Received: from imap38 ([10.202.2.88]) by compute4.internal (MEProxy); Mon, 16 Sep 2019 18:35:46 -0400
X-ME-Sender: <xms:Qg6AXRkEgqRLYYxsBry_UOjQ5iZtOKak-6xuY7KqmKtIkG-iQUPyXg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeggdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrkhcutehtfihoohgufdcuoehmrghrkhdrrghtfiho ohgusehnthhpshgvtgdrohhrgheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfrghllh gvnhhpvghgrghsuhhsodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeitdel keegvdekuddquddvtdefudeivdelqdhmrghrkhdrrghtfihoohgupeepnhhtphhsvggtrd horhhgsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:Qg6AXaUsiBwTh0FL55X4LWPFHs33T8h3S32pKnOiBuW_9Ni5RqsJEQ> <xmx:Qg6AXd8AIAqKPc9H79Cr6AndLG5nvB5HoI2yQAl96VA6Lr6_EfDJiQ> <xmx:Qg6AXYvg7Gb2Jj4F2y7NBlJ4j9wcLmnForcGZ6HeicQu0ebLPr0qSg> <xmx:Qg6AXXorVxbOa3-_KHqMX3vTqvo5kAnx6rDpARjv8gJay_BdF3l9xg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5DCE54C000A6; Mon, 16 Sep 2019 18:35:46 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-237-gf35468d-fmstable-20190912v1
Mime-Version: 1.0
Message-Id: <68411c15-f838-4dd9-be3f-d6a09fcef399@www.fastmail.com>
In-Reply-To: <20190916063649.3343940605C@ip-64-139-1-69.sjc.megapath.net>
References: <20190916063649.3343940605C@ip-64-139-1-69.sjc.megapath.net>
Date: Mon, 16 Sep 2019 15:35:25 -0700
From: Mark Atwood <mark.atwood@ntpsec.org>
To: ntp@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/O-6T1bN97NVj3Tu_ARao5jsRvlU>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 22:35:49 -0000

On Sun, Sep 15, 2019, at 23:36, Hal Murray wrote:
> 
> mlichvar@redhat.com said:
> >> Can we assume that every server will have an Ethernet host address?
> > The vast majority will, but I'm not sure we can rely on them being random. 
> 
> They are definitely not random.  They are unique.  (unless somebody screws up)
> 
> Within a batch of Ethernet cards, they will probably be sequential.  (I'll say 
> more if anybody wants.)

In a past life, I've written the scripts that generate the mapping of manufacturing serial number to ethernet MAC addresses, and then generated the text files in the format requested by various manufacturing vendors so that they can fuse the MAC address into the device at manufacturing time, and so that the manufacturer and packaging vendors can print the necessary pcb labels and external case and box labels and barcodes.    And I've seen a lot of such other files that are sent to similar manufacturers.

I've never seen one that wasn't sequential.

The sequential relationship is so strong that it's used to identify supply chain and logistics glitches.


On the other other hand, you must not bet your life or your security on them being truly globally unique.   There are lots of chips in the supply chains and in warehouses that were manufactured off-label, grey market, unlicensed, and off-shift.   And anyone with kernel level or UEFI write level access to a box can persuade a chip or it's driver to lie about it's MAC.

..m

v2.23.0 | Report a Bug | By Email