Hello, I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255". I'm curious because any network /0-/23,/31,/32 can legitimately have ip addresses in-use which end as such. /32's can obviously have (most) any ip address, since there is no notion of a network or broadcast address. /31 doesn't have a directed broadcast. For /0-/23 only the first ".0" and the last ".255" correspond to reserved addresses. All of the intervening addresses are legal. Is this type of filtering common? What alternate solutions are available to mitigate (I'm assuming) concerns about smurf amplifiers, that still allow traffic to/from legitimate addresses. What rationale is used to filter all traffic to network/broadcast addresses of /24 networks while ignoring network/broadcast of /25-/30? For that matter, what percentage of smurf amplifiers land on /24 boundaries? Thanks, Stephen
On Mon, Jan 21, 2002 at 05:53:16PM -0500, Stephen Griffin wrote:
Hello,
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
they will have problems reaching people who are now using /31s on links that cover the last /31 and first /31 of the /24 that they reside in. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
### On Mon, 21 Jan 2002 18:01:44 -0500, Jared Mauch <jared@puck.Nether.net> ### casually decided to expound upon Stephen Griffin ### <stephen.griffin@rcn.com> the following thoughts about "Re: traffic ### filtering": JM> On Mon, Jan 21, 2002 at 05:53:16PM -0500, Stephen Griffin wrote: JM> > JM> > I'm curious about how many networks completely filter all traffic to JM> > any ip address ending in either ".0" or ".255". JM> JM> they will have problems reaching people who are now using /31s JM> on links that cover the last /31 and first /31 of the /24 that they reside JM> in. I guess depending on where one places the filter (and to whom it is applied), one could argue that this is a good thing. It does make troubleshooting a bit pesky however. I once moved a router and forgot to reconfigure the IP address on its serial interface. Most "everything" worked fine and didn't discover my mistake until I was troubleshooting my VOIP tunnel. |8^) -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
In the referenced message, Jared Mauch said:
On Mon, Jan 21, 2002 at 05:53:16PM -0500, Stephen Griffin wrote:
Hello,
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
they will have problems reaching people who are now using /31s on links that cover the last /31 and first /31 of the /24 that they reside in.
- Jared
or (as in my case) router loopbacks using a /32 with .0 or .255, or dialup users allocated out of a /21 pool, where any but the first .0 and last .255 are legitimate (technically, with dialup if they are allocated as /32's they are all legitimate). Or any lan larger than a /24.
Stephen Griffin wrote:
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
I've only heard of one other institution doing this.
I'm curious because any network /0-/23,/31,/32 can legitimately have ip addresses in-use which end as such. /32's can obviously have (most) any ip address, since there is no notion of a network or broadcast address. /31 doesn't have a directed broadcast. For /0-/23 only the first ".0" and the last ".255" correspond to reserved addresses. All of the intervening addresses are legal.
Right. That is exactly why this is generally at least a silly, if not bad idea.
Is this type of filtering common? What alternate solutions are available
I don't think it is very common. I'd be curious to hear otherwise.
to mitigate (I'm assuming) concerns about smurf amplifiers, that still allow traffic to/from legitimate addresses. What rationale is used to
Devices that forward (routers) should provide mechanisms to disable the forwarding of directed broadcasts. See the following RFC: http://www.rfc-editor.org/rfc/rfc2644.txt
filter all traffic to network/broadcast addresses of /24 networks while ignoring network/broadcast of /25-/30? For that matter, what percentage of smurf amplifiers land on /24 boundaries?
Rationale? Perhaps sites that only use /24 in their route tables have that rationale? Otherwise its probably due to a misunderstanding of IP addressing. John
In the referenced message, Stephen Griffin said:
Hello,
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
Just to clarify, since a lot of the messages I'm receiving seem to indicate I was unclear. I'm not trying to determine how I should filter. I'm trying to determine how many other networks filter in such a manner that traffic to/from legitimate hosts is blocked. One solution, rather than completely filter particular ip addresses, is to simply rate-limit either/both icmp echo request/icmp echo response message types. This should allow these other networks the ability to mitigate smurfs, while still allowing traffic from legitimate ip addresses.
On Mon 21 Jan 2002 (18:46 -0500), Stephen Griffin wrote:
In the referenced message, Stephen Griffin said:
Hello,
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
Just to clarify, since a lot of the messages I'm receiving seem to indicate I was unclear. I'm not trying to determine how I should filter. I'm trying to determine how many other networks filter in such a manner that traffic to/from legitimate hosts is blocked.
One solution, rather than completely filter particular ip addresses, is to simply rate-limit either/both icmp echo request/icmp echo response message types. This should allow these other networks the ability to mitigate smurfs, while still allowing traffic from legitimate ip addresses.
We had to move some ADSL /32's off the .0 address because some idiots out there were filtering on /24 boundaries. Demon never allocates dialup /32's on .0 or .255, because there are misconfigured setups out there. -- Jim Segrave jes@nl.demon.net
On Mon, 21 Jan 2002, Stephen Griffin wrote:
Is this type of filtering common? What alternate solutions are available to mitigate (I'm assuming) concerns about smurf amplifiers, that still allow traffic to/from legitimate addresses. What rationale is used to filter all traffic to network/broadcast addresses of /24 networks while ignoring network/broadcast of /25-/30? For that matter, what percentage of smurf amplifiers land on /24 boundaries?
As of last Monday / Tuesday, approximately 45% of all smurf amplifiers in the RIPE region had addresses ending in .0 or .255 [1]. I'm unsure about ARIN / APNIC IP space. I would certainly hope the kind of filtering you mention is uncommon :) If you filter on your ingress, packets who destination address ends in .0 or .255, and you are a smurf amplifier, you're only stalling the inevitable. The best course of action is to fix the smurf amplifier itself :) Check http://www.ircnetops.org/smurf/faq.php if you need to do this. Regards, [1] = Data provided by SAFE (http://www.ircnetops.org/smurf) -- Avleen Vig Network Security Officer Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf
On Mon, Jan 21, 2002 at 05:53:16PM -0500, Stephen Griffin wrote:
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
I heard recently that Windows 2000 will refuse to send packets to addresses with the least-significant octet 255, if the most- significant octet indicates the address lies in a pre-CIDR class C. So, for example, 192.168.0.255 would be unreachable from a windows 2000 machine, regardless of the fact that it might be a legitimate host numbered within 192.168.0.0/23. This seems like a strange design decision for windows 2000, if it's real. But, if it *is* true, the answer to your question "is this kind of filtering common" might be a strong "yes", at least in the Microsoft-populated extreme network edge. Joe
Date: Tue, 22 Jan 2002 12:34:57 -0500 From: Joe Abley <jabley@automagic.org>
This seems like a strange design decision for windows 2000, if
Strange? Stupid is more like it.
it's real. But, if it *is* true, the answer to your question "is this kind of filtering common" might be a strong "yes", at least in the Microsoft-populated extreme network edge.
Wouldn't surprise me. IIRC, Win95 (NT? 98?) would send bcast messages to the classful broadcast address, regardless of subnet mask. Anyone have a Win2000 machine handy to confirm or deny? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Tue, 22 Jan 2002 at 12:34pm Joe Abley wrote:
On Mon, Jan 21, 2002 at 05:53:16PM -0500, Stephen Griffin wrote:
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
I heard recently that Windows 2000 will refuse to send packets to addresses with the least-significant octet 255, if the most- significant octet indicates the address lies in a pre-CIDR class C. So, for example, 192.168.0.255 would be unreachable from a windows 2000 machine, regardless of the fact that it might be a legitimate host numbered within 192.168.0.0/23.
Not true. M$ is guilty of many evil things, but not this one. -- Joseph F. Noonan Rigaku/MSC Inc. jfn@msc.com ------------------------------------------- Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\>tracert o2 Tracing route to o2.msc.com [12.110.0.218] over a maximum of 30 hops: 1 <10 ms <10 ms <10 ms netb.msc.com [192.246.38.10] 2 <10 ms <10 ms <10 ms 172.16.16.2 3 <10 ms 10 ms <10 ms 12.124.26.249 4 <10 ms 10 ms <10 ms gbr2-p51.hs1tx.ip.att.net [12.123.134.18] 5 <10 ms <10 ms 10 ms gbr3-p40.dlstx.ip.att.net [12.122.2.97] 6 10 ms 10 ms 10 ms gbr4-p60.dlstx.ip.att.net [12.122.1.138] 7 30 ms 30 ms 30 ms gbr4-p50.dvmco.ip.att.net [12.122.2.102] 8 30 ms 30 ms 30 ms gbr1-p20.dvmco.ip.att.net [12.122.5.22] 9 40 ms 40 ms 40 ms ar1-p3110.slkut.ip.att.net [12.123.207.5] 10 40 ms 40 ms 40 ms 12.127.107.26 11 50 ms 40 ms 60 ms fw-utah.msc.com [12.110.0.130] 12 40 ms 40 ms 60 ms o2.msc.com [12.110.0.218] Trace complete. C:\>
Never mind. Brain several iterations behind keyboard. It was kindly pointed out to me offlist. I will now return to lurking where I belong. thx, On Tue, 22 Jan 2002 at 1:57pm J.F. Noonan wrote:
On Tue, 22 Jan 2002 at 12:34pm Joe Abley wrote:
On Mon, Jan 21, 2002 at 05:53:16PM -0500, Stephen Griffin wrote:
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
I heard recently that Windows 2000 will refuse to send packets to addresses with the least-significant octet 255, if the most- significant octet indicates the address lies in a pre-CIDR class C. So, for example, 192.168.0.255 would be unreachable from a windows 2000 machine, regardless of the fact that it might be a legitimate host numbered within 192.168.0.0/23.
Not true. M$ is guilty of many evil things, but not this one.
--
Joseph F. Noonan Rigaku/MSC Inc. jfn@msc.com
-------------------------------------------
Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp.
C:\>tracert o2
Tracing route to o2.msc.com [12.110.0.218] over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms netb.msc.com [192.246.38.10] 2 <10 ms <10 ms <10 ms 172.16.16.2 3 <10 ms 10 ms <10 ms 12.124.26.249 4 <10 ms 10 ms <10 ms gbr2-p51.hs1tx.ip.att.net [12.123.134.18] 5 <10 ms <10 ms 10 ms gbr3-p40.dlstx.ip.att.net [12.122.2.97] 6 10 ms 10 ms 10 ms gbr4-p60.dlstx.ip.att.net [12.122.1.138] 7 30 ms 30 ms 30 ms gbr4-p50.dvmco.ip.att.net [12.122.2.102] 8 30 ms 30 ms 30 ms gbr1-p20.dvmco.ip.att.net [12.122.5.22] 9 40 ms 40 ms 40 ms ar1-p3110.slkut.ip.att.net [12.123.207.5] 10 40 ms 40 ms 40 ms 12.127.107.26 11 50 ms 40 ms 60 ms fw-utah.msc.com [12.110.0.130] 12 40 ms 40 ms 60 ms o2.msc.com [12.110.0.218]
Trace complete.
C:\>
On Tue, Jan 22, 2002 at 01:57:07PM -0600, J.F. Noonan wrote:
On Tue, 22 Jan 2002 at 12:34pm Joe Abley wrote:
On Mon, Jan 21, 2002 at 05:53:16PM -0500, Stephen Griffin wrote:
I'm curious about how many networks completely filter all traffic to any ip address ending in either ".0" or ".255".
I heard recently that Windows 2000 will refuse to send packets to addresses with the least-significant octet 255, if the most- significant octet indicates the address lies in a pre-CIDR class C. So, for example, 192.168.0.255 would be unreachable from a windows 2000 machine, regardless of the fact that it might be a legitimate host numbered within 192.168.0.0/23.
Not true. M$ is guilty of many evil things, but not this one.
I just tried this. This is not exhaustive. I may well have made some kind of some screw-up. Interpret as you will. Contents may have settled in transit. NetBSD 1.5.2 i386 FreeBSD 4.5-PRERELEASE | | ---+------------+------------+---- | Win2k SP3 I configured the following addresses: NetBSD: 192.168.0.1/23, 192.168.0.255/23 FreeBSD: 192.168.0.20/23 Win2k: 192.168.0.30/23 FreeBSD box can ping 192.168.0.1. FreeBSD box can ping 192.168.0.255. NetBSD box can ping 192.168.0.20. NetBSD box can ping 192.168.0.30 (tcpdump shows the NetBSD box is using a source of 192.168.0.1 for these pings). Win2k box can ping 192.168.0.1. Win2k box can ping 192.168.0.20. Win2k cannot ping 192.168.0.255: C:\>ping 192.168.0.255 Pinging 192.168.0.255 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.0.255: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\> NetBSD box is receiving the requests, however, and replying to them. tcpdump shows: 15:30:39.753003 192.168.0.20 > 192.168.0.255: icmp: echo request 15:30:39.753307 192.168.0.255 > 192.168.0.20: icmp: echo reply 15:30:41.228742 192.168.0.20 > 192.168.0.255: icmp: echo request 15:30:41.229053 192.168.0.255 > 192.168.0.20: icmp: echo reply 15:30:42.230249 192.168.0.20 > 192.168.0.255: icmp: echo request 15:30:42.230555 192.168.0.255 > 192.168.0.20: icmp: echo reply 15:30:43.231735 192.168.0.20 > 192.168.0.255: icmp: echo request 15:30:43.232046 192.168.0.255 > 192.168.0.20: icmp: echo reply So, the Windows box seems to behave differently when dealing with the particular address ending in 255 that I tried. I guess the rule of thumb when numbering devices which need to coexist with Windows is "avoid 255". Joe
On Tue, 22 Jan 2002, Joe Abley wrote:
I guess the rule of thumb when numbering devices which need to coexist with Windows is "avoid 255".
How about "when doing networking avoid Windows" instead? ;^) Being at a site which not only uses .0 & .255 addresses in our network but also has a "255" in two of our our base net numbers (128.255.0.0/16 & 129.255.0.0/16), I appeal to sanity & common sense in requesting that folks not blindly filter on octets of 0 or 255 when they don't (& can't) know the corresponding net masking. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-5505
On Thu, 24 Jan 2002, Jay Ford wrote:
On Tue, 22 Jan 2002, Joe Abley wrote:
I guess the rule of thumb when numbering devices which need to coexist with Windows is "avoid 255".
How about "when doing networking avoid Windows" instead? ;^)
Being at a site which not only uses .0 & .255 addresses in our network but also has a "255" in two of our our base net numbers (128.255.0.0/16 & 129.255.0.0/16), I appeal to sanity & common sense in requesting that folks
you appeal to 'sanity & common sense'.. good luck in your crusade! hehe
not blindly filter on octets of 0 or 255 when they don't (& can't) know the corresponding net masking.
________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-5505
-- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008
Thank you all for your responses public and private. About 4 respondents stated they do filter (traffic) on /24 network/broadcast boundaries. It appears that microsoft boxes may have some issues due to bugs in their networking code. I'm going to attempt to address those with Microsoft. In response to my queries, none of the respondents stated why rate-limitting certain icmp message types would not be sufficient to all-out filtering. The prevalent supporting argument was that old or buggy gear may have trouble with addresses ending in ".0" or ".255", and that others filter. Several folks mentioned sizable providers that do allocate addresses with ".0" and ".255" (some were mentioned privately, so I'll omit those) to include mediaone and aol. How folks choose to filter is their own business, but I would respectfully request that consideration be made into alternatives that address their needs while encouraging vlsm, and connectivity for legitimate ip addresses. Thank you all, Stephen
* stephen.griffin@rcn.com (Stephen Griffin) [Thu 24 Jan 2002, 18:04 CET]: [whether to filter addresses at the boundaries of /24's]
It appears that microsoft boxes may have some issues due to bugs in their networking code. I'm going to attempt to address those with Microsoft.
At a previous employer handing out addresses ending in .0 or .255 out of a netblock in "traditional class C space" to dialup customers often caused problems for them. I don't know whether that was due to the equipment used (Cisco AS5300/AS5800) or to the clients (Windows 98 and similar ilk); I suspect the latter, though, although the former had their own set of problems... Regards, -- Niels. -- "The Internet is totally out of control, impossible to map accurately, and being used far beyond its original intentions. So far, so good." -- Dr. Dobb's Journal, May 1993
participants (12)
-
Avleen Vig -
E.B. Dreger -
J.F. Noonan -
Jake Khuon -
Jared Mauch -
Jay Ford -
Jim Segrave -
Joe Abley -
John Kristoff -
Niels Bakker -
Stephen Griffin -
Stephen J. Wilcox