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
due to parsing the TCP header, splitting fields, pulling in external
descriptions, etc.  Looking beyond the headers is far less structured,
because applications do the structuring on their own, which in turn
makes external descriptions hard to, er, describe -- hence the hard-
wired C approach.  The only "complexity" is the growing amount of
application descriptions, but each application function is completely
isolated.

Here's the DPI hook function (a bit simplified for the context of this
discussion):

li_get(const struct li_packet *packet, const struct li_flow *flow)
{
        unsigned int i;

        if (!packet->app_len) {
                return (LI_UNKNOWN);
        }

        for (i = 0; i < lengthof(apps); ++i) {
                if ((apps[i].p1 == flow->type) ||
                    (apps[i].p2 == flow->type)) {
                        if (apps[i].function(packet, flow)) {
                                return (apps[i].number);
                        }
                }
        }

        /*
         * Set 'undefined' right away. Only one chance for
         * each side of the flow. This makes it easier for
         * a rules engine to do negation of policies.
         */
        return (LI_UNDEFINED);
}

apps is an array of all of the available application functions. It looks
something like this:

static const struct li_apps apps[] = {
        LI_LIST_APP(LI_PPTP, pptp, IPPROTO_TCP, IPPROTO_GRE),
        LI_LIST_APP(LI_HTTP, http, IPPROTO_TCP, IPPROTO_MAX),
        /* more stuff here */
};

Really, that's all there is to it.

> So another example might be: "pass proto tcp app $someapp divert-packet
> $someproxy", with $someproxy handling the second stage?

Yes, that looks reasonable.  "proto tcp" may be zapped as well.
If we are talking use cases the biggest ones would be traffic shaping
and policy enforcement in general (no SMTP to the outside, blocking
non-TLS stuff on port 443, etc.)

> Yes, this is clearly a less messy approaach than opendpi ;)

I probably shouldn't say I worked for these guys a few years ago.
Nobody would believe me I never touched the DPI code, but it's the
truth!


Franco

Reply via email to