[Oisf-devel] RFC: Yaml conf structure for enabling/disabling protocol parsers

Christian Kreibich christian at lastline.com
Sun Dec 29 10:59:38 UTC 2013


Hey guys,

On 12/17/2013 02:32 AM, Anoop Saldanha wrote:
> If you have something different on your mind, please go ahead and
> introduce it, and we can deliberate on adding it to the list as well.

A few comments:

- When specifying protocol application statically, you want to provide a
way to specify multiple possible ports and ideally also primitives on
the ports (e.g., negation). Similarly, you may want to allow for future
non-port constraints, such as enabling a parser only for flows (not)
to/from certain subnets. You can express each (conjunctive) set of
constraints in a (disjunctive) list of sequence items.

- You could combine TCP vs UDP info with port numbers as a type notion,
Bro style, so you don't need an extra level of hierarchy. Easy enough to
parse.

So, HTTP with dynamic detection everywhere and DNS statically configured
on two responder ports, one UDP, one TCP, might look like this:

app-layer:
  protocols:
    http:
      - resp_ports: dynamic
    dns:
      - resp_ports: [ 53/udp, 53/tcp ]

You could then add future constraints to a sequence item's mapping,
perhaps resp_nets for responder subnets:

    http:
      - resp_ports: [ 80/tcp ]
        resp_nets:  [ 192.168.1.1/32 ]
      - resp_ports: [ 8080/tcp ]
        resp_nets:  [ 192.168.1.2/32 ]

Also, you'll want to allow for multiple of those app-layer config trees
so you don't lose the ability to configure different protocols in
different YAML files.

Hth,
-C.



More information about the Oisf-devel mailing list