January 2017 - Test - lists.nanog.org

ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
by Fernando Gont 13 Jan '17

13 Jan '17

Folks, I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 and/or IPv6 fragments targeted to BGP routers (off-list datapoints are welcome). In any case, you mind find it worth reading to check if you're affected (from Section 2 of recently-published RFC8021): ---- cut here ---- The security implications of IP fragmentation have been discussed at length in [RFC6274] and [RFC7739]. An attacker can leverage the generation of IPv6 atomic fragments to trigger the use of fragmentation in an arbitrary IPv6 flow (in scenarios in which actual fragmentation of packets is not needed) and can subsequently perform any type of fragmentation-based attack against legacy IPv6 nodes that do not implement [RFC6946]. That is, employing fragmentation where not actually needed allows for fragmentation-based attack vectors to be employed, unnecessarily. We note that, unfortunately, even nodes that already implement [RFC6946] can be subject to DoS attacks as a result of the generation of IPv6 atomic fragments. Let us assume that Host A is communicating with Host B and that, as a result of the widespread dropping of IPv6 packets that contain extension headers (including fragmentation) [RFC7872], some intermediate node filters fragments between Host B and Host A. If an attacker sends a forged ICMPv6 PTB error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario. Another possible scenario is that in which two BGP peers are employing IPv6 transport and they implement Access Control Lists (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If the aforementioned BGP peers drop IPv6 fragments but still honor received ICMPv6 PTB error messages, an attacker could easily attack the corresponding peering session by simply sending an ICMPv6 PTB message with a reported MTU smaller than 1280 bytes. Once the attack packet has been sent, the aforementioned routers will themselves be the ones dropping their own traffic. ---- cut here ---- Is this something waiting to be exploited? Am I missing something? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

4 15

Bandwidth Savings
by Keenan Singh 13 Jan '17

13 Jan '17

Hi Guys We are an ISP in the Caribbean, and are faced with extremely high Bandwidth costs, compared to the US, we currently use Peer App for Caching however with most services now moving to HTTPS the cache is proving to be less and less effective. We are currently looking at any way we can save on Bandwidth or to be more Efficient with the Bandwidth we currently have. We do have a Layer 2 Circuit between the Island and Miami, I am seeing there are WAN Accelerators where they would put a Server on either end and sort of Compress and decompress the Traffic before it goes over the Layer 2, I have never used this before, has any one here used anything like this, what results would I be able to expect for ISP Traffic? If not any ideas on Bandwidth Savings, or being more Efficient with want we currently. Many thanks for any Help Keenan

11 14

Weekly Routing Table Report
by cscora＠apnic.net 13 Jan '17

