L7-filter Supported Protocols

Below is the list of supported protocols. Note that most of the
protocols are listed as needing more testing. We need your help (yes,
you!) to do this. Simply reporting on how patterns are
working for you is helpful. The easiest way to do this is to follow the
links by patterns you use. On the wiki, post your results in the
l7-filter section of each page. You can also post to
l7-filter-developers(@)lists(.)sf(.)net (you mustsubscribe
first).

Key to symbols

Quality

The "quality" gives a rough idea of how well the pattern works. This
is a conglomerate measure of several things, including (1) how well the
protocol is understood (2) how much the pattern has been tested (3) in
what variety of situations the pattern has been tested and (4) what
fraction of identifiable traffic is identified correctly.
For details, read the pattern file or the protocol's wiki entry.

Great: Works.

Good: Works as far as we know.

Ok: Probably works.

Marginal: Might work, might not.

Poor: Probably doesn't work.

Speed

The protocol package includes a tool for testing pattern performance.
It tests them against 122 samples of actual network data (as of the
2009-05-19 release) 100,000 times each. The following times are for a
2 GHz Opteron.

The first speed shown for a pattern in the tables below is the speed
when used in the kernel (with the old V8 regular expression library). The second is the speed when
used in userspace (with the modern GNU library). Note that the userspace version has a smaller
spread of speeds. That is, its slowest patterns are faster and its
fastest patterns are slower than the kernel version.

Very fast: 0.8–3 seconds.

Fast: 3–10 seconds.

Not so fast: 10–100 seconds.

Slow: >100 seconds (worst as of this writing was 1750s for the kernel library
and 100s for the userspace library).

Other notes

Overmatching pattern: It is either hard or impossible to write a pattern for this protocol
that reliably matches only the intended protocol. In other words, use of this pattern is likely to yield false positives, so you should probably only use it in conjunction
with other matches, such as port or IP number. See the comments in the pattern file and/or wiki for specifics.

Undermatching pattern: It is either hard or impossible to write a pattern for this
protocol that matches all connections. For example, in a P2P protocol, it may only be able to match search requests, but not file
transfers in. (However, P2P protocol patterns are not considered to undermatch as long as they match downloads.) See the comments in the pattern file and/or wiki for
specifics.

Superset: This pattern matches traffic which is a superset of the traffic that some other
patterns match. If it is ahead of one of these patterns in your iptables rules, the other patterns will never match. See the pattern file for which other patterns are
involved.

Subset: This pattern matches traffic which is a subset of the traffic matched by some other
pattern.

Groups

Protocols are marked as being in one or more "groups". Some groups
refer to what sort of purpose each protocol has. These allow front-ends
to treat a set of protocols in the same way without requiring the user
to select (or know about) each individual protocol. For instance, an
application could have a checkbox for "VoIP" rather than one for Skype,
one for H.323, etc..

Other groups indicate whether a protocol is documented in an IETFRFC, whether it is standardized by any official
body, a non-standard but used primarily by open source programs, or
proprietary. Among other things, this is supposed to give some idea of
how volatile these protocols are likely to be. IETF standards are
highly unlikely to change behavior and break l7-filter's patterns
suddenly. (Although if programs misimplement them, anything can
happen.) Open source non-standardized protocols are somewhat more likely
to change abruptly, but changes are likely to be publically documented
and, of course, the source code can be read to learn about them as a
last resort. Proprietary protocols can change at any time without
warning. The nature of the changes may be a closely kept secret.

Not all groups that exist in the pattern files have icons shown on
this page. Also, just because a protocol is not listed as being in a
group does not mean that it is specifically excluded from that group.
For instance, not every protocol without "secure" is insecure. We
invite you to make the groups more complete by sending
corrections/additions to our mailing list.

P2P

VoIP

Streaming video

Streaming audio

Chat

Game

Document retrieval

Networking

Mail

File

Printer

Remote access

Time synchronization

Version control

Monitoring

Secure

Obsolete

IETF proposed standard

IETF draft standard

IETF standard

Non-standards track RFC'd

Other standard

Open source

Proprietary

Protocols

The pattern name is what you must use when issuing l7-filter
commands. The names below link to the pattern files. Select column
headings to sort.

Malware

This category is for worms, viruses, and anything else that uses the
network to bother us. It doesn't appear that there is much demand for
this functionality, but in case it interests you, this is a
proof-of-concept. Malware
README.