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
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
Hi Damien,
On May 2, 2013, at 10:03 AM, Damien Miller d...@mindrot.org 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
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 *
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 unsigned
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 it a
On May 2, 2013, at 10:45 AM, Damien Miller d...@mindrot.org 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
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 1:23 PM, Damien Miller d...@mindrot.org 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
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 become
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 range
On May 2, 2013, at 2:40 PM, Damien Miller d...@mindrot.org 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
On May 2, 2013, at 3:20 PM, Damien Miller d...@mindrot.org 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
fOn Thu, May 02, 2013 at 04:03:05PM +0200, Franco Fichtner wrote:
On May 2, 2013, at 3:20 PM, Damien Miller d...@mindrot.org 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
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 available
Hi Stuart,
On May 1, 2013, at 1:11 AM, Stuart Henderson st...@openbsd.org 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
Hi Ted,
On May 1, 2013, at 1:14 AM, Ted Unangst t...@tedunangst.com 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
On 2013/05/01 09:01, Franco Fichtner wrote:
Hi Stuart,
On May 1, 2013, at 1:11 AM, Stuart Henderson st...@openbsd.org 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
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 Kernels and
On May 1, 2013, at 9:41 AM, Stuart Henderson st...@openbsd.org 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
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
Franco Fichtner slashy83 at 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
On 2013/05/01 00:16, Franco Fichtner wrote:
Hi Alexey,
On Apr 30, 2013, at 11:51 PM, Alexey E. Suslikov
alexey.susli...@gmail.com wrote:
Franco Fichtner slashy83 at gmail.com writes:
so I have been working on a BSD licensed DPI engine. It's a
very lightweight, non-intrusive
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
24 matches
Mail list logo
