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