[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalls-gc
Subject:    Re: Firewalls Digest V1 #41
From:       brian () nic1 ! barrnet ! net
Date:       1992-12-05 14:41:00
[Download RAW message or body]

>From: lars@spectrum.CMC.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
elements:

1.  Interface
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.COM
>  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
brian@lloyd.com                                   Cameron Park, CA  95682
brian@angband.stanford.edu                        (916) 676-3442 - fax
(415) 725-1392                                    (916) 676-1147 - voice

[prev in list] [next in list] [prev in thread] [next in thread]