Re: Question regarding match function

[Patrick Tullmann <tullmann@cs.utah.edu>]

Hi Graham,

You've pretty much nailed all the issues we've thought of in regards
to the match function.  The big sticking point is variable length
headers.

In the NodeOS spec[1] the match function is provided as a sequence of
<offset,length,bytes,mask> tuples.  This is satisfactory if the packet
header is a collection of fixed fields.  Its probably also sufficient
if the variable length headers are well known, and can be specified
through magic.  (E.g., if I say "after the UDP header" somehow).

Taking this to the next level allows the AA developer to specify more
complex match functions in a language (e.g., existing packet filter
languages like BPF, DPF, etc).  Some of these language allow skipping
a variable number of bytes in a header.

In the active network we have additional flexibilty.  We can separate
what part of the demultiplex function is done "in the kernel" and what
part is done in the application.  For example, I can imagine an EE
that lets its AAs provide both an <offset,length,bytes,mask> field and
an arbitrary function against which packets are matched.  The EE would
just install the tuple in the "in-kernel" packet check and then run
the function in the AA's context to further classify the packet.  If
the EE trusts the AA (or can verify its function is safe) then the EE
could inline the function in the in-kernel packet check.

For now, though, the DemultiplexKey should probably be updated to
match the facilities provided by the NodeOS specification.  The NodeOS
spec has simple interfaces that implicitly skip well-known
variable-length headers (e.g, IPv4, UDP, TCP).  Eventually, we hope to 
push a more flexible scheme for packet matching into the NodeOS spec,
but we haven't worked out any details at this point.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann@cs.utah.edu

[1] http://www.cs.princeton.edu/nsg/papers/nodeos.ps