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

[Warner Losh <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>