[email protected] 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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
