Re: [ntpwg] comments on draft-stenn-ntp-suggest-refid-00

Sharon Goldberg <goldbe@cs.bu.edu> Tue, 05 April 2016 18:54 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C4012D8A6 for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Tue, 5 Apr 2016 11:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.798
X-Spam-Level:
X-Spam-Status: No, score=-6.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=gmail.com
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 iQaoZXVsI7PX for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Tue, 5 Apr 2016 11:54:14 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C93E712D7B7 for <ntp-archives-ahFae6za@lists.ietf.org>; Tue, 5 Apr 2016 11:54:14 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C159F86DC00 for <ntp-archives-ahFae6za@lists.ietf.org>; Tue, 5 Apr 2016 18:54:14 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 4B39086DAEC for <ntpwg@lists.ntp.org>; Tue, 5 Apr 2016 18:43:10 +0000 (UTC)
Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <sharon.goldbe@gmail.com>) id 1anVwS-0009zC-Bj for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 18:43:10 +0000
Received: by mail-wm0-x236.google.com with SMTP id n3so33295398wmn.0 for <ntpwg@lists.ntp.org>; Tue, 05 Apr 2016 11:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=uw1p0zf3XlV9r9Aw+xicvVIvojKe+llgtPjRu+ZV9Ls=; b=bt2pIx7jt6hvBCSb7yciOGy6TCsVcAJHAe488VIj5VIOnzX09pQCt/4FmS8ghfW8vb /u9o6Wugw5rA2yLF6BgQDbT8zIk/UjliplHnzB9ACuFj+9p5VoSUlX6MTAq+/Me6YZww mZah9Sm5tLLFmQ7csrjFhIzVTxwqUEulE+e8+wQE3Lmtp89m/Tq+NoPhTx83sppU6EST z2EI7d+/08/PQiXdtw+AC6+T9QDDBLHKStemzbMTTW9PFgdD4ZR1/WWntJVLFf1coVrs 588RyetZAc8zYf+nTayby1AUuRK5lwqhTrjyAZGOvhm29SUi06Q+8Pl4dQU95IlZ9QGj FLhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=uw1p0zf3XlV9r9Aw+xicvVIvojKe+llgtPjRu+ZV9Ls=; b=Fek+KebEqzCKUiExN1ZPVZJ7513WqCuWdiKdAJopPu5qyMI1siFEsKrQykbJu/tfhO 5D1lxElKSVfFMm2PmQvyQG/GLqBzGahx13aqD0pREnbSkhH5acDKQp5R4QAZ6qKuYFL2 M9mz3ofoMdMyhL3tW4RH/n87EMTYBurDZP0w5ywfIR1zds015abS9Vqs2M+mZyNfxg+j ltxoz+2icvGs+rmxL20isk3E7uWY/1M9Es2mqEusxPVi7EE72xRurGN20RfPnQX8k5+b 3bee+5QeeP2eM/pI4hwEiCe3HoYW2A1JTefcW0BWPU3ymvH44PAqcHAekelBcvvR3ZEc i2dg==
X-Gm-Message-State: AD7BkJKx3JajOYM9kA099Z0IeMpBSq/ypTp9LXamXvT4l5VsLNmQI6rLFapY2iAN6ZG1HbLZ4KdSOfPoD9RWpg==
X-Received: by 10.28.227.130 with SMTP id a124mr19633695wmh.2.1459881787023; Tue, 05 Apr 2016 11:43:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.71.200 with HTTP; Tue, 5 Apr 2016 11:42:27 -0700 (PDT)
In-Reply-To: <CAJHGrrQimUVqtRg6bowwBr5pxrSUh+mHkEzB0P1SBxP=nzczbg@mail.gmail.com>
References: <CAJHGrrQimUVqtRg6bowwBr5pxrSUh+mHkEzB0P1SBxP=nzczbg@mail.gmail.com>
From: Sharon Goldberg <goldbe@cs.bu.edu>
Date: Tue, 05 Apr 2016 14:42:27 -0400
X-Google-Sender-Auth: Kg8tIK5wcIehrB1W2IKSJlYeJHU
Message-ID: <CAJHGrrSBj19-12UY=GyYsx5FaaCqTSixaFdt0Sf=ELNL4DXUew@mail.gmail.com>
To: NTP Working Group <ntpwg@lists.ntp.org>, tictoc@ietf.org
X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::236
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: sharon.goldbe@gmail.com
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Subject: Re: [ntpwg] comments on draft-stenn-ntp-suggest-refid-00
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>
Content-Type: multipart/mixed; boundary="===============7112691241450838308=="
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>

All, just to summarize the conversation on meetcho just now. I think  that
this proposal would also solve the problem hashed IPv6 addresses colliding
with IPv4 addresses on the same network, which is addressed
in draft-stenn-ntp-ipv6-refid-hash-00.

Why? Because the only time a server will put an IP address in the refID
field is when it is responding to a query from *that specific IP*.  (Else,
it puts the "nonsense" value in the refID.)  So even if a collision
happens, it should not matter, since the only party to see the collision is
the IP that sent the query.

Sharon

On Tue, Apr 5, 2016 at 2:28 PM, Sharon Goldberg <goldbe@cs.bu.edu> wrote:

> Dear WG,
>
> To follow up on my comments on draft-stenn-ntp-suggest-refid-00 at the
> IETF'95 WG meeting just now. The current draft requires the use of an
> extension field.  I believe the goals of the draft can be accomplished
> without using an extension field, in a backwards compatible fashion.
>
> The goal of the draft is to limit the information exposed by the REFID
> while still preserving robustness to "length-1" timing loops where system A
> takes time from system B, but system B takes time from system A.
> This proposal allow system A to limit the info it leaks in its refID,
> without harming any of its legacy clients.
>
> Suppose system A is taking time from system B. Then there are two cases:
> 1) If A gets a time query from system B, A puts the IP of B in the refID
> of its response. This way, even a legacy B can tell it cannot take time
> from A because this would cause a timing loop.
>
> 2) If A gets a time query from system C, A puts a "nonsense" value in its
> refID.  Even a legacy C can see that its IP is not in the refID, and so it
> is allowed to take time from A.
>
> One question is what this "nonsense" value should be.  I think it should
> be a fixed value. For example 0.0.0.0.  We would not want a randomly-chosen
> value since this might collide with actual IP addresses on the network.
>
> Thanks,
> Sharon
>
>
> --
> Sharon Goldberg
> Computer Science, Boston University
> http://www.cs.bu.edu/~goldbe
>



-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg