Не. Я тебя сначала понял так, что ключом для flow является не 5-tuple, а что-то больше,

разумеется, теоретически может больше, но мне сейчас ни одного протокола в голову не приходит.
а, нет, пришло.
фильтрация внутри GRE. не того, GRE, который у нас на tun принимается, а транзитного.
вот тут да -- 5 тупле в пролете. и не на 5 тупле ориентироваться, мне кажется можно вообще не завязываться напрямую на IP.

например, в рамках одного tcp-соединения по итогам разбора могут быть несколько flow созданы. Чему и удивился. Но всё-таки ты предлагаешь тот же самый обычный трекинг (FTP DATA, IRC DCC, PPTP GRE, SIP и др.), который везде есть, просто под оригинальным соусом.

я предлагаю фрэймворк. т.е. когда действительно то, что получится может никак не быть предусмотренно проектировщиком файрвола.

Я понял, это лучше называть алгоритмической оптимизацией. Конкретно про регэкспы - чисто имплементации регэкспов в ядро портировать напряжно, ну смотря что от них нужно, конечно - существуют достаточно простые реализации регэкспов, причем без непредсказуемых задержек скорости, за счет того, что в них backreferences (\1, \2) нельзя.

нет, алгоритмическая -- плохое слово. алгоритм не оптимизируется, он относительно стандартный. паралельное -- тоже плохое слово, согласен. backreferences пожалуй не нужен. вот что точно нужно -- эффективное определение какая альтернатива сработала (в pcre после срабатывания (GET|PUT|POST) надо еще отдельный анализ устраивать кто из трех сработал. ну и аналогично, если мы пять правил в одно через "или" объеденили -- как узнать какое сработало? в pcre неудобно.

Что касается BPF - он здесь упоминался как идея, а не как реальный bpf, ессно. Что транслируется в нечто, что потом сравнительно простой виртуальной машиной в ядре и исполняется.

я понял, но смысл именно в том, что не было исполнения виртуальной машиной. т.е. что бы делалось одно-несколько деревьев по которым делался бы анализ. да, потом, некторые операции будут выполняться, в этом смысле наверное виртуальная машина и bpf. но в этом смысле и ipfw сейчас -- bpf.

То, что ты описываешь, называется nftables, см. http://www.opennet.ru/opennews/art.shtml?num=20843 - и это как раз подход, взятый из BPF и такой, как ты описываешь, то есть там просто в итоге в ядре операции над байтами пакета по смещениям, как и в BPF. Только вот сдохла эта разработка =)

нет, по крайне мере не совсем. я предлагаю на псевдоязыке описывать только протокол. а правила фильтрации -- боле-менее обычным образом, но описание на псевдоязыке дают возможность в правилах фильтрации использовать параметры описанных протоколов.

Проблема с этим подходом (если забыть про проблемы декомпиляции) - ядром выполняется интерпретация, а интерпретация - это накладно. Чем больше и крупнее операции, написанные на чистом Си, тем эти куски быстрее работают - поэтому в BPF-подобном ipfw2 и применяются сравнительно "крупные" операции над пакетом, типа "проверить src по radix-таблице".

не понимаю, какая декомпиляция. и мне не видно чего бы тут "операции" были сущестенно мельче.

Я пока что собирался делать а-ля conntrack в линуксах, то есть набор хуков и функций фреймворка - если это сильно криво, то почему у них есть столько модулей, а вот ихний же nftables таки загнулся? ;)

потому что выживает всегда самое кривое! вот хоть архитектуру PC взять. да кто их знает, не понравились мантэйнеру дистрибутива, не получили юзербазы и потеряли интерфейс. или слишком сложное сделали. или синтаксис правил фильтрации неудобный получился.

А ты сможешь такое декларативное описание набросать на псевдокоде? А то для меня пока что это всё выглядит как сказочный лес, нечто зыбкое и туманное.

попробую. в воскресенье на поезде ехать -- как раз буду бумагу чирикать. это, вероятно, будет чем-то похоже на описание MIBов