- Test - lists.nanog.org

Re: UUNet Routing SNAFU
by Mark Milhollan 09 Oct '97

09 Oct '97

>> What about the cable providers that have chunks of 24/8? > >62/8, 63/8 and 64/8 are being assigned now. > >So you just relax the filters according to what's being assigned. AT&T has been allocating customers from 12/8.

5 5

Re: UUNet Routing SNAFU
by Danny McPherson 09 Oct '97

09 Oct '97

> You may want to check out our configuration generation tool RtConfig in > http://www.isi.edu/ra/RAToolSet. RtConfig does a good job of generating those > 46K+ lines automatically from IRR. Generating ACLs from the IRRs and deploying the configs is no problem. Booting my router afterwards is.. -danny

1 0

Re: UUNet Routing SNAFU
by Danny McPherson 09 Oct '97

09 Oct '97

> And since I helped *create* the CA*net database *and* the CA*net route > filters based on the various DBs, yes, I meant RADB. How many providers actually apply prefix-based filtering (based on IRR objects) to other providers? I like the idea of prefix-based filtering applied to customers (by everyone that claims to be tier 1 & 2 (&3), at the very least), as well as the idea of configuring static filters for /19s and such, but if I were to build 46K++ lines of ACLs to filter prefixes from all eBGP peers for all registered prefixes (from several different registries) .. my routers wouldn't be manageable. -danny

3 2

Prefix filtering traditional A space (Was Re: UUNet Routing SNAFU)
by Mark Milhollan 09 Oct '97

09 Oct '97

>> AT&T has been allocating customers from 12/8. > >And how many routes has it been split up into? None that I can see, but I have darned limited views. I thought the thread was regarding preparation, rather than actuals.

1 0

UUNet Routing SNAFU
by prue＠ISI.EDU 09 Oct '97

09 Oct '97

At this time I am receiving a ton of bogus routes originating from AS701. This AS has hijacked all the /24 subnets of 128.1 through 128.1xx. Since the more specific route prevails in the cidr world they have managed to wipe out my network 128.9.0.0 not to mention a hundred other 128.x networks. This is not good. The third hand story I got from their hotline was that a core route crashed causing other core routers to crash. This doesn't explain anything to me. Are they using Ascend Giga routers in their core? Walt Prue

13 15

Re: UUNet Routing SNAFU
by jleddy＠mediaone.net 09 Oct '97

09 Oct '97

62.108/19 is assigned to A2000 a cable company in Amsterdam. RIPE is handing out pieces of 62/8. Please don't filter :) John Leddy MediaOne >No one is currently assigned 62/8, for example, so no one should be >announcing 62/8. > Jay B.

1 0

Filters
by Michael Dillon 09 Oct '97

09 Oct '97

>Do you have a ready pointer to a document describing Sean's filters? I suppose this should be a public answer so here goes... http://www.nanog.org/filter.html Take a moment to check out the nanog.org pages every once in a while because they do add new stuff from time to time. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************

1 0

Re: Denial of service attacks apparently from UUNET Netblocks
by Barney Wolff 09 Oct '97

09 Oct '97

Let me try again, since it seems I wasn't clear enough. There's been a lot of delightful talk about whether/how to retrieve the calling phone on a given port. But none about how to determine with confidence which port the nasty packets come from. Without source address assurance, any user on any port of any dialin box can source packets with any IP address(es) desired. So you don't know which port to go get ANI/CLID for. What is also not explained is how to produce multi-megabit streams from dialup. MP? Multiple independent calls? Ping to broadcast with faked source address? Or was the attack not from dialup at all? In other words, I don't know why this attack generated a debate about ANI/CLID. Barney Wolff > Date: Wed, 8 Oct 1997 10:33:16 -0500 (CDT) > From: Joe Shaw <jshaw(a)insync.net> > To: Barney Wolff <barney(a)databus.com> > Cc: nanog(a)merit.edu > Subject: Re: Denial of service attacks apparently from UUNET Netblocks > Content-Length: 1151 > > On Tue, 7 Oct 1997, Barney Wolff wrote: > > > Date: Tue, 7 Oct 1997 12:04:27 -0400 (EDT) > > > From: Alex Przekupowski <oop(a)idt.net> > > > > > > On the MAX's that I have set up, I log that info to syslog (Local 7), and > > > can pull it up at will. If you need a hand, just let me know. By > > > combining the syslog output, and the RADIUS accounting logs, we can > > > definately prove at least the home address of the attacker. > > > > How are you providing source address assurance, on either a MAX or a TNT? > > My understanding, which may well be flawed, is that the only way is with > > a filter. I have heard claims, which may also be flawed, that filters > > have a severe performance impact on MAX and TNT. > > > > Without source address assurance, how do you know that the packets are > > actually coming from the user who was assigned that address at that time? > > > > Barney Wolff <barney(a)databus.com> > > What he means is that he can provide the number of the person who dialed > into his equipment. That information can be given to you on your PRI, and > reported in both radius accounting and syslog. > > Joe Shaw - jshaw(a)insync.net > NetAdmin - Insync Internet Services > >

5 7

Re: UUNet Routing SNAFU
by Matt Ranney 09 Oct '97

09 Oct '97

"Dorian R. Kim" <dorian(a)blackrose.org> writes: [...] > 62/8, 63/8 and 64/8 are being assigned now. > > So you just relax the filters according to what's being assigned. So is there any good way of hearing about these new assignments as they are made so we could adjust our filters before people complain? -- Matt Ranney - mjr(a)ranney.com Let's not let the students run the High School.

6 6

Is 701 becoming 7007?
by cameo 09 Oct '97

09 Oct '97

Sometimes, in times like these, one has a hard time telling the difference. Another "router bug?" Bahaha.

1 0