>From: lars @
COM (Lars Poulsen)
>Date: Sat, 5 Dec 92 07:34:57 GMT
>Subject: Re: packet filter metalanguage
>I think we have two competing factions here.
>(1) Wants to move the state of the art forward, and define a new way
> for kernel writers and router maufacturers to implement packet
> filters with an interpreted language, so that users can write their
> own filters in that new language.
>(2) Wants to share what criteria their router/kernel/whatever is capable
> of specifying, in the hope that increased user awareness of what is
> available wil move the common denominator upwards.
>My personal feeling is that we would get a lot further for the immediate
>future, if we all shared our ideas for data structures for a standard
>filtering function, so that we could all move up to a common baseline
>near the top of the current state of the art.
I agree Lars, but it is even simpler than that. We just need to convince
router manufacturers what is necessary and sufficient for specifying filter
rules. It has been *VERY* difficult to get router manufacturers to listen.
Atomic filters specs for IP/TCP/UDP need to encompass the following
2. Direction (inbound/outbound on interface)
3. Source IP address
4. Source IP address mask
5. Destination IP address
6. Destination IP address mask
7. Protocol (UDP, TCP, ICMP, etc.)
8. Source port [range]
9. Destination port [range]
10. Pass/reject the packet if it matches the filter
For ICMP you need to substitute the following for 8 & 9 above:
8'. ICMP message type
9'. ICMP message subtype
To construct rule sets you need to order the atomic filter specs. Due to
possible undesired interactions the filter "builder" needs to be able to
order the atomic filter rules to produce the final rule set.
Once you can do all of this you can build reasonably secure firewalls with
minimal undesired interaction.
>There is some confusion between the facilities that a given IP router
>can provide and the command language in which that system's user manual
>expresses those facilities. That was why I suggested SNMP as a common
>ground for expressing the features available. After all, if the router
>is SNMP-manageable, you might have your choice of snazzy GUI management
>stations to choose from, while the common SNMP MIB describes what
>features can actually be implemented.
While not being a great fan of SNMP, it should work in this situation. I
have long held that we need to separate filtering along the lines you
mention: the rule set used by the router and the specification of the rule
set by the administrator. Being able to just specify the rule set is a big
win and should be minimally sufficient to build firewalls (I am sure that
everyone will agree that sendmail is one of the most arcane and obscure
programs to configure but most email in the Internet still flows through
sendmail in spite of the difficulty in its configuration).
A compiler that will accept a human-oriented language as input and will
generate filter rule sets as output would be very nice. Heck, it could
even generate SNMP messages.
>This group does not concur, so I'll shut up (about that topic).
Actually, I concur with you on this. We could probably get it into the
router requirements RFC if we work at it. That would put pressure on the
router mfgrs to "do it right."
>/ Lars Poulsen, SMTS Software Engineer Internet E-mail: lars @
> CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262
> Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256
Brian Lloyd 3420 Sudbury Road
com Cameron Park, CA 95682
edu (916) 676-3442 - fax
(415) 725-1392 (916) 676-1147 - voice