Re: [Ntp] Eric Rescorla's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Fri, 22 March 2019 16:29 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE61B13121E for <ntp@ietfa.amsl.com>; Fri, 22 Mar 2019 09:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 KVOmwfrKwYob for <ntp@ietfa.amsl.com>; Fri, 22 Mar 2019 09:29:49 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7890131229 for <ntp@ietf.org>; Fri, 22 Mar 2019 09:29:48 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id y18so1886679lfe.1 for <ntp@ietf.org>; Fri, 22 Mar 2019 09:29:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SsKVGS5uiH8EzOrqTRtPJ4h9wc7jqr7FXlae76rjsCo=; b=mZcpLR2bhkDDo6lbbFWMvSjJk8RuY9LpcDd0NJLOFoAVoMuGfQY3pFaM2nxJm8W4vi IVlT/Ci1ZpQKCSUQinqwLWcfGYge+OtxMr0WreedI0JS6O0DLiFsLh/GctqOCoTRY5kT o793RdwnNlaUf3GC2lUiufDzmMkfXWyhZ5TphzSllCOPjyxZ5P1fFGvUOlwHk89FrWzW HG4jDopsK6p/2ReYtDQJBCHO/Dg5q5c0U5QaBuYfj2d2FyOnbMOlDdaZX8Axz749ko4d y9OmwfXEY5xNeu4qNo1Ef0dH4U5r5JdI+MPc4jl/NpQboR8/aKjywlnjBzq9tAlxQOhU LLJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SsKVGS5uiH8EzOrqTRtPJ4h9wc7jqr7FXlae76rjsCo=; b=FVs+KyuQsA1NpbVpvov+CH1A26e0f7eZvXh90+VpfF185xX/EKFmYq+rbxIiuLvh/V OnO8s5ygbLKKTb3+FKyasI91ove5CFnWHFpQJz0TC+eRYTraaxQtJoRtC0DbPNMviEW3 +9ggsuFeG/XstGKvt9qALK2KgIijQz2a8lD1WK06bgbLr4smGHd/MhdPDQ9QRbMxROyn z2btgfMnXNmHBqLBZWXEfF5c8Bq1RK3iytv0xGG2eBU8sFVZrd3vK38qdCTZCKrVEDyg 3+4zW+ad0QUhL+BtN2Ojkb7cqsaIsNUelpEXRauBYdGNkV0YJnfJFOoV+une/5sElOzY PFFA==
X-Gm-Message-State: APjAAAVgrRx/RNeCeoy9kRGr9cfH2iolM445VGnYMhu9kFXhv9yw6RK7 fHjkYVg8ioxZAMv7cwvzH8pm58C/3TLLSRKRa+xWyg==
X-Google-Smtp-Source: APXvYqx0uOrAHjfuibKrSiOYWjV/vewKOl2WaLAr0Rkh2ftgHMWLAhM7Vo1eLiJcDp1jrS8ZhYHGZYJyUAXKquAUE2A=
X-Received: by 2002:ac2:53a4:: with SMTP id j4mr4988131lfh.106.1553272187027; Fri, 22 Mar 2019 09:29:47 -0700 (PDT)
MIME-Version: 1.0
References: <154527054937.2209.11236792660983022790.idtracker@ietfa.amsl.com> <AM0PR0602MB373042D6BA57B56999B91864FF830@AM0PR0602MB3730.eurprd06.prod.outlook.com>
In-Reply-To: <AM0PR0602MB373042D6BA57B56999B91864FF830@AM0PR0602MB3730.eurprd06.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 22 Mar 2019 09:29:09 -0700
Message-ID: <CABcZeBMXnaCebrRfL=SHN8+3qTjcrb7yFWG2AfSf=FWXOtiPEg@mail.gmail.com>
To: Denis Reilly <denis.reilly@orolia.com>
Cc: The IESG <iesg@ietf.org>, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>, "odonoghue@isoc.org" <odonoghue@isoc.org>, "draft-ietf-ntp-bcp@ietf.org" <draft-ietf-ntp-bcp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f2970b0584b15c49"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/d_YLcgFLNGh7aMt4AwHaUZYfoO0>
Subject: Re: [Ntp] Eric Rescorla's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2019 16:29:54 -0000
On Thu, Jan 17, 2019 at 10:14 AM Denis Reilly <denis.reilly@orolia.com> wrote: > Hello, Eric! Thanks for the review. Sorry for the late reply. I've posted > a new version of the draft which incorporate the feedback from the review. > > Please see our responses in-line: > > -- > Denis Reilly | Technical Lead | denis.reilly@orolia.com (585)321-5837 > > -----Original Message----- > From: Eric Rescorla <ekr@rtfm.com> > Sent: Wednesday, December 19, 2018 8:49 PM > To: The IESG <iesg@ietf.org> > Cc: ntp-chairs@ietf.org; Karen O'Donoghue <odonoghue@isoc.org>; > ntp@ietf.org; odonoghue@isoc.org; draft-ietf-ntp-bcp@ietf.org > Subject: Eric Rescorla's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS > and COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-ntp-bcp-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3844 > > I notice that a number of the recommendations here differ from those in > NDSS16. In particular the following recommendations from that paper do not > seem to appear: > > - Do not put INIT in the reference ID on restart > - Do not send KoD > - Disable fragmentation > - Randomize source ports > > I'm not saying that all of these recommendations need to be in this > document, but I am curious why they are not and would tend to think that > one should document why they are not. > > Response: > We worked closely with Sharon Goldberg, one of the authors on the > referenced paper, when writing this section. While the paper makes the > recommendations you list, we simply didn't want to include everything in > the BCP, but rather include the things that would have the most immediate > impact. > > - The advice for not putting INIT in the reference ID on restart might be > useful to include after all, as we do give other advice for implementors at > the end of the "Avoiding Daemon Restart Attacks" section, so we will add it. > > - The paper lists "eliminate NTP's KoD" as one recommendation, but then > immediately acknowledges that it eliminates a server's ability to deal with > heavy volumes of traffic. We elected to not recommend the elimination of > KoDs, in part because there will be many servers deployed who still use > them. Perhaps that is a topic for NTP v5, someday. > > - The paper suggests that the attack surface for the NTP fragmentation > attack is "small but non-negligible". We felt the attack surface was not > large enough > to include directly in this BCP. Since the paper is referenced in multiple > places, though, interested readers (such as yourself) would be able to find > it. > > - The paper mentions Source Port Randomization as a possibility to > mitigate the fragmentation attack, but then goes on to say that it is not a > "sufficient defense". > > All right. > DETAIL > S 2.1. > > response to a small query, which makes it more attractive as a > vector > > for distributed denial-of-service attacks. (NTP Control messages > are > > discussed further in Section 3.4). One documented instance of such > > an attack can be found here [1], and further discussion in [IMC14] > > and [NDSS14]. Mitigating source address spoofing attacks should be > a > > priority of anyone administering NTP. > > what does this text mean? What practices can I engage in as an NTP server > that mitigate source spoofing attacks? The next paragraph seems to largely > talk about traffic *sources*. Is the assumption that the NTP server is > supposed to do BCP 38 filtering? That seems not that effective. > > As a smaller point, I see that this text says "should", not SHOULD. Is > that a mistake or is this intended not to have any normative force? > > Response: > As part of another comment, we've moved the "mitigating source address > spoofing attacks" sentence to the next paragraph, to further highlight > it's relation to BCP38. > > BCP38 would provide some level of protection against spoofing attacks, but > as you note it's not really effective when applied at the server > level. This is why we give the guidance for large ISP's and networks. > > We do have normative language later in that paragraph now saying that "It > is RECOMMENDED that ISP's and large corporate networks implement ingress > and egress filtering", and we feel that's enough. > But these aren't things that the *server* can do, really. So, I don't understand how it's meaningful to say that it should be a priority to mitigate these attacks for "anyone administering NTP" > S 3.2. > > See Section 3.7.1 for more information. > > > > Operators SHOULD monitor all of the time sources that are in use. > If > > time sources do not generally agree, find out the cause and either > > correct the problems or stop using defective servers. See > > Section 3.5 for more information. > > It's not really possible to evaluate this advice without any description > of the threat model, which is pretty sketchily covered below. In > particular, if an attacker controls my network, then it's basically like > having one NTP server, no matter how many people I am talking to, and even > an inaccurate but secure server (e.g., tlsdate) is superior. > > Response: > In Sec. 3.2 we give advice on the number of time sources so that NTP's > inherent selection mechanisms are enabled to protect against > unintentionally false time sources. We don't consider the case in which > adversaries are able to manipulate NTP packets. This is done in Sec. 4. > Then you need to state that this isn't intended to deal with this threat model. > S 3.2. > > > > o If there are 2 sources of time and they agree well enough, then > > the best time can be calculated easily. But if one source fails, > > then the solution degrades to the single-source solution outlined > > above. And if the two sources don't agree, then it's impossible > > to know which one is correct by simply looking at the time. > > This isn't strictly true. Consider the case where I have an iPhone and the > onboard clock reads 2018-12-19 and the NTP server reads 2001. I know the > NTP server is wrong because iPhones didn't exist in 2001. > > Response: > Only if the iPhone is smart enough to disqualify the rogue source, in > which case you're still back to 1 source. I think the advice here still > stands. > The problem here is the statement that it is "impossible". That is clearly false. > -- > > S 3.4. > > optionally authenticated control of NTP and its configuration. Used > > properly, these facilities provide vital debugging and performance > > information and control. Used improperly, these facilities can be > an > > abuse vector. For this reason, it is RECOMMENDED that publicly- > > facing NTP servers should block mode 6 queries from outside their > > organization. > > Why are these facilites an abuse vector > > Response: > We've clarified that a bit: "But these facilities can be a vector for > amplification attacks when abused." > OK. -- > > > S 3.5. > > > > If a system starts getting unexpected time replies from its time > > servers, that can be an indication that the IP address of the system > > is being forged in requests to its time server. The goal of this > > attack is to convince the time server to stop serving time to the > > system whose address is being forged. > > Why would this work? Some sort of rate limit on the server. > > Response: > We've rewritten this for clarity: > If a system starts to receive NTP Reply packets from a time server > that do not correspond to any requests sent by the system, that can be > an indication that an attacker is forging that system's IP address in > requests to the remote time server. The goal of this attack would be to > convince the time server to stop serving time to the > system whose address is being forged. > I think you need to state that the time server will potentially throttle in response to this. S 7. > > anycast servers may arbitrarily enter and leave the network, the > > server a particular client is connected to may change. This may > > cause a small shift in time from the perspective of the client when > > the server it is connected to changes. It is RECOMMENDED that > > anycast only be deployed in environments where these small shifts > can > > be tolerated. > > Who is this guidance to? It seems like the clients might well not know, > but they are the ones who tolerate the shift (or not). > > Response: > The guidance is to the network operators, and ultimately to the users of > the NTP service. Utilizing Anycast in this manner may affect the quality > of the > recovered time. But in some applications, this is preferable to > potentially having to change the configuration of a large number of > clients whenever a server is added or removed. > How do the clients know whether anycast is in use? -Ekr
- [Ntp] Eric Rescorla's Discuss on draft-ietf-ntp-b… Eric Rescorla
- Re: [Ntp] Eric Rescorla's Discuss on draft-ietf-n… Denis Reilly
- Re: [Ntp] Eric Rescorla's Discuss on draft-ietf-n… Eric Rescorla
- Re: [Ntp] Eric Rescorla's Discuss on draft-ietf-n… Denis Reilly
- Re: [Ntp] Eric Rescorla's Discuss on draft-ietf-n… Eric Rescorla