IETF Logo Mail Archive

Re: [Ntp] WG Call for Adoption: draft-stenn-ntp-extension-fields

Hal Murray <hmurray@megapathdsl.net> Thu, 27 September 2018 08:36 UTC

Return-Path: <hmurray@megapathdsl.net>
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 D0391130E6F for <ntp@ietfa.amsl.com>; Thu, 27 Sep 2018 01:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.033
X-Spam-Level: *
X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982] autolearn=no 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 laW5rU4OrWVK for <ntp@ietfa.amsl.com>; Thu, 27 Sep 2018 01:36:19 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id AD243130E5E for <ntp@ietf.org>; Thu, 27 Sep 2018 01:36:18 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 41F8440605C; Thu, 27 Sep 2018 01:36:17 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: ntp@ietf.org
cc: hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Miroslav Lichvar <mlichvar@redhat.com> of "Wed, 26 Sep 2018 16:10:25 +0200." <20180926141025.GD9309@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Sep 2018 01:36:17 -0700
Message-Id: <20180927083617.41F8440605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/XRP2g5CUHQUNEn7elMTaieFpo_8>
Subject: Re: [Ntp] WG Call for Adoption: draft-stenn-ntp-extension-fields
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: Thu, 27 Sep 2018 08:36:21 -0000

> An NTPv4.1 packet would have the following format:
> - 48-octet NTPv4 header
> - 2-octet magic number (the packing EF type)
> - 2-octet length of all data following the NTP header (the packing EF
>   length)
> - >24 octets of one or more EFs with no restrictions on minimal length

A possible alternative would be an EF that said no bare MAC.
  2 byte magic number
  2 byte length

--------

Is this whole problem a wild goose chase?  If two systems are using MACs, they 
have exchanged keys.  Could they also exchange a no-bare-MAC flag using the 
same mechanism?

Why can't a system simply declare that it doesn't support bare MACs?  If so, 
why would anybody ever send it one?


-- 
These are my opinions.  I hate spam.

v2.23.0 | Report a Bug | By Email