From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 06:28:12 2016 Return-Path: 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 F19CB12D124 for ; Fri, 1 Apr 2016 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 vhWpQFObru5L for ; Fri, 1 Apr 2016 06:28:10 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0F49412D0E7 for ; Fri, 1 Apr 2016 06:28:10 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 04A6A86DB95 for ; Fri, 1 Apr 2016 13:28:08 +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 1C29F86D77B for ; Fri, 1 Apr 2016 12:11:56 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alxvX-0001gU-IC for ntpwg@lists.ntp.org; Fri, 01 Apr 2016 12:11:56 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id u31CBfbA023434-u31CBfbC023434 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2016 14:11:41 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id E28AEC4A92; Fri, 1 Apr 2016 14:11:41 +0200 (CEST) In-Reply-To: <20160331182727.C8A29406078@ip-64-139-1-69.sjc.megapath.net> References: Message from Sharon Goldberg of "Thu, 31 Mar 2016 12:37:40 EDT." <20160331182727.C8A29406078@ip-64-139-1-69.sjc.megapath.net> To: Hal Murray , "NTP Working Group" , tictoc@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Fri, 1 Apr 2016 14:11:39 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kristof.teichel@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835502338670057451==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============1835502338670057451== Content-Type: multipart/alternative; boundary="=_alternative 0042FC7DC1257F88_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0042FC7DC1257F88_= Content-Type: text/plain; charset="US-ASCII" > Von: Hal Murray > An: NTP Working Group , tictoc@ietf.org > Kopie: Hal Murray > Datum: 31.03.2016 20:27 > Betreff: Re: [TICTOC] [ntpwg] WGLC on NTS: Round trips for key exchange > Gesendet von: "TICTOC" > > > goldbe@cs.bu.edu said: > > I suggest that NTS should encourage users to write the current time to a > > persistent file that is available upon reboot. This should be overwritten > > on every clock update. Then, when the client reboots, it can check that > > the expiry time of the certificates is no earlier than the last time time > > written to the presisent file. This limits the impact of attackers that use > > old compromised certificates to break the security of NTS. > > I think the issue of getting started is much more complicated than that. > > It probably deserves a separate document to collect all the ideas. I agree. > Individual documents like NTS should be explicit about what they are > assuming. Do they need valid (how close?) time or valid certificates or ??? I can see that a paragraph like this might be necessary. We will think about where it's appropriate (NTS main document or NTS-4-NTP). > The above paragraph assumes the system has a writable file system. The > "every clock update" may be too expensive for some systems. > > What happens the first time? Even if you assume that file was sanely > initialized at the factory, the unit may have sat on a shelf for a long time. > > What do you do if your clock gets set far into the future? > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc --=_alternative 0042FC7DC1257F88_= Content-Type: text/html; charset="US-ASCII" > Von: Hal Murray <hmurray@megapathdsl.net>
> An: NTP Working Group <ntpwg@lists.ntp.org>, tictoc@ietf.org
> Kopie: Hal Murray <hmurray@megapathdsl.net>
> Datum: 31.03.2016 20:27
> Betreff: Re: [TICTOC] [ntpwg]  WGLC on NTS: Round trips for key exchange
> Gesendet von: "TICTOC" <tictoc-bounces@ietf.org>
>
>
> goldbe@cs.bu.edu said:
> > I suggest that NTS should encourage users to write the current time to a
> > persistent file that is available upon reboot.  This should be overwritten
> > on every clock update.    Then, when the client reboots, it can check that
> > the expiry time of the certificates is no earlier than the last time time
> > written to the presisent file.  This limits the impact of attackers that use
> > old compromised certificates to break the security of NTS.
>
> I think the issue of getting started is much more complicated than that.
>
> It probably deserves a separate document to collect all the ideas.

I agree.

> Individual documents like NTS should be explicit about what they are
> assuming.  Do they need valid (how close?) time or valid certificates or ???

I can see that a paragraph like this might be necessary. We will think about where it's appropriate (NTS main document or NTS-4-NTP).

> The above paragraph assumes the system has a writable file system.  The
> "every clock update" may be too expensive for some systems.
>
> What happens the first time?  Even if you assume that file was sanely
> initialized at the factory, the unit may have sat on a shelf for a long time.
>
> What do you do if your clock gets set far into the future?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
 --=_alternative 0042FC7DC1257F88_=-- --===============1835502338670057451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1835502338670057451==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 06:29:25 2016 Return-Path: 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 E59B712D599 for ; Fri, 1 Apr 2016 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 CgtbIteZEgFd for ; Fri, 1 Apr 2016 06:29:23 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9F23212D159 for ; Fri, 1 Apr 2016 06:29:23 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6598D86DC25 for ; Fri, 1 Apr 2016 13:29:23 +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 8F09786D77B for ; Fri, 1 Apr 2016 12:19:01 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aly2P-0001nQ-Ak for ntpwg@lists.ntp.org; Fri, 01 Apr 2016 12:19:01 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id u31CIlsS023968-u31CIlsU023968 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2016 14:18:47 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id 533B2C4AA6; Fri, 1 Apr 2016 14:18:47 +0200 (CEST) In-Reply-To: References: <20160329152654.GH20902@localhost> <20160331125908.GG834@localhost> To: Sharon Goldberg , "NTP Working Group" , tictoc@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Fri, 1 Apr 2016 14:18:46 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kristof.teichel@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7488499934982172613==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============7488499934982172613== Content-Type: multipart/alternative; boundary="=_alternative 0043A348C1257F88_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0043A348C1257F88_= Content-Type: text/plain; charset="US-ASCII" > > On Thu, Mar 31, 2016 at 8:59 AM, Miroslav Lichvar wrote: > > On Thu, Mar 31, 2016 at 01:58:35PM +0200, kristof.teichel@ptb.de wrote: > > > To be honest, we had never assumed for IP fragmentation (on one request > > > and one response) to be a huge problem. > > > > One request and response could still be a problem. If the client is > > not able to receive fragmented packets, it won't be able to initialize > > the NTS association. > > Right, to second that, there are middleboxes that block fragmented packets. > > > > If people see grave problems with it, we would welcome an > > > elaboration as to why this is. > > > > I'm not sure and I was hoping others would comment on that. It seems > > to me problems with IPv4 fragmentation are quite common due to > > firewalls dropping ICMP packets or IP fragments, and IPv6 doesn't seem > > to recommend sending packets larger than 1500. > > To add to that, fragmentation is commonly used as an attack vector. > I would strongly discourage the use of IP fragmentation in what is > supposed to be a security protocol. Please see these references for > a small sampling of examples. Is the issue specific to IP fragmentation of UDP packets? Or to IP fragmentation in general? (I'm assuming it does not apply to all possible kinds of packet fragmentation.) I'm sorry, I have yet to go over the linked documents. > https://www.nanog.org/sites/default/files/mon.general.fragmentation.bonica.pdf > > http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf > > http://arxiv.org/abs/1205.4011 > > https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis- > Attacking_IPv6-WP.pdf > > http://www.iss.net/security_center/reference/vuln/TearDrop.htm > > https://www.offensive-security.com/wifu/Fragmentation-Attack-in-Practice.pdf > > Even if you don't see a SPECIFIC attack on NTS in these papers, my > point is that we can usually find a way to exploit IP fragmentation > in unexpected ways to break security. This has happened over and > over in the last two decades on many different protocols. In fact > this is exactly what we did in our recent NTP paper, Section VI: > > .https://eprint.iacr.org/2015/1020.pdf > > I would strongly object to having NTS rely on IP fragmentation. > This would be a horrible design decision. Noted. --=_alternative 0043A348C1257F88_= Content-Type: text/html; charset="US-ASCII" > > On Thu, Mar 31, 2016 at 8:59 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > On Thu, Mar 31, 2016 at 01:58:35PM +0200, kristof.teichel@ptb.de wrote:
> > > To be honest, we had never assumed for IP fragmentation (on one request
> > > and one response) to be a huge problem.
> >
> > One request and response could still be a problem. If the client is
> > not able to receive fragmented packets, it won't be able to initialize
> > the NTS association.
>
> Right, to second that, there are middleboxes that block fragmented packets.
>  
> > > If people see grave problems with it, we would welcome an
> > > elaboration as  to why this is.
> >
> > I'm not sure and I was hoping others would comment on that. It seems
> > to me problems with IPv4 fragmentation are quite common due to
> > firewalls dropping ICMP packets or IP fragments, and IPv6 doesn't seem
> > to recommend sending packets larger than 1500.
>
> To add to that, fragmentation is commonly used as an attack vector. 
> I would strongly discourage the use of IP fragmentation in what is
> supposed to be a security protocol.  Please see these references for
> a small sampling of examples.

Is the issue specific to IP fragmentation of UDP packets? Or to IP fragmentation in general?
(I'm assuming it does not apply to all possible kinds of packet fragmentation.)
I'm sorry, I have yet to go over the linked documents.
 
> https://www.nanog.org/sites/default/files/mon.general.fragmentation.bonica.pdf
>
> http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
>
> http://arxiv.org/abs/1205.4011
>
> https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis-
> Attacking_IPv6-WP.pdf
>
> http://www.iss.net/security_center/reference/vuln/TearDrop.htm
>
> https://www.offensive-security.com/wifu/Fragmentation-Attack-in-Practice.pdf
>
> Even if you don't see a SPECIFIC attack on NTS in these papers, my
> point  is that we can usually find a way to exploit IP fragmentation
> in unexpected ways to break security. This has happened over and
> over in the last two decades on many different protocols. In fact
> this is exactly what we did in our recent NTP paper, Section VI:
>
> .https://eprint.iacr.org/2015/1020.pdf
>
> I would strongly object to having NTS rely on IP fragmentation.  
> This would be a horrible design decision.
Noted. --=_alternative 0043A348C1257F88_=-- --===============7488499934982172613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7488499934982172613==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 07:41:47 2016 Return-Path: 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 A95C012D588 for ; Fri, 1 Apr 2016 07:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, 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=unavailable 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 8pk2SZ8XbdMI for ; Fri, 1 Apr 2016 07:41:43 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id EA98B12D603 for ; Fri, 1 Apr 2016 07:34:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C0C5686DBBB for ; Fri, 1 Apr 2016 14:34:40 +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 3066D86DB7B for ; Fri, 1 Apr 2016 13:00:42 +0000 (UTC) Received: from mail-yw0-x22a.google.com ([2607:f8b0:4002:c05::22a]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alygl-0002IJ-Ld for ntpwg@lists.ntp.org; Fri, 01 Apr 2016 13:00:42 +0000 Received: by mail-yw0-x22a.google.com with SMTP id g127so157323542ywf.2 for ; Fri, 01 Apr 2016 06:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PXgEsz3juLMQv8fYbcFRvhobx5hwvKsm0qdQDCHelko=; b=wY1iu0ZQTpQbabLKXMibEKA+C0AzZV9D7BPl0l+w6dctkYcguOgd8AcXYKbx5kmvys QqI4FkmIOzcFwuVuLoS/KxMMj6Sl/c7aLAnJsDdgI4Lzqzi2RASrBQolvaKSXEZkA6HR EqbDRCeRmpsVrsQ2UWZdVfBo1tjjHODIxd3X4Saz+WTA5nqopGB92qspC4pPk9LRzocb P6ufxeMfXd7uoG/1gH22zhjnz9W22yMGOwN1WmNmGqhEQseflQoxYWgAly369bYj+nXj 7WEfvw8wJlxRpd/RgT/Opf555qTNAOtInuiwSCJyXUHzTosHzsqaKAQuac++5fQIKMhI a7Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PXgEsz3juLMQv8fYbcFRvhobx5hwvKsm0qdQDCHelko=; b=XdzkHGD09MA8P1qUwQj6lCbWMQ0KhJQW3NIVqhwdGw2Zzj9W3Et33MKTvlB01qzapj s8hXMoqlBuAnOPqJDWBdxXJFELdRdIxbLO+sYreQRYk3P8Kn8fpIkAtSivyzxjuc+cym uWz8cynF/p8RvIN6h1GI0Se/aKpd3qVdLprHRkdGF1c0YPJJ0Ea+Ap3UYmiC49FmNSsO Ueuq3T+pJ9z8/VATYd3zqmndNhRcmGpUC2+kUN6CpYDd/hGL+Eyrp58IoLgaexJn29fB oFdlLGV1Pn/nKEiPvjX/eRsNC/Nqy3NewTthe0pJMKP4UTE0+aYGelikEQsmnrcAMemp YF2g== X-Gm-Message-State: AD7BkJKgACRw2yV32qm81i97YNmWB0jnhtX28oMP7DVK2aoN1Q25dmqSpuI09x3JEQ0hTQ== X-Received: by 10.129.153.193 with SMTP id q184mr2613177ywg.345.1459515632483; Fri, 01 Apr 2016 06:00:32 -0700 (PDT) Received: from [100.98.118.194] (126.sub-70-192-8.myvzw.com. [70.192.8.126]) by smtp.gmail.com with ESMTPSA id w79sm3532741ywd.55.2016.04.01.06.00.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2016 06:00:29 -0700 (PDT) Mime-Version: 1.0 (1.0) From: Sharon Goldberg X-Mailer: iPhone Mail (13E234) In-Reply-To: Date: Fri, 1 Apr 2016 09:00:28 -0400 Message-Id: References: <20160329152654.GH20902@localhost> <20160331125908.GG834@localhost> To: kristof.teichel@ptb.de X-SA-Exim-Connect-IP: 2607:f8b0:4002:c05::22a 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] [TICTOC] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.org Content-Type: multipart/mixed; boundary="===============8204593990216965646==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============8204593990216965646== Content-Type: multipart/alternative; boundary=Apple-Mail-C4351318-B1B8-4D96-AC37-1D1F1CC49A0D Content-Transfer-Encoding: 7bit --Apple-Mail-C4351318-B1B8-4D96-AC37-1D1F1CC49A0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sharon, on phone=20 > On Apr 1, 2016, at 8:18 AM, kristof.teichel@ptb.de wrote: >=20 > > > On Thu, Mar 31, 2016 at 8:59 AM, Miroslav Lichvar wrote:=20 > > > On Thu, Mar 31, 2016 at 01:58:35PM +0200, kristof.teichel@ptb.de wrote= : > > > > To be honest, we had never assumed for IP fragmentation (on one requ= est > > > > and one response) to be a huge problem. > > >=20 > > > One request and response could still be a problem. If the client is > > > not able to receive fragmented packets, it won't be able to initialize= > > > the NTS association. > > > > Right, to second that, there are middleboxes that block fragmented packe= ts. > > =20 > > > > If people see grave problems with it, we would welcome an=20 > > > > elaboration as to why this is. > > >=20 > > > I'm not sure and I was hoping others would comment on that. It seems > > > to me problems with IPv4 fragmentation are quite common due to > > > firewalls dropping ICMP packets or IP fragments, and IPv6 doesn't seem= > > > to recommend sending packets larger than 1500.=20 > >=20 > > To add to that, fragmentation is commonly used as an attack vector.=20 > > I would strongly discourage the use of IP fragmentation in what is=20 > > supposed to be a security protocol. Please see these references for > > a small sampling of examples.=20 >=20 > Is the issue specific to IP fragmentation of UDP packets? Or to IP fragmen= tation in general?=20 > (I'm assuming it does not apply to all possible kinds of packet fragmentat= ion.)=20 > I'm sorry, I have yet to go over the linked documents.=20 All fragmentation. The following paper affects both tcp and udp. =20 https://www.usenix.org/legacy/event/woot11/tech/final_files/Gilad.pdf Again. My point is that we should not be relying on fragmentation in NTS. It= regularly leads to unexpected attacks. =20 Also quoting Ron Bonica from the first linked conversation below: "please don't write new applications that fragment packets." Sharon=20 > =20 > > https://www.nanog.org/sites/default/files/mon.general.fragmentation.boni= ca.pdf > >=20 > > http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf > >=20 > > http://arxiv.org/abs/1205.4011 > >=20 > > https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis- > > Attacking_IPv6-WP.pdf > >=20 > > http://www.iss.net/security_center/reference/vuln/TearDrop.htm > >=20 > > https://www.offensive-security.com/wifu/Fragmentation-Attack-in-Practice= .pdf > >=20 > > Even if you don't see a SPECIFIC attack on NTS in these papers, my=20 > > point is that we can usually find a way to exploit IP fragmentation > > in unexpected ways to break security. This has happened over and=20 > > over in the last two decades on many different protocols. In fact=20 > > this is exactly what we did in our recent NTP paper, Section VI: > >=20 > > .https://eprint.iacr.org/2015/1020.pdf > >=20 > > I would strongly object to having NTS rely on IP fragmentation. =20 > > This would be a horrible design decision. >=20 > Noted. --Apple-Mail-C4351318-B1B8-4D96-AC37-1D1F1CC49A0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


Sharon, on phone 
On Apr 1, 2016, at 8:18 AM, kristof.teichel@ptb.de wrote:

> > On Thu, Mar 31, 2016 at 8:59 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > On Thu, Mar 31, 2016 at 01:58:35PM +0200, kristof.teichel@ptb.de wrote:
> > > To be honest, we had never assumed for IP fragmentation (on one request
> > > and one response) to be a huge problem.
> >
> > One request and response could still be a problem. If the client is
> > not able to receive fragmented packets, it won't be able to initialize
> > the NTS association.
>
> Right, to second that, there are middleboxes that block fragmented packets.
>  
> > > If people see grave problems with it, we would welcome an
> > > elaboration as  to why this is.
> >
> > I'm not sure and I was hoping others would comment on that. It seems
> > to me problems with IPv4 fragmentation are quite common due to
> > firewalls dropping ICMP packets or IP fragments, and IPv6 doesn't seem
> > to recommend sending packets larger than 1500.
>
> To add to that, fragmentation is commonly used as an attack vector. 
> I would strongly discourage the use of IP fragmentation in what is
> supposed to be a security protocol.  Please see these references for
> a small sampling of examples.

Is the issue specific to IP fragmentation of UDP packets? Or to IP fragmentation in general?
(I'm assuming it does not apply to all possible kinds of packet fragmentation.)
I'm sorry, I have yet to go over the linked documents.

All fragmentation. The following paper affects both tcp and udp.  


Again. My point is that we should not be relying on fragmentation in NTS. It regularly leads to unexpected attacks.  

Also quoting Ron Bonica from the first linked conversation below:

"please don't write new applications that fragment packets."

Sharon 
 
> https://www.nanog.org/sites/default/files/mon.general.fragmentation.bonica.pdf
>
> http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
>
> http://arxiv.org/abs/1205.4011
>
> https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis-
> Attacking_IPv6-WP.pdf
>
> http://www.iss.net/security_center/reference/vuln/TearDrop.htm
>
> https://www.offensive-security.com/wifu/Fragmentation-Attack-in-Practice.pdf
>
> Even if you don't see a SPECIFIC attack on NTS in these papers, my
> point  is that we can usually find a way to exploit IP fragmentation
> in unexpected ways to break security. This has happened over and
> over in the last two decades on many different protocols. In fact
> this is exactly what we did in our recent NTP paper, Section VI:
>
> .https://eprint.iacr.org/2015/1020.pdf
>
> I would strongly object to having NTS rely on IP fragmentation.  
> This would be a horrible design decision.
Noted.
--Apple-Mail-C4351318-B1B8-4D96-AC37-1D1F1CC49A0D-- --===============8204593990216965646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============8204593990216965646==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 08:26:44 2016 Return-Path: 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 175D412D187 for ; Fri, 1 Apr 2016 08:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, 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 (1024-bit key) reason="fail (message has been altered)" header.d=mscc365.onmicrosoft.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 EffNvjxg5h11 for ; Fri, 1 Apr 2016 08:26:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 72DC212D691 for ; Fri, 1 Apr 2016 08:26:39 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6CC8F86DC0E for ; Fri, 1 Apr 2016 15:26:39 +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 D3BFA86DB64 for ; Fri, 1 Apr 2016 15:25:00 +0000 (UTC) Received: from mail-bn1on0082.outbound.protection.outlook.com ([157.56.110.82] helo=na01-bn1-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1am0wO-0004Xy-UB for ntpwg@lists.ntp.org; Fri, 01 Apr 2016 15:25:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+/CpvH7Y+TNaEHTlZ19xeUuZqoarpIEUB00jXKPb+u8=; b=U0ncpUefshcBV2B81d57QXtzVwi/akX76OycqObK5gKGjTOcJGsPpVqdUjTHtDNBm/I18l3ss7JJz9nqGejfMGx4/X7yfULsQPzFGk3s8IKu3/oiXx1kG3Qd5NbYRqmrjFClMqk63G72xqFdPqBehkxpmVx3SqUeO6vr5qGp2hY= Received: from BLUPR02CA043.namprd02.prod.outlook.com (10.160.23.161) by DM2PR0201MB1008.namprd02.prod.outlook.com (10.160.219.142) with Microsoft SMTP Server (TLS) id 15.1.443.12; Fri, 1 Apr 2016 15:24:50 +0000 Received: from BY2FFO11FD032.protection.gbl (2a01:111:f400:7c0c::168) by BLUPR02CA043.outlook.office365.com (2a01:111:e400:8ad::33) with Microsoft SMTP Server (TLS) id 15.1.447.15 via Frontend Transport; Fri, 1 Apr 2016 15:24:50 +0000 Authentication-Results: spf=none (sender IP is 208.19.100.20) smtp.mailfrom=microsemi.com; lists.ntp.org; dkim=none (message not signed) header.d=none;lists.ntp.org; dmarc=none action=none header.from=microsemi.com; Received-SPF: None (protection.outlook.com: microsemi.com does not designate permitted sender hosts) Received: from avsrvexchhts2.microsemi.net (208.19.100.20) by BY2FFO11FD032.mail.protection.outlook.com (10.1.14.210) with Microsoft SMTP Server (TLS) id 15.1.453.6 via Frontend Transport; Fri, 1 Apr 2016 15:24:48 +0000 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avsrvexchhts2.microsemi.net (10.100.34.106) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 1 Apr 2016 08:24:43 -0700 Received: from SJSRVEXCHMBX2.microsemi.net ([fe80::6da0:6f9d:d5d1:3d5d]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0266.001; Fri, 1 Apr 2016 08:24:42 -0700 From: Greg Dowd To: Sharon Goldberg , "kristof.teichel@ptb.de" Thread-Topic: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange Thread-Index: AQHRjCOg8DZ6a195Q0ieQP0IjDuxIp91OaLg Date: Fri, 1 Apr 2016 15:24:41 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BF7AAFC3EA@sjsrvexchmbx2.microsemi.net> References: <20160329152654.GH20902@localhost> <20160331125908.GG834@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.82] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:208.19.100.20; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(428002)(377454003)(24454002)(189002)(243025005)(199003)(16236675004)(50986999)(54356999)(15975445007)(76176999)(19617315012)(19300405004)(106466001)(106116001)(101416001)(86362001)(102836003)(1220700001)(3846002)(1096002)(105586002)(19580395003)(19580405001)(6116002)(4326007)(15395725005)(55846006)(551934003)(2906002)(790700001)(16796002)(19625215002)(84326002)(31430400001)(33656002)(586003)(5008740100001)(2501003)(512874002)(5250100002)(11100500001)(5004730100002)(92566002)(87936001)(2950100001)(2920100001)(6806005)(5003600100002)(189998001)(81166005)(53416004)(2900100001)(5001770100001)(562404015)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB1008; H:avsrvexchhts2.microsemi.net; FPR:; SPF:None; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD032; 1:EQZoaBISiO9L8Oh6UGePjmobmh5yBHq5gdMasKoSH/iY+9lhl43FLjFyHJglBgaF1PVx035rUvqUPjd2tiWEMFBy5K3gmr5bkAoLEyniDc6MZWnITxrbz2IxiYidsut8YUmvzi1EF54qD+cfsLBk7Icyng/uMPun6ThB1yAwyvvC3NDmqqGGanAzV8FtxL3f1d8SgceGvpKtv+bNKYXyWxZggNi9y0lGHn4G9JnhkpR1lEiyID7oCxTXDBBxsY6GXJETTcrJW2zkAaH07uKMUFvt34ajhbZID/bwc2+FrJCW3mlYJP34PZAmB0qEjAqFZMJjdoRYJMUl/IgsvfabLLshNB6NGmsAlgSWuNj5BsmrKkjLTwHUzEctdJkPeaD1VXPexOWpuj/Z2zDl/6enp7b4lE2wBngR7oEZgbpPzjH7soKdHRNUzCErU3u2/BZmoMBsjjLo1YOU/Ofyj7JA/WP4P6U8rQ75klQaG72QC20bmwRhPHl1v7iXi9vGWGot X-MS-Office365-Filtering-Correlation-Id: 02db6e9f-dd6d-417c-a7c8-08d35a41c418 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB1008; 2:1O0VL+4a9xpvbvvaniBkGZ49Oak7vQo+WPlx2yHBHjShq/HwacDjT5/iIHdndRUjr4yIt8NqXSjisvoMX2gt6hSokny45q4FXmT0ARSoQDr1ztEDcHv387KkVnMte82lOk/8FlcPeYR/cqfx3Kp1XKss7zZX8hXajMapj/y5zB1RMCYiTHGbfe2sBWeEB0K0; 3:m19gNXetRfHg4meUT/Iddas6i1wpSj2OhqW3i4aFkv5ump6h4WLn58urVeqieAYqMN6sTWZJA08OswdGJDxW0SxDdxumkhJkXhRLv42dpUom+xl8/BgKRJZR+mB0feSn5NW5ATF7ltbsso+aesK4zBGXplVaE70Thl8xraTCumZe/09FzTXGX0IW1804Z849c1W0I9KbPhmrG0g00SoZi0kI659/eiahgcfQ5sE4zeI=; 25:6c3q0Oq0mBr75Z3YYGXP7d3SZfIxPWWFHkVqjoPhPflgr/kMuT//QUF0jUCMqKjdPALgdqebmUFW5GUzgMaGv/DoIZ9HKFUxVwBuahuZwmHzvLl2g9w58fgBGLr0527A1BXBFdv+zSetIbzeNM770z23lWLm3+UH6yABk63qDeeqAcFQ5uOk4udavsxanxSczfkeux2wFA3or5X+NmVJqpUazk9T6OKM8DeVGShoXMb3m8IjORKpXmDs1toQIUEUhHo0YstxtxiObOoOKMGOYIUTEvxLM0LHnAuFJX21wtKMZoXH67hnK+4FSSkWgsKWx8tEGHwYJV/IY8x3Q7M+95Bsw2fD+UBw5nndSot0Qgk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB1008; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB1008; 20:07djoHlgNg0AWeQMyEwMRxSZVf8aV1CHskhMGauZ31lsrpqUcvQ2pzdubEQjWFxgk2zF/9DJ2Y6sHfhwfg6EQSciKCFdZI3HqWfXkKIkrg76FIuPUQUl6++WDiCh5Wp6Oscc7erHs5LTqxoK3fgVS6b3wGHo3uPDLkrdrO5To5zGfMlF3ns68IXnsfPpFg1XS296EcvLxRUQx9D4TW/C0Kn21Sl/F6HVlMD1+TAJkhXK2iAMaV25lTIH1swFJplmOrxrv6B8D00kYIHR1sVACx/GRbivvQUpj/8axCsUOO+ovbMr7FayEDPiDPRgV5Ee3q1pZzqwbX7MG0f4ehzrsoIu3pLIrRWwfpr4MYzCO7+mUZ4g3ZrxdgWPVEtxTDtj93Na+cCmAzEb6dhI+4+OnXNVx6rP/gEVCloUGcUm6lrmLEWpoB9iKSBov03a7al611RsYVO4caZruncJB1JWR4PAWQLJz2jOnrzNqjBXnbX8dJbbADs6uCEDzRxZoecz; 4:dxzWQD07tPDIcZlhuf8rJu8t/w709ffS4ZzuDA6bdLWvOn1kFKjqcGCj7IjDTbdZX4rWsHjVzsuPGZ6iuwrAAHmilSi5QKlnYFAWjQFm/JnHVoQfXA3Ku2/VwP7PR+kmtbNC36fxQWosqPlhgmsYW9zGUsOF/Vs6q2MMHsibJvUInYPWfXX9GgkLansM5rIEGg8b16aBiSn3zQRyS7UYe90+K54hGPapro0OBGYYCkr4PQhJ69chYiB6GDASKtEwhZn84Oe3tsw0cNmrfl1qSRXVdyOJOx+n9xb6I3vwfwmeuNnMz11wjKjv7IXsDTPCngxZHHB2Ld/SDNVl+hWr81RDU8QPj/PtMmqNy0aK4FGwcSlwrArejZveAH9tKHHc0A3viMHt/5Zq+KBOjqDxnLPb8BASPtPSMEjWV/iwGoZNiCx2U3lfCsN9Pc5N6AsY X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(13023025)(13016025)(8121501046)(5005006)(13024025)(3002001)(10201501046); SRVR:DM2PR0201MB1008; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB1008; X-Forefront-PRVS: 0899B47777 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0201MB1008; 23:855fGl0PWt/1zk9id7e2iO8i2J99g7crGi5P2qy?= =?us-ascii?Q?0t4ra++fDfWxcZEqhuJpSkLPqLYmykINQR/aObf32vUqeoowrPppOYtsZw8B?= =?us-ascii?Q?U7F0F0kMA4C2PN0i3Is9W1BXUHO1cDCEJlvpXC9CPRJTAsIcJKrxLXMcOfKz?= =?us-ascii?Q?IKT3ljXrPFcGajM+25c8mjPN2K2tAoxr6XKvfkpVZXXvvUlc96jT1NagBgE8?= =?us-ascii?Q?/Hip+phUHwu8H+joWhG2t3npbFB+gmaj0soAGpB0O+W7/wz+BjVu/2hwBX4N?= =?us-ascii?Q?OyhgbJzqWbznjZi3MPGo+64lVdUhxviZGeMs6O+tLw+fiYvP7wWcY2XY9IB1?= =?us-ascii?Q?rvus2UlIfL6YA0iZBWH85oaTHWm2nd28MTGjEPO0eBM690qIDla6PzKwvvFu?= =?us-ascii?Q?+Fnmix7MfhpOKhpFrLkFY89FSsLrdoOvDRJSJpfZVmvrYRPJ7wwwDYkB2zIp?= =?us-ascii?Q?Fv6vRL/ftrTjJTUmPmyFHOiBekc40lnFzYYjA7C3CHNraK4ZcbPuH/iglnz2?= =?us-ascii?Q?mf7+Wu3R/oQWVrskchrIcjfUDAmZxFDiHiUDuZaogur+nwUZ2svalzotCC6V?= =?us-ascii?Q?UoEqe6gjinuwPFdXmIPVYp7ggA5ccQWXDyEOub4xML4PUdtR8W4oRP2WJZrZ?= =?us-ascii?Q?XbiKGaX5zyfoyiw8TgacFgJtFGXezGtJCcArL6ci8c+Q1CRO2XfTYp+VtU33?= =?us-ascii?Q?XLEryk4MHfLbrpjbKSeOi07eQHmpAJjSq3goxIIz0zUBh8nfmtWq0e6XcLgd?= =?us-ascii?Q?+zXL9x5MHKc7fsWrwrseIiXfUYKXZ2ec/QZpzqwz7jVLMiGmJymnSVd3FGjz?= =?us-ascii?Q?0smTN7f8dh+x0jvfIYU9keANo2q4JdoMC35msJ75pE8DKSxTU29tcqnqASDm?= =?us-ascii?Q?T72179Tt/qWgiI6oQdnrYQIdtdausozF6f3DIyeKo/DiFGtxiX1nyJ/i4i6B?= =?us-ascii?Q?2HkYcyW+5owF3YhmLAn/gJHyqZnCI+/wW1w+Q9wS5KltH7Bbofqox+LoXNFB?= =?us-ascii?Q?fyrtjWgk7nRU2buZzLlNE0WxgOF2iLC+qf2aOScu+kK8ccdzdob+q9XdzPAg?= =?us-ascii?Q?l2OW4YDzofOwvqEappzDW00bXpMuWA/A5YTgcUdV+TpjFQbwIk1hZ0ciOtjj?= =?us-ascii?Q?15GRMBZ81WSAVPq44SiUrFuZLrr9PPTScbq91VqRPvjqQLjAt/d/SNua+PEb?= =?us-ascii?Q?xuf+dC8Ap6FEjQC1HwrNjOOyA5+JhTG4nGPa0KX7ejQwVox7KE0id9eRVH5w?= =?us-ascii?Q?S27rkjWayVoZI67KrYVCZCdrNbisG+iyOJsIs4LbBR5tunBjjIKH9k7T1k80?= =?us-ascii?Q?QOxGzpNHchVabLWSA46qeZp12c/dIyuuctTITdEXDBjfNkpf+WGimTDtIqNu?= =?us-ascii?Q?4G594Hr8GqplEZTq9P1IgsHORkj6MjP53mRhJE9HzRE6H5OvQFGKFfNVvSp1?= =?us-ascii?Q?ROhYohAF9glDacHaoAsd9M/dUTWGj4IgutFPOuhhcXnFFvKEVHCuKZ3qorud?= =?us-ascii?Q?01UtAyMGhH6tjxQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB1008; 5:lazXKFqdUADQAzW0KSH/zknS66HXh7w/D3H3JknnsKmjrn9y4WxwssWKyA90jTyfNzChopS5pQw1jgPxdSWUzYASfO0+WtKG1NEw/qDjo6H6RdaTis1p3PjmcazDjPP4XVfsLhRWY8SIaBFDyWLliw==; 24:DIt2ZUkjoph6j9CdnT42GYnJHCp2prXK8xFND/nj1Nn07z40v6TIDdjRHI7M8Do5ZECFPCNibCWUl9fM3xf9bG2hI5Qj3h2DYpusAdB74AY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2016 15:24:48.2940 (UTC) X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.20]; Helo=[avsrvexchhts2.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB1008 X-SA-Exim-Connect-IP: 157.56.110.82 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Greg.Dowd@microsemi.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============7053758990970549851==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============7053758990970549851== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_8D2BF679AAC7C346848A489074F9F8BF7AAFC3EAsjsrvexchmbx2mi_" --_000_8D2BF679AAC7C346848A489074F9F8BF7AAFC3EAsjsrvexchmbx2mi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVtb3ZpbmcgZnJhZ21lbnRhdGlvbiBieSBkZWZpbml0aW9uIGluIGFuIGFwcGxpY2F0aW9uIHBy b3RvY29sIGlzbuKAmXQgZXZlbiBwb3NzaWJsZSBpbiBJcHY0IGFzIHJvdXRlcnMgY2FuIGZyYWcu ICBJdCBzZWVtcyBhIGxhcmdlIGNoYWxsZW5nZSB0byBtYW5pcHVsYXRlIGFueSB4NTA5IHN0YWNr IGFuZCBub3QgZXhwZWN0IGZyYWdtZW50YXRpb24/ICBJIGtub3cgd2UgYWxsIHRlbmQgdG8gdGhp bmsgb2YgMTUxNCAoSVAgb3ZlciA4MDIuMyBFdGhlcm5ldCkgYnV0IE1UVSBpcyBub3QgZGVmaW5l ZCBieSB0aGUgZW5kcG9pbnRzIGJ1dCB0aGUgcGF0aC4gIEkgdGhpbmsgYSBudW1iZXIgb2YgdGlt ZXMgdGhlcmUgaGFzIGJlZW4gYSBkaXNjdXNzaW9uIG9mIHJ1bm5pbmcgc29tZSBzZXNzaW9uIGNv bXBvbmVudHMgb3ZlciB0Y3Agd2hpY2ggbWlnaHQgaGVscCB3aXRoIHNvbWUgb2YgdGhlIHNlcXVl bmNpbmcgaXNzdWVzIG9mIHNwbGl0dGluZyB0aGUgdHJhbnNhY3Rpb24/ICBBIGJhY2t3YXJkcyBj b21wYXRpYmlsaXR5IGNoYWxsZW5nZSBpcyB0aGF0LCB3aGlsZSBudHAgb3ducyB1ZHAgYW5kIHRj cCAxMjMsIEkgdGhpbmsgbWFueSBleGlzdGluZyBmaXJld2FsbCBjb25maWd1cmF0aW9ucyB3b3Vs ZCBkcm9wIHRjcCBjb25uZWN0aW9ucyBmb3IgMTIzLiAgSSBkb27igJl0IGtub3cgaG93IG1hbnkg YXV0b2tleSBkZXBsb3ltZW50cyBhcmUgYWN0dWFsbHkgcnVubmluZyBzbyBwZXJoYXBzIGl0IGlz IG5vdCB0aGF0IGJpZyBhbiBpc3N1ZS4NCg0KRnJvbTogbnRwd2cgW21haWx0bzpudHB3Zy1ib3Vu Y2VzK2dyZWcuZG93ZD1taWNyb3NlbWkuY29tQGxpc3RzLm50cC5vcmddIE9uIEJlaGFsZiBPZiBT aGFyb24gR29sZGJlcmcNClNlbnQ6IEZyaWRheSwgQXByaWwgMDEsIDIwMTYgNjowMCBBTQ0KVG86 IGtyaXN0b2YudGVpY2hlbEBwdGIuZGUNCkNjOiBOVFAgV29ya2luZyBHcm91cDsgdGljdG9jQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW250cHdnXSBbVElDVE9DXSBXR0xDIG9uIE5UUzogUm91bmQg dHJpcHMgZm9yIGtleSBleGNoYW5nZQ0KDQpFWFRFUk5BTCBFTUFJTA0KDQoNClNoYXJvbiwgb24g cGhvbmUNCk9uIEFwciAxLCAyMDE2LCBhdCA4OjE4IEFNLCBrcmlzdG9mLnRlaWNoZWxAcHRiLmRl PG1haWx0bzprcmlzdG9mLnRlaWNoZWxAcHRiLmRlPiB3cm90ZToNCj4gPiBPbiBUaHUsIE1hciAz MSwgMjAxNiBhdCA4OjU5IEFNLCBNaXJvc2xhdiBMaWNodmFyIDxtbGljaHZhckByZWRoYXQuY29t PG1haWx0bzptbGljaHZhckByZWRoYXQuY29tPj4gd3JvdGU6DQo+ID4gT24gVGh1LCBNYXIgMzEs IDIwMTYgYXQgMDE6NTg6MzVQTSArMDIwMCwga3Jpc3RvZi50ZWljaGVsQHB0Yi5kZTxtYWlsdG86 a3Jpc3RvZi50ZWljaGVsQHB0Yi5kZT4gd3JvdGU6DQo+ID4gPiBUbyBiZSBob25lc3QsIHdlIGhh ZCBuZXZlciBhc3N1bWVkIGZvciBJUCBmcmFnbWVudGF0aW9uIChvbiBvbmUgcmVxdWVzdA0KPiA+ ID4gYW5kIG9uZSByZXNwb25zZSkgdG8gYmUgYSBodWdlIHByb2JsZW0uDQo+ID4NCj4gPiBPbmUg cmVxdWVzdCBhbmQgcmVzcG9uc2UgY291bGQgc3RpbGwgYmUgYSBwcm9ibGVtLiBJZiB0aGUgY2xp ZW50IGlzDQo+ID4gbm90IGFibGUgdG8gcmVjZWl2ZSBmcmFnbWVudGVkIHBhY2tldHMsIGl0IHdv bid0IGJlIGFibGUgdG8gaW5pdGlhbGl6ZQ0KPiA+IHRoZSBOVFMgYXNzb2NpYXRpb24uDQo+DQo+ IFJpZ2h0LCB0byBzZWNvbmQgdGhhdCwgdGhlcmUgYXJlIG1pZGRsZWJveGVzIHRoYXQgYmxvY2sg ZnJhZ21lbnRlZCBwYWNrZXRzLg0KPg0KPiA+ID4gSWYgcGVvcGxlIHNlZSBncmF2ZSBwcm9ibGVt cyB3aXRoIGl0LCB3ZSB3b3VsZCB3ZWxjb21lIGFuDQo+ID4gPiBlbGFib3JhdGlvbiBhcyAgdG8g d2h5IHRoaXMgaXMuDQo+ID4NCj4gPiBJJ20gbm90IHN1cmUgYW5kIEkgd2FzIGhvcGluZyBvdGhl cnMgd291bGQgY29tbWVudCBvbiB0aGF0LiBJdCBzZWVtcw0KPiA+IHRvIG1lIHByb2JsZW1zIHdp dGggSVB2NCBmcmFnbWVudGF0aW9uIGFyZSBxdWl0ZSBjb21tb24gZHVlIHRvDQo+ID4gZmlyZXdh bGxzIGRyb3BwaW5nIElDTVAgcGFja2V0cyBvciBJUCBmcmFnbWVudHMsIGFuZCBJUHY2IGRvZXNu J3Qgc2VlbQ0KPiA+IHRvIHJlY29tbWVuZCBzZW5kaW5nIHBhY2tldHMgbGFyZ2VyIHRoYW4gMTUw MC4NCj4NCj4gVG8gYWRkIHRvIHRoYXQsIGZyYWdtZW50YXRpb24gaXMgY29tbW9ubHkgdXNlZCBh cyBhbiBhdHRhY2sgdmVjdG9yLg0KPiBJIHdvdWxkIHN0cm9uZ2x5IGRpc2NvdXJhZ2UgdGhlIHVz ZSBvZiBJUCBmcmFnbWVudGF0aW9uIGluIHdoYXQgaXMNCj4gc3VwcG9zZWQgdG8gYmUgYSBzZWN1 cml0eSBwcm90b2NvbC4gIFBsZWFzZSBzZWUgdGhlc2UgcmVmZXJlbmNlcyBmb3INCj4gYSBzbWFs bCBzYW1wbGluZyBvZiBleGFtcGxlcy4NCg0KSXMgdGhlIGlzc3VlIHNwZWNpZmljIHRvIElQIGZy YWdtZW50YXRpb24gb2YgVURQIHBhY2tldHM/IE9yIHRvIElQIGZyYWdtZW50YXRpb24gaW4gZ2Vu ZXJhbD8NCihJJ20gYXNzdW1pbmcgaXQgZG9lcyBub3QgYXBwbHkgdG8gYWxsIHBvc3NpYmxlIGtp bmRzIG9mIHBhY2tldCBmcmFnbWVudGF0aW9uLikNCkknbSBzb3JyeSwgSSBoYXZlIHlldCB0byBn byBvdmVyIHRoZSBsaW5rZWQgZG9jdW1lbnRzLg0KDQpBbGwgZnJhZ21lbnRhdGlvbi4gVGhlIGZv bGxvd2luZyBwYXBlciBhZmZlY3RzIGJvdGggdGNwIGFuZCB1ZHAuDQoNCmh0dHBzOi8vd3d3LnVz ZW5peC5vcmcvbGVnYWN5L2V2ZW50L3dvb3QxMS90ZWNoL2ZpbmFsX2ZpbGVzL0dpbGFkLnBkZg0K DQpBZ2Fpbi4gTXkgcG9pbnQgaXMgdGhhdCB3ZSBzaG91bGQgbm90IGJlIHJlbHlpbmcgb24gZnJh Z21lbnRhdGlvbiBpbiBOVFMuIEl0IHJlZ3VsYXJseSBsZWFkcyB0byB1bmV4cGVjdGVkIGF0dGFj a3MuDQoNCkFsc28gcXVvdGluZyBSb24gQm9uaWNhIGZyb20gdGhlIGZpcnN0IGxpbmtlZCBjb252 ZXJzYXRpb24gYmVsb3c6DQoNCiJwbGVhc2UgZG9uJ3Qgd3JpdGUgbmV3IGFwcGxpY2F0aW9ucyB0 aGF0IGZyYWdtZW50IHBhY2tldHMuIg0KDQpTaGFyb24NCg0KDQo+IGh0dHBzOi8vd3d3Lm5hbm9n Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL21vbi5nZW5lcmFsLmZyYWdtZW50YXRpb24uYm9uaWNh LnBkZg0KPg0KPiBodHRwOi8vd3d3LmhwbC5ocC5jb20vdGVjaHJlcG9ydHMvQ29tcGFxLURFQy9X UkwtODctMy5wZGYNCj4NCj4gaHR0cDovL2FyeGl2Lm9yZy9hYnMvMTIwNS40MDExDQo+DQo+IGh0 dHBzOi8vbWVkaWEuYmxhY2toYXQuY29tL2JoLWV1LTEyL0F0bGFzaXMvYmgtZXUtMTItQXRsYXNp cy0NCj4gQXR0YWNraW5nX0lQdjYtV1AucGRmDQo+DQo+IGh0dHA6Ly93d3cuaXNzLm5ldC9zZWN1 cml0eV9jZW50ZXIvcmVmZXJlbmNlL3Z1bG4vVGVhckRyb3AuaHRtDQo+DQo+IGh0dHBzOi8vd3d3 Lm9mZmVuc2l2ZS1zZWN1cml0eS5jb20vd2lmdS9GcmFnbWVudGF0aW9uLUF0dGFjay1pbi1QcmFj dGljZS5wZGYNCj4NCj4gRXZlbiBpZiB5b3UgZG9uJ3Qgc2VlIGEgU1BFQ0lGSUMgYXR0YWNrIG9u IE5UUyBpbiB0aGVzZSBwYXBlcnMsIG15DQo+IHBvaW50ICBpcyB0aGF0IHdlIGNhbiB1c3VhbGx5 IGZpbmQgYSB3YXkgdG8gZXhwbG9pdCBJUCBmcmFnbWVudGF0aW9uDQo+IGluIHVuZXhwZWN0ZWQg d2F5cyB0byBicmVhayBzZWN1cml0eS4gVGhpcyBoYXMgaGFwcGVuZWQgb3ZlciBhbmQNCj4gb3Zl ciBpbiB0aGUgbGFzdCB0d28gZGVjYWRlcyBvbiBtYW55IGRpZmZlcmVudCBwcm90b2NvbHMuIElu IGZhY3QNCj4gdGhpcyBpcyBleGFjdGx5IHdoYXQgd2UgZGlkIGluIG91ciByZWNlbnQgTlRQIHBh cGVyLCBTZWN0aW9uIFZJOg0KPg0KPiAuaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNS8xMDIw LnBkZg0KPg0KPiBJIHdvdWxkIHN0cm9uZ2x5IG9iamVjdCB0byBoYXZpbmcgTlRTIHJlbHkgb24g SVAgZnJhZ21lbnRhdGlvbi4NCj4gVGhpcyB3b3VsZCBiZSBhIGhvcnJpYmxlIGRlc2lnbiBkZWNp c2lvbi4NCg0KTm90ZWQuDQo= --_000_8D2BF679AAC7C346848A489074F9F8BF7AAFC3EAsjsrvexchmbx2mi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FtYnJpYTsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KdHQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZW1vdmluZyBm cmFnbWVudGF0aW9uIGJ5IGRlZmluaXRpb24gaW4gYW4gYXBwbGljYXRpb24gcHJvdG9jb2wgaXNu 4oCZdCBldmVuIHBvc3NpYmxlIGluIElwdjQgYXMgcm91dGVycyBjYW4gZnJhZy4mbmJzcDsgSXQg c2VlbXMgYSBsYXJnZSBjaGFsbGVuZ2UgdG8gbWFuaXB1bGF0ZSBhbnkNCiB4NTA5IHN0YWNrIGFu ZCBub3QgZXhwZWN0IGZyYWdtZW50YXRpb24/Jm5ic3A7IEkga25vdyB3ZSBhbGwgdGVuZCB0byB0 aGluayBvZiAxNTE0IChJUCBvdmVyIDgwMi4zIEV0aGVybmV0KSBidXQgTVRVIGlzIG5vdCBkZWZp bmVkIGJ5IHRoZSBlbmRwb2ludHMgYnV0IHRoZSBwYXRoLiZuYnNwOyBJIHRoaW5rIGEgbnVtYmVy IG9mIHRpbWVzIHRoZXJlIGhhcyBiZWVuIGEgZGlzY3Vzc2lvbiBvZiBydW5uaW5nIHNvbWUgc2Vz c2lvbiBjb21wb25lbnRzIG92ZXIgdGNwDQogd2hpY2ggbWlnaHQgaGVscCB3aXRoIHNvbWUgb2Yg dGhlIHNlcXVlbmNpbmcgaXNzdWVzIG9mIHNwbGl0dGluZyB0aGUgdHJhbnNhY3Rpb24/Jm5ic3A7 IEEgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgY2hhbGxlbmdlIGlzIHRoYXQsIHdoaWxlIG50cCBv d25zIHVkcCBhbmQgdGNwIDEyMywgSSB0aGluayBtYW55IGV4aXN0aW5nIGZpcmV3YWxsIGNvbmZp Z3VyYXRpb25zIHdvdWxkIGRyb3AgdGNwIGNvbm5lY3Rpb25zIGZvciAxMjMuJm5ic3A7IEkgZG9u 4oCZdCBrbm93DQogaG93IG1hbnkgYXV0b2tleSBkZXBsb3ltZW50cyBhcmUgYWN0dWFsbHkgcnVu bmluZyBzbyBwZXJoYXBzIGl0IGlzIG5vdCB0aGF0IGJpZyBhbiBpc3N1ZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBudHB3ZyBbbWFpbHRvOm50cHdnLWJvdW5jZXMmIzQzO2dyZWcuZG93ZD1taWNyb3Nl bWkuY29tQGxpc3RzLm50cC5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNoYXJvbiBHb2xkYmVy Zzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDAxLCAyMDE2IDY6MDAgQU08YnI+DQo8 Yj5Ubzo8L2I+IGtyaXN0b2YudGVpY2hlbEBwdGIuZGU8YnI+DQo8Yj5DYzo8L2I+IE5UUCBXb3Jr aW5nIEdyb3VwOyB0aWN0b2NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtudHB3 Z10gW1RJQ1RPQ10gV0dMQyBvbiBOVFM6IFJvdW5kIHRyaXBzIGZvciBrZXkgZXhjaGFuZ2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5FWFRFUk5B TCBFTUFJTDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NClNoYXJvbiwgb24gcGhvbmUmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5PbiBBcHIgMSwgMjAxNiwgYXQgODoxOCBBTSwgPGEgaHJlZj0ibWFpbHRvOmty aXN0b2YudGVpY2hlbEBwdGIuZGUiPg0Ka3Jpc3RvZi50ZWljaGVsQHB0Yi5kZTwvYT4gd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmZ3Q7IE9uIFRodSwgTWFyIDMx LCAyMDE2IGF0IDg6NTkgQU0sIE1pcm9zbGF2IExpY2h2YXIgJmx0OzxhIGhyZWY9Im1haWx0bzpt bGljaHZhckByZWRoYXQuY29tIj5tbGljaHZhckByZWRoYXQuY29tPC9hPiZndDsgd3JvdGU6PC9z cGFuPjwvdHQ+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg Jmd0OyBPbiBUaHUsIE1hciAzMSwgMjAxNiBhdCAwMTo1ODozNVBNICYjNDM7MDIwMCwgPGEgaHJl Zj0ibWFpbHRvOmtyaXN0b2YudGVpY2hlbEBwdGIuZGUiPg0Ka3Jpc3RvZi50ZWljaGVsQHB0Yi5k ZTwvYT4gd3JvdGU6PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4N Cjx0dD4mZ3Q7ICZndDsgJmd0OyBUbyBiZSBob25lc3QsIHdlIGhhZCBuZXZlciBhc3N1bWVkIGZv ciBJUCBmcmFnbWVudGF0aW9uIChvbiBvbmUgcmVxdWVzdDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0 OyAmZ3Q7IGFuZCBvbmUgcmVzcG9uc2UpIHRvIGJlIGEgaHVnZSBwcm9ibGVtLjwvdHQ+PGJyPg0K PHR0PiZndDsgJmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsgT25lIHJlcXVlc3QgYW5kIHJl c3BvbnNlIGNvdWxkIHN0aWxsIGJlIGEgcHJvYmxlbS4gSWYgdGhlIGNsaWVudCBpczwvdHQ+PGJy Pg0KPHR0PiZndDsgJmd0OyBub3QgYWJsZSB0byByZWNlaXZlIGZyYWdtZW50ZWQgcGFja2V0cywg aXQgd29uJ3QgYmUgYWJsZSB0byBpbml0aWFsaXplPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IHRo ZSBOVFMgYXNzb2NpYXRpb24uPC90dD48YnI+DQo8dHQ+Jmd0OzwvdHQ+PGJyPg0KPHR0PiZndDsg UmlnaHQsIHRvIHNlY29uZCB0aGF0LCB0aGVyZSBhcmUgbWlkZGxlYm94ZXMgdGhhdCBibG9jayBm cmFnbWVudGVkIHBhY2tldHMuPC90dD48YnI+DQo8dHQ+Jmd0OyAmbmJzcDs8L3R0Pjwvc3Bhbj4g PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZndDsgJmd0OyBJ ZiBwZW9wbGUgc2VlIGdyYXZlIHByb2JsZW1zIHdpdGggaXQsIHdlIHdvdWxkIHdlbGNvbWUgYW4N Cjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyAm Z3Q7ICZndDsgZWxhYm9yYXRpb24gYXMmbmJzcDsgdG8gd2h5IHRoaXMgaXMuPC90dD48YnI+DQo8 dHQ+Jmd0OyAmZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBJJ20gbm90IHN1cmUgYW5kIEkg d2FzIGhvcGluZyBvdGhlcnMgd291bGQgY29tbWVudCBvbiB0aGF0LiBJdCBzZWVtczwvdHQ+PGJy Pg0KPHR0PiZndDsgJmd0OyB0byBtZSBwcm9ibGVtcyB3aXRoIElQdjQgZnJhZ21lbnRhdGlvbiBh cmUgcXVpdGUgY29tbW9uIGR1ZSB0bzwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyBmaXJld2FsbHMg ZHJvcHBpbmcgSUNNUCBwYWNrZXRzIG9yIElQIGZyYWdtZW50cywgYW5kIElQdjYgZG9lc24ndCBz ZWVtPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7IHRvIHJlY29tbWVuZCBzZW5kaW5nIHBhY2tldHMg bGFyZ2VyIHRoYW4gMTUwMC48L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48YnI+DQo8dHQ+Jmd0OyBUbyBhZGQgdG8gdGhhdCwgZnJhZ21lbnRhdGlvbiBpcyBjb21tb25s eSB1c2VkIGFzIGFuIGF0dGFjayB2ZWN0b3IuJm5ic3A7PC90dD48YnI+DQo8dHQ+Jmd0OyBJIHdv dWxkIHN0cm9uZ2x5IGRpc2NvdXJhZ2UgdGhlIHVzZSBvZiBJUCBmcmFnbWVudGF0aW9uIGluIHdo YXQgaXMgPC90dD48YnI+DQo8dHQ+Jmd0OyBzdXBwb3NlZCB0byBiZSBhIHNlY3VyaXR5IHByb3Rv Y29sLiZuYnNwOyBQbGVhc2Ugc2VlIHRoZXNlIHJlZmVyZW5jZXMgZm9yPC90dD48YnI+DQo8dHQ+ Jmd0OyBhIHNtYWxsIHNhbXBsaW5nIG9mIGV4YW1wbGVzLjwvdHQ+PC9zcGFuPiA8YnI+DQo8YnI+ DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPklzIHRoZSBpc3N1ZSBzcGVjaWZp YyB0byBJUCBmcmFnbWVudGF0aW9uIG9mIFVEUCBwYWNrZXRzPyBPciB0byBJUCBmcmFnbWVudGF0 aW9uIGluIGdlbmVyYWw/DQo8L3NwYW4+PC90dD48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPihJJ20gYXNzdW1pbmcgaXQgZG9lcyBub3QgYXBwbHkgdG8gYWxsIHBvc3Np YmxlIGtpbmRzIG9mIHBhY2tldCBmcmFnbWVudGF0aW9uLik8L3NwYW4+PC90dD4NCjxicj4NCjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SSdtIHNvcnJ5LCBJIGhhdmUgeWV0IHRv IGdvIG92ZXIgdGhlIGxpbmtlZCBkb2N1bWVudHMuPC9zcGFuPjwvdHQ+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgZnJh Z21lbnRhdGlvbi4gVGhlIGZvbGxvd2luZyBwYXBlciBhZmZlY3RzIGJvdGggdGNwIGFuZCB1ZHAu ICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwczovL3d3dy51c2VuaXgub3JnL2xlZ2FjeS9ldmVudC93b290MTEvdGVjaC9m aW5hbF9maWxlcy9HaWxhZC5wZGYiPmh0dHBzOi8vd3d3LnVzZW5peC5vcmcvbGVnYWN5L2V2ZW50 L3dvb3QxMS90ZWNoL2ZpbmFsX2ZpbGVzL0dpbGFkLnBkZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdhaW4uIE15IHBvaW50IGlzIHRo YXQgd2Ugc2hvdWxkIG5vdCBiZSByZWx5aW5nIG9uIGZyYWdtZW50YXRpb24gaW4gTlRTLiBJdCBy ZWd1bGFybHkgbGVhZHMgdG8gdW5leHBlY3RlZCBhdHRhY2tzLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyBxdW90aW5nIFJv biBCb25pY2EgZnJvbSB0aGUgZmlyc3QgbGlua2VkIGNvbnZlcnNhdGlvbiBiZWxvdzo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7cGxl YXNlIGRvbid0IHdyaXRlIG5ldyBhcHBsaWNhdGlvbnMgdGhhdCBmcmFnbWVudCBwYWNrZXRzLiZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hhcm9u Jm5ic3A7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPHR0PiZndDsgPC90dD48L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly93d3cubmFub2cub3JnL3NpdGVzL2RlZmF1bHQvZmlsZXMvbW9uLmdl bmVyYWwuZnJhZ21lbnRhdGlvbi5ib25pY2EucGRmIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPmh0dHBzOi8vd3d3Lm5hbm9nLm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL21vbi5n ZW5lcmFsLmZyYWdtZW50YXRpb24uYm9uaWNhLnBkZjwvc3Bhbj48L3R0PjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0 Pjwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmhwbC5ocC5jb20vdGVjaHJlcG9ydHMvQ29tcGFx LURFQy9XUkwtODctMy5wZGYiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0 cDovL3d3dy5ocGwuaHAuY29tL3RlY2hyZXBvcnRzL0NvbXBhcS1ERUMvV1JMLTg3LTMucGRmPC9z cGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9hcnhpdi5vcmcv YWJzLzEyMDUuNDAxMSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwOi8v YXJ4aXYub3JnL2Ficy8xMjA1LjQwMTE8L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly9tZWRpYS5ibGFja2hhdC5jb20vYmgtZXUtMTIvQXRsYXNpcy9iaC1l dS0xMi1BdGxhc2lzLSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwczov L21lZGlhLmJsYWNraGF0LmNvbS9iaC1ldS0xMi9BdGxhc2lzL2JoLWV1LTEyLUF0bGFzaXMtPC9z cGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBB dHRhY2tpbmdfSVB2Ni1XUC5wZGY8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZn dDsgPC90dD48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pc3MubmV0L3NlY3VyaXR5X2NlbnRl ci9yZWZlcmVuY2UvdnVsbi9UZWFyRHJvcC5odG0iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+aHR0cDovL3d3dy5pc3MubmV0L3NlY3VyaXR5X2NlbnRlci9yZWZlcmVuY2UvdnVs bi9UZWFyRHJvcC5odG08L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cub2ZmZW5zaXZlLXNlY3VyaXR5LmNvbS93aWZ1L0ZyYWdtZW50YXRpb24tQXR0 YWNrLWluLVByYWN0aWNlLnBkZiI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5o dHRwczovL3d3dy5vZmZlbnNpdmUtc2VjdXJpdHkuY29tL3dpZnUvRnJhZ21lbnRhdGlvbi1BdHRh Y2staW4tUHJhY3RpY2UucGRmPC9zcGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48YnI+DQo8dHQ+Jmd0OzwvdHQ+PC9zcGFuPiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsgRXZlbiBpZiB5b3UgZG9uJ3Qgc2VlIGEgU1BFQ0lGSUMgYXR0 YWNrIG9uIE5UUyBpbiB0aGVzZSBwYXBlcnMsIG15DQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PGJyPg0KPHR0PiZndDsgcG9pbnQmbmJzcDsgaXMgdGhhdCB3ZSBjYW4g dXN1YWxseSBmaW5kIGEgd2F5IHRvIGV4cGxvaXQgSVAgZnJhZ21lbnRhdGlvbjwvdHQ+PGJyPg0K PHR0PiZndDsgaW4gdW5leHBlY3RlZCB3YXlzIHRvIGJyZWFrIHNlY3VyaXR5LiBUaGlzIGhhcyBo YXBwZW5lZCBvdmVyIGFuZCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IG92ZXIgaW4gdGhlIGxhc3QgdHdv IGRlY2FkZXMgb24gbWFueSBkaWZmZXJlbnQgcHJvdG9jb2xzLiBJbiBmYWN0IDwvdHQ+PGJyPg0K PHR0PiZndDsgdGhpcyBpcyBleGFjdGx5IHdoYXQgd2UgZGlkIGluIG91ciByZWNlbnQgTlRQIHBh cGVyLCBTZWN0aW9uIFZJOjwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAu PGEgaHJlZj0iaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNS8xMDIwLnBkZiI+aHR0cHM6Ly9l cHJpbnQuaWFjci5vcmcvMjAxNS8xMDIwLnBkZjwvYT48L3R0Pjxicj4NCjx0dD4mZ3Q7PC90dD48 L3NwYW4+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBJIHdv dWxkIHN0cm9uZ2x5IG9iamVjdCB0byBoYXZpbmcgTlRTIHJlbHkgb24gSVAgZnJhZ21lbnRhdGlv bi4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 YnI+DQo8dHQ+Jmd0OyBUaGlzIHdvdWxkIGJlIGEgaG9ycmlibGUgZGVzaWduIGRlY2lzaW9uLjwv dHQ+PGJyPg0KPC9zcGFuPjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Tm90ZWQuPC9zcGFuPjwvdHQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8D2BF679AAC7C346848A489074F9F8BF7AAFC3EAsjsrvexchmbx2mi_-- --===============7053758990970549851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7053758990970549851==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 09:14:09 2016 Return-Path: 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 6BEB312D0D8 for ; Fri, 1 Apr 2016 09:14:09 -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 TI7qwGlrOssg for ; Fri, 1 Apr 2016 09:14:06 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 789E612D192 for ; Fri, 1 Apr 2016 09:14:06 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6D36086DBF7 for ; Fri, 1 Apr 2016 16:14:06 +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 D778886D55E for ; Thu, 31 Mar 2016 13:23:25 +0000 (UTC) Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alcZF-0002af-Mx for ntpwg@lists.ntp.org; Thu, 31 Mar 2016 13:23:25 +0000 Received: by mail-wm0-x229.google.com with SMTP id 20so113751085wmh.1 for ; Thu, 31 Mar 2016 06:23:21 -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:cc; bh=807SGxoZxh/I4yKAG8nzr8iPVf5eVhEOtyab7moJSrQ=; b=n+GicCAJImTZ5qJ7UXgFfVh+7tW3v3YjS5YRw1OS8lUFXyqM02l/9W2mWtRYMUQsO+ 5V/iroiK5PrjfbaSK6pezBt22MFaE3+Z3la01ENVEKvzLY4RC91jdbHshUU8zCEulkFE RoKKx6/60CFtz/+qFlTMIxPazoOI9F4LlLRtXHtdxyXqJSDOfafhckQAR2LGqFIFWJUn DzcnKazd5emCwe47rByIP4ZcNwuSXAEuzDJ4JVV1mv3kgNDpvpCKOL39XAX2bIr9wY7j ylk9tZDEUYbetD9ebBrFAVc0tp7QafhvqYhiXJdSWzIiWGDdQaPWJ5iGquzh19ZrN58K NLng== 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:cc; bh=807SGxoZxh/I4yKAG8nzr8iPVf5eVhEOtyab7moJSrQ=; b=dvcH2IijJX55misERKjv5+HkcV8hhQ9KmK7JOzNuiD5F3j+b/Cl4eOMG7GedhtnrJZ fy+/ujNm19zYC+SdByFol+ylBN0H14OYvcFKf/dMNKjZeGWfzj2NOV4Uat1giz74G0MH by1Pu+jD19CoxtLGSJiyAdRRzFEqDFoSLWcLMmGklNi1pBEFO96cyin6+ItymqqrnER8 bzwGfCOUgMeWl36Bvl4irNGgziftz2bm0YdPFQb7CUrgDkpPr4F5HQgqQ3+F6Sr6J3Yh FABHMKQW+j+SduMWX+2g6NXBB/TrlKGfhoDrm4UFHsiJ2dmAaFIyyDxFQryFh8Ak1+f0 xQog== X-Gm-Message-State: AD7BkJInSHB9Y3hZkmeC379IZUqSIF7OI65RJUnVQrrLhPf2urgxeuqgzIP5TbO/IXSMniknJuU/W8kSihEboA== X-Received: by 10.194.223.104 with SMTP id qt8mr15456511wjc.11.1459430599895; Thu, 31 Mar 2016 06:23:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.242.35 with HTTP; Thu, 31 Mar 2016 06:22:40 -0700 (PDT) In-Reply-To: <20160331125908.GG834@localhost> References: <20160329152654.GH20902@localhost> <20160331125908.GG834@localhost> From: Sharon Goldberg Date: Thu, 31 Mar 2016 09:22:40 -0400 X-Google-Sender-Auth: i7Vh84PuriXWj49aaYCtGJ4mj-o Message-ID: To: Miroslav Lichvar X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::229 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) X-Mailman-Approved-At: Fri, 01 Apr 2016 16:06:43 +0000 Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.org Content-Type: multipart/mixed; boundary="===============7450767832235672288==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============7450767832235672288== Content-Type: multipart/alternative; boundary=001a11c3b8a47b3030052f582a3d --001a11c3b8a47b3030052f582a3d Content-Type: text/plain; charset=UTF-8 On Thu, Mar 31, 2016 at 8:59 AM, Miroslav Lichvar wrote: > On Thu, Mar 31, 2016 at 01:58:35PM +0200, kristof.teichel@ptb.de wrote: > > To be honest, we had never assumed for IP fragmentation (on one request > > and one response) to be a huge problem. > > One request and response could still be a problem. If the client is > not able to receive fragmented packets, it won't be able to initialize > the NTS association. > > Right, to second that, there are middleboxes that block fragmented packets. > > If people see grave problems with it, we would welcome an elaboration > as to why this is. > > I'm not sure and I was hoping others would comment on that. It seems > to me problems with IPv4 fragmentation are quite common due to > firewalls dropping ICMP packets or IP fragments, and IPv6 doesn't seem > to recommend sending packets larger than 1500. > To add to that, fragmentation is commonly used as an attack vector. I would strongly discourage the use of IP fragmentation in what is supposed to be a security protocol. Please see these references for a small sampling of examples. https://www.nanog.org/sites/default/files/mon.general.fragmentation.bonica.pdf http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf http://arxiv.org/abs/1205.4011 https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf http://www.iss.net/security_center/reference/vuln/TearDrop.htm https://www.offensive-security.com/wifu/Fragmentation-Attack-in-Practice.pdf Even if you don't see a SPECIFIC attack on NTS in these papers, my point is that we can usually find a way to exploit IP fragmentation in unexpected ways to break security. This has happened over and over in the last two decades on many different protocols. In fact this is exactly what we did in our recent NTP paper, Section VI: .https://eprint.iacr.org/2015/1020.pdf I would strongly object to having NTS rely on IP fragmentation. This would be a horrible design decision. Thanks, Sharon --001a11c3b8a47b3030052f582a3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 31, 2016 at 8:59 AM, Miroslav Lichvar <mlichvar@redhat.com&g= t; wrote:
On Thu, Mar 31, 2016 at 01:58:35PM +0200, kristof.teichel@ptb.de wrote:
> To be honest, we had never assumed for IP fragmentation (on one reques= t
> and one response) to be a huge problem.

One request and response could still be a problem. If the client is<= br> not able to receive fragmented packets, it won't be able to initialize<= br> the NTS association.


Right, to seco= nd that, there are middleboxes that block fragmented packets.
=C2=A0
> If people see grave problems with it, we would welcome an elaboration = as=C2=A0 to why this is.

I'm not sure and I was hoping others would comment on that. It s= eems
to me problems with IPv4 fragmentation are quite common due to
firewalls dropping ICMP packets or IP fragments, and IPv6 doesn't seem<= br> to recommend sending packets larger than 1500.

Even if you don't see a SPECIFI= C attack on NTS in these papers, my point=C2=A0 is that we can usually find= a way to exploit IP fragmentation in unexpected ways to break security. Th= is has happened over and over in the last two decades on many different pro= tocols. In fact this is exactly what we did in our recent NTP paper, Sectio= n VI:

.https://epr= int.iacr.org/2015/1020.pdf

I would strongly object to= having NTS rely on IP fragmentation.=C2=A0=C2=A0 This would be a horrible = design decision.

Thanks,
Sharon


--001a11c3b8a47b3030052f582a3d-- --===============7450767832235672288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7450767832235672288==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 09:14:19 2016 Return-Path: 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 D9BE512D18C for ; Fri, 1 Apr 2016 09:14:19 -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 5_iHX6tZg2Ur for ; Fri, 1 Apr 2016 09:14:15 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 98AC712D0B8 for ; Fri, 1 Apr 2016 09:14:15 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 94CE486DC08 for ; Fri, 1 Apr 2016 16:14:15 +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 86EA686D55E for ; Thu, 31 Mar 2016 16:38:24 +0000 (UTC) Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alfby-0005Or-3N for ntpwg@lists.ntp.org; Thu, 31 Mar 2016 16:38:24 +0000 Received: by mail-wm0-x232.google.com with SMTP id 20so121072544wmh.1 for ; Thu, 31 Mar 2016 09:38:21 -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:cc; bh=/tyfJxgz6/6w3GXl4FaQefpnrKv3i8/LD0uba3aqLOk=; b=ns7MUqkHxPZAU2kQRB5OGadqoWphVr2oPHlqRhrwGf0uPvwVusXdIQN70adZ50sO0o +Mxf+Dc8oP/HhwgYsx7ys7U1EwQ2B+47FPgTvC2x5hxb6DOA/oUE+Am56QX4RG6zSym6 /BiHugrd8u/kPYF6Q+58LiaSsTyHxaEQwvBpq54PzeB6mJrp7//HvKKxzWRXrprjCKzr GB2fLIJWilrtWdPCwrqePtBzbJQhwhTzPNyKGrrq408c1Ai9gKVn7tJu7ereN1ze5jmR HKfgQ20j2op9LR1E0IyYfrUH6yCpzavl7zeG+rVAnSSCp1Id1+C/i0g2K2DanxW4oE2l csJA== 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:cc; bh=/tyfJxgz6/6w3GXl4FaQefpnrKv3i8/LD0uba3aqLOk=; b=SRmoRYY+jKuB+wB297g4K0zM3rlay12UUvOxvR3wYAxZu7ozwv3PpMFLqIizQIpHqp VN4SSOUCI+FZhJIh/BFrG1VvVc0TkBtc7YZRYZPW4btx5AdKivjuTv0LMN3lrQSQRehz LFGRvXN78ryeLH98t9l2D74PbZSOCwLLRshlFED549FCmH2miIY+BDSTv8kH6fmgb20x PQ2ESTeRhQi6PgqJuNDlyYYfyrkbxjU4d4/SlkwTFGaq0Q31BFIh5t7WexO3ajPitUPW qaGY+IbLArz9TQ1adQs+NKPTHzIqY4gXkTgKYgwPd5VscJ8uhwEI8dAXIhYlfxLKY8jq pbpg== X-Gm-Message-State: AD7BkJITGtPLGTaWi2tGd7AWO9NhfF3GJ/Uzm0B9gW8sEMs+1kvM/XMq2nU/9+lWBSufQBPpF+PaBNIV2USBdQ== X-Received: by 10.28.220.215 with SMTP id t206mr3239520wmg.68.1459442300543; Thu, 31 Mar 2016 09:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.242.35 with HTTP; Thu, 31 Mar 2016 09:37:40 -0700 (PDT) In-Reply-To: References: <20160327022407.9BF4D406060@ip-64-139-1-69.sjc.megapath.net> From: Sharon Goldberg Date: Thu, 31 Mar 2016 12:37:40 -0400 X-Google-Sender-Auth: geuae43f2XAjmvJikZGZMOpnBT8 Message-ID: To: kristof.teichel@ptb.de X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::232 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) X-Mailman-Approved-At: Fri, 01 Apr 2016 16:06:43 +0000 Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Hal Murray , tictoc@ietf.org Content-Type: multipart/mixed; boundary="===============9070093118758102659==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============9070093118758102659== Content-Type: multipart/alternative; boundary=001a114b2d46e4e8d4052f5ae37e --001a114b2d46e4e8d4052f5ae37e Content-Type: text/plain; charset=UTF-8 On Wed, Mar 30, 2016 at 7:02 AM, wrote: > 2) I am fairly certain that any ideas like this should not concern either > of the NTS-related documents. Whether/how to use any samples whose > authenticity & integrity can *not* be verified by NTS should be out of > scope for us. > > I disagree. The whole purpose of NTS is to protect timing information, so at the very least the document should clearly and precisely explain the bootstrapping problem (what to do if the client has no idea what time it is upon startup) and the implications of using unauthenticate time. Punting on this means that the draft ignores a central issue in secure time synchronization. The language in Section 9.2 of the current draft could be strengthened. Re:bootstrapping: I suggest that NTS should encourage users to write the current time to a persistent file that is available upon reboot. This should be overwritten on every clock update. Then, when the client reboots, it can check that the expiry time of the certificates is no earlier than the last time time written to the presisent file. This limits the impact of attackers that use old compromised certificates to break the security of NTS. Re: using unauthenticated time samples. Leaving this out of scope gives uses just enough rope to hang themselves. The draft should explain the risks and implication of using unathenticated time. As I discussed in my previous email, doing this allows even a *boosttrapped* client to be attacked. I would even suggest that the draft use MUST to forbid the use of unauthenticated samples. If this is already in the draft and I have missed it, please accept my apologies. Thanks, Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a114b2d46e4e8d4052f5ae37e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 7:02 AM, <kristof.teichel@ptb.de>= wrote:
2) I am fairly c= ertain that any ideas like this should not concern either of the NTS-relate= d documents. Whether/how to use any samples whose authenticity & integr= ity can *not* be verified by NTS should be out of scope for us.

I dis= agree. The whole purpose of NTS is to protect timing information, so at the= very least the document should clearly and precisely explain the bootstrap= ping problem (what to do if the client has no idea what time it is upon sta= rtup) and the implications of using unauthenticate time.=C2=A0 Punting on t= his means that the draft ignores a central issue in secure time synchroniza= tion.

The language in Section 9.2 of the current draft could be str= engthened.

Re:bootstrapping:

I suggest that NTS should encou= rage users to write the current time to a persistent file that is available= upon reboot.=C2=A0 This should be overwritten on every clock update.=C2=A0= =C2=A0=C2=A0 Then, when the client reboots, it can check that the expiry ti= me of the certificates is no earlier than the last time time written to the= presisent file.=C2=A0 This limits the impact of attackers that use old com= promised certificates to break the security of NTS.

Re: using unauth= enticated time samples.

Leaving this out of scope gives uses just en= ough rope to hang themselves.=C2=A0 The draft should explain the risks and = implication of using unathenticated time. As I discussed in my previous ema= il, doing this allows even a *boosttrapped* client to be attacked.=C2=A0 I = would even suggest that the draft use MUST to forbid the use of unauthentic= ated samples.=C2=A0 If this is already in the draft and I have missed it, p= lease accept my apologies.

Thanks,
Sharon



--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a114b2d46e4e8d4052f5ae37e-- --===============9070093118758102659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============9070093118758102659==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 09:14:32 2016 Return-Path: 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 04CD512D0D8 for ; Fri, 1 Apr 2016 09:14:32 -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 Zj0z6DdZZPR7 for ; Fri, 1 Apr 2016 09:14:30 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id CB80C12D0CC for ; Fri, 1 Apr 2016 09:14:24 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BD69886DC5E for ; Fri, 1 Apr 2016 16:14:24 +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 7986C86D643 for ; Thu, 31 Mar 2016 20:43:57 +0000 (UTC) Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aljRb-0008s2-5B for ntpwg@lists.ntp.org; Thu, 31 Mar 2016 20:43:57 +0000 Received: by mail-wm0-x235.google.com with SMTP id f198so367917wme.0 for ; Thu, 31 Mar 2016 13:43:54 -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:date:message-id:subject :from:to:cc; bh=IjFwzmvY2tPFOLsp7MmrDXRssMKjG9ybKdAuOYjVR7U=; b=AXXsMfZh31q0hVKwoIeEETrComMPOQy2yyNnb9YmZSk56ygPFQ5gK8O0jEvzdrCnyv M78jo2Sz+2izDqbzFrFHAbg4dH16peclxXFyFuh63bJzJ7FD467TYxv38pMN53iP0J/6 owcdSoMzvIbJ7VBupaEUC32qaLIrANbhe3r4Q61jwAihQuqPteTO7WnyJZhXa88VX6Qr 1rBUnsakUXh6QfhaJGjI4akgHUglXtv6DMuGCPutLo2nHSXV0yjLWb5QRInOCv6B6QRc gIHC/nsuMo9Az5s01X2din7Sphivt4WFvaooykfSyJ1hzDhPZF7ey5vu/8+PQ3cxIx+1 IOJw== 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:date :message-id:subject:from:to:cc; bh=IjFwzmvY2tPFOLsp7MmrDXRssMKjG9ybKdAuOYjVR7U=; b=I0IEgYrfmmtG3+miRmAVl9VQmx9D7VBThkgzcyAddUn6ivsqn86/k0YbDLLB3rmKtm k0XnhjpK2ANPTAksU4gCgJjs/5XEIMr24R+YRePahFk+xvq1SiYaZOm66ZtjNzQsf+lg bg+YOipl0hNykj0hvN986JGHFcRkOd2Ei1QZUGN3hp+0OC2jz+/jviVFs+JiGMLGr8Ka 007Am1faKBhkGjv24fFIv378g/s/4KV66Nur2nUip57DxFXFFZBCtySEJWhMG/rJd5XX bVNP/utx5AUHK+U5GQXRDo2xrB8ghPWusTFrKcfG5PfuvkA3cndM5pygNMGu9ff44FhT TabA== X-Gm-Message-State: AD7BkJKd/3OsUKoppEFQ2THJRQCaUaHnLRQgQ0Fp4MVG/mBcEATd99Vdn14/mwwQNfuLJDmtIZneC3lsPjCQRQ== MIME-Version: 1.0 X-Received: by 10.28.174.72 with SMTP id x69mr830350wme.68.1459457033353; Thu, 31 Mar 2016 13:43:53 -0700 (PDT) Received: by 10.194.242.35 with HTTP; Thu, 31 Mar 2016 13:43:53 -0700 (PDT) In-Reply-To: <20160331182727.C8A29406078@ip-64-139-1-69.sjc.megapath.net> References: <20160331182727.C8A29406078@ip-64-139-1-69.sjc.megapath.net> Date: Thu, 31 Mar 2016 16:43:53 -0400 X-Google-Sender-Auth: cNg2q9Q0eaGTHRk2TBckzy44_sY Message-ID: From: Sharon Goldberg To: Hal Murray X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::235 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) X-Mailman-Approved-At: Fri, 01 Apr 2016 16:06:43 +0000 Subject: Re: [ntpwg] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============4060584487314694580==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============4060584487314694580== Content-Type: multipart/alternative; boundary=001a114444e009c489052f5e5210 --001a114444e009c489052f5e5210 Content-Type: text/plain; charset=UTF-8 I agree with Hal that this problem is quite complicated. My suggestion was just meant to deal with a very easy case. On Thursday, March 31, 2016, Hal Murray wrote: > > goldbe@cs.bu.edu said: > > I suggest that NTS should encourage users to write the current time to a > > persistent file that is available upon reboot. This should be > overwritten > > on every clock update. Then, when the client reboots, it can check > that > > the expiry time of the certificates is no earlier than the last time time > > written to the presisent file. This limits the impact of attackers that > use > > old compromised certificates to break the security of NTS. > > I think the issue of getting started is much more complicated than that. > > It probably deserves a separate document to collect all the ideas. > Individual documents like NTS should be explicit about what they are > assuming. Do they need valid (how close?) time or valid certificates or > ??? > > The above paragraph assumes the system has a writable file system. The > "every clock update" may be too expensive for some systems. > > What happens the first time? Even if you assume that file was sanely > initialized at the factory, the unit may have sat on a shelf for a long > time. > > What do you do if your clock gets set far into the future? > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a114444e009c489052f5e5210 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Hal that this problem=C2=A0is quite complicated. My suggestion= was just meant to deal with a=C2=A0very easy case.=C2=A0

On Thursda= y, March 31, 2016, Hal Murray <hmurray@megapathdsl.net> wrote:
=
goldbe@cs.bu.edu=C2=A0said:
> I suggest that NTS should encourage users to write the current time to= a
> persistent file that is available upon reboot.=C2=A0 This should be ov= erwritten
> on every clock update.=C2=A0 =C2=A0 Then, when the client reboots, it = can check that
> the expiry time of the certificates is no earlier than the last time t= ime
> written to the presisent file.=C2=A0 This limits the impact of attacke= rs that use
> old compromised certificates to break the security of NTS.

I think the issue of getting started is much more complicated than that.
It probably deserves a separate document to collect all the ideas.
Individual documents like NTS should be explicit about what they are
assuming.=C2=A0 Do they need valid (how close?) time or valid certificates = or ???

The above paragraph assumes the system has a writable file system.=C2=A0 Th= e
"every clock update" may be too expensive for some systems.

What happens the first time?=C2=A0 Even if you assume that file was sanely<= br> initialized at the factory, the unit may have sat on a shelf for a long tim= e.

What do you do if your clock gets set far into the future?


--
These are my opinions.=C2=A0 I hate spam.



_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://li= sts.ntp.org/listinfo/ntpwg



--
Sharon Goldberg
Computer Science, Boston Uni= versity
http:= //www.cs.bu.edu/~goldbe
--001a114444e009c489052f5e5210-- --===============4060584487314694580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============4060584487314694580==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 09:14:34 2016 Return-Path: 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 72F8212D0D8 for ; Fri, 1 Apr 2016 09:14:34 -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 EAJEsWSuwtGD for ; Fri, 1 Apr 2016 09:14:32 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 861E512D0B8 for ; Fri, 1 Apr 2016 09:14:30 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7ED9086DBED for ; Fri, 1 Apr 2016 16:14:30 +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 8E5E286D643 for ; Thu, 31 Mar 2016 20:59:04 +0000 (UTC) Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aljgE-0009B8-0l for ntpwg@lists.ntp.org; Thu, 31 Mar 2016 20:59:03 +0000 Received: by mail-wm0-x231.google.com with SMTP id 20so128914650wmh.1 for ; Thu, 31 Mar 2016 13:59:01 -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:date:message-id:subject :from:to:cc; bh=dTtFqIbxTY1OmU+3xsdGgHK4MiY0tKzhXLaaJNBoYng=; b=KL0BirxnP4pPs+GJ2G0pLhWgF3jatSYfxdiq/M2l/M5Y92mwYgPgfzOBo/wtitXSKu FmeXHxfRq3/9/CTRe2YyhrWMxOhgCyTt7iDDd37cbfaQqqZgJuacCDNsLBp9lqIOFDjN 3XyNeTC+Wylkwi7JwDU2eAEj4mksCHZ0GCVAVvfPHGpNHstl9LnWc/ceWK2YocvE2SkT 06X7nK6xvkTuTydaJ0GOtDKtnuavVuITM+YAk3FhmSzlIiC4MDSigG/8xwfRTkty0yz/ FOvJH3bNRUM7U+TzKuGFopmzL29kjE4k54ZDYt+2CjAJpFn1Vb0N7DlxJ7Q82h0SJBFo 7ToA== 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:date :message-id:subject:from:to:cc; bh=dTtFqIbxTY1OmU+3xsdGgHK4MiY0tKzhXLaaJNBoYng=; b=VQJm8FSdftIQ0E5ZuAsf/yOMs17W3y+rJtm4iSvftdoOm2HyrfKlVBM9jcB87gnJpd QTHjyIcNywaY+G1MKR1M2gooJDnE4rDEiWjhrfxlfJ/2LIXZng+eLLAIxh7srd83iux7 IljPMi+q/zQQXnvEPzQCd40RzMdm/xqdwfOPSWD9DznJgrXe//bF2IW2cX/fXTFYAumf 3E1qVOCfUZSG6CTxmeQTaXuK1oBuqvW3B6SAZfsj6X2TY77zgT/qCbkmCEnqbGEzzmf1 +FPNrw+Ou2/6B0Nhuq9Ortjb7d14wN3dMcfsXw+k4/wwA0h/gWPkeEYBGTD+W+4bjZw/ 6ocw== X-Gm-Message-State: AD7BkJIwSSDeekIEtiyhSfc74q41bXRogJcJYukbhk2VlEfT1vwydB/J6rGjXvBwL+Vf7nIzzu7nj1gLMyDyMg== MIME-Version: 1.0 X-Received: by 10.194.223.104 with SMTP id qt8mr881901wjc.11.1459457940274; Thu, 31 Mar 2016 13:59:00 -0700 (PDT) Received: by 10.194.242.35 with HTTP; Thu, 31 Mar 2016 13:59:00 -0700 (PDT) In-Reply-To: References: <20160331075844.GE834@localhost> <20160331090247.201B8406078@ip-64-139-1-69.sjc.megapath.net> <20160331094521.GA16340@localhost> Date: Thu, 31 Mar 2016 16:59:00 -0400 X-Google-Sender-Auth: g6-L7cv9z7fbBKWdTcygcXA_OG0 Message-ID: From: Sharon Goldberg To: Harlan Stenn X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::231 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) X-Mailman-Approved-At: Fri, 01 Apr 2016 16:06:43 +0000 Subject: Re: [ntpwg] What's the current thinking on rate limiting? X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Hal Murray , "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============0314493647945773241==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============0314493647945773241== Content-Type: multipart/alternative; boundary=001a11c3b8a41846a9052f5e88fb --001a11c3b8a41846a9052f5e88fb Content-Type: text/plain; charset=UTF-8 Thanks. For the record see the "priming the pump" attack in our paper: https://eprint.iacr.org/2015/1020.pdf On Thursday, March 31, 2016, Harlan Stenn wrote: > Miroslav Lichvar writes: > > Yes, that is a security issue in the implementation of rate limiting > > in ntpd, which was published last year. You may have seen posts from > > authors of the paper on this list :). The fix is to respond randomly > > when the clients appear to be sending too many requests, so they can't > > be starved from responses completely. At least one NTP implementation > > already does that. > > We're now doing a number of different things along those lines. There > are probably more things we could do, too. > > H > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a11c3b8a41846a9052f5e88fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks. For the record see the "priming the pump" attack in our p= aper:

https:= //eprint.iacr.org/2015/1020.pdf

On Thursday, March 31, 2016, Har= lan Stenn <stenn@ntp.org> wrote:=
Miroslav Lichvar writes:
> Yes, that is a security issue in the implementation of rate limiting > in ntpd, which was published last year. You may have seen posts from > authors of the paper on this list :). The fix is to respond randomly > when the clients appear to be sending too many requests, so they can&#= 39;t
> be starved from responses completely. At least one NTP implementation<= br> > already does that.

We're now doing a number of different things along those lines.=C2=A0 T= here
are probably more things we could do, too.

H
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://li= sts.ntp.org/listinfo/ntpwg



--
Sharon Goldberg
Computer Science= , Boston University
http://www.cs.bu.edu/~goldbe
--001a11c3b8a41846a9052f5e88fb-- --===============0314493647945773241== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============0314493647945773241==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 09:23:38 2016 Return-Path: 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 4050E12D0B8 for ; Fri, 1 Apr 2016 09:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 NzK-zgE7lKVQ for ; Fri, 1 Apr 2016 09:23:33 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id E7F5712D0F3 for ; Fri, 1 Apr 2016 09:23:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id E3AC986DC3E for ; Fri, 1 Apr 2016 16:23:31 +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 B0AC686DAD7 for ; Fri, 1 Apr 2016 16:03:58 +0000 (UTC) Received: from puck.nether.net ([2001:418:3f4::5]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1am1Y5-0005BB-Ka for ntpwg@lists.ntp.org; Fri, 01 Apr 2016 16:03:58 +0000 Received: from host226.workshop.dns-oarc.net (unknown [200.61.11.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 5F8855403E1; Fri, 1 Apr 2016 12:03:46 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jared Mauch In-Reply-To: <8D2BF679AAC7C346848A489074F9F8BF7AAFC3EA@sjsrvexchmbx2.microsemi.net> Date: Fri, 1 Apr 2016 12:03:43 -0400 Message-Id: <4CC4CA53-B8AF-40A9-9118-128DB06DD7FD@puck.nether.net> References: <20160329152654.GH20902@localhost> <20160331125908.GG834@localhost> <8D2BF679AAC7C346848A489074F9F8BF7AAFC3EA@sjsrvexchmbx2.microsemi.net> To: Greg Dowd X-Mailer: Apple Mail (2.3124) X-SA-Exim-Connect-IP: 2001:418:3f4::5 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: jared@puck.nether.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Fri, 01 Apr 2016 16:05:20 +0000 Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , "tictoc@ietf.org" , Sharon Goldberg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" Cj4gT24gQXByIDEsIDIwMTYsIGF0IDExOjI0IEFNLCBHcmVnIERvd2QgPEdyZWcuRG93ZEBtaWNy b3NlbWkuY29tPiB3cm90ZToKPiAKPiBSZW1vdmluZyBmcmFnbWVudGF0aW9uIGJ5IGRlZmluaXRp b24gaW4gYW4gYXBwbGljYXRpb24gcHJvdG9jb2wgaXNu4oCZdCBldmVuIHBvc3NpYmxlIGluIElw djQgYXMgcm91dGVycyBjYW4gZnJhZy4gIEl0IHNlZW1zIGEgbGFyZ2UgY2hhbGxlbmdlIHRvIG1h bmlwdWxhdGUgYW55IHg1MDkgc3RhY2sgYW5kIG5vdCBleHBlY3QgZnJhZ21lbnRhdGlvbj8gIEkg a25vdyB3ZSBhbGwgdGVuZCB0byB0aGluayBvZiAxNTE0IChJUCBvdmVyIDgwMi4zIEV0aGVybmV0 KSBidXQgTVRVIGlzIG5vdCBkZWZpbmVkIGJ5IHRoZSBlbmRwb2ludHMgYnV0IHRoZSBwYXRoLiAg SSB0aGluayBhIG51bWJlciBvZiB0aW1lcyB0aGVyZSBoYXMgYmVlbiBhIGRpc2N1c3Npb24gb2Yg cnVubmluZyBzb21lIHNlc3Npb24gY29tcG9uZW50cyBvdmVyIHRjcCB3aGljaCBtaWdodCBoZWxw IHdpdGggc29tZSBvZiB0aGUgc2VxdWVuY2luZyBpc3N1ZXMgb2Ygc3BsaXR0aW5nIHRoZSB0cmFu c2FjdGlvbj8gIEEgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgY2hhbGxlbmdlIGlzIHRoYXQsIHdo aWxlIG50cCBvd25zIHVkcCBhbmQgdGNwIDEyMywgSSB0aGluayBtYW55IGV4aXN0aW5nIGZpcmV3 YWxsIGNvbmZpZ3VyYXRpb25zIHdvdWxkIGRyb3AgdGNwIGNvbm5lY3Rpb25zIGZvciAxMjMuICBJ IGRvbuKAmXQga25vdyBob3cgbWFueSBhdXRva2V5IGRlcGxveW1lbnRzIGFyZSBhY3R1YWxseSBy dW5uaW5nIHNvIHBlcmhhcHMgaXQgaXMgbm90IHRoYXQgYmlnIGFuIGlzc3VlLgoKVGhlcmUgaXMg YSBsb3Qgb2YgZGF0YSBhcm91bmQgcGFja2V0IHNpemVzIHRoYXQgYXJlIGFibGUgdG8gYmUgcGFz c2VkIG9uIHRoZSB3aXJlIHdpdGhvdXQgaXNzdWUuICBBbnl0aGluZyBvdmVyIDE0MDAgc3RhcnRz IHRvIGJlIGEgcmlzayBvZiBiZWluZyBkcm9wcGVkLiAgQ29uc3VtZXJzIG9uIFBQUG9FIG9mdGVu IHNlZSAxNDkyLgoKTXkgYWR2aWNlIGlzIHRvIGxvb2sgYXQgd2hhdCBoYXMgdHJhbnNwaXJlZCBp biB0aGUgRE5TIHByb3RvY29sIGFyb3VuZCB0aGlzLiAgSWYgeW91IGhhdmVu4oCZdCBoYWQgdGlt ZSB0byByZWFkIHVwIG9uIHRoZSBoaXN0b3J5IHRoZXJlLCBpdOKAmXMgcmlwZSB3aXRoIGRldGFp bHMgb2Ygd2hhdCB3b3JrcyBhbmQgZG9lcyBub3QuICBUaGVyZSBpcyBhIGxvdCBvZiBwcm9iaW5n IHRoYXQgaGFwcGVucyBpbiB0aGUgcHJvdG9jb2wgdG8gZGV0ZXJtaW5lIHRoZSBwYWNrZXQgc2l6 ZXMgcGVybWlzc2libGUgd2l0aCBFRE5TLgoKV2hpbGUgZnJhZ21lbnRhdGlvbiBtYXkgb2NjdXIg YW5kIGJpdHMgbWF5IHBhc3MsIGl0IGlzIHVubGlrZWx5IHRvIGJlIHJlbGlhYmxlLiAgQXMgdGhl IHByb3RvY29sIGlzIGRlc2lnbmVkLCB0aGVzZSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyBz aG91bGQgdW5kZXJzdG9vZC4KCi0gSmFyZWQKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbnRwd2cgbWFpbGluZyBsaXN0Cm50cHdnQGxpc3RzLm50cC5vcmcK aHR0cDovL2xpc3RzLm50cC5vcmcvbGlzdGluZm8vbnRwd2c= From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 1 12:57:19 2016 Return-Path: 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 A3E7D12D5EA for ; Fri, 1 Apr 2016 12:57:19 -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 (1024-bit key) reason="fail (message has been altered)" header.d=isoc.onmicrosoft.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 ysYSTlTPx6Xm for ; Fri, 1 Apr 2016 12:57:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 613D512D5CD for ; Fri, 1 Apr 2016 12:57:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 50E3486DC18 for ; Fri, 1 Apr 2016 19:57:16 +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 85D2386D48C for ; Fri, 1 Apr 2016 19:56:45 +0000 (UTC) Received: from mail-bn1on0066.outbound.protection.outlook.com ([157.56.110.66] helo=na01-bn1-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1am5BM-0008jL-Mb for ntpwg@lists.ntp.org; Fri, 01 Apr 2016 19:56:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jH5ZyO0LbIBw/m0QCHrouRfomeAG8adqsMMBNkyqAII=; b=QSjteOsiSRlbMC1QdQYccZT7rVpD51KNcjsbuTAQPafJhPxCaSBQjI+Mq5h4dKbzK7iPyHLft6bmXey+vJt/shrC5ePNVmauBIDU4/5eN/F9EbAhNgI6ihp7tge4EiaVte7ap0Ip5cpujWe/df92SfLgtNPeDMymH2Q2n2dTkCk= Received: from BY1PR0601MB1111.namprd06.prod.outlook.com (10.160.196.14) by BY1PR0601MB1111.namprd06.prod.outlook.com (10.160.196.14) with Microsoft SMTP Server (TLS) id 15.1.443.12; Fri, 1 Apr 2016 19:56:34 +0000 Received: from BY1PR0601MB1111.namprd06.prod.outlook.com ([10.160.196.14]) by BY1PR0601MB1111.namprd06.prod.outlook.com ([10.160.196.14]) with mapi id 15.01.0443.017; Fri, 1 Apr 2016 19:56:34 +0000 From: Karen O'Donoghue To: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Thread-Topic: Remote Participation for IETF 95: Meetecho Details Thread-Index: AQHRisHwUm+aYbHzmEGVugXIwIi9Fg== Date: Fri, 1 Apr 2016 19:56:34 +0000 Message-ID: <042BAC14-28B3-4E7C-8EB3-9DBB26322CD0@isoc.org> References: <20160330202243.4795.63685.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.ntp.org; dkim=none (message not signed) header.d=none; lists.ntp.org; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.140.249] x-ms-office365-filtering-correlation-id: c8384ad9-0851-411d-0ed1-08d35a67baa2 x-microsoft-exchange-diagnostics: 1; BY1PR0601MB1111; 5:qn9wz6W7w2zvhs8ZZez/zDY2mB19mbZ6Aj7e7hX2Zhi1tq43kc3DlXAbJTbQC7TNI4CjwCNcU+sPToHJeMcR/gPkbLlT6aCubokerH4X1DfaIpO2iNUSLQoikYqweB2hFNr3t1aSIYsgbuRqT/9SYg==; 24:dMROD+HIg4/4oTiZFKN0aXBOEMztTe6jV9YvnTkk/S4TWAc/kAE1ykjVZkfI/WWNxz53A99aSh3BvJus50ifYjBY+O589M3GwUGfGk4ZQ/E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0601MB1111; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY1PR0601MB1111; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0601MB1111; x-forefront-prvs: 0899B47777 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(2473001)(377454003)(3846002)(5002640100001)(10400500002)(86362001)(54356999)(50986999)(76176999)(2501003)(36756003)(2906002)(82746002)(107886002)(19580405001)(189998001)(5004730100002)(92566002)(122556002)(83716003)(77096005)(19300405004)(81166005)(5001770100001)(586003)(16799955002)(87936001)(15395725005)(1096002)(6116002)(3280700002)(19617315012)(106116001)(99286002)(1220700001)(5008740100001)(2900100001)(19273905006)(19580395003)(3660700001)(102836003)(66066001)(11100500001)(15975445007)(16236675004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0601MB1111; H:BY1PR0601MB1111.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2016 19:56:34.5873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0601MB1111 X-SA-Exim-Connect-IP: 157.56.110.66 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Fwd: Remote Participation for IETF 95: Meetecho Details X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8371791877191074782==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============8371791877191074782== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_042BAC1428B34E7C8EB39DBB26322CD0isocorg_" --_000_042BAC1428B34E7C8EB39DBB26322CD0isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As a reminder, the Joint NTP/TICTOC meeting here at IETF 95 is Tuesday, 5 April, 1400-1600 ART (1700-1900 UTC). As part of the effort to improve remote participation support, there has be= en a change to the remote participation process for IETF 95. You are asked = to register for the meeting. There is no cost for this registration. We will be using meetecho to support this meeting. There are also links to = a self test that you should perform in advance of the session itself. Thanks! Karen Begin forwarded message: From: IETF Secretariat > Subject: Remote Participation for IETF 95: Meetecho Details Date: March 30, 2016 at 5:22:43 PM GMT-3 To: "IETF Announcement List" > Cc: wgchairs@ietf.org, recentattendees@ietf.org, 95all@ietf.org Reply-To: ietf@ietf.org You may use Meetecho to participate in or just observe any session being he= ld in Buenos Aires. Here are the requirements and details. 1. Individuals are required to register for the meeting to observe or parti= cipate via Meetecho. - Individuals are required to enter registration I.D and name when logging = into a session via Meetecho - The name must match that used to register for the meeting - Please register even if you are participating as part of remote hub - There is no cost to register as a remote attendee. Register here:http://i= etf.org/meeting/register.html. 2. Participation includes the ability to transmit audio and video via the M= eetecho virtual queue. - The virtual queue permits remote attendees to share audio and video if th= ey choose, see here for more information: https://ietf95.conf.meetecho.com/= index.php/UMPIRE_Project - Anyone who thinks they may want to participate by transmitting audio / vi= deo should perform the Meetecho self-test prior to the start of the session= : http://ietf95.conf.meetecho.com/index.php/Self_Test 3. WG Chairs will control the virtual queue, unmuting and muting of remote = participants 4. The agenda for the WG sessions, as well as more detail on how to use Mee= techo to participate, can be found here: https://ietf95.conf.meetecho.com/i= ndex.php/. --_000_042BAC1428B34E7C8EB39DBB26322CD0isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <03240BFEA9F8B040A9E657826592A574@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Folks,

As a reminder, the Joint NTP/TICTOC meeting here at IETF 95= is 
Tuesday, 5 April, 1400-1600 ART (1700-1900 UTC). 

As part of the effort to improve remote participation suppo= rt, there has been a change to the remote participation process for IETF 95= . You are asked to register for the meeting. There is no cost for this regi= stration. 

We will be using meetecho to support this meeting. There ar= e also links to a self test that you should perform in advance of the sessi= on itself. 

Thanks!
Karen

Begin forwarded message:

From: IETF Secretariat <ietf-secretariat@ietf.org>
Subject: Remote Participation for = IETF 95: Meetecho Details
Date: March 30, 2016 at 5:22:43 PM GMT-3
To: "IETF Announcement List" <= ietf-announce@ietf.org= >
Cc: wgchairs@ietf.org, recentattendees@ietf= .org, 95all@ietf.org
Reply-To: ietf@ietf.org

You may use Meetecho to participate in or just observe any = session being held in Buenos Aires. Here are the requirements and details.

1. Individuals are required to register for the meeting to observe or parti= cipate via Meetecho.
- Individuals are required to enter registration I.D and name when logging = into a session via Meetecho
- The name must match that used to register for the meeting
- Please register even if you are participating as part of remote hub
- There is no cost to register as a remote attendee. Register here:http://<= a href=3D"http://ietf.org/meeting/register.html" class=3D"">ietf.org/meetin= g/register.html.

2. Participation includes the ability to transmit audio and video via the M= eetecho virtual queue.
- The virtual queue permits remote attendees to share audio and video if th= ey choose, see here for more information: https://ietf95.conf.meetecho.com/index.php/UMPIRE_Project
- Anyone who thinks they may want to participate by transmitting audio / vi= deo should perform the Meetecho self-test prior to the start of the session= : = http://ietf95.conf.meetecho.com/index.php/Self_Test

3. WG Chairs will control the virtual queue, unmuting and muting of remote = participants

4. The agenda for the WG sessions, as well as more detail on how to use Mee= techo to participate, can be found here: https://= ietf95.conf.meetecho.com/index.php/.


--_000_042BAC1428B34E7C8EB39DBB26322CD0isocorg_-- --===============8371791877191074782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============8371791877191074782==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sat Apr 2 07:01:11 2016 Return-Path: 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 7E8FC12D0C9 for ; Sat, 2 Apr 2016 07:01:11 -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 (1024-bit key) reason="fail (message has been altered)" header.d=isoc.onmicrosoft.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 NGaS9defddER for ; Sat, 2 Apr 2016 07:01:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3B22612D0DF for ; Sat, 2 Apr 2016 07:01:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 1402086DC4A for ; Sat, 2 Apr 2016 14:01:08 +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 BBFAC86D48C for ; Sat, 2 Apr 2016 12:34:51 +0000 (UTC) Received: from mail-bn1on0063.outbound.protection.outlook.com ([157.56.110.63] helo=na01-bn1-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1amKlG-0002uc-MG for ntpwg@lists.ntp.org; Sat, 02 Apr 2016 12:34:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rglv/yX4hVFpKCOzTultoWIIVhYH8NfmnjkONtTqGQk=; b=T8f5fRwjUCyiQlouplXWSXYYYyqrJ/qFRKwkv6cstX96B9w7tyQdYafQ13q4Ife7AacNRldT5TK37WBAZEJ5ob/VmyTmz8S1/Nga34qeMQVyaGBQRzTguMw0eL8v+i4ttLHQetkx9Syn5GGGzK8kKXi5nhNcnRA2vLojPVVEW34= Received: from BY1PR0601MB1111.namprd06.prod.outlook.com (10.160.196.14) by BY1PR0601MB1112.namprd06.prod.outlook.com (10.160.196.140) with Microsoft SMTP Server (TLS) id 15.1.443.12; Sat, 2 Apr 2016 12:34:39 +0000 Received: from BY1PR0601MB1111.namprd06.prod.outlook.com ([10.160.196.14]) by BY1PR0601MB1111.namprd06.prod.outlook.com ([10.160.196.14]) with mapi id 15.01.0443.017; Sat, 2 Apr 2016 12:34:40 +0000 From: Karen O'Donoghue To: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Thread-Topic: Remote Participation for IETF 95: Meetecho Details Thread-Index: AQHRisHwUm+aYbHzmEGVugXIwIi9Fp92ooWA Date: Sat, 2 Apr 2016 12:34:39 +0000 Message-ID: <6DD14B3B-4632-4913-900A-E5167254DA05@isoc.org> References: <20160330202243.4795.63685.idtracker@ietfa.amsl.com> <042BAC14-28B3-4E7C-8EB3-9DBB26322CD0@isoc.org> In-Reply-To: <042BAC14-28B3-4E7C-8EB3-9DBB26322CD0@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.ntp.org; dkim=none (message not signed) header.d=none; lists.ntp.org; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.130.224.165] x-ms-office365-filtering-correlation-id: 1a1e634c-a26f-49b4-2ecb-08d35af3290a x-microsoft-exchange-diagnostics: 1; BY1PR0601MB1112; 5:PigI2bqo1wMAaDfvmlMtdr3TgHnNQvW5Mx8jgXhRhqNWq4oFm0/6P2M4W1x1SWx4YLLNRm2UD+j+4u1pDjsN40ygE6cAuf7nUbw8sbcLMR/m5RWv7DPDYz3FpUqn9jRbXrE/5NWxN9Hp19yy1ct09A==; 24:mJ3Qf/uqkou62Y/4hDteXL04uq17QrqziJWafGf24/N4xmIco5qpewGBtqANI5hfd9BrKeAVnf8TnmPt9uR4da8xEv/fOuMXbvgOGHX55wg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0601MB1112; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY1PR0601MB1112; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0601MB1112; x-forefront-prvs: 09007040D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(24454002)(377454003)(54356999)(122556002)(82746002)(76176999)(83716003)(1220700001)(19580405001)(81166005)(1096002)(19580395003)(50986999)(19617315012)(2501003)(586003)(3846002)(86362001)(92566002)(2906002)(10400500002)(87936001)(66066001)(5002640100001)(6116002)(102836003)(107886002)(5004730100002)(3280700002)(189998001)(5001770100001)(15395725005)(3660700001)(16236675004)(33656002)(2950100001)(36756003)(2900100001)(16799955002)(106116001)(99286002)(5008740100001)(19273905006)(15975445007)(19300405004)(77096005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0601MB1112; H:BY1PR0601MB1111.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2016 12:34:39.8645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0601MB1112 X-SA-Exim-Connect-IP: 157.56.110.63 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Remote Participation for IETF 95: Meetecho Details X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7929298145236169842==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============7929298145236169842== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_6DD14B3B46324913900AE5167254DA05isocorg_" --_000_6DD14B3B46324913900AE5167254DA05isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As sometimes happens when processes change, there has been a glitch with re= mote registration. Please follow the link provided by the secretariat below= to register for remote participation. Karen, We realized last night that when registration closed it also automatically closed remote participation registration as well. We had our IT folk reopen remote participation registration. They can access remote participation fro= m the link on this page. http://ietf.org/meeting/95/remote-participation.html Thanks, Karen On Apr 1, 2016, at 4:56 PM, Karen O'Donoghue > wrote: Folks, As a reminder, the Joint NTP/TICTOC meeting here at IETF 95 is Tuesday, 5 April, 1400-1600 ART (1700-1900 UTC). As part of the effort to improve remote participation support, there has be= en a change to the remote participation process for IETF 95. You are asked = to register for the meeting. There is no cost for this registration. We will be using meetecho to support this meeting. There are also links to = a self test that you should perform in advance of the session itself. Thanks! Karen Begin forwarded message: From: IETF Secretariat > Subject: Remote Participation for IETF 95: Meetecho Details Date: March 30, 2016 at 5:22:43 PM GMT-3 To: "IETF Announcement List" > Cc: wgchairs@ietf.org, recentattendees@ietf.org, 95all@ietf.org Reply-To: ietf@ietf.org You may use Meetecho to participate in or just observe any session being he= ld in Buenos Aires. Here are the requirements and details. 1. Individuals are required to register for the meeting to observe or parti= cipate via Meetecho. - Individuals are required to enter registration I.D and name when logging = into a session via Meetecho - The name must match that used to register for the meeting - Please register even if you are participating as part of remote hub - There is no cost to register as a remote attendee. Register here:http://i= etf.org/meeting/register.html. 2. Participation includes the ability to transmit audio and video via the M= eetecho virtual queue. - The virtual queue permits remote attendees to share audio and video if th= ey choose, see here for more information: https://ietf95.conf.meetecho.com/= index.php/UMPIRE_Project - Anyone who thinks they may want to participate by transmitting audio / vi= deo should perform the Meetecho self-test prior to the start of the session= : http://ietf95.conf.meetecho.com/index.php/Self_Test 3. WG Chairs will control the virtual queue, unmuting and muting of remote = participants 4. The agenda for the WG sessions, as well as more detail on how to use Mee= techo to participate, can be found here: https://ietf95.conf.meetecho.com/i= ndex.php/. --_000_6DD14B3B46324913900AE5167254DA05isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Folks,

As sometimes happens when processes change, there has been = a glitch with remote registration. Please follow the link provided by the s= ecretariat below to register for remote participation. 

Karen,
We realized last night that when regis= tration closed it also automatically
closed remote participation registration as well. We had our IT folk reopen=
remote participation registration. They can access remote participation fro= m
the link on this page.

http://ietf.org/meeting/95/remote-participation.html

Thanks,
Karen

On Apr 1, 2016, at 4:56 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:
Folks,

As a reminder, the Joint NTP/TICTOC meeting here at IETF 95= is 
Tuesday, 5 April, 1400-1600 ART (1700-1900 UTC). 

As part of the effort to improve remote participation suppo= rt, there has been a change to the remote participation process for IETF 95= . You are asked to register for the meeting. There is no cost for this regi= stration. 

We will be using meetecho to support this meeting. There ar= e also links to a self test that you should perform in advance of the sessi= on itself. 

Thanks!
Karen

Begin forwarded message:

From: IETF Secretariat <ietf-secretariat@ietf.org>
Subject: Remote Participation for = IETF 95: Meetecho Details
Date: March 30, 2016 at 5:22:43 PM GMT-3
To: "IETF Announcement List" <= ietf-announce@ietf.org= >
Cc: wgchairs@ietf.org, recentattendees@ietf= .org, 95all@ietf.org
Reply-To: ietf@ietf.org

You may use Meetecho to participate in or just observe any = session being held in Buenos Aires. Here are the requirements and details.

1. Individuals are required to register for the meeting to observe or parti= cipate via Meetecho.
- Individuals are required to enter registration I.D and name when logging = into a session via Meetecho
- The name must match that used to register for the meeting
- Please register even if you are participating as part of remote hub
- There is no cost to register as a remote attendee. Register here:http://<= a href=3D"http://ietf.org/meeting/register.html" class=3D"">ietf.org/meetin= g/register.html.

2. Participation includes the ability to transmit audio and video via the M= eetecho virtual queue.
- The virtual queue permits remote attendees to share audio and video if th= ey choose, see here for more information: https://ietf95.conf.meetecho.com/index.php/UMPIRE_Project
- Anyone who thinks they may want to participate by transmitting audio / vi= deo should perform the Meetecho self-test prior to the start of the session= : = http://ietf95.conf.meetecho.com/index.php/Self_Test

3. WG Chairs will control the virtual queue, unmuting and muting of remote = participants

4. The agenda for the WG sessions, as well as more detail on how to use Mee= techo to participate, can be found here: https://= ietf95.conf.meetecho.com/index.php/.



--_000_6DD14B3B46324913900AE5167254DA05isocorg_-- --===============7929298145236169842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7929298145236169842==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 4 05:02:59 2016 Return-Path: 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 9863912D5CD for ; Mon, 4 Apr 2016 05:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 qbnMABFXzYrO for ; Mon, 4 Apr 2016 05:02:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id AB55412D5D2 for ; Mon, 4 Apr 2016 05:02:51 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 9E3CE86DC0F for ; Mon, 4 Apr 2016 12:02:51 +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 6546386DBE0 for ; Mon, 4 Apr 2016 11:58:50 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1an39S-0003vl-5g for ntpwg@lists.ntp.org; Mon, 04 Apr 2016 11:58:50 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id u34BwUZ5026710-u34BwUZ7026710 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 13:58:30 +0200 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id D1FA3C55A8; Mon, 4 Apr 2016 13:58:30 +0200 (CEST) To: "NTP Working Group" , tictoc@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Mon, 4 Apr 2016 13:58:29 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kristof.teichel@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Meet up for NTS discussions in Buenos Aires? X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1168272182199633626==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============1168272182199633626== Content-Type: multipart/alternative; boundary="=_alternative 0041C7B6C1257F8B_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0041C7B6C1257F8B_= Content-Type: text/plain; charset="US-ASCII" Hello all, I just wanted to throw out the question who else on these mailing lists is in Buenos Aires for this IETF meeting and would want to meet up with me to discuss any NTS-related issues over some food and/or drink? I would prefer to do this after tomorrow's WG session. Best regards, Kristof --=_alternative 0041C7B6C1257F8B_= Content-Type: text/html; charset="US-ASCII" Hello all,

I just wanted to throw out the question who else on these mailing lists is in Buenos Aires for this IETF meeting and would want to meet up with me to discuss any NTS-related issues over some food and/or drink?
I would prefer to do this after tomorrow's WG session.

Best regards,
Kristof --=_alternative 0041C7B6C1257F8B_=-- --===============1168272182199633626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1168272182199633626==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 09:08:24 2016 Return-Path: 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 ADDDC12D725 for ; Tue, 5 Apr 2016 09:08:24 -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 (1024-bit key) reason="fail (message has been altered)" header.d=isoc.onmicrosoft.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 i7iZawpjtRrY for ; Tue, 5 Apr 2016 09:08: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 AB5CA12D71B for ; Tue, 5 Apr 2016 09:08:13 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A02B086DBD7 for ; Tue, 5 Apr 2016 16:08:13 +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 EC85886DB07 for ; Tue, 5 Apr 2016 16:06:28 +0000 (UTC) Received: from mail-by2on0095.outbound.protection.outlook.com ([207.46.100.95] helo=na01-by2-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anTUi-0007lW-8o for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 16:06:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gfzqphq5hhH71eBanCqxCArO8JYwLIehpMd6O0bC4Gs=; b=cBPrMz35iTFbJhNnw5SHR1AwsuQyuE7rL9t4aoQqgylXkeL1oDc1iVWxoofYpIz+uWhjuACo4o1mJFEkK/EqDFpeo7fpwQgi2/kQCq1+XyjAcynPCLXzUGzJk4eoBR7mPLi0Y3AQ2Y7LdIQ/ACjuR5lB29dEwcgnMziKXIytsMc= Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) by DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 16:06:19 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) with mapi id 15.01.0447.028; Tue, 5 Apr 2016 16:06:19 +0000 From: Karen O'Donoghue To: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Thread-Topic: final instructions for the NTP/TICTOC remote participation Thread-Index: AQHRj1UWSjaBhpEHNU+8xws6WkVjMA== Date: Tue, 5 Apr 2016 16:06:18 +0000 Message-ID: <2304D4FC-6CD1-422B-9F09-948C61E090E7@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.ntp.org; dkim=none (message not signed) header.d=none; lists.ntp.org; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.176.204] x-ms-office365-filtering-correlation-id: b128a604-532c-4146-4bc7-08d35d6c397d x-microsoft-exchange-diagnostics: 1; DM2PR0601MB1118; 5:ANlFmBLsQUA/Aw9Ipl3KwxS+Xk9hZktVhcTCIqLFIZ6bzLvc5P3rhuYtb3U1dMBgxf4t0sUFU+YfSkL/b8Vo6YgH2Y46mulk4CYuWs5CYu6y6eCFCH0mlSUY7SggglvzaFSkpQbBvmRM+pkUKbI9hA==; 24:5ULO8ZezIPvrNa0neLzgKEZllFoa2AYG94SWlTF7Rovol5u00FzSHuRt60uKrppfawcVJIWwvWwBru/4fwEjnuB66A+cjfc6pi7cQpFp2rk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB1118; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DM2PR0601MB1118; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1118; x-forefront-prvs: 0903DD1D85 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(81166005)(229853001)(83716003)(87936001)(5008740100001)(16236675004)(66066001)(107886002)(19617315012)(15975445007)(77096005)(5004730100002)(36756003)(5001770100001)(92566002)(189998001)(2900100001)(122556002)(2501003)(33656002)(54356999)(16799955002)(86362001)(5002640100001)(99286002)(3280700002)(106116001)(11100500001)(6116002)(1220700001)(3660700001)(1096002)(586003)(3846002)(10400500002)(2906002)(102836003)(19580395003)(82746002)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB1118; H:DM2PR0601MB1118.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2016 16:06:18.9391 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB1118 X-SA-Exim-Connect-IP: 207.46.100.95 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] final instructions for the NTP/TICTOC remote participation X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1390043515924054758==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============1390043515924054758== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2304D4FC6CD1422B9F09948C61E090E7isocorg_" --_000_2304D4FC6CD1422B9F09948C61E090E7isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNClJlbWluZGVyIHRoYXQgdGhlIE5UUC9USUNUT0MgbWVldGluZyBzdGFydHMgaW4g MSBob3VyLiBXZSBhcmUgd29ya2luZyBvbiBpbXByb3Zpbmcgb3VyIHJlbW90ZSBwYXJ0aWNpcGF0 aW9uIHRvb2xzLg0KDQpIZXJlIGlzIGEgbGluayB0byBhbGwgdGhlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBNZWV0ZWNobyB0b29sDQpodHRwOi8vaWV0Zjk1LmNvbmYubWVldGVjaG8uY29tL2luZGV4 LnBocC9SZW1vdGVfUGFydGljaXBhdGlvbg0KDQpJIHNlbnQgc29tZXRoaW5nIGVhcmxpZXIgYWJv dXQgcmVxdWlyaW5nIHJlZ2lzdHJhdGlvbi4gVGhleSB3b3VsZCByZWFsbHkgbGlrZSB5b3UgdG8g cmVnaXN0ZXIsIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRv4oCmDQoNCkhvd2V2ZXIsIEkgd291bGQg c3Ryb25nbHkgZW5jb3VyYWdlIHlvdSB0byBkbyB0aGUgc2VsZiB0ZXN0IHRvIGVuc3VyZSB0aGF0 IHlvdXIgYXVkaW8vdmlkZW8gYXJlIHdvcmtpbmcuIEnigJl2ZSBkb25lIGl0IHdpdGggdGhlIGNo cm9tZSBicm93c2VyIGFuZCBpdCB3b3JrZWQgZmluZeKApiBubyBwbHVnaW5zIG9yIGFueXRoaW5n 4oCmDQoNClRoYW5rcywNCkthcmVuDQoNCg== --_000_2304D4FC6CD1422B9F09948C61E090E7isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <15F0BC9D2F432D4BAD59ED33C8FCE310@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Gb2xrcyw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlJlbWluZGVyIHRoYXQgdGhlIE5UUC9USUNUT0MgbWVldGluZyBzdGFydHMgaW4gMSBob3VyLiBX ZSBhcmUgd29ya2luZyBvbiBpbXByb3Zpbmcgb3VyIHJlbW90ZSBwYXJ0aWNpcGF0aW9uIHRvb2xz LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SGVyZSBpcyBhIGxpbmsgdG8gYWxsIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUg TWVldGVjaG8gdG9vbDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwOi8vaWV0Zjk1 LmNvbmYubWVldGVjaG8uY29tL2luZGV4LnBocC9SZW1vdGVfUGFydGljaXBhdGlvbiIgY2xhc3M9 IiI+aHR0cDovL2lldGY5NS5jb25mLm1lZXRlY2hvLmNvbS9pbmRleC5waHAvUmVtb3RlX1BhcnRp Y2lwYXRpb248L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5JIHNlbnQgc29tZXRoaW5nIGVhcmxpZXIgYWJvdXQgcmVxdWlyaW5nIHJl Z2lzdHJhdGlvbi4gVGhleSB3b3VsZCByZWFsbHkgbGlrZSB5b3UgdG8gcmVnaXN0ZXIsIGJ1dCB5 b3UgZG9u4oCZdCBoYXZlIHRv4oCmJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVyLCBJIHdvdWxkIHN0cm9uZ2x5IGVu Y291cmFnZSB5b3UgdG8gZG8gdGhlIHNlbGYgdGVzdCB0byBlbnN1cmUgdGhhdCB5b3VyIGF1ZGlv L3ZpZGVvIGFyZSB3b3JraW5nLiBJ4oCZdmUgZG9uZSBpdCB3aXRoIHRoZSBjaHJvbWUgYnJvd3Nl ciBhbmQgaXQgd29ya2VkIGZpbmXigKYgbm8gcGx1Z2lucyBvciBhbnl0aGluZ+KApiZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5LYXJlbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2304D4FC6CD1422B9F09948C61E090E7isocorg_-- --===============1390043515924054758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1390043515924054758==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 10:53:50 2016 Return-Path: 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 E74C912D129 for ; Tue, 5 Apr 2016 10:53:50 -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 NHb61y9PADbt for ; Tue, 5 Apr 2016 10:53:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id B345912D758 for ; Tue, 5 Apr 2016 10:53:47 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A820786DBEA for ; Tue, 5 Apr 2016 17:53:47 +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 B5A4586DBC1 for ; Tue, 5 Apr 2016 17:40:03 +0000 (UTC) Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anUxM-0008v5-Si for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 17:40:03 +0000 Received: by mail-wm0-x230.google.com with SMTP id 191so32285433wmq.0 for ; Tue, 05 Apr 2016 10:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=pUKZCp9FIeFXJVo7uPeatovGgsym1Eywfb5As/KHtrs=; b=HsMBFCeLexWiBMcQmPipS4cw1eZ7HeuCKILebHzmo7aWxR5PUG6dYljo8kYUueLgB1 wb+cfCAkEXt1GqyUbxpmRsEZiehd5cSTQRPS65oTExjfjo+16l6FfOhzJjZnGXVunNDl 85ByXXZGZ46gXFnVawrYwvAZsM3GZGePUTqMTsc0MBu0YeWu3FlZs5IuIoYa0JWfMYd3 aDIJaE4siFu5zY3aH8ItcPgneL74YHfX0PJJQZkn7BTUCyVEfC9O/3NBs4XL22+7PtnU QUIkwzQNaicVpYH2CAXQwAEykcYVmGira81UUflNFA5mwJ/bBeKuv10g1iGDpE2ni2sB JOIA== 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:from:date:message-id:subject :to; bh=pUKZCp9FIeFXJVo7uPeatovGgsym1Eywfb5As/KHtrs=; b=CyosPjKRnjYn5PhwfWzFcwob8YtBDcDrGQFqsw7cikRFgcRHrn8UD5xjTbwdrBRtqA keTma0LSOnUX/XM4YkuySavTLrdiSqkV54c3VZi4oXefdWRKg81aTXdHeOvyw13ZXfTG JyyxK0hrCCK9DFsnzY970uzfwy+g52a06wjxymfckhDlMat8v9J65ld9/sQ96pqrraeC IOCKkVMChoan+PoUunxky91V8cGh0DFfCpJvqlVpdvihiqb4SFvz3LANxnYb5lT0wJ2h 0TZsAcrdGl+45w8B7v80lA3AEJ1mkNJeu/vgeicxjAsH/iRw9LNvN2D54WeeJntW+gYY 5Pjw== X-Gm-Message-State: AD7BkJI0KLtLYSc7SfvYRMHxmv3wYcHWlGcmcf+DeSNApM4UIf5m4gN8XdXLsx1RZDnqURgTzjouz5dMmurO0Q== X-Received: by 10.194.178.233 with SMTP id db9mr7535395wjc.11.1459877999076; Tue, 05 Apr 2016 10:39:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Tue, 5 Apr 2016 10:39:19 -0700 (PDT) From: Sharon Goldberg Date: Tue, 5 Apr 2016 13:39:19 -0400 X-Google-Sender-Auth: VIDeUYYI1KC5PspTBsNYrgF5N38 Message-ID: To: NTP Working Group , tictoc@ietf.org X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::230 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: [ntpwg] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6218076878079984926==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============6218076878079984926== Content-Type: multipart/alternative; boundary=089e013d1a088cec6f052fc0551d --089e013d1a088cec6f052fc0551d Content-Type: text/plain; charset=UTF-8 Just to follow up on my comment during the IETF'95 wg meeting right now: NTS requires a server-seed refresh, and uses the 5th and 6th message of the KE protocol to do this. What is the use case for server seed key refresh? Thanks, Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --089e013d1a088cec6f052fc0551d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to follow up on my comment during the IETF'95 wg = meeting right now: =C2=A0NTS requires a server-seed refresh, and uses the 5= th and 6th message of the KE protocol to do this.=C2=A0 What is the use cas= e for server seed key refresh?=C2=A0

Thanks,
Sharon<= /div>

--
Sharon Goldb= erg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--089e013d1a088cec6f052fc0551d-- --===============6218076878079984926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============6218076878079984926==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 11:39:12 2016 Return-Path: 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 14A1B12D162 for ; Tue, 5 Apr 2016 11:39:12 -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 I3FUuY0j8c5x for ; Tue, 5 Apr 2016 11:39:10 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 39CC612D12C for ; Tue, 5 Apr 2016 11:39:10 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 3560986DBDB for ; Tue, 5 Apr 2016 18:39:10 +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 6D61086DAEC for ; Tue, 5 Apr 2016 18:28:50 +0000 (UTC) Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anVia-0009eN-DO for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 18:28:50 +0000 Received: by mail-wm0-x230.google.com with SMTP id n3so32843360wmn.0 for ; Tue, 05 Apr 2016 11:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=Z51CzLKGXGPJeBZ9b8AD4D4GTSNjqpZA+PZZUI4/3xI=; b=BhQ7cxeT/GsE4P44USquz1xpJ0kEdKVcQ/7Xe/XcWxrOrYVcZrKSkyLEeFoSj4bSgb O2T5KjcC8aMhH0ug8XD3E5TK5PZQB9xbeNF576bBueUeQhMc7rS1Dn8MzzYD9MLNlYbL 7CkTLRIltwGasJMhN0+GZ8OLPE6TrzFhwZoiFEl1xF4mvZJRhaJitaRVxBzzBKcO7odS vVBYhkGED1zgoG9bRfN2l0rbYCIws+lCYgwU2bah0gp/4If78ASEzulzmLWlflHHf2or uo6kksPUyGdtGZ3U8+gv3bBjFSn587rLyzqPmjBXX8wfYpbSlS39B6R29+h7zyJ8CDq0 VctA== 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:from:date:message-id:subject :to; bh=Z51CzLKGXGPJeBZ9b8AD4D4GTSNjqpZA+PZZUI4/3xI=; b=R/DePuwwikiGJtx4W51lk04cnX7bxHGVmOi5UTts9Cj8S3xiu32yzK7i1+IBnZdYgU OGQACQgG75/vO9vEurmE46TllOBgzLXB0o/xe+5x2ZXslu63VLcS3YcWzmuAS1xqDL5U MLQCtghsq82m04X7Uh2sbogoANhmMH+/WTJ226DFn/tHWbY9hfjnvk/eMCeAnpLEI6O4 5jTiIFVhD65MEBJpG8RyscNLZgn9JTBEmD6SgUPH4RbpmrIKYZzb6yACqrWsIZyd469h sHcVm6MkZZnH+hVfKG43jZ/kNb0bstDZtSB8G5ogwVjcNnFJCZyJmkKkz+15qQ7ZW3H+ 66JA== X-Gm-Message-State: AD7BkJK2CbY9R92IDQ01qmTiY9IhZP75OaKIh25Ul/+0k7DLCKD2IZZbr4fEUJ/GjPBCsUojGwJwKI9EmResGQ== X-Received: by 10.28.227.130 with SMTP id a124mr19574809wmh.2.1459880926855; Tue, 05 Apr 2016 11:28:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Tue, 5 Apr 2016 11:28:07 -0700 (PDT) From: Sharon Goldberg Date: Tue, 5 Apr 2016 14:28:07 -0400 X-Google-Sender-Auth: bSVIivK_1HeqCLIq_AmRyULwB_A Message-ID: To: NTP Working Group , tictoc@ietf.org X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::230 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: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3013788298113570257==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============3013788298113570257== Content-Type: multipart/alternative; boundary=001a114ccbd40f479b052fc10468 --001a114ccbd40f479b052fc10468 Content-Type: text/plain; charset=UTF-8 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 --001a114ccbd40f479b052fc10468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.=C2=A0 I= believe the goals of the draft can be accomplished without using an extens= ion field, in a backwards compatible fashion.

The = goal of the draft is to limit the information exposed by the REFID while st= ill preserving robustness to "length-1" timing loops where system= A takes time from system B, but system B takes time from system A. =C2=A0<= /div>
This proposal allow system A to limit the info it leaks in its re= fID, without harming any of its legacy clients.=C2=A0

<= div>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 tak= e time from A because this would cause a timing loop.

<= div>2) If A gets a time query from system C, A puts a "nonsense" = value in its refID.=C2=A0 Even a legacy C can see that its IP is not in the= refID, and so it is allowed to take time from A.=C2=A0

One question is what this "nonsense" value should be.=C2=A0= I think it should be a fixed value. For example 0.0.0.0.=C2=A0 We would no= t want a randomly-chosen value since this might collide with actual IP addr= esses on the network.

Thanks,
Sharon


--
Sharo= n Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a114ccbd40f479b052fc10468-- --===============3013788298113570257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============3013788298113570257==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 11:54:17 2016 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ) 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 ; 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: References: From: Sharon Goldberg Date: Tue, 5 Apr 2016 14:42:27 -0400 X-Google-Sender-Auth: Kg8tIK5wcIehrB1W2IKSJlYeJHU Message-ID: To: NTP Working Group , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7112691241450838308==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============7112691241450838308== Content-Type: multipart/alternative; boundary=001a114ccbd4546512052fc137f9 --001a114ccbd4546512052fc137f9 Content-Type: text/plain; charset=UTF-8 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 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 --001a114ccbd4546512052fc137f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All, just to summarize the conversation on meetcho just no= w. I think =C2=A0that this proposal would also solve the problem hashed IPv= 6 addresses colliding with IPv4 addresses on the same network, which is add= ressed in=C2=A0draft-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*. =C2=A0(Else, it = puts the "nonsense" value in the refID.) =C2=A0So even if a colli= sion happens, it should not matter, since the only party to see the collisi= on is the IP that sent the query.

Sharon

On Tue, Apr 5, 2016 a= t 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 t= he IETF'95 WG meeting just now. The current draft requires the use of a= n extension field.=C2=A0 I believe the goals of the draft can be accomplish= ed without using an extension field, in a backwards compatible fashion.

The goal of the draft is to limit the information exp= osed by the REFID while still preserving robustness to "length-1"= timing loops where system A takes time from system B, but system B takes t= ime from system A. =C2=A0
This proposal allow system A to limit t= he info it leaks in its refID, without harming any of its legacy clients.= =C2=A0

Suppose system A is taking time from system= B. Then there are two cases:
1) If A gets a time query from syst= em B, A puts the IP of B in the refID of its response. This way, even a leg= acy 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.=C2=A0 Even a legacy C can s= ee that its IP is not in the refID, and so it is allowed to take time from = A.=C2=A0

One question is what this "nonsense&= quot; value should be.=C2=A0 I think it should be a fixed value. For exampl= e 0.0.0.0.=C2=A0 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 Univ= ersity
http:/= /www.cs.bu.edu/~goldbe



--
Sharon = Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a114ccbd4546512052fc137f9-- --===============7112691241450838308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7112691241450838308==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 11:54:30 2016 Return-Path: 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 D478212D58B for ; Tue, 5 Apr 2016 11:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 SmOO4bHrd5Bg for ; Tue, 5 Apr 2016 11:54:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3F19512D7B7 for ; Tue, 5 Apr 2016 11:54:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id F38FB86DAEC for ; Tue, 5 Apr 2016 18:54:21 +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 C60DD86DAEC for ; Tue, 5 Apr 2016 18:49:12 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anW2B-000A6Y-Jq for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 18:49:12 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id u35ImwLP029890-u35ImwLR029890 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 20:48:58 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id B4BC6C6490; Tue, 5 Apr 2016 20:48:58 +0200 (CEST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: dieter.sibold@ptb.de To: Sharon Goldberg Message-ID: Date: Tue, 5 Apr 2016 20:48:57 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group Content-Type: multipart/mixed; boundary="===============0902297501482447011==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============0902297501482447011== Content-Type: multipart/alternative; boundary="=_alternative 00675C1FC1257F8C_=" --=_alternative 00675C1FC1257F8C_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The =C2=A0periodic server refresh have been introduced because of Sec 5.6.1= of RFC 7384. This already had been commented by Florian Weimar (if I remember the name c= orrectly). He suggested not to refresh the server seed during NTPD's operat= ion. The argument was, as far as I remember, that if the applied primitives= are sound a refresh of the underlying server seed will not necessary. At t= hat time we decided to stick with the periodic key refresh, mainly because = the requirement mentioned above. But yes, if we refrain from the periodic r= efresh we could merge the second and third round in the key exchange and ad= ditionally we would not have the situation that all clients need to refresh= their cookie because the server refreshed the server seed. But, of course,= we would need to explain why we neglect the must requirement in RFC 7384. Dieter -----"TICTOC" wrote: ----- >To: NTP Working Group , tictoc@ietf.org >From: Sharon Goldberg=20 >Sent by: "TICTOC"=20 >Date: 04/05/2016 18:40 >Subject: [TICTOC] WGLC on NTS: Server seed key refresh > >Just to follow up on my comment during the IETF'95 wg meeting right >now: =C2=A0NTS requires a server-seed refresh, and uses the 5th and 6th >message of the KE protocol to do this.=C2=A0 What is the use case for >server seed key refresh?=C2=A0 >Thanks,Sharon >--=20 >Sharon Goldberg >Computer Science, Boston University >http://www.cs.bu.edu/~goldbe > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >TICTOC mailing list >TICTOC@ietf.org >https://www.ietf.org/mailman/listinfo/tictoc > --=_alternative 00675C1FC1257F8C_= Content-Type: text/html; charset=UTF-8 Content-ID: <> Content-Transfer-Encoding: quoted-printable
The  periodic server refresh have been introduc= ed because of Sec 5.6.1 of RFC 7384.

This already had been commented by Florian Weimar (if I remember t= he name correctly). He suggested not to refresh the server seed during NTPD= 's operation. The argument was, as far as I remember, that if the applied p= rimitives are sound a refresh of the underlying server seed will not necess= ary. At that time we decided to stick with the periodic key refresh, mainly= because the requirement mentioned above. But yes, if we refrain from the p= eriodic refresh we could merge the second and third round in the key exchan= ge and additionally we would not have the situation that all clients need t= o refresh their cookie because the server refreshed the server seed. But, o= f course, we would need to explain why we neglect the must requirement in R= FC 7384.

Dieter





<= /div>
-----"TICTOC" <tictoc-= bounces@ietf.org> wrote: -----

=
>To: NTP Working Group <ntpwg@lists.ntp.or= g>, tictoc@ietf.org
>From: Sharon Goldb= erg
>Sent by: "TICTOC"
>Date: 04/05/2016 18:40
>S= ubject: [TICTOC] WGLC on NTS: Server seed key refresh
>
>Just to follow up on my c= omment during the IETF'95 wg meeting right
&g= t;now:  NTS requires a server-seed refresh, and uses the 5th and 6th
>message of the KE protocol to do this.&nbs= p; What is the use case for
>server seed k= ey refresh? 
>Thanks,Sharon
=
>--
>Sharon Goldb= erg
>Computer Science, Boston University
>http://www.cs.bu.edu/~goldbe
>
>=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>TICTOC mailing list
>TICTOC@ietf.o= rg
>https://www.ietf.org/mailman/listinfo/= tictoc
>
--=_alternative 00675C1FC1257F8C_=-- --===============0902297501482447011== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============0902297501482447011==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 12:24:18 2016 Return-Path: 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 7B42E12D7CA for ; Tue, 5 Apr 2016 12:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 GYLEUUbPH6i1 for ; Tue, 5 Apr 2016 12:24:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id BDD7212D798 for ; Tue, 5 Apr 2016 12:24:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B3DB286DBDB for ; Tue, 5 Apr 2016 19:24:16 +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 5325686DAEC for ; Tue, 5 Apr 2016 19:00:34 +0000 (UTC) Received: from chessie.everett.org ([66.220.13.234]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anWD9-000AKJ-DN for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 19:00:34 +0000 Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id 167D9B80E for ; Tue, 5 Apr 2016 19:00:22 +0000 (UTC) Received: from [10.2.64.150] (unknown [198.22.153.36]) by chessie.everett.org (Postfix) with ESMTPSA id 261CDB82B; Tue, 5 Apr 2016 19:00:21 +0000 (UTC) References: To: Sharon Goldberg , NTP Working Group , tictoc@ietf.org From: Danny Mayer Message-ID: <57040B4A.4090301@pdmconsulting.net> Date: Tue, 5 Apr 2016 15:00:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Apr 5 19:00:22 2016 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 6384,57040b46829932020613535 X-SA-Exim-Connect-IP: 66.220.13.234 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mayer@pdmconsulting.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mayer@pdmconsulting.net Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" On 4/5/2016 2:28 PM, Sharon Goldberg 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.=C2 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.= =C2 = > This proposal allow system A to limit the info it leaks in its refID, > without harming any of its legacy clients.=C2 = > = > 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.=C2 Even a legacy C can see that its IP is not in the refID, > and so it is allowed to take time from A.=C2 = > = > One question is what this "nonsense" value should be.=C2 I think it > should be a fixed value. For example 0.0.0.0.=C2 We would not want a > randomly-chosen value since this might collide with actual IP addresses > on the network. > = > Thanks, > Sharon The problem that I was alluding to in the jabber room is this. I'll keep the problem simple and to one example. A takes its time from B over an IPv4 address. A then gets a time query from C over IPv6. How does it know if B and C are the same system or different system? A has no information about that. Is this clearer? Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 12:24:32 2016 Return-Path: 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 8C1D812D798 for ; Tue, 5 Apr 2016 12:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 WeojUTW7vVkw for ; Tue, 5 Apr 2016 12:24:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9BE12D772 for ; Tue, 5 Apr 2016 12:24:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 04A7786DC7C for ; Tue, 5 Apr 2016 19:24:31 +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 4905C86DAEC for ; Tue, 5 Apr 2016 19:01:10 +0000 (UTC) Received: from chessie.everett.org ([2001:470:1:205::234]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anWDi-000AKQ-Qp for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 19:01:10 +0000 Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id 8A6F0B814 for ; Tue, 5 Apr 2016 19:00:58 +0000 (UTC) Received: from [10.2.64.150] (unknown [198.22.153.36]) by chessie.everett.org (Postfix) with ESMTPSA id 9656EB82B; Tue, 5 Apr 2016 19:00:56 +0000 (UTC) From: Danny Mayer References: To: Sharon Goldberg , NTP Working Group , tictoc@ietf.org Message-ID: <57040B6E.6070104@ntp.org> Date: Tue, 5 Apr 2016 15:01:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Apr 5 19:00:58 2016 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 6384,57040b6a829932195710061 X-SA-Exim-Connect-IP: 2001:470:1:205::234 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" On 4/5/2016 2:28 PM, Sharon Goldberg 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.=C2 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.= =C2 = > This proposal allow system A to limit the info it leaks in its refID, > without harming any of its legacy clients.=C2 = > = > 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.=C2 Even a legacy C can see that its IP is not in the refID, > and so it is allowed to take time from A.=C2 = > = > One question is what this "nonsense" value should be.=C2 I think it > should be a fixed value. For example 0.0.0.0.=C2 We would not want a > randomly-chosen value since this might collide with actual IP addresses > on the network. > = > Thanks, > Sharon The problem that I was alluding to in the jabber room is this. I'll keep the problem simple and to one example. A takes its time from B over an IPv4 address. A then gets a time query from C over IPv6. How does it know if B and C are the same system or different system? A has no information about that. Is this clearer? Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 12:39:20 2016 Return-Path: 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 21C1312D6EB for ; Tue, 5 Apr 2016 12:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 YbsoDDm6_MKX for ; Tue, 5 Apr 2016 12:39:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5C812D63B for ; Tue, 5 Apr 2016 12:39:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 1414286DBDF for ; Tue, 5 Apr 2016 19:39:17 +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 467E686DAEC for ; Tue, 5 Apr 2016 19:12:16 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1anWOe-0002gM-Gb; Tue, 05 Apr 2016 19:12:16 +0000 From: Harlan Stenn To: Sharon Goldberg In-reply-to: References: Comments: In-reply-to Sharon Goldberg message dated "Tue, 05 Apr 2016 14:28:07 -0400." 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: Tue, 05 Apr 2016 19:12:16 +0000 Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" Sharon Goldberg writes: > 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. I think your proposal will usually work. There is a potential problem in that A does not have complete information about what B and C are doing. It may be that B and C are effectively the same machine/source of time, and that B and C would look at the REFID returned by A and decide that there is a timing loop if A is getting its time from B and C (which is also effectively B) is considering using A for time. If we're going for a strictly clean paradigm here we need to note this. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 12:39:26 2016 Return-Path: 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 D689B12D5F5 for ; Tue, 5 Apr 2016 12:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 6Lij9awZ-0xT for ; Tue, 5 Apr 2016 12:39:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7333912D63B for ; Tue, 5 Apr 2016 12:39:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6DF2086DBF5 for ; Tue, 5 Apr 2016 19:39:22 +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 6E8C386DAEC for ; Tue, 5 Apr 2016 19:16:27 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1anWSg-0002gh-0L; Tue, 05 Apr 2016 19:16:26 +0000 From: Harlan Stenn To: dieter.sibold@ptb.de In-reply-to: References: Comments: In-reply-to dieter.sibold@ptb.de message dated "Tue, 05 Apr 2016 20:48:57 +0200." 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: Tue, 05 Apr 2016 19:16:25 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group 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" ntp associations can last for a very long time. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 12:39:34 2016 Return-Path: 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 00E9D12D5F5 for ; Tue, 5 Apr 2016 12:39:34 -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 fFziHoPC-3YD for ; Tue, 5 Apr 2016 12:39:29 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A212D63B for ; Tue, 5 Apr 2016 12:39:28 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 2640586DC49 for ; Tue, 5 Apr 2016 19:39:28 +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 7A74286DAEC for ; Tue, 5 Apr 2016 19:21:59 +0000 (UTC) Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anWY1-000AUq-57 for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 19:21:59 +0000 Received: by mail-wm0-x22b.google.com with SMTP id l6so36519136wml.1 for ; Tue, 05 Apr 2016 12:21:57 -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:cc; bh=9hleVfag85qhXGKAu3o7Qtdl2XTetRsfDp4W7I2eGDI=; b=Yeu5nX87HBFkP2NJdLs2DGHkliSm2FKcqk4gp8lrTefgp1Cx1s7sN+TlqVj5tOsLJF WPtjR/9hk9Hw0Ix5UFdAi7lTI050jE+azHRX+IA6G842GBFrufS8IXQuGtFB1l0Tubtl l38DlTJSKxA7VxO4BshxM9yW7Z8XCipKPDPNMOXcor+b0IwPqPHmV5uCI7teD174MHoU enSQvlUeKCcvQW6chBxsc00pDZ87q4zTzM848hvpI2+Eve1iLrgBspOBo2n0kRHP+msE gcYdz+OShjBWxq+u9XvIblnl46qce6XN5g3wnU+jl1mIvjY4IqT/a4I7ggyRnYjHbBV2 p3og== 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:cc; bh=9hleVfag85qhXGKAu3o7Qtdl2XTetRsfDp4W7I2eGDI=; b=CZrZkhEZYEmvRj9Y23SS1XCH451yheeS5WqLgEcsy+MpqheauWurhy1ASRyEeZcW28 MtHtsXb6+62yR69Gjc99JDIr7i26aqtwMx/+wtDicUCPNbIQGyhA2aDzna4q1fjJG4W2 0+WVIHUoGC/1pAfutpO5NO1OfvRGpmyHKDD2VW5DhkabDJ1/G4+xFJwv+Vk8Wulvni3r U8lkYGW81e3fTdZIURTibS+vpdBfhewLUPJIutp4m/3c38/gTSzPXCQh01WB8TRA/2j6 bPhMN9ZvOMxplmt2mM3/fnfBZYZrUbawrXeZMh7RbJUvqdYX9NWLOfVcwwH+prNdf/zO +HXg== X-Gm-Message-State: AD7BkJIU5L8OAdmnesyrnMkS5VJE9wRB+3RViRu2tPGi9HsZot4FNFanB5yA2IIlh+KKqXmfUhnBzbVRtCcIow== X-Received: by 10.194.178.233 with SMTP id db9mr7949956wjc.11.1459884115715; Tue, 05 Apr 2016 12:21:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Tue, 5 Apr 2016 12:21:16 -0700 (PDT) In-Reply-To: <57040B4A.4090301@pdmconsulting.net> References: <57040B4A.4090301@pdmconsulting.net> From: Sharon Goldberg Date: Tue, 5 Apr 2016 15:21:16 -0400 X-Google-Sender-Auth: QgRpElxPujsqj12odFgLdtL1RyU Message-ID: To: mayer@pdmconsulting.net X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::22b 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] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.org Content-Type: multipart/mixed; boundary="===============1401397743669271447==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============1401397743669271447== Content-Type: multipart/alternative; boundary=089e013d1a08216ac4052fc1c2b2 --089e013d1a08216ac4052fc1c2b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2016 at 3:00 PM, Danny Mayer wrote= : > On 4/5/2016 2:28 PM, Sharon Goldberg 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.=C3=82 I believe the goals of the draft can be accompl= ished > > 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. =C3=82 > > This proposal allow system A to limit the info it leaks in its refID, > > without harming any of its legacy clients.=C3=82 > > > > 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 refI= D > > 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.=C3=82 Even a legacy C can see that its IP is not in the ref= ID, > > and so it is allowed to take time from A.=C3=82 > > > > One question is what this "nonsense" value should be.=C3=82 I think it > > should be a fixed value. For example 0.0.0.0.=C3=82 We would not want = a > > randomly-chosen value since this might collide with actual IP addresses > > on the network. > > > > Thanks, > > Sharon > > The problem that I was alluding to in the jabber room is this. I'll keep > the problem simple and to one example. > > A takes its time from B over an IPv4 address. A then gets a time query > from C over IPv6. How does it know if B and C are the same system or > different system? A has no information about that. > > Is this clearer? > > Yes, it's clear. How does the current ntpd implementation deal with this problem? Sharon --=20 Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --089e013d1a08216ac4052fc1c2b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 5, 2016 at 3:00 PM, Danny Mayer <mayer@pdmconsulting.net= > wrote:
On 4/= 5/2016 2:28 PM, Sharon Goldberg 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.=C3=82=C2=A0 I believe the goals of the draft c= an be accomplished
> without using an extension field, in a backwards comp= atible 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. =C3=82
> This proposal allow system A to limit the info it lea= ks in its refID,
> without harming any of its legacy clients.=C3=82
>
> Suppose system A is taking time from system B. Then there are two case= s:
> 1) If A gets a time query from system B, A puts the IP of B in the ref= ID
> of its response. This way, even a legacy B can tell it cannot take tim= e
> 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.=C3=82=C2=A0 Even a legacy C can see that its IP is n= ot in the refID,
> and so it is allowed to take time from A.=C3=82
>
> One question is what this "nonsense" value should be.=C3=82= =C2=A0 I think it
> should be a fixed value. For example 0.0.0.0.=C3=82=C2=A0 We would not= want a
> randomly-chosen value since this might collide with a= ctual IP addresses
> on the network.
>
> Thanks,
> Sharon

The problem that I was alluding to in the jabber room is this. I'= ;ll keep
the problem simple and to one example.

A takes its time from B over an IPv4 address. A then gets a time query
from C over IPv6. How does it know if B and C are the same system or
different system? A has no information about that.

Is this clearer?

Yes, it's clear. How does the current ntpd = implementation deal with this problem? =C2=A0

= Sharon



--
Sharon Goldberg
Computer Science, Boston Universityhttp://www.cs.b= u.edu/~goldbe
--089e013d1a08216ac4052fc1c2b2-- --===============1401397743669271447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1401397743669271447==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 12:54:23 2016 Return-Path: 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 3E34C12D80F for ; Tue, 5 Apr 2016 12:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 SLZ6YDSn0-Iv for ; Tue, 5 Apr 2016 12:54:21 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 69CFD12D80B for ; Tue, 5 Apr 2016 12:54:21 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6198C86DC1B for ; Tue, 5 Apr 2016 19:54:21 +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 855C586D55E for ; Tue, 5 Apr 2016 19:27:55 +0000 (UTC) Received: from [198.22.153.36] (helo=[10.2.64.150]) by mail1.ntp.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anWdm-000AeB-AI; Tue, 05 Apr 2016 19:27:55 +0000 References: <57040B4A.4090301@pdmconsulting.net> To: Sharon Goldberg From: Danny Mayer Organization: NTP Message-ID: <570411C0.7000004@ntp.org> Date: Tue, 5 Apr 2016 15:28:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 198.22.153.36 X-SA-Exim-Rcpt-To: tictoc@ietf.org, ntpwg@lists.ntp.org, goldbe@cs.bu.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mayer@ntp.org Cc: NTP Working Group , tictoc@ietf.org Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" On 4/5/2016 3:21 PM, Sharon Goldberg wrote: > On Tue, Apr 5, 2016 at 3:00 PM, Danny Mayer > wrote: > = > On 4/5/2016 2:28 PM, Sharon Goldberg 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.=C3=82=C2 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 RE= FID > > 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. =C3=82 > > This proposal allow system A to limit the info it leaks in its refI= D, > > without harming any of its legacy clients.=C3=82 > > > > Suppose system A is taking time from system B. Then there are two c= ases: > > 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.=C3=82=C2 Even a legacy C can see that its IP is not in = the > refID, > > and so it is allowed to take time from A.=C3=82 > > > > One question is what this "nonsense" value should be.=C3=82=C2 I t= hink it > > should be a fixed value. For example 0.0.0.0.=C3=82=C2 We would no= t want a > > randomly-chosen value since this might collide with actual IP addre= sses > > on the network. > > > > Thanks, > > Sharon > = > The problem that I was alluding to in the jabber room is this. I'll k= eep > the problem simple and to one example. > = > A takes its time from B over an IPv4 address. A then gets a time query > from C over IPv6. How does it know if B and C are the same system or > different system? A has no information about that. > = > Is this clearer? > = > Yes, it's clear. How does the current ntpd implementation deal with this > problem? =C2 = > = Currently it doesn't. One of my proposals is for each system to generate a RefID and use that for all interfaces. I'm not sure if that works for all cases or causes other issues. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 13:24:18 2016 Return-Path: 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 A9A3812D844 for ; Tue, 5 Apr 2016 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 9JEwbo6prexT for ; Tue, 5 Apr 2016 13:24:17 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6D12D843 for ; Tue, 5 Apr 2016 13:24:17 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BFF3086DB84 for ; Tue, 5 Apr 2016 20:24:16 +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 99A5886D48C for ; Tue, 5 Apr 2016 20:19:44 +0000 (UTC) Received: from uillean.fuaim.com ([206.197.161.140]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anXRo-000BS6-5S for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 20:19:44 +0000 Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EEDAF880C7 for ; Tue, 5 Apr 2016 13:19:35 -0700 (PDT) Received: from dhcp-b17a.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:cc07:7adb:b61f:c8e2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 82E0A328081A for ; Tue, 5 Apr 2016 13:19:35 -0700 (PDT) To: ntpwg@lists.ntp.org From: Brian Haberman Message-ID: <57041DD0.3030402@innovationslab.net> Date: Tue, 5 Apr 2016 16:19:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 206.197.161.140 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: brian@innovationslab.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Leap seconds file X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1738655344249766157==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1738655344249766157== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="muPCFag8k1H9ickBnEdEKSVIQBJK93LvE" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --muPCFag8k1H9ickBnEdEKSVIQBJK93LvE Content-Type: multipart/mixed; boundary="hB84pq2KUUwCp1so0jBxFDPduNfQ5in1t" From: Brian Haberman To: ntpwg@lists.ntp.org Message-ID: <57041DD0.3030402@innovationslab.net> Subject: Leap seconds file --hB84pq2KUUwCp1so0jBxFDPduNfQ5in1t Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, During Denis' presentation today, there was a question about the validity of http://www.ietf.org/timezones/data/leap-seconds.list. It turns out that the info available in that file is pulled from the IANA timezone information found at http://www.iana.org/time-zones. The README states it is non-authoritative, but it appears to be as close to the authoritative information as I can find. Just passing info along... Brian --hB84pq2KUUwCp1so0jBxFDPduNfQ5in1t-- --muPCFag8k1H9ickBnEdEKSVIQBJK93LvE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXBB3VAAoJEBOZRqCi7goq2I0IAKwmSCfWFBMQu+TPOfOui+g6 hIS0txpmSK5NyZXH7vowmsWSBk0sE7YaHnl6xXxTzgNRKFzQANoTlXfMM2Vrw11x RXk2/AU8eTmfj1vYn1IShwKircifSolx/opUxxOOe4+E6qm4SnMXWOzWXwppHhLh VVyuMvxrEG/donY3cq7hOz4f3t2la88rxahpaUBkI4fqYB0sD4rlHK549zRsQdm2 mg10HJeO7/OzelUx3fmfSU0dvIIwAArXN38zSuxXeqSxQO7fkS+Hfx4viUzcJD9F DZIRFUZHrwzhZ69vdMRiSlIfBTgVjeUut2VDpOA9Bomdr6kXVQKRwVJT+NfHxn8= =hOcz -----END PGP SIGNATURE----- --muPCFag8k1H9ickBnEdEKSVIQBJK93LvE-- --===============1738655344249766157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1738655344249766157==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 14:10:40 2016 Return-Path: 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 A9C6E12D64E for ; Tue, 5 Apr 2016 14:10:40 -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 Xs5rHkv651t4 for ; Tue, 5 Apr 2016 14:10:38 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8912D519 for ; Tue, 5 Apr 2016 14:10:38 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 61F0E86DBCD for ; Tue, 5 Apr 2016 21:10:38 +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 6F7BA86DAD1 for ; Tue, 5 Apr 2016 20:55:00 +0000 (UTC) Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anY02-000C2U-UB for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 20:55:00 +0000 Received: by mail-wm0-x22e.google.com with SMTP id u206so19808637wme.1 for ; Tue, 05 Apr 2016 13:54:58 -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:cc; bh=klaq/yRkt2DLZEm233NvVly7pKO8XhOKtmMdPBO5zBY=; b=ZqfaASDonfx01f5Ip54nJCPjwP7S9vA/vTGGoC5SYDZnNt/FJIkzU4KalZ1lGxD3MX /mjgc+yPyzAyoNuQv4KekpL8fB8ONrIyeF/QWfQylP9vRZTX8z22VxxH44n+UWcU4rBn 6/HDsf3rZa9I3jDlAskGz2Cn9UrzKl2xjGtIFxtN/HqhZ2cQedeFddBSlZIvDApwl+MG m88/UBRiFgfKnXoZuQao9ZOTXcfiDKZ9pkaXH8XC0VghaIPiPukI53UnC8pe/KBktkL7 ToW6siua+5ypWeF1MIHEoEKMieTikIcimvJS9XhcUqZaI6Ju5s7Hn6uXOHMffkhECJq+ xtVw== 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:cc; bh=klaq/yRkt2DLZEm233NvVly7pKO8XhOKtmMdPBO5zBY=; b=hQlVVytc0JvHfbL+OECNNSOy2dNDmRW6nX4ijdAp9rrTzNboktoKeckRqXFi1WZBBb uasQu33UHq9M20OoxUBvGemmTFgmrMI78c9ebdazG07cfr12gHg8ZSqRLslpB7+nFSfO xT2f0QD1nXQ7SSxsYwmNrpUnv/98ppSw2HY1Uj0wjCh5x+DzOojSANsrfqRONQa+eJfu skjIxpbA9ZeUwQQHO2DBbuqqUxol/YgclzEMzw6JQbrkQBk2ttJBVEXVQ4lO96hPaes7 oIU+rj2yRwCX5jv1uj2k9mWHTOyohoILeRua6qvc4jxO6DQz8ozpLW9UzvbNbPPEG3na 5cVA== X-Gm-Message-State: AD7BkJJXEkNRm1PEYdNVw1SlXjKBnIY8PLS1bhbdd1Y0KnC5gOpS+PLp9Eam8F5JpHfaI9FTWrHMLufInRjyEQ== X-Received: by 10.28.60.197 with SMTP id j188mr10497047wma.68.1459889697424; Tue, 05 Apr 2016 13:54:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Tue, 5 Apr 2016 13:54:17 -0700 (PDT) In-Reply-To: <570411C0.7000004@ntp.org> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> From: Sharon Goldberg Date: Tue, 5 Apr 2016 16:54:17 -0400 X-Google-Sender-Auth: ouBxwbUZh5kgTYsDCY2JpF8KUPg Message-ID: To: "Danny Mayer (mayer@ntp.org)" X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::22e 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] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.org Content-Type: multipart/mixed; boundary="===============2283282513139232552==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============2283282513139232552== Content-Type: multipart/alternative; boundary=001a1148f200d3bc85052fc30e3b --001a1148f200d3bc85052fc30e3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > The problem that I was alluding to in the jabber room is this. I'll > keep > > the problem simple and to one example. > > > > A takes its time from B over an IPv4 address. A then gets a time > query > > from C over IPv6. How does it know if B and C are the same system o= r > > different system? A has no information about that. > > > > Is this clearer? > > > > Yes, it's clear. How does the current ntpd implementation deal with thi= s > > problem? =C3=82 > > > > Currently it doesn't. One of my proposals is for each system to generate > a RefID and use that for all interfaces. I'm not sure if that works for > all cases or causes other issues. > OK. To clarify: you are proposing an extension to NTP where a server that has multiple IP addresses can choose a special value as its refID, and communicate that to its clients. Then, if the clients choose to take time from that server, they put that special value in as their refID, instead of an IP address. AFAIK this functionality is not part of NTP today, right? It would probably require an extension field? Also its not backwards compatible, since a server that chooses to do this would need to make sure that its clients understand what it is doing. And currently clients don't know how to do this, right? Please clarify if I have misunderstood. --=20 Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a1148f200d3bc85052fc30e3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0 =C2=A0 =C2=A0The pro= blem that I was alluding to in the jabber room is this. I'll keep
>=C2=A0 =C2=A0 =C2=A0the problem simple and to one example.
>
>=C2=A0 =C2=A0 =C2=A0A takes its time from B over an IPv4 address. A the= n gets a time query
>=C2=A0 =C2=A0 =C2=A0from C over IPv6. How does it know if B and C are t= he same system or
>=C2=A0 =C2=A0 =C2=A0different system? A has no information about that.<= br> >
>=C2=A0 =C2=A0 =C2=A0Is this clearer?
>
> Yes, it's clear. How does the current ntpd implementation deal wit= h this
> problem? =C3=82
>

Currently it doesn't. One of my proposals is for each system to generat= e
a RefID and use that for all interfaces. I'm not sure if that works for=
all cases or causes other issues.

OK. T= o clarify: you are proposing an extension to NTP where a server that has mu= ltiple IP addresses can choose a special value as its refID, and communicat= e that to its clients.=C2=A0 Then, if the clients choose to take time from = that server, they put that special value in as their refID, instead of an I= P address.

AFAIK this functionality is not part of= NTP today, right? It would probably require an extension field? Also its n= ot backwards compatible, since a server that chooses to do this would need = to make sure that its clients understand what it is doing. And currently cl= ients don't know how to do this, right?

= Please clarify if I have misunderstood.

--
Sharon Goldberg
Computer Science, Boston Universi= ty
http://www= .cs.bu.edu/~goldbe
--001a1148f200d3bc85052fc30e3b-- --===============2283282513139232552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============2283282513139232552==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 14:25:37 2016 Return-Path: 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 6DD6212DA2C for ; Tue, 5 Apr 2016 14:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1024-bit key) reason="fail (message has been altered)" header.d=maths.tcd.ie 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 V3vmZsBzB8t5 for ; Tue, 5 Apr 2016 14:25:34 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1D912DA2F for ; Tue, 5 Apr 2016 14:25:34 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 9A3DD86DC14 for ; Tue, 5 Apr 2016 21:25:34 +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 E5E3586DAD1 for ; Tue, 5 Apr 2016 20:59:42 +0000 (UTC) Received: from salmon.maths.tcd.ie ([2001:770:10:300::86e2:510b]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anY4a-000C5A-Ri for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 20:59:42 +0000 Received: from salmon.maths.tcd.ie (localhost [127.0.0.1]) by salmon.maths.tcd.ie (Postfix) with ESMTP id 1F9FC1591B1; Tue, 5 Apr 2016 21:59:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=maths.tcd.ie; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received:received; s=20150418; t= 1459889968; x=1461704369; bh=VInhm0/KAYVKF6ps4/CJl+YBY4tTL7Vy4So Z1k6l5KI=; b=l/UDjmwFPxI3Pw76zvjHvr4DcCxo+zPEukx0o0MDsAUMXYu22Pp /1p2KXA169QYe3VOwoKukN5oCWmV23onvd/xeLG1NuZGcF44m/xUYav+665xa/F2 s4Zj0+VmDbGDp6TVWaBXBtQOaABgsS1osigvq9KWtib0rQ0Q9I2xxzKc= X-Virus-Scanned: amavisd-new at maths.tcd.ie Received: from salmon.maths.tcd.ie ([127.0.0.1]) by salmon.maths.tcd.ie (salmon.maths.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Wr24G3E37Zv; Tue, 5 Apr 2016 21:59:28 +0100 (IST) Received: from smtp.maths.tcd.ie (walton.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510a]) by salmon.maths.tcd.ie (Postfix) with ESMTP id 2CC231591C5; Tue, 5 Apr 2016 21:59:28 +0100 (IST) Received: by smtp.maths.tcd.ie (Postfix, from userid 238) id A8B047309C; Tue, 5 Apr 2016 21:59:27 +0100 (IST) Date: Tue, 5 Apr 2016 21:59:27 +0100 From: David Malone To: Brian Haberman Message-ID: <20160405205927.GA99384@walton.maths.tcd.ie> References: <57041DD0.3030402@innovationslab.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <57041DD0.3030402@innovationslab.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2001:770:10:300::86e2:510b X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dwmalone@maths.tcd.ie X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Leap seconds file X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Tue, Apr 05, 2016 at 04:19:28PM -0400, Brian Haberman wrote: > During Denis' presentation today, there was a question about the > validity of http://www.ietf.org/timezones/data/leap-seconds.list. It > turns out that the info available in that file is pulled from the IANA > timezone information found at http://www.iana.org/time-zones. The README > states it is non-authoritative, but it appears to be as close to the > authoritative information as I can find. There seem to be a few people providing leap seconds information in this format at the moment: https://www.ietf.org/timezones/data/leap-seconds.list ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list ftp://time.nist.gov/pub/leap-seconds.list https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list I guess technically, it is probably the IERS who are making the decision about when leap seconds are, but I think they are relatively new to the game of providing a file for ntp. If anyone is interested, I've written up some of my measurements of the NTP network's behaviour during leap seconds, which includes some comments on the leap second file: http://www.maths.tcd.ie/~dwmalone/p/tma2016.pdf David. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 14:40:23 2016 Return-Path: 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 3782C12D8AF for ; Tue, 5 Apr 2016 14:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 WxYvdyfifU-w for ; Tue, 5 Apr 2016 14:40:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9512D8AB for ; Tue, 5 Apr 2016 14:40:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id F0B0786DBEC for ; Tue, 5 Apr 2016 21:40:21 +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 3EDBE86DAEF for ; Tue, 5 Apr 2016 21:16:52 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1anYIm-0002p4-59; Tue, 05 Apr 2016 21:14:20 +0000 From: Harlan Stenn To: mayer@ntp.org In-reply-to: <570411C0.7000004@ntp.org> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> Comments: In-reply-to Danny Mayer message dated "Tue, 05 Apr 2016 15:28:00 -0400." 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: Tue, 05 Apr 2016 21:14:20 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" Danny Mayer writes: > On 4/5/2016 3:21 PM, Sharon Goldberg wrote: > > On Tue, Apr 5, 2016 at 3:00 PM, Danny Mayer > > wrote: > > = > > > On 4/5/2016 2:28 PM, Sharon Goldberg 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.=C3=82=C2 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 RE= > FID > > > 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. =C3=82 > > > This proposal allow system A to limit the info it leaks in its refI= > D, > > > without harming any of its legacy clients.=C3=82 > > > > > > Suppose system A is taking time from system B. Then there are two c= > ases: > > > 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.=C3=82=C2 Even a legacy C can see that its IP is not in = > the > > refID, > > > and so it is allowed to take time from A.=C3=82 > > > > > > One question is what this "nonsense" value should be.=C3=82=C2 I t= > hink it > > > should be a fixed value. For example 0.0.0.0.=C3=82=C2 We would no= > t want a > > > randomly-chosen value since this might collide with actual IP addre= > sses > > > on the network. > > > > > > Thanks, > > > Sharon > > = > > > The problem that I was alluding to in the jabber room is this. I'll k= > eep > > the problem simple and to one example. > > = > > > A takes its time from B over an IPv4 address. A then gets a time query > > from C over IPv6. How does it know if B and C are the same system or > > different system? A has no information about that. > > = > > > Is this clearer? > > = > > > Yes, it's clear. How does the current ntpd implementation deal with this > > problem? =C2 = > > > = > > Currently it doesn't. One of my proposals is for each system to generate > a RefID and use that for all interfaces. I'm not sure if that works for > all cases or causes other issues. It *hasn't* been an issue. It would be easy enough to address it if somebody felt there was a need to, however. The point is that with your proposal, Sharon, I'm not seeing that it is possible to address this case. That is separate from whether or not it's a problem that needs to be addressed, now or in the "near" future. It's clear that if A has multiple IPs on it (very common now, not common 20 years' ago) that A could check all of its IPs when it saw B's refid and decide if any of them meant B was sync'd to A. In reality, we have only seen that if A sends a packet to B, B responds to that same address on that same IP. We have had cases where that response has come over a different interface. There are other possiblities, though. Here are more scenarios. A VM host maintains the primary clock, and "guests" use that clock. In this case, if A and B are on the same VM host, their underlying system clock is actually the same one. And that assumes one (common) scenario - the VMs are likely set up so that all the VMs have tightly-synchronized time. There's another use case I've been looking for - a VM setup where I can configure each VM to have a clock that behaves independently, so I can test wider behaviors more easily. Is it sufficient to check for loops of degree 1? Exactly what problems are we solving here? What about the situation where a single refclock is directly feeding multiple servers? If A and B are getting their time from the same refclock, should that mean A and B should not fall back on each other if one of them loses signal to their shared refclock? If A and B are talking to the same type of refclock is that something that should be addressed? There have been cases where broken firmware has caused a family of refclocks to all take simultaneous leaps to the same spot in the weeds. If A and B are both using GPS (for example) and there is a system glitch where GPS time is affected, is that also a timing loop that we'd want to avoid? This happened in Jan 2016. What about a group of systems that share a PPS signal? The PPS signal might become untrustworthy, or the "source of numbered seconds" might break. Many of these issues are currently(!) insignificant in a LAN setting where we're looking at timing/frequency sync to around the millisecond level (roughly). I don't *know*, but I'd bet they are significant when trying to get to the microsecond level, let alone the nanosecond level. Hello PTP. Hello RADclock and the work PHK is doing with the algorithms he's using on Ntimed. Once we learn more about these, we need to make sure these different choices will "play nice" with each other. Similarly, chrony uses algorithms that are slightly different from the ones NTP uses. We haven't seen studies of any potential loop instabilities between these two approaches, either. I mention this because 20 years' ago we thought we were doing well getting clocks to sync to within a tenth of a second. Now, getting sub-millisecond sync on a LAN is common. I've spoken with folks who told me that with some care and support, they are getting sync levels with NTP that are very close to what they get with PTP - down to the range of nanoseconds. Where will we be 10 years' time from now? I recall PHK saying that with PTP (or PTP-like stuff), he was able to get offset and frequency sync on cold start in less than a second. He was doing this with a poll interval of about -9, or about 500 polls/second. I know DLM was solving a real and evidenced problem with the refid and loop detection. It's looking like we need to take a stronger look at this to decide if those problems are still significant, and if different problems are becoming significant. -- Harlan Stenn http://networktimefoundation.org - be a member! _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 14:40:37 2016 Return-Path: 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 652AF12D8A5 for ; Tue, 5 Apr 2016 14:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 fnZatAYSD7YR for ; Tue, 5 Apr 2016 14:40:27 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id BF55112D8AF for ; Tue, 5 Apr 2016 14:40:27 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 9AF2986DC02 for ; Tue, 5 Apr 2016 21:40:27 +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 D0D8B86DAEF for ; Tue, 5 Apr 2016 21:19:58 +0000 (UTC) Received: from mail137c25.carrierzone.com ([64.29.147.207] helo=mail26c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anYO5-000CNX-Eu for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 21:19:58 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail26c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u35LJkp4020122 for ; Tue, 5 Apr 2016 21:19:47 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 0076E406057; Tue, 5 Apr 2016 14:19:45 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: NTP Working Group From: Hal Murray Mime-Version: 1.0 Date: Tue, 05 Apr 2016 14:19:45 -0700 Message-Id: <20160405211946.0076E406057@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=duLiVTQ4 c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=0fTvZqz43H84IsveLiUA:9 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A010203.57042BF4.0025, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.207 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Hal Murray 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" dieter.sibold@ptb.de said: > But yes, if we refrain from the periodic refresh we could merge the second > and third round in the key exchange and additionally we would not have the > situation that all clients need to refresh > their cookie because the server refreshed the server seed. But, of course, > we would need to explain why we neglect the must requirement in RFC 7384. Would it simplify the description and/or implementation if things were collapsed to two rounds? Both the server and client can get rebooted at any time. So either side can force a rekey by starting over. If the server is going to have performance problems with rekeying, it will have the same sort of problem when it gets rebooted. (Maybe worse since all the buggy implementations with short retransmission timeouts will be banging away.) -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 14:56:55 2016 Return-Path: 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 D487112D78F for ; Tue, 5 Apr 2016 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 2Iop0xXRnY3T for ; Tue, 5 Apr 2016 14:56:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 30BBD12D556 for ; Tue, 5 Apr 2016 14:56:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 0E71A86DC27 for ; Tue, 5 Apr 2016 21:56:52 +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 7731586DAEF for ; Tue, 5 Apr 2016 21:36:27 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1anYbk-0002qu-8u; Tue, 05 Apr 2016 21:33:56 +0000 From: Harlan Stenn To: Sharon Goldberg In-reply-to: References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> Comments: In-reply-to Sharon Goldberg message dated "Tue, 05 Apr 2016 16:54:17 -0400." 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: Tue, 05 Apr 2016 21:33:56 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" Sharon Goldberg writes: >>> The problem that I was alluding to in the jabber room is >>> >>> this. I'll keep the problem simple and to one example. >>> >>> A takes its time from B over an IPv4 address. A then gets a time >>> query from C over IPv6. How does it know if B and C are the same >>> system or different system? A has no information about that. >>> >>> Is this clearer? >>> >>> Yes, it's clear. How does the current ntpd implementation deal with this >>> problem? >> >> Currently it doesn't. One of my proposals is for each system to >> generate a RefID and use that for all interfaces. I'm not sure if >> that works for all cases or causes other issues. > > OK. To clarify: you are proposing an extension to NTP where a server > that has multiple IP addresses can choose a special value as its > refID, and communicate that to its clients. Then, if the clients > choose to take time from that server, they put that special value in > as their refID, instead of an IP address. My proposal for SUGGEST-REFID is simply a mechanism for an NTP instance to tell others "If you use me as your system peer, please use as your refid." If a server chooses to suggest a single nonce for all of its interfaces as its suggested refid, great. If it chooses to use that same nonce for all of its associations, that's great too. For me, we're now in the realm of "policy", and there are tradeoffs there. My goal was to provide a robust mechanism to allow for these policy choices. > AFAIK this functionality is not part of NTP today, right? It would > probably require an extension field? Also its not backwards > compatible, since a server that chooses to do this would need to make > sure that its clients understand what it is doing. And currently > clients don't know how to do this, right? Danny's (policy) proposal would most likely be implemented using the suggest-refid EF proposal I made, so: Yes, an EF Nobody is doing this yet, unless somebody has implemented my proposal and not told me. As for backward compatibility, that's not really an issue. An old server will not understand the EF so it will use the current rules for choosing its refid when selecting its system peer. This is what I talked about in my first "set", covering the I-Do and Last-EF proposals. If I send you packets with I-Do and get back a plain response, I know you can't or aren't willing to do these newer choices. Either way, I need to be prepared to check the legacy and suggested refid choices in responses I get from you. If I send you an I-Do and get *no* response, then I don't know if you never got my packet or you got it and dropped it because it had an unrecognized EF in it. Eventually I would just send plain packets. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 17:11:49 2016 Return-Path: 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 5FEC812D121 for ; Tue, 5 Apr 2016 17:11:49 -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=bsdimp-com.20150623.gappssmtp.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 BXw82YGenWUg for ; Tue, 5 Apr 2016 17:11:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id BA51C12D61F for ; Tue, 5 Apr 2016 17:11:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A707086DBE4 for ; Wed, 6 Apr 2016 00:11:44 +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 AA36B86DB52 for ; Tue, 5 Apr 2016 23:48:24 +0000 (UTC) Received: from mail-io0-x236.google.com ([2607:f8b0:4001:c06::236]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anahl-000EYt-05 for ntpwg@lists.ntp.org; Tue, 05 Apr 2016 23:48:24 +0000 Received: by mail-io0-x236.google.com with SMTP id q128so37588075iof.3 for ; Tue, 05 Apr 2016 16:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=hPRIdfBI4ICgEdDN2vxl2NNE3uqj20FdWFyipLDyTIU=; b=RHE0J6q8l3k6hit49IitxpMUFeGNBN35q8wf8DlE+qaSADylYDQTfy4WaOpFePl5gR TE65H8tPzF+QITq2z/NA1ImhsvJXUP596tYjGCURamK1jjrR4AToizDzxvN/puEZlkFe tZBXeomDDpTK8JuX/CHYsiqt3zZOMnhpWCwz4wUUPTIMuE9mTIxdslcUzGS0OsJiNptm CHYHl7JQfj82AjcJ7/AjIHqFN0WPvWHp1E6ORoKZB/cUAF/66lTLneZeKKrE1a/Q7Y+E AWTKxzfKRjJXtnlQKw7wxBXbfEYk06VA5DbjaAexPi3DUmBglQdO9Uh6WlzSC6Vgi4/Y RkPg== 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:date :message-id:subject:from:to:cc; bh=hPRIdfBI4ICgEdDN2vxl2NNE3uqj20FdWFyipLDyTIU=; b=IIJIQDL978PiPeKzkzgY8GzpeH5KXB/m/xvYRd8ArgYMZBIjVImVWQQKCH0i+a4RQK wUhiBE3jiIa84UElbu7JI2pF7/ln36lRiMWB3+dekrwZMXWJObTJQLG2OschSv6qiX6k saYgCF6qYIQ1BxcqykIebIZ0slMH++SWcMHfver7qMubAspgDKk1LM1yDg6KlYdRnYFu turEig10k0h71mjc+2Dj5xyUHFyU0LqogfWg+8lJs7lH1ISqfA/u9+enrDrBiU6AMP14 WW+ErkQrfbXuj8qRPor+QiCIRQhJMe7/i970iAzQSZNCxbwLVfhJZWhT8g6fAhbyz5eM /Iuw== X-Gm-Message-State: AD7BkJJ1eQd/N5GhlrtCHSx4qrJwj5IzOmtjpgfvnSVpA3tpqw171nkEGj4YawT9uVvN4vvLiwUkm+gbQsQMDg== MIME-Version: 1.0 X-Received: by 10.107.14.209 with SMTP id 200mr16334709ioo.73.1459900095818; Tue, 05 Apr 2016 16:48:15 -0700 (PDT) Received: by 10.36.194.3 with HTTP; Tue, 5 Apr 2016 16:48:15 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160405205927.GA99384@walton.maths.tcd.ie> References: <57041DD0.3030402@innovationslab.net> <20160405205927.GA99384@walton.maths.tcd.ie> Date: Tue, 5 Apr 2016 17:48:15 -0600 X-Google-Sender-Auth: 6dwtnzgzaSPwFqY-xJPgNMftAR8 Message-ID: From: Warner Losh To: David Malone X-SA-Exim-Connect-IP: 2607:f8b0:4001:c06::236 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: wlosh@bsdimp.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Leap seconds file X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group Content-Type: multipart/mixed; boundary="===============6275150071027680472==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============6275150071027680472== Content-Type: multipart/alternative; boundary=001a113fad2e9e84cc052fc57a78 --001a113fad2e9e84cc052fc57a78 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 5, 2016 at 2:59 PM, David Malone wrote: > On Tue, Apr 05, 2016 at 04:19:28PM -0400, Brian Haberman wrote: > > During Denis' presentation today, there was a question about the > > validity of http://www.ietf.org/timezones/data/leap-seconds.list. It > > turns out that the info available in that file is pulled from the IANA > > timezone information found at http://www.iana.org/time-zones. The README > > states it is non-authoritative, but it appears to be as close to the > > authoritative information as I can find. > > There seem to be a few people providing leap seconds information > in this format at the moment: > > https://www.ietf.org/timezones/data/leap-seconds.list > ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list > ftp://time.nist.gov/pub/leap-seconds.list > https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list > > I guess technically, it is probably the IERS who are making the > decision about when leap seconds are, but I think they are relatively > new to the game of providing a file for ntp. > IETF is relatively a newbee too at providing this file. USNO has been providing this info for a while now, but in different formats. NIST has been doing in this format for at least two decades, but that's just because Judah's Lavine is there and his keen interest in ntpd. It's the canonical source of the file, even if IERS is the canonical source of the data used to generate the file. This distinction a relic of the days when Bulletin C received by people who had to do things based on it. :) Warner --001a113fad2e9e84cc052fc57a78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 2:59 PM, David Malone <dwmalone@maths.tcd.i= e> wrote:
= On Tue, Apr 05, 2016 at 04:19:28PM -0400, Brian Haberman wrote:
>=C2=A0 =C2=A0 =C2=A0 During Denis' presentation today, there was a = question about the
> validity of http://www.ietf.org/timezones/d= ata/leap-seconds.list. It
> turns out that the info available in that file is pulled from the IANA=
> timezone information found at http://www.iana.org/time-zones.= The README
> states it is non-authoritative, but it appears to be as close to the > authoritative information as I can find.

There seem to be a few people providing leap seconds information
in this format at the moment:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.or= g/timezones/data/leap-seconds.list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ftp://tycho.usno.navy= .mil/pub/ntp/leap-seconds.list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ftp://time.nist.gov/pub/leap-se= conds.list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://hpier= s.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

I guess technically, it is probably the IERS who are making the
decision about when leap seconds are, but I think they are relatively
new to the game of providing a file for ntp.

IETF is relatively a newbee too at providing this file. USNO has been=
providing this info for a while now, but in different formats. N= IST has
been doing in this format for at least two decades, but t= hat's just because
Judah's Lavine is there and his keen i= nterest in ntpd. It's the canonical
source of the file, even = if IERS is the canonical source of the data used
to generate the = file. This distinction a relic of the days when Bulletin C
receiv= ed by people who had to do things based on it. :)

= Warner
--001a113fad2e9e84cc052fc57a78-- --===============6275150071027680472== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============6275150071027680472==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 19:27:03 2016 Return-Path: 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 4B56612D172 for ; Tue, 5 Apr 2016 19:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 oqXwaG_Ihm8h for ; Tue, 5 Apr 2016 19:27:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id ACB6B12D0D9 for ; Tue, 5 Apr 2016 19:27:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A2D6E86DBEB for ; Wed, 6 Apr 2016 02:27:01 +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 F252C86DB3B for ; Wed, 6 Apr 2016 02:02:11 +0000 (UTC) Received: from pool-71-174-223-70.bstnma.east.verizon.net ([71.174.223.70] helo=[10.10.10.102]) by mail1.ntp.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ancnJ-000Gge-Hi; Wed, 06 Apr 2016 02:02:10 +0000 References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> To: Sharon Goldberg From: Danny Mayer Organization: NTP Message-ID: <57046E26.2050705@ntp.org> Date: Tue, 5 Apr 2016 22:02:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 71.174.223.70 X-SA-Exim-Rcpt-To: tictoc@ietf.org, ntpwg@lists.ntp.org, goldbe@cs.bu.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mayer@ntp.org Cc: NTP Working Group , tictoc@ietf.org Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" On 4/5/2016 4:54 PM, Sharon Goldberg wrote: > >=C2 =C2 =C2 The problem that I was alluding to in the jabber room = is this. I'll keep > >=C2 =C2 =C2 the problem simple and to one example. > > > >=C2 =C2 =C2 A takes its time from B over an IPv4 address. A then g= ets a time query > >=C2 =C2 =C2 from C over IPv6. How does it know if B and C are the = same system or > >=C2 =C2 =C2 different system? A has no information about that. > > > >=C2 =C2 =C2 Is this clearer? > > > > Yes, it's clear. How does the current ntpd implementation deal with= this > > problem? =C3=82 > > > = > Currently it doesn't. One of my proposals is for each system to gener= ate > a RefID and use that for all interfaces. I'm not sure if that works f= or > all cases or causes other issues. > = > = > OK. To clarify: you are proposing an extension to NTP where a server > that has multiple IP addresses can choose a special value as its refID, > and communicate that to its clients.=C2 Then, if the clients choose to > take time from that server, they put that special value in as their > refID, instead of an IP address. > = > AFAIK this functionality is not part of NTP today, right? It would > probably require an extension field? Also its not backwards compatible, > since a server that chooses to do this would need to make sure that its > clients understand what it is doing. And currently clients don't know > how to do this, right? > = > Please clarify if I have misunderstood. You did misunderstand. I said the Refid itself and not an extension field so it would be interoperable. I'm of the opinion that a server should only have one refid for all interfaces no matter which one is being used to send the packet. I recall that there is an issue that Harlan had to explain to me in excruciating detail as to why the existing refid is the way it is today but I don't recall now the details. We already have a problem where the hash of the IPv6 address can conflict with a real IPv4 address. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 21:27:41 2016 Return-Path: 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 7D51E12D099 for ; Tue, 5 Apr 2016 21:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 2O5xfU2kPHpz for ; Tue, 5 Apr 2016 21:27:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 063D212D507 for ; Tue, 5 Apr 2016 21:27:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B548486DBD2 for ; Wed, 6 Apr 2016 04:27:39 +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 933A486D77E for ; Wed, 6 Apr 2016 03:58:57 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1aneZs-0003LS-ST; Wed, 06 Apr 2016 03:56:24 +0000 From: Harlan Stenn To: mayer@ntp.org In-reply-to: <57046E26.2050705@ntp.org> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <57046E26.2050705@ntp.org> Comments: In-reply-to Danny Mayer message dated "Tue, 05 Apr 2016 22:02:14 -0400." 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: Wed, 06 Apr 2016 03:56:24 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" Danny Mayer writes: > You did misunderstand. I said the Refid itself and not an extension > field so it would be interoperable. I'm of the opinion that a server > should only have one refid for all interfaces no matter which one is > being used to send the packet. I recall that there is an issue that > Harlan had to explain to me in excruciating detail as to why the > existing refid is the way it is today but I don't recall now the > details. We already have a problem where the hash of the IPv6 address > can conflict with a real IPv4 address. If that would be your policy then the way to implement it is with the suggest-refid EF proposal I submitted. The legacy behavior is that "For S2+, I use the IPv4 (or partial hash of the IPv6) address of my system peer as the refid." If this situation is not clearly described in my proposal please show where that information could be improved. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 23:21:38 2016 Return-Path: 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 5725012D11C for ; Tue, 5 Apr 2016 23:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 oZm1YaGU84iB for ; Tue, 5 Apr 2016 23:21:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1A64B12D6D2 for ; Tue, 5 Apr 2016 23:21:35 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id CC75E86DC29 for ; Wed, 6 Apr 2016 06:21:34 +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 9F31B86D9B2 for ; Wed, 6 Apr 2016 04:26:18 +0000 (UTC) Received: from cyrus.watson.org ([198.74.231.69]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anf2f-000JJr-Kr for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 04:26:18 +0000 Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 8BDC246B1A; Wed, 6 Apr 2016 00:26:07 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.15.2/8.15.2) with ESMTP id u364Q72J055173; Wed, 6 Apr 2016 00:26:07 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.15.2/8.15.2/Submit) with ESMTP id u364Q69f055170; Wed, 6 Apr 2016 00:26:07 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 6 Apr 2016 00:26:06 -0400 (EDT) From: Samuel Weiler To: Danny Mayer In-Reply-To: <56F98E6B.1000805@ntp.org> Message-ID: References: <56F98E6B.1000805@ntp.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Wed, 06 Apr 2016 00:26:07 -0400 (EDT) X-SA-Exim-Connect-IP: 198.74.231.69 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: weiler@watson.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Wed, 06 Apr 2016 06:11:29 +0000 Subject: Re: [ntpwg] Cipher suites for NTS? X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org, "tictoc@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" On Mon, 28 Mar 2016, Danny Mayer wrote: > We have to be careful here. I agree that at least some cipher suites > should be specified as a minimal subset in the draft but we also > need flexibility as new ciphers come out and older ones are found to > be vunerable. Otherwise we will need to create new RFC's to update > the RFC for either of these scenarios. We should pick a cipher suite. Absent a compelling reason for more, let's just pick one (for now). And we do need to provide for algorithm agility. Unfortunately, that is much trickier than merely parameterizing ciphers - we also need to understand the negotiation of cipher suites and prevent downgrade attacks. Here's some discussion on the topic: https://tools.ietf.org/html/rfc7696 For good or ill, other negotiations (e.g. NTS version number) may also provide opportunities for downgrade. Which means we may be also to address multiple vulnerabilities at once. One step toward addressing all of this might be to extend the ntp client config file to include a bit for "this name server is expected to use NTS (version #blah)". Perhaps cipher suite info could be in the same config file or in the server's certs? Lastly, do not be afraid to roll a new RFC to introduce a new algorithm. While it makes sense to have an IANA registry for cipher suites, "standards action" might be a good choice of policy to add a new entry into that registry. -- Sam _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 5 23:21:47 2016 Return-Path: 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 D680E12D0CF for ; Tue, 5 Apr 2016 23:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 CVAKTwHqvQSB for ; Tue, 5 Apr 2016 23:21:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 55D6912D11C for ; Tue, 5 Apr 2016 23:21:43 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 50FE686DCAC for ; Wed, 6 Apr 2016 06:21:43 +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 7A34F86D9B2 for ; Wed, 6 Apr 2016 04:32:19 +0000 (UTC) Received: from cyrus.watson.org ([198.74.231.69]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anf8S-000JSC-D3 for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 04:32:19 +0000 Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 0FFC646B4C for ; Wed, 6 Apr 2016 00:32:08 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.15.2/8.15.2) with ESMTP id u364W7ZC055592 for ; Wed, 6 Apr 2016 00:32:07 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.15.2/8.15.2/Submit) with ESMTP id u364W7IK055589 for ; Wed, 6 Apr 2016 00:32:07 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 6 Apr 2016 00:32:07 -0400 (EDT) From: Samuel Weiler To: "ntpwg@lists.ntp.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Wed, 06 Apr 2016 00:32:07 -0400 (EDT) X-SA-Exim-Connect-IP: 198.74.231.69 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: weiler@watson.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Wed, 06 Apr 2016 06:11:29 +0000 Subject: [ntpwg] WGLC on NTS: mutual/client authentication X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" The mutual/client authentication bits of NTS seem pretty underdeveloped in the current doc, and, as I asked during Tuesday's meeting, I'm wondering if this feature is really needed. Are we perhaps just burdening implementations with an unused code path? Absent some compelling need for client authentication, shouldn't we take the opportunity to simplify the protocol? If a future use for client auth comes along, there is this lovely NTS version field... -- Sam _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 01:51:41 2016 Return-Path: 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 24F4312D0E3 for ; Wed, 6 Apr 2016 01:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 h6WUDkHBfUjj for ; Wed, 6 Apr 2016 01:51:39 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9D12712D0DC for ; Wed, 6 Apr 2016 01:51:39 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C530E86DBF4 for ; Wed, 6 Apr 2016 08:51:38 +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 6F71886DBD2 for ; Wed, 6 Apr 2016 08:40:58 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anj17-000NaY-JJ for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 08:40:58 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ABF2E92472; Wed, 6 Apr 2016 08:40:48 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u368elqi024418; Wed, 6 Apr 2016 04:40:47 -0400 Date: Wed, 6 Apr 2016 10:40:46 +0200 From: Miroslav Lichvar To: Harlan Stenn Message-ID: <20160406084046.GB9802@localhost> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" On Tue, Apr 05, 2016 at 09:33:56PM +0000, Harlan Stenn wrote: > Sharon Goldberg writes: > > OK. To clarify: you are proposing an extension to NTP where a server > > that has multiple IP addresses can choose a special value as its > > refID, and communicate that to its clients. Then, if the clients > > choose to take time from that server, they put that special value in > > as their refID, instead of an IP address. > > My proposal for SUGGEST-REFID is simply a mechanism for an NTP instance > to tell others "If you use me as your system peer, please use as > your refid." I think an extension field that would allow servers to announce their own refids to clients is an excellent idea and I'm glad someone is working on it. However, I'm not sure about the intended security use case of the proposal. I'm still not convinced that hiding refid would be a major problem for an attacker. I think the number of servers that most clients use on the Internet is fairly small, it probably consist of pool.ntp.org and the list of public servers maintained on the ntp.org wiki. The attacker can probably restrict the list by geo location of the client to a country zone with few hundred of servers at most. I suspect in most cases the attacker would be able to succeed by sending spoofed packets from all these servers. If there is a security issue with clients accepting spoofed packets, I think it should be fixed directly instead of adding some security through obscurity. I'd rather see this extension field used as a way to improve the robustness of the protocol. As Danny pointed out, if servers announced the same refid to all clients, they could reliably detect multihomed hosts. My suggestion is to modify the field so it includes also refids of all upstream servers. The clients could then prevent synchronisation loops longer than 2. Loops between 3 peers polling one another can happen easily and currently the best recommendation to prevent them is to use a "line" configuration for the peers instead of a fully connected mesh. Also, if the clients knew all upstream refids, they could detect duplicate servers in the paths to the stratum 1 servers and ignore them or decrease their weight. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 01:51:52 2016 Return-Path: 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 BEA2D12D0F6 for ; Wed, 6 Apr 2016 01:51:52 -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 Q3pzrztxqOG6 for ; Wed, 6 Apr 2016 01:51:46 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1E12D0DC for ; Wed, 6 Apr 2016 01:51:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 60F7A86DBDD for ; Wed, 6 Apr 2016 08:51:45 +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 5772386DBD2 for ; Wed, 6 Apr 2016 08:44: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 ) id 1anj4I-000Ncc-IH for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 08:44:10 +0000 Received: by mail-wm0-x236.google.com with SMTP id u206so35418689wme.1 for ; Wed, 06 Apr 2016 01:44:06 -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:cc; bh=ACLy6T8xIDA+3qLQtXWby/zVreoWPrEJsMy221FqZuo=; b=dHnBo7P6p+bAv+KGkypJPwUM+8hZ0jymQd5nCms4/A8gkPeol85vaX2DltfNI8TwpA dvmLFPibLSG4M0k4/Yr3/lYOxUx+T74Bm6tpn0ydqitcIvhowN90F+44CViSWwxGR67B CAeRU2i1ZwkjYmNVcbiYQ06sO9OS5D+eO6oj/CTsxmbqsMWaBxdWm4j0xbTxLx50psHu +RJcZ4LBVUAldaJBblkTtORfCs3ioTN+mcX2u7o+gVshpK5Ksxxkz1zbAxZCOxd1qCC2 NTbN4IvnonHhiNR8/DKCVVDsic/E2pxV6tbRmcUE30SvZS9382bmUYeOuzXwV+xldKTm wuNA== 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:cc; bh=ACLy6T8xIDA+3qLQtXWby/zVreoWPrEJsMy221FqZuo=; b=aJ1tGP0toqGiwLgvam2HDLzOpKHtvXbH6dmvueGnlXXEGS4zfP3HZhVvmCjWZGr596 ybnzYikqOqJsfYGy8bnF6nav7nVndyTWdbkFKl61CZGNAT+VV9AtJEM1uizil/pN3vvI E1C9UjLONLnQBJGdsxgfAfwDi8NLZSM6J3UjrP+bxqAE624Oc7mxynkLMEyuT2cG7UKB Ubl74pBCwz7N7vHNlxhfIzu6PKUBYI3Jfqc0Y3kx8Owg0Qurd14/XiG6hUxWBwm1SO3g ybgeGncNDGsJOahurfsCkRYU7Kwt5QzQwjpLaQ7ihFTF2q6fBJJZgBLaumJ5PHrJohBK Dqgg== X-Gm-Message-State: AD7BkJK9C6hBX/Hgx8qzdmq5m6FfoQWUxtRpNQzE9aQm1pKBbl/ZZuV2jmxwaiQBvZtqF1Be9BvGxklO/7gV2Q== X-Received: by 10.194.5.101 with SMTP id r5mr27506532wjr.47.1459932244592; Wed, 06 Apr 2016 01:44:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Wed, 6 Apr 2016 01:43:25 -0700 (PDT) In-Reply-To: <20160405211946.0076E406057@ip-64-139-1-69.sjc.megapath.net> References: <20160405211946.0076E406057@ip-64-139-1-69.sjc.megapath.net> From: Sharon Goldberg Date: Wed, 6 Apr 2016 04:43:25 -0400 X-Google-Sender-Auth: YoRMj_kwKE0GGc4f6W5BHVv4Y7g Message-ID: To: Hal Murray 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] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group Content-Type: multipart/mixed; boundary="===============4800050000628000206==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============4800050000628000206== Content-Type: multipart/alternative; boundary=047d7b5d3e5cd5d125052fccf6d6 --047d7b5d3e5cd5d125052fccf6d6 Content-Type: text/plain; charset=UTF-8 Hal makes a good point. The rekeying mechanism could be to restart the KE from the first message. Since anyway NTS has to be able to deal with the client or server being rebooted, and rekeying should be infrequent. On Tue, Apr 5, 2016 at 5:19 PM, Hal Murray wrote: > > dieter.sibold@ptb.de said: > > But yes, if we refrain from the periodic refresh we could merge the > second > > and third round in the key exchange and additionally we would not have > the > > situation that all clients need to refresh > > their cookie because the server refreshed the server seed. But, of > course, > > we would need to explain why we neglect the must requirement in RFC > 7384. > > Would it simplify the description and/or implementation if things were > collapsed to two rounds? > > Both the server and client can get rebooted at any time. So either side > can > force a rekey by starting over. > > > If the server is going to have performance problems with rekeying, it will > have the same sort of problem when it gets rebooted. (Maybe worse since > all the buggy implementations with short retransmission timeouts will be > banging away.) > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --047d7b5d3e5cd5d125052fccf6d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hal makes a good point. The rekeying mechanism could be to= restart the KE from the first message.=C2=A0 Since anyway NTS has to be ab= le to deal with the client or server being rebooted, and rekeying should be= infrequent.

On Tu= e, Apr 5, 2016 at 5:19 PM, Hal Murray <hmurray@megapathdsl.net&g= t; wrote:

dieter.sibold@ptb= .de said:
> But yes, if we refrain from the periodic refresh we could merge the se= cond
> and third round in the key exchange and additionally we would not have= the
> situation that all clients need to refresh
>=C2=A0 their cookie because the server refreshed the server seed. But, = of course,
>=C2=A0 we would need to explain why we neglect the must requirement in = RFC 7384.

Would it simplify the description and/or implementation if things we= re
collapsed to two rounds?

Both the server and client can get rebooted at any time.=C2=A0 So either si= de can
force a rekey by starting over.


If the server is going to have performance problems with rekeying, it will = have the same sort of problem when it gets rebooted.=C2=A0 (Maybe worse sin= ce all the buggy implementations with short retransmission timeouts will be= banging away.)


--
These are my opinions.=C2=A0 I hate spam.



_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.or= g
http://lists.ntp.org/listinfo/ntpwg




--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~gold= be
--047d7b5d3e5cd5d125052fccf6d6-- --===============4800050000628000206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============4800050000628000206==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 01:51:57 2016 Return-Path: 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 B5F7212D0F6 for ; Wed, 6 Apr 2016 01:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ZJef8dy5fC16 for ; Wed, 6 Apr 2016 01:51:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDD812D0EC for ; Wed, 6 Apr 2016 01:51:51 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 55C5286DC7B for ; Wed, 6 Apr 2016 08:51:51 +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 1E84086DBD2 for ; Wed, 6 Apr 2016 08:50:43 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anjAX-000Ngk-Le for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 08:50:43 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4FF1364380; Wed, 6 Apr 2016 08:50:33 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u368oVfB009091; Wed, 6 Apr 2016 04:50:32 -0400 Date: Wed, 6 Apr 2016 10:50:31 +0200 From: Miroslav Lichvar To: Hal Murray Message-ID: <20160406085031.GC9802@localhost> References: <20160405211946.0076E406057@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160405211946.0076E406057@ip-64-139-1-69.sjc.megapath.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 06 Apr 2016 08:50:33 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group 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" On Tue, Apr 05, 2016 at 02:19:45PM -0700, Hal Murray wrote: > Both the server and client can get rebooted at any time. So either side can > force a rekey by starting over. I think the server can save the seed to a file and avoid having clients to reinitialize NTS when it's restarted. In such case NTS requiring periodic refresh of the seed would make sense. The clients might want to save their cookies too and skip the NTS initialization. > If the server is going to have performance problems with rekeying, it will have the same sort of problem when it gets rebooted. (Maybe worse since all the buggy implementations with short retransmission timeouts will be banging away.) If the server is expected to have a large number of clients, it can use multiple seeds and refresh them slowly one by one to spread the extra CPU load. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 02:22:19 2016 Return-Path: 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 9F0CC12D0C5 for ; Wed, 6 Apr 2016 02:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 pZXsYbWmae0U for ; Wed, 6 Apr 2016 02:22:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3D94912D0B6 for ; Wed, 6 Apr 2016 02:22:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 2981586DBF4 for ; Wed, 6 Apr 2016 09:22:18 +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 6824886DBD2 for ; Wed, 6 Apr 2016 09:13:51 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1anjUd-0003hc-Ho; Wed, 06 Apr 2016 09:11:19 +0000 From: Harlan Stenn To: Miroslav Lichvar In-reply-to: <20160406084046.GB9802@localhost> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> Comments: In-reply-to Miroslav Lichvar message dated "Wed, 06 Apr 2016 10:40:46 +0200." 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: Wed, 06 Apr 2016 09:11:19 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tictoc@ietf.org, NTP Working Group 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" Miroslav Lichvar writes: > I think an extension field that would allow servers to announce their > own refids to clients is an excellent idea and I'm glad someone is > working on it. > > However, I'm not sure about the intended security use case of the > proposal. I'm still not convinced that hiding refid would be a major > problem for an attacker. I think the number of servers that most > clients use on the Internet is fairly small, it probably consist of > pool.ntp.org and the list of public servers maintained on the ntp.org > wiki. The attacker can probably restrict the list by geo location of > the client to a country zone with few hundred of servers at most. I > suspect in most cases the attacker would be able to succeed by sending > spoofed packets from all these servers. How do you define "the attacker would be able to succeed" in this case? Refclocks are increasingly easy to use, too, and this sort of knowledge/attack is not useful if somebody has a local refclock. I don't know how valid it is to assume your geo location claim. Finally, if an attacker is going after somebody's servers that means the "victim" will be getting unsolicited responses, and we now alert on that case. There are other protections against these attacks in the current codebase, too. > If there is a security issue with clients accepting spoofed packets, I > think it should be fixed directly instead of adding some security > through obscurity. What do you suggest? How does the current proposal make things worse in any way? > I'd rather see this extension field used as a way to improve the > robustness of the protocol. Huh? I think you are conflating things here. The proposal is a *mechanism* and the value it contains is *policy*. > As Danny pointed out, if servers announced > the same refid to all clients, they could reliably detect multihomed > hosts. Then all a bad guy has to do is to send a time request to a target, see what refid it gets, and then use that knowledge as an attack vector. Also, there has been no demonstrated benefit that this "wider scope" loop detection will be of any useful value. > My suggestion is to modify the field so it includes also refids of all > upstream servers. The clients could then prevent synchronisation loops > longer than 2. Loops between 3 peers polling one another can happen > easily and currently the best recommendation to prevent them is to > use a "line" configuration for the peers instead of a fully connected > mesh. Also, if the clients knew all upstream refids, they could detect > duplicate servers in the paths to the stratum 1 servers and ignore > them or decrease their weight. Can you demonstrate tangible problems with the current scheme and tangible benefit with your solution? Please also consider the security ramifications. I've seen lots of mesh setups - they have all worked fine. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 03:40:00 2016 Return-Path: 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 2D30212D13B for ; Wed, 6 Apr 2016 03:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 iAV4RC3fXTUt for ; Wed, 6 Apr 2016 03:39:58 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C473D12D0E1 for ; Wed, 6 Apr 2016 03:39:58 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BC0F386DC35 for ; Wed, 6 Apr 2016 10:39:58 +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 0752886DBED for ; Wed, 6 Apr 2016 10:39:33 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ankrj-0004BK-4A for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 10:39:33 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F23181441B1; Wed, 6 Apr 2016 10:39:13 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u36AdCsE026994; Wed, 6 Apr 2016 06:39:13 -0400 Date: Wed, 6 Apr 2016 12:39:12 +0200 From: Miroslav Lichvar To: Harlan Stenn Message-ID: <20160406103912.GA11632@localhost> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 06 Apr 2016 10:39:14 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" On Wed, Apr 06, 2016 at 09:11:19AM +0000, Harlan Stenn wrote: > Miroslav Lichvar writes: > > wiki. The attacker can probably restrict the list by geo location of > > the client to a country zone with few hundred of servers at most. I > > suspect in most cases the attacker would be able to succeed by sending > > spoofed packets from all these servers. > > How do you define "the attacker would be able to succeed" in this case? Sending a packet that will be accepted by the client and disrupting the synchronisation. > Refclocks are increasingly easy to use, too, and this sort of > knowledge/attack is not useful if somebody has a local refclock. Well, if everyone had a reliable refclock, we wouldn't need NTP. :) > > If there is a security issue with clients accepting spoofed packets, I > > think it should be fixed directly instead of adding some security > > through obscurity. > > What do you suggest? How does the current proposal make things worse in > any way? If the implementation follows the recommendation to change the refid randomly, a client can't detect if it's talking to the same server as its server for instance. > > I'd rather see this extension field used as a way to improve the > > robustness of the protocol. > > Huh? I think you are conflating things here. The proposal is a > *mechanism* and the value it contains is *policy*. >From how I read the draft, it seems to suggest it's a security mechanism. The word "attacker" is used quite a few times. I'd rather see the proposal going in the other direction, giving clients a better view of the NTP network instead of hiding information. If you don't see the benefits, that's ok. I just thought I should write my suggestions and see if anyone agrees with that. > > As Danny pointed out, if servers announced > > the same refid to all clients, they could reliably detect multihomed > > hosts. > > Then all a bad guy has to do is to send a time request to a target, see > what refid it gets, and then use that knowledge as an attack vector. If the client is fixed to not accept spoofed packets, what exactly the attacker can do with that information? > Also, there has been no demonstrated benefit that this "wider scope" > loop detection will be of any useful value. > > > My suggestion is to modify the field so it includes also refids of all > > upstream servers. The clients could then prevent synchronisation loops > > longer than 2. Loops between 3 peers polling one another can happen > > easily and currently the best recommendation to prevent them is to > > use a "line" configuration for the peers instead of a fully connected > > mesh. Also, if the clients knew all upstream refids, they could detect > > duplicate servers in the paths to the stratum 1 servers and ignore > > them or decrease their weight. > > Can you demonstrate tangible problems with the current scheme and > tangible benefit with your solution? Please also consider the security > ramifications. For instance, if the client knew the same stratum 1 server is used by multiple stratum 3 servers and they didn't agree with other sources, they could be rejected as one assuming the stratum 1 server is bad. > I've seen lots of mesh setups - they have all worked fine. I've received reports on loops forming between three peers that were polling one another when they stopped receiving time from their upstream sources. I was able to reproduce that. It's not a critical issue, but I think it would be nice if NTP could prevent that. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 12:21:03 2016 Return-Path: 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 7B57012D614 for ; Wed, 6 Apr 2016 12:21:03 -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 IbDeXzciGf7B for ; Wed, 6 Apr 2016 12:21:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9112D5C1 for ; Wed, 6 Apr 2016 12:21:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BC4F786DC5D for ; Wed, 6 Apr 2016 19:21:01 +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 B2E8A86DB80 for ; Wed, 6 Apr 2016 19:12:48 +0000 (UTC) Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anssg-000BzP-RB for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 19:12:48 +0000 Received: by mail-wm0-x230.google.com with SMTP id l6so78108600wml.1 for ; Wed, 06 Apr 2016 12:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=TEe+w8hw50XnqORJQq2nN1piw+LwtHsBkFqgAas3nno=; b=JFlh+ZW8ItcaNqxItaG1KjtC7+hshkagniEhy66+MVVPu+5TjH+FV62B2G9LGzlVIR A5fLiWx5Lau27qE63LFI3lECJgvChAjpuyxpWdr2N7KXnhfNV5vySROD+qhEfqHMbe1i kFccP+fQqVxf4kxg6VVtIv886BfkKRTblYy1l2R+j5ytFkzJsibEYnpS44StaFXwHsqz Jo+Cb0lmHlIbVz32wp3pcovnCC/dVe6GqYXrtqwBMkHC95qaogN6jlN28F9oYK0tWUeE C2qYmE/uqPH9ONO2JDB3u5aqbRSDtwZ7nP0pxHSqsi3JGHRTsOYkl9yPiAz8nd3RA9xy 0SGA== 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:from:date:message-id:subject :to:cc; bh=TEe+w8hw50XnqORJQq2nN1piw+LwtHsBkFqgAas3nno=; b=W+8cPWXDgqjNGAqt4lNPxpO59gdUd5RzJ7WsgAWVqMhDiP1qs5bGN5qP9ELeisSqrH i8kb23xETRBJv+it75Yen6hE528G25r9LWeZ1J3fj1UYefVCNz8tuQ1arG/DqFr5i9+d LrLeg2txdAVdsUNzcWO4+kJtDJcvxUHoQlP73m73gqF2v24QXthUxudNWhSPGe+JZmYk z9kn9z8AmljddIR73QMf0+cEZ6qXnEJpeZ9nVFLduOEJy39keu7TJt2QcG934OA7FjVd bqSTtBV4ykOCIZS58afRQUEXyeydmA0hPl+Doi0SfHDGFGBuppwmEyh5uAAis83kxvpo bvLw== X-Gm-Message-State: AD7BkJK5zE92RnTAv8cr89NoPLoTJC0jF0RD/iLCRZH6FnTK2F8hhvgpMjKLP38doqrYVXVmMi1yJxglRHJ4vA== X-Received: by 10.194.62.110 with SMTP id x14mr26357592wjr.68.1459969965064; Wed, 06 Apr 2016 12:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Wed, 6 Apr 2016 12:12:05 -0700 (PDT) From: Sharon Goldberg Date: Wed, 6 Apr 2016 15:12:05 -0400 X-Google-Sender-Auth: le7GnffLC73YPwQrk6-YVFJOZN0 Message-ID: To: Miroslav Lichvar X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::230 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] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Hal Murray Content-Type: multipart/mixed; boundary="===============5652001439144101713==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============5652001439144101713== Content-Type: multipart/alternative; boundary=047d7b86d66c26877b052fd5bf51 --047d7b86d66c26877b052fd5bf51 Content-Type: text/plain; charset=UTF-8 Miroslav, this is a good point. But still one could rerun the KE from first message in order to rekey, but stagger the runs as you describe below. On Wed, Apr 6, 2016 at 4:50 AM, Miroslav Lichvar wrote: > On Tue, Apr 05, 2016 at 02:19:45PM -0700, Hal Murray wrote: > > Both the server and client can get rebooted at any time. So either side > can > > force a rekey by starting over. > > I think the server can save the seed to a file and avoid having > clients to reinitialize NTS when it's restarted. In such case NTS > requiring periodic refresh of the seed would make sense. > > The clients might want to save their cookies too and skip the NTS > initialization. > > > If the server is going to have performance problems with rekeying, it > will have the same sort of problem when it gets rebooted. (Maybe worse > since all the buggy implementations with short retransmission timeouts will > be banging away.) > > If the server is expected to have a large number of clients, it can > use multiple seeds and refresh them slowly one by one to spread the > extra CPU load. > > -- > Miroslav Lichvar > --047d7b86d66c26877b052fd5bf51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Miroslav, this is a good point.=C2=A0 But still one could = rerun the KE from first message in order to rekey, but stagger the runs as = you describe below.=C2=A0

On Wed, Apr 6, 2016 at 4:50 AM, Miroslav Lichvar <mlichvar@= redhat.com> wrote:
On Tue, Apr 05, 2016 at 02:19:45PM -0700, Hal Murray wrote:
> Both the server and client can get rebooted at any time.=C2=A0 So eith= er side can
> force a rekey by starting over.

I think the server can save the seed to a file and avoid having
clients to reinitialize NTS when it's restarted. In such case NTS
requiring periodic refresh of the seed would make sense.

The clients might want to save their cookies too and skip the NTS
initialization.

> If the server is going to have performance problems with rekeying, it = will have the same sort of problem when it gets rebooted.=C2=A0 (Maybe wors= e since all the buggy implementations with short retransmission timeouts wi= ll be banging away.)

If the server is expected to have a large number of clients, it can<= br> use multiple seeds and refresh them slowly one by one to spread the
extra CPU load.

--
Miroslav Lichvar

--047d7b86d66c26877b052fd5bf51-- --===============5652001439144101713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============5652001439144101713==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 13:21:20 2016 Return-Path: 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 1728E12D667 for ; Wed, 6 Apr 2016 13:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 toS3Xc7YIFLM for ; Wed, 6 Apr 2016 13:21:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 73A1012D0BC for ; Wed, 6 Apr 2016 13:21:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6810086DC78 for ; Wed, 6 Apr 2016 20:21:18 +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 5651786DB11 for ; Wed, 6 Apr 2016 20:21:03 +0000 (UTC) Received: from mail234c25.carrierzone.com ([64.29.147.248] helo=mail222c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1antwa-000CvQ-CL for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 20:21:03 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail222c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u36KKmuR024140 for ; Wed, 6 Apr 2016 20:20:50 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 43AB6406061; Wed, 6 Apr 2016 13:20:48 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Miroslav Lichvar From: Hal Murray In-Reply-To: Message from Miroslav Lichvar of "Wed, 06 Apr 2016 12:39:12 +0200." <20160406103912.GA11632@localhost> Mime-Version: 1.0 Date: Wed, 06 Apr 2016 13:20:48 -0700 Message-Id: <20160406202048.43AB6406061@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=S+zgnucP c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=20KFwNOVAAAA:8 a=yGp3T9Tg3H-NKCqjOgYA:9 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A010205.57056FA2.0068, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.248 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , hmurray@megapathdsl.net, tictoc@ietf.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" [refid discussion] mlichvar@redhat.com said: > If you don't see the benefits, that's ok. I just thought I should write my > suggestions and see if anyone agrees with that. I think that's an important idea. We need to consider the trade-offs between security from hiding the real refid compared to the forensic value of being able to figure out what is or was going on. On the other hand, I don't have a handful of stories where it has been helpful so maybe it isn't really important. Is a warm-fuzzy feeling worth anything? mlichvar@redhat.com said: > If the client is fixed to not accept spoofed packets, what exactly the > attacker can do with that information? It tells the bad guys one of the servers a system is using. That is probably useful targeting information, either for DoS or for infiltration via phishing or exploit. mlichvar@redhat.com said: > I've received reports on loops forming between three peers that were polling > one another when they stopped receiving time from their upstream sources. I > was able to reproduce that. It's not a critical issue, but I think it would > be nice if NTP could prevent that. Doesn't that case bump the stratum level each time around the loop until is falls off the end? -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 14:54:18 2016 Return-Path: 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 2AF0412D53D for ; Wed, 6 Apr 2016 14:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 26ecf3ygu_Pf for ; Wed, 6 Apr 2016 14:54:15 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C905C12D15D for ; Wed, 6 Apr 2016 14:54:15 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C2C2F86DC5A for ; Wed, 6 Apr 2016 21:54:15 +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 1986686DC27 for ; Wed, 6 Apr 2016 21:53:47 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1anvNF-0004Ro-NV; Wed, 06 Apr 2016 21:52:29 +0000 From: Harlan Stenn To: Miroslav Lichvar In-reply-to: <20160406103912.GA11632@localhost> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> <20160406103912.GA11632@localhost> Comments: In-reply-to Miroslav Lichvar message dated "Wed, 06 Apr 2016 12:39:12 +0200." 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: Wed, 06 Apr 2016 21:52:29 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tictoc@ietf.org, NTP Working Group 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" Miroslav Lichvar writes: > On Wed, Apr 06, 2016 at 09:11:19AM +0000, Harlan Stenn wrote: > > Miroslav Lichvar writes: > > > wiki. The attacker can probably restrict the list by geo location of > > > the client to a country zone with few hundred of servers at most. I > > > suspect in most cases the attacker would be able to succeed by sending > > > spoofed packets from all these servers. > > > > How do you define "the attacker would be able to succeed" in this case? > > Sending a packet that will be accepted by the client and disrupting > the synchronisation. I think we're approaching a workable definition there. It depends on "accepted by the client" and "disrupting". To me, the goal of the protocol includes (and this needs more tweaking, too): - weed out flagrantly bad packets - update some core peer state data - perform thorough packet checks - if these checks pass, send the packet to the filters Even then, bogus or otherwise bad packets will get thru. The algorithms are designed to deal with these problems. > > Refclocks are increasingly easy to use, too, and this sort of > > knowledge/attack is not useful if somebody has a local refclock. > > Well, if everyone had a reliable refclock, we wouldn't need NTP. :) I notice the smiley. Even so, that's an incomplete, myopic, and insufficient oversimplication. > > > If there is a security issue with clients accepting spoofed packets, I > > > think it should be fixed directly instead of adding some security > > > through obscurity. > > > > What do you suggest? How does the current proposal make things worse in > > any way? > > If the implementation follows the recommendation to change the refid > randomly, a client can't detect if it's talking to the same server as > its server for instance. I'm not seeing where you think the current proposal is worse in any way. As for your response/suggestion, where is this recommendation to change the refid randomly? In the case where I suggest a refid and you choose me as your server and use my suggested refid as your system peer, even if I change this on every poll interval it will be pretty easy for me to track these random refids and still detect a loop. Yes, it means saving some state. The server suggesting the refid has control over if it uses the same refid for everybody or not, and also for how often it chooses to change its suggested refid. This is a local policy choice. Even if the client is broken and uses us as their server giving us a refid we do not understand, in that case there will be a timing loop and each poll interval the stratum on each side will increase. Eventually, these systems will either find another peer to get time from or they'll both become unsync'd (because there is no other source of time). This is no different from A noticing that B is getting its time from A, refusing to take time from B, and either getting time from somewhere else or just changing its state to unsynch'd (S16). > > > I'd rather see this extension field used as a way to improve the > > > robustness of the protocol. > > > > Huh? I think you are conflating things here. The proposal is a > > *mechanism* and the value it contains is *policy*. > > From how I read the draft, it seems to suggest it's a security > mechanism. The word "attacker" is used quite a few times. I'd rather > see the proposal going in the other direction, giving clients a better > view of the NTP network instead of hiding information. Yes, it's a security mechanism. And please remember that we're trying to get away from the expectation that an S2+ refid is an IPv4 address, because that is increasingly incorrect. Also note we're about to make it easy to control "who can see what", so if you want to know who my upstream server really is and you have the authorization to get that information, that would be made available thru a mode 6 query. > If you don't see the benefits, that's ok. I just thought I should > write my suggestions and see if anyone agrees with that. I wouldn't do what you and Danny are suggesting, but if you want to do things that way it's your choice - that's why I'm saying my proposal offers a mechanism, and while we'll provide a default policy choice on what that suggested refid will be, there will also be mechanism in the config file to allow you to specify your local policy on what that suggested refid will be and the circumstances under which that suggesteed refid will change. > > > As Danny pointed out, if servers announced > > > the same refid to all clients, they could reliably detect multihomed > > > hosts. > > > > Then all a bad guy has to do is to send a time request to a target, see > > what refid it gets, and then use that knowledge as an attack vector. > > If the client is fixed to not accept spoofed packets, what exactly the > attacker can do with that information? How can anybody detect that an incoming packet has a forged source address? > > Also, there has been no demonstrated benefit that this "wider scope" > > loop detection will be of any useful value. > > > > > My suggestion is to modify the field so it includes also refids of all > > > upstream servers. The clients could then prevent synchronisation loops > > > longer than 2. Loops between 3 peers polling one another can happen > > > easily and currently the best recommendation to prevent them is to > > > use a "line" configuration for the peers instead of a fully connected > > > mesh. Also, if the clients knew all upstream refids, they could detect > > > duplicate servers in the paths to the stratum 1 servers and ignore > > > them or decrease their weight. > > > > Can you demonstrate tangible problems with the current scheme and > > tangible benefit with your solution? Please also consider the security > > ramifications. > > For instance, if the client knew the same stratum 1 server is used by > multiple stratum 3 servers and they didn't agree with other sources, > they could be rejected as one assuming the stratum 1 server is bad. How would you propose this work in practice? This seems to be a special case of a Sybil attack. I think the overhead this would introduce would be huge and is better addressed elsewhere, by proper monitoring and having enough upstream servers. > > I've seen lots of mesh setups - they have all worked fine. > > I've received reports on loops forming between three peers that > were polling one another when they stopped receiving time from their > upstream sources. I was able to reproduce that. It's not a critical > issue, but I think it would be nice if NTP could prevent that. Were these 3 machines the only source of time? Are they set up in orphan mode? What would have happened if this loop had been prevented? H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 16:06:19 2016 Return-Path: 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 A0F5A12D616 for ; Wed, 6 Apr 2016 16:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 G1_UBBqZQh8S for ; Wed, 6 Apr 2016 16:06:17 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7916A12D535 for ; Wed, 6 Apr 2016 16:06:17 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6E47486DC3E for ; Wed, 6 Apr 2016 23:06:17 +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 B577B86D4A6 for ; Wed, 6 Apr 2016 22:57:51 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anwOL-000FMa-NY for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 22:57:51 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id u36MvaAg007001-u36MvaAi007001 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 00:57:36 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id 632B3C6EA9; Thu, 7 Apr 2016 00:57:36 +0200 (CEST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: dieter.sibold@ptb.de To: Sharon Goldberg Message-ID: Date: Thu, 7 Apr 2016 00:57:35 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Hal Murray Content-Type: multipart/mixed; boundary="===============1426476694524717544==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============1426476694524717544== Content-Type: multipart/alternative; boundary="=_alternative 007E1F59C1257F8D_=" --=_alternative 007E1F59C1257F8D_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -----"ntpwg" wrote: --= --- >To: Miroslav Lichvar >From: Sharon Goldberg=20 >Sent by: "ntpwg"=20 >Date: 04/06/2016 20:29 >Cc: NTP Working Group , Hal Murray > >Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh > >Miroslav, this is a good point.=C2=A0 But still one could rerun the KE >from first message in order to rekey, but stagger the runs as you >describe below.=C2=A0=20 Yes, the staggering would be desirable. I've discussed this with Kristof so= me time ago. The problem with this is - as far as I remember - that the ser= ver would have to save state, because if the server re-generates the cookie= upon a client request the choice of the server seed would be a function of= the provided KIV. This would have violated the paradigm to have the the pr= otocol stateless on the server-side. However, if the advantages in introduc= ing state at the server-side outweighs the disadvantage, we might change th= is paradigm. Dieter > >On Wed, Apr 6, 2016 at 4:50 AM, Miroslav Lichvar > wrote: >On Tue, Apr 05, 2016 at 02:19:45PM -0700, Hal Murray wrote: > >> Both the server and client can get rebooted at any time.=C2=A0 So either >side can > >> force a rekey by starting over. > > > >I think the server can save the seed to a file and avoid having > >clients to reinitialize NTS when it's restarted. In such case NTS > >requiring periodic refresh of the seed would make sense. > > > >The clients might want to save their cookies too and skip the NTS > >initialization. > > > >> If the server is going to have performance problems with rekeying, >it will have the same sort of problem when it gets rebooted.=C2=A0 (Maybe >worse since all the buggy implementations with short retransmission >timeouts will be banging away.) > > > >If the server is expected to have a large number of clients, it can > >use multiple seeds and refresh them slowly one by one to spread the > >extra CPU load. > > > >-- > >Miroslav Lichvar > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >ntpwg mailing list >ntpwg@lists.ntp.org >http://lists.ntp.org/listinfo/ntpwg --=_alternative 007E1F59C1257F8D_= Content-Type: text/html; charset=UTF-8 Content-ID: <> Content-Transfer-Encoding: quoted-printable


-----"ntpwg" <ntpwg-bounces+dieter.sibold=3Dptb.de@lis= ts.ntp.org> wrote: -----

=
>To: Miroslav Lichvar <mlichvar@redhat.com>
>From: Sharon Goldberg
>Sent by: "ntpwg"
>Date: 04= /06/2016 20:29
>Cc: NTP Working Group <= ntpwg@lists.ntp.org>, Hal Murray
><h= murray@megapathdsl.net>
>Subject: Re: [= ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh
>
>Miroslav, this is a good poi= nt.  But still one could rerun the KE
&g= t;from first message in order to rekey, but stagger the runs as you
>describe below. 

Yes, the staggering would be desirable.= I've discussed this with Kristof some time ago. The problem with this is -= as far as I remember - that the server would have to save state, because i= f the server re-generates the cookie upon a client request the choice of th= e server seed would be a function of the provided KIV. This would have viol= ated the paradigm to have the the protocol stateless on the server-side. Ho= wever, if the advantages in introducing state at the server-side outweighs = the disadvantage, we might change this paradigm.
=
Dieter

<= div style=3D"margin: 0px; direction: ltr; font-family: Verdana, Arial, Helv= etica, sans-serif;">>
>On Wed, Apr 6, 2= 016 at 4:50 AM, Miroslav Lichvar
><mlic= hvar@redhat.com> wrote:
>On Tue, Apr 05= , 2016 at 02:19:45PM -0700, Hal Murray wrote:
>
>> Both the server and client can= get rebooted at any time.  So either
&g= t;side can
>
>> force a rekey by starting over.
>= ;
>
>
=
>I think the server can save the seed to a fi= le and avoid having
>
>clients to reinitialize NTS when it's restarted. In such cas= e NTS
>
>= requiring periodic refresh of the seed would make sense.
>
>
>
>The clients might want to sav= e their cookies too and skip the NTS
>
=
>initialization.
>
>= ;
>> If the server is going to have per= formance problems with rekeying,
>it will = have the same sort of problem when it gets rebooted.  (Maybe
=
>worse since all the buggy implementations with sho= rt retransmission
>timeouts will be bangin= g away.)
>
&= gt;
>
>If= the server is expected to have a large number of clients, it can
=
>
>use multiple se= eds and refresh them slowly one by one to spread the
>
>extra CPU load.
>
>
>
>--
>
>Miroslav Lichvar
>
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F
>ntpwg mailing list
=
>ntpwg@lists.ntp.org
= >http://lists.ntp.org/listinfo/ntpwg
 --=_alternative 007E1F59C1257F8D_=-- --===============1426476694524717544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1426476694524717544==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 16:51:29 2016 Return-Path: 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 3E7C712D18E for ; Wed, 6 Apr 2016 16:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 XwgTUTX34w_t for ; Wed, 6 Apr 2016 16:51:27 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8519D12D160 for ; Wed, 6 Apr 2016 16:51:27 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7E2C286DC4C for ; Wed, 6 Apr 2016 23:51:27 +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 9DF6C86D58E for ; Wed, 6 Apr 2016 23:51:16 +0000 (UTC) Received: from mail230c25.carrierzone.com ([64.29.147.244] helo=mail237c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1anxE3-000G9a-2O for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 23:51:16 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail237c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u36Np3rZ019918 for ; Wed, 6 Apr 2016 23:51:04 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id C2620406061; Wed, 6 Apr 2016 16:51:02 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: NTP Working Group From: Hal Murray Mime-Version: 1.0 Date: Wed, 06 Apr 2016 16:51:02 -0700 Message-Id: <20160406235102.C2620406061@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=EYLxHpWC c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=f41RBWoJlmyGjYm1hnsA:9 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A010205.5705A0E8.0128, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.244 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Hal Murray 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" dieter.sibold@ptb.de said: > Yes, the staggering would be desirable. I've discussed this with Kristof so= > me time ago. The problem with this is - as far as I remember - that the ser= > ver would have to save state, because if the server re-generates the cookie= > upon a client request the choice of the server seed would be a function of= > the provided KIV. This would have violated the paradigm to have the the pr= > otocol stateless on the server-side. However, if the advantages in introduc= > ing state at the server-side outweighs the disadvantage, we might change th= > is paradigm. There are two levels of "state". You could save a seed per-client. That looks expensive, but may still be practical with modern hardware. You could also batch things, say by hashing the client's IP Address to access a table of seeds. The size of the table would determine the reduction in peak load. There is probably a maximum useful size of such a table. I think we could calculate it if we had good statistics. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 22:52:35 2016 Return-Path: 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 B523012D1EC for ; Wed, 6 Apr 2016 22:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 StrA99Tiaxy3 for ; Wed, 6 Apr 2016 22:52:34 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4315E12D127 for ; Wed, 6 Apr 2016 22:52:34 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 3954286DC5B for ; Thu, 7 Apr 2016 05:52:34 +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 701C386DC25 for ; Thu, 7 Apr 2016 05:48:40 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1ao2o0-00053F-SP; Thu, 07 Apr 2016 05:48:36 +0000 From: Harlan Stenn To: Hal Murray In-reply-to: <20160406202048.43AB6406061@ip-64-139-1-69.sjc.megapath.net> References: <20160406202048.43AB6406061@ip-64-139-1-69.sjc.megapath.net> Comments: In-reply-to Hal Murray message dated "Wed, 06 Apr 2016 13:20:48 -0700." 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, 07 Apr 2016 05:48:36 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" Hal Murray writes: > [refid discussion] > > mlichvar@redhat.com said: > > If you don't see the benefits, that's ok. I just thought I should write my > > suggestions and see if anyone agrees with that. > > I think that's an important idea. We need to consider the trade-offs > between security from hiding the real refid compared to the forensic > value of being able to figure out what is or was going on. As I said before, the real source of time is available from a mode 6 query. How can y'all not know this, even without my pointing it out? H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 23:22:01 2016 Return-Path: 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 22F0F12D594 for ; Wed, 6 Apr 2016 23:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 5UPDhtiKJCyr for ; Wed, 6 Apr 2016 23:21:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 2D81712D569 for ; Wed, 6 Apr 2016 23:21:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 26F0886DC7E for ; Thu, 7 Apr 2016 06:21:59 +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 4FED386DC2E for ; Thu, 7 Apr 2016 06:21:50 +0000 (UTC) Received: from mail225c25.carrierzone.com ([64.29.147.239] helo=mail24c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ao3K1-000MIT-Ix; Thu, 07 Apr 2016 06:21:50 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail24c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u376LbOK011659; Thu, 7 Apr 2016 06:21:39 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 2395D406074; Wed, 6 Apr 2016 23:21:37 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Harlan Stenn From: Hal Murray In-Reply-To: Message from Harlan Stenn of "Thu, 07 Apr 2016 05:48:36 -0000." Mime-Version: 1.0 Date: Wed, 06 Apr 2016 23:21:37 -0700 Message-Id: <20160407062137.2395D406074@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=LLhfHvm9 c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=85N1-lAfAAAA:8 a=wIKCeUunG4cN5H6-N-gA:9 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A010202.5705FC73.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.239 X-SA-Exim-Rcpt-To: stenn@ntp.org, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Hal Murray , tictoc@ietf.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" stenn@ntp.org said: > As I said before, the real source of time is available from a mode 6 query. My system doesn't automatically log that. The remove system probably does log it, but I probably don't have convenient access to those log files. If the reason the remove server is hiding the real refid is to prevent the bad guys from figuring out which servers it is using, then mode 6 access is probably blocked. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 6 23:38:09 2016 Return-Path: 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 592A512D555 for ; Wed, 6 Apr 2016 23:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 rxwUDIceXT-p for ; Wed, 6 Apr 2016 23:38:07 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id A925F12D56C for ; Wed, 6 Apr 2016 23:38:07 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A45A986DCAA for ; Thu, 7 Apr 2016 06:38:07 +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 B590186DB35 for ; Thu, 7 Apr 2016 06:38:01 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1ao3XO-00057A-Rw; Thu, 07 Apr 2016 06:35:30 +0000 From: Harlan Stenn To: Hal Murray In-reply-to: <20160407062137.2395D406074@ip-64-139-1-69.sjc.megapath.net> References: <20160407062137.2395D406074@ip-64-139-1-69.sjc.megapath.net> Comments: In-reply-to Hal Murray message dated "Wed, 06 Apr 2016 23:21:37 -0700." 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, 07 Apr 2016 06:35:30 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" Hal Murray writes: > > stenn@ntp.org said: > > As I said before, the real source of time is available from a mode 6 query. > > > My system doesn't automatically log that. The remove system probably > does log it, but I probably don't have convenient access to those log > files. How did you get from a mode 6 query to a log file? > If the reason the remove server is hiding the real refid is to prevent > the bad guys from figuring out which servers it is using, then mode 6 > access is probably blocked. a) the "real refid" is not being hidden. The express purpose of the refid is maintained. b) if you have a valid reason for issuing mode 6 queries and the "other side" doesn't choose to allow this, that's their policy choice. In that case you can continue to use them for time, or not. Your policy choice. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 00:22:06 2016 Return-Path: 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 4F5DB12D594 for ; Thu, 7 Apr 2016 00:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 6F9WOxGk2FNU for ; Thu, 7 Apr 2016 00:22:04 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id AF57E12D585 for ; Thu, 7 Apr 2016 00:22:04 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 8B96486DC69 for ; Thu, 7 Apr 2016 07:22:04 +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 6A5FA86DC3D for ; Thu, 7 Apr 2016 07:16:33 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ao4Ax-000NBr-EK for ntpwg@lists.ntp.org; Thu, 07 Apr 2016 07:16:32 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5CD9E6436F; Thu, 7 Apr 2016 07:16:22 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u377GKol020298; Thu, 7 Apr 2016 03:16:21 -0400 Date: Thu, 7 Apr 2016 09:16:20 +0200 From: Miroslav Lichvar To: Hal Murray Message-ID: <20160407071620.GB20410@localhost> References: <20160406235102.C2620406061@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160406235102.C2620406061@ip-64-139-1-69.sjc.megapath.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 07 Apr 2016 07:16:22 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group 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" On Wed, Apr 06, 2016 at 04:51:02PM -0700, Hal Murray wrote: > You could also batch things, say by hashing the client's IP Address to access > a table of seeds. The size of the table would determine the reduction in > peak load. > > There is probably a maximum useful size of such a table. I think we could > calculate it if we had good statistics. That could work. Another option is to use just two seeds and slowly pull the clients from one seed to another using a threshold for the hash of the client's address. The refreshing operation could be something like: - all clients are using seed 1 - seed 2 is generated - set the threshold to 0 - slowly increment the threshold, clients with their hash below the threshold are using seed 2 - all clients are using seed 2 - copy seed 2 to seed 1 and start the process again The server could increment the threshold as slowly as needed and it requires only constant memory. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 00:37:05 2016 Return-Path: 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 2902112D5B2 for ; Thu, 7 Apr 2016 00:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 752UkVybvmQO for ; Thu, 7 Apr 2016 00:37:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B712D5A9 for ; Thu, 7 Apr 2016 00:37:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A5FA186DCB5 for ; Thu, 7 Apr 2016 07:37:00 +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 0DA3F86DC38 for ; Thu, 7 Apr 2016 07:36:54 +0000 (UTC) Received: from mail158c25.carrierzone.com ([64.29.147.228] helo=mail223c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ao4Ud-000NZa-7l for ntpwg@lists.ntp.org; Thu, 07 Apr 2016 07:36:54 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail223c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u377aeEo021922 for ; Thu, 7 Apr 2016 07:36:41 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id B763E406074; Thu, 7 Apr 2016 00:36:39 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Miroslav Lichvar From: Hal Murray In-Reply-To: Message from Miroslav Lichvar of "Thu, 07 Apr 2016 09:16:20 +0200." <20160407071620.GB20410@localhost> Mime-Version: 1.0 Date: Thu, 07 Apr 2016 00:36:39 -0700 Message-Id: <20160407073639.B763E406074@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=YdmEuWhf c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=20KFwNOVAAAA:8 a=2kjFNnFmbTXF0dyg-UUA:9 a=CjuIK1q_8ugA:10 a=Emr5vKMlBO0A:10 X-CTCH-RefID: str=0001.0A010203.57060E09.010C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.228 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Hal Murray 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" mlichvar@redhat.com said: > Another option is to use just two seeds and slowly pull the clients from one > seed to another using a threshold for the hash of the client's address. I like that. Thanks. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 01:37:09 2016 Return-Path: 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 23C5112D5CA for ; Thu, 7 Apr 2016 01:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 VmC0BKHW5Y2D for ; Thu, 7 Apr 2016 01:37:07 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 42AC912D58F for ; Thu, 7 Apr 2016 01:37:07 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 3B1BA86DC5D for ; Thu, 7 Apr 2016 08:37:07 +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 629A786DBDC for ; Thu, 7 Apr 2016 08:32:47 +0000 (UTC) Received: from mail230c25.carrierzone.com ([64.29.147.244] helo=mail237c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ao5MX-000OK9-2h; Thu, 07 Apr 2016 08:32:47 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail237c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u378WLlc011852; Thu, 7 Apr 2016 08:32:22 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 1F3B2406074; Thu, 7 Apr 2016 01:32:21 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Harlan Stenn From: Hal Murray In-Reply-To: Message from Harlan Stenn of "Thu, 07 Apr 2016 06:35:30 -0000." Mime-Version: 1.0 Date: Thu, 07 Apr 2016 01:32:21 -0700 Message-Id: <20160407083221.1F3B2406074@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=EYLxHpWC c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=jVlkoXtc9V915UhSPW4A:9 a=CjuIK1q_8ugA:10 a=lbFWo1bU1VEA:10 X-CTCH-RefID: str=0001.0A010204.57061B17.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.244 X-SA-Exim-Rcpt-To: stenn@ntp.org, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Hal Murray , tictoc@ietf.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" > How did you get from a mode 6 query to a log file? You said I could get the real refid via mode 6, The context I was thinking about was forensics. I'm often interested in what has happened rather than what is happening. In that case, all the evidence that is available is what's in the log files. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 01:55:14 2016 Return-Path: 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 E20A912D604 for ; Thu, 7 Apr 2016 01:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 g4UpWYNfFKMc for ; Thu, 7 Apr 2016 01:55:13 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3D48E12D5FF for ; Thu, 7 Apr 2016 01:55:13 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 38AF786DC71 for ; Thu, 7 Apr 2016 08:55:13 +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 6B7BA86DBDB for ; Thu, 7 Apr 2016 08:55:02 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1ao5fz-0005GE-Mx; Thu, 07 Apr 2016 08:52:31 +0000 From: Harlan Stenn To: Hal Murray In-reply-to: <20160407083221.1F3B2406074@ip-64-139-1-69.sjc.megapath.net> References: <20160407083221.1F3B2406074@ip-64-139-1-69.sjc.megapath.net> Comments: In-reply-to Hal Murray message dated "Thu, 07 Apr 2016 01:32:21 -0700." 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, 07 Apr 2016 08:52:31 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" Hal Murray writes: > > How did you get from a mode 6 query to a log file? > > You said I could get the real refid via mode 6, No, I said you could get the address of the upstream peer with mode 6. > The context I was thinking about was forensics. I'm often interested > in what has happened rather than what is happening. In that case, all > the evidence that is available is what's in the log files. That may be OK with IPv4 refids, but how do the current logfiles help you with IPv6-based refids? H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 01:57:24 2016 Return-Path: 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 06CA412D10E for ; Thu, 7 Apr 2016 01:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 5DNykoW5NeL7 for ; Thu, 7 Apr 2016 01:57:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 71E4C12D53D for ; Thu, 7 Apr 2016 01:57:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6BE7A86DCE7 for ; Thu, 7 Apr 2016 08:57:22 +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 8436986DBDB for ; Thu, 7 Apr 2016 08:57:18 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ao5kS-000OoT-Lw for ntpwg@lists.ntp.org; Thu, 07 Apr 2016 08:57:18 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2464DC04B319; Thu, 7 Apr 2016 08:57:08 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u378v7jU005673; Thu, 7 Apr 2016 04:57:07 -0400 Date: Thu, 7 Apr 2016 10:57:06 +0200 From: Miroslav Lichvar To: Hal Murray Message-ID: <20160407085706.GC20410@localhost> References: <20160406103912.GA11632@localhost> <20160406202048.43AB6406061@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160406202048.43AB6406061@ip-64-139-1-69.sjc.megapath.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" On Wed, Apr 06, 2016 at 01:20:48PM -0700, Hal Murray wrote: > mlichvar@redhat.com said: > > If you don't see the benefits, that's ok. I just thought I should write my > > suggestions and see if anyone agrees with that. > > I think that's an important idea. We need to consider the trade-offs between > security from hiding the real refid compared to the forensic value of being > able to figure out what is or was going on. I agree. > On the other hand, I don't have a handful of stories where it has been > helpful so maybe it isn't really important. Is a warm-fuzzy feeling worth > anything? I think it could be more than just a warm-fuzzy feeling. I think knowing refids up to stratum 1 could be useful for NTP clients to make better decision in the source selection and also for administrators when debugging problems. Harlan referred to mode 6. That's not always available. It's not a part of the current NTPv4 spec (it was optional in the NTPv3 spec) and AFAIK only ntpd implements it. Also, on servers accessible from Internet it's normally disabled as it allows amplification. > mlichvar@redhat.com said: > > I've received reports on loops forming between three peers that were polling > > one another when they stopped receiving time from their upstream sources. I > > was able to reproduce that. It's not a critical issue, but I think it would > > be nice if NTP could prevent that. > > Doesn't that case bump the stratum level each time around the loop until is > falls off the end? It does. The trouble is that unless the servers have a local reference enabled (e.g. orphan mode), they will stuck to stratum 16, 15, ... and will be unusable for clients one, two, ... layers below. As I said, I don't think it's a huge deal, but it would be nice if NTP could prevent that. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 02:40:35 2016 Return-Path: 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 BC62612D125 for ; Thu, 7 Apr 2016 02:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 7CtdUZAUMWOG for ; Thu, 7 Apr 2016 02:40:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id C99E512D0EC for ; Thu, 7 Apr 2016 02:40:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BB20686DC7B for ; Thu, 7 Apr 2016 09:40:31 +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 EC99786DB98 for ; Thu, 7 Apr 2016 09:40:02 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ao6PJ-000PSE-CR for ntpwg@lists.ntp.org; Thu, 07 Apr 2016 09:40:01 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2BA1FD571A; Thu, 7 Apr 2016 09:39:07 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u379WPqQ032046; Thu, 7 Apr 2016 05:32:32 -0400 Date: Thu, 7 Apr 2016 11:32:25 +0200 From: Miroslav Lichvar To: Harlan Stenn Message-ID: <20160407093225.GD20410@localhost> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> <20160406103912.GA11632@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 07 Apr 2016 09:39:07 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , tictoc@ietf.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" On Wed, Apr 06, 2016 at 09:52:29PM +0000, Harlan Stenn wrote: > Miroslav Lichvar writes: > > If the implementation follows the recommendation to change the refid > > randomly, a client can't detect if it's talking to the same server as > > its server for instance. > > I'm not seeing where you think the current proposal is worse in any way. > > As for your response/suggestion, where is this recommendation to change > the refid randomly? Your draft says: A system that decides to send a Suggested REFID extension field SHOULD generate a new Suggested REFID for each new association. I'm assuming this is about client associations distinguished by IP address (ignoring the fact the multiple clients may be behind one address). If the server sends different refids to different clients, the clients won't be able to detect that they are a client of another client of the same server. Older ntpd versions had a check for that. While we may argue about how useful it really is, it will no longer be possible if the suggestion is implemented. > > If the client is fixed to not accept spoofed packets, what exactly the > > attacker can do with that information? > > How can anybody detect that an incoming packet has a forged source > address? The cookie (aka origin timestamp) in the reply doesn't match the request. > > For instance, if the client knew the same stratum 1 server is used by > > multiple stratum 3 servers and they didn't agree with other sources, > > they could be rejected as one assuming the stratum 1 server is bad. > > How would you propose this work in practice? > > This seems to be a special case of a Sybil attack. I think the overhead > this would introduce would be huge and is better addressed elsewhere, by > proper monitoring and having enough upstream servers. It would complicate the selection algorithm, no doubt about that, but that's the choice of the implementation. > > I've received reports on loops forming between three peers that > > were polling one another when they stopped receiving time from their > > upstream sources. I was able to reproduce that. It's not a critical > > issue, but I think it would be nice if NTP could prevent that. > > Were these 3 machines the only source of time? Yes. > Are they set up in orphan mode? No. > What would have happened if this loop had been prevented? Alarms monitoring the synchronisation would not be triggered. The servers would stay in a synchronised state with a real reference and could be used by their clients and clients of their clients for few hours until the upstream servers were reachable again. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 04:48:02 2016 Return-Path: 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 4142412D1A8 for ; Thu, 7 Apr 2016 04:48:02 -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 3bPWFdxIb_xc for ; Thu, 7 Apr 2016 04:48:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 45D8B12D0C6 for ; Thu, 7 Apr 2016 04:48:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 1C55086DC69 for ; Thu, 7 Apr 2016 11:47:59 +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 0535186DB5B for ; Thu, 7 Apr 2016 10:29:11 +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 ) id 1ao7BU-0004zG-FH for ntpwg@lists.ntp.org; Thu, 07 Apr 2016 10:29:11 +0000 Received: by mail-wm0-x236.google.com with SMTP id l6so19085931wml.1 for ; Thu, 07 Apr 2016 03:29: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:cc; bh=7Xe323ZiUSfYcVUHqIl0PcjrJfm7j7/REYPR2uc+65Q=; b=moQO7wjfoOTwvh18uZ9qZTXToNJvY7sU9ulpBbh0ubPk0ujU+9pSiboI8SBybJ7ZWr bYxBRHUN71QgyPHAJEV5WtJ+LcLN2fZ8KLYGKiDQqqxWtdkZCWHDpGs8AFms8jrIkZ/n YIADuXT+XjLYTWQtX7BfXq9gmyXcRzUsJxAC/18Aw56KQqL9D8uAnDq2vIad3wTkCjUX /3jmKABEBZKPLCrxUtZyuzzR4uaPkCWmxmf4/5oFDnxi//FCr2Szk6HXgo6IQaDH4gtQ S/8zxpssBwEjAOAA7CO8lxveLS5igCjKQ1vCooPofuQ+afKkmSb/kq21pfplTXNbJxG4 qLgg== 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:cc; bh=7Xe323ZiUSfYcVUHqIl0PcjrJfm7j7/REYPR2uc+65Q=; b=j11f5qy6xYLceR0MX1taMXdkFTuiYiwsaCxbPtZ9DOd8fz7EuEKVYD2rXHzS/N6isT Aw9uU0d7Fq94MDk9YzyBhXNSagUeP2BocWLwFNzA1XrXAHBWkq8ueTdOCIzo3Zb5hcqw bww1JQC409R+zVBDHaML8BgX9vED+ZC4iiY4Wp8B6V2NwuCVartEtufSYy12mbmn8AI1 c73p27eVZCQpZOtzjcbC/3k5DWhSi7RnTiEsZ41uWdrm1v07TUN+mQn6qcN7wPwJiHdR aeZFBPSaP4LvDBMrheDWyofcgvXnAv2BiS7s1LOuJv0VHgGiPT7M/+WIPrf7Z9a8LsCw ENDQ== X-Gm-Message-State: AD7BkJJC8I4YgRfLyzkpnnX5Jy4qZBuLMslUHMBoXXe8WMiZ+0I2dFe8B6sEu0rGgtUrONEi8r45GSXz64z/LA== X-Received: by 10.28.54.148 with SMTP id y20mr3073247wmh.68.1460024946887; Thu, 07 Apr 2016 03:29:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Thu, 7 Apr 2016 03:28:27 -0700 (PDT) In-Reply-To: <20160407093225.GD20410@localhost> References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> <20160406103912.GA11632@localhost> <20160407093225.GD20410@localhost> From: Sharon Goldberg Date: Thu, 7 Apr 2016 06:28:27 -0400 X-Google-Sender-Auth: 2QwRSil116QKgvFNV82524C07v4 Message-ID: To: NTP Working Group 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] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Matthew Van Gundy , tictoc@ietf.org Content-Type: multipart/mixed; boundary="===============1789015244382505406==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============1789015244382505406== Content-Type: multipart/alternative; boundary=001a1142b68e529239052fe28ce7 --001a1142b68e529239052fe28ce7 Content-Type: text/plain; charset=UTF-8 My proposal is orthogonal to what is being discussed here. I believe it can be implemented alongside Harlan's proposal in suggest-refid. I want to emphasize that my proposal is backwards compatible and can be implemented today without an extension field. Whereas Harlan's idea is super clever but it requires both the client and the server to understand an extension field. First off, to reiterate why I care about this, pretty much all the off-path attacks that we and Cisco have done have the following first step: Query the target client. Get the response. Learn its refID. Now you know the client's server. $Attack the server. (Potentially rinse and repeat if the client moves to another server.) Sure, mode 6 reveals this information but modern NTP configurations should prevent remote IPs from launching mode 6 queries, as it is not only an amplification vector and also leaks state making it easier to attack the system. (See also Cisco's "origin leak" bug [1].) So I do not have a "warm fuzzy" feeling when I see NTP leaking information. Especially since most NTP traffic is not usually cryptographically protected. I think NTP should leak less information, not more. My proposal offers a backwards compatible way for a system to limit the information leaked in its reference ID. It solves the IPv6 refID collision problem. And it seems to be compatible with what NTP is doing today. Some exceptions could be made for stratum 1 servers to broadcast to all clients that your refID is GPS or some other external source, if this really a problem. But we should be sure its really a problem, because information leakage always makes it easier to launch attacks. Much of this discussion has been regarding a future use case in which a client had two IP addresses B and C. This client sends a query from interface B and wants to make sure it is not in a timing loop with another system A who is taking time from interface B. One could deal with this usecase using Harlan's proposal, but this does not preclude my proposal running in parallel. To deal with this, the client "B and C" uses Harlan's extension field to signal "if you take time from me, put this nonce as your refID." If it decided to signal the *same* nonce to all clients, it has explicitly taken on the risk than an attacker can use this information as a first step in an attack, as I have described above. If it signals a different nonce to all clients, then it is protected from this. This non-backwards compatible feature would therefore only be used by systems that need it, eg those that have two IP addresses. All other systems could limit the amount of information being leaked in their refID by using my proposal. Sharon [1] http://www.talosintel.com/reports/TALOS-2016-0078/ --001a1142b68e529239052fe28ce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My proposal is orthogonal to what is b= eing discussed here.=C2=A0=C2=A0 I believe it can be implemented alongside = Harlan's proposal in suggest-refid.

I want to emphasize that my = proposal is backwards compatible and can be implemented today without an ex= tension field.=C2=A0 Whereas Harlan's idea is super clever but it requi= res both the client and the server to understand an extension field.

First off, to reiterate why I care about this, pretty much all the o= ff-path attacks that we and Cisco have done have the following first step:<= br>
Query the target client. Get the response. Learn its refID. No= w you know the client's server. $Attack the server. (Potentially rinse = and repeat if the client moves to another server.)

Sure, = mode 6 reveals this information but modern NTP configurations should preven= t remote IPs from launching mode 6 queries, as it is not only an amplificat= ion vector and also leaks state making it easier to attack the system.=C2= =A0 (See also Cisco's "origin leak" bug [1].)=C2=A0 So I do n= ot have a "warm fuzzy" feeling when I see NTP leaking information= . Especially since most NTP traffic is not usually cryptographically protec= ted.=C2=A0 I think NTP should leak less information, not more.

My proposal offers a backwards compatible way for a system to limit t= he information leaked in its reference ID. It solves the IPv6 refID collisi= on problem.=C2=A0 And it seems to be compatible with what NTP is doing toda= y.

Some exceptions could be made for stratum 1= servers=20 to broadcast to all clients that your refID is GPS or some other=20 external source, if this really a problem.=C2=A0 But we should be sure its= =20 really a problem, because information leakage always makes it easier to=20 launch attacks.

Much of this discussion has been regardi= ng a future use case in which a client had two IP addresses B and C.=C2=A0= =C2=A0 This client sends a query from interface B and wants to make sure it is not in a timing loop with another system A who is taking time from=20 interface B.=C2=A0

One could deal with this usecase using Harlan= 9;s proposal, but this does not preclude my proposal running in parallel.= =C2=A0 To deal with this, the client "B and C"=C2=A0 uses Harlan&= #39;s extension field to signal "if you take time from me, put this no= nce as your refID."=C2=A0=C2=A0 If it decided to signal the *same* non= ce to all clients, it has explicitly taken on the risk than an attacker can= use this information as a first step in an attack, as I have described abo= ve.=C2=A0 If it signals a different nonce to all clients, then it is protec= ted from this.

This non-backwards compatible feature would t= herefore only be used by systems that need it, eg those that have two IP ad= dresses. All other systems could limit the amount of information being leak= ed in their refID by using my proposal.
--001a1142b68e529239052fe28ce7-- --===============1789015244382505406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1789015244382505406==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 06:13:04 2016 Return-Path: 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 54E1D12D95A for ; Thu, 7 Apr 2016 06:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 5BNPykmJtcNq for ; Thu, 7 Apr 2016 06:13:02 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id BDCB212D95F for ; Thu, 7 Apr 2016 06:12:56 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B291686DC9F for ; Thu, 7 Apr 2016 13:12:56 +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 08CE286DB70 for ; Thu, 7 Apr 2016 12:14:59 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ao8pl-0006S7-Ar for ntpwg@lists.ntp.org; Thu, 07 Apr 2016 12:14:59 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7A53280088 for ; Thu, 7 Apr 2016 12:14:48 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u37CElwa029188 for ; Thu, 7 Apr 2016 08:14:47 -0400 Date: Thu, 7 Apr 2016 14:14:47 +0200 From: Miroslav Lichvar To: ntpwg@lists.ntp.org Message-ID: <20160407121447.GE20410@localhost> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" I've few quick comments and questions on the new drafts. I can expand on that later if there is any interest. draft-mayer-ntp-mac-extension-field-00 - I'm not sure if hiding the length of the MAC using padding with random data is really useful. This was discussed before. The attacker can search for the key in parallel using all hash functions. As their number is very small, the slowdown is insignificant. - Instead of hiding the hash function, I think it might be more useful to specify it directly in the field to allow easier debugging when the authentication fails. The MAC length field could be shortened to one octet and the other octet could specify the key type, allowing 256 different types. - In order to save bandwidth with functions producing long digests, they could be truncated to some fixed size, like NTS already does in its MAC extension field. Is 128 bits enough? - MACs could be treated as opaque data, not requiring symmetric keys with 32-bit key IDs. This would allow storing MACs from new authentication schemes and they wouldn't need a new extension field, just a new MAC type for this extension field. draft-stenn-ntp-i-do-00 - The draft mentions negotiation. Is the server required to keep a state of what the client supports? I'd expect it to be a purely informational field that doesn't change over time. - It's not clear to me why there needs to be a "MAC required" bit and why it should be specified in this draft. This was discussed before, but I've not seen any conclusion. draft-stenn-ntp-ipv6-refid-hash-00 - The idea was discussed several times before. It doesn't make much sense to me. - In order to avoid conflicts with refids based on IPv4 addresses it makes conflicts between refids based on IPv6 more likely. Why should be IPv4 special? The world is quickly moving to IPv6. - It's an incompatible change making assumptions about how the refid is used in clients. draft-stenn-ntp-leap-smear-refid-00 - I don't think the refid field in NTP packet is a good place to store an offset. - The refid will conflict with 1/256 of refids based on IPv6. Even if the IPv6 refid draft that shrinks the space for IPv6 refids to 24 bits is accepted, it will take some time before it's used. - This should rather be a new extension field, maybe in a more general form that allows different time scales and their offset to UTC to be specified. draft-stenn-ntp-suggest-refid-00 - Again, the "required MAC" bit in the field type doesn't seem useful. - I'd suggest to use all bits of the refid (not fix the first octet to 0xfd) to make collisions less likely. - The extension field could be extended to contain also refids of upstream servers (obtained with this extension). - Instead of hiding the real refid, I'd rather see servers to use this extension field to announce the same refid to all clients in order to allow them to detect multihomed hosts and duplicates in paths to their stratum 1 sources. This is discussed in the other thread. draft-stenn-ntp-last-extension-00 - Field length of 4 is currently not valid in NTP packets. The minimum length is 16 and there are special rules for the last extension field. Is there a plan to relax these requirements? (It would be an incompatible change.) - Will be this extension field useful when the new MAC extension field is ready? It looks like they have a similar purpose. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 10:53:24 2016 Return-Path: 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 53A5612D60C for ; Thu, 7 Apr 2016 10:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 MeQFUNPPlXAF for ; Thu, 7 Apr 2016 10:53:20 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1E09812D5F4 for ; Thu, 7 Apr 2016 10:53:20 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id F310886DCBA for ; Thu, 7 Apr 2016 17:53:19 +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 D0F8486DB77 for ; Thu, 7 Apr 2016 17:48:33 +0000 (UTC) Received: from chessie.everett.org ([66.220.13.234]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aoE2Y-000BQo-Pv for ntpwg@lists.ntp.org; Thu, 07 Apr 2016 17:48:33 +0000 Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id 7DE1CB830 for ; Thu, 7 Apr 2016 17:48:22 +0000 (UTC) Received: from [10.2.64.150] (unknown [198.22.153.36]) by chessie.everett.org (Postfix) with ESMTPSA id BE6CAB80E; Thu, 7 Apr 2016 17:48:19 +0000 (UTC) References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> <20160406103912.GA11632@localhost> <20160407093225.GD20410@localhost> To: Sharon Goldberg , NTP Working Group From: Danny Mayer Message-ID: <57069D6A.8030407@pdmconsulting.net> Date: Thu, 7 Apr 2016 13:48:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Apr 7 17:48:22 2016 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 6384,57069d66829932714613156 X-SA-Exim-Connect-IP: 66.220.13.234 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mayer@pdmconsulting.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mayer@pdmconsulting.net Cc: Matthew Van Gundy , tictoc@ietf.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" On 4/7/2016 6:28 AM, Sharon Goldberg wrote: > > This non-backwards compatible feature would therefore only be used by > systems that need it, eg those that have two IP addresses. All other > systems could limit the amount of information being leaked in their > refID by using my proposal. > The number of systems that don't have multiple addresses these days can probably be counted on one hand. All newer O/S's support both IPv4 and IPv6 addresses. Furthermore NTP has broadcast and multicast modes so packets can also arrive over those addresses as well. Harlan and I had a discussion on this yesterday and now I remember why the current preferred server's address is being used in the refID. At the time it was implemented it was meant to prevent timing loops and security was not a worry. In today's world that's the primary worry. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 11:23:50 2016 Return-Path: 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 89F2812D0DA for ; Thu, 7 Apr 2016 11:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 BigAFAZxqrUC for ; Thu, 7 Apr 2016 11:23:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 06E3712D68D for ; Thu, 7 Apr 2016 11:23:43 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BDC9186DC96 for ; Thu, 7 Apr 2016 18:23:42 +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 85F0E86DB31 for ; Wed, 6 Apr 2016 19:55:47 +0000 (UTC) Received: from [58.251.152.64] (helo=szxga01-in.huawei.com) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1antYB-000CiN-Hf for ntpwg@lists.ntp.org; Wed, 06 Apr 2016 19:55:47 +0000 Received: from 172.24.1.136 (EHLO szxema411-hub.china.huawei.com) ([172.24.1.136]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIG23021; Thu, 07 Apr 2016 03:55:08 +0800 (CST) Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.160]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Thu, 7 Apr 2016 03:54:54 +0800 From: Jiangyuanlong To: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Thread-Topic: Non-WG Mailing List: Scsn -- Scalable Clock Synchronization Network- Discussion of Scalable Clock Synchronization Network Thread-Index: AdGQPZcXxcd0J3IJRve4Kx7p/ZDHxg== Date: Wed, 6 Apr 2016 19:54:53 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B91686D4B@szxema506-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.56] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5705699D.0044, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a752f2a3c5dbc14de4445e7793634b7d X-SA-Exim-Connect-IP: 58.251.152.64 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: jiangyuanlong@huawei.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Thu, 07 Apr 2016 18:23:28 +0000 Subject: [ntpwg] Non-WG Mailing List: Scsn -- Scalable Clock Synchronization Network- Discussion of Scalable Clock Synchronization Network X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" Hi NTPers and TICTOCers, You may have interest to join the SCSN mailing list, which is allocated to discuss the Scalable Clock Synchronization Network. Following is the SCSN list information: A new IETF non-working group email list has been created. List address: scsn@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=scsn To subscribe: https://www.ietf.org/mailman/listinfo/scsn Purpose: The purpose of this mailing list is to discuss the operational and management challenges found in large-scale clock synchronization networks. There appear to be challenges in configuring, determining faults within, and monitoring the performance of such networks. Several examples of a large-scale clock synchronization network include mobile backhaul networks, industrial automation networks, and utility networks. Typically these networks employ IEEE 1588v2 and SyncE, which have been widely deployed in existing networks. The goal of these discussions is to determine if there is IETF-related work needed to improve the management and operation of these clock synchronization networks. Regards, Yuanlong _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 11:39:04 2016 Return-Path: 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 5DCE212D6BD for ; Thu, 7 Apr 2016 11:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 s0NB6t63UezV for ; Thu, 7 Apr 2016 11:38:58 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA0E12D69B for ; Thu, 7 Apr 2016 11:38:34 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 0968E86DC80 for ; Thu, 7 Apr 2016 18:38:34 +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 E772286DAB2 for ; Thu, 7 Apr 2016 18:31:17 +0000 (UTC) Received: from [198.22.153.36] (helo=[10.2.64.150]) by mail1.ntp.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aoEi3-000C7G-0C; Thu, 07 Apr 2016 18:31:16 +0000 From: Danny Mayer References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> <20160406103912.GA11632@localhost> <20160407093225.GD20410@localhost> To: Sharon Goldberg , NTP Working Group Organization: NTP Message-ID: <5706A779.8030505@ntp.org> Date: Thu, 7 Apr 2016 14:31:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 198.22.153.36 X-SA-Exim-Rcpt-To: tictoc@ietf.org, mvangund@cisco.com, mlichvar@redhat.com, ntpwg@lists.ntp.org, goldbe@cs.bu.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mayer@ntp.org Cc: Matthew Van Gundy , tictoc@ietf.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" On 4/7/2016 6:28 AM, Sharon Goldberg wrote: > > This non-backwards compatible feature would therefore only be used by > systems that need it, eg those that have two IP addresses. All other > systems could limit the amount of information being leaked in their > refID by using my proposal. > The number of systems that don't have multiple addresses these days can probably be counted on one hand. All newer O/S's support both IPv4 and IPv6 addresses. Furthermore NTP has broadcast and multicast modes so packets can also arrive over those addresses as well. Harlan and I had a discussion on this yesterday and now I remember why the current preferred server's address is being used in the refID. At the time it was implemented it was meant to prevent timing loops and security was not a worry. In today's world that's the primary worry. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 11:53:45 2016 Return-Path: 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 99CA112D6BE for ; Thu, 7 Apr 2016 11:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 N2Su3ACh4txS for ; Thu, 7 Apr 2016 11:53:42 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9812D6B2 for ; Thu, 7 Apr 2016 11:53:42 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B390B86DC8B for ; Thu, 7 Apr 2016 18:53:42 +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 2CC4486DAB2 for ; Thu, 7 Apr 2016 18:53:03 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1aoF39-0005oO-6j; Thu, 07 Apr 2016 18:53:03 +0000 From: Harlan Stenn To: Sharon Goldberg In-reply-to: References: <57040B4A.4090301@pdmconsulting.net> <570411C0.7000004@ntp.org> <20160406084046.GB9802@localhost> <20160406103912.GA11632@localhost> <20160407093225.GD20410@localhost> Comments: In-reply-to Sharon Goldberg message dated "Thu, 07 Apr 2016 06:28:27 -0400." 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, 07 Apr 2016 18:53:02 +0000 Message-Id: Subject: Re: [ntpwg] [TICTOC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group , Matthew Van Gundy , tictoc@ietf.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" Sharon Goldberg writes: > My proposal is orthogonal to what is being discussed here. I believe it > can be implemented alongside Harlan's proposal in suggest-refid. Agreed. > I want to emphasize that my proposal is backwards compatible and can be > implemented today without an extension field. Whereas Harlan's idea is > super clever but it requires both the client and the server to understand > an extension field. > > First off, to reiterate why I care about this, pretty much all the off-path > attacks that we and Cisco have done have the following first step: > > Query the target client. Get the response. Learn its refID. Now you know > the client's server. $Attack the server. (Potentially rinse and repeat if > the client moves to another server.) The bad guy can impersonate the client and "vex" the server, and the bad guy can also impersonate the server and "vex" the client. > Sure, mode 6 reveals this information but modern NTP configurations should > prevent remote IPs from launching mode 6 queries, as it is not only an > amplification vector and also leaks state making it easier to attack the > system. (See also Cisco's "origin leak" bug [1].) So I do not have a > "warm fuzzy" feeling when I see NTP leaking information. Especially since > most NTP traffic is not usually cryptographically protected. I think NTP > should leak less information, not more. > > My proposal offers a backwards compatible way for a system to limit the > information leaked in its reference ID. It solves the IPv6 refID collision > problem. And it seems to be compatible with what NTP is doing today. > > Some exceptions could be made for stratum 1 servers to broadcast to all > clients that your refID is GPS or some other external source, if this > really a problem. But we should be sure its really a problem, because > information leakage always makes it easier to launch attacks. The refid changes affect S2+ only, we'd leave S1 refids alone. > Much of this discussion has been regarding a future use case in which a > client had two IP addresses B and C. This client sends a query from > interface B and wants to make sure it is not in a timing loop with another > system A who is taking time from interface B. The timing loop issue has 2 aspects (at least). I'll talk about one of them now. One reason to avoid a timing loop has to do with sailing off into the weeds. I'm not sure how significant this case is anymore. If I only have 1 source of time, well, we know what that means. If that source of time only has me as their source of time then the timing loop stuff means we'll detect this immedately and we'll both go out-of-sync. But if we do not detect this loop, if A is at S2 then B is at S3. When we're down to no additional sources of time, at that point A will become S4 and B will be come S5, then it goes to S6/S7, ... until the machines go out of sync. In this case that will happen in 6 poll intervals. If there are no other sources of time available, then is it significant that the machines go out of sync after 1 or 2 poll intervals instead of 6? I'm using round numbers here. A semblance of order would be in place if the boxes were configured using orphan mode, or even local refclocks. So I'd really like to know exactly what the concerns are about this particular "failure mode". H -- > One could deal with this usecase using Harlan's proposal, but this does not > preclude my proposal running in parallel. To deal with this, the client "B > and C" uses Harlan's extension field to signal "if you take time from me, > put this nonce as your refID." If it decided to signal the *same* nonce > to all clients, it has explicitly taken on the risk than an attacker can > use this information as a first step in an attack, as I have described > above. If it signals a different nonce to all clients, then it is > protected from this. > > This non-backwards compatible feature would therefore only be used by > systems that need it, eg those that have two IP addresses. All other > systems could limit the amount of information being leaked in their refID > by using my proposal. > > Sharon > > [1] http://www.talosintel.com/reports/TALOS-2016-0078/ > > --001a1142b68e529239052fe28ce7 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >
My proposal is orthogonal to what is b= > eing discussed here.=C2=A0=C2=A0 I believe it can be implemented alongside = > Harlan's proposal in suggest-refid.

I want to emphasize that my = > proposal is backwards compatible and can be implemented today without an ex= > tension field.=C2=A0 Whereas Harlan's idea is super clever but it requi= > res both the client and the server to understand an extension field.
iv>
First off, to reiterate why I care about this, pretty much all the o= > ff-path attacks that we and Cisco have done have the following first step:<= > br>
Query the target client. Get the response. Learn its refID. No= > w you know the client's server. $Attack the server. (Potentially rinse = > and repeat if the client moves to another server.)

Sure, = > mode 6 reveals this information but modern NTP configurations should preven= > t remote IPs from launching mode 6 queries, as it is not only an amplificat= > ion vector and also leaks state making it easier to attack the system.=C2= > =A0 (See also Cisco's "origin leak" bug [1].)=C2=A0 So I do n= > ot have a "warm fuzzy" feeling when I see NTP leaking information= > . Especially since most NTP traffic is not usually cryptographically protec= > ted.=C2=A0 I think NTP should leak less information, not more.

>
My proposal offers a backwards compatible way for a system to limit t= > he information leaked in its reference ID. It solves the IPv6 refID collisi= > on problem.=C2=A0 And it seems to be compatible with what NTP is doing toda= > y.

Some exceptions could be made for stratum 1= > servers=20 > to broadcast to all clients that your refID is GPS or some other=20 > external source, if this really a problem.=C2=A0 But we should be sure its= > =20 > really a problem, because information leakage always makes it easier to=20 > launch attacks.

Much of this discussion has been regardi= > ng a future use case in which a client had two IP addresses B and C.=C2=A0= > =C2=A0 This client sends a query from interface B and wants to make sure it > is not in a timing loop with another system A who is taking time from=20 > interface B.=C2=A0

One could deal with this usecase using Harlan= > 9;s proposal, but this does not preclude my proposal running in parallel.= > =C2=A0 To deal with this, the client "B and C"=C2=A0 uses Harlan&= > #39;s extension field to signal "if you take time from me, put this no= > nce as your refID."=C2=A0=C2=A0 If it decided to signal the *same* non= > ce to all clients, it has explicitly taken on the risk than an attacker can= > use this information as a first step in an attack, as I have described abo= > ve.=C2=A0 If it signals a different nonce to all clients, then it is protec= > ted from this.

This non-backwards compatible feature would t= > herefore only be used by systems that need it, eg those that have two IP ad= > dresses. All other systems could limit the amount of information being leak= > ed in their refID by using my proposal.
> > --001a1142b68e529239052fe28ce7-- > > --===============5243542199967168099== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > --===============5243542199967168099==-- > _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 14:23:55 2016 Return-Path: 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 A2B2312D725 for ; Thu, 7 Apr 2016 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 DxlqAX26PNBh for ; Thu, 7 Apr 2016 14:23:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 49EA312D718 for ; Thu, 7 Apr 2016 14:23:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 0D3BF86DC86 for ; Thu, 7 Apr 2016 21:23:52 +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 C5B9E86DC77 for ; Thu, 7 Apr 2016 21:16:27 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1aoHHv-0005vf-03; Thu, 07 Apr 2016 21:16:27 +0000 From: Harlan Stenn To: Miroslav Lichvar In-reply-to: <20160407121447.GE20410@localhost> References: <20160407121447.GE20410@localhost> Comments: In-reply-to Miroslav Lichvar message dated "Thu, 07 Apr 2016 14:14:47 +0200." 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, 07 Apr 2016 21:16:26 +0000 Message-Id: Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" Miroslav Lichvar writes: > I've few quick comments and questions on the new drafts. I can expand > on that later if there is any interest. > > draft-mayer-ntp-mac-extension-field-00 > - I'm not sure if hiding the length of the MAC using padding with > random data is really useful. This was discussed before. The > attacker can search for the key in parallel using all hash > functions. As their number is very small, the slowdown is > insignificant. Doing this is a local policy choice. If you don't want to do it, then don't. > - Instead of hiding the hash function, I think it might be more useful > to specify it directly in the field to allow easier debugging when > the authentication fails. The MAC length field could be shortened to > one octet and the other octet could specify the key type, allowing > 256 different types. I see the cost of advertising the hash function. I don't see the benefit to advertising the hash function. If there's a failure, that should be a very rare event and it should be obvious how to fix it. It should also be possible to provide the hash function with a mode 6 query, so authenticated folks can see the hash algorithm. If the hash function is communicated, I think there are probably better ways to convey that information besides trying to save 1 byte. I have no opinion as to whether or not we should limit the size of the hash to ~256 bytes (if I understood that part correctly). > - In order to save bandwidth with functions producing long digests, > they could be truncated to some fixed size, like NTS already does in > its MAC extension field. Is 128 bits enough? I'd like to see a clear and complete analysis of the costs and benefits. Doing this is certainly an option. > - MACs could be treated as opaque data, not requiring symmetric keys > with 32-bit key IDs. This would allow storing MACs from new > authentication schemes and they wouldn't need a new extension field, > just a new MAC type for this extension field. I don't understand "... they wouldn't need a new extension field, just a new MAC type for this extension field." The existing and new MAC proposals don't need any changes for new authentication schemes, from what I can see. > draft-stenn-ntp-i-do-00 > - The draft mentions negotiation. Is the server required to keep a > state of what the client supports? I'd expect it to be a purely > informational field that doesn't change over time. If no state is kept then traditional v4 behavior should be used. If there is a "peer" structure of some sort, then it's easy to keep a bit of state. But again, this is a local policy choice. And yes, this information may change over time, and either side can re-issue this exchange. Two obvious reasons why this might happen include "Now that we have completed an NTS negotiation, I see that you qualify for additional authorizations, so I-Do the follwing, if you are interested", and "Gee, I restarted. I don't remember what we agreed to before." > - It's not clear to me why there needs to be a "MAC required" bit and > why it should be specified in this draft. This was discussed before, > but I've not seen any conclusion. We've had MACs from before we had the first EF. When autokey arrived, it *required* a MAC. Many years' later, we have now just added an experimental EF that says "there MUST NOT be a MAC." The bit is "MAC OPTIONAL", not "MAC REQUIRED". The use of this bit is backward-compatible with the original behavior. > draft-stenn-ntp-ipv6-refid-hash-00 > - The idea was discussed several times before. It doesn't make much > sense to me. Then don't implement it, and don't announce that you support it in I-Do exchanges. > - In order to avoid conflicts with refids based on IPv4 addresses it > makes conflicts between refids based on IPv6 more likely. Why should > be IPv4 special? The world is quickly moving to IPv6. It uses an initial octet that CANNOT appear as a source address, so your argument that it "makes conflicts between refids based on IPv6 more likely" seems ... wrong to me, at least for IPv4-based refids. For IPv6 refids I think we'd only get a false-positive response in this case. And again, this doesn't happen if both sides implement I-Do. *If* you want to use traditional S2+ refids instead of Sharon's "Not You" refid, or my suggested-refid, then fine, do that. If you are OK with the current setup, then fine, use that. If you don't want to implement this, then don't. As I recall, it was 2 trivial lines of code to make this work on each side, "sending it", and "is that what I got". Oh, if "The world is quickly moving to IPv6" and the assumption is that IPv4 will die off soon, then it shouldn't be too long before more folks upgrade their NTP software. :) > - It's an incompatible change making assumptions about how the refid > is used in clients. It's easy enough to control when it's used if that's important. And the cost if one side doesn't implement it is not huge, it's a timing loop where each side will increase its stratum every poll. This is a "self-correcting" problem, in the rare event it happens. As more software gets upgraded, more systems can be expected to implement I-Do and then this situation can be better detected. > draft-stenn-ntp-leap-smear-refid-00 > - I don't think the refid field in NTP packet is a good place to store > an offset. Where else can it go that it's obvious, visible, and almost totally backward-compatible? > - The refid will conflict with 1/256 of refids based on IPv6. Even if > the IPv6 refid draft that shrinks the space for IPv6 refids to 24 > bits is accepted, it will take some time before it's used. Only for client mode associations at the ~S3 level, that do not choose to implement any of the other proposals around I-Do and refids. What do you propose as an alternative for servers that want to offer smeared time to clients? > - This should rather be a new extension field, maybe in a more general > form that allows different time scales and their offset to UTC to be > specified. Feel free to propose that as an alternative. I specifically chose what I did because it's very good at being backward-compatible and it's very visible. Putting the offset in an EF means clients that don't understand the EF will either drop the packet completely (a clear lose) or won't know what to do with it. Running ntpq -p will not show that the system is following a leap-smeared system peer. These limitations are show-stoppers, in my book. This issue is *all* about backward-compatibility in the face of people running out-of-date software. > draft-stenn-ntp-suggest-refid-00 > - Again, the "required MAC" bit in the field type doesn't seem useful. Again, what I wrote above. The bit says "MAC OPTIONAL", and is backward-compatible. > - I'd suggest to use all bits of the refid (not fix the first octet to > 0xfd) to make collisions less likely. Your suggestion is backwards-incompatible. We have already seen reports of the IPv6 hash returing a value that matches the IPv4 address of a *different IPv4 host on the same network as the IPv6 host*. Refids are there for 1-degree loop detection, not "who is my upstream server". > - The extension field could be extended to contain also refids of > upstream servers (obtained with this extension). Out-of-scope for this proposal, and of unproven value. > - Instead of hiding the real refid, I'd rather see servers to use this > extension field to announce the same refid to all clients in order > to allow them to detect multihomed hosts and duplicates in paths to > their stratum 1 sources. This is discussed in the other thread. It's not hiding the real refid. The primary reason for the refid is to detect degree-1 timing loops. There are other ways to do this, and providing information about the identity of "other servers involved with time exchange" creates security problems. > draft-stenn-ntp-last-extension-00 > - Field length of 4 is currently not valid in NTP packets. The minimum > length is 16 and there are special rules for the last extension > field. Is there a plan to relax these requirements? (It would be > an incompatible change.) Then don't use it unless it's agreeable based on I-Do. If it's agreeable then it's OK to use it. > - Will be this extension field useful when the new MAC extension field > is ready? It looks like they have a similar purpose. Yes. If nothing else, it can be useful for broadcast situations where some clients may not understand MAC-EF but do understand a legacy MAC. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 15:24:54 2016 Return-Path: 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 BB2CF12D6E6 for ; Thu, 7 Apr 2016 15:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.29 X-Spam-Level: X-Spam-Status: No, score=-5.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 m4FJa9rv5vQB for ; Thu, 7 Apr 2016 15:24:47 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id AE97F12D5E7 for ; Thu, 7 Apr 2016 15:24:47 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A7CED86DCB9 for ; Thu, 7 Apr 2016 22:24:47 +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 50AD686DC8D for ; Thu, 7 Apr 2016 21:29:15 +0000 (UTC) Received: from userp1040.oracle.com ([156.151.31.81]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aoHU8-000EeQ-3E; Thu, 07 Apr 2016 21:29:15 +0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u37LT0Ch011229 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 21:29:01 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u37LSx9t017949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 21:29:00 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u37LSxP0024762; Thu, 7 Apr 2016 21:28:59 GMT Received: from [10.154.190.199] (/10.154.190.199) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Apr 2016 14:28:59 -0700 To: Harlan Stenn , Miroslav Lichvar References: <20160407121447.GE20410@localhost> From: brian utterback Organization: Oracle Corporation Message-ID: <5706D119.50707@oracle.com> Date: Thu, 7 Apr 2016 17:28:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-SA-Exim-Connect-IP: 156.151.31.81 X-SA-Exim-Rcpt-To: stenn@ntp.org, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: brian.utterback@oracle.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org Content-Type: multipart/mixed; boundary="===============2888162997167941659==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" This is a multi-part message in MIME format. --===============2888162997167941659== Content-Type: multipart/alternative; boundary="------------000101090904080005090004" This is a multi-part message in MIME format. --------------000101090904080005090004 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 4/7/2016 5:16 PM, Harlan Stenn wrote: > And yes, this information may change over time, and either side can > re-issue this exchange. Two obvious reasons why this might happen > include "Now that we have completed an NTS negotiation, I see that you > qualify for additional authorizations, so I-Do the follwing, if you are > interested", and "Gee, I restarted. I don't remember what we agreed to > before." I saw the I-Do also as a possible request function if the extension only works in one direction. That is something like "I understand X and would like to get one if you support it". -- Oracle Brian Utterback | Principle Software Engineer Phone: +1 6038973049 Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 ------------------------------------------------------------------------ All working systems eventually start to exhibit their own agenda ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment --------------000101090904080005090004 Content-Type: multipart/related; boundary="------------080101020200010102000804" --------------080101020200010102000804 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On 4/7/2016 5:16 PM, Harlan Stenn wrote:
And yes, this information may change over time, and either side can
re-issue this exchange.  Two obvious reasons why this might happen
include "Now that we have completed an NTS negotiation, I see that you
qualify for additional authorizations, so I-Do the follwing, if you are
interested", and "Gee, I restarted.  I don't remember what we agreed to
before."

I saw the I-Do also as a possible request function if the extension only works in one direction. That is something like "I understand X and would like to get one if you support it".
--
Oracle
Brian Utterback | Principle Software Engineer
Phone: +1 6038973049
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
All working systems eventually start to exhibit their own agenda
Green Oracle Oracle is committed to developing practices and products that help protect the environment
--------------080101020200010102000804 Content-Type: image/gif; name="oracle_sig_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oracle_sig_logo.gif" R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9A QP/AwP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPV IDfcOQa6A8yRaO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1n BGRmhl8AWiUJYicCAIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4 AAunsqg/dw95KwdfBgzBqKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1It xK7aKl8lCl8DAfALW1+2rUi3QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyI qRgMcA8a/z5AZQWXOxEdHxwUgfIgsX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjU mYLnomokcDlS4s0eFzQNqvXDEyzmAwFPyaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpF RxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt 1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvPm8OVEkAIYLYPThSsRIpEQJr1x94QBIT0 9FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8ABijggAQWaOCBCCao4A+CDDbo4IMQ RijhhBQKGAIAOw== --------------080101020200010102000804 Content-Type: image/gif; name="green-for-email-sig_0.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="green-for-email-sig_0.gif" R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zP uZu2lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxj SYdrOp/Q6NPgYqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMq DwFCAAIFPIYDgidrOUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQG BH82TpMicD0pAgQACToDAchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLD LS8MAvf497ruCZ+gOA0gfNt3AIK0J/JWKVzIsEQIADs= --------------080101020200010102000804-- --------------000101090904080005090004-- --===============2888162997167941659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============2888162997167941659==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 7 16:06:41 2016 Return-Path: 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 0E09C12D580 for ; Thu, 7 Apr 2016 16:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 TYx0W9rfC5IM for ; Thu, 7 Apr 2016 16:06:39 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7412D12E for ; Thu, 7 Apr 2016 16:06:39 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 5186986DCC8 for ; Thu, 7 Apr 2016 23:06:39 +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 AAEBB86D48C for ; Thu, 7 Apr 2016 21:49:13 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1aoHlB-0005xx-DI; Thu, 07 Apr 2016 21:46:41 +0000 From: Harlan Stenn To: brian utterback In-reply-to: <5706D119.50707@oracle.com> References: <20160407121447.GE20410@localhost> <5706D119.50707@oracle.com> Comments: In-reply-to brian utterback message dated "Thu, 07 Apr 2016 17:28:57 -0400." 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, 07 Apr 2016 21:46:41 +0000 Message-Id: Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" Hi Brian, brian utterback writes: > On 4/7/2016 5:16 PM, Harlan Stenn wrote: >> And yes, this information may change over time, and either side can >> re-issue this exchange. Two obvious reasons why this might happen >> include "Now that we have completed an NTS negotiation, I see that >> you qualify for additional authorizations, so I-Do the follwing, if >> you are interested", and "Gee, I restarted. I don't remember what we >> agreed to before." > > I saw the I-Do also as a possible request function if the extension only > works in one direction. That is something like "I understand X and would > like to get one if you support it". The way I intend to implement it and the way I see it being used is: I Send: I-Do: A, B, D You Reply: nothing at all This probably means either a dropped packet, one direction or the other, or "you" dropped the packet because of an unrecognized EF. We'd continue using stock NTPv4. You Reply: normal response This is taken to mean "I don't understand what you are offering" so we'd use stock NTPv4. You Reply: I-Do-Response: A, D This means that you and I have agreed that A and D are good to use. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 8 01:58:20 2016 Return-Path: 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 48FBC12D672 for ; Fri, 8 Apr 2016 01:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 pIiTPjw4h6FA for ; Fri, 8 Apr 2016 01:58:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 961C612D667 for ; Fri, 8 Apr 2016 01:58:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 77C5886DCC8 for ; Fri, 8 Apr 2016 08:58:18 +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 4F2E886DB0C for ; Fri, 8 Apr 2016 08:57:41 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aoSEK-0001sF-Vu for ntpwg@lists.ntp.org; Fri, 08 Apr 2016 08:57:41 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 808C2627C2; Fri, 8 Apr 2016 08:57:27 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u388vQYE022957; Fri, 8 Apr 2016 04:57:26 -0400 Date: Fri, 8 Apr 2016 10:57:26 +0200 From: Miroslav Lichvar To: Harlan Stenn Message-ID: <20160408085726.GA13598@localhost> References: <20160407121447.GE20410@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 08 Apr 2016 08:57:27 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Thu, Apr 07, 2016 at 09:16:26PM +0000, Harlan Stenn wrote: > Miroslav Lichvar writes: > > draft-mayer-ntp-mac-extension-field-00 > > - Instead of hiding the hash function, I think it might be more useful > > to specify it directly in the field to allow easier debugging when > > the authentication fails. The MAC length field could be shortened to > > one octet and the other octet could specify the key type, allowing > > 256 different types. > > I see the cost of advertising the hash function. I don't see the > benefit to advertising the hash function. If there's a failure, that > should be a very rare event and it should be obvious how to fix it. Beside knowing which hash function was used in the MAC, the type field will allow other MACs in the field, not just those used by authentication with symmetric keys. > If the hash function is communicated, I think there are probably better > ways to convey that information besides trying to save 1 byte. If you want to keep the data aligned to 4 octets and not waste too much space, what else do you propose? > I have no opinion as to whether or not we should limit the size of the > hash to ~256 bytes (if I understood that part correctly). The size could be specified in multiplies of 4, if you think 256 is not enough. I don't. > > - MACs could be treated as opaque data, not requiring symmetric keys > > with 32-bit key IDs. This would allow storing MACs from new > > authentication schemes and they wouldn't need a new extension field, > > just a new MAC type for this extension field. > > I don't understand "... they wouldn't need a new extension field, just a > new MAC type for this extension field." The NTS MAC could be stored in this field for instance, it doesn't have to be a new extension field. If you had multiple MACs in this field packet, they would be independent. Their order wouldn't change the result, the second MAC wouldn't have to include the first one, the third MAC wouldn't need to include the first and second one, and so on. > > draft-stenn-ntp-i-do-00 > > - It's not clear to me why there needs to be a "MAC required" bit and > > why it should be specified in this draft. This was discussed before, > > but I've not seen any conclusion. > > We've had MACs from before we had the first EF. When autokey arrived, > it *required* a MAC. Many years' later, we have now just added an > experimental EF that says "there MUST NOT be a MAC." That information is included in the specification of the field. How will that bit change behaviour of an implementation that doesn't understand the field? It would be great if you could give an example of a difference in the processing of the packet when this bit is set and not set. > > draft-stenn-ntp-ipv6-refid-hash-00 > > - The idea was discussed several times before. It doesn't make much > > sense to me. > > Then don't implement it, and don't announce that you support it in I-Do > exchanges. If I don't implement it, I won't be able to detect loops with servers that do implement it. This is not an optional feature as I understand it. It changes the definition of the refid field in the NTPv4 packets and everyone has to deal with it. > > - In order to avoid conflicts with refids based on IPv4 addresses it > > makes conflicts between refids based on IPv6 more likely. Why should > > be IPv4 special? The world is quickly moving to IPv6. > > It uses an initial octet that CANNOT appear as a source address, so > your argument that it "makes conflicts between refids based on IPv6 more > likely" seems ... wrong to me, at least for IPv4-based refids. I mean conflict between two refids generated from two different IPv6 addresses. Your proposal prevents a conflict between IPv6 refids and IPv4 refids, but at a cost that there will be more conflicts between IPv6 refids. The 32-bit IPv4 space would be mapped to 32 bits in refid, but the 128-bit IPv6 space only to 24 bits. Don't you see the problem? > > draft-stenn-ntp-leap-smear-refid-00 > > - I don't think the refid field in NTP packet is a good place to store > > an offset. > > Where else can it go that it's obvious, visible, and almost totally > backward-compatible? I think the reference timestamp would be a much better choice. > > - The refid will conflict with 1/256 of refids based on IPv6. Even if > > the IPv6 refid draft that shrinks the space for IPv6 refids to 24 > > bits is accepted, it will take some time before it's used. > > Only for client mode associations at the ~S3 level, that do not choose > to implement any of the other proposals around I-Do and refids. That includes all old implementations, right? I.e. the target of the proposal? > What do you propose as an alternative for servers that want to offer > smeared time to clients? If you need to see the fact that the server is leap smearing in the ntpq output in the refid field, pick a constant value for refid and don't encode the offset. That's what I did in chrony. > > draft-stenn-ntp-suggest-refid-00 > > - Again, the "required MAC" bit in the field type doesn't seem useful. > > Again, what I wrote above. The bit says "MAC OPTIONAL", and is > backward-compatible. Ok, sorry for the confusion. > > - I'd suggest to use all bits of the refid (not fix the first octet to > > 0xfd) to make collisions less likely. > > Your suggestion is backwards-incompatible. We have already seen reports > of the IPv6 hash returing a value that matches the IPv4 address of a > *different IPv4 host on the same network as the IPv6 host*. But the same thing is happening in IPv6-only networks (and you want to make that problem even more common). The users just need to know the refid is not an IPv4 address. > Refids are there for 1-degree loop detection, not "who is my upstream > server". I disagree. Yes, the main purpose is prevention of loops, but up to now matching refids of two servers indicated they used the same source. That is a useful information. > The primary reason for the refid is to detect degree-1 timing loops. Ok, so preventing loops between two peers is important, but between three and more peers it is not? -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 8 02:10:25 2016 Return-Path: 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 BDC2812D5B9 for ; Fri, 8 Apr 2016 02:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 lU8BgWhVBLae for ; Fri, 8 Apr 2016 02:10:24 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0F12D5AC for ; Fri, 8 Apr 2016 02:09:50 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 2E72286DCC1 for ; Fri, 8 Apr 2016 09:09:50 +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 798E286DB05 for ; Fri, 8 Apr 2016 09:06:51 +0000 (UTC) Received: from mail146c25.carrierzone.com ([64.29.147.216] helo=mail239c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aoSNC-0001yc-R7 for ntpwg@lists.ntp.org; Fri, 08 Apr 2016 09:06:51 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail239c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u3896Z6Z023229 for ; Fri, 8 Apr 2016 09:06:36 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 17000406074; Fri, 8 Apr 2016 02:06:35 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Miroslav Lichvar From: Hal Murray In-Reply-To: Message from Miroslav Lichvar of "Fri, 08 Apr 2016 10:57:26 +0200." <20160408085726.GA13598@localhost> Mime-Version: 1.0 Date: Fri, 08 Apr 2016 02:06:35 -0700 Message-Id: <20160408090635.17000406074@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=cNXZ7DuN c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=20KFwNOVAAAA:8 a=oQIFU35PG5ZX0AXLI_4A:9 a=vfu1EiXRu0L_TYhe:21 a=yE9x-Cymth23KGMw:21 a=CjuIK1q_8ugA:10 a=vT-s8mQUKP4A:10 X-CTCH-RefID: str=0001.0A010205.5707749D.0033, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.216 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org, hmurray@megapathdsl.net 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" mlichvar@redhat.com said: > The size could be specified in multiplies of 4, if you think 256 is not > enough. I don't. 256 is enough for today. It won't be tomorrow. > If you want to keep the data aligned to 4 octets and not waste too much > space, what else do you propose? Table lookup. There are only a small number of lengths that are likely to be used. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 8 03:55:49 2016 Return-Path: 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 5526212D860 for ; Fri, 8 Apr 2016 03:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 2X5whXznQZ5C for ; Fri, 8 Apr 2016 03:55:47 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id D706512D115 for ; Fri, 8 Apr 2016 03:55:46 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id CEA0E86DCDB for ; Fri, 8 Apr 2016 10:55:46 +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 0C25086DC56 for ; Fri, 8 Apr 2016 10:53:56 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1aoU0b-0006mQ-Sa; Fri, 08 Apr 2016 10:51:25 +0000 From: Harlan Stenn To: Miroslav Lichvar In-reply-to: <20160408085726.GA13598@localhost> References: <20160407121447.GE20410@localhost> <20160408085726.GA13598@localhost> Comments: In-reply-to Miroslav Lichvar message dated "Fri, 08 Apr 2016 10:57:26 +0200." 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: Fri, 08 Apr 2016 10:51:25 +0000 Message-Id: Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" Miroslav Lichvar writes: > On Thu, Apr 07, 2016 at 09:16:26PM +0000, Harlan Stenn wrote: > > Miroslav Lichvar writes: > > > draft-mayer-ntp-mac-extension-field-00 > > > - Instead of hiding the hash function, I think it might be more useful > > > to specify it directly in the field to allow easier debugging when > > > the authentication fails. The MAC length field could be shortened to > > > one octet and the other octet could specify the key type, allowing > > > 256 different types. > > > > I see the cost of advertising the hash function. I don't see the > > benefit to advertising the hash function. If there's a failure, that > > should be a very rare event and it should be obvious how to fix it. > > Beside knowing which hash function was used in the MAC, the type field > will allow other MACs in the field, not just those used by > authentication with symmetric keys. The security folks tell me that it's better to not advertise the algorithm. If you get adequate consensus from them that it's not an issue to publish the hash function then OK. Why do you think the described proposal only allows symmetric key encryption? It supports autokey as well, and the only other proposed EF that includes a MAC is NTS, and that protocol embeds its MAC in the NTS packet, and once the key exchange is completed NTS provides its own MAC. I asked if the NTS MAC could/should be separated out into a separate MAC field and was told "No, we want it in the NTS EF." Oh, what's stopping people from publishing 1 algorithm but actually using another, again for security purposes? > > If the hash function is communicated, I think there are probably better > > ways to convey that information besides trying to save 1 byte. > > If you want to keep the data aligned to 4 octets and not waste too > much space, what else do you propose? I already proposed what I think we should do. Not encode the algorithm in the MAC. We've never done it before and there seems to be no compelling reason to do it now. There are other ways to get this information, and they don't seem to be difficult to use. > > I have no opinion as to whether or not we should limit the size of the > > hash to ~256 bytes (if I understood that part correctly). > > The size could be specified in multiplies of 4, if you think 256 is > not enough. I don't. I don't have the cycles to explore this right now. We don't need to think about this if we don't encode the algorithm in the MAC. And right now we expressly do not encode the algorithm in the MAC. > > > - MACs could be treated as opaque data, not requiring symmetric keys > > > with 32-bit key IDs. This would allow storing MACs from new > > > authentication schemes and they wouldn't need a new extension field, > > > just a new MAC type for this extension field. > > > > I don't understand "... they wouldn't need a new extension field, just a > > new MAC type for this extension field." > > The NTS MAC could be stored in this field for instance, it doesn't > have to be a new extension field. If you had multiple MACs in this > field packet, they would be independent. Their order wouldn't change > the result, the second MAC wouldn't have to include the first one, the > third MAC wouldn't need to include the first and second one, and so on. The NTS designers have told me they do not want to do this. The NTS stuff uses its packet for a bunch of different things. So you're suggesting we don't use a new EF for NTS? > > > draft-stenn-ntp-i-do-00 > > > - It's not clear to me why there needs to be a "MAC required" bit and > > > why it should be specified in this draft. This was discussed before, > > > but I've not seen any conclusion. > > > > We've had MACs from before we had the first EF. When autokey arrived, > > it *required* a MAC. Many years' later, we have now just added an > > experimental EF that says "there MUST NOT be a MAC." > > That information is included in the specification of the field. How > will that bit change behaviour of an implementation that doesn't > understand the field? It would be great if you could give an example > of a difference in the processing of the packet when this bit is set > and not set. If I understand you, your first sentence means that the knowledge of whether or not an EF expects a MAC is known because that knowledge is embedded in the specification of that EF type. That fails if the current NTP instance does not know how to process this "new" EF. As for examples of how the bits for MAC-OPTIONAL and MAC-INCLUDED, in what way have I provided incomplete examples or supporting explanation before? > > > draft-stenn-ntp-ipv6-refid-hash-00 > > > - The idea was discussed several times before. It doesn't make much > > > sense to me. > > > > Then don't implement it, and don't announce that you support it in I-Do > > exchanges. > > If I don't implement it, I won't be able to detect loops with servers > that do implement it. This is not an optional feature as I understand > it. It changes the definition of the refid field in the NTPv4 packets > and everyone has to deal with it. It's one thing to use what is described for detection. It's another thing to decide to send them yourself. 1) if you implement I-Do then you will be able to say "I don't send this style of IPv6 refid hash and I don't want you sent it to me, either." It's up to the "other side" to decide if they're going to honor your request. 2) You can implement as much or as little of this mechanism to detect IPv6-based refid hashes as you wish, and decide how many of these mechanisms to test for along the way. As I said, this is pretty easy and lightweight to do. 3) if the Suggest-REFID proposal is implemented, this is a non-issue. 4) if Sharon's idea for "Not-You REFID" is used, this is a non-issue. 5) There are a number of different mechisms proposed around REFIDs. They are not mutually exclusive. You should have the flexibility here to implement a local policy you are comfortable with. 6) if somebody doesn't implement this and they do not detect a loop when it exists, the stratum of each side will degrade every poll. And if they don't have enough other sources of time or they have misconfigured their systems, and they're not properly monitoring their systems, that's their problem. > > > - In order to avoid conflicts with refids based on IPv4 addresses it > > > makes conflicts between refids based on IPv6 more likely. Why should > > > be IPv4 special? The world is quickly moving to IPv6. > > > > It uses an initial octet that CANNOT appear as a source address, so > > your argument that it "makes conflicts between refids based on IPv6 more > > likely" seems ... wrong to me, at least for IPv4-based refids. > > I mean conflict between two refids generated from two different IPv6 > addresses. Your proposal prevents a conflict between IPv6 refids and > IPv4 refids, but at a cost that there will be more conflicts between > IPv6 refids. The 32-bit IPv4 space would be mapped to 32 bits in > refid, but the 128-bit IPv6 space only to 24 bits. Don't you see the > problem? Yes. There is a 1 in 16.7M chance of a collision in this case. The decision to use this mechanism is a local policy choice. There are collision risks with the original mechanism. One can use REFID-SUGGEST to avoid this problem, potentially creating a 1 in 16.7M chance of collision with the original IPv6 hash mechanism. One can use the Not-You refid proposal, which has a 1 in 4B chance of a collision. The cost of any of these collisions is that the other side will be identified as a false-positive timing loop. That should not be a real problem for anybody. For REFID-SUGGEST it's possible to periodically change the nonce, which would limit the period of time when this false-positive condition exists. Regardless, if you are a client, you're not serving time so you have no timing loop issue to worry about. If you only have 1 source of time, you have different problems. If there is benefit to combining the refid loop detection code with a stratum check that may also be useful. We have known, active problems with the current refid implementation. Choose your poison. > > > draft-stenn-ntp-leap-smear-refid-00 > > > - I don't think the refid field in NTP packet is a good place to store > > > an offset. > > > > Where else can it go that it's obvious, visible, and almost totally > > backward-compatible? > > I think the reference timestamp would be a much better choice. I strongly disagree with you. 1) How does somebody know when the reference timestamp is a reference timestamp and when it's an offset? Whether or not the reference timestamp in its current form is sufficiently useful is a different discussion. But we should not "hijack" it without a compelling reason. 2) How is this easily visible from ntpq? We're talking about making sure things work when things can go sideways in a major way, about once every 2 years' time, over a period of about 24 hours. Let's make finding these problems as quick and easy as possible. > > > - The refid will conflict with 1/256 of refids based on IPv6. Even if > > > the IPv6 refid draft that shrinks the space for IPv6 refids to 24 > > > bits is accepted, it will take some time before it's used. > > > > Only for client mode associations at the ~S3 level, that do not choose > > to implement any of the other proposals around I-Do and refids. > > That includes all old implementations, right? I.e. the target of the > proposal? Yes. And beyond that... First, I'm not sure I buy the 1/256 collision thing. How is this not a 1 in 4B chance of collision that would only happen on 1 poll exchange? If it does happen on 1 poll exchange who cares? The protocol is robust enough to handle 1 ignored sample. Also see above about how a pure client will never need timing loop detection. > > What do you propose as an alternative for servers that want to offer > > smeared time to clients? > > If you need to see the fact that the server is leap smearing in the > ntpq output in the refid field, pick a constant value for refid and > don't encode the offset. That's what I did in chrony. What refid value did you choose? What happens when you have different servers offering different applications of the leap smear? How can you tell what they are doing? > > > draft-stenn-ntp-suggest-refid-00 > > > - Again, the "required MAC" bit in the field type doesn't seem useful. > > > > Again, what I wrote above. The bit says "MAC OPTIONAL", and is > > backward-compatible. > > Ok, sorry for the confusion. > > > > - I'd suggest to use all bits of the refid (not fix the first octet to > > > 0xfd) to make collisions less likely. > > > > Your suggestion is backwards-incompatible. We have already seen reports > > of the IPv6 hash returing a value that matches the IPv4 address of a > > *different IPv4 host on the same network as the IPv6 host*. > > But the same thing is happening in IPv6-only networks (and you want to > make that problem even more common). The users just need to know the > refid is not an IPv4 address. No, the primary purpose of the refid is for 1-degree loop detection. If folks want to know about an upstream server and they have authorization to ask, they can issue a mode 6 request and see what the source address is for that association. If your local policy allows for this, great. But it's unreasonable to expect others to conform to your policy choices. The security folks are pushing hard to limit access to this sort of information. People who do a lousy job of upgrading their software can expect problems caused by running outdated software. > > Refids are there for 1-degree loop detection, not "who is my upstream > > server". > > I disagree. Yes, the main purpose is prevention of loops, but up to > now matching refids of two servers indicated they used the same > source. That is a useful information. And dangerous. So if you want a local policy that allows it, that's your choice. Again, it's inapproprate for you to dictate that policy for others. Note that more and more folks are making this harder and harder to do. More to the point, they DO NOT WANT arbitrary folks to know where they are getting their time from. It's a security thing. > > The primary reason for the refid is to detect degree-1 timing loops. > > Ok, so preventing loops between two peers is important, but between > three and more peers it is not? Yes. It may be that larger loops are a problem too, but in those cases it may be that there are other, earlier problems. Was it you who mentioned that you saw a 3-system loop, and that loop was on systems that were using neither orphan mode nor local refclock? If that's the case, then please show how increasing the protocol complexity (including a security analysis) to detect these loops is worth the cost. Why just not fix the configuration so this doesn't happen? Why didn't your systems monitoring catch this when the stratum of your servers went out-of-spec? H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 8 07:16:31 2016 Return-Path: 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 708E012D917 for ; Fri, 8 Apr 2016 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 eaZk6v697qGY for ; Fri, 8 Apr 2016 07:16:29 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id DFB6A12D914 for ; Fri, 8 Apr 2016 07:16:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4670086DBBF for ; Fri, 8 Apr 2016 14:16:17 +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 2075E86DAFF for ; Fri, 8 Apr 2016 13:26:12 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aoWQE-000AOr-1N for ntpwg@lists.ntp.org; Fri, 08 Apr 2016 13:26:12 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A2BF48B; Fri, 8 Apr 2016 13:26:01 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u38DQ0to016826; Fri, 8 Apr 2016 09:26:00 -0400 Date: Fri, 8 Apr 2016 15:25:59 +0200 From: Miroslav Lichvar To: Harlan Stenn Message-ID: <20160408132559.GA14867@localhost> References: <20160407121447.GE20410@localhost> <20160408085726.GA13598@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Fri, Apr 08, 2016 at 10:51:25AM +0000, Harlan Stenn wrote: > Miroslav Lichvar writes: > > > > draft-mayer-ntp-mac-extension-field-00 > > Beside knowing which hash function was used in the MAC, the type field > > will allow other MACs in the field, not just those used by > > authentication with symmetric keys. > > The security folks tell me that it's better to not advertise the > algorithm. If you get adequate consensus from them that it's not an > issue to publish the hash function then OK. Ok, I can try. Who made the suggestion? Are they following this list? > Oh, what's stopping people from publishing 1 algorithm but actually > using another, again for security purposes? Sure, they can do that and if it's not a common practice, it might work. That's security through obscurity. The reasonable approach is to use secure keys. > The NTS designers have told me they do not want to do this. The NTS > stuff uses its packet for a bunch of different things. So you're > suggesting we don't use a new EF for NTS? Having all MACs in one extension field looks like a cleaner approach to me, but I don't want to make that suggestion unless it can be done without further delaying the NTS draft. > > > > draft-stenn-ntp-i-do-00 > As for examples of how the bits for MAC-OPTIONAL and MAC-INCLUDED, in > what way have I provided incomplete examples or supporting explanation > before? I'd like to see an example where the client or server does anything differently when the bit is set the other way, i.e. why it needs to be transferred in NTP packets. > > > > draft-stenn-ntp-ipv6-refid-hash-00 > 5) There are a number of different mechisms proposed around REFIDs. > They are not mutually exclusive. You should have the flexibility here > to implement a local policy you are comfortable with. If you only want to prevent loop, they might not be exclusive. But if you want to use refid to detect you are using the same source as your server, mixing different kinds of refids in the same network will break it. > > > > draft-stenn-ntp-leap-smear-refid-00 > > > Where else can it go that it's obvious, visible, and almost totally > > > backward-compatible? > > > > I think the reference timestamp would be a much better choice. > 1) How does somebody know when the reference timestamp is a reference > timestamp and when it's an offset? You can use a special refid to indicate leap smearing is active and reftime has special meaning. > Whether or not the reference > timestamp in its current form is sufficiently useful is a different > discussion. But we should not "hijack" it without a compelling reason. Very few client implementations look at the reference timestamp. ntpd as a client ignores it completely. From how it's specified in NTPv3 and NTPv4, there is about 44 bits that can set arbitrarily without breaking things. It just needs to be not newer than the transmit timestamp and not older than few hours. You could use the encoding specified in the refid draft directly in the fractional part of the timestamp. You would just need to decrement seconds by one to make sure it's not newer than the transmit timestamp. No client would have a problem with that and refid would stay clean. > 2) How is this easily visible from ntpq? ntpq -c rv prints the reference timestamp. > First, I'm not sure I buy the 1/256 collision thing. How is this not a 1 > in 4B chance of collision that would only happen on 1 poll exchange? On average 1 in 256 IPv6 servers (using the current definition of refid) will appear as constantly performing leap smear. If a client should act on that, it would be a problem. If it's meant only for humans monitoring the network (who probably can figure out the offset is not changing and it's a false positive), the draft should make it clear. > > If you need to see the fact that the server is leap smearing in the > > ntpq output in the refid field, pick a constant value for refid and > > don't encode the offset. That's what I did in chrony. > > What refid value did you choose? 127.127.1.255 > What happens when you have different servers offering different > applications of the leap smear? Things might break horribly. > How can you tell what they are doing? There is a command that prints the current leap smearing status and offset in the chrony monitoring protocol. > > > > draft-stenn-ntp-suggest-refid-00 > If folks want to know about an upstream server and they have > authorization to ask, they can issue a mode 6 request and see what the > source address is for that association. Mode 6 is an ntpd-specific extension of NTP. Even if the server runs ntpd, it's typically disabled. NTP clients can't work with that. > Was it you who mentioned that you saw a 3-system loop, and that loop was > on systems that were using neither orphan mode nor local refclock? If > that's the case, then please show how increasing the protocol complexity > (including a security analysis) to detect these loops is worth the cost. > Why just not fix the configuration so this doesn't happen? Why didn't > your systems monitoring catch this when the stratum of your servers went > out-of-spec? I think the monitoring caught it, that's not the problem. The problem was they were unusable for clients below them, it's an unexpected situation. A local reference was not an option as the servers and clients were required to always report real synchronisation distance. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 8 18:12:00 2016 Return-Path: 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 6EA1412D103 for ; Fri, 8 Apr 2016 18:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 BusUL_2fek_c for ; Fri, 8 Apr 2016 18:11:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8B76112D0D3 for ; Fri, 8 Apr 2016 18:11:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 79FFD86DBED for ; Sat, 9 Apr 2016 01:11:57 +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 3FE1B86DB51 for ; Sat, 9 Apr 2016 01:02:10 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1aohFT-0007TT-SE; Sat, 09 Apr 2016 00:59:39 +0000 From: Harlan Stenn To: Miroslav Lichvar In-reply-to: <20160408132559.GA14867@localhost> References: <20160407121447.GE20410@localhost> <20160408085726.GA13598@localhost> <20160408132559.GA14867@localhost> Comments: In-reply-to Miroslav Lichvar message dated "Fri, 08 Apr 2016 15:25:59 +0200." 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: Sat, 09 Apr 2016 00:59:39 +0000 Message-Id: Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" Miroslav Lichvar writes: > On Fri, Apr 08, 2016 at 10:51:25AM +0000, Harlan Stenn wrote: > > Miroslav Lichvar writes: > > > > > > draft-mayer-ntp-mac-extension-field-00 > > > > Beside knowing which hash function was used in the MAC, the type field > > > will allow other MACs in the field, not just those used by > > > authentication with symmetric keys. > > > > The security folks tell me that it's better to not advertise the > > algorithm. If you get adequate consensus from them that it's not an > > issue to publish the hash function then OK. > > Ok, I can try. Who made the suggestion? Are they following this list? I believe I heard this from Sharon Goldberg and her team (who are following this, TTBOMK) and also from at least one of the Cisco teams. > > Oh, what's stopping people from publishing 1 algorithm but actually > > using another, again for security purposes? > > Sure, they can do that and if it's not a common practice, it might > work. That's security through obscurity. The reasonable approach is to > use secure keys. It's keeping keys secure *and* using acceptable hash algorithms. The purpose of the MAC is twofold, to detect packet tampering and to authenticate the packet data. > > The NTS designers have told me they do not want to do this. The NTS > > stuff uses its packet for a bunch of different things. So you're > > suggesting we don't use a new EF for NTS? > > Having all MACs in one extension field looks like a cleaner approach > to me, but I don't want to make that suggestion unless it can be done > without further delaying the NTS draft. I have no strong opinion on this - I was originally expecting this to be the approach, in that NTS would do its thing and pass us a MAC that we would use. But the NTS designers said "No, we're including the MAC in our packet and we'll return appropriate status codes to you so you'll know whether or not the EF contained an authenticator, and whether or not the packet passed this MAC check." This goes to the bit in the EF that says "MAC-INCLUDED", as the timestamps on packets that use NTS cannot be trusted until they are authenticated or can be reality-checked with other trusted packets. That's also why I want to *allow* NTS packets to also be covered, at least initially, with symmetric key MACs. > > > > > draft-stenn-ntp-i-do-00 > > > As for examples of how the bits for MAC-OPTIONAL and MAC-INCLUDED, in > > what way have I provided incomplete examples or supporting explanation > > before? > > I'd like to see an example where the client or server does anything > differently when the bit is set the other way, i.e. why it needs to be > transferred in NTP packets. It goes to allowing the local NTP instance to do some high-level sanity checks, and to have more information about "should I drop a packet that contains an EF with no MAC protection or just ignore that EF?" > > > > > draft-stenn-ntp-ipv6-refid-hash-00 > > > 5) There are a number of different mechisms proposed around REFIDs. > > They are not mutually exclusive. You should have the flexibility here > > to implement a local policy you are comfortable with. > > If you only want to prevent loop, they might not be exclusive. But if > you want to use refid to detect you are using the same source as your > server, mixing different kinds of refids in the same network will > break it. Being (usually) able to make that choice is possible with the traditional REFID. It was never a defined usage, and how valuable is this capability? I'm game to tweak the proposed language changes to show that sending the legacy IPv6 refid hash is deprecated, because we're starting to use values in the first octet in the 240.0.0.0/4 range for various special cases. The calculation is the same, but the proposed new IPv6 refid puts 0xFF as the first octet. Returning to your point about other ways refids can be used, do you want to avoid using a system that is sync'd with a specific refclock driver just because another of your servers is also using that refclock driver? What about, for example, all GPS? If you already sync with a NIST server, does that mean you do not want to sync with another server that syncs with NIST? The national labs all sync with each other. If you are syncing with NIST do you then want to avoid syncing with PTB? What exactly is the problem you are trying to solve here? > > > > > draft-stenn-ntp-leap-smear-refid-00 > > > > > Where else can it go that it's obvious, visible, and almost totally > > > > backward-compatible? > > > > > > I think the reference timestamp would be a much better choice. > > > 1) How does somebody know when the reference timestamp is a reference > > timestamp and when it's an offset? > > You can use a special refid to indicate leap smearing is active and > reftime has special meaning. That seems like a lot of work for little gain, and it's a whole lot messier, IMO. It's also, as I mentioned, not backward compatible. > > Whether or not the reference > > timestamp in its current form is sufficiently useful is a different > > discussion. But we should not "hijack" it without a compelling reason. > > Very few client implementations look at the reference timestamp. ntpd > as a client ignores it completely. From how it's specified in NTPv3 > and NTPv4, there is about 44 bits that can set arbitrarily without > breaking things. It just needs to be not newer than the transmit > timestamp and not older than few hours. And several of those conditions you mention will not be valid during the leap smear, and older software *will not know this* so it seems like this approach is creating new problems in the very population of clients where we are trying to solve the leap smear issue. If folks think this is a useful alternative way to go, however, let's write it up and get it passed as an alternative mechanism. > You could use the encoding specified in the refid draft directly in > the fractional part of the timestamp. You would just need to decrement > seconds by one to make sure it's not newer than the transmit > timestamp. No client would have a problem with that and refid would > stay clean. Yes, and one of the points of this is that we want to CLEARLY identify that a leap smear is in effect. So we'd still be offering a "unique" refid in this case, right? To keep the proposals someowhat compatible, we could use 254.a.b.c, where if a.b.c are all 0 the offset is encoded as you describe in the reference time, and otherwise they are encoded as I describe. I still think your approach is suboptimal. The 'ntpq -p' billboard will only show a refid of 254.0.0.0 during the entire time of the leap smear, and one will have to take extra steps to try and get the amount of smear. With my proposal, the amount of smear is visible, in an encoded form, in a single ntpq query. If one is logging this information, it's arguably easier to log a timestamp and a refid then it is to log a timestamp, a refid, and a reference time. Unless all that information is already being logged. > > 2) How is this easily visible from ntpq? > > ntpq -c rv prints the reference timestamp. That's not my idea of easy, and it may not be visible soon as we're about to implement access restriction control to that sort of data. > > First, I'm not sure I buy the 1/256 collision thing. How is this not a 1 > > in 4B chance of collision that would only happen on 1 poll exchange? > > On average 1 in 256 IPv6 servers (using the current definition of > refid) will appear as constantly performing leap smear. If a client > should act on that, it would be a problem. If it's meant only for > humans monitoring the network (who probably can figure out the offset > is not changing and it's a false positive), the draft should make it > clear. The proposal is designed to make it easy for monitoring, as the premise is that the clients are too old/simple to handle a leap second insertion themselves. 1) they would appear to be constantly applying a *constant* smear. If they were *serving time to a client*. One does not see the refid smear if one does an 'ntpq -p' query to the server itself. One does not get a refid smear if one is using This refid is only sent in a time response packet to a *client mode* request. 2) Clients do not act on this information. The whole purpose of sending leap-smeared time is to send them: - only in response to client mode requests - to systems that are expected to be unable to deal with leap seconds 3) if you are in a network where you have upgraded your servers to send leap-smeared time, how much harder is it to upgrade those servers before the next leap-second so they include this fix too? It's already established that the leap smear is only needed in environments where there are old clients that do not properly handle leap seconds. If these old clients *were* updated there would be no need to use a leap smear. 4) I had another important point to make about this but I got interrupted before I could write it down. It's gone now :) > > > If you need to see the fact that the server is leap smearing in the > > > ntpq output in the refid field, pick a constant value for refid and > > > don't encode the offset. That's what I did in chrony. > > > > What refid value did you choose? > > 127.127.1.255 I implemented what I considered to be the best policy. You implemented what you consider to be best policy. If there is no clear consensus on the "one way to go" let's put both in the Standard and give folks the option to pick the one they want. > > What happens when you have different servers offering different > > applications of the leap smear? > > Things might break horribly. > > > How can you tell what they are doing? > > There is a command that prints the current leap smearing status and > offset in the chrony monitoring protocol. > > > > > > draft-stenn-ntp-suggest-refid-00 > > > If folks want to know about an upstream server and they have > > authorization to ask, they can issue a mode 6 request and see what the > > source address is for that association. > > Mode 6 is an ntpd-specific extension of NTP. No it's not. It's part of the NTPv3 Standard that was inadvertently omitted from the NTPv4 Standard. Karen mentioned this again last week at the IETF WG meeting. > Even if the server runs > ntpd, it's typically disabled. NTP clients can't work with that. That's a local policy choice. It's trivial in the reference implementation to control whether or not mode 6/7 queries are answered. Clients do not need mode 6 for their operation. Mode 6 is about monitoring and control. > > Was it you who mentioned that you saw a 3-system loop, and that loop was > > on systems that were using neither orphan mode nor local refclock? If > > that's the case, then please show how increasing the protocol complexity > > (including a security analysis) to detect these loops is worth the cost. > > Why just not fix the configuration so this doesn't happen? Why didn't > > your systems monitoring catch this when the stratum of your servers went > > out-of-spec? > > I think the monitoring caught it, that's not the problem. The problem > was they were unusable for clients below them, it's an unexpected > situation. A local reference was not an option as the servers and > clients were required to always report real synchronisation distance. What is the real synchronization difference from a time island? Does it depend on the reference time and the sync distance at that time, adding "PHI*elapsed seconds since sync" to that value? H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sat Apr 9 08:58:25 2016 Return-Path: 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 304C612B02E for ; Sat, 9 Apr 2016 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 Jxx21ebeSevF for ; Sat, 9 Apr 2016 08:58:24 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id EB4BE12B02C for ; Sat, 9 Apr 2016 08:58:23 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D3DAC86DD30 for ; Sat, 9 Apr 2016 15:58:23 +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 EEE4A86DC05 for ; Sat, 9 Apr 2016 15:53:01 +0000 (UTC) Received: from userp1040.oracle.com ([156.151.31.81]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aovBq-000CjS-RI for ntpwg@lists.ntp.org; Sat, 09 Apr 2016 15:53:01 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u39Fqns6005922 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 9 Apr 2016 15:52:50 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u39Fqnn7028856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 9 Apr 2016 15:52:49 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u39FqnCJ001247 for ; Sat, 9 Apr 2016 15:52:49 GMT Received: from [10.154.163.189] (/10.154.163.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 09 Apr 2016 08:52:49 -0700 To: ntpwg@lists.ntp.org References: <557FE204020000A10001AC61@gwsmtp1.uni-regensburg.de> <20150616094745.GA75580@walton.maths.tcd.ie> From: brian utterback Organization: Oracle Corporation Message-ID: <5709254E.9060807@oracle.com> Date: Sat, 9 Apr 2016 11:52:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20150616094745.GA75580@walton.maths.tcd.ie> X-Source-IP: userv0022.oracle.com [156.151.31.74] X-SA-Exim-Connect-IP: 156.151.31.81 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: brian.utterback@oracle.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2641247081155587656==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" This is a multi-part message in MIME format. --===============2641247081155587656== Content-Type: multipart/alternative; boundary="------------050209080403050804080807" This is a multi-part message in MIME format. --------------050209080403050804080807 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Miroslav's erratum (id 4504) is still listed as "reported" for RFC 5905. I think the consensus from this discussion was that the LI can be set for more than a day so the erratum is incorrect and the current wording is correct. What is the process for getting the erratum marked as "denied" in some way? On 6/16/2015 5:47 AM, David Malone wrote: > On Tue, Jun 16, 2015 at 08:41:45AM +0000, Harlan Stenn wrote: >> I will say we're well in to June and there are plenty of v4 servers out >> there and we haven're received a bug report. > Based on my data: > > http://www.maths.tcd.ie/~dwmalone/time/leaps/ > > It looks like they've been advertised for more than a day for a > long time. I could try and extract a bigger window, if that was > useful. > > Daviid. > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg -- Oracle Brian Utterback | Principal Software Engineer Phone: +1 6038973049 Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 ------------------------------------------------------------------------ All working systems eventually start to exhibit their own agenda ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment --------------050209080403050804080807 Content-Type: multipart/related; boundary="------------070300020707000801070500" --------------070300020707000801070500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Miroslav's erratum (id 4504) is still listed as "reported" for RFC 5905. I think the consensus from this discussion was that the LI can be set for more than a day so the erratum is incorrect and the current wording is correct. What is the process for getting the erratum marked as "denied" in some way?

On 6/16/2015 5:47 AM, David Malone wrote:
On Tue, Jun 16, 2015 at 08:41:45AM +0000, Harlan Stenn wrote:

I will say we're well in to June and there are plenty of v4 servers out
there and we haven're received a bug report.

Based on my data:

	http://www.maths.tcd.ie/~dwmalone/time/leaps/

It looks like they've been advertised for more than a day for a
long time. I could try and extract a bigger window, if that was
useful.

	Daviid.
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

--
Oracle
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
All working systems eventually start to exhibit their own agenda
Green Oracle Oracle is committed to developing practices and products that help protect the environment
--------------070300020707000801070500 Content-Type: image/gif; name="oracle_sig_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oracle_sig_logo.gif" R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9A QP/AwP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPV IDfcOQa6A8yRaO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1n BGRmhl8AWiUJYicCAIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4 AAunsqg/dw95KwdfBgzBqKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1It xK7aKl8lCl8DAfALW1+2rUi3QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyI qRgMcA8a/z5AZQWXOxEdHxwUgfIgsX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjU mYLnomokcDlS4s0eFzQNqvXDEyzmAwFPyaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpF RxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt 1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvPm8OVEkAIYLYPThSsRIpEQJr1x94QBIT0 9FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8ABijggAQWaOCBCCao4A+CDDbo4IMQ RijhhBQKGAIAOw== --------------070300020707000801070500 Content-Type: image/gif; name="green-for-email-sig_0.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="green-for-email-sig_0.gif" R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zP uZu2lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxj SYdrOp/Q6NPgYqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMq DwFCAAIFPIYDgidrOUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQG BH82TpMicD0pAgQACToDAchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLD LS8MAvf497ruCZ+gOA0gfNt3AIK0J/JWKVzIsEQIADs= --------------070300020707000801070500-- --------------050209080403050804080807-- --===============2641247081155587656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============2641247081155587656==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 11 00:28:39 2016 Return-Path: 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 3CF2B12E809 for ; Mon, 11 Apr 2016 00:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 U-fxakK9yHTr for ; Mon, 11 Apr 2016 00:28:38 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 26D5512E808 for ; Mon, 11 Apr 2016 00:28:38 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id E47B486DBBC for ; Mon, 11 Apr 2016 07:28:37 +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 1F7AB86DB91 for ; Mon, 11 Apr 2016 07:28:02 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1apWGI-0004bC-7a for ntpwg@lists.ntp.org; Mon, 11 Apr 2016 07:28:02 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 277A480099; Mon, 11 Apr 2016 07:27:53 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3B7RqH5015904; Mon, 11 Apr 2016 03:27:52 -0400 Date: Mon, 11 Apr 2016 09:27:51 +0200 From: Miroslav Lichvar To: brian utterback Message-ID: <20160411072751.GA27534@localhost> References: <557FE204020000A10001AC61@gwsmtp1.uni-regensburg.de> <20150616094745.GA75580@walton.maths.tcd.ie> <5709254E.9060807@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5709254E.9060807@oracle.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Sat, Apr 09, 2016 at 11:52:46AM -0400, brian utterback wrote: > Miroslav's erratum (id 4504) is still listed as "reported" for RFC 5905. > I think the consensus from this discussion was that the LI can be set > for more than a day so the erratum is incorrect and the current wording > is correct. What is the process for getting the erratum marked as > "denied" in some way? Getting consensus on that first? The current wording in RFC 5905 is conflicting. Once it says it's day and once it says it's month. The RFC indicates several times the field is meant to be compatible with NTPv3, where it was just day (unambigiously). The page referred below shows a vast majority of the servers started announcing the last leap (June 2015) one day before, following the NTPv3 definition. It seems it's only very old ntpd versions (pre RFC 5905) that announced it for month. Brian, I assume you are still maintaining some old versions that do that and the "day" definition would meant they have to be fixed? If the intended interval for the leap bits in NTPv4 was really month, the draft needs to be updated to not say the field is compatible with NTPv3, like it does with the refid field. Clients that don't check what day it is would need to be fixed. The old ntpd versions that announce the leap for more than day would still be incompatible with NTPv3. Both choices have some drawbacks, there is no clear winner, but I think the "day" definition is a better choice, at least for NTPv4. > On 6/16/2015 5:47 AM, David Malone wrote: > > On Tue, Jun 16, 2015 at 08:41:45AM +0000, Harlan Stenn wrote: > >> I will say we're well in to June and there are plenty of v4 servers out > >> there and we haven're received a bug report. > > Based on my data: > > > > http://www.maths.tcd.ie/~dwmalone/time/leaps/ > > > > It looks like they've been advertised for more than a day for a > > long time. I could try and extract a bigger window, if that was > > useful. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 11 01:40:58 2016 Return-Path: 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 C90E612E94C for ; Mon, 11 Apr 2016 01:40:58 -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 0zNheSxsSdGO for ; Mon, 11 Apr 2016 01:40:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id B319A12E94B for ; Mon, 11 Apr 2016 01:40:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B546986DBDC for ; Mon, 11 Apr 2016 08:40:56 +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 F1CEE86DB09 for ; Mon, 11 Apr 2016 08:39:13 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1apXNH-000AXB-Cb; Mon, 11 Apr 2016 08:39:11 +0000 From: Harlan Stenn To: Miroslav Lichvar In-reply-to: <20160411072751.GA27534@localhost> References: <557FE204020000A10001AC61@gwsmtp1.uni-regensburg.de> <20150616094745.GA75580@walton.maths.tcd.ie> <5709254E.9060807@oracle.com> <20160411072751.GA27534@localhost> Comments: In-reply-to Miroslav Lichvar message dated "Mon, 11 Apr 2016 09:27:51 +0200." 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: Mon, 11 Apr 2016 08:39:11 +0000 Message-Id: Subject: Re: [ntpwg] leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" Miroslav Lichvar writes: > The current wording in RFC 5905 is conflicting. Once it says it's day > and once it says it's month. The RFC indicates several times the field > is meant to be compatible with NTPv3, where it was just day > (unambigiously). Offhand, I don't recall the details of this well enough. My belief is that we've been doing the announcement a month in advance, but it will be easy enough to check. I do know that we've known for years that one problem is that it is the poll interval can be 17, which is more than a day, so in that case it's not enough to rely on the leap bits for this notification. I think it needs to be allowed any time during the month where it can happen. Also note that for a while, *any* server that announced a leap second was enough to trigger this condition. This was a feature when the majority of systems out there did not handle this well. Now I think we might have switched to a "majority vote" in the case where the local system doesn't have a leapsecond file. Or something like that. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 11 03:22:02 2016 Return-Path: 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 2538112EB73 for ; Mon, 11 Apr 2016 03:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 WFhcVa_gphWb for ; Mon, 11 Apr 2016 03:22:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id D692312EB71 for ; Mon, 11 Apr 2016 03:22:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C90EB86DB72 for ; Mon, 11 Apr 2016 10:22:00 +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 96A2A86DB54 for ; Mon, 11 Apr 2016 10:20:51 +0000 (UTC) Received: from mail146c25.carrierzone.com ([64.29.147.216] helo=mail239c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1apYxT-000BuN-Pp for ntpwg@lists.ntp.org; Mon, 11 Apr 2016 10:20:51 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail239c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u3BAKNpt028461 for ; Mon, 11 Apr 2016 10:20:33 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 2B665406070; Mon, 11 Apr 2016 03:20:18 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Miroslav Lichvar From: Hal Murray In-Reply-To: Message from Miroslav Lichvar of "Mon, 11 Apr 2016 09:27:51 +0200." <20160411072751.GA27534@localhost> Mime-Version: 1.0 Date: Mon, 11 Apr 2016 03:20:18 -0700 Message-Id: <20160411102018.2B665406070@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=cNXZ7DuN c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=8X6oF24DlmAhzvsTByoA:9 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A010205.570B7A75.00D8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.216 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org, hmurray@megapathdsl.net 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" GPS sends out the warning close to 6 months early. The HP driver has a hack/patch to only pass that on in June and December. (I added similar code to the Palisade driver for the recent leap.) I looked in log files from last June. It was only sent out one day in advance. I looked around a bit, but didn't find the filtering in the main code. I think it may be tangled up with the leap file code. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 11 08:42:50 2016 Return-Path: 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 2507912EA64 for ; Mon, 11 Apr 2016 08:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.784 X-Spam-Level: X-Spam-Status: No, score=-7.784 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mscc365.onmicrosoft.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 NGvfR1fpsgwI for ; Mon, 11 Apr 2016 08:42:48 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 5A70612E8E5 for ; Mon, 11 Apr 2016 08:42:48 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 5123F86DB9E for ; Mon, 11 Apr 2016 15:42:48 +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 7966C86DB08 for ; Mon, 11 Apr 2016 15:42:24 +0000 (UTC) Received: from mail-bl2on0056.outbound.protection.outlook.com ([65.55.169.56] helo=na01-bl2-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1apdyh-000GYX-52 for ntpwg@lists.ntp.org; Mon, 11 Apr 2016 15:42:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SZwGi0kJ0wQ+Wt/pr5FHFYXAtCA1BUSZzwNGeDQpQa4=; b=e9wWhI4JS4QThvs1bYfEdkweTE/Gvm2mDe/l3+2OP6cAyJbbdCOW5pdW0rHRf28hA6ldRcNKCE+HMmtCZMaoep3WKbGpbyhYSbsGtDRHSTZHLpET8eJB2KF6AZCcHAz7SAkrzxRTKk4zEwadaQLN5SIBiYvzmd/fT/Bp0KzVz/A= Received: from BY2PR02CA0125.namprd02.prod.outlook.com (10.163.44.179) by SN1PR02MB1950.namprd02.prod.outlook.com (10.165.227.12) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 15:42:12 +0000 Received: from BN1AFFO11FD049.protection.gbl (2a01:111:f400:7c10::158) by BY2PR02CA0125.outlook.office365.com (2a01:111:e400:5261::51) with Microsoft SMTP Server (TLS) id 15.1.453.26 via Frontend Transport; Mon, 11 Apr 2016 15:42:12 +0000 Authentication-Results: spf=none (sender IP is 208.19.100.20) smtp.mailfrom=microsemi.com; lists.ntp.org; dkim=none (message not signed) header.d=none;lists.ntp.org; dmarc=none action=none header.from=microsemi.com; Received-SPF: None (protection.outlook.com: microsemi.com does not designate permitted sender hosts) Received: from avsrvexchhts2.microsemi.net (208.19.100.20) by BN1AFFO11FD049.mail.protection.outlook.com (10.58.53.64) with Microsoft SMTP Server (TLS) id 15.1.453.6 via Frontend Transport; Mon, 11 Apr 2016 15:42:12 +0000 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avsrvexchhts2.microsemi.net (10.100.34.106) with Microsoft SMTP Server (TLS) id 14.3.266.1; Mon, 11 Apr 2016 08:42:11 -0700 Received: from SJSRVEXCHMBX2.microsemi.net ([fe80::6da0:6f9d:d5d1:3d5d]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0266.001; Mon, 11 Apr 2016 08:42:10 -0700 From: Greg Dowd To: Hal Murray , Miroslav Lichvar Thread-Topic: [ntpwg] leap second: definitions and DCF-77 Thread-Index: AQHRk9u+/ErFe0PCk0Co4j+lcD+d9Z+E5AVA Date: Mon, 11 Apr 2016 15:42:09 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BF7AB04B65@sjsrvexchmbx2.microsemi.net> References: Message from Miroslav Lichvar of "Mon, 11 Apr 2016 09:27:51 +0200." <20160411072751.GA27534@localhost> <20160411102018.2B665406070@ip-64-139-1-69.sjc.megapath.net> In-Reply-To: <20160411102018.2B665406070@ip-64-139-1-69.sjc.megapath.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.25] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:208.19.100.20; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(428002)(199003)(189002)(377454003)(4326007)(54356999)(2920100001)(2950100001)(2900100001)(92566002)(76176999)(86362001)(97756001)(50986999)(81166005)(9686002)(189998001)(586003)(87936001)(46406003)(106466001)(5003600100002)(2906002)(5004730100002)(1220700001)(3846002)(5008740100001)(53416004)(47776003)(1720100001)(1096002)(6116002)(102836003)(23726003)(55846006)(5001770100001)(19580405001)(5250100002)(33656002)(101416001)(19580395003)(50466002)(106116001)(16796002)(11100500001)(15975445007)(6806005)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR02MB1950; H:avsrvexchhts2.microsemi.net; FPR:; SPF:None; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD049; 1:GdNA3Jvo+UzNSirjQJB88Jw7NdNCYyv4jvSxIYPNgk7nj7YjJV35Cmw+aacffSwCpNtfCcALw4pZrQlcgmFOfL7Bcz1W8/5tKrAVXlR2QN9ldCJfNO2/p41DTc3sadmUdi67UK1irKP82RXL6tIm6l9au3SEZ0nINGnTJIbnX6edr/D18Lr+wDpVi4EMuM2D/YDuCB84JG9rBnKINGZMvZtKlUSw5H++QdjlqozCqRt1ak7s9GkE/s9sj/vLSfo7Q4FNbykwHYTc9uAI1TbMVqGt8NYaCysYbNbFDY9q8wNt/dzs9zHF+YFbLrmpRwS9SYcA1p1kV7tIndYYWN/qv3ncQd6QCwccnLa9U+KqUQkgRlIvnxqM2SKPu6oX8EOz8O63ZTBBBZ1nWykAL0CDzfsAFz/HtBa6773/q6pcmTELJvbGQNleL0LVrb4Ez6tIPcE2lQ7aXZmeqoBbNg8GLyCMGxr5R8FkMDMyU11Eq5ot4vJi3mIFJVV6r4xu4+SDrgO1IuRDKBoj84ZCyQ2pAg== X-MS-Office365-Filtering-Correlation-Id: f7963c82-80bd-42c4-fa17-08d3621fd9c9 X-Microsoft-Exchange-Diagnostics: 1; SN1PR02MB1950; 2:EZfL0efgIYnFHEPZkV7Cb7b659/SPJ69XzbbVUoqkNMlHwQmTuHgW7KzUCgNQYUZj1mTxeyTl0jjxEa2iswGyaF/oDNS8b/aFLPzASl7WuAyU6ikRk0Izl0ZArnNCiKMHgpdK0vQo7np5oPy/SMFWT1GSsQHi8wHFLB24mi8nHqql232qOcTbUOk+umsOr3T; 3:Hj/NiItyag7NXaiZY4Xn0fwCzqGuN+qq98S5JwzcG+6rglMcLQ+rATDo17Vy4vqYJgxlQtCHLX/ivb/N/6J8RQ1XATTZCVfghPIltT902m5Gchm/oGdBJ3LsUW7zrTthcLDtrV5BCWlzNMYOi68XX1+/lTYDG3DFYvad4JEuroFrWNK5dsb6p2SZCF1omU+k3p7cZPw3+RGfEPf2SGcTpXp/YPpJ8dXtTPvLlkypoRU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR02MB1950; X-Microsoft-Exchange-Diagnostics: 1; SN1PR02MB1950; 25:N2CJZJlgyBwCfyxYf+mpLohwRoQT1m+e/VTJ4d5GTR7IK9S5EjB9UMSMEPUUzGXD8PtlFx5tB/sHDB8pic6u5WZxziRmuwpskeB7Le0rQBShgtvsknjxYzWsqppE5+O3r2cMxzLq5/45pMz5CurMhKFZPZAjtaRhUs9zM6+omfzTd+KJPq7GL20WjoFXlGqGUG7JBH82RwUQTCQNqg0wToHG+bzemErBQpYLP7t5CjyP5k8HtRoiXduO3PRjdGUpQwOysfyDCa6W5CVLeqP2W1+Ia/CmnV4IQJ6rO+H8ccfqvALrTA1W2IeXrdDPrkuXxSo3xk6vTthjKmKGH7bj4/R6cH2yzws1TcKBkzQ9Aa0Nh56SRaJ2xROIMGLCSGZ+Xm6/uNcyErrsSA4C8Z06/kmHBCLN/0YkPNnZiUJoKYsVFKsaaKnxHepfC3qAacDoRmxZnnuYqSuX6rQcquL2SKlU3vlLGtOD4WO2d58gbRFe0kd76GYeF0LwtdIJMDdzPnf49v0TfE44u79QFUaNscfFJlf0VUi1Kkg5ShA5XYsCh/u9wGv9HlO/CrqU+ugA0ft9FAYh1X2yXwqUphCxu7pWQh/qxyHYoccKVCYFH4/y4O7xDgFg13q3AMVmaDb/Scv2P6zi7a0n3i6qbfWgM4TJjf615GIPXS6crr2NwRq5s6kY7h9Y8Ckzu8OLgqEOAzeJjn5NhXAI8pf0V1cC1fmWel+8F74+tp6rbkAiLQAWOgxh4BrYLR2l0BFHdt74loVIlhhH2GXf1tkppA50GmXbcnpoGVwlcD50Iz1yYqorTmwnJPyDJA1d+JdQGtcU X-Microsoft-Exchange-Diagnostics: 1; SN1PR02MB1950; 20:uBIbeMQvhrIyyjKTp4r5OhLoeG3Pl0AW3iiEfEB+M1imoDLR3STh/3ciGCtACw07F56/tj099UuXxF2+8m0Ns42jAhpYpOaq4zE1p9C6e2ZEYGH4DIdcJU+drcL9dh3R9K5diGxjW8RfQ/30oRNnBWpUEe0mvDa+c215sb8wQocLUKn0sMjeN9exSIEWeV9FUfrjVy52Zu4rYi1TrTjUwsaN13Ov6TKU8nRurTWr2cdYISwDQ2fWpAF65avlbERuPUPVKPLTGwuHxMo5C2ERW4+XDsKpKQZv5GD4eaWdIQhrMTFVCD7he+lQz/WNFDLgntaMPxX4aTQSUeiFcgGzFIJVVKIJrXNeiFcRFFTUaGUFPMGUhgar/tW2zmk11ZRO41sV4gFslkKGHfeN32FWM6TiWdOj6zkpqKv8BlzvDw3ago1t/DoSB39tD7uoqmpEzQmRdEZmVyOwTXKX4ud/n+eYMNHyItryovU7aeLz9jsoejzB+7vUVf3jAPAi6357; 4:P/AiBsxNxzkTvacCzF4RO0pdGmEG2nFUNA/A0GYgipn1vSEiVHAjNSiajfQ55HweDLxrypj/Syv3jAe1M6RrD6nHZrExmez4lbOjt/HuqVnx0DUIscr79yUkxz2zjS+uH+kGc9m+05FJypO57XrRSNmP7I/JkFCe+Kd4J/We6QoMsYCdJ72euJltVej3I4TVXTQCF6JerfGzBIpjTaenkiuVQGkx6qX5qm7srBjduBeRHuzII7Y/eVfoCFJXhcZL5QInNx6HlPNiKTD3KC3Z51KE+qDG5MruJmVcWU2G4dG7smrRXGlZZ0CoqHHTWxUkzaFvweFCxxAQ+qmzPcy8qeWYAs+tiBdezSjkMtrQ45u4rQyyklnq9XDEe0H9GKwwWle/ExiIkrE/8yI8wKftF8NzinJIcNajPSz6KCfM1ua4U9rwpgtBhIlqNJjiVTgG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(13018025)(13016025)(13024025)(13023025)(8121501046)(10201501046)(3002001); SRVR:SN1PR02MB1950; BCL:0; PCL:0; RULEID:; SRVR:SN1PR02MB1950; X-Forefront-PRVS: 09090B6B69 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR02MB1950; 23:bs5RebekT3/ztsA9pt+Rfhv+MMKG+KsEFfSeR2fCK?= =?us-ascii?Q?lZsrFlPGYjMJaFekxTceJf17V8K6KJr9diboDxeP6virVDdPDgbiVTG71Yqh?= =?us-ascii?Q?ImnF54M4ZrQ7z+RDaitB+29byP2WjSiu7CPE/40iTb75yztuo6eX+Q+x2kUB?= =?us-ascii?Q?vxLEG88G07UrXUs+/PN7VOazWzsjVPIe5DjFiJO0nI9iUv/H2cSa9xtdxZRA?= =?us-ascii?Q?rZ5PqoD0JOCbO9TVO65HtktE+UabLA3pcoPPjTDG0+lAm0ifir/jfCFGNWfo?= =?us-ascii?Q?BCxIzzda/WAd7Xb/44kIBuCWUd1EDhBWn/Bx5zVzs8FXoxUr68ZjlQPLRJs+?= =?us-ascii?Q?67HnKqjtLlyU5tQFb/weWTxNtWlXq8R2MQ/COkb06syGg5cNKeueV3p2ohjd?= =?us-ascii?Q?lvv3sR09r+anlTpUNpzdD5xXIGrlvRLjphaiM2+cp0M0RFYvFCPQqfiXpcNk?= =?us-ascii?Q?YdZxK1Rl4Fi3u0B9Gaa3RB+GrMD/kGsTrx+H1LpCW/qA1nFXn0Ceu9W3NUbj?= =?us-ascii?Q?jAohklltLYI6o0F6itDXaQT/VrmYaTpLmkMCOW5dayq/qsq7ehQc4dRvU5D3?= =?us-ascii?Q?iWo6HMWuVu7Zd50N15mhlYtdGeciYGf65zp89epRJwTwmG2j5bXUX0tivr17?= =?us-ascii?Q?SFUG2pbpagsjfIOah7QfhCodAOHUVDCqVrzpkjIu4xGVvCtdL7XqMVZ//c8+?= =?us-ascii?Q?OctATzkt/Orae0+p2Jvj9cmzPWJkPk7Vd44MuPE2d+6S4ONY2RcNGHWa/037?= =?us-ascii?Q?gmBjlxcqRQyykQqAy6TtjEJxVwOXPPPO4WtGopWVvSybRsQJaxFBgo59b9JY?= =?us-ascii?Q?XL6/l3YsDTlpQB6Wy+X4mIhihPf9qrgnlhqMbdGJ1mWLPQeU96Z4mOFVHI+V?= =?us-ascii?Q?jB0QOIpksfU7DAN6E1c17OJKBceUpOtrBKzb7u0DbTOqk0Wdr1jhqysvk/oK?= =?us-ascii?Q?tjvXPQ5/wpDmnfL29Y/i5vPuTpvrFTvMPkAkLQ+KhY9LTP7zPNkYQ5e5OLEj?= =?us-ascii?Q?VVIwo78GvzsgHajUhPQqzLgJUtSr5VLwPdXo/oiEVXrYQOpEM2FST/CZuIcW?= =?us-ascii?Q?mkBDAS9ex/sDIgc5LnBA980SRWFSPziU6cYxMQigSJo81sclYzyXDPX3Amk2?= =?us-ascii?Q?xumVxaJbhFh3zZ6sZA/g3NqAMp/4Vwt4tvQ3X0e8A2Q2SYCPAgbLdL9J6iG4?= =?us-ascii?Q?Y0RfvZDkdSZ8kWK+KEfpTzoBkbciLtPHkbxh2obTuEH9rClJxg54p9QqWO4P?= =?us-ascii?Q?z6P+lo+UQrHvK/92EQ3Ncuzfsu2Z+czUEswepIcbVSJCXXA6/YcC1bqBOz0b?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR02MB1950; 5:JEDSP5BlKxLjvHKPXSL0zRSsqE6U+E9RFGaZx287ajV0PFzNY+YxFWaE7GgiIJ+vboeZI1hULyw41hW3cCAp7ZljM0eud4V7AsIAMfqof7va12Z6neE/LIixmkNktjKVixRzpxT8tYc5t+slP6z8kA==; 24:t4wK6DoAlcmWuYktT07b1f97fLq6ypo9pGJFUMxG716qf0GM8BF/DGs4lA6Vmx4g4LEJMZ1Kn8l3k4mhR0unLFqKp58yQEb2ACh/hV5zDbA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 15:42:12.2872 (UTC) X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.20]; Helo=[avsrvexchhts2.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR02MB1950 X-SA-Exim-Connect-IP: 65.55.169.56 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Greg.Dowd@microsemi.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntpwg@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" I think GPS just has to be in the right 127 week window so it definitely can propagate quite early, that knocked a few receivers out a couple leap seconds ago. As I've mentioned in the past, I've debated the properties of the leap second and it's propagation with Mills in the past without complete satisfaction, at least on my part :-) As Harlan mentioned, the poll interval can exceed one day although that is really targeted at dialup which, other than NIST lockclock servers, is becoming obsolete. Mills mentioned deep space probes as well but that is tucked pretty far into the corner case. The goal, explicitly reviewed many times in the NTPv4 meetings at ietf and on the mailing list, was to allow advance notice of the impending leap. The rationale was that ntp was not responsible for implementing the leap but merely for providing notice that the event was going to occur to the operating system. As operating systems evolve, this model will continue to improve. If we agree that the os needs to handle the event, then presumably the requirement to gate the event to a particular leap event window (primary June/Dec, optional Mar/Sept) seems reasonable. The current logic, as I understand it, is that a local reference clock, if it survives the clustering algo, is allowed to set the leap event independently. If the source of the leap data is upstream via ntp, then a majority of the cluster has to agree to generate an event. Actually, the one I have not experimented with is that autokey passes the leap file, if present, at the server end of the association. At least it used to. How that is processed I do not know. At the risk of boring the audience, I am yet again going to point out that the clearing of the event can also be an important piece of state information. I suppose since ntp is implemented as a user space, asynchronous application, any quasi real-time requirements are hard to mandate. I have always believed that the leap indicator needed to be cleared immediately after the insertion/deletion. The issue is that most implementations repeat the second on insertion. When that occurs, there is an easy way to to distinguish the repeated time (which does violate the monotonic timescale concept) by using the leap bit set/clear as the unique element. However, this can be tough to implement reliably in software so Mills was against it. Even though he was against the concept, his earlier web documentation clearly showed the leap bits operating in the manner I described, at least from a computer science point of view. So, currently the clear logic is simply the above logic so the bits are cleared on the next round through the peer select crunching. Regardless of the choice, the input source (NIST ACTS, IRIG B-1344, PTP, NTP, GPS, Glonass) all use different time gates to provide warning so nothing is guaranteed. I am always a proponent of the KISS principle so I think the current month logic in 5905 works. -----Original Message----- From: ntpwg [mailto:ntpwg-bounces+greg.dowd=microsemi.com@lists.ntp.org] On Behalf Of Hal Murray Sent: Monday, April 11, 2016 3:20 AM To: Miroslav Lichvar Cc: ntpwg@lists.ntp.org; hmurray@megapathdsl.net Subject: Re: [ntpwg] leap second: definitions and DCF-77 EXTERNAL EMAIL GPS sends out the warning close to 6 months early. The HP driver has a hack/patch to only pass that on in June and December. (I added similar code to the Palisade driver for the recent leap.) I looked in log files from last June. It was only sent out one day in advance. I looked around a bit, but didn't find the filtering in the main code. I think it may be tangled up with the leap file code. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 11 18:53:59 2016 Return-Path: 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 015F312DC82 for ; Mon, 11 Apr 2016 18:53:59 -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 B4VaPOfF697o for ; Mon, 11 Apr 2016 18:53:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC412DC7E for ; Mon, 11 Apr 2016 18:53:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4A70586DBDB for ; Tue, 12 Apr 2016 01:53:57 +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 6C44086DB12 for ; Tue, 12 Apr 2016 01:53:34 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1apnWC-000BQi-FH; Tue, 12 Apr 2016 01:53:28 +0000 From: Harlan Stenn To: Greg Dowd In-reply-to: <8D2BF679AAC7C346848A489074F9F8BF7AB04B65@sjsrvexchmbx2.microsemi.net> References: Message from Miroslav Lichvar of "Mon, 11 Apr 2016 09:27:51 +0200." <20160411072751.GA27534@localhost> <20160411102018.2B665406070@ip-64-139-1-69.sjc.megapath.net> <8D2BF679AAC7C346848A489074F9F8BF7AB04B65@sjsrvexchmbx2.microsemi.net> Comments: In-reply-to Greg Dowd message dated "Mon, 11 Apr 2016 15:42:09 +0000." 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: Tue, 12 Apr 2016 01:53:28 +0000 Message-Id: Subject: Re: [ntpwg] leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntpwg@lists.ntp.org" , Hal Murray 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" Greg Dowd writes: > I think GPS just has to be in the right 127 week window so it > definitely can propagate quite early, that knocked a few receivers out > a couple leap seconds ago. As I've mentioned in the past, I've > debated the properties of the leap second and it's propagation with > Mills in the past without complete satisfaction, at least on my part > :-) As Harlan mentioned, the poll interval can exceed one day although > that is really targeted at dialup which, other than NIST lockclock > servers, is becoming obsolete. Mills mentioned deep space probes as > well but that is tucked pretty far into the corner case. Yes, and as Ulrich mentioned, another problem is that clients may be several layers deeper, so several poll intervals will be needed. Multiples, if there is "consensus voting" going on. > The goal, explicitly reviewed many times in the NTPv4 meetings at ietf > and on the mailing list, was to allow advance notice of the impending > leap. The rationale was that ntp was not responsible for implementing > the leap but merely for providing notice that the event was going to > occur to the operating system. As operating systems evolve, this > model will continue to improve. If we agree that the os needs to > handle the event, then presumably the requirement to gate the event to > a particular leap event window (primary June/Dec, optional Mar/Sept) > seems reasonable. > > The current logic, as I understand it, is that a local reference > clock, if it survives the clustering algo, is allowed to set the leap > event independently. If the source of the leap data is upstream via > ntp, then a majority of the cluster has to agree to generate an event. > Actually, the one I have not experimented with is that autokey passes > the leap file, if present, at the server end of the association. At > least it used to. How that is processed I do not know. I'd have to look, and I don't have time for that now. Autokey is not recommended/deprecated. Moving the leapseconds file around with NTS has not been proposed, and I don't see the value in a means to do that, either via NTS or a new extension field. The update-leap script should be fine for that, and there are other, similar ways otherwise dumb clients can get the leapseconds file (libcurl or libfetch, for example). > At the risk of boring the audience, I am yet again going to point out > that the clearing of the event can also be an important piece of state > information. I agree. > I suppose since ntp is implemented as a user space, > asynchronous application, any quasi real-time requirements are hard to > mandate. I have always believed that the leap indicator needed to be > cleared immediately after the insertion/deletion. I agree. > The issue is that > most implementations repeat the second on insertion. When that > occurs, there is an easy way to to distinguish the repeated time > (which does violate the monotonic timescale concept) by using the leap > bit set/clear as the unique element. However, this can be tough to > implement reliably in software so Mills was against it. Even though > he was against the concept, his earlier web documentation clearly > showed the leap bits operating in the manner I described, at least > from a computer science point of view. The above is true for POSIX timescales. NTF's General Timestamp API handles this better. And there is a lot of work to do there still. > So, currently the clear logic is simply the above logic so the bits > are cleared on the next round through the peer select crunching. It also goes to "what happens when ntpd is queried just before, during, and after a leap second event?" H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 11 23:15:16 2016 Return-Path: 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 AC35A12DCB0 for ; Mon, 11 Apr 2016 23:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 jSyJQfkcwhzq for ; Mon, 11 Apr 2016 23:15:14 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id DB2FE12D86D for ; Mon, 11 Apr 2016 23:15:14 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B7DB786DBEB for ; Tue, 12 Apr 2016 06:15: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 7884386DAB9 for ; Tue, 12 Apr 2016 06:14:53 +0000 (UTC) Received: from rrzmta2.uni-regensburg.de ([194.94.155.52]) by mail1.ntp.org with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aprb1-0003eF-QR for ntpwg@lists.ntp.org; Tue, 12 Apr 2016 06:14:52 +0000 Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E1EE764915 for ; Tue, 12 Apr 2016 08:14:41 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id C1A1743D for ; Tue, 12 Apr 2016 08:14:41 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 12 Apr 2016 08:14:44 +0200 Message-Id: <570CAE6F020000A10002092E@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Tue, 12 Apr 2016 08:14:39 +0200 From: "Ulrich Windl" To: Mime-Version: 1.0 Content-Disposition: inline X-SA-Exim-Connect-IP: 194.94.155.52 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Ulrich.Windl@rz.uni-regensburg.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Wtrlt: Antw: Re: leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" I forgot to send to the list.... >>>I wrote (11.04.2016 um 14:21) in Nachricht <570CAE3C.ED38.00A1.0@rz.uni-regensburg.de>: >>>> Harlan Stenn schrieb am 11.04.2016 um 10:39 in Nachricht > : > > Miroslav Lichvar writes: > >> The current wording in RFC 5905 is conflicting. Once it says it's day > >> and once it says it's month. The RFC indicates several times the field > >> is meant to be compatible with NTPv3, where it was just day > >> (unambigiously). > > > > Offhand, I don't recall the details of this well enough. My belief is > > that we've been doing the announcement a month in advance, but it will > > be easy enough to check. > > Hi! > > I cannot remember whether there is a "consensus algorithm for leap second > announcements" in the RFC. So what should a server do if one source announces > a leap second, and another doesn't? > > > > > I do know that we've known for years that one problem is that it is the > > poll interval can be 17, which is more than a day, so in that case it's > > not enough to rely on the leap bits for this notification. > > Exactly. Most likely someone who prolonged the polling interval just didn't > think about that. > The other thing is propagation to lower stratum which will take some extra > time. > > > > > I think it needs to be allowed any time during the month where it can > > happen. > > Interesting side-question: How long before and/or after the leap second > event MUST/MAY/SHOULD the leap announcement be set? > > If the kernel clock handles the leap second, it may not be reset before it > actually happened. If ntpd does the trick, it's quite different. If ntpd > samples (queues) the event, the actual announcements could be reset some time > before, but then once announced, the leap couldn't be cancelled. > > > > > Also note that for a while, *any* server that announced a leap second > > was enough to trigger this condition. This was a feature when the > > majority of systems out there did not handle this well. Now I think we > > might have switched to a "majority vote" in the case where the local > > system doesn't have a leapsecond file. Or something like that. > > See above. Instantaneously I feel like the leap announcement should be part > of the clustering and peer selection algorithm. In turn this means that the > announcement bits have to be stable for "a while". > > Random thought: If we put the date of the leap event in an extension field > (NTP format or TAI, maybe), ntpq and friends could provide better > diagnostics. > > Regards, > Ulrich > > _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 11 23:17:16 2016 Return-Path: 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 6AD2312E07B for ; Mon, 11 Apr 2016 23:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 tJa2NShF9VXu for ; Mon, 11 Apr 2016 23:17:14 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC4F12E039 for ; Mon, 11 Apr 2016 23:17:14 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 8E33686DC50 for ; Tue, 12 Apr 2016 06:17: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 848E086D55F for ; Tue, 12 Apr 2016 06:17:09 +0000 (UTC) Received: from rrzmta1.uni-regensburg.de ([194.94.155.51]) by mail1.ntp.org with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aprdE-0003hW-TH for ntpwg@lists.ntp.org; Tue, 12 Apr 2016 06:17:09 +0000 Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2B8B15798B for ; Tue, 12 Apr 2016 08:16:59 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id C11AC57972 for ; Tue, 12 Apr 2016 08:16:58 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 12 Apr 2016 08:17:01 +0200 Message-Id: <570CAEF9020000A100020932@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Tue, 12 Apr 2016 08:16:57 +0200 From: "Ulrich Windl" To: References: Message from Miroslav Lichvar of "Mon, 11 Apr 2016 09:27:51 +0200." <20160411072751.GA27534@localhost> <20160411102018.2B665406070@ip-64-139-1-69.sjc.megapath.net> <8D2BF679AAC7C346848A489074F9F8BF7AB04B65@sjsrvexchmbx2.microsemi.net> In-Reply-To: <8D2BF679AAC7C346848A489074F9F8BF7AB04B65@sjsrvexchmbx2.microsemi.net> Mime-Version: 1.0 Content-Disposition: inline X-SA-Exim-Connect-IP: 194.94.155.51 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Ulrich.Windl@rz.uni-regensburg.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Antw: Re: leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" >>> Greg Dowd schrieb am 11.04.2016 um 17:42 in Nachricht <8D2BF679AAC7C346848A489074F9F8BF7AB04B65@sjsrvexchmbx2.microsemi.net>: > I think GPS just has to be in the right 127 week window so it definitely can > propagate quite early, that knocked a few receivers out a couple leap seconds > ago. As I've mentioned in the past, I've debated the properties of the leap > second and it's propagation with Mills in the past without complete > satisfaction, at least on my part :-) As Harlan mentioned, the poll interval > can exceed one day although that is really targeted at dialup which, other > than NIST lockclock servers, is becoming obsolete. Mills mentioned deep > space probes as well but that is tucked pretty far into the corner case. I'd say long polling intervals are not for dial-up sources; they are for clocks that are raher stable compared to the jitter of the source. So the long polling interval will make the clock more stable than a short polling interval would (assuming that the clocks internal error is less then the jitter over the long polling interval). AFAIR, in NTP before v4 some integers would overflow with a longer polling interval, so it was not allowed... > > The goal, explicitly reviewed many times in the NTPv4 meetings at ietf and > on the mailing list, was to allow advance notice of the impending leap. The > rationale was that ntp was not responsible for implementing the leap but > merely for providing notice that the event was going to occur to the > operating system. As operating systems evolve, this model will continue to NTP is also not responsible for implementing time, but as a leap second introduced an "error" of 1 second, the same care as for propagating the correct time has to be taken to correctly proagate leap second information (not to talk about implementing the switch). > improve. If we agree that the os needs to handle the event, then presumably > the requirement to gate the event to a particular leap event window (primary > June/Dec, optional Mar/Sept) seems reasonable. NTP being portable across platforms cannot make such assumptions easily, I'm afraid. > > The current logic, as I understand it, is that a local reference clock, if > it survives the clustering algo, is allowed to set the leap event > independently. If the source of the leap data is upstream via ntp, then a > majority of the cluster has to agree to generate an event. Actually, the one > I have not experimented with is that autokey passes the leap file, if > present, at the server end of the association. At least it used to. How > that is processed I do not know. Maybe the idea was that clients could do additional verification... > > At the risk of boring the audience, I am yet again going to point out that > the clearing of the event can also be an important piece of state > information. I suppose since ntp is implemented as a user space, I had commented on a message of Harlan on that, but I'm afraid I just replied to him (until recently). > asynchronous application, any quasi real-time requirements are hard to > mandate. I have always believed that the leap indicator needed to be cleared > immediately after the insertion/deletion. The issue is that most > implementations repeat the second on insertion. When that occurs, there is > an easy way to to distinguish the repeated time (which does violate the > monotonic timescale concept) by using the leap bit set/clear as the unique > element. However, this can be tough to implement reliably in software so > Mills was against it. Even though he was against the concept, his earlier > web documentation clearly showed the leap bits operating in the manner I > described, at least from a computer science point of view. > > So, currently the clear logic is simply the above logic so the bits are > cleared on the next round through the peer select crunching. > > Regardless of the choice, the input source (NIST ACTS, IRIG B-1344, PTP, NTP, > GPS, Glonass) all use different time gates to provide warning so nothing is > guaranteed. I am always a proponent of the KISS principle so I think the > current month logic in 5905 works. > > > > -----Original Message----- > From: ntpwg [mailto:ntpwg-bounces+greg.dowd=microsemi.com@lists.ntp.org] On > Behalf Of Hal Murray > Sent: Monday, April 11, 2016 3:20 AM > To: Miroslav Lichvar > Cc: ntpwg@lists.ntp.org; hmurray@megapathdsl.net > Subject: Re: [ntpwg] leap second: definitions and DCF-77 > > EXTERNAL EMAIL > > > GPS sends out the warning close to 6 months early. The HP driver has a > hack/patch to only pass that on in June and December. (I added similar code > to the Palisade driver for the recent leap.) > > I looked in log files from last June. It was only sent out one day in > advance. > > > I looked around a bit, but didn't find the filtering in the main code. I > think it may be tangled up with the leap file code. > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 12 00:13:38 2016 Return-Path: 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 F032512E67A for ; Tue, 12 Apr 2016 00:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 bLvkrxbWXXp2 for ; Tue, 12 Apr 2016 00:13:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5E86E12E66A for ; Tue, 12 Apr 2016 00:13:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 5639F86DC04 for ; Tue, 12 Apr 2016 07:13:36 +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 185FC86DAE2 for ; Tue, 12 Apr 2016 07:11:21 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1apsTe-0004uc-SL for ntpwg@lists.ntp.org; Tue, 12 Apr 2016 07:11:21 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 94AE56314D; Tue, 12 Apr 2016 07:11:09 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3C7B7aR001189; Tue, 12 Apr 2016 03:11:08 -0400 Date: Tue, 12 Apr 2016 09:11:07 +0200 From: Miroslav Lichvar To: Harlan Stenn Message-ID: <20160412071107.GB27927@localhost> References: <20160411072751.GA27534@localhost> <20160411102018.2B665406070@ip-64-139-1-69.sjc.megapath.net> <8D2BF679AAC7C346848A489074F9F8BF7AB04B65@sjsrvexchmbx2.microsemi.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 12 Apr 2016 07:11:09 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] leap second: definitions and DCF-77 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntpwg@lists.ntp.org" , Hal Murray 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" On Tue, Apr 12, 2016 at 01:53:28AM +0000, Harlan Stenn wrote: > Greg Dowd writes: > > The current logic, as I understand it, is that a local reference > > clock, if it survives the clustering algo, is allowed to set the leap > > event independently. If the source of the leap data is upstream via > > ntp, then a majority of the cluster has to agree to generate an event. > > Actually, the one I have not experimented with is that autokey passes > > the leap file, if present, at the server end of the association. At > > least it used to. How that is processed I do not know. > > I'd have to look, and I don't have time for that now. If I understand the current code correctly, there is a timer which is set in the source selection when the survivors are announcing a leap second. One refclock is enough for that, with NTP sources there has to be a majority. On the last day of the month the timer sets the system leap status. That is what NTP clients get. It doesn't matter if the leap was from a refclock, the clients always see the leap only on the last day of the month. I agree it would be better if servers were allowed to announce it sooner. But at this point I think it's about compatibility. There are very few NTP server implementations and all recent versions seem to announce it on the last day of the month. The number of client implementations is much larger and we don't know how applications are interpreting the leap status. To me it seems safer to stick with one day interval for the announcement. Of course, in NTPv5 or some NTPv4 extension field it could be different. As for the errata I submitted for RFC 5905, it's supposed to fix a typo. The word "month" should have been "day" and it will be consistent with the two other occurences of "day" and the following sentence: A list of the packet header variables is shown in Figure 7 and described in detail below. Except for a minor variation when using the IPv6 address family, these fields are backwards compatible with NTPv3. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 12 02:33:25 2016 Return-Path: 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 BFAB012E998 for ; Tue, 12 Apr 2016 02:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 AEiA1vb5Qn3L for ; Tue, 12 Apr 2016 02:33:23 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBDE12E994 for ; Tue, 12 Apr 2016 02:33:23 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 930EC86DC14 for ; Tue, 12 Apr 2016 09:33:22 +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 37E8486DAB5 for ; Tue, 12 Apr 2016 09:33:01 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1apugm-00075G-2W for ntpwg@lists.ntp.org; Tue, 12 Apr 2016 09:33:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 39B6DC04B307; Tue, 12 Apr 2016 09:32:51 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3C9Wnb6007801; Tue, 12 Apr 2016 05:32:50 -0400 Date: Tue, 12 Apr 2016 11:32:49 +0200 From: Miroslav Lichvar To: Harlan Stenn Message-ID: <20160412093249.GC27927@localhost> References: <20160407121447.GE20410@localhost> <20160408085726.GA13598@localhost> <20160408132559.GA14867@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Comments on new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Sat, Apr 09, 2016 at 12:59:39AM +0000, Harlan Stenn wrote: > > > > > > draft-mayer-ntp-mac-extension-field-00 > > > The security folks tell me that it's better to not advertise the > > > algorithm. If you get adequate consensus from them that it's not an > > > issue to publish the hash function then OK. > > > > Ok, I can try. Who made the suggestion? Are they following this list? > > I believe I heard this from Sharon Goldberg and her team (who are > following this, TTBOMK) and also from at least one of the Cisco teams. Sharon, can you please comment on this point? What advantages does hiding the crypto hash have? (beside adding ~2 bits to the space the attacker has to search) > > > > > > draft-stenn-ntp-i-do-00 > > I'd like to see an example where the client or server does anything > > differently when the bit is set the other way, i.e. why it needs to be > > transferred in NTP packets. > > It goes to allowing the local NTP instance to do some high-level sanity > checks, and to have more information about "should I drop a packet that > contains an EF with no MAC protection or just ignore that EF?" Any example in which the client might drop the packet if the bit was set one way, but not if was set the other way? > > > > > > draft-stenn-ntp-ipv6-refid-hash-00 > > If you only want to prevent loop, they might not be exclusive. But if > > you want to use refid to detect you are using the same source as your > > server, mixing different kinds of refids in the same network will > > break it. > It was never a defined usage, and how valuable is this capability? Isn't that an obvious usage following from the definition? The reference ID is defined as a 32-bit code that identifies the source of the synchronisation. If different clients see different codes, is it still a reference ID? > I'm game to tweak the proposed language changes to show that sending the > legacy IPv6 refid hash is deprecated, because we're starting to use > values in the first octet in the 240.0.0.0/4 range for various special > cases. The calculation is the same, but the proposed new IPv6 refid > puts 0xFF as the first octet. Which increases the number of collisions between IPv6-based refids, creating more false positives in the loop detection and preventing synchronisation between peers that don't have the same source. > Returning to your point about other ways refids can be used, do you want > to avoid using a system that is sync'd with a specific refclock driver > just because another of your servers is also using that refclock driver? > What about, for example, all GPS? I might want to do that in some cases. As we have recently seen with the 13us error in GPS for instance, there are issues that can affect all refclocks of the same type and it might be useful to group sources by type. > If you already sync with a NIST server, does that mean you do not want > to sync with another server that syncs with NIST? Yes, I might want to ignore the second source. Older ntpd versions used to do exactly that. If not completely ignore, I might want to at least decrease the weight of the source. This is up to the implementation and its configuration. > > > > > > draft-stenn-ntp-leap-smear-refid-00 > > You can use a special refid to indicate leap smearing is active and > > reftime has special meaning. > > That seems like a lot of work for little gain, and it's a whole lot > messier, IMO. It's also, as I mentioned, not backward compatible. I think it is compatible and it is a cleaner approach than encoding the offset in refid. refid is supposed to identify a source, it's a discrete variable (unlike reference time). > > Very few client implementations look at the reference timestamp. ntpd > > as a client ignores it completely. From how it's specified in NTPv3 > > and NTPv4, there is about 44 bits that can set arbitrarily without > > breaking things. It just needs to be not newer than the transmit > > timestamp and not older than few hours. > > And several of those conditions you mention will not be valid during the > leap smear Which ones? > and older software *will not know this* so it seems like > this approach is creating new problems in the very population of clients > where we are trying to solve the leap smear issue. I don't think it creates any new problems. The clients either don't care about reference timestamp at all (this includes ntpd) or they just check if it's not too old (e.g. older than one day) and not newer than transmit timestamp. Reference timestamps are normally thousands of seconds old, a backward adjustment of one second will be well hidden in this. > I still think your approach is suboptimal. The 'ntpq -p' billboard will > only show a refid of 254.0.0.0 during the entire time of the leap smear, > and one will have to take extra steps to try and get the amount of > smear. Yes, an extra command is needed to get the reference time. Considering how rarely this will be used, I don't see that as a problem. The offset (encoded in refid or reftime) still needs to be converted to a decimal value and the user will likely have a script for that. > > Mode 6 is an ntpd-specific extension of NTP. > > No it's not. It's part of the NTPv3 Standard that was inadvertently > omitted from the NTPv4 Standard. Karen mentioned this again last week > at the IETF WG meeting. Ok, that's interesting. I hope it won't be added to the NTPv4 spec until it's fixed/redesigned to not allow traffic amplification. > > I think the monitoring caught it, that's not the problem. The problem > > was they were unusable for clients below them, it's an unexpected > > situation. A local reference was not an option as the servers and > > clients were required to always report real synchronisation distance. > > What is the real synchronization difference from a time island? > > Does it depend on the reference time and the sync distance at that time, > adding "PHI*elapsed seconds since sync" to that value? Yes. With a local reference the server reports zero synchronisation distance and the clients don't know how far from UTC they are. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 12 15:37:02 2016 Return-Path: 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 922EC12DEE6 for ; Tue, 12 Apr 2016 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.784 X-Spam-Level: X-Spam-Status: No, score=-7.784 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, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=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 Wi8YEGhA4qWd for ; Tue, 12 Apr 2016 15:37:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEE12DF1B for ; Tue, 12 Apr 2016 15:37:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id EDAC286DC8E for ; Tue, 12 Apr 2016 22:36:59 +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 A8FDA86DC8C for ; Tue, 12 Apr 2016 22:36:38 +0000 (UTC) Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aq6vA-000NZE-5d for ntpwg@lists.ntp.org; Tue, 12 Apr 2016 22:36:38 +0000 Received: by mail-wm0-x22f.google.com with SMTP id a140so71142264wma.0 for ; Tue, 12 Apr 2016 15:36:32 -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:cc; bh=mGl7+UGJvSzUtm5HwYHgyiBaQUX4DoucQwz2AMnZrz4=; b=FjAxamJKK2JWBSJMOrKxGafieytsiySCz/tWc49+bo1xeddMtptqe5wnkilvfRlH33 hiUngLTWLirFIiMVzp4bVMmXz1VndPOJ795X25MIzUYjbhrppWeaDvWjK8cnv9Ld+9US k2ExQUg8yIetAEBinYFJEDizbQozQMPgKAj3DVuWs7qN3B/3ymDK9IRFgU16jqMYkCgD /akzYx8Y8DKYbmMFUk7w20tijYvF0QFtFQfHeexZfY3dg9Jj71KCdQ5/7yOGM4+Efe+2 ouDPj9gcJJAEtWncdRLjM/P+fNbLkJdH0A8+vvvTfRSZixXWLi1L4W1ndwYbCIQQ0Jnx vX6A== 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:cc; bh=mGl7+UGJvSzUtm5HwYHgyiBaQUX4DoucQwz2AMnZrz4=; b=iYK5IDHTPT+VFNVKap7AuJo7wtDBGXINfJE8WpDMDbhUvXtPs/hb4BBqA+To0lQ+qn tuilED6UJI6/HlMy11nfhmpyrAKfJzVRoEh0IYOVlX3B48XSbIbxZoy7lrvTFUzxtIpO FJCgiyOk955Tl1+kcm4QtiucGj1wxw2VHPBJqALZMO2An/qnMj0KKkcA9cahTTjGG/Hz vJR/pzbIotvjvx9jlW71ORC5XUEGwG4YDkq02a8kB74EBRmmpbAYFc9i9TKUNjK9aKaL M11p1HjqzUWrqVt+GZ4Z3Nvt4WLpy1/+/dNA/P23DMdj8u3hJ4fUqADFnW3I//oUcwhP PpUQ== X-Gm-Message-State: AD7BkJKJ1vkOgmZ9QP8OmYKelWnxvitrMdLnm08SirPlfd1lR3dH0dKaGBQapCLDtPF1UhMsVUvQo3XWOuUZSg== X-Received: by 10.28.156.10 with SMTP id f10mr28518983wme.42.1460500590532; Tue, 12 Apr 2016 15:36:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Tue, 12 Apr 2016 15:35:51 -0700 (PDT) In-Reply-To: <20160407121447.GE20410@localhost> References: <20160407121447.GE20410@localhost> From: Sharon Goldberg Date: Tue, 12 Apr 2016 18:35:51 -0400 X-Google-Sender-Auth: kWVJj-xVF7_6k7MJFfrjuMnTHBg Message-ID: To: Miroslav Lichvar X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::22f 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 new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group Content-Type: multipart/mixed; boundary="===============4210627952513865368==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============4210627952513865368== Content-Type: multipart/alternative; boundary=001a114b4378e49dfe0530514a5a --001a114b4378e49dfe0530514a5a Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 8:14 AM, Miroslav Lichvar wrote: > I've few quick comments and questions on the new drafts. I can expand > on that later if there is any interest. > > draft-mayer-ntp-mac-extension-field-00 > - I'm not sure if hiding the length of the MAC using padding with > random data is really useful. This was discussed before. The > attacker can search for the key in parallel using all hash > functions. As their number is very small, the slowdown is > insignificant. > I agree with Miroslav on this. There is no security benefit in hiding the hash function being used. The attacker can just brute force try all hash functions. There are very few hash function to try. Other protocols (eg TLS, DNSSEC) advertise their ciphersuites in the clear. (Note I have not yet read the draft. Will try to do so soon) Sharon --001a114b4378e49dfe0530514a5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 7, 2016 at 8:14 AM, Miroslav Lichvar <mlichvar@redhat.com&g= t; wrote:
I've few quick comme= nts and questions on the new drafts. I can expand
on that later if there is any interest.

draft-mayer-ntp-mac-extension-field-00
- I'm not sure if hiding the length of the MAC using padding with
=C2=A0 random data is really useful. This was discussed before. The
=C2=A0 attacker can search for the key in parallel using all hash
=C2=A0 functions. As their number is very small, the slowdown is
=C2=A0 insignificant.

I agree with Miroslav on this. There is no= security benefit in hiding the hash function being used.=C2=A0 The attacke= r can just brute force try all hash functions. There are very few hash func= tion to try.

Other protocols (eg TLS, DNSSEC) = advertise their ciphersuites in the clear.

(Note I have not yet read the draft.=C2=A0 Will try to do = so soon)

Sharon
--001a114b4378e49dfe0530514a5a-- --===============4210627952513865368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============4210627952513865368==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 12 15:39:37 2016 Return-Path: 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 41D0E12D1A8 for ; Tue, 12 Apr 2016 15:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.784 X-Spam-Level: X-Spam-Status: No, score=-7.784 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, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=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 98Tm0zWNFv31 for ; Tue, 12 Apr 2016 15:39:35 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA3812D6AE for ; Tue, 12 Apr 2016 15:39:35 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 277AC86DCCE for ; Tue, 12 Apr 2016 22:39:35 +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 DF78C86DC8D for ; Tue, 12 Apr 2016 22:39:29 +0000 (UTC) Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aq6xy-000Ne0-Kc for ntpwg@lists.ntp.org; Tue, 12 Apr 2016 22:39:29 +0000 Received: by mail-wm0-x22f.google.com with SMTP id f198so205663527wme.0 for ; Tue, 12 Apr 2016 15:39:26 -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:cc; bh=lc6f3T8BoZVkW9xqON0VV/8q6oDjivXet0+qndCck7Q=; b=g2izpICca7VcsVDq65JzfBMNhvp7hE3pwH4pE8bzANsUHNc1VsrGKbPQeYm5m/NdOU fwV18ybjqv7AbRuO1bu7p0inn2+6KDWWp3fk9Ql5cVv+mWDF+fwBV0WyamFi75+xPEYb U3qc0NT6Cw98o4Ha0r16zOw2JGKXbcJAcL64mDq426XZ8fwMwSzvwKtVwMqjIOFRwYA0 FH9u8J8KK3AYNUEoWeT5ghQmXZRSb5KkD+OdhpbdSHEVn3DbJ/HMvYY/MmM6rEcw0xBT rZoqa8vU+XPyhNlhjt1EO1uuMaF9yPU6cbxCAujaVmjDfCEimsQDqg4CmoOvoGMbItls HqdA== 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:cc; bh=lc6f3T8BoZVkW9xqON0VV/8q6oDjivXet0+qndCck7Q=; b=lR5wHcNozs56jjvHiI2tvdliGFptCREV5QjxGFc1RoKHHD38r00CGCwQKKhmenF5lp 0owLiG/UuLyw8PjFyCOScgdpSp0MtrD60wmjk7Zc/iDNDu9wZ46LspSdktUI5WDFL8+A LmA3WHBFJI+A7i5PrEsMaTOsfG0pfOoTfiqMb+jXBloRwOdz0vOjXPKKbJrkoBzXY4Bj 2G5cCdTJHizLL56VAIgv3UkzhhIxjJ5kKeEbB+8VxUiMlwZzR36cqXxs7K8hElgLJP02 RkHL7bTpPlzblqwZl7eUXL+09PR69ita18vHWngAUup4GdhDUtrEkFTkzMIa02nCn/AB 4vFQ== X-Gm-Message-State: AOPr4FU+myy25BRCXxQvzJkKkGKTyIzkrCQq+r0qO8yOZQ6mpeYzR1Qi+ydefyXiJln3PJKSDrkPS0ReeiEOGA== X-Received: by 10.194.5.101 with SMTP id r5mr6568595wjr.47.1460500765204; Tue, 12 Apr 2016 15:39:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.200 with HTTP; Tue, 12 Apr 2016 15:38:45 -0700 (PDT) In-Reply-To: <20160412093249.GC27927@localhost> References: <20160407121447.GE20410@localhost> <20160408085726.GA13598@localhost> <20160408132559.GA14867@localhost> <20160412093249.GC27927@localhost> From: Sharon Goldberg Date: Tue, 12 Apr 2016 18:38:45 -0400 X-Google-Sender-Auth: 0kJkFZq8ENmkgIVT0pNZ1GSov6E Message-ID: To: Miroslav Lichvar X-SA-Exim-Connect-IP: 2a00:1450:400c:c09::22f 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 new drafts X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: NTP Working Group Content-Type: multipart/mixed; boundary="===============0411219808136126967==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============0411219808136126967== Content-Type: multipart/alternative; boundary=047d7b5d3e5c4de66a05305155ad --047d7b5d3e5c4de66a05305155ad Content-Type: text/plain; charset=UTF-8 On Tue, Apr 12, 2016 at 5:32 AM, Miroslav Lichvar wrote: > On Sat, Apr 09, 2016 at 12:59:39AM +0000, Harlan Stenn wrote: > > > > > > > draft-mayer-ntp-mac-extension-field-00 > > > > The security folks tell me that it's better to not advertise the > > > > algorithm. If you get adequate consensus from them that it's not an > > > > issue to publish the hash function then OK. > > > > > > Ok, I can try. Who made the suggestion? Are they following this list? > > > > I believe I heard this from Sharon Goldberg and her team (who are > > following this, TTBOMK) and also from at least one of the Cisco teams. > > Sharon, can you please comment on this point? What advantages does > hiding the crypto hash have? (beside adding ~2 bits to the space the > attacker has to search) > > I agree with Miroslav. There is no benefit to hiding the hash function (beyond ~2 bits added to the brute force space). Perhaps something I said was misunderstood? I'm strongly in favor of hiding the identity of servers in the refid . Perhaps that is the source of the confusion. Sharon --047d7b5d3e5c4de66a05305155ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 12, 2016 at 5:32 AM, Miroslav Lichvar <mlichvar@redhat.com&g= t; wrote:
On Sat, Apr 09, 2016 at = 12:59:39AM +0000, Harlan Stenn wrote:
> > > > > > draft-mayer-ntp-mac-extension-field-00
> > > The security folks tell me that it's be= tter to not advertise the
> > > algorithm.=C2=A0 If you get adequate consensus from them tha= t it's not an
> > > issue to publish the hash function then OK.
> >
> > Ok, I can try. Who made the suggestion? Are they following this l= ist?
>
> I believe I heard this from Sharon Goldberg and her team (who are
> following this, TTBOMK) and also from at least one of the Cisco teams.=

Sharon, can you please comment on this point? What advantages does hiding the crypto hash have? (beside adding ~2 bits to the space the
attacker has to search)


I agree with Miroslav. There is no ben= efit to hiding the hash function (beyond ~2 bits added to the brute force s= pace).=C2=A0 Perhaps something I said was misunderstood?

= I'm strongly in favor of hiding the identity of servers in the refid . = Perhaps that is the source of the confusion.

Sharon

--047d7b5d3e5c4de66a05305155ad-- --===============0411219808136126967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============0411219808136126967==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 19 19:51:47 2016 Return-Path: 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 B214A12EAF7 for ; Tue, 19 Apr 2016 19:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.914 X-Spam-Level: X-Spam-Status: No, score=-7.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sQ3Xlf90m9Xf for ; Tue, 19 Apr 2016 19:51:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id AEB7212EAF8 for ; Tue, 19 Apr 2016 19:51:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6A47B86DC0F for ; Wed, 20 Apr 2016 02:51:45 +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 8A79986D48C for ; Wed, 20 Apr 2016 01:51:01 +0000 (UTC) Received: from userp1040.oracle.com ([156.151.31.81]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ashI4-0003UW-5x for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 01:51:01 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3K1ooD5028639 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Apr 2016 01:50:51 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3K1onaQ025539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Apr 2016 01:50:50 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3K1onHm016159 for ; Wed, 20 Apr 2016 01:50:49 GMT Received: from [10.154.111.70] (/10.154.111.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Apr 2016 18:48:37 -0700 References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> To: ntpwg@lists.ntp.org From: brian utterback Organization: Oracle Corporation Message-ID: <5716DFF2.60805@oracle.com> Date: Tue, 19 Apr 2016 21:48:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-SA-Exim-Connect-IP: 156.151.31.81 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: brian.utterback@oracle.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7276687655434035001==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" This is a multi-part message in MIME format. --===============7276687655434035001== Content-Type: multipart/alternative; boundary="------------080304080302020603000705" This is a multi-part message in MIME format. --------------080304080302020603000705 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I have been trying to figure out the procedure for figuring out if there is an extension field and/or a legacy MAC and where they are. This seems to be covered in section 7.5.1. I am looking at this in terms of an implementer. I feel that there is some length restriction left out of the document because there seems to be cases as is that are ambiguous. If the packet is 12 words long, there is no extension fields and no legacy mac. No problem. If the data past the first 12 words is greater then 24 octets, then we know there is is at least on extension field, so we can read the length of the first extension and move past it. If the length got us to the end of the packet, we are done, there was one extension and no legacy MAC. We know from 7.5.1.4 that if there is no MAC then the last extension in the packet must be 28 octets or greater but an extension might be that long and not be the last one. Also, there is no limit on how small an extension might be if it is not the last. And there is no maximum or minimum size of the legacy MAC if it is with an extension field. So, after getting past the first extension field, unless it's length got me to the end of the packet I can't say if what I am pointing to is an extension or a MAC and I don't see a way to determine it. The same thing happens if the residual data after the regular NTP packet is less than 24 octets. It might be a MAC, or it might be a short extension field followed by a short MAC. On 2/9/2016 1:39 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Time Protocol of the IETF. > > Title : The Network Time Protocol Version 4 (NTPv4) Extension Fields > Authors : Tal Mizrahi > Danny Mayer > Filename : draft-ietf-ntp-extension-field-07.txt > Pages : 8 > Date : 2016-02-08 > > Abstract: > The Network Time Protocol Version 4 (NTPv4) defines the optional > usage of extension fields. An extension field, defined in RFC5905, is > an optional field that resides at the end of the NTP header, and can > be used to add optional capabilities or additional information that > is not conveyed in the standard NTP header. This document updates > RFC5905 by clarifying some points regarding NTP extension fields and > their usage with Message Authentication Codes (MAC). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ntp-extension-field/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ntp-extension-field-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-extension-field-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg -- Oracle Brian Utterback | Principal Software Engineer Phone: +1 6038973049 Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 ------------------------------------------------------------------------ All working systems eventually start to exhibit their own agenda ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment --------------080304080302020603000705 Content-Type: multipart/related; boundary="------------090007010609070306070202" --------------090007010609070306070202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit I have been trying to figure out the procedure for figuring out if there is an extension field and/or a legacy MAC and where they are. This seems to be covered in section 7.5.1. I am looking at this in terms of an implementer. I feel that there is some length restriction left out of the document because there seems to be cases as is that are ambiguous.

If the packet is 12 words long, there is no extension fields and no legacy mac. No problem.

If the data past the first 12 words is greater then 24 octets, then we know there is is at least on extension field, so we can read the length of the first extension and move past it. If the length got us to the end of the packet, we are done, there was one extension and no legacy MAC.

We know from 7.5.1.4 that if there is no MAC then the last extension in the packet must be 28 octets or greater but an extension might be that long and not be the last one. Also, there is no limit on how small an extension might be if it is not the last. And there is no maximum or minimum size of the legacy MAC if it is with an extension field. So, after getting past the first extension field, unless it's length got me to the end of the packet I can't say if what I am pointing to is an extension or a MAC and I don't see a way to determine it. The same thing happens if the residual data after the regular NTP packet is less than 24 octets. It might be a MAC, or it might be a short extension field followed by a short MAC.


On 2/9/2016 1:39 AM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol of the IETF.

        Title           : The Network Time Protocol Version 4 (NTPv4) Extension Fields
        Authors         : Tal Mizrahi
                          Danny Mayer
	Filename        : draft-ietf-ntp-extension-field-07.txt
	Pages           : 8
	Date            : 2016-02-08

Abstract:
   The Network Time Protocol Version 4 (NTPv4) defines the optional
   usage of extension fields. An extension field, defined in RFC5905, is
   an optional field that resides at the end of the NTP header, and can
   be used to add optional capabilities or additional information that
   is not conveyed in the standard NTP header. This document updates
   RFC5905 by clarifying some points regarding NTP extension fields and
   their usage with Message Authentication Codes (MAC).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-extension-field/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ntp-extension-field-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-extension-field-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

--
Oracle
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
All working systems eventually start to exhibit their own agenda
Green Oracle Oracle is committed to developing practices and products that help protect the environment
--------------090007010609070306070202 Content-Type: image/gif; name="oracle_sig_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oracle_sig_logo.gif" R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9A QP/AwP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPV IDfcOQa6A8yRaO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1n BGRmhl8AWiUJYicCAIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4 AAunsqg/dw95KwdfBgzBqKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1It xK7aKl8lCl8DAfALW1+2rUi3QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyI qRgMcA8a/z5AZQWXOxEdHxwUgfIgsX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjU mYLnomokcDlS4s0eFzQNqvXDEyzmAwFPyaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpF RxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt 1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvPm8OVEkAIYLYPThSsRIpEQJr1x94QBIT0 9FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8ABijggAQWaOCBCCao4A+CDDbo4IMQ RijhhBQKGAIAOw== --------------090007010609070306070202 Content-Type: image/gif; name="green-for-email-sig_0.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="green-for-email-sig_0.gif" R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zP uZu2lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxj SYdrOp/Q6NPgYqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMq DwFCAAIFPIYDgidrOUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQG BH82TpMicD0pAgQACToDAchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLD LS8MAvf497ruCZ+gOA0gfNt3AIK0J/JWKVzIsEQIADs= --------------090007010609070306070202-- --------------080304080302020603000705-- --===============7276687655434035001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7276687655434035001==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Apr 19 23:52:55 2016 Return-Path: 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 D2D7112DD37 for ; Tue, 19 Apr 2016 23:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4dGrRDfsQ7om for ; Tue, 19 Apr 2016 23:52:54 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2595212D0C0 for ; Tue, 19 Apr 2016 23:52:54 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 13F0A86DBEB for ; Wed, 20 Apr 2016 06:52:53 +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 59C9986D4A6 for ; Wed, 20 Apr 2016 05:47:28 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1askz2-000NFy-NI; Wed, 20 Apr 2016 05:47:28 +0000 From: Harlan Stenn To: brian utterback In-reply-to: <5716DFF2.60805@oracle.com> References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> Comments: In-reply-to brian utterback message dated "Tue, 19 Apr 2016 21:48:34 -0400." 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: Wed, 20 Apr 2016 05:47:28 +0000 Message-Id: Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" brian utterback writes: > I have been trying to figure out the procedure for figuring out if > there is an extension field and/or a legacy MAC and where they > are. This seems to be covered in section 7.5.1. I am looking at this > in terms of an implementer. I feel that there is some length > restriction left out of the document because there seems to be cases > as is that are ambiguous. I really don't see this as a big deal, and I don't think we need special considerations. I think I described all of this before, but I'm not finding those emails. There are two situations, newer code and older code. With newer code, we can expect people to be using various combinations of: - unknown-EF: this should be more rare if folks implement I-Do - MAC-EF - Last-EF - legacy MAC Older code will, at best support: - autokey - legacy MAC To go a bit beyond this, old code will have either a legacy MAC, or a single autokey packet and a legacy MAC. Nothing else, unless there are unknown implementation that chose to use unregistered EFs. An EF consists of 2 bytes of field type and 2 bytes of field length. A MAC consists of a 4-byte key ID follwed by the digest. It's pretty easy to do a test for an EF. You can look up the Field Type and see if it's anything expected or normal. For the legacy case, that's going to be a limited number of first byte values and a 2nd byte of '2'. The next 2 bytes must either equal the remaining length of the data, or be less than the remaining length of data. It's pretty easy to test for a legacy MAC. The first 4-bytes will be a key ID, and for all known existing cases, the digest payload will be a 16 byte MD5 key (20 bytes total), which should be, by far, the most prevalent case. Other cases include: MD2 MD4 MDC2 RIPEMD160 SHA SHA1 or any other hash algoritm the OpenSSL library supports. These can be 256 or even 512 bit hashes. So other legacy MAC lengths can easily be 24, 36, or 68 bytes long. There are more possibilities. The interesting thing here is the key ID. If the key ID is < 65535, this will be a symmetric key. If we have that keyid in our tables, we can validate it. If we do not have that keyid in our tables, if this is a legacy MAC we *cannot* validate it. If the key ID is > 65535, it must be an autokey session key and we can validate it if we have a matching key, and we *cannot* validate it if it's not in our key list. So we have a variety of ways to handle packets that have extra data in them, and this boils down to: - length checks: if it's an EF and there is extra data, what comes after? - key ID checks - there should never be a packet from an old system with more than 1 EF, and if an old system has 1 EF what comes next must be a legacy MAC - current proposals have ways to completely avoid these problems Please check out the relevant bits of RFC5905 and RFC5906. I'm sure we can better document these things, if that is really necessary and useful. Can people screw things up and make things difficult? Yes. And I'd like to see valid use-cases for these situations. Let's be aware of the difference between "being thorough" and "overengineering" in this case. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 00:56:42 2016 Return-Path: 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 92EC312DE45 for ; Wed, 20 Apr 2016 00:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Kyxz64dKL1WQ for ; Wed, 20 Apr 2016 00:56:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7709E12DDA6 for ; Wed, 20 Apr 2016 00:56:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 35D3F86DBC8 for ; Wed, 20 Apr 2016 07:56:40 +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 77F0186DAE5 for ; Wed, 20 Apr 2016 05:53:09 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1asl4X-000NGI-Az; Wed, 20 Apr 2016 05:53:09 +0000 From: Harlan Stenn To: brian utterback In-reply-to: <5716DFF2.60805@oracle.com> References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> Comments: In-reply-to brian utterback message dated "Tue, 19 Apr 2016 21:48:34 -0400." 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: Wed, 20 Apr 2016 05:53:09 +0000 Message-Id: Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" I'll also add that I have a number of suggestions for improvements to this document. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 00:57:47 2016 Return-Path: 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 842D012E734 for ; Wed, 20 Apr 2016 00:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.915 X-Spam-Level: X-Spam-Status: No, score=-7.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 yHmyewd-Zhm8 for ; Wed, 20 Apr 2016 00:57:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id A226912E5E4 for ; Wed, 20 Apr 2016 00:57:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 8521986DBF0 for ; Wed, 20 Apr 2016 07:57:45 +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 2C54686DAE5 for ; Wed, 20 Apr 2016 06:35:41 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asljX-0007q1-LP for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 06:35:41 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B36D83B3C2; Wed, 20 Apr 2016 06:35:30 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3K6ZTDx032655; Wed, 20 Apr 2016 02:35:30 -0400 Date: Wed, 20 Apr 2016 08:35:29 +0200 From: Miroslav Lichvar To: brian utterback Message-ID: <20160420063529.GL17272@localhost> References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5716DFF2.60805@oracle.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Tue, Apr 19, 2016 at 09:48:34PM -0400, brian utterback wrote: > I have been trying to figure out the procedure for figuring out if there > is an extension field and/or a legacy MAC and where they are. This seems > to be covered in section 7.5.1. I am looking at this in terms of an > implementer. I feel that there is some length restriction left out of > the document because there seems to be cases as is that are ambiguous. I think the algorithm needed for parsing extension fields and MACs in NTP packets is supposed to be simple after this RFC. If special MACs are not negotiated as described in 7.5.1.3, the parsing should be: 1. parse header of NTP packet (48 octets) 2. if remaining length == 0: return success else if remaining length >= 28: parse an extension field, if not valid return error move pointer by the length of the extension field else if remaining length in (4, 20, 24): parse legacy MAC return success else: return error 3. go to 2 > We know from 7.5.1.4 that if there is no MAC then the last extension in > the packet must be 28 octets or greater but an extension might be that > long and not be the last one. Also, there is no limit on how small an > extension might be if it is not the last. 7.5 mentions the minimum length is 16 octets, this didn't change with the new RFC. Are you saying it should be specified with a MUST? > And there is no maximum or > minimum size of the legacy MAC if it is with an extension field. As the second paragraph in 1. says, legacy MACs are 4, 20 or 24 octets long. This corresponds to NAK, MD5 and SHA1 MACs and should apply to packets with and without extension fields. > So, > after getting past the first extension field, unless it's length got me > to the end of the packet I can't say if what I am pointing to is an > extension or a MAC and I don't see a way to determine it. If the remaining length is >= 28, it should be an extension field. > The same thing > happens if the residual data after the regular NTP packet is less than > 24 octets. It might be a MAC, or it might be a short extension field > followed by a short MAC. It's a MAC, because last extension field is required to be at least 28 octets. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 01:58:29 2016 Return-Path: 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 0DA2A12D9B6 for ; Wed, 20 Apr 2016 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.805 X-Spam-Level: X-Spam-Status: No, score=-7.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=isoc.onmicrosoft.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 vSA7A-1f1GON for ; Wed, 20 Apr 2016 01:58:26 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8C512D139 for ; Wed, 20 Apr 2016 01:58:26 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4AA8986DBE2 for ; Wed, 20 Apr 2016 08:58:26 +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 6B22386DB22 for ; Wed, 20 Apr 2016 07:08:59 +0000 (UTC) Received: from mail-bn1bon0055.outbound.protection.outlook.com ([157.56.111.55] helo=na01-bn1-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asmFl-0008PB-ND for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 07:08:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wIVrUTH4aa1S1X5XbOhLSoteFHdtjQuA2bZbpG9BwIE=; b=g3ycDiQb8ag5wj8ptINDjjXEYTJIo7jbD/VqnQcOySx79WpnVDbdmkDQYdjfdRS3dGfyDemOlbuOzOYWL1hJKXOSUq5CkWT8XNCZaJq4KX0dlkz0mBKIzOnsDI9pKwhUHMyMXr45n4mC375zBdLmM/zlU6riUnBzHvi9iuk3vLk= Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) by DM2PR0601MB1119.namprd06.prod.outlook.com (10.160.218.14) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 20 Apr 2016 07:08:48 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 07:08:47 +0000 From: Karen O'Donoghue To: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Thread-Topic: draft minutes from NTP/TICTOC meeting @ IETF 95 (4 April 2016) Thread-Index: AQHRmtN73K3BWcnq30SExm5Zhy3X2g== Date: Wed, 20 Apr 2016 07:08:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.ntp.org; dkim=none (message not signed) header.d=none; lists.ntp.org; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [46.218.58.213] x-ms-office365-filtering-correlation-id: 92cbdcb9-5e4d-4bcd-438c-08d368ea9e6f x-microsoft-exchange-diagnostics: 1; DM2PR0601MB1119; 5:mL2Jqic0B7DuaRBJ1DTnMzvwG22guEX4Y23rI9/NTKQdZK8jqPtFl+57CuSaE5BCkdF//Rzfq4IC2FQuRohpIxPibfvG81wslVABXQtyt3km56tmBFebSqPPYWd3Tdbopm6v+Ja+JuSh/Pdg30Q0uQ==; 24:6XmJQu1os3tguLXfvGJF/t7nxQkEXFcyL/g7u+G+I/mN4FhMuLoSx0TuxSRwLd1Vez0FWPjNmwXOE16KhT2dNG0QLzhDVmYl5bX9SRxmFTQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB1119; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR0601MB1119; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1119; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(54356999)(50986999)(33656002)(82746002)(2501003)(5008740100001)(3846002)(1096002)(87936001)(92566002)(586003)(102836003)(1220700001)(83716003)(6116002)(86362001)(122556002)(77096005)(107886002)(36756003)(66066001)(189998001)(99286002)(10400500002)(2900100001)(229853001)(106116001)(5004730100002)(2906002)(5001770100001)(3280700002)(3660700001)(5002640100001)(81166005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB1119; H:DM2PR0601MB1118.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <01BAF6153405AA4B9200C6BB4062E209@namprd06.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 07:08:47.4880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB1119 X-SA-Exim-Connect-IP: 157.56.111.55 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] draft minutes from NTP/TICTOC meeting @ IETF 95 (4 April 2016) X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" Folks, I have uploaded (and provided below) draft minutes from our meeting @ IETF 95. If you have any comments or changes please speak up. Our next meeting will be 5 May 2016. Watch for the coming announcement. Regards, Karen ************* NTP/TICTOC joint meeting 5 April 2016 Samuel Weiler as scribe Karen gave an update on WG status. Kristof gave an update on NTS, consistent with the slideware. Sam (your scribe): what's the use case for client/mutual auth? Are we just creating an unneeded/unused code path? Kristof: paid service. Jared: cost of hardware for NTP is so low that the idea of a paid service is not commmercially viable. Can't imagine a case where we need this in the protocol (v. IP filtering). This just adds complexity and opportunities for abuse. Harlan: re: why do server auth: [didn't understand answer] Karen proposes to set up a design team to resolve some of these issues. Send her mail if you're interested. Brian Haberman (AD): asks that Karen be clear about what design team is dealing with, and tell the WG that. Karen: is it okay if we say "address WGLC comments"? Brian: Yes, if it is scoped that narrowly. Sharon Goldberg: Why do we have periodic server seed refresh? (address this in design team?) Karen: send that one to the list. Karen: send any other issues to the list NOW, so we can assign them to the design team, if appropriate. -- Denis gave an update on the NTP BCP. Karen asked when Denis thought this might be ready for WGLC; Denis thinks MAYBE in July. Harlan spoke sans slides, giving some background on the i-do, last-extension, and mac-extension-field drafts. Danny continued the discussion of the mac-extension-field draft. Karen: does it make sense to combine these? Danny believes they are stand-alone. Eric Raymond thinks this design looks good; he'll supply a second interoperable implementation. Harlan, again sans slideware, gave short briefs on his three REFID drafts. Sharon asks if nonces are per-client or reused. Harlan expects them to be per-client. Sharon sees issues with backwards compatibility. Sharon counter-proposes that since a client knows where it got its time, it can put put jibberish in REFIDs EXCEPT if it gets asked for time by the server it knows it's using. Harlan says that might work, but he's not sure. Karen asks Sharon to summarize this on list, and Harlan and Sharon to work on a combined statement. Karen thinks these docs can proceed independently. -- TICTOC part of meeting. Karen gave a briefing on doc status. Yuanlong Jiang presented on a YANG data model for IEEE 1588v2. No one in the room admitted to having read the document. Karen suggests taking this to the list because the prople who might be paying attention aren't in the meeting today. Karen explains that this may, at some point, be fully transferred to 1588. Yuanlong Jiang also presented on Scalable Synchronization Networks (SCSN) Problems and Analysis. Karen pointed out that there is a separate mailing list set up for this week; 5-6 people in the room are aware of that list. Karen does not think adding this to the (rechartered) WG's work plan is wise. Brian Haberman asks how much this as been discussed with OPS/MGT folks. Brian would like to avoid point solutions for different protocols. Karen suggests pulling OPS/MGT types into the conversation on that mailing list. -- Next steps. Suresh will be the new AD. Karen plans to continue monthly virtual interim schedule. Recharter will presumably include NTPv4 items but not NTPv5 (yet). There are several holes left in the current documentation set, including interleave and mode 6. There are opportunities for those newer to the IETF to edit documents. Karen is supportive of using little drafts to clarify and correct issues. Next virtual interim will be May 5th. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 01:59:52 2016 Return-Path: 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 1FD8612E6B7 for ; Wed, 20 Apr 2016 01:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 Qj5-OMbHOOB6 for ; Wed, 20 Apr 2016 01:59:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 926F612E5D4 for ; Wed, 20 Apr 2016 01:59:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 871F586DC83 for ; Wed, 20 Apr 2016 08:59:49 +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 0C76986DB8F for ; Wed, 20 Apr 2016 07:57:06 +0000 (UTC) Received: from rrzmta2.uni-regensburg.de ([194.94.155.52]) by mail1.ntp.org with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asn0K-00097s-3z for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 07:57:05 +0000 Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ED98A6495A for ; Wed, 20 Apr 2016 09:56:53 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id C049A64958 for ; Wed, 20 Apr 2016 09:56:52 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Wed, 20 Apr 2016 09:56:53 +0200 Message-Id: <57175262020000A100020AAD@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Wed, 20 Apr 2016 09:56:50 +0200 From: "Ulrich Windl" To: References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline X-SA-Exim-Connect-IP: 194.94.155.52 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Ulrich.Windl@rz.uni-regensburg.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Antw: Re: I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" >>> Harlan Stenn schrieb am 20.04.2016 um 07:47 in Nachricht : [...] > It's pretty easy to test for a legacy MAC. > > The first 4-bytes will be a key ID, and for all known existing cases, > the digest payload will be a 16 byte MD5 key (20 bytes total), which > should be, by far, the most prevalent case. Other cases include: Somewhat stupid question: You talk as if those data have a unique signature to tell what it is, but don't the key ID and the MD5 key look very much like random data (with no destince pattern)? I'n in support for Brian, and as soid before, I'd appreciate an exact algorithm over all that text. As the past indicated, nobody wants to give a precise algorithm, probably because of non-determinedness. It seems you'll have to make several assumptions that are outside of the data packet. > > MD2 > MD4 > MDC2 > RIPEMD160 > SHA > SHA1 > > or any other hash algoritm the OpenSSL library supports. These can be > 256 or even 512 bit hashes. So other legacy MAC lengths can easily be > 24, 36, or 68 bytes long. There are more possibilities. > > The interesting thing here is the key ID. If the key ID is < 65535, > this will be a symmetric key. If we have that keyid in our tables, we > can validate it. If we do not have that keyid in our tables, if this is > a legacy MAC we *cannot* validate it. If the key ID is > 65535, it must > be an autokey session key and we can validate it if we have a matching > key, and we *cannot* validate it if it's not in our key list. Won't an autokey look very much like random data? > > So we have a variety of ways to handle packets that have extra data in > them, and this boils down to: > > - length checks: if it's an EF and there is extra data, what comes after? > - key ID checks > - there should never be a packet from an old system with more than 1 EF, > and if an old system has 1 EF what comes next must be a legacy MAC How to detect an "old system"? > - current proposals have ways to completely avoid these problems > > Please check out the relevant bits of RFC5905 and RFC5906. > > I'm sure we can better document these things, if that is really > necessary and useful. > > Can people screw things up and make things difficult? Yes. And I'd > like to see valid use-cases for these situations. > > Let's be aware of the difference between "being thorough" and > "overengineering" in this case. Well, you cannot change the past, but for the future is much more preferrable to have one precise specification rather tahn a specification with multiple addendums and clarifications, partially contradicting previous specifications. Regards, Ulrich _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 04:00:57 2016 Return-Path: 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 42B6412E3A3 for ; Wed, 20 Apr 2016 04:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.915 X-Spam-Level: X-Spam-Status: No, score=-7.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 yRLJOT2DmKG2 for ; Wed, 20 Apr 2016 04:00:55 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id DE2C612E1C4 for ; Wed, 20 Apr 2016 04:00:55 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B311F86DB96 for ; Wed, 20 Apr 2016 11:00:55 +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 0061786DB28 for ; Wed, 20 Apr 2016 09:07:59 +0000 (UTC) Received: from mail137c25.carrierzone.com ([64.29.147.207] helo=mail26c25-2586.carrierzone.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aso6u-000AD8-KQ for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 09:07:59 +0000 X-POP-User: hmurray@megapathdsl.net Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail26c25-2586.carrierzone.com (8.14.9/8.13.1) with ESMTP id u3K97j3Q022743 for ; Wed, 20 Apr 2016 09:07:46 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 38B87406057; Wed, 20 Apr 2016 02:07:45 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Miroslav Lichvar From: Hal Murray In-Reply-To: Message from Miroslav Lichvar of "Wed, 20 Apr 2016 08:35:29 +0200." <20160420063529.GL17272@localhost> Mime-Version: 1.0 Date: Wed, 20 Apr 2016 02:07:45 -0700 Message-Id: <20160420090745.38B87406057@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.1 cv=duLiVTQ4 c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kziv93cY1bsA:10 a=20KFwNOVAAAA:8 a=2V-3Hk6MWFVPKb7HQi4A:9 a=AatYsGArHqex12FH:21 a=SzLecojP-uL_K0J9:21 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A010205.571746E3.004A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-SA-Exim-Connect-IP: 64.29.147.207 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org, hmurray@megapathdsl.net 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" mlichvar@redhat.com said: > else if remaining length in (4, 20, 24): > parse legacy MAC > return success What is a 4 byte MAC? I'm missing a key idea. Why are legacy MACs allowed after new extension fields? I'd expect them to have their own extension type. That would clean up the extension parsing. Does moving the test for the length of legacy MACs inside the loop simplifiy something? I think it makes it harder to ever un-grandfather legacy MACs. -- These are my opinions. I hate spam. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 04:02:21 2016 Return-Path: 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 5CD8112E40B for ; Wed, 20 Apr 2016 04:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.915 X-Spam-Level: X-Spam-Status: No, score=-7.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hdp6_tAQiBZT for ; Wed, 20 Apr 2016 04:02:19 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id DA9D612E3F0 for ; Wed, 20 Apr 2016 04:02:19 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B59C286DC7A for ; Wed, 20 Apr 2016 11:02:19 +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 C4FF886DB28 for ; Wed, 20 Apr 2016 09:26:11 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asoOY-000AO6-By for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 09:26:11 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0734885365; Wed, 20 Apr 2016 09:26:02 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3K9Q0Uw029363; Wed, 20 Apr 2016 05:26:01 -0400 Date: Wed, 20 Apr 2016 11:26:00 +0200 From: Miroslav Lichvar To: Hal Murray Message-ID: <20160420092600.GO17272@localhost> References: <20160420063529.GL17272@localhost> <20160420090745.38B87406057@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160420090745.38B87406057@ip-64-139-1-69.sjc.megapath.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Wed, Apr 20, 2016 at 02:07:45AM -0700, Hal Murray wrote: > > mlichvar@redhat.com said: > > else if remaining length in (4, 20, 24): > > parse legacy MAC > > return success > > What is a 4 byte MAC? It's a crypto-NAK, the key ID is zero and there is no digest. It's used in server reply when the client's MAC is invalid to let it know the authentication is bad. > I'm missing a key idea. Why are legacy MACs allowed after new extension > fields? I'd expect them to have their own extension type. That would clean > up the extension parsing. There is a new extension field proposed for MACs. Should it be a requirement for clients that support new extension fields? The server will still need to be able to parse packets from old clients. > Does moving the test for the length of legacy MACs inside the loop simplifiy > something? I think it makes it harder to ever un-grandfather legacy MACs. Legacy MACs are allowed in packets with extension fields. Until all extension fields are parsed, we don't know where the MAC starts, so I'm not sure how would that work. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 07:03:42 2016 Return-Path: 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 392F712D5D7 for ; Wed, 20 Apr 2016 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.893 X-Spam-Level: X-Spam-Status: No, score=-7.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 VMXXIM9Hg_dU for ; Wed, 20 Apr 2016 07:03:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0FE12B02F for ; Wed, 20 Apr 2016 07:03:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D7F2986DBAF for ; Wed, 20 Apr 2016 14:03:39 +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 4581386DB3E for ; Wed, 20 Apr 2016 12:01:55 +0000 (UTC) Received: from userp1040.oracle.com ([156.151.31.81]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asqpE-000HYi-56 for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 12:01:55 +0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3KC1hSD024606 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Apr 2016 12:01:43 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3KC1gEK011473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Apr 2016 12:01:43 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u3KC1dnr000955; Wed, 20 Apr 2016 12:01:41 GMT Received: from [10.154.111.70] (/10.154.111.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Apr 2016 05:01:39 -0700 To: Miroslav Lichvar References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> <20160420063529.GL17272@localhost> From: brian utterback Organization: Oracle Corporation Message-ID: <57176F9C.9060203@oracle.com> Date: Wed, 20 Apr 2016 08:01:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20160420063529.GL17272@localhost> X-Source-IP: userv0021.oracle.com [156.151.31.71] X-SA-Exim-Connect-IP: 156.151.31.81 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: brian.utterback@oracle.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org Content-Type: multipart/mixed; boundary="===============6041219241224918914==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" This is a multi-part message in MIME format. --===============6041219241224918914== Content-Type: multipart/alternative; boundary="------------090904080309040007090208" This is a multi-part message in MIME format. --------------090904080309040007090208 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 4/20/2016 2:35 AM, Miroslav Lichvar wrote: > I think the algorithm needed for parsing extension fields and MACs in > NTP packets is supposed to be simple after this RFC. If special MACs > are not negotiated as described in 7.5.1.3, the parsing should be: > > 1. parse header of NTP packet (48 octets) > 2. if remaining length == 0: > return success > else if remaining length >= 28: > parse an extension field, if not valid return error > move pointer by the length of the extension field > else if remaining length in (4, 20, 24): > parse legacy MAC > return success > else: > return error That is not consistent with what is in the extensions draft. It may be consistent with what was intended but it isn't with what it currently says. As it stands, the only requirement that the last extension field be >= 28 octets is if there is no MAC and at the time we are looking at the length to see if it is >- 28 octets we do not know that yet. This means that if it is less than 28 octets it might be two small extension fields and not a MAC. I think that Harlan's "last" extension might fix the problem, but it should not be a separate extension. It needs to be added to 7822 to update 5905. That is, for it to be useful it must be mandatory. -- Oracle Brian Utterback | Principal Software Engineer Phone: +1 6038973049 Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 ------------------------------------------------------------------------ All working systems eventually start to exhibit their own agenda ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment --------------090904080309040007090208 Content-Type: multipart/related; boundary="------------080705060608040408070000" --------------080705060608040408070000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On 4/20/2016 2:35 AM, Miroslav Lichvar wrote:
I think the algorithm needed for parsing extension fields and MACs in
NTP packets is supposed to be simple after this RFC. If special MACs
are not negotiated as described in 7.5.1.3, the parsing should be:

1. parse header of NTP packet (48 octets)
2. if remaining length == 0:
     return success
   else if remaining length >= 28:
     parse an extension field, if not valid return error
     move pointer by the length of the extension field
   else if remaining length in (4, 20, 24):
     parse legacy MAC
     return success
   else:
     return error

That is not consistent with what is in the extensions draft. It may be consistent with what was intended but it isn't with what it currently says. As it stands, the only requirement that the last extension field be >= 28 octets is if there is no MAC and at the time we are looking at the length to see if it is >- 28 octets we do not know that yet. This means that if it is less than 28 octets it might be two small extension fields and not a MAC.

I think that Harlan's "last" extension might fix the problem, but it should not be a separate extension. It needs to be added to 7822 to update 5905. That is, for it to be useful it must be mandatory.
--
Oracle
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
All working systems eventually start to exhibit their own agenda
Green Oracle Oracle is committed to developing practices and products that help protect the environment
--------------080705060608040408070000 Content-Type: image/gif; name="oracle_sig_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oracle_sig_logo.gif" R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9A QP/AwP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPV IDfcOQa6A8yRaO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1n BGRmhl8AWiUJYicCAIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4 AAunsqg/dw95KwdfBgzBqKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1It xK7aKl8lCl8DAfALW1+2rUi3QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyI qRgMcA8a/z5AZQWXOxEdHxwUgfIgsX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjU mYLnomokcDlS4s0eFzQNqvXDEyzmAwFPyaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpF RxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt 1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvPm8OVEkAIYLYPThSsRIpEQJr1x94QBIT0 9FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8ABijggAQWaOCBCCao4A+CDDbo4IMQ RijhhBQKGAIAOw== --------------080705060608040408070000 Content-Type: image/gif; name="green-for-email-sig_0.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="green-for-email-sig_0.gif" R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zP uZu2lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxj SYdrOp/Q6NPgYqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMq DwFCAAIFPIYDgidrOUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQG BH82TpMicD0pAgQACToDAchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLD LS8MAvf497ruCZ+gOA0gfNt3AIK0J/JWKVzIsEQIADs= --------------080705060608040408070000-- --------------090904080309040007090208-- --===============6041219241224918914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============6041219241224918914==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 08:01:27 2016 Return-Path: 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 5358812DE1C for ; Wed, 20 Apr 2016 08:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 T5uaD4uObbkp for ; Wed, 20 Apr 2016 08:01:25 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id F241812B006 for ; Wed, 20 Apr 2016 08:01:24 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id ED19C86DC5D for ; Wed, 20 Apr 2016 15:01:24 +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 60A4686D756 for ; Wed, 20 Apr 2016 13:24:46 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ass7C-000Ihe-Bg for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 13:24:43 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AE0F37F342; Wed, 20 Apr 2016 13:24:20 +0000 (UTC) Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3KDOJjE015627; Wed, 20 Apr 2016 09:24:20 -0400 Date: Wed, 20 Apr 2016 15:24:19 +0200 From: Miroslav Lichvar To: brian utterback Message-ID: <20160420132419.GP17272@localhost> References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> <20160420063529.GL17272@localhost> <57176F9C.9060203@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <57176F9C.9060203@oracle.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" On Wed, Apr 20, 2016 at 08:01:32AM -0400, brian utterback wrote: > On 4/20/2016 2:35 AM, Miroslav Lichvar wrote: > > 1. parse header of NTP packet (48 octets) > > 2. if remaining length == 0: > > return success > > else if remaining length >= 28: > > parse an extension field, if not valid return error > > move pointer by the length of the extension field > > else if remaining length in (4, 20, 24): > > parse legacy MAC > > return success > > else: > > return error > > That is not consistent with what is in the extensions draft. It may be > consistent with what was intended but it isn't with what it currently > says. As it stands, the only requirement that the last extension field > be >= 28 octets is if there is no MAC and at the time we are looking at > the length to see if it is >- 28 octets we do not know that yet. Hm, I see. > This > means that if it is less than 28 octets it might be two small extension > fields and not a MAC. If extension fields are required to be at least 16 octets, two wouldn't fit in 28 octets. An extension field and crypto-NAK would fit there, however. If crypto-NAK wasn't allowed in packets with extension fields (is it?), this would still work, or not? 4 octets is crypto-NAK 20 octets is MD5 MAC 24 octets is SHA1 MAC 28 octets is 1 EF 32 octets is 1 EF 36 octets is 1 EF or 1 EF + MD5 MAC 40 octets is 1 EF or 1 EF + MD5/SHA1 MAC 44 octets is 1 EF or 1 EF + MD5/SHA1 MAC or 2 EF (16 + 28 octets) ... The only change in the algorithm above would be a special case for 4 remaining octets with crypto-NAK. > I think that Harlan's "last" extension might fix the problem, but it > should not be a separate extension. It needs to be added to 7822 to > update 5905. That is, for it to be useful it must be mandatory. The problem with the "last" extension is that it will need to be at least 16 octets if old implementations should be able to parse and reply to packets that have it, which I think would be a waste of bandwidth. If we were considering breaking compatibility, I'd rather see a cleaner approach. Maybe allow legacy MACs only in packets that don't have any extension fields. If length < 28, it's a MAC, otherwise there are only extension fields. Autokey could be enabled for old clients with a special option if necessary. -- Miroslav Lichvar _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 09:05:37 2016 Return-Path: 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 AB54812D8B2 for ; Wed, 20 Apr 2016 09:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.785 X-Spam-Level: X-Spam-Status: No, score=-7.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=isoc.onmicrosoft.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 1R5-OYWwrVcw for ; Wed, 20 Apr 2016 09:05:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 6203F12D7FC for ; Wed, 20 Apr 2016 09:05:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 5BAB086DBF7 for ; Wed, 20 Apr 2016 16:05:36 +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 A623886D756 for ; Wed, 20 Apr 2016 15:00:01 +0000 (UTC) Received: from mail-bl2on0058.outbound.protection.outlook.com ([65.55.169.58] helo=na01-bl2-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1astbc-000KGB-SC for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 15:00:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KxuQMUFWZZKgVmE975axvGxpPIvPYkbhAc0OBYmMp48=; b=oiK6xX58EuttfRi7UjV5O+KgsaZ8tsFHWOILd2qaYCMjwKkYGmotRFPyMsvoVFTiTRyiJVun7659Tw7N4Ikx409b7zSl7M/tlwQU5RDRuM4L0vANQB8bkYzkvGUvhOVD0MSa874w/isiL+bMd2KcUhugFKSmF1J9jIeSsbiYS4E= Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) by DM2PR0601MB1119.namprd06.prod.outlook.com (10.160.218.14) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 20 Apr 2016 14:59:49 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 14:59:49 +0000 From: Karen O'Donoghue To: "tictoc@ietf.org" Thread-Topic: WGLC on draft-ietf-tictoc-ptp-enterprise-profile-06 Thread-Index: AQHRmxVIxH0uTbr/rUq9StTgt++Pgw== Date: Wed, 20 Apr 2016 14:59:49 +0000 Message-ID: <15556A59-F26E-41DE-BF9E-BF6344F534A6@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [46.218.58.213] x-ms-office365-filtering-correlation-id: 4df93c18-46c3-4add-bd4b-08d3692c6bba x-microsoft-exchange-diagnostics: 1; DM2PR0601MB1119; 5:ZNfO8CtCNNrQWvDcL5f1bZdu8ddAFqwbn2kMvXAmbBB4L1Rw8XTRZGDK+c3h3Zb4fP2+nc+8ouX1SYfZ4wmu4BhvJc/KZGDvja6GxK1pb5REPEfggJIZ977vHlDuVMXayASTeyh/v2YSwqwNqvKsug==; 24:gMv2DkRt0eR797Wc4xrFayljvDra14ZqLl4591LE9tgdvuzKVu9m7+2yUyAAzBOUszcxjg2K+ihJGj8OHSVYrk2ZM4c8v+NLny/ITNkE7+4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB1119; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR0601MB1119; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1119; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(5640700001)(99286002)(10400500002)(229853001)(2900100001)(106116001)(2351001)(15975445007)(110136002)(77096005)(122556002)(189998001)(36756003)(230783001)(66066001)(5002640100001)(3660700001)(3280700002)(81166005)(5004730100002)(11100500001)(2906002)(5008740100001)(82746002)(2501003)(1096002)(3846002)(87936001)(19580395003)(54356999)(33656002)(4326007)(50986999)(83716003)(102836003)(1220700001)(86362001)(6116002)(92566002)(586003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB1119; H:DM2PR0601MB1118.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <25BE3A9857A4E847976138D39F970BFF@namprd06.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 14:59:49.1874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB1119 X-SA-Exim-Connect-IP: 65.55.169.58 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] WGLC on draft-ietf-tictoc-ptp-enterprise-profile-06 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntpwg@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" Folks, This message begins a 2 week WGLC on the following document: Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile-06 Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed. Please send all comments in by Wednesday 4 May 2016. Thank you! Karen _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 10:05:09 2016 Return-Path: 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 F16ED12DB61 for ; Wed, 20 Apr 2016 10:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.785 X-Spam-Level: X-Spam-Status: No, score=-7.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=isoc.onmicrosoft.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 lm0MUK4Qy4ye for ; Wed, 20 Apr 2016 10:05:03 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7A512DB1B for ; Wed, 20 Apr 2016 10:05:03 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 1409A86DBBD for ; Wed, 20 Apr 2016 17:05:02 +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 E8CE586DAA5 for ; Wed, 20 Apr 2016 15:12:16 +0000 (UTC) Received: from mail-bl2on0072.outbound.protection.outlook.com ([65.55.169.72] helo=na01-bl2-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1astnU-000KbM-3j for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 15:12:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pk8tJ541eDME2R51JJbmASG+HtKiLIQZiPslVd5sLjQ=; b=WI39Jdb5n7cSrxMhc9cHoKXQC6lDNUIxTThs99GLzYq789Z5IjVBt6Oo/Vp80Ii29sXpFiJZsAQPHzSZdJ6g0OpQauYlEes0+1jiau051bovhLiPmj0FbSwe3bYcsuxQPgzxU9QQCWr9aodaD51oRfWklwxf3PUP3a6mtrZKTJ8= Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) by DM2PR0601MB1119.namprd06.prod.outlook.com (10.160.218.14) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 20 Apr 2016 15:12:06 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 15:12:06 +0000 From: Karen O'Donoghue To: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Thread-Topic: Joint NTP/TICTOC working group virtual interim meeting - 5 May 2016 @ 1530 UTC Thread-Index: AQHRmxcAz9ELFD9DGkydX0PB4WDJAA== Date: Wed, 20 Apr 2016 15:12:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.ntp.org; dkim=none (message not signed) header.d=none; lists.ntp.org; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [46.218.58.213] x-ms-office365-filtering-correlation-id: 190979c5-d958-49f1-7e81-08d3692e22ce x-microsoft-exchange-diagnostics: 1; DM2PR0601MB1119; 5:YH7QkmZ6HKLb8t414SUlC22S8jdAesNhlvL+FyWo4EP+1O0V4MjGISvvZOiIHHGlExo3cQ8UKhO1TfKTuj7NN7NAVTDGZaYf7NyXWk01es3CcjM5c8J9LSqeKHDw5wvmYZPhBZlIIaqqpH27yO4E4g==; 24:YQbaKlLrqqFVUulxS44NMRHmg7c/gd1dNw8TomoKIFV1ioZUdGJfrEZhcKoIECKG1zzUfBxYyJrXFQWfY3+WZ3qdOh+8oMuQArjAPQ6AYhs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB1119; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR0601MB1119; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1119; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(54356999)(19580395003)(16799955002)(50986999)(33656002)(4326007)(82746002)(2501003)(5008740100001)(3846002)(1096002)(87936001)(92566002)(586003)(1220700001)(83716003)(6116002)(86362001)(102836003)(77096005)(122556002)(66066001)(36756003)(189998001)(99286002)(10400500002)(2900100001)(229853001)(106116001)(15975445007)(11100500001)(2906002)(5004730100002)(5001770100001)(3280700002)(3660700001)(5002640100001)(551544002)(81166005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB1119; H:DM2PR0601MB1118.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 15:12:06.0867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB1119 X-SA-Exim-Connect-IP: 65.55.169.72 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Joint NTP/TICTOC working group virtual interim meeting - 5 May 2016 @ 1530 UTC X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "iesg-secretary@ietf.org" , Suresh Krishnan 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" There will be a joint meeting of the NTP and TICTOC working groups on Thursday 5 May 2016 @ 11:30 am EDT (15:30 UTC) The agenda of this meeting will include: - NTP WG Status - Preliminary report from NTS WGLC design team - NTS implementation updates - NTP BCP - Next steps for extension field and REFID drafts - TICTOC WG Status - PTP Profile WGLC Comments - AOB & Next meeting planning NTP/TICTOC joint virtual interim meeting Thursday, May 5, 2016 11:30 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr 30 mins https://isoc.webex.com/isoc/j.php?MTID=mcde7866f39032e6d059b3dcba4c0456e Meeting number: 921 731 640 Meeting password: timesynch Join by phone 1-877-668-4493 Call-in toll-free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 921 731 640 Global call-in numbers https://isoc.webex.com/isoc/globalcallin.php?serviceType=MC&ED=438264717&tollFree=1 Toll-free calling restrictions https://www.webex.com/pdf/tollfree_restrictions.pdf Add to your calendar https://isoc.webex.com/isoc/j.php?MTID=me2102d9d25ca6882983e05d80aa5a861 _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 11:06:05 2016 Return-Path: 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 E5DC712E3EE for ; Wed, 20 Apr 2016 11:06:05 -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 O38HR3MpQS9I for ; Wed, 20 Apr 2016 11:06:04 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C85F012E21E for ; Wed, 20 Apr 2016 11:06:04 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id AAA7286DC43 for ; Wed, 20 Apr 2016 18:06:04 +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 4100C86DAEB for ; Wed, 20 Apr 2016 16:20:37 +0000 (UTC) Received: from [198.22.153.130] (helo=[10.2.184.138]) by mail1.ntp.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asuri-000LsQ-LK; Wed, 20 Apr 2016 16:20:36 +0000 References: <20160420063529.GL17272@localhost> <20160420090745.38B87406057@ip-64-139-1-69.sjc.megapath.net> <20160420092600.GO17272@localhost> To: Miroslav Lichvar , Hal Murray From: Danny Mayer Organization: NTP Message-ID: <5717AC65.4000506@ntp.org> Date: Wed, 20 Apr 2016 12:20:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160420092600.GO17272@localhost> X-SA-Exim-Connect-IP: 198.22.153.130 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org, hmurray@megapathdsl.net, mlichvar@redhat.com X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mayer@ntp.org Cc: ntpwg@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" On 4/20/2016 5:26 AM, Miroslav Lichvar wrote: > On Wed, Apr 20, 2016 at 02:07:45AM -0700, Hal Murray wrote: >> >> mlichvar@redhat.com said: >>> else if remaining length in (4, 20, 24): >>> parse legacy MAC >>> return success >> >> What is a 4 byte MAC? > > It's a crypto-NAK, the key ID is zero and there is no digest. It's > used in server reply when the client's MAC is invalid to let it know > the authentication is bad. > Yes. >> I'm missing a key idea. Why are legacy MACs allowed after new extension >> fields? I'd expect them to have their own extension type. That would clean >> up the extension parsing. > > There is a new extension field proposed for MACs. Should it be a > requirement for clients that support new extension fields? If a new extension field requires a MAC it needs to use the MAC extension field rather than the legacy one. The server > will still need to be able to parse packets from old clients. > Yes. The new extension field does not need to require a legacy MAC as long as other requirements don't require it (symmetric key is a case that requires a legacy MAC). >> Does moving the test for the length of legacy MACs inside the loop simplifiy >> something? I think it makes it harder to ever un-grandfather legacy MACs. > > Legacy MACs are allowed in packets with extension fields. Until all > extension fields are parsed, we don't know where the MAC starts, so > I'm not sure how would that work. > I have some ideas about how to do this, but it cannot be guaranteed to not get the wrong results. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 14:54:58 2016 Return-Path: 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 007AB12D508 for ; Wed, 20 Apr 2016 14:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.895 X-Spam-Level: X-Spam-Status: No, score=-107.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, USER_IN_WHITELIST=-100] 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 rz_hEalB2aXS for ; Wed, 20 Apr 2016 14:54:56 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA0112B061 for ; Wed, 20 Apr 2016 14:54:56 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 5EAE386DBF1 for ; Wed, 20 Apr 2016 21:54:56 +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 1803C86DABD for ; Wed, 20 Apr 2016 20:36:04 +0000 (UTC) Received: from mail.ietf.org ([4.31.198.44]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1asyqq-000Paj-76 for ntpwg@lists.ntp.org; Wed, 20 Apr 2016 20:36:04 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B018712E8DF; Wed, 20 Apr 2016 13:35:55 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420203555.907.61462.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 13:35:55 -0700 X-SA-Exim-Connect-IP: 4.31.198.44 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: iesg-secretary@ietf.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Joint NTP/TICTOC working group virtual interim meeting - 5 May 2016 @ 1530 UTC X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ietf@ietf.org Cc: ntpwg@lists.ntp.org, tictoc@ietf.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" There will be a joint meeting of the Network Time Protocol (ntp) and Timing over IP Connection and Transfer of Clock (tictoc) working groups on Thursday 5 May 2016 @ 11:30 am EDT (15:30 UTC) The agenda of this meeting will include: - NTP WG Status - Preliminary report from NTS WGLC design team - NTS implementation updates - NTP BCP - Next steps for extension field and REFID drafts - TICTOC WG Status - PTP Profile WGLC Comments - AOB & Next meeting planning NTP/TICTOC joint virtual interim meeting Thursday, May 5, 2016 11:30 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr 30 mins https://isoc.webex.com/isoc/j.php?MTID=mcde7866f39032e6d059b3dcba4c0456e Meeting number: 921 731 640 Meeting password: timesynch Join by phone 1-877-668-4493 Call-in toll-free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 921 731 640 Global call-in numbers https://isoc.webex.com/isoc/globalcallin.php?serviceType=MC&ED=438264717&tollFree=1 Toll-free calling restrictions https://www.webex.com/pdf/tollfree_restrictions.pdf Add to your calendar https://isoc.webex.com/isoc/j.php?MTID=me2102d9d25ca6882983e05d80aa5a861 _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 15:53:45 2016 Return-Path: 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 0BC9812E51E for ; Wed, 20 Apr 2016 15:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 i0hP7y9trhr4 for ; Wed, 20 Apr 2016 15:53:43 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3A212E424 for ; Wed, 20 Apr 2016 15:53:43 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 2378586DBDD for ; Wed, 20 Apr 2016 22:53:43 +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 4D83686DABD for ; Wed, 20 Apr 2016 21:27:24 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1aszeb-000O5k-QT; Wed, 20 Apr 2016 21:27:21 +0000 From: Harlan Stenn To: Miroslav Lichvar In-reply-to: <20160420063529.GL17272@localhost> References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> <20160420063529.GL17272@localhost> Comments: In-reply-to Miroslav Lichvar message dated "Wed, 20 Apr 2016 08:35:29 +0200." 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: Wed, 20 Apr 2016 21:27:21 +0000 Message-Id: Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" Miroslav, You have eloquently described the problems I have with this document. It claims to decree that things that were not required before are now required, these things are not sufficient to fully address the problem, and we need to do better. H Miroslav Lichvar writes: > On Tue, Apr 19, 2016 at 09:48:34PM -0400, brian utterback wrote: > > I have been trying to figure out the procedure for figuring out if there > > is an extension field and/or a legacy MAC and where they are. This seems > > to be covered in section 7.5.1. I am looking at this in terms of an > > implementer. I feel that there is some length restriction left out of > > the document because there seems to be cases as is that are ambiguous. > > I think the algorithm needed for parsing extension fields and MACs in > NTP packets is supposed to be simple after this RFC. If special MACs > are not negotiated as described in 7.5.1.3, the parsing should be: > > 1. parse header of NTP packet (48 octets) > 2. if remaining length == 0: > return success > else if remaining length >= 28: > parse an extension field, if not valid return error > move pointer by the length of the extension field > else if remaining length in (4, 20, 24): > parse legacy MAC > return success > else: > return error > 3. go to 2 > > > We know from 7.5.1.4 that if there is no MAC then the last extension in > > the packet must be 28 octets or greater but an extension might be that > > long and not be the last one. Also, there is no limit on how small an > > extension might be if it is not the last. > > 7.5 mentions the minimum length is 16 octets, this didn't change with > the new RFC. Are you saying it should be specified with a MUST? > > > And there is no maximum or > > minimum size of the legacy MAC if it is with an extension field. > > As the second paragraph in 1. says, legacy MACs are 4, 20 or 24 octets > long. This corresponds to NAK, MD5 and SHA1 MACs and should apply to > packets with and without extension fields. > > > So, > > after getting past the first extension field, unless it's length got me > > to the end of the packet I can't say if what I am pointing to is an > > extension or a MAC and I don't see a way to determine it. > > If the remaining length is >= 28, it should be an extension field. > > > The same thing > > happens if the residual data after the regular NTP packet is less than > > 24 octets. It might be a MAC, or it might be a short extension field > > followed by a short MAC. > > It's a MAC, because last extension field is required to be at least 28 > octets. > > -- > Miroslav Lichvar > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 16:53:01 2016 Return-Path: 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 627EF12DFCE for ; Wed, 20 Apr 2016 16:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ut0JKVBoqZL5 for ; Wed, 20 Apr 2016 16:52:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id CDB1A12E991 for ; Wed, 20 Apr 2016 16:52:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id AAA7586DB9E for ; Wed, 20 Apr 2016 23:52:59 +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 C462686DAA5 for ; Wed, 20 Apr 2016 22:01:12 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1at0BM-000O7u-60; Wed, 20 Apr 2016 22:01:12 +0000 From: Harlan Stenn To: "Ulrich Windl" In-reply-to: <57175262020000A100020AAD@gwsmtp1.uni-regensburg.de> References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> <57175262020000A100020AAD@gwsmtp1.uni-regensburg.de> Comments: In-reply-to "Ulrich Windl" message dated "Wed, 20 Apr 2016 09:56:50 +0200." 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: Wed, 20 Apr 2016 22:01:12 +0000 Message-Id: Subject: Re: [ntpwg] Antw: Re: I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" "Ulrich Windl" writes: > >>> Harlan Stenn schrieb am 20.04.2016 um 07:47 in Nachricht > : > > [...] > > > It's pretty easy to test for a legacy MAC. > > > > The first 4-bytes will be a key ID, and for all known existing cases, > > the digest payload will be a 16 byte MD5 key (20 bytes total), which > > should be, by far, the most prevalent case. Other cases include: > > Somewhat stupid question: You talk as if those data have a unique signature t > o tell what it is, but don't the key ID and the MD5 key look very much like r > andom data (with no destince pattern)? They do have a unique structure. How did I not clearly describe this? We can sanity check EFs based on Field Type and Field Length. We can sanity check legacy MACs because the first 4 bytes are a key ID and we have knowledge there. We're not operating in a vacuum here. > I'n in support for Brian, and as soid before, I'd appreciate an exact algorit > hm over all that text. As the past indicated, nobody wants to give a precise > algorithm, probably because of non-determinedness. It seems you'll have to ma > ke several assumptions that are outside of the data packet. Absolutely, and this is to be expected. Why do we need to describe this in detail? We don't describe lots of other things in that level of detail. Also, with the proposed new EFs, all of this "goes away". Why do we want to make it easy for people to run deprecated and outdated stuff? > > > > MD2 > > MD4 > > MDC2 > > RIPEMD160 > > SHA > > SHA1 > > > > or any other hash algoritm the OpenSSL library supports. These can be > > 256 or even 512 bit hashes. So other legacy MAC lengths can easily be > > 24, 36, or 68 bytes long. There are more possibilities. > > > > The interesting thing here is the key ID. If the key ID is < 65535, > > this will be a symmetric key. If we have that keyid in our tables, we > > can validate it. If we do not have that keyid in our tables, if this is > > a legacy MAC we *cannot* validate it. If the key ID is > 65535, it must > > be an autokey session key and we can validate it if we have a matching > > key, and we *cannot* validate it if it's not in our key list. > > Won't an autokey look very much like random data? Autokey looks like an EF. It has to be explicitly configured on each side, so it's *expected*. If you don't support autokey and somebody sends you an autokey packet, it's just like getting any other EF you don't recognize, except for many years the *only* EF we listed was an autokey EF. I don't see what you're concerned about. > > So we have a variety of ways to handle packets that have extra data in > > them, and this boils down to: > > > > - length checks: if it's an EF and there is extra data, what comes after? > > - key ID checks > > - there should never be a packet from an old system with more than 1 EF, > > and if an old system has 1 EF what comes next must be a legacy MAC > > How to detect an "old system"? What do you mean by "detect"? Please describe the exact situation, as that's important in this case. > > - current proposals have ways to completely avoid these problems > > > > Please check out the relevant bits of RFC5905 and RFC5906. > > > > I'm sure we can better document these things, if that is really > > necessary and useful. > > > > Can people screw things up and make things difficult? Yes. And I'd > > like to see valid use-cases for these situations. > > > > Let's be aware of the difference between "being thorough" and > > "overengineering" in this case. > > Well, you cannot change the past, but for the future is much more preferrable > to have one precise specification rather tahn a specification with multiple > addendums and clarifications, partially contradicting previous specifications > . Yes, and the proposed new EF proposals handle this, especially after we address the problems caused by the just-installed new EF proposal. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Apr 20 21:55:10 2016 Return-Path: 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 A509912DAC1 for ; Wed, 20 Apr 2016 21:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pZV2Eycb-eXO for ; Wed, 20 Apr 2016 21:55:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF812D0BB for ; Wed, 20 Apr 2016 21:55:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C3F0386DB56 for ; Thu, 21 Apr 2016 04:55:08 +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 B4A8686D4A6 for ; Thu, 21 Apr 2016 03:10:08 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1at4xi-000OUD-AW; Thu, 21 Apr 2016 03:07:26 +0000 From: Harlan Stenn To: mayer@ntp.org In-reply-to: <5717AC65.4000506@ntp.org> References: <20160420063529.GL17272@localhost> <20160420090745.38B87406057@ip-64-139-1-69.sjc.megapath.net> <20160420092600.GO17272@localhost> <5717AC65.4000506@ntp.org> Comments: In-reply-to Danny Mayer message dated "Wed, 20 Apr 2016 12:20:53 -0400." 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, 21 Apr 2016 03:07:26 +0000 Message-Id: Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org, Hal Murray 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" Danny Mayer writes: > On 4/20/2016 5:26 AM, Miroslav Lichvar wrote: >> On Wed, Apr 20, 2016 at 02:07:45AM -0700, Hal Murray wrote: >>> >>> mlichvar@redhat.com said: >>>> else if remaining length in (4, 20, 24): >>>> parse legacy MAC >>>> return success >>> >>> What is a 4 byte MAC? >> >> It's a crypto-NAK, the key ID is zero and there is no digest. It's >> used in server reply when the client's MAC is invalid to let it know >> the authentication is bad. > > Yes. > >>> I'm missing a key idea. Why are legacy MACs allowed after new >>> extension fields? I'd expect them to have their own extension type. >>> That would clean up the extension parsing. >> >> There is a new extension field proposed for MACs. Should it be a >> requirement for clients that support new extension fields? > > If a new extension field requires a MAC it needs to use the MAC > extension field rather than the legacy one. No it doesn't. The rules were very clear until this document was accepted. The MAC-EF is arguably a *better* solution, but it's really no big deal either way. >> The server will still need to be able to parse packets from old >> clients. > > Yes. The new extension field does not need to require a legacy MAC as > long as other requirements don't require it (symmetric key is a case > that requires a legacy MAC). symmetric key should not require a legacy MAC. It should require "a MAC". >>> Does moving the test for the length of legacy MACs inside the loop >>> simplifiy something? I think it makes it harder to ever >>> un-grandfather legacy MACs. >> >> Legacy MACs are allowed in packets with extension fields. Until all >> extension fields are parsed, we don't know where the MAC starts, so >> I'm not sure how would that work. > > I have some ideas about how to do this, but it cannot be guaranteed to > not get the wrong results. This is an implementation issue, and from everything I have seen it's easily solvable. >From my POV, the Standard should talk about "mechanism", and the implementation is "policy". We should be VERY careful about where we specify policy in the Standard. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 21 01:42:03 2016 Return-Path: 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 1822A12E29D for ; Thu, 21 Apr 2016 01:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 DTJhFV8evUUX for ; Thu, 21 Apr 2016 01:41:52 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id B4BA912E264 for ; Thu, 21 Apr 2016 01:41:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7F07386DBE1 for ; Thu, 21 Apr 2016 08:41:41 +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 035E686D55E for ; Thu, 21 Apr 2016 07:10:19 +0000 (UTC) Received: from rrzmta1.uni-regensburg.de ([194.94.155.51]) by mail1.ntp.org with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1at8kX-00091N-4u for ntpwg@lists.ntp.org; Thu, 21 Apr 2016 07:10:18 +0000 Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3D6B057A9E for ; Thu, 21 Apr 2016 09:10:03 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id E781357AB5 for ; Thu, 21 Apr 2016 09:10:02 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Thu, 21 Apr 2016 09:10:03 +0200 Message-Id: <571898E9020000A100020AF8@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Thu, 21 Apr 2016 09:10:01 +0200 From: "Ulrich Windl" To: "Harlan Stenn" References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> <57175262020000A100020AAD@gwsmtp1.uni-regensburg.de> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline X-SA-Exim-Connect-IP: 194.94.155.51 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Ulrich.Windl@rz.uni-regensburg.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Antw: Re: Antw: Re: I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" >>> Harlan Stenn schrieb am 21.04.2016 um 00:01 in Nachricht : > "Ulrich Windl" writes: >> >>> Harlan Stenn schrieb am 20.04.2016 um 07:47 in Nachricht >> : >> >> [...] >> >> > It's pretty easy to test for a legacy MAC. >> > >> > The first 4-bytes will be a key ID, and for all known existing cases, >> > the digest payload will be a 16 byte MD5 key (20 bytes total), which >> > should be, by far, the most prevalent case. Other cases include: >> >> Somewhat stupid question: You talk as if those data have a unique signature > t >> o tell what it is, but don't the key ID and the MD5 key look very much like > r >> andom data (with no destince pattern)? > > They do have a unique structure. > > How did I not clearly describe this? > > We can sanity check EFs based on Field Type and Field Length. > > We can sanity check legacy MACs because the first 4 bytes are a key ID > and we have knowledge there. > > We're not operating in a vacuum here. > >> I'n in support for Brian, and as soid before, I'd appreciate an exact > algorit >> hm over all that text. As the past indicated, nobody wants to give a precise Harlan, it seems your mailer wraps quotes lines not obeying word boundaries; that looks a bit strange. > >> algorithm, probably because of non-determinedness. It seems you'll have to ma >> ke several assumptions that are outside of the data packet. > > Absolutely, and this is to be expected. > > Why do we need to describe this in detail? We don't describe lots of > other things in that level of detail. Well, why not have a se of sample packets (binary images) as well as a reference interpretation of those. That way automatic tests could be used for any algorithm that tries to interpret those packets. > > Also, with the proposed new EFs, all of this "goes away". Why do we > want to make it easy for people to run deprecated and outdated stuff? Do we want people driving cars using fossile fuel? ;-) > >> > >> > MD2 >> > MD4 >> > MDC2 >> > RIPEMD160 >> > SHA >> > SHA1 >> > >> > or any other hash algoritm the OpenSSL library supports. These can be >> > 256 or even 512 bit hashes. So other legacy MAC lengths can easily be >> > 24, 36, or 68 bytes long. There are more possibilities. >> > >> > The interesting thing here is the key ID. If the key ID is < 65535, >> > this will be a symmetric key. If we have that keyid in our tables, we >> > can validate it. If we do not have that keyid in our tables, if this is >> > a legacy MAC we *cannot* validate it. If the key ID is > 65535, it must >> > be an autokey session key and we can validate it if we have a matching >> > key, and we *cannot* validate it if it's not in our key list. >> >> Won't an autokey look very much like random data? > > Autokey looks like an EF. It has to be explicitly configured on each > side, so it's *expected*. > > If you don't support autokey and somebody sends you an autokey packet, > it's just like getting any other EF you don't recognize, except for many > years the *only* EF we listed was an autokey EF. > > I don't see what you're concerned about. > >> > So we have a variety of ways to handle packets that have extra data in >> > them, and this boils down to: >> > >> > - length checks: if it's an EF and there is extra data, what comes after? >> > - key ID checks >> > - there should never be a packet from an old system with more than 1 EF, >> > and if an old system has 1 EF what comes next must be a legacy MAC >> >> How to detect an "old system"? > > What do you mean by "detect"? Please describe the exact situation, as > that's important in this case. If you receive packet you want to process, everything you need to know should be in that packet. Specifically for a connectionless protocol like UDP or a stateless protocol like NTP (in most cases at least). > >> > - current proposals have ways to completely avoid these problems >> > >> > Please check out the relevant bits of RFC5905 and RFC5906. >> > >> > I'm sure we can better document these things, if that is really >> > necessary and useful. >> > >> > Can people screw things up and make things difficult? Yes. And I'd >> > like to see valid use-cases for these situations. >> > >> > Let's be aware of the difference between "being thorough" and >> > "overengineering" in this case. >> >> Well, you cannot change the past, but for the future is much more > preferrable >> to have one precise specification rather tahn a specification with multiple > >> addendums and clarifications, partially contradicting previous > specifications >> . > > Yes, and the proposed new EF proposals handle this, especially after we > address the problems caused by the just-installed new EF proposal. > > H Regards, Ulrich _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Apr 21 02:59:42 2016 Return-Path: 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 B425F12D5D0 for ; Thu, 21 Apr 2016 02:59:42 -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 CGvgtDXGc6rk for ; Thu, 21 Apr 2016 02:59:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 6287B12D17D for ; Thu, 21 Apr 2016 02:59:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 30A3186DBB5 for ; Thu, 21 Apr 2016 09:59:41 +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 2585086DAEB for ; Thu, 21 Apr 2016 08:32:33 +0000 (UTC) Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1at9zs-000OqC-CM; Thu, 21 Apr 2016 08:30:00 +0000 From: Harlan Stenn To: "Ulrich Windl" In-reply-to: <571898E9020000A100020AF8@gwsmtp1.uni-regensburg.de> References: <20160209063913.16201.80653.idtracker@ietfa.amsl.com> <5716DFF2.60805@oracle.com> <57175262020000A100020AAD@gwsmtp1.uni-regensburg.de> <571898E9020000A100020AF8@gwsmtp1.uni-regensburg.de> Comments: In-reply-to "Ulrich Windl" message dated "Thu, 21 Apr 2016 09:10:01 +0200." 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, 21 Apr 2016 08:30:00 +0000 Message-Id: Subject: Re: [ntpwg] Antw: Re: Antw: Re: I-D Action: draft-ietf-ntp-extension-field-07.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" "Ulrich Windl" writes: >>>> Harlan Stenn schrieb >> Why do we need to describe this in detail? We don't describe lots of >> other things in that level of detail. > > Well, why not have a se of sample packets (binary images) as well as a > reference interpretation of those. That way automatic tests could be > used for any algorithm that tries to interpret those packets. Sure. Great idea. But with this sort of data there are still places where choices on what to do are "policy" choices, and tests like these are "mechanism" choices. >> Also, with the proposed new EFs, all of this "goes away". Why do we >> want to make it easy for people to run deprecated and outdated stuff? > > Do we want people driving cars using fossile fuel? ;-) That's policy. We're talking about mechanism. >>>> So we have a variety of ways to handle packets that have extra data >>>> in them, and this boils down to: >>>> >>>> - length checks: if it's an EF and there is extra data, what comes >>>> after? >>>> - key ID checks >>>> - there should never be a packet from an old system with more than >>>> 1 EF, and if an old system has 1 EF what comes next must be a >>>> legacy MAC >>> >>> How to detect an "old system"? >> >> What do you mean by "detect"? Please describe the exact situation, >> as that's important in this case. > > If you receive packet you want to process, everything you need to know > should be in that packet. I don't think so. And we remember lots of other stuff too, like origin timestamps and previous other things, and there is state information we must maintain for autokey. Also symmetric key information is maintained outside of the packet. You should know all of this. > Specifically for a connectionless protocol like > UDP or a stateless protocol like NTP (in most cases at least). See above. We get into a lot of trouble if we do too much or too little, or do things in the "wrong" places. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Apr 25 01:03:42 2016 Return-Path: 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 9FC9F12D514 for ; Mon, 25 Apr 2016 01:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 nB2NPQWJixER for ; Mon, 25 Apr 2016 01:03:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1B012D516 for ; Mon, 25 Apr 2016 01:03:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 46CCD86DB65 for ; Mon, 25 Apr 2016 08:03:41 +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 F225686DABC for ; Mon, 25 Apr 2016 07:37:06 +0000 (UTC) Received: from mail.ietf.org ([2001:1900:3001:11::2c]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aub4s-0007cf-2Q for ntpwg@lists.ntp.org; Mon, 25 Apr 2016 07:37:06 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542012D1D2; Mon, 25 Apr 2016 00:37:05 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425073705.28350.52431.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 00:37:05 -0700 X-SA-Exim-Connect-IP: 2001:1900:3001:11::2c X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: internet-drafts@ietf.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] I-D Action: draft-stenn-ntp-i-do-01.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@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" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol of the IETF. Title : Network Time Protocol I-Do Extension Field Author : Harlan Stenn Filename : draft-stenn-ntp-i-do-01.txt Pages : 5 Date : 2016-04-25 Abstract: The first implementation of NTPv4 was released in 2003. NTPv4 is defined by RFC 5905 [RFC5905]. It contains a public-key security protocol, autokey, which is defined by RFC 5906 [RFC5906]. Until very recently, autokey has been the only defined "user" of NTP packet Extension Fields. New proposals for extension fields are being written and there is currently no convenient way to learn if a remote instance of NTP supports any extension fields or not. This proposal contains a method to tell a remote instance of NTP what we support, and ask what they support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-stenn-ntp-i-do-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-stenn-ntp-i-do-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Apr 29 14:08:38 2016 Return-Path: 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 C178A12D564 for ; Fri, 29 Apr 2016 14:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.805 X-Spam-Level: X-Spam-Status: No, score=-7.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=oroliagroup.onmicrosoft.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 kCKXzAQkBQSO for ; Fri, 29 Apr 2016 14:08:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id D7C1212D739 for ; Fri, 29 Apr 2016 14:08:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 8CA8086DABF for ; Fri, 29 Apr 2016 21:08:36 +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 11DA286D48C for ; Fri, 29 Apr 2016 20:30:07 +0000 (UTC) Received: from mail-db3on0064.outbound.protection.outlook.com ([157.55.234.64] helo=emea01-db3-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1awF30-0008LJ-Jw for ntpwg@lists.ntp.org; Fri, 29 Apr 2016 20:30:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=OROLIAGROUP.onmicrosoft.com; s=selector1-spectracom-orolia-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hkz4aUwioNLqHWAJO7uFMiUAv9xfDHLzROdfnwaf9so=; b=bGWMRmTPbA0n5z4RsPjDcmh7rqqfh2eccseCIRPObjh+qPM8W/NR+kyf/fX6gYAXoke5l6uuIJcYiAbuPrlR/kjoW3xk03/BlbbLZ70Xikdr4TnW9UyAug4Rcixu4H5MsP3kOHmZ+EZLIcr+szDJuR2oo6VBK8WNMYBAu3vzzdI= Received: from AM3PR06MB1202.eurprd06.prod.outlook.com (2a01:111:e400:58a0::28) by AM3PR06MB1204.eurprd06.prod.outlook.com (2a01:111:e400:58a0::30) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 29 Apr 2016 20:29:54 +0000 Received: from AM3PR06MB1202.eurprd06.prod.outlook.com ([fe80::18f6:dc6:e8d5:2bc1]) by AM3PR06MB1202.eurprd06.prod.outlook.com ([fe80::18f6:dc6:e8d5:2bc1%14]) with mapi id 15.01.0466.028; Fri, 29 Apr 2016 20:29:54 +0000 From: Denis Reilly To: Karen O'Donoghue , "tictoc@ietf.org" Thread-Topic: WGLC on draft-ietf-tictoc-ptp-enterprise-profile-06 Thread-Index: AQHRmxVIxH0uTbr/rUq9StTgt++Pg5+hdQyg Date: Fri, 29 Apr 2016 20:29:54 +0000 Message-ID: References: <15556A59-F26E-41DE-BF9E-BF6344F534A6@isoc.org> In-Reply-To: <15556A59-F26E-41DE-BF9E-BF6344F534A6@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isoc.org; dkim=none (message not signed) header.d=none;isoc.org; dmarc=none action=none header.from=spectracom.orolia.com; x-originating-ip: [66.193.84.98] x-ms-office365-filtering-correlation-id: 60e12e63-b0e2-4ce6-7ef6-08d3706d0656 x-microsoft-exchange-diagnostics: 1; AM3PR06MB1204; 5:YsK5A1Fk6XOizcFnxjHANOtvuY4gdVN63qkYnBT5kR1pSZiDI4KvK5vvlsga/bFr9WWzarhukmm4+ezc+r/AihzHtoL3XO4fty2do8wfarxwqcVNvCBr9tHIxO76zp1T66VA9E9TPoai/ktsPr+K0GRqMeEne68vYm5uySAJcsb9VaaHlZb8Ygn5CNh2mFME; 24:DLZQngoUsNP//JIPzsTMMwu55OH+miejw9JdvQWxAo7DN+y+PuHQpEVUIc208Db0T60DsynRJBpqCl3LOd/YInMINV4BXsjqrBL+NiyrSDo=; 7:/tr+ekAT6Ko2jxWm1/g0ZBoZmRzEuqbSApmmRRfRsSV+ivsPZ33ZO62YiZHPCsPCDQMZ78M3PPzkPn5Yh7IQXxwudGveGNyEOOGiwiGIQ08dbbYAn2+EGByHm38Vhdkz7qTdnixoGKZ4E17Vc1GGmPiwnU4j6utBzPsRLJW56f25RwRCwfcPv1jefgAfYArSNJmv8Tzo4HOTz7nnXS0i/yPU7g7xetqhu8RAZrpqNUg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR06MB1204; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR06MB1204; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB1204; x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(19580395003)(19580405001)(2906002)(3660700001)(5008740100001)(189998001)(74316001)(2501003)(106116001)(87936001)(66066001)(230783001)(86362001)(5003600100002)(3280700002)(33656002)(76576001)(102836003)(3846002)(6116002)(2950100001)(11100500001)(92566002)(81166005)(2900100001)(15975445007)(1220700001)(1096002)(5001770100001)(1720100001)(9686002)(5250100002)(50986999)(5002640100001)(76176999)(54356999)(586003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR06MB1204; H:AM3PR06MB1202.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: spectracom.orolia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2016 20:29:54.8199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a263030c-9c1b-421f-9471-1dec0b29c664 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB1204 X-SA-Exim-Connect-IP: 157.55.234.64 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: denis.reilly@spectracom.orolia.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] WGLC on draft-ietf-tictoc-ptp-enterprise-profile-06 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ntpwg@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" All, I like this version of the document (draft-ietf-tictoc-ptp-enterprise-profile-06) and would support it moving on to the next phase. Best Regards, -- Denis Reilly | Lead Engineer | denis.reilly@spectracom.orolia.com (585)321-5837 This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you received this e-mail in error please note that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. -----Original Message----- From: ntpwg [mailto:ntpwg-bounces+denis.reilly=spectracom.orolia.com@lists.ntp.org] On Behalf Of Karen O'Donoghue Sent: Wednesday, April 20, 2016 11:00 AM To: tictoc@ietf.org Cc: ntpwg@lists.ntp.org Subject: [ntpwg] WGLC on draft-ietf-tictoc-ptp-enterprise-profile-06 Folks, This message begins a 2 week WGLC on the following document: Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile-06 Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed. Please send all comments in by Wednesday 4 May 2016. Thank you! Karen _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sat Apr 30 19:45:43 2016 Return-Path: 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 546A812D1B6 for ; Sat, 30 Apr 2016 19:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.915 X-Spam-Level: X-Spam-Status: No, score=-107.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, USER_IN_WHITELIST=-100] 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 fshvR4cySz4M for ; Sat, 30 Apr 2016 19:45:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 68FFA12D137 for ; Sat, 30 Apr 2016 19:45:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 59F0186DB36 for ; Sun, 1 May 2016 02:45:41 +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 C6E2686D4A6 for ; Fri, 29 Apr 2016 15:32:29 +0000 (UTC) Received: from rfc-editor.org ([2001:1900:3001:11::31]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1awAP6-0004EL-3n for ntpwg@lists.ntp.org; Fri, 29 Apr 2016 15:32:29 +0000 Received: by rfc-editor.org (Postfix, from userid 30) id 870F0180003; Fri, 29 Apr 2016 08:32:07 -0700 (PDT) To: mills@udel.edu, jrmii@isc.org, jack.burbank@jhuapl.edu, william.kasch@jhuapl.edu, suresh.krishnan@ericsson.com, terry.manderson@icann.org, odonoghue@isoc.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160429153207.870F0180003@rfc-editor.org> Date: Fri, 29 Apr 2016 08:32:07 -0700 (PDT) X-SA-Exim-Connect-IP: 2001:1900:3001:11::31 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: wwwrun@rfc-editor.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Sun, 01 May 2016 01:50:46 +0000 Subject: [ntpwg] [Editorial Errata Reported] RFC5905 (4680) X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org, r.brama@cmclabs.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 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" The following errata report has been submitted for RFC5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5905&eid=4680 -------------------------------------- Type: Editorial Reported by: Riccardo Brama Section: 6, Fig 3 Original Text ------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Era Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Era Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Fraction | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NTP Date Format Corrected Text -------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Era Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Era Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Fraction + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NTP Date Format Notes ----- This allows to better appreciate only two 32b rows really form the Fraction part, leading to an overall type length of 128b instead of 160b as it could otherwise be misunderstood in the original figure. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5905 (draft-ietf-ntp-ntpv4-proto-13) -------------------------------------- Title : Network Time Protocol Version 4: Protocol and Algorithms Specification Publication Date : June 2010 Author(s) : D. Mills, J. Martin, Ed., J. Burbank, W. Kasch Category : PROPOSED STANDARD Source : Network Time Protocol Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg