- Test - lists.nanog.org

Weekly Routing Table Report
by cscora＠apnic.net 10 Aug '18

10 Aug '18

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 11 Aug, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 710351 Prefixes after maximum aggregation (per Origin AS): 272851 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 341377 Total ASes present in the Internet Routing Table: 61486 Prefixes per ASN: 11.55 Origin-only ASes present in the Internet Routing Table: 53097 Origin ASes announcing only one prefix: 23134 Transit ASes present in the Internet Routing Table: 8389 Transit-only ASes present in the Internet Routing Table: 266 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 71 Number of instances of unregistered ASNs: 71 Number of 32-bit ASNs allocated by the RIRs: 23624 Number of 32-bit ASNs visible in the Routing Table: 19037 Prefixes from 32-bit ASNs in the Routing Table: 79679 Number of bogon 32-bit ASNs visible in the Routing Table: 107 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 275 Number of addresses announced to Internet: 2857141828 Equivalent to 170 /8s, 76 /16s and 134 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 237154 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 193620 Total APNIC prefixes after maximum aggregation: 55167 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 191870 Unique aggregates announced from the APNIC address blocks: 79105 APNIC Region origin ASes present in the Internet Routing Table: 8995 APNIC Prefixes per ASN: 21.33 APNIC Region origin ASes announcing only one prefix: 2537 APNIC Region transit ASes present in the Internet Routing Table: 1341 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3958 Number of APNIC addresses announced to Internet: 767223811 Equivalent to 45 /8s, 186 /16s and 232 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 210910 Total ARIN prefixes after maximum aggregation: 100181 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 210886 Unique aggregates announced from the ARIN address blocks: 99818 ARIN Region origin ASes present in the Internet Routing Table: 18212 ARIN Prefixes per ASN: 11.58 ARIN Region origin ASes announcing only one prefix: 6737 ARIN Region transit ASes present in the Internet Routing Table: 1812 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2396 Number of ARIN addresses announced to Internet: 1103025824 Equivalent to 65 /8s, 190 /16s and 214 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 194304 Total RIPE prefixes after maximum aggregation: 92790 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 190611 Unique aggregates announced from the RIPE address blocks: 113115 RIPE Region origin ASes present in the Internet Routing Table: 25398 RIPE Prefixes per ASN: 7.50 RIPE Region origin ASes announcing only one prefix: 11460 RIPE Region transit ASes present in the Internet Routing Table: 3514 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7284 Number of RIPE addresses announced to Internet: 714048896 Equivalent to 42 /8s, 143 /16s and 133 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 92228 Total LACNIC prefixes after maximum aggregation: 20546 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 93649 Unique aggregates announced from the LACNIC address blocks: 41078 LACNIC Region origin ASes present in the Internet Routing Table: 7399 LACNIC Prefixes per ASN: 12.66 LACNIC Region origin ASes announcing only one prefix: 2008 LACNIC Region transit ASes present in the Internet Routing Table: 1387 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4944 Number of LACNIC addresses announced to Internet: 172309792 Equivalent to 10 /8s, 69 /16s and 61 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 19217 Total AfriNIC prefixes after maximum aggregation: 4104 AfriNIC Deaggregation factor: 4.68 Prefixes being announced from the AfriNIC address blocks: 23060 Unique aggregates announced from the AfriNIC address blocks: 8018 AfriNIC Region origin ASes present in the Internet Routing Table: 1185 AfriNIC Prefixes per ASN: 19.46 AfriNIC Region origin ASes announcing only one prefix: 392 AfriNIC Region transit ASes present in the Internet Routing Table: 237 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 455 Number of AfriNIC addresses announced to Internet: 100085248 Equivalent to 5 /8s, 247 /16s and 46 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4689 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4405 477 468 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2969 1153 83 VIETEL-AS-AP Viettel Group, VN 4766 2830 11132 759 KIXS-AS-KR Korea Telecom, KR 9829 2816 1497 543 BSNL-NIB National Internet Backbone, IN 45899 2573 1634 157 VNPT-AS-VN VNPT Corp, VN 9394 2543 4907 32 CTTNET China TieTong Telecommunications 17974 2261 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2249 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2115 417 203 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3442 1324 82 SHAW - Shaw Communications Inc., CA 22773 3253 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2842 256 421 CABLEONE - CABLE ONE, INC., US 16509 2259 4791 768 AMAZON-02 - Amazon.com, Inc., US 18566 2166 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2124 2641 484 CHARTER-NET-HKY-NC - Charter Communicat 30036 2018 344 142 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 2007 1031 1445 AKAMAI-AS - Akamai Technologies, Inc., 209 1994 5085 604 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 7018 1764 20206 1281 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4682 1613 128 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2819 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2552 624 1891 AKAMAI-ASN1, US 12389 2042 1891 731 ROSTELECOM-AS, RU 34984 2013 335 506 TELLCOM-AS, TR 9121 1837 1692 19 TTNET, TR 13188 1605 100 39 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1204 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5191 3349 607 Uninet S.A. de C.V., MX 10620 3483 531 456 Telmex Colombia S.A., CO 11830 2657 369 78 Instituto Costarricense de Electricidad 6503 1666 444 63 Axtel, S.A.B. de C.V., MX 7303 1508 1027 189 Telecom Argentina S.A., AR 28573 1087 2241 189 CLARO S.A., BR 3816 1020 508 128 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 933 377 31 Telefonica del Peru S.A.A., PE 11172 929 126 85 Alestra, S. de R.L. de C.V., MX 18881 913 1078 30 TELEFÔNICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1172 396 48 LINKdotNET-AS, EG 37611 890 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 744 1411 40 ETISALAT-MISR, EG 24835 635 818 18 RAYA-AS, EG 8452 602 1730 18 TE-AS TE-AS, EG 37492 474 470 57 ORANGE-, TN 29571 459 68 12 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 373 231 15 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5191 3349 607 Uninet S.A. de C.V., MX 4538 4689 4192 74 ERX-CERNET-BKB China Education and Rese 12479 4682 1613 128 UNI2-AS, ES 7545 4405 477 468 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3483 531 456 Telmex Colombia S.A., CO 6327 3442 1324 82 SHAW - Shaw Communications Inc., CA 22773 3253 2968 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7552 2969 1153 83 VIETEL-AS-AP Viettel Group, VN 11492 2842 256 421 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4538 4689 4615 ERX-CERNET-BKB China Education and Research Net 12479 4682 4554 UNI2-AS, ES 7545 4405 3937 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3442 3360 SHAW - Shaw Communications Inc., CA 22773 3253 3104 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 10620 3483 3027 Telmex Colombia S.A., CO 7552 2969 2886 VIETEL-AS-AP Viettel Group, VN 8551 2819 2775 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2657 2579 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64514 PRIVATE 5.42.231.0/24 35753 ITC ITC AS number, SA 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 135391 AOFEI-HK AOFEI DATA INTERNATIO 268422 UNALLOCATED 45.160.208.0/24 263321 Ejmnet Tecnologia ltda, BR 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 45.121.32.0/22 134356 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:36 /11:99 /12:291 /13:570 /14:1096 /15:1896 /16:13372 /17:7913 /18:13792 /19:25356 /20:39404 /21:45677 /22:88015 /23:71590 /24:399059 /25:800 /26:602 /27:627 /28:35 /29:20 /30:19 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3427 4682 UNI2-AS, ES 6327 3231 3442 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2515 3253 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2281 2819 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 2214 2842 CABLEONE - CABLE ONE, INC., US 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 2005 2657 Instituto Costarricense de Electricidad y Telec 30036 1770 2018 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1575 3483 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1612 2:835 4:18 5:2827 6:43 7:1 8:1128 12:1877 13:210 14:1795 15:31 16:3 17:190 18:54 20:50 23:2464 24:2209 25:2 27:2476 31:2020 32:88 35:29 36:512 37:2883 38:1486 39:254 40:122 41:3154 42:652 43:1967 44:122 45:5309 46:3101 47:197 49:1333 50:1049 51:318 52:1078 54:370 55:1 56:12 57:39 58:1622 59:991 60:403 61:2118 62:1862 63:1793 64:5050 65:2216 66:4705 67:2552 68:1164 69:3290 70:1155 71:582 72:2155 74:2722 75:422 76:463 77:1643 78:1686 79:2133 80:1541 81:1381 82:1031 83:783 84:1034 85:1986 86:566 87:1357 88:918 89:2356 90:216 91:6444 92:1263 93:2368 94:2393 95:2919 96:793 97:357 98:934 99:133 100:85 101:1234 102:174 103:18328 104:3578 105:216 106:769 107:1775 108:714 109:3147 110:1639 111:1798 112:1334 113:1299 114:1136 115:1660 116:1645 117:1774 118:2217 119:1678 120:1009 121:1047 122:2435 123:1767 124:1446 125:1922 128:1109 129:690 130:492 131:1636 132:727 133:195 134:1023 135:232 136:499 137:645 138:1946 139:664 140:471 141:736 142:810 143:1027 144:809 145:484 146:1209 147:730 148:1646 149:748 150:741 151:1100 152:821 153:323 154:1488 155:804 156:1313 157:797 158:655 159:1821 160:1296 161:841 162:2592 163:602 164:1080 165:1528 166:460 167:1296 168:3135 169:828 170:3833 171:492 172:1002 173:2027 174:929 175:779 176:2005 177:4035 178:2505 179:1251 180:2170 181:2421 182:2392 183:1240 184:1041 185:13938 186:3644 187:2401 188:2914 189:2037 190:8357 191:1357 192:9812 193:6099 194:5002 195:3983 196:2660 197:1593 198:5572 199:5911 200:7394 201:5018 202:10247 203:10290 204:4590 205:2923 206:3163 207:3207 208:3962 209:4012 210:3866 211:1989 212:3042 213:2811 214:1043 215:56 216:6041 217:2118 218:859 219:578 220:1813 221:994 222:972 223:1373 End of report

1 0

Multicast traffic % in enterprise network ?
by Mankamana Mishra (mankamis) 10 Aug '18

10 Aug '18

Hi Every one, Recently we had good discussion over multicast uses in public internet. From discussion, it was pointed out uses of multicast is more with in enterprise. Wanted to understand how much % multicast traffic present in network * If there is any data which can provide what % of traffic is multicast traffic. And if multicast is removed, how much unicast traffic it would add up? * Since this forum has people from deployment area, I would love to know if there is real deployment problems or its pain to deploy multicast. These questions is to work / discussion in IETF to see what is pain points for multicast, and how can we simplify it. Thanks Mankamana

14 21

celebrating 10 years of routing insecurity
by Job Snijders 10 Aug '18

10 Aug '18

Dear all, Today marks the 10th anniversary of the famous Kapela-Pilosov Man-in-the-middle BGP attack! It is a fantastic and innovative attack that would be worthy of referencing in the next Mr Robot season. :-) video: https://www.youtube.com/watch?v=S0BM6aB90n8 slide: https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-piloso… So, what is the state of routing security anno 2018? It seems that as an industry we're on an upwards trajectory: various IRR registries are locking themselves down to prevent creation of unauthorized route(6) objects, new filter generation tools are becoming available, RPKI based BGP Origin Validation is slowly seeing more and more deployment, and the concept of blocking route announcements with improbable AS_PATHs is gaining popularity as well. Let's see where we are 10 years from now! Kind regards, Job

1 0

Summer of Hijacks: My message to RIPE and the RIPE Executive Board
by Ronald F. Guilmette 10 Aug '18

10 Aug '18

Found yet another big hijacking operation. Coming out of RIPEland, again. See below for full details. I didn't really want to post again to NANOG on this topic (hijacks) quite this soon, but the bloody European crooks, spammers, and hijackers aren't really giving me a break, and I can't abide just sitting in silence and stewing about it for another month or three. I mean this stuff is just getting ridiculous. And I do wory that the Internet community is just starting to accept this stuff as "normal behavior", which it isn't. Maybe the following will finally get somebody's attention in RIPEland, but I'm not holding my breath for what I personally consider a Good Outcome (which would include full disclosure about what the hell they are actually going to do about any of this, which is probably far too much to even hope for). I'll probably be permanently banned from all of the relevant RIPE mailing lists for having posted this. I just skimmed over RIPE's Code of Conduct for their mailing lists and it basically says that Thou Shalt Not Say Anything Bad About Anybody Specifically, Ever, and I'm pretty sure that I just broke that rule, in spades. Oh well. May God bless the First Amendment, and may God bless NANOG! P.S. It was just now brough to my attention that AS197328, Istanbuldc, is -only- routing 176.116.0.0/19, which looks to be one of the few routes that are maintained by MNT-SERVERSGET that are actually for legitimately allocated IPv4 blocks. For the record, I do not dispute that some of the routes maintained by MNT-SERVERSGET are for legitimately allocated space. I will and do however dispute any assertion that ALL such routes are for IP space that has been legitimately allocated to either Mr. Alexander Samuilov or to his various corporate identities or corporate partners. That does not appear to be the case, based on the evidence. (note - minor edits applied) ========================================================================== From: "Ronald F. Guilmette" <rfg(a)tristatelogic.com> To: exec-board(a)ripe.net, db-wg(a)ripe.net, routing-wg(a)ripe.net, anti-abuse-wg(a)ripe.net, noc(a)ripe.net, Subject: The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top The entire set of objects in the RIPE WHOIS data base that are currently registered with mnt-by: MNT-SERVERSGET is listed here: https://pastebin.com/raw/GiYWxHMh Among this set of objects there are 235 separate route objects. Evidence indicates persuasively that some sizable fraction of these RIPE- registered route objects are fradulent and are simply there to provide cover for multiple IPv4 address block hijacks. The presence of these objects in the data base permits the following set of ASNs to claim that they are acting "legitimately" even as they route these hijacked blocks: AS9009 M247 Ltd (UK) AS43350 NFOrce Internet Sevices (Netherlands) AS57129 Optibit, LLC (Russia) AS197328 Istanbuldc Veri Merkezi Ltd. Sti (Turkey) -- SEE NOTE ABOVE AS202287 Men Danil Valentinovich (Russia) AS204895 Santa Plus, LLC (Russia) The total amount of IPv4 space encompassed within the set of route objects registered with mnt-by: MNT-SERVERSGET at the present time amounts to eight hundred and fifty nine (859) /24 blocks. Of these, only three hundred and five (305) actually have correctly functioning and properly delegated reverse DNS at the present time, and even among those, only two hundred and two (202) have functioning reverse DNS delegations to the prefered name servers of MNT-SERVERSGET, which is to say the name servers ns5.dnsget.top and ns6.dnsget.top. The bottom line is that it appears that, at the present time, something less than 1/4 of all of the IPv4 address space currently registered in the RIPE data base (via route objects) by and to MNT-SERVERSGET is space for which a plausible case could be made that the blocks in question are actually legitimately assigned to and/or under the legitimate control of MNT-SERVERSGET aka Mr. Alexander Samuilov. The other 3/4ths of the IPv4 space in question has provenance which is, at best, dubious. Due to its use of little country-of-registration flags for each IP address block, the web site bgp.he.net provides the most visually obvious indications of at least two of the specific block hijacks in this case, specifically the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129: https://bgp.he.net/AS57129#_prefixes Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake an immediate and conmprehensive review of all objects in the data base that are currently registered with mnt-by: MNT-SERVERSGET. Additionally, I also respectfully request RIPE NCC to publish the results of this review to the mailing lists of the Database Working Group and the Anti-Abuse Working Group. The charters of both of these Working Groups are directly relevant to this issue, and there exists neither need nor reason to simply sweep this issue quietly under the carpet, as has been done in previous and similar cases. Cases such as this, and the two others of similar magnitude that I have publicly disclosed just this summer, affect the operation of, the stability of, and the continued enjoyment of the entire planetary Internet and its billions of users. Despite its status as a strictly private corporation, RIPE has a public responsibility, not only to handle such incidents responsibly and competently, but to show the world that it is ready, willing, and able to do so. The responses of RIPE to prior instances of this exact type of bad behavior have been largely or entirely cloaked in secrecy, presumably to protect the guilty. This longstanding and antiquated tradition of omerta within the RIPE community is unambiguously counterproductive to the goal of a well-managed and properly fuctioning Internet. Just as importantly, it naturally gives rise to unavoidable questions about the actual competence of, and capabilities of RIPE NCC staff as they attempt to deal with such incidents. I personally feel that RIPE NCC staff are doing the best they can when responding to incidents such as this, but the tradition of playing "hide the ball" with respect to their actions in such cases reflects badly on them, and badly on RIPE generally. It certainly raises doubts about RIPE's claim to authority over even its own data base. Lastly, I respectfully request both the RIPE Executive Board and the RIPE membership to make plain and explicit their respective intentions with regards to the various bad actors that have been caught, and that may in future be caught red handed engaging in the deliberate and premeditated corruption of the RIPE data base. To date, the policies an actions that RIPE applies, or which RIPE may apply to such bad actors have been shrouded in apparently deliberate secrecy and mystery. To put this request in more concrete terms, I would like to know if RIPE and the Executive Board actually and deliberately intend to take no action whatsoever with respect to the ongoing RIPE memberships of clearly identified bad actors, specifically, in this case, whatever persons or entities are currently repreesented by the RIPE WHOIS handle MNT-SERVERSGET (aka AS202287 and AS202275), which would appear to be this specific entity / RIPE member: https://www.ripe.net/membership/indices/data/ru.danil.html Is it the express intention of both the Board and the RIPE membership to simply deprive this bad actor of just those fradulent data base entries that have effectively legitimized his/her/its fradulent routing announcements? Is it the express intention of both the Board and the RIPE membership to simply make this bad actor give back what he has stolen, and to otherwise take no action, just as the response has been in the two other and similar cases that have also arisen in the RIPE region and that I have also publicly reported on this summer? https://mailman.nanog.org/pipermail/nanog/2018-June/096034.html https://mailman.nanog.org/pipermail/nanog/2018-July/096437.html My question is prompted by the following simple facts. In the two prior cases cited above, and also in the one I am presenting here today, the bad actors involved were seen to have not only hijacked large swaths of IP address space that clearly didn't belong to them, but also, as in the case I am presenting today, these same bad actors additionally acted to corrupt the RIPE data base with premeditated and deliberately fradulent entries. Nonetheless, and regardless of these attacks on the reliability and trustworthyness of the RIPE data base, to date it appears that no action whatsoever has been taken which might affect the ongoing RIPE memberships of the relevant parties and bad actors involved, and they are all still members in good standing of RIPE at the present time: https://www.ripe.net/membership/indices/data/pt.bitcanal-pt.html https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html This is, to say the least, puzzling. I would like to know when, where, and how the Executive Board and/or the RIPE membership reached the altogether dubious conclusion that the best possible way to deal with bad actors such as these is to make them give back -just- the stuff the stole, and then to otherwise impose no penality of any kind, thus allowing them to live on, so that they may hijack another day. Whether this policy is a result of either deliberation or default, it *does* appear to be the policy, based on the evidence. Without intending to be rude, I feel that I must ask the obvious question: In what Universe does this otherwise admirable and generous Christian policy of "turning the other cheek" with respect to such verified bad actors have any effect other than encouraging the next hijacker, and then next one, and the one after that? Has either the Board or the membership even ever seriously debated what penalties should be imposed upon those members who are caught red handed deliberately corrupting the RIPE data base? Is the present RIPE policy of "forgive and forget" with respect to such travesties a product of anyone's intentional design, or is it instead merely the result of utter apathy and indifference on the part of the entire RIPE community? In either case, I believe it to be self evident that the time is... ummm... blooming, blossoming, burgeoning, flourishing, and flowering for this policy to be reexamined and revised. From where I am sitting it is self evident that the current policy of turning a blind eye to these events, and to the bad actors behind them is quite clearly encouraging others to follow suit and to themselves undertake the exact same sorts of travesties. Why shouldn't they? There is no downside. At the very worst, one is simply made to give back all of the stuff that one has stolen, and one is then allowed to go on one's merry way. Regards, rfg P.S. As incensed as I am at the fact that the above named bad actors have been allowed not only to retain their RIPE memberships, but also, apparently, 100% of their legitimately-allocated number resources, this is not even nearly as utterly appalling and inexplicable as the fact that two of the bad actors with direct and provable connections to the prior instances of hijacking that I have reported on publicly this summer have been allowed to remain as officially recognized RIPE IP brokers: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/bro… I am referring here specifically to Ebonyhorizon Telecomunicacoes Lda (aka Bitcanal) and also to NetAssist LLC (AS29632), which conveniently continues to maintain its association with, and peering arrangements with both AS57166 aka D2 International Investment Ukraine, Ltd. and, indirectly via D2, AS205869 aka Universal IP Solution Corp., both of which apparently continue to this day to try their best to hijack, either directly or indirectly, via AS Path fraud, a number of IPv4 blocks that clearly do not belong to any of these three Ukranian entities: https://bgp.he.net/AS57166#_peers https://bgp.he.net/AS205869#_peers https://bgp.he.net/AS29632#_peers What IP blocks are these two officially recognized RIPE IP brokers, Ebony Horizon and NetAssist brokering, exactly? Are they blocks that have been successfully hijacked? Does either RIPE or RIPE NCC even know? Does either RIPE or RIPE NCC even care? (One cannot help but wonder what might occur if RIPE were put in charge of distributing meat supplies within Europe. Would RIPE officially designate the McDonald's "Hamburglar" as RIPE's officially recognized agent for said distributions?) I guess that, in the end, all of the questions I have raised above can be boiled down to just one simple question: Who exactly does one need to either kill or maim or seriously wound in order to get kicked out of this organization (RIPE)? Regards, rfg P.P.S. Among the set of six companies / ASNs listed toward the top of this message as possible facilitators of the current hijacks of MNT-SERVERSGET, three are already fairly well known... at least in anti-spam circles... as being among "the usual suspects" when it comes to facilitating spamming and spammers. And no, I do not care to publicly specify which three. It may be true, as the saying goes that "On the Internet, nobody knows that you're a dog", but memories are long, and people don't forget if your company has been repeatedly caught acting like one.

1 0

Feedback - SBC Vendors.
by Ryan Finnesey 09 Aug '18

09 Aug '18

I am going to have to install a series of SBCs for a voice offering connected to Microsoft Teams. We are going to pass the SIP traffic off to a larger number of SIP providers. I would like to get some feedback from the group on SBC vendors. I have two options for vendors Ribbon or AudioCodes. I am leaning towards a software based SBC over an appliance. Would be helpful to get the other members feedback on Ribbon or AudioCodes deployments within their networks. Cheers Ryan

7 8

Yahoo Groups contact
by Andy Ringsmuth 09 Aug '18

09 Aug '18

Any chance someone here has admin/troubleshooting involvement with Yahoo Groups, or knows someone who does? Much appreciated. ---- Andy Ringsmuth andy(a)newslink.com 5609 Harding Dr. Lincoln, NE 68521 (402) 304-0083 cellular

1 0

Akamai Contact
by Jawaid Bazyar 09 Aug '18

09 Aug '18

Hi, having trouble engaging with an Akamai contact in relation to the server stack we have here. Feel free to contact me. -- Jawaid Bazyar President ph 303.815.1814 fax 303.815.1001 Jawaid.Bazyar(a)foreThought.net <email:Jawaid.Bazyar@foreThought.net> <http://www.foreThought.net>

3 2

Re: Multicast traffic % in enterprise network ?
by Scott Weeks 09 Aug '18

09 Aug '18

--- jtk(a)depaul.edu wrote: From: John Kristoff <jtk(a)depaul.edu> :: In my experience, real world IP multicast experience :: and expertise is almost non-existent. :: but it tends to just work once setup and rarely :: changes. :: the setup was done a long time ago and people rarely :: touch it now. :: If I want to simplify and secure things a little :: more, I'd probably look at better limiting IGMP and :: PIM joins. Limiting as much of the possibility for :: anyone or anything to instantiate state in the :: network Major snippage, but these're my experiences, too. However, not in the .edu world. scott

2 1

Nokia SP Business Group Account Contact
by Brant Ian Stevens 09 Aug '18

09 Aug '18

Sorry to bother the list, but could someone help me get in touch with a Nokia account rep from their SP team for the NYC area? Specifically looking for information on the managed sp wireless solution. I've tried going through the website, but have made no progress reaching the right people to move my request forward. -- Regards, -- Brant I. Stevens

1 1

Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
by Marcus Leske 09 Aug '18

09 Aug '18

What do you mean ? Examples of Telemetry use cases are infinite? Are you asking for popular use cases that were not possible with snmp and netflow? Cheers On Sunday, August 5, 2018, Sami Joseph <sami.joseph(a)gmail.com> wrote: > On the topic of marketing hypes vs real requirements, does anyone see real > use cases for telemetry ? Can anyone pls give me examples? > > Thanks > > On Sunday, July 8, 2018, <adamv0025(a)netconsultings.com> wrote: > >> > From: Marcus Leske [mailto:marcusleskex@gmail.com] >> > Sent: Saturday, July 07, 2018 3:58 PM >> > >> > open APIs tops that funny abuse list IMHO : >> > https://github.com/OAI/OpenAPI-Specification/issues/568 >> > >> > can we change the topic of the thread to an informative one, instead of >> a >> > leaked video or not, to why exactly do network engineers are often >> > confused by the abusive marketing all over the place of what is open and >> > what is not and other computing terms. >> > >> > I guess this is happening in networking more often than other domains >> > because networking people didnt get a chance in their career to learn >> about >> > the world of computing, their heads were somewhere else, learning about >> > complex networking protocols and not the common computing interfaces, >> > the open source world, existing frameworks and paradigms, this video >> helps >> > a bit on how did this happen: >> > https://vimeo.com/262190505https://vimeo.com/262190505 >> > >> > has anyone here seen list of topics that network engineers usually miss >> on >> > their journey ? i know they never get exposed to software development >> > and engineering in general, databases, web technologies, operating >> system >> > fundamentals. >> > >> Well I guess if you stick around in networking for long time you kind of >> get exposed to some of these to a certain level on a day job, some of it >> was covered in school in various levels of detail, and to some of these >> concepts we (networkers) get a specific very narrow filed exposure I'd say, >> like in your example of databases -well various protocol tables are good >> examples of decentralized distributed databases, then some Network OS-es >> are good examples of distributed operating systems. So I guess it then just >> boils down to the willingness of and individual to understand these >> concepts on an ever more fundamental level -with every next interaction >> with these. Maybe it draws one more towards the software development side >> or perhaps more towards the somewhat holistic understanding of the >> networking discipline through graph theory and complex adaptive systems. >> >> >> adam >> >> netconsultings.com >> ::carrier-class solutions for the telecommunications industry:: >> >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp(a)puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >

1 0