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.
jon
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.