The end of the beginning is in sight
Hal Murray
hmurray at megapathdsl.net
Sat Jan 7 06:06:45 UTC 2017
esr at thyrsus.com said:
> I think the solution for this is obvious. We define an extension type the
> contents of which, if it exists, SHOULD be used as the refid.
> Implementations that don't know about that extension will be no worse off
> than before.
Only if they correctly ignore extensions that they don't expect.
I'll bet there is a lot of code out there that has never seen an extension
and does a simple sanity check on the length of a packet assuming there are
no extensions.
> Somebody mentioned on the Signal channel that some routers truncate NTP
> packets to their 48-byte headers in order to avoid DoS attacks. If that's a
> widespread practice, it pretty much blocks the easy path forward - we'll
> need a new protocol number and a new protocol.
There is some filtering going on, but I don't know any details. I think it
would be wrong to try to depend on any specific form of it.
[extenstions]
> Can you be more specific about the past troubles?
Not really. There was a lot of discussion about various complications on one
of the ntp lists. I didn't follow all the details and/or I may be confusing
two discussions.
I think the problem was that autokey got tangled up in this area. Maybe a
few magic lengths had to be avoided. ???
> I'm already sketching a couple of possibilities for NTPv5 in my head. Both
> are based on the PNG model of self-describing chunks (which I've heard it
> iherited from TIFF). One uses binary chunks, like PNG itself. The other uses
> textual chunks. I could detail-spec either in a couple days' work.
It's not hard if you have a clean slate. It's much more complicated if you
have to support existing installed gear that won't get updated.
--
These are my opinions. I hate spam.
More information about the devel
mailing list