Will do. Thanks for the input. First time posting to this board. When I get everything together, should I just resend the entire email or just the information being requested? Nick Downey -----Original Message----- From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: Tuesday, August 05, 2008 12:37 PM To: Nick Downey Cc: nanog@nanog.org Subject: Re: Out of Date Bogon Prefix 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 [..]

Please fix your mailer as it seems to be broken with respect to line-breaks and that makes reading very annoying.

The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list and was blocked by all

If you really want the block you have to be debogonized it would be handy if you: - provide the full prefix, including prefix length, and not just x.x.x - reference to the whois entry - the ASN you are announcing this from - an IP address in that prefix that replies to at least ICMP echo requests with an ICMP echo response so that people can check for you if they can reach it. The people who care about these things would love to help you, but without proper information (173.0.0.0/8 is pretty big you know), that is very impossible, and why would they spend time on resolving your problem if you don't take the nice steps to provide proper information? Please also do some work on your side, and read up on: http://www.ris.ripe.net/debogon/ Greets, Jeroen PS: Most people here know what ARIN is and they also know what bogon routes are, repeating those terms is not very clueful ;)

Thanks for the input. Currently, we are receiving 173.16.x.x /19 and /18, with plans to get additional IPs within the same range. ASN 6478 or 7018 - Through AT&T You can test access to this network by ping this gateway: 173.16.28.1 Whois information: 173.16.28.1 Record Type: IP Address OrgName: Mediacom Communications Corp OrgID: MCC-244 Address: 100 Crystal Run Rd. City: Middletown StateProv: NY PostalCode: 10941 Country: US ReferralServer: rwhois://rwhois.mediacomcc.com:4321 NetRange: 173.16.0.0 - 173.17.31.255 CIDR: 173.16.0.0/16, 173.17.0.0/19 NetName: MEDIACOM-RESIDENTIAL-CUST NetHandle: NET-173-16-0-0-1 Parent: NET-173-0-0-0-0 NetType: Direct Allocation NameServer: NS1.MCHSI.COM NameServer: NS2.MCHSI.COM Comment: RegDate: 2008-05-19 Updated: 2008-07-29 OrgTechHandle: JSE90-ARIN OrgTechName: Selvage, Joe OrgTechPhone: +1-845-695-2706 OrgTechEmail: jselvage@mediacomcc.com -----Original Message----- From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: Tuesday, August 05, 2008 12:37 PM To: Nick Downey Cc: nanog@nanog.org Subject: Re: Out of Date Bogon Prefix 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 [..]

Please fix your mailer as it seems to be broken with respect to line-breaks and that makes reading very annoying.

The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list and was blocked by all

If you really want the block you have to be debogonized it would be handy if you: - provide the full prefix, including prefix length, and not just x.x.x - reference to the whois entry - the ASN you are announcing this from - an IP address in that prefix that replies to at least ICMP echo requests with an ICMP echo response so that people can check for you if they can reach it. The people who care about these things would love to help you, but without proper information (173.0.0.0/8 is pretty big you know), that is very impossible, and why would they spend time on resolving your problem if you don't take the nice steps to provide proper information? Please also do some work on your side, and read up on: http://www.ris.ripe.net/debogon/ Greets, Jeroen PS: Most people here know what ARIN is and they also know what bogon routes are, repeating those terms is not very clueful ;)

Ya sure, like any of us would admit to 50% clue-ness. With all the posts here about bogons I would really be surprised that any nanog readers didn't know about keeping bogons updated. -- Tim Sanderson, network administrator tims@donet.com -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, August 05, 2008 2:15 PM To: Nick Downey Cc: nanog@nanog.org Subject: Re: Out of Date Bogon Prefix On Tue, 05 Aug 2008 12:16:53 CDT, Nick Downey said:

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.

Out of curiosity - what percentage of connectivity providers are both clued enough to be represented on NANOG and yet unclued enough to not understand the need to keep bogon filters up to date (even if you just get a BGP feed from Team Cymru)? (By the way, Nick - if what you sent NANOG was a form letter template, I'd lose a lot of the RFC references and point at Team Cymru's stuff instead)...

On 6/08/2008, at 4:18 PM, Patrick W. Gilmore wrote:

Switching topics only slightly: Nick, do you have any data on what parts of the 'Net you can and cannot reach? Perhaps take a dump of route-views and ping some IPs in each ASN? Shouldn't be hard to script, and might yield useful data - both to you and the rest of us.

http://www.apricot.net/apricot2007/presentation/conference/plenary3-randy-bo... is probably of interest to you. Not sure if it's been published elsewhere, or if the work has been scripted and run recently. Perhaps a monthly update would be useful? -- Nathan Ward

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

Switching topics only slightly: Nick, do you have any data on what parts of the 'Net you can and cannot reach? Perhaps take a dump of route-views and ping some IPs in each ASN? Shouldn't be hard to script, and might yield useful data - both to you and the rest of us.

tee hee. been there. done that. and for 173.0.0.0/20. paper submitted a month ago, but you saw a preso of the technique a year ago, see <http://rip.psg.com/~randy/070604.nanog-bogons.pdf>. arin has the code from us so they could put it into production if they so chose. randy

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:bicknell@ufp.org] 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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

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 matthew@eeph.com http://www.matthew.at

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

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:bicknell@ufp.org] 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?

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:joelja@bogus.com] 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.

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.

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:joelja@bogus.com] 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?

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:joelja@bogus.com] 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.

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:darden@armc.org] 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:joelja@bogus.com] 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.

I've always enjoyed your posts Michael. You are obviously an expert, with no patience for idiocy, and you always go for the throat and try to hurt the other person as much as you can. Your messages are always very entertaining. In this case, however, you are responding to a conversation that is pretty much over and done. I've already received umpty emails telling me how right I am, and another umpty emails telling me I am an idiot and I should go back to knitting. Most of the latter were privately sent, and I appreciate both their candor and discretion.... The reasonable voices seem to feel that it doesn't matter if I am right, as the real world just doesn't care. I have to agree with that. That's kinda the whole point, I think. The forward thinkers feel as you do that IPV6 is the real answer. I believe I was the first to say that in this thread. As far as the individual points that you satirize below--well ok then. We are not talking about people. I was not the person who raised people as a metric. Jump his case if you feel the need. I was actually jumping his case about it myself, albeit tongue in cheek, and hopefully with no hard feelings. However, the original conversation centered on the best way to design private networks so that internetworking between companies who did not confer on eachothers' network design does not cause problems, and how very few companies follow RFC1918 very well in my experience. Whether they fail at RFC1918 for real reasons or not, they still fail. As far as companies that design their own networks so they have trouble interoperating with themselves--well, bummer for them. I bet they wish they had done their design more efficiently instead of making "large sprawling" networks with plenty of room for growth for soda machines. Because you just can't assign enough IP address space for your soda machines. "Cute sound bites does (sic) not make you an expert in anything. " I agree with this too. But just because it's cute, doesn't mean it's wrong. --Patrick Darden michael.dillon@bt.com wrote:

...

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?

You don't seem to understand how IPv4 networks are designed and how that interacts with scale, i.e. the large sprawling networks that international enterprises have. You don't simply count out x addresses per employee. Instead, you design a subnet architecture that a) can grow at all levels, and b) can be cut off the network when you sell off a branch operation or two.

This leads to large amounts of IP addresses used up in padding at all levels, which then leads to these organizations running out of RFC 1918 space, a more and more common occurence. This, in itself, is a good incentive to move to IPv6, since the seemingly wasteful subnet architecture is considered best practice with IPv6, and a ULA prefix or two gives you lots of space to keep growing.

...

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?

Nope. We are not talking about people, but about network architecture and topology. Two people in one office need two addresses. Put them in separate offices and they need two subnets. Topology dominates the design.

...

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.

I believe the first two companies to run out of RFC 1918 space (or to project that it would happen) are Comcast, and American cable provider in one continent, and a Japanese cable provider on a small Pacific island next to China.

...

//Err. Doing it wrong does not justify doing it wrong.

Cute sound bites does not make you an expert in anything.

In any case, IPv4 is yesterday's news. Nowadays everyone is scrambling to integrate IPv6 into their networks and shift services onto IPv6.

--Michael Dillon

Hi Jay, Jay R. Ashworth wrote:

You really think Michael is malicious in his intent? You've spent a whole lot of time paying now attention around here, haven't you?

I think Michael tends to get confrontational. As, apparently, do you. I'm on a lot of the same lists Michael is on. Have been since 1997. I have a lot of respect for him, with reservations gathered from experience. He is sharp, and he has a sharp tongue.

No, cute soundbites don't make you an expert.

But in this case, Dillon's right, and you're wrong: your attempt to trivialize the specific issue on point (allocation within the 1918 space internal to a company network) by implying that the only reasons to do it the way he suggests amount to "leaving space for soda machines" only proves in public that you don't know what you're talking about.

