Re: [Ntp] Details of the fragmentation attacks against NTP and port randomization
Warner Losh <imp@bsdimp.com> Wed, 12 June 2019 02:26 UTC
Return-Path: <wlosh@bsdimp.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 8BCC81200B7 for <ntp@ietfa.amsl.com>; Tue, 11 Jun 2019 19:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) 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 MTRJ7clk1UY4 for <ntp@ietfa.amsl.com>; Tue, 11 Jun 2019 19:26:43 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 2F0D512007A for <ntp@ietf.org>; Tue, 11 Jun 2019 19:26:42 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id d15so9050866qkl.4 for <ntp@ietf.org>; Tue, 11 Jun 2019 19:26:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aYc6T7QKzcNxTXyFwX4y64Gz4n4VeTC0oqpjtKeZz48=; b=w9wTSSyb6RONGVuV/TM9FZVpb69RtFpDJ+Ad0GhzeNrPhs5Z3bn6O+Xu0MccDpK8p1 1aR2KBGIhxebM/oIWRNpcMOEue0SbCBAQWClUY70friKdDKGLcVDnYB5v6/kGUBRPuk7 IncAMZguFzIh8X3q7wa1RwNgM0V70nuEGg39ihR0Ozo6jd/ZdyLNiDDV7FUgTORW2El0 r6VyhCKrdRnkk0H8ymb9XFqkLUBFaZTY8wTsLCICkJR14QwM2RuHNpt1uJTZplb3SS6c WgZGYBFph+ZhuxlOcmdX8vXxBPgqbYP4P4GhKzmuhwjDBkN5ohjoWGSWwDTpSasqJjrQ EYvg==
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=aYc6T7QKzcNxTXyFwX4y64Gz4n4VeTC0oqpjtKeZz48=; b=W+6MTmWkQsQ0g2cL+4s0wajAcmm9tq3dXTrgDfPpvOXrvXPUSSnX/kY4XaE6mxvsj3 JWECwz4yWyL7a+2ZzSXvolH+1/dUi3gtup80vi2rH/D7xJ1XTwhA9o8YbMNwbJKHN7tA nST3qtPy3i2AOFLdMbPl/EwO0bQ7sZUakfoAg5k5VgVLEH+hmC/R4ODXmCtZbZojxkey jTVQekcgIDIb9Xj8D9BBHhuiFMT8OsbspTlkVYYQCScPGPDRa68yf3j6EXdmBPRSfDcS 24zxW9HYDd7sY9eT6YNGz+KWp+cv78ICexFsybQWvEfv8+9e8xH06BK4ZBCWC8WwtlmQ QSmQ==
X-Gm-Message-State: APjAAAXtmB6bYClq/0V2OytBQwfYpXxhbly9FUyY0QsiJIPxaz7Sm7BE 1JrYISdtvauvJL6m/TRh3mRMwKVpQQojKjP5mVMpiQ==
X-Google-Smtp-Source: APXvYqxVTjlFWe/+PNjeNGTvVOZbdDmxJ01i1tPd0fttQ5EPzIyUDiepWtmWV/CR+gqKye4Nw+M6ZweCFKAsb2aSl4g=
X-Received: by 2002:a05:620a:1519:: with SMTP id i25mr31854302qkk.331.1560306401722; Tue, 11 Jun 2019 19:26:41 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <b4a5d0ec-606e-7994-9bc9-e21e24f38def@ntp.org>
From: Warner Losh <imp@bsdimp.com>
Date: Tue, 11 Jun 2019 20:26:29 -0600
Message-ID: <CANCZdfp-Zro4Kqf3BtTWuW-r1gDNkbyTwQePFt4ov-ucxOjnSQ@mail.gmail.com>
To: Danny Mayer <mayer@ntp.org>
Cc: Fernando Gont <fgont@si6networks.com>, NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d0e836058b1724ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/v7a6TZMtp6xVrSO3qO28KDZMiYQ>
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: Wed, 12 Jun 2019 02:26:46 -0000
Can we please keep it technical rather than launch into personal attacks? You can make your points without the vitriol and nastiness. Warner On Tue, Jun 11, 2019, 4:34 PM Danny Mayer <mayer@ntp.org> wrote: > > On 6/7/19 6:53 AM, Fernando Gont wrote: > > On 5/6/19 05:41, Danny Mayer wrote: > >> On 6/4/19 2:39 AM, Fernando Gont wrote: > >>> On 4/6/19 06:09, Danny Mayer wrote: > >>>> On 6/3/19 2:24 PM, Watson Ladd wrote: > >>>> > >>>>> Dear all, > >>>>> > >>>>> The debate over client port randomization is missing an important > >>>>> fact: off-path attacks against NTP are not prevented by the origin > >>>>> timestamp due to the OS handling of fragmentation. In > >>>>> http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf we see that > sending > >>>>> a properly crafted IP fragment can selectively overwrite NTP packets, > >>>>> thus allowing an attacker to modify received data without overwriting > >>>>> the origin timestamp. I would recommend we adopt port randomization > >>>>> to handle this problem. > >>>>> > >>>>> Sincerely, > >>>>> Watson Ladd > >>>> Actually if you read Section VI you will see that the last sentence of > >>>> that section states that they do not consider it to be a sufficient > defense. > >>> Wasn't Your argument that the timestamp was enough to mitigate off-path > >>> attacks? > >>> > >> Yes and no. The draft you wrote requires using random ports to avoid > >> off-path attacks. > > No. > Actually that's exactly what it says. See the abstract of your own draft. > > > > The draft we wrote says employing predictable identifiers is a bad > > practice that has been known for over 20 years. We have been on this > > road so many times. You just don't use predictable IDs. > You do this of off-path attackers. > > > > Using them leads to trouble, with no benefit. Using random port numbers > > helps mitigate such trouble. > No always which why your RFC is a BCP. What needs to be clarified is > when it is wise to do so and when not to do so and what are the > consequences if you do so. You cannot make proposals without including > them. > > > > > > > >> The paper demonstrates that for at least some O/S's an > >> off-path fragmentation attack succeeds regardless of the port number. > >> This is at a layer below NTP. So randomizing the ports doesn't matter > >> for this attack according to the paper. The proper way to deal with this > >> fragmentation attack is to fix the underlying O/S behavior as has > >> already been done for most of them. The NTP basic payload is only 48 > >> bytes so there is no reason to allow fragmentation in the first place. > > The IPv4 minimum MTU is 68 bytes. Anything longer than that may need to > > be fragmented. > Yes, and when you add the UDP envelope and the IP envelope to the NTP > Payload you have 78 bytes (if I did the addition correctly). If there > were way to avoid fragmentation I'd recommend doing so particularly for > NTP packets as they are time-sensitive, separate from this fragmentation > attack. A fragmented, reassembled NTP packet is likely to be thrown out > anyway since it is likely to be outside the limits of the error budget, > jitter, and other acceptability requirements. > > > > > >> If you can't attack that way then your off-path attacker cannot guess > >> the origin timestamp which is a 64-bit quantity. Furthermore the > >> attacker doesn't know the server being used by the NTP client so the IP > >> address of that server will be invalid as well. > > In many-many cases, the possible NTP servers are known. We have been > > dicussiing this sort of thing *for ages* in the transport area. See e.g. > > RFC5927 > > > > > > > > > >> So RFC6056 doesn't really apply as a mandate. > > It's a BCP from the *transport area* about how to employ ephemeral port > > numbers. I can't see what's the rationale to ignore such advice. > It's advice and you need to examine consequences in both directions > before you recommend this. > > > > > >> You can certainly ask to > >> update draft-ietf-ntp-bcp to recommend randomizing the port for outgoing > >> queries. > > Yes. That's what our draft does. > No, it actually obsoletes RFC5905! You should be updating the NTP BCP > since you seemed to have missed the draft review. > > > > > >> In any case RFC6056 is about randomizing ports and is not > >> really a security document. If it were then it would have made a very > >> basic recommendation concerning the port: if you have received your > >> response and it is valid then close the port immediately and the next > >> time you want to make a new request open a new random port to perform > >> the request. That way the off-path attacker will have no way of knowing > >> what the new port number will be. > > The document provides advice for all transport protocols. What you > > describe only applies for connection-less protocols, where the app-layer > > only does occasional packets exchanges. > And falls short of proper advise on what to do when the port is not in > use. NTP *is* a connectionless protocol and that's what this WG is > dealing with. > > > > > >> In the case of NTP you don't want to trust a single server, The draft > >> NTP BCP recommends at least 3 different servers and preferably 4 to > >> allow for the loss of one server. > > You keep mixing things up. > > > > There's a lot of things you may want to do (and probably should!) at the > > app layer. This document is concerned with what you do at the *transport > > layer*. Any good practices at the app layer don't rule out good > > practices at the transport layer. > Yes, but you need to consider the consequences of what you do at each > layer, you cannot do this in a vacuum. You seem to ignore the whole in > preference of the detail. It's the whole you need to deal with. > > > > You keep arguing that you want to keep a very bad practice, because > > somehow you are doing something else that you thing will relieve you > > from the possible pain of the bad practice. > Not at all. If the circumstances are right then you should do it. > > > > Our draft argues: bad practices are bad practices. Do the right thing. > Reminds me of Theresa May's statement: "Brexit means Brexit" which > really means nothing at all. Doing the right thing involves more than > just saying that. > > > > > >> See section 3.2. If you are really > >> concerned about security you should arrange with your server providers > >> to include either a MAC at the end of the packet or use the new NTS > >> security mechanism to validate and secure the packets returned. If you > >> are concerned about attacks you should be employing firewalls anyway. > >> Lastly you can get yourself a GPS unit and use that to get your clock > >> information. For the really paranoid, get an atomic clock! > > I guess with the same line of reasoning you could argue that if you're > > really concerned about security, you wouldn't keep the servers connected > > to the Internet? > > No I'm saying use proper security where possible or close the port when > not using it and open it on a new port when you need it again. *That* is > good practice yet nowhere in RFC6056 does it say that. > > Danny > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp >
- [Ntp] Details of the fragmentation attacks agains… Watson Ladd
- Re: [Ntp] Details of the fragmentation attacks ag… Danny Mayer
- Re: [Ntp] Details of the fragmentation attacks ag… Watson Ladd
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… tglassey@earthlink.net
- Re: [Ntp] Details of the fragmentation attacks ag… Danny Mayer
- Re: [Ntp] Details of the fragmentation attacks ag… Ask Bjørn Hansen
- Re: [Ntp] Details of the fragmentation attacks ag… Warner Losh
- Re: [Ntp] Details of the fragmentation attacks ag… Tony Finch
- Re: [Ntp] Details of the fragmentation attacks ag… Watson Ladd
- Re: [Ntp] Details of the fragmentation attacks ag… Majdi S. Abbas
- Re: [Ntp] Details of the fragmentation attacks ag… Danny Mayer
- Re: [Ntp] Details of the fragmentation attacks ag… Hal Murray
- Re: [Ntp] Details of the fragmentation attacks ag… Danny Mayer
- Re: [Ntp] Details of the fragmentation attacks ag… tglassey@earthlink.net
- Re: [Ntp] Details of the fragmentation attacks ag… Miroslav Lichvar
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… Salz, Rich
- Re: [Ntp] Details of the fragmentation attacks ag… Danny Mayer
- Re: [Ntp] Details of the fragmentation attacks ag… Watson Ladd
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… Danny Mayer
- Re: [Ntp] Details of the fragmentation attacks ag… Warner Losh
- Re: [Ntp] Details of the fragmentation attacks ag… tglassey@earthlink.net
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… kristof.teichel
- Re: [Ntp] Details of the fragmentation attacks ag… Gary E. Miller
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… Gary E. Miller
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- Re: [Ntp] Details of the fragmentation attacks ag… Gary E. Miller
- Re: [Ntp] Details of the fragmentation attacks ag… Fernando Gont
- [Ntp] Antw: Re: Details of the fragmentation atta… Ulrich Windl
- Re: [Ntp] Antw: Re: Details of the fragmentation … Fernando Gont