Focusing on the single in SINGLESOCK...
That doesn't work in FreeBSD. (see my previous message about no IP_PKTINFO)
Is that fatal?
Even if we have a single socket, do we still need to track interface changes?
If so, should we be discussing how to clean up that code?
---
The interface
We can filter by IP Address using the restrict command. We may have to add a
new flag that says don't poke any holes in me.
Case ALPHA:
> Nothing visible changes. Packet filtering by interface name is still
> supported by using IP_PKTINFO to get the interface of incoming packets.
recvmsg()
> 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 peo
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 IP_PKT
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 t
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 i
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 separatel
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 sq
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 absolu
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
a
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. It'
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 times
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 i
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 remov
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_ interf
> -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 sam
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 cre
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 s
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 filterin
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 seg
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 dropped
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 asymmet
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 in
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 ne
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
--
These are my opinions. I hate spam.
_
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 inpu
> 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 ha
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 f
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. Ra
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 ala
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 ne
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, t
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.
--
http://w
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 potent
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 reac
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 wa
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 filte
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 preda
42 matches
Mail list logo