No, you are wrong. Your attempt to trivialize what I have to say by calling it cute only proves that you don't know what you are talking about. Bad logic, isn't it? Statement that you are wrong, then "proving it" with nonsense addressing someone's character without addressing the point.... Your mislabelling my tongue-in-cheek ongoing obsession with soda machines as Trivializing only proves you have no sense of humor. I remember when some kids at MIT first put their dorm's soda machine on the internet. Man that was cool. You could ping it and find out how many cokes were left, and their temperature....

As randy would put it, I encourage my competitors to hire you to architect their WANs.

Thank you. Your bile does you credit. --Patrick Darden

Hi Jay, Jay Ashworth:

Sure. And he's not always right either; none of us are. But he gave cogent arguments to support his point, and you gave us

He gave good arguments. You, however, did not.

None of which amounts to "wants to hurt people", which is what you accused him of.

I was out of line here. I apologize to Michael. I don't think he took offense, but if he did I genuinely regret it.

And yet I see tha tyou don't yourself bother to try to prove your argument; you merely continue to go after Michael and I on peripheral points. No pun intended.

Didn't have to: you didn't address anything other than personal or peripheral stuff.

Sure. Online coke machines are just about as cool as coffee-pot webcams.

They were in 1995. Back when the first one went online. That was too cool for me to express.

But they're orthogonal to the discussion that was at hand, and your returning to that well in the middle of a serious discussion suggests that you, yourself, are not all that serious.

Or perhaps that I was trying to cool the discussion down a bit. I had already tried to bring it to a close once.... It was an extended hyperbole of ridiculousness. Soda machines. MMMMMMMMMmmmmmmmmm.

Once is tongue in cheek. Twice or three times is dilettante.

No, I think it just proves that saying the same stupid joke three times doesn't make it funny. Doesn't mean I am a dilettante network operator. Just means I'm not funny. ;-)

I don't know, Patrick; you seem to be the one emotionalizing the argument.

Yeah, I have a sharp tongue too. And I am a dillettante. And everything I say is just so cute and precious. And I am Wrong.

I'm out of this one though; we are certainly out of AUP.

I'm with you on this, for sure. If you want to address me off-list please feel free. --Patrick Darden

On Wed, Aug 06, 2008 at 09:36:05AM -0700, 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).

I'm certain that wasn't the intent of 1918, from the "random" wording.

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?

My network serves around 300 machines and employees, and uses 10.10/16, though very sparsely -- we do indeed subject one /24 per function. The *point* though, is that it's 10.*10*. Another client is using 10.55.storenumber with one /24 per store. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

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

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!");

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

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.

Hi Randy, .-- My secret spy satellite informs me that at Thu, 07 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?

I did some measurements in The Netherlands (SURFnet) using netflow around 1,5 years ago. During this project around 86 million 'Bogon flows' were analyzed. This was not more then 0.1% (probably even lower) of all flows during that 1 week period. The majority of these flows were actually from/to RFC1918 address space. One of the things (amongst others) we looked at was SMTP traffic from / to bogons, to verify the theory that spammers announce a bogon prefix to sent spam. From the 86 million bogon flows analyzed, 12 SMTP flows were found, very minimal. Other things we looked at, were type of traffic (applications) & protocols and the sources of those flows. We saw some strange (interesting) things, but that was really just a few flows in many many many milions of flows. Anyways, if you're interested the research report can be found here: http://www.toonk.nl/bogon-traffic-analysis.pdf There's also a presentation http://www.toonk.nl/presentations.php Cheers, Andree -- Andree Toonk http://www.toonk.ca/blog/

bogon block attacks % of attacks 0.0.0.0/7 65 0.01 2.0.0.0/8 3 0.00 5.0.0.0/8 3 0.00 10.0.0.0/8 8794 1.21 23.0.0.0/8 4 0.00 27.0.0.0/8 7 0.00 92.0.0.0/6 101 0.01 100.0.0.0/6 374 0.05 104.0.0.0/5 303 0.04 112.0.0.0/5 775 0.11 120.0.0.0/8 45 0.01 127.0.0.0/8 6 0.00 172.16.0.0/12 3646 0.50 174.0.0.0/7 1 0.00 176.0.0.0/5 1 0.00 192.168.0.0/16 7451 1.02 223.0.0.0/8 10 0.00 224.0.0.0/3 8 0.00

well, we can see why andree wanted to look behind the 1918 stuff. it is the elephant. thanks, danny! randy

In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change.

my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space. randy

Randy Bush <randy@psg.com> writes:

...

In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change.

my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space.

so is there any case to be made for filtering bogons on upstream/peering ingress at all anymore? (this discussion is orthogonal to bcp38/urpf, which i think we all agree is a good thing and would be great if we could get it further deployed) ---rob

On Fri, 15 Aug 2008, Robert E. Seastrom wrote:

