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

kristof.teichel@ptb.de Thu, 13 June 2019 15:06 UTC

Return-Path: <kristof.teichel@ptb.de>
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 6C1B11203C6; Thu, 13 Jun 2019 08:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 1z3nWCcnQCn2; Thu, 13 Jun 2019 08:06:09 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48791203C8; Thu, 13 Jun 2019 08:05:55 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id x5DF5qmi015218-x5DF5qmk015218 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 13 Jun 2019 17:05:52 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 43A1F7EA5E1; Thu, 13 Jun 2019 17:05:52 +0200 (CEST)
In-Reply-To: <f4b5312c-b02c-ee51-1c59-f0467f51ab77@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>
To: Fernando Gont <fgont@si6networks.com>
Cc: ntp@ietf.org, ntp <ntp-bounces@ietf.org>
MIME-Version: 1.0
Message-ID: <OF8F5917D8.BA274E92-ONC1258418.004C2FAF-C1258418.0052EEFB@ptb.de>
From: kristof.teichel@ptb.de
Date: Thu, 13 Jun 2019 17:06:18 +0200
Content-Type: multipart/alternative; boundary="=_alternative 0052EEF8C1258418_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/mfFGZpSEghZqIN4N1kcB8_xQwuE>
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: Thu, 13 Jun 2019 15:06:16 -0000

Hello all,

so far, I have remained largely silent on this thread, mostly because I 
felt I knew too little about the implications of port selection and usage.
But the more of this discussion I witness, the more Fernando's points make 
sense to me on a purely logical, abstract level and I suspect that large 
parts of the discussion have involved mix-ups regarding where the 
burden-of-proof actually lies.

We've established a few things that are (I believe) non-controversial:
1) Always randomizing ports is the default decision, as per a BCP document
2) The default decision as per a BCP document is not mandatory and its 
benefits should be weighed against potential costs/disadvantages
3) Randomizing ports does not immediately solve all possible security 
issues (on all network layers) involving NTP

As I see it, 1) puts the burden-of-proof on anyone arguing not to opt for 
mandating port randomization.
Accepting that, 2) gives a prescription of what such a proof might look 
like: prove that the costs outweigh the benefits.
I guess 3) becomes somewhat relevant here, but logically, "is not a 
perfect solution" basically tells us nothing.
>From my point of view, the combination of 1) - 3) just says: mandate port 
randomization except in cases where there is proof (!) of significant cost 
outweighing its benefits.

Which brings us to the final discussion point, which seems (much) more 
controversial:
4) Randomizing ports might or might not in some cases have significant 
disadvantages

Basically, I think the way forward is pretty clear-cut:
We want a list of concrete scenarios/use cases that pertain to 4) where 
the suspicion is that the costs of randomizing ports outweigh its benefits 
and mandate/recommend port randomization in all other scenarios.
The decision process for each individual scenario that *does* appear on 
said list is complex: come up with actual metrics to quantify both the 
costs and the benefits (avoiding oversimplification specifically by either 
using 4) without proof or fallaciosly mistaking 3) for a showstopper.), 
then do the following.
If the benefits predominate, mandate/recommend port randomization. If the 
costs predominate, formulate a clear rationale for why they do and include 
that in whatever document the proposal eventually affects. If in doubt, 
mandate/recommend port randomization - because 1).
(Just to be clear: from my point of view, there is currently no proof that 
this list is even non-empty.)


Best regards,
Kristof





Von:    "Fernando Gont" <fgont@si6networks.com>
An:     "Danny Mayer" <mayer@ntp.org>, ntp@ietf.org
Datum:  13.06.2019 15:36
Betreff:        Re: [Ntp] Details of the fragmentation attacks against NTP 
and port randomization
Gesendet von:   "ntp" <ntp-bounces@ietf.org>



Hello, Danny,

On 12/6/19 01:33, Danny Mayer 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.

It's a mitigation. It is not meant to be *the only* mitigation.




>> 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.

Could you please tell me the advantages of using the flawed scheme (src
port=123)?





>>> 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. 

That's layer 3, where port randomization is layer 4. I'm fine with any
smarts you want to do at any other layers... but that's exactly the
point: what you do at other layers has nothing to do with port
randomization, which happens at layer-4.



>>> 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.

Indeed, and hopefully the next rev will expand on this.

May I ask, once again:
* What are the befenits of src=123?

* If you assume there are bad implications of port randomization, which
would be a show stopper for this I-D, why aren't we already suffering
from that trouble in all the scenarios where we have multiple NTP
clients operating behind a NAT?



>>> 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.

There is an error in the I-D, indeed: it should say "Updates", rather
than "Obsoletes". We will fix this.

RFC5905 talks about port number selection. SO it's RFC5905 that should
be updated.



>>> 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. 

It talks about port number *selection*, not *usage*. FOr obvious reasons
it also doesn't answer questions such as "Should my app protocol reuse
the same connection, or use different connections to exchange objects?".
It also doesn't comment on "should i use a 'connected' UDP socket or not?"



> NTP *is* a connectionless protocol and that's what this WG is
> dealing with.

The RFC6056 talks about ephemeral port selection, irrespective of
whether the transport protocol is conenctionless or connection oriented.




>>> 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.

The transport area considered that "whole" when it issued its BCP. If
you want to go against such BCP, please provide arguments in that 
direction.

I'd expect that in the context of the normal scenario of multiple NTP
clients behind NAT devices, you might have a hard time. But please give
it a try.




>> 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.

PLease go and tell the transport area. And while you do it, please
answer the question I asked before, namely:
What are the problems you expect with port randomization, and if they
are such big problems, how you are dealing with them in networks such as
IPv4-based where NATs are already part of the architecture.



>>>  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.

Because it talks about port number selection, not usage.

Want a similar example: IPv6 address configuration and IID
generation/selection vs IPv6 address usage policies. You are mixing up
two orthogonal things.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp