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

[Danny Mayer <[e-mail]>]

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