Hi all,
adhering to the basic rule of not reinventing the wheel has sort of
crippled the efforts to come up with an elegant solution for the
topic at hand. Two approaches have been proposed earlier, so let's
go through them:
(1) Diverting traffic to userspace
That's generally a good idea, but d
On Thu, 2 May 2013, Damien Miller wrote:
> You've just described bpf, right down to "no endless loops" and the amount
> of data it returns.
>
> For a little more code that it takes to write one packet parser
> (basically: loading bpf rules from pf and making the bpf_filter()'s
> return value avai
fOn Thu, May 02, 2013 at 04:03:05PM +0200, Franco Fichtner wrote:
> On May 2, 2013, at 3:20 PM, Damien Miller wrote:
>
> > On Thu, 2 May 2013, Franco Fichtner wrote:
> >
> >> OK, the implementation only pulls a couple of bytes from the packet's
> >> payload. It will never pull bytes that are no
On May 2, 2013, at 3:20 PM, Damien Miller wrote:
> On Thu, 2 May 2013, Franco Fichtner wrote:
>
>> OK, the implementation only pulls a couple of bytes from the packet's
>> payload. It will never pull bytes that are not verified. It will never
>> allocate anything. It will never test against some
On May 2, 2013, at 2:40 PM, Damien Miller wrote:
> On Thu, 2 May 2013, Franco Fichtner wrote:
>
>> Moving implementations to user space does not necessarily make them
>> better or less of a problem.
>
> The big difference is that its possible to sandbox a userspace
> implementation so that smal
On Thu, 2 May 2013, Franco Fichtner wrote:
> OK, the implementation only pulls a couple of bytes from the packet's
> payload. It will never pull bytes that are not verified. It will never
> allocate anything. It will never test against something that's neither
> hard-coded nor available in the ran
On Thu, 2 May 2013, Franco Fichtner wrote:
> Moving implementations to user space does not necessarily make them
> better or less of a problem.
The big difference is that its possible to sandbox a userspace
implementation so that small integer overflow bugs or length checking
failures don't becom
On May 2, 2013, at 1:23 PM, Damien Miller wrote:
> On Thu, 2 May 2013, Franco Fichtner wrote:
>
>>> Well, bare minimum complexity per-protocol * large_number_of_protocols =
>>> a lot of complexity. The incentive is always going to be to add more
>>> protocols and never retire them.
>>
>> I gues
On Thu, 2 May 2013, Franco Fichtner wrote:
> > Well, bare minimum complexity per-protocol * large_number_of_protocols =
> > a lot of complexity. The incentive is always going to be to add more
> > protocols and never retire them.
>
> I guess that's true for most software projects.
We try not to
On May 2, 2013, at 10:45 AM, Damien Miller wrote:
> On Thu, 2 May 2013, Franco Fichtner wrote:
>
>> as stated before, breaking down complexity to the bare minimum is my
>> requirement for this to be happening at all. You all get to be the
>> judges. I'm just trying to work on something worth d
On Thu, May 02, 2013 at 10:35:19AM +0200, Franco Fichtner wrote:
>
> as stated before, breaking down complexity to the bare minimum is my
> requirement for this to be happening at all. You all get to be the
> judges. I'm just trying to work on something worth doing.
>
> > The last thing we want
On 2013/05/02 18:03, Damien Miller wrote:
> > I find C to be quite flexible and empowering
> > if one doesn't overcomplicate[2].
> >
> > [2] https://github.com/fichtner/OpenDPI/blob/master/src/lib/protocols/ssl.c
>
> That's complicated and scary code for a kernel, e.g. multiple opportunities
> for
On Thu, 2 May 2013, Franco Fichtner wrote:
> as stated before, breaking down complexity to the bare minimum is my
> requirement for this to be happening at all. You all get to be the
> judges. I'm just trying to work on something worth doing.
Well, bare minimum complexity per-protocol * large_n
Hi Damien,
On May 2, 2013, at 10:03 AM, Damien Miller wrote:
> On Wed, 1 May 2013, Franco Fichtner wrote:
>
>> Not sure if that's a fitting comparison; and I know too little OSPF
>> to answer. Let me try another route. The logic consists of an array
>> of application detection functions, whic
On Wed, 1 May 2013, Franco Fichtner wrote:
> Not sure if that's a fitting comparison; and I know too little OSPF
> to answer. Let me try another route. The logic consists of an array
> of application detection functions, which can be invoked via their
> respective IP types.
I don't like this ap
On May 1, 2013, at 9:41 AM, Stuart Henderson wrote:
> I should have expanded the acronum to make it clear - osfp i.e. the
> OS fingerprinting code (pf_osfp.c).
oh, sorry, my mistake. This I can comment on. :)
The idea is the same. I'd say at this stage osfp has more complexity
due to parsing
On Tue, Apr 30, 2013 at 07:14:50PM -0400, Ted Unangst wrote:
> On Wed, May 01, 2013 at 00:16, Franco Fichtner wrote:
> > Yes, I am proposing a lightweight approach: hard-wired regex-like
> > code, no allocations, no reassembly or state machines. I've seen
> > far worse things being put into Kernel
On 2013/05/01 09:01, Franco Fichtner wrote:
> Hi Stuart,
>
> On May 1, 2013, at 1:11 AM, Stuart Henderson wrote:
>
> > On 2013/05/01 00:16, Franco Fichtner wrote:
> >>
> >> Yes, I am proposing a lightweight approach: hard-wired regex-like
> >> code, no allocations, no reassembly or state machin
Hi Ted,
On May 1, 2013, at 1:14 AM, Ted Unangst wrote:
> On Wed, May 01, 2013 at 00:16, Franco Fichtner wrote:
>> Yes, I am proposing a lightweight approach: hard-wired regex-like
>> code, no allocations, no reassembly or state machines. I've seen
>> far worse things being put into Kernels and
Hi Stuart,
On May 1, 2013, at 1:11 AM, Stuart Henderson wrote:
> On 2013/05/01 00:16, Franco Fichtner wrote:
>>
>> Yes, I am proposing a lightweight approach: hard-wired regex-like
>> code, no allocations, no reassembly or state machines. I've seen
>> far worse things being put into Kernels an
On Wed, May 01, 2013 at 00:16, Franco Fichtner wrote:
> Yes, I am proposing a lightweight approach: hard-wired regex-like
> code, no allocations, no reassembly or state machines. I've seen
> far worse things being put into Kernels and I assure you that I do
> refrain from putting in anything that
On 2013/05/01 00:16, Franco Fichtner wrote:
> Hi Alexey,
>
> On Apr 30, 2013, at 11:51 PM, "Alexey E. Suslikov"
> wrote:
>
> > Franco Fichtner gmail.com> writes:
> >
> >> so I have been working on a BSD licensed DPI engine. It's a
> >> very lightweight, non-intrusive approach and I know that
Hi Alexey,
On Apr 30, 2013, at 11:51 PM, "Alexey E. Suslikov"
wrote:
> Franco Fichtner gmail.com> writes:
>
>> so I have been working on a BSD licensed DPI engine. It's a
>> very lightweight, non-intrusive approach and I know that teasers
>> are boring, but I'd like to know if it's worth the
Franco Fichtner gmail.com> writes:
> so I have been working on a BSD licensed DPI engine. It's a
> very lightweight, non-intrusive approach and I know that teasers
> are boring, but I'd like to know if it's worth the time to
> work on inclusion for pf(4). So far I have about 25 supported
> appl
Hi misc@,
so I have been working on a BSD licensed DPI engine. It's a
very lightweight, non-intrusive approach and I know that teasers
are boring, but I'd like to know if it's worth the time to
work on inclusion for pf(4). So far I have about 25 supported
applications and the necessary hooks for
25 matches
Mail list logo