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

List:       firewalls-gc
Subject:    address mask (was: packet filter metalanguage)
From:       Bob Sutterfield <bob () MorningStar ! Com>
Date:       1992-12-12 0:48:05
[Download RAW message or body]

   Date: Fri, 11 Dec 92 17:35:53 -0800
   From: Brent Chapman <brent@greatcircle.com>
   To: Firewalls@greatcircle.com

   By "address mask", he means a mask to apply to determine how many
   bits to look at when comparing an address from a packet to the
   address in a filtering table.  I.e., on a NetBlazer, if you wanted
   to examine the top 24 bits of an address in a rule, you'd express
   the address as 123.45.67/24; on a Cisco, it would be 123.45.67.0
   0.0.0.255 (I like the NetBlazer syntax much better, by the way;
   it's much shorter and simpler).

If you can only count 1-bits from the left, you eliminate any
possibility of handling noncontiguous masks, which are allowed (though
not encouraged) in both RFC-950 and RFC-1122.  A mask notation that
describes the arrangement of the bits is more general than one that
only allows their enumeration.

   Ideally, I think you'd like to have three actions and an option to
   choose from.  The actions would be "pass", "reject" (i.e., return
   to sender with an appropriate ICMP error message), and "drop" ...

Do you mean something like the new "unreachable" codes described in
RFC-1122 section 3.2.2.1?  What routers do those now?  All I've ever
seen them do is to just drop the packet on the floor.

   For dialup routers, another thing that I've wished for is the ability
   to log the first N packets (where N is set by the user) received or
   sent after the modems connect.  This would help you figure out why
   your PPP boxes keep connecting every 10 minutes for no apparent
   reason, for instance.

By default, ours shows the packet that caused the action, like

12/11-22:08:05-88 tcp 137.175.6.7/1718 -> 137.175.2.11/domain 44 syn bringup

which indicates that my home machine's in.named wanted to refresh its
cache.  We've never needed to see any more than N=1 outgoing packets
to figure out why the link became active, but I suppose we could add
the ability to log the first N packets on an incoming connection too,
in case the calling machine's log was inaccessible.

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