- NANOG - lists.nanog.org

Anyone from GoDaddy here?
by Mark Andrews 09 Oct '16

09 Oct '16

Can you please explain why you do not acknowledge reports of your nameservers being broken. Can you please explain why you are are blocking EDNS 1 queries over IPv4 when your servers are clearly capable of handling them over IPv6? Can you please explain why your servers mishandle EDNS flags? What part of the following is unclear. You *send* replies. The flag bits should be empty in the replies even if they are set in the request. You obviously are not ignore them as you echo them back (IPv6) or drop the query (IPv4). This will make the flag bits less useful when they are finally defined as no one will be able to depend on the bits not being echoed. We already have a flag bit where we can't depend on its return state (AD) because too many server just echo it. We do not need this to happen to any other bits. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. Mark Checking: 'utahtrust.gov' as at 2016-10-09T22:37:30Z utahtrust.gov @216.69.185.50 (pdns01.domaincontrol.com.) edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout docookie=ok edns@512tcp=ok optlist=nsid,subnet utahtrust.gov @2607:f208:207::32 (pdns01.domaincontrol.com.) edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok edns@512tcp=ok optlist=nsid,subnet utahtrust.gov @208.109.255.50 (pdns02.domaincontrol.com.) edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout docookie=ok edns@512tcp=ok optlist=nsid,subnet utahtrust.gov @2607:f208:303::32 (pdns02.domaincontrol.com.) edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok edns@512tcp=ok optlist=nsid,subnet The Following Tests Failed Warning: test failures may indicate that some DNS clients cannot resolve the zone or will get a unintended answer or resolution will be slower than necessary. Warning: failure to address issues identified here may make future DNS extensions that you want to use ineffective. In particular echoing back unknown EDNS options and unknown EDNS flags will break future signaling between DNS client and DNS server. We already have examples of this were you cannot depend on the AD flag bit meaning anything in replies because too many DNS servers just echo it back. Similarly the EDNS Client Subnet (ECS) option cannot just be sent to everyone in part because of servers just echoing it back. EDNS - Unknown Version Handling (edns1) dig +nocookie +norec +noad +edns=1 +noednsneg soa zone @server expect: BADVERS expect: OPT record with version set to 0 expect: not to see SOA See RFC6891, 6.1.3. OPT Record TTL Field Use EDNS - Unknown Version with Unknown Option Handling (edns1opt) dig +nocookie +norec +noad +edns=1 +noednsneg +ednsopt=100 soa zone @server expect: BADVERS expect: OPT record with version set to 0 expect: not to see SOA expect: that the option will not be present in response See RFC6891 EDNS - Unknown Flag Handling (ednsflags) dig +nocookie +norec +noad +ednsflags=0x80 soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: Z bits to be clear in response See RFC6891, 6.1.4 Flags Codes ok - test passed. nsid - NSID supported [RFC5001]. subnet - EDNS Client Subnet supported [RFC7871]. mbz - EDNS flags echoed back. timeout - lookup timed out. To retrieve this report in the future: https://ednscomp.isc.org/ednscomp/79f338bd47 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

1 0

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey
by Large Hadron Collider 09 Oct '16

09 Oct '16

Sorry florian. Meant to put it to list. On 2016-10-09 12:25 PM, Large Hadron Collider wrote: > > > On 2016-10-09 04:20 AM, Florian Weimer wrote: >> * Eliot Lear: >> >>> Not my end goal. My end goal is that consumers have a means to limit >>> risk in their home environments, and service providers have a means to >>> deliver that to them. >> They already have, with today's technology. It's just not a >> mass-market business. Consumers either have to educate themselves >> (which is not that hard), and service providers need to provide actual >> service, instead charging a fee for access to a computer system. >> >> There is little interest in this, however. There's a comparable >> business case for providing managed PCs to consumers, and I'm not sure >> if any such companies are still left. > I'd wager that after the Indian tech support fucks, they've went like > "too risky" > > But yeah there's a good case. If I had it in me I'd hire a bunch of > people to manage consumers' managed PCs. >> >>>> I'm not convinced that expected traffic profiles are the right answer. >>>> We already have that in the server hosting market, and it does >>>> constraint the types of services you can run on hosted servers (for >>>> the hosting providers who does this). I'm wary of the network putting >>>> severe constraints on application architecture, way beyond what is >>>> dictated by current technology. NAT more or less killed servers on >>>> consumer networks, and this kind of traffic profiling has begun to >>>> kill clients on server networks. >>> The whole point of MUD is to leave control in the hands of those who >>> have developed and have to support Things. It is not simply for the SP >>> to decide what traffic is ok, or to charge more for it, but to respect >>> the wishes of the developers. That may be sufficient to stop a lot of >>> bad things from happening to a lot of Things. >> Nobody respects what developers want, otherwise we wouldn't have any >> shipping products at all. >> >> What I'm trying to say: Cutting corners is more often a >> non-development decision. If you can ship today without any security, >> or at some unknowable date in the future, with additional security >> features whose impact may not matter, things usually head for the >> earlier shipping date. >> >> I used to be frustrated by such decisions, but over the past few >> years, I've come to realize that most of us have so little data on the >> effectiveness of security features that mandates for them are >> essentially arbitrary. >> >>> And again, this is the wrong way to look at it. The consumer should >>> always get final say. They're the customer. This is a chance for the >>> manufacturer of the device they're using to explain how the device is >>> supposed to behave on the network. >> If we want to make consumers to make informed decisions, they need to >> learn how things work up to a certain level. And then current >> technology already works. >> >> (Sorry that I'm not inclined to read upon the specs—I do wonder how >> this an improvement over UPnP.) >

1 0

Weekly Routing Table Report
by cscora＠apnic.net 07 Oct '16

07 Oct '16

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 08 Oct, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 613098 Prefixes after maximum aggregation (per Origin AS): 220270 Deaggregation factor: 2.78 Unique aggregates announced (without unneeded subnets): 299031 Total ASes present in the Internet Routing Table: 54952 Prefixes per ASN: 11.16 Origin-only ASes present in the Internet Routing Table: 36365 Origin ASes announcing only one prefix: 15357 Transit ASes present in the Internet Routing Table: 6515 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 54 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 59 Unregistered ASNs in the Routing Table: 16 Number of 32-bit ASNs allocated by the RIRs: 15672 Number of 32-bit ASNs visible in the Routing Table: 12072 Prefixes from 32-bit ASNs in the Routing Table: 48549 Number of bogon 32-bit ASNs visible in the Routing Table: 171 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 368 Number of addresses announced to Internet: 2831156388 Equivalent to 168 /8s, 192 /16s and 4 /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.3 Total number of prefixes smaller than registry allocations: 199304 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156388 Total APNIC prefixes after maximum aggregation: 42908 APNIC Deaggregation factor: 3.64 Prefixes being announced from the APNIC address blocks: 170156 Unique aggregates announced from the APNIC address blocks: 69373 APNIC Region origin ASes present in the Internet Routing Table: 5186 APNIC Prefixes per ASN: 32.81 APNIC Region origin ASes announcing only one prefix: 1148 APNIC Region transit ASes present in the Internet Routing Table: 939 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 54 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2406 Number of APNIC addresses announced to Internet: 760131012 Equivalent to 45 /8s, 78 /16s and 173 /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: 184574 Total ARIN prefixes after maximum aggregation: 89501 ARIN Deaggregation factor: 2.06 Prefixes being announced from the ARIN address blocks: 190411 Unique aggregates announced from the ARIN address blocks: 88508 ARIN Region origin ASes present in the Internet Routing Table: 16168 ARIN Prefixes per ASN: 11.78 ARIN Region origin ASes announcing only one prefix: 5673 ARIN Region transit ASes present in the Internet Routing Table: 1700 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: 1499 Number of ARIN addresses announced to Internet: 1107151264 Equivalent to 65 /8s, 253 /16s and 201 /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: 146152 Total RIPE prefixes after maximum aggregation: 71972 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 156615 Unique aggregates announced from the RIPE address blocks: 96828 RIPE Region origin ASes present in the Internet Routing Table: 18129 RIPE Prefixes per ASN: 8.64 RIPE Region origin ASes announcing only one prefix: 7815 RIPE Region transit ASes present in the Internet Routing Table: 3040 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 27 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5059 Number of RIPE addresses announced to Internet: 709023488 Equivalent to 42 /8s, 66 /16s and 215 /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: 62520 Total LACNIC prefixes after maximum aggregation: 12578 LACNIC Deaggregation factor: 4.97 Prefixes being announced from the LACNIC address blocks: 78550 Unique aggregates announced from the LACNIC address blocks: 37624 LACNIC Region origin ASes present in the Internet Routing Table: 2482 LACNIC Prefixes per ASN: 31.65 LACNIC Region origin ASes announcing only one prefix: 544 LACNIC Region transit ASes present in the Internet Routing Table: 587 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 22 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2844 Number of LACNIC addresses announced to Internet: 170638912 Equivalent to 10 /8s, 43 /16s and 190 /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: 14855 Total AfriNIC prefixes after maximum aggregation: 3301 AfriNIC Deaggregation factor: 4.50 Prefixes being announced from the AfriNIC address blocks: 16998 Unique aggregates announced from the AfriNIC address blocks: 6371 AfriNIC Region origin ASes present in the Internet Routing Table: 740 AfriNIC Prefixes per ASN: 22.97 AfriNIC Region origin ASes announcing only one prefix: 177 AfriNIC Region transit ASes present in the Internet Routing Table: 184 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: 264 Number of AfriNIC addresses announced to Internet: 83812096 Equivalent to 4 /8s, 254 /16s and 223 /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 5559 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3532 382 249 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2953 904 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2815 11131 853 KIXS-AS-KR Korea Telecom, KR 9829 2699 1497 532 BSNL-NIB National Internet Backbone, IN 9808 2185 8781 42 CMNET-GD Guangdong Mobile Communication 4755 2056 429 219 TATACOMM-AS TATA Communications formerl 4808 1769 2289 522 CHINA169-BJ China Unicom Beijing Provin 45899 1563 1235 90 VNPT-AS-VN VNPT Corp, VN 24560 1549 516 220 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 3526 2964 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6389 2218 3671 41 BELLSOUTH-NET-BLK - BellSouth.net Inc., 18566 2196 405 110 MEGAPATH5-US - MegaPath Corporation, US 20115 1941 1985 406 CHARTER-NET-HKY-NC - Charter Communicat 30036 1746 336 294 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1725 5070 658 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1677 848 227 ITCDELTA - Earthlink, Inc., US 701 1612 10674 674 UUNET - MCI Communications Services, In 16509 1424 2537 474 AMAZON-02 - Amazon.com, Inc., US 7018 1366 20092 1006 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 39891 3329 169 15 ALJAWWALSTC-AS , SA 20940 2805 1054 2007 AKAMAI-ASN1 , US 34984 1977 326 354 TELLCOM-AS , TR 12479 1360 1018 46 UNI2-AS , ES 13188 1267 99 57 BANKINFORM-AS , UA 8551 1206 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 6849 1142 355 21 UKRTELNET , UA 8402 1096 544 15 CORBINA-AS Russia, RU 12389 923 1120 406 ROSTELECOM-AS , RU 6830 892 2755 467 LGI-UPC formerly known as UPC Broadband 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 3497 540 183 Telmex Colombia S.A., CO 8151 2265 3353 556 Uninet S.A. de C.V., MX 7303 1547 958 246 Telecom Argentina S.A., AR 6503 1419 437 54 Axtel, S.A.B. de C.V., MX 11830 1322 367 57 Instituto Costarricense de Electricidad 6147 1230 377 27 Telefonica del Peru S.A.A., PE 28573 1000 2221 197 CLARO S.A., BR 7738 994 1882 40 Telemar Norte Leste S.A., BR 3816 974 471 195 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 906 125 76 Alestra, S. de R.L. de C.V., MX 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 1184 402 50 LINKdotNET-AS, EG 36903 682 343 125 MT-MPLS, MA 37611 665 67 6 Afrihost, ZA 36992 565 1373 25 ETISALAT-MISR, EG 8452 518 1471 15 TE-AS TE-AS, EG 37492 384 250 69 ORANGE-TN, TN 24835 350 611 17 RAYA-AS, EG 29571 332 37 12 CITelecom-AS, CI 15399 302 35 7 WANANCHI-KE, KE 2018 269 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 5559 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3532 382 249 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3526 2964 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3497 540 183 Telmex Colombia S.A., CO 39891 3329 169 15 ALJAWWALSTC-AS , SA 17974 2953 904 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2815 11131 853 KIXS-AS-KR Korea Telecom, KR 20940 2805 1054 2007 AKAMAI-ASN1 , US 9829 2699 1497 532 BSNL-NIB National Internet Backbone, IN 8151 2265 3353 556 Uninet S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3526 3380 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3497 3314 Telmex Colombia S.A., CO 39891 3329 3314 ALJAWWALSTC-AS , SA 7545 3532 3283 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2953 2875 TELKOMNET-AS2-AP PT Telekomunikasi Indo 6389 2218 2177 BELLSOUTH-NET-BLK - BellSouth.net Inc., 9829 2699 2167 BSNL-NIB National Internet Backbone, IN 9808 2185 2143 CMNET-GD Guangdong Mobile Communication 18566 2196 2086 MEGAPATH5-US - MegaPath Corporation, US 4766 2815 1962 KIXS-AS-KR Korea Telecom, KR 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 65512 PRIVATE 45.252.244.0/24 45899 VNPT-AS-VN VNPT Corp, VN 65512 PRIVATE 45.252.245.0/24 45899 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.249.144.0/20 40430 COLO4JAX-AS - colo4jax, LLC, US 27.100.7.0/24 56096 UNKNOWN 41.73.1.0/24 37004 -Reserved AS-, ZZ 41.73.2.0/24 37004 -Reserved AS-, ZZ 41.73.3.0/24 37004 -Reserved AS-, ZZ 41.73.4.0/24 37004 -Reserved AS-, ZZ 41.73.5.0/24 37004 -Reserved AS-, ZZ 41.73.6.0/24 37004 -Reserved AS-, ZZ 41.73.7.0/24 37004 -Reserved AS-, ZZ 41.73.8.0/24 37004 -Reserved AS-, ZZ 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:273 /13:523 /14:1052 /15:1775 /16:13173 /17:7840 /18:13061 /19:25397 /20:38800 /21:40321 /22:68217 /23:59789 /24:341400 /25:473 /26:397 /27:303 /28:57 /29:32 /30:13 /31:1 /32:33 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2896 3329 ALJAWWALSTC-AS , SA 22773 2747 3526 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2088 2196 MEGAPATH5-US - MegaPath Corporation, US 30036 1561 1746 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1422 3497 Telmex Colombia S.A., CO 6389 1416 2218 BELLSOUTH-NET-BLK - BellSouth.net Inc., 6983 1325 1677 ITCDELTA - Earthlink, Inc., US 34984 1262 1977 TELLCOM-AS , TR 11492 1211 1303 CABLEONE - CABLE ONE, INC., US 13188 1042 1267 BANKINFORM-AS , UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1670 2:786 4:23 5:2196 6:31 8:992 12:1800 13:44 14:1743 15:46 16:2 17:99 18:126 20:50 22:1 23:1869 24:1809 27:2322 31:1790 32:83 33:4 35:4 36:326 37:2321 38:1260 39:36 40:102 41:2970 42:453 43:1862 44:45 45:2150 46:2544 47:98 49:1178 50:911 51:13 52:553 53:2 54:350 55:6 56:4 57:41 58:1568 59:1018 60:376 61:1826 62:1510 63:1917 64:4581 65:2175 66:4271 67:2216 68:1131 69:3267 70:1284 71:557 72:2080 74:2583 75:402 76:415 77:1404 78:1217 79:925 80:1307 81:1406 82:988 83:705 84:872 85:1575 86:482 87:1134 88:553 89:2095 90:222 91:6104 92:918 93:2369 94:2418 95:2496 96:578 97:344 98:958 99:89 100:147 101:1157 103:12506 104:2566 105:126 106:441 107:1435 108:780 109:2277 110:1278 111:1638 112:1069 113:1145 114:1084 115:1688 116:1678 117:1569 118:2050 119:1578 120:937 121:1122 122:2268 123:2035 124:1569 125:1827 128:693 129:438 130:419 131:1379 132:607 133:175 134:488 135:198 136:386 137:397 138:1781 139:431 140:601 141:447 142:668 143:957 144:726 145:165 146:956 147:653 148:1392 149:540 150:659 151:899 152:673 153:301 154:693 155:950 156:529 157:533 158:389 159:1207 160:517 161:735 162:2408 163:570 164:775 165:1120 166:336 167:1188 168:2253 169:658 170:1992 171:252 172:748 173:1738 174:767 175:671 176:1727 177:4038 178:2244 179:1174 180:2148 181:1918 182:2080 183:1006 184:835 185:7591 186:3201 187:2149 188:2208 189:1757 190:7832 191:1302 192:9040 193:5745 194:4461 195:3849 196:1784 197:1214 198:5589 199:5757 200:7176 201:3705 202:10120 203:9838 204:4513 205:2735 206:2999 207:3075 208:4069 209:3872 210:3887 211:2045 212:2731 213:2347 214:861 215:68 216:5704 217:1989 218:804 219:611 220:1634 221:880 222:698 223:1311 End of report

1 0

Re: AS47860 - 93.175.240.0/20 - Wiskey Tango Foxtrot
by Martin List-Petersen 07 Oct '16

07 Oct '16

On 06/10/16 16:38, Sandra Murphy wrote: > Private reply: > > bgp.he.net sees it. For me. > > http://bgp.he.net/net/93.175.240.0/20 > > I don’t know why they do and you do not. > > —Sandy That just means, they "have" seen it. Not that they're seeing it right now, actually. I checked our feed, which you also can at http://lg.as42227.net And various upstream looking glasses, for example HE.net's actually. https://lg.he.net/ NIKHEF Amsterdam Interxion Copenhagen he.net Freemont 2 None of them have the route in the table. Even the CIDR report reports, that it's withdrawn: http://www.cidr-report.org/cgi-bin/as-report?as=AS47860&view=2.0 But it has been seen in the last 7 days. Kind regards, Martin List-Petersen Airwire Ltd. > > >> On Oct 6, 2016, at 4:34 AM, Martin List-Petersen <martin(a)airwire.ie> wrote: >> >> On 06/10/16 00:55, Ronald F. Guilmette wrote: >>> Anyway, it's rather annoying to me personally... and I hope I'm not the >>> only one who feels that way... to know that this has gone mostly unnoticed >>> for so long, that nobody within the RIPE region has ever bothered to -do- >>> anything about it, and that the AS and the bogus route are still being >>> announced, even as we speak. >> >> I had a look in my feeds, then a few global BGP LG's and well, it's not in the BGP table. >> >> In reality, it's the upstream, that feeds it in, that really needs to be penalised. >> >> Kind regards, >> Martin List-Petersen >> -- >> Airwire Ltd. - Ag Nascadh Pobail an Iarthair >> http://www.airwire.ie >> Phone: 091-865 968 >> Registered Office: Moy, Kinvara, Co. Galway, 091-865 968 - Registered in Ireland No. 508961 > -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 Registered Office: Moy, Kinvara, Co. Galway, 091-865 968 - Registered in Ireland No. 508961

2 1

AS47860 - 93.175.240.0/20 - Wiskey Tango Foxtrot
by Ronald F. Guilmette 07 Oct '16

07 Oct '16

My analysis: Serious and apparently long-lived bogosity, with a clear history of substantial spamming aactivity. But you be the judge. Looks to me like an unregistered RIPE AS announcing a route to a /20 worth of unregistered RIPE IPv4 space. And this didn't exactly crop up just yesterday. Looks like this has been ongoing for one hell of a long time: https://stat.ripe.net/widget/routing-history#w.resource=AS47860 Of course, it's not even nearly as much of an issue -now- as it was, say, about 1 year ago, in October of 2015, when the /20 was apparently populated by a huge boat load of snowshoe spammer domains. Sadly, Spamhaus has a bad habit of consistantly failing to ever put any helpful date information on any of its listings, otherwise I'd be able to see when -they- first noticed this absurd mess. https://www.spamhaus.org/pbl/query/PBL1626432 Anyway, it's rather annoying to me personally... and I hope I'm not the only one who feels that way... to know that this has gone mostly unnoticed for so long, that nobody within the RIPE region has ever bothered to -do- anything about it, and that the AS and the bogus route are still being announced, even as we speak. Assuming the thing remains in play, how long will be be before the spammers return to use and abuse it yet again? Maybe they were just waiting for a full year to go by so that they might have some hopes of this /20 being automatically aged off some blacklists. Regards, rfg P.S. This crap appears to be be brought to us courtesy of AS29632, NetAssist, LLC: http://new.netassist.ua/ So anyway, where are the grownups?

4 5

EDNS compliance and BIND 9.11.0
by Mark Andrews 07 Oct '16

07 Oct '16

BIND 9.11.0 was released this week. BIND 9.11.0 and BIND 9.10.4 implement EDNS COOKIES. They are on by default in BIND 9.11.0 and BIND 9.10.4 Windows. For the non Windows builds of BIND 9.10.4 they need to be enabled at configure time. If your nameservers are not EDNS compliant, especially for unknown EDNS options, you could be seeing issues ranging from additional traffic, slow DNS lookups to full blown lookup failures. If you having fixed your servers already you need to fix them now. You can test your servers at https://ednscomp.isc.org/ednscomp/ to see if they are EDNS compliant. You can see EDNS compliance trends and list of failing servers at https://ednscomp.isc.org. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

1 0

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension
by Larry Sheldon 07 Oct '16

07 Oct '16

On 10/6/2016 15:26, Jesse McGraw wrote: > (This is me scratching an itch of my own and hoping that sharing it > might be useful to others on this list. Apologies if it isn't) > > When I'm trying to comprehend a new or complicated Cisco router, > switch or firewall configuration an old pet-peeve of mine is how > needlessly difficult it is to follow deeply nested logic in route-maps, > ACLs, QoS policy-maps etc etc A dim, weak voice from the past. Has advantages of the plan proposed here. > > To make this a bit simpler I’ve been working on a perl script to convert > these text-based configuration files into HTML with links between the > different elements (e.g. To an access-list from the interface where it’s > applied, from policy-maps to class-maps etc), hopefully making it easier > to to follow the chain of logic via clicking links and using the forward > and back buttons in your browser to go back and forth between command > and referenced list. We used to (using a HB lead in a draftsman' lead holder and a stack for Forms SN 457* (Blank Spread Sheet, 11 x 17) sorted all of the requests, demands and other requirements into logical packages. Then, using the blank back side of the spread sheet, we drew "flow diagrams depicting how we would code the requirements. If a section got a little complicated and tedious, we'd put a symbol on the diagram, a title that made sense and a page number. On a new sheet, we wrote that title and that page number and drew the flow diagram for that messy bit of business. Then we would "desk check" the flow diagrams and in the process, note on the requirements sheet (s) the diagram number (and entry point if there was more than one) where the requirement was satisfied. Then we would start with a new sheet working from the flow diagrams, write the code for the machine (noting on the flow diagram the page and line number in the code where the operation on the flow diagram occurred. There are several advantages to this approach--hard to leave important stuff out, hard to include code that is never exercised, hard to make changes to the code because you don't know how to make HTML depict it correctly. No need to lecture me on the folly of the old ways--it is why I got fired for being too old. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account.

1 0

Questions re: VPN protocols globally
by Eric Germann 05 Oct '16

05 Oct '16

I’ve been charged with building a global VPN as an overlay on top of a certain 3 letter company who also sells lots of stuff. We’re looking at US East US West US Central (eventually) Brazil Singapore Frankfurt Ireland Sydney Maybe Canada Maybe India (outsourcesrs) In the planning stages now and wondering if there are any protocols I need to stay away from ITAR wise with this list of countries. Contemplating Suite B with GCM, etc and AES acceleration. Any land mines? Thanks in advance EKG

5 6

Re: Legislative proposal sent to my Congressman
by Anne Mitchell 05 Oct '16

05 Oct '16

(Interesting and inarguably well-intentioned, and possibly even sound, idea snipped, but noted.) There are a handful of reasons that this will never happen (well, I'm 98% certain it will never happen, nothing is every 100% sure when it comes to the law, and legislation)... among them the manufacturer's lobby is much more well-girded than is the 'home internet security' lobby; the cyber-security concerns of the Federal government are focussed on other things (whether they should be or not, they are); and for the most part legislators are still fairly unsavvy about tech in general, and these things make their eyes glaze over. That said, there are already tort (negligence, etc.) laws and precedents under which such manufacturers can be sued, along with things like breach of contract between the manufacturer and consumer, and breach of implied warranty of fitness for a particular purpose and breach of implied warranty of merchantability. A couple of winning lawsuits against manufacturers under these laws and theories - which judges *already understand* - is, I think, not only a more likely, but a much faster, route to industry reform. All that said, much of this faces the same issues that spam lawsuits faced - the people who care the most about it are not the ones who can afford to finance such lawsuits. Anne Anne P. Mitchell, Attorney at Law Legislative Consultant CEO/President, Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Asilomar Microcomputer Workshop Committee Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop

3 2

Re: Legislative proposal sent to my Congressman
by Larry Sheldon 05 Oct '16

05 Oct '16

On 10/3/2016 13:58, Stephen Satchell wrote: > In thinking over the last DDos involving IoT devices, I think we don't > have a good technical solution to the problem. Cutting off people with > defective devices they they don't understand, and have little control > over, is an action that makes sense, but hurts the innocent. "Hey, > Grandma, did you know your TV set is hurting the Internet?" > > It's the people who foist bad stuff on the people who need to take the > responsibility. Indeed, with enough moxie, we could avoid the net > saturation problem in the first place. > > My proposal, as I sent it to my US House Representative: > [much snipping] > Why not nip the IoT problem in the bud? Why not, indeed? (Full disclosure: I am not and have not for some years been active in management of any networks, and I AM woefully behind the state of the arts.) Having said that, it occurs to me that Mr. Satchell's proposal (and most of the others I have read about here and elsewhere lately) are doomed to the same failure as Chicago's plan for reducing illegal deaths by firearm, and for much the same reason (discussion of which here I will spare you. Back in the day, I was fighting a problem that I summarized (then and now) as trying to stop the use and abuse of the University's (that employed me) 56kb Frame Relay link to the Internet. Then as now I defined "abuse" as the use of our facilities for purposes that no stretch of imagination or definition could be said to be to the University's benefit. Through some experimentation I concluded that there were several clearly identifiable sources of abuse. I disremember the ordering by severity but they included: Outright attacks on the University and others. Myriad "scans" for a variety of reasons. The first of these two I remember as being the worst (in terms of item-count AND in terms of packet-size. I also recall it being the easiest to fix, if anybody want to fix it. (The dominant reasons given where that it would cost money without a revenue stream, and it would reduce traffic that WAS in the revenue stream. The fix I proposed: Require (by law) that every service provider and every origination customer of a service provider would under penalty of law, block the transmission of a packet whose source address could not be reached via the link upon which it was found. The Myriad scans problem was a little harder (for among other reasons--the argument that they were good for us, even though they accounted for something like 60% of the traffic on that link). The solution I tried but ran out of dollars on was to detect somebody scanning and route them to the Loopback interface of the boundary router. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account.

2 1