so is there any case to be made for filtering bogons on upstream/peering ingress at all anymore?

Depends on where and how. On highly managed routers at highly managed interconnection points around the Internet, having some basic packet hygiene checks can serve as a "fire breaks" to keep the effectiveness of large scale attacks with reserved/unallocated address low. Unlike BCP38/uRPF/SAVI, it doesn't need 100% deployment; just enough to make it less attractive as an attack vector compared to other things. Even within a single provider, you might not deploy it everywhere. Maybe just between different continents or regions, depending on your hardware and operational capabilities. For highly managed routers, operational management of allocation updates is more limited because you only need to keep track of IANA changes (or use some of Team Cymru's tools) rather than figure out which peer or customer is authorized to use unallocated source addresses. Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a "default" in anything, i.e. Cisco's auto-secure).

(this discussion is orthogonal to bcp38/urpf, which i think we all agree is a good thing and would be great if we could get it further deployed)

I agree.

...

Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a "default" in anything, i.e. Cisco's auto-secure).

You make a very good point about the difference between routers that are being routinely maintained by highly clueful people and routers that are in the field and untouched/unloved for months to years at a time.

in the field != untouched/unloved i contend that all one's routers should be rigorously configured as programmatically as possible. randy

Randy Bush <randy@psg.com> writes:

...

...

Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a "default" in anything, i.e. Cisco's auto-secure).

You make a very good point about the difference between routers that are being routinely maintained by highly clueful people and routers that are in the field and untouched/unloved for months to years at a time.

in the field != untouched/unloved

That's why I used the conjunction "and".

i contend that all one's routers should be rigorously configured as programmatically as possible.

Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs. As smb so eloquently just asserted, "availability is a security issue too". -r

Randy Bush <randy@psg.com> writes:

...

Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs.

and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved.

I agree 100%, I'm just acknowledging reality and suggesting that we should not promulgate practices which don't take into account the skew between best-implementation-and-followthrough and oversight-by-PHB. -r

On Fri, 15 Aug 2008, Steven M. Bellovin wrote:

...

and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved.

That, I think, is why he distinguished between routers run by "highly clueful people" and routers run by others. I think we all agree on your basic point; it's just that too many people aren't clueful enough to realize that they even have a problem, let alone know how to solve it. (Of course, you and I both have a background in programming languages and compilers, which is why we naturally think of router configurations as a form of assembler language that only a compiler should every emit.)

To avoid people feeling individually insulted, I sometimes try to distinguish between the purposes of equipment rather than the capabilities of the person maintaining it. A NASCAR racing team may perform extensive monitoring and maintenance on their racing cars; but that doesn't mean I should need a team of 5 mechanics to keep my regular street car operating safely with a few idiot lights on the dashboard.

Robert E. Seastrom writes:

Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs. As smb so eloquently just asserted, "availability is a security issue too".

This is particularly but not exclusively true if they are implementing an "overhead" function - i.e., if they are not directly in the money-generating path. If they are, they at least have some chance at getting some attention when not on fire. Otherwise, they will likely be ignored until failure. Joe

...

i contend that all one's routers should be rigorously configured as programmatically as possible. What sort of tools do you use to facilitate this?

ntt/verio, level(3), ... have sophisticated locally developed systems. they see these as competitive advantage, so sharing is extremely unlikely. and, as they are home grown, they likely do not have a portable layer of indirection to corporate back-end data. some large telcos seem proud that "the network is the database of record" and are proud of it. i wish all my competitors thought that. for my own use, i use m4, python and perl, and peval() randy

On Mon, Aug 18, 2008 at 09:51:20AM +0100, michael.dillon@bt.com wrote:

m4 is a macro processor that you probably should not bother learning since you can do everything that it does by using Python

Oh, Abley is gonna have fun with this... and for the record, my money is on Joe. He could probably implement python *IN* m4 if you offered enough beer! --Jeff

On Fri, 15 Aug 2008 09:49:38 -0400 (EDT) Sean Donelan <sean@donelan.com> wrote:

On Fri, 15 Aug 2008, Randy Bush wrote:

...

my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space.

Although I've disagreed with Rob about the configuration of bogon filters, especially on unmanaged (or semi-managed) routers, it is important to remember attacks and bogus packets are not naturally occuring phenomenon. The attacker chooses the attack vector and target, usually based on effectiveness and vulnerability but often on ease for the attacker.

Packet and especially source address hygiene can be very useful for highly managed equipement. However, bogon filters have often become more a source of recurring security consultant maintenance revenue than effective packet controls. Understanding the operational maintenance demands is also an important part of implementing good security controls.

For unmanaged and semi-managed routers, I'd suggest strict out-bound packet controls (i.e. be conservative in what you send) because you already need to make operational updates when they change. But consider using inbound controls that require less extensive recurring maintenance, e.g. only filtering martians (i.e. 0/8, 127/8, 255.255.255.255/32, etc) instead of updating bogons (i.e. changing reserved and unallocated) every few months.

Martians plus 1918 space, I'd say, though that requires knowing which are border interfaces. Other than that, I agree 100% -- bogon filters have little security relevance for most sites. Furthermore, as the allocated address space increases, the percentage of actual bogon space decreases and the rate of false positives -- packets that are rejected that shouldn't be -- will increase. Security? Remember that availability is a security issue, too. --Steve Bellovin, http://www.cs.columbia.edu/~smb

as a mutual friend who pretends he does not read nanog emailed privately "rfc1918 filters, like bcp38 filters, could be construed as topological assertions rather than bogon filters per se. certainly they are for edge routers, but even in the dfz, "i don't think we're in rfc 1918 space anymore, toto."" randy

Robert E. Seastrom wrote:

"Steven M. Bellovin" <smb@cs.columbia.edu> writes:

...

Security? Remember that availability is a security issue, too.

It never ceases to amaze me how many "security people" walk around oblivious to this basic notion.

But of course! The most secure object is one nobody knows about and can't get to anyway. That is the whole point!

Since there are ways to dynamically filter the bogons, using BGP or DNS, I don't really see the need to stop doing so. If you're managing your routing and firewall filters manually, you have bigger problems than the release of Bogon space. It's not just the number of attacks that is the issue, but the potential severity of them. Traffic sourced from Bogon space (REAL Bogon space) is 100% guaranteed to be traffic you DON'T want to receive. It could be advertised bogon space, in which case it is likely criminal, and thus something you REALLY don't want to see. Prioritization of defense effort is based on a product of probability and severity divided by a factor that takes the cost and unfavorable consequences of the mitigation strategy into account. For any given threat, you can choose methods that decrease or increase any factor, and address those with the highest payoff first. An example would be Thermonuclear attack: low probability, very high severity, with fairly significant cost and unpleasant side consequences, yet the result, total annihilation, is so high that we have ICBMs, Submarines, Bombers, and ABM technology, which taken together cost a lot more than the efforts spent on blocking SPAM, which is very probable, but unlikely to kill anyone. Applying Bogon filters, using dynamic sources, is a very low cost way to block attacks that can be of high severity, while unlikely to have adverse consequences, and so is a BCP. Filtering RFC1918 space at the edge has always been a BCP, independent of Bogon filters. You neither want to accept if from outside, or let any of yours leak. That should be part of the static filter set/null route table in any router.

-----Original Message----- From: Robert E. Seastrom [mailto:rs@seastrom.com] Sent: Friday, August 15, 2008 5:23 AM To: Randy Bush Cc: NANOG list Subject: Re: Is it time to abandon bogon prefix filters?

Randy Bush <randy@psg.com> writes:

...

...

bogon block attacks % of attacks 0.0.0.0/7 65 0.01 2.0.0.0/8 3 0.00 5.0.0.0/8 3 0.00 10.0.0.0/8 8794 1.21 23.0.0.0/8 4 0.00 27.0.0.0/8 7 0.00 92.0.0.0/6 101 0.01 100.0.0.0/6 374 0.05 104.0.0.0/5 303 0.04 112.0.0.0/5 775 0.11 120.0.0.0/8 45 0.01 127.0.0.0/8 6 0.00 172.16.0.0/12 3646 0.50 174.0.0.0/7 1 0.00 176.0.0.0/5 1 0.00 192.168.0.0/16 7451 1.02 223.0.0.0/8 10 0.00 224.0.0.0/3 8 0.00

well, we can see why andree wanted to look behind the 1918 stuff. it is the elephant.

thanks, danny!

randy

In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change.

What's the operational cost trade-off with going after that remaining 7.9%? I'll betcha it's not justifiable. Maybe it's time to change the best current practices we recommend so that they stop biting us in the ass every time a chunk of our ever-dwindling pool of unused address space goes into play.

My uncle used to tell this joke:

Q: Why did the man hit himself in the head with a hammer? A: Because it felt so good when he stopped?

-r

ACLs

-----Original Message----- From: Pete Templin [mailto:petelists@templin.org] Sent: Sunday, August 17, 2008 5:57 PM To: Tomas L. Byrnes Cc: NANOG list Subject: Re: Is it time to abandon bogon prefix filters?

...

Since there are ways to dynamically filter the bogons, using BGP or DNS, I don't really see the need to stop doing so. If you're managing your routing and firewall filters manually, you have bigger

Tomas L. Byrnes wrote: problems

...

than the release of Bogon space.

Can you share the Cisco configuration snippet you recommend to dynamically FILTER bogons using BGP or DNS? Not just inserting null-routes for the bogon aggregates, but preventing the acceptance of more-specifics that transits/peers/customers have managed to sneak past someone's filters (or lack thereof), please.

(Without an offline configuration generator, I postulate that it can't be done.)

pt

On Sun, Aug 17, 2008 at 07:57:25PM -0500, Pete Templin wrote:

Tomas L. Byrnes wrote:

...

Since there are ways to dynamically filter the bogons, using BGP or DNS, I don't really see the need to stop doing so. If you're managing your routing and firewall filters manually, you have bigger problems than the release of Bogon space.

Can you share the Cisco configuration snippet you recommend to dynamically FILTER bogons using BGP or DNS?

On a router with full routes (ie: no default) the command is: Router(config-if)#ip verify unicast source reachable-via any Go ahead and try it out. you can view the resulting drop counter via the 'show ip int <x/y>' command. While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

Jared Mauch wrote:

...

On a router with full routes (ie: no default) the command is:

Router(config-if)#ip verify unicast source reachable-via any

None of these suggestions (including the wisecrack "ACLs") provide full filtering:

If a miscreant originates a route in bogon space, their transit provider(s) doesn't filter their customers, and you or your peer/transit doesn't filter their peers/transits, your router will accept the route in bogon space and will accept the bogon packets. Filtering has not been accomplished, and the bogon attack vector remains open.

Rather than hoping that everyone filters their customers or that all of my transits filter every peer, if I want to protect my network from bogon packets, I need to ensure that my routers won't accept any prefixes in bogon space. The Team Cymru BGP feed does NOT provide this function; it merely provides a way to inject null routes for bogon aggregates. I think you misunderstand the meaning of the "ip verify unicasr source reachable-via any" command. When a packet arrives the router will drop it if it doesn't have a valid return path for the source. Since the

Pete Templin wrote: source is a bogon, and routed to Null0, then the inbound packet is dropped. Sam

Once upon a time, Sam Stickland <sam_mailinglists@spacething.org> said:

I think you misunderstand the meaning of the "ip verify unicasr source reachable-via any" command. When a packet arrives the router will drop it if it doesn't have a valid return path for the source. Since the source is a bogon, and routed to Null0, then the inbound packet is dropped.

First, that is only true on Cisco routers (all the world is not a Cisco). Second, you are missing the point: you have bogon route for 10/8, but rouge route for 10.1/16 (or even 10.0/9 and 10.128/9) arrives; it is more specific and your automatic bogon filter is useless. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On Aug 18, 2008, at 6:33 AM, Jared Mauch wrote:

On a router with full routes (ie: no default) the command is:

Router(config-if)#ip verify unicast source reachable-via any

Go ahead and try it out. you can view the resulting drop counter via the 'show ip int <x/y>' command.

While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops.

That's a good point. My problem with "loose mode" RPF is that it subjects a packet's source address to ANY FIB entry existence only mitigates spoofing of non-routed ranges. All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action. -danny

You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. This is usually VERY BAD traffic, and EVEN WORSE if a user goes TO a site hosted in such IP space. So, Bogon filtering has value beyond mere spoofed source rejection.

-----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Thursday, August 21, 2008 5:19 PM To: NANOG list Subject: Re: Is it time to abandon bogon prefix filters?

On Mon, 18 Aug 2008, Danny McPherson wrote:

...

All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action.

Yep. Same thing with bogon filters. Any attacker which can source packets with bogon addresses, can by definition, source packets with any "valid" IP address too. Great as an academic exercise, but the bad guys are going to send evil packets without the evil bit nor using bogon addresses. If the bad guys are using spoofed addresses, they don't care about the reply packets to either valid or unallocated addresses.

However, seeing packets with unallocated IP addresses on the Internet is evidence of a broken network. Just like when a network trips "max prefix" on a BGP session, shouldn't a broken network be shutdown until the problem is fixed. If you don't want to risk your network peers turning off the connections, make sure your network doesn't source spoofed packets.

Valdis.Kletnieks@vt.edu wrote:

On Sun, 24 Aug 2008 23:21:23 PDT, "Tomas L. Byrnes" said:

...

You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so.

But if you've seen a BGP announcement with a prefix that covers the source, is it really a bogon anymore?

IIRC "bogon" is specific to unallocated space. Whether it be advertised or not should not matter. Regards, Chris

On Sun, 24 Aug 2008, Tomas L. Byrnes wrote:

You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so.

This is usually VERY BAD traffic, and EVEN WORSE if a user goes TO a site hosted in such IP space.

So, Bogon filtering has value beyond mere spoofed source rejection.

Unmanaged (or semi-managed) routers probably should not be running BGP or other exterior routing protocols. Unmanaged routers with BGP provide more opportunities to create havoc and mischief.

On Tue, 19 Aug 2008, Kevin Loch wrote:

...

While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops.

Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change.

Strict uRPF (feasible paths variant, RFC3704) works just fine with multihomed customers here. But we don't allow TE more specifics either from the customer or from peers, so the longest prefix matching doesn't get messed up. And with certain kind of p2p link numbering, you may need to add a dummy static route. But it works. For more see especially Section 3 of: http://tools.ietf.org/id/draft-savola-bcp84-urpf-experiences-03.txt (comments are also welcome.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Aug 20, 2008, at 7:00 AM, Kevin Loch wrote:

It doesn't look like the feasible paths rpf handles the situation where your bgp customer is not announcing all or any of their prefixes to you. This can be done for TE or debugging an inbound routing issue. Announcing prefixes to me and then blackholing the traffic is not something I would appreciate as a customer.

If you do this (or strict rpf) on BGP customers at least warn them up front that if they ever stop announcing prefixes to you then traffic they send you will get dropped.

Clueful BGP admins know how to send their routes with no-advertise on them. There are fairly good reasons to require your direct customers always advertise their routes to you, even if you won't be readvertising them. uRPF is one. Not paying transit both inbound and out for multi- gig DoS attacks is my favorite. Etc. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote:

On Tue, 19 Aug 2008, Kevin Loch wrote:

...

...

While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops.

Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change.

Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok?

Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets.

If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say "Be careful if you are a using source IP addresses without informing your upstream."

In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface?

I certainly believe that this is the trap people fall into. I can't manage it, nor do I want to spend the effort telling my provider, peer, etc.. that I stole their customer from them, so I'm better off making the global network less secure. With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

In article <ABD7F391-84FE-4DC2-997F-04E0D6DE327E@multicasttech.com> you write:

On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote:

...

On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote:

With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value.

If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge.

this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have?

My Bank (Bank of America) put in something to mitigate against this about 2 years ago (IIRC), so they were clearly anticipating something like this. Not only do you have to verify that you are you, you also have to verify that the bank is the bank.

Regards Marshall

While some people with some protocols have solutions to detect when the communication path has been compromised. Not all people with all protocols have a solution to this problem. There is no panecea to this problem, however *everyone* should do their best to reduce the problem. Any operator not implemting BCP 38 is potentially aiding and abetting some criminal. BCP 38 is over 10 years old. There is no excuse for not having equipment in place to handle the processing needs of BCP 38. Mark

...

If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation.

- Jared

On Aug 7, 2008, at 2:04 PM, Pete Templin wrote:

Patrick W. Gilmore wrote:

...

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 :).

How can you recommend Team Cymru, when their product is not in any way a filter? It is merely an automated method of injecting aggregate null routes for bogons, but in no way prevents a network from accepting aggregate or specific bogon announcements (i.e. it does not _filter_).

HUH? Team Cymru offers many ways to set up filters, null routes, etc. See <http://www.team-cymru.org/Services/Bogons/

.

Oh, and to answer Randy's question about how much actually comes from bogons, on that same page: <quote> How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.). A presentation based on that study, entitled "60 Days of Basic Naughtiness," can be viewed here. Your mileage may vary, and you may opt to filter more conservatively or more liberally. As always, you must KNOW YOUR NETWORK to understand the effects of such filtering. </quote> I guess that means filtering bogons is useful. -- TTFN, patrick

...

How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) Stated another way, you can get 60% success on bogon filtering by ignoring the free pool

if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more /8s in the bank then we thought, eh? :) btw, patrick neglected the last sentences of that paragraph, which made me wonder what rob would actually say. luckily, in response to my post, rob replied that he/they would try to get some useful measures in the near term. i am patient. but your post makes me inclined to beg that he/that he have a few taxa within the bogon space. randy

On Aug 7, 2008, at 5:35 PM, Robert E. Seastrom wrote:

Randy Bush <randy@psg.com> writes:

...

...

...

How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.)

Stated another way, you can get 60% success on bogon filtering by ignoring the free pool

if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more / 8s in the bank then we thought, eh? :)

I guess I didn't really word that clearly.

My point was that by not including the free pool in your candidates for filtering (i.e., only filtering out packets from addresses that will never be allocated or are permanently reserved such as 1918 space), you're only sacrificing 40% of your likely hits... and that number is going down over time. Why not just cut to the chase and make a filter that will never go stale, take any possible lumps on the bogus packet announcement side, and collect handsomely on the operational side?

I guess I parsed that differently than you did. When he said "fully 60% of the naughty packets were obvious bogons", I read that as meaning 60% of all bad packets (bogon-sourced or otherwise) were from bogon space. If my interpretation is correct, you cannot tell anything about which % was from permanently bad space vs. unallocated space. Rob T., could you clarify for us please? Also, filtering bogons has the same utility / dangers of MD5. Many people think MD5 is a "good thing", even though the amount of downtime caused by it is (at least) several orders of magnitude larger than the amount of downtime caused by successful RST attacks. I think the danger outweighs the benefit. If you are arguing the same thing here, that's fine with me. But let's find out what the danger is and make the decision. Oh, and then everyone should take their own advice and de-configure MD5. :-) -- TTFN, patrick

Hi, NANOG (he says with a shout)!

btw, patrick neglected the last sentences of that paragraph, which made me wonder what rob would actually say. luckily, in response to my post, rob replied that he/they would try to get some useful measures in the near term. i am patient.

Yep yep, have some results at last. Sorry, the queries took a bit longer than planned. Note that the study I conducted which populated the "60 Days of Basic Naughtiness" presentation is now years old. Such studies, like me, don't necessarily age well. :) This is not meant to replace a more comprehensive and clueful study by the likes of Vern, Stefan, and the CAIDA crew. As folks may know we have a large Darknet[1] project. In there we collect the scanning activity of malware, backscatter, and the like. Often we can tie the scanning pattern to a family of malware or maltool. If the source of a scan or probe is a bogon, we tag it that way in our data store. I went back to 2008-01 and found the following percentages of bogons in our data: 2008-01: 0.001095262% 2008-02: 0.001759343% 2008-03: 0.001619555% 2008-04: 0.001433908% 2008-05: 0.001182351% 2008-06: 0.130534559% 2008-07: 0.002327683% 2008-08: 0.001258054% (thus far) That's not a lot of bogon activity in the Darknets, though Darknets are only one measure of malevolent traffic. Your mileage may vary, etc. [1] <http://www.team-cymru.org/Services/darknets.html> Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!");

* randy@psg.com (Randy Bush) [Fri 08 Aug 2008, 00:59 CEST]:

rob,

...

If the source of a scan or probe is a bogon, we tag it that way in our data store. I went back to 2008-01 and found the following percentages of bogons in our data: [..] 2008-08: 0.001258054% (thus far)

this is an extremely far cry from 60%. what am i not understanding?

and can you separate reserved (127, ...) and unallocated?

This is scanning of darknets - usually you're interested in what comes back, i.e. can you 0wn it? so src has to be valid. (D)DoS of course are much more likely to come closer to the 60% number. No need to get the SYN+ACKs or the ICMP echo replies back... -- Niels.

Hey, Randy.

this is an extremely far cry from 60%. what am i not understanding?

There are a few factors at work here. One, the 60% figure was from 2001-03-16. There were more bogons then, and our sundry measures saw a lot more malevolence from bogon space. A popular belief in the underground in 2001 was that spoofing in general, and the use of bogon space specifically, added a layer of protection for their collections of compromised hosts. In the age of masses of compromised routers, servers, and workstations, that's no longer a necessary defensive measure. At circa US $.04 each, bots are easily replaced. Compromised routers don't cost much more than that. Two, we really can't compare the two (time issues aside). The 60% figure came from a study of a frequently (as in daily) attacked web site. The figures I shared today came from our Darknets, which are more global and not limited to a certain type of service or site owner. Third, that site has been split into multiple sites (after about 2005) so unfortunately I can't easily reproduce the study from 2001. That is a real bummer. So I'm not comparing apples and apples. We also track DDoS attacks, malware propagation, and other Internet malevolence. As a shot from the hip, I'll say we see very little abuse from bogon IP space. I won't say we see no abuse from bogon space, however, so we keep bogons automatically filtered on our border. I like to keep the online criminal toolkit as sparse as I can. :)

and can you separate reserved (127, ...) and unallocated?

I can indeed, though it'll take me a bit to do so. Again, stay tuned. Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!");

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 actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs

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 C&C 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

That makes sense. I am working on updating our M&P. Thanks. Nick -----Original Message----- From: Heather Schiller [mailto:heather.schiller@verizonbusiness.com] 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 ndowney@mediacomcc.com

====================================================================== ====== ================================================================ 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. ====================================================================== ====== ================================================================