13 Jan '17

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, SAFNOG, SdNOG, BJNOG, CaribNOG 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 14 Jan, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 628138 Prefixes after maximum aggregation (per Origin AS): 221607 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 304580 Total ASes present in the Internet Routing Table: 55581 Prefixes per ASN: 11.30 Origin-only ASes present in the Internet Routing Table: 36240 Origin ASes announcing only one prefix: 15211 Transit ASes present in the Internet Routing Table: 6557 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 55 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 51 Unregistered ASNs in the Routing Table: 16 Number of 32-bit ASNs allocated by the RIRs: 16861 Number of 32-bit ASNs visible in the Routing Table: 12784 Prefixes from 32-bit ASNs in the Routing Table: 52671 Number of bogon 32-bit ASNs visible in the Routing Table: 725 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 381 Number of addresses announced to Internet: 2832873956 Equivalent to 168 /8s, 218 /16s and 57 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 208158 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156458 Total APNIC prefixes after maximum aggregation: 43125 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 171200 Unique aggregates announced from the APNIC address blocks: 70946 APNIC Region origin ASes present in the Internet Routing Table: 5188 APNIC Prefixes per ASN: 33.00 APNIC Region origin ASes announcing only one prefix: 1135 APNIC Region transit ASes present in the Internet Routing Table: 941 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 55 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2610 Number of APNIC addresses announced to Internet: 761620356 Equivalent to 45 /8s, 101 /16s and 103 /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-137529 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: 188178 Total ARIN prefixes after maximum aggregation: 89286 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195218 Unique aggregates announced from the ARIN address blocks: 89636 ARIN Region origin ASes present in the Internet Routing Table: 16064 ARIN Prefixes per ASN: 12.15 ARIN Region origin ASes announcing only one prefix: 5595 ARIN Region transit ASes present in the Internet Routing Table: 1718 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1702 Number of ARIN addresses announced to Internet: 1104227488 Equivalent to 65 /8s, 209 /16s and 44 /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-397212 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: 151356 Total RIPE prefixes after maximum aggregation: 73249 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 162799 Unique aggregates announced from the RIPE address blocks: 99050 RIPE Region origin ASes present in the Internet Routing Table: 18151 RIPE Prefixes per ASN: 8.97 RIPE Region origin ASes announcing only one prefix: 7762 RIPE Region transit ASes present in the Internet Routing Table: 3050 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5104 Number of RIPE addresses announced to Internet: 709410176 Equivalent to 42 /8s, 72 /16s and 189 /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: 64045 Total LACNIC prefixes after maximum aggregation: 12654 LACNIC Deaggregation factor: 5.06 Prefixes being announced from the LACNIC address blocks: 80795 Unique aggregates announced from the LACNIC address blocks: 37929 LACNIC Region origin ASes present in the Internet Routing Table: 2483 LACNIC Prefixes per ASN: 32.54 LACNIC Region origin ASes announcing only one prefix: 548 LACNIC Region transit ASes present in the Internet Routing Table: 592 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3082 Number of LACNIC addresses announced to Internet: 171021888 Equivalent to 10 /8s, 49 /16s and 150 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 15378 Total AfriNIC prefixes after maximum aggregation: 3286 AfriNIC Deaggregation factor: 4.68 Prefixes being announced from the AfriNIC address blocks: 17745 Unique aggregates announced from the AfriNIC address blocks: 6672 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 24.11 AfriNIC Region origin ASes announcing only one prefix: 171 AfriNIC Region transit ASes present in the Internet Routing Table: 186 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 286 Number of AfriNIC addresses announced to Internet: 86134016 Equivalent to 5 /8s, 34 /16s and 77 /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 5544 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3731 390 255 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2731 11133 742 KIXS-AS-KR Korea Telecom, KR 9829 2684 1498 535 BSNL-NIB National Internet Backbone, IN 9808 2296 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2047 428 217 TATACOMM-AS TATA Communications formerl 45899 1808 1265 100 VNPT-AS-VN VNPT Corp, VN 4808 1638 1790 453 CHINA169-BJ China Unicom Beijing Provin 24560 1561 562 245 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd 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 22773 3613 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3256 1333 82 SHAW - Shaw Communications Inc., CA 18566 2194 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2094 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1959 2023 403 CHARTER-NET-HKY-NC - Charter Communicat 209 1734 5066 637 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1721 322 436 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1678 848 227 ITCDELTA - Earthlink, Inc., US 701 1599 10629 661 UUNET - MCI Communications Services, In 16509 1520 3028 521 AMAZON-02 - Amazon.com, 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 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 2995 1129 2135 AKAMAI-ASN1 , US 9121 2253 1707 94 TTNET , TR 34984 1991 327 374 TELLCOM-AS , TR 13188 1604 99 61 TRIOLAN , UA 12479 1427 1033 51 UNI2-AS , ES 6849 1312 355 22 UKRTELNET , UA 8551 1206 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1154 544 15 CORBINA-AS OJSC "Vimpelcom", RU 9198 1018 352 25 KAZTELECOM-AS , KZ 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 3533 544 173 Telmex Colombia S.A., CO 8151 2479 3374 548 Uninet S.A. de C.V., MX 11830 1799 368 66 Instituto Costarricense de Electricidad 6503 1544 437 54 Axtel, S.A.B. de C.V., MX 7303 1525 974 254 Telecom Argentina S.A., AR 6147 1352 377 27 Telefonica del Peru S.A.A., PE 28573 1054 2271 177 CLARO S.A., BR 3816 1007 479 179 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 993 236 87 Techtel LMDS Comunicaciones Interactiva 17072 968 127 346 TOTAL PLAY TELECOMUNICACIONES SA DE CV, 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 1294 398 42 LINKdotNET-AS, EG 36903 703 353 122 MT-MPLS, MA 37611 679 67 6 Afrihost, ZA 36992 580 1373 25 ETISALAT-MISR, EG 24835 492 658 16 RAYA-AS, EG 8452 489 1474 16 TE-AS TE-AS, EG 37492 401 290 74 ORANGE-TN, TN 29571 368 36 10 CITelecom-AS, CI 15399 316 35 6 WANANCHI-KE, KE 2018 287 327 74 TENET-1, ZA 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 5544 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3731 390 255 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3613 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3533 544 173 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3256 1333 82 SHAW - Shaw Communications Inc., CA 20940 2995 1129 2135 AKAMAI-ASN1 , US 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2731 11133 742 KIXS-AS-KR Korea Telecom, KR 9829 2684 1498 535 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3731 3476 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3613 3462 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3533 3360 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3256 3174 SHAW - Shaw Communications Inc., CA 17974 2984 2913 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2296 2263 CMNET-GD Guangdong Mobile Communication 9121 2253 2159 TTNET , TR 9829 2684 2149 BSNL-NIB National Internet Backbone, IN 18566 2194 2085 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom 65001 PRIVATE 94.242.128.0/20 15468 KLGELECS-AS 38, Teatralnaya st Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG 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:13 /10:36 /11:103 /12:276 /13:532 /14:1051 /15:1789 /16:13162 /17:7788 /18:13039 /19:25193 /20:38097 /21:40682 /22:73358 /23:61448 /24:350212 /25:550 /26:406 /27:292 /28:33 /29:18 /30:17 /31:0 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3053 3256 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2814 3613 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2087 2194 MEGAPATH5-US - MegaPath Corporation, US 9121 1581 2253 TTNET , TR 30036 1536 1721 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1448 3533 Telmex Colombia S.A., CO 6389 1392 2094 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1349 1604 TRIOLAN , UA 6983 1323 1678 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:829 4:25 5:2423 6:32 8:1025 12:1811 13:71 14:1773 15:23 16:2 17:106 18:128 19:1 20:51 23:1980 24:1814 27:2402 31:1847 32:89 33:9 34:1 35:3 36:389 37:2484 38:1308 39:45 40:99 41:2890 42:452 43:1919 44:54 45:2319 46:2559 47:108 49:1203 50:948 51:17 52:619 54:355 55:6 56:4 57:40 58:1599 59:979 60:389 61:1863 62:1505 63:1933 64:4544 65:2186 66:4389 67:2223 68:1166 69:3295 70:1302 71:570 72:2055 74:2595 75:400 76:416 77:1384 78:1572 79:923 80:1364 81:1414 82:967 83:722 84:867 85:1689 86:484 87:1129 88:778 89:2041 90:197 91:6112 92:984 93:2339 94:2347 95:2779 96:567 97:360 98:937 99:97 100:148 101:1232 103:13272 104:2678 105:147 106:473 107:1511 108:767 109:2547 110:1284 111:1665 112:1146 113:1289 114:1007 115:1637 116:1712 117:1610 118:2045 119:1585 120:945 121:1073 122:2262 123:2028 124:1571 125:1819 128:732 129:502 130:421 131:1362 132:560 133:187 134:517 135:211 136:385 137:408 138:1838 139:484 140:616 141:511 142:728 143:915 144:762 145:165 146:996 147:648 148:1402 149:561 150:679 151:924 152:708 153:313 154:726 155:955 156:544 157:573 158:431 159:1353 160:567 161:734 162:2464 163:533 164:771 165:1141 166:361 167:1249 168:2456 169:721 170:2546 171:263 172:897 173:1832 174:785 175:708 176:1752 177:4143 178:2418 179:1141 180:2075 181:1964 182:2183 183:1013 184:838 185:8453 186:3241 187:2249 188:2332 189:1779 190:8168 191:1290 192:9308 193:5765 194:4557 195:3858 196:1876 197:1248 198:5606 199:5800 200:7307 201:4135 202:10041 203:9841 204:4463 205:2768 206:2965 207:3153 208:3990 209:3881 210:3879 211:2079 212:2769 213:2446 214:848 215:65 216:5782 217:1978 218:824 219:602 220:1678 221:897 222:714 223:1149 End of report

