Is it time to abandon bogon prefix filters?
Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpC6GPSPZlqX.pgp Description: PGP signature
RE: Is it time to abandon bogon prefix filters?
Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog@nanog.org Subject: Is it time to abandon bogon prefix filters? Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
was bogon filters, now Brief Segue on 1918
Was looking over 1918 again, and for the record I have only run into one network that follows: If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose *randomly* from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. I added the asterisks. Most private networks start at the bottom and work up: 192.168.0.X++, 10.0.0.X++, etc. This makes any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen a lot of hack jobs using NAT to get around this. Ugly. --Patrick Darden -Original Message- From: Darden, Patrick S. Sent: Wednesday, August 06, 2008 9:19 AM To: 'Leo Bicknell'; nanog@nanog.org Subject: RE: Is it time to abandon bogon prefix filters? Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog@nanog.org Subject: Is it time to abandon bogon prefix filters? Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: was bogon filters, now Brief Segue on 1918
Where I work we are more aimed towards the SMB market, and we do run into that issue a lot. Of course a lot of the problem we run into is that the engineers who set up these SMB clients, even getting into some of the larger businesses just use what they always do. I can think of one specific engineer who everything he does is 192.168.1.0/24 .254 gateway .1 server which has cause issues. We have one particular client who has nearly 40 VPN's between partners and they have actually had to do a lot of natting at the vpn endpoint as they have 3 clients they connect to that are 10.0.1.0/24 and several that are 192.168.0.0/24 however a lot of the newer VPN firewalls that we work with actually do a pretty slick job. SonicWall NSA series devices have a NAT VPN range checkbox when you build the VPN and you just give it the range to use, as do the Fortinet devices. -Original Message- From: Darden, Patrick S. [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 7:26 AM To: nanog@nanog.org Subject: was bogon filters, now Brief Segue on 1918 Was looking over 1918 again, and for the record I have only run into one network that follows: If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose *randomly* from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. I added the asterisks. Most private networks start at the bottom and work up: 192.168.0.X++, 10.0.0.X++, etc. This makes any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen a lot of hack jobs using NAT to get around this. Ugly. --Patrick Darden -Original Message- From: Darden, Patrick S. Sent: Wednesday, August 06, 2008 9:19 AM To: 'Leo Bicknell'; nanog@nanog.org Subject: RE: Is it time to abandon bogon prefix filters? Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog@nanog.org Subject: Is it time to abandon bogon prefix filters? Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: Is it time to abandon bogon prefix filters?
This makes sense especially for static filters. Automated feeds, such as the bogon route-server or DNS zones, leaves folks with options. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: was bogon filters, now Brief Segue on 1918
Darden, Patrick S. wrote: Most private networks start at the bottom and work up: 192.168.0.X++, 10.0.0.X++, etc. This makes any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen a lot of hack jobs using NAT to get around this. Ugly. Well, you can always do what one of the companies I work with does: allocate from 42.0.0.0/8 for networks that might need to interoperate with 1918 space and hope that it is forever before we run so low on IPv4 space that 42.0.0.0/8 needs to be taken out of reserved status. How many more weeks is forever now? Matthew Kaufman [EMAIL PROTECTED] http://www.matthew.at
Re: was bogon filters, now Brief Segue on 1918
Matthew Kaufman wrote: do what one of the companies I work with does: allocate from 42.0.0.0/8 some italian isps use blocked american military /8s. i find that highly amusing, especially when i think of the long-term implication for the folk who blocked access to that they wanted to 'own'. randy
Re: Is it time to abandon bogon prefix filters?
On Aug 6, 2008, at 10:28 AM, Rob Thomas wrote: This makes sense especially for static filters. Automated feeds, such as the bogon route-server or DNS zones, leaves folks with options. Honestly, I don't believe the 80/20 rules applies here. Until all transit networks are willing to strictly filter their downstreams (and themselves!), if there is any unused space (note I said unused, not unallocated), the miscreants will use it. They are not going around saying oh, damn, there are only a few /8s left, we better stop!. Filter your bogons. But do it in an automated fashion, from a trusted source. Of course, I recommend Team Cymru, which has a most sterling record. Nearly perfect (other than the fact they still recommend MD5 on BGP sessions :). -- TTFN, patrick
Re: Is it time to abandon bogon prefix filters?
Until all transit networks are willing to strictly filter their downstreams (and themselves!), if there is any unused space (note I said unused, not unallocated), the miscreants will use it. serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? randy
Re: Is it time to abandon bogon prefix filters?
serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? Let me see what we can produce in the way of data. I'll just count 2008, though I could go back further if there's interest. Stay tuned, I should have some answers in a few hours. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: was bogon filters, now Brief Segue on 1918
Darden, Patrick S. wrote: Was looking over 1918 again, and for the record I have only run into one network that follows: If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose *randomly* from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. I added the asterisks. You're supposed to choose ula-v6 /48 prefixs randomly as well... Any bets on whether that routinely happens? While you're home can probably randomly allocate subnets out of a /8 or /12 for a while without collisions, nobody that's actually building a subnetting plan for a large private network is going to be able to get away with that in v4. --Patrick Darden -Original Message- From: Darden, Patrick S. Sent: Wednesday, August 06, 2008 9:19 AM To: 'Leo Bicknell'; nanog@nanog.org Subject: RE: Is it time to abandon bogon prefix filters? Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog@nanog.org Subject: Is it time to abandon bogon prefix filters? Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently?
Re: Is it time to abandon bogon prefix filters?
Randy Bush wrote: serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? I still have 2 of my borders using an inbound ACL to filter BOGONs vs null routes. For the ACLs I've broken down the BOGONs to nothing larger than a /8. I see a number of hits on those entries, especially on 94/8. and 0/8. While some of the other hits are accidental I'm sure, I would seriously doubt if those 2 /8s are. Justin
Re: Is it time to abandon bogon prefix filters?
Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? In my opinion no; BOGON filters are still very useful. Back when only 5% of the IP space was allocated we didn't have the same kinds of serious threats to our networks and our users that we have today. We didn't have spammers hijacking unallocated space (can if be considered hijacking when the block hasn't been allocated yet?) to mass mail our users, host phishing servers, run CC servers for botnets, etc. Today we do and the use of what few networks are still unallocated for bad purposes are prevalent. For my users I only recommend that they use dynamic methods of keeping up to date with changes in the BOGON list. While I still do much of my BOGON work manually, as I'm sure many of us do, I have my local BOGON lists updated within a few hours of learning of a new allocation (sometimes even before the bogon-announce email arrives). For those that aren't uber network geeks I recommend using something automated. Look at it this way: you have what's essentially a mostly static list of netblocks from which all traffic is unquestionably malicious. Wouldn't you block it if you could for the sake of your network security and that of your users? Justin
Re: Is it time to abandon bogon prefix filters?
I see a number of hits on those entries, especially on 94/8. and 0/8. You do know that 94/8 has been assigned to the RIPE NCC, right? :-) Cheers, Rob
Re: was bogon filters, now Brief Segue on 1918
On Aug 6, 2008, at 7:44 AM, Matthew Kaufman wrote: Darden, Patrick S. wrote: Most private networks start at the bottom and work up: 192.168.0.X++, 10.0.0.X++, etc. This makes any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen a lot of hack jobs using NAT to get around this. Ugly. Well, you can always do what one of the companies I work with does: allocate from 42.0.0.0/8 for networks that might need to interoperate with 1918 space and hope that it is forever before we run so low on IPv4 space that 42.0.0.0/8 needs to be taken out of reserved status. How many more weeks is forever now? Personally, I'd like to see such numbers put on a list for ICANN to give priority to in their next RIR distribution. Owen
Re: Is it time to abandon bogon prefix filters?
Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? Seems like filtering against those could be done on the backplane, so to speak. One of the things that has always puzzled me is this: In the default-free zone, why is necessary to filter _against_ anybody? Seems like traffic for which there is no route would at most be dumped to an error-log someplace. For folks with a default route, I have long advocated (with no success what ever) filtering against stuff like the above, your own networks as sourced somewhere else, such. I also think a central blacklist a la spamhaus for networks makes sense. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actioInfallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs
Re: Is it time to abandon bogon prefix filters?
Rob Evans wrote: I see a number of hits on those entries, especially on 94/8. and 0/8. You do know that 94/8 has been assigned to the RIPE NCC, right? :-) I knew I should have logged into a production box to look at the ACL counters. But no, I thought the former border that I was already logged into was good enough. Apparently not! :-) I stopped updating it's BOGON list when it was decommissioned and retasked. I could have sworn that was just this past April and the only change since then was 112 and 113/8 which I accounted for mentally. Apparently it was longer ago than I thought! Justin
RE: was bogon filters, now Brief Segue on 1918
Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 11:21 AM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 Darden, Patrick S. wrote: *randomly* from the reserved pool of private addresses, when You're supposed to choose ula-v6 /48 prefixs randomly as well... Any bets on whether that routinely happens? While you're home can probably randomly allocate subnets out of a /8 or /12 for a while without collisions, nobody that's actually building a subnetting plan for a large private network is going to be able to get away with that in v4.
Re: was bogon filters, now Brief Segue on 1918
On 06/08/2008 4:44, Matthew Kaufman [EMAIL PROTECTED] wrote: [...] Well, you can always do what one of the companies I work with does: allocate from 42.0.0.0/8 for networks that might need to interoperate with 1918 space and hope that it is forever before we run so low on IPv4 space that 42.0.0.0/8 needs to be taken out of reserved status. I'm very confident that 42.0.0.0/8 will be allocated within the next three years. Leo
Re: was bogon filters, now Brief Segue on 1918
Darden, Patrick S. wrote: Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use? --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 11:21 AM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 Darden, Patrick S. wrote: *randomly* from the reserved pool of private addresses, when You're supposed to choose ula-v6 /48 prefixs randomly as well... Any bets on whether that routinely happens? While you're home can probably randomly allocate subnets out of a /8 or /12 for a while without collisions, nobody that's actually building a subnetting plan for a large private network is going to be able to get away with that in v4.
Verizon Contactg
Would someone from Verizon please contact me? Or, if you know of a technical contact for Verizon, please pass it along. Thanks. Best, Alan
Re: was bogon filters, now Brief Segue on 1918
On Aug 6, 2008, at 12:36 PM, Joel Jaeggli wrote: Darden, Patrick S. wrote: Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use? In my experience, effectively all of it. Marshall --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 11:21 AM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 Darden, Patrick S. wrote: *randomly* from the reserved pool of private addresses, when You're supposed to choose ula-v6 /48 prefixs randomly as well... Any bets on whether that routinely happens? While you're home can probably randomly allocate subnets out of a / 8 or /12 for a while without collisions, nobody that's actually building a subnetting plan for a large private network is going to be able to get away with that in v4.
Re: Is it time to abandon bogon prefix filters?
On Aug 6, 2008, at 11:46 AM, Laurence F. Sheldon, Jr. wrote: Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? Seems like filtering against those could be done on the backplane, so to speak. One of the things that has always puzzled me is this: In the default-free zone, why is necessary to filter _against_ anybody? Seems like traffic for which there is no route would at most be dumped to an error-log someplace. For folks with a default route, I have long advocated (with no success what ever) filtering against stuff like the above, your own networks as sourced somewhere else, such. I'm confused. Why does it matter if you are DF or not? If the packets are just coming in, there does not need to be a prefix in the table. If duplex communication is required (e.g. spam runs), a prefix need to be in the table whether you have a 0/0 or not. We know spammers have done runs by announcing a block (which gets it into the DFZ if it is not filtered properly), send spam, pull prefix. So again, why does it matter if you have a default route or not? I also think a central blacklist a la spamhaus for networks makes sense. See Team Cymru. -- TTFN, patrick
RE: was bogon filters, now Brief Segue on 1918
Well, how about this then: 10.Z.X.Y with Z being continent, X being country name with letters beginning with A assigned 1-10, B 11-20, with any unused letters having their numbers appended as needed, and Y being of course the host/int itself with maybe still 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) continent 1:10.100.x.y/16 provides ~65,000 IP addresses Continent 2:10.101.x.y/16 provides the same continent 3:whoa, asian market is big, better allocate for enterprise growth. 10.102.x.y and 10.103.x.y cont 4: 10.104/16 cont 5: 10.105/16 We have provided for ~400,000 employees here, fairly spread out equally amongst your 5 continents. With lots of room for growth by just adding another 10.Z/16 or two to each continent. Country algeria gets 10.100.1 and 10.100.2, country aguonia (?) gets 10.100.3 and 10.100.4, country bwabistan gets 10.100.11-15 (~1270 usable IPs, room for 150 servers, 250 printers, 500 PCs, 250 simultaneous telecommuters, and 100 switches and routers) because the company is big there. Etc. etc. My off the cuff network scheme isn't very good, but you get the drift. RFC1918 works. Details just have to be worked out on a case by case basis. IPV6 where are you?! --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 12:36 PM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 Darden, Patrick S. wrote: Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use?
RE: was bogon filters, now Brief Segue on 1918
Actually, rereading this, I agree. My experience is large companies take it all, using huge swathes inefficiently, instead of doing it right. In my previous post I was answering the question I thought you were asking, not your real question. I agree with you both. I think that RFC1918 Could work, if companies used it correctly Again, though, I have only run into one company that used it correctly. IPV6, you are our only hope! (obiwan kenobi, you are our only hope!) --p Joel said How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use? Marshall said In my experience, effectively all of it.
RE: Is it time to abandon bogon prefix filters?
Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) - S (Sent via dumb phone mail client, apologies for any formatting badness). -Original Message- From: Patrick W. Gilmore [EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 11:59 To: NANOG list nanog@nanog.org Subject: Re: Is it time to abandon bogon prefix filters? On Aug 6, 2008, at 11:46 AM, Laurence F. Sheldon, Jr. wrote: Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? Seems like filtering against those could be done on the backplane, so to speak. One of the things that has always puzzled me is this: In the default-free zone, why is necessary to filter _against_ anybody? Seems like traffic for which there is no route would at most be dumped to an error-log someplace. For folks with a default route, I have long advocated (with no success what ever) filtering against stuff like the above, your own networks as sourced somewhere else, such. I'm confused. Why does it matter if you are DF or not? If the packets are just coming in, there does not need to be a prefix in the table. If duplex communication is required (e.g. spam runs), a prefix need to be in the table whether you have a 0/0 or not. We know spammers have done runs by announcing a block (which gets it into the DFZ if it is not filtered properly), send spam, pull prefix. So again, why does it matter if you have a default route or not? I also think a central blacklist a la spamhaus for networks makes sense. See Team Cymru. -- TTFN, patrick
RE: Is it time to abandon bogon prefix filters?
1. DOS of Cymru (as noted below). 2. False Positives. Your network is suddenly stranded. Maybe on purpose. (DOS of a network, e.g. China or Youtube). 3. False Negatives. A bogus network is suddenly centrally rubber-stamped. Could happen. We've seen a lot of shenanigans with the domain registrars--similar issues could happen here. . . I guess I am just trying to say that a centralized trusted repository brings with it a chance for a single point of failure. Could be the pros outweigh the cons. There are issues with a de-centralized system as well (which is what brought this conversation about.) Nothing specific to Cymru. --Patrick Darden -Original Message- From: Skywing [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:25 PM To: Patrick W. Gilmore; NANOG list Subject: RE: Is it time to abandon bogon prefix filters? Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) - S
Re: Is it time to abandon bogon prefix filters?
On Thu, 7 Aug 2008, Randy Bush wrote: serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? Attacks or misconfigured leaks? Leaks of RFC1918 stuff is pretty common, just ask any of the root server operators how many packets they see from RFC1918 leaking networks or do a traceroute across several residential cable network backbones. Attacks aren't as common because there is enough (not 100%) anti-spoofing (good) and/or bogon-filters (not as good) in different parts of the Internet it requires more thought to launch a spoofed DDOS than it does just to use tens of thousands of non-spoofed bots to launch a DDOS. Arbor Networks has some data.
Re: Is it time to abandon bogon prefix filters?
Hi, Skywing. We've had a few DDoS attacks and lots of scans and hack attempts. Some of the DDoS attacks managed to wipe out our front-end. At no point were the route-servers impacted, since we keep them well away from our networks, widely distributed, and vigorously monitored (configs, responsiveness, advertisements). Of course we're not perfect and there is no 100% solution, but we understand the implications of filtering gone awry (especially since we use it ourselves), and spend a lot of time and code keeping an eye on these things. Knowing that no one has a monopoly on imagination, we also have some friends at commercial pen-testers hit us regularly, just to be sure. :) Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: was bogon filters, now Brief Segue on 1918
Darden, Patrick S. wrote: I'll reply below with //s. My point is still: most companies do not use RFC1918 correctly. As with say v4 prefix distribution as a whole where you observe that the number of very large prefix holders is rather small, it's really easy to say most casually, trivially in fact, that most rfc1918 uses are single devices with a single subnet behind them. There are a small number (low tens of thousands instead of low hundreds of millions) of applications where rfc1918 space feels rather tight, because in fact it's all going to get used. you don't have to look very far for operators (what we traditionally thing of as operators represent a chunk of those applications) chaffing under their 1918 limitations, see for example this draft which is undoubtedly met with opposition since the idea has come around before. http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-00 Your point seemed to be that it is not a large enough allocation of IPs for an international enterprise of 80K souls. My rebuttal is: 16.5 million IPs isn't enough? That is my point, 24 bits is rather tight. The least specific 32 of 96 bits looks like it will continue to work ok for some time... --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:31 PM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 That's comical thanks. come back when you've done it. //Ok. Marshall is correct. //Ok. If you'd like to avoid constant renumbering you need a sparser allocation model. You're still going to have collisions with your suppliers and acquisitions and some applications (eg labs, factory automation systems etc) have orders of magnitude large address space requirements than the number of humans using them implies. //You used the metric of 80K people. Now you say it is a bad metric when I reply using it. Your fault, you compound it--you don't provide a better one. What are we talking about then? 100 IPs per person--say each person has 10 PCs, 10 printers, 10 automated factory machines, 10 lab instruments, 49 servers and the soda machine on their network? 80,000*100==8 million IP addresses. That leaves you with 8.5 million And that includes 80,000 networked soda machines. I don't think you have that many soda machines. Even on 5 continents. Even with your growing Asian market, your suppliers, and the whole marketing team. In practice indivudal sites might be assigned between a 22 and a 16 with sites with exotic requirements having multiple assignments potentially from different non-interconnected networks (but still with internal uniqueness requirements). //Err. Doing it wrong does not justify doing it wrong.
Re: Is Usenet actually dead?
RES Date: Tue, 05 Aug 2008 09:19:44 -0400 RES From: Robert E. Seastrom RES If trends have continued since last I looked at it, very manageable RES after you take out the binaries. Insignificant if you could figure RES out a way to get rid of the flames and spam. :) Usenet - binaries - flames - spam = pretty close to actually dead ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Out of Date Bogon Prefix
Nick, I had experienced similar situation in last year. We evaluated our internet connectivity on application layer to explain our connectivity for our customer. I had presentation in JANOG21 (JApan Network Operators' Group 21th meeting) in January. JANOG i18n members translated my Japansese material. http://www.janog.gr.jp/en/index.php?JANOG21%20Programs#t4bc51ef
RE: Is Usenet actually dead?
We operate a transit box, and there are still quite a few of them out there. Pushing hundreds and hundreds of megs. http://news.anthologeek.net/ -Original Message- From: Edward B. DREGER [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 2:48 PM To: Robert E. Seastrom Cc: nanog@nanog.org Subject: Re: Is Usenet actually dead? RES Date: Tue, 05 Aug 2008 09:19:44 -0400 RES From: Robert E. Seastrom RES If trends have continued since last I looked at it, very manageable RES after you take out the binaries. Insignificant if you could figure RES out a way to get rid of the flames and spam. :) Usenet - binaries - flames - spam = pretty close to actually dead ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: was bogon filters, now Brief Segue on 1918
--- [EMAIL PROTECTED] wrote: Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. --- One way to do it... In picking out 1918 space for a network, I happened to notice it was 2:45pm. I randomly picked 20 minutes less and came up with 10.245.225. Then I started going lower as everyone seems to start lower and then goes higher. 10.245.225.0/24, 10.245.224.0/24, etc. Within those (and the larger subnets) I chose to fill out the blocks based on a scheme. So far, no network has used these ranges and we've connected to many. scott
RE: was bogon filters, now Brief Segue on 1918
But ... that's part of why RFC1918 is used, so they have this fairly large address range to play with. And remember, what one person calls inefficiency, another calls flexibility. Either (or neither) may be right! Oh, and I don't think we can say RFC1918 doesn't work today - obviously it does, just possibly inducing lots of head-aches. And yes, same ideas occur - just with larger numbers :) - in v6. To keep the analogy complete, reference ULAs ... with a (more stringent?) random component. (I put a question mark on that just because you can break the spec and configure non-random ones grumble) /TJ -Original Message- From: Darden, Patrick S. [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:19 PM To: Marshall Eubanks; Joel Jaeggli Cc: nanog@nanog.org Subject: RE: was bogon filters, now Brief Segue on 1918 Actually, rereading this, I agree. My experience is large companies take it all, using huge swathes inefficiently, instead of doing it right. In my previous post I was answering the question I thought you were asking, not your real question. I agree with you both. I think that RFC1918 Could work, if companies used it correctly Again, though, I have only run into one company that used it correctly. IPV6, you are our only hope! (obiwan kenobi, you are our only hope!) --p Joel said How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use? Marshall said In my experience, effectively all of it.
RE: Out of Date Bogon Prefix
Very helpful information. Thanks. Nick Downey -Original Message- From: Hiroyuki ASHIDA [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:51 PM To: [EMAIL PROTECTED] Cc: nanog@nanog.org Subject: Re: Out of Date Bogon Prefix Nick, I had experienced similar situation in last year. We evaluated our internet connectivity on application layer to explain our connectivity for our customer. I had presentation in JANOG21 (JApan Network Operators' Group 21th meeting) in January. JANOG i18n members translated my Japansese material. http://www.janog.gr.jp/en/index.php?JANOG21%20Programs#t4bc51ef
RE: was bogon filters, now Brief Segue on 1918
I think the problem is that operational reality (ease of use, visual clarity, etc.) has long since won the war against the numerical capabilities. Things like assigning /24's per vlan make the routing table easy to read, subnets easy to assign, etc. Starting from the bottom up, the next easy segregation point is /16s per site. Yielding just over 250 sites, each with just over 250 network segments, each supporting up to 250 or so users. Easy aggregation summarization, easy to own and operate ... grossly inefficient. But common. So, right or wrong is largely irrelevant - it just is. Now go into that environment and push for a strictly-speaking efficient allocation mechanism and let me know what kind of traction you get. Moving forward, we can try to do things right in our IPv6 networks ... assuming we don't inherit too much of the cruft from above. Use the bits to do flexible allocation while also maintaining aggregation / summarization - it can be done. ... now let's get some work done. /TJ -Original Message- From: Darden, Patrick S. [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:48 PM To: Joel Jaeggli Cc: nanog@nanog.org Subject: RE: was bogon filters, now Brief Segue on 1918 I'll reply below with //s. My point is still: most companies do not use RFC1918 correctly. Your point seemed to be that it is not a large enough allocation of IPs for an international enterprise of 80K souls. My rebuttal is: 16.5 million IPs isn't enough? --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:31 PM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 That's comical thanks. come back when you've done it. //Ok. Marshall is correct. //Ok. If you'd like to avoid constant renumbering you need a sparser allocation model. You're still going to have collisions with your suppliers and acquisitions and some applications (eg labs, factory automation systems etc) have orders of magnitude large address space requirements than the number of humans using them implies. //You used the metric of 80K people. Now you say it is a bad metric when I reply using it. Your fault, you compound it--you don't provide a better one. What are we talking about then? 100 IPs per person--say each person has 10 PCs, 10 printers, 10 automated factory machines, 10 lab instruments, 49 servers and the soda machine on their network? 80,000*100==8 million IP addresses. That leaves you with 8.5 million And that includes 80,000 networked soda machines. I don't think you have that many soda machines. Even on 5 continents. Even with your growing Asian market, your suppliers, and the whole marketing team. In practice indivudal sites might be assigned between a 22 and a 16 with sites with exotic requirements having multiple assignments potentially from different non-interconnected networks (but still with internal uniqueness requirements). //Err. Doing it wrong does not justify doing it wrong.
Re: Is it time to abandon bogon prefix filters?
Skywing wrote: Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) Use a prefix list of existing bogons against the Team Cymru BGP feed. If they are hacked this limits the possible attacks to the following bounds: 1) They advertise no address space, and you end up with no bogon filtering. 2) They advertise all of the IPv4 address space, but your prefix list limits this to (an admittedly out-of-date) list of bogons. Sam
RE: gTLD root nameserver anomaly
sorry, nm. glue records in the rootzones, that no one should have put. I'll go back in my corner now. -Original Message- From: Ross Dmochowski Sent: Wednesday, August 06, 2008 12:33 PM To: nanog@nanog.org Subject: gTLD root nameserver anomaly Importance: High Something weird seems afoot in the root nameservers. I am noticing that the root nameservers are handing out extra info with TTLs much longer than those delineated in the respective zone file on the authoritative nameserver for that zone. Case in point: I asked my local DNS server for ns2.gamespy.com and it went directly to a gtld server (f.gtld-servers.net.): 08:25:27.541627 IP 172.19.2.15.45505 192.35.51.30.domain: 42289% [1au] A? ns2.gamespy.com. (44) 08:25:27.544415 IP 192.35.51.30.domain 172.19.2.15.45505: 42289- 1/5/3 A 207.38.0.11 (229) and returned an answer with the larger TTL: dig ns2.gamespy.com ; DiG 9.2.4 ns2.gamespy.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 37167 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 7 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com.172800 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com.172800 IN NS pdns4.ultradns.org. gamespy.com.172800 IN NS pdns5.ultradns.info. gamespy.com.172800 IN NS pdns1.ultradns.net. gamespy.com.172800 IN NS pdns2.ultradns.net. gamespy.com.172800 IN NS pdns3.ultradns.org. ;; ADDITIONAL SECTION: pdns1.ultradns.net. 131158 IN A 204.74.108.1 pdns1.ultradns.net. 44758 IN 2001:502:f3ff::1 pdns2.ultradns.net. 131158 IN A 204.74.109.1 pdns3.ultradns.org. 44758 IN A 199.7.68.1 pdns4.ultradns.org. 44758 IN A 199.7.69.1 pdns4.ultradns.org. 44758 IN 2001:502:4612::1 pdns5.ultradns.info.44758 IN A 204.74.114.1 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 6 08:25:27 2008 ;; MSG SIZE rcvd: 322 but if I ask an UltraDNS server directly...it returns the correct TTL dig @204.74.108.1 ns2.gamespy.com ; DiG 9.2.4 @204.74.108.1 ns2.gamespy.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 23978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com.300 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com.300 IN NS PDNS6.ULTRADNS.CO.UK. gamespy.com.300 IN NS PDNS5.ULTRADNS.INFO. gamespy.com.300 IN NS PDNS4.ULTRADNS.ORG. gamespy.com.300 IN NS PDNS3.ULTRADNS.ORG. gamespy.com.300 IN NS PDNS2.ULTRADNS.NET. gamespy.com.300 IN NS PDNS1.ULTRADNS.NET. but unfortunately, my nameserver honors (as expected) the TTL that came back from the initial request ;; ANSWER SECTION: ns2.gamespy.com.172493 IN A 207.38.0.11 Another example would be 'gss1.foxtv.com'. I changed the IP for that server on Sunday night, and if you ask the authoritative nameservers (for IGN), they give you the correct response. However, when you do a trace, once can see that the gTLD server gives out its own info, which is not correct, and no one ever seems to get to the authoritative nameserver to get the appropriate information. -bash-2.05b$ dig +trace gss1.foxtv.com ; DiG 9.2.4 +trace gss1.foxtv.com ;; global options: printcmd . 1796IN NS f.root-servers.net. . 1796IN NS g.root-servers.net. . 1796IN NS h.root-servers.net. . 1796IN NS i.root-servers.net. . 1796IN NS j.root-servers.net. . 1796IN NS k.root-servers.net. . 1796IN NS l.root-servers.net. . 1796IN NS m.root-servers.net. . 1796IN NS a.root-servers.net. . 1796IN NS b.root-servers.net. . 1796IN NS c.root-servers.net. . 1796IN NS d.root-servers.net. . 1796IN NS e.root-servers.net.
Re: Out of Date Bogon Prefix
Nick, You might want to take a closer look at who is really bogon filtering you. Emailing their upstream providers may not be the most effective method for getting endsites to update their bogon filters. They don't have to listen to us when we forward your note on. We can't force them to accept traffic from you or update their filters. As someone else pointed out, directly contacting the folks who are filtering you may be time consuming but typically draws the best results. I agree with the other comments that if you are going to use a form letter please provide more details about the IP's you are using and your ASN. Please also pass this on to your colleagues Eric and Kevin, who I've heard from lately :) --Heather ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ Nick Downey wrote: This is an heads-up from the Mediacom Network Operations Center about an issue we are seeing. We were recently given an IP scope from ARIN (American Registry for Internet Numbers) that still exists on older Bogon lists many web providers are currently using. A Bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a Bogon range. These are commonly found as the source addresses of DDoS attacks. The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list and was blocked by all websites using a Bogon prefix up until February of 2008, when it was released by IANA (Internet Assigned Numbers Authority) for public use and an updated Bogon prefix was provided. Mediacom customers that are within this IP range are not able to reach a website hosted by many organizations. Mediacom is individually requesting that these providers update their Bogon prefix to the most current version to resolve this issue immediately. We are requesting assistance from this community to make this issue known and to advise administrators to update to the most current Bogon list. We have provided some reference material that many may find helpful in resolving this issue. Bogons are defined as Martians (private and reserved addresses defined by http://www.ietf.org/rfc/rfc1918.txt RFC 1918 http://www.faqs.org/rfcs/rfc1918.html http://www.faqs.org/rfcs/rfc1918.html and http://www.ietf.org/rfc/rfc3330.txt RFC 3330 http://www.faqs.org/rfcs/rfc3330.html http://www.faqs.org/rfcs/rfc3330.html) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority http://www.iana.org/ http://www.iana.org/. IANA maintains a convenient IPv4 summary page http://www.iana.org/assignments/ipv4-address-space http://www.iana.org/assignments/ipv4-address-space listing allocated and reserved netblocks. Please help to spread the word. Nick Downey Director Network Operations Center Mediacom Communications Main (800)308-6715 Secondary (515)267-1167 [EMAIL PROTECTED] LEGAL DISCLAIMER This E-mail and any attachments are strictly confidential and intended solely for the addressee. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender or Mediacom Communications Corporation. If you are not the intended addressee please notify the sender by return E-mail and delete this E-mail and its attachments.
RE: Out of Date Bogon Prefix
That makes sense. I am working on updating our MP. Thanks. Nick -Original Message- From: Heather Schiller [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 3:13 PM To: Nick Downey Cc: nanog@nanog.org Subject: Re: Out of Date Bogon Prefix Nick, You might want to take a closer look at who is really bogon filtering you. Emailing their upstream providers may not be the most effective method for getting endsites to update their bogon filters. They don't have to listen to us when we forward your note on. We can't force them to accept traffic from you or update their filters. As someone else pointed out, directly contacting the folks who are filtering you may be time consuming but typically draws the best results. I agree with the other comments that if you are going to use a form letter please provide more details about the IP's you are using and your ASN. Please also pass this on to your colleagues Eric and Kevin, who I've heard from lately :) --Heather ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ Nick Downey wrote: This is an heads-up from the Mediacom Network Operations Center about an issue we are seeing. We were recently given an IP scope from ARIN (American Registry for Internet Numbers) that still exists on older Bogon lists many web providers are currently using. A Bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a Bogon range. These are commonly found as the source addresses of DDoS attacks. The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list and was blocked by all websites using a Bogon prefix up until February of 2008, when it was released by IANA (Internet Assigned Numbers Authority) for public use and an updated Bogon prefix was provided. Mediacom customers that are within this IP range are not able to reach a website hosted by many organizations. Mediacom is individually requesting that these providers update their Bogon prefix to the most current version to resolve this issue immediately. We are requesting assistance from this community to make this issue known and to advise administrators to update to the most current Bogon list. We have provided some reference material that many may find helpful in resolving this issue. Bogons are defined as Martians (private and reserved addresses defined by http://www.ietf.org/rfc/rfc1918.txt RFC 1918 http://www.faqs.org/rfcs/rfc1918.html http://www.faqs.org/rfcs/rfc1918.html and http://www.ietf.org/rfc/rfc3330.txt RFC 3330 http://www.faqs.org/rfcs/rfc3330.html http://www.faqs.org/rfcs/rfc3330.html) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority http://www.iana.org/ http://www.iana.org/. IANA maintains a convenient IPv4 summary page http://www.iana.org/assignments/ipv4-address-space http://www.iana.org/assignments/ipv4-address-space listing allocated and reserved netblocks. Please help to spread the word. Nick Downey Director Network Operations Center Mediacom Communications Main (800)308-6715 Secondary (515)267-1167 [EMAIL PROTECTED] == == LEGAL DISCLAIMER == == This E-mail and any attachments are strictly confidential and intended solely for the addressee. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender or Mediacom Communications Corporation. If you are not the intended addressee please notify the sender by return E-mail and delete this E-mail and its attachments. == ==
facebook worm
Hi all. You may want to be ready for a *possible* support lines flood today. Yesterday I discovered a fast-spreading facebook worm. It spreads by sending messages to all your facebook friends, from your account, asking them to click on a link in the .pl ccTLD. This worm is somewhat similar to zlob, here is a link to a kaspersky paper on a previous iteration of it, they call it koobface: http://www.kaspersky.com/news?id=207575670 The worm collects spam subject lines from, and then sends the users personal data to the following CC: zzzping.com I spoke with DirectNIC last night and the Registrar Operations (reg-ops) mailing list was updated that the domain is no longer reachable. That was very fast response time from DirectNIC, which we appreciate. The worm is still fast-spreading, watch the statistics as they fly: http://www.d9.pl/system/stats.php The facebook security team is working on this, and they are quite capable. The security operations community has been doing analysis and take-downs, but the worm seems to still be spreading. All anti virus vendors have been notified, and detection (if not removal) should be added within a few hours to a few days. For now, while users may get infected, their information is safe (unless the worm has a secondary contact CC which I have not verified yet). It seems like some users may have learned not to click on links in email, but any other medium does not compute. Gadi.
