Re: [ntpwg] New Version Notification for draft-ietf-ntp-network-time-security-12.txt and draft-ietf-ntp-using-nts-for-ntp-03.txt

Harlan Stenn <stenn@ntp.org> Thu, 24 December 2015 01:58 UTC

Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE9E1AD05B for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Wed, 23 Dec 2015 17:58:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=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 OvrdIClxvebw for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Wed, 23 Dec 2015 17:58:25 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8B1AD059 for <ntp-archives-ahFae6za@lists.ietf.org>; Wed, 23 Dec 2015 17:58:25 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id F2E0986DB30 for <ntp-archives-ahFae6za@lists.ietf.org>; Thu, 24 Dec 2015 01:58:24 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from stenn.ntp.org (stenn.ntp.org [IPv6:2001:4f8:fff7:1::30]) by lists.ntp.org (Postfix) with ESMTP id 783B186D58E; Thu, 24 Dec 2015 00:47:04 +0000 (UTC)
Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86 (FreeBSD)) (envelope-from <stenn@stenn.ntp.org>) id 1aBtyk-000E6g-Qw; Thu, 24 Dec 2015 00:42:02 +0000
From: Harlan Stenn <stenn@ntp.org>
To: mayer@ntp.org
In-reply-to: <567B191C.5050801@ntp.org>
References: <56785CE5.6080102@ntp.org> <OFDECED69B.3FA71F92-ONC1257F22.0063AA4C-C1257F22.006401FE@ptb.de> <OF3D6DD6FA.812C6BCC-ONC1257F22.00775A28-C1257F22.00775A29@ptb.de> <567877FB.7030608@ntp.org> <OF0AC1CCBA.2E240196-ONC1257F23.00313FBA-C1257F23.0033AC80@ptb.de> <5679639D.4010906@nwtime.org> <56799A3E.3020506@ntp.org> <OFB626AB50.8283A0AC-ONC1257F24.002B274D-C1257F24.002CE30C@ptb.de> <567AB392.8040008@ntp.org> <E1aBqjC-000Dx3-DH@stenn.ntp.org> <567B191C.5050801@ntp.org>
Comments: In-reply-to Danny Mayer <mayer@ntp.org> message dated "Wed, 23 Dec 2015 16:58:52 -0500."
X-Mailer: MH-E 7.4.2; nmh 1.6; XEmacs 21.4 (patch 24)
Mime-Version: 1.0 (generated by tm-edit 1.8)
Date: Thu, 24 Dec 2015 00:42:02 +0000
Message-Id: <E1aBtyk-000E6g-Qw@stenn.ntp.org>
Subject: Re: [ntpwg] New Version Notification for draft-ietf-ntp-network-time-security-12.txt and draft-ietf-ntp-using-nts-for-ntp-03.txt
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <http://lists.ntp.org/pipermail/ntpwg/>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Cc: ntpwg@lists.ntp.org, ntpwg <ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Sender: ntpwg <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>

Danny Mayer writes:
> On 12/23/2015 4:13 PM, Harlan Stenn wrote:
> > Danny Mayer writes:
> >> ... The problem is that a
> >> MAC extension field needs to be specified so that it can replace the
> >> existing MAC field. I'm also considering allowing for multiple MAC
> >> extension fields in a single packet so that one MAC hashing algorithm
> >> can be retired if found to be compromisable without disrupting NTP
> >> infrastructure and existing implementations. It also needs some
> >> discussion on usage by responding packets and which to use.
> > 
> > If this is a V4 thing there will be backward compatability issues.
> 
> No, not really. New code like NTS would use the new Extension Field but
> the MAC will need to be kept for older systems who won't be able to use
> NTS anyway.

You mean "updated versions of ntpd" wil be able to use the new Extension
Field, right?

> > I think I have an idea about how to do this so older systems might still
> > work.  It will require more research though.
> 
> The older systems won't know about the NTS stuff so it doesn't matter.

This is not about NTS.  It's about your statement re using an extension
field for the MAC instead of the old MAC.

Think about the case where a new authenticated association is being spun
up and the initiating system does not know if the target system supports
this new extension field.

> The MAC itself can't go away until v5.

We've done a suboptimal job of supporting older NTP versions.  The good
news is that this hasn't caused problems so nobody has cared about it,
at least not enough to have ever emailed or opened a bug about it.

I don't think we'll have that luxury for v5 servers with v4 (or earlier)
clients.

And while we will need a mechanism in v5 to support v4 or earlier
versions, we can also implement a policy choice to decide what earlier
versions of the protocol the running ntpd will/won't support.
-- 
Harlan Stenn <stenn@ntp.org>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg