Re: Public shaming list for ISPs announcing other ISPs IP space by mistake

2008-08-16 Thread Michael Smith


 
 janitor.
 
 No really, the reason for some leaks isn't because so-and-so was
 never a customer, they were.  5 years ago.  nobody removed the
 routes from
 the IRR or AS-SET or insert method here and now the route is
 learned via
 some other location and it's bypassed your perimiter security and
 infiltrated your BGP.
 
 I agree, how many of you folks that use IRRs have
 ever deleted an IRR object?  Heck, some ISPs even
 add them based on existence of advertised routes.
 
 -danny
 
Even better, how many have tried to get another provider to remove legacy
objects from days gone by when someone was adding objects on your behalf?  I
have objects that date back to 1998 that are completely bogus and I can't do
squat about it.

Mike




RE: Is it time to abandon bogon prefix filters?

2008-08-16 Thread Tomas L. Byrnes
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:[EMAIL PROTECTED] 
 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 [EMAIL PROTECTED] 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  87941.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   36460.50
  174.0.0.0/7 1   0.00
  176.0.0.0/5 1   0.00
  192.168.0.0/16  74511.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
 
 
 
 



RE: Is it time to abandon bogon prefix filters?

2008-08-16 Thread Tomas L. Byrnes
In the case of routers and firewalls, managing your block lists
dynamically is akin to checking the oil. Which is something too few car
owners do as well.

It's also relatively easy to do:

shameless plug
For firewalls, I came up with ThreatSTOP to make this simple for
everyone.
/shameless plug

Team Cymru has been doing this for routers forever.


 -Original Message-
 From: Sean Donelan [mailto:[EMAIL PROTECTED] 
 Sent: Friday, August 15, 2008 10:07 AM
 To: Steven M. Bellovin
 Cc: NANOG list
 Subject: Re: Is it time to abandon bogon prefix filters?
 
 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.
 
 
 



Re: Is it time to abandon bogon prefix filters?

2008-08-16 Thread Randy Bush
 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