1 0

You're invited to St. Louis Regional Internet Exchange - Preview (Jan 19, 2017)
by St. Louis Regional Internet Exchange 13 Jan '17

13 Jan '17

The St. Louis region to benefit from improved digital capacity and Smart City infrastructure capability.   To help address the demands of data oriented businesses and startups, the Internet of Things (IoT) and the Smart City, a team of industry recognized experts has developed the St. Louis Regional Internet Exchange or STL-RIX.   The St Louis Regional Internet Exchange is a not for profit corporation, in a collaborative partnership with the Smart City Internet Exchange (SCIX), the MidWest Internet Exchange and the St. Louis region.   When operational in February, this capability will provide an unprecedented opportunity for business collaboration, and Smart City economic development, for the St. Louis region.   Lightning Round Agenda: 10:30 AM Welcome - Owen Graham - Netrality Properties Keynote - Jerry Cox CEO Blendics and Founder of SLIAC Smart City St. Louis - Jim Highfill and David Sandel - Founders of Innovation Neighborhoods Business Structure - Andrew Ruben - PAULE, CAMAZINE & BLUMENTHAL, P.C Brief Tech and Ops Description - Mike Hammett and Justin Wilson (MIX), Nathan Schrenk (STL-RIX, SCIX) Market Perspective - Moderator: Noted Technical Writer David Strom, Ken Owens Cisco CTO Cloud Platforms and Services Group, Joe Wojtal VP SP Solutions WWT, Ken Harrington BayBerry Group, Richard Schreier Canadian Internet Registration Authority 11:40 AM Panel and Press - General Q&A Official Press Release Share this event on Facebook and Twitter We hope you can make it!Cheers,St. Louis Regional Internet Exchange ------------------------------ Event Summary: ------------------------------ Event: St. Louis Regional Internet Exchange - Preview Date: Thursday, January 19, 2017 from 10:30 AM to 12:00 PM (CST) Location: CIC - The Havana Room 4240 Duncan Avenue St. Louis, MO 63110 ------------------------------ Event Details: ------------------------------ The St. Louis region to benefit from improved digital capacity and Smart City infrastructure capability. To help address the demands of data oriented businesses and startups, the Internet of Things (IoT) and the Smart City, a team of industry recognized experts has developed the St. Louis Regional Internet Exchange or STL-RIX. The St Louis Regional Internet Exchange is a not for profit corporation, in a collaborative partnership with the Smart City Internet Exchange (SCIX), the MidWest Internet Exchange and the St. Louis region. When operational in February, this capability will provide an unprecedented opportunity for business collaboration, and Smart City economic development, for the St. Louis region. Lightning Round Agenda: 10:30 AM Welcome - Owen Graham - Netrality Properties Keynote - Jerry Cox CEO Blendics and Founder of SLIAC Smart City St. Louis - Jim Highfill and David Sandel - Founders of Innovation Neighborhoods Business Structure - Andrew Ruben - PAULE, CAMAZINE & BLUMENTHAL, P.C Brief Tech and Ops Description - Mike Hammett and Justin Wilson (MIX), Nathan Schrenk (STL-RIX, SCIX) Market Perspective - Moderator: Noted Technical Writer David Strom, Ken Owens Cisco CTO Cloud Platforms and Services Group, Joe Wojtal VP SP Solutions WWT, Ken Harrington BayBerry Group, Richard Schreier Canadian Internet Registration Authority 11:40 AM Panel and Press - General Q&A Official Press Release ------------------------------ Hosted By: ------------------------------ St. Louis Regional Internet Exchange The St Louis Regional Internet Exchange (STL-RIX), is a not-for-profit corporation in a collaborative partnership with the Midwest Internet Exchange (MIX), and Smart City Internet Exchange (SCIX). STL-RIX offers both traditional IX services as well as an additional switch fabric for the provisioning of Smart City and (IoT) services. ------------------------------ Register Online: ------------------------------ More information and online registration are available here: https://www.eventbrite.com/e/st-louis-regional-internet-exchange-preview-ti… ---------------------------------------------------------------------- Collect event fees online with Eventbrite http://www.eventbrite.com

1 0

Advice re network compromise and "law enforcement" (PCI certification)
by David H 11 Jan '17

11 Jan '17

Hi all, I figure there's probably some folks on the list that have hands in environments that touch credit cards. Unlike HIPAA compliance, or even social security numbers, PCI is very ambiguous about what must occur if a network/systems breach occurs that exposes credit card data. PCI, and its auditors, don't seem to want to tell you what your security policy should state with regard to what constitutes an event worthy of 'law enforcement' contact, nor what agency is appropriate, yet they require you to have such a policy in place. Anyone have pointers/advice on what you came up with for a reasonable definition of events that warrant involving law enforcement, and then what agency/agencies would be contacted? We're obviously not going to waste the time, on either side, of calling the FBI if one credit card number is stolen since they won't care, nor would the local police, who don't even have a cybercrime section. Generic policies covering network breaches and law enforcement would be welcome too; may be able to work it into something that is appropriate for our environment and credit card data. Thanks, David

5 4

Re: Bandwidth Savings
by Marty Strong 11 Jan '17

11 Jan '17

Seemingly also a GGC is there: https://ix.tt/cache-services-now-live-at-ttix/ maybe if the cost is low it might be worth it, assuming the incumbent doesn’t make it prohibitive. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty(a)cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 11 Jan 2017, at 22:17, Martin Hannigan <hannigan(a)gmail.com> wrote: > > > > > There's also an IXP in Trinidad: > > https://www.peeringdb.com/ix/940 > > [ .. ] > > https://ix.tt/membership/founding-members/ > > That doesn't mean a lot other than there's an IXP with at least Akamai and Columbus. I know the Akamai cache is there because I put it there. > > I was going to point at CaribNOG, but the MX is null and they're off the air. > > Best, > > -M< > > > > > On Wed, Jan 11, 2017 at 4:34 PM, Marty Strong via NANOG <nanog(a)nanog.org> wrote: > I believe the ISP is located in Trinidad & Tobago. > > There are five international submarine cables that land on the island: > - SG-SCS > - Americas-II > - ECFS > - Southern Caribbean Fiber > - ECLink > > Of those, 1 go to the closest real interconnectivity hub of Miami, with the others requiring another pair onwards. > > ECLink lands in Curaçao, which could give access to AMS-IX Caribbean, which may help with connectivity to content providers, both Akamai and Goole are live and we are in the process of connecting (https://cw.ams-ix.net/connected_parties) Pricing however, is probably just as expensive on that cable than to Miami. > > It would be interesting to hear from the OP the rough pricing for connectivity to Miami, vs. elsewhere. > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty(a)cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > > > On 11 Jan 2017, at 21:23, Eric Kuhnke <eric.kuhnke(a)gmail.com> wrote: > > > > The challenges are almost certainly economics related, at the lack of > > competition and high costs for layer 1/2 transport from his Caribbean > > island to Miami. Via whatever submarine cables exist that are controlled by > > larger ILEC type entities/telcos. Or satellite (whether geostationary > > transponder capacity or o3b). > > > > Depending on what island we're talking about, the $$$$$/month for a single > > 1GbE or 10GbE layer 2 transport service from $ISLAND to Miami will be very > > high compared to what a network operator in the US 48 states is accustomed > > to paying. > > > > On Wed, Jan 11, 2017 at 12:55 PM, Richard Hicks <richard.hicks(a)gmail.com> > > wrote: > > > >> > >> I don't know the the Caribbean Internet Exchanges market. Are any worth > >> peering at versus buying additional L2 bandwidth to Miami? > >> > >> https://cw.ams-ix.net/ > >> http://www.ocix.net/ocix/ > >> > >> Rick > >> > >> On Tue, Jan 10, 2017 at 8:08 PM, Keenan Singh <keenansingh(a)airlinktt.net> > >> wrote: > >> > >>> Hi Guys > >>> > >>> We are an ISP in the Caribbean, and are faced with extremely high > >> Bandwidth > >>> costs, compared to the US, we currently use Peer App for Caching however > >>> with most services now moving to HTTPS the cache is proving to be less > >> and > >>> less effective. We are currently looking at any way we can save on > >>> Bandwidth or to be more Efficient with the Bandwidth we currently have. > >> We > >>> do have a Layer 2 Circuit between the Island and Miami, I am seeing there > >>> are WAN Accelerators where they would put a Server on either end and sort > >>> of Compress and decompress the Traffic before it goes over the Layer 2, I > >>> have never used this before, has any one here used anything like this, > >> what > >>> results would I be able to expect for ISP Traffic? > >>> > >>> If not any ideas on Bandwidth Savings, or being more Efficient with want > >> we > >>> currently. > >>> > >>> Many thanks for any Help > >>> > >>> Keenan > >>> > >> > >

1 0

RE: Soliciting your opinions on Internet routing: A survey on BGP convergence
by Jakob Heitz (jheitz) 11 Jan '17

11 Jan '17

When you simply bring down an ebgp session, withdraws will propagate throughout the network. Soon after, the alternate routes will propagate. In the interim, some routers will lose connectivity. This problem is solved by graceful shutdown. This only works for planned shutdown This interim time can be many minutes because of the advertisement-interval (MRAI timer). A possible solution to reduce this interim to seconds instead of minutes is to set the MRAI timer to 0 on all routers. A potential problem with that is that any BGP instability in the network will cause some serious flapping. Another alternative is to use BGP add-path (rfc7911) to distribute backup routes. This will avoid the MRAI problem, but requires more memory on routers. This also works for accidental shutdown. Thanks, Jakob. > -----Original Message----- > From: Jakob Heitz (jheitz) > Sent: Tuesday, January 10, 2017 11:52 AM > To: nanog(a)nanog.org; 'baldur.norddahl(a)gmail.com' <baldur.norddahl(a)gmail.com> > Subject: RE: Soliciting your opinions on Internet routing: A survey on BGP convergence > > Hi Baldur, > > Have you tried graceful shutdown? > You need redundant links, but not to the same transit. > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06 > This draft is expired, but it is actually implemented by several vendors. > > I implemented this. > http://www.slideshare.net/bduvivie/bgp-graceful-shutdown-ios-xr > I added an option to configure AS-path prepends in case the gshut community was not supported by peers. > > Thanks, > Jakob. > > > > Date: Tue, 10 Jan 2017 03:51:04 +0100 > > From: Baldur Norddahl <baldur.norddahl(a)gmail.com> > > > > Hello > > > > I find that the type of outage that affects our network the most is > > neither of the two options you describe. As is probably typical for > > smaller networks, we do not have redundant uplinks to all of our > > transits. If a transit link goes, for example because we had to reboot a > > router, traffic is supposed to reroute to the remaining transit links. > > Internally our network handles this fairly fast for egress traffic. > > > > However the problem is the ingress traffic - it can be 5 to 15 minutes > > before everything has settled down. This is the time before everyone > > else on the internet has processed that they will have to switch to your > > alternate transit. > > > > The only solution I know of is to have redundant links to all transits. > > Going forward I will make sure we have this because it is a huge > > disadvantage not being able to take a router out of service without > > causing downtime for all users. Not to mention that a router crash or > > link failure that should have taken seconds at most to reroute, but > > instead causes at least 5 minutes of unstable internet. > > > > Regards, > > > > Baldur

1 0

OmanTel hijacking of IP space
by Jared Mauch 11 Jan '17

11 Jan '17

There is an ongoing pattern of OmanTel hijacking IP space and advertising it to many of their peers (but not transits). here’s the most recent announcement. This could be mitigated in a few days, such as filtering your peers on a prefix basis, or at minimum rejecting the private ASN space, eg: 64512-65535, as well as the 4 byte variant range: 4200000000-4294967294 Please take a moment and update your AS_PATH filters to minimize the pollution you accept or propagate. - Jared (more details - http://dyn.com/blog/iran-leaks-censorship-via-bgp-hijacks/ ) route-views>sh ip bgp 206.125.164.0/24 long BGP table version is 38506351, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 206.125.164.0 193.0.0.56 0 3333 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 123.108.254.218 0 9902 24218 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 i * 195.208.112.161 0 3277 3267 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 194.85.40.15 0 3267 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 212.66.96.126 0 20912 1267 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 95.85.0.2 0 200130 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 5.101.110.2 0 202018 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i *> 103.247.3.45 0 58511 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 80.241.176.31 0 20771 47872 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i

2 1

SoCal FIOS outage(?) / static IP readdressing
by Paul B. Henson 11 Jan '17

11 Jan '17

So I woke up this morning to discover my business FIOS had croaked about 3:30 AM :(. Everything looked good on the ONT, but couldn't ping the gateway. Poked at it from the other side, and it looked like traceroute died a hop or so short of what I remember, so seemed to be a layer 3 issue on their side. Called support, killed an hour going through the level 1 checklist (I suppose I understand why they have to do it, but it doesn't make it any less frustrating to have to do the reset/power cycle/cable reseat dance when you already know it's not going to change a thing). Finally talked her into escalating the issue, and was told there was a known outage in my area with reference #37202878, no cause provided, and no ETA on resolution. Yay. So I opened a chat session a little bit ago to see if I could get an update on when my FIOS might come back. Of course the support tech wanted to lead me through the dance again <sigh>, but I explained my earlier conversation and asked him if he could just update me on the outage. He said he had no record of that outage. I talked him into escalating the issue again. He said his escalation engineer had never heard of that outage or that reference number, and that everything seemed fine with my FIOS, and I should just try resetting the ONT again 8-/. So here I am, still with no FIOS, a general outage that may or may not exist, and support techs with different stories :(. The last time I had a problem like this my FIOS was down about three days, level 1 and level 2 support swore there was nothing wrong with it and had actually scheduled a truck roll to replace my ONT, and it turned out to be an accidental misconfiguration that took a while to resolve. I'm assuming something similar happened again this time, same mysterious layer 3 breakage in the middle of the night, same claims by layer 1 and layer 2 support that there's nothing wrong, same obvious layer 3 functionality issues. I'm guessing it will eventually just start working again. Hopefully it won't be three days this time. If anybody in Frontier land wants to throw a fellow network admin a bone and has any information on this potential outage or when my FIOS might come back online I'd really appreciate knowing :). On another note, I was wondering if anybody has had their static FIOS IP addresses migrated from Verizon space to Frontier space yet? Last April they said they are going to do it by this April, which only leaves four months. So far I haven't heard anything about it regarding my account. Thanks…

16 27

RE: Soliciting your opinions on Internet routing: A survey on BGP convergence
by Jakob Heitz (jheitz) 10 Jan '17

10 Jan '17

Hi Baldur, Have you tried graceful shutdown? You need redundant links, but not to the same transit. https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06 This draft is expired, but it is actually implemented by several vendors. I implemented this. http://www.slideshare.net/bduvivie/bgp-graceful-shutdown-ios-xr I added an option to configure AS-path prepends in case the gshut community was not supported by peers. Thanks, Jakob. > Date: Tue, 10 Jan 2017 03:51:04 +0100 > From: Baldur Norddahl <baldur.norddahl(a)gmail.com> > > Hello > > I find that the type of outage that affects our network the most is > neither of the two options you describe. As is probably typical for > smaller networks, we do not have redundant uplinks to all of our > transits. If a transit link goes, for example because we had to reboot a > router, traffic is supposed to reroute to the remaining transit links. > Internally our network handles this fairly fast for egress traffic. > > However the problem is the ingress traffic - it can be 5 to 15 minutes > before everything has settled down. This is the time before everyone > else on the internet has processed that they will have to switch to your > alternate transit. > > The only solution I know of is to have redundant links to all transits. > Going forward I will make sure we have this because it is a huge > disadvantage not being able to take a router out of service without > causing downtime for all users. Not to mention that a router crash or > link failure that should have taken seconds at most to reroute, but > instead causes at least 5 minutes of unstable internet. > > Regards, > > Baldur

1 0