> I gather it's been a while since you did anything with raw IP. What you want
> is sendto(2)/sendmsg(2). It's dead easy with those.
Yes. I think most of my work was with connected sockets.
I poked around a bit and haven't figured out how to use it, but it feels like
it should work. Other
The discussion of how to do SINGLESOCKET has become rather splintered.
This is an attempt to pull it back together by presenting different
scenarios about how to do it.
In all scenarios, the per-interface sockets go away; all UDP listening
is done on what is now the wildcard socket.
Case ALPHA:
Hal Murray :
> Can we get the dest address on receive without a separate socket per IP
> Address? recvfrom() gives us the source address. I don't see how to get the
> dest address, but I haven't looked very hard.
Here's the hook:
IP_PKTINFO (since Linux 2.2)
Pass an
Ian Bruene :
> > Are you up for trying? "No" is an acceptable answer - I'm not certain
> > you're ready for this myself.
>
> Yes, though I can't guarantee I won't be screaming for help at 10%
> completion. Also it won't start till after SELF as this does not need to be
> happening right before a
devel@ntpsec.org said:
> Assuming we drop interface-name filtering, everything but the wildcard
> socket is going to go away. I think this will make tracking routing
> unecessary. I hope so, anyway. That code is a mess and I want to nuke it.
We don't track routing in the sense of BGP. We do
On 05/29/2018 03:54 PM, Eric S. Raymond wrote:
Ian Bruene via devel :
I've skimmed through some of the code associated with these features during
deglobalization. It /needs/ to be cleaned up one way or another. Cleaning it
with a scythe is all the better.
Hmmm. You may have talked yourself
Yo Eric!
On Tue, 29 May 2018 17:02:47 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Yo Eric!
> >
> > On Tue, 29 May 2018 16:17:36 -0400
> > "Eric S. Raymond" wrote:
> >
> > > Please either choose one drop/no-drop or explain why these cases
> > > should be treated
Gary E. Miller via devel :
> Yo Eric!
>
> On Tue, 29 May 2018 16:17:36 -0400
> "Eric S. Raymond" wrote:
>
> > Please either choose one drop/no-drop or explain why these cases
> > should be treated separately.
>
> If that is the choice, the choice should be no-drop.
Well, then, we're back to
Ian Bruene via devel :
> I've skimmed through some of the code associated with these features during
> deglobalization. It /needs/ to be cleaned up one way or another. Cleaning it
> with a scythe is all the better.
Hmmm. You may have talked yourself into a job, apprentice. Because you
are
Yo Eric!
On Tue, 29 May 2018 16:17:36 -0400
"Eric S. Raymond" wrote:
> Please either choose one drop/no-drop or explain why these cases
> should be treated separately.
If that is the choice, the choice should be no-drop.
A ton of ntpd installations were setup a long time ago, and unlikely an
Yo Richard!
On Tue, 29 May 2018 15:33:16 -0500
Richard Laager via devel wrote:
> On 05/29/2018 03:32 PM, Jason Azze via devel wrote:
> > I'd be pretty pissed off if, let's say, the Postfix or MySQL people
> > took this attitude. That's why I think I'm misunderstanding.
>
> FWIW, I agree.
Yo Eric!
On Tue, 29 May 2018 16:06:56 -0400
"Eric S. Raymond via devel" wrote:
> Hal Murray via devel :
> >
> > There are command line options as well as ntp.conf:
> >-I Str interface Listen on an interface name or address
> > - may appear multiple
On 05/29/2018 03:32 PM, Jason Azze via devel wrote:
> I'd be pretty pissed off if, let's say, the Postfix or MySQL people took this
> attitude. That's why I think I'm misunderstanding.
FWIW, I agree. It's perfectly reasonable to list the interfaces to
listen() or bind() to or whatever the call
On Tue, May 29, 2018, at 4:28 PM, Richard Laager via devel wrote:
> Choosing _which_ interfaces to listen() on at all is not userspace
> packet filtering.
This is my instinct as well. I suspect I don't understand what we're talking
about, so I am hesitant to comment.
Are you suggesting
On 05/29/2018 03:17 PM, Eric S. Raymond via devel wrote:
> The point of *this* part of the discussion is that if we accept Mark's
> security rationale (which I don't disagree with) then *every* form of
> userspace packet filtering NTP does is a defect and should be flushed.
Choosing _which_
> -I would definitely dropped. I don't comprehend "virtual interfaces". so I
> don't know if that should survive.
I've never used them, so be somewhat suspicious.
I'm pretty sure they are just what they sound like. If your eth0 is 1.2.3.4,
you can add another logical interface sharing the
Hal Murray :
>
> k...@roeckx.be said:
> > Do we only have 1/2 socket by default, or do we still have a listen socket
> > per interface / ip address?
>
> The current code has a socket per interface and a wildcard socket.
>
> It also has another pile of (ugly) code to watch the interfaces and
Hal Murray via devel writes:
> devel@ntpsec.org said:
>> Provided you somehow route the packets from different networks to different
>> (virtual) interfaces, you could measure and eventually compensate the
>> asymmetry associated with that particular network provided you have some
>> trusted time
Gary E. Miller via devel :
> > This opens a can of worms, though. Should we drop the entire
> > interface command?
>
> Yes, after years of deprecation. At least to start we want to be drop=in
> replacement for NTP Classic.
I think you're now trying to have things both ways. If we drop
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Achim Gratz via devel :
> >> However, there is still value in the knowledge of which interface the
> >> packet came in so that ntpd can place different levels of trust
> >> depending on whether it's from a private (virtual) network
Hal Murray via devel :
>
> There are command line options as well as ntp.conf:
>-I Str interface Listen on an interface name or address
> - may appear multiple times
>-L no novirtualips Do not listen to virtual interfaces
-I would definitely
Hal Murray via devel :
>
> > We could kill the interface command, and let the usual syntax error happen.
> > Or we could raise a special syntax error, calling out the need to use the
> > packet filter instead. Then the question becomes, is it a
> > warn-and-continue,
> > or a error-and-halt?
devel@ntpsec.org said:
> Provided you somehow route the packets from different networks to different
> (virtual) interfaces, you could measure and eventually compensate the
> asymmetry associated with that particular network provided you have some
> trusted time server on each side of the
k...@roeckx.be said:
> Do we only have 1/2 socket by default, or do we still have a listen socket
> per interface / ip address?
The current code has a socket per interface and a wildcard socket.
It also has another pile of (ugly) code to watch the interfaces and create a
new socket when an
Eric S. Raymond via devel writes:
> Achim Gratz via devel :
>> However, there is still value in the knowledge of which interface the
>> packet came in so that ntpd can place different levels of trust
>> depending on whether it's from a private (virtual) network segement, an
>> internal or public
On Tue, May 29, 2018 at 03:15:15PM -0400, Eric S. Raymond via devel wrote:
> [[interface]]
> +interface+ [+listen+ | +ignore+ | +drop+] [+all+ | +ipv4+ | +ipv6+ |
> +wildcard+ | 'name' | 'address'[/'prefixlen']]::
> This command controls which network addresses +ntpd+ opens, and
> whether
> We could kill the interface command, and let the usual syntax error happen.
> Or we could raise a special syntax error, calling out the need to use the
> packet filter instead. Then the question becomes, is it a warn-and-continue,
> or a error-and-halt?
Error and halt. (or set a flag to
Yo Eric!
On Tue, 29 May 2018 15:15:15 -0400
"Eric S. Raymond via devel" wrote:
> I could summarize it something like this:
>
> "We have removed packet filtering by interface name because we judge
> it's a security-defect attractor. The place to do this is in
> kernel-level packet filters and
We could kill the interface command, and let the usual syntax error happen.
Or we could raise a special syntax error, calling out the need to use the
packet filter instead. Then the question becomes, is it a
warn-and-continue, or a error-and-halt?
..m
On Tue, May 29, 2018 at 12:17 PM Eric S.
On 05/29/2018 02:15 PM, Eric S. Raymond via devel wrote:
I'm inclined to think dropping this would be a good thing. There's a
lot of code complexity behind that, and that bit abour interface
commands being inoperative if you choose the wrong command-line option
raises my shoot-self-in-foot
On Tue, May 29, 2018 at 11:15 AM Achim Gratz via devel
wrote:
> However, there is still value in the knowledge of which interface the
> packet came in so that ntpd can place different levels of trust
> depending on whether it's from a private (virtual) network segement, an
> internal or public
Achim Gratz via devel :
> However, there is still value in the knowledge of which interface the
> packet came in so that ntpd can place different levels of trust
> depending on whether it's from a private (virtual) network segement, an
> internal or public network.
If I'm following the argument,
Hal Murray :
> My reading of Eric's concerns is that he doesn't want to remove a feature
> that somebody is (or might be) using.
That is currect. But we've already removed stuff people might be using
for infosec reasons; I get much less worried if we have that story.
--
Mark Atwood, Project Manager :
> There are a couple of different but very similar angles of approach to
> explain why a network security experts will not trust a userspace daemon to
> control it's own defensive packet filtering.
>
> The UNIX concept: each tool should do one thing, and do it well.
Achim Gratz said:
> However, there is still value in the knowledge of which interface the packet
> came in so that ntpd can place different levels of trust depending on
> whether it's from a private (virtual) network segement, an internal or
> public network. Also, this information would
Mark Atwood via devel writes:
> No modern sysadmin or devops shop is going to use or trust an userspace
> packet filter built into the userspace daemon they are defending.
>
> Direct-internet-connected boxes are going to use the kernel packet policy
> filter, and drop the packet before it ever
Nice. Thanks.
mark.atw...@ntpsec.org said:
> There are a couple of different but very similar angles of approach to
> explain why a network security experts will not trust a userspace daemon to
> control it's own defensive packet filtering.
My reading of Eric's concerns is that he doesn't
There are a couple of different but very similar angles of approach to
explain why a network security experts will not trust a userspace daemon to
control it's own defensive packet filtering.
The UNIX concept: each tool should do one thing, and do it well. The ntpd
should no more do packet
Mark Atwood :
> No modern sysadmin or devops shop is going to use or trust an userspace
> packet filter built into the userspace daemon they are defending.
Hm. I am ignorant here. Why is this so?
> This is an ancient feature that is a fossil evidence that NTP was a known
> security tarpit
39 matches
Mail list logo
