Re: [Ntp] Details of the fragmentation attacks against NTP and port randomization

"Gary E. Miller" <gem@rellim.com> Fri, 14 June 2019 18:25 UTC

Return-Path: <gem@rellim.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 E6002120127 for <ntp@ietfa.amsl.com>; Fri, 14 Jun 2019 11:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 i3XWri6mj0AI for <ntp@ietfa.amsl.com>; Fri, 14 Jun 2019 11:25:25 -0700 (PDT)
Received: from rellim.com (spidey.rellim.com [204.17.205.8]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FF9120199 for <ntp@ietf.org>; Fri, 14 Jun 2019 11:25:25 -0700 (PDT)
Received: from localhost (spidey.rellim.com [204.17.205.8]) by rellim.com (Postfix) with ESMTPSA id C521F202A7F for <ntp@ietf.org>; Fri, 14 Jun 2019 11:25:23 -0700 (PDT)
Date: Fri, 14 Jun 2019 11:25:22 -0700
From: "Gary E. Miller" <gem@rellim.com>
To: ntp@ietf.org
Message-ID: <20190614112522.2e5676f3@rellim.com>
In-Reply-To: <3b7c6e55-b2a9-443c-e5cb-3b4c9e5bb642@si6networks.com>
References: <CAN2QdAGS20q=7+r+qMFEBBu4gNmSDR9-vYDbvgC=ZnqWLEU-6w@mail.gmail.com> <739c2eaa-05f1-0b30-4b64-fc5d3f91ce5b@pdmconsulting.net> <a3a545cf-d83d-a2c7-ad6c-3e349de78615@si6networks.com> <9f75e400-cf2f-053f-ed06-f4d6df415eaf@pdmconsulting.net> <70d86938-5d50-7732-5257-c698d7d308d6@si6networks.com> <b4a5d0ec-606e-7994-9bc9-e21e24f38def@ntp.org> <f4b5312c-b02c-ee51-1c59-f0467f51ab77@si6networks.com> <OF8F5917D8.BA274E92-ONC1258418.004C2FAF-C1258418.0052EEFB@ptb.de> <20190613100006.45108edd@rellim.com> <68186be5-764d-73e7-1631-04567edf28a7@si6networks.com> <20190613122929.0e049722@rellim.com> <3b7c6e55-b2a9-443c-e5cb-3b4c9e5bb642@si6networks.com>
Organization: Rellim
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; boundary="Sig_/LqrQXp9G/2/43BcQlIKtx2B"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ot8yN2CdEc7nRTc11IZGSOqfIqs>
Subject: Re: [Ntp] Details of the fragmentation attacks against NTP and port randomization
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, 14 Jun 2019 18:25:27 -0000

Yo Fernando!

On Fri, 14 Jun 2019 14:07:29 +0300
Fernando Gont <fgont@si6networks.com> wrote:

> > PROVEN to degrade.  With a few known mechanisms for that understood.
> > Many more suspected but as yet undocumented.  
> 
> What I'm saying it: the port number may affect the path in scenarios
> where forwarding is somewhat based on the port number.

Yes.  That is one of a great many scenarios where randomizing the port
per connection degrades the time qulity of the connection.

> Unless you
> assume that every router forwards packets with a hash-based algorithm
> that includes the port, then randomization *may* affect the path.

So you propose one, of many, ways the random port per connection is
bad.  Then sweep all the others under the rug because they are not that
one?  Sloppy thinking.

> That said, at least in the IPv4 world, you have to learned to live
> with this, since the pervasive of NATs means that it may be
> impossible to enforce src=PORT (whatever port is), unless e.g. you
> send requests every t<30 secs which is a usual NAT timeout for and
> UDP "flow".

Yup.  The point of this discussion is finding the best of all the
imperfect options.

> > But your summary did not mention it.  
> 
> Indeed the last rev didn't mentioned. In all fairness, I think it was
> you that raised this (and we already starting working on this on our
> working copy) -- those who objected to port randomization didn't raise
> this, and even less considered per-association vs per-request
> randomization in the objections they voiced.

I read the room differently.  No need to pile on when the data is
obvious.  Save the discussion for the differences.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem@rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin