March 2003 - Test - lists.nanog.org

Re: Route Supression Problem
by Danny McPherson 12 Mar '03

12 Mar '03

Hrmm... Then care to take a stab at explaining the findings in the document that Randy referenced earlier? -danny > danny(a)tcb.net (Danny McPherson) writes: > > > > Dampening is done on the eBGP router where the route enters the AS, and, > > > unless I'm mistaken, per route/path and not per prefix. So the flapping > > > that ISP A sees from ISP B is a completely seperate thing from the > > > flapping that ISP A sees from its customer's customer as far as the > > > dampening algorithm is concerned. > > > > Nope. It's per-prefix. > > Nope. It is per-path. > > Pedro.

1 0

RE: 69/8...this sucks
by Ejay Hire 12 Mar '03

12 Mar '03

Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, March 11, 2003 11:22 AM To: Stephen J. Wilcox Cc: nanog(a)merit.edu Subject: Re: 69/8...this sucks > On Mon, 10 Mar 2003, Owen DeLong wrote: > >> It seems to me that it would be relatively simple to solve this problem >> by doing the following: >> >> 1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range >> of 20 ASNs to be used as BOGON-ORIGINATE. > > Why not just one or private/reserved? > Because I think there is value in each RIR having their own AS to peer EBGP with the other RIR's. I have no problem with this comming from reserved ASN space (that would be up to ICANN where they pull it from). As to private, it would have two problems. One, it would violate the RFC for private ASNs, and, two, it would likely conflict with existing internal uses of private ASNs at some carriers. >> 2. Each RIR should operate one or more routers with an open peering >> policy which will perform the following functions: >> >> A. Advertise all unissued space allocated to the RIR as >> originating from an ASN allocated to <RIR>-BOGON. >> >> B. Peer with the corresponding routers at each of the other >> RIRs and accept and readvertise their BOGON list through >> BGP. >> >> C. Provide a full BOGON feed to any router that chooses to >> peer, but not accept any routes or non-BGP traffic from >> those routers. > > Of course, configure it wrong and you would end up sending all the junk > that you would have null routed to your RIR. Sounds messy. > I think there are ways for the RIR to protect themselves from this. > Whats more I can see potential whenever we start creating these kind of > self propagating blackholes for hackers to introduce genuine address > blocks to create a DDoS. > Only if the hacker manages to own one or more of the RIR routers providing the feed. Remember, they will be configured not to listen to _ANY_ advertisement from any routers other than the other RIR routers that are known to provide equivalant service for the other RIRs. As such, assuming the RIRs run the routers with reasonable security precautions, I don't see this as being any more of a DDoS risk than any large backbone provider you can name today. >> >> >> 3. Any provider which wishes to filter BOGONs could peer with the >> closest one or two of these and set up route maps that modify >> the next-hop for all BOGONs to be an address which is statically >> routed to NULL0 on each of their routers. > > How many ebgp sessions do the RIRs need to maintain?? A lot.. and the > maintenance would be a nightmare. Dont think this will work purely > because of that overhead you create!! > Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't be full-table sessions. They'd be send-only with a small number of prefixes representing the bogon space. Also, it is possible to configure most routers to peer with "all comers" and assign the ones that don't have a specific configuration to a default peer group. That peer group would be configured to advertise-only the bogon list and accept nothing. With that configuration, the maintenance is near nil. Owen > Steve > >> Apologies if this has been discussed before, but, it seems to me that >> this is the easiest way to make the data readily available to the >> community directly from the maintainers of the databases in a fashion >> which is automatically up to date. > > There are other ways that dont use BGP peering to create lists that are > more suitable > > Steve >

10 14

RE: 69/8 problem -- Would CNN care?
by Lee Watterworth 12 Mar '03

12 Mar '03

Hi Avleen, When you start crying to the list because your new IP allocation is blocked, I'll try to be the first to tell you that "The solution here is *VERY* simple". Like it or not, the 69/8 problem *IS* operational content. If message threads containing operational content offend or disturb you in some way, I recommend that you tune in next week, when I'm sure that there will be plenty of off-topic emails for you to read. -Lee -----Original Message----- From: Avleen Vig [mailto:work@silverwraith.com] Sent: March 12, 2003 4:06 AM To: Lee Watterworth Cc: North American Noise and Off-topic Gripes Subject: Re: 69/8 problem -- Would CNN care? On Tue, Mar 11, 2003 at 02:06:49PM -0500, Lee Watterworth wrote: > Over the last few years CNN has covered many internet tech articles -- > various worms, attacks and outages. > > Think they would care to do a story on this problem? No offense Lee, but OH MY GOD, can we *PLEASE* drop this now? If 69/8 is unreachable by some people, it's REALLY NOT THAT IMPORTANT. If 10% of the internet cannot reach 69/8, then it's the problem of that 10%. I'm sure when people cannot reach it they'll eventually figure it out on their own if they don't read nanog. I really really fail to see why people are making such a big deal out of this. Yes, I agree that's it's an issue and it neds to be discussed, but that happened and was dealt with several posts ago. The solution here is *VERY* simple. If you have address space in 69/8, use it as you want to. If someone can't reach you, that's their problem. If you want to help them fix it, fine. If not, don't. But after the first few emails to NANOG, it's between you and them. Period. -- Avleen Vig "Say no to cheese-eating surrender-monkeys" Systems Admin "Fast, Good, Cheap. Pick any two." www.silverwraith.com "Move BSD. For great justice!"

2 1

69/8 is harder to fix than it looks at first glance
by Michael.Dillon＠radianz.com 12 Mar '03

12 Mar '03

> the problem is simple: outdated filters. Agreed, more or less. > the solution is simple: tell people that their filters are out of date Sorry, but this fixes nothing. It notifies people that a problem exists but it doesn't fix the filters. Several things need to be done for a lasting fix. - we need to identify where the broken filters are. - we need to find contact information for all those places. - we need to notify all the places that their filters are broken. Already, this is a heck of a lot of work and I would not describe this as a simple solution. But now the real fun begins because all of those people that were notified will reply. - some will tentatively accept your info but ask for proof that their filter is broken. - some will strongly deny that anything is wrong with their filters - some will ask what will fix their broken filter - some will ask whether your fix is short term or whether it is general enough to handle similar issues And therein lies the crux of the problem. We have no good answer to this last one other than to tell these people to change their filters today and then to regularly hunt through some mailing lists or websites to find notifications that the filters need to be changed again. And again. And again and again and again. When does it stop? The fact is that are operating these 21st century networks using 19th century business technology. This does not scale. The net is too big to be managed by person to person exchange of information. That's why we have DNS protocols instead of issuing updated copies of the hosts file. And that's why we need an automated system to publish current status of IP address ranges in a format that would be acceptable to firewall admins and firewall vendors. These people already trust LDAP enough to use it for distributing keys and certificates. IP address range attributes are similar sorts of out-of-band information that is not essential to packet forwarding but needs to be distributed in order to configure devices correctly. In this case, the attribute that we are primarily interested in distributing is whether or not an IP address range has been allocated by ARIN for use or not. But there are other useful attributes that could be distributed as well such as contact information. Let's all stop this lazy style of knee-jerk engineering that assumes all problems are simple and can be solved using a router and some PERL scripts. Some problems are hard technically and socially. These kinds of problems can only be solved if you are willing to look at the big picture as well as the immediate impacts. --Michael Dillon

2 1

Re: Route Supression Problem
by Michael.Dillon＠radianz.com 12 Mar '03

12 Mar '03

> His bandwidth then drops > to 0 for almost exactly 30 minutes (MRTG isn't an exactly graph). My guess Still using MRTG? Have you read this? http://www.mit.edu/~rbeverly/papers/rtg-lisa02.pdf Or this? http://rtg.sourceforge.net/docs/rtgfaq.html Have you checked the price of 200 gigabyte hard drives and calculated how long it would take to fill one if you were saving everything RTG could collect? Seriously, how much do you risk losing over one incident like this where you don't have the data to show your customer exactly what happened and give them the impression that you are an amazing TCP/IP guru? MRTG is utterly obsolete; replace it! http://rtg.sourceforge.net And if you can't make it to every NANOG meeting, then do check the website for useful presentations like this one http://www.nanog.org/mtg-0302/ppt/beverly.pdf --Michael Dillon P.S. considering the price of huge disk drives, I'd even consider setting up a system to capture traces of all the traffic whenever a traffic anomally occurs. That way you have even more useful info for a post mortem analysis.

2 1

Re: [Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)]
by Joshua Smith 12 Mar '03

12 Mar '03

for all of the $adjective schemes and ideas that have been posted, has anyone (besides jon and few others affected) been doing anything substanitive? outreach, more than any technical 'magic' that we can come up with, is the only 'real' solution (subjective real, what is real to me probably doesn't mean sh*t to you, but, hey, wtf). the media might be good, perhaps some online tech sites (someone with a 'big' name in networking would probably be better able to get exposure/contact than a network nobody) - there are/were some reporter-types lurking on nanog (are you out there??), if you are please help. one thing that has been mentioned is the bogon style filtering in various o/s firewall scripts. anyone thought to contact the authors of those scripts, or of the howtos on places like tldp.org? or is everyone too busy reveling in their technical grandeur.... the problem is simple: outdated filters. the cause is murkier, but lack of clue is probably the biggest, followed closely by lack of documentation on the part of previous admins (but we all document our work carefully right?!?!) the solution is simple: tell people that their filters are out of date the implementation is difficult only in terms of scale. none of us have the time to call/email or otherwise track down every admin out there, so we have to use the tools available to us (unless you really really think that reinventing the wheel again is a good thing) my $0.02 usd - this network nobody is now returning you to your regularly scheduled ego-fest joshua Richard A Steenbergen <ras(a)e-gerbil.net> wrote: > > On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote: > > > > Charles Sprickman wrote: > > > > >Seriously though, somewhere there is a popular site that is non-profit in > > >nature that would trade say a month of free access for the hassle of being > > >put into a widely-blocked block. > > > > The suggestion of putting Yahoo or Google on a 69/8 IP led me to this > > idea: > > > > Google could put their *beta* sites on a 69/8 IP, without causing them > > (Google) much Internet reachability/connectivity harm, and benefiting > > the Internet at large considerably. > > (Note to Mr. Dill, this is not intended to pick on you specifically, > it's just a convenient place to butt in) > > JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to > put random things in 69/8 space. These goals are mutually exclusive. You > can't put important stuff on broken IPs, and you can't fix broken IPs by > putting unimportant stuff on them. No one is going to move all of the root > servers to try and fix a couple outdated filters, and no one who is still > running outdated filters is going to notice it because they can't reach > Google beta sites. > > These are not just bad ideas, they are STUPID ideas. What happened to the > days when, before people posted to mailing lists, they thought "will this > make me look like an idiot in front of engineers across the entire > planet"? This is quickly not only becoming one of the most all-time > useless threads ever, but it is continuing to repell the useful people who > can no longer stand to read NANOG because of crap like this. > > Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 > was opened up it destroyed a beautiful 64/3 filter on unallocated space, > and yet somehow we all made it through just fine. The people who are > stupid enough to filter IPs without a plan on keeping those filters up to > date deserve their connectivity problems. Maybe next time they'll give > consideration to whether they actually need unallocated bogon filters on > every last linux server. :) > > -- > Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

Question concerning authoritative bodies.
by Jack Bates 12 Mar '03

12 Mar '03

Here's the background: From: "Rich Kulawiec" on Spam-L mailing list > On Sun, Mar 09, 2003 at 10:58:18AM -0600, Jack Bates wrote: > > And this is what makes DNSBLs a good deal. Mark is asking for trouble with > > his theories. If every ISP and business issues its own scans, we only > > succeed in making scanning traffic worse than spam itself at a server > > resource level. We also increase the administration factor when mistakes are > > made. Instead of contacting 3-5 DNSBLs, one must contact every ISP that > > happened to do a scan during the outage period. Centralizing scanning for > > security issues is a good thing in every way. It is the responsible thing to do. > > I must reluctantly agree. (The reluctance stems from my desire not > to intrude on others' networks. However, it's been overcome by the > reluctance to be abused by those networks.) > > Centralized, or quasi-centralized, scanning with appropriate safeguards > (to minimize frequency) and appropriate assignment of responsibility, > beats the heck out of having thousands of independent entities repeating > the same scans and thus adding to the collective misery. > > If we agree on this (and I don't know that we all do) then the debate > shifts to "who?" and "how?". > So I'm curious what people think. We have semi centralized various things in the past such as IP assignments and our beloved DNS root servers. Would it not also make sense to handle common security checks in a similar manner? In creating an authority to handle this, we cut back on the amount of noise issued. I bring this up because the noise is getting louder. More and more networks are issuing their own relay and proxy checks. At this rate, in a few years, we'll see more damage done to server resources by scanners than we do from spam and those who would exploit such vulnerabilities. I know that this is more service level than network level, except for the arguments continue to escalate over the rights of people to scan a network. These arguments would be diminished if an authoritative body handled it in a proper manner. At what point do we as a community decide that something needs to be done? Would it not be better to have a single test suite run against a server once every six months than the constant bombardment we see now? -Jack

8 15

Re: OT: Increasing Cell Phone Signal inside a NOC?
by Michael.Dillon＠radianz.com 12 Mar '03

12 Mar '03

>I'm sure a lot of people have the same problem as we are having... Our NOC and Server Equipment is located in "No Cell Phone signal" zone of our building >(It's amazing what metal walls, Server Racks and HVAC Systems will do to Cellphone Signals). I was wondering if anyone out there has found a device that >will be able to repeat the Cell Phone signal back into our NOC & Server Area's??? You need an LDAP server to fix this ;-> Uhm, if your cellphone provider supports call forwarding to another number when the phone is outside of signal range, then you could set up an in-house cordless phone system and everyone could set up their cell to forward to their cordless phone. Talk to any local company selling PBXs and office phone systems for more info on office-wide cordless phone systems. This will work because the transmitters are inside the metal walls and they can be placed to work around obstructions like HVAC or racks. --Michael Dillon P.S. of course, my first answer might have been right too... http://www.innmug.org/information/switchview.html Replace the cordless phone system with 802.11b and VOIP and some LDAP servers and this phoneset http://www.symbol.com/news/pressreleases/press_releases_wirelesslans_vo.html :-)

4 3

Increase in packet loss from the west coast
by Sean Donelan 12 Mar '03

12 Mar '03

I've been seeing an increase in packet loss across a few different providers out of San Francisco/Seattle on the west coast. Did anyone lose some transport out west?

1 0

RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
by Todd A. Blank 12 Mar '03

12 Mar '03

Wanting to continue to be a part of the solution, and not part of the problem, I just want to post publicly to the list that we would gladly donate some IP space from our ARIN direct assignment (which lives in the 69/8 CIDR) to the cause. If anyone is interested, please contact me off list. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853 -----Original Message----- From: McBurnett, Jim [mailto:jmcburnett@msmgmt.com] Sent: Tuesday, March 11, 2003 8:00 PM To: JC Dill; nanog(a)merit.edu Subject: RE: Put part of Google on 69/8 (was Re: 69/8...this sucks) Idea #2.. CNN.com-- Put some of their content.. They would probrably really enjoy the publicity.. And that would really be an educational point.. Anybody here from there??? Jim > The suggestion of putting Yahoo or Google on a 69/8 IP led me to this > idea: > > Google could put their *beta* sites on a 69/8 IP, without > causing them > (Google) much Internet reachability/connectivity harm, and benefiting > the Internet at large considerably. > > Set up a page (hopefully linked from www.google.com) that > lists all of > Google's present beta sites.

1 0