Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route?
Come on...clearly you haven't been paying attention.
You need LDAP filters. LDAP filters and a South Vietnamese revolution
against the IRRs for being fragmented and greedy.
And if that doesn't poison your inverse arp, then multiplex a private
bogon server with a centralized host scanner-based DNSBL. Don't forget the
trailing dot! And don't forget to invert the subnet mask!
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Andy Dills 301-682-9972
Xecunet, LLC www.xecu.net
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dialup * Webhosting * E-Commerce * High-Speed Access
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
So why does it need to be done by somebody "official"? Why make
organizations who don't have route servers do this?
I've been peering with Rob's bogon server for a little while, and it works
great. All of my customers get routes that point the bogons to a traffic
sink on my network. If they were so inclined, they could sink that traffic
before leaving their network.
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Andy Dills 301-682-9972
Xecunet, LLC www.xecu.net
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dialup * Webhosting * E-Commerce * High-Speed Access
Great. If you can get _EVERYONE_ to listen to Rob's server, I'm all for
it. Frankly, I was unaware of Rob's server. However, I think it makes
more sense to have the people maintaining the data distribute the data
directly from the source. Right now, I'm betting that Rob's server requires
someone in Rob's organization to keep up to date on all the RIRs and manually
tweak the contents of his list.
What is the perceived advantage to the extra layer of indirection?
Owen
Hi again, Owen.
] Frankly, I was unaware of Rob's server.
For everyone who hasn't received our copious spam. 
] Right now, I'm betting that Rob's server requires someone in Rob's
] organization to keep up to date on all the RIRs and manually tweak
] the contents of his list.
Actually it requires one server and the tireless service of cron for
most of the work. However, two of us eyeball it before any
changes are applied. Better safe than sorry.
While I agree that an "authoritative body" would be best to host
this service, I'm happy to provide it for as long as there is a need.
This is a free service, and not at all cumbersome to the members of
Team Cymru.
Thanks,
Rob.
I think Rob's server scans all the registry web pages for announced
changes and then either modifies the list automatically or sets off an
alarm to have the pages and list modified. I may be corrected but I think
the process is either entirely or mostly automated.
How???
Iljitsch van Beijnum wrote:
> 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.How???
There is a technically possible (but rather twisted) way you
could not use the adverts, but not a way to refuse receiving
them that I know of.
Consider the connection between ISP X and ISP Y.
ISP Y and is the provider who wants to null route any bogon
traffic, even if ISP X advertises a more specific route for
it.
EBGP session between 192.168.0.1/30 and 192.168.0.2/30.
ISP Y places 192.168.0.2 into VRF "X-Real".
Also in VRF "X-Real" is 192.168.1.1
Now a VRF "X-Bogon" is created containing
192.168.1.2 and 192.168.2.1.
And finally the ISP's Default-IP-Routing-Table or other general
internet VRF contains 192.168.2.2.
192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected.
(for example, create virtual interfaces on a GigE representing
each side of a pair in the relevant VRFs and then loop the
VLANs of each pair of virtual interfaces -- is there a way
to create two "paired" loopback interfaces to interconnect VRFs
rather than extending to a physical connection like I always have?)
192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router
in Default-IP-Routing-Table) communicate via IBGP route
reflection. Either dynamic or static routing can be used to
ensure 192.158.1.1 and 192.168.2.2 know the way to reach each
other.
BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon
feed, and modifies the received routes to set the next hop either
into oblivion (eg. out a loopback with no ip unreachables set and
a deny ip any any ACL) or to a some kind of DoS/worm tracking
server (since almost all of this traffic will be part of some
kind of attack or worm, and you will quite probably want to
know about it; you can also set your default route in your
regular network to such a server that records all traffic
received).
Policy routing is applied on interface 192.168.1.2 saying "set
IP default next hop 192.168.2.2" and on interface 192.168.2.1
saying "set IP default next hop 192.168.1.1".
It would work. I've done things similar to this example in a
lab to prove they work. I wouldn't want to let a configuration
like this loose on the production internet, though, and anyone
who would is probably a _Certifiable_ Cisco Internet Engineer.
David.
Iljitsch van Beijnum wrote:
>
> > 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.
>
> How???There is a technically possible (but rather twisted) way you
could not use the adverts, but not a way to refuse receiving
them that I know of.
I think youre mixing up with ingress filtering by prefix list which you can
specify prefix length on and hence ignore longer (or smaller) matches.
Steve
Stephen J Wilcox wrote:
> Iljitsch van Beijnum wrote:
> >
> > > 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.
> >
> > How???
>
> There is a technically possible (but rather twisted) way you
> could not use the adverts, but not a way to refuse receiving
> them that I know of.I think youre mixing up with ingress filtering by prefix list
which you can
specify prefix length on and hence ignore longer (or smaller) matches.
The example I provided achieved both ingress and egress filtering
based on routes in a bogon BGP feed, in a way which would even
block when a more-specific route is in the provider's BGP table.
While it didn't actually prevent the routes being in the routing
table (as I said, it doesn't provide a way to stop receiving them),
it does prevent traffic from and to the bogon locations, which is
a significant part of the reason to use bogon lists.
However, yes, it has some deficiencies[1] compared with using the
static bogon lists for route filtering (and ingress/egress); it
does not prevent routing table bloat, and it does not prevent
traffic travelling across your WAN to the point of network egress
only to be dropped.
If you want to actually not receive into your network at all the
BGP routes which match bogons, as I stated earlier, there is no
way I know of to do this via a BGP feed. The only way to do it
that I know of would be to use either a prefix list or a standard
ACL (you can do anything you can do with a prefix list with a
compiled extended ACL on BGP routes, it's just less clear to
read as an extended ACL).
Although, Owen DeLong has stated that it is possible, so maybe
we should wait for his response 
David.
[1] Apart from simply being a completely twisted design.
I'm trying to get some time to actually put it in a router and test, but
I believe there is a way to get similar functionality through a combination
of route-map entries. When I have actual router config (I'll be testing on
Cisco, but if anyone want's to provide me a Juniper testbed, I'll be happy
to try that too), I'll post it. If I can't, I'll post a public apology
and start beating on vendors to make it possible.
Owen