Who is announcing bogons?

David Luyer david at luyer.net
Tue Apr 29 13:00:26 UTC 2003


> Ahhh, but that was not the correct question to ask (I have not read the
> study). It is not whether ISP's filter inbound customer route 
> announcements. It is how they filter them. If the customer goes and 
> says I am going to announce 4.0.0.0/8  and the ISP just blindly adds
> that to the filter, we have a problem, but the ISP did answer that
> question truthfully. They are filtering.

That's one important question, but another other question is, are _ALL_
customers prefix filtered?  How about major peers?  Sure, the default,
new, small customer is prefix filtered.

In 2000 -- the same year that study was done -- we were adding prefixes
so quickly that iHug unfiltered us, and EPOCH unfiltered iHug, to prevent
the need for us to notify them of every single route change.  At any one
time we only had around 150 prefixes maximum - there's just a lot of 203.*
space which goes back and forward between ISPs in Australia resulting
in a lot of filter updates.

_After_ our circuit had been disconnected from iHug, for a brief period
long before 66.0.0.0/8 was allocated, I tested pushing the /8 to their
BGP peer we had in the US (multihop BGP as it was a satellite service).

In theory:

   0.  Our BGP session should have been shut down anyway, when our
       satellite service was cancelled
   1.  Bogon filtering would catch it
   2.  Anyone using RADB would catch it
   3.  It wouldn't get far as no major network would pick it up

The result - all test sites I tried either saw the route, or default routed
to
someone who saw the route.

Here's an example of the non-optimal route taken from one site, but the fact
is it still made it to hop #16, after which it would have gone to us if our
satellite PVC was still active, and just from this example AARNet, Optus,
UUnet, BBN, EPOCH, Netgate and iHug all in some way would reach that clearly
bogus advertisement.  Which says to me that at least in 2000, the big guys
weren't even applying simple bogon filters on routes received between each
other.

typhaon; traceroute 66.0.0.1
traceroute to 66.0.0.1 (66.0.0.1), 30 hops max, 40 byte packets
 1  muchacho.uwa.edu.au (130.95.128.128)  1.515 ms  0.88 ms  1.702 ms
 2  parnet-uwa.parnet.edu.au (203.19.110.17)  2.848 ms  2.664 ms  2.353 ms
 3  ATM9-0-0-2.ia5.optus.net.au (192.65.88.189)  57.681 ms  57.819 ms
59.205 ms
 4  GigEth12-0-0.rr2.optus.net.au (202.139.191.22)  57.83 ms  57.787 ms
57.658 ms
 5  POS5-0-0.la1.optus.net.au (192.65.89.214)  368.02 ms  367.933 ms
368.018 ms
 6  34.ATM0-0-0.GW1.LAX4.ALTER.NET (157.130.227.181)  373.831 ms  373.879 ms
374.79 ms
 7  121.ATM3-0.XR2.LAX4.ALTER.NET (146.188.248.110)  375.665 ms  374.306 ms
373.71 ms
 8  193.at-1-1-0.TR1.LAX9.ALTER.NET (152.63.112.174)  373.284 ms  373.43 ms
372.938 ms
 9  131.at-5-0-0.TR1.DFW9.ALTER.NET (152.63.3.161)  408.254 ms  429.138 ms
404.189 ms
10  289.at-1-0-0.XR1.DFW9.ALTER.NET (152.63.98.29)  404.381 ms  407.777 ms
410.8 ms
11  185.ATM6-0.BR3.DFW9.ALTER.NET (152.63.100.169)  406.129 ms  404.228 ms
404.08 ms
12  137.39.93.10 (137.39.93.10)  433.381 ms  415.909 ms  413.664 ms
13  pos10-0-0.lax-c100.gw.epoch.net (155.229.123.125)  416.909 ms  414 ms
416.23 ms
14  pos4-1.pao-c000.gw.epoch.net (155.229.120.49)  414.646 ms  416.578 ms
414.258 ms
15  pos8-0-0.npa-m100.gw.epoch.net (155.229.57.74)  417.329 ms  421.818 ms
600.575 ms
16  tig-us-pas-1.ihug.net (207.214.25.225)  420.169 ms  417.283 ms  417.213
ms
17  202-49-88-201.ihug.net (202.49.88.201)  531.449 ms  532.27 ms  530.245
ms
18  atm-5-0-0-2-netgate-akl.ihug.net (202.49.88.42)  531.121 ms  531.005 ms
530.884 ms
19  a0-0-0-2.tkbr1.netgate.net.nz (202.37.246.121)  534.236 ms  532.467 ms
530.545 ms
20  s1-1-1.labr1.netgate.net.nz (202.37.245.170)  767.038 ms  734.685 ms
768.571 ms
21  s5-0-0.lsanca1-cr1.bbnplanet.net (4.24.24.17)  681.512 ms  733.892 ms
751.962 ms
22  p2-1.lsanca1-ba1.bbnplanet.net (4.24.4.5)  765.545 ms  755.466 ms
680.472 ms
23  p7-0.lsanca1-br1.bbnplanet.net (4.24.4.2)  679.542 ms  766.558 ms
752.332 ms
24  p2-0.lsanca1-br2.bbnplanet.net (4.24.4.14)  750.405 ms  680.72 ms
765.398 ms
25  p1-0.crtntx1-ba1.bbnplanet.net (4.24.6.78)  808.366 ms  792.82 ms
806.672 ms
26  p1-0.crtntx1-ba2.bbnplanet.net (4.24.4.242)  786.897 ms  790.172 ms
770.245 ms
27  4.24.147.38 (4.24.147.38)  781.226 ms  782.357 ms  785.577 ms
28  pos10-0-0.lax-c100.gw.epoch.net (155.229.123.125)  850.728 ms  782.862
ms  782.42 ms
29  pos4-1.pao-c000.gw.epoch.net (155.229.120.49)  788.301 ms  782.932 ms
786.786 ms
30  pos8-0-0.npa-m100.gw.epoch.net (155.229.57.74)  840.266 ms  841.006 ms
785.38 ms

2000 isn't very long ago.  It would be interesting to see what a similar
unallocated route leaked into a significant provider would achieve today.

David.




More information about the NANOG mailing list