North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: 69/8...this sucks

  • From: Owen DeLong
  • Date: Tue Mar 11 13:01:07 2003 
In short, it doesn't.  Longer answer, if the ISP configures his router
correctly, he can actually refuse to accept advertisements from other
sessions that are longer versions of prefixes received through this session.

However, it's primarily intended to solve the non-malicious, but somewhat
malignant problem of out-of-date bogon filters by people trying to do the
right thing.

Owen


Er, guys...  How does this fix the problem of a Malicious user
advertising a more specific bogon route?

-----Original Message-----
From: Owen DeLong [mailto:[email protected]]
Sent: Tuesday, March 11, 2003 11:22 AM
To: Stephen J. Wilcox
Cc: [email protected]
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