[midcom] notification of work that may help

I've been glancing over the rfc3304.txt and
draft-ietf-midcom-protocol-eval-06.txt documents and thought you
probably should be aware of some existing work within the IETF that
may help you out (you'll likely need to build upon it, but you can use
it as a good starting point).  I haven't read either document cover to
cover, so forgive me if I say something out of line.

Much of these two documents discusses the need for required policy
rules for packet filtering.  There has been a lot of work in this area
within the ip-security-policy (ipsp) working group.  Specifically, I'm
one of the authors of the IPSEC-POLICY-MIB which is a document that
closely aligns with your work and you might consider looking at.  For
example, the following requirement:

   2.2.8.

      The Midcom protocol must be able to carry filtering rules,
      including but not limited to the 5-tuple, from the midcom agent
      to the middlebox.

      By "5-tuple", we refer to the standard <source address, source
      port, destination address, destination port, transport protocol>
      tuple.  Other filtering elements may be carried, as well.

and the associated comments about SNMP in the evaluation document:

    2.2.8 Transport of filtering rules
      SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+

      SNMP: This requirement can be met by an appropriate definition of a
      MIDCOM MIB module. SMI, the language used for defining MIB modules,
      is flexible enough to allow the implementation of a MIB module to
      meet the semantics of this requirement.

These are filled in part or in total by the IPSEC-POLICY-MIB.  (Don't
let the "IPSEC" in the name confuse you.  It's not IPSEC-specific).
The IPSEC-POLICY-MIB can be divided into 2 parts: a policy rules
section for processing packets using rules, filters, and actions.
The other 2/3rds of the MIB is devoted to IPsec specific actions
(start an SA, start an IKE transaction, ...).  There is a very
deliberate delineation between the packet processing portion of the
MIB and the IPsec specific actions.  Specifically, the packet
processing rules are really just a firewall configuration section
(there are standard actions for "drop packet" and "accept packet" as
well).  There are numerous filtering mechanisms in place within the
MIB, such as the ipHeaderFilterTable which directly meets the 2.2.8
requirement above and the timeFilterTable which may meet other of your
requirements.

The MIB is deliberately very extensible, and new filters and actions
can be defined in external documents so that if you wanted to base
your work on it's packet and rule processing system but needed some
extra filters, it would be easy to do so.

All of this work is in alignment with the policy models being
developed within the Policy Framework working group, the IPSP WG, and
the DMTF.  I mention this because it looks like you refer to parts of
these data models in your documents at times.

Finally, there is also a IPSEC-POLICY-PIB for COPS also being
published in the IPSP working group.  I don't know if it is extensible
and reusable as the MIB as I haven't given it a review lately.  We
designed the MIB to be a generic firewall configuration engine, but I
don't know if the PIB authors had the same goal.

There is also a working reference-release implementation for the MIB
on linux, as well as a manager that should run on just about any
platform.  See http://net-policy.sourceforge.net/ for details on that
particular project.

-- 
Wes Hardaker
Network Associates Laboratories
_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom