Hi All,
More whining and bitching from me ... sorry...
So who thinks allowing anyone to route to or from IANA Reserved blocks (Bogons) is acceptable?
A few captured packets....
15:42:41.434384 1.6.145.24.1116 > 203.101.254.254.53: S 2056192000:2056192000(0) win 16384
15:42:41.570812 1.6.145.161.1043 > 203.101.254.254.53: S 773455872:773455872(0) win 16384
15:42:41.678862 1.6.147.198.1505 > 203.101.254.254.53: S 424280064:424280064(0) win 16384
15:42:41.985075 1.6.148.115.1448 > 203.101.254.254.53: S 1675624448:1675624448(0) win 16384
15:42:42.045121 1.6.148.202.1467 > 203.101.254.254.53: S 2072117248:2072117248(0) win 16384
15:42:42.528080 1.6.151.121.1180 > 203.101.254.254.53: S 1363410944:1363410944(0) win 16384
15:42:42.851633 1.6.153.101.1904 > 203.101.254.254.53: S 786563072:786563072(0) win 16384
15:42:42.908956 1.6.153.158.1712 > 203.101.254.254.53: S 1205272576:1205272576(0) win 16384
15:42:43.564536 1.6.157.75.1864 > 203.101.254.254.53: S 1150615552:1150615552(0) win 16384
15:42:43.653790 1.6.157.220.1882 > 203.101.254.254.53: S 209584128:209584128(0) win 16384
15:42:43.900861 1.6.159.103.1172 > 203.101.254.254.53: S 1935015936:1935015936(0) win 16384
15:42:44.247869 1.6.161.53.1045 > 203.101.254.254.53: S 1374552064:1374552064(0) win 16384
15:42:44.247936 1.6.161.140.1877 > 203.101.254.254.53: S 1761083392:1761083392(0) win 16384
15:42:44.388279 1.6.162.58.1230 > 203.101.254.254.53: S 1534263296:1534263296(0) win 16384
15:42:44.583169 1.6.163.23.1584 > 203.101.254.254.53: S 467271680:467271680(0) win 16384
15:42:44.653624 1.6.163.168.1091 > 203.101.254.254.53: S 1094844416:1094844416(0) win 16384
15:42:44.960670 1.6.166.33.1953 > 203.101.254.254.53: S 517210112:517210112(0) win 16384
15:42:45.323007 1.6.167.182.1541 > 203.101.254.254.53: S 417857536:417857536(0) win 16384
15:42:45.558600 1.6.168.235.1603 > 203.101.254.254.53: S 1652490240:1652490240(0) win 16384
15:42:45.588731 1.6.169.36.1581 > 203.101.254.254.53: S 1524498432:1524498432(0) win 16384
15:42:45.618207 1.6.170.39.1591 > 203.101.254.254.53: S 271319040:271319040(0) win 16384
15:42:47.164426 1.6.178.177.1159 > 203.101.254.254.53: S 879689728:879689728(0) win 16384
15:42:47.379603 1.6.179.231.1331 > 203.101.254.254.53: S 1859256320:1859256320(0) win 16384
15:42:47.979871 1.6.183.72.1516 > 203.101.254.254.53: S 1277362176:1277362176(0) win 16384
15:42:48.249871 1.6.184.215.1945 > 203.101.254.254.53: S 718929920:718929920(0) win 16384
15:42:48.581342 1.6.186.166.1478 > 203.101.254.254.53: S 889782272:889782272(0) win 16384
15:42:48.638018 1.6.187.54.1372 > 203.101.254.254.53: S 1532952576:1532952576(0) win 16384
15:42:48.803879 1.6.188.47.1253 > 203.101.254.254.53: S 1614348288:1614348288(0) win 16384
15:42:48.910837 1.6.188.191.1872 > 203.101.254.254.53: S 164429824:164429824(0) win 16384
15:42:49.014086 1.6.189.22.1078 > 203.101.254.254.53: S 1580924928:1580924928(0) win 16384
And a few more....
13:31:16.215267 255.205.43.12.1146 > 203.101.254.254.53: S 1909522432:1909522432(0) win 16384
13:31:16.225790 254.255.110.156.1934 > 203.101.254.254.53: S 843513856:843513856(0) win 16384
13:31:16.255373 255.205.9.178.1040 > 203.101.254.254.53: S 1741881344:1741881344(0) win 16384
13:31:16.297785 255.64.58.64.1759 > 203.101.254.254.53: S 832634880:832634880(0) win 16384
13:31:16.365988 255.64.58.47.1057 > 203.101.254.254.53: S 1301217280:1301217280(0) win 16384
13:31:16.375685 254.255.111.56.1351 > 203.101.254.254.53: S 2103771136:2103771136(0) win 16384
13:31:16.397829 254.255.110.157.1513 > 203.101.254.254.53: S 1743912960:1743912960(0) win 16384
13:31:16.562945 254.255.111.57.1137 > 203.101.254.254.53: S 1048379392:1048379392(0) win 16384
13:31:16.586507 255.64.58.106.1017 > 203.101.254.254.53: S 1919811584:1919811584(0) win 16384
13:31:16.607479 254.255.110.158.1400 > 203.101.254.254.53: S 1749942272:1749942272(0) win 16384
13:31:16.633489 255.64.58.118.1783 > 203.101.254.254.53: S 1790640128:1790640128(0) win 16384
13:31:16.669888 255.64.58.130.1871 > 203.101.254.254.53: S 223608832:223608832(0) win 16384
13:31:16.727705 255.205.44.169.1309 > 203.101.254.254.53: S 1294270464:1294270464(0) win 16384
13:31:16.769538 255.205.11.113.1578 > 203.101.254.254.53: S 386662400:386662400(0) win 16384
13:31:16.804433 254.255.111.58.1724 > 203.101.254.254.53: S 1657602048:1657602048(0) win 16384
13:31:16.804552 255.64.58.195.1374 > 203.101.254.254.53: S 1183514624:1183514624(0) win 16384
13:31:16.838304 254.255.110.159.1749 > 203.101.254.254.53: S 2041905152:2041905152(0) win 16384
13:31:16.854785 255.205.45.24.1962 > 203.101.254.254.53: S 980942848:980942848(0) win 16384
13:31:16.891851 255.64.58.189.1145 > 203.101.254.254.53: S 1588723712:1588723712(0) win 16384
13:31:16.907291 255.205.45.101.1850 > 203.101.254.254.53: S 281804800:281804800(0) win 16384
13:31:16.926608 255.64.58.199.1491 > 203.101.254.254.53: S 396623872:396623872(0) win 16384
13:31:16.960441 255.64.58.240.1647 > 203.101.254.254.53: S 1321926656:1321926656(0) win 16384
13:31:17.041859 254.255.111.59.1760 > 203.101.254.254.53: S 1589116928:1589116928(0) win 16384
13:31:17.056862 254.255.110.160.1140 > 203.101.254.254.53: S 707133440:707133440(0) win 16384
13:31:17.080801 255.205.45.214.1924 > 203.101.254.254.53: S 1915224064:1915224064(0) win 16384
13:31:17.125443 255.64.59.0.1309 > 203.101.254.254.53: S 582287360:582287360(0) win 16384
13:31:17.228794 254.255.111.60.1733 > 203.101.254.254.53: S 1086128128:1086128128(0) win 16384
13:31:17.248735 255.205.13.20.1313 > 203.101.254.254.53: S 1997733888:1997733888(0) win 16384
13:31:17.272623 254.255.110.161.1478 > 203.101.254.254.53: S 2034368512:2034368512(0) win 16384
13:31:17.337051 255.205.46.189.1570 > 203.101.254.254.53: S 1085341696:1085341696(0) win 16384
13:31:17.380544 255.205.13.134.1182 > 203.101.254.254.53: S 1334706176:1334706176(0) win 16384
13:31:17.393981 255.64.59.108.1988 > 203.101.254.254.53: S 275841024:275841024(0) win 16384
13:31:17.394332 254.255.111.61.1225 > 203.101.254.254.53: S 1829044224:1829044224(0) win 16384
13:31:17.409783 254.255.110.162.1695 > 203.101.254.254.53: S 472383488:472383488(0) win 16384
13:31:17.419251 255.205.13.171.1933 > 203.101.254.254.53: S 1066336256:1066336256(0) win 16384
13:31:17.510895 254.255.111.62.1450 > 203.101.254.254.53: S 1052508160:1052508160(0) win 16384
13:31:17.535728 254.255.110.163.1492 > 203.101.254.254.53: S 289079296:289079296(0) win 16384
13:31:17.545043 255.205.47.123.1256 > 203.101.254.254.53: S 1559035904:1559035904(0) win 16384
13:31:17.680832 255.64.59.182.1939 > 203.101.254.254.53: S 930217984:930217984(0) win 16384
13:31:17.718981 254.255.111.63.1391 > 203.101.254.254.53: S 2029191168:2029191168(0) win 16384
13:31:17.739317 255.64.59.168.1043 > 203.101.254.254.53: S 1719926784:1719926784(0) win 16384
13:31:17.749319 254.255.110.164.1398 > 203.101.254.254.53: S 444006400:444006400(0) win 16384
13:31:17.820087 255.64.59.225.1438 > 203.101.254.254.53: S 186712064:186712064(0) win 16384
13:31:17.845466 255.64.59.232.1771 > 203.101.254.254.53: S 1787756544:1787756544(0) win 16384
13:31:17.849674 255.205.48.121.1409 > 203.101.254.254.53: S 1942159360:1942159360(0) win 16384
13:31:17.856734 254.255.111.64.1394 > 203.101.254.254.53: S 1471348736:1471348736(0) win 16384
13:31:17.883396 254.255.110.165.1367 > 203.101.254.254.53: S 611909632:611909632(0) win 16384
13:31:17.895921 255.205.48.160.1147 > 203.101.254.254.53: S 1586495488:1586495488(0) win 16384
13:31:17.913763 255.64.59.249.1026 > 203.101.254.254.53: S 708116480:708116480(0) win 16384
13:31:17.951460 255.205.15.147.1949 > 203.101.254.254.53: S 2000027648:2000027648(0) win 16384
13:31:17.989485 254.255.111.65.1467 > 203.101.254.254.53: S 81395712:81395712(0) win 16384
Is there any need to route bogons? Is there any reason why it cannot be filtered (I appreciate 224-239 is a different story)....?
These packets were all originated on the other side of the Pacific to Telecom NZ.
/ Mat
Hi, Mat.
] So who thinks allowing anyone to route to or from IANA Reserved blocks
] (Bogons) is acceptable?
It's a continuing mystery to me, when it's not exactly impossible
to do.
<http://www.cymru.com/Bogons/index.html>
Thanks,
Rob.
Hi All,
More whining and bitching from me ... sorry...
So who thinks allowing anyone to route to or from IANA Reserved blocks
(Bogons) is acceptable?
Technically these packets are 'routed' correctly, they are perhaps not
filtered, but thats another story entirely.
A few captured packets....
15:42:41.434384 1.6.145.24.1116 > 203.101.254.254.53: S
-- snip --
Is there any need to route bogons? Is there any reason why it cannot be
filtered (I appreciate 224-239 is a different story)....?
At the edge, very near the originating host there is no reason not to
filter these, if you find the sources you might consider asking them why
they didn't filter these for you...
These packets were all originated on the other side of the Pacific to
Telecom NZ.
and they travelled well apparently.
> More whining and bitching from me ... sorry...
>
> So who thinks allowing anyone to route to or from IANA Reserved blocks
> (Bogons) is acceptable?
>
Technically these packets are 'routed' correctly, they are perhaps not
filtered, but thats another story entirely.
> A few captured packets....
>
> 15:42:41.434384 1.6.145.24.1116 > 203.101.254.254.53: S
-- snip --
>
> Is there any need to route bogons? Is there any reason why it cannot be
> filtered (I appreciate 224-239 is a different story)....?
>
At the edge, very near the originating host there is no reason not to
filter these, if you find the sources you might consider asking them why
they didn't filter these for you...
I would ask your upstreams to filter out such "worthless"
traffic. My opinion is fairly clear on this topic. If I can't
return it, I'm not going to accept it.
Fairly simple policy.
- jared
My opinion is fairly clear on this topic. If I can't
return it, I'm not going to accept it.
AMEN!
I get these with frequency also on my edge logs. I just let my own filters catch them. It differs each month also on the ammount of traffic I get from these address blocks.
G.
Jared Mauch writes:
> More whining and bitching from me ... sorry...
>
> So who thinks allowing anyone to route to or from IANA Reserved blocks
> (Bogons) is acceptable?
>
Technically these packets are 'routed' correctly, they are perhaps not
filtered, but thats another story entirely.
> A few captured packets....
>
> 15:42:41.434384 1.6.145.24.1116 > 203.101.254.254.53: S
-- snip --
>
> Is there any need to route bogons? Is there any reason why it cannot be
> filtered (I appreciate 224-239 is a different story)....?
>
At the edge, very near the originating host there is no reason not to
filter these, if you find the sources you might consider asking them why
they didn't filter these for you...
I would ask your upstreams to filter out such "worthless"
traffic. My opinion is fairly clear on this topic. If I can't
return it, I'm not going to accept it.
Fairly simple policy.
- jared
> These packets were all originated on the other side of the Pacific to
> Telecom NZ.
>
and they travelled well apparently.
--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | Jared Mauch's Home Page My statements are only mine.
Gerardo A. Gregory
Manager Network Administration and Security
402-970-1463 (Direct)
402-850-4008 (Cell)
Christopher L. Morrow wrote:
At the edge, very near the originating host there is no reason not to
filter these, if you find the sources you might consider asking them why
they didn't filter these for you...
And what is the reason to not filter these in the backbone? Full spoof protection at some levels is near impossible. However, bogon filtering is not.
-Jack
(i know i said i wouldn't comment on this, but that was yesterday.)
> At the edge, very near the originating host there is no reason not to
> filter these, if you find the sources you might consider asking them why
> they didn't filter these for you...
i've asked. answers are usually of the form "huh? what's that?" unless it's
a relatively smart person with the misfortune to be working at a bankrupt
backbone with short staff and no equipment budget in which case the answer
is some variation of "well that's fine at the edge but not in the core". in
fact, see above :-).
And what is the reason to not filter these in the backbone? Full spoof
protection at some levels is near impossible. However, bogon filtering
is not.
loose-rpf is a start. none of the packets shown below came to me from a
peer or transit who runs loose-rpf in their backbone. however, loose-rpf
only solves a small part of the source address ambiguity problem, since
the niks can still source their zwil from (other people's) routed cidr
blocks.
with respect to the trace below, this is one f-root out of about 25, and
while we normally have to sanitize the source addresses of our traces before
we make them public, as you can see it's really not nec'y for this one:
#sfo2a.f:i386# tcpdump -n src net \( 10 or 172.16/12 or 192.168/16 \)
tcpdump: listening on fxp0
16:34:44.982330 172.20.1.1.3436 > 192.5.5.241.53: 4072[|domain]
16:34:45.027735 172.16.1.13.53 > 192.5.5.241.53: 21659 A? updatekeepalive.mcafee.com. (44)
16:34:45.053542 10.10.220.10.32769 > 192.5.5.241.53: 52143 NS? . (17) (DF)
16:34:45.084594 10.23.1.40.1024 > 192.5.5.241.53: 7932 NS? . (17)
16:34:45.832620 192.168.0.2.1133 > 192.5.5.241.53: 8690 A? g-images.amazon.com. (37)
16:34:45.837360 192.168.0.2.1133 > 192.5.5.241.53: 12795 A? g-images.amazon.com. (37)
16:34:45.841734 192.168.0.2.1133 > 192.5.5.241.53: 512 A? g-images.amazon.com. (37)
16:34:45.846085 192.168.0.2.1133 > 192.5.5.241.53: 6665 A? g-images.amazon.com. (37)
16:34:45.850969 192.168.0.2.1133 > 192.5.5.241.53: 12820 A? g-images.amazon.com. (37)
16:34:45.871451 192.168.0.63.1105 > 192.5.5.241.53: 84 PTR? 8.0.168.192.in-addr.arpa. (42)
16:34:45.924779 10.2.3.39.1030 > 192.5.5.241.53: 57 A? www.symantec.com. (34)
16:34:45.926582 10.2.3.39.1030 > 192.5.5.241.53: 6208 A? time-a.timefreq.bldrdoc.gov. (45)
16:34:45.931745 10.2.3.39.1030 > 192.5.5.241.53: 12361 A? time-a.timefreq.bldrdoc.gov. (45)
16:34:46.096376 192.168.1.113.32830 > 192.5.5.241.53: 18162 [1au] MX? networkoptservices.net. OPT UDPsize=4096 (51)
(DF)
16:34:46.098370 192.168.1.113.32830 > 192.5.5.241.53: 9520 MX? activision.info. (33) (DF)
16:34:46.801114 172.30.60.229.53 > 192.5.5.241.53: 1400 SOA? 150.118.162.in-addr.arpa. (42)
16:34:46.828786 192.168.104.10.1097 > 192.5.5.241.53: 1290 A? images.daemon.sh. (34)
16:34:46.830733 192.168.104.10.1097 > 192.5.5.241.53: 11542 A? images.daemon.sh. (34)
16:34:46.832704 192.168.104.10.1097 > 192.5.5.241.53: 1305 A? images.daemon.sh. (34)
16:34:46.833516 192.168.104.10.1097 > 192.5.5.241.53: 13600 A? images.daemon.sh. (34)
16:34:46.834898 192.168.0.2.1133 > 192.5.5.241.53: 10777 A? g-images.amazon.com. (37)
16:34:46.834905 192.168.104.10.1097 > 192.5.5.241.53: 15659 A? images.daemon.sh. (34)
16:34:46.839097 192.168.0.2.1133 > 192.5.5.241.53: 544 A? g-images.amazon.com. (37)
16:34:46.843399 192.168.0.2.1133 > 192.5.5.241.53: 552 A? g-images.amazon.com. (37)
16:34:46.848108 192.168.0.2.1133 > 192.5.5.241.53: 14902 A? g-images.amazon.com. (37)
16:34:46.853027 192.168.0.2.1133 > 192.5.5.241.53: 6718 A? g-images.amazon.com. (37)
16:34:46.898737 192.168.203.7.1111 > 192.5.5.241.53: 3150 A? microsoft.com.mailwell.com. (44)
16:34:46.900221 192.168.203.7.1111 > 192.5.5.241.53: 5206 A? microsoft.com.mailwell.com. (44)
16:34:46.926334 10.2.3.39.1030 > 192.5.5.241.53: 4182 A? www.symantec.com. (34)
16:34:46.926721 10.2.3.39.1030 > 192.5.5.241.53: 2143 A? www.symantec.com. (34)
16:34:47.018181 192.168.100.24.1102 > 192.5.5.241.53: 16356 A? sbasupport. (28)
16:34:47.828700 192.168.104.10.1097 > 192.5.5.241.53: 15668 A? rsthost1.ods.org. (34)
16:34:47.829026 192.168.104.10.1097 > 192.5.5.241.53: 5439 A? rsthost1.ods.org. (34)
16:34:47.892288 10.81.0.22.1069 > 192.5.5.241.53: 6014 SOA? 0.81.10.in-addr.arpa. (38)
16:34:47.905254 192.168.128.4.53 > 192.5.5.241.53: 614 PTR? 30.128.168.192.in-addr.arpa. (45)
16:34:47.919143 10.1.0.3.53 > 192.5.5.241.53: 26579 A? www.symantec.com. (34)
16:34:47.926353 10.2.3.39.1030 > 192.5.5.241.53: 12388 SOA? 12.2.10.in-addr.arpa. (38)
16:34:47.981405 172.20.1.1.3436 > 192.5.5.241.53: 8189[|domain]
^C
3205 packets received by filter
0 packets dropped by kernel
Source address-based filtering in the backbone is expensive and, in many
cases, non-feasible.
Owen
I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly there
was some lesson learned from this, no?
] I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly there
] was some lesson learned from this, no?
Yep, and the lesson is: Lots of folks do a poor job of network
management. 
Keeping up with the bogons can be automated, see:
<http://www.cymru.com/BGP/bogon-rs.html>
It gets even worse. Cisco has hard-coded the list of Bogons into some of
its latest low-end IOS versions as part of its "auto-secure" feature.
Yes, Cisco includes warnings in the manual the user should check the
official list at IANA; but I also know the power of defaults. People
upgrade their IOS versions even less often then they update their
Windows boxes. So we're going to see chunks of the net blocked depending
on the release date of versions of IOS.
Do you have a reference page as to what platforms/releases/release trains
that is being applied to?
Seems like it might be a handy list to have bookmarked. 
Thanks,
Adam Debus
Linux Certified Professional, Linux Certified Administrator #447641
Network Engineer, ReachONE Internet
adam@reachone.com
Sean Donelan wrote:
It gets even worse. Cisco has hard-coded the list of Bogons into some of
its latest low-end IOS versions as part of its "auto-secure" feature.
Yes, Cisco includes warnings in the manual the user should check the
official list at IANA; but I also know the power of defaults. People
upgrade their IOS versions even less often then they update their
Windows boxes. So we're going to see chunks of the net blocked depending
on the release date of versions of IOS.
There is an old saying which seems to fit here;
"The road to hell is paved with good intentions."
Pete
[multiple response]
Christopher L. Morrow wrote:
I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly there
was some lesson learned from this, no?
I don't buy it, Chris. Are you saying that a large backbone provider can't maintain up-to-date bogon filters? In fact, I'd say they would be better at it, and if they were using the filters, then there would be less need for their customers to apply the filters and we'd have less bogon issues in the future.
Owen DeLong wrote:
> Source address-based filtering in the backbone is expensive and, in
> many cases, non-feasible.
Most vendor equipment is easily capable of handling bogon filtering using any number of methods. This is particular true when filtering packets that are not announced bogons (such as most dDOS spoof attacks), even if announced bogon packets are allowed through.
-Jack
And, of course, unnecessary. Everything in the core must have gotten there over a border towards some external network or an edge towards a customer (counting own servers and stuff as "customer" too) so if filtering is done there, no need to repeat it in the core.
BTW, from what I can tell on a pretty old/slow Cisco box, uRPF makes packet forwarding take about 10% more CPU, which is the same as a short standard access list (which can only look at source addresses). A short extended access list takes around 20% more CPU.
> Sean Donelan wrote:
>
> It gets even worse. Cisco has hard-coded the list of
> Bogons into some of its latest low-end IOS versions as
> part of its "auto-secure" feature. Yes, Cisco includes
> warnings in the manual the user should check the official
> list at IANA; but I also know the power of defaults.
> People upgrade their IOS versions even less often then
> they update their Windows boxes. So we're going to see
> chunks of the net blocked depending on the release date
> of versions of IOS.
Adam Debus wrote:
Do you have a reference page as to what
platforms/releases/release trains that is being applied to?
Seems like it might be a handy list to have bookmarked. 
Per
guide09186a008017d101.html, it was introduced in 12.3 mainline. It's
anyone's guess where it will end up from there but note that it's
already in a service provider train (12.2(18)S). So we may (or probably
will?) end up with ISP's using the bogon-list feature as well.
If one upgrades from version A of Autosecure-enabled IOS to version B of
Autosecure-enabled IOS, will the bogon-list ACLs in the device's
configuration be automatically updated? Or will the user have to
disable and then re-enable Autosecure?
Is this progress? Or is this something that "seemed like a good idea at
the time"?
-Terry
Terry Baranski wrote:
Is this progress? Or is this something that "seemed like a good idea at
the time"?
I would like to refer to my previous statement on this matter.
"The road to hell is paved with good intentions."
The other favourite which applies;
"Ignorance often translates to increased sales."
Pete