On Mon, 20 Apr 1998, Michael Dillon wrote:
Wholesale filtering of ?.?.?.255 is irresponsible but if you have downstream networks who are unable to block directed broadcasts then it is a reasonable stopgap measure to block ?.?.?.255 traffic in those
Only if the downstream networks are no bigger than a class C and/or you have the permission of all customers affected by that filter and the filter only affects packets destined to your customers (not outbound packets to the net). If you have any downstreams larger than a /24, you should allow those through. Even then, your netmask should have 1s on the left and right (i.e. 255.255.0.255) for a /16 subnetted at /8. Really, you should filter the known broadcast addresses of your downstream networks with the cooperation of those networks. What I was objecting to was the idea that some ISP would get the idea that it was a good idea to filter all .255 destined traffic passing through their network and the general idea that it was ok for an ISP to assume that .255 was a broadcast address when they should actually know their downstream networks in more detail than that (although they might not know about subnetting). Actually, even if they don't know the subnet structure before hand, they will discover this, as far as is relevent to smurfing, when they perform a smurf scan on their own CIDR blocks. Any address that results in multiple smurf type echo replies from different addresses would be considered a broadcast address; any that didn't, wouldn't. And, of course, any ISP should always inform their downstream contacts of any filtering which affects packets to/from their downstream network (no matter how standard) and this information should be propagated downward (possibly excluding details of the firewall protecting the ISPs servers provided that that firewall is not inline for packets between the downstream and either upstream, peers, or other downstreams).
downstream network blocks only. But at the same time you should *DEMAND* that the downstream customer's router vendor fix their broken equipment or else advertise that it is suitable only for use on networks that are not interconnected with the Internet.
Indeed. In the following comments, "firewall" will refer to a packet filtering box, not a proxy box. In a separate message, in private email, another participant, Marc Slemco, pointed out that IP fragment reassembly by a router is contrary to RFC 1812 and dangerous in some situations because the fragments could take separate routes. So, I would consider the following conditions to be necessary before one used fragment reassembly: - The firewall in question is the only route in or out of a network (i.e. if there are multiple links they all come to the same box). - An exception to the above rule could, perhaps, be granted, if all the firewalls protecting a multiply connected leaf network were programmed to behave in such a way that fragments which took multiple routes were sent to the same box to be reassembled. One still needs to consider what happens when one of the boxes is down. One also needs to be careful, from a security perspective, that the method of relaying fragments does not cause them to be mistaken for traffic originating inside; simply "routing" all fragments which arrive at firewall1 and firewall2 to firewall0 (or using a hash) would not be acceptable (unless you had a dedicated fragment network), some form of encapsulation would be needed. - And the deviation from RFC-1812 was well documented, preferably somewhere readily accessable from both inside and outside the protected network. Actually, I would like to see a RFC for using DNS to associate (perhaps using text records) a URL to a WEB page which documents any ideosyncracies of any given router with the canonical forward DNS entry for that router. That way, there would be a consistent way to document broken hardware or hardware which had to, for some reason, deviate from the RFC's. I.e., you MUST not do this, but if you do it anyway, you MUST confess :-). And confession should not be confused with absolution. [Another pet peeve: people who fail to include reverse address DNS records for their router addresses. It is so easy to do (http://www.dbd.com/~whitis/temp/dns/makerev.c) ]. It is also possible, I suspect, if you have multiple links, for some packets to be consistenly fragmented and the fragments routed consistently over multiple routes (based on size or some other criteria) including one which was down so that you received (consistently) some but not all fragments for a while. Combination of retransmission, fragmentation, and multiple routes could conceivably even conspire to produce hostile DoS style improperly fragmented packets entirely by accident (i.e. the overlapping fragment style); this is regardless of whether you reassemble packets at your firewall(s). But if you are protecting a leaf network with a firewall, I still do think you should normally reassemble packets at the firewall; you simply cannot trust all the different stacks inside the firewall in most situations. But conformance with RFC-1812 is likely to mean you have to have a single firewall (a single point of failure, possibly with an offline backup) between the protected organization and all outside connections or that some new code be written. --------------------------------------------------------------------------- --- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- ---------------------------------------------------------------------------