Re: DPI for pf(4)

2013-06-10 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
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

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
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 *

Re: DPI for pf(4)

2013-05-02 Thread Stuart Henderson
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

Re: DPI for pf(4)

2013-05-02 Thread Alexandre Ratchov
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

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
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

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
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

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-02 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-02 Thread Otto Moerbeek
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

Re: DPI for pf(4)

2013-05-02 Thread Damien Miller
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

Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-05-01 Thread Stuart Henderson
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

Re: DPI for pf(4)

2013-05-01 Thread Jiri B
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

Re: DPI for pf(4)

2013-05-01 Thread Franco Fichtner
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

Re: DPI for pf(4)

2013-04-30 Thread Alexey E. Suslikov
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

Re: DPI for pf(4)

2013-04-30 Thread Stuart Henderson
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

Re: DPI for pf(4)

2013-04-30 Thread Ted Unangst
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