Re: 'g' suffix egg on my face
Sanjeev Gupta via devel writes: > Eric, next request. I have a spare parallel port on the system, could I > have a software patch so that it can connect to a 10G optical WDM cable? But that only works if you drill a hole exactly down the center of each data wire in the parallel cable, you'll also need one hole per wavelength in the strobe wire. ;-P Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Does broadcast *server* mode still exist?
Hi, I know that broadcast *client* mode was removed last year, because it was impossible to secure. Broadcast *server* mode was deprecated. I have a feeling that was also removed, at some time. Has it? -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
Sanjeev Gupta via devel : > I have a feeling that was also removed, at some time. Has it? I do not recall that we explicitly removed it. But I wouldn't count on it to work without testing. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
On Sun, Aug 18, 2019 at 7:35 PM Eric S. Raymond wrote: > Sanjeev Gupta via devel : > > I have a feeling that was also removed, at some time. Has it? > > I do not recall that we explicitly removed it. But I wouldn't count on > it to work without testing. > The "Broadcast" item in ntpd/ntp_parser.yy was removed in 3703251c18d4dfd4c1b5c334875d4f7392d4789a Placing a "broadcast" line, as described in NTP Classic, generates an error: 2019-08-18T21:07:20 ntpd[12697]: CONFIG: readconfig: parsing file: /etc/ntp.conf 2019-08-18T21:07:20 ntpd[12697]: CONFIG: line 57 column 0 syntax error, unexpected T_String, expecting $end 2019-08-18T21:07:20 ntpd[12697]: CONFIG: syntax error in /etc/ntp.conf line 57, column 0 The documentation is inconsistent. There is some mention of broadcast and multicast, but the description of how to turn it on has been removed (which is why I had to consult NTP Classic documentation). Since the code, as of now, has no way to turn on broadcast _server_,and we have documented removal or broadcast _client_ , can I assume this is final? If yes, I will go through the docs, tidying them up. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
Sanjeev Gupta : > On Sun, Aug 18, 2019 at 7:35 PM Eric S. Raymond wrote: > > > Sanjeev Gupta via devel : > > > I have a feeling that was also removed, at some time. Has it? > > > > I do not recall that we explicitly removed it. But I wouldn't count on > > it to work without testing. > > > > > The "Broadcast" item in ntpd/ntp_parser.yy was removed in > 3703251c18d4dfd4c1b5c334875d4f7392d4789a > > Placing a "broadcast" line, as described in NTP Classic, generates an error: > > 2019-08-18T21:07:20 ntpd[12697]: CONFIG: readconfig: parsing file: > /etc/ntp.conf > 2019-08-18T21:07:20 ntpd[12697]: CONFIG: line 57 column 0 syntax error, > unexpected T_String, expecting $end > 2019-08-18T21:07:20 ntpd[12697]: CONFIG: syntax error in /etc/ntp.conf line > 57, column 0 > > > > The documentation is inconsistent. There is some mention of broadcast and > multicast, but the description of how to turn it on has been removed (which > is why I had to consult NTP Classic documentation). > > Since the code, as of now, has no way to turn on broadcast _server_,and we > have documented removal or broadcast _client_ , can I assume this is > final? If yes, I will go through the docs, tidying them up. Go ahead. Whatever broadcast code was left is pretty much a vermiform appendix, anyway. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
e...@thyrsus.com said: > Go ahead. Whatever broadcast code was left is pretty much a vermiform > appendix, anyway. The only leftovers that I know about are packet types. They may be used by ntpq. I remember a comment about there being no way to do broadcast securely. It would be good to include an expanded version of that in the documentation. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
Hal Murray : > I remember a comment about there being no way to do broadcast securely. It > would be good to include an expanded version of that in the documentation. That's covered. In the page on NTPsec changes: * Broadcast- and multicast modes, which are impossible to secure, have been removed. I'm pretty religious about keeping that page uodated. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
e...@thyrsus.com said: > That's covered. In the page on NTPsec changes: > * Broadcast- and multicast modes, which are impossible to > secure, have been removed. I was looking for more information. Why can't we secure it? What's wrong with using a public/private key to sign each broadcast packet? (It's hard to prove a negative like "impossible to secure", but maybe security geeks know things that I don't.) --- I'm not sad to see broadcast modes gone. It was tangled up with a state machine which I never really understood. In general, broadcasting is evil. That's another reason to drop it. But there might be good reasons to use it. Maybe simplifying the config file for some deployment applications? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
On Sun, Aug 18, 2019 at 5:27 PM Hal Murray via devel wrote: > > e...@thyrsus.com said: > > That's covered. In the page on NTPsec changes: > > * Broadcast- and multicast modes, which are impossible to > > secure, have been removed. > > I was looking for more information. Why can't we secure it? > > What's wrong with using a public/private key to sign each broadcast packet? > > (It's hard to prove a negative like "impossible to secure", but maybe > security > geeks know things that I don't.) > > --- > > I'm not sad to see broadcast modes gone. It was tangled up with a state > machine which I never really understood. > > In general, broadcasting is evil. That's another reason to drop it. > > But there might be good reasons to use it. Maybe simplifying the config > file for some deployment applications? > Assuming a can opener, If the packets were signed with a private key it might reasonably be possible to verify that signature with the *known* associated public key. However, there is not reasonable protection against delayed or replayed packets. OTOH broadcast NTP service solicitations should reasonably be securable via NTS if the FQDN is returned in addition to the network address. However, in such an instance it might be easier/better to use the pool directive with a multicast DNS SRV resolver. All of this is shallow thinking and I am sure I missed much. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
>> What's wrong with using a public/private key to sign each broadcast packet? > However, there is not reasonable protection against delayed or replayed > packets. Thanks. That's what I was looking for. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
Hal Murray : > > e...@thyrsus.com said: > > That's covered. In the page on NTPsec changes: > > * Broadcast- and multicast modes, which are impossible to > > secure, have been removed. > > I was looking for more information. Why can't we secure it? Daniel explained it to me once, but I've forgotten the details. Perhaps he'll speak up. > I'm not sad to see broadcast modes gone. It was tangled up with a state > machine which I never really understood. And may no longer exist since Daniel's massive refactor of the protcol engine! -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does broadcast *server* mode still exist?
>> I was looking for more information. Why can't we secure it? > Daniel explained it to me once, but I've forgotten the details. Perhaps he'll > speak up. The delay/replay problem is fatal, at least with a simple public key system like I proposed. There is probably something like a FAQ entry that explains that if you want to get time relevant data from A to B, you have to start by sending something from B to A, a nonce if nothing else. You could eliminate duplicates by having the sender include a sequence number. You would have to add a dance to get started. I don't see how to protect against delays without sending something from B to A -- or knowing the time. >> I'm not sad to see broadcast modes gone. It was tangled up with a >> state machine which I never really understood. > And may no longer exist since Daniel's massive refactor of the protcol > engine! I removed the state machine after we had removed enough stuff (like broadcast and peers) so that the remaining cases were simple enough to understand. That was a while ago. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
