November 2014 - routing-wg - mailman.ripe.net

Weekly Routing Table Report
by Routing Analysis Role Account 07 Nov '14

07 Nov '14

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, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. 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 08 Nov, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 523431 Prefixes after maximum aggregation: 199835 Deaggregation factor: 2.62 Unique aggregates announced to Internet: 253728 Total ASes present in the Internet Routing Table: 48493 Prefixes per ASN: 10.79 Origin-only ASes present in the Internet Routing Table: 36280 Origin ASes announcing only one prefix: 16320 Transit ASes present in the Internet Routing Table: 6192 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 68 Max AS path prepend of ASN ( 55644) 61 Prefixes from unregistered ASNs in the Routing Table: 1788 Unregistered ASNs in the Routing Table: 434 Number of 32-bit ASNs allocated by the RIRs: 7832 Number of 32-bit ASNs visible in the Routing Table: 6021 Prefixes from 32-bit ASNs in the Routing Table: 21417 Number of bogon 32-bit ASNs visible in the Routing Table: 5 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 371 Number of addresses announced to Internet: 2713875332 Equivalent to 161 /8s, 194 /16s and 115 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 177009 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133276 Total APNIC prefixes after maximum aggregation: 36928 APNIC Deaggregation factor: 3.61 Prefixes being announced from the APNIC address blocks: 137306 Unique aggregates announced from the APNIC address blocks: 53553 APNIC Region origin ASes present in the Internet Routing Table: 4985 APNIC Prefixes per ASN: 27.54 APNIC Region origin ASes announcing only one prefix: 1198 APNIC Region transit ASes present in the Internet Routing Table: 866 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 68 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1160 Number of APNIC addresses announced to Internet: 737099840 Equivalent to 43 /8s, 239 /16s and 64 /24s Percentage of available APNIC address space announced: 86.1 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, 131072-135580 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: 172029 Total ARIN prefixes after maximum aggregation: 85452 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173896 Unique aggregates announced from the ARIN address blocks: 81551 ARIN Region origin ASes present in the Internet Routing Table: 16391 ARIN Prefixes per ASN: 10.61 ARIN Region origin ASes announcing only one prefix: 6081 ARIN Region transit ASes present in the Internet Routing Table: 1705 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 251 Number of ARIN addresses announced to Internet: 1053335744 Equivalent to 62 /8s, 200 /16s and 160 /24s Percentage of available ARIN address space announced: 55.7 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, 393216-394239 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: 125663 Total RIPE prefixes after maximum aggregation: 63695 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 131171 Unique aggregates announced from the RIPE address blocks: 82803 RIPE Region origin ASes present in the Internet Routing Table: 17789 RIPE Prefixes per ASN: 7.37 RIPE Region origin ASes announcing only one prefix: 8177 RIPE Region transit ASes present in the Internet Routing Table: 2914 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3177 Number of RIPE addresses announced to Internet: 691660420 Equivalent to 41 /8s, 57 /16s and 230 /24s Percentage of available RIPE address space announced: 100.6 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, 196608-202239 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: 58707 Total LACNIC prefixes after maximum aggregation: 10832 LACNIC Deaggregation factor: 5.42 Prefixes being announced from the LACNIC address blocks: 67577 Unique aggregates announced from the LACNIC address blocks: 30704 LACNIC Region origin ASes present in the Internet Routing Table: 2376 LACNIC Prefixes per ASN: 28.44 LACNIC Region origin ASes announcing only one prefix: 656 LACNIC Region transit ASes present in the Internet Routing Table: 470 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1370 Number of LACNIC addresses announced to Internet: 168403968 Equivalent to 10 /8s, 9 /16s and 164 /24s Percentage of available LACNIC address space announced: 100.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12244 Total AfriNIC prefixes after maximum aggregation: 2884 AfriNIC Deaggregation factor: 4.25 Prefixes being announced from the AfriNIC address blocks: 13110 Unique aggregates announced from the AfriNIC address blocks: 4787 AfriNIC Region origin ASes present in the Internet Routing Table: 732 AfriNIC Prefixes per ASN: 17.91 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 151 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 63 Number of AfriNIC addresses announced to Internet: 59895296 Equivalent to 3 /8s, 145 /16s and 238 /24s Percentage of available AfriNIC address space announced: 59.5 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 5547 4190 71 China Education and Research 4766 2952 11584 925 Korea Telecom 17974 2825 903 77 PT Telekomunikasi Indonesia 7545 2441 336 126 TPG Telecom Limited 4755 1915 411 187 TATA Communications formerly 9829 1671 1322 37 National Internet Backbone 4812 1520 2098 109 China Telecom (Group) 9808 1478 6639 15 Guangdong Mobile Communicatio 4808 1423 2213 429 CNCGROUP IP network China169 9583 1362 112 561 Sify Limited 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 6389 2894 3688 51 BellSouth.net Inc. 22773 2851 2956 144 Cox Communications Inc. 18566 2045 379 184 MegaPath Corporation 7029 2000 1960 317 Windstream Communications Inc 20115 1819 1797 476 Charter Communications 4323 1636 1052 409 tw telecom holdings, inc. 6983 1581 867 250 ITC^Deltacom 30036 1488 309 611 Mediacom Communications Corp 701 1428 11265 708 MCI Communications Services, 22561 1313 409 242 CenturyTel Internet Holdings, 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 34984 1842 298 356 TELLCOM ILETISIM HIZMETLERI A 20940 1496 579 1104 Akamai International B.V. 8402 1328 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1028 100 36 TOV "Bank-Inform" 8551 952 373 43 Bezeq International-Ltd 6849 829 356 26 JSC "Ukrtelecom" 9198 798 346 32 JSC Kazakhtelecom 6830 790 2339 437 Liberty Global Operations B.V 12479 765 786 96 France Telecom Espana SA 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 10620 3032 493 237 Telmex Colombia S.A. 28573 2500 2317 107 NET Serviços de Comunicação S 7303 1766 1171 241 Telecom Argentina S.A. 6147 1713 374 30 Telefonica del Peru S.A.A. 8151 1480 3021 426 Uninet S.A. de C.V. 6503 1203 433 58 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 914 2325 35 Tim Celular S.A. 27947 909 130 52 Telconet S.A 3816 891 383 149 COLOMBIA TELECOMUNICACIONES S 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 8452 1395 958 13 TE-AS 24863 958 280 26 Link Egypt (Link.NET) 6713 680 763 35 Office National des Postes et 36992 359 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 233 19 6 Data Telecom Service 37457 187 161 7 Telkom SA Ltd. 36947 179 807 13 Telecom Algeria 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 4538 5547 4190 71 China Education and Research 10620 3032 493 237 Telmex Colombia S.A. 4766 2952 11584 925 Korea Telecom 6389 2894 3688 51 BellSouth.net Inc. 22773 2851 2956 144 Cox Communications Inc. 17974 2825 903 77 PT Telekomunikasi Indonesia 28573 2500 2317 107 NET Serviços de Comunicação S 7545 2441 336 126 TPG Telecom Limited 18566 2045 379 184 MegaPath Corporation 7029 2000 1960 317 Windstream Communications Inc Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2894 2843 BellSouth.net Inc. 10620 3032 2795 Telmex Colombia S.A. 17974 2825 2748 PT Telekomunikasi Indonesia 22773 2851 2707 Cox Communications Inc. 28573 2500 2393 NET Serviços de Comunicação S 7545 2441 2315 TPG Telecom Limited 4766 2952 2027 Korea Telecom 18566 2045 1861 MegaPath Corporation 4755 1915 1728 TATA Communications formerly 7029 2000 1683 Windstream Communications Inc Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 Xnet Media LLC 23.252.224.0/21 62502 Xnet Media LLC 23.252.232.0/21 62502 Xnet Media LLC 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>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:16 /9:12 /10:31 /11:90 /12:262 /13:500 /14:1012 /15:1718 /16:13041 /17:7249 /18:12076 /19:25510 /20:36567 /21:38018 /22:55828 /23:49160 /24:279415 /25:1101 /26:1059 /27:705 /28:17 /29:19 /30:11 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2065 2851 Cox Communications Inc. 18566 2000 2045 MegaPath Corporation 6389 1674 2894 BellSouth.net Inc. 30036 1335 1488 Mediacom Communications Corp 6147 1333 1713 Telefonica del Peru S.A.A. 6983 1266 1581 ITC^Deltacom 7029 1219 2000 Windstream Communications Inc 34984 1162 1842 TELLCOM ILETISIM HIZMETLERI A 11492 1144 1195 CABLE ONE, INC. 10620 1067 3032 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1348 2:677 3:3 4:16 5:1193 6:21 8:772 12:1838 13:4 14:1183 15:17 16:2 17:42 18:21 20:51 23:957 24:1754 27:1817 31:1342 32:40 33:2 34:5 36:157 37:1817 38:1012 39:15 40:238 41:2955 42:348 43:603 44:20 45:80 46:2062 47:28 49:749 50:799 52:12 54:59 55:4 56:8 57:32 58:1197 59:717 60:438 61:1737 62:1242 63:1837 64:4415 65:2284 66:4182 67:2045 68:1092 69:3234 70:876 71:486 72:1986 74:2601 75:374 76:398 77:1603 78:901 79:773 80:1323 81:1287 82:807 83:663 84:713 85:1362 86:429 87:1172 88:500 89:1809 90:138 91:5812 92:804 93:1656 94:1929 95:1303 96:426 97:340 98:1091 99:48 100:67 101:783 103:6058 104:527 105:163 106:187 107:710 108:599 109:1984 110:1069 111:1443 112:733 113:900 114:800 115:1246 116:1213 117:1010 118:1587 119:1373 120:449 121:1021 122:2216 123:1699 124:1477 125:1601 128:644 129:387 130:377 131:933 132:422 133:164 134:322 135:82 136:325 137:317 138:385 139:202 140:229 141:419 142:598 143:445 144:512 145:110 146:676 147:555 148:1053 149:413 150:515 151:642 152:477 153:241 154:396 155:623 156:381 157:331 158:279 159:928 160:332 161:608 162:1856 163:371 164:648 165:669 166:363 167:690 168:1128 169:120 170:1428 171:215 172:60 173:1649 174:699 175:609 176:1518 177:3727 178:2087 179:812 180:1808 181:1809 182:1695 183:565 184:711 185:2321 186:2981 187:1659 188:2019 189:1538 190:7942 191:795 192:7748 193:5562 194:4048 195:3628 196:1662 197:795 198:5321 199:5482 200:6472 201:2910 202:9604 203:9016 204:4681 205:2665 206:3025 207:2962 208:3922 209:3799 210:3657 211:2035 212:2424 213:2197 214:861 215:84 216:5648 217:1710 218:718 219:549 220:1295 221:770 222:685 223:617 End of report

1 0

Draft minutes RIPE 68
by João Damas 07 Nov '14

07 Nov '14

As mentioned during the meeting at RIPE 69 this week, we managed to drop the ball on sending out the minutes from the previous working group meting, at RIPE 68. We are posting those now, below, and open a 2-week period for comments. Regards Joao Damas & Rob Evans Chairs, RIPE Routing WG === RIPE 68 - Routing Working Group 15 May 2014 14:00-16:00 Scribe: Anand Buddhev A. Administrivia João Damas, Working Group Chair, opened the meeting, thanking the stenographer, scribes and chat monitors. The minutes of RIPE 67 were declared approved and Joao asked the RIPE NCC to publish them. B. RDL: A Programmatic Approach to Generating Router Configurations- Benno Overeinder, NLnet Labs The presentation is available at: https://ripe68.ripe.net/presentations/366-ripe68-rdl-20140515.pdf Rudiger Volk, Deutsche Telekom, said that there was a big gap in the presentation about how policies can be applied, particularly in a modular way when a peer has an external relationship. He asked how well this model would work in the real world. Benno replied that this need more work, and he would be happy to involve Rudiger in it. Joao Damas said he understood how RDL helps with documenting, but didn't see the distinction between RDL programming the Autonomous System (AS) and configuring routers. Benno replied that these tools help shape our thoughts. RDL tries to express policy, and not to program routers. YANG and netconf can be used to actually configure routers, and RDL could be transformed into YANG; RDL is part of a toolset to configure routers. Geoff Houston, APNIC, said inter-domain routing is about negotiation. Peers express preferences. An AS cannot express absolute preferences. In routing, peers offer and accept. Geoff said that in RDL, things look more absolute, and can't quite understand what it might be useful for. Rudiger Volk said this engine has two views: one view shows inter-domain relations, which is public. The other view is for intra-domain policy, and probably internal and private. He asked whether RDL provides the ability to publish parts of the configuration as public and private. Andreas Polyrakis, GRNET, said that he was involved in the initial requirements gathering process, and was surprised by the presentation. He said that at the requirements level, many of Geoff's and Rudiger's concerns were listed. He said that RDL is a language to express policy, and a good language needs the ability to express different views of the policy, such as public policy that can be exported to the RIPE Database, and internal policy for use with neighbours. He said that the mailing list archives show that these requirements were indeed listed, but he wasn't sure how much of it was implemented in RDL. However he said Benno and Per were going in the right direction. C. Creating an Automated Prefix Filtering How-To - Job Snijders Job said that there was no good documentation about how to do prefix filtering. He wants the community to put together a how-to or document on how to do filtering, that can beginners can be directed to. He asked whether it was a good idea, and asked for volunteers. Some people raised their hands. Rudiger Volk said it was a good idea to write such a document, but that its biggest challenge would be to get figure out what reliable sources of data to use. Job agreed and said that he starts with the most accurate source and moves on to less and less reliable ones, and hopes for the best. At least documenting this process would be a big help to the community. Geoff Houston said this was not the first time such work had been attempted, and won't be the last time either. Job said he couldn't find references to any previous work. Geoff said it's difficult because one has to differentiate between customer and transit routes, and needs to know one's peer's policy. This isn't easy to do automatically. This is a long-standing problem, and is difficult to solve. He said that RPKI was invented to try and solve this problem, and the technology exists now, but nobody seems to be using it, and he doesn't know why. Job said that a small group of volunteers had stepped up to write this document, so he will set up a mailing list and get the work started. He also said that, if there is a need, they may write some helpful tools because the IRR toolset has been abandoned. Gert Doering, Spacenet, asked the room generally, on how we could get more people to filter. Many networks just accept junk. He referred to ISPs that accept all routes from customers without filtering. João Damas said that with such discussions, the problem is usually one of scope. Talking to external peers for filtering is dodgy. An audience speaker said it wasn't really about inter-domain routing, but more about transit carriers filtering routes from their customers. Rudiger said that a document on how to do filtering would help those who are not filtering. He said it is a valuable idea, but wasn't sure how successful will it be. Elvis Velea, V4Escrow, said that in Romania 99% of ISPs filter based on route objects. They mainly use proprietary scripts against the RIPE Database to generate filters. Gert was very happy to hear this. Elvis said he was surprised that, when he signed contracts with transit providers, they would allow him to announce any prefix without questions. An audience speaker said that, in Romania, most of the prefixes are filtered and must have a route object in the RIPE Database in order to be accepted. Mateo, Jaguar Networks, via remote participation, said that the main problem was getting people to update RIPE Database objects. The problem is worse when the customer is outside the RIPE region. An anonymous audience speaker said that in developing and emerging markets, customer networks change rapidly and is difficult to filter automatically. However, he thought that if there were a document, and perhaps tools to help, it would be appreciated. Elvis Velea said that even if a prefix is from outside the RIPE region, it can be added to the RIPE Database. D. Routing Resilience Manifesto- Andrei Robachevsky, Internet Society The presentation is available at: https://ripe68.ripe.net/presentations/365-20140515-Routing_Resilience.pdf Rudiger Volk said that he would be very reluctant to make statements about a minimum deployable state. A manifesto with minimum requirements has the danger that people who sign it will do no more than that. Setting a minimum target has the danger of not achieving much. This manifesto is a trade-off between a too low and too high mark. Andrei said this work has to start somewhere. Later, we can always introduce a second version of the manifesto with stricter requirements. Gert Doering disagreed with Rudiger. He said that it was important to reach many people. He said we should solve this problem ourselves before regulators come along and solve it for us, and it's a good way forward. He said that, if we reach this target and still need more, we can aim for a second version of the manifest. He supports this effort, and would be happy to have his company sign the manifesto. Daniel Karrenberg, unaffiliated, thanked Andrei for initiating this effort. He said that perhaps the principles should be formulated more generally rather than being too technical. A way forward, to avoid endless discussion, would be to describe the goals rather than a technical implementation. He then added that one should be be careful about perception of the third goal in the manifesto. He said that in this region we have solved it quite well, and having it in the manifesto may create the perception that there is a big issue to solve. Andrei Robachevsky asked Daniel whether some of the text was okay or not. Daniel said that some of the text was perhaps too short but added that Andrei should proceed with it. Andrei said he would take Daniel's feedback into account. Geoff Houston said that, in the IPv6 area, despite lots of documentation about how to implement it, people were not doing it. He said that a similar situation existed in routing. He argued that making such a statement would make it obvious that there exists a problem that is not being solved, and will invite regulatory intervention. Geoff pointed out the example of the route leak from an Indonesian operator, and said that it was not deliberate. He said that we need to understand the causes of incorrect routing, and solve that problem instead of stating the obvious with such a manifesto. Andrei said that the concept of the Tragedy of the Commons cannot be avoided in large communities. He said that our collective collaborative nature can help. He said that by having a manifesto, we make the statement more tangible and visible. Geoff said that this was not a tragedy of the commons type of situation. In a tragedy of commons, one's self-interest is stronger than the common interest. However, this is not the case here. Geoff said that routing problems are not necessarily about self-interest. He summarised by saying that the problem here is more difficult to identify, and that the concept of the Tragedy of Commons does not apply here. Andrei said he would talk to Geoff some more about this later. Sandy Murphy, PARSONS, said that network operators will use prefix-based filters, a common practice to solve the issue of identifying the legitimate origin of a prefix. This solution already appears in many documents about routing security and routing best practices. She asked what it will mean when an operator signs this document. Andrei said that signing this document will mean that an operator is not just agreeing to the principles, but applying them. It will create some sort of peer pressure, and thus carry more weight. He then said that more work was needed in the document to ensure that prefix filtering was not the only recommendation, but more of an example. E. BGP Blackholing Project – Join & Fight! - Łukasz Bromirski, Cisco Systems The presentation is available at: https://ripe68.ripe.net/presentations/369-bgp_bh_ripe.pdf Nick Hilliard, INEX, said that he really likes this tool from a technical viewpoint and would love to become involved in it. He said, however, that politically it is a disaster, and that all kinds of law enforcement agencies, courts and copyright holders would like it. He said it was a socially corrosive project, technically beautiful but covered in layer 9 issues. Lukasz agreed with Nick, and said that he was just trying to achieve something at a technical level. F. Setting up RPKI for Provider Independent (PI) End User Space- Alex Band, RIPE NCC The presentation is available at: https://ripe68.ripe.net/presentations/370-RPKI_for_PI.pdf João thanked Alex for his presentation, saying that that the process seems clear and simple. Erik Bais, A2B Internet, added that he had tried this tool. He asked how it would work for PI users who have moved to other sponsoring organisations. Alex said that he will look into this. G. RIPE Database Routing Update - Denis Walker, RIPE NCC During his presentation, Denis asked some questions of the community. His first question was about cleaning up the syntax of AUT-NUM objects in the RIPE Database. Rudiger Volk said that not everyone was using it in the same way, and that it should not be changed. Denis said he was asking for feedback. If the community feels that nothing is broken and doesn't need a fix then the RIPE NCC will do nothing. He then asked about deletion of orphaned ASN objects and what should be done. Alex le Heux, Kobo Inc., said that the RIPE NCC should do nothing. Rudiger Volk said that a cleanup is not necessary. He said that there's a lot of garbage in the various routing registries in the world. Denis said that "we" don't want garbage in the RIPE Database. Rudiger said that we should just leave things as they are, and not interfere with objects maintained by people. João Damas agreed with Rudiger. He said perhaps warnings were okay, but do not do a cleanup. Alex le Heux said that even warnings may be too much work. He said that the operational impact would be low to none. Nick Hilliard said that RPSL syntax was convoluted such that trying to clean up may cause problems. Denis Walker said that there was an action on the RIPE NCC from the RIPE NCC Services Working Group to clean up these references. João said that the consensus from the Routing Working Group was to not do any cleanup. Denis said that emails were sent to people to clean up their own objects and reference. Some people had done this but most had not. H. Charter Discussion João commented that only Job Snijders had sent feedback on the proposed new charter. He invited the session participants to read it and to comment on the mailing list so that it can be wrapped up before the next RIPE Meeting. Z. AOB There were no other points of business. João thanked the room before closing the session.

1 0

Fwd: [stat-dev] RIPE routing registry (ab)used to legitimize prefix hijacks
by Daniel Karrenberg 06 Nov '14

06 Nov '14

Dear colleagues, maybe this is something you could find time to discuss at today's face-to-face meeting. I believe the points Rene raises are worth considering. I do not have a concrete proposal how to improve this undesirable state of things. Of course RPKI is the a better tool. But do we need to do something here before it is deployed widely? Daniel -------- Forwarded Message -------- Subject: [stat-dev] RIPE routing registry (ab)used to legitimize prefix hijacks Date: Thu, 06 Nov 2014 01:32:29 +0100 From: Rene Wilhelm <wilhelm(a)ripe.net> ... As per the below message from nanog.org list, AS201640 is hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. Interestingly, as shown in the RIPEstat AS routing consistency widget[*], some of the announcements get a touch of legitimacy by corresponding route objects in the RIPE routing registry; because the IP space is from other RIRs (apnic, afrinic), the usual checks for hierarchical authorization do not apply and hijackers can fool RIPE DB users, claim AS201640 is allowed to originate the hijacked prefixes. Is there anything we can do about that? remove the rogue objects? disallow new route objects with origin AS201640 in non-RIPE space? Do the RIPE DB terms and conditions have clauses which deal with entering false information? Even if it has no impact on the hijack in progress, I think it helps quality and reputation of RIPE routing registry if we act on dubious, most likely false, entries which are brought to our attention. -- Rene [*] https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS201640 -------- Original Message -------- Return-path: <nanog-bounces(a)nanog.org> Envelope-to: wilhelm(a)ripe.net Delivery-date: Wed, 05 Nov 2014 23:00:02 +0100 Received: from koko.ripe.net ([193.0.19.72]) by titi.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <nanog-bounces(a)nanog.org>) id 1Xm8cT-0008Am-OP; Wed, 05 Nov 2014 23:00:01 +0100 Received: from mail.nanog.org ([2001:1838:2001:8::10]) by koko.ripe.net with esmtp (Exim 4.72) (envelope-from <nanog-bounces(a)nanog.org>) id 1Xm8cS-0002Ry-LF; Wed, 05 Nov 2014 23:00:01 +0100 Received: from mail.nanog.org (localhost [127.0.0.1]) by mail.nanog.org (Postfix) with ESMTP id 9D2632D41A9; Wed, 5 Nov 2014 21:59:24 +0000 (UTC) X-Original-To: nanog(a)nanog.org Delivered-To: nanog(a)nanog.org Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mail.nanog.org (Postfix) with ESMTP id C10362D415F for <nanog(a)nanog.org>; Wed, 5 Nov 2014 21:59:17 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 297803AF26 for <nanog(a)nanog.org>; Wed, 5 Nov 2014 13:59:17 -0800 (PST) From: Ronald F. Guilmette <rfg(a)tristatelogic.com> To: nanog(a)nanog.org Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud Date: Wed, 05 Nov 2014 13:59:17 -0800 Message-ID: <81757.1415224757(a)server1.tristatelogic.com> X-BeenThere: nanog(a)nanog.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: North American Network Operators Group <nanog.nanog.org> List-Unsubscribe: <http://mailman.nanog.org/mailman/options/nanog>, <mailto:nanog-request@nanog.org?subject=unsubscribe> List-Archive: <http://mailman.nanog.org/pipermail/nanog/> List-Post: <mailto:nanog@nanog.org> List-Help: <mailto:nanog-request@nanog.org?subject=help> List-Subscribe: <http://mailman.nanog.org/mailman/listinfo/nanog>, <mailto:nanog-request@nanog.org?subject=subscribe> Errors-To: nanog-bounces(a)nanog.org Sender: "NANOG" <nanog-bounces(a)nanog.org> X-RIPE-Spam-Level: + X-RIPE-Spam-Report: Spam Total Points: 1.5 points pts rule name description ---- ---------------------- ------------------------------------ -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 4.0 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) X-RIPE-Signature: b6ab524b1e2ef58d696cc0c68bdb4d998c7e56c7a3ace7a0c536a4fd780385ef I already posted about this rogue AS days ago, but nothing has really changed much, since then, with respect to its hijacking of IP space. Well, at least Brian Krebs was kind anough to write about it: http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ (Please note that that is a convicted felon spamming from the hijacked IP space. He's not allowed to own firearms, but he _can_ apparently own a keyboard.) As of today, AS201640 is still hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. In fact, it would appear that the organization that is the registrant of AS201640 currently has exactly -zero- IP addresses to call its own. Nobody in a postion to _do_ anything about this gives a darn? As of today: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20

3 2