Deaggregating for emergency purposes

Mailman List Mirror (Read Only)
1

I am currently announcing only my aggregate routes, but I have lately
thought about the possibility of someone mistakenly, or maliciously,
announcing more specifics from my space.
The best solution for an emergency response to that (that I can think
of), is registering all of the /24's that make up my network, so if
someone should announce a more-specific, I can always announce the most
specific that would be accepted (assuming they don't announce the /24's
too, it should be a problem avoided)

Does anyone else have any other ideas on ways to quickly deal with
someone else announcing your more specifics, since contacting their NOC
is likely going to take a long time...

--Phil

2

seems a hack. what if they announce a /24 from your space and they mostly have
shorter path lengths? you still lose...

Steve

3

Seems like a remarkable waste of time and IRR resources. That is why NOCs
exist, so you can contact them quickly and make those announcements stop.

4

Advertise the /24 yourself, and 2 * /25, and hope. I had to do this recently,
due to a certain ISP in .au advertising a /24 from our space, and it actually
worked remarkably well. To their credit, the ISP were also pretty responsive
about fixing the problem.

Simon

5

I had a problem in the past with Telia announcing sub aggregates from my
space, and even after getting in touch with their American NOC, I was
told "you need to contact our NOC in Europe" When doing that, I had
difficulty finding someone who spoke English -- needless to say, it took
a few hours to get that fixed. Because I hadn't put more specifics in
the IRR, I had no choice but to just sit and deal with NOC employees who
couldn't care less.

You thing trusting another NOC with *YOUR* uptime is a better idea than
taking control?
--Phil

6

Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected

Having had this happen to me several different times, I'd have to
recommend, calling the NOC of the advertising party. as the pref'd
way of handling it.

7

But the question is, what do you do if it's coming from somewhere with a
difficult to contact NOC, and their upstream is difficult to contact as
well?

--Phil

8

I usually don't play the "what if" game, as there will always be exception, but.
... If the upstream provider is obscure, remote, or incompetent odds are their A
S path is equally obscure, remote, or incompetent. A subsection of the globe may
by holed until reasonable parties can be contacted. Advertising deaggragated ro
utes my be a viable temporary solution for misconfigurations--and other than a f
ew angelic engineers, no one would fault you--but malevolent configurations woul
d most certainly be /24. I believe a discussion once occurred here advocating BG
P authentication using some distributed source for AS verification, and while I
believe such a process is feasible, I advocate an open community in a heirarchic
al model to enforce good policy.

HMM, I swear I had a point when I started...

9

get on the bandwaggon that filtering is a good thing ?? :slight_smile:

at some point some transit is going to listen and drop the announcement.

Lets take an example. Deep Dark middle of asia, someone starts announcing
a /24 of yours. Their upstream takes the packet, and so forth. At some point
they will touch a NSP or ISP (international service provider) and you can get
things dropped their.

Your pushing out a /24 will help slurp some of the traffic towards you,
but not all.

Personally I have deagged some prefixes to cause a DOS/DDOS towards a
particular address to route down a slow connection I had. Sacrifice
one link, to keep customers running on the others. But thats different.

Its about networking, the people kind, at this point.

cheers

john brown
chagres technologies, inc

10

Yes, obscure places will feel the "pain" of their error more than others.

Personally, I haven't seen this be a real problem. Eg, not a once a month
major melt down type of an issue.

john brown
chagres technologies, inc

11

What about announcing and registering with your IRR, more-specific
routes for the period that the problem ONLY exists, instead of being
lazy?

If all else fails, break out Outlook and your favorite translator,
because last time I checked, speaking English was not a requirement
to run a network. Even if most of you do, this is not a "Majority
Rules" situation.

get on the bandwaggon that filtering is a good thing ?? :slight_smile:

at some point some transit is going to listen and drop the announcement.

Lets take an example. Deep Dark middle of asia, someone starts announcing
a /24 of yours. Their upstream takes the packet, and so forth. At some point
they will touch a NSP or ISP (international service provider) and you can get
things dropped their.

Yes. End of story. Go directly to the finish diamond at the end of
your flowchart. If the next step in your flowchart is "pollute IRRs
with 3592375238957235893275839572 /32s", please return your maintainer
object.

Your pushing out a /24 will help slurp some of the traffic towards you,
but not all.

Personally I have deagged some prefixes to cause a DOS/DDOS towards a
particular address to route down a slow connection I had. Sacrifice
one link, to keep customers running on the others. But thats different.

Yes, but you removed it later on, correct?

12

Based on my experience with the BGP misconfiguration study
http://www.cs.washington.edu/homes/ratul/bgp/index.html I can say that
this is not an idle worry. We saw about 15 hijack incidents (mostly of
more-specifics, but full prefixes too) per day. We used route-views data,
so even if hijacks come from middle of asia (some did, not all), they did
make it to the tables of some major providers.

If all else fails, break out Outlook and your favorite translator,
because last time I checked, speaking English was not a requirement
to run a network. Even if most of you do, this is not a "Majority
Rules" situation.

This too is a concern when depending on foreign nocs to take action. I ran
into many non-english speaking nocs; mainly in south america.

  -- Ratul

13

What about announcing and registering with your IRR, more-specific
routes for the period that the problem ONLY exists, instead of being
lazy?

Secondly, show me a ISP that updates their filters with IRR
data every 60 seconds. So even if you do pollute the IRRs,
it won't hit filters until the next morning, and during that
period you could have fired off 2390573295827598 e-mails to
3472398473298 of their upstreams (assuming this is a large
misconfigured network).

14

Date: Mon, 5 Aug 2002 18:41:22 -0400
From: Phil Rosenthal

Bear with me... punchline at the end.

I am currently announcing only my aggregate routes, but I
have lately thought about the possibility of someone
mistakenly, or maliciously, announcing more specifics from my
space.

The best solution for an emergency response to that (that I
can think of), is registering all of the /24's that make up
my network, so if someone should announce a more-specific, I
can always announce the most specific that would be accepted
(assuming they don't announce the /24's too, it should be a
problem avoided)

I don't think this is a valid assumption, particularly in the
case of malicious route hijacking. Polluting IRRs with numerous
deaggregated /24s for something with little/no benefit sounds
like a bad idea to me.

You advocate "s/he who dies with the shortest as-path, and oldest
routes in case of a tie, wins".

Does anyone else have any other ideas on ways to quickly deal
with someone else announcing your more specifics, since
contacting their NOC is likely going to take a long time...

Well, let's see... I wonder if this ever was a problem with
domain jacking, and what a registrar would do in a similar
scenario.

Perhaps the answer is not to hear/announce routes blindly?

First, make sure IRRs contain proper data. Maybe maintainer
objects should be authorized by an ASN's POC, and both (maint-obj
and ASN POC) require proper authorization (crypt/md5/aes or PGP).

Use the IRRs. Granted, this will be a problem at the edge; small
providers seem to take the attitude of "why should I pay to put
my routes in the RADB when things 'work just fine' without?"
Somewhere along the line, hopefully there will be an upstream or
peer that uses the route registries.

Let clueful providers cache a copy of the IRR databases. Run a
BGP listener to cross-reference routes with IRR entries. In the
event of a suspicious route, a real-time individual query might
be useful. Flag routes that fail that test.

I'll shut up now, lest I "invent" something that smellls too much
like DNS. (Gee, maybe including some sort of "ASN authorized to
advertise this IP space" in an-addr.arpa would be too easy.)

Eddy

15

Most ISPs that build off of the IRR's do it nightly. I am talking about
10 /24's out of /19, and I'm not announcing any of the /24's -- and wont
unless there is an emergency, and only then would it be temporary.

--Phil

16

You should check that your upstream router vendor can handle
the increased config size.

  You are lucky to have as much as 512k config mem on a router
let alone 2M+ as is necessary for some people that do IRR based filtering.

  This is something everyone should keep in mind doing vendor
selection these days...

  - Jared

17

Speaking of that, anyone know of the config mem size on a Cisco 6509, a
Foundry Bigiron, a Juniper M40 for example?

--Phil

18

Most ISPs that build off of the IRR's do it nightly. I am talking about
10 /24's out of /19, and I'm not announcing any of the /24's -- and wont
unless there is an emergency, and only then would it be temporary.

Yes, and during that time, you could have:
a) Gone to CompUSA and bought some translation software.
b) Installed Windows and Office XP.
c) E-mailed some friends in fluid Spanish/German/Italian.
d) Bought a $10 international calling card.
e) Gone back to CompUSA and bought some text to speech software.
f) Put it all together in an e-mail to the ISP's upstreams,
   and blasted the NOC's phone with a translated message of
   "Stop announcing 192.168.0.0/16, it is my space".

And once again, if the ISPs in question receiving the routes
actually filtered based on IRR data, the route would not have
made it in the first place, correct? So how is IRR pollution
going to help this if there's no IRR filtering policy to
begin with?

19

Date: Tue, 6 Aug 2002 13:29:58 -0400
From: Phil Rosenthal

Most ISPs that build off of the IRR's do it nightly. I am
talking about 10 /24's out of /19, and I'm not announcing any
of the /24's -- and wont unless there is an emergency, and
only then would it be temporary.

How did you arrive at 10x /24's? What about when someone else
has a shorter as-path, or it gets to "oldest route wins"?
Polluting the IRRs for little/no benefit is a bad thing.

Eddy

20

IRR pollution helps because all of *MY* uplinks filter, even if theirs
don't.
--Phil