Re: [Ntp] An NTPv5 design sketch

Miroslav Lichvar <mlichvar@redhat.com> Tue, 14 April 2020 15:39 UTC

Return-Path: <mlichvar@redhat.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 360C83A09EC for <ntp@ietfa.amsl.com>; Tue, 14 Apr 2020 08:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 Uy_uGZgND8KX for <ntp@ietfa.amsl.com>; Tue, 14 Apr 2020 08:39:00 -0700 (PDT)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9873A09D2 for <ntp@ietf.org>; Tue, 14 Apr 2020 08:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586878737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZSuEVQio7XAbdXgubeEeLS1wxX7lsRLaVcVnixrSi3U=; b=AwTMUJgCvvQsoNwSY4OKQmwVg7gOfFv+X3kGGPl7OIvWyRILCLt/Q9liXHeBE+ysE8qCOv 12cdvnZB5a3cj3FSYMEbDF6oy+z1PQwq24JqKB5liCosZHqbQ3BLJTr1KIv53NBG7hsUIP ANZWbnl5qkIJGzXI0LfrafsD8DEtbBU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-75-7UHYjgRmOxeRKpOa_udYvA-1; Tue, 14 Apr 2020 11:38:52 -0400
X-MC-Unique: 7UHYjgRmOxeRKpOa_udYvA-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8C8E4107ACC9; Tue, 14 Apr 2020 15:38:51 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2477272A0; Tue, 14 Apr 2020 15:38:49 +0000 (UTC)
Date: Tue, 14 Apr 2020 17:38:48 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: NTP WG <ntp@ietf.org>
Message-ID: <20200414153848.GE1945@localhost>
References: <CAJm83bBV+Pox3r6KU49ShwMOvr=R+U_vDKJtSZhfT6XX4qWmbA@mail.gmail.com> <20200414112541.GD1945@localhost> <CAJm83bAFwZYtWac-ABL-ozMqa=oppekF078-zOBmMUD7=Ah=Bw@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAJm83bAFwZYtWac-ABL-ozMqa=oppekF078-zOBmMUD7=Ah=Bw@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/BTKk29dBTnWWVA6knsbXnI3STYA>
Subject: Re: [Ntp] An NTPv5 design sketch
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: Tue, 14 Apr 2020 15:39:01 -0000

On Tue, Apr 14, 2020 at 10:35:16AM -0400, Daniel Franke wrote:
> You're correct — having just a brief ability to receive traffic at a
> particular IP address allows later amplification of traffic to that
> address until the cookie expires. But the same thing is true of
> practically every other protocol on the internet. Modern UDP-based
> protocols like QUIC implement a similar scheme to this one, with the
> same shortcoming and a much larger amplification factor. Anything
> TCP-based is susceptible as well, if the attacker can learn (or guess)
> the initial SYN value.

I'm not sure if QUIC or TCP is comparable to NTP/NTS. It is not
possible to blindly create a new connection, or replay one, is it?

An existing TCP connection can be exploited only as long as the upper
protocol allows it. For example, is it likely that the attacker would
be able to blindly send requests to its own HTTPS connection
continuously for a week?

-- 
Miroslav Lichvar