From morrowc.lists at gmail.com Fri Feb 1 00:31:49 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Jan 2019 16:31:49 -0800 Subject: Google you have a problem. In-Reply-To: <70277A54-8FC6-4CF5-896D-C281ABB59260@isc.org> References: <70277A54-8FC6-4CF5-896D-C281ABB59260@isc.org> Message-ID: just in case.. .this appears to be working now. -chris On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote: > [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi > looking up www.google.com > connecting to www.google.com:443 > SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 > Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN= > www.google.com > Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet > Authority G3 > requesting https://www.google.com/jsapi > fetch: https://www.google.com/jsapi: Bad Gateway > [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi > * Trying 2607:f8b0:4007:80e::2004... > * TCP_NODELAY set > * Trying 172.217.14.100... > * TCP_NODELAY set > * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) > * ALPN, offering http/1.1 > * Cipher selection: > ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > * successfully set certificate verify locations: > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > CApath: none > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN= > www.google.com > * start date: Jan 15 13:15:00 2019 GMT > * expire date: Apr 9 13:15:00 2019 GMT > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > * SSL certificate verify ok. > > GET /jsapi HTTP/1.1 > > Host: www.google.com > > User-Agent: curl/7.63.0 > > Accept: */* > > > < HTTP/1.1 502 Bad Gateway > < Content-Length: 0 > < Date: Thu, 31 Jan 2019 22:20:34 GMT > < Content-Type: text/html; charset=UTF-8 > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > < > * Connection #0 to host www.google.com left intact > [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi > * Trying 172.217.14.100... > * TCP_NODELAY set > * Connected to www.google.com (172.217.14.100) port 443 (#0) > * ALPN, offering http/1.1 > * Cipher selection: > ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > * successfully set certificate verify locations: > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > CApath: none > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN= > www.google.com > * start date: Jan 15 13:15:00 2019 GMT > * expire date: Apr 9 13:15:00 2019 GMT > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > * SSL certificate verify ok. > > GET /jsapi HTTP/1.1 > > Host: www.google.com > > User-Agent: curl/7.63.0 > > Accept: */* > > > < HTTP/1.1 502 Bad Gateway > < Content-Length: 0 > < Date: Thu, 31 Jan 2019 22:24:43 GMT > < Content-Type: text/html; charset=UTF-8 > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > < > * Connection #0 to host www.google.com left intact > [beetle:~/git/bind9] marka% traceroute 172.217.14.100 > traceroute to 172.217.14.100 (172.217.14.100), 64 hops max, 52 byte packets > 1 172.30.42.65 (172.30.42.65) 1.340 ms 3.278 ms 1.673 ms > 2 * * * > 3 * * * > 4 59.154.18.232 (59.154.18.232) 13.710 ms > hu0-5-0-0.22btpr01.optus.net.au (59.154.18.234) 24.311 ms 13.662 ms > 5 72.14.219.128 (72.14.219.128) 12.445 ms 43.781 ms 10.760 ms > 6 108.170.247.74 (108.170.247.74) 12.743 ms 12.797 ms > 108.170.247.59 (108.170.247.59) 14.167 ms > 7 216.239.50.172 (216.239.50.172) 159.864 ms 162.324 ms 157.546 ms > 8 108.170.230.130 (108.170.230.130) 147.234 ms 151.094 ms 152.088 ms > 9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms > 10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms > 74.125.252.75 (74.125.252.75) 149.363 ms > 11 lax31s01-in-f4.1e100.net (172.217.14.100) 158.438 ms 147.982 ms > 149.593 ms > [beetle:~/git/bind9] marka% > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Fri Feb 1 00:34:45 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 1 Feb 2019 11:34:45 +1100 Subject: Google you have a problem. In-Reply-To: References: <70277A54-8FC6-4CF5-896D-C281ABB59260@isc.org> Message-ID: George Michaelson forwarded me Google’s notice which said there would be a temporary outage along with a new home. Time to update the code to use the new home. > On 1 Feb 2019, at 11:31 am, Christopher Morrow wrote: > > just in case.. .this appears to be working now. > -chris > > On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote: > [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi > looking up www.google.com > connecting to www.google.com:443 > SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 > Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com > Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet Authority G3 > requesting https://www.google.com/jsapi > fetch: https://www.google.com/jsapi: Bad Gateway > [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi > * Trying 2607:f8b0:4007:80e::2004... > * TCP_NODELAY set > * Trying 172.217.14.100... > * TCP_NODELAY set > * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) > * ALPN, offering http/1.1 > * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > * successfully set certificate verify locations: > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > CApath: none > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com > * start date: Jan 15 13:15:00 2019 GMT > * expire date: Apr 9 13:15:00 2019 GMT > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > * SSL certificate verify ok. > > GET /jsapi HTTP/1.1 > > Host: www.google.com > > User-Agent: curl/7.63.0 > > Accept: */* > > > < HTTP/1.1 502 Bad Gateway > < Content-Length: 0 > < Date: Thu, 31 Jan 2019 22:20:34 GMT > < Content-Type: text/html; charset=UTF-8 > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > < > * Connection #0 to host www.google.com left intact > [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi > * Trying 172.217.14.100... > * TCP_NODELAY set > * Connected to www.google.com (172.217.14.100) port 443 (#0) > * ALPN, offering http/1.1 > * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > * successfully set certificate verify locations: > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > CApath: none > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com > * start date: Jan 15 13:15:00 2019 GMT > * expire date: Apr 9 13:15:00 2019 GMT > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > * SSL certificate verify ok. > > GET /jsapi HTTP/1.1 > > Host: www.google.com > > User-Agent: curl/7.63.0 > > Accept: */* > > > < HTTP/1.1 502 Bad Gateway > < Content-Length: 0 > < Date: Thu, 31 Jan 2019 22:24:43 GMT > < Content-Type: text/html; charset=UTF-8 > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > < > * Connection #0 to host www.google.com left intact > [beetle:~/git/bind9] marka% traceroute 172.217.14.100 > traceroute to 172.217.14.100 (172.217.14.100), 64 hops max, 52 byte packets > 1 172.30.42.65 (172.30.42.65) 1.340 ms 3.278 ms 1.673 ms > 2 * * * > 3 * * * > 4 59.154.18.232 (59.154.18.232) 13.710 ms > hu0-5-0-0.22btpr01.optus.net.au (59.154.18.234) 24.311 ms 13.662 ms > 5 72.14.219.128 (72.14.219.128) 12.445 ms 43.781 ms 10.760 ms > 6 108.170.247.74 (108.170.247.74) 12.743 ms 12.797 ms > 108.170.247.59 (108.170.247.59) 14.167 ms > 7 216.239.50.172 (216.239.50.172) 159.864 ms 162.324 ms 157.546 ms > 8 108.170.230.130 (108.170.230.130) 147.234 ms 151.094 ms 152.088 ms > 9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms > 10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms > 74.125.252.75 (74.125.252.75) 149.363 ms > 11 lax31s01-in-f4.1e100.net (172.217.14.100) 158.438 ms 147.982 ms 149.593 ms > [beetle:~/git/bind9] marka% > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bryan at shout.net Fri Feb 1 01:00:06 2019 From: bryan at shout.net (Bryan Holloway) Date: Thu, 31 Jan 2019 19:00:06 -0600 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> Message-ID: <9eb5604e-9d43-feb7-85b6-c531727bac7e@shout.net> What do IXes do (or can do) to enforce the completion of a renumbering? For example, Chicago Equinix announced a renumbering beginning of 2018, and while 99% of our peers have renumbered, we still have an albeit small handful who have not. (I will not name names.) That situation didn't get nearly the "media attention" that DE-CIX New York did, if any. The "end of migration period" was May 1st 2018; here we are. What's the next step, if any? On 1/30/19 4:05 PM, Thomas King wrote: > Hi all, > > Thanks for your support! This helps us getting all peers on the new IPv4 > space. > > Our looking glass shows which peers already have changed the IP settings > (see section “BGP session established”) and which peers are still > working on it (see section “BGP sessions down”): > > https://lg.de-cix.net/routeservers/rs1_nyc_ipv4#sessions-up > From alejandroacostaalamo at gmail.com Fri Feb 1 01:45:46 2019 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Thu, 31 Jan 2019 21:45:46 -0400 Subject: RTBH no_export In-Reply-To: <39954B9C-6DA6-427F-8CBB-7CD6408FD6D3@ciscodude.net> References: <39954B9C-6DA6-427F-8CBB-7CD6408FD6D3@ciscodude.net> Message-ID: <8161cb44-87a8-549e-6cbc-a1a838d11aa1@gmail.com> One more thing, RFC7999 has category Informational El 31/1/19 a las 16:21, Theodore Baschak escribió: > >> On Jan 31, 2019, at 1:28 PM, Roel Parijs > > wrote: >> >> For our BGP customers the problem is more complex. Our BGP customers >> can send us the RTBH community, and we will drop the traffic at our >> borders. Since we're only running a small network, we don't have the >> capacity to deal with large attacks. If we would be able to forward >> (and maybe alter it) this RTBH community towards our upstream >> providers, the impact on our network would be limited. However, the >> RFC states that an announcement tagged with the blackhole community >> should get the no_advertise or no_export community. >> >> What is your opinion on this ? >> > > In RFC7999 section 3.2 the first paragraph talks about what you're > mentioning, NO_EXPORT and/or NO_ADVERTISE. It uses the word SHOULD. > SHOULD has special meaning in RFCs, its not MUST. Its also not MAY. > RFC2119 talks about the way these words should be interpreted.  > > In the next paragraph it says that extreme caution should be used when > "purposefully propagating IP prefixes tagged with the BLACKHOLE > community outside the local routing domain, unless policy explicitly > aims at doing just that." > > So if your local routing policy is to propagate those blackholes on to > your upstreams (and its mutually agreed and they're configured to > accept them), then it can be done. Nothing technical in the RFC > stopping that.  > > Theo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Fri Feb 1 02:31:20 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 1 Feb 2019 03:31:20 +0100 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <9eb5604e-9d43-feb7-85b6-c531727bac7e@shout.net> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <9eb5604e-9d43-feb7-85b6-c531727bac7e@shout.net> Message-ID: <20190201023119.GB45327@jima.tpb.net> * bryan at shout.net (Bryan Holloway) [Fri 01 Feb 2019, 02:00 CET]: >What do IXes do (or can do) to enforce the completion of a renumbering? Renumbering is not complicated, but it's a lot of work to do it well. - Set a realistic time schedule well in advance. Keep in mind that some have change control limitations that differ from what you may be used to in the ISP industry. Talk about it in your regular membership meeting prior to the renumbering at the very least, and send mails to your general membership mailing lists. - Make sure your contacts for all connected ISPs are up to date. Generate unique emails per connected party and require them to acknowledge. If they don't, start making phone calls. - Allow for an overlap of old and new IP space to avoid outages. Don't set a flag day since not everybody will be able to make that due to timezones and aforementioned change control, but pick a week. Give instructions on how to have duplicated BGP sessions to avoid outages while allowing all connected parties to migrate at their speed. - Consider temporarily duplicating your route server infrastructure. - Keep a very close eye on your arpwatch and other monitoring in case people make typos - and people will make typos. - Be ready to move ports to a quarantine VLAN when they haven't renumbered in time, despite those previously mentioned personal communications, so you can reuse the IP address space elsewhere. HTH, -- Niels. From michel.py at tsisemi.com Fri Feb 1 03:13:08 2019 From: michel.py at tsisemi.com (Michel Py) Date: Fri, 1 Feb 2019 03:13:08 +0000 Subject: RTBH no_export In-Reply-To: <8161cb44-87a8-549e-6cbc-a1a838d11aa1@gmail.com> References: <39954B9C-6DA6-427F-8CBB-7CD6408FD6D3@ciscodude.net> <8161cb44-87a8-549e-6cbc-a1a838d11aa1@gmail.com> Message-ID: > Alejandro Acosta wrote : > One more thing, RFC7999 has category Informational Point well taken. A good thing, IMHO. If I remember correctly, I once opposed this text; not because it was a bad idea (standardizing is sometimes a good idea) but because I found it imprecise enough that it was not achieveing any goal and blurred the definition of what is a RTBH. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From morrowc.lists at gmail.com Fri Feb 1 04:15:35 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Jan 2019 20:15:35 -0800 Subject: Google you have a problem. In-Reply-To: References: <70277A54-8FC6-4CF5-896D-C281ABB59260@isc.org> Message-ID: On Thu, Jan 31, 2019 at 4:34 PM Mark Andrews wrote: > George Michaelson forwarded me Google’s notice which said there would be a > temporary outage along with a new home. Time to update the code to use the > new home. > > oh hey neato! :) Also, hey! this change didn't happen on a friday! w00t! > > On 1 Feb 2019, at 11:31 am, Christopher Morrow > wrote: > > > > just in case.. .this appears to be working now. > > -chris > > > > On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote: > > [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi > > looking up www.google.com > > connecting to www.google.com:443 > > SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 > > Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN= > www.google.com > > Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet > Authority G3 > > requesting https://www.google.com/jsapi > > fetch: https://www.google.com/jsapi: Bad Gateway > > [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi > > * Trying 2607:f8b0:4007:80e::2004... > > * TCP_NODELAY set > > * Trying 172.217.14.100... > > * TCP_NODELAY set > > * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) > > * ALPN, offering http/1.1 > > * Cipher selection: > ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > > * successfully set certificate verify locations: > > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > > CApath: none > > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > > * TLSv1.2 (IN), TLS handshake, Server hello (2): > > * TLSv1.2 (IN), TLS handshake, Certificate (11): > > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > > * TLSv1.2 (IN), TLS handshake, Server finished (14): > > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (OUT), TLS handshake, Finished (20): > > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (IN), TLS handshake, Finished (20): > > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > > * ALPN, server accepted to use http/1.1 > > * Server certificate: > > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN= > www.google.com > > * start date: Jan 15 13:15:00 2019 GMT > > * expire date: Apr 9 13:15:00 2019 GMT > > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > > * SSL certificate verify ok. > > > GET /jsapi HTTP/1.1 > > > Host: www.google.com > > > User-Agent: curl/7.63.0 > > > Accept: */* > > > > > < HTTP/1.1 502 Bad Gateway > > < Content-Length: 0 > > < Date: Thu, 31 Jan 2019 22:20:34 GMT > > < Content-Type: text/html; charset=UTF-8 > > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > > < > > * Connection #0 to host www.google.com left intact > > [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi > > * Trying 172.217.14.100... > > * TCP_NODELAY set > > * Connected to www.google.com (172.217.14.100) port 443 (#0) > > * ALPN, offering http/1.1 > > * Cipher selection: > ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > > * successfully set certificate verify locations: > > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > > CApath: none > > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > > * TLSv1.2 (IN), TLS handshake, Server hello (2): > > * TLSv1.2 (IN), TLS handshake, Certificate (11): > > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > > * TLSv1.2 (IN), TLS handshake, Server finished (14): > > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (OUT), TLS handshake, Finished (20): > > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (IN), TLS handshake, Finished (20): > > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > > * ALPN, server accepted to use http/1.1 > > * Server certificate: > > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN= > www.google.com > > * start date: Jan 15 13:15:00 2019 GMT > > * expire date: Apr 9 13:15:00 2019 GMT > > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > > * SSL certificate verify ok. > > > GET /jsapi HTTP/1.1 > > > Host: www.google.com > > > User-Agent: curl/7.63.0 > > > Accept: */* > > > > > < HTTP/1.1 502 Bad Gateway > > < Content-Length: 0 > > < Date: Thu, 31 Jan 2019 22:24:43 GMT > > < Content-Type: text/html; charset=UTF-8 > > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > > < > > * Connection #0 to host www.google.com left intact > > [beetle:~/git/bind9] marka% traceroute 172.217.14.100 > > traceroute to 172.217.14.100 (172.217.14.100), 64 hops max, 52 byte > packets > > 1 172.30.42.65 (172.30.42.65) 1.340 ms 3.278 ms 1.673 ms > > 2 * * * > > 3 * * * > > 4 59.154.18.232 (59.154.18.232) 13.710 ms > > hu0-5-0-0.22btpr01.optus.net.au (59.154.18.234) 24.311 ms 13.662 > ms > > 5 72.14.219.128 (72.14.219.128) 12.445 ms 43.781 ms 10.760 ms > > 6 108.170.247.74 (108.170.247.74) 12.743 ms 12.797 ms > > 108.170.247.59 (108.170.247.59) 14.167 ms > > 7 216.239.50.172 (216.239.50.172) 159.864 ms 162.324 ms 157.546 ms > > 8 108.170.230.130 (108.170.230.130) 147.234 ms 151.094 ms 152.088 ms > > 9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms > > 10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms > > 74.125.252.75 (74.125.252.75) 149.363 ms > > 11 lax31s01-in-f4.1e100.net (172.217.14.100) 158.438 ms 147.982 ms > 149.593 ms > > [beetle:~/git/bind9] marka% > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Fri Feb 1 04:22:48 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 1 Feb 2019 15:22:48 +1100 Subject: Google you have a problem. In-Reply-To: References: <70277A54-8FC6-4CF5-896D-C281ABB59260@isc.org> Message-ID: <2FDC414B-BF56-4D73-B0BE-CD8673DD6146@isc.org> It was 9:29 AM Feb 1 AEST when I reported this so yes it was FRIDAY. > On 1 Feb 2019, at 3:15 pm, Christopher Morrow wrote: > > > > On Thu, Jan 31, 2019 at 4:34 PM Mark Andrews wrote: > George Michaelson forwarded me Google’s notice which said there would be a > temporary outage along with a new home. Time to update the code to use the > new home. > > > oh hey neato! :) > Also, hey! this change didn't happen on a friday! w00t! > > > On 1 Feb 2019, at 11:31 am, Christopher Morrow wrote: > > > > just in case.. .this appears to be working now. > > -chris > > > > On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote: > > [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi > > looking up www.google.com > > connecting to www.google.com:443 > > SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 > > Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com > > Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet Authority G3 > > requesting https://www.google.com/jsapi > > fetch: https://www.google.com/jsapi: Bad Gateway > > [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi > > * Trying 2607:f8b0:4007:80e::2004... > > * TCP_NODELAY set > > * Trying 172.217.14.100... > > * TCP_NODELAY set > > * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) > > * ALPN, offering http/1.1 > > * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > > * successfully set certificate verify locations: > > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > > CApath: none > > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > > * TLSv1.2 (IN), TLS handshake, Server hello (2): > > * TLSv1.2 (IN), TLS handshake, Certificate (11): > > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > > * TLSv1.2 (IN), TLS handshake, Server finished (14): > > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (OUT), TLS handshake, Finished (20): > > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (IN), TLS handshake, Finished (20): > > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > > * ALPN, server accepted to use http/1.1 > > * Server certificate: > > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com > > * start date: Jan 15 13:15:00 2019 GMT > > * expire date: Apr 9 13:15:00 2019 GMT > > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > > * SSL certificate verify ok. > > > GET /jsapi HTTP/1.1 > > > Host: www.google.com > > > User-Agent: curl/7.63.0 > > > Accept: */* > > > > > < HTTP/1.1 502 Bad Gateway > > < Content-Length: 0 > > < Date: Thu, 31 Jan 2019 22:20:34 GMT > > < Content-Type: text/html; charset=UTF-8 > > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > > < > > * Connection #0 to host www.google.com left intact > > [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi > > * Trying 172.217.14.100... > > * TCP_NODELAY set > > * Connected to www.google.com (172.217.14.100) port 443 (#0) > > * ALPN, offering http/1.1 > > * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > > * successfully set certificate verify locations: > > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > > CApath: none > > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > > * TLSv1.2 (IN), TLS handshake, Server hello (2): > > * TLSv1.2 (IN), TLS handshake, Certificate (11): > > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > > * TLSv1.2 (IN), TLS handshake, Server finished (14): > > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (OUT), TLS handshake, Finished (20): > > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (IN), TLS handshake, Finished (20): > > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > > * ALPN, server accepted to use http/1.1 > > * Server certificate: > > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com > > * start date: Jan 15 13:15:00 2019 GMT > > * expire date: Apr 9 13:15:00 2019 GMT > > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > > * SSL certificate verify ok. > > > GET /jsapi HTTP/1.1 > > > Host: www.google.com > > > User-Agent: curl/7.63.0 > > > Accept: */* > > > > > < HTTP/1.1 502 Bad Gateway > > < Content-Length: 0 > > < Date: Thu, 31 Jan 2019 22:24:43 GMT > > < Content-Type: text/html; charset=UTF-8 > > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > > < > > * Connection #0 to host www.google.com left intact > > [beetle:~/git/bind9] marka% traceroute 172.217.14.100 > > traceroute to 172.217.14.100 (172.217.14.100), 64 hops max, 52 byte packets > > 1 172.30.42.65 (172.30.42.65) 1.340 ms 3.278 ms 1.673 ms > > 2 * * * > > 3 * * * > > 4 59.154.18.232 (59.154.18.232) 13.710 ms > > hu0-5-0-0.22btpr01.optus.net.au (59.154.18.234) 24.311 ms 13.662 ms > > 5 72.14.219.128 (72.14.219.128) 12.445 ms 43.781 ms 10.760 ms > > 6 108.170.247.74 (108.170.247.74) 12.743 ms 12.797 ms > > 108.170.247.59 (108.170.247.59) 14.167 ms > > 7 216.239.50.172 (216.239.50.172) 159.864 ms 162.324 ms 157.546 ms > > 8 108.170.230.130 (108.170.230.130) 147.234 ms 151.094 ms 152.088 ms > > 9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms > > 10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms > > 74.125.252.75 (74.125.252.75) 149.363 ms > > 11 lax31s01-in-f4.1e100.net (172.217.14.100) 158.438 ms 147.982 ms 149.593 ms > > [beetle:~/git/bind9] marka% > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Fri Feb 1 04:25:36 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Jan 2019 20:25:36 -0800 Subject: Google you have a problem. In-Reply-To: <2FDC414B-BF56-4D73-B0BE-CD8673DD6146@isc.org> References: <70277A54-8FC6-4CF5-896D-C281ABB59260@isc.org> <2FDC414B-BF56-4D73-B0BE-CD8673DD6146@isc.org> Message-ID: On Thu, Jan 31, 2019 at 8:23 PM Mark Andrews wrote: > It was 9:29 AM Feb 1 AEST when I reported this so yes it was FRIDAY. > > :) it's very easy to rile you up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at studio442.com.au Fri Feb 1 09:05:00 2019 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 1 Feb 2019 20:05:00 +1100 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <20190201023119.GB45327@jima.tpb.net> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <9eb5604e-9d43-feb7-85b6-c531727bac7e@shout.net> <20190201023119.GB45327@jima.tpb.net> Message-ID: <251f5864-32e1-a237-5e7d-d47ff0097f79@studio442.com.au> On 1/2/19 1:31 pm, Niels Bakker wrote: > * bryan at shout.net (Bryan Holloway) [Fri 01 Feb 2019, 02:00 CET]: >> What do IXes do (or can do) to enforce the completion of a renumbering? > - Be ready to move ports to a quarantine VLAN when they haven't > renumbered in time, despite those previously mentioned personal > communications, so you can reuse the IP address space elsewhere. Or just ACL ARP traffic for that subnet (assuming your equipment allows you to configure such a filter, most kit can probably program such an ACL, although perhaps not to configure it in the OS) From nick at foobar.org Fri Feb 1 11:01:09 2019 From: nick at foobar.org (Nick Hilliard) Date: Fri, 1 Feb 2019 11:01:09 +0000 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <9eb5604e-9d43-feb7-85b6-c531727bac7e@shout.net> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <9eb5604e-9d43-feb7-85b6-c531727bac7e@shout.net> Message-ID: Bryan Holloway wrote on 01/02/2019 01:00: > What's the next step, if any? use edge ACLs on the IXP infrastructure to block BGP on the old IP address range. You can then use ARP ping to work out who's still got the old IP addresses configured. Nick From alex at nlnetlabs.nl Fri Feb 1 13:13:44 2019 From: alex at nlnetlabs.nl (Alex Band) Date: Fri, 1 Feb 2019 14:13:44 +0100 Subject: RPKI Documentation as an open source project Message-ID: Hey all, A couple on months ago we started putting together an FAQ on RPKI [0] which led to quite a number of community contributions. We decided to expand upon this project and write comprehensive RPKI documentation, as an open source project. Other than reading every RFC on the topic, this should give operators a good understanding of the moving parts involved, and how to use RPKI in the real world. We got to the point where we think we have all the basics covered and made it available here: https://rpki.readthedocs.io As this is a project on GitHub [1] and managed using the Sphinx documentation tooling, we welcome corrections, additions, readability improvements and even translations. Feel free to create an issue or pull request on GitHub. Hope this is useful! See y’all in S.F. Cheers, Martin, Tim & Alex The NLnet Labs RPKI Team [0] https://github.com/NLnetLabs/rpki-faq [1] https://github.com/NLnetLabs/rpki-doc From ncariaga at gmail.com Fri Feb 1 13:55:46 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Fri, 1 Feb 2019 21:55:46 +0800 Subject: RapidScale Network Contact Message-ID: Good day to all. I would like to reach out to any Rapid Scale network contact on this list. Have some few clarifications on the latency spike within the RapidScale network when doing traceroutes going to some IPs. Thanks in advance. -nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Feb 1 14:01:57 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 1 Feb 2019 09:01:57 -0500 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> Message-ID: “Sold you fiber , not working fiber” is at the same time amazing lawerying and insanely facepalmy. :) On Thu, Jan 31, 2019 at 11:48 Fletcher Kittredge wrote: > > Cold changes the transmission characteristics of fiber. At one point we > were renting some old dark fiber from the local telephone company in > northern Maine. When it would get below -15%-degree F the dB would get bad > enough that the link using that fiber would stop working. The telephone > company was selling us dark fiber because regulation required them to. They > refused to give us another fiber nor inspect/repair. They took the position > they were required to sell us fiber, not working fiber. > > > On Wed, Jan 30, 2019 at 11:41 AM Mark Tinka wrote: > >> For anyone running IP networks in the Midwest, are you having to do >> anything special to keep your networks up? >> >> For the data centres, is this cold front a chance to reduce air >> conditioning costs, or is it actually straining the infrastructure? >> >> I'm curious, from a +27-degree C summer's day here in Johannesburg. >> >> Mark. >> > > > -- > Fletcher Kittredge > GWI > 207-602-1134 > www.gwi.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Feb 1 18:03:17 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Feb 2019 04:03:17 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190201180318.030EDC55A0@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Feb, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 735331 Prefixes after maximum aggregation (per Origin AS): 283580 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 354621 Total ASes present in the Internet Routing Table: 63092 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54357 Origin ASes announcing only one prefix: 23579 Transit ASes present in the Internet Routing Table: 8735 Transit-only ASes present in the Internet Routing Table: 268 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 21 Number of instances of unregistered ASNs: 23 Number of 32-bit ASNs allocated by the RIRs: 25627 Number of 32-bit ASNs visible in the Routing Table: 20862 Prefixes from 32-bit ASNs in the Routing Table: 90590 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 271 Number of addresses announced to Internet: 2842533251 Equivalent to 169 /8s, 109 /16s and 157 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 246362 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200035 Total APNIC prefixes after maximum aggregation: 57413 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 197150 Unique aggregates announced from the APNIC address blocks: 81608 APNIC Region origin ASes present in the Internet Routing Table: 9414 APNIC Prefixes per ASN: 20.94 APNIC Region origin ASes announcing only one prefix: 2663 APNIC Region transit ASes present in the Internet Routing Table: 1397 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4417 Number of APNIC addresses announced to Internet: 769642274 Equivalent to 45 /8s, 223 /16s and 207 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 217799 Total ARIN prefixes after maximum aggregation: 103376 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 217128 Unique aggregates announced from the ARIN address blocks: 104009 ARIN Region origin ASes present in the Internet Routing Table: 18341 ARIN Prefixes per ASN: 11.84 ARIN Region origin ASes announcing only one prefix: 6829 ARIN Region transit ASes present in the Internet Routing Table: 1851 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: 2562 Number of ARIN addresses announced to Internet: 1079669920 Equivalent to 64 /8s, 90 /16s and 116 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 202096 Total RIPE prefixes after maximum aggregation: 96285 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 198251 Unique aggregates announced from the RIPE address blocks: 117420 RIPE Region origin ASes present in the Internet Routing Table: 25787 RIPE Prefixes per ASN: 7.69 RIPE Region origin ASes announcing only one prefix: 11488 RIPE Region transit ASes present in the Internet Routing Table: 3631 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7793 Number of RIPE addresses announced to Internet: 716711872 Equivalent to 42 /8s, 184 /16s and 39 /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-210331 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: 95098 Total LACNIC prefixes after maximum aggregation: 22279 LACNIC Deaggregation factor: 4.27 Prefixes being announced from the LACNIC address blocks: 96501 Unique aggregates announced from the LACNIC address blocks: 42173 LACNIC Region origin ASes present in the Internet Routing Table: 8027 LACNIC Prefixes per ASN: 12.02 LACNIC Region origin ASes announcing only one prefix: 2174 LACNIC Region transit ASes present in the Internet Routing Table: 1505 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5577 Number of LACNIC addresses announced to Internet: 173075968 Equivalent to 10 /8s, 80 /16s and 238 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20281 Total AfriNIC prefixes after maximum aggregation: 4209 AfriNIC Deaggregation factor: 4.82 Prefixes being announced from the AfriNIC address blocks: 26030 Unique aggregates announced from the AfriNIC address blocks: 9167 AfriNIC Region origin ASes present in the Internet Routing Table: 1239 AfriNIC Prefixes per ASN: 21.01 AfriNIC Region origin ASes announcing only one prefix: 425 AfriNIC Region transit ASes present in the Internet Routing Table: 246 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 513 Number of AfriNIC addresses announced to Internet: 103031296 Equivalent to 6 /8s, 36 /16s and 34 /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 4653 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4579 531 527 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3056 1241 49 VIETEL-AS-AP Viettel Group, VN 45899 3006 1725 112 VNPT-AS-VN VNPT Corp, VN 4766 2811 11127 767 KIXS-AS-KR Korea Telecom, KR 9829 2752 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2437 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2395 4906 29 CTTNET China TieTong Telecommunications 4755 2142 438 183 TATACOMM-AS TATA Communications formerl 17974 2034 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3578 1326 92 SHAW - Shaw Communications Inc., CA 11492 3495 226 595 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2598 5391 1021 AMAZON-02 - Amazon.com, Inc., US 16625 2275 1250 1715 AKAMAI-AS - Akamai Technologies, Inc., 20115 2152 2759 536 CHARTER-20115 - Charter Communications, 18566 2136 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2089 3074 1462 FRONTIER-FRTR - Frontier Communications 30036 2078 345 292 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2068 5076 577 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5329 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3273 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2631 560 1915 AKAMAI-ASN1, US 12389 2205 2209 657 ROSTELECOM-AS, RU 34984 2066 339 527 TELLCOM-AS, TR 9121 1682 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 9009 1327 145 741 M247, GB 8402 1316 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5546 3325 589 Uninet S.A. de C.V., MX 10620 2959 448 993 Telmex Colombia S.A., CO 11830 2683 371 60 Instituto Costarricense de Electricidad 6503 1565 449 55 Axtel, S.A.B. de C.V., MX 7303 1409 934 221 Telecom Argentina S.A., AR 6147 1286 377 29 Telefonica del Peru S.A.A., PE 28573 1173 2240 183 CLARO S.A., BR 3816 1029 511 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 931 143 66 Alestra, S. de R.L. de C.V., MX 13999 911 528 243 Mega Cable, S.A. 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 1152 393 21 LINKdotNET-AS, EG 37611 907 107 9 Afrihost, ZA 36903 797 401 142 MT-MPLS, MA 36992 789 1411 44 ETISALAT-MISR, EG 24835 685 636 22 RAYA-AS, EG 8452 640 1731 20 TE-AS TE-AS, EG 29571 485 70 13 ORANGE-COTE-IVOIRE, CI 37492 468 470 57 ORANGE-, TN 15399 425 45 11 WANANCHI-, KE 37342 419 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5546 3325 589 Uninet S.A. de C.V., MX 12479 5329 1628 138 UNI2-AS, ES 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4579 531 527 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3578 1326 92 SHAW - Shaw Communications Inc., CA 11492 3495 226 595 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3273 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 7552 3056 1241 49 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5329 5191 UNI2-AS, ES 4538 4653 4579 ERX-CERNET-BKB China Education and Research Net 7545 4579 4052 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3578 3486 SHAW - Shaw Communications Inc., CA 8551 3273 3230 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3310 3136 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3056 3007 VIETEL-AS-AP Viettel Group, VN 11492 3495 2900 CABLEONE - CABLE ONE, INC., US 45899 3006 2894 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.96.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64141 UNALLOCATED 181.119.152.0/24 264619 Wireless Provider, AR Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.171.96.0/24 394378 NMICA-01 - NMICA, LLC, US 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 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:12 /9:10 /10:36 /11:99 /12:292 /13:568 /14:1129 /15:1918 /16:13373 /17:7882 /18:13853 /19:25609 /20:39703 /21:46133 /22:91481 /23:74783 /24:415615 /25:924 /26:820 /27:864 /28:20 /29:6 /30:7 /31:0 /32:194 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4179 5329 UNI2-AS, ES 6327 3340 3578 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2757 3495 CABLEONE - CABLE ONE, INC., US 8551 2729 3273 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2550 3310 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2031 2136 MEGAPATH5-US - MegaPath Corporation, US 11830 2029 2683 Instituto Costarricense de Electricidad y Telec 30036 1826 2078 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2089 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1612 2:896 4:23 5:2786 6:47 7:1 8:1176 12:1867 13:315 14:1867 15:37 16:2 17:219 18:57 20:50 23:2604 24:2481 25:2 27:2544 31:2043 32:94 35:35 36:831 37:3016 38:1616 39:294 40:122 41:3127 42:726 43:2003 44:141 45:6567 46:3223 47:248 49:1344 50:1080 51:319 52:1078 54:347 55:1 56:6 57:41 58:1705 59:1054 60:481 61:2056 62:2075 63:1794 64:5076 65:2195 66:4826 67:2693 68:1172 69:3485 70:1150 71:603 72:2288 74:2758 75:418 76:544 77:1730 78:1762 79:2314 80:1641 81:1423 82:1103 83:897 84:1084 85:2140 86:560 87:1554 88:990 89:2414 90:215 91:6569 92:1239 93:2434 94:2482 95:3232 96:919 97:349 98:944 99:169 100:87 101:1160 102:373 103:19926 104:3562 105:249 106:867 107:1812 108:693 109:3672 110:1611 111:1865 112:1389 113:1409 114:1148 115:1722 116:1671 117:1919 118:2190 119:1621 120:1046 121:1030 122:2366 123:1644 124:1454 125:1950 128:1206 129:675 130:523 131:1646 132:713 133:218 134:1046 135:238 136:550 137:681 138:1959 139:835 140:570 141:803 142:801 143:1008 144:891 145:505 146:1248 147:802 148:1713 149:794 150:782 151:1005 152:1005 153:324 154:2446 155:966 156:1650 157:892 158:657 159:1919 160:1512 161:910 162:2671 163:780 164:1135 165:1573 166:438 167:1384 168:3263 169:869 170:4013 171:526 172:1090 173:2157 174:999 175:883 176:2301 177:3997 178:2559 179:1292 180:2090 181:2440 182:2680 183:1049 184:1149 185:14683 186:3707 187:2452 188:2894 189:2008 190:8343 191:1454 192:10068 193:6538 194:5335 195:4044 196:2973 197:1736 198:5789 199:5973 200:7273 201:5104 202:10104 203:10152 204:4619 205:3005 206:3318 207:3274 208:3959 209:4228 210:3939 211:1986 212:3063 213:2837 214:1082 215:52 216:5978 217:2199 218:919 219:574 220:1845 221:995 222:994 223:1427 End of report From marka at isc.org Fri Feb 1 21:23:28 2019 From: marka at isc.org (Mark Andrews) Date: Sat, 2 Feb 2019 08:23:28 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <9E46C8B6-41A4-4DB7-830C-499AEFF0B734@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> <2e963381-9963-925c-7fb2-4961b22753df@seacom.mu> <9E46C8B6-41A4-4DB7-830C-499AEFF0B734@isc.org> Message-ID: Google has started their rollout. https://groups.google.com/forum/#!msg/public-dns-announce/-qaRKDV9InA/tExCFrppAgAJ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Fri Feb 1 22:57:41 2019 From: randy at psg.com (Randy Bush) Date: Fri, 01 Feb 2019 14:57:41 -0800 Subject: RTBH no_export In-Reply-To: <8161cb44-87a8-549e-6cbc-a1a838d11aa1@gmail.com> References: <39954B9C-6DA6-427F-8CBB-7CD6408FD6D3@ciscodude.net> <8161cb44-87a8-549e-6cbc-a1a838d11aa1@gmail.com> Message-ID: > One more thing, RFC7999 has category Informational and what exactly do you think that means. in ietf terms, it is a formal spec which does not specify a protocol. it is still a formal spec. randy From list at satchell.net Sat Feb 2 15:01:57 2019 From: list at satchell.net (Stephen Satchell) Date: Sat, 2 Feb 2019 07:01:57 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> <2e963381-9963-925c-7fb2-4961b22753df@seacom.mu> <9E46C8B6-41A4-4DB7-830C-499AEFF0B734@isc.org> Message-ID: On 2/1/19 1:23 PM, Mark Andrews wrote: > Google has started their rollout. So has Red Hat (RHEL and Centos). I woke up to a rather large update this morning. From marka at isc.org Sat Feb 2 20:01:22 2019 From: marka at isc.org (Mark Andrews) Date: Sun, 3 Feb 2019 07:01:22 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> <2e963381-9963-925c-7fb2-4961b22753df@seacom.mu> <9E46C8B6-41A4-4DB7-830C-499AEFF0B734@isc.org> Message-ID: > On 3 Feb 2019, at 2:01 am, Stephen Satchell wrote: > > On 2/1/19 1:23 PM, Mark Andrews wrote: >> Google has started their rollout. > > So has Red Hat (RHEL and Centos). I woke up to a rather large update > this morning. RedHat or third party RPM’s you have chosen to run on RedHat? RedHat is notorious for not updating packages they include in the base system and to the best of my knowledge they haven’t dug these changes out of BIND 9.13 (which is a development series) and back ported them. BIND 9.14 is yet to be released. Now PowerDNS have released their new recursive server and if you happen to have installed that on RedHat it may have been what you saw. https://blog.powerdns.com/2019/02/01/changes-in-the-powerdns-recursor-4-2-0/ Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tom at ninjabadger.net Sun Feb 3 18:15:54 2019 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 3 Feb 2019 18:15:54 +0000 Subject: RTBH no_export In-Reply-To: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> References: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> Message-ID: On 31/01/2019 20:17, Nick Hilliard wrote: > you should implement a different community for upstream blackholing. > This should be stripped at your upstream links and replaced with the > provider's RTBH community.  Your provider will then handle export > restrictions as they see fit. This works wonderfully, from past experience. :) -- Tom From contact at winterei.se Sun Feb 3 23:08:19 2019 From: contact at winterei.se (Paul S.) Date: Mon, 4 Feb 2019 08:08:19 +0900 Subject: RTBH no_export In-Reply-To: References: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> Message-ID: <178bdc61-15e3-7613-5f78-a83c72c2b694@winterei.se> +1, exactly what we did. I also recommend implementing per-upstream/region blackhole communities (so your users can choose who to blackhole as they see fit.) Often time, DDoS traffic comes from regions that do not intersect with legitimate traffic. On 2/4/2019 03:15 午前, Tom Hill wrote: > On 31/01/2019 20:17, Nick Hilliard wrote: >> you should implement a different community for upstream blackholing. >> This should be stripped at your upstream links and replaced with the >> provider's RTBH community.  Your provider will then handle export >> restrictions as they see fit. > > This works wonderfully, from past experience. :) > From Nikos.Leontsinis at eu.equinix.com Mon Feb 4 08:39:19 2019 From: Nikos.Leontsinis at eu.equinix.com (Nikos Leontsinis) Date: Mon, 4 Feb 2019 08:39:19 +0000 Subject: [EXTERNAL] Re: RTBH no_export In-Reply-To: <178bdc61-15e3-7613-5f78-a83c72c2b694@winterei.se> References: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> <178bdc61-15e3-7613-5f78-a83c72c2b694@winterei.se> Message-ID: This is a 20+ year old solution. Ugly because you will block good traffic and on your effort to protect your network you will block legitimate traffic too (satisfying the attacker) but most upstream providers will give you a community to use (Cogent is a notable exception) and tag the prefix under attack so that the attack will not reach your network. Sadly most IXs after 20 years they still don't understand the need for this community but at least someone has written an rfc so that all of us use the same community. At least we made some progress there... -----Original Message----- From: NANOG On Behalf Of Paul S. Sent: Sunday, February 3, 2019 11:08 PM To: nanog at nanog.org Subject: [EXTERNAL] Re: RTBH no_export +1, exactly what we did. I also recommend implementing per-upstream/region blackhole communities (so your users can choose who to blackhole as they see fit.) Often time, DDoS traffic comes from regions that do not intersect with legitimate traffic. On 2/4/2019 03:15 午前, Tom Hill wrote: > On 31/01/2019 20:17, Nick Hilliard wrote: >> you should implement a different community for upstream blackholing. >> This should be stripped at your upstream links and replaced with the >> provider's RTBH community. Your provider will then handle export >> restrictions as they see fit. > > This works wonderfully, from past experience. :) > This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889. From martijnschmidt at i3d.net Mon Feb 4 09:01:20 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Mon, 4 Feb 2019 09:01:20 +0000 Subject: [EXTERNAL] Re: RTBH no_export In-Reply-To: References: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> <178bdc61-15e3-7613-5f78-a83c72c2b694@winterei.se> Message-ID: Cogent does let you use RTBH, but on a separate BGP session to a blackhole server. So it's a bit more hassle to set it up policy-wise, because it deviates from the standard. Same story for "former GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM and Asia. Best regards, Martijn On 2/4/19 9:39 AM, Nikos Leontsinis wrote: > This is a 20+ year old solution. Ugly because you will block good traffic and on your effort to protect your network you will block legitimate traffic too (satisfying the attacker) but most upstream providers > will give you a community to use (Cogent is a notable exception) and tag the prefix under attack so that the attack will not reach your network. > Sadly most IXs after 20 years they still don't understand the need for this community but at least someone has written an rfc so that all of us use the same community. > At least we made some progress there... > > -----Original Message----- > From: NANOG On Behalf Of Paul S. > Sent: Sunday, February 3, 2019 11:08 PM > To: nanog at nanog.org > Subject: [EXTERNAL] Re: RTBH no_export > > +1, exactly what we did. I also recommend implementing > per-upstream/region blackhole communities (so your users can choose who to blackhole as they see fit.) > > Often time, DDoS traffic comes from regions that do not intersect with legitimate traffic. > > On 2/4/2019 03:15 午前, Tom Hill wrote: >> On 31/01/2019 20:17, Nick Hilliard wrote: >>> you should implement a different community for upstream blackholing. >>> This should be stripped at your upstream links and replaced with the >>> provider's RTBH community. Your provider will then handle export >>> restrictions as they see fit. >> This works wonderfully, from past experience. :) >> > This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889. From bernat at luffy.cx Mon Feb 4 09:48:26 2019 From: bernat at luffy.cx (Vincent Bernat) Date: Mon, 04 Feb 2019 10:48:26 +0100 Subject: [EXTERNAL] Re: RTBH no_export In-Reply-To: (i3D net's message of "Mon, 4 Feb 2019 09:01:20 +0000") References: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> <178bdc61-15e3-7613-5f78-a83c72c2b694@winterei.se> Message-ID: ❦ 4 février 2019 09:01 +00, i3D.net - Martijn Schmidt : > Cogent does let you use RTBH, but on a separate BGP session to a > blackhole server. So it's a bit more hassle to set it up policy-wise, > because it deviates from the standard. Same story for "former > GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM > and Asia. Cogent will "soon" support a blackhole community on regular BGP sessions. I've got this information a few months ago, so maybe just ask for it to make it happen sooner. -- Use uniform input formats. - The Elements of Programming Style (Kernighan & Plauger) From Nikos.Leontsinis at eu.equinix.com Mon Feb 4 13:11:51 2019 From: Nikos.Leontsinis at eu.equinix.com (Nikos Leontsinis) Date: Mon, 4 Feb 2019 13:11:51 +0000 Subject: [EXTERNAL] Re: RTBH no_export In-Reply-To: References: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> <178bdc61-15e3-7613-5f78-a83c72c2b694@winterei.se> Message-ID: I heard that before... -----Original Message----- From: Vincent Bernat Sent: Monday, February 4, 2019 9:48 AM To: i3D.net - Martijn Schmidt Cc: Nikos Leontsinis ; Paul S. ; nanog at nanog.org Subject: Re: [EXTERNAL] Re: RTBH no_export ❦ 4 février 2019 09:01 +00, i3D.net - Martijn Schmidt : > Cogent does let you use RTBH, but on a separate BGP session to a > blackhole server. So it's a bit more hassle to set it up policy-wise, > because it deviates from the standard. Same story for "former > GlobalCrossing", now CenturyLink's AS3549, which is still used for > LATAM and Asia. Cogent will "soon" support a blackhole community on regular BGP sessions. I've got this information a few months ago, so maybe just ask for it to make it happen sooner. -- Use uniform input formats. - The Elements of Programming Style (Kernighan & Plauger) This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889. From dovid at telecurve.com Mon Feb 4 13:18:20 2019 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 4 Feb 2019 08:18:20 -0500 Subject: Cellular backup connections In-Reply-To: References: Message-ID: Anyone know if Verizon static IP's over LTE have same issue where they bounce the traffic around before it gets back to the NY metro area? On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender wrote: > All, > > Thanks for all of the feedback. I was on site today and noticed two things. > 1) As someone mentioned it could be for static IP's they have the traffic > going to a specific location. The POP is in NJ there was a min. latency of > 120ms which prob had to do with this. > 2) I was watching the ping times and it looked something like this: > 400ms > 360ms > 330ms > 300ms > 260ms > 210ms > 170ms > 140ms > 120ms > 400ms > 375ms > > It seems to have been coming in "waves". I assume this has to do with "how > cellular work" and the signal. I tried moving it around by putting it down > low on the floor, moving it locations etc. and saw the same thing every > time. I am going to try Verizon next and see how it goes. > > > > On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan wrote: > >> On Fri, 28 Dec 2018, Dovid Bender wrote: >> >> >I finally got around to setting up a cellular backup device in our new >> POP. >> >> >When SSH'ing in remotely the connection seems rather slow. >> >> Perhaps using MOSH can help make the interactive CLI session less >> annoying. >> >> >Verizon they charge $500.00 just to get a public IP and I want to avoid >> >that if possible. >> >> You might look into have it call out / maintain a connection back to >> your infrastructure. >> >> >> /mark >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtk at depaul.edu Mon Feb 4 14:57:22 2019 From: jtk at depaul.edu (John Kristoff) Date: Mon, 4 Feb 2019 08:57:22 -0600 Subject: [EXTERNAL] Re: RTBH no_export In-Reply-To: <1ede666e34f14bcca3396e7d8e393cff@XCASPRD02.dpu.depaul.edu> References: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> <178bdc61-15e3-7613-5f78-a83c72c2b694@winterei.se> <1ede666e34f14bcca3396e7d8e393cff@XCASPRD02.dpu.depaul.edu> Message-ID: <20190204085722.2cef1083@p50.localdomain> On Mon, 4 Feb 2019 09:01:20 +0000 i3D.net - Martijn Schmidt wrote: > Cogent does let you use RTBH, but on a separate BGP session to a > blackhole server. So it's a bit more hassle to set it up policy-wise, > because it deviates from the standard. Same story for "former > GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM > and Asia. There are other providers that do this besides those you listed. I'm not sure one way or the other is truly "the standard" approach, but there may be an advantage and potentially good reason to have a separate session. If a no-multihop peering link/session is down, you might still be able to establish a RTBH peering session via another path. That may be what you need to get that direct neighbor back up. :-) John From jcurran at arin.net Mon Feb 4 18:44:21 2019 From: jcurran at arin.net (John Curran) Date: Mon, 4 Feb 2019 18:44:21 +0000 Subject: =?utf-8?B?QVJJTiBETlNTRUMgTW9uaXRvcmluZyBlbmhhbmNlbWVudCBkZXBsb3llZCAo?= =?utf-8?B?d2FzOiAyMDE5LTAxLTExIEFSSU4uTkVUIEROU1NFQyBPdXRhZ2Ug4oCTIFBv?= =?utf-8?Q?st-Mortem)?= In-Reply-To: References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <20190111143753.6lxcpaxxpg2h2vfe@nic.fr> <3DD245D6-A005-4FC8-A6B9-4B81F6512D85@arin.net> Message-ID: <8E007678-E7D7-49A3-B7E2-6EEED92D2EE6@arin.net> On 11 Jan 2019, at 3:59 PM, John Curran > wrote: ... My apologies for this incident – while ARIN does have some fragility in our older systems (which we have been working aggressively to phase out via system refresh and replacements), it is not acceptable to have this situation with key infrastructure such as our DNS zones. We will prioritize the necessary alert and monitor changes and I will report back to the community once that has been completed. Folks - I indicated that we would report back once appropriate DNSSEC monitoring is in place - this has now been completed (ref: attached announcement of same) Thanks again for your patience in this matter, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN > Subject: [arin-announce] DNSSEC Monitoring Enhancements Date: 4 February 2019 at 11:32:25 AM EST To: > On 31 January, ARIN deployed DNSSEC monitoring enhancements, including proactive RRSIG expiration checking, zone syntax checking, and DNSSEC validation. We are monitoring from various disparate locations across the Internet with these checks. This effort was undertaken in response to the incident that occurred on 11 January, detailed in the incident report below. Improved monitoring of DNSSEC and the arin.net zone will provide earlier alerts of any issues such as Resource Record Signature (RRSIG) expiration and any issues with DNSSEC validation. These enhancements will provide early warning of potential issues, prevent outages, and improve our ability to troubleshoot DNSSEC problems if they occur in the future. Regards, Mark Kosters Chief Technology Officer American Registry for Internet Numbers (ARIN) Incident Report: On 11 January 2019, at approximately 8:30 a.m. ET, ARIN monitoring systems alerted that some arin.net properties were unreachable. All users with validating DNS resolvers were unable to look up resources within arin.net and thus were unable to reach them. ARIN’s www.arin.net and ftp.arin.net sites and Whois, RPKI, and DNS services were affected for those users who use validating resolvers. ARIN’s Engineering staff determined that DNSSEC validation for the arin.net zone was failing and temporarily unpublished Delegation Signer (DS) records with our registrar so that we could investigate the problem. Upon troubleshooting, ARIN staff discovered that the removal of a resource record had created a spurious record, which caused a script to fail to reload. New versions of the zone could not be loaded, and the zone file in use expired. After determining the cause of the problem, the offending file was removed and the zone was reloaded. Delegation Signer (DS) records were republished and the zone validated, restoring service at approximately 10:30 a.m. ET. _______________________________________________ ARIN-Announce -------------- next part -------------- An HTML attachment was scrubbed... URL: From benlogan at myriverstreet.net Mon Feb 4 19:36:39 2019 From: benlogan at myriverstreet.net (Ben Logan) Date: Mon, 4 Feb 2019 14:36:39 -0500 Subject: IP Geo-Location Message-ID: Hi, What's the proper way to specify the location of prefixes within a larger prefix? For example, we purchased a /17 and it is registered in ARIN as being located in our home town. However, smaller prefixes within that /17 are located in different areas of VA and NC, and people are complaining about location services showing them in the wrong area. Not sure how to "properly" fix it. Thanks, Ben -- Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan at myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net myriverstreet.net This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Feb 4 19:28:26 2019 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 4 Feb 2019 13:28:26 -0600 (CST) Subject: Frontier Communications Cisco DSL In-Reply-To: <2033777357.6250.1549308377981.JavaMail.mhammett@ThunderFuck> Message-ID: <2079656957.6267.1549308506441.JavaMail.mhammett@ThunderFuck> If any of you have a Cisco 2811 connected via DSL to Frontier, could you hit me up offlist? Likewise, if anyone from Frontier can help me, that'd be great. Most of the Cisco DSL documentation I'm running to is forever old and doesn't necessarily work on newer IOS releases or different configs at Frontier. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Mon Feb 4 20:12:23 2019 From: bryan at shout.net (Bryan Holloway) Date: Mon, 4 Feb 2019 14:12:23 -0600 Subject: IP Geo-Location In-Reply-To: References: Message-ID: <13034dd1-789d-c0e8-d141-4518fc27dbc6@shout.net> On 2/4/19 1:36 PM, Ben Logan wrote: > Hi, > > What's the proper way to specify the location of prefixes within a > larger prefix?  For example, we purchased a /17 and it is registered in > ARIN as being located in our home town.  However, smaller prefixes > within that /17 are located in different areas of VA and NC, and people > are complaining about location services showing them in the wrong area. > Not sure how to "properly" fix it. > > Thanks, > Ben > * Create assignment objects in ARIN for your longer-prefixes based on customer and/or region with appropriate geographic info, * Make sure your forward and reverse DNS are accurate -- I'm told some geo-location databases look at this if you put geographic info into your A(AAA) or PTR records, (e.g., blah.raleigh.nc.us.myfavoriteisp.net) * Reach out to GeoIP DBs like MaxMind, IP2Location, etc. and submit updates. Unfortunately, you may have to wait several weeks or even a month for databases to update. C'est la vie. From kmedcalf at dessus.com Mon Feb 4 20:30:27 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 04 Feb 2019 13:30:27 -0700 Subject: IP Geo-Location In-Reply-To: <13034dd1-789d-c0e8-d141-4518fc27dbc6@shout.net> Message-ID: >Unfortunately, you may have to wait several weeks or even a month for >databases to update. Don't be silly! It takes nanoseconds to update the database once "the proper motivation" is present to encourage the pressing of the key. It may take weeks of months for the update to entered into the database, however, once the appropriate motivation is present, the update takes effect immediately. In other words the issue is "motivation" and not a technical one. "Adequate motivation" is a matter of nuclear weapons, lawsuits, and pending bankruptcy. In the absence of such "motivational factors" there is not impetus to act with expedience. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From dwhite at olp.net Mon Feb 4 21:09:50 2019 From: dwhite at olp.net (Dan White) Date: Mon, 4 Feb 2019 15:09:50 -0600 Subject: oneamerica.com Contact Message-ID: <20190204210950.GE3883@dan.olp.net> If there is a representative from OneAmerica here, please contact me off-list. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com From neil at domino.org Tue Feb 5 08:55:43 2019 From: neil at domino.org (Neil J. McRae) Date: Tue, 5 Feb 2019 08:55:43 +0000 Subject: DNS admin request Microsoft / Comcast Message-ID: <10BCA983-55C1-4E1F-BBBD-34513D1C6E6B@domino.org> Folks, If there is a Microsoft lead DNS person here and a comcast lead DNS person here can you contact me off-list please. Cheers, Neil McRae. From neil at domino.org Tue Feb 5 08:56:42 2019 From: neil at domino.org (Neil J. McRae) Date: Tue, 5 Feb 2019 08:56:42 +0000 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> Message-ID: +1! On 30/01/2019, 22:10, "NANOG on behalf of Ren Provo" on behalf of ren.provo at gmail.com> wrote: Hi Thomas, You probably should remove sessions with networks explicitly *not* participating in route servers versus displaying them on a global shame list. Cheers, -ren On Wed, Jan 30, 2019 at 5:06 PM Thomas King > wrote: Hi all, Thanks for your support! This helps us getting all peers on the new IPv4 space. Our looking glass shows which peers already have changed the IP settings (see section “BGP session established”) and which peers are still working on it (see section “BGP sessions down”): https://lg.de-cix.net/routeservers/rs1_nyc_ipv4#sessions-up Best regards, Thomas From: NANOG > on behalf of James Stankiewicz > Date: Wednesday, 30. January 2019 at 19:32 To: Jared Mauch > Cc: North American Network Operators' Group > Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY Microsoft an Edgecast has not yet made there changes. On Wed, Jan 30, 2019 at 12:20 PM Jared Mauch > wrote: Akamai is working on doing our part. Apologies. Sent from my iCar On Jan 30, 2019, at 12:02 PM, Mehmet Akcin > wrote: Pinged my contacts in each On Wed, Jan 30, 2019 at 05:52 Jason Lixfeld > wrote: Hi, In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. Thanks. -- Mehmet +1-424-298-1903 -- Jim Stankiewicz Principal Network Architect NJEdge W:855.832.EDGE(3343) c:201.306.4409 [https://docs.google.com/uc?export=download&id=0B15Cb24EwZVsOUhIa0lWbG9ZT2c&revid=0B15Cb24EwZVsdVB2SlJ3ekFEUllPRDZyMGZ5cUtkbko2bWQ0PQ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Tue Feb 5 15:12:57 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 5 Feb 2019 15:12:57 +0000 Subject: Any detail on 3356 outage this morning? Message-ID: <751F610E-A45A-407A-B61C-D491437929F9@dino.hostasaurus.com> Curious if anyone has detail on the cause of the CenturyLink/L3 outage this morning? Their master ticket response is not exactly confidence inspiring; hey, routers nationwide decided to reboot, but don’t worry, service was restored with no manual intervention…. *** CASCADED EXTERNAL NOTES 05-Feb-2019 14:06:31 GMT From CASE: 15846504 - Event Event Conclusion Summary Outage Start: February 05, 2019 11:00 GMT Outage Stop: February 05, 2019 12:37 GMT Root Cause: Multiple devices rebooted impacting IP services in multiple markets. Fix Action: Services restored with no CenturyLink intervention. Reason for Outage (RFO) Summary: On February 05, 2018 at 11:00 GMT, CenturyLink identified a service impact in all markets network wide. The IP NOC reported multiple devices rebooted impacting IP services in multiple markets. Services restored on their with no CenturyLink intervention. The IP NOC engaged the equipment vendor, Tier III Technical Support, and Operations Engineering to conduct a post analysis review of the incident. This service impact has concluded; if additional issues are experienced, please contact the CenturyLink Repair Center. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Feb 5 15:43:53 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 5 Feb 2019 15:43:53 +0000 Subject: Any detail on 3356 outage this morning? In-Reply-To: <751F610E-A45A-407A-B61C-D491437929F9@dino.hostasaurus.com> References: <751F610E-A45A-407A-B61C-D491437929F9@dino.hostasaurus.com> Message-ID: <6CCADD1A-61A7-4384-94AE-444B28B8618F@beckman.org> Yeah, it was obviously only in Greenwich, UK. :) -mel via cell On Feb 5, 2019, at 7:13 AM, David Hubbard > wrote: Curious if anyone has detail on the cause of the CenturyLink/L3 outage this morning? Their master ticket response is not exactly confidence inspiring; hey, routers nationwide decided to reboot, but don’t worry, service was restored with no manual intervention…. *** CASCADED EXTERNAL NOTES 05-Feb-2019 14:06:31 GMT From CASE: 15846504 - Event Event Conclusion Summary Outage Start: February 05, 2019 11:00 GMT Outage Stop: February 05, 2019 12:37 GMT Root Cause: Multiple devices rebooted impacting IP services in multiple markets. Fix Action: Services restored with no CenturyLink intervention. Reason for Outage (RFO) Summary: On February 05, 2018 at 11:00 GMT, CenturyLink identified a service impact in all markets network wide. The IP NOC reported multiple devices rebooted impacting IP services in multiple markets. Services restored on their with no CenturyLink intervention. The IP NOC engaged the equipment vendor, Tier III Technical Support, and Operations Engineering to conduct a post analysis review of the incident. This service impact has concluded; if additional issues are experienced, please contact the CenturyLink Repair Center. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Feb 5 17:16:59 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 5 Feb 2019 09:16:59 -0800 Subject: DNS admin request Microsoft / Comcast In-Reply-To: <10BCA983-55C1-4E1F-BBBD-34513D1C6E6B@domino.org> References: <10BCA983-55C1-4E1F-BBBD-34513D1C6E6B@domino.org> Message-ID: I will email you intros off the list On Tue, Feb 5, 2019 at 07:05 Neil J. McRae wrote: > Folks, > If there is a Microsoft lead DNS person here and a comcast lead DNS person > here can you contact me off-list please. > > Cheers, > Neil McRae. > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Wed Feb 6 12:36:45 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 6 Feb 2019 12:36:45 -0000 Subject: BGP Experiment In-Reply-To: References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> <01a601d4b403$de7b2160$9b716420$@netconsultings.com> <00df01d4b945$b68aaad0$23a00070$@netconsultings.com> Message-ID: <001701d4be18$9ed74e70$dc85eb50$@netconsultings.com> > From: Randy Bush > Sent: Thursday, January 31, 2019 6:56 PM > > > I suspect simple bugs are found by vendor, complex bugs are not > > economic to find. > > the running internet is complex and has a horrifying number of special cases > compounded by kiddies being clever. no one, independent of resource > requirements, could build a lab to the scale needed to test. > Yes what can break will break, yet here we are exchanging emails, I think your statement assumes a vast search space. No need to solve the whole thing, just to make my tiny part a bit better. No need to solve my tiny part for eternity, just for the near term. Yes there will always be this long tail, but with what one would deem a sufficiently low probability, in the intersection of the above search spaces. > and then there is ewd's famous quote about testing. > Yes human brains have their limits, hence we invented AI to help us solve complexity. Though in a sense it's just shifting the complexity to yet another layer above... adam From adamv0025 at netconsultings.com Wed Feb 6 13:53:48 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 6 Feb 2019 13:53:48 -0000 Subject: [Community bleaching on edge] RTBH no_export Message-ID: <002101d4be23$62e821e0$28b865a0$@netconsultings.com> Hi folks, This "RTBH no_export" thread made me wonder what is the latest view on BGP community bleaching at the edge (in/out). Anyone filtering extended RT communities inbound on NOSes that accept extended communities by default? Yeah about that. adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Wed Feb 6 15:01:16 2019 From: job at ntt.net (Job Snijders) Date: Wed, 6 Feb 2019 16:01:16 +0100 Subject: [Community bleaching on edge] RTBH no_export In-Reply-To: <002101d4be23$62e821e0$28b865a0$@netconsultings.com> References: <002101d4be23$62e821e0$28b865a0$@netconsultings.com> Message-ID: <20190206150116.GI91214@hanna.meerval.net> Hi Adam, On Wed, Feb 06, 2019 at 01:53:48PM -0000, adamv0025 at netconsultings.com wrote: > This "RTBH no_export" thread made me wonder what is the latest view on > BGP community bleaching at the edge (in/out). At NTT/AS 2914 we took a look at BGP community bleaching recently. We intend to deploy something along these lines on EBGP sessions with non-customer peering partners: LEAVE 65535:0 # allow graceful_shutdown LEAVE $Peer_ASN:* # Allow peer's communities, these have no effect in NTT DELETE *:* # delete the rest, including other well-known communities (The last 'delete' line also implicitly removes things like 0:*, 2914:*, 23456:*, etc. Note that for customer facing EBGP sessions, we have a different, more relaxed, policy.) The thinking was that our customers can potentially benefit from BGP communities set by our peering partners, but we also have to take BGP UPDATE packing and memory utilisation into consideration. IETF participants have written some snippets on the topic of BGP community bleaching: "Networks administrators SHOULD NOT remove other communities applied on received routes" https://tools.ietf.org/html/rfc7454#section-11 "In general, the intended audiences of Informational Communities are downstream networks and the GA itself, but any AS could benefit from receiving these communities." https://tools.ietf.org/html/rfc8195#section-2.1 > Anyone filtering extended RT communities inbound on NOSes that accept > extended communities by default? Yeah about that. I'd be hesitant to filter/scrub BGP Path Attributes that have no meaning in your network, it may stiffle innovation somewhere. Kind regards, Job From mehmet at akcin.net Wed Feb 6 15:18:15 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 6 Feb 2019 07:18:15 -0800 Subject: Colombia Message-ID: Hi there I am looking to meet with folks who has done work in the past shipping network gear, or sourcing locally network gear/servers to/from colombia (Bogota). If you have any experience with hosting / colocation in Colombia please contact me offlist - thank you Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncariaga at gmail.com Wed Feb 6 20:53:41 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Thu, 7 Feb 2019 04:53:41 +0800 Subject: Initial ARIN IPv4 membership and resource request Message-ID: Dear NANOG, does someone here have a breakdown of the initial ARIN fees / cost assuming I'll be requesting an initial block of /22 IPv4 resource? Regards, -nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at joelwhitehouse.com Wed Feb 6 21:00:35 2019 From: code at joelwhitehouse.com (Joel Whitehouse) Date: Wed, 6 Feb 2019 15:00:35 -0600 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: <130d58c7-afc5-8d48-bd52-50227427317e@joelwhitehouse.com> On 2/6/19 2:53 PM, Nathanael Catangay Cariaga wrote: > Dear NANOG, does someone here have a breakdown of the initial ARIN fees > / cost assuming I'll be requesting an initial block of /22 IPv4 resource? > > > Regards, > > -nathan See ARIN's official fee schedule at: https://www.arin.net/fees/fee_schedule.html From tj at pcguys.us Wed Feb 6 21:03:43 2019 From: tj at pcguys.us (TJ Trout) Date: Wed, 6 Feb 2019 13:03:43 -0800 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: You do realize that there aren't any resources available to request right? On Wed, Feb 6, 2019 at 12:54 PM Nathanael Catangay Cariaga < ncariaga at gmail.com> wrote: > Dear NANOG, does someone here have a breakdown of the initial ARIN fees / > cost assuming I'll be requesting an initial block of /22 IPv4 resource? > > > Regards, > > -nathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Wed Feb 6 21:19:13 2019 From: woody at pch.net (Bill Woodcock) Date: Wed, 6 Feb 2019 13:19:13 -0800 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: No _v4_ resources to speak of, but it’s a little late in the day to be worrying about that anyway. -Bill > On Feb 6, 2019, at 13:05, TJ Trout wrote: > > You do realize that there aren't any resources available to request right? > >> On Wed, Feb 6, 2019 at 12:54 PM Nathanael Catangay Cariaga wrote: >> Dear NANOG, does someone here have a breakdown of the initial ARIN fees / cost assuming I'll be requesting an initial block of /22 IPv4 resource? >> >> >> Regards, >> >> -nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Wed Feb 6 21:24:01 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 6 Feb 2019 15:24:01 -0600 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: <94c6462d-7e60-df88-c033-f0cd57e4d567@shout.net> A v6 /22 would be a neat announcement ... On 2/6/19 3:19 PM, Bill Woodcock wrote: > No _v4_ resources to speak of, but it’s a little late in the day to be > worrying about that anyway. >                 -Bill > > > On Feb 6, 2019, at 13:05, TJ Trout > > wrote: > >> You do realize that there aren't any resources available to request right? >> >> On Wed, Feb 6, 2019 at 12:54 PM Nathanael Catangay Cariaga >> > wrote: >> >> Dear NANOG, does someone here have a breakdown of the initial ARIN >> fees / cost assuming I'll be requesting an initial block of /22 >> IPv4 resource? >> >> >> Regards, >> >> -nathan >> From ncariaga at gmail.com Wed Feb 6 21:24:06 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Thu, 7 Feb 2019 05:24:06 +0800 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: lol thatvis something i missed in the portal... well thanks anyways.. 😁 On Thu, Feb 7, 2019, 5:03 AM TJ Trout, wrote: > You do realize that there aren't any resources available to request right? > > On Wed, Feb 6, 2019 at 12:54 PM Nathanael Catangay Cariaga < > ncariaga at gmail.com> wrote: > >> Dear NANOG, does someone here have a breakdown of the initial ARIN fees / >> cost assuming I'll be requesting an initial block of /22 IPv4 resource? >> >> >> Regards, >> >> -nathan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsweeting at arin.net Wed Feb 6 21:00:40 2019 From: jsweeting at arin.net (John Sweeting) Date: Wed, 6 Feb 2019 21:00:40 +0000 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: Hi Nathanael, I will respond to you off list. Thanks John Sweeting, Sr.Dir RSD, ARIN Sent from my iPhone > On Feb 6, 2019, at 3:54 PM, Nathanael Catangay Cariaga wrote: > > Dear NANOG, does someone here have a breakdown of the initial ARIN fees / cost assuming I'll be requesting an initial block of /22 IPv4 resource? > > > Regards, > > -nathan From don at depref.net Wed Feb 6 21:11:45 2019 From: don at depref.net (Don Beal) Date: Wed, 6 Feb 2019 15:11:45 -0600 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: You're correct, but he'll still need approval to go through legit markets, and to get in line for a direct allocation. https://www.arin.net/resources/request/waiting_list.html --Don On Wed, Feb 6, 2019 at 3:04 PM TJ Trout wrote: > You do realize that there aren't any resources available to request right? > > On Wed, Feb 6, 2019 at 12:54 PM Nathanael Catangay Cariaga < > ncariaga at gmail.com> wrote: > >> Dear NANOG, does someone here have a breakdown of the initial ARIN fees / >> cost assuming I'll be requesting an initial block of /22 IPv4 resource? >> >> >> Regards, >> >> -nathan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Wed Feb 6 21:51:43 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 6 Feb 2019 16:51:43 -0500 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: On 2/6/19 4:19 PM, Bill Woodcock wrote: > No _v4_ resources to speak of, but it’s a little late in the day to be > worrying about that anyway. They do still have some limited v4 resources available to help deploy IPv6. A new ISP can still get a /24 that way. Obviously that's not going to do much aside from let you deploy IPv6 in a non-trivial service provider deployment, but then that's kinda the point. So it's not NO v4 resources...more like extremely limited. -- Brandon Martin From sethm at rollernet.us Wed Feb 6 23:33:25 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 6 Feb 2019 15:33:25 -0800 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: On 2/6/19 13:24, Nathanael Catangay Cariaga wrote: > lol thatvis something i missed in the portal... well thanks anyways.. 😁 ARIN's free pool ran out on September 24, 2015. You can of course join the waiting list for whatever it's worth: https://www.arin.net/resources/request/waiting_list.html From clayton at MNSi.Net Wed Feb 6 23:39:31 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 06 Feb 2019 18:39:31 -0500 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: Message-ID: <1549496373_27215@surgemail.mnsi.net> Surprisingly, addresses do get returned to the free pool and are re-assigned to people on the waiting list. At 06:33 PM 06/02/2019, Seth Mattinen wrote: >On 2/6/19 13:24, Nathanael Catangay Cariaga wrote: >>lol thatvis something i missed in the portal... well thanks anyways.. 😁 > > >ARIN's free pool ran out on September 24, 2015. > >You can of course join the waiting list for whatever it's worth: > >https://www.arin.net/resources/request/waiting_list.html -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From owen at delong.com Wed Feb 6 23:40:28 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Feb 2019 15:40:28 -0800 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: <94c6462d-7e60-df88-c033-f0cd57e4d567@shout.net> References: <94c6462d-7e60-df88-c033-f0cd57e4d567@shout.net> Message-ID: <60DFC03E-D4DB-41D8-AA11-473826B8EFEC@delong.com> ARIN won’t issue a /22 of IPv6. You can get a /20 or a /24 if you meet the qualifications, but a /22 isn’t on a nibble boundary and ARIN stopped issuing non-nibble-aligned blocks several years ago. Sure, if you get a /20, you can announce it as /22s. To put the qualifications in perspective, you’d have to be pretty massive to get to the /20 stage. I”ve done address work for three relatively large organizations that qualified for /24s (one each). While I can easily imagine some organizations (mostly very large oligopolous eye-ball ISPs) needing larger than /20 even, especially if they respected their customers with /48s as they should, there are very few networks that large. Owen > On Feb 6, 2019, at 13:24 , Bryan Holloway wrote: > > A v6 /22 would be a neat announcement ... > > > On 2/6/19 3:19 PM, Bill Woodcock wrote: >> No _v4_ resources to speak of, but it’s a little late in the day to be worrying about that anyway. >> -Bill >> On Feb 6, 2019, at 13:05, TJ Trout > wrote: >>> You do realize that there aren't any resources available to request right? >>> >>> On Wed, Feb 6, 2019 at 12:54 PM Nathanael Catangay Cariaga > wrote: >>> >>> Dear NANOG, does someone here have a breakdown of the initial ARIN >>> fees / cost assuming I'll be requesting an initial block of /22 >>> IPv4 resource? >>> >>> >>> Regards, >>> >>> -nathan >>> From owen at delong.com Wed Feb 6 23:42:10 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Feb 2019 15:42:10 -0800 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: <1549496373_27215@surgemail.mnsi.net> References: <1549496373_27215@surgemail.mnsi.net> Message-ID: While it’s a possibility, I wouldn’t bet my business on the continued availability of resources through that process at this point. Owen > On Feb 6, 2019, at 15:39 , Clayton Zekelman wrote: > > > Surprisingly, addresses do get returned to the free pool and are re-assigned to people on the waiting list. > > At 06:33 PM 06/02/2019, Seth Mattinen wrote: >> On 2/6/19 13:24, Nathanael Catangay Cariaga wrote: >>> lol thatvis something i missed in the portal... well thanks anyways.. 😁 >> >> >> ARIN's free pool ran out on September 24, 2015. >> >> You can of course join the waiting list for whatever it's worth: >> >> https://www.arin.net/resources/request/waiting_list.html > > -- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 From lists.nanog at monmotha.net Thu Feb 7 13:56:19 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Thu, 7 Feb 2019 08:56:19 -0500 Subject: Initial ARIN IPv4 membership and resource request In-Reply-To: References: <1549496373_27215@surgemail.mnsi.net> Message-ID: <6ac6aabe-8c86-0ff9-2352-033cbfd461fc@monmotha.net> On 2/6/19 6:42 PM, Owen DeLong wrote: > While it’s a possibility, I wouldn’t bet my business on the continued availability of resources through that process at this point. To put it into perspective, the waiting list has people on it from over 18 months ago albeit asking for comparatively large blocks. There are wait-listed requests for a /24, the smallest they'll deal in via that process, that are getting close to a year old. With how much IPv4 space is now worth in the specified recipient transfer market, I would suspect almost everybody with existing space will be making use of that with ARIN basically getting "returned" space largely via people failing to pay their ARIN fees. -- Brandon Martin From James at arenalgroup.co Thu Feb 7 17:30:58 2019 From: James at arenalgroup.co (James Breeden) Date: Thu, 7 Feb 2019 17:30:58 +0000 Subject: Hill Country Telephone Cooperative Message-ID: Anyone from HCTC operations on here? Trying to reach your wholesale sales team, web contacts aren't getting answered. Please reach out offlist. Thanks! James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Thu Feb 7 18:47:25 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 7 Feb 2019 12:47:25 -0600 Subject: CGNAT In-Reply-To: References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> Message-ID: <001601d4bf15$91f83bd0$b5e8b370$@gvtc.com> Rich, et al, Circling back on some older threads... I'm doing this because I've been growing my cgnat environments and needing to remind myself of somethings, etc... If an attack is targeted at 1 ip address, you would think that if would/could affect all the napt-44 (nat overloaded/pat'd) ip's that hide behind it... but isn't that *IF* that traffic actually got through the nat boundary and flowed to the intended target(s) ? Unsolicited outside---->inside traffic I believe results in a deny of traffic... and I'm seeing that the nat actually builds those flows as drop flows.... I generated some traffic at a nat destination and I see all my traffic is "Drop"... now I wonder if this is a fast path like in asic (pfe) hardware being dropped... if so, it would seem that the nat boundary is yet a really nice way to quickly drop unsolicited inbound traffic from perhaps bad sources. My source where I was generating traffic... Hollywood-ip (only works in the movies) 256.256.191.133 (bad guy) Nat destination where I sending traffic to... 256.256.130.4 (victim/target) Now of course the resources/network outside the nat is bogged down, but the inside nat domain seems to be unaffected in this case from what I can tell. And again, I'm wondering if that "Drop" flow is lightweight/fast processing for the ms-mpc-128g juniper gear ? {master} agould at 960> show services sessions destination-prefix 256.256.130.4/32 | grep 256.256.191.133 | refresh 1 ---(refreshed at 2019-02-07 12:36:45 CST)--- ---(refreshed at 2019-02-07 12:36:46 CST)--- ---(refreshed at 2019-02-07 12:36:47 CST)--- ---(refreshed at 2019-02-07 12:36:48 CST)--- ---(refreshed at 2019-02-07 12:36:49 CST)--- ---(refreshed at 2019-02-07 12:36:50 CST)--- ---(refreshed at 2019-02-07 12:36:51 CST)--- ---(refreshed at 2019-02-07 12:36:52 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:53 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:54 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:55 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:56 CST)--- ---(refreshed at 2019-02-07 12:36:57 CST)--- ---(refreshed at 2019-02-07 12:36:58 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:36:59 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:37:00 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:37:01 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 - Aaron -----Original Message----- From: Compton, Rich A [mailto:Rich.Compton at charter.com] Sent: Thursday, April 6, 2017 3:49 PM To: Aaron Gould; 'Ahmed Munaf'; 'Nanog at Nanog' Subject: Re: CGNAT Hi Aaron, thanks for the info. I¹m curious what you or others do about DDoS attacks to CGNAT devices. It seems that a single attack could affect the thousands of customers that use those devices. Also, do you have issues detecting attacks vs. legitimate traffic when you have so much traffic destined to a small group of IPs? Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112 From Rich.Compton at charter.com Thu Feb 7 20:03:09 2019 From: Rich.Compton at charter.com (Compton, Rich A) Date: Thu, 7 Feb 2019 20:03:09 +0000 Subject: CGNAT In-Reply-To: <001601d4bf15$91f83bd0$b5e8b370$@gvtc.com> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> <001601d4bf15$91f83bd0$b5e8b370$@gvtc.com> Message-ID: <8EDC3058-69B6-4488-90CF-0BC7F6DD91D4@charter.com> Hi, I would suggest that you test fragmented traffic as well to your NAT device. Fragment packets (that are not the first packet) don't have the L4 info so the NAT device will have to keep them in memory until the first fragment comes in w/ the L4 info. This can cause a DoS condition if the NAT device doesn't adequately prune fragmented packets from the memory when there is a flood of these type of packets. On 2/7/19, 11:47 AM, "Aaron Gould" wrote: Rich, et al, Circling back on some older threads... I'm doing this because I've been growing my cgnat environments and needing to remind myself of somethings, etc... If an attack is targeted at 1 ip address, you would think that if would/could affect all the napt-44 (nat overloaded/pat'd) ip's that hide behind it... but isn't that *IF* that traffic actually got through the nat boundary and flowed to the intended target(s) ? Unsolicited outside---->inside traffic I believe results in a deny of traffic... and I'm seeing that the nat actually builds those flows as drop flows.... I generated some traffic at a nat destination and I see all my traffic is "Drop"... now I wonder if this is a fast path like in asic (pfe) hardware being dropped... if so, it would seem that the nat boundary is yet a really nice way to quickly drop unsolicited inbound traffic from perhaps bad sources. My source where I was generating traffic... Hollywood-ip (only works in the movies) 256.256.191.133 (bad guy) Nat destination where I sending traffic to... 256.256.130.4 (victim/target) Now of course the resources/network outside the nat is bogged down, but the inside nat domain seems to be unaffected in this case from what I can tell. And again, I'm wondering if that "Drop" flow is lightweight/fast processing for the ms-mpc-128g juniper gear ? {master} agould at 960> show services sessions destination-prefix 256.256.130.4/32 | grep 256.256.191.133 | refresh 1 ---(refreshed at 2019-02-07 12:36:45 CST)--- ---(refreshed at 2019-02-07 12:36:46 CST)--- ---(refreshed at 2019-02-07 12:36:47 CST)--- ---(refreshed at 2019-02-07 12:36:48 CST)--- ---(refreshed at 2019-02-07 12:36:49 CST)--- ---(refreshed at 2019-02-07 12:36:50 CST)--- ---(refreshed at 2019-02-07 12:36:51 CST)--- ---(refreshed at 2019-02-07 12:36:52 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:53 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:54 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:55 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:56 CST)--- ---(refreshed at 2019-02-07 12:36:57 CST)--- ---(refreshed at 2019-02-07 12:36:58 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:36:59 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:37:00 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:37:01 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 - Aaron -----Original Message----- From: Compton, Rich A [mailto:Rich.Compton at charter.com] Sent: Thursday, April 6, 2017 3:49 PM To: Aaron Gould; 'Ahmed Munaf'; 'Nanog at Nanog' Subject: Re: CGNAT Hi Aaron, thanks for the info. I¹m curious what you or others do about DDoS attacks to CGNAT devices. It seems that a single attack could affect the thousands of customers that use those devices. Also, do you have issues detecting attacks vs. legitimate traffic when you have so much traffic destined to a small group of IPs? Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112 E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From jcurran at arin.net Thu Feb 7 21:32:47 2019 From: jcurran at arin.net (John Curran) Date: Thu, 7 Feb 2019 21:32:47 +0000 Subject: Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy In-Reply-To: References: Message-ID: FYI - Relevant to discussion on this list re ARIN IPv4 waiting list. FYI, /John Begin forwarded message: From: ARIN > Date: February 7, 2019 at 4:15:51 PM EST To: > Subject: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy At their business meeting in January 2019, the ARIN Board of Trustees, in light of the potential misuse of number resources under NRPM section 4.1.8 (Unmet Requests), suspended issuance of number resources per NRPM section 4.1.8.2. (Fulfilling unmet needs), and referred NRPM section 4.1.8 to the ARIN Advisory Council for their recommendation. ARIN will complete open transactions to waiting list organizations where IPv4 addresses have already been approved pending fee payment. We will continue to accept and process IPv4 requests according to NRPM 4.1.8, and organizations may be added to the waiting list while waiting list issuance is suspended. All future IPv4 address space issued under this policy is subject to the outcome of pending policy review. To view the Board meeting minutes, visit: https://www.arin.net/about_us/bot/bot2019_0116.html View NRPM 4.1.8 at: https://www.arin.net/policy/nrpm.html#four18 Regards, John Curran President & CEO American Registry for Internet Numbers (ARIN) ____________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radevita at mejeticks.com Thu Feb 7 23:29:09 2019 From: radevita at mejeticks.com (Robert DeVita) Date: Thu, 7 Feb 2019 23:29:09 +0000 Subject: Cell Tower Database Message-ID: Does anyone know of a FREE cell tower database where I can search for cell towers? Thanks in advance.. Rob [photo] [https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png] Robert DeVita Managing Director, Mejeticks [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png] [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png] [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png] 214-305-2444 [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png] 469-441-8864 [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png] radevita at mejeticks.com [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png] www.mejeticks.com [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.png] 1919 McKinney Ave, Dallas, TX 75201 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at snowpondtech.com Thu Feb 7 23:33:49 2019 From: lists at snowpondtech.com (Snow Pond Tech Group lists) Date: Thu, 7 Feb 2019 23:33:49 +0000 Subject: Cell Tower Database In-Reply-To: References: Message-ID: https://www.cellmapper.net/map They have a free app for Android too. Used yesterday while installing an external antenna for a national ISP while on the roof of a federal gov't building. Regards, Joshua Zukerman Snow Pond Technology Group Inc. Office 207-692-2415 ________________________________ From: NANOG on behalf of Robert DeVita Sent: Thursday, February 7, 2019 6:29:09 PM To: nanog at nanog.org Subject: Cell Tower Database Does anyone know of a FREE cell tower database where I can search for cell towers? Thanks in advance.. Rob [photo] [https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png] Robert DeVita Managing Director, Mejeticks [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png] [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png] [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png] 214-305-2444 [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png] 469-441-8864 [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png] radevita at mejeticks.com [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png] www.mejeticks.com [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.png] 1919 McKinney Ave, Dallas, TX 75201 -------------- next part -------------- An HTML attachment was scrubbed... URL: From djratkay79 at gmail.com Thu Feb 7 23:46:40 2019 From: djratkay79 at gmail.com (David Ratkay) Date: Thu, 7 Feb 2019 18:46:40 -0500 Subject: Last Mile Design Message-ID: I am not sure if this is a easy question to answer. But I am wondering what ISP's do for their residential and business customers for designing POP's that they usually access to get theur traffic into a given ISP and beyond. Is it usually a L1/L2 connection from the CE to the last mile POP? Or L2 even within the last mile POP. Do you just have POP's delegated to residential users and a separate POP for business users. Or is it done on a geographical basis. So for this region of City-A we manage both residential and business customers at this same POP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Fri Feb 8 00:37:32 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Thu, 7 Feb 2019 19:37:32 -0500 Subject: Last Mile Design In-Reply-To: References: Message-ID: On 2/7/19 6:46 PM, David Ratkay wrote: > I am not sure if this is a easy question to answer. But I am wondering > what ISP's do for their residential and business customers for designing > POP's that they usually access to get theur traffic into a given ISP and > beyond. Is it usually a L1/L2 connection from the CE to the last mile > POP? Or L2 even within the last mile POP. Do you just have POP's > delegated to residential users and a separate POP for business users. Or > is it done on a geographical basis. So for this region of City-A we > manage both residential and business customers at this same POP. L3 switches that can handle a reasonable number of routes/VLANs/MACs and lots of bandwidth are so cheap that I'm fond of pushing L3 fairly deep into the access network with them in many cases. Not much benefit to that if you prefer centralized BRAS/BNG style boxes with all the bells and whistles to take the traffic management away from your last-mile gear, though. So you need access gear with its own traffic management capabilities and potentially L2 filtering of higher level traffic (DHCP snooping, ARP/ND inspection, RA guard, TCP/UDP port blocking, etc.) and that may limit your options or force you to terminate fewer customers at a PoP than you'd like to stay within the capabilities of a typical L3 switch product. I've never been overly fond of the Ma' Bell style designs with humongous routers in centralized areas and L2-only haul out to the last-mile termination. The failure modes of such systems often result in hilariously large outages that are super visible publicly and put egg on peoples' face. A neighborhood being down is a little easier to manage from a customer relations POV, I think, and it's easy to make that happen with distributed L3 termination. I've also found it easier to handle multiple backhaul paths at L3 than L2 since spanning tree is such a pain in the butt, but E-RPS/G.8032, if you get switches that support it, can also be very handy. There are some smaller, somewhat cost-effective full-touch routers that can help bridge the gap between those two options, though. Juniper's MX104 and the Cisco ASR1k series are some reasonable options for that, but it'll definitely cost more than a cheap L3 switch for a given amount of bandwidth. I do like to separate SMB and Resi traffic, but it's mostly for customer service reasons rather than technical reasons. That separation rarely entails separate equipment but rather just VLANs and PCPs, IP subnets, etc. Now if you want to sell DIA type services where you can offer full BGP tables, MPLS interconnection, etc., that's another matter. A need for IPv4 CGNAT may, as well, but things like 464XLAT, lw4o6, MAP, etc. can fix that up if you're willing to put some extra requirements on your CPE/RG. If you're in a position where you want to or have to offer competitors access to your network to sell service directly to customers, that's also going to potentially really change the situation. -- Brandon Martin From afmug at zirkel.us Fri Feb 8 00:46:49 2019 From: afmug at zirkel.us (Sean Heskett) Date: Thu, 7 Feb 2019 17:46:49 -0700 Subject: Cell Tower Database In-Reply-To: References: Message-ID: this google earth plugin will give you all towers registered with the FCC. it doesn't include *all* towers tho, just any that have been registered. http://www.fccinfo.com/fccinfo_google_earth.php -Sean On Thu, Feb 7, 2019 at 4:29 PM Robert DeVita wrote: > Does anyone know of a FREE cell tower database where I can search for cell > towers? > > > > Thanks in advance.. > > > > Rob > > > > [image: photo] > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png] > > Robert DeVita > Managing Director, Mejeticks > > [image: > https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png] > > > [image: https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png] > > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png] > 214-305-2444 <214-305-2444> > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png] > 469-441-8864 <469-441-8864> > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png] > radevita at mejeticks.com > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png] > www.mejeticks.com > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.png] > 1919 McKinney Ave, Dallas, TX 75201 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Fri Feb 8 01:14:43 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 07 Feb 2019 20:14:43 -0500 Subject: Last Mile Design In-Reply-To: References: Message-ID: <16704.1549588483@turing-police.cc.vt.edu> On Thu, 07 Feb 2019 18:46:40 -0500, David Ratkay said: > I am not sure if this is a easy question to answer. Actually,trivial to answer: "It depends". Often due to "hysterical raisins". > even within the last mile POP. Do you just have POP's delegated to > residential users and a separate POP for business users. Or is it done on a > geographical basis. So for this region of City-A we manage both residential > and business customers at this same POP. How well is servicing both out of one POP working for you? If what you have in City A is working for you, your business plan, and your customers, don't change it :) Some companies may want 2 POPs because one area of the city is highly commercial/industrial and all the home eyeball networks are on the other side of town. Or they're DSL providers in a not densely packed town, and needed two POPs to get all the customers inside the cable foot limit for sane DSL. Or they had their residential POP already up and running, and then acquired a business ISP that already had a POP. Or they designed it based on what dark fiber or coller was already in conduits or up on poles. I'm sure that at least one DSL provider ended up with two POPs due to the headaches of trying to get one POP past the incumbent, and there's probably somebody who ended up with one POP because it was impossible to set up 2 with the incumbent... From mark.tinka at seacom.mu Fri Feb 8 07:07:00 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 8 Feb 2019 09:07:00 +0200 Subject: Last Mile Design In-Reply-To: References: Message-ID: On 8/Feb/19 02:37, Brandon Martin wrote:   > > I've never been overly fond of the Ma' Bell style designs with > humongous routers in centralized areas and L2-only haul out to the > last-mile termination.  The failure modes of such systems often result > in hilariously large outages that are super visible publicly and put > egg on peoples' face.  A neighborhood being down is a little easier to > manage from a customer relations POV, I think, and it's easy to make > that happen with distributed L3 termination. We don't do Consumer services, but for our Enterprise customers, we run IP/MPLS all the way into the Access and deliver services directly off those devices. Like you, we don't like centralizing services for the very same reasons that you state. That said, I've often considered different architectures if we did provide Consumer services - from centralized BNG's on a per-region or per-town basis, as well as de-centralized BNG's on smaller routers (back when the MX80 had just launched, but obviously not fit-for-purpose in 2019). Ultimately, I can't find a feasible way to deliver Consumer services scalably and inexpensively in a de-centralized model. But, I suppose, given the nature of the product and the ARPU, reasonable centralization for such customers is not a bad thing. > There are some smaller, somewhat cost-effective full-touch routers > that can help bridge the gap between those two options, though.  > Juniper's MX104 and the Cisco ASR1k series are some reasonable options > for that, but it'll definitely cost more than a cheap L3 switch for a > given amount of bandwidth. Our poison is the Cisco ASR920 and Juniper MX204. I am yet to find any other platforms with the size, density, capability and price for full IP/MPLS capability in the Access. > > I do like to separate SMB and Resi traffic, but it's mostly for > customer service reasons rather than technical reasons.  That > separation rarely entails separate equipment but rather just VLANs and > PCPs, IP subnets, etc. Many years ago, I did consider running both Consumer and Enterprise traffic on one router - and for purposes of pride, I'm sure the major vendors would like to boast that they could allow you to do this. But in practice, it's probably a bad idea... BNG's have too many moving parts, and for some platforms, there is actually special code optimized for BNG deployments that may have an impact on traditional Enterprise or Service Provider customers. So I would separate BNG's from regular edge routers. > > Now if you want to sell DIA type services where you can offer full BGP > tables, MPLS interconnection, etc., that's another matter.  A need for > IPv4 CGNAT may, as well, but things like 464XLAT, lw4o6, MAP, etc. can > fix that up if you're willing to put some extra requirements on your > CPE/RG. We do all this in the Access on our ASR920's and MX204's (once we start deploying them). > > If you're in a position where you want to or have to offer competitors > access to your network to sell service directly to customers, that's > also going to potentially really change the situation. Why? Chances are they will require Ethernet access between their customer and their head-end, which is a typical scenario. Mark. From lists.nanog at monmotha.net Fri Feb 8 17:44:18 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 8 Feb 2019 12:44:18 -0500 Subject: Last Mile Design In-Reply-To: References: Message-ID: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> On 2/8/19 2:07 AM, Mark Tinka wrote: >> >> I do like to separate SMB and Resi traffic, but it's mostly for >> customer service reasons rather than technical reasons.  That >> separation rarely entails separate equipment but rather just VLANs and >> PCPs, IP subnets, etc. > > Many years ago, I did consider running both Consumer and Enterprise > traffic on one router - and for purposes of pride, I'm sure the major > vendors would like to boast that they could allow you to do this. But in > practice, it's probably a bad idea... BNG's have too many moving parts, > and for some platforms, there is actually special code optimized for BNG > deployments that may have an impact on traditional Enterprise or Service > Provider customers. > > So I would separate BNG's from regular edge routers. Enterprise DIA is a whole different beast. For sure, that stays separate at least for now. Some of the forthcoming PON technologies have so much bandwidth that it may become attractive to start merging them at the access layer for smaller customers, and then I guess we'll have to see what the best way to handle L3 termination on that is. If anything, just ensuring that the (often) separate tech teams have the proper access to it and knowledge of what the others are doing might be a bit of an issue. >> >> If you're in a position where you want to or have to offer competitors >> access to your network to sell service directly to customers, that's >> also going to potentially really change the situation. > > Why? Chances are they will require Ethernet access between their > customer and their head-end, which is a typical scenario. I'm thinking that, if you push L3 termination all the way out to the last access node (FTTN DSLAM being the obvious one here), you may then lack a decent way to haul pure Ethernet back to their head-end. If your L3 termination also supports MPLS, or Q-in-Q, you're probably fine. The latter might negate the potential advantages of distributed L3 from a routing POV by forcing you to again run STP or similar. If you're doing L3 termination a bit more centralized, even if not with big behemoths on a "one per super-metro" basis, this may not be a problem at all. HFC and FTTx PONs might end up being like that inherently just because of the nature of the plant and tech that runs on it. -- Brandon Martin From cscora at apnic.net Fri Feb 8 18:03:52 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Feb 2019 04:03:52 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190208180352.2577FC55A0@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Feb, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 735782 Prefixes after maximum aggregation (per Origin AS): 283896 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 354692 Total ASes present in the Internet Routing Table: 63154 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54395 Origin ASes announcing only one prefix: 23628 Transit ASes present in the Internet Routing Table: 8759 Transit-only ASes present in the Internet Routing Table: 269 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 23 Number of instances of unregistered ASNs: 25 Number of 32-bit ASNs allocated by the RIRs: 25701 Number of 32-bit ASNs visible in the Routing Table: 20922 Prefixes from 32-bit ASNs in the Routing Table: 90815 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 272 Number of addresses announced to Internet: 2840238979 Equivalent to 169 /8s, 74 /16s and 155 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 246466 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200254 Total APNIC prefixes after maximum aggregation: 57486 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 197290 Unique aggregates announced from the APNIC address blocks: 81759 APNIC Region origin ASes present in the Internet Routing Table: 9439 APNIC Prefixes per ASN: 20.90 APNIC Region origin ASes announcing only one prefix: 2672 APNIC Region transit ASes present in the Internet Routing Table: 1405 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4441 Number of APNIC addresses announced to Internet: 769736994 Equivalent to 45 /8s, 225 /16s and 65 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 217826 Total ARIN prefixes after maximum aggregation: 103457 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 217127 Unique aggregates announced from the ARIN address blocks: 104021 ARIN Region origin ASes present in the Internet Routing Table: 18351 ARIN Prefixes per ASN: 11.83 ARIN Region origin ASes announcing only one prefix: 6829 ARIN Region transit ASes present in the Internet Routing Table: 1860 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2573 Number of ARIN addresses announced to Internet: 1077270688 Equivalent to 64 /8s, 53 /16s and 216 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 202475 Total RIPE prefixes after maximum aggregation: 96393 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 198575 Unique aggregates announced from the RIPE address blocks: 117680 RIPE Region origin ASes present in the Internet Routing Table: 25807 RIPE Prefixes per ASN: 7.69 RIPE Region origin ASes announcing only one prefix: 11507 RIPE Region transit ASes present in the Internet Routing Table: 3628 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7813 Number of RIPE addresses announced to Internet: 716757184 Equivalent to 42 /8s, 184 /16s and 216 /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-210331 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: 94825 Total LACNIC prefixes after maximum aggregation: 22319 LACNIC Deaggregation factor: 4.25 Prefixes being announced from the LACNIC address blocks: 96267 Unique aggregates announced from the LACNIC address blocks: 41816 LACNIC Region origin ASes present in the Internet Routing Table: 8029 LACNIC Prefixes per ASN: 11.99 LACNIC Region origin ASes announcing only one prefix: 2194 LACNIC Region transit ASes present in the Internet Routing Table: 1508 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5580 Number of LACNIC addresses announced to Internet: 173070848 Equivalent to 10 /8s, 80 /16s and 218 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20378 Total AfriNIC prefixes after maximum aggregation: 4221 AfriNIC Deaggregation factor: 4.83 Prefixes being announced from the AfriNIC address blocks: 26251 Unique aggregates announced from the AfriNIC address blocks: 9173 AfriNIC Region origin ASes present in the Internet Routing Table: 1241 AfriNIC Prefixes per ASN: 21.15 AfriNIC Region origin ASes announcing only one prefix: 426 AfriNIC Region transit ASes present in the Internet Routing Table: 245 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 515 Number of AfriNIC addresses announced to Internet: 102993920 Equivalent to 6 /8s, 35 /16s and 144 /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 7545 4658 540 538 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3057 1241 49 VIETEL-AS-AP Viettel Group, VN 45899 3006 1725 112 VNPT-AS-VN VNPT Corp, VN 4766 2811 11127 767 KIXS-AS-KR Korea Telecom, KR 9829 2751 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2437 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2394 4906 29 CTTNET China TieTong Telecommunications 4755 2140 422 180 TATACOMM-AS TATA Communications formerl 17974 2004 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3575 1326 92 SHAW - Shaw Communications Inc., CA 11492 3498 226 588 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2607 5392 1017 AMAZON-02 - Amazon.com, Inc., US 16625 2304 1263 1738 AKAMAI-AS - Akamai Technologies, Inc., 20115 2151 2743 535 CHARTER-20115 - Charter Communications, 18566 2132 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2094 348 248 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2074 5079 583 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5302 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3269 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2619 551 1908 AKAMAI-ASN1, US 12389 2230 2221 633 ROSTELECOM-AS, RU 34984 2059 339 531 TELLCOM-AS, TR 9121 1727 1692 18 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 9009 1351 147 760 M247, GB 8402 1312 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5564 3325 588 Uninet S.A. de C.V., MX 10620 2886 437 1014 Telmex Colombia S.A., CO 11830 2694 386 39 Instituto Costarricense de Electricidad 6503 1564 433 54 Axtel, S.A.B. de C.V., MX 7303 1406 932 231 Telecom Argentina S.A., AR 6147 1284 377 29 Telefonica del Peru S.A.A., PE 28573 1243 2244 184 CLARO S.A., BR 3816 1029 511 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 931 143 66 Alestra, S. de R.L. de C.V., MX 13999 916 528 244 Mega Cable, S.A. 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 1212 393 21 LINKdotNET-AS, EG 37611 923 107 9 Afrihost, ZA 36903 810 407 147 MT-MPLS, MA 36992 806 1475 48 ETISALAT-MISR, EG 24835 685 636 22 RAYA-AS, EG 8452 642 1731 20 TE-AS TE-AS, EG 29571 487 70 13 ORANGE-COTE-IVOIRE, CI 37492 468 470 57 ORANGE-, TN 15399 427 45 11 WANANCHI-, KE 37342 419 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5564 3325 588 Uninet S.A. de C.V., MX 12479 5302 1628 138 UNI2-AS, ES 7545 4658 540 538 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3575 1326 92 SHAW - Shaw Communications Inc., CA 11492 3498 226 588 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3269 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 7552 3057 1241 49 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5302 5164 UNI2-AS, ES 4538 4653 4579 ERX-CERNET-BKB China Education and Research Net 7545 4658 4120 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3575 3483 SHAW - Shaw Communications Inc., CA 8551 3269 3226 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3310 3136 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3057 3008 VIETEL-AS-AP Viettel Group, VN 11492 3498 2910 CABLEONE - CABLE ONE, INC., US 45899 3006 2894 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65544 DOCUMENT 117.239.163.0/24 65542 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.96.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 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:12 /9:10 /10:36 /11:99 /12:291 /13:567 /14:1132 /15:1906 /16:13361 /17:7896 /18:13869 /19:25584 /20:39740 /21:46092 /22:91640 /23:74944 /24:415770 /25:925 /26:820 /27:861 /28:20 /29:6 /30:7 /31:0 /32:194 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4185 5302 UNI2-AS, ES 6327 3338 3575 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2759 3498 CABLEONE - CABLE ONE, INC., US 8551 2725 3269 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2550 3310 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2037 2694 Instituto Costarricense de Electricidad y Telec 18566 2027 2132 MEGAPATH5-US - MegaPath Corporation, US 30036 1841 2094 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1758 2086 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1604 2:893 4:22 5:2801 6:47 7:1 8:1191 12:1868 13:313 14:1893 15:37 16:4 17:238 18:59 20:50 23:2602 24:2524 25:2 27:2546 31:2058 32:94 35:36 36:831 37:3026 38:1655 39:294 40:122 41:3125 42:725 43:1990 44:141 45:6574 46:3240 47:248 49:1337 50:1088 51:319 52:1085 54:350 55:1 56:6 57:41 58:1706 59:1056 60:492 61:2057 62:2083 63:1786 64:5074 65:2181 66:4809 67:2695 68:1172 69:3494 70:1153 71:600 72:2292 74:2748 75:420 76:543 77:1698 78:1758 79:2318 80:1636 81:1425 82:1111 83:905 84:1088 85:2150 86:552 87:1563 88:955 89:2433 90:205 91:6580 92:1234 93:2449 94:2505 95:3235 96:915 97:348 98:937 99:174 100:86 101:1225 102:386 103:19955 104:3563 105:249 106:867 107:1802 108:694 109:3668 110:1625 111:1876 112:1392 113:1411 114:1138 115:1726 116:1680 117:1917 118:2192 119:1621 120:1047 121:1029 122:2290 123:1641 124:1433 125:1956 128:1210 129:679 130:522 131:1643 132:715 133:218 134:1048 135:238 136:551 137:705 138:1946 139:836 140:571 141:810 142:801 143:1031 144:892 145:506 146:1248 147:811 148:1713 149:795 150:785 151:1005 152:1003 153:325 154:2554 155:972 156:1661 157:893 158:657 159:1909 160:1508 161:911 162:2672 163:781 164:1136 165:1572 166:438 167:1376 168:3268 169:869 170:3998 171:525 172:1094 173:2163 174:1005 175:885 176:2294 177:3947 178:2568 179:1285 180:2093 181:2430 182:2685 183:1050 184:1157 185:14722 186:3686 187:2412 188:2889 189:2008 190:8289 191:1453 192:10038 193:6552 194:5357 195:4049 196:2978 197:1738 198:5766 199:5988 200:7250 201:5063 202:10112 203:10155 204:4605 205:3008 206:3244 207:3258 208:3959 209:4223 210:3936 211:1984 212:3057 213:2888 214:1087 215:52 216:5955 217:2196 218:920 219:578 220:1846 221:995 222:994 223:1432 End of report From aaron at wholesaleinternet.net Fri Feb 8 19:17:56 2019 From: aaron at wholesaleinternet.net (Aaron) Date: Fri, 8 Feb 2019 13:17:56 -0600 Subject: Last Mile Design In-Reply-To: References: Message-ID: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> We run direct fiber connections to each house and business and terminate them on the same switches.  Our switches are housed in small "huts" that are dispersed throughout the city and each handle a specific area then the huts are all connected in a ring. It really comes down to what your geography looks like. Aaron On 2/7/2019 5:46 PM, David Ratkay wrote: > I am not sure if this is a easy question to answer. But I am wondering > what ISP's do for their residential and business customers for > designing POP's that they usually access to get theur traffic into a > given ISP and beyond. Is it usually a L1/L2 connection from the CE to > the last mile POP? Or L2 even within the last mile POP. Do you just > have POP's delegated to residential users and a separate POP for > business users. Or is it done on a geographical basis. So for this > region of City-A we manage both residential and business customers at > this same POP. -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From mfidelman at meetinghouse.net Fri Feb 8 19:38:54 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 8 Feb 2019 14:38:54 -0500 Subject: Last Mile Design In-Reply-To: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> Message-ID: <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> Good for you.  None of this PON splitter nonsense. Miles Fidelman On 2/8/19 2:17 PM, Aaron wrote: > We run direct fiber connections to each house and business and > terminate them on the same switches.  Our switches are housed in small > "huts" that are dispersed throughout the city and each handle a > specific area then the huts are all connected in a ring. It really > comes down to what your geography looks like. > > Aaron > > > On 2/7/2019 5:46 PM, David Ratkay wrote: >> I am not sure if this is a easy question to answer. But I am >> wondering what ISP's do for their residential and business customers >> for designing POP's that they usually access to get theur traffic >> into a given ISP and beyond. Is it usually a L1/L2 connection from >> the CE to the last mile POP? Or L2 even within the last mile POP. Do >> you just have POP's delegated to residential users and a separate POP >> for business users. Or is it done on a geographical basis. So for >> this region of City-A we manage both residential and business >> customers at this same POP. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From aaron at wholesaleinternet.net Fri Feb 8 19:48:30 2019 From: aaron at wholesaleinternet.net (Aaron) Date: Fri, 8 Feb 2019 13:48:30 -0600 Subject: Last Mile Design In-Reply-To: <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> Message-ID: <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> I've always felt PON is a tool for people who don't know how to design a proper network. Aaron On 2/8/2019 1:38 PM, Miles Fidelman wrote: > Good for you.  None of this PON splitter nonsense. > > Miles Fidelman > > On 2/8/19 2:17 PM, Aaron wrote: >> We run direct fiber connections to each house and business and >> terminate them on the same switches.  Our switches are housed in >> small "huts" that are dispersed throughout the city and each handle a >> specific area then the huts are all connected in a ring. It really >> comes down to what your geography looks like. >> >> Aaron >> >> >> On 2/7/2019 5:46 PM, David Ratkay wrote: >>> I am not sure if this is a easy question to answer. But I am >>> wondering what ISP's do for their residential and business customers >>> for designing POP's that they usually access to get theur traffic >>> into a given ISP and beyond. Is it usually a L1/L2 connection from >>> the CE to the last mile POP? Or L2 even within the last mile POP. Do >>> you just have POP's delegated to residential users and a separate >>> POP for business users. Or is it done on a geographical basis. So >>> for this region of City-A we manage both residential and business >>> customers at this same POP. >> -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From gtaylor at tnetconsulting.net Fri Feb 8 20:12:35 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 8 Feb 2019 13:12:35 -0700 Subject: Last Mile Design In-Reply-To: <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> Message-ID: On 02/08/2019 12:48 PM, Aaron wrote: > I've always felt PON is a tool for people who don't know how to design a > proper network. Why is that? I always thought PON was a technology that reduced the number of active ports, thus altering the port cost per subscriber significantly by not actually needing dedicated ports. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From tony at wicks.co.nz Fri Feb 8 20:31:34 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Sat, 9 Feb 2019 09:31:34 +1300 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> Message-ID: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> It also significantly reduces the requirement to distribute active equipment into the field while massively reducing the feeder fibre requirement. Point to point has its place to be sure, but mass market FTTH is not viable without PON's economics. On 02/08/2019 12:48 PM, Aaron wrote: > I've always felt PON is a tool for people who don't know how to design a > proper network. Why is that? I always thought PON was a technology that reduced the number of active ports, thus altering the port cost per subscriber significantly by not actually needing dedicated ports. -- Grant. . . . unix || die --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From aaron at wholesaleinternet.net Fri Feb 8 21:02:21 2019 From: aaron at wholesaleinternet.net (Aaron) Date: Fri, 8 Feb 2019 15:02:21 -0600 Subject: Last Mile Design In-Reply-To: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> Message-ID: <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> My statement was meant to be tongue in cheek.  We deliver 1G to the home free of charge and make our money on the 10,40 and 100G connections.  We haven't been able to deliver those capacities over PON so we've never really taken it seriously.  As with everything else, you're use case and economics may vary. Aaron On 2/8/2019 2:31 PM, Tony Wicks wrote: > It also significantly reduces the requirement to distribute active equipment into the field while massively reducing the feeder fibre requirement. Point to point has its place to be sure, but mass market FTTH is not viable without PON's economics. > > > On 02/08/2019 12:48 PM, Aaron wrote: >> I've always felt PON is a tool for people who don't know how to design a >> proper network. > Why is that? > > I always thought PON was a technology that reduced the number of active > ports, thus altering the port cost per subscriber significantly by not > actually needing dedicated ports. > > > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From aaron1 at gvtc.com Fri Feb 8 22:26:17 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 8 Feb 2019 16:26:17 -0600 Subject: Last Mile Design In-Reply-To: <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> Message-ID: <003101d4bffd$4f8b3020$eea19060$@gvtc.com> We do 1 gig over pon (gpon)...Calix E7 (olt) Yes, it's my understanding, and I agree with previous post response, that PON is for using 1 fiber strand to a home (bidir , different wavelengths for xmt and rcv) and then I believe it even gets prism'd (however the heck they do it) into a 1/32 split or something like that so that you don't have to run direct fibers from every home back to the CO.... ...AND, in a rural area, geez, those are loooonnnnggg fiber runs.... so a pon cabinet in the field helps greatly Yes, 2.4g down and 1.2 g up is a concern when you've sold (oversubscribed) more bw than that We are concerned and looking for ways to overcome this and keep up with subscriber bw demands all the time ... fun and job secure -Aaron ....another Aaron :) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Sent: Friday, February 8, 2019 3:02 PM To: nanog at nanog.org Subject: Re: Last Mile Design My statement was meant to be tongue in cheek. We deliver 1G to the home free of charge and make our money on the 10,40 and 100G connections. We haven't been able to deliver those capacities over PON so we've never really taken it seriously. As with everything else, you're use case and economics may vary. Aaron On 2/8/2019 2:31 PM, Tony Wicks wrote: > It also significantly reduces the requirement to distribute active equipment into the field while massively reducing the feeder fibre requirement. Point to point has its place to be sure, but mass market FTTH is not viable without PON's economics. > > > On 02/08/2019 12:48 PM, Aaron wrote: >> I've always felt PON is a tool for people who don't know how to design a >> proper network. > Why is that? > > I always thought PON was a technology that reduced the number of active > ports, thus altering the port cost per subscriber significantly by not > actually needing dedicated ports. > > > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From djratkay79 at gmail.com Fri Feb 8 22:32:30 2019 From: djratkay79 at gmail.com (David Ratkay) Date: Fri, 8 Feb 2019 17:32:30 -0500 Subject: Last Mile Design In-Reply-To: References: Message-ID: I want to work in a ISP environment and all the input here has helped. Thanks! On Thu, Feb 7, 2019, 6:46 PM David Ratkay I am not sure if this is a easy question to answer. But I am wondering > what ISP's do for their residential and business customers for designing > POP's that they usually access to get theur traffic into a given ISP and > beyond. Is it usually a L1/L2 connection from the CE to the last mile POP? > Or L2 even within the last mile POP. Do you just have POP's delegated to > residential users and a separate POP for business users. Or is it done on a > geographical basis. So for this region of City-A we manage both residential > and business customers at this same POP. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CGross at ninestarconnect.com Fri Feb 8 22:44:28 2019 From: CGross at ninestarconnect.com (Chris Gross) Date: Fri, 8 Feb 2019 22:44:28 +0000 Subject: Last Mile Design In-Reply-To: <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz>, <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> Message-ID: For a lot of us, PONs are a way of life and may not even have any 100G capable devices in our network, muchless enough to make our money on. While you may be so "lucky" to "never really take it seriously", it is supporting hundreds of thousands, if not millions, of homes in the US. PON is the lifeblood if many rural communities. I'm luckily to have a healthy mix of PON and AE operations since I'm located next to cities. But I've met cooperatives in the middle of no where with super low density where it's 6 people + 2 donkeys on staff. AE would never work there, but PONs allow them cheap and available broadband options. Unless someone wants to give enough funding to run AE to people's homes, PONs will continue to allow many communities to have more than cellular internet access options, if that. This email has been sent from my phone. Please excuse any brevity, typos, or lack of formality. ________________________________ From: Aaron Sent: Friday, February 8, 2019 16:03 To: nanog at nanog.org Subject: Re: Last Mile Design My statement was meant to be tongue in cheek. We deliver 1G to the home free of charge and make our money on the 10,40 and 100G connections. We haven't been able to deliver those capacities over PON so we've never really taken it seriously. As with everything else, you're use case and economics may vary. Aaron On 2/8/2019 2:31 PM, Tony Wicks wrote: > It also significantly reduces the requirement to distribute active equipment into the field while massively reducing the feeder fibre requirement. Point to point has its place to be sure, but mass market FTTH is not viable without PON's economics. > > > On 02/08/2019 12:48 PM, Aaron wrote: >> I've always felt PON is a tool for people who don't know how to design a >> proper network. > Why is that? > > I always thought PON was a technology that reduced the number of active > ports, thus altering the port cost per subscriber significantly by not > actually needing dedicated ports. > > > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wholesaleinternet.com&data=02%7C01%7C%7C4dd5a2f0e3104555418808d68e08f0ac%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636852566386965544&sdata=1ICTe0CT6jJ1zyXEzxKK1epS%2BBxFhqAS1Yyv%2FFdAD7k%3D&reserved=0 ================================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ESundberg at nitelusa.com Sat Feb 9 03:05:22 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Sat, 9 Feb 2019 03:05:22 +0000 Subject: Comcast - NTT seeing congestion in Chicago at 350 Cermak Message-ID: Comcast\NTT, I am seeing a bit of congestion between the NTT and Comcast connection in Chicago. Can you guys take a look at this? Normally this is a sub 10ms path, it running at 100ms. speedtest (0.0.0.0) Fri Feb 8 20:23:49 2019 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 45.61.24.33 0.0% 862 1.0 1.1 0.9 24.9 1.6 2. te-0-0-25.ear2.chi2.us.nitelusa.net 0.0% 862 0.9 0.9 0.8 54.4 2.2 3. te-0-0-25.ear1.chi2.us.nitelusa.net 0.0% 862 1.5 1.2 0.9 34.5 1.6 4. te-0-0-24.ear1.chi1.us.nitelusa.net 0.0% 862 1.1 1.1 0.9 74.4 3.0 5. te-0-0-1-0.cr1.chi1.us.nitelusa.net 0.0% 862 0.8 0.7 0.7 13.7 0.6 6. xe-0-0-8-0.a02.chcgil09.us.bb.gin.ntt.net 0.0% 861 42.5 2.7 0.3 54.7 6.4 7. ae-0.comcast.chcgil09.us.bb.gin.ntt.net 0.5% 861 102.1 99.1 42.0 120.2 10.3 8. be-10577-cr02.350ecermak.il.ibone.comcast.net 0.6% 861 113.8 100.7 41.6 161.0 10.7 9. be-7922-ar01.area4.il.chicago.comcast.net 1.2% 861 107.8 100.7 45.1 127.6 10.8 10. be-123-rur02.homewood.il.chicago.comcast.net 0.6% 861 106.9 102.0 42.1 123.6 10.8 11. 68.87.235.206 0.9% 861 102.0 101.8 44.7 140.1 10.7 12. c-xxxxxxxxxxx.hsd1.il.comcast.net 0.7% 861 103.1 110.7 49.9 136.4 10.5 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sat Feb 9 04:00:45 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 8 Feb 2019 23:00:45 -0500 Subject: VPS providers contacts Message-ID: Hey there I am looking to get in touch with VPS providers (like vultr.com etc.) which has all automated control panel to ask few questions regarding BGP implementation and overall automated control panel related stuff. I have been trying to get a hold of someone from virtkick.com which on paper sounded like exactly what i needed but unfortunately got no response from them. thanks in advance mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Sat Feb 9 06:22:47 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 9 Feb 2019 07:22:47 +0100 (CET) Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz>, <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> Message-ID: On Fri, 8 Feb 2019, Chris Gross wrote: > For a lot of us, PONs are a way of life and may not even have any 100G > capable devices in our network, muchless enough to make our money on. > While you may be so "lucky" to "never really take it seriously", it is > supporting hundreds of thousands, if not millions, of homes in the US. > > PON is the lifeblood if many rural communities. I'm luckily to have a > healthy mix of PON and AE operations since I'm located next to cities. > But I've met cooperatives in the middle of no where with super low > density where it's 6 people + 2 donkeys on staff. AE would never work > there, but PONs allow them cheap and available broadband options. > > Unless someone wants to give enough funding to run AE to people's homes, > PONs will continue to allow many communities to have more than cellular > internet access options, if that. PON and AE both have their strengths and weakness and make sense for different deployment scenarios. My biggest problem with PON is that it seems some operators build their fiber plant for PON for all deployment cases and then it's extremely hard to back out of it and switch to AE. If you have AE you can switch to PON fairly easily, but not the other way around if you've put splitters in the manholes. -- Mikael Abrahamsson email: swmike at swm.pp.se From Ryan.Hamel at quadranet.com Sat Feb 9 07:00:10 2019 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Sat, 9 Feb 2019 07:00:10 +0000 Subject: VPS providers contacts In-Reply-To: References: Message-ID: <1d0aaff76c3745ccbff04ea9d5993aa3@LAX-MBX01.quadranet.local> Mehmet, On our network automation, we “drive” each product through SSH/telnet and use the native terminal or netconf. This automation has been around before netconf was a concept, anything new is simple as writing the configuration snippets, creating the functions in the abstracted automation classes, and overriding it in vendor model specific classes. This same template idea could be used to generate BIRD configurations that can go into a pre-defined folder from the main config file, and trigger a soft reload. I personally can’t wrap my head around BIRD since I came from the traditional network hardware background, but it certainly does have its place in the automation sector. Just make sure your system has a way to log each step from the device and program functions for checks and balances, and combine it all in a transaction like process, along with throwing an exception on data it doesn’t know to expect, and rolling back the changes if it’s possible. -- Ryan Hamel Network Administrator ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sat Feb 9 07:13:09 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 9 Feb 2019 09:13:09 +0200 Subject: Last Mile Design In-Reply-To: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> Message-ID: <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> On 8/Feb/19 19:44, Brandon Martin wrote: >   > > I'm thinking that, if you push L3 termination all the way out to the > last access node (FTTN DSLAM being the obvious one here), you may then > lack a decent way to haul pure Ethernet back to their head-end.  If > your L3 termination also supports MPLS, or Q-in-Q, you're probably > fine.  The latter might negate the potential advantages of distributed > L3 from a routing POV by forcing you to again run STP or similar. > > If you're doing L3 termination a bit more centralized, even if not > with big behemoths on a "one per super-metro" basis, this may not be a > problem at all.  HFC and FTTx PONs might end up being like that > inherently just because of the nature of the plant and tech that runs > on it. My assumption is that you'd be running full IP/MPLS all the way into the Access. In that case, what I'm saying is that you can run EoMPLS to deliver the service. Mark. From ben at 6by7.net Sat Feb 9 07:19:20 2019 From: ben at 6by7.net (Ben Cannon) Date: Fri, 8 Feb 2019 23:19:20 -0800 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> Message-ID: PON in my view is well suited for residential distribution and use profiles. 10G/XG-PON at 10gig/2.5gig is a pretty serious residential connection and even 2.5/1 is pretty great for residential 1/1 symmetric service. That said, I would in urban environments not recommend designing for GPON physical cable plan - go AE on your cabling. Play with PON if you want more headaches here with little redeeming features IMO. Instead, design rings/meshes, and think redundant/diverse path and entry/distro. There’s a reason telco standards work. These days there’s little reason to separate residential vs commercial traffic, it’s all packets at our scale. Our core is agnostic and switches anything we throw it at hardware speed, and it’s HA (min 2 core routers in every POP - even some customer buildings have diverse/redundant fiber entry from us now, back to multiple $alldayallnightjob POPs no less, in some cases to meet regulatory minimum standards compliance. All of our DCs are built this way. Fact is, if you want a network to be fast as hell, and never ever go down, think redundant everything with diversity. That said, for rural distribution, especially cheap aerial residential services in far flung locations - there’s literally nothing finer and faster and more cost effective than GPON - which is HUGELY important for reaching the final 15 MILLION Americans that do not have broadband internet connections at all. For those people, GPON can be nothing short of utterly life transforming. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On Feb 8, 2019, at 10:22 PM, Mikael Abrahamsson wrote: > > On Fri, 8 Feb 2019, Chris Gross wrote: > >> For a lot of us, PONs are a way of life and may not even have any 100G capable devices in our network, muchless enough to make our money on. While you may be so "lucky" to "never really take it seriously", it is supporting hundreds of thousands, if not millions, of homes in the US. >> >> PON is the lifeblood if many rural communities. I'm luckily to have a healthy mix of PON and AE operations since I'm located next to cities. But I've met cooperatives in the middle of no where with super low density where it's 6 people + 2 donkeys on staff. AE would never work there, but PONs allow them cheap and available broadband options. >> >> Unless someone wants to give enough funding to run AE to people's homes, PONs will continue to allow many communities to have more than cellular internet access options, if that. > > PON and AE both have their strengths and weakness and make sense for different deployment scenarios. My biggest problem with PON is that it seems some operators build their fiber plant for PON for all deployment cases and then it's extremely hard to back out of it and switch to AE. If you have AE you can switch to PON fairly easily, but not the other way around if you've put splitters in the manholes. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Sat Feb 9 10:54:24 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 9 Feb 2019 11:54:24 +0100 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> Message-ID: PON in urban areas absolutely makes sense. Maybe less in a high rise area, where each building can have a small building wide network of its own. But it in areas with single family homes PON is king. Our POPs can have up to 10 000 customers each. All on a single 96 fiber strand cable leading into the POP building. We have extra ducts, but nothing that would allow us to change that to a point to point network. That would require 100x that 96 fiber cable. With extra ducts it would be possible to rebuild from PON to point to point. But it would require massive investments. Basically you would have to invest all that we saved by building PON. For starters, you would have to have many more POPs. And yes, there are splitters in the hand holes. This is not what stops you from rebuilding from PON. It is the fact that we never paid for extra fiber. The backbone in a sub area is typically build with a 24 fiber strand cable. Because fibers are not free and are actually quite expensive as the number of fibers grow and the distances get longer. We can do a few point to point connections, for example if we need to deliver a commercial service or for our own needs (to connect POPs etc). We are not big on commercial services. But if we were, I would use WDM splitters for that. Or the long awaited 10G PON if that ever arrives and turns out at a price point that works. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Sat Feb 9 10:59:12 2019 From: ben at 6by7.net (Ben Cannon) Date: Sat, 9 Feb 2019 02:59:12 -0800 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> Message-ID: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> I should probably have mentioned that in this sense I view “urban” as exclusive to “single family homes” - meaning I’m talking about high density modern urban with under grounding requirements - and high rise residential towers. We are the opposite, we are presently enterprise, midsize, and exotic-small business only, and have no residential arm or support structure (or SLA expectations, or standards or lack thereof) of a residential connection. -Ben. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On Feb 9, 2019, at 2:54 AM, Baldur Norddahl wrote: > > PON in urban areas absolutely makes sense. Maybe less in a high rise area, where each building can have a small building wide network of its own. But it in areas with single family homes PON is king. > > Our POPs can have up to 10 000 customers each. All on a single 96 fiber strand cable leading into the POP building. We have extra ducts, but nothing that would allow us to change that to a point to point network. That would require 100x that 96 fiber cable. > > With extra ducts it would be possible to rebuild from PON to point to point. But it would require massive investments. Basically you would have to invest all that we saved by building PON. For starters, you would have to have many more POPs. > > And yes, there are splitters in the hand holes. This is not what stops you from rebuilding from PON. It is the fact that we never paid for extra fiber. The backbone in a sub area is typically build with a 24 fiber strand cable. Because fibers are not free and are actually quite expensive as the number of fibers grow and the distances get longer. We can do a few point to point connections, for example if we need to deliver a commercial service or for our own needs (to connect POPs etc). > > We are not big on commercial services. But if we were, I would use WDM splitters for that. Or the long awaited 10G PON if that ever arrives and turns out at a price point that works. > > Regards, > > Baldur > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Sat Feb 9 13:05:23 2019 From: job at ntt.net (Job Snijders) Date: Sat, 9 Feb 2019 14:05:23 +0100 Subject: Comcast - NTT seeing congestion in Chicago at 350 Cermak In-Reply-To: References: Message-ID: <20190209130523.GR91214@hanna.meerval.net> Hi, I'll follow up off list. Kind regards, Job On Sat, Feb 09, 2019 at 03:05:22AM +0000, Erik Sundberg wrote: > Comcast\NTT, > > I am seeing a bit of congestion between the NTT and Comcast connection in Chicago. Can you guys take a look at this? > > > Normally this is a sub 10ms path, it running at 100ms. > > > > speedtest (0.0.0.0) Fri Feb 8 20:23:49 2019 > Keys: Help Display mode Restart statistics Order of fields quit > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. 45.61.24.33 0.0% 862 1.0 1.1 0.9 24.9 1.6 > 2. te-0-0-25.ear2.chi2.us.nitelusa.net 0.0% 862 0.9 0.9 0.8 54.4 2.2 > 3. te-0-0-25.ear1.chi2.us.nitelusa.net 0.0% 862 1.5 1.2 0.9 34.5 1.6 > 4. te-0-0-24.ear1.chi1.us.nitelusa.net 0.0% 862 1.1 1.1 0.9 74.4 3.0 > 5. te-0-0-1-0.cr1.chi1.us.nitelusa.net 0.0% 862 0.8 0.7 0.7 13.7 0.6 > 6. xe-0-0-8-0.a02.chcgil09.us.bb.gin.ntt.net 0.0% 861 42.5 2.7 0.3 54.7 6.4 > 7. ae-0.comcast.chcgil09.us.bb.gin.ntt.net 0.5% 861 102.1 99.1 42.0 120.2 10.3 > 8. be-10577-cr02.350ecermak.il.ibone.comcast.net 0.6% 861 113.8 100.7 41.6 161.0 10.7 > 9. be-7922-ar01.area4.il.chicago.comcast.net 1.2% 861 107.8 100.7 45.1 127.6 10.8 > 10. be-123-rur02.homewood.il.chicago.comcast.net 0.6% 861 106.9 102.0 42.1 123.6 10.8 > 11. 68.87.235.206 0.9% 861 102.0 101.8 44.7 140.1 10.7 > 12. c-xxxxxxxxxxx.hsd1.il.comcast.net 0.7% 861 103.1 110.7 49.9 136.4 10.5 > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From mark.tinka at seacom.mu Sat Feb 9 15:29:56 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 9 Feb 2019 17:29:56 +0200 Subject: Last Mile Design In-Reply-To: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> Message-ID: <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> My preference, for the home, would be Active-E. But I do understand the economics that may support PON, and my position on that has softened over the years. My service provider delivers their FTTH service to me via PON, and for the most part, it's been all good. That said, I was particularly impressed with what CDE Lightband did in Clarksville, Tennessee, where they deployed their FTTH network with Active-E using Brocade to over 60,000 subscribers:     https://www.youtube.com/watch?v=cV1nYGl_Bjc If I had to build a consumer broadband network and had the budget (and owned the fibre) to do so, I'd definitely always choose Active-E:    In South Africa, we have an access network operator that uses Active-E primarily to deliver their service, making it perhaps the only FTTH provider not using PON to do this. I find this quite fascinating. Mark. On 9/Feb/19 12:59, Ben Cannon wrote: > I should probably have mentioned that in this sense I view “urban” as > exclusive to “single family homes” - meaning I’m talking about high > density modern urban with under grounding requirements - and high rise > residential towers. > > We are the opposite, we are presently enterprise, midsize, and > exotic-small business only, and have no residential arm or support > structure (or SLA expectations, or standards or lack thereof) of a > residential connection. > > -Ben. > > -Ben Cannon > CEO 6x7 Networks & 6x7 Telecom, LLC  > ben at 6by7.net > > > >> On Feb 9, 2019, at 2:54 AM, Baldur Norddahl >> > wrote: >> >> PON in urban areas absolutely makes sense. Maybe less in a high rise >> area, where each building can have a small building wide network of >> its own. But it in areas with single family homes PON is king. >> >> Our POPs can have up to 10 000 customers each. All on a single 96 >> fiber strand cable leading into the POP building. We have extra >> ducts, but nothing that would allow us to change that to a point to >> point network. That would require 100x that 96 fiber cable. >> >> With extra ducts it would be possible to rebuild from PON to point to >> point. But it would require massive investments. Basically you would >> have to invest all that we saved by building PON. For starters, you >> would have to have many more POPs. >> >> And yes, there are splitters in the hand holes. This is not what >> stops you from rebuilding from PON. It is the fact that we never paid >> for extra fiber. The backbone in a sub area is typically build with a >> 24 fiber strand cable. Because fibers are not free and are actually >> quite expensive as the number of fibers grow and the distances get >> longer. We can do a few point to point connections, for example if we >> need to deliver a commercial service or for our own needs (to connect >> POPs etc). >> >> We are not big on commercial services. But if we were, I would use >> WDM splitters for that. Or the long awaited 10G PON if that ever >> arrives and turns out at a price point that works. >> >> Regards, >> >> Baldur >>   > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sat Feb 9 16:07:35 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 9 Feb 2019 11:07:35 -0500 Subject: Last Mile Design In-Reply-To: <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> Message-ID: <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> On 2/9/19 2:13 AM, Mark Tinka wrote: > My assumption is that you'd be running full IP/MPLS all the way into the > Access. In that case, what I'm saying is that you can run EoMPLS to > deliver the service. Bingo. You're fine as long as your access L3 gear speaks MPLS. That does somewhat bump you out of the realm of "cheap L3 switch", but there are still options. -- Brandon Martin From swmike at swm.pp.se Sat Feb 9 17:59:57 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 9 Feb 2019 18:59:57 +0100 (CET) Subject: Last Mile Design In-Reply-To: <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> Message-ID: On Sat, 9 Feb 2019, Mark Tinka wrote: > If I had to build a consumer broadband network and had the budget (and > owned the fibre) to do so, I'd definitely always choose Active-E:    For anyone saying it's "impossible" to do AE they're welcome here to the nordic region and especially Sweden where PON is basically unheard of. We have millions of AE connected households. I live in one of them. -- Mikael Abrahamsson email: swmike at swm.pp.se From mfidelman at meetinghouse.net Sat Feb 9 18:20:36 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 9 Feb 2019 13:20:36 -0500 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> Message-ID: <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> Speaking of which, the Grant County Public Utility District (Washington State), has wired active ethernet all over their rural county. Seems to me that the cost difference between splitters & switches is a pretty minor component of deploying FTTH - the costs are in the trenching, and the fiber.  What you put on the poles, or in the lawn furniture, is a pretty minor cost component. Though... getting power to the switches might be an issue, less so if you're deploying on power poles. Miles Fidelman On 2/9/19 12:59 PM, Mikael Abrahamsson wrote: > On Sat, 9 Feb 2019, Mark Tinka wrote: > >> If I had to build a consumer broadband network and had the budget >> (and owned the fibre) to do so, I'd definitely always choose Active-E: > > For anyone saying it's "impossible" to do AE they're welcome here to > the nordic region and especially Sweden where PON is basically unheard > of. We have millions of AE connected households. I live in one of them. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From sander at steffann.nl Sat Feb 9 18:22:08 2019 From: sander at steffann.nl (Sander Steffann) Date: Sat, 9 Feb 2019 19:22:08 +0100 Subject: Last Mile Design In-Reply-To: <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> Message-ID: <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> Hi Mark, > My preference, for the home, would be Active-E. But I do understand the economics that may support PON, and my position on that has softened over the years. Same for me. I like the architecture where the PON splitters are in powered roadside cabinets (even though the splitter is passive). That way the ISP can convert it to AE at any time they want. The architectures where PON has been hardcoded into the design has always felt like a huge risk regarding future developments. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From clayton at MNSi.Net Sat Feb 9 18:35:18 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sat, 09 Feb 2019 13:35:18 -0500 Subject: Last Mile Design In-Reply-To: <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> Message-ID: <1549737322_50005@surgemail.mnsi.net> We have around 60,000 homes passed with GPON architecture. I'm not really sure how we would have built that with active roadside cabinets, and still have been able to maintain any sort cost control. If we did it with a home run individual fibre scheme hauled back to a central POP, the frame would have been massive and the power and cooling requirements would have made the entire project unfeasible. Maybe the economics are different in other markets. Because PON is so widely deployed, you can count on vendors coming up with capacity increases (NG, X, etc.) to support the installed base of infrastructure. Verizon alone will drive that market. From a purist point of view, AE is a nice idea, but it really isn't necessary for now or the foreseeable future. At 01:22 PM 09/02/2019, Sander Steffann wrote: >Hi Mark, > > > My preference, for the home, would be Active-E. But I do > understand the economics that may support PON, and my position on > that has softened over the years. > >Same for me. I like the architecture where the PON splitters are in >powered roadside cabinets (even though the splitter is passive). >That way the ISP can convert it to AE at any time they want. The >architectures where PON has been hardcoded into the design has >always felt like a huge risk regarding future developments. > >Cheers, >Sander > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From baldur.norddahl at gmail.com Sat Feb 9 18:37:32 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 9 Feb 2019 19:37:32 +0100 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> Message-ID: It is not impossible just more expensive. Incidentally here in Denmark we have TDC now converting active ethernet to GPON. lør. 9. feb. 2019 19.01 skrev Mikael Abrahamsson : > On Sat, 9 Feb 2019, Mark Tinka wrote: > > > If I had to build a consumer broadband network and had the budget (and > > owned the fibre) to do so, I'd definitely always choose Active-E: > > For anyone saying it's "impossible" to do AE they're welcome here to the > nordic region and especially Sweden where PON is basically unheard of. We > have millions of AE connected households. I live in one of them. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sat Feb 9 18:44:29 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 9 Feb 2019 11:44:29 -0700 Subject: Last Mile Design In-Reply-To: <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> Message-ID: <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> On 2/9/19 11:22 AM, Sander Steffann wrote: > Same for me. I like the architecture where the PON splitters are in > powered roadside cabinets (even though the splitter is passive). That > way the ISP can convert it to AE at any time they want. The architectures > where PON has been hardcoded into the design has always felt like a huge > risk regarding future developments. I agree that PON with splitters where you can't put Active Ethernet equipment is largely equivalent to solution lock-in. But is that in and of itself a bad thing? Especially when viewed in within the lifecycle of the network? From an outsider n00b point of view, the things that I'm reading it seems that people don't like about PON are largely it's inflexibility to be able to be converted to Active Ethernet without careful forethought and planning at construction time of the fiber network to allow it to change in the future. In some ways, I've heard of the industry having this, or a very similar discussion for 25 years. Twisted pair (Cat 3 vs Cat 5 vs Cat 5e vs Cat 6) vs coax (RG 59 vs RG 6 vs F-11) vs fiber (OS1 vs OS2 vs OM1 vs OM2 vs OM3 vs OM4 vs OM5) vs RF (myriad of options). Included to topology designs equating to lock-in. However, none of this seems to be related to how functional any given design is. I guess perhaps that the subject "Last Mile Design" does encourage discussions about topology and technology. So let me ask this: Are there any functional reasons to favor AE over PON /within/ the lifecycle of a deployment? Does one methodology offer any significant advantages or disadvantages over the other? If so, is (are) the pro(s) / con(s) applicable to specific use case(s)? Remember that there are LOTs of ways to do things. I'm trying to glean what makes one method better or worse than another, possibly for different types of deployments. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From mfidelman at meetinghouse.net Sat Feb 9 19:12:06 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 9 Feb 2019 14:12:06 -0500 Subject: Last Mile Design In-Reply-To: <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> Message-ID: <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> On 2/9/19 1:44 PM, Grant Taylor via NANOG wrote: > > So let me ask this:  Are there any functional reasons to favor AE over > PON /within/ the lifecycle of a deployment?  Does one methodology > offer any significant advantages or disadvantages over the other?  If > so, is (are) the pro(s) / con(s) applicable to specific use case(s)? > With early PON designs, upstream bandwidth was horrible. Not particularly useful if you're doing things like remote backup, or video chatting, or running a server (business grade service). GPON does better on upstream bandwidth, but it's still asymmetric. If you're marketing to business customers, or home office professionals, of families with multiple users that consume upstream bandwidth, AE gives you a lot of room for upside growth (assuming you provision the right kinds of fiber). --- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From gtaylor at tnetconsulting.net Sat Feb 9 19:51:12 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 9 Feb 2019 12:51:12 -0700 Subject: Last Mile Design In-Reply-To: <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> Message-ID: On 2/9/19 12:12 PM, Miles Fidelman wrote: > With early PON designs, upstream bandwidth was horrible. Not > particularly useful if you're doing things like remote backup, or video > chatting, or running a server (business grade service). GPON does better > on upstream bandwidth, but it's still asymmetric. Intriguing. I would have not considered my municipal GPON to be asymmetric. Well, not as such. Routinely, when I do speed tests I get better upstream speeds than I do downstream speeds. (More below.) > If you're marketing to business customers, or home office professionals, > of families with multiple users that consume upstream bandwidth, AE > gives you a lot of room for upside growth (assuming you provision the > right kinds of fiber). Are you referring to the dedicated bandwidth between the CPU and the AE equipment? Or the fact that bandwidth feeding the GPON and all subscribers is aggregate? I have attributed the asymmetry in my speed tests to be that most people on my GPON are predominantly downloading, thus consuming aggregate download bandwidth. Conversely, few are uploading more than requests, thus using relatively little of the aggregate upload bandwidth. Do I see asymmetry? Yes. Is it truly asymmetric? I don't think so. I think is just based on consumption of aggregate bandwidth. I have no idea if this is normal for GPON or not. Hence one of the reasons that I'm finding this thread enlightening. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From baldur.norddahl at gmail.com Sat Feb 9 20:13:17 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 9 Feb 2019 21:13:17 +0100 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> Message-ID: GPON is 2.4 Gbps downstream and 1.2 Gbps upstream. Residential users are download heavy and more than 1:2. However there is a big difference between average, peak and micro burst. The conclusion is not simple. We typically have 60+ users on each port. We sell 1000/1000 internet. And yet we only get good ratings for the speed. I find that many, that are sceptical about the shared bandwidth of GPON, forget that a typical POP might only be fed by a 10 Gbps uplink. Usually this has much lower bandwidth per user than the GPON link. Regards Baldur lør. 9. feb. 2019 20.52 skrev Grant Taylor via NANOG : > On 2/9/19 12:12 PM, Miles Fidelman wrote: > > With early PON designs, upstream bandwidth was horrible. Not > > particularly useful if you're doing things like remote backup, or video > > chatting, or running a server (business grade service). GPON does better > > on upstream bandwidth, but it's still asymmetric. > > Intriguing. > > I would have not considered my municipal GPON to be asymmetric. Well, > not as such. Routinely, when I do speed tests I get better upstream > speeds than I do downstream speeds. (More below.) > > > If you're marketing to business customers, or home office professionals, > > of families with multiple users that consume upstream bandwidth, AE > > gives you a lot of room for upside growth (assuming you provision the > > right kinds of fiber). > > Are you referring to the dedicated bandwidth between the CPU and the AE > equipment? Or the fact that bandwidth feeding the GPON and all > subscribers is aggregate? > > I have attributed the asymmetry in my speed tests to be that most people > on my GPON are predominantly downloading, thus consuming aggregate > download bandwidth. Conversely, few are uploading more than requests, > thus using relatively little of the aggregate upload bandwidth. > > Do I see asymmetry? Yes. Is it truly asymmetric? I don't think so. I > think is just based on consumption of aggregate bandwidth. > > I have no idea if this is normal for GPON or not. Hence one of the > reasons that I'm finding this thread enlightening. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Feb 9 20:14:51 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 9 Feb 2019 14:14:51 -0600 (CST) Subject: Last Mile Design In-Reply-To: <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> Message-ID: <2008061440.1306.1549743289267.JavaMail.mhammett@ThunderFuck> Electrical consumption of the equipment is different and then the environmental conditioning that larger electronic load. Let's not forget that actual consumer bit consumption changes very little whether they have 20 megs or 2 gigs provisioned and available. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Miles Fidelman" To: nanog at nanog.org Sent: Saturday, February 9, 2019 12:20:36 PM Subject: Re: Last Mile Design Speaking of which, the Grant County Public Utility District (Washington State), has wired active ethernet all over their rural county. Seems to me that the cost difference between splitters & switches is a pretty minor component of deploying FTTH - the costs are in the trenching, and the fiber. What you put on the poles, or in the lawn furniture, is a pretty minor cost component. Though... getting power to the switches might be an issue, less so if you're deploying on power poles. Miles Fidelman On 2/9/19 12:59 PM, Mikael Abrahamsson wrote: > On Sat, 9 Feb 2019, Mark Tinka wrote: > >> If I had to build a consumer broadband network and had the budget >> (and owned the fibre) to do so, I'd definitely always choose Active-E: > > For anyone saying it's "impossible" to do AE they're welcome here to > the nordic region and especially Sweden where PON is basically unheard > of. We have millions of AE connected households. I live in one of them. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman at meetinghouse.net Sat Feb 9 20:23:29 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 9 Feb 2019 15:23:29 -0500 Subject: Last Mile Design In-Reply-To: References: <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> Message-ID: On 2/9/19 2:51 PM, Grant Taylor via NANOG wrote: > On 2/9/19 12:12 PM, Miles Fidelman wrote: >> With early PON designs, upstream bandwidth was horrible. Not >> particularly useful if you're doing things like remote backup, or >> video chatting, or running a server (business grade service). GPON >> does better on upstream bandwidth, but it's still asymmetric. > > Intriguing. > > I would have not considered my municipal GPON to be asymmetric. Well, > not as such.  Routinely, when I do speed tests I get better upstream > speeds than I do downstream speeds.  (More below.) > >> If you're marketing to business customers, or home office >> professionals, of families with multiple users that consume upstream >> bandwidth, AE gives you a lot of room for upside growth (assuming you >> provision the right kinds of fiber). > > Are you referring to the dedicated bandwidth between the CPU and the > AE equipment?  Or the fact that bandwidth feeding the GPON and all > subscribers is aggregate? I'm thinking about the backside.  Generally there's a lot more downstream bandwidth to distribute, and not a lot of upstream bandwidth.  Makes a lot of sense if you're a content provider & expect your customers to be passive consumers (also, considering that a lot of that bandwidth might be used for things other than IP packets). > > I have attributed the asymmetry in my speed tests to be that most > people on my GPON are predominantly downloading, thus consuming > aggregate download bandwidth.  Conversely, few are uploading more than > requests, thus using relatively little of the aggregate upload bandwidth. Probably the case.  But if you're in an area with a lot of home office users, or gamers, or business grade customers running servers, your experience might be different. > > Do I see asymmetry?  Yes.  Is it truly asymmetric?  I don't think so.  > I think is just based on consumption of aggregate bandwidth. > > I have no idea if this is normal for GPON or not.  Hence one of the > reasons that I'm finding this thread enlightening. > > The SPECS are asymmetric, as is the technology when you take into account allocation of bandwidth between downstream video & IP services. Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Sat Feb 9 20:26:13 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 9 Feb 2019 15:26:13 -0500 Subject: Last Mile Design In-Reply-To: <2008061440.1306.1549743289267.JavaMail.mhammett@ThunderFuck> References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> <2008061440.1306.1549743289267.JavaMail.mhammett@ThunderFuck> Message-ID: <5bdbdfed-e1d4-4f24-baac-0687417d0fbc@meetinghouse.net> I expect things are going to change as IoT takes off - security cameras, baby monitors, start to push video upstream - that makes a difference. And then there are the efforts of cell carriers to push traffic onto home wifi - more and more facetime video will also add load. Miles On 2/9/19 3:14 PM, Mike Hammett wrote: > Electrical consumption of the equipment is different and then the > environmental conditioning that larger electronic load. > > Let's not forget that actual consumer bit consumption changes very > little whether they have 20 megs or 2 gigs provisioned and available. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ------------------------------------------------------------------------ > *From: *"Miles Fidelman" > *To: *nanog at nanog.org > *Sent: *Saturday, February 9, 2019 12:20:36 PM > *Subject: *Re: Last Mile Design > > Speaking of which, the Grant County Public Utility District (Washington > State), has wired active ethernet all over their rural county. > > Seems to me that the cost difference between splitters & switches is a > pretty minor component of deploying FTTH - the costs are in the > trenching, and the fiber.  What you put on the poles, or in the lawn > furniture, is a pretty minor cost component. Though... getting power to > the switches might be an issue, less so if you're deploying on power > poles. > > Miles Fidelman > > On 2/9/19 12:59 PM, Mikael Abrahamsson wrote: > > On Sat, 9 Feb 2019, Mark Tinka wrote: > > > >> If I had to build a consumer broadband network and had the budget > >> (and owned the fibre) to do so, I'd definitely always choose Active-E: > > > > For anyone saying it's "impossible" to do AE they're welcome here to > > the nordic region and especially Sweden where PON is basically unheard > > of. We have millions of AE connected households. I live in one of them. > > > -- > In theory, there is no difference between theory and practice. > In practice, there is.  .... Yogi Berra > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Feb 9 20:27:37 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 9 Feb 2019 14:27:37 -0600 (CST) Subject: Last Mile Design In-Reply-To: <5bdbdfed-e1d4-4f24-baac-0687417d0fbc@meetinghouse.net> References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> <2008061440.1306.1549743289267.JavaMail.mhammett@ThunderFuck> <5bdbdfed-e1d4-4f24-baac-0687417d0fbc@meetinghouse.net> Message-ID: <992851510.1361.1549744054054.JavaMail.mhammett@ThunderFuck> The biggest use of bandwidth as the IoT buzzword comes to fruition is exploits. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Miles Fidelman" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Saturday, February 9, 2019 2:26:13 PM Subject: Re: Last Mile Design I expect things are going to change as IoT takes off - security cameras, baby monitors, start to push video upstream - that makes a difference. And then there are the efforts of cell carriers to push traffic onto home wifi - more and more facetime video will also add load. Miles On 2/9/19 3:14 PM, Mike Hammett wrote: Electrical consumption of the equipment is different and then the environmental conditioning that larger electronic load. Let's not forget that actual consumer bit consumption changes very little whether they have 20 megs or 2 gigs provisioned and available. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Miles Fidelman" To: nanog at nanog.org Sent: Saturday, February 9, 2019 12:20:36 PM Subject: Re: Last Mile Design Speaking of which, the Grant County Public Utility District (Washington State), has wired active ethernet all over their rural county. Seems to me that the cost difference between splitters & switches is a pretty minor component of deploying FTTH - the costs are in the trenching, and the fiber. What you put on the poles, or in the lawn furniture, is a pretty minor cost component. Though... getting power to the switches might be an issue, less so if you're deploying on power poles. Miles Fidelman On 2/9/19 12:59 PM, Mikael Abrahamsson wrote: > On Sat, 9 Feb 2019, Mark Tinka wrote: > >> If I had to build a consumer broadband network and had the budget >> (and owned the fibre) to do so, I'd definitely always choose Active-E: > > For anyone saying it's "impossible" to do AE they're welcome here to > the nordic region and especially Sweden where PON is basically unheard > of. We have millions of AE connected households. I live in one of them. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman at meetinghouse.net Sat Feb 9 20:28:22 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 9 Feb 2019 15:28:22 -0500 Subject: Last Mile Design In-Reply-To: <992851510.1361.1549744054054.JavaMail.mhammett@ThunderFuck> References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> <2008061440.1306.1549743289267.JavaMail.mhammett@ThunderFuck> <5bdbdfed-e1d4-4f24-baac-0687417d0fbc@meetinghouse.net> <992851510.1361.1549744054054.JavaMail.mhammett@ThunderFuck> Message-ID: There is that. On 2/9/19 3:27 PM, Mike Hammett wrote: > The biggest use of bandwidth as the IoT buzzword comes to fruition is > exploits. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ------------------------------------------------------------------------ > *From: *"Miles Fidelman" > *To: *"Mike Hammett" > *Cc: *nanog at nanog.org > *Sent: *Saturday, February 9, 2019 2:26:13 PM > *Subject: *Re: Last Mile Design > > I expect things are going to change as IoT takes off - security > cameras, baby monitors, start to push video upstream - that makes a > difference. > > > And then there are the efforts of cell carriers to push traffic onto > home wifi - more and more facetime video will also add load. > > > Miles > > > On 2/9/19 3:14 PM, Mike Hammett wrote: > > Electrical consumption of the equipment is different and then the > environmental conditioning that larger electronic load. > > Let's not forget that actual consumer bit consumption changes very > little whether they have 20 megs or 2 gigs provisioned and available. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ------------------------------------------------------------------------ > *From: *"Miles Fidelman" > *To: *nanog at nanog.org > *Sent: *Saturday, February 9, 2019 12:20:36 PM > *Subject: *Re: Last Mile Design > > Speaking of which, the Grant County Public Utility District > (Washington > State), has wired active ethernet all over their rural county. > > Seems to me that the cost difference between splitters & switches > is a > pretty minor component of deploying FTTH - the costs are in the > trenching, and the fiber.  What you put on the poles, or in the lawn > furniture, is a pretty minor cost component. Though... getting > power to > the switches might be an issue, less so if you're deploying on > power poles. > > Miles Fidelman > > On 2/9/19 12:59 PM, Mikael Abrahamsson wrote: > > On Sat, 9 Feb 2019, Mark Tinka wrote: > > > >> If I had to build a consumer broadband network and had the budget > >> (and owned the fibre) to do so, I'd definitely always choose > Active-E: > > > > For anyone saying it's "impossible" to do AE they're welcome > here to > > the nordic region and especially Sweden where PON is basically > unheard > > of. We have millions of AE connected households. I live in one > of them. > > > -- > In theory, there is no difference between theory and practice. > In practice, there is.  .... Yogi Berra > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From bellman at nsc.liu.se Sat Feb 9 21:04:39 2019 From: bellman at nsc.liu.se (Thomas Bellman) Date: Sat, 9 Feb 2019 22:04:39 +0100 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> Message-ID: <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> On 2019-02-09 18:59 CET, Mikael Abrahamsson wrote: > For anyone saying it's "impossible" to do AE they're welcome here to > the nordic region and especially Sweden where PON is basically unheard > of. We have millions of AE connected households. I live in one of them. However, large parts (probably even most) of our FTTH deployments have been built, and are owned, by our municipalities, not private companies. And have had government subsidies. (Sometimes outsourced to normal commercial companies, but those companies then have the municipality as their customer, not us end-users.) Even without the subsidies, I expect that changes what kind of long- term view is taken on the investment. A purely commercial company might want a return on their investments in just a few years, and if the fiber plant needs to be replaced in its entirety ten years from now, that will be the problem of a different CEO. :-) A municipality (or a company wholly owned by the municipality) is used to build roads and water pipes with expected lifetimes of 50 years, and might build their fiber plants expecting them to live 20 years or longer. /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From gtaylor at tnetconsulting.net Sat Feb 9 21:12:01 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 9 Feb 2019 14:12:01 -0700 Subject: Last Mile Design In-Reply-To: References: <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> Message-ID: <70d68a23-9805-2acb-a5a7-f8fe445e4836@spamtrap.tnetconsulting.net> On 2/9/19 1:13 PM, Baldur Norddahl wrote: > GPON is 2.4 Gbps downstream and 1.2 Gbps upstream. Okay. I guess I've not thought about the fact that the GPON itself might be ~> is asymmetric. From my naive point of view, I see a 1G/1G symmetric Ethernet hand off from the ONT to my equipment. Hence my uninformed understanding. > Residential users are download heavy and more than 1:2. However there is > a big difference between average, peak and micro burst. The conclusion > is not simple. ACK > We typically have 60+ users on each port. We sell 1000/1000 internet. > And yet we only get good ratings for the speed. I've learned that people are quick to judge harshly and slow to complement. Or that good or better speeds ratings are lost to other things like price and / or other services offered, like native IPv6 or not. > I find that many, that are sceptical about the shared bandwidth of GPON, > forget that a typical POP might only be fed by a 10 Gbps uplink. Usually > this has much lower bandwidth per user than the GPON link. I remember having these discussions in the early 2000's about ADSL vs Cable Modem. I wonder if some of the earlier horror stories are unconsciously biasing people's opinions. Or if people quite literally only look at / think about the directly attached network segment. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From mfidelman at meetinghouse.net Sat Feb 9 21:17:18 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 9 Feb 2019 16:17:18 -0500 Subject: Last Mile Design In-Reply-To: <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> Message-ID: <9ea5800e-8dce-c014-0bb2-cbfca78f17bd@meetinghouse.net> On 2/9/19 4:04 PM, Thomas Bellman wrote: > On 2019-02-09 18:59 CET, Mikael Abrahamsson wrote: > >> For anyone saying it's "impossible" to do AE they're welcome here to >> the nordic region and especially Sweden where PON is basically unheard >> of. We have millions of AE connected households. I live in one of them. > However, large parts (probably even most) of our FTTH deployments have > been built, and are owned, by our municipalities, not private companies. > And have had government subsidies. (Sometimes outsourced to normal > commercial companies, but those companies then have the municipality as > their customer, not us end-users.) > > Even without the subsidies, I expect that changes what kind of long- > term view is taken on the investment. A purely commercial company might > want a return on their investments in just a few years, and if the fiber > plant needs to be replaced in its entirety ten years from now, that will > be the problem of a different CEO. :-) A municipality (or a company > wholly owned by the municipality) is used to build roads and water pipes > with expected lifetimes of 50 years, and might build their fiber plants > expecting them to live 20 years or longer. > Yes indeed, longer time horizon, but generally not so much subsidized as: - having a big initial customer (municipal electric utility, water utility, the city or county) - a lot of municipal builds are essentially done for internal purposes, with service to the public as a bonus - still, usually funded by bonds - long-term money, low rates - and maybe some money from the NTIA (also available to rural coops) - a view of networks as infrastructure, with cost-recovery pricing, rather than as a revenue stream to milk (same as internal networks at a university or corporation) By and large, there's a pretty good argument that we SHOULD be viewing broadband networks as infrastructure, with ownership & management to match.  (Fair disclosure, I used to promote that view as director of a non-profit policy shop, and as a consultant to municipal governments.  I've also helped design & build big networks, for big customers - in my days at BBN - so it's an informed opinion :-). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mark.tinka at seacom.mu Sat Feb 9 22:24:07 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 10 Feb 2019 00:24:07 +0200 Subject: Last Mile Design In-Reply-To: <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> Message-ID: <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> On 9/Feb/19 18:07, Brandon Martin wrote: >   > > Bingo.  You're fine as long as your access L3 gear speaks MPLS.  That > does somewhat bump you out of the realm of "cheap L3 switch", but > there are still options. IP-capable switches that have little to no MPLS support would certainly be cheaper than one that does. But given the benefits of an MPLS-based Metro-E network vs. the traditional architecture, I find current prices somewhat reasonable. Mark. From mark.tinka at seacom.mu Sat Feb 9 22:25:21 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 10 Feb 2019 00:25:21 +0200 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> Message-ID: <2ab5f93c-0cf3-f9ce-0739-0c1ceaef26a5@seacom.mu> On 9/Feb/19 19:59, Mikael Abrahamsson wrote: >    > > For anyone saying it's "impossible" to do AE they're welcome here to > the nordic region and especially Sweden where PON is basically unheard > of. We have millions of AE connected households. I live in one of them. Love what Stokab did/are doing. A prime example of how well things can be done if gubbermints and the private sector are efficient. Mark. From mark.tinka at seacom.mu Sat Feb 9 22:36:50 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 10 Feb 2019 00:36:50 +0200 Subject: Last Mile Design In-Reply-To: <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> Message-ID: On 9/Feb/19 21:12, Miles Fidelman wrote: >   > > If you're marketing to business customers, or home office > professionals, of families with multiple users that consume upstream > bandwidth, AE gives you a lot of room for upside growth (assuming you > provision the right kinds of fiber). Agreed - we generally do not recommend the use of GPON for our Enterprise customers. However, in cases where a 3rd party partner discloses their use of GPON to deliver our tails, we dumb down the SLA's and technical capabilities and advise the customer accordingly. Mark. From tony at wicks.co.nz Sat Feb 9 23:01:13 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Sun, 10 Feb 2019 12:01:13 +1300 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <53DBF153-78D8-4667-AA71-AE5EA8FF1657@steffann.nl> <16e6dfd9-84b0-d122-3b75-9e38544359ca@spamtrap.tnetconsulting.net> <946f428a-6d7e-9617-8ea2-88fe64d996e8@meetinghouse.net> Message-ID: <00b401d4c0cb$5b14f060$113ed120$@wicks.co.nz> In New Zealand we have a mostly (any town of about 20k population or more) nationwide FTTH rollout underway (government/private partnership) that is mostly based on GPON. Both Point to Point and Dark Fibre are available as well. The service is layer 2 QinQ delivered to the retail service providers, (1/16 split on the GPON) while the fibre infrastructure provider is barred from retail service sales. GPON speeds generally delivered are 100/50, 200/200 and 1G/500. In general the real world result of this is a network that performs fantastically for both retail and SMB. Larger businesses are often delivered over single strand dark Fibre, but in practice the 1G/500M service works extremely well for most situations. 10G over the PON network is about to start a trial phase, but the ready availability of DF significantly reduces the urgency of this (8x10G over cheap CWDM fibre mux's makes for a nice solution). > >Agreed - we generally do not recommend the use of GPON for our Enterprise customers. However, in cases where a 3rd party partner discloses their use of GPON to deliver our tails, we dumb down the SLA's and >technical capabilities and advise the customer accordingly. > >Mark. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From morrowc.lists at gmail.com Sun Feb 10 02:09:29 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 9 Feb 2019 21:09:29 -0500 Subject: Verizon having a bad routing day today? Message-ID: howdy! I wonder if there's a lurking verizon/701 engineer on-list who may have a few moments to reach me out of band? :) I've got what looks like busted routing (or changes to peering/etc) causing me some headaches this last day or so. I'd like to chat/email and see if there's a good reason for this OR if it's just the vagaries of the tubes these days? thanks! -chris (an actual verizon customer, still) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sun Feb 10 05:16:31 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sun, 10 Feb 2019 00:16:31 -0500 Subject: Last Mile Design In-Reply-To: <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <7a0d8300-eafb-d9ec-9759-426de875ec45@meetinghouse.net> Message-ID: <9529dde4-7c22-e60b-851f-ccc100dd6826@monmotha.net> On 2/9/19 1:20 PM, Miles Fidelman wrote: > Though... getting power to > the switches might be an issue, less so if you're deploying on power poles. Just because you're on the power poles doesn't mean you can easily get permission or space to mount powered equipment on them let alone power at reasonable costs. In areas with a commercial for-profit monopoly electric utility, just getting attachment space in the telecom zone at a reasonable price can be a big issue, and often putting stuff outside the telecom cable attachment zone is impossible. -- Brandon Martin From baldur.norddahl at gmail.com Sun Feb 10 05:20:52 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 10 Feb 2019 06:20:52 +0100 Subject: Last Mile Design In-Reply-To: <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> Message-ID: The FTTH rollout in Sweden has resulted in monopoly and the prices are high. Anything will work if you do not need to compete and you are getting financed by someone with money to spend. lør. 9. feb. 2019 22.05 skrev Thomas Bellman : > On 2019-02-09 18:59 CET, Mikael Abrahamsson wrote: > > > For anyone saying it's "impossible" to do AE they're welcome here to > > the nordic region and especially Sweden where PON is basically unheard > > of. We have millions of AE connected households. I live in one of them. > > However, large parts (probably even most) of our FTTH deployments have > been built, and are owned, by our municipalities, not private companies. > And have had government subsidies. (Sometimes outsourced to normal > commercial companies, but those companies then have the municipality as > their customer, not us end-users.) > > Even without the subsidies, I expect that changes what kind of long- > term view is taken on the investment. A purely commercial company might > want a return on their investments in just a few years, and if the fiber > plant needs to be replaced in its entirety ten years from now, that will > be the problem of a different CEO. :-) A municipality (or a company > wholly owned by the municipality) is used to build roads and water pipes > with expected lifetimes of 50 years, and might build their fiber plants > expecting them to live 20 years or longer. > > > /Bellman > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Sun Feb 10 05:41:29 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Sun, 10 Feb 2019 18:41:29 +1300 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> Message-ID: <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> Certainly the devil is in the details, in New Zealand the access layer (GPON plus local transport) is largely regulated. Then Retail service providers buy the access component wholesale and add layer3, national backhaul etc. Retail for unlimited 1G/500M internet is about $75USD/month, for 100/50 you are looking at about 50USD/month. Key to this was the breakup of the incumbent into an access plus retail provider. This was done by allowing power (lines) companies in a few regions to win the access component contract. From: NANOG On Behalf Of Baldur Norddahl Sent: Sunday, 10 February 2019 6:21 PM To: nanog at nanog.org Subject: Re: Last Mile Design The FTTH rollout in Sweden has resulted in monopoly and the prices are high. Anything will work if you do not need to compete and you are getting financed by someone with money to spend. On 2019-02-09 18:59 CET, Mikael Abrahamsson wrote: --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sun Feb 10 09:09:38 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 10 Feb 2019 11:09:38 +0200 Subject: Last Mile Design In-Reply-To: References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> Message-ID: On 10/Feb/19 07:20, Baldur Norddahl wrote: > The FTTH rollout in Sweden has resulted in monopoly and the prices are > high. The prices are high? I'd like to hear more on your thoughts about this. Mark. From jwbensley at gmail.com Sun Feb 10 09:16:42 2019 From: jwbensley at gmail.com (James Bensley) Date: Sun, 10 Feb 2019 09:16:42 +0000 Subject: [Community bleaching on edge] RTBH no_export In-Reply-To: <002101d4be23$62e821e0$28b865a0$@netconsultings.com> References: <002101d4be23$62e821e0$28b865a0$@netconsultings.com> Message-ID: On Wed, 6 Feb 2019 at 13:55, wrote: > > Hi folks, > > > > This “RTBH no_export” thread made me wonder what is the latest view on BGP community bleaching at the edge (in/out). > > Anyone filtering extended RT communities inbound on NOSes that accept extended communities by default? Yeah about that… Hi Adam, I think Junos is an example of a NOS that advertises extended BGP communities by default (and accepts them without scrubbing). It seems "not ideal" to me (by which I mean there could be potential for BGP NLRIs to be processed in an undesired way). However, I think that ext-comm information sent in NLRI UPDATES over an AFI/SAFI 1/1 or 2/1 session aren't processed. I haven't got the time to lab this right now but, I guess one question would be if (for example) a CPE sends a BGP UPDATE over an 1/1 or 2/1 session into a PE inside a VRF, with ext comm attached, when the UPDATE is advertised to another PE over a 1/128 or 2/128 session will that remote PE process the ext-comm value the CPE sent to the initial PE in the 1/1 or 2/1 session? What if that CPE was in instead a transit or peering partner and you're running an Internet-in-a-VRF design, can anyone on the Internet send routes into your edge PE and, with the correct ext-comm, have them importing into another L3 VPN? Cheers, James. From maxtul at netassist.ua Sun Feb 10 13:23:47 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Feb 2019 15:23:47 +0200 Subject: IPv6 and forensic requests Message-ID: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> Hi All, we are implementing IPv6 only infrastructure. For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. There is a number of ways for Linux based NAT to store information for future forensic requests (i.e. "who was it cracking that website?"). But what about 6to4 translators, as tayga? I believe there should be well-known patches or solutions. The aim is to have what /64 (not even /128) was translated to what IPv4 at the requested time. Is there any? From swmike at swm.pp.se Sun Feb 10 13:27:11 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 10 Feb 2019 14:27:11 +0100 (CET) Subject: Last Mile Design In-Reply-To: <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> References: <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> Message-ID: On Sun, 10 Feb 2019, Tony Wicks wrote: > Certainly the devil is in the details, in New Zealand the access layer > (GPON plus local transport) is largely regulated. Then Retail service > providers buy the access component wholesale and add layer3, national > backhaul etc. Retail for unlimited 1G/500M internet is about > $75USD/month, for 100/50 you are looking at about 50USD/month. Key to > this was the breakup of the incumbent into an access plus retail > provider. This was done by allowing power (lines) companies in a few > regions to win the access component contract. The general going rate for a 250/100 in Sweden is around 35EUR for the kind of service where you can then choose any ISP. Typically the first-mile provider takes the bulk of this money. In the cases where the proprty is on STOKAB fiber footprint (or equivalent) and you have a reasonably large MDU the landlord can contract an ISP to deliver ETTH to all apartments (typically CAT6 from switch in basement) where the going rate per apartment is around 5-15EUR a month for something like 100/100, 1G/100M or 1G/1G. All of this with *PON nowhere to be seen. It's all AE over fiber or CAT5/6/7. -- Mikael Abrahamsson email: swmike at swm.pp.se From jordi.palet at consulintel.es Sun Feb 10 13:51:25 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 10 Feb 2019 14:51:25 +0100 Subject: IPv6 and forensic requests In-Reply-To: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> References: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> Message-ID: <3A60263F-8251-4E15-8162-EB90B9158934@consulintel.es> Do you really mean 6to4 or NAT64? Totally different things ... If that's the case, I will suggest you go for Jool instead of Tayga. Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 14:26 Para: NANOG Asunto: IPv6 and forensic requests Hi All, we are implementing IPv6 only infrastructure. For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. There is a number of ways for Linux based NAT to store information for future forensic requests (i.e. "who was it cracking that website?"). But what about 6to4 translators, as tayga? I believe there should be well-known patches or solutions. The aim is to have what /64 (not even /128) was translated to what IPv4 at the requested time. Is there any? ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From brandon at rd.bbc.co.uk Sun Feb 10 13:52:27 2019 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 10 Feb 2019 13:52:27 +0000 Subject: Last Mile Design In-Reply-To: <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> Message-ID: <20190210135226.GA27256@sunf10.rd.bbc.co.uk> On Sun Feb 10, 2019 at 06:41:29PM +1300, Tony Wicks wrote: > in New Zealand the access layer (GPON plus local transport) > is largely regulated. Then Retail service providers buy the > access component wholesale and add layer3, national backhaul > etc. Retail for unlimited 1G/500M internet is about $75USD/month, > for 100/50 you are looking at about 50USD/month What is the wholesale price? Is the same for everyone? In the UK the line is reasonably priced (wholesale around US$15/month for FTTC, FTTP is rare and $25 to $80/month) but backhaul is a problem as the incumbent charges around $40/ Mb/s /month. You're not going to sell a service with that for a viable price when retail prices are around $20/month for the popular products (40 and 80Mb/s). It skews the market to a hand full of large providers who can afford to build their own backhaul On the FTTH I've been involved in (www.balquhidder.net) I used AE rather than GPON. Positive factors were: Simple, cheaper, CPE not needing replacing each time a new faster wifi standard appears (the service is 1Gb/s). Simpler build with dispersed properties. Preference to maintain a (cheaper) ethernet switch vs propriertary GPON Any business can be given dedicated 1G DIA and can independently upgrade to 10G. With a lot of farms/home working the business/domestic distinction is fluid. Negative: Higher fibre costs but not huge vs GPON kit. A fibre cut results in a lot more fibres to splice increasing time to repair (96c on our trunks, would be 12c with GPON). This is the only major AE issue. brandon From mark.tinka at seacom.mu Sun Feb 10 14:05:17 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 10 Feb 2019 16:05:17 +0200 Subject: Last Mile Design In-Reply-To: References: <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> Message-ID: <0e9a7cb5-7da3-3b83-f182-0ae11d9680bc@seacom.mu> On 10/Feb/19 15:27, Mikael Abrahamsson wrote: >   > The general going rate for a 250/100 in Sweden is around 35EUR for the > kind of service where you can then choose any ISP. Typically the > first-mile provider takes the bulk of this money. > > In the cases where the proprty is on STOKAB fiber footprint (or > equivalent) and you have a reasonably large MDU the landlord can > contract an ISP to deliver ETTH to all apartments (typically CAT6 from > switch in basement) where the going rate per apartment is around > 5-15EUR a month for something like 100/100, 1G/100M or 1G/1G. Which is what I know about having a mate that has a home in Stockholm. So when Baldur mentioned that it was expensive, I was curious to understand if we were talking about the same Sweden. Fair point, my mate is on a Stokab-driven network, but EUR35 for 250Mbps is nothing to laugh at. I'm paying double that for 100Mbps in Johannesburg, on GPON. Mark. From swmike at swm.pp.se Sun Feb 10 14:30:45 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 10 Feb 2019 15:30:45 +0100 (CET) Subject: Last Mile Design In-Reply-To: <0e9a7cb5-7da3-3b83-f182-0ae11d9680bc@seacom.mu> References: <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <0e9a7cb5-7da3-3b83-f182-0ae11d9680bc@seacom.mu> Message-ID: On Sun, 10 Feb 2019, Mark Tinka wrote: > Fair point, my mate is on a Stokab-driven network, but EUR35 for 250Mbps > is nothing to laugh at. I'm paying double that for 100Mbps in > Johannesburg, on GPON. I also have available 250/50 via DOCSIS for approx the same EUR35. Basically access technology (AE/GPON/DOCSIS) doesn't matter a huge part, it's all about market and competition. -- Mikael Abrahamsson email: swmike at swm.pp.se From maxtul at netassist.ua Sun Feb 10 15:28:17 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Feb 2019 17:28:17 +0200 Subject: IPv6 and forensic requests In-Reply-To: <3A60263F-8251-4E15-8162-EB90B9158934@consulintel.es> References: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> <3A60263F-8251-4E15-8162-EB90B9158934@consulintel.es> Message-ID: Hello Jordi, thank you, I will take a look on Jool! Exactly CLAT was the issue. First, I thought to provide a /128 to every mobile, and then do a static 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses a lot of random IPv6 inside assigned /64, several addresses together at each time, CLAT uses the most of it (on Android). So direct translation 6->public4 is impossible. 10.02.19 15:51, JORDI PALET MARTINEZ пише: > Do you really mean 6to4 or NAT64? Totally different things ... > > If that's the case, I will suggest you go for Jool instead of Tayga. > > Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Max Tulyev > Fecha: domingo, 10 de febrero de 2019, 14:26 > Para: NANOG > Asunto: IPv6 and forensic requests > > Hi All, > > we are implementing IPv6 only infrastructure. > > For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. > > There is a number of ways for Linux based NAT to store information for > future forensic requests (i.e. "who was it cracking that website?"). > > But what about 6to4 translators, as tayga? I believe there should be > well-known patches or solutions. The aim is to have what /64 (not even > /128) was translated to what IPv4 at the requested time. > > Is there any? > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > From baldur.norddahl at gmail.com Sun Feb 10 15:46:42 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 10 Feb 2019 16:46:42 +0100 Subject: Last Mile Design In-Reply-To: References: <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> Message-ID: <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> Hello There are of course regions where monopoly has created even higher prices. But it should be fair to compare the Skåne region of Sweden directly with the greater Copenhagen area of Denmark, as those are separated by just a bridge. In Denmark the government choose to regulate access to the fiber infrastructure owned by the incumbent operator TDC. The cheapest access is to "raw fiber" meaning the "alternate operator" gets access to an uninterrupted stretch of fiber between a POP and the end user. We can then connect our own equipment in both ends. My company started out by doing exactly that. We were the first to implement GPON technology on the TDC owned fiber. TDC was at the time using active ethernet, but have since started migrating everything to GPON as well. Maybe they got inspired. The regulated prices are found here: https://erhvervsstyrelsen.dk/sites/default/files/media/endelig_prisafgoerelse_lraic_fastnet_2019.pdf Sorry, that document is in danish. Maybe the swedish guys can understand some of it. There are multiple prices, but the price we pay for most of our users is (1584-577)/12 = DKK 83.92 / month (USD 12.76 / EUR 11.24). As you get access to the fiber itself, nobody will care what speeds or even what technology you use on that fiber. It is also possible to rent access to so called "bit stream access". In this case TDC will provide a VPN connection to the end user and the operator will just have to provide the IP service. To compare with that 250 Mbit/s swedish offering, we can lookup the price for 250 Mbit/s BSA service in the DONG area (this means mostly anything near Copenhagen): (2170-625.7)/12 = DKK 128.69 / month (USD 19.56 / EUR 17.24). How much do you really need to add on top of that, if all you need to do is buy that $0.12/Mbps transit from HE.net and let TDC take care of everything else? In any case, we are now building out our own fiber to cover the gaps left by TDC. Here the end user has to pay DKK 12,000 (USD 1,824 / EUR 1,608) one time fee and with that he gets everything including 5 years of free internet. This works out at DKK 200 / month including 25% VAT tax (USD 30 / EUR 27). I guarantee that it is not possible to build at this price without using PON technology. The network is fully funded by the users themselves and we have a paid off network after just 5 years. Regards, Baldur From cb.list6 at gmail.com Sun Feb 10 16:06:29 2019 From: cb.list6 at gmail.com (Ca By) Date: Sun, 10 Feb 2019 08:06:29 -0800 Subject: IPv6 and forensic requests In-Reply-To: References: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> <3A60263F-8251-4E15-8162-EB90B9158934@consulintel.es> Message-ID: You want this to log the bindings through the nat64 https://www.jool.mx/en/usr-flags-global.html#logging-bib Then you cross reference that with the /64 that is assigned to the UE in the CDR When doing lookups of this data, only look at the first 64 bits. That is all that matters and is unique to the UE. The last 64 bits in mobile is just noise from a Lawful Intercept and logging perspective. On Sun, Feb 10, 2019 at 7:29 AM Max Tulyev wrote: > Hello Jordi, > > thank you, I will take a look on > Exactly CLAT was the issue. > > First, I thought to provide a /128 to every mobile, and then do a static > 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses > a lot of random IPv6 inside assigned /64, several addresses together at > each time, CLAT uses the most of it (on Android). So direct translation > 6->public4 is impossible. > > 10.02.19 15:51, JORDI PALET MARTINEZ пише: > > Do you really mean 6to4 or NAT64? Totally different things ... > > > > If that's the case, I will suggest you go for Jool instead of Tayga. > > > > Also, if you want the customers are able to use old IPv4 apps and > devices, NAT64 is not sufficient, you need also CLAT at the customer > premises (so they can run 464XLAT). > > > > Regards, > > Jordi > > > > > > > > -----Mensaje original----- > > De: NANOG en nombre de Max Tulyev < > maxtul at netassist.ua> > > Fecha: domingo, 10 de febrero de 2019, 14:26 > > Para: NANOG > > Asunto: IPv6 and forensic requests > > > > Hi All, > > > > we are implementing IPv6 only infrastructure. > > > > For IPv4 access, we using tayga for 6to4 translation and then CGN > for NAT. > > > > There is a number of ways for Linux based NAT to store information > for > > future forensic requests (i.e. "who was it cracking that website?"). > > > > But what about 6to4 translators, as tayga? I believe there should be > > well-known patches or solutions. The aim is to have what /64 (not > even > > /128) was translated to what IPv4 at the requested time. > > > > Is there any? > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sun Feb 10 18:06:35 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 10 Feb 2019 19:06:35 +0100 Subject: IPv6 and forensic requests In-Reply-To: References: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> <3A60263F-8251-4E15-8162-EB90B9158934@consulintel.es> Message-ID: <1E97FB4E-2BE2-4C3E-8AB0-1CDE4E00AC97@consulintel.es> Well, if it is mobile, then definitively you should use /64 for every PDP context, and clearly is NAT64. In this case, you don't need to take care about the CLAT part, just look at the /64 prefix for the logging. Make sure to talk about stateful NAT64 ... otherwise you create lot of confusion. You've some deployment hints at https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC meeting, etc., there are even videos of them). Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 16:30 CC: NANOG Asunto: Re: IPv6 and forensic requests Hello Jordi, thank you, I will take a look on Jool! Exactly CLAT was the issue. First, I thought to provide a /128 to every mobile, and then do a static 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses a lot of random IPv6 inside assigned /64, several addresses together at each time, CLAT uses the most of it (on Android). So direct translation 6->public4 is impossible. 10.02.19 15:51, JORDI PALET MARTINEZ пише: > Do you really mean 6to4 or NAT64? Totally different things ... > > If that's the case, I will suggest you go for Jool instead of Tayga. > > Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Max Tulyev > Fecha: domingo, 10 de febrero de 2019, 14:26 > Para: NANOG > Asunto: IPv6 and forensic requests > > Hi All, > > we are implementing IPv6 only infrastructure. > > For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. > > There is a number of ways for Linux based NAT to store information for > future forensic requests (i.e. "who was it cracking that website?"). > > But what about 6to4 translators, as tayga? I believe there should be > well-known patches or solutions. The aim is to have what /64 (not even > /128) was translated to what IPv4 at the requested time. > > Is there any? > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From maxtul at netassist.ua Sun Feb 10 18:16:36 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 10 Feb 2019 20:16:36 +0200 Subject: IPv6 and forensic requests In-Reply-To: <1E97FB4E-2BE2-4C3E-8AB0-1CDE4E00AC97@consulintel.es> References: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> <3A60263F-8251-4E15-8162-EB90B9158934@consulintel.es> <1E97FB4E-2BE2-4C3E-8AB0-1CDE4E00AC97@consulintel.es> Message-ID: <334cd9ef-81b8-b438-ee81-86466bcc6ff6@netassist.ua> Great, thank you! Did you manage to whitelist APN at Apple so iOS devices can use it too? 10.02.19 20:06, JORDI PALET MARTINEZ пише: > Well, if it is mobile, then definitively you should use /64 for every PDP context, and clearly is NAT64. > > In this case, you don't need to take care about the CLAT part, just look at the /64 prefix for the logging. > > Make sure to talk about stateful NAT64 ... otherwise you create lot of confusion. > > You've some deployment hints at > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ > > Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC meeting, etc., there are even videos of them). > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Max Tulyev > Fecha: domingo, 10 de febrero de 2019, 16:30 > CC: NANOG > Asunto: Re: IPv6 and forensic requests > > Hello Jordi, > > thank you, I will take a look on Jool! > > Exactly CLAT was the issue. > > First, I thought to provide a /128 to every mobile, and then do a static > 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses > a lot of random IPv6 inside assigned /64, several addresses together at > each time, CLAT uses the most of it (on Android). So direct translation > 6->public4 is impossible. > > 10.02.19 15:51, JORDI PALET MARTINEZ пише: > > Do you really mean 6to4 or NAT64? Totally different things ... > > > > If that's the case, I will suggest you go for Jool instead of Tayga. > > > > Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). > > > > Regards, > > Jordi > > > > > > > > -----Mensaje original----- > > De: NANOG en nombre de Max Tulyev > > Fecha: domingo, 10 de febrero de 2019, 14:26 > > Para: NANOG > > Asunto: IPv6 and forensic requests > > > > Hi All, > > > > we are implementing IPv6 only infrastructure. > > > > For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. > > > > There is a number of ways for Linux based NAT to store information for > > future forensic requests (i.e. "who was it cracking that website?"). > > > > But what about 6to4 translators, as tayga? I believe there should be > > well-known patches or solutions. The aim is to have what /64 (not even > > /128) was translated to what IPv4 at the requested time. > > > > Is there any? > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > From jordi.palet at consulintel.es Sun Feb 10 18:48:42 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 10 Feb 2019 19:48:42 +0100 Subject: IPv6 and forensic requests In-Reply-To: <334cd9ef-81b8-b438-ee81-86466bcc6ff6@netassist.ua> References: <773cb7e6-f83d-197b-03e0-83261a700a83@netassist.ua> <3A60263F-8251-4E15-8162-EB90B9158934@consulintel.es> <1E97FB4E-2BE2-4C3E-8AB0-1CDE4E00AC97@consulintel.es> <334cd9ef-81b8-b438-ee81-86466bcc6ff6@netassist.ua> Message-ID: <00EF8793-3746-4D62-96F3-7C0F6F733638@consulintel.es> Apple doesn't use CLAT, because apps should support IPv6-only since a couple of year ago. If they don't something "close" to a CLAT is done by RFC8305. If is doing tethering, then the CLAT is done towards the tethered devices. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 19:21 Para: NANOG Asunto: Re: IPv6 and forensic requests Great, thank you! Did you manage to whitelist APN at Apple so iOS devices can use it too? 10.02.19 20:06, JORDI PALET MARTINEZ пише: > Well, if it is mobile, then definitively you should use /64 for every PDP context, and clearly is NAT64. > > In this case, you don't need to take care about the CLAT part, just look at the /64 prefix for the logging. > > Make sure to talk about stateful NAT64 ... otherwise you create lot of confusion. > > You've some deployment hints at > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ > > Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC meeting, etc., there are even videos of them). > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Max Tulyev > Fecha: domingo, 10 de febrero de 2019, 16:30 > CC: NANOG > Asunto: Re: IPv6 and forensic requests > > Hello Jordi, > > thank you, I will take a look on Jool! > > Exactly CLAT was the issue. > > First, I thought to provide a /128 to every mobile, and then do a static > 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses > a lot of random IPv6 inside assigned /64, several addresses together at > each time, CLAT uses the most of it (on Android). So direct translation > 6->public4 is impossible. > > 10.02.19 15:51, JORDI PALET MARTINEZ пише: > > Do you really mean 6to4 or NAT64? Totally different things ... > > > > If that's the case, I will suggest you go for Jool instead of Tayga. > > > > Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). > > > > Regards, > > Jordi > > > > > > > > -----Mensaje original----- > > De: NANOG en nombre de Max Tulyev > > Fecha: domingo, 10 de febrero de 2019, 14:26 > > Para: NANOG > > Asunto: IPv6 and forensic requests > > > > Hi All, > > > > we are implementing IPv6 only infrastructure. > > > > For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. > > > > There is a number of ways for Linux based NAT to store information for > > future forensic requests (i.e. "who was it cracking that website?"). > > > > But what about 6to4 translators, as tayga? I believe there should be > > well-known patches or solutions. The aim is to have what /64 (not even > > /128) was translated to what IPv4 at the requested time. > > > > Is there any? > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mark.tinka at seacom.mu Mon Feb 11 03:50:15 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 11 Feb 2019 05:50:15 +0200 Subject: Last Mile Design In-Reply-To: References: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <0e9a7cb5-7da3-3b83-f182-0ae11d9680bc@seacom.mu> Message-ID: <5133d459-6c05-01cd-6a4b-02ae8c9ccf11@seacom.mu> On 10/Feb/19 16:30, Mikael Abrahamsson wrote:   > > I also have available 250/50 via DOCSIS for approx the same EUR35. > > Basically access technology (AE/GPON/DOCSIS) doesn't matter a huge > part, it's all about market and competition. In essence, agreed. For the most part, my 100Mbps does the job, despite it being "a bit too priced". It could have been worse, but as things go in Africa at the moment in this space, what I am paying for 100Mbps FTTH is actually very reasonable. The only reason for considering anything faster is when I upgrade my standard HD TV to 4K/UHD, and then I can upgrade my Netflix subscription to match :-). But for the current use-case (a small LAN, family Internet access, VoD streaming, a VoIP "land" line and my home office), I can't really complain. I wouldn't know what to do with a Gig, but at least my provider can get me there, should that day come. Mark. From mark.tinka at seacom.mu Mon Feb 11 03:57:20 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 11 Feb 2019 05:57:20 +0200 Subject: Last Mile Design In-Reply-To: <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> References: <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> Message-ID: <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> On 10/Feb/19 17:46, Baldur Norddahl wrote:   > > As you get access to the fiber itself, nobody will care what speeds or > even what technology you use on that fiber. This has always been the end-goal: * How many IPTV channels do I get; not how much bandwidth do they require? * How many annual free Voice minutes do they get; not how many concurrent calls can I fit into 128Kbps? * Is Netflix 4K streaming included; not how much bandwidth do I have for streaming? * e.t.c. > > In any case, we are now building out our own fiber to cover the gaps > left by TDC. Here the end user has to pay DKK 12,000 (USD 1,824 / EUR > 1,608) one time fee and with that he gets everything including 5 years > of free internet. This works out at DKK 200 / month including 25% VAT > tax (USD 30 / EUR 27). Very interesting - don't you feel that an initial outlay like that could put some potential customers off? Then again, per capita income in Denmark, I'd imagine, could allow most to think about this. If all that buys me Internet access for 5 years before I have to shell out anymore wedge, I'd do it. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bellman at nsc.liu.se Mon Feb 11 09:31:13 2019 From: bellman at nsc.liu.se (Thomas Bellman) Date: Mon, 11 Feb 2019 10:31:13 +0100 Subject: Last Mile Design In-Reply-To: <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> References: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> Message-ID: On 2019-02-11 04:57 CET, Mark Tinka wrote: > On 10/Feb/19 17:46, Baldur Norddahl wrote: [...] >> In any case, we are now building out our own fiber to cover the gaps >> left by TDC. Here the end user has to pay DKK 12,000 (USD 1,824 / EUR >> 1,608) one time fee and with that he gets everything including 5 years >> of free internet. This works out at DKK 200 / month including 25% VAT >> tax (USD 30 / EUR 27). > Very interesting - don't you feel that an initial outlay like that could > put some potential customers off? Then again, per capita income in > Denmark, I'd imagine, could allow most to think about this. If all that > buys me Internet access for 5 years before I have to shell out anymore > wedge, I'd do it. I assume this is targeted towards single-family detached houses, where the family owns the house themselves. Then they likely will view that as an investment in the house. If you want to sell your house a couple of years later, and it doesn't have a fiber connection, buyers will be less attracted to the house, and want to pay less. It might also be more expensive to connect after the initial buildout of an area. I believe that's how the commercial companies in Sweden that build FTTH work. I can also note that where I live (Linköping, Sweden), the municipal fiber company charges ~2400 EUR to connect a single-family home to their network. That does *not* include the laying of fiber on your property, from the street to your house. And on top of that, you need to buy Internet connectivity from a normal commercial ISP at a monthly cost; the municipal fiber company only provides layer 2 connectivity between the home and the ISPs (currently 19 different ISPs). /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From mark.tinka at seacom.mu Mon Feb 11 10:23:30 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 11 Feb 2019 12:23:30 +0200 Subject: Last Mile Design In-Reply-To: References: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> Message-ID: <4896bd53-27ad-5815-2b3c-197aa5c8f3d9@seacom.mu> On 11/Feb/19 11:31, Thomas Bellman wrote: > I assume this is targeted towards single-family detached houses, where > the family owns the house themselves. Then they likely will view that > as an investment in the house. If you want to sell your house a couple > of years later, and it doesn't have a fiber connection, buyers will be > less attracted to the house, and want to pay less. Makes sense. > It might also be more expensive to connect after the initial buildout > of an area. I believe that's how the commercial companies in Sweden > that build FTTH work. Cities also aren't keen on opening up streets again, e.t.c. > > I can also note that where I live (Linköping, Sweden), the municipal > fiber company charges ~2400 EUR to connect a single-family home to their > network. That does *not* include the laying of fiber on your property, > from the street to your house. And on top of that, you need to buy > Internet connectivity from a normal commercial ISP at a monthly cost; > the municipal fiber company only provides layer 2 connectivity between > the home and the ISPs (currently 19 different ISPs). Having an option, even though it could be pricey, is better than not having anything at all. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From swmike at swm.pp.se Mon Feb 11 10:49:10 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 Feb 2019 11:49:10 +0100 (CET) Subject: Last Mile Design In-Reply-To: <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> References: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> Message-ID: On Mon, 11 Feb 2019, Mark Tinka wrote: >> In any case, we are now building out our own fiber to cover the gaps >> left by TDC. Here the end user has to pay DKK 12,000 (USD 1,824 / EUR >> 1,608) one time fee and with that he gets everything including 5 years >> of free internet. This works out at DKK 200 / month including 25% VAT >> tax (USD 30 / EUR 27). > > Very interesting - don't you feel that an initial outlay like that could > put some potential customers off? Then again, per capita income in > Denmark, I'd imagine, could allow most to think about this. If all that > buys me Internet access for 5 years before I have to shell out anymore > wedge, I'd do it. In Sweden it's very common that people who live in detached house areas have to pay 1500-3000EUR to get attached to the fiber network as it's being built out. There are even bank loans you can get to pay for this, and pay it off over time. It's considered to be a good deal because it improves the value of the house as well as a huge improvement over having satellite-dish/terrestrial TV and ADSL/LTE for Internet access, now instead you can pay 30-40EUR a month to get a everything over the fiber. Now, I like the LLUB model where ISPs get access to the dark fiber all the way to the customer, and we do have that here as well, just not as commonly as I'd like. That's where https://www.bahnhof.se/villafiber/ comes from where they offer 10GE for 50EUR a month. This is done on Telia LLUB:ed dark fiber which costs around 15EUR a month (regulated price). It's a great PR case for "dark fiber access rocks and bitstream sucks". You get IPv6 in there as well, which isn't commonly available on most of the bitstream access services (because not only do we not do PON, we don't do PPPoE either here in Sweden). So it's a mixed bag and pricing and functionality could definitely be better, but the FTTH rollout has gone quite well here and it's as usual 10-15 different factors contributing but the willingness of the population who lives in houses to fork out 1500-3000EUR for fiber install has made this a lot less cash flow misery for the ISPs that roll this out. I just wish there would have been a requirement for everybody to actually rent this dark fiber out (which there isn't unless you're one of the biggest players) because after paying those 1500-3000EUR and you ask the fiber installation company "who owns this fiber?" they say "we do" and if you ask "ok, I'd like it connected to someone else" they will say "huh? what do you mean". There is an unfortunate common conflation between the fiber optic cable and the services offered on it. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Mon Feb 11 13:46:53 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 11 Feb 2019 15:46:53 +0200 Subject: Last Mile Design In-Reply-To: References: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> Message-ID: <7337aeae-ff22-10e2-ec53-ec98768011a6@seacom.mu> On 11/Feb/19 12:49, Mikael Abrahamsson wrote:   > > In Sweden it's very common that people who live in detached house > areas have to pay 1500-3000EUR to get attached to the fiber network as > it's being built out. There are even bank loans you can get to pay for > this, and pay it off over time. It's considered to be a good deal > because it improves the value of the house as well as a huge > improvement over having satellite-dish/terrestrial TV and ADSL/LTE for > Internet access, now instead you can pay 30-40EUR a month to get a > everything over the fiber. Yes, makes sense, especially if you can get support to fund it. > > Now, I like the LLUB model where ISPs get access to the dark fiber all > the way to the customer, and we do have that here as well, just not as > commonly as I'd like. That's where https://www.bahnhof.se/villafiber/ > comes from where they offer 10GE for 50EUR a month. This is done on > Telia LLUB:ed dark fiber which costs around 15EUR a month (regulated > price). It's a great PR case for "dark fiber access rocks and > bitstream sucks". You get IPv6 in there as well, which isn't commonly > available on most of the bitstream access services (because not only > do we not do PON, we don't do PPPoE either here in Sweden). Cut the price of wine and meat and I'll move to this PPPoE-free land :-). > > So it's a mixed bag and pricing and functionality could definitely be > better, but the FTTH rollout has gone quite well here and it's as > usual 10-15 different factors contributing but the willingness of the > population who lives in houses to fork out 1500-3000EUR for fiber > install has made this a lot less cash flow misery for the ISPs that > roll this out. I just wish there would have been a requirement for > everybody to actually rent this dark fiber out (which there isn't > unless you're one of the biggest players) because after paying those > 1500-3000EUR and you ask the fiber installation company "who owns this > fiber?" they say "we do" and if you ask "ok, I'd like it connected to > someone else" they will say "huh? what do you mean". There is an > unfortunate common conflation between the fiber optic cable and the > services offered on it. I get what you're saying, but sadly, someone has to take the risk to build out a network. Unless you are a large incumbent like Telia, chances are it will be company whose sole focus is just fibre network construction, and anything higher up in the layers is of no interest to them. Mark. From swmike at swm.pp.se Mon Feb 11 13:55:48 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 Feb 2019 14:55:48 +0100 (CET) Subject: Last Mile Design In-Reply-To: <7337aeae-ff22-10e2-ec53-ec98768011a6@seacom.mu> References: <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> <7337aeae-ff22-10e2-ec53-ec98768011a6@seacom.mu> Message-ID: On Mon, 11 Feb 2019, Mark Tinka wrote: >> someone else" they will say "huh? what do you mean". There is an >> unfortunate common conflation between the fiber optic cable and the >> services offered on it. > > I get what you're saying, but sadly, someone has to take the risk to > build out a network. Unless you are a large incumbent like Telia, > chances are it will be company whose sole focus is just fibre network > construction, and anything higher up in the layers is of no interest to > them. The problem here is that it might be an energy company or someone who isn't really into datacom. Now they're going to have to operate an active network to provide this "bitstream access" with DHCP relays, BCP38 support and all that comes with it. The result is that right now, most of these networks do not support IPv6 and they do not support > 1 gigabit/s speed (some don't even support more than 100-500 either). If they had just stayed at the L1 level and provided dark fiber for the amount of money mentioned before (for instance 10-15 EUR a month) then a lot of the problems wouldn't be there. They could have used the same organisation as before that now could do fiber as well, and that's that. Simple product, can't go wrong in a lot of weird ways. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Mon Feb 11 14:01:08 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 11 Feb 2019 16:01:08 +0200 Subject: Last Mile Design In-Reply-To: References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> <7337aeae-ff22-10e2-ec53-ec98768011a6@seacom.mu> Message-ID: <2bb3b4b0-c295-6bc9-6bac-341717e585cc@seacom.mu> On 11/Feb/19 15:55, Mikael Abrahamsson wrote: >   > > If they had just stayed at the L1 level and provided dark fiber for > the amount of money mentioned before (for instance 10-15 EUR a month) > then a lot of the problems wouldn't be there. They could have used the > same organisation as before that now could do fiber as well, and > that's that. Simple product, can't go wrong in a lot of weird ways. We have the same problem here in Africa too (and I saw it in Asia-Pac while I was there as well)... non-telco-centric companies that deployed fibre to manage their non-telco infrastructure, now entering the telco space to make use of the excess capacity, or because they want to be part of the "next digital wave", with zero operational experience, and a single-mindedness about one thing - "We will never sell dark fibre to anyone". Ultimately, they wise up or get bought by an operator. It's just a question of how much patience you've got to spend. Mark. From swmike at swm.pp.se Mon Feb 11 14:21:44 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 Feb 2019 15:21:44 +0100 (CET) Subject: Last Mile Design In-Reply-To: <2bb3b4b0-c295-6bc9-6bac-341717e585cc@seacom.mu> References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> <7337aeae-ff22-10e2-ec53-ec98768011a6@seacom.mu> <2bb3b4b0-c295-6bc9-6bac-341717e585cc@seacom.mu> Message-ID: On Mon, 11 Feb 2019, Mark Tinka wrote: > We have the same problem here in Africa too (and I saw it in Asia-Pac > while I was there as well)... non-telco-centric companies that deployed Speaking of an Asia-Pac example, Thailand, the government owned telco. https://www.tot.co.th/%E0%B8%9A%E0%B8%A3%E0%B8%B4%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%AD%E0%B8%B4%E0%B8%99%E0%B9%80%E0%B8%97%E0%B8%AD%E0%B8%A3%E0%B9%8C%E0%B9%80%E0%B8%99%E0%B9%87%E0%B8%95/tot-fiber-2u Typically there are 1-3 different FTTH providers if you live in something that resembles a town, pay 50-100EUR installation fee, they show up within days to pull your new fiber and now you can have 150/50 for around 20EUR a month. The price level has remained the same the past 5-6 years, but speed has gone up from 10/3 to 150/50 for the same monthly payment. Last year the 150/50 price level offering was 100/20 instead. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark.tinka at seacom.mu Mon Feb 11 14:30:35 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 11 Feb 2019 16:30:35 +0200 Subject: Last Mile Design In-Reply-To: References: <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> <7337aeae-ff22-10e2-ec53-ec98768011a6@seacom.mu> <2bb3b4b0-c295-6bc9-6bac-341717e585cc@seacom.mu> Message-ID: <4c3fe890-24a9-e502-7a67-a89083ce4ae7@seacom.mu> On 11/Feb/19 16:21, Mikael Abrahamsson wrote:   > > Speaking of an Asia-Pac example, Thailand, the government owned telco. > > https://www.tot.co.th/%E0%B8%9A%E0%B8%A3%E0%B8%B4%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%AD%E0%B8%B4%E0%B8%99%E0%B9%80%E0%B8%97%E0%B8%AD%E0%B8%A3%E0%B9%8C%E0%B9%80%E0%B8%99%E0%B9%87%E0%B8%95/tot-fiber-2u > > > Typically there are 1-3 different FTTH providers if you live in > something that resembles a town, pay 50-100EUR installation fee, they > show up within days to pull your new fiber and now you can have 150/50 > for around 20EUR a month. > > The price level has remained the same the past 5-6 years, but speed > has gone up from 10/3 to 150/50 for the same monthly payment. Last > year the 150/50 price level offering was 100/20 instead. I can attest to this as I saw exactly the same thing in Malaysia, and more so after I've been away these past couple of years. The company I worked for at the time started rolling our GPON with the top speed at 50Mbps for several hundred RM/month back in 2010. 9 years later, they are selling 1Gbps @ RM99/month. I suppose we can choke it down to the cost of living in the North Western hemisphere being what it is, or some such reason :-). Mark. From jayb at braeburn.org Mon Feb 11 14:53:45 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Mon, 11 Feb 2019 09:53:45 -0500 Subject: AT&T/as7018 now drops invalid prefixes from peers Message-ID: <23649.35961.352370.101277@oz.mt.att.com> FYI: The AT&T/as7018 network is now dropping all RPKI-invalid route announcements that we receive from our peers. We continue to accept invalid route announcements from our customers, at least for now. We are communicating with our customers whose invalid announcements we are propagating, informing them that these routes will be accepted by fewer and fewer networks over time. Thanks to those of you who are publishing ROAs in the RPKI. We would also like to encourage other networks to join us in taking this step to improve the quality of routing information in the Internet. Thanks! Jay B. From cb.list6 at gmail.com Mon Feb 11 14:58:22 2019 From: cb.list6 at gmail.com (Ca By) Date: Mon, 11 Feb 2019 06:58:22 -0800 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: On Mon, Feb 11, 2019 at 6:55 AM Jay Borkenhagen wrote: > > FYI: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. > > We continue to accept invalid route announcements from our customers, > at least for now. We are communicating with our customers whose > invalid announcements we are propagating, informing them that these > routes will be accepted by fewer and fewer networks over time. > > Thanks to those of you who are publishing ROAs in the RPKI. We would > also like to encourage other networks to join us in taking this step > to improve the quality of routing information in the Internet. > > Thanks! > > Jay B. > > > Good move AT&T , thanks for taking this on > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Mon Feb 11 15:03:26 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Mon, 11 Feb 2019 15:03:26 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: A round of applause to AT&T for leading the way! Best regards, Martijn On 2/11/19 3:53 PM, Jay Borkenhagen wrote: > FYI: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. > > We continue to accept invalid route announcements from our customers, > at least for now. We are communicating with our customers whose > invalid announcements we are propagating, informing them that these > routes will be accepted by fewer and fewer networks over time. > > Thanks to those of you who are publishing ROAs in the RPKI. We would > also like to encourage other networks to join us in taking this step > to improve the quality of routing information in the Internet. > > Thanks! > > Jay B. > > > From job at ntt.net Mon Feb 11 15:08:25 2019 From: job at ntt.net (Job Snijders) Date: Mon, 11 Feb 2019 16:08:25 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: <20190211150825.GE2715@hanna.meerval.net> Dear Jay, AT&T, On Mon, Feb 11, 2019 at 09:53:45AM -0500, Jay Borkenhagen wrote: > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. Thanks for filtering us! :-) AT&T doing origin validation combined with the peerlock-style AS_PATH filters this makes for a pretty strongly protected path between you and others. > We continue to accept invalid route announcements from our customers, > at least for now. We are communicating with our customers whose > invalid announcements we are propagating, informing them that these > routes will be accepted by fewer and fewer networks over time. I think this is a sensible strategy. > Thanks to those of you who are publishing ROAs in the RPKI. We would > also like to encourage other networks to join us in taking this step > to improve the quality of routing information in the Internet. Thank you for paving the way! If you can share more about the experience in terms of load on the support tiers in your organisation, or questions from peering partners, that could perhaps be helpful information for others in their preparations. Kind regards, Job From patrick at ianai.net Mon Feb 11 15:36:19 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 Feb 2019 10:36:19 -0500 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: Jay & everyone AT&T: I just want to say thank you. Kudos to your team for implementing and management for having the intestinal fortitude to do so. -- TTFN, patrick > On Feb 11, 2019, at 09:53, Jay Borkenhagen wrote: > > > FYI: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. > > We continue to accept invalid route announcements from our customers, > at least for now. We are communicating with our customers whose > invalid announcements we are propagating, informing them that these > routes will be accepted by fewer and fewer networks over time. > > Thanks to those of you who are publishing ROAs in the RPKI. We would > also like to encourage other networks to join us in taking this step > to improve the quality of routing information in the Internet. > > Thanks! > > Jay B. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rich.Compton at charter.com Mon Feb 11 16:47:41 2019 From: Rich.Compton at charter.com (Compton, Rich A) Date: Mon, 11 Feb 2019 16:47:41 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: <20BBDC85-DFBF-4677-A347-07EC1927053A@charter.com> That's great! Do you guys have plans to publish ROAs for your own netblocks? If so, can you please share info on your process (tools, pitfalls, etc.)? Thanks! On 2/11/19, 7:55 AM, "NANOG on behalf of Jay Borkenhagen" wrote: FYI: The AT&T/as7018 network is now dropping all RPKI-invalid route announcements that we receive from our peers. We continue to accept invalid route announcements from our customers, at least for now. We are communicating with our customers whose invalid announcements we are propagating, informing them that these routes will be accepted by fewer and fewer networks over time. Thanks to those of you who are publishing ROAs in the RPKI. We would also like to encourage other networks to join us in taking this step to improve the quality of routing information in the Internet. Thanks! Jay B. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From melchior at aelmans.eu Mon Feb 11 18:13:09 2019 From: melchior at aelmans.eu (Melchior Aelmans) Date: Mon, 11 Feb 2019 19:13:09 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: This is the best news today! Great job!! Cheers, Melchior On Mon, Feb 11, 2019 at 3:56 PM Jay Borkenhagen wrote: > > FYI: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. > > We continue to accept invalid route announcements from our customers, > at least for now. We are communicating with our customers whose > invalid announcements we are propagating, informing them that these > routes will be accepted by fewer and fewer networks over time. > > Thanks to those of you who are publishing ROAs in the RPKI. We would > also like to encourage other networks to join us in taking this step > to improve the quality of routing information in the Internet. > > Thanks! > > Jay B. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon Feb 11 23:09:20 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 11 Feb 2019 18:09:20 -0500 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: <5704.1549926560@turing-police.cc.vt.edu> On Mon, 11 Feb 2019 09:53:45 -0500, Jay Borkenhagen said: > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. Congrats! Are you able to comment on what amount of routes are getting dropped? From jayb at braeburn.org Tue Feb 12 00:01:46 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Mon, 11 Feb 2019 19:01:46 -0500 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <20BBDC85-DFBF-4677-A347-07EC1927053A@charter.com> References: <23649.35961.352370.101277@oz.mt.att.com> <20BBDC85-DFBF-4677-A347-07EC1927053A@charter.com> Message-ID: <23650.3306.926729.428632@oz.mt.att.com> Compton, Rich A writes: > That's great! Do you guys have plans to publish ROAs for your own netblocks? If so, can you please share info on your process (tools, pitfalls, etc.)? Thanks! > Hi Rich, We do have ROAs published for a not insignificant fraction of our address space. For example (and cherry-picking the representation most favorable to us) we're listed at #6 in the "25 Autonomous Systems with the most Address Space VALID by RPKI" at this NIST RPKI tracker: https://rpki-monitor.antd.nist.gov/#rpki_adopters We will publish more ROAs over time. Thusfar we have been utilizing ARIN's hosted model, but down the road ARIN's delegated model will be in our future. https://www.arin.net/resources/rpki/using_rpki.html Thanks. Jay B. From jayb at braeburn.org Tue Feb 12 00:14:26 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Mon, 11 Feb 2019 19:14:26 -0500 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <5704.1549926560@turing-police.cc.vt.edu> References: <23649.35961.352370.101277@oz.mt.att.com> <5704.1549926560@turing-police.cc.vt.edu> Message-ID: <23650.4066.729939.143220@oz.mt.att.com> valdis.kletnieks at vt.edu writes: > On Mon, 11 Feb 2019 09:53:45 -0500, Jay Borkenhagen said: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > > announcements that we receive from our peers. > > Congrats! Thanks! > Are you able to comment on what amount of routes are getting dropped? In round numbers, we dropped about 5000 invalid prefixes total between ipv4 and ipv6. Roughly half of those prefixes were covered by less-specific non-invalid routes, so connectivity should not have been affected for those prefixes (assuming an announcement yields reachability to all destinations within it). Flow analysis was showing just a couple Gbps of traffic to all invalid routes all across the country, and much less than that with those invalids having no covering less-specifics. Jay B. From jayb at braeburn.org Tue Feb 12 00:52:46 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Mon, 11 Feb 2019 19:52:46 -0500 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <20190211150825.GE2715@hanna.meerval.net> References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> Message-ID: <23650.6366.573248.750616@oz.mt.att.com> Job Snijders writes: > Dear Jay, AT&T, > > On Mon, Feb 11, 2019 at 09:53:45AM -0500, Jay Borkenhagen wrote: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > > announcements that we receive from our peers. > > Thanks for filtering us! :-) Any time! :-) > If you can share more about the experience in terms of load on the > support tiers in your organisation, or questions from peering partners, > that could perhaps be helpful information for others in their > preparations. > A few reports of resulting connectivity loss have come in through various channels: on Jared's outages mailing list, on IRC, through our customer care ticket system, etc. Thusfar I have been very pleased with the reactions folks have had when we described how our policy change caused us to lose their affected route announcement. Everyone so far has understood the purpose of the RPKI, they understood why the affected route announcements were deemed invalid and thus were dropped, and best of all -- they understood what they needed to do to fix things. We got some very good advice watching this video from your most recent NLNOG day: https://www.youtube.com/watch?v=vrzl__yGqLE ... but there is one place where I disagree with Niels. He advised against lowering the local-pref of invalid routes. I agree that this should not be anyone's target policy, but it is a useful step along the way. To set invalid routes a lower local-pref, one needs to establish RTR sessions from routers to relying party servers, and to configure a policy that takes validation state into account. The policy here can also set community based on the validation state, which can help with flow-based traffic analysis. Then, when you are comfortable operating RPs that talk RTR to your routers and you're ready to implement a meaningful policy, it's a simple matter of changing from: if validation-state = invalid then local-pref = $LOWER community = foo fi to: if validation-state = invalid then drop fi In short: C'mon in! The water's fine! :-) Thanks. Jay B. From mark.tinka at seacom.mu Tue Feb 12 04:30:06 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 12 Feb 2019 06:30:06 +0200 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23649.35961.352370.101277@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> Message-ID: <9bf6fe0b-33fb-fc8e-dc74-43bdf6e4c9e2@seacom.mu> On 11/Feb/19 16:53, Jay Borkenhagen wrote: > FYI: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. > > We continue to accept invalid route announcements from our customers, > at least for now. We are communicating with our customers whose > invalid announcements we are propagating, informing them that these > routes will be accepted by fewer and fewer networks over time. > > Thanks to those of you who are publishing ROAs in the RPKI. We would > also like to encourage other networks to join us in taking this step > to improve the quality of routing information in the Internet. Well done! Mark. From morrowc.lists at gmail.com Tue Feb 12 05:05:22 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 12 Feb 2019 00:05:22 -0500 Subject: Verizon having a bad routing day today? In-Reply-To: References: Message-ID: On Sat, Feb 9, 2019 at 9:09 PM Christopher Morrow wrote: > I wonder if there's a lurking verizon/701 engineer on-list who may have a > few moments to reach me out of band? :) I've got what looks like busted > routing (or > howdy! actually 3 different vz folk found me, explained what I'm seeing and ... mostly it's ok just unexpected by me :) -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels at fusix.nl Tue Feb 12 08:54:00 2019 From: niels at fusix.nl (Niels Raijer) Date: Tue, 12 Feb 2019 09:54:00 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23650.6366.573248.750616@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: <7908BE45-B202-4976-BBEA-17A126A8151E@fusix.nl> On 12 Feb 2019, at 01:52, Jay Borkenhagen wrote: > We got some very good advice watching this video from your most recent > NLNOG day: > > https://www.youtube.com/watch?v=vrzl__yGqLE > > ... but there is one place where I disagree with Niels. You’re of course welcome to do so :-) > He advised > against lowering the local-pref of invalid routes. I agree that this > should not be anyone's target policy, but it is a useful step along > the way. To set invalid routes a lower local-pref, one needs to > establish RTR sessions from routers to relying party servers, and to > configure a policy that takes validation state into account. I agree that this is a good approach for taking first steps into the RPKI world and I would not discourage a lower local preference as a first stage. As long as we’re on the same page about invalid == reject being the intended end result. > In short: C'mon in! The water's fine! :-) As a competitive swimmer I couldn’t agree more! -- Niels Raijer niels at fusix.nl From alex at nlnetlabs.nl Tue Feb 12 09:33:02 2019 From: alex at nlnetlabs.nl (Alex Band) Date: Tue, 12 Feb 2019 10:33:02 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23650.3306.926729.428632@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> <20BBDC85-DFBF-4677-A347-07EC1927053A@charter.com> <23650.3306.926729.428632@oz.mt.att.com> Message-ID: Congrats Jay, this is awesome news! > On 12 Feb 2019, at 01:01, Jay Borkenhagen wrote: > > Compton, Rich A writes: >> That's great! Do you guys have plans to publish ROAs for your own netblocks? If so, can you please share info on your process (tools, pitfalls, etc.)? Thanks! >> > > Hi Rich, > > We do have ROAs published for a not insignificant fraction of our > address space. For example (and cherry-picking the representation > most favorable to us) we're listed at #6 in the "25 Autonomous Systems > with the most Address Space VALID by RPKI" at this NIST RPKI tracker: > > https://rpki-monitor.antd.nist.gov/#rpki_adopters I’m interested to hear what is preventing you from creating ROAs for all of your announcements. > We will publish more ROAs over time. Thusfar we have been utilizing > ARIN's hosted model, but down the road ARIN's delegated model will be > in our future. > > https://www.arin.net/resources/rpki/using_rpki.html What are your main drivers for wanting to move to the delegated model? Cheers! -Alex From matthew at walster.org Tue Feb 12 14:50:53 2019 From: matthew at walster.org (Matthew Walster) Date: Tue, 12 Feb 2019 15:50:53 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <23650.6366.573248.750616@oz.mt.att.com> References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: On Tue, 12 Feb 2019, 01:52 Jay Borkenhagen ... but there is one place where I disagree with Niels. He advised > against lowering the local-pref of invalid routes. I agree that this > should not be anyone's target policy, but it is a useful step along > the way. > For initial deployment, this can seem attractive, but remember that one of the benefits an ROA gives is specifying the maximum prefix length. This means that someone can't hijack a /23 with a /24. Lowering local pref on invalid means you're no longer protected (just generating alerts) because longer prefix length always beats local preference. Once you are confident that you're not dropping anything valuable, the local preference rule should move to dropping the route (not the traffic!) from being installed. M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Tue Feb 12 15:05:28 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 12 Feb 2019 15:05:28 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: Matthew Walster wrote on 12/02/2019 14:50: > For initial deployment, this can seem attractive, but remember that one > of the benefits an ROA gives is specifying the maximum prefix length. > This means that someone can't hijack a /23 with a /24. they can if they forge the source ASN. RPKI helps against misconfigs rather than intentional hijackings. Nick From xxnog at ledeuns.net Tue Feb 12 15:09:36 2019 From: xxnog at ledeuns.net (Denis Fondras) Date: Tue, 12 Feb 2019 16:09:36 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: <20190212150936.GF11905@carcass.ledeuns.net> On Tue, Feb 12, 2019 at 03:05:28PM +0000, Nick Hilliard wrote: > Matthew Walster wrote on 12/02/2019 14:50: > > For initial deployment, this can seem attractive, but remember that one > > of the benefits an ROA gives is specifying the maximum prefix length. > > This means that someone can't hijack a /23 with a /24. > > they can if they forge the source ASN. RPKI helps against misconfigs rather > than intentional hijackings. > Only if you specify a a minlen of /23 and a maxlen of /24 and you only announce a /23. Which you should not. From job at instituut.net Tue Feb 12 15:31:13 2019 From: job at instituut.net (Job Snijders) Date: Tue, 12 Feb 2019 15:31:13 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: On Tue, Feb 12, 2019 at 3:06 PM Nick Hilliard wrote: > > Matthew Walster wrote on 12/02/2019 14:50: > > For initial deployment, this can seem attractive, but remember that one > > of the benefits an ROA gives is specifying the maximum prefix length. > > This means that someone can't hijack a /23 with a /24. > > they can if they forge the source ASN. RPKI helps against misconfigs > rather than intentional hijackings. Some networks have AS_PATH filters in place that prevent accepting a spoofed ASN behind an EBGP session that is not authorized to announce the spoofed ASN. Secondly, there also is a group of networks that assign the same local preference for all routes received via peering - meaning that the use of a spoofed ASN will make the AS_PATH one hop longer. In other words: everyone should peer directly with the destination networks that matter to them. This is not news of course. :-) I agree some attacks in some cases may still get through, but I've come to think that ASN spoofing is far less of an issue than I originally thought it would be. Kind regards, Job From colinj at gt86car.org.uk Tue Feb 12 16:28:53 2019 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 12 Feb 2019 16:28:53 +0000 Subject: Clueful Contact at IPVolume.net ? Message-ID: Anyone know knowledgeable contact at IPvolume.net ? Having weird advance threat protection events from 93.174.93.73 and unable to get abuse contact to answer. Must be nice monitoring kit in London/NL/Frankfurt from Seychelles :( inetnum: 93.174.93.0 - 93.174.93.255 netname: NET-3-93 descr: IPV NETBLOCK country: NL geoloc: 52.370216 4.895168 org: ORG-IVI1-RIPE admin-c: IVI24-RIPE tech-c: IVI24-RIPE status: ASSIGNED PA mnt-by: IPV mnt-lower: IPV mnt-routes: IPV created: 2008-06-29T21:36:16Z last-modified: 2019-02-04T13:12:31Z source: RIPE Highlight RIPE NCC managed values Login to update  organisation: ORG-IVI1-RIPE org-name: IP Volume inc org-type: OTHER address: Suite 9 address: Victoria, Mahe address: Seychelles e-mail: abuse at ipvolume.net abuse-c: IVNO1-RIPE mnt-ref: IPV mnt-by: IPV created: 2018-05-14T11:46:50Z last-modified: 2019-01-31T14:39:36Z source: RIPE Login to update  role: IPV address: Suite 9 address: Victoria, Mahe address: Seychelles e-mail: abuse at ipvolume.net nic-hdl: IVI24-RIPE mnt-by: IPV created: 2018-05-16T13:28:41Z last-modified: 2019-01-31T21:21:20Z source: RIPE Login to update  RIPEstat  route: 93.174.93.0/24 origin: AS202425 remarks: +----------------------------------------------- remarks: | For abuse e-mail abuse at ipvolume.net remarks: | We do not always reply to abuse. remarks: | But we do take care your report is dealt with! remarks: +----------------------------------------------- mnt-by: IPV created: 2019-02-08T16:07:14Z last-modified: 2019-02-08T16:07:14Z source: RIPE Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Tue Feb 12 16:38:47 2019 From: david at xtom.com (David Guo) Date: Tue, 12 Feb 2019 16:38:47 +0000 Subject: Clueful Contact at IPVolume.net ? In-Reply-To: References: Message-ID: Try to contact abuse at quasinetworks.com Formally as known as Ecatel https://torrentfreak.com/brein-is-taking-infamous-piracy-hosting-provider-ecatel-to-court-170815/ From: NANOG On Behalf Of Colin Johnston Sent: Wednesday, February 13, 2019 12:29 AM To: North American Network Operators' Group Subject: Clueful Contact at IPVolume.net ? Anyone know knowledgeable contact at IPvolume.net ? Having weird advance threat protection events from 93.174.93.73 and unable to get abuse contact to answer. Must be nice monitoring kit in London/NL/Frankfurt from Seychelles :( * inetnum: 93.174.93.0 - 93.174.93.255 * netname: NET-3-93 * descr: IPV NETBLOCK * country: NL * geoloc: 52.370216 4.895168 * org: ORG-IVI1-RIPE * admin-c: IVI24-RIPE * tech-c: IVI24-RIPE * status: ASSIGNED PA * mnt-by: IPV * mnt-lower: IPV * mnt-routes: IPV * created: 2008-06-29T21:36:16Z * last-modified: 2019-02-04T13:12:31Z * source: RIPE [ ]Highlight RIPE NCC managed values Login to update * organisation: ORG-IVI1-RIPE * org-name: IP Volume inc * org-type: OTHER * address: Suite 9 * address: Victoria, Mahe * address: Seychelles * e-mail: abuse at ipvolume.net * abuse-c: IVNO1-RIPE * mnt-ref: IPV * mnt-by: IPV * created: 2018-05-14T11:46:50Z * last-modified: 2019-01-31T14:39:36Z * source: RIPE Login to update * role: IPV * address: Suite 9 * address: Victoria, Mahe * address: Seychelles * e-mail: abuse at ipvolume.net * nic-hdl: IVI24-RIPE * mnt-by: IPV * created: 2018-05-16T13:28:41Z * last-modified: 2019-01-31T21:21:20Z * source: RIPE Login to update RIPEstat * route: 93.174.93.0/24 * origin: AS202425 * remarks: +----------------------------------------------- * remarks: | For abuse e-mail abuse at ipvolume.net * remarks: | We do not always reply to abuse. * remarks: | But we do take care your report is dealt with! * remarks: +----------------------------------------------- * mnt-by: IPV * created: 2019-02-08T16:07:14Z * last-modified: 2019-02-08T16:07:14Z * source: RIPE Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Tue Feb 12 18:15:54 2019 From: job at ntt.net (Job Snijders) Date: Tue, 12 Feb 2019 18:15:54 +0000 Subject: Analysing traffic in context of rejecting RPKI invalids using pmacct Message-ID: <20190212181554.GB36142@vurt.meerval.net> Dear all, Whether to deploy RPKI Origin Validation with an "invalid == reject" policy really is a business decision. One has to weigh the pros and cons: what are the direct and indirect costs of accepting misconfigurations or hijacks for my company? what is the cost of deploying RPKI? What is the cost of honoring misconfigured RPKI ROAs? There are a few thousand misconfigured ROAs, what does this mean for me? To answer these questions, Paolo Lucente and myself worked to extend pmacct traffic analysis engine (http://pmacct.net/) in such a way that it can do perform the RFC 6811 Origin Validation procedure and present the outcome as a property in the flow aggregation process. Pmacct has the ability to ingest BGP feeds and correlate the BGP data to the sflow/netflow/ipfix data. This allows for fantastic business intelligence, you can see exactly how much traffic is flowing from what customers to what endpoints for what reason! Pmacct implemented Origin Validation in a cute way: it separates out RPKI invalid BGP announcements into two categories: a) "invalid with no overlapping or alternative route" (aka will be blackholed if 'invalid == reject') b) "invalid but an overlapping unknown/valid announcement also exists" (end-to-end connectivity can still work). Because pmacct separates out the various types kinds of (invalid) BGP announcements, operators don't have to do deploy *anything* in their network to get a good grasp on how their connectivity to the rest of the Internet would look like after deploying a "invalid == reject" policy. No changes to your network configurations are required to make use of this feature, you don't need to tag routes with communities or do other tricks. All the analysis happens inside pmacct. Of course we tested this first in the NTT global backbone AS 2914! At the moment of writing, we're seeing less than a handful of gigabits per second being send towards BGP announcements that are RPKI Invalid and for which no alternative route exists. In context of NTT's backbone that amount of traffic is just statistical noise. This is a very encouraging sign, it may help us move towards the goal of deploying RPKI Origin Validation in AS 2914. Nusenu wrote a great blog post on where these RPKI ROA misconfigurations are located, i recommend reading their posts to develop a better understanding of the problem space: https://medium.com/@nusenu/where-are-rpki-unreachable-networks-located-65c7a0bae0f8 Even if you don't intend to deploy RPKI Origin Validation (or are single-homed), pmacct's RPKI capabilities can be useful in forensic investigations. It'll be easier to analyse how much and what kind of traffic for what period of time was sent to a possible hijack. This will help you when writing RFOs! If you want to testdrive this feature, fetch pmacct version 1.7.3-rc1 from https://github.com/pmacct/pmacct/releases/tag/1.7.3-rc1 Documentation on how to configure the feature: https://github.com/pmacct/pmacct/blob/master/QUICKSTART#L1783-#L1833 https://github.com/pmacct/pmacct/blob/master/CONFIG-KEYS#L2626-#L2647 Let us know what you think! Or if you'd like to chat telemetry with Paolo or me about analysing the effects of BGP hijacks and RPKI, we'll both be at the San Francisco NANOG meeting next week! Kind regards, Job ps. Dear Kentik & Deepfield, please copy+paste this feature! We'll happily share development notes with you, you can even look at pmacct's source code for inspiration. :-) From jsweeting at arin.net Tue Feb 12 18:20:56 2019 From: jsweeting at arin.net (John Sweeting) Date: Tue, 12 Feb 2019 18:20:56 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <3C717E35-FCB0-4A16-AB34-3BDCB7E74C81@arin.net> References: <23649.35961.352370.101277@oz.mt.att.com> <5704.1549926560@turing-police.cc.vt.edu> <3C717E35-FCB0-4A16-AB34-3BDCB7E74C81@arin.net> Message-ID: <55394A17-8433-41AB-ABC3-8DCEEEB7B31A@arin.net> From: TJ Trout Date: Monday, February 11, 2019 at 6:49 PM To: Cc: Jay Borkenhagen , nanog Subject: Re: AT&T/as7018 now drops invalid prefixes from peers How does one register their routes in the Rpki? If the routes are in the Arin database under the proper company name is that sufficient? *Ducks* TJ and all, To participate in RPKI with ARIN, your organization would need to have Internet number resources directly registered and those Internet number resources must be covered under a Registration Services Agreement (RSA) or a Legacy RSA. In addition, participation in RPKI will require that you have an ARIN Online account, linked to an Admin or Tech Point of Contact (POC) on the Organization Identifier (Org ID) that contains the Internet number resources to be certified. Our “Resource Public Key Infrastructure (RPKI)” is a great jumping off point to get started with certifying your Internet number resources. If you would like any assistance verifying your eligibility for RPKI participation or would like additional information on getting started with RPKC, please call our Registration Services Helpdesk at 703.227.0660. Our hours of operation are Monday – Friday, from 7:00 am to 7:00 pm eastern time. On Mon, Feb 11, 2019, 3:09 PM wrote: On Mon, 11 Feb 2019 09:53:45 -0500, Jay Borkenhagen said: > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. Congrats! Are you able to comment on what amount of routes are getting dropped? -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Feb 12 18:39:48 2019 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Feb 2019 10:39:48 -0800 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: <55394A17-8433-41AB-ABC3-8DCEEEB7B31A@arin.net> References: <23649.35961.352370.101277@oz.mt.att.com> <5704.1549926560@turing-police.cc.vt.edu> <3C717E35-FCB0-4A16-AB34-3BDCB7E74C81@arin.net> <55394A17-8433-41AB-ABC3-8DCEEEB7B31A@arin.net> Message-ID: To be clear, I don’t believe they are dropping all routes which don’t validate (have no ROAs), only routes where the prefix matches an existing ROA and the origin AS in the AS PATH does not match. Owen > On Feb 12, 2019, at 10:20 , John Sweeting wrote: > > > From: TJ Trout > > Date: Monday, February 11, 2019 at 6:49 PM > To: > > Cc: Jay Borkenhagen >, nanog > > Subject: Re: AT&T/as7018 now drops invalid prefixes from peers > > How does one register their routes in the Rpki? If the routes are in the Arin database under the proper company name is that sufficient? *Ducks* > > TJ and all, > > To participate in RPKI with ARIN, your organization would need to have Internet number resources directly registered and those Internet number resources must be covered under a Registration Services Agreement (RSA) or a Legacy RSA. In addition, participation in RPKI will require that you have an ARIN Online account, linked to an Admin or Tech Point of Contact (POC) on the Organization Identifier (Org ID) that contains the Internet number resources to be certified. > > Our “Resource Public Key Infrastructure (RPKI)” is a great jumping off point to get started with certifying your Internet number resources. > > If you would like any assistance verifying your eligibility for RPKI participation or would like additional information on getting started with RPKC, please call our Registration Services Helpdesk at 703.227.0660. Our hours of operation are Monday – Friday, from 7:00 am to 7:00 pm eastern time. > > > On Mon, Feb 11, 2019, 3:09 PM wrote: > On Mon, 11 Feb 2019 09:53:45 -0500, Jay Borkenhagen said: > > The AT&T/as7018 network is now dropping all RPKI-invalid route > > announcements that we receive from our peers. > > Congrats! > > Are you able to comment on what amount of routes are getting dropped? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Tue Feb 12 18:48:01 2019 From: job at instituut.net (Job Snijders) Date: Tue, 12 Feb 2019 18:48:01 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <5704.1549926560@turing-police.cc.vt.edu> <3C717E35-FCB0-4A16-AB34-3BDCB7E74C81@arin.net> <55394A17-8433-41AB-ABC3-8DCEEEB7B31A@arin.net> Message-ID: On Tue, Feb 12, 2019 at 6:40 PM Owen DeLong wrote: > > To be clear, I don’t believe they are dropping all routes which don’t validate (have no ROAs), only routes where the prefix matches an existing ROA and the origin AS in the AS PATH does not match. Small addition: routes are not only rejected when the BGP Origin ASN doesn't match with any of the ROAs, but also if the Prefix Length doesn't match up. RFC 6811 describes the procedure. Kind regards, Job From matthew at walster.org Tue Feb 12 19:27:07 2019 From: matthew at walster.org (Matthew Walster) Date: Tue, 12 Feb 2019 20:27:07 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: On Tue, 12 Feb 2019 at 16:05, Nick Hilliard wrote: > Matthew Walster wrote on 12/02/2019 14:50: > > For initial deployment, this can seem attractive, but remember that one > > of the benefits an ROA gives is specifying the maximum prefix length. > > This means that someone can't hijack a /23 with a /24. > > they can if they forge the source ASN. RPKI helps against misconfigs > rather than intentional hijackings. As it stands today, RPKI is only useful to prevent fat-fingering of ebgp routing policies, where routes are leaked from a point of "legitimate" re-origination such as a web filter service. It's entirely unsuitable (at present) for anything where someone is re-originating the prefix somewhere else with the same origin ASN present (i.e. maliciously) and it doesn't protect against someone accidentally sending you a prefix they heard elsewhere that is valid. My understanding is that part of that problem can be solved with https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 but once again it's still only preventing fat-fingering and not malicious intent. RPKI provides an additional layer of security, but it stands independent of the need for prefix list and AS_PATH filter generation (likely derived from IRR data). I'm actually of the opinion that the whole "PKI" part of RPKI is the bit that really needs to die. PKI certificates brought no real benefit to the solution. Embedding RFC 3779 (X.509 Extensions for IP Addresses and AS Identifiers) makes the data so much less accessible and difficult to process for all but the most technically competent system/network administrators, especially considering most existing tools and libraries for X.509 certificate operations just don't support doing anything reasonable with them in a way that doesn't involve several hours afterwards in a candle-lit bath with a Pink Floyd CD playing in the background. Personally, I'd like to see BMP (RFC 7854, unidirectional flow of information) bolted on to an extended version of the RTR protocol (RFC8210) or a stripped down unidirectional BGP session, and have the whole policy engine offloaded from the border router to some kind of daemon running, potentially on a distributed controller of sorts, that: - Pulled in all this raw data and processed it, using the compute power available in servers after the invention of the Cyrix 200. - Asserted the veracity of the data it has received (real-time updates of prefix-lists, paths, trustworthiness, advertised "directionality" akin to peerlock etc) without having to periodically push new configuration to your routers. - Applied policy decisions, including mapping traffic for that destination into a FEC / MPLS tunnel as appropriate. - Possibly even applying aggregation at the FIB install level if appropriate to reduce total FIB entry size and programming time. - Distributed a final RIB (+FIB if needed) out to each of the BGP routers in the AS, depending on the view they needed. I think I'd have a hard time convincing people of that though, and the RIR policy folk would have a small heart attack at the level of complexity required. M -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Tue Feb 12 19:56:31 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 12 Feb 2019 19:56:31 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: Matthew Walster wrote on 12/02/2019 19:27: > I'm actually of the opinion that the whole "PKI" part of RPKI is the bit > that really needs to die. I'll claim a de-facto godwin if anyone mentions the word "blockchain". Nick From mh at xalto.net Tue Feb 12 20:06:20 2019 From: mh at xalto.net (Michael Hallgren) Date: Tue, 12 Feb 2019 21:06:20 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: Le 2019-02-12 20:56, Nick Hilliard a écrit : > Matthew Walster wrote on 12/02/2019 19:27: >> I'm actually of the opinion that the whole "PKI" part of RPKI is the >> bit that really needs to die. > > I'll claim a de-facto godwin if anyone mentions the word "blockchain". > > Nick https://www.google.fr/search?q=blockchain+for+BGP+routing+security&oq=blockchain+for+BGP+routing+security&aqs=chrome..69i57.18977j0j7&sourceid=chrome&ie=UTF-8 :-) mh From job at instituut.net Tue Feb 12 23:24:16 2019 From: job at instituut.net (Job Snijders) Date: Tue, 12 Feb 2019 23:24:16 +0000 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster wrote: > On Tue, 12 Feb 2019 at 16:05, Nick Hilliard wrote: >> Matthew Walster wrote on 12/02/2019 14:50: >> > For initial deployment, this can seem attractive, but remember that one >> > of the benefits an ROA gives is specifying the maximum prefix length. >> > This means that someone can't hijack a /23 with a /24. >> >> they can if they forge the source ASN. RPKI helps against misconfigs >> rather than intentional hijackings. > > As it stands today, RPKI is only useful to prevent fat-fingering of ebgp routing policies, where routes are leaked from a point of "legitimate" re-origination such as a web filter service. This simply isn't true. I'm willing to argue a bit about to what degree and in what circumstances RPKI Origin Validation technology is useful or not, but the use of the word "only" in this context is incorrect. > It's entirely unsuitable (at present) for anything where someone is re-originating the prefix somewhere else with the same origin ASN present (i.e. maliciously) and it doesn't protect against someone accidentally sending you a prefix they heard elsewhere that is valid. This also is not true. It is not as black and white as you make it out to be. 1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't accept them. You can't inject yourself between AT&T and NTT using spoofing. 2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location. We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1. > My understanding is that part of that problem can be solved with https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 but once again it's still only preventing fat-fingering and not malicious intent. Uh... that draft is about something else entirely. :-) > I think I'd have a hard time convincing people of that though, and the RIR policy folk would have a small heart attack at the level of complexity required. you are probably right about that, I'd prefer to stick to a technology that actually exists and is deployable! :-) Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at walster.org Wed Feb 13 02:02:15 2019 From: matthew at walster.org (Matthew Walster) Date: Wed, 13 Feb 2019 03:02:15 +0100 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: On Wed, 13 Feb 2019 at 00:24, Job Snijders wrote: > On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster > wrote: > > As it stands today, RPKI is only useful to prevent fat-fingering of ebgp > routing policies, where routes are leaked from a point of "legitimate" > re-origination such as a web filter service. > > This simply isn't true. I'm willing to argue a bit about to what degree > and in what circumstances RPKI Origin Validation technology is useful or > not, but the use of the word "only" in this context is incorrect. > I have massively oversimplified the situation, true, but essentially the vast majority of the pie chart of "why a prefix would be originated from another ASN and/or of a different prefix length" is: - Leaking from within the originator's borders where the border acts as a point of aggregation (atomic or otherwise). Mostly harmless. - Someone else leaking out the prefix when they generate it to assist with traffic engineering, including through a proxy/filter (Pakistan/YouTube) - Someone maliciously acting, so as to steal that traffic (predominantly Bitcoin mining pools, but could be ACME TLS etc) Have I missed anything (that has substantial real-life relevance to any incident seen so far) or would you say that was a far summary? > > It's entirely unsuitable (at present) for anything where someone is > re-originating the prefix somewhere else with the same origin ASN present > (i.e. maliciously) and it doesn't protect against someone accidentally > sending you a prefix they heard elsewhere that is valid. > > This also is not true. It is not as black and white as you make it out to > be. > > 1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the > AS_PATH except on the direct EBGP sessions between 7018 and 2914. This > means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't > accept them. You can't inject yourself between AT&T and NTT using spoofing. > Not relevant to RPKI as it currently stands, which is unrelated to the current mechanism being used: origin validation. Path filtering and IRR prefix list filtering are much more important tools that should be used first -- RPKI can only supplement those tools and should not be used in isolation, unlike the others which do a "good enough" job for most non-transit networks. > 2/ Many networks give all their peering partners the same > LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but > also compete & win for the shortest path in order for your hijack to arrive > at the intended location. > > We as industry essentially already have path validation for paths of > length 1. This may not seem much, but since people in this industry tend to > peer directly with networks that matter to them. The majority of Internet > traffic flows over paths that have an AS_PATH length of 1. > We do? I beg to differ. Much of Europe does, national networks in North America generally do, but those in the LACNIC / AfriNIC / APNIC regions? Of course there are exceptions (HKIX et al) but your average path length is going to be generally longer in those regions, and all it takes is for someone at a local IX to forge a couple of path attributes, and suddenly a bunch of traffic shifts. > > My understanding is that part of that problem can be solved with > https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 > but once again it's still only preventing fat-fingering and not malicious > intent. > > Uh... that draft is about something else entirely. :-) > Oh whooops! Copied the URL from the wrong tab! I of course meant the draft you and Massimiliano Stucchi have at https://tools.ietf.org/html/draft-ss-grow-rpki-as-cones-00 -- my bad!! > > I think I'd have a hard time convincing people of that though, and the > RIR policy folk would have a small heart attack at the level of complexity > required. > > you are probably right about that, I'd prefer to stick to a technology > that actually exists and is deployable! :-) > My idea is deployable today (for some values of today). Mark all the received NLRIs as not to be installed in the FIB, replicate the data via BMP or BGP with add-paths to a collector, process it, and ship out the results via a BGP session that sets the correct next-hops. I wrote a simple BGP speaker that had 4 byte ASN capability advertisement and graceful restart, literally in a day. Sure, it only supported IPv4 unicast, but with the wide array of open source BGP engines out there, it wouldn't be so hard to put something together that offloaded the entire policy phase from the router to a control plane. You could easily add modules in (just a chain of OOP interfaces) so that you could compare across prefixes, apply aggregation and damping, near real-time mirroring of IRR data to use as filter sets, maybe even read interface stats via SNMP / streaming telemetry / sFlow to start moving traffic around when ports get hot. Oh dear, I've re-invented SDN haven't I? :S However, just because you *could* deploy it today, doesn't mean you should =) M -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Feb 13 05:22:30 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Feb 2019 00:22:30 -0500 Subject: Route Filtering Update Message-ID: Howdy! At Nanog74 in Vancouver I mentioned (along with some other folk in the security track) that we are planning on filtering peerings to AS15169 'by chrismas 2018', roughly speaking. A few folk(bcc'd, hi!) noticed that I'm late on that work item... yes I am, sorry. I'm hopeful I'll get the ducks[0[ lined up to get this accomplished this quarter instead. I'll be at the Nanog meeting next week and I'm hoping to get a lightning talk slot to chat about this, progress and next steps. Worse case operations folk interested should feel free to corner me at the venue to chat about this topic directly. other topics are also fine to chat about :) thanks, -chris 0: https://www.digitaltrends.com/wp-content/uploads/2013/02/1-duck-sized-horse-vs-100-horse-sized-ducks.jpg -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Feb 13 09:20:15 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Feb 2019 01:20:15 -0800 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20190211150825.GE2715@hanna.meerval.net> <23650.6366.573248.750616@oz.mt.att.com> Message-ID: <1EE12CBB-AA5B-4A3A-BCC4-89E61E05D14B@delong.com> > > 1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't accept them. You can't inject yourself between AT&T and NTT using spoofing. Sure, but RPKI plays no role in this. > 2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location. Also utterly and completely unrelated to ROAs. > We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1. I would buy this argument with length 1-3, but I’m not completely convinced of “1”. Owen From spoofer-info at caida.org Fri Feb 8 18:00:05 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Fri, 8 Feb 2019 10:00:05 -0800 Subject: Spoofer Report for NANOG for Jan 2019 Message-ID: <201902081800.x18I054O086521@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Jan 2019: ASN Name Fixed-By 4 ISI 2019-01-02 4181 TDS 2019-01-02 13830 COREX 2019-01-07 11215 LOGIXCOMM 2019-01-14 2381 WISCNET1 2019-01-18 2828 XO-AS15 2019-01-24 11827 WSU 2019-01-24 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jan 2019: ASN Name First-Spoofed Last-Spoofed 15003 AS-UBIQUITY 2016-03-24 2019-01-26 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-01-29 6128 CABLE-NET-1 2016-09-03 2019-01-25 20412 CLARITY-TELECOM 2016-09-30 2019-01-31 6181 FUSE-NET 2016-10-10 2019-01-29 25787 ROWE-NETWORKS 2016-10-21 2019-01-31 31857 PRIORITY-TERABIT 2016-10-25 2019-01-26 30341 SCTA-ASN 2016-10-31 2019-01-28 32440 LONI 2016-11-03 2019-01-31 12083 WOW-INTERNET 2016-11-09 2019-01-29 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-01-29 3549 LVLT-3549 2016-11-16 2019-01-16 7106 INDEPENDENTSFIBERNETWORK 2017-01-09 2019-01-02 21832 KELLINCOM-1 2017-02-03 2019-01-26 18451 LESNET 2017-02-22 2019-01-23 701 UUNET 2017-06-14 2019-01-29 6461 ZAYO-6461 2017-06-21 2019-01-25 63296 AMARILLO-WIRELESS 2017-09-01 2019-01-30 7233 YAHOO-US 2017-09-07 2019-01-28 33523 ROWANUNIVERSITY 2017-10-29 2019-01-29 546 PARSONS-PGS-1 2017-11-20 2019-01-23 12222 AKAMAI 2018-02-14 2019-01-30 29384 Qatar-Foundation 2018-03-08 2019-01-06 23148 TERRENAP 2018-03-15 2019-01-09 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2019-01-30 4201 ORST 2018-04-19 2019-01-29 225 VIRGINIA 2018-06-18 2019-01-28 54804 CSMIII-BUNKIELA 2018-09-15 2019-01-25 33452 RW 2018-09-19 2019-01-25 20448 VPNTRANET-LLC 2018-09-20 2019-01-18 11996 LOBOIS 2018-09-24 2019-01-31 13825 TROYCABLE-NET 2018-11-21 2019-01-31 6453 AS6453 2018-12-11 2019-01-15 23338 ASN-DCS-01 2019-01-06 2019-01-06 36024 COLO4-CO 2019-01-09 2019-01-09 2381 WISCNET1 2019-01-16 2019-01-16 53274 3DB-WIRELESS 2019-01-18 2019-01-18 23523 VOYAGEURINTERNET-1 2019-01-22 2019-01-22 2914 NTT-COMMUNICATIONS-2914 2019-01-24 2019-01-24 397097 2019-01-27 2019-01-27 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From the76posse at gmail.com Fri Feb 8 20:10:08 2019 From: the76posse at gmail.com (Steve Danello) Date: Fri, 8 Feb 2019 15:10:08 -0500 Subject: Latency question - Juniper MX960 vs the Tellabs 8860 Message-ID: <951737BD-06EF-420B-A456-07DAB580E225@gmail.com> Looking for two latency profiles, best/worst cast would be great for the Telllabs 8860 and Juniper MX960. Looks like the Juniper may be in the 15us range Both cases would be a 10Gb -1Gb and 1Gb - 10Gb We’d understand the serialization piece; really looking to provide a customer the hardware latency, we don’t have a great means to test them Thanks all! Steve From chinese.apricot at gmail.com Sun Feb 10 05:38:26 2019 From: chinese.apricot at gmail.com (william manning) Date: Sat, 9 Feb 2019 21:38:26 -0800 Subject: Fwd: wither cyclops? In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: william manning Date: Sat, Feb 9, 2019 at 9:34 PM Subject: wither cyclops? To: Did this tool die on the vine? https://cyclops.cs.ucla.edu/ /Wm -------------- next part -------------- An HTML attachment was scrubbed... URL: From fkittred at gwi.net Sun Feb 10 15:44:15 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Sun, 10 Feb 2019 10:44:15 -0500 Subject: Last Mile Design [American Operators] In-Reply-To: <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> References: <708b44c9-2452-d7a0-61c1-9d98a3418dd7@wholesaleinternet.net> <034f4fdc-6aab-de34-35c6-d84b039c3bbf@meetinghouse.net> <52f06797-26a2-3a50-c77f-61081cf31b2b@wholesaleinternet.net> <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> Message-ID: I find the input to this discussion from non-US operators very useful. Thank you. One flaw of America is our parochialism and isolation means we don't learn from experiences elsewhere. We are so used to leading the world in technology that we have very little exposure to advances outside of the US. This is particularly true in the ISP world were demonstrably other regions are ahead of the US. Personally, I would be very interested in learning more about what is going on in New Zealand and Scandinavia. Pointers to background reading would be deeply appreciated, or even good search terms. -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From eng.mssk at gmail.com Sun Feb 10 20:10:05 2019 From: eng.mssk at gmail.com (Mohammad Khalil) Date: Sun, 10 Feb 2019 22:10:05 +0200 Subject: BGP topological vs centralized route reflector Message-ID: Dears Am trying to find some documents and practical implementations regarding bgp topological vs centralized route reflector(In-band vs out-of-band) Any good shares are appreciated -------------- next part -------------- An HTML attachment was scrubbed... URL: From fkittred at gwi.net Mon Feb 11 14:26:31 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 11 Feb 2019 09:26:31 -0500 Subject: Last Mile Design In-Reply-To: References: <004a01d4bfed$487d1ba0$d97752e0$@wicks.co.nz> <4f48eead-ef86-5af7-3f5a-645087f1c711@wholesaleinternet.net> <98EF7F9D-99E1-4F89-934A-B8D5A91C5430@6by7.net> <87f00110-20fd-2a9c-d839-1e50032f59ed@seacom.mu> <1b5db4da-d834-eebc-5dff-b662011389d6@nsc.liu.se> <00d901d4c103$45a30040$d0e900c0$@wicks.co.nz> <8ac7ca7f-9b79-d815-0311-f5a13a6afb75@gmail.com> <93558c6c-9324-2129-c422-ab4097a9d38f@seacom.mu> Message-ID: For my fellow americans, LLUB stands for Local Loop UnBundling. What we might call a Unbundled Network Element. On Mon, Feb 11, 2019 at 5:49 AM Mikael Abrahamsson wrote: > On Mon, 11 Feb 2019, Mark Tinka wrote: > > >> In any case, we are now building out our own fiber to cover the gaps > >> left by TDC. Here the end user has to pay DKK 12,000 (USD 1,824 / EUR > >> 1,608) one time fee and with that he gets everything including 5 years > >> of free internet. This works out at DKK 200 / month including 25% VAT > >> tax (USD 30 / EUR 27). > > > > Very interesting - don't you feel that an initial outlay like that could > > put some potential customers off? Then again, per capita income in > > Denmark, I'd imagine, could allow most to think about this. If all that > > buys me Internet access for 5 years before I have to shell out anymore > > wedge, I'd do it. > > In Sweden it's very common that people who live in detached house areas > have to pay 1500-3000EUR to get attached to the fiber network as it's > being built out. There are even bank loans you can get to pay for this, > and pay it off over time. It's considered to be a good deal because it > improves the value of the house as well as a huge improvement over having > satellite-dish/terrestrial TV and ADSL/LTE for Internet access, now > instead you can pay 30-40EUR a month to get a everything over the fiber. > > Now, I like the LLUB model where ISPs get access to the dark fiber all the > way to the customer, and we do have that here as well, just not as > commonly as I'd like. That's where https://www.bahnhof.se/villafiber/ > comes from where they offer 10GE for 50EUR a month. This is done on Telia > LLUB:ed dark fiber which costs around 15EUR a month (regulated price). > It's a great PR case for "dark fiber access rocks and bitstream sucks". > You get IPv6 in there as well, which isn't commonly available on most of > the bitstream access services (because not only do we not do PON, we don't > do PPPoE either here in Sweden). > > So it's a mixed bag and pricing and functionality could definitely be > better, but the FTTH rollout has gone quite well here and it's as usual > 10-15 different factors contributing but the willingness of the population > who lives in houses to fork out 1500-3000EUR for fiber install has made > this a lot less cash flow misery for the ISPs that roll this out. I just > wish there would have been a requirement for everybody to actually rent > this dark fiber out (which there isn't unless you're one of the biggest > players) because after paying those 1500-3000EUR and you ask the fiber > installation company "who owns this fiber?" they say "we do" and if you > ask "ok, I'd like it connected to someone else" they will say "huh? what > do you mean". There is an unfortunate common conflation between the fiber > optic cable and the services offered on it. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdambrosia at gmail.com Mon Feb 11 15:07:40 2019 From: jdambrosia at gmail.com (John DAmbrosia) Date: Mon, 11 Feb 2019 10:07:40 -0500 Subject: IEEE 802.3 Ethernet Bandwidth Assessment Message-ID: <170b01d4c21b$8b2dff20$a189fd60$@gmail.com> All, I am chairing the IEEE 802.3 New Ethernet Applications ad hoc, which has an activity underway that is looking at doing an update to its 2012 Ethernet Bandwidth Assessment (see http://www.ieee802.org/3/ad_hoc/bwa/BWA_Report.pdf). Please note that this effort will focus on gathering information throughout 2019 that will enable an evaluation of the future bandwidth needs of various Ethernet wireline applications. If anyone has any information that they believe is pertinent to this assessment that they would like to share, please contact me. The webpage for the new Bandwidth Assessment Ad hoc is http://www.ieee802.org/3/ad_hoc/bwa2/index.html. The ad hoc wrote a request for information that can be found at http://www.ieee802.org/3/minutes/sep18/outgoing/IEEE_802d3_to_ALL_BWA_0918.p df. Please note that you don't need to attend an IEEE 802.3 meeting to present this data, it can be done via teleconference. Regards, John D'Ambrosia Chair, IEEE 802.3 New Ethernet Applications Ad hoc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michjo at viviotech.net Mon Feb 11 18:18:59 2019 From: michjo at viviotech.net (Jordan Michaels) Date: Mon, 11 Feb 2019 10:18:59 -0800 (PST) Subject: VPS providers contacts In-Reply-To: References: Message-ID: <1485625446.101605.1549909139839.JavaMail.zimbra@viviotech.net> Virtkick was acquired by OnApp (https://www.virtkick.com/blog/onapp-to-acquire-virtkick.html), so you might be able to contact OnApp about it. Hope this helps. -- Kind regards, Jordan Michaels Vivio Technologies ----- Original Message ----- From: "Mehmet Akcin" To: "nanog" Sent: Friday, 8 February, 2019 20:00:45 Subject: VPS providers contacts Hey there I am looking to get in touch with VPS providers (like vultr.com etc.) which has all automated control panel to ask few questions regarding BGP implementation and overall automated control panel related stuff. I have been trying to get a hold of someone from virtkick.com which on paper sounded like exactly what i needed but unfortunately got no response from them. thanks in advance mehmet From owen at delong.com Wed Feb 13 17:49:38 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Feb 2019 09:49:38 -0800 Subject: VPS providers contacts In-Reply-To: <1485625446.101605.1549909139839.JavaMail.zimbra@viviotech.net> References: <1485625446.101605.1549909139839.JavaMail.zimbra@viviotech.net> Message-ID: <6C1E9E5C-8B19-480D-8F6B-94ECDACF3D75@delong.com> I highly recommend NetActuate. Awesome folks, great network and customer interface and willing to do custom stuff when needed. Very flexible and easy to work with. Owen > On Feb 11, 2019, at 10:18 , Jordan Michaels wrote: > > Virtkick was acquired by OnApp (https://www.virtkick.com/blog/onapp-to-acquire-virtkick.html), so you might be able to contact OnApp about it. > > Hope this helps. > > -- > Kind regards, > Jordan Michaels > Vivio Technologies > > ----- Original Message ----- > From: "Mehmet Akcin" > To: "nanog" > Sent: Friday, 8 February, 2019 20:00:45 > Subject: VPS providers contacts > > Hey there > > I am looking to get in touch with VPS providers (like vultr.com etc.) which > has all automated control panel to ask few questions regarding BGP > implementation and overall automated control panel related stuff. > > I have been trying to get a hold of someone from virtkick.com which on > paper sounded like exactly what i needed but unfortunately got no response > from them. > > thanks in advance > > mehmet From mark at exonetric.com Wed Feb 13 17:53:11 2019 From: mark at exonetric.com (Mark Blackman) Date: Wed, 13 Feb 2019 17:53:11 +0000 Subject: VPS providers contacts In-Reply-To: <1485625446.101605.1549909139839.JavaMail.zimbra@viviotech.net> References: <1485625446.101605.1549909139839.JavaMail.zimbra@viviotech.net> Message-ID: > On 11 Feb 2019, at 18:18, Jordan Michaels wrote: > > Virtkick was acquired by OnApp (https://www.virtkick.com/blog/onapp-to-acquire-virtkick.html), so you might be able to contact OnApp about it. "Ultimately, the acquisition was not consummated, and Virtkick remained an independent entity.” - Mark From saku at ytti.fi Wed Feb 13 17:53:14 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 13 Feb 2019 19:53:14 +0200 Subject: Latency question - Juniper MX960 vs the Tellabs 8860 In-Reply-To: <951737BD-06EF-420B-A456-07DAB580E225@gmail.com> References: <951737BD-06EF-420B-A456-07DAB580E225@gmail.com> Message-ID: Hey Steve, 15us would be more than you'll realistically see in uncongested MX960, but it is in the ball-bark. I've not tried Tellabs, if customer is latency sensitive you probably want to look constant time pipeline devices rather than run to completion npus. You'll see low single digit us on typical box. Remember that 10us is just 2km of fibre (1km of RTT). On Wed, Feb 13, 2019 at 7:28 PM Steve Danello wrote: > > Looking for two latency profiles, best/worst cast would be great for the Telllabs 8860 and Juniper MX960. Looks like the Juniper may be in the 15us range > > Both cases would be a 10Gb -1Gb and 1Gb - 10Gb > > We’d understand the serialization piece; really looking to provide a customer the hardware latency, we don’t have a great means to test them > > Thanks all! > > Steve -- ++ytti From saku at ytti.fi Wed Feb 13 18:00:33 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 13 Feb 2019 20:00:33 +0200 Subject: BGP topological vs centralized route reflector In-Reply-To: References: Message-ID: Hey, in-band, out-of-band is bit of misnomers to me. You mean in-path or out-of-path. Main advantage of out-of-path is that you decouple FIB and RIB scaling requirements and feature requirements. Your backbone device does not need to be qualified for large RIB or BGP at all. And when you do need more RIB scaling, you can upgrade out-of-path without any network interruption. Main advantage of in-path is maturity and simplicity, you don't need ORR and you might not need AddPath. On Wed, Feb 13, 2019 at 7:37 PM Mohammad Khalil wrote: > > Dears > Am trying to find some documents and practical implementations regarding bgp topological vs centralized route reflector(In-band vs out-of-band) > > Any good shares are appreciated -- ++ytti From the76posse at gmail.com Wed Feb 13 18:32:51 2019 From: the76posse at gmail.com (Steve Danello) Date: Wed, 13 Feb 2019 13:32:51 -0500 Subject: Latency question - Juniper MX960 vs the Tellabs 8860 In-Reply-To: References: <951737BD-06EF-420B-A456-07DAB580E225@gmail.com> Message-ID: <9C4C04BA-E958-4657-A0C2-8D460FF917BA@gmail.com> Yes thank you Saku! We’ve accounted for the fiber distance. We just want to be able to quote the hardware latency. Thanks for verifying that Juniper; just need the Tellabs... thank you:) Sent from my iPhone > On Feb 13, 2019, at 12:53 PM, Saku Ytti wrote: > > Hey Steve, > > 15us would be more than you'll realistically see in uncongested MX960, > but it is in the ball-bark. I've not tried Tellabs, if customer is > latency sensitive you probably want to look constant time pipeline > devices rather than run to completion npus. You'll see low single > digit us on typical box. Remember that 10us is just 2km of fibre (1km > of RTT). > > >> On Wed, Feb 13, 2019 at 7:28 PM Steve Danello wrote: >> >> Looking for two latency profiles, best/worst cast would be great for the Telllabs 8860 and Juniper MX960. Looks like the Juniper may be in the 15us range >> >> Both cases would be a 10Gb -1Gb and 1Gb - 10Gb >> >> We’d understand the serialization piece; really looking to provide a customer the hardware latency, we don’t have a great means to test them >> >> Thanks all! >> >> Steve > > > > -- > ++ytti From randy at psg.com Wed Feb 13 20:11:38 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Feb 2019 12:11:38 -0800 Subject: skype attack Message-ID: an update to skype will pop up and ask you -------------- next part -------------- deny. you will have to deny repeatedly. there is no reason in the world skype should have access to your icloud, contacts, ... randy From morrowc.lists at gmail.com Wed Feb 13 20:58:42 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Feb 2019 15:58:42 -0500 Subject: skype attack In-Reply-To: References: Message-ID: Y U USE SKYPE? On Wed, Feb 13, 2019 at 3:11 PM Randy Bush wrote: > an update to skype will pop up and ask you > > > deny. you will have to deny repeatedly. there is no reason in the > world skype should have access to your icloud, contacts, ... > > randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Feb 13 21:20:34 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Feb 2019 13:20:34 -0800 Subject: skype attack In-Reply-To: References: Message-ID: > Y U USE SKYPE? yep. some researchers are still stuck there for con calls. i hate it. randy From morrowc.lists at gmail.com Wed Feb 13 22:01:31 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Feb 2019 17:01:31 -0500 Subject: skype attack In-Reply-To: References: Message-ID: On Wed, Feb 13, 2019 at 4:20 PM Randy Bush wrote: > > Y U USE SKYPE? > > yep. some researchers are still stuck there for con calls. i hate it. > > welp, at least the nsa can keep trac in real-time. they have that going for them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Feb 13 22:03:09 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Feb 2019 14:03:09 -0800 Subject: skype attack In-Reply-To: References: Message-ID: >> yep. some researchers are still stuck there for con calls. i hate >> it. > welp, at least the nsa can keep trac in real-time. the nsa is not in the researchers' threat model. this is not that kind of math. randy From drc at virtualized.org Wed Feb 13 22:21:57 2019 From: drc at virtualized.org (David Conrad) Date: Wed, 13 Feb 2019 14:21:57 -0800 Subject: skype attack In-Reply-To: References: Message-ID: <718D7B0B-F27D-4903-B83A-D68719833E5A@virtualized.org> Perhaps (issue created on 6 Dec 2017) relevant: https://answers.microsoft.com/en-us/skype/forum/skype_accountms-skype_privacyms/skype-suggests-people-from-my-contact-list-to/d8cc03ad-fa15-4de7-8d96-51510615cff4 > On Feb 13, 2019, at 12:11 PM, Randy Bush wrote: > > an update to skype will pop up and ask you > > > deny. you will have to deny repeatedly. there is no reason in the > world skype should have access to your icloud, contacts, ... > > randy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From randy at psg.com Wed Feb 13 22:45:38 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Feb 2019 14:45:38 -0800 Subject: skype attack In-Reply-To: <718D7B0B-F27D-4903-B83A-D68719833E5A@virtualized.org> References: <718D7B0B-F27D-4903-B83A-D68719833E5A@virtualized.org> Message-ID: > Perhaps (issue created on 6 Dec 2017) relevant: > > https://answers.microsoft.com/en-us/skype/forum/skype_accountms-skype_privacyms/skype-suggests-people-from-my-contact-list-to/d8cc03ad-fa15-4de7-8d96-51510615cff4 perms for contact list is one thing. perms for icloud account is another. this request is for icloud. they want your appleid! From mattia.rossi.mailinglists at gmail.com Wed Feb 13 23:02:24 2019 From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi) Date: Thu, 14 Feb 2019 10:02:24 +1100 Subject: skype attack In-Reply-To: References: Message-ID: <23f49817-fe35-448d-3000-6c06760d63c2@gmail.com> On 14/2/19 9:03 am, Randy Bush wrote: >>> yep. some researchers are still stuck there for con calls. i hate >>> it. Why not use jitsi meet? Free, Open Source, Standards compliant, WebRTC, an instance is hosted by IETF as well... It's actually perfect for researchers. https://jitsi.tools.ietf.org/ Cheers, Mat From randy at psg.com Wed Feb 13 23:06:18 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Feb 2019 15:06:18 -0800 Subject: skype attack In-Reply-To: <23f49817-fe35-448d-3000-6c06760d63c2@gmail.com> References: <23f49817-fe35-448d-3000-6c06760d63c2@gmail.com> Message-ID: > Why not use jitsi meet? i am familiar with jitsi. it's fine. but i am trying to get research done, not teach/preach conferencing to a bunch of researchers. this was just a warning about an attack through a skype update; not meant as a discussion of conferencing technologies or an opportunity for advertisement. randy From hf0002+nanog at uah.edu Wed Feb 13 23:06:17 2019 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Wed, 13 Feb 2019 17:06:17 -0600 Subject: skype attack In-Reply-To: References: Message-ID: On Wed, Feb 13, 2019 at 2:12 PM Randy Bush wrote: > > an update to skype will pop up and ask you > > > deny. you will have to deny repeatedly. there is no reason in the > world skype should have access to your icloud, contacts, ... Was there meant to be a screenshot or some explanation of what would be denied here? As of right now, it seems like I'm missing the details of this, or how it would pertain to me as a network operator. Maybe I just need more caffeine. Cheers. From randy at psg.com Wed Feb 13 23:07:36 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Feb 2019 15:07:36 -0800 Subject: skype attack In-Reply-To: References: Message-ID: On Wed, 13 Feb 2019 15:06:17 -0800, Hunter Fuller wrote: > Was there meant to be a screenshot or some explanation of what would > be denied here? sorry From randy at psg.com Wed Feb 13 23:18:37 2019 From: randy at psg.com (Randy Bush) Date: Wed, 13 Feb 2019 15:18:37 -0800 Subject: skype attack In-Reply-To: References: Message-ID: >> Was there meant to be a screenshot or some explanation of what would >> be denied here? > > sorry seems mailing list filters; so it was not my fault. try https://archive.psg.com/skype.jpg randy From anthony at fms.io Thu Feb 14 01:08:08 2019 From: anthony at fms.io (Anthony Leto) Date: Thu, 14 Feb 2019 01:08:08 +0000 Subject: VPS providers contacts In-Reply-To: <6C1E9E5C-8B19-480D-8F6B-94ECDACF3D75@delong.com> References: <1485625446.101605.1549909139839.JavaMail.zimbra@viviotech.net> <6C1E9E5C-8B19-480D-8F6B-94ECDACF3D75@delong.com> Message-ID: <71F2D7FF-FBE0-4238-955A-19551CE9A7BD@fms.io> I would recommend NetActuate as well. They really know their stuff! They helped a company I used to work at immensely with LVS and DNS load balancing in an anycast configuration. I would use them anytime. Anthony Leto > On Feb 13, 2019, at 12:51 PM, Owen DeLong wrote: > > I highly recommend NetActuate. > > Awesome folks, great network and customer interface and willing to do custom stuff when needed. > > Very flexible and easy to work with. > > Owen > > >> On Feb 11, 2019, at 10:18 , Jordan Michaels wrote: >> >> Virtkick was acquired by OnApp (https://www.virtkick.com/blog/onapp-to-acquire-virtkick.html), so you might be able to contact OnApp about it. >> >> Hope this helps. >> >> -- >> Kind regards, >> Jordan Michaels >> Vivio Technologies >> >> ----- Original Message ----- >> From: "Mehmet Akcin" >> To: "nanog" >> Sent: Friday, 8 February, 2019 20:00:45 >> Subject: VPS providers contacts >> >> Hey there >> >> I am looking to get in touch with VPS providers (like vultr.com etc.) which >> has all automated control panel to ask few questions regarding BGP >> implementation and overall automated control panel related stuff. >> >> I have been trying to get a hold of someone from virtkick.com which on >> paper sounded like exactly what i needed but unfortunately got no response >> from them. >> >> thanks in advance >> >> mehmet > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2760 bytes Desc: not available URL: From mehmet at akcin.net Thu Feb 14 01:12:33 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 13 Feb 2019 17:12:33 -0800 Subject: VPS providers contacts In-Reply-To: <71F2D7FF-FBE0-4238-955A-19551CE9A7BD@fms.io> References: <1485625446.101605.1549909139839.JavaMail.zimbra@viviotech.net> <6C1E9E5C-8B19-480D-8F6B-94ECDACF3D75@delong.com> <71F2D7FF-FBE0-4238-955A-19551CE9A7BD@fms.io> Message-ID: I am already and very happy customer On Wed, Feb 13, 2019 at 17:08 Anthony Leto wrote: > I would recommend NetActuate as well. They really know their stuff! They > helped a company I used to work at immensely with LVS and DNS load > balancing in an anycast configuration. I would use them anytime. > > Anthony Leto > > > > On Feb 13, 2019, at 12:51 PM, Owen DeLong wrote: > > > > I highly recommend NetActuate. > > > > Awesome folks, great network and customer interface and willing to do > custom stuff when needed. > > > > Very flexible and easy to work with. > > > > Owen > > > > > >> On Feb 11, 2019, at 10:18 , Jordan Michaels > wrote: > >> > >> Virtkick was acquired by OnApp ( > https://www.virtkick.com/blog/onapp-to-acquire-virtkick.html), so you > might be able to contact OnApp about it. > >> > >> Hope this helps. > >> > >> -- > >> Kind regards, > >> Jordan Michaels > >> Vivio Technologies > >> > >> ----- Original Message ----- > >> From: "Mehmet Akcin" > >> To: "nanog" > >> Sent: Friday, 8 February, 2019 20:00:45 > >> Subject: VPS providers contacts > >> > >> Hey there > >> > >> I am looking to get in touch with VPS providers (like vultr.com etc.) > which > >> has all automated control panel to ask few questions regarding BGP > >> implementation and overall automated control panel related stuff. > >> > >> I have been trying to get a hold of someone from virtkick.com which on > >> paper sounded like exactly what i needed but unfortunately got no > response > >> from them. > >> > >> thanks in advance > >> > >> mehmet > > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Thu Feb 14 02:41:55 2019 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 13 Feb 2019 20:41:55 -0600 Subject: Last Mile Design In-Reply-To: <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> Message-ID: Just wondering, but what IP-capable MPLS switches are people using to deploy AE to residential internet connections? Most 48 port AE switches from repetuable vendors are crazy expensive, and I can't see how the ROI would ever work compared to GPON. On Sat, Feb 9, 2019 at 4:25 PM Mark Tinka wrote: > > > On 9/Feb/19 18:07, Brandon Martin wrote: > > > > > > > Bingo. You're fine as long as your access L3 gear speaks MPLS. That > > does somewhat bump you out of the realm of "cheap L3 switch", but > > there are still options. > > IP-capable switches that have little to no MPLS support would certainly > be cheaper than one that does. > > But given the benefits of an MPLS-based Metro-E network vs. the > traditional architecture, I find current prices somewhat reasonable. > > Mark. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Feb 14 05:08:30 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 14 Feb 2019 07:08:30 +0200 Subject: Last Mile Design In-Reply-To: References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> Message-ID: <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> On 14/Feb/19 04:41, Colton Conor wrote: > Just wondering, but what IP-capable MPLS switches are people using to > deploy AE to residential internet connections? Most 48 port AE > switches from repetuable vendors are crazy expensive, and I can't see > how the ROI would ever work compared to GPON. I'd never use an MPLS-capable router (even if it looks like a switch) for Consumer customers. That math doesn't work. As a pure FTTH Active-E AN, I still think the Brocade (Extreme) CER/CES is a good box. Cisco had the good sense of pushing out the ME2600X for this years ago, and then opted to pull it. I can't find anything in their portfolio that makes sense to me for this. Juniper don't have anything on their end, either, that makes sense to me for this. So I'd probably still stick with the Brocade/Extreme. Mark. From mark.tinka at seacom.mu Thu Feb 14 05:15:49 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 14 Feb 2019 07:15:49 +0200 Subject: BGP topological vs centralized route reflector In-Reply-To: References: Message-ID: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> On 13/Feb/19 20:00, Saku Ytti wrote: > > Main advantage of out-of-path is that you decouple FIB and RIB scaling > requirements and feature requirements. Your backbone device does not > need to be qualified for large RIB or BGP at all. And when you do need > more RIB scaling, you can upgrade out-of-path without any network > interruption. We've ran this for years (Cisco CSR1000v, since 2014), and our biggest problem has been server hardware failure. Failing fans, sensitivity to higher temperatures that routers can weather better... that sort of thing. Other than that, run this as a VM in your favourite hypervisor and you're good to go. Can't recommend it enough. Mark. From ahebert at pubnix.net Thu Feb 14 12:04:48 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 14 Feb 2019 07:04:48 -0500 Subject: BGP topological vs centralized route reflector In-Reply-To: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> Message-ID: <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net>     Hi,     Unlucky as always, we had issues with the chassis of a MX104 about every years since we installed.     I thinking the vibration from the train track above our location might be having an effect on connectors in those chassis, but we never got a "autopsy" report back from JNP about the chassis we swapped.     Oddly luck, we have ~40 VM servers in the rack beside it with a mix of mechanical and SSDs drive with 0 issues for the same time span.     So mileage may vary. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 2/14/19 12:15 AM, Mark Tinka wrote: > > On 13/Feb/19 20:00, Saku Ytti wrote: > >> Main advantage of out-of-path is that you decouple FIB and RIB scaling >> requirements and feature requirements. Your backbone device does not >> need to be qualified for large RIB or BGP at all. And when you do need >> more RIB scaling, you can upgrade out-of-path without any network >> interruption. > We've ran this for years (Cisco CSR1000v, since 2014), and our biggest > problem has been server hardware failure. Failing fans, sensitivity to > higher temperatures that routers can weather better... that sort of thing. > > Other than that, run this as a VM in your favourite hypervisor and > you're good to go. Can't recommend it enough. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Feb 14 13:08:46 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 14 Feb 2019 15:08:46 +0200 Subject: BGP topological vs centralized route reflector In-Reply-To: <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> Message-ID: <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> On 14/Feb/19 14:04, Alain Hebert wrote: >     Hi, > >     Unlucky as always, we had issues with the chassis of a MX104 about > every years since we installed. Are you using the MX104 as a route reflector? If so, make one of the VM's your alternative for this function :-). If you're not doing any non-Ethernet services on your MX104, and are struggling with the control plane, I'd propose moving to the MX204. Mark. From aaron1 at gvtc.com Thu Feb 14 15:02:07 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 14 Feb 2019 09:02:07 -0600 Subject: BGP topological vs centralized route reflector In-Reply-To: <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> Message-ID: <000301d4c476$41364e10$c3a2ea30$@gvtc.com> To not get off-topic too much, since you mentioned MX204, please tell me, do you know if it is a nice MPLS P/PE box ? If so, is it quite capable in its ability to do L3 VPN's, L2 VPN's (l2circuit mainly, but also curious of vpls, evpn). Actually I'm considering it as a router for my ENNI hand-offs to 3rd party neighboring networks where I hand-off vlans (double tagged) for various enterprise customers and cbh towers, etc.... then I would carry that probably in a l2circuit from that MX204 to the utter-most parts of my mpls cloud. I would want to police at that subinterface (unit) level to limit traffic for obviously what they buy. MX204 be good for that ? Thanks Mark -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Tinka Sent: Thursday, February 14, 2019 7:09 AM To: nanog at nanog.org Subject: Re: BGP topological vs centralized route reflector On 14/Feb/19 14:04, Alain Hebert wrote: > Hi, > > Unlucky as always, we had issues with the chassis of a MX104 about > every years since we installed. Are you using the MX104 as a route reflector? If so, make one of the VM's your alternative for this function :-). If you're not doing any non-Ethernet services on your MX104, and are struggling with the control plane, I'd propose moving to the MX204. Mark. From aaron1 at gvtc.com Thu Feb 14 15:10:25 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 14 Feb 2019 09:10:25 -0600 Subject: Last Mile Design In-Reply-To: <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> Message-ID: <000501d4c477$69d1b390$3d751ab0$@gvtc.com> Not sure if this is what y'all are talking about, but I use lots of Juniper ACX5048 (previously Cisco ME3600 or ASR9000) for mpls-capable router edging in native ip/ethernet from ftth gpon network into mpls l2circuits and LOTS of vrf.... vrf for public ip, vrf for cgnat for private ip, vrf for voice... I'm glad I did it. Residential----- ONT-----ftth/gpon------OLT------ACX5048-----mpls/vrf x-------cgnat/inet------ Residential----- DSL Modem-----DSLAM-----------ACX5048-----mpls/vrf y-------cgnat/inet------ Residential----- Cable Modem-----CMTS-----------ACX5048-----mpls/vrf z-------cgnat/inet------ -Aaron From sy at netcases.net Thu Feb 14 15:48:02 2019 From: sy at netcases.net (Howard C. Berkowitz) Date: Thu, 14 Feb 2019 10:48:02 -0500 Subject: Return to NANOG, last mile, municipal facilities In-Reply-To: References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> Message-ID: <3c5a459086b4a7b181c542e35cda6957@netcases.net> It frightens me when I realize how long it's been since I was active in NANOG (2006?, but a lot before then). Happily, I'm surfacing from a lot of health and personal issues, and starting to do some consulting. *waves to lots of old friends, thinking of the time, in frustration, that I called VZ the employer of last resort for color-blind cable splicers. No long term insult intended.* I'm newly on the cable TV advisory commission for the Village of Chatham on Cape Cod, and trying to find other counterparts and specific experience. I am proposing that my committee take on a broader scope, to include municipal communications architecture not just with cable, but with town owned facilities/leased duct/carrier hotel, systematic cellular repeater towar placement and leasing, and WLANs among town buildings and possibly for residents. I'm also interacting with the emergency operations manager for various VHF, GETS/WPS telephony, and perhaps satellite. We're a fishing community with lots of marine band radio and satellite; the backup for the town and county emergency communications is 2-meter ham. Anyone else doing something like this? As a fishing and resort area, we'll be looking at providing WLAN connectivity in the harbor and nearby waters. We have an incumbent cable provider, which will not change this year. The committee advises the town on the contract and modifications. One area is that the town share of cable revenues is going down with more movie-over-IP and the like getting users to drop cable subscriptions. Cellular repeater rents might be one balancer. -- Howard C. Berkowitz 95 George Ryder Rd. Chatham, MA 02633 sy at netcases.net (509)241-1362 cell (866)262-6579 fax From colton.conor at gmail.com Thu Feb 14 18:50:26 2019 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 14 Feb 2019 12:50:26 -0600 Subject: Last Mile Design In-Reply-To: <000501d4c477$69d1b390$3d751ab0$@gvtc.com> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <000501d4c477$69d1b390$3d751ab0$@gvtc.com> Message-ID: Aaron, Indeed the ACX5048 is a great box but expensive. I was talking about using the Gig-e ports of a 48 port switch to face subscribers, and asking what low cost IP-Capable MPLS capable 48 port switch fits that role. Basically an access switch for AE. On Thu, Feb 14, 2019 at 9:10 AM Aaron Gould wrote: > Not sure if this is what y'all are talking about, but I use lots of > Juniper ACX5048 (previously Cisco ME3600 or ASR9000) for mpls-capable > router edging in native ip/ethernet from ftth gpon network into mpls > l2circuits and LOTS of vrf.... vrf for public ip, vrf for cgnat for private > ip, vrf for voice... I'm glad I did it. > > > Residential----- ONT-----ftth/gpon------OLT------ACX5048-----mpls/vrf > x-------cgnat/inet------ > > Residential----- DSL Modem-----DSLAM-----------ACX5048-----mpls/vrf > y-------cgnat/inet------ > > Residential----- Cable Modem-----CMTS-----------ACX5048-----mpls/vrf > z-------cgnat/inet------ > > > > -Aaron > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Thu Feb 14 18:58:42 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 14 Feb 2019 10:58:42 -0800 Subject: Last Mile Design In-Reply-To: References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <000501d4c477$69d1b390$3d751ab0$@gvtc.com> Message-ID: A much more common configuration is a combination of a low cost 48-port L2 aggregation switch, something whitebox or similar to a Taiwanese OEM/ODM such as edgecore, with a single 10GbE uplink to a small MPLS-capable router. One 10Gbps link can fit a great many 1GbE active-E residential customers in it. On Thu, Feb 14, 2019 at 10:52 AM Colton Conor wrote: > Aaron, > > Indeed the ACX5048 is a great box but expensive. I was talking about using > the Gig-e ports of a 48 port switch to face subscribers, and asking what > low cost IP-Capable MPLS capable 48 port switch fits that role. Basically > an access switch for AE. > > > > > > On Thu, Feb 14, 2019 at 9:10 AM Aaron Gould wrote: > >> Not sure if this is what y'all are talking about, but I use lots of >> Juniper ACX5048 (previously Cisco ME3600 or ASR9000) for mpls-capable >> router edging in native ip/ethernet from ftth gpon network into mpls >> l2circuits and LOTS of vrf.... vrf for public ip, vrf for cgnat for private >> ip, vrf for voice... I'm glad I did it. >> >> >> Residential----- ONT-----ftth/gpon------OLT------ACX5048-----mpls/vrf >> x-------cgnat/inet------ >> >> Residential----- DSL Modem-----DSLAM-----------ACX5048-----mpls/vrf >> y-------cgnat/inet------ >> >> Residential----- Cable Modem-----CMTS-----------ACX5048-----mpls/vrf >> z-------cgnat/inet------ >> >> >> >> -Aaron >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayb at braeburn.org Thu Feb 14 19:10:08 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Thu, 14 Feb 2019 14:10:08 -0500 Subject: AT&T/as7018 now drops invalid prefixes from peers In-Reply-To: References: <23649.35961.352370.101277@oz.mt.att.com> <20BBDC85-DFBF-4677-A347-07EC1927053A@charter.com> <23650.3306.926729.428632@oz.mt.att.com> Message-ID: <23653.48400.497054.555059@oz.mt.att.com> > Congrats Jay, this is awesome news! Thanks, Alex! > I’m interested to hear what is preventing you from creating ROAs for all of your announcements. > > > We will publish more ROAs over time. Thusfar we have been utilizing > > ARIN's hosted model, but down the road ARIN's delegated model will be > > in our future. > > > What are your main drivers for wanting to move to the delegated model? We can publish ROAs immediately for aggregate address blocks that we have been allocated if all routes are originated only by our network. But for our address allocations within which we have further assigned sub-blocks to our customers as PA space where we allow multihoming (e.g. within 12.0.0.0/8), we need to offer our downstream customers the ability to publish ROAs for their specific portions first before we publish a ROA for the aggregate, or else we'll make their announcements become invalid. Setting up that ability for our customers to publish ROAs for the PA space they receive from us will require tight integration with our customer software support systems, and perhaps also with our own certificate authority -- thus the delegated model. BTW: Alex, do you know where one might be able to get RPKI CA software? :-) Thanks. Jay B. From mehmet at akcin.net Thu Feb 14 20:05:37 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 14 Feb 2019 12:05:37 -0800 Subject: How to choose a transit provider? In-Reply-To: <4055a90d-6183-6498-f4aa-e9be7f4d6e40@seacom.mu> References: <4055a90d-6183-6498-f4aa-e9be7f4d6e40@seacom.mu> Message-ID: thanks for all feedback, I have tried to summarize my thoughts in a video, hoping this is useful set of notes https://youtu.be/4gihKxb6uys On Sat, Dec 15, 2018 at 9:46 AM Mark Tinka wrote: > > > On 15/Dec/18 19:37, nanog-isp at mail.com wrote: > > > > > I certainly subscribe to the notion that transport + transit is > usually less expensive than DIA, but this does depend on the market and > location. > > ... and the type of customer. > > DIA for a high-value "Enterprise" customer (think of a large > conglomerate) is typically more costly than DIA for a low-value > "Enterprise" customer (think of a family-owned travel & tour company). > The large global ISP's are making more money from "enterprise" business > than typical wholesale/transit services. This can support the idea that > DIA can be pricier than transit. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.leinen at switch.ch Thu Feb 14 20:42:35 2019 From: simon.leinen at switch.ch (Simon Leinen) Date: Thu, 14 Feb 2019 21:42:35 +0100 Subject: Fwd: wither cyclops? In-Reply-To: (william manning's message of "Sat, 9 Feb 2019 21:38:26 -0800") References: Message-ID: > Did this tool die on the vine? > https://cyclops.cs.ucla.edu/ Not sure I would express it that way https://www.cs.ucla.edu/thousandeyes-a-look-inside-two-ucla-alumnis-273-million-startup/ -- Simon. From swmike at swm.pp.se Thu Feb 14 20:54:30 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 14 Feb 2019 21:54:30 +0100 (CET) Subject: Last Mile Design In-Reply-To: References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> Message-ID: On Wed, 13 Feb 2019, Colton Conor wrote: > Just wondering, but what IP-capable MPLS switches are people using to > deploy AE to residential internet connections? Most 48 port AE switches > from repetuable vendors are crazy expensive, and I can't see how the ROI > would ever work compared to GPON. Why do you need MPLS? Most people just use regular L2 switches with some SAVI functionality (DHCP inspection, RA guard tec). When I did this, we happened to have an L3 switch there so I made each customer IPv6 (protocol based vlan) broadcast domain unique for each customer, and the L3 switch had built in DHCPv6-PD server. So just route a /51 to it, and it was a self contained IPv6 upstream router. For IPv4 we had a shared vlan and I didn't change that design at all. For the FTTH deployment I am currently connected to, other end of my fiber is a big L2 chassi switch (~600 ports) with 10GE uplink to somewhere, and it does SAVI and then there is some BNG somewhere at the other end of this 10GE uplink. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Thu Feb 14 20:57:46 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 14 Feb 2019 21:57:46 +0100 (CET) Subject: Last Mile Design In-Reply-To: <000501d4c477$69d1b390$3d751ab0$@gvtc.com> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <000501d4c477$69d1b390$3d751ab0$@gvtc.com> Message-ID: On Thu, 14 Feb 2019, Aaron Gould wrote: > Not sure if this is what y'all are talking about, but I use lots of Juniper ACX5048 (previously Cisco ME3600 or ASR9000) for mpls-capable router edging in native ip/ethernet from ftth gpon network into mpls l2circuits and LOTS of vrf.... vrf for public ip, vrf for cgnat for private ip, vrf for voice... I'm glad I did it. > > > Residential----- ONT-----ftth/gpon------OLT------ACX5048-----mpls/vrf x-------cgnat/inet------ > > Residential----- DSL Modem-----DSLAM-----------ACX5048-----mpls/vrf y-------cgnat/inet------ > > Residential----- Cable Modem-----CMTS-----------ACX5048-----mpls/vrf z-------cgnat/inet------ Residential----fiber media converter---L2 switch-- and then the rest of the setup you can re-use. AE isn't magic, insted of having an OLT,CMTS or DSLAM you just have an L2 ethernet switch. They're mostly just media converters anyway. 15 years ago I deployed ADSL like this: Residential---DSL modem---DSLAM----L3 switch So DSL-modem---DSLAM was just doing RFC1843bridged over ATM. Just media converters. Same thing, just different type of media converter. -- Mikael Abrahamsson email: swmike at swm.pp.se From lists.nanog at monmotha.net Thu Feb 14 21:25:15 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Thu, 14 Feb 2019 16:25:15 -0500 Subject: Last Mile Design In-Reply-To: <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> Message-ID: <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> On 2/14/19 12:08 AM, Mark Tinka wrote: > As a pure FTTH Active-E AN, I still think the Brocade (Extreme) CER/CES > is a good box. The CES is...wonky. My Foundry/Brocade/Extreme SEs have steered me away from them on more than one occasion. The CER is fine but of course more expensive. It'll take a full Internet table, though, which is handy. For AE resi deployments, I'd aggregate folks onto cheap 48 port switches then terminate onto a single pizza box router somewhere "less deep" in the network. Distributed, in-field L3 termination doesn't mean you have to terminate L3 right at the customer-facing port. -- Brandon Martin From nusenu-lists at riseup.net Thu Feb 14 21:39:00 2019 From: nusenu-lists at riseup.net (nusenu) Date: Thu, 14 Feb 2019 21:39:00 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: References: Message-ID: <2b8f9b07-27a7-08ba-ac51-afd39b30f769@riseup.net> Sriram, Kotikalapudi (Fed) (2018-09-18):> I also found your analysis very interesting and useful. Thanks for that. > >> What do you think about adding graphs that show the amount of actually >> unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists) > > I am also part of the NIST BGP team. > Doug has already responded with information that we will soon have a new version of the NIST Monitor > which will provide the kind of graphs that you requested. Can you share an estimate for when you plan to publish the new version of the NIST Monitor? thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From aaron1 at gvtc.com Thu Feb 14 22:51:06 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 14 Feb 2019 16:51:06 -0600 Subject: cgnat ams0 vrf-aware flow data export help Message-ID: <003c01d4c4b7$c5a01910$50e04b30$@gvtc.com> Need assistance with exporting flow data for inside interface of cgnat ams0 aggregated multiservice interface I have MX960 with MS-MPC-128G doing cgnat using AMS0 (aggregated multiservice of underlying mams interfaces) using next-hop-style vrf-aware cgnat. I need the cgnat inside domain interface (ams0.551) to be configured to export flow data (jflow, sflow, ipfix, whichever version i can use) to a flow collector server, this is important so we can have flow data of *pre-nat) private ip traffic. Anyone know how ? -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.joseph at gmail.com Fri Feb 15 00:01:13 2019 From: sami.joseph at gmail.com (Sami Joseph) Date: Thu, 14 Feb 2019 16:01:13 -0800 Subject: Whitebox with OSPF optics Message-ID: Hey, Have you guys seen any ODM vendor that makes platforms based on Tomahawk 3 or later OSPF optics ? Thank you Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Feb 15 07:52:18 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Feb 2019 09:52:18 +0200 Subject: BGP topological vs centralized route reflector In-Reply-To: <000301d4c476$41364e10$c3a2ea30$@gvtc.com> References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: On 14/Feb/19 17:02, Aaron Gould wrote: > To not get off-topic too much, since you mentioned MX204, please tell me, do you know if it is a nice MPLS P/PE box ? If so, is it quite capable in its ability to do L3 VPN's, L2 VPN's (l2circuit mainly, but also curious of vpls, evpn). We've started ordering them as our new peering and border routers. However, we shall also be using them as high-capacity Metro-E routers, where customers need 10Gbps hand-off, with a 100Gbps backbone. > > Actually I'm considering it as a router for my ENNI hand-offs to 3rd party neighboring networks where I hand-off vlans (double tagged) for various enterprise customers and cbh towers, etc.... then I would carry that probably in a l2circuit from that MX204 to the utter-most parts of my mpls cloud. I would want to police at that subinterface (unit) level to limit traffic for obviously what they buy. > > MX204 be good for that ? I'm sure it will be - it's an MPC7 in a cage :-). Mark. From mark.tinka at seacom.mu Fri Feb 15 07:53:18 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Feb 2019 09:53:18 +0200 Subject: Last Mile Design In-Reply-To: <000501d4c477$69d1b390$3d751ab0$@gvtc.com> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <000501d4c477$69d1b390$3d751ab0$@gvtc.com> Message-ID: <491b1365-a7a3-eddb-fa6a-f9f1679b3cdb@seacom.mu> On 14/Feb/19 17:10, Aaron Gould wrote: > Not sure if this is what y'all are talking about, but I use lots of Juniper ACX5048 (previously Cisco ME3600 or ASR9000) for mpls-capable router edging in native ip/ethernet from ftth gpon network into mpls l2circuits and LOTS of vrf.... vrf for public ip, vrf for cgnat for private ip, vrf for voice... I'm glad I did it. > > > Residential----- ONT-----ftth/gpon------OLT------ACX5048-----mpls/vrf x-------cgnat/inet------ > > Residential----- DSL Modem-----DSLAM-----------ACX5048-----mpls/vrf y-------cgnat/inet------ > > Residential----- Cable Modem-----CMTS-----------ACX5048-----mpls/vrf z-------cgnat/inet------ I've never been a fan of the ACX because of its merchant silicon. On the other hand, that makes it quite affordable. Mark. From mark.tinka at seacom.mu Fri Feb 15 07:58:35 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Feb 2019 09:58:35 +0200 Subject: Last Mile Design In-Reply-To: <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> Message-ID: <22b60c00-6844-1a66-8be2-eeb14f4cea24@seacom.mu> On 14/Feb/19 23:25, Brandon Martin wrote: >   > > The CES is...wonky.  My Foundry/Brocade/Extreme SEs have steered me > away from them on more than one occasion. > > The CER is fine but of course more expensive.  It'll take a full > Internet table, though, which is handy. > > For AE resi deployments, I'd aggregate folks onto cheap 48 port > switches then terminate onto a single pizza box router somewhere "less > deep" in the network.  Distributed, in-field L3 termination doesn't > mean you have to terminate L3 right at the customer-facing port. One of the reasons I'd pay a little extra for an Active-E FTTH-centric switch is to control bandwidth right at the port the customer connects to. Cheap Ethernet switches generally don't have this capability (or if they do, have it in only one direction). This is why I felt the CES/CER were reasonable, but purely as Layer 2 termination and not using their IP/MPLS capabilities. Anyway, it's been a while since I had any interest in this, so it's possible life has changed since I was at the beach :-). Mark. From saku at ytti.fi Fri Feb 15 08:40:59 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 15 Feb 2019 10:40:59 +0200 Subject: MX204 applications, (was about BGP RR design) In-Reply-To: References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: On Fri, Feb 15, 2019 at 9:55 AM Mark Tinka wrote: > > MX204 be good for that ? > > I'm sure it will be - it's an MPC7 in a cage :-). Anyone know why MX204 has so few ports? It seems like it only has WAN side used, leaving FAB side entirely unused, throwing away 50% of free capacity. MX80/MX104 have both sides for revenue ports. I would GLADLY take 50% more ports in MX204, without taking any more PPS or QoS bandwidth. Is this because we as a community are so anal towards vendors about PPS performance that JNPR marketing forbade them making pizza-box MPC7 using all the capacity in fears of people being angry about not being able to do good PPS on all ports? As far as I understand, it would have been zero cost to have double ports in MX204, if you don't want to use them, there is capex efficient vendor-agnostic, single-spare solution[0] to turn any platform back into full PPS platform. I want my free ports, in metro application you are limited by your east+west capacity and you can never see more PPS, but you want to add more edges. [0] http://z.ip.fi/BVLE -- ++ytti From mark.tinka at seacom.mu Fri Feb 15 08:53:27 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Feb 2019 10:53:27 +0200 Subject: MX204 applications, (was about BGP RR design) In-Reply-To: References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: On 15/Feb/19 10:40, Saku Ytti wrote: > Is this because we as a community are so anal towards vendors about > PPS performance that JNPR marketing forbade them making pizza-box MPC7 > using all the capacity in fears of people being angry about not being > able to do good PPS on all ports? > > As far as I understand, it would have been zero cost to have double > ports in MX204, if you don't want to use them, there is capex > efficient vendor-agnostic, single-spare solution[0] to turn any > platform back into full PPS platform. > I want my free ports, in metro application you are limited by your > east+west capacity and you can never see more PPS, but you want to add > more edges. I'm with you - but from what I can imagine, Juniper did not envisage this box being used in high-density Metro-E applications (which I wouldn't mind doing by planting a bunch of customers on 10Gbps that, in an ideal world, would oversubscribe the 100Gbps uplinks, but in real life, won't). If someone from Juniper is reading this thread, I'd take the feedback and have an "MX204-ME" style box designed with more port density on the platform without having to increase pps or the uplink. Mark. From phil.lavin at cloudcall.com Fri Feb 15 08:54:31 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Fri, 15 Feb 2019 08:54:31 +0000 Subject: MX204 applications, (was about BGP RR design) In-Reply-To: References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: > Anyone know why MX204 has so few ports? It seems like it only has WAN side used, leaving FAB side entirely unused, throwing away 50% of free capacity. The usable port configs are also quite tricky. Juniper have had to make a tool to validate the configurations (https://apps.juniper.net/home/port-checker/). For example, using 4x40G disables all of the 10G ports however using 3x40G and 1x100G gives you all of the 10G ports > MX80/MX104 have both sides for revenue ports. They are, however, not Trio - rather just commodity CPUs. Routing re-convergence times are shockingly high - in the region of 5-10 minutes for MX80 with a full table vs 30 seconds (ish) for 204 > I would GLADLY take 50% more ports in MX204, without taking any more PPS or QoS bandwidth. You can add switches (EX or QFX) as line cards using Fusion, to add more port density. I've heard some good things about Fusion, though I'm always wary of proprietary clustering technology having been bitten by VC a few times. You can also just trunk some VLANs up to switches if you don't want to buy the Fusion license From saku at ytti.fi Fri Feb 15 08:57:38 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 15 Feb 2019 10:57:38 +0200 Subject: MX204 applications, (was about BGP RR design) In-Reply-To: References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: On Fri, Feb 15, 2019 at 10:54 AM Phil Lavin wrote: > > MX80/MX104 have both sides for revenue ports. > > They are, however, not Trio - rather just commodity CPUs. Routing re-convergence times are shockingly high - in the region of 5-10 minutes for MX80 with a full table vs 30 seconds (ish) for 204 They are normal 1st gen trio boxes, same as MPC1, MPC2, MPC3 originals were. You may be confused about the fact that their control plane is freescale, instead of intel. -- ++ytti From mark.tinka at seacom.mu Fri Feb 15 09:00:10 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Feb 2019 11:00:10 +0200 Subject: MX204 applications, (was about BGP RR design) In-Reply-To: References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: On 15/Feb/19 10:54, Phil Lavin wrote: > They are, however, not Trio - rather just commodity CPUs. Routing re-convergence times are shockingly high - in the region of 5-10 minutes for MX80 with a full table vs 30 seconds (ish) for 204 They are Trio. It's the control plane which is not Intel... Freescale. > You can add switches (EX or QFX) as line cards using Fusion, to add more port density. I've heard some good things about Fusion, though I'm always wary of proprietary clustering technology having been bitten by VC a few times. You can also just trunk some VLANs up to switches if you don't want to buy the Fusion license Nasty, but doable (with or without Fusion). I'd prefer not to, but I'm getting old so my resolve could be questioned :-). Mark. From phil.lavin at cloudcall.com Fri Feb 15 09:03:55 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Fri, 15 Feb 2019 09:03:55 +0000 Subject: MX204 applications, (was about BGP RR design) In-Reply-To: References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: > They are normal 1st gen trio boxes, same as MPC1, MPC2, MPC3 originals were. You may be confused about the fact that their control plane is freescale, instead of intel. Sorry, yes - you're right. Re-convergence times are, however, still awful. Though if you're not handling a lot of routes, that may not be a huge problem for you From ahebert at pubnix.net Fri Feb 15 11:59:51 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 15 Feb 2019 06:59:51 -0500 Subject: Last Mile Design In-Reply-To: <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> Message-ID: <2a8cb8b5-e770-62d0-1a36-01c7bf748e81@pubnix.net>     Not all gen of CER takes full routes.     I got a pair of 1gen here with 512k FIB. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 2/14/19 4:25 PM, Brandon Martin wrote: > On 2/14/19 12:08 AM, Mark Tinka wrote: >> As a pure FTTH Active-E AN, I still think the Brocade (Extreme) CER/CES >> is a good box. > > The CES is...wonky.  My Foundry/Brocade/Extreme SEs have steered me > away from them on more than one occasion. > > The CER is fine but of course more expensive.  It'll take a full > Internet table, though, which is handy. > > For AE resi deployments, I'd aggregate folks onto cheap 48 port > switches then terminate onto a single pizza box router somewhere "less > deep" in the network.  Distributed, in-field L3 termination doesn't > mean you have to terminate L3 right at the customer-facing port. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougm at nist.gov Fri Feb 15 12:50:37 2019 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Fri, 15 Feb 2019 12:50:37 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? Message-ID: <3E33FB38-EEA8-4FCE-9F8C-710301A1D975@nist.gov> Our effort to get our new monitor transitioned to a public facing system ran into a wall for ~35 days. Unfortunately during that time, the visa of a visiting researcher leading that effort expired. We have almost recovered from all of that. Unfortunately, we have a bit of a bureaucracy to deploying public facing systems. So I would guess it will take ~end of March to get it on-line. Thanks DougM -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST Date: Thu, 14 Feb 2019 21:39:00 +0000 From: nusenu To: "Sriram, Kotikalapudi (Fed)" Cc: rpki-monitor , "nanog at nanog.org" , "Montgomery, Douglas (Fed)" Subject: Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? Message-ID: <2b8f9b07-27a7-08ba-ac51-afd39b30f769 at riseup.net> Content-Type: text/plain; charset="utf-8" Sriram, Kotikalapudi (Fed) (2018-09-18):> I also found your analysis very interesting and useful. Thanks for that. > >> What do you think about adding graphs that show the amount of actually >> unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists) > > I am also part of the NIST BGP team. > Doug has already responded with information that we will soon have a new version of the NIST Monitor > which will provide the kind of graphs that you requested. Can you share an estimate for when you plan to publish the new version of the NIST Monitor? thanks, nusenu From colton.conor at gmail.com Fri Feb 15 13:06:16 2019 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 15 Feb 2019 07:06:16 -0600 Subject: Last Mile Design In-Reply-To: <22b60c00-6844-1a66-8be2-eeb14f4cea24@seacom.mu> References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> <22b60c00-6844-1a66-8be2-eeb14f4cea24@seacom.mu> Message-ID: Well the CES is EOLed. ACX5048 can be had for around $10k, so not cheap for residential customers but fine for upstream aggregation. On Fri, Feb 15, 2019 at 2:00 AM Mark Tinka wrote: > > > On 14/Feb/19 23:25, Brandon Martin wrote: > > > > > > > The CES is...wonky. My Foundry/Brocade/Extreme SEs have steered me > > away from them on more than one occasion. > > > > The CER is fine but of course more expensive. It'll take a full > > Internet table, though, which is handy. > > > > For AE resi deployments, I'd aggregate folks onto cheap 48 port > > switches then terminate onto a single pizza box router somewhere "less > > deep" in the network. Distributed, in-field L3 termination doesn't > > mean you have to terminate L3 right at the customer-facing port. > > One of the reasons I'd pay a little extra for an Active-E FTTH-centric > switch is to control bandwidth right at the port the customer connects > to. Cheap Ethernet switches generally don't have this capability (or if > they do, have it in only one direction). This is why I felt the CES/CER > were reasonable, but purely as Layer 2 termination and not using their > IP/MPLS capabilities. > > Anyway, it's been a while since I had any interest in this, so it's > possible life has changed since I was at the beach :-). > > Mark. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Feb 15 13:09:03 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Feb 2019 15:09:03 +0200 Subject: Last Mile Design In-Reply-To: References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> <22b60c00-6844-1a66-8be2-eeb14f4cea24@seacom.mu> Message-ID: <29291a0d-8715-1ea0-0975-ffd11f2cd0c8@seacom.mu> On 15/Feb/19 15:06, Colton Conor wrote: > Well the CES is EOLed. Like I said, been a while. But with a quick scan over the years, nothing is blowing my skirt up. > > ACX5048 can be had for around $10k, so not cheap for residential > customers but fine for upstream aggregation. You need wine you vendors :-). Mark. From mark.tinka at seacom.mu Fri Feb 15 13:15:45 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Feb 2019 15:15:45 +0200 Subject: Last Mile Design In-Reply-To: References: <930b0454-e97a-d353-667e-423c826a89c1@monmotha.net> <1d9d490d-7e3a-a895-dd6e-2afb18bcf72b@seacom.mu> <57a77cba-d081-3e1a-6b4d-8a32f39178ee@monmotha.net> <90627d63-e25e-e674-9ca7-bb2558959b4e@seacom.mu> <63ab87e0-4c10-5dc1-0b91-992ea73148d3@seacom.mu> <37b01678-bf11-b723-c35f-8c13e0a84e4a@monmotha.net> <22b60c00-6844-1a66-8be2-eeb14f4cea24@seacom.mu> Message-ID: On 15/Feb/19 15:06, Colton Conor wrote: > Well the CES is EOLed. Like I said, been a while. But with a quick scan over the years, nothing is blowing my skirt up. > ACX5048 can be had for around $10k, so not cheap for residential > customers but fine for upstream aggregation. You need to wine you vendors :-). Mark. From ercin.torun at turkcell.com.tr Fri Feb 15 05:35:32 2019 From: ercin.torun at turkcell.com.tr (ERCIN TORUN) Date: Fri, 15 Feb 2019 05:35:32 +0000 Subject: Whitebox with OSPF optics In-Reply-To: References: Message-ID: <858ad312ccfd4506aefbedd6bfb82c8c@turkcell.com.tr> Hello Sami, Edgecore (Accton) announced A9716-32X last year but it is not available on their web page, seems like they contributed the design to the OCP but not on sale yet. https://www.opencompute.org/products/270/edgecore-networks-as9700-32x-400g-open-networking-switch Regards Erçin TORUN From: NANOG On Behalf Of Sami Joseph Sent: Friday, February 15, 2019 3:01 AM To: nanog at nanog.org Subject: Whitebox with OSPF optics Hey, Have you guys seen any ODM vendor that makes platforms based on Tomahawk 3 or later OSPF optics ? Thank you Sam [http://www.turkcell.com.tr/downloads/bireysel/img/Tcelldis.gif] Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir. TURKCELL bu mesajin icerdigi bilgilerin doğruluğu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve TURKCELLin goruslerini yansitmayabilir Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. ________________________________ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TURKCELL. This e-mail has been scanned for all known computer viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From universe at truemetal.org Fri Feb 15 15:36:47 2019 From: universe at truemetal.org (Markus) Date: Fri, 15 Feb 2019 16:36:47 +0100 Subject: OT/venting: RIPE legal - please stop this madness! Message-ID: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> Hi list! The following is off-topic/venting. It's about RIPE and my company in Germany. If you don't care about this even remotely, don't read on and don't flame me. I'm just so pissed and I have no other connection to the ISP (and related) community than the NANOG mailing list and I know there are some other European ISPs on this list. Here goes: My company has been a RIPE LIR for 17 years now. This week was the first time ever that I became, was and still am really, really pissed at RIPE. There's some madness going on in RIPEs legal department. It appears they recently hired some retard who now wants to prove he/she is a smartass. Harsh words, but I have no other explanation for what's going on right now! Here's the story: Sunday, 10th February, 17:08 CET: I sent away the online application for an additional LIR account. Automatic E-Mail confirmation received. Monday, 11th February, 15:07 CET: I didn't receive a human reply yet, and since the business day was nearing its end, I mailed them about the status, and asked whether I could come by their Amsterdam office the next day to sign the required documents - in order to speed up the whole process. Monday, 11th February, 15:57 CET: Reply from RIPE. Let me just copy and paste: "I regret to inform you that we do not offer the possibility to sign your contracts in our office and regrettably there is no option to speed up the application procedure." - Ok, no biggie. But then: Quote start. "We can see that this is an additional LIR account for Lightup Network Solutions GmbH & Co. KG. We are currently reviewing applications with a legal entity type 'GmbH & Co. KG' together with our legal department and they have stated the following: "GmbH & Co. KG" is a sub-form of a "KG" (partnership). It normally consists of a general partner and one or more limited partners, which can be legal or natural persons. According to "Due Diligence for the Quality of the RIPE NCC Registration Data" the signing party of an agreement can either be a legal or a natural person. A "KG" is not considered a legal person and cant be the signing party in our agreements. The agreement can be signed though by one of the legal or natural persons that are partners (general or limited). We therefore cannot register Lightup Network Solutions GmbH & Co. KG. As you already have an LIR account with us, we will have to update your existing account, de.lightupnet, before we can register this second account for Lightup Network Solutions GmbH & Co. KG. I created a new ticket for your company update and my colleagues will contact you shortly for the update." Quote end. That didn't sound so good. I've had a company with the legal form GmbH & Co. KG (it's a German company) for about 15 years now and my initial gut feeling was "That's just plain bullsh*t!". Tuesday, 12th February, 12:30: I receive another E-Mail. New ticket, as they promised. Quote start. "It has come to our attention, that the legal name of your LIR account has been registered incorrectly. It was advised by our Legal Department that the legal form of your company as "GmbH & Co. KG" is a form of a general partnership that does not have a legal personality. If there is a document proving opposite, please send it to us. According to our procedure, we can only sign an agreement with a legal person that has a legal personality or a natural person. Therefore, we will have to correct your legal name to , instead of ." Quote end. They also asked that I upload a photo/scan of my passport, which I did. I just thought: Ok, let them have their way. If they want to change my LIRs description, who really cares. All I want is to create a 2nd LIR and speed this whole thing up. But, since they want to be SO LEGALLY CORRECT, I replied and mentioned the following. Let me copy and paste. Quote start. "I just uploaded my passport. However, following your logic, you need to change all of the following German legal forms in your database to "Individual-name trading as ...": - OHG - KG - GmbH & Co. OHG - GmbH & Co. KG I understand that you would have to do that with a GbR, as a GbR cannot get registered in the commercial register of companies and you need to specify the names of the individuals. But I think with the above 4 legal forms you are making as mistake here. Although it is correct that a GmbH & Co. KG does not have a legal personality that differs from its general partners (Persoenlich haftende Gesellschafterin) or limited partners (Kommanditist), a GmbH & Co. KG is still a legal entity as its able to sue in front of court, or get sued in front of court. A GmbH & Co. KG can also purchase rights and enter into liabilities, can purchase property and other in rem rights related to estates. (Source: ) That being said, since Lightup Network Solutions GmbH & Co. KG was founded, I have never ever signed a contract where the contractual partner was "Markus Stalder trading as Lightup Network Solutions GmbH & Co. KG" but the contractual partner was always Lightup Network Solutions GmbH & Co. KG. That includes application forms towards government entities as well as contracts with larger corporations. Actually, my gut feeling based on my own experience with my GmbH & Co. KG in the last decades tells me that you are making a mistake here. And, if you want to be really accurate: You must be aware that the Kommanditist (limited partner) is not allowed to represent the company. That is something only the Komplementaerin (general partner) can do. The general partner of Lightup Network Solutions GmbH & Co. KG is AirAccess GmbH. I'm attaching both company extracts for your convenience. So, correct would be: AirAccess GmbH trading as Lightup Network Solutions GmbH & Co. KG" Quote end. Wednesday, 13th February, 18:02: Reply from RIPE: Quote start: "Many thanks for the clarification and the provided documents. Please be informed that our Due Diligence for the Quality of the RIPE NCC Registration Data has been implemented in 2018. As the application process for our members was not so strict before, it was possible to register an LIR account under the partnership name. Currently, we are working on correcting these details in the Database. At this moment we are reviewing German applications with a legal entity type 'GmbH & Co. KG' together with our legal department. Thus the information you provided is very helpful. On the review the documents you submitted, we indeed can see that "AirAccess GmbH" is a general partner with a special right to represent the company. The names of both LIR accounts (de.lightupnet, de.lightupnet1) will be corrected tomorrow. It will be confirmed to you once the account are updated." Quote end. ... another day passes ... Thursday, 14th February, 16:11: Now for the E-Mail from RIPE that blew my mind, in a negative sense. Quote start: "Many thanks for your patience. We have reviewed your case internally and agreed that there is no need to sign a new agreement for LIR account , as it was signed by the director of the company. It has also come to our attention that, the company AirAccess GmbH (reg. No HRB 56386) already has LIR account . Therefore LIR should be linked as an additional account to , and . Please be informed that the following will be applied to all additional LIR accounts: - The /22 IPv4 allocation you will receive is subject to the RIPE NCC Transfer Policy and can therefore only be transferred 24 months after the allocation date. - Members with multiple LIR accounts are entitled to just one vote at RIPE NCC General Meetings. The oldest LIR account will receive the vote. - If you wish to transfer internet resources between your LIR accounts, you need to pay the full annual service fee for all LIR accounts. - If you wish to close LIR account, you need to pay the full annual service fee for all LIR accounts. At this moment could you please inform us what name you prefer for LIR accounts , : "AirAccess GmbH" or "AirAccess GmbH trading us Lightup Network Solutions GmbH & Co. KG"? Once it is clarified, we will proceed with updating the legal details of your accounts and process the application for ." Quote end. Spontaneous thought: HOLY F*CK, ARE THEY SERIOUS ?! ?! ?! They want to change the name of my company - Lightup Network Solutions GmbH & Co. KG - to a completely different company: AirAccess GmbH !!! Totally unrelated to each other, different business, different everything. The only thing these two companies have in common is that they're both mine. RIPE MUST BE NUTS! Here my reply: Quote start. "Hi , thanks for your mail. Ok, now you are really taking it over the top. 1) You want to link AirAccess GmbH as an additional account to de.lightupnet. And you want to do this for a company which is a legal entity by itself. I do not allow you to do this. AirAccess GmbH is a legal entity by itself and I do not want that you change anything about its current LIR status, name or anything else. 2) You are offering that I can choose the name for de.lightupnet and de.lightupnet1 to be "AirAccess GmbH", a company which is an entity by itself and is merely the Komplementaerin (general partner) for Lightup Network Solutions GmbH & GmbH Co. KG. I'm shocked by that idea. That is just completely wrong. Of course I do NOT want de.lightupnet and de.lightupnet1 to be named "AirAccess GmbH" because it would be an factual error. And I don't want RIPE to make wrong statements about our company/companies towards the public. It would be like offering to present nl.ripe as KPN. Or Nike as Adidas. As it appears right now your legal department is doing a mistake when it comes to understanding how GmbH + Co. KGs work. Could you also please let me know the E-Mail address or telephone number where I can file a complaint about this whole procedure? Thank you." Quote end. This is where it stands right now. It's Friday, 15th February. The work week is over. I'm sitting here, waiting for RIPE since Monday to send me the LIR agreement for the 2nd LIR, so that I can sign it, pay it, and be done with it. My rhetorical questions are: 1) Are they fucking serious ... I can't remember the last time I was this angry at anyone. 2) It's RIPE. A large, established organisation that's been around forever. WHY THE F*CK does it take them always 1 day to process something, to reply to something? They have TONS of employees, they have TONS of LIRs that pay them TONS of money, why is everything moving so slowly with them ?! ?! ?! It's 2019, not 1995 FOR F*CKS SAKE !!! Get your act together and adapt to the times, modernize yourself and BE FASTER. UARRRGHHHL. 3) Why in heavens name do they EXACTLY have to start with this whole f*cked-up process when I ACTUALLY need something from them (a 2nd LIR account)? Why in this very moment? Yeah, because my company popped up on their screen because I applied for a 2nd LIR account, makes sense. But, could they not simply process the damn LIR application at the same time to speed this whole thing up, and later change this sh*t. No, of course, it would be not efficient for them to do that, but it's NOT MY FAULT they didn't ask to update this data/fix this company sh*t earlier. But now THEY MAKE IT MY PROBLEM. Because I'm losing precious time. F*CK! 4) If you look at the LIR list for Germany here - - and search for "GmbH & Co. KG" in the document, you will see many companies that are still "unchanged": Company name GmbH & Co. KG, but you will also see some that were already "updated" according to RIPE logic: "Firstname Lastname trading as "Company GmbH & Co. KG" - the "funny" thing is that this is just wrong as I explained earlier. They have to re-do all these changes. By looking at this list it appears I'm the first where they offer to change it to "Another-company-name GmbH trading as Company GmbH & Co. KG" JUST BECAUSE I told them that with GmbH & Co. KGs the Kommanditist (legal partner) is not allowed to represent the company. So, being the first, and looking at that list for comparison tells me they have no idea what they are doing! Have a good day everyone and down with unnecessary, over-the-top bureaucracy! It's 2019 FOR F*CKS SAKE!!! Regards Markus From mel at beckman.org Fri Feb 15 15:46:55 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 15 Feb 2019 15:46:55 +0000 Subject: OT/venting: RIPE legal - please stop this madness! In-Reply-To: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> References: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> Message-ID: <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org> Sorry, but not only is your giant bolus of a rant not operational, it’s not even North American. Please respect the boundaries of our group and keep your venting in Europe where it belongs. This isn’t a flame, it’s just a polite request that you knock it off. -mel beckman > On Feb 15, 2019, at 7:37 AM, Markus wrote: > > Hi list! > > The following is off-topic/venting. It's about RIPE and my company in Germany. If you don't care about this even remotely, don't read on and don't flame me. I'm just so pissed and I have no other connection to the ISP (and related) community than the NANOG mailing list and I know there are some other European ISPs on this list. Here goes: > > > My company has been a RIPE LIR for 17 years now. This week was the first time ever that I became, was and still am really, really pissed at RIPE. > > There's some madness going on in RIPEs legal department. It appears they recently hired some retard who now wants to prove he/she is a smartass. Harsh words, but I have no other explanation for what's going on right now! > > Here's the story: > > Sunday, 10th February, 17:08 CET: I sent away the online application for an additional LIR account. Automatic E-Mail confirmation received. > > Monday, 11th February, 15:07 CET: I didn't receive a human reply yet, and since the business day was nearing its end, I mailed them about the status, and asked whether I could come by their Amsterdam office the next day to sign the required documents - in order to speed up the whole process. > > Monday, 11th February, 15:57 CET: Reply from RIPE. Let me just copy and paste: "I regret to inform you that we do not offer the possibility to sign your contracts in our office and regrettably there is no option to speed up the application procedure." - Ok, no biggie. But then: > > > Quote start. > > "We can see that this is an additional LIR account for Lightup Network Solutions GmbH & Co. KG. > > We are currently reviewing applications with a legal entity type 'GmbH & Co. KG' together with our legal department and they have stated the following: "GmbH & Co. KG" is a sub-form of a "KG" (partnership). > > It normally consists of a general partner and one or more limited partners, which can be legal or natural persons. > > According to "Due Diligence for the Quality of the RIPE NCC Registration Data" the signing party of an agreement can either be a legal or a natural person. A "KG" is not considered a legal person and cant be the signing party in our agreements. > > The agreement can be signed though by one of the legal or natural persons that are partners (general or limited). We therefore cannot register Lightup Network Solutions GmbH & Co. KG. > > As you already have an LIR account with us, we will have to update your existing account, de.lightupnet, before we can register this second account for Lightup Network Solutions GmbH & Co. KG. > > I created a new ticket for your company update and my colleagues will contact you shortly for the update." > > Quote end. > > > That didn't sound so good. I've had a company with the legal form GmbH & Co. KG (it's a German company) for about 15 years now and my initial gut feeling was "That's just plain bullsh*t!". > > > Tuesday, 12th February, 12:30: I receive another E-Mail. New ticket, as they promised. > > > Quote start. > > "It has come to our attention, that the legal name of your LIR account has been registered incorrectly. > > It was advised by our Legal Department that the legal form of your company as "GmbH & Co. KG" is a form of a general partnership that does not have a legal personality. > > If there is a document proving opposite, please send it to us. According to our procedure, we can only sign an agreement with a legal person that has a legal personality or a natural person. > > Therefore, we will have to correct your legal name to , instead of ." > > Quote end. > > > They also asked that I upload a photo/scan of my passport, which I did. I just thought: Ok, let them have their way. If they want to change my LIRs description, who really cares. All I want is to create a 2nd LIR and speed this whole thing up. But, since they want to be SO LEGALLY CORRECT, I replied and mentioned the following. Let me copy and paste. > > > Quote start. > > "I just uploaded my passport. > > However, following your logic, you need to change all of the following German legal forms in your database to "Individual-name trading as ...": > > - OHG > - KG > - GmbH & Co. OHG > - GmbH & Co. KG > > I understand that you would have to do that with a GbR, as a GbR cannot get registered in the commercial register of companies and you need to specify the names of the individuals. But I think with the above 4 legal forms you are making as mistake here. > > Although it is correct that a GmbH & Co. KG does not have a legal personality that differs from its general partners (Persoenlich haftende Gesellschafterin) or limited partners (Kommanditist), a GmbH & Co. KG is still a legal entity as its able to sue in front of court, or get sued in front of court. A GmbH & Co. KG can also purchase rights and enter into liabilities, can purchase property and other in rem rights related to estates. (Source: ) > > That being said, since Lightup Network Solutions GmbH & Co. KG was founded, I have never ever signed a contract where the contractual partner was "Markus Stalder trading as Lightup Network Solutions GmbH & Co. KG" but the contractual partner was always Lightup Network Solutions GmbH & Co. KG. That includes application forms towards government entities as well as contracts with larger corporations. > > Actually, my gut feeling based on my own experience with my GmbH & Co. KG in the last decades tells me that you are making a mistake here. > > And, if you want to be really accurate: You must be aware that the Kommanditist (limited partner) is not allowed to represent the company. That is something only the Komplementaerin (general partner) can do. The general partner of Lightup Network Solutions GmbH & Co. KG is AirAccess GmbH. > > I'm attaching both company extracts for your convenience. > > So, correct would be: > > AirAccess GmbH trading as Lightup Network Solutions GmbH & Co. KG" > > Quote end. > > > Wednesday, 13th February, 18:02: Reply from RIPE: > > > Quote start: > > "Many thanks for the clarification and the provided documents. > > Please be informed that our Due Diligence for the Quality of the RIPE NCC Registration Data has been implemented in 2018. As the application process for our members was not so strict before, it was possible to register an LIR account under the partnership name. Currently, we are working on correcting these details in the Database. > > At this moment we are reviewing German applications with a legal entity type 'GmbH & Co. KG' together with our legal department. Thus the information you provided is very helpful. > > On the review the documents you submitted, we indeed can see that "AirAccess GmbH" is a general partner with a special right to represent the company. The names of both LIR accounts (de.lightupnet, de.lightupnet1) will be corrected tomorrow. It will be confirmed to you once the account are updated." > > Quote end. > > > ... another day passes ... > > > Thursday, 14th February, 16:11: Now for the E-Mail from RIPE that blew my mind, in a negative sense. > > > Quote start: > > "Many thanks for your patience. > > We have reviewed your case internally and agreed that there is no need to sign a new agreement for LIR account , as it was signed by the director of the company. > > It has also come to our attention that, the company AirAccess GmbH (reg. No HRB 56386) already has LIR account . > > Therefore LIR should be linked as an additional account to , and . > > Please be informed that the following will be applied to all additional LIR accounts: > > - The /22 IPv4 allocation you will receive is subject to the RIPE NCC > Transfer Policy and can therefore only be transferred 24 months after the > allocation date. > - Members with multiple LIR accounts are entitled to just one vote at RIPE > NCC General Meetings. The oldest LIR account will receive the vote. > - If you wish to transfer internet resources between your LIR accounts, > you need to pay the full annual service fee for all LIR accounts. > - If you wish to close LIR account, you need to pay the full annual > service fee for all LIR accounts. > > At this moment could you please inform us what name you prefer for LIR accounts , : "AirAccess GmbH" or "AirAccess GmbH trading us Lightup Network Solutions GmbH & Co. KG"? > > Once it is clarified, we will proceed with updating the legal details of your accounts and process the application for ." > > Quote end. > > > Spontaneous thought: HOLY F*CK, ARE THEY SERIOUS ?! ?! ?! They want to change the name of my company - Lightup Network Solutions GmbH & Co. KG - to a completely different company: AirAccess GmbH !!! Totally unrelated to each other, different business, different everything. The only thing these two companies have in common is that they're both mine. RIPE MUST BE NUTS! Here my reply: > > > Quote start. > > "Hi , > > thanks for your mail. > > Ok, now you are really taking it over the top. > > 1) You want to link AirAccess GmbH as an additional account to de.lightupnet. And you want to do this for a company which is a legal entity by itself. > > I do not allow you to do this. AirAccess GmbH is a legal entity by itself and I do not want that you change anything about its current LIR status, name or anything else. > > 2) You are offering that I can choose the name for de.lightupnet and de.lightupnet1 to be "AirAccess GmbH", a company which is an entity by itself and is merely the Komplementaerin (general partner) for Lightup Network Solutions GmbH & GmbH Co. KG. > > I'm shocked by that idea. That is just completely wrong. > > Of course I do NOT want de.lightupnet and de.lightupnet1 to be named "AirAccess GmbH" because it would be an factual error. And I don't want RIPE to make wrong statements about our company/companies towards the public. > > It would be like offering to present nl.ripe as KPN. Or Nike as Adidas. > > As it appears right now your legal department is doing a mistake when it comes to understanding how GmbH + Co. KGs work. > > Could you also please let me know the E-Mail address or telephone number where I can file a complaint about this whole procedure? > > Thank you." > > Quote end. > > > This is where it stands right now. > > It's Friday, 15th February. > > The work week is over. > > I'm sitting here, waiting for RIPE since Monday to send me the LIR agreement for the 2nd LIR, so that I can sign it, pay it, and be done with it. > > > My rhetorical questions are: > > 1) Are they fucking serious ... I can't remember the last time I was this angry at anyone. > > 2) It's RIPE. A large, established organisation that's been around forever. WHY THE F*CK does it take them always 1 day to process something, to reply to something? They have TONS of employees, they have TONS of LIRs that pay them TONS of money, why is everything moving so slowly with them ?! ?! ?! It's 2019, not 1995 FOR F*CKS SAKE !!! Get your act together and adapt to the times, modernize yourself and BE FASTER. UARRRGHHHL. > > 3) Why in heavens name do they EXACTLY have to start with this whole f*cked-up process when I ACTUALLY need something from them (a 2nd LIR account)? Why in this very moment? Yeah, because my company popped up on their screen because I applied for a 2nd LIR account, makes sense. But, could they not simply process the damn LIR application at the same time to speed this whole thing up, and later change this sh*t. No, of course, it would be not efficient for them to do that, but it's NOT MY FAULT they didn't ask to update this data/fix this company sh*t earlier. But now THEY MAKE IT MY PROBLEM. Because I'm losing precious time. F*CK! > > 4) If you look at the LIR list for Germany here - - and search for "GmbH & Co. KG" in the document, you will see many companies that are still "unchanged": Company name GmbH & Co. KG, but you will also see some that were already "updated" according to RIPE logic: "Firstname Lastname trading as "Company GmbH & Co. KG" - the "funny" thing is that this is just wrong as I explained earlier. They have to re-do all these changes. By looking at this list it appears I'm the first where they offer to change it to "Another-company-name GmbH trading as Company GmbH & Co. KG" JUST BECAUSE I told them that with GmbH & Co. KGs the Kommanditist (legal partner) is not allowed to represent the company. So, being the first, and looking at that list for comparison tells me they have no idea what they are doing! > > > Have a good day everyone and down with unnecessary, over-the-top > bureaucracy! It's 2019 FOR F*CKS SAKE!!! > > > Regards > Markus From job at instituut.net Fri Feb 15 15:50:30 2019 From: job at instituut.net (Job Snijders) Date: Fri, 15 Feb 2019 09:50:30 -0600 Subject: OT/venting: RIPE legal - please stop this madness! In-Reply-To: <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org> References: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org> Message-ID: Dear Markus, I think you are better off taking a deep breath, perhaps removing some strongly worded sentences, and bring up the topic on one of the RIPE mailing lists: https://www.ripe.net/participate/mail/ripe-mailing-lists/ripe-list Kind regards, Job On Fri, Feb 15, 2019 at 9:47 Mel Beckman wrote: > Sorry, but not only is your giant bolus of a rant not operational, it’s > not even North American. Please respect the boundaries of our group and > keep your venting in Europe where it belongs. This isn’t a flame, it’s just > a polite request that you knock it off. > > -mel beckman > > > On Feb 15, 2019, at 7:37 AM, Markus wrote: > > > > Hi list! > > > > The following is off-topic/venting. It's about RIPE and my company in > Germany. If you don't care about this even remotely, don't read on and > don't flame me. I'm just so pissed and I have no other connection to the > ISP (and related) community than the NANOG mailing list and I know there > are some other European ISPs on this list. Here goes: > > > > > > My company has been a RIPE LIR for 17 years now. This week was the first > time ever that I became, was and still am really, really pissed at RIPE. > > > > There's some madness going on in RIPEs legal department. It appears they > recently hired some retard who now wants to prove he/she is a smartass. > Harsh words, but I have no other explanation for what's going on right now! > > > > Here's the story: > > > > Sunday, 10th February, 17:08 CET: I sent away the online application for > an additional LIR account. Automatic E-Mail confirmation received. > > > > Monday, 11th February, 15:07 CET: I didn't receive a human reply yet, > and since the business day was nearing its end, I mailed them about the > status, and asked whether I could come by their Amsterdam office the next > day to sign the required documents - in order to speed up the whole process. > > > > Monday, 11th February, 15:57 CET: Reply from RIPE. Let me just copy and > paste: "I regret to inform you that we do not offer the possibility to sign > your contracts in our office and regrettably there is no option to speed up > the application procedure." - Ok, no biggie. But then: > > > > > > Quote start. > > > > "We can see that this is an additional LIR account for Lightup Network > Solutions GmbH & Co. KG. > > > > We are currently reviewing applications with a legal entity type 'GmbH & > Co. KG' together with our legal department and they have stated the > following: "GmbH & Co. KG" is a sub-form of a "KG" (partnership). > > > > It normally consists of a general partner and one or more limited > partners, which can be legal or natural persons. > > > > According to "Due Diligence for the Quality of the RIPE NCC Registration > Data" the signing party of an agreement can either be a legal or a natural > person. A "KG" is not considered a legal person and cant be the signing > party in our agreements. > > > > The agreement can be signed though by one of the legal or natural > persons that are partners (general or limited). We therefore cannot > register Lightup Network Solutions GmbH & Co. KG. > > > > As you already have an LIR account with us, we will have to update your > existing account, de.lightupnet, before we can register this second account > for Lightup Network Solutions GmbH & Co. KG. > > > > I created a new ticket for your company update and my colleagues will > contact you shortly for the update." > > > > Quote end. > > > > > > That didn't sound so good. I've had a company with the legal form GmbH & > Co. KG (it's a German company) for about 15 years now and my initial gut > feeling was "That's just plain bullsh*t!". > > > > > > Tuesday, 12th February, 12:30: I receive another E-Mail. New ticket, as > they promised. > > > > > > Quote start. > > > > "It has come to our attention, that the legal name of your LIR account > has been registered incorrectly. > > > > It was advised by our Legal Department that the legal form of your > company as "GmbH & Co. KG" is a form of a general partnership that does not > have a legal personality. > > > > If there is a document proving opposite, please send it to us. According > to our procedure, we can only sign an agreement with a legal person that > has a legal personality or a natural person. > > > > Therefore, we will have to correct your legal name to trading as "Lightup Network Solutions GmbH & Co. KG">, instead of Network Solutions GmbH & Co. KG>." > > > > Quote end. > > > > > > They also asked that I upload a photo/scan of my passport, which I did. > I just thought: Ok, let them have their way. If they want to change my LIRs > description, who really cares. All I want is to create a 2nd LIR and speed > this whole thing up. But, since they want to be SO LEGALLY CORRECT, I > replied and mentioned the following. Let me copy and paste. > > > > > > Quote start. > > > > "I just uploaded my passport. > > > > However, following your logic, you need to change all of the following > German legal forms in your database to "Individual-name trading as ...": > > > > - OHG > > - KG > > - GmbH & Co. OHG > > - GmbH & Co. KG > > > > I understand that you would have to do that with a GbR, as a GbR cannot > get registered in the commercial register of companies and you need to > specify the names of the individuals. But I think with the above 4 legal > forms you are making as mistake here. > > > > Although it is correct that a GmbH & Co. KG does not have a legal > personality that differs from its general partners (Persoenlich haftende > Gesellschafterin) or limited partners (Kommanditist), a GmbH & Co. KG is > still a legal entity as its able to sue in front of court, or get sued in > front of court. A GmbH & Co. KG can also purchase rights and enter into > liabilities, can purchase property and other in rem rights related to > estates. (Source: < > https://www.frankfurt-main.ihk.de/existenzgruendung/rechtsfragen/idem/kg/ > >) > > > > That being said, since Lightup Network Solutions GmbH & Co. KG was > founded, I have never ever signed a contract where the contractual partner > was "Markus Stalder trading as Lightup Network Solutions GmbH & Co. KG" but > the contractual partner was always Lightup Network Solutions GmbH & Co. KG. > That includes application forms towards government entities as well as > contracts with larger corporations. > > > > Actually, my gut feeling based on my own experience with my GmbH & Co. > KG in the last decades tells me that you are making a mistake here. > > > > And, if you want to be really accurate: You must be aware that the > Kommanditist (limited partner) is not allowed to represent the company. > That is something only the Komplementaerin (general partner) can do. The > general partner of Lightup Network Solutions GmbH & Co. KG is AirAccess > GmbH. > > > > I'm attaching both company extracts for your convenience. > > > > So, correct would be: > > > > AirAccess GmbH trading as Lightup Network Solutions GmbH & Co. KG" > > > > Quote end. > > > > > > Wednesday, 13th February, 18:02: Reply from RIPE: > > > > > > Quote start: > > > > "Many thanks for the clarification and the provided documents. > > > > Please be informed that our Due Diligence for the Quality of the RIPE > NCC Registration Data > has been implemented in 2018. As the application process for our members > was not so strict before, it was possible to register an LIR account under > the partnership name. Currently, we are working on correcting these details > in the Database. > > > > At this moment we are reviewing German applications with a legal entity > type 'GmbH & Co. KG' together with our legal department. Thus the > information you provided is very helpful. > > > > On the review the documents you submitted, we indeed can see that > "AirAccess GmbH" is a general partner with a special right to represent the > company. The names of both LIR accounts (de.lightupnet, de.lightupnet1) > will be corrected tomorrow. It will be confirmed to you once the account > are updated." > > > > Quote end. > > > > > > ... another day passes ... > > > > > > Thursday, 14th February, 16:11: Now for the E-Mail from RIPE that blew > my mind, in a negative sense. > > > > > > Quote start: > > > > "Many thanks for your patience. > > > > We have reviewed your case internally and agreed that there is no need > to sign a new agreement for LIR account , as it was signed > by the director of the company. > > > > It has also come to our attention that, the company AirAccess GmbH (reg. > No HRB 56386) already has LIR account . > > > > Therefore LIR should be linked as an additional account > to , and . > > > > Please be informed that the following will be applied to all additional > LIR accounts: > > > > - The /22 IPv4 allocation you will receive is subject to the RIPE NCC > > Transfer Policy and can therefore only be transferred 24 months after the > > allocation date. > > - Members with multiple LIR accounts are entitled to just one vote at > RIPE > > NCC General Meetings. The oldest LIR account will receive the vote. > > - If you wish to transfer internet resources between your LIR accounts, > > you need to pay the full annual service fee for all LIR accounts. > > - If you wish to close LIR account, you need to pay the full annual > > service fee for all LIR accounts. > > > > At this moment could you please inform us what name you prefer for LIR > accounts , : "AirAccess GmbH" or "AirAccess > GmbH trading us Lightup Network Solutions GmbH & Co. KG"? > > > > Once it is clarified, we will proceed with updating the legal details of > your accounts and process the application for ." > > > > Quote end. > > > > > > Spontaneous thought: HOLY F*CK, ARE THEY SERIOUS ?! ?! ?! They want to > change the name of my company - Lightup Network Solutions GmbH & Co. KG - > to a completely different company: AirAccess GmbH !!! Totally unrelated to > each other, different business, different everything. The only thing these > two companies have in common is that they're both mine. RIPE MUST BE NUTS! > Here my reply: > > > > > > Quote start. > > > > "Hi , > > > > thanks for your mail. > > > > Ok, now you are really taking it over the top. > > > > 1) You want to link AirAccess GmbH as an additional account to > de.lightupnet. And you want to do this for a company which is a legal > entity by itself. > > > > I do not allow you to do this. AirAccess GmbH is a legal entity by > itself and I do not want that you change anything about its current LIR > status, name or anything else. > > > > 2) You are offering that I can choose the name for de.lightupnet and > de.lightupnet1 to be "AirAccess GmbH", a company which is an entity by > itself and is merely the Komplementaerin (general partner) for Lightup > Network Solutions GmbH & GmbH Co. KG. > > > > I'm shocked by that idea. That is just completely wrong. > > > > Of course I do NOT want de.lightupnet and de.lightupnet1 to be named > "AirAccess GmbH" because it would be an factual error. And I don't want > RIPE to make wrong statements about our company/companies towards the > public. > > > > It would be like offering to present nl.ripe as KPN. Or Nike as Adidas. > > > > As it appears right now your legal department is doing a mistake when it > comes to understanding how GmbH + Co. KGs work. > > > > Could you also please let me know the E-Mail address or telephone number > where I can file a complaint about this whole procedure? > > > > Thank you." > > > > Quote end. > > > > > > This is where it stands right now. > > > > It's Friday, 15th February. > > > > The work week is over. > > > > I'm sitting here, waiting for RIPE since Monday to send me the LIR > agreement for the 2nd LIR, so that I can sign it, pay it, and be done with > it. > > > > > > My rhetorical questions are: > > > > 1) Are they fucking serious ... I can't remember the last time I was > this angry at anyone. > > > > 2) It's RIPE. A large, established organisation that's been around > forever. WHY THE F*CK does it take them always 1 day to process something, > to reply to something? They have TONS of employees, they have TONS of LIRs > that pay them TONS of money, why is everything moving so slowly with them > ?! ?! ?! It's 2019, not 1995 FOR F*CKS SAKE !!! Get your act together and > adapt to the times, modernize yourself and BE FASTER. UARRRGHHHL. > > > > 3) Why in heavens name do they EXACTLY have to start with this whole > f*cked-up process when I ACTUALLY need something from them (a 2nd LIR > account)? Why in this very moment? Yeah, because my company popped up on > their screen because I applied for a 2nd LIR account, makes sense. But, > could they not simply process the damn LIR application at the same time to > speed this whole thing up, and later change this sh*t. No, of course, it > would be not efficient for them to do that, but it's NOT MY FAULT they > didn't ask to update this data/fix this company sh*t earlier. But now THEY > MAKE IT MY PROBLEM. Because I'm losing precious time. F*CK! > > > > 4) If you look at the LIR list for Germany here - < > https://www.ripe.net/membership/indices/DE.html> - and search for "GmbH & > Co. KG" in the document, you will see many companies that are still > "unchanged": Company name GmbH & Co. KG, but you will also see some that > were already "updated" according to RIPE logic: "Firstname Lastname trading > as "Company GmbH & Co. KG" - the "funny" thing is that this is just wrong > as I explained earlier. They have to re-do all these changes. By looking at > this list it appears I'm the first where they offer to change it to > "Another-company-name GmbH trading as Company GmbH & Co. KG" JUST BECAUSE I > told them that with GmbH & Co. KGs the Kommanditist (legal partner) is not > allowed to represent the company. So, being the first, and looking at that > list for comparison tells me they have no idea what they are doing! > > > > > > Have a good day everyone and down with unnecessary, over-the-top > > bureaucracy! It's 2019 FOR F*CKS SAKE!!! > > > > > > Regards > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabo at tzi.org Fri Feb 15 16:06:46 2019 From: cabo at tzi.org (Carsten Bormann) Date: Fri, 15 Feb 2019 17:06:46 +0100 Subject: OT/venting: RIPE legal - please stop this madness! In-Reply-To: <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org> References: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org> Message-ID: On Feb 15, 2019, at 16:46, Mel Beckman wrote: > > rant not operational, it’s not even North American While that is true, an event where a regional registry has been taken over by (badly programmed) AI robots should be very much of interest both operationally and for North Americans. Grüße, Carsten From mel at beckman.org Fri Feb 15 16:10:01 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 15 Feb 2019 16:10:01 +0000 Subject: OT/venting: RIPE legal - please stop this madness! In-Reply-To: References: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org>, Message-ID: <8FBCCA3F-C1FA-4AD4-9D1F-67CC7F328990@beckman.org> When AI robots take over a regional registry, let us know. In the current world, there is no such thing as AI robots running any bureaucracy. They’re all run by fallible humans, and only humans are to blame. In this case, European humans. :) -mel > On Feb 15, 2019, at 8:06 AM, Carsten Bormann wrote: > >> On Feb 15, 2019, at 16:46, Mel Beckman wrote: >> >> rant not operational, it’s not even North American > > While that is true, an event where a regional registry has been taken over by (badly programmed) AI robots should be very much of interest both operationally and for North Americans. > > Grüße, Carsten > From david at xtom.com Fri Feb 15 16:30:21 2019 From: david at xtom.com (David Guo) Date: Fri, 15 Feb 2019 16:30:21 +0000 Subject: OT/venting: RIPE legal - please stop this madness! In-Reply-To: <8FBCCA3F-C1FA-4AD4-9D1F-67CC7F328990@beckman.org> References: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org>, , <8FBCCA3F-C1FA-4AD4-9D1F-67CC7F328990@beckman.org> Message-ID: They are based in Netherlands and may be not familiar with Germany business laws Get Outlook for iOS ________________________________ From: NANOG on behalf of Mel Beckman Sent: Saturday, February 16, 2019 00:11 To: Carsten Bormann Cc: nanog at nanog.org Subject: Re: OT/venting: RIPE legal - please stop this madness! When AI robots take over a regional registry, let us know. In the current world, there is no such thing as AI robots running any bureaucracy. They’re all run by fallible humans, and only humans are to blame. In this case, European humans. :) -mel > On Feb 15, 2019, at 8:06 AM, Carsten Bormann wrote: > >> On Feb 15, 2019, at 16:46, Mel Beckman wrote: >> >> rant not operational, it’s not even North American > > While that is true, an event where a regional registry has been taken over by (badly programmed) AI robots should be very much of interest both operationally and for North Americans. > > Grüße, Carsten > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Feb 15 18:03:54 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Feb 2019 04:03:54 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190215180354.65992C55A0@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Feb, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 737069 Prefixes after maximum aggregation (per Origin AS): 284406 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 355337 Total ASes present in the Internet Routing Table: 63249 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54461 Origin ASes announcing only one prefix: 23611 Transit ASes present in the Internet Routing Table: 8788 Transit-only ASes present in the Internet Routing Table: 270 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 26 Number of instances of unregistered ASNs: 28 Number of 32-bit ASNs allocated by the RIRs: 25797 Number of 32-bit ASNs visible in the Routing Table: 21025 Prefixes from 32-bit ASNs in the Routing Table: 91435 Number of bogon 32-bit ASNs visible in the Routing Table: 23 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 265 Number of addresses announced to Internet: 2840868547 Equivalent to 169 /8s, 84 /16s and 54 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 246891 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200469 Total APNIC prefixes after maximum aggregation: 57566 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 197448 Unique aggregates announced from the APNIC address blocks: 81948 APNIC Region origin ASes present in the Internet Routing Table: 9451 APNIC Prefixes per ASN: 20.89 APNIC Region origin ASes announcing only one prefix: 2657 APNIC Region transit ASes present in the Internet Routing Table: 1413 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4459 Number of APNIC addresses announced to Internet: 769815906 Equivalent to 45 /8s, 226 /16s and 117 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 217989 Total ARIN prefixes after maximum aggregation: 103510 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 217330 Unique aggregates announced from the ARIN address blocks: 104080 ARIN Region origin ASes present in the Internet Routing Table: 18359 ARIN Prefixes per ASN: 11.84 ARIN Region origin ASes announcing only one prefix: 6834 ARIN Region transit ASes present in the Internet Routing Table: 1855 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2581 Number of ARIN addresses announced to Internet: 1077344416 Equivalent to 64 /8s, 54 /16s and 248 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 202728 Total RIPE prefixes after maximum aggregation: 96543 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 198781 Unique aggregates announced from the RIPE address blocks: 117953 RIPE Region origin ASes present in the Internet Routing Table: 25827 RIPE Prefixes per ASN: 7.70 RIPE Region origin ASes announcing only one prefix: 11496 RIPE Region transit ASes present in the Internet Routing Table: 3636 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7839 Number of RIPE addresses announced to Internet: 716829376 Equivalent to 42 /8s, 185 /16s and 242 /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-210331 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: 95234 Total LACNIC prefixes after maximum aggregation: 22511 LACNIC Deaggregation factor: 4.23 Prefixes being announced from the LACNIC address blocks: 96677 Unique aggregates announced from the LACNIC address blocks: 41867 LACNIC Region origin ASes present in the Internet Routing Table: 8074 LACNIC Prefixes per ASN: 11.97 LACNIC Region origin ASes announcing only one prefix: 2195 LACNIC Region transit ASes present in the Internet Routing Table: 1526 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5624 Number of LACNIC addresses announced to Internet: 173195520 Equivalent to 10 /8s, 82 /16s and 193 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20622 Total AfriNIC prefixes after maximum aggregation: 4255 AfriNIC Deaggregation factor: 4.85 Prefixes being announced from the AfriNIC address blocks: 26568 Unique aggregates announced from the AfriNIC address blocks: 9252 AfriNIC Region origin ASes present in the Internet Routing Table: 1249 AfriNIC Prefixes per ASN: 21.27 AfriNIC Region origin ASes announcing only one prefix: 429 AfriNIC Region transit ASes present in the Internet Routing Table: 244 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 522 Number of AfriNIC addresses announced to Internet: 103345152 Equivalent to 6 /8s, 40 /16s and 236 /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 4653 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4648 541 540 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3085 1240 50 VIETEL-AS-AP Viettel Group, VN 45899 3014 1729 113 VNPT-AS-VN VNPT Corp, VN 4766 2808 11127 766 KIXS-AS-KR Korea Telecom, KR 9829 2751 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2437 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2372 4906 29 CTTNET China TieTong Telecommunications 4755 2144 422 180 TATACOMM-AS TATA Communications formerl 17974 2006 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3596 1326 92 SHAW - Shaw Communications Inc., CA 11492 3505 226 592 CABLEONE - CABLE ONE, INC., US 22773 3311 2978 172 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2545 5387 1025 AMAZON-02 - Amazon.com, Inc., US 16625 2278 1249 1724 AKAMAI-AS - Akamai Technologies, Inc., 20115 2151 2744 535 CHARTER-20115 - Charter Communications, 18566 2130 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2098 349 239 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2093 5095 585 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 5650 2089 3074 1462 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5319 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3260 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2614 552 1904 AKAMAI-ASN1, US 12389 2226 2221 637 ROSTELECOM-AS, RU 34984 2059 339 531 TELLCOM-AS, TR 9121 1735 1692 18 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 9009 1337 145 745 M247, GB 8402 1310 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5572 3329 590 Uninet S.A. de C.V., MX 10620 2875 436 1014 Telmex Colombia S.A., CO 11830 2697 386 36 Instituto Costarricense de Electricidad 6503 1512 433 54 Axtel, S.A.B. de C.V., MX 7303 1408 937 236 Telecom Argentina S.A., AR 6147 1271 377 29 Telefonica del Peru S.A.A., PE 28573 1268 2246 186 CLARO S.A., BR 3816 1021 506 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 931 144 66 Alestra, S. de R.L. de C.V., MX 13999 916 530 245 Mega Cable, S.A. 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 1217 393 21 LINKdotNET-AS, EG 37611 932 107 9 Afrihost, ZA 24835 847 636 22 RAYA-AS, EG 36992 812 1538 43 ETISALAT-MISR, EG 36903 810 407 147 MT-MPLS, MA 8452 648 1731 20 TE-AS TE-AS, EG 29571 486 70 13 ORANGE-COTE-IVOIRE, CI 37492 468 470 57 ORANGE-, TN 15399 428 45 11 WANANCHI-, KE 37342 420 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5572 3329 590 Uninet S.A. de C.V., MX 12479 5319 1628 138 UNI2-AS, ES 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4648 541 540 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3596 1326 92 SHAW - Shaw Communications Inc., CA 11492 3505 226 592 CABLEONE - CABLE ONE, INC., US 22773 3311 2978 172 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3260 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 7552 3085 1240 50 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5319 5181 UNI2-AS, ES 4538 4653 4579 ERX-CERNET-BKB China Education and Research Net 7545 4648 4108 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3596 3504 SHAW - Shaw Communications Inc., CA 8551 3260 3217 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3311 3139 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3085 3035 VIETEL-AS-AP Viettel Group, VN 11492 3505 2913 CABLEONE - CABLE ONE, INC., US 45899 3014 2901 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 1358592 UNALLOCATED 103.134.14.0/23 63956 COLO-AS-AP Colocation Australi 1358592 UNALLOCATED 103.134.15.0/24 63956 COLO-AS-AP Colocation Australi 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 224413 UNALLOCATED 131.221.136.0/22 264413 Conecta Telecom Ltda, BR 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 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:12 /9:10 /10:36 /11:99 /12:291 /13:566 /14:1132 /15:1908 /16:13352 /17:7902 /18:13887 /19:25593 /20:39779 /21:46105 /22:91898 /23:75067 /24:416564 /25:938 /26:826 /27:878 /28:20 /29:6 /30:7 /31:0 /32:193 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4199 5319 UNI2-AS, ES 6327 3359 3596 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2761 3505 CABLEONE - CABLE ONE, INC., US 8551 2716 3260 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2552 3311 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2040 2697 Instituto Costarricense de Electricidad y Telec 18566 2025 2130 MEGAPATH5-US - MegaPath Corporation, US 30036 1845 2098 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2089 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1610 2:890 4:22 5:2845 6:47 7:1 8:1196 12:1868 13:313 14:1895 15:38 16:4 17:220 18:59 20:49 23:2604 24:2507 25:2 27:2547 31:2067 32:94 35:36 36:830 37:3035 38:1652 39:294 40:122 41:3132 42:723 43:2001 44:140 45:6663 46:3244 47:249 49:1342 50:1089 51:319 52:1046 54:329 55:1 56:6 57:41 58:1707 59:1061 60:495 61:2058 62:2040 63:1794 64:5078 65:2193 66:4806 67:2690 68:1173 69:3516 70:1154 71:600 72:2297 74:2757 75:421 76:544 77:1693 78:1763 79:2320 80:1612 81:1436 82:1111 83:867 84:1100 85:2143 86:552 87:1535 88:998 89:2422 90:217 91:6560 92:1233 93:2441 94:2481 95:3242 96:920 97:348 98:939 99:174 100:88 101:1163 102:407 103:20037 104:3569 105:247 106:866 107:1818 108:697 109:3684 110:1627 111:1870 112:1393 113:1413 114:1131 115:1721 116:1694 117:1916 118:2181 119:1625 120:1047 121:1032 122:2287 123:1640 124:1446 125:1960 128:1231 129:677 130:524 131:1626 132:712 133:218 134:1047 135:239 136:553 137:707 138:2030 139:840 140:572 141:814 142:797 143:1014 144:901 145:505 146:1251 147:792 148:1714 149:795 150:787 151:1006 152:1008 153:321 154:2627 155:977 156:1671 157:903 158:672 159:1921 160:1511 161:917 162:2676 163:778 164:1129 165:1567 166:439 167:1382 168:3285 169:871 170:4010 171:529 172:1093 173:2188 174:1012 175:879 176:2305 177:3994 178:2548 179:1334 180:2089 181:2436 182:2688 183:1049 184:1153 185:14732 186:3706 187:2397 188:2912 189:1949 190:8294 191:1449 192:10050 193:6556 194:5376 195:4053 196:2988 197:1744 198:5773 199:5986 200:7319 201:5111 202:10152 203:10185 204:4606 205:2991 206:3273 207:3273 208:3981 209:4230 210:3924 211:1987 212:3059 213:2895 214:1075 215:52 216:5978 217:2198 218:919 219:578 220:1850 221:996 222:991 223:1440 End of report From nusenu-lists at riseup.net Fri Feb 15 20:21:00 2019 From: nusenu-lists at riseup.net (nusenu) Date: Fri, 15 Feb 2019 20:21:00 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: <3E33FB38-EEA8-4FCE-9F8C-710301A1D975@nist.gov> References: <3E33FB38-EEA8-4FCE-9F8C-710301A1D975@nist.gov> Message-ID: Montgomery, Douglas (Fed): > Our effort to get our new monitor transitioned to a public facing > system ran into a wall for ~35 days. Unfortunately during that time, > the visa of a visiting researcher leading that effort expired. > > We have almost recovered from all of that. Unfortunately, we have a > bit of a bureaucracy to deploying public facing systems. So I would > guess it will take ~end of March to get it on-line. thanks for the status update! -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From valdis.kletnieks at vt.edu Sat Feb 16 06:06:21 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 16 Feb 2019 01:06:21 -0500 Subject: OT/venting: RIPE legal - please stop this madness! In-Reply-To: References: <8a321c3e-3673-567b-67d6-a910535b6cf0@truemetal.org> <3981D9F1-8BC3-4A63-A0CC-1ADE24718261@beckman.org>, , <8FBCCA3F-C1FA-4AD4-9D1F-67CC7F328990@beckman.org> Message-ID: <14305.1550297181@turing-police.cc.vt.edu> On Fri, 15 Feb 2019 16:30:21 +0000, David Guo via NANOG said: > They are based in Netherlands and may be not familiar with Germany business laws I'd expect that due diligence on their part would be to find an actual expert on German business law. And given that RIPE deals with most of Europe, I'd be surprised if *nobody* in their legal department understands what are pretty basic concepts of German law. From ben at 6by7.net Sun Feb 17 02:07:02 2019 From: ben at 6by7.net (Ben Cannon) Date: Sat, 16 Feb 2019 18:07:02 -0800 Subject: Amazon contact off-list Message-ID: Can someone from Amazon (preferably SF Bay area) contact me off-list please? -Ben. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From samir.rana at cybera.ca Sun Feb 17 20:42:44 2019 From: samir.rana at cybera.ca (Samir Rana) Date: Sun, 17 Feb 2019 13:42:44 -0700 Subject: fs.com dwdm equipment Message-ID: Hello All, Does anybody have experience with fs.com dwdm equipment in their production environment? Are you they working without any issue? How's their warranty support if the issue arises? Thanks in advance for all the answers and help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Mon Feb 18 02:03:32 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 18 Feb 2019 07:33:32 +0530 Subject: A Zero Spam Mail System [Feedback Request] Message-ID: Hello Everyone, My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over TLS on Port 26 last month. I'm also the guy who attacked (???) John Levine. Today I have something to show you. Long story short.... I solved the email spam problem. Well... Actually I solved it long time back. I'm just ready to disclose it today. Again... Yeah.. Yeah.. Yeah... If only I had a dime for every time people insult me for saying "I solved the spam problem" They usually start with the insult like "You think you are the inventor of FUSSP?" These guys always are the know-it-all assholes. They don't listen. They don't want to listen. They are like barking dogs. If one started to bark, everyone else gets the courage to do the same thing. I'm tired of fighting these assholes in every mailing list. I'm on your side morons. So how about you all knock it off? Six months back, it was John Levine who humiliated me in the DMARC list. Apparently, for him 50 words are enough to attack me. Töma Gavrichenkov and Suresh Ramasubramanian even started to defend this man saying 50 words are enough to judge a 50,000 words paper. [We are gonna figure it out today] ---------------------------------- @Töma Gavrichenkov In theory, I can easily recall a few cases in my life when going > through just 50 words was quite enough for a judgment. How can you be so sure that you didn't fuck up none of the lives of these "few cases"? Or in more technical terms, How can you be absolutely sure that there is no "False Positives"? ---------------------------------- @Suresh Ramasubramanian Yes, 50 words are more than enough to decide a bad idea is bad. You don't > have to like that, or like any of us, but facts are facts Merely appending the text "facts are facts" not gonna convert a bullshit statement into a fact. You know what's the meaning of the word "fact"? It's a statement that can be proved TRUE. Let's do a little experiment. 100 researchers presents their lifetime work to us. Each of their research paper contain 50,000 words. We are gonna judge them. You are gonna judge them based on only the first 50 words. And I'm gonna judge them by tossing a coin. Can you guess who is gonna fuck up less number of researcher lives? I'm claiming that I solved the email spam problem. If that's true, then you should know, common sense is one of the very basic requirement for that. I designed my email system. Every inch of it. I wrote my research paper. Every word of it. I made my prototype video. Every second of it. So I'm the captain of my ship. Not you. But you all think you know my system better than me? That too, with only 50 words? My research paper has around 50,000 words. And you think 50 words are enough to judge my work? Let me make sure I get this right. You are all saying, you know what's in the rest of the 49,950 words based on only the first 50 words? That's stupid on so many levels. If you are gonna do a half-assed job and relay that misinformation to thousands of people, why volunteer in the first place? And by the way, by saying you are all doing half-assed job, I'm actually insulting the people who are REALLY doing the half-assed job. ---------------------------------- John Levine vs. me One month back, some of you may have noticed a thread created by John Levine where he goes like "He's Forum Shopping". The whole gist of that message was "We already have DANE and MTA-STS. We don't a third solution". And then I used some harsh words to defend myself. But that was the Season 2 of his "Shitshow". The Season 1 was aired 6 months back. You all missed that show. This is what happened in Season 1. 1. Six months back, I posted on three mailing list saying "I solved the email spam problem" and asked them to provide feedback on my invention. Those three mailing lists were SPF, DKIM and DMARC. That's because my solution relied on them and those three were the only email related mailing lists I knew at that time. 2. In DMARC community, John Levine started to insult me after reading only the first 50 words. 3. Dave Crocker joined the cast and did a flawless job on abusing me. He asked me to kill my project. I told him he is being rude. And this is what he replied for that . He is one of the most radical and ignorant person I have seen in tech. He didn't even stop for a moment and think "Am I attacking an Innocent person?". He even went to other mailing lists to attack me. He abused all his power and kept on attacking me just to have some "dopamine orgasm". Something tells me he slept peacefully on that day. 4. And then bunch of other guys joined. So the whole thread gone crazy. This is because John Levine successfully distributed wrong version of the story to thousands of people with only 50 words. 5. Both Dave Crocker and John Levine are the bigshots there. So I knew no matter how much I cry for help, no one is gonna help me. 6. John seemed like a "decent-asshole" while compared to Dave Crocker. So I sent a private mail to John saying "John, I'm not really sure whether I can afford you since I have not raised any money yet. But let me give it a shot. Could you tell me how much you would charge to go through my presentation, demo video and give me a detailed feedback about my system?" [The reason I was ready to pay him is because he made it very clear in the DMARC thread by saying "Sorry, but I don't provide consulting for free". I thought if I make him read my document, he would go back and correct his mistake] 7. And this is what he replied for that. "Really, even if you had money, it wouldn't be worth your money or my time". [For the record, he come to this conclusion without even knowing what's inside in my document] 8. I said only "ok, thankyou" and then unsubscribed from the DMARC mailing list. [What more can you argue with a bunch of know-it-all morons who thinks they are all right?] 9. Six month later (last month), John started his shitshow again attacking my IETF proposal. He tried to make me look like an idiot again. And that's when I started to defend myself by using harsh words. 10. You all know the rest. ---------------------------------- One person told me on that thread to take John Levine's words as criticism. You see I have no problems with criticism. I usually thank people when they criticize my work. The best criticism usually follows this format. "I went through your paper (#1), your work is full of shit (#2), Here are the reasons (#3)" #1 says, the critic really knows what the author is talking about. #2 says, the critic is speaking his mind without any bullshit. #3 says, the critic has valid points for his criticism. However, I can't consider someone as critic who straightly go for #2. Especially when the whole argument was all about killing my work just because he is one of the inventor of MTA-STS. If I start to listen his words, then next time he will create a new thread to attack me for creating saying "He's forum shopping. I already told him it's not worth his money and my time". What you want me to do in this case? Take that as criticism and move on? It's my 5 fucking years of research. I can't just let it go just because someone doesn't like my work. ---------------------------------- @Valdis Kletnieks You missed the part where the RFC says you *MUST* fall back to A if there's > no MX. "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself; Therefore all progress depends on the unreasonable man" - George Bernard Shaw ---------------------------------- @John Levine I was trying to contribute to IETF the other day. One of the guy from DMARC list uses your words as a reason to attack me and asking me to turn down the proposal. You were watching that. If I really solved the email spam problem, that puts me in the "best problem solvers in the world" category. So how about you go back to the DMARC list and write a decent apology for posting misinformation to everyone? [Of course only if I solved the spam problem. That was my claim from the beginning right?] ---------------------------------- @Everyone Here is what you all should know. It's my 5 years of research. So it's worth more than 50 words. I started my work back in 2013 and I used to call my work "XMail" at that time. It's now called "Dombox" My prototype codebase has around 200,000 lines of code. [To be exact: 466,965 ++ 254,169 --] Sequoia Capital is one of the well known venture firm in the world. They have invested in over 250 companies since 1972, including Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp. Bill Coughran is a senior investor in Sequoia Capital. According to his linkedin profile, he started as a Programmer in the late 60s and held many engineering related positions over the years. Worked in Bell Laboratories for 20 years. Worked as SVP of Engineering in Google for 8.5 years. To quote his words "I have some level of expertise about the current email systems, which is why I was did some investigating". So this man is one of the toughest person to impress. But he is one of the nicest investor I have met. When I asked him whether he can take a look, he didn't insult me with words like "You think you are the inventor of FUSSP?" He just told me "Sure, I'd be happy to." He went through my entire paper and then sent me this mail . He later turned me down because it's hard for a startup to distribute a new solution. Maybe he is right. Or maybe I'll overcome that too. [Today's discussion is about whether I solved the spam problem. Not about how I'm gonna distribute the solution] Yesterday I published my work on a medium blog post and linked my white paper. An engineer read my white paper and sent me this mail . These guys see value in my white paper because they completed my ~300 pages white paper. To the "50 words are enough" band members, let me tell you something. I'm the author of my work. It's my job to decide "what to show you" and "when to show you". I have posted my system summary in a medium blog post. When you reach 75% of the article, you will see a title called "Hot Gates Strategy". Everything you see above is pointless without the remaining 25% of the content. Put it this way, I have designed 75% of that system, only to have remaining 25% of the system. So yeah, even if you had 75% of the content, you still can't judge my work. Whether you all believe it or not, I'm the goddamn inventor of FUSSP. I can proudly say that because my system doesn't have the "spam" folder. So how about you all appreciate the guy who spent 5 years in chasing for a solution like a madman and succeeded in solving a challenging problem rather than spending your time in attacking me? [For the record, my single white paper plenty of problems. Email Spam is one of them] Looking forward to hear your feedback. People who complete my white paper, please post whether my claims are true or I'm just wasting everyone's time. [I'm going to bed now. So I may not be online for the next 8 hours. I'll respond to your queries after that] Thanks ---------------------------------- Materials: System Overview - https://medium.com/@Viruthagiri/dombox-the-zero-spam-mail-system-2b08ff7432cd White Paper - https://www.dombox.org/dombox.pdf Flowcharts - https://www.dombox.org/flowcharts.pdf Prototype - https://www.youtube.com/watch?v=VK2eSfCurx4 [This is the video I uploaded before posting to DMARC list. So the interface is little outdated] -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsage at finchhaven.com Mon Feb 18 02:13:44 2019 From: jsage at finchhaven.com (John Sage) Date: Sun, 17 Feb 2019 18:13:44 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <5C6A14D8.7060107@finchhaven.com> On 02/17/2019 06:03 PM, Viruthagiri Thirumavalavan wrote: > Hello Everyone, - John From ross at tajvar.io Mon Feb 18 02:14:17 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sun, 17 Feb 2019 21:14:17 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: I'd be a lot more inclined to read your paper if you weren't so self-righteous about it. Rehashing all the times people disagreed with ("attacked") you is a poor way to encourage others to earnestly engage with your ideas. On Sun, Feb 17, 2019, 9:06 PM Viruthagiri Thirumavalavan Hello Everyone, > > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over > TLS on Port 26 > last > month. I'm also the guy who attacked (???) John Levine. > > Today I have something to show you. > > Long story short.... I solved the email spam problem. Well... Actually I > solved it long time back. I'm just ready to disclose it today. Again... > > Yeah.. Yeah.. Yeah... If only I had a dime for every time people insult me > for saying "I solved the spam problem" > > They usually start with the insult like "You think you are the inventor of > FUSSP?" > > These guys always are the know-it-all assholes. They don't listen. They > don't want to listen. They are like barking dogs. If one started to bark, > everyone else gets the courage to do the same thing. > > I'm tired of fighting these assholes in every mailing list. I'm on your > side morons. So how about you all knock it off? > > Six months back, it was John Levine who humiliated me in the DMARC list. > Apparently, for him 50 words are enough to attack me. > > Töma Gavrichenkov and Suresh Ramasubramanian even started to defend this > man saying 50 words are enough to judge a 50,000 words paper. [We are > gonna figure it out today] > > ---------------------------------- > > @Töma Gavrichenkov > > In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. > > > How can you be so sure that you didn't fuck up none of the lives of these > "few cases"? Or in more technical terms, How can you be absolutely sure > that there is no "False Positives"? > > ---------------------------------- > > @Suresh Ramasubramanian > > Yes, 50 words are more than enough to decide a bad idea is bad. You don't >> have to like that, or like any of us, but facts are facts > > > Merely appending the text "facts are facts" not gonna convert a bullshit > statement into a fact. > > You know what's the meaning of the word "fact"? It's a statement that can > be proved TRUE. > > Let's do a little experiment. 100 researchers presents their lifetime work > to us. Each of their research paper contain 50,000 words. We are gonna > judge them. > > You are gonna judge them based on only the first 50 words. And I'm gonna > judge them by tossing a coin. Can you guess who is gonna fuck up less > number of researcher lives? > > I'm claiming that I solved the email spam problem. If that's true, then > you should know, common sense is one of the very basic requirement for that. > > I designed my email system. Every inch of it. I wrote my research paper. > Every word of it. I made my prototype video. Every second of it. So I'm the > captain of my ship. Not you. But you all think you know my system better > than me? That too, with only 50 words? > > My research paper has around 50,000 words. And you think 50 words are > enough to judge my work? Let me make sure I get this right. You are all > saying, you know what's in the rest of the 49,950 words based on only the > first 50 words? That's stupid on so many levels. > > If you are gonna do a half-assed job and relay that misinformation to > thousands of people, why volunteer in the first place? And by the way, by > saying you are all doing half-assed job, I'm actually insulting the people > who are REALLY doing the half-assed job. > > ---------------------------------- > > John Levine vs. me > > One month back, some of you may have noticed a thread created by John > Levine > > where he goes like "He's Forum Shopping". The whole gist of that message > was "We already have DANE and MTA-STS. We don't a third solution". And then > I used some harsh words to defend myself. But that was the Season 2 of his > "Shitshow". The Season 1 was aired 6 months back. You all missed that show. > This is what happened in Season 1. > > > 1. Six months back, I posted on three mailing list saying "I solved > the email spam problem" and asked them to provide feedback on my invention. > Those three mailing lists were SPF, DKIM and DMARC. That's because my > solution relied on them and those three were the only email related mailing > lists I knew at that time. > 2. In DMARC community, John Levine started to insult me after reading > only the first 50 words. > 3. Dave Crocker joined the cast and did a flawless job on abusing me. > He asked me to kill my project. I told him he is being rude. And this is what > he replied for that . He is one > of the most radical and ignorant person I have seen in tech. He didn't even > stop for a moment and think "Am I attacking an Innocent person?". He even > went to other mailing lists to attack me. He abused all his power and kept > on attacking me just to have some "dopamine orgasm". Something tells me he > slept peacefully on that day. > 4. And then bunch of other guys joined. So the whole thread gone > crazy. This is because John Levine successfully distributed wrong version > of the story to thousands of people with only 50 words. > 5. Both Dave Crocker and John Levine are the bigshots there. So I knew > no matter how much I cry for help, no one is gonna help me. > 6. John seemed like a "decent-asshole" while compared to Dave Crocker. > So I sent a private mail to John saying "John, I'm not really sure whether > I can afford you since I have not raised any money yet. But let me give it > a shot. Could you tell me how much you would charge to go through my > presentation, demo video and give me a detailed feedback about my system?" > [The reason I was ready to pay him is because he made it very clear in the > DMARC thread by saying "Sorry, but I don't provide consulting for free". I > thought if I make him read my document, he would go back and correct his > mistake] > 7. And this is what he replied for that. "Really, even if you had > money, it wouldn't be worth your money or my time". [For the record, he > come to this conclusion without even knowing what's inside in my document] > 8. I said only "ok, thankyou" and then unsubscribed from the DMARC > mailing list. [What more can you argue with a bunch of know-it-all morons > who thinks they are all right?] > 9. Six month later (last month), John started his shitshow again > attacking my IETF proposal. He tried to make me look like an idiot again. > And that's when I started to defend myself by using harsh words. > 10. You all know the rest. > > > ---------------------------------- > > One person told me on that thread to take John Levine's words as > criticism. > > You see I have no problems with criticism. I usually thank people when > they criticize my work. The best criticism usually follows this format. > > "I went through your paper (#1), your work is full of shit (#2), Here are > the reasons (#3)" > > #1 says, the critic really knows what the author is talking about. > #2 says, the critic is speaking his mind without any bullshit. > #3 says, the critic has valid points for his criticism. > > However, I can't consider someone as critic who straightly go for #2. > Especially when the whole argument was all about killing my work just > because he is one of the inventor of MTA-STS. > > If I start to listen his words, then next time he will create a new thread > to attack me for creating saying "He's forum shopping. I > already told him it's not worth his money and my time". What you want me to > do in this case? Take that as criticism and move on? It's my 5 fucking > years of research. I can't just let it go just because someone doesn't like > my work. > > ---------------------------------- > > @Valdis Kletnieks > > You missed the part where the RFC says you *MUST* fall back to A if there's >> no MX. > > > "The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself; Therefore all progress > depends on the unreasonable man" - George Bernard Shaw > > ---------------------------------- > @John Levine > > I was trying to contribute to IETF the other day. One of the guy from > DMARC list uses your words as a reason to attack me > and asking me to turn down > the proposal. You were watching that. > > If I really solved the email spam problem, that puts me in the "best > problem solvers in the world" category. So how about you go back to the > DMARC list and write a decent apology for posting misinformation to > everyone? [Of course only if I solved the spam problem. That was my claim > from the beginning right?] > > ---------------------------------- > > @Everyone > > Here is what you all should know. > > It's my 5 years of research. So it's worth more than 50 words. I started > my work back in 2013 and I used to call my work "XMail" at that time. It's > now called "Dombox" > > My prototype codebase has around 200,000 lines of code. [To be exact: > 466,965 ++ 254,169 --] > > Sequoia Capital is one of the well known venture firm in the world. They > have invested in over 250 companies since 1972, including Apple, Google, > Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp. Bill > Coughran is a senior > investor in Sequoia Capital. According to his linkedin profile, he started > as a Programmer in the late 60s and held many engineering related positions > over the years. Worked in Bell Laboratories for 20 years. Worked as SVP of > Engineering in Google for 8.5 years. To quote his words "I have some level > of expertise about the current email systems, which is why I was did some > investigating". So this man is one of the toughest person to impress. But > he is one of the nicest investor I have met. When I asked him whether he > can take a look, he didn't insult me with words like "You think you are the > inventor of FUSSP?" He just told me "Sure, I'd be happy to." He went > through my entire paper and then sent me this mail > . He later turned me down > because it's hard for a startup to distribute a new solution. Maybe he is > right. Or maybe I'll overcome that too. [Today's discussion is about > whether I solved the spam problem. Not about how I'm gonna distribute the > solution] > > Yesterday I published my work on a medium blog post and linked my white > paper. An engineer read my white paper and sent me this mail > . > > These guys see value in my white paper because they completed my ~300 > pages white paper. > > To the "50 words are enough" band members, let me tell you something. I'm > the author of my work. It's my job to decide "what to show you" and "when > to show you". I have posted my system summary in a medium blog post. When > you reach 75% of the article, you will see a title called "Hot Gates > Strategy". Everything you see above is pointless without the remaining 25% > of the content. Put it this way, I have designed 75% of that system, only > to have remaining 25% of the system. So yeah, even if you had 75% of the > content, you still can't judge my work. > > Whether you all believe it or not, I'm the goddamn inventor of FUSSP. I > can proudly say that because my system doesn't have the "spam" folder. So > how about you all appreciate the guy who spent 5 years in chasing for a > solution like a madman and succeeded in solving a challenging problem > rather than spending your time in attacking me? [For the record, my single > white paper plenty of problems. Email Spam is one of them] > > Looking forward to hear your feedback. People who complete my white paper, > please post whether my claims are true or I'm just wasting everyone's time. > > [I'm going to bed now. So I may not be online for the next 8 hours. I'll > respond to your queries after that] > > Thanks > > ---------------------------------- > > Materials: > > System Overview - > https://medium.com/@Viruthagiri/dombox-the-zero-spam-mail-system-2b08ff7432cd > > White Paper - https://www.dombox.org/dombox.pdf > > Flowcharts - https://www.dombox.org/flowcharts.pdf > > Prototype - https://www.youtube.com/watch?v=VK2eSfCurx4 [This is the > video I uploaded before posting to DMARC list. So the interface is little > outdated] > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Mon Feb 18 02:14:50 2019 From: bruns at 2mbit.com (Brielle) Date: Sun, 17 Feb 2019 19:14:50 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <027F7B2B-CBF6-400B-91C7-8DB10BC224D5@2mbit.com> You literally lost my interest in reading your solution when I realized that 99.99999999999% of this post is just you railing against people. People are right, if you can’t get my attention in 50 words, then either your solution isn’t a solution but a marketing ploy, or you need someone who actually knows how to present things to people in this field. Im a former DNSbl maintainer - I get excited over new anti spam solutions and love to throw resources at new solutions. So yeah, this is a non starter. Sent from my iPhone > On Feb 17, 2019, at 7:03 PM, Viruthagiri Thirumavalavan wrote: > > Hello Everyone, > > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over TLS on Port 26 last month. I'm also the guy who attacked (???) John Levine. > > Today I have something to show you. > > Long story short.... I solved the email spam problem. Well... Actually I solved it long time back. I'm just ready to disclose it today. Again... > > Yeah.. Yeah.. Yeah... If only I had a dime for every time people insult me for saying "I solved the spam problem" > > They usually start with the insult like "You think you are the inventor of FUSSP?" > > These guys always are the know-it-all assholes. They don't listen. They don't want to listen. They are like barking dogs. If one started to bark, everyone else gets the courage to do the same thing. > > I'm tired of fighting these assholes in every mailing list. I'm on your side morons. So how about you all knock it off? > > Six months back, it was John Levine who humiliated me in the DMARC list. Apparently, for him 50 words are enough to attack me. > > Töma Gavrichenkov and Suresh Ramasubramanian even started to defend this man saying 50 words are enough to judge a 50,000 words paper. [We are gonna figure it out today] > > ---------------------------------- > > @Töma Gavrichenkov > >> In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. > > How can you be so sure that you didn't fuck up none of the lives of these "few cases"? Or in more technical terms, How can you be absolutely sure that there is no "False Positives"? > > ---------------------------------- > > @Suresh Ramasubramanian > >> Yes, 50 words are more than enough to decide a bad idea is bad. You don't have to like that, or like any of us, but facts are facts > > Merely appending the text "facts are facts" not gonna convert a bullshit statement into a fact. > > You know what's the meaning of the word "fact"? It's a statement that can be proved TRUE. > > Let's do a little experiment. 100 researchers presents their lifetime work to us. Each of their research paper contain 50,000 words. We are gonna judge them. > > You are gonna judge them based on only the first 50 words. And I'm gonna judge them by tossing a coin. Can you guess who is gonna fuck up less number of researcher lives? > > I'm claiming that I solved the email spam problem. If that's true, then you should know, common sense is one of the very basic requirement for that. > > I designed my email system. Every inch of it. I wrote my research paper. Every word of it. I made my prototype video. Every second of it. So I'm the captain of my ship. Not you. But you all think you know my system better than me? That too, with only 50 words? > > My research paper has around 50,000 words. And you think 50 words are enough to judge my work? Let me make sure I get this right. You are all saying, you know what's in the rest of the 49,950 words based on only the first 50 words? That's stupid on so many levels. > > If you are gonna do a half-assed job and relay that misinformation to thousands of people, why volunteer in the first place? And by the way, by saying you are all doing half-assed job, I'm actually insulting the people who are REALLY doing the half-assed job. > > ---------------------------------- > > John Levine vs. me > > One month back, some of you may have noticed a thread created by John Levine where he goes like "He's Forum Shopping". The whole gist of that message was "We already have DANE and MTA-STS. We don't a third solution". And then I used some harsh words to defend myself. But that was the Season 2 of his "Shitshow". The Season 1 was aired 6 months back. You all missed that show. This is what happened in Season 1. > > Six months back, I posted on three mailing list saying "I solved the email spam problem" and asked them to provide feedback on my invention. Those three mailing lists were SPF, DKIM and DMARC. That's because my solution relied on them and those three were the only email related mailing lists I knew at that time. > In DMARC community, John Levine started to insult me after reading only the first 50 words. > Dave Crocker joined the cast and did a flawless job on abusing me. He asked me to kill my project. I told him he is being rude. And this is what he replied for that. He is one of the most radical and ignorant person I have seen in tech. He didn't even stop for a moment and think "Am I attacking an Innocent person?". He even went to other mailing lists to attack me. He abused all his power and kept on attacking me just to have some "dopamine orgasm". Something tells me he slept peacefully on that day. > And then bunch of other guys joined. So the whole thread gone crazy. This is because John Levine successfully distributed wrong version of the story to thousands of people with only 50 words. > Both Dave Crocker and John Levine are the bigshots there. So I knew no matter how much I cry for help, no one is gonna help me. > John seemed like a "decent-asshole" while compared to Dave Crocker. So I sent a private mail to John saying "John, I'm not really sure whether I can afford you since I have not raised any money yet. But let me give it a shot. Could you tell me how much you would charge to go through my presentation, demo video and give me a detailed feedback about my system?" [The reason I was ready to pay him is because he made it very clear in the DMARC thread by saying "Sorry, but I don't provide consulting for free". I thought if I make him read my document, he would go back and correct his mistake] > And this is what he replied for that. "Really, even if you had money, it wouldn't be worth your money or my time". [For the record, he come to this conclusion without even knowing what's inside in my document] > I said only "ok, thankyou" and then unsubscribed from the DMARC mailing list. [What more can you argue with a bunch of know-it-all morons who thinks they are all right?] > Six month later (last month), John started his shitshow again attacking my IETF proposal. He tried to make me look like an idiot again. And that's when I started to defend myself by using harsh words. > You all know the rest. > > ---------------------------------- > > One person told me on that thread to take John Levine's words as criticism. > > You see I have no problems with criticism. I usually thank people when they criticize my work. The best criticism usually follows this format. > > "I went through your paper (#1), your work is full of shit (#2), Here are the reasons (#3)" > > #1 says, the critic really knows what the author is talking about. > #2 says, the critic is speaking his mind without any bullshit. > #3 says, the critic has valid points for his criticism. > > However, I can't consider someone as critic who straightly go for #2. Especially when the whole argument was all about killing my work just because he is one of the inventor of MTA-STS. > > If I start to listen his words, then next time he will create a new thread to attack me for creating saying "He's forum shopping. I already told him it's not worth his money and my time". What you want me to do in this case? Take that as criticism and move on? It's my 5 fucking years of research. I can't just let it go just because someone doesn't like my work. > > ---------------------------------- > > @Valdis Kletnieks > >> You missed the part where the RFC says you *MUST* fall back to A if there's >> no MX. > > "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself; Therefore all progress depends on the unreasonable man" - George Bernard Shaw > > ---------------------------------- > @John Levine > > I was trying to contribute to IETF the other day. One of the guy from DMARC list uses your words as a reason to attack me and asking me to turn down the proposal. You were watching that. > > If I really solved the email spam problem, that puts me in the "best problem solvers in the world" category. So how about you go back to the DMARC list and write a decent apology for posting misinformation to everyone? [Of course only if I solved the spam problem. That was my claim from the beginning right?] > > ---------------------------------- > > @Everyone > > Here is what you all should know. > > It's my 5 years of research. So it's worth more than 50 words. I started my work back in 2013 and I used to call my work "XMail" at that time. It's now called "Dombox" > > My prototype codebase has around 200,000 lines of code. [To be exact: 466,965 ++ 254,169 --] > > Sequoia Capital is one of the well known venture firm in the world. They have invested in over 250 companies since 1972, including Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp. Bill Coughran is a senior investor in Sequoia Capital. According to his linkedin profile, he started as a Programmer in the late 60s and held many engineering related positions over the years. Worked in Bell Laboratories for 20 years. Worked as SVP of Engineering in Google for 8.5 years. To quote his words "I have some level of expertise about the current email systems, which is why I was did some investigating". So this man is one of the toughest person to impress. But he is one of the nicest investor I have met. When I asked him whether he can take a look, he didn't insult me with words like "You think you are the inventor of FUSSP?" He just told me "Sure, I'd be happy to." He went through my entire paper and then sent me this mail. He later turned me down because it's hard for a startup to distribute a new solution. Maybe he is right. Or maybe I'll overcome that too. [Today's discussion is about whether I solved the spam problem. Not about how I'm gonna distribute the solution] > > Yesterday I published my work on a medium blog post and linked my white paper. An engineer read my white paper and sent me this mail. > > These guys see value in my white paper because they completed my ~300 pages white paper. > > To the "50 words are enough" band members, let me tell you something. I'm the author of my work. It's my job to decide "what to show you" and "when to show you". I have posted my system summary in a medium blog post. When you reach 75% of the article, you will see a title called "Hot Gates Strategy". Everything you see above is pointless without the remaining 25% of the content. Put it this way, I have designed 75% of that system, only to have remaining 25% of the system. So yeah, even if you had 75% of the content, you still can't judge my work. > > Whether you all believe it or not, I'm the goddamn inventor of FUSSP. I can proudly say that because my system doesn't have the "spam" folder. So how about you all appreciate the guy who spent 5 years in chasing for a solution like a madman and succeeded in solving a challenging problem rather than spending your time in attacking me? [For the record, my single white paper plenty of problems. Email Spam is one of them] > > Looking forward to hear your feedback. People who complete my white paper, please post whether my claims are true or I'm just wasting everyone's time. > > [I'm going to bed now. So I may not be online for the next 8 hours. I'll respond to your queries after that] > > Thanks > > ---------------------------------- > > Materials: > > System Overview - https://medium.com/@Viruthagiri/dombox-the-zero-spam-mail-system-2b08ff7432cd > > White Paper - https://www.dombox.org/dombox.pdf > > Flowcharts - https://www.dombox.org/flowcharts.pdf > > Prototype - https://www.youtube.com/watch?v=VK2eSfCurx4 [This is the video I uploaded before posting to DMARC list. So the interface is little outdated] > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michel at targointernet.com Mon Feb 18 00:56:23 2019 From: Michel at targointernet.com (Michel Blais) Date: Sun, 17 Feb 2019 19:56:23 -0500 Subject: fs.com dwdm equipment In-Reply-To: References: Message-ID: I tryed SFP, MUX, DEMUX and OADM, all working as expected. Le dim. 17 févr. 2019 19 h 18, Samir Rana a écrit : > Hello All, > > Does anybody have experience with fs.com dwdm equipment in their > production environment? Are you they working without any issue? How's their > warranty support if the issue arises? > > Thanks in advance for all the answers and help. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddunder at gmail.com Mon Feb 18 02:17:57 2019 From: toddunder at gmail.com (Todd Underwood) Date: Sun, 17 Feb 2019 21:17:57 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: This is truly awful and off topic for network engineering. Please stop and try to listen to the people who are offering you feedback. On other lists. Not here. Thanks! T On Sun, Feb 17, 2019, 21:05 Viruthagiri Thirumavalavan Hello Everyone, > > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over > TLS on Port 26 > last > month. I'm also the guy who attacked (???) John Levine. > > Today I have something to show you. > > Long story short.... I solved the email spam problem. Well... Actually I > solved it long time back. I'm just ready to disclose it today. Again... > > Yeah.. Yeah.. Yeah... If only I had a dime for every time people insult me > for saying "I solved the spam problem" > > They usually start with the insult like "You think you are the inventor of > FUSSP?" > > These guys always are the know-it-all assholes. They don't listen. They > don't want to listen. They are like barking dogs. If one started to bark, > everyone else gets the courage to do the same thing. > > I'm tired of fighting these assholes in every mailing list. I'm on your > side morons. So how about you all knock it off? > > Six months back, it was John Levine who humiliated me in the DMARC list. > Apparently, for him 50 words are enough to attack me. > > Töma Gavrichenkov and Suresh Ramasubramanian even started to defend this > man saying 50 words are enough to judge a 50,000 words paper. [We are > gonna figure it out today] > > ---------------------------------- > > @Töma Gavrichenkov > > In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. > > > How can you be so sure that you didn't fuck up none of the lives of these > "few cases"? Or in more technical terms, How can you be absolutely sure > that there is no "False Positives"? > > ---------------------------------- > > @Suresh Ramasubramanian > > Yes, 50 words are more than enough to decide a bad idea is bad. You don't >> have to like that, or like any of us, but facts are facts > > > Merely appending the text "facts are facts" not gonna convert a bullshit > statement into a fact. > > You know what's the meaning of the word "fact"? It's a statement that can > be proved TRUE. > > Let's do a little experiment. 100 researchers presents their lifetime work > to us. Each of their research paper contain 50,000 words. We are gonna > judge them. > > You are gonna judge them based on only the first 50 words. And I'm gonna > judge them by tossing a coin. Can you guess who is gonna fuck up less > number of researcher lives? > > I'm claiming that I solved the email spam problem. If that's true, then > you should know, common sense is one of the very basic requirement for that. > > I designed my email system. Every inch of it. I wrote my research paper. > Every word of it. I made my prototype video. Every second of it. So I'm the > captain of my ship. Not you. But you all think you know my system better > than me? That too, with only 50 words? > > My research paper has around 50,000 words. And you think 50 words are > enough to judge my work? Let me make sure I get this right. You are all > saying, you know what's in the rest of the 49,950 words based on only the > first 50 words? That's stupid on so many levels. > > If you are gonna do a half-assed job and relay that misinformation to > thousands of people, why volunteer in the first place? And by the way, by > saying you are all doing half-assed job, I'm actually insulting the people > who are REALLY doing the half-assed job. > > ---------------------------------- > > John Levine vs. me > > One month back, some of you may have noticed a thread created by John > Levine > > where he goes like "He's Forum Shopping". The whole gist of that message > was "We already have DANE and MTA-STS. We don't a third solution". And then > I used some harsh words to defend myself. But that was the Season 2 of his > "Shitshow". The Season 1 was aired 6 months back. You all missed that show. > This is what happened in Season 1. > > > 1. Six months back, I posted on three mailing list saying "I solved > the email spam problem" and asked them to provide feedback on my invention. > Those three mailing lists were SPF, DKIM and DMARC. That's because my > solution relied on them and those three were the only email related mailing > lists I knew at that time. > 2. In DMARC community, John Levine started to insult me after reading > only the first 50 words. > 3. Dave Crocker joined the cast and did a flawless job on abusing me. > He asked me to kill my project. I told him he is being rude. And this is what > he replied for that . He is one > of the most radical and ignorant person I have seen in tech. He didn't even > stop for a moment and think "Am I attacking an Innocent person?". He even > went to other mailing lists to attack me. He abused all his power and kept > on attacking me just to have some "dopamine orgasm". Something tells me he > slept peacefully on that day. > 4. And then bunch of other guys joined. So the whole thread gone > crazy. This is because John Levine successfully distributed wrong version > of the story to thousands of people with only 50 words. > 5. Both Dave Crocker and John Levine are the bigshots there. So I knew > no matter how much I cry for help, no one is gonna help me. > 6. John seemed like a "decent-asshole" while compared to Dave Crocker. > So I sent a private mail to John saying "John, I'm not really sure whether > I can afford you since I have not raised any money yet. But let me give it > a shot. Could you tell me how much you would charge to go through my > presentation, demo video and give me a detailed feedback about my system?" > [The reason I was ready to pay him is because he made it very clear in the > DMARC thread by saying "Sorry, but I don't provide consulting for free". I > thought if I make him read my document, he would go back and correct his > mistake] > 7. And this is what he replied for that. "Really, even if you had > money, it wouldn't be worth your money or my time". [For the record, he > come to this conclusion without even knowing what's inside in my document] > 8. I said only "ok, thankyou" and then unsubscribed from the DMARC > mailing list. [What more can you argue with a bunch of know-it-all morons > who thinks they are all right?] > 9. Six month later (last month), John started his shitshow again > attacking my IETF proposal. He tried to make me look like an idiot again. > And that's when I started to defend myself by using harsh words. > 10. You all know the rest. > > > ---------------------------------- > > One person told me on that thread to take John Levine's words as > criticism. > > You see I have no problems with criticism. I usually thank people when > they criticize my work. The best criticism usually follows this format. > > "I went through your paper (#1), your work is full of shit (#2), Here are > the reasons (#3)" > > #1 says, the critic really knows what the author is talking about. > #2 says, the critic is speaking his mind without any bullshit. > #3 says, the critic has valid points for his criticism. > > However, I can't consider someone as critic who straightly go for #2. > Especially when the whole argument was all about killing my work just > because he is one of the inventor of MTA-STS. > > If I start to listen his words, then next time he will create a new thread > to attack me for creating saying "He's forum shopping. I > already told him it's not worth his money and my time". What you want me to > do in this case? Take that as criticism and move on? It's my 5 fucking > years of research. I can't just let it go just because someone doesn't like > my work. > > ---------------------------------- > > @Valdis Kletnieks > > You missed the part where the RFC says you *MUST* fall back to A if there's >> no MX. > > > "The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself; Therefore all progress > depends on the unreasonable man" - George Bernard Shaw > > ---------------------------------- > @John Levine > > I was trying to contribute to IETF the other day. One of the guy from > DMARC list uses your words as a reason to attack me > and asking me to turn down > the proposal. You were watching that. > > If I really solved the email spam problem, that puts me in the "best > problem solvers in the world" category. So how about you go back to the > DMARC list and write a decent apology for posting misinformation to > everyone? [Of course only if I solved the spam problem. That was my claim > from the beginning right?] > > ---------------------------------- > > @Everyone > > Here is what you all should know. > > It's my 5 years of research. So it's worth more than 50 words. I started > my work back in 2013 and I used to call my work "XMail" at that time. It's > now called "Dombox" > > My prototype codebase has around 200,000 lines of code. [To be exact: > 466,965 ++ 254,169 --] > > Sequoia Capital is one of the well known venture firm in the world. They > have invested in over 250 companies since 1972, including Apple, Google, > Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp. Bill > Coughran is a senior > investor in Sequoia Capital. According to his linkedin profile, he started > as a Programmer in the late 60s and held many engineering related positions > over the years. Worked in Bell Laboratories for 20 years. Worked as SVP of > Engineering in Google for 8.5 years. To quote his words "I have some level > of expertise about the current email systems, which is why I was did some > investigating". So this man is one of the toughest person to impress. But > he is one of the nicest investor I have met. When I asked him whether he > can take a look, he didn't insult me with words like "You think you are the > inventor of FUSSP?" He just told me "Sure, I'd be happy to." He went > through my entire paper and then sent me this mail > . He later turned me down > because it's hard for a startup to distribute a new solution. Maybe he is > right. Or maybe I'll overcome that too. [Today's discussion is about > whether I solved the spam problem. Not about how I'm gonna distribute the > solution] > > Yesterday I published my work on a medium blog post and linked my white > paper. An engineer read my white paper and sent me this mail > . > > These guys see value in my white paper because they completed my ~300 > pages white paper. > > To the "50 words are enough" band members, let me tell you something. I'm > the author of my work. It's my job to decide "what to show you" and "when > to show you". I have posted my system summary in a medium blog post. When > you reach 75% of the article, you will see a title called "Hot Gates > Strategy". Everything you see above is pointless without the remaining 25% > of the content. Put it this way, I have designed 75% of that system, only > to have remaining 25% of the system. So yeah, even if you had 75% of the > content, you still can't judge my work. > > Whether you all believe it or not, I'm the goddamn inventor of FUSSP. I > can proudly say that because my system doesn't have the "spam" folder. So > how about you all appreciate the guy who spent 5 years in chasing for a > solution like a madman and succeeded in solving a challenging problem > rather than spending your time in attacking me? [For the record, my single > white paper plenty of problems. Email Spam is one of them] > > Looking forward to hear your feedback. People who complete my white paper, > please post whether my claims are true or I'm just wasting everyone's time. > > [I'm going to bed now. So I may not be online for the next 8 hours. I'll > respond to your queries after that] > > Thanks > > ---------------------------------- > > Materials: > > System Overview - > https://medium.com/@Viruthagiri/dombox-the-zero-spam-mail-system-2b08ff7432cd > > White Paper - https://www.dombox.org/dombox.pdf > > Flowcharts - https://www.dombox.org/flowcharts.pdf > > Prototype - https://www.youtube.com/watch?v=VK2eSfCurx4 [This is the > video I uploaded before posting to DMARC list. So the interface is little > outdated] > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Mon Feb 18 02:25:36 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 18 Feb 2019 07:55:36 +0530 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <027F7B2B-CBF6-400B-91C7-8DB10BC224D5@2mbit.com> References: <027F7B2B-CBF6-400B-91C7-8DB10BC224D5@2mbit.com> Message-ID: There's this small percentage of cranks that are brilliant Doc Emmett Brown level inventors who come up with truly brilliant products and solutions. And then there's the much larger percentage of cranks that have a bad idea that they're prepared to defend to the last. Very well then .. On Mon, Feb 18, 2019 at 7:51 AM Brielle wrote: > > You literally lost my interest in reading your solution when I realized that 99.99999999999% of this post is just you railing against people. > > People are right, if you can’t get my attention in 50 words, then either your solution isn’t a solution but a marketing ploy, or you need someone who actually knows how to present things to people in this field. > > Im a former DNSbl maintainer - I get excited over new anti spam solutions and love to throw resources at new solutions. > > So yeah, this is a non starter. > > Sent from my iPhone > > On Feb 17, 2019, at 7:03 PM, Viruthagiri Thirumavalavan wrote: > > Hello Everyone, > > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over TLS on Port 26 last month. I'm also the guy who attacked (???) John Levine. > > Today I have something to show you. > > Long story short.... I solved the email spam problem. Well... Actually I solved it long time back. I'm just ready to disclose it today. Again... > > Yeah.. Yeah.. Yeah... If only I had a dime for every time people insult me for saying "I solved the spam problem" > > They usually start with the insult like "You think you are the inventor of FUSSP?" > > These guys always are the know-it-all assholes. They don't listen. They don't want to listen. They are like barking dogs. If one started to bark, everyone else gets the courage to do the same thing. > > I'm tired of fighting these assholes in every mailing list. I'm on your side morons. So how about you all knock it off? > > Six months back, it was John Levine who humiliated me in the DMARC list. Apparently, for him 50 words are enough to attack me. > > Töma Gavrichenkov and Suresh Ramasubramanian even started to defend this man saying 50 words are enough to judge a 50,000 words paper. [We are gonna figure it out today] > > ---------------------------------- > > @Töma Gavrichenkov > >> In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. > > > How can you be so sure that you didn't fuck up none of the lives of these "few cases"? Or in more technical terms, How can you be absolutely sure that there is no "False Positives"? > > ---------------------------------- > > @Suresh Ramasubramanian > >> Yes, 50 words are more than enough to decide a bad idea is bad. You don't have to like that, or like any of us, but facts are facts > > > Merely appending the text "facts are facts" not gonna convert a bullshit statement into a fact. > > You know what's the meaning of the word "fact"? It's a statement that can be proved TRUE. > > Let's do a little experiment. 100 researchers presents their lifetime work to us. Each of their research paper contain 50,000 words. We are gonna judge them. > > You are gonna judge them based on only the first 50 words. And I'm gonna judge them by tossing a coin. Can you guess who is gonna fuck up less number of researcher lives? > > I'm claiming that I solved the email spam problem. If that's true, then you should know, common sense is one of the very basic requirement for that. > > I designed my email system. Every inch of it. I wrote my research paper. Every word of it. I made my prototype video. Every second of it. So I'm the captain of my ship. Not you. But you all think you know my system better than me? That too, with only 50 words? > > My research paper has around 50,000 words. And you think 50 words are enough to judge my work? Let me make sure I get this right. You are all saying, you know what's in the rest of the 49,950 words based on only the first 50 words? That's stupid on so many levels. > > If you are gonna do a half-assed job and relay that misinformation to thousands of people, why volunteer in the first place? And by the way, by saying you are all doing half-assed job, I'm actually insulting the people who are REALLY doing the half-assed job. > > ---------------------------------- > > John Levine vs. me > > One month back, some of you may have noticed a thread created by John Levine where he goes like "He's Forum Shopping". The whole gist of that message was "We already have DANE and MTA-STS. We don't a third solution". And then I used some harsh words to defend myself. But that was the Season 2 of his "Shitshow". The Season 1 was aired 6 months back. You all missed that show. This is what happened in Season 1. > > Six months back, I posted on three mailing list saying "I solved the email spam problem" and asked them to provide feedback on my invention. Those three mailing lists were SPF, DKIM and DMARC. That's because my solution relied on them and those three were the only email related mailing lists I knew at that time. > In DMARC community, John Levine started to insult me after reading only the first 50 words. > Dave Crocker joined the cast and did a flawless job on abusing me. He asked me to kill my project. I told him he is being rude. And this is what he replied for that. He is one of the most radical and ignorant person I have seen in tech. He didn't even stop for a moment and think "Am I attacking an Innocent person?". He even went to other mailing lists to attack me. He abused all his power and kept on attacking me just to have some "dopamine orgasm". Something tells me he slept peacefully on that day. > And then bunch of other guys joined. So the whole thread gone crazy. This is because John Levine successfully distributed wrong version of the story to thousands of people with only 50 words. > Both Dave Crocker and John Levine are the bigshots there. So I knew no matter how much I cry for help, no one is gonna help me. > John seemed like a "decent-asshole" while compared to Dave Crocker. So I sent a private mail to John saying "John, I'm not really sure whether I can afford you since I have not raised any money yet. But let me give it a shot. Could you tell me how much you would charge to go through my presentation, demo video and give me a detailed feedback about my system?" [The reason I was ready to pay him is because he made it very clear in the DMARC thread by saying "Sorry, but I don't provide consulting for free". I thought if I make him read my document, he would go back and correct his mistake] > And this is what he replied for that. "Really, even if you had money, it wouldn't be worth your money or my time". [For the record, he come to this conclusion without even knowing what's inside in my document] > I said only "ok, thankyou" and then unsubscribed from the DMARC mailing list. [What more can you argue with a bunch of know-it-all morons who thinks they are all right?] > Six month later (last month), John started his shitshow again attacking my IETF proposal. He tried to make me look like an idiot again. And that's when I started to defend myself by using harsh words. > You all know the rest. > > > ---------------------------------- > > One person told me on that thread to take John Levine's words as criticism. > > You see I have no problems with criticism. I usually thank people when they criticize my work. The best criticism usually follows this format. > > "I went through your paper (#1), your work is full of shit (#2), Here are the reasons (#3)" > > #1 says, the critic really knows what the author is talking about. > #2 says, the critic is speaking his mind without any bullshit. > #3 says, the critic has valid points for his criticism. > > However, I can't consider someone as critic who straightly go for #2. Especially when the whole argument was all about killing my work just because he is one of the inventor of MTA-STS. > > If I start to listen his words, then next time he will create a new thread to attack me for creating saying "He's forum shopping. I already told him it's not worth his money and my time". What you want me to do in this case? Take that as criticism and move on? It's my 5 fucking years of research. I can't just let it go just because someone doesn't like my work. > > ---------------------------------- > > @Valdis Kletnieks > >> You missed the part where the RFC says you *MUST* fall back to A if there's >> no MX. > > > "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself; Therefore all progress depends on the unreasonable man" - George Bernard Shaw > > ---------------------------------- > @John Levine > > I was trying to contribute to IETF the other day. One of the guy from DMARC list uses your words as a reason to attack me and asking me to turn down the proposal. You were watching that. > > If I really solved the email spam problem, that puts me in the "best problem solvers in the world" category. So how about you go back to the DMARC list and write a decent apology for posting misinformation to everyone? [Of course only if I solved the spam problem. That was my claim from the beginning right?] > > ---------------------------------- > > @Everyone > > Here is what you all should know. > > It's my 5 years of research. So it's worth more than 50 words. I started my work back in 2013 and I used to call my work "XMail" at that time. It's now called "Dombox" > > My prototype codebase has around 200,000 lines of code. [To be exact: 466,965 ++ 254,169 --] > > Sequoia Capital is one of the well known venture firm in the world. They have invested in over 250 companies since 1972, including Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp. Bill Coughran is a senior investor in Sequoia Capital. According to his linkedin profile, he started as a Programmer in the late 60s and held many engineering related positions over the years. Worked in Bell Laboratories for 20 years. Worked as SVP of Engineering in Google for 8.5 years. To quote his words "I have some level of expertise about the current email systems, which is why I was did some investigating". So this man is one of the toughest person to impress. But he is one of the nicest investor I have met. When I asked him whether he can take a look, he didn't insult me with words like "You think you are the inventor of FUSSP?" He just told me "Sure, I'd be happy to." He went through my entire paper and then sent me this mail. He later turned me down because it's hard for a startup to distribute a new solution. Maybe he is right. Or maybe I'll overcome that too. [Today's discussion is about whether I solved the spam problem. Not about how I'm gonna distribute the solution] > > Yesterday I published my work on a medium blog post and linked my white paper. An engineer read my white paper and sent me this mail. > > These guys see value in my white paper because they completed my ~300 pages white paper. > > To the "50 words are enough" band members, let me tell you something. I'm the author of my work. It's my job to decide "what to show you" and "when to show you". I have posted my system summary in a medium blog post. When you reach 75% of the article, you will see a title called "Hot Gates Strategy". Everything you see above is pointless without the remaining 25% of the content. Put it this way, I have designed 75% of that system, only to have remaining 25% of the system. So yeah, even if you had 75% of the content, you still can't judge my work. > > Whether you all believe it or not, I'm the goddamn inventor of FUSSP. I can proudly say that because my system doesn't have the "spam" folder. So how about you all appreciate the guy who spent 5 years in chasing for a solution like a madman and succeeded in solving a challenging problem rather than spending your time in attacking me? [For the record, my single white paper plenty of problems. Email Spam is one of them] > > Looking forward to hear your feedback. People who complete my white paper, please post whether my claims are true or I'm just wasting everyone's time. > > [I'm going to bed now. So I may not be online for the next 8 hours. I'll respond to your queries after that] > > Thanks > > ---------------------------------- > > Materials: > > System Overview - https://medium.com/@Viruthagiri/dombox-the-zero-spam-mail-system-2b08ff7432cd > > White Paper - https://www.dombox.org/dombox.pdf > > Flowcharts - https://www.dombox.org/flowcharts.pdf > > Prototype - https://www.youtube.com/watch?v=VK2eSfCurx4 [This is the video I uploaded before posting to DMARC list. So the interface is little outdated] > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. -- Suresh Ramasubramanian (ops.lists at gmail.com) From michel.py at tsisemi.com Mon Feb 18 02:52:16 2019 From: michel.py at tsisemi.com (Michel Py) Date: Mon, 18 Feb 2019 02:52:16 +0000 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> > Viruthagiri Thirumavalavan wrote : > I solved the email spam problem. Oh, this is wonderful news. There are plenty of other problems that need your brilliance. In no specific order : - Global warming. - Nuclear proliferation. - Peace in the middle east. - World hunger. - IPv6 multihoming. We will be looking for your next improvement. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From mfidelman at meetinghouse.net Mon Feb 18 02:56:37 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 17 Feb 2019 21:56:37 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> References: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> Message-ID: I can't get past all the blabbering to bother reviewing stuff. But why does this guy remind me of Shiva Ayyadurai - you know, the "inventor of email." Seriously - isn't the general rule to start with a demonstration, not a polemic?  (Shiva actually built an email system.  And people actually used it.) On 2/17/19 9:52 PM, Michel Py wrote: >> Viruthagiri Thirumavalavan wrote : >> I solved the email spam problem. > Oh, this is wonderful news. > There are plenty of other problems that need your brilliance. In no specific order : > > - Global warming. > - Nuclear proliferation. > - Peace in the middle east. > - World hunger. > - IPv6 multihoming. > > We will be looking for your next improvement. > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ops.lists at gmail.com Mon Feb 18 02:57:07 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 18 Feb 2019 08:27:07 +0530 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> References: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> Message-ID: <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> ... and of all those, once you solve v6 multihoming (possibly with ipv9) do come back to nanog where I'm sure it will be operational. On 18/02/19, 8:23 AM, "NANOG on behalf of Michel Py" wrote: > Viruthagiri Thirumavalavan wrote : > I solved the email spam problem. Oh, this is wonderful news. There are plenty of other problems that need your brilliance. In no specific order : - Global warming. - Nuclear proliferation. - Peace in the middle east. - World hunger. - IPv6 multihoming. We will be looking for your next improvement. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From jlewis at lewis.org Mon Feb 18 03:15:02 2019 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 17 Feb 2019 22:15:02 -0500 (EST) Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: On Mon, 18 Feb 2019, Viruthagiri Thirumavalavan wrote: > Hello Everyone, > > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over TLS on Port 26 last month. > I'm also the guy who attacked (???) John Levine. > > Today I have something to show you.  > > Long story short.... I solved the email spam problem. Well... Actually I solved it long time back. I'm > just ready to disclose it today. Again... Spam and email really aren't "on-topic" for NANOG. That said, I was intrigued, so I did get a several dozen pages into your white paper. 1) If you wrote that, you need to stop and hire/con someone else to do your tech writing. To say your writing is atrocious does not do it justice. 2) The ideas look like they may have some merit, except that the average Internet/email user is neither capable of nor willing to manage domboxes for every entity from which they expect to receive transactional email. I didn't get much further into the paper than this, because, as mentioned, your writing style SUCKS and I'm not strapped into my poetry appreciation chair, so you can't make me endure any more of it. So, in summary, too complicated for my mom to use, and such a crappy delivery of the idea that I can't imagine anyone will get through the entire pitch (to tell you what the other flaws are). ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ross at tajvar.io Mon Feb 18 03:14:53 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sun, 17 Feb 2019 22:14:53 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> References: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> Message-ID: Not to derail this highly relevant thread, and forgive my ignorance, but what's the issue with IPv6 multihoming? On Sun, Feb 17, 2019, 10:01 PM Suresh Ramasubramanian ... and of all those, once you solve v6 multihoming (possibly with ipv9) > do come back to nanog where I'm sure it will be operational. > > On 18/02/19, 8:23 AM, "NANOG on behalf of Michel Py" < > nanog-bounces at nanog.org on behalf of michel.py at tsisemi.com> wrote: > > > Viruthagiri Thirumavalavan wrote : > > I solved the email spam problem. > > Oh, this is wonderful news. > There are plenty of other problems that need your brilliance. In no > specific order : > > - Global warming. > - Nuclear proliferation. > - Peace in the middle east. > - World hunger. > - IPv6 multihoming. > > We will be looking for your next improvement. > > TSI Disclaimer: This message and any files or text attached to it are > intended only for the recipients named above and contain information that > may be confidential or privileged. If you are not the intended recipient, > you must not forward, copy, use or otherwise disclose this communication or > the information contained herein. In the event you have received this > message in error, please notify the sender immediately by replying to this > message, and then delete all copies of it from your system. Thank you!... > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Mon Feb 18 03:16:50 2019 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 17 Feb 2019 22:16:50 -0500 (EST) Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> References: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> Message-ID: Anyone else having flashbacks to Jim Fleming telling us about how IPv8 was the final ultimate solution to IPv4 runout? On Mon, 18 Feb 2019, Suresh Ramasubramanian wrote: > ... and of all those, once you solve v6 multihoming (possibly with ipv9) do come back to nanog where I'm sure it will be operational. > > On 18/02/19, 8:23 AM, "NANOG on behalf of Michel Py" wrote: > > > Viruthagiri Thirumavalavan wrote : > > I solved the email spam problem. > > Oh, this is wonderful news. > There are plenty of other problems that need your brilliance. In no specific order : > > - Global warming. > - Nuclear proliferation. > - Peace in the middle east. > - World hunger. > - IPv6 multihoming. > > We will be looking for your next improvement. > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... > > > > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From valdis.kletnieks at vt.edu Mon Feb 18 03:21:30 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 17 Feb 2019 22:21:30 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <2163.1550460090@turing-police.cc.vt.edu> On Mon, 18 Feb 2019 07:33:32 +0530, Viruthagiri Thirumavalavan said: > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over > TLS on Port 26 Unfortunately, your attempt there didn't demonstrate an in-depth knowledge of the email ecology of the sort needed to *actually* solve the spam problem. > Today I have something to show you. > > Long story short.... I solved the email spam problem. Well... Actually I > solved it long time back. I'm just ready to disclose it today. Again... So actually *disclose* it already, rather than whining about how you've been treated. And there's this telling statement: > [Today's discussion is about whether I solved the spam problem. Not about how > I'm gonna distribute the solution] You apparently don't understand that how the solution gets distributed is a very important part of whether the solution will work. Bottom line: You hit most of the points in Vernon Schryver's FUSSP list, plus an amazing number of points in John Baez's crackpot index. Not a good way to start. So because I'm needing some entertainment, I went to go check the Medium post. > "Spammers have no idea what's going on INSIDE the email system. i.e. They > have no idea whether their mail gets marked as spam or not." Oh, you poor, poor uneducated person. Spammers have a *very good* idea of whether it was marked as spam. > "Now, what if your first mail get rejected with an error message like "Unauthorized Sender"? > Would you still write your follow-up mail? No, right?" At which point you totally miss the point - for a spammer, the reasonable thing to do is *send another mail with a different From: value*, in hopes of hitting one that's an "authorized sender". > "So when mails get rejected with an error message, spammers gonna remove your > email address from their email list. That's because your email address is a > dead end for them." OK, I'm done here. We obviously have a total lack of understanding of the problem space, and it's very unlikely that an actually correct solution will arise from that. Also, I'll offer you a totally free piece of technical advice: Those SAD entries in the DNS that you're hoping to use to tie domains together are trivially forgeable. To save everybody else the effort: As far as I can tell, he's re-invented plus addressing, and says that if everybody creates mailboxes john.smith at example.com for personal mail, and a john.smith+nanog at example.com for nanog mail, and john.smith+my-bank at example.com for his bank emails, spam will apparently give up in defeat There's a whole bunch more, including assuming that Joe Sixpack *will* create a separate address for each "transactional" piece of mail, that spammers won't send mail that looks like personal mail, that spammers won't create bogus DNS entries, and a few other whoppers... From valdis.kletnieks at vt.edu Mon Feb 18 03:26:52 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 17 Feb 2019 22:26:52 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> Message-ID: <2402.1550460412@turing-police.cc.vt.edu> On Sun, 17 Feb 2019 22:16:50 -0500, Jon Lewis said: > Anyone else having flashbacks to Jim Fleming telling us about how IPv8 was > the final ultimate solution to IPv4 runout? I was thinking more of the guy who was convinced that each octet in an IPV4 address could store 0 through 256. From timoid at timoid.org Mon Feb 18 03:50:35 2019 From: timoid at timoid.org (Tim Warnock) Date: Mon, 18 Feb 2019 03:50:35 +0000 Subject: TATA/AS6453 BGP communities Message-ID: Hey, Anyone have a list of BGP communities for TATA/AS6453? Mainly chasing geo tags. Their peeringdb contacts are non-responsive. Thanks Tim. From edugas at unknowndevice.ca Mon Feb 18 03:54:17 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Sun, 17 Feb 2019 22:54:17 -0500 Subject: TATA/AS6453 BGP communities In-Reply-To: References: Message-ID: <1550462042.local-2297a964-aab4-v1.5.6-4cb1851b@getmailspring.com> There you go: https://www.scribd.com/document/399871041/TATA-AS6453-BGP-Communities On Feb 17 2019, at 10:50 pm, Tim Warnock wrote: > Hey, > > Anyone have a list of BGP communities for TATA/AS6453? Mainly chasing geo tags. > Their peeringdb contacts are non-responsive. > Thanks > Tim. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From timoid at timoid.org Mon Feb 18 03:59:48 2019 From: timoid at timoid.org (Tim Warnock) Date: Mon, 18 Feb 2019 03:59:48 +0000 Subject: TATA/AS6453 BGP communities In-Reply-To: <1550462042.local-2297a964-aab4-v1.5.6-4cb1851b@getmailspring.com> References: <1550462042.local-2297a964-aab4-v1.5.6-4cb1851b@getmailspring.com> Message-ID: <19b4290e4e734b9a8389eab66a25c33c@timoid.org> > From: Eric Dugas [mailto:edugas at unknowndevice.ca] > Sent: Monday, 18 February 2019 1:54 PM > To: Tim Warnock > Cc: NANOG list > Subject: Re: TATA/AS6453 BGP communities > > There you go: https://www.scribd.com/document/399871041/TATA-AS6453- > BGP-Communities > Legendary! Thanks :) From david at zeromail.us Mon Feb 18 05:00:31 2019 From: david at zeromail.us (David S.) Date: Mon, 18 Feb 2019 12:00:31 +0700 Subject: fs.com dwdm equipment In-Reply-To: References: Message-ID: They have solid product and good support, I bought many SFP+ for Nexus, Juniper, Force10 and never had a problem with them. HTH Best regards, David S. ------------------------------------------------ e. david at zeromail.us w. pnyet.web.id p. 087881216110 On Mon, Feb 18, 2019 at 9:23 AM Michel Blais wrote: > I tryed SFP, MUX, DEMUX and OADM, all working as expected. > > Le dim. 17 févr. 2019 19 h 18, Samir Rana a écrit : > >> Hello All, >> >> Does anybody have experience with fs.com dwdm equipment in their >> production environment? Are you they working without any issue? How's their >> warranty support if the issue arises? >> >> Thanks in advance for all the answers and help. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Mon Feb 18 05:35:05 2019 From: matt at netfire.net (Matt Harris) Date: Sun, 17 Feb 2019 23:35:05 -0600 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <2163.1550460090@turing-police.cc.vt.edu> References: <2163.1550460090@turing-police.cc.vt.edu> Message-ID: On Sun, Feb 17, 2019 at 9:23 PM wrote: > > > [Today's discussion is about whether I solved the spam problem. Not > about how > > I'm gonna distribute the solution] > > You apparently don't understand that how the solution gets distributed is a > very important part of whether the solution will work. > If only everyone would change everything about how they do everything overnight, pay me/my company, and trust me/my company as a central authority... well, we'd have no problems, *I guarantee it!* I tried whole-assedly skimming the first two dozen pages of his pdf doc and switched to half-assedly for the latter several hundred pages. My take-away is that he has a company called dombox/teleport, and if we pay him to authorize us as not being spammers, then we're not spammers. But instead of simply that, also every system and the way everyone uses email, including trusting him as a primary point of authority, has to change before it works. Page 121 states that every website on the entire internet will need to implement his buttons. There's also some rather onerous sounding stuff around page 115 where he states that users won't be able to delete their email accounts, or the contents thereof. So I'm pretty sure this system is entirely in violation of European law. > > "Now, what if your first mail get rejected with an error message like > "Unauthorized Sender"? > > Would you still write your follow-up mail? No, right?" > > At which point you totally miss the point - for a spammer, the reasonable > thing to do > is *send another mail with a different From: value*, in hopes of hitting > one that's > an "authorized sender". > Further, most recipients can't be burdened with having to authorize every potential sender. Systems implementing that logic have been implemented in various and sundry places, and never for very long. To save everybody else the effort: As far as I can tell, he's re-invented > plus > addressing, and says that if everybody creates mailboxes > john.smith at example.com > for personal mail, and a john.smith+nanog at example.com for nanog mail, and > john.smith+my-bank at example.com for his bank emails, spam will apparently > give > up in defeat > I'm pretty sure there was something in there about paying him to act as a central authority too, you've gotta half-assedly skim another hundred pages to get to it, though. Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at interall.co.il Mon Feb 18 05:54:04 2019 From: hank at interall.co.il (hank at interall.co.il) Date: Mon, 18 Feb 2019 07:54:04 +0200 Subject: A Zero Spam Mail System [Feedback Request] Message-ID: <20190218075404.17625pi1kooi30qk@62.219.67.37> On 18/02/2019 04:03, Viruthagiri Thirumavalavan wrote: If that is the case you should have a startup worth at least $10M with numerous VC banging down your door. If not, you need to ask yourself the question "why not?". -Hank > Hello Everyone, > > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP > over TLS on Port 26 last month. I'm also the guy who attacked (???) > John Levine. > > Today I have something to show you. Long story short.... I solved > the email spam problem. Well... Actually I solved it long time back. > I'm just ready to disclose it today. Again... > > @Everyone > > Here is what you all should know. > > It's my 5 years of research. So it's worth more than 50 words. I > started my work back in 2013 and I used to call my work "XMail" at > that time. It's now called "Dombox" > > My prototype codebase has around 200,000 lines of code. [To be > exact: 466,965 ++ 254,169 --] > > Sequoia Capital is one of the well known venture firm in the world. > They have invested in over 250 companies since 1972, including > Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! > and WhatsApp. Bill Coughran is a senior investor in Sequoia Capital. > According to his linkedin profile, he started as a Programmer in the > late 60s and held many engineering related positions over the years. > Worked in Bell Laboratories for 20 years. Worked as SVP of > Engineering in Google for 8.5 years. To quote his words "I have some > level of expertise about the current email systems, which is why I > was did some investigating". So this man is one of the toughest > person to impress. But he is one of the nicest investor I have met. > When I asked him whether he can take a look, he didn't insult me > with words like "You think you are the inventor of FUSSP?" He just > told me "Sure, I'd be happy to." He went through my entire paper and > then sent me this mail. He later turned me down because it's hard > for a startup to distribute a new solution. Maybe he is right. Or > maybe I'll overcome that too. [Today's discussion is about whether I > solved the spam problem. Not about how I'm gonna distribute the > solution] > > Yesterday I published my work on a medium blog post and linked my > white paper. An engineer read my white paper and sent me this mail. > These guys see value in my white paper because they completed my > ~300 pages white paper. ---------------------------------- > > Materials: > > System Overview - > https://medium.com/@Viruthagiri/dombox-the-zero-spam-mail-system-2b08ff7432cd > > White Paper - https://www.dombox.org/dombox.pdf > > Flowcharts - https://www.dombox.org/flowcharts.pdf > > Prototype - https://www.youtube.com/watch?v=VK2eSfCurx4 [This is the > video I uploaded before posting to DMARC list. So the interface is > little outdated] > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. From bzs at theworld.com Mon Feb 18 05:59:06 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 18 Feb 2019 00:59:06 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <23658.18858.515661.965019@gargle.gargle.HOWL> I made it a few dozen pages into the white paper, it's 200+ pages long and TBH just rambles on about what spam bots are and other basic definitions. No one who doesn't know all that will even attempt to read your paper I don't think. THAT SAID, I got to the point where it required CAPTCHAs of senders and thought well, that's theoretically possible, but quite a threshold to expect of others who may not much care if you read their email, but you the recipient may care a lot and oh well you never get the mail. It doesn't add much, really, and spammers figured out how to bust things like CAPTCHAs decades ago*. I accept there's probably more to your idea, put it on one or two pages. * Take the CAPTCHA image, flash it up on another site which offers access to free porn for solving the CAPTCHA, forward answer to original site. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From mel at beckman.org Mon Feb 18 06:17:18 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 18 Feb 2019 06:17:18 +0000 Subject: fs.com dwdm equipment In-Reply-To: References: , Message-ID: <21AA4487-7E10-4398-8A79-A960EAE7DC7A@beckman.org> We’ve purchased many SFP modules from fs.com for Cisco gear, and the only problem we run into is that Cisco IOS seem unwilling to expose the error counters via SNMP. This is kind of annoying, because that’s how we get early warning of fiber problems. I suspect IOS does this deliberately because it notices the module is not OEM. But the cost savings with fs.com is tremendous, so we put up with this inconvenience. On a side note, their sales support is always prompt and very personable. Technical support seems to be limited to offering free advance warranty replacement shipping. With a few hundred modules, we’ve had maybe two dead ones. So less than 1% iinfant mortality on pretty complex optics. -mel On Feb 17, 2019, at 9:01 PM, David S. > wrote: They have solid product and good support, I bought many SFP+ for Nexus, Juniper, Force10 and never had a problem with them. HTH Best regards, David S. ------------------------------------------------ e. david at zeromail.us w. pnyet.web.id p. 087881216110 On Mon, Feb 18, 2019 at 9:23 AM Michel Blais > wrote: I tryed SFP, MUX, DEMUX and OADM, all working as expected. Le dim. 17 févr. 2019 19 h 18, Samir Rana > a écrit : Hello All, Does anybody have experience with fs.com dwdm equipment in their production environment? Are you they working without any issue? How's their warranty support if the issue arises? Thanks in advance for all the answers and help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egon at egon.cc Mon Feb 18 03:42:05 2019 From: egon at egon.cc (James Downs) Date: Sun, 17 Feb 2019 19:42:05 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <2402.1550460412@turing-police.cc.vt.edu> References: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> <2402.1550460412@turing-police.cc.vt.edu> Message-ID: > On Feb 17, 2019, at 19:26, valdis.kletnieks at vt.edu wrote: > I was thinking more of the guy who was convinced that each octet in an IPV4 > address could store 0 through 256. That's what the overflow flag is for, right? From jna at retina.net Mon Feb 18 06:38:38 2019 From: jna at retina.net (John Adams) Date: Sun, 17 Feb 2019 22:38:38 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <2163.1550460090@turing-police.cc.vt.edu> References: <2163.1550460090@turing-police.cc.vt.edu> Message-ID: <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Agreed. I’ve never seen someone so excited to have reinvented TMDA from the 1990’s. Please, tell us more how the Internet will readdress itself to meet your fascinating solution. Can we go back to talking about network engineering now? Sent from my iPhone > On Feb 17, 2019, at 19:21, valdis.kletnieks at vt.edu wrote: > > On Mon, 18 Feb 2019 07:33:32 +0530, Viruthagiri Thirumavalavan said: >> My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over >> TLS on Port 26 > > Unfortunately, your attempt there didn't demonstrate an in-depth knowledge of > the email ecology of the sort needed to *actually* solve the spam problem. > >> Today I have something to show you. >> >> Long story short.... I solved the email spam problem. Well... Actually I >> solved it long time back. I'm just ready to disclose it today. Again... > > So actually *disclose* it already, rather than whining about how you've been > treated. > > And there's this telling statement: > >> [Today's discussion is about whether I solved the spam problem. Not about how >> I'm gonna distribute the solution] > > You apparently don't understand that how the solution gets distributed is a > very important part of whether the solution will work. > > Bottom line: You hit most of the points in Vernon Schryver's FUSSP list, plus > an amazing number of points in John Baez's crackpot index. Not a good way to > start. > > So because I'm needing some entertainment, I went to go check the Medium post. > >> "Spammers have no idea what's going on INSIDE the email system. i.e. They >> have no idea whether their mail gets marked as spam or not." > > Oh, you poor, poor uneducated person. Spammers have a *very good* idea > of whether it was marked as spam. > >> "Now, what if your first mail get rejected with an error message like "Unauthorized Sender"? >> Would you still write your follow-up mail? No, right?" > > At which point you totally miss the point - for a spammer, the reasonable thing to do > is *send another mail with a different From: value*, in hopes of hitting one that's > an "authorized sender". > >> "So when mails get rejected with an error message, spammers gonna remove your >> email address from their email list. That's because your email address is a >> dead end for them." > > OK, I'm done here. We obviously have a total lack of understanding of the > problem space, and it's very unlikely that an actually correct solution will > arise from that. > > Also, I'll offer you a totally free piece of technical advice: Those SAD > entries in the DNS that you're hoping to use to tie domains together are > trivially forgeable. > > To save everybody else the effort: As far as I can tell, he's re-invented plus > addressing, and says that if everybody creates mailboxes john.smith at example.com > for personal mail, and a john.smith+nanog at example.com for nanog mail, and > john.smith+my-bank at example.com for his bank emails, spam will apparently give > up in defeat > > There's a whole bunch more, including assuming that Joe Sixpack *will* create a > separate address for each "transactional" piece of mail, that spammers won't > send mail that looks like personal mail, that spammers won't create bogus DNS > entries, and a few other whoppers... > From CGross at ninestarconnect.com Mon Feb 18 06:39:57 2019 From: CGross at ninestarconnect.com (Chris Gross) Date: Mon, 18 Feb 2019 06:39:57 +0000 Subject: fs.com dwdm equipment In-Reply-To: References: Message-ID: For managing them, do you use the actual software they ship with it? When I last checked, it requires a MSSQL instance with hard coded “sa” user access which was an immediate no go for me. I still have them sitting in a box in our lab as a teaching aid really. From: NANOG On Behalf Of Michel Blais Sent: Sunday, February 17, 2019 4:56 PM To: Samir Rana Cc: nanog at nanog.org Subject: Re: fs.com dwdm equipment I tryed SFP, MUX, DEMUX and OADM, all working as expected. Le dim. 17 févr. 2019 19 h 18, Samir Rana > a écrit : Hello All, Does anybody have experience with fs.com dwdm equipment in their production environment? Are you they working without any issue? How's their warranty support if the issue arises? Thanks in advance for all the answers and help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Mon Feb 18 06:55:21 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 18 Feb 2019 07:55:21 +0100 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <20190218065521.yp5335siacti5i6b@nic.fr> On Mon, Feb 18, 2019 at 07:33:32AM +0530, Viruthagiri Thirumavalavan wrote a message of 515 lines which said: > My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP > over TLS on Port 26 Besides all the excellent remarks that were made here (and I seriously urge you to read them; really), I want to add: > It's my 5 years of research. So it's worth more than 50 words. You have a very strange way of measuring the importance of something. A lot of people spent 30 years or more on useless and stupid things. The time past is *not* a good indicator of value. > My prototype codebase has around 200,000 lines of code. [To be exact: > 466,965 ++ 254,169 --] Same thing for source code. Boasting of the number of lines, as if it measured value of the program, won't make people interested. Really, this metric was abandoned or at east downplayed more than thirty years ago. > Sequoia Capital is one of the well known venture firm in the > world. They have invested in over 250 companies since 1972, > including Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, > Yahoo! and WhatsApp. Come on, most people on this list have a lot of experience with the wonderful world of Silicon Valley startups. We have seen a lot of dollars invested in really stupid projects. "One VC gave me money" proves nothing, except that some people have too much money and too little sense. From giri at dombox.org Mon Feb 18 06:58:21 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 18 Feb 2019 12:28:21 +0530 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: Just gone through all your replies. Literally everyone attacking me here. Could you tell me why? Because I have been rude to John Levine, right? So you all think you have the right to give me "mob justice". But as an innocent man I have to suffer all John Levine attacks because he is a most valued member of NANOG. Is that what you are all saying? There is only one regret I have in this situation. I shouldn't have been rude with Töma Gavrichenkov and Suresh Ramasubramanian. That's because they didn't know what happened between John and me 6 months back. Most probably they would never have behaved with me in the way John behaved. I wasn't paying attention to that part. When I noticed the word "50 words", I thought they are mocking me too. --------- @Töma Gavrichenkov and Suresh Ramasubramanian I don't think I can go back and correct my mistakes. But trust me. I do regret for my words. I'm really sorry for being rude with you two. Take this as my sincerest apology. You two deserve that. --------- @Everyone It sucks when you sit on the "humiliation" chair when the mistake is not yours. I'm a farmer's son from a third world country, yet trying to contribute to this world in the way I can. Asking for feedback is not a mistake. But I have been attacked in multiple lists for that. This is the only thread I was rude and cocky. What you all think I spend my time only in attacking others? Have you ever noticed my other threads ? I usually give respect to everyone. But I can't give respect to people who don't care about others feelings. What you all think, I'm a heartless man? One guy was attacking me for my poor english skills. Excuse me for not being poetic in my paper. I studied in my local language. English was an alien language to me. I started to learn "English" only in my early twenties. I just turned 30. This is what I picked in the past 10 years. Just because the ball is in your court doesn't mean, you all can throw at me in the way you can. I explained what happened between John Levine and me in my original post. That's because I don't want this man to go and create another thread to attack me or meddle in my efforts. I'm a guy who spend day and night in working on things I believe. I'm definitely not gonna turn into a Mark Zuckerberg. But I'm gonna make a difference to this world one way or another. None of never completed my paper. Most probably you have no idea what's in it. But you all think you have the right to attack me, because I was rude with John? This is an engineering community. Don't convert it into a "Prison Brotherhood" where the new guy always has to bend over. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Mon Feb 18 07:05:16 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 18 Feb 2019 02:05:16 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: You are so missing the point. This isn't about your interaction with John Levine. You came her asking for feedback (after an extensive and very unprofessional rant) and you got it. Just because you don't like the feedback doesn't mean people are "attacking" you. This is so irrelevant to NANOG. Please stop. On Mon, Feb 18, 2019, 2:00 AM Viruthagiri Thirumavalavan Just gone through all your replies. > > Literally everyone attacking me here. Could you tell me why? Because I > have been rude to John Levine, right? So you all think you have the right > to give me "mob justice". But as an innocent man I have to suffer all John > Levine attacks because he is a most valued member of NANOG. Is that what > you are all saying? > > There is only one regret I have in this situation. I shouldn't have been > rude with Töma Gavrichenkov and Suresh Ramasubramanian. That's because they > didn't know what happened between John and me 6 months back. Most probably > they would never have behaved with me in the way John behaved. I wasn't > paying attention to that part. When I noticed the word "50 words", I > thought they are mocking me too. > > --------- > @Töma Gavrichenkov and Suresh Ramasubramanian > > I don't think I can go back and correct my mistakes. But trust me. I do > regret for my words. I'm really sorry for being rude with you two. Take > this as my sincerest apology. You two deserve that. > --------- > > @Everyone > > It sucks when you sit on the "humiliation" chair when the mistake is not > yours. I'm a farmer's son from a third world country, yet trying to > contribute to this world in the way I can. > > Asking for feedback is not a mistake. But I have been attacked in multiple > lists for that. This is the only thread I was rude and cocky. > > What you all think I spend my time only in attacking others? Have you ever > noticed my other threads ? I > usually give respect to everyone. But I can't give respect to people who > don't care about others feelings. What you all think, I'm a heartless man? > > One guy was attacking me for my poor english skills. Excuse me for not > being poetic in my paper. I studied in my local language. English was an > alien language to me. I started to learn "English" only in my early > twenties. I just turned 30. This is what I picked in the past 10 years. > > Just because the ball is in your court doesn't mean, you all can throw at > me in the way you can. I explained what happened between John Levine and me > in my original post. That's because I don't want this man to go and create > another thread to attack me or meddle in my efforts. > > I'm a guy who spend day and night in working on things I believe. I'm > definitely not gonna turn into a Mark Zuckerberg. But I'm gonna make a > difference to this world one way or another. > > None of never completed my paper. Most probably you have no idea what's in > it. But you all think you have the right to attack me, because I was rude > with John? This is an engineering community. Don't convert it into a > "Prison Brotherhood" where the new guy always has to bend over. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Feb 18 07:14:31 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 18 Feb 2019 09:14:31 +0200 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: <48853542-881a-d576-dd26-458bd4bc1685@seacom.mu> On 18/Feb/19 08:58, Viruthagiri Thirumavalavan wrote: > > It sucks when you sit on the "humiliation" chair when the mistake is > not yours. I'm a farmer's son from a third world country, yet trying > to contribute to this world in the way I can.  > > Asking for feedback is not a mistake. But I have been attacked in > multiple lists for that. This is the only thread I was rude and cocky.  > My simple advice, take 2 weeks and think about how this thread has gone, cool down, and then decide how you want to proceed next. While nobody can take your work away from you, it does not mean that they have to accept it either. Your circumstances are your circumstances, as are everybody else's. Most people can smell a guilt trip, and often times, they don't like it. As I used to tell my friends who had trouble dating girls, "You don't get what you deserve, you get what you negotiate". Part of the gig is endearing yourself to people so that they can consider what you have to say. I do not know of any law that obliges anyone to give you attention. There is no shortage of brilliant minds that have never had their ideas realized - or even heard - simply because they could not deal with the social side of the gig. Please don't fall into that trap. Everybody wakes up everyday with their own set of problems. They have no obligation to be a part of yours, so make it easier for folk to listen to you. Whether you are right or wrong, bickering about the past deafens your core message, and simply turns people away so they don't have to add your problems on to theirs. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Mon Feb 18 07:33:39 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 18 Feb 2019 08:33:39 +0100 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: <20190218073339.2glupjv7lrwxhc7y@nic.fr> On Mon, Feb 18, 2019 at 12:28:21PM +0530, Viruthagiri Thirumavalavan wrote a message of 111 lines which said: > Just gone through all your replies. And apparently you did not read them and did not take any lesson in it. > Literally everyone attacking me here. In the current thread, NOT ONE reply was an attack. All the replies were kind and considerate (franly, much more than what you deserved) and explained why you are wrong. Read them again. Really. It would help you. This is probably your last chance before everyone definitely classify you as "useless crank". > One guy was attacking me for my poor english skills. Excuse me for > not being poetic in my paper. I studied in my local > language. English was an alien language to me. English is not my mother tongue either and I make many mistakes. But I try to fix them, and do not complain when people who speak better english correct me. Frankly, as someone who has trouble understanding people speaking at the IETF meetings, I do not think that english is your main problem. > None of never completed my paper. Nobody is forced to. There are more interesting papers to read that anyone have time to do so. We have to decide what to read and what to ignore. Why should we drop promising papers and read yours, when the external appearance is that of a guy who does not listen, does not know what he is talking about, and just complains endlessly how the world is unfair? From ximaera at gmail.com Mon Feb 18 07:51:17 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 18 Feb 2019 10:51:17 +0300 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: On Mon, Feb 18, 2019, 5:05 AM Viruthagiri Thirumavalavan wrote: > @Töma Gavrichenkov > > In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. > > > How can you be so sure that you didn't fuck up none of the lives of these > "few cases"? Or in more technical terms, How can you be absolutely sure > that there is no "False Positives"? > Easily. I shouldn't have been rude with Töma Gavrichenkov > Oh, feel free to, I don't really care. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Mon Feb 18 08:51:35 2019 From: jwbensley at gmail.com (James Bensley) Date: Mon, 18 Feb 2019 08:51:35 +0000 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: <38517E5A-CEEB-4BB4-80CE-AF0664B84F5E@gmail.com> On 18 February 2019 06:58:21 GMT, Viruthagiri Thirumavalavan wrote: >Just gone through all your replies. > >Literally everyone attacking me here. Could you tell me why? Because I >have >been rude to John Levine, right? So you all think you have the right to >give me "mob justice". But as an innocent man I have to suffer all John >Levine attacks because he is a most valued member of NANOG. Is that >what >you are all saying? > >There is only one regret I have in this situation. I shouldn't have >been >rude with Töma Gavrichenkov and Suresh Ramasubramanian. That's because >they >didn't know what happened between John and me 6 months back. Most >probably >they would never have behaved with me in the way John behaved. I wasn't >paying attention to that part. When I noticed the word "50 words", I >thought they are mocking me too. > >--------- >@Töma Gavrichenkov and Suresh Ramasubramanian > >I don't think I can go back and correct my mistakes. But trust me. I do >regret for my words. I'm really sorry for being rude with you two. Take >this as my sincerest apology. You two deserve that. >--------- > >@Everyone > >It sucks when you sit on the "humiliation" chair when the mistake is >not >yours. I'm a farmer's son from a third world country, yet trying to >contribute to this world in the way I can. > >Asking for feedback is not a mistake. But I have been attacked in >multiple >lists for that. This is the only thread I was rude and cocky. > >What you all think I spend my time only in attacking others? Have you >ever >noticed my other threads ? I >usually give respect to everyone. But I can't give respect to people >who >don't care about others feelings. What you all think, I'm a heartless >man? > >One guy was attacking me for my poor english skills. Excuse me for not >being poetic in my paper. I studied in my local language. English was >an >alien language to me. I started to learn "English" only in my early >twenties. I just turned 30. This is what I picked in the past 10 years. > >Just because the ball is in your court doesn't mean, you all can throw >at >me in the way you can. I explained what happened between John Levine >and me >in my original post. That's because I don't want this man to go and >create >another thread to attack me or meddle in my efforts. > >I'm a guy who spend day and night in working on things I believe. I'm >definitely not gonna turn into a Mark Zuckerberg. But I'm gonna make a >difference to this world one way or another. > >None of never completed my paper. Most probably you have no idea what's >in >it. But you all think you have the right to attack me, because I was >rude >with John? This is an engineering community. Don't convert it into a >"Prison Brotherhood" where the new guy always has to bend over. I have no idea who you are, or who John is, or what sort if disagreement you guys had. I also don't care. I'm a user of this list, I read the threads that look interesting when I can (when I have time) and sometimes post responses. You haven't offended me and I don't owe you anything, so here is my impartial response; Your white paper is 300 pages long. That is literally 10x the length of what a white paper should be. White papers are not instruction manuals on exactly how something works and how to set it up, they're short succinct documents that give the highlights of the product, who can benefit from it, how, why etc. Who is your target audience for your writing? I read somewhere up to about half of your medium blog post. You start by explaining what different kinds of email are (spam vs phishing, transactional vs promotional) etc. This is an introduction for what email is. That's too basic for sending to a technical audience. Skip right to the main course, people have short attention spans, I hate having to skim through pages of stuff I know to find what I'm looking for. I didn't finish the blog post. I read that I'd have to create a mailbox (Dombox) for each domain I want to receive mail form and I switched off. I read further to see the examples but this killed my interest. Its too much effort for the average person. I'm emailing you now from throw-away Gmail account, which is free with world class spam filtering, I get like 1 spam email in my inbox per month. 1! And the reason I have this Gmail account is so that I can be reckless with handing out this this email address and it has no negative consequences for me. It's signed up to about 50 mailing lists right now, I get hundreds of emails. If I had to create an entry for each domain I wanted to received mail from I'd pull my eyes out with frustration. Also, this already exists. I could just run my own mail server and deny a mail except from domains or addresses which I have explicitly white listed in my server config, so how is your solution bettering that? I can even use a two step system: free email with Gmail to use their excellent spam filtering which my server then pulls via IMAP and drops anything not in my whitelist. Sorry, I just don't see the benefit (or at least, I couldn't see it in the few 2 thousand words of your blog, if its not clear by this point, why would I read on, I'm too busy to have to read more than a couple of thousands words and still not get to a clear description of the benefits you're offering). Cheers, James. From ximaera at gmail.com Mon Feb 18 08:52:52 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 18 Feb 2019 11:52:52 +0300 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <20190218065521.yp5335siacti5i6b@nic.fr> References: <20190218065521.yp5335siacti5i6b@nic.fr> Message-ID: On Mon, Feb 18, 2019, 9:56 AM Stephane Bortzmeyer > Sequoia Capital is one of the well known venture firm in the > > world. They have invested in over 250 companies since 1972, > > including Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, > > Yahoo! and WhatsApp. > > Come on, most people on this list have a lot of experience with the > wonderful world of Silicon Valley startups. We have seen a lot of > dollars invested in really stupid projects. "One VC gave me money" > proves nothing, except that some people have too much money and too > little sense. > Well, if I read it correctly, that VC hasn't in fact ever given the OP a cent. *Sometimes*, VCs might make obvious mistakes, that's right, but their balance sheets prove it doesn't happen quite often. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Mon Feb 18 11:11:14 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 18 Feb 2019 16:41:14 +0530 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <38517E5A-CEEB-4BB4-80CE-AF0664B84F5E@gmail.com> References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> <38517E5A-CEEB-4BB4-80CE-AF0664B84F5E@gmail.com> Message-ID: Thanks James for the feedback. I created that medium post for non-technical audience. But yes your feedback is quite valid. I just removed plenty of content from the blog post. You don't need a throw-away email account in my system. If I had to create an entry for each domain I wanted to received mail from > I'd pull my eyes out with frustration. You would do this only for the unique domains just like you do in "Password Manager". For example, you would create a box for nanog. We deal with "spammers" only in the "injection" phase. If you have not read until the part where it says "Hot Gates Strategy", then it's really hard to connect the dots. Thanks On Mon, Feb 18, 2019 at 2:21 PM James Bensley wrote: > > > On 18 February 2019 06:58:21 GMT, Viruthagiri Thirumavalavan < > giri at dombox.org> wrote: > >Just gone through all your replies. > > > >Literally everyone attacking me here. Could you tell me why? Because I > >have > >been rude to John Levine, right? So you all think you have the right to > >give me "mob justice". But as an innocent man I have to suffer all John > >Levine attacks because he is a most valued member of NANOG. Is that > >what > >you are all saying? > > > >There is only one regret I have in this situation. I shouldn't have > >been > >rude with Töma Gavrichenkov and Suresh Ramasubramanian. That's because > >they > >didn't know what happened between John and me 6 months back. Most > >probably > >they would never have behaved with me in the way John behaved. I wasn't > >paying attention to that part. When I noticed the word "50 words", I > >thought they are mocking me too. > > > >--------- > >@Töma Gavrichenkov and Suresh Ramasubramanian > > > >I don't think I can go back and correct my mistakes. But trust me. I do > >regret for my words. I'm really sorry for being rude with you two. Take > >this as my sincerest apology. You two deserve that. > >--------- > > > >@Everyone > > > >It sucks when you sit on the "humiliation" chair when the mistake is > >not > >yours. I'm a farmer's son from a third world country, yet trying to > >contribute to this world in the way I can. > > > >Asking for feedback is not a mistake. But I have been attacked in > >multiple > >lists for that. This is the only thread I was rude and cocky. > > > >What you all think I spend my time only in attacking others? Have you > >ever > >noticed my other threads ? I > >usually give respect to everyone. But I can't give respect to people > >who > >don't care about others feelings. What you all think, I'm a heartless > >man? > > > >One guy was attacking me for my poor english skills. Excuse me for not > >being poetic in my paper. I studied in my local language. English was > >an > >alien language to me. I started to learn "English" only in my early > >twenties. I just turned 30. This is what I picked in the past 10 years. > > > >Just because the ball is in your court doesn't mean, you all can throw > >at > >me in the way you can. I explained what happened between John Levine > >and me > >in my original post. That's because I don't want this man to go and > >create > >another thread to attack me or meddle in my efforts. > > > >I'm a guy who spend day and night in working on things I believe. I'm > >definitely not gonna turn into a Mark Zuckerberg. But I'm gonna make a > >difference to this world one way or another. > > > >None of never completed my paper. Most probably you have no idea what's > >in > >it. But you all think you have the right to attack me, because I was > >rude > >with John? This is an engineering community. Don't convert it into a > >"Prison Brotherhood" where the new guy always has to bend over. > > > I have no idea who you are, or who John is, or what sort if disagreement > you guys had. I also don't care. I'm a user of this list, I read the > threads that look interesting when I can (when I have time) and sometimes > post responses. You haven't offended me and I don't owe you anything, so > here is my impartial response; > > Your white paper is 300 pages long. That is literally 10x the length of > what a white paper should be. White papers are not instruction manuals on > exactly how something works and how to set it up, they're short succinct > documents that give the highlights of the product, who can benefit from it, > how, why etc. > > Who is your target audience for your writing? I read somewhere up to about > half of your medium blog post. You start by explaining what different kinds > of email are (spam vs phishing, transactional vs promotional) etc. This is > an introduction for what email is. That's too basic for sending to a > technical audience. Skip right to the main course, people have short > attention spans, I hate having to skim through pages of stuff I know to > find what I'm looking for. > > I didn't finish the blog post. I read that I'd have to create a mailbox > (Dombox) for each domain I want to receive mail form and I switched off. I > read further to see the examples but this killed my interest. Its too much > effort for the average person. I'm emailing you now from throw-away Gmail > account, which is free with world class spam filtering, I get like 1 spam > email in my inbox per month. 1! And the reason I have this Gmail account is > so that I can be reckless with handing out this this email address and it > has no negative consequences for me. It's signed up to about 50 mailing > lists right now, I get hundreds of emails. If I had to create an entry for > each domain I wanted to received mail from I'd pull my eyes out with > frustration. > > Also, this already exists. I could just run my own mail server and deny a > mail except from domains or addresses which I have explicitly white listed > in my server config, so how is your solution bettering that? I can even use > a two step system: free email with Gmail to use their excellent spam > filtering which my server then pulls via IMAP and drops anything not in my > whitelist. > > Sorry, I just don't see the benefit (or at least, I couldn't see it in the > few 2 thousand words of your blog, if its not clear by this point, why > would I read on, I'm too busy to have to read more than a couple of > thousands words and still not get to a clear description of the benefits > you're offering). > > Cheers, > James. > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Feb 18 13:24:53 2019 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 18 Feb 2019 07:24:53 -0600 (CST) Subject: fs.com dwdm equipment In-Reply-To: References: Message-ID: <182901066.1003.1550496288745.JavaMail.mhammett@ThunderFuck> None of our stuff has management, all passive. Once you get into the amps and whatnot, those have management. We'll likely be getting some shortly as we're rebuilding our infrastructure and adding some things. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Chris Gross" To: "Michel Blais" , "Samir Rana" Cc: nanog at nanog.org Sent: Monday, February 18, 2019 12:39:57 AM Subject: RE: fs.com dwdm equipment For managing them, do you use the actual software they ship with it? When I last checked, it requires a MSSQL instance with hard coded “sa” user access which was an immediate no go for me. I still have them sitting in a box in our lab as a teaching aid really. From: NANOG On Behalf Of Michel Blais Sent: Sunday, February 17, 2019 4:56 PM To: Samir Rana Cc: nanog at nanog.org Subject: Re: fs.com dwdm equipment I tryed SFP, MUX, DEMUX and OADM, all working as expected. Le dim. 17 févr. 2019 19 h 18, Samir Rana < samir.rana at cybera.ca > a écrit : Hello All, Does anybody have experience with fs.com dwdm equipment in their production environment? Are you they working without any issue? How's their warranty support if the issue arises? Thanks in advance for all the answers and help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.zhu at uniserveteam.com Mon Feb 18 06:01:13 2019 From: erik.zhu at uniserveteam.com (Erik Zhu) Date: Mon, 18 Feb 2019 06:01:13 +0000 Subject: Craigslist technical contact - IP Ranges blocked Message-ID: Hello All, Does anyone know the best way to get connect to Craiglist technical support regarding the blocked IP ranges. We are an ISP in Canada, and since early this year we noticed that most of our IP blocks are blocked on some of the Craigslist's servers. One easy example is finding any items on Craigslist, hit reply, and gives an error "Sorry, something went wrong", the web analyzer indicates status code 403 forbidden. I understand that if individual subscriber IP could be automatically blocked due to certain reasons by Craigslist, but I don't know why our entire IP blocks could be blocked, even some IP ranges are never assigned to any active services. Did anyone have the encountered the same issue before, how can we get it resolved? Thanks, Erik From mysidia at gmail.com Mon Feb 18 16:18:32 2019 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 18 Feb 2019 10:18:32 -0600 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: On Sun, Feb 17, 2019 at 8:05 PM Viruthagiri Thirumavalavan wrote: > These guys always are the know-it-all assholes. They don't listen. They don't want to listen. I would simply like to remind everyone that NANOG is a Mailing list that has some rules. They could be found here: https://www.nanog.org/list I would like to request for the Communications Committee to look at this thread, except the list of NANOG Committee members seems to be secret - https://nanog.org/governance/cc The message I reply to seems to be a long string of major deviations from AUP, specifically: : 4. Postings that are defamatory, abusive, profane, threatening, or include foul language, : character assassination, and lack of respect for other participants are prohibited. We get really tired about people bringing up disputes and personal issues -- this is not the right place. > Long story short.... I solved the email spam problem. Well... Actually I solved it long time back. I'm just ready to disclose it today. Again... While you have some technical solution and some ideas that appear to have merit such as "Isolated mailboxes" (Isolated Mailboxes are not really a new idea -- but there is currently no agreed protocol/standard to make such function convenient enough for people to use); Prompting e-mail senders to answer "CAPTCHA" sounds too burdensome to use; This is also not Spam-Free, as spammers will find ways to answer CAPTCHAs. The overall claims to have "zero" spam or completely "solved" the spam problem technically are way too bold and are close to "Product Marketing" in my view, since some Dombox dot com service is being advertised. Most Network Operators like those that subscribe to NANOG usually have little to say about technical details involved in developing standards regarding e-mail protocols; please see IETF for on-topic discussion groups. -- -JH From valdis.kletnieks at vt.edu Mon Feb 18 16:27:56 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 18 Feb 2019 11:27:56 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: <22631.1550507276@turing-police.cc.vt.edu> On Mon, 18 Feb 2019 12:28:21 +0530, Viruthagiri Thirumavalavan said: > Literally everyone attacking me here. Could you tell me why? Because I have > been rude to John Levine, right? No, it's because (a) every aspect we could understand from your writing has already been tried and failed, and (b) you've repeatedly proven that you're totally unaware of the state of the art on both the spammer side and the anti-spammer side. Oh, and (c) you appear to be totally unaware of just how little you know. From bruns at 2mbit.com Mon Feb 18 17:00:29 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 18 Feb 2019 10:00:29 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: <7b322f20-37c8-f170-89a2-30598db84504@2mbit.com> On 2/17/2019 11:58 PM, Viruthagiri Thirumavalavan wrote: > Just gone through all your replies. > > Literally everyone attacking me here. Could you tell me why? Technical people like what you'd find on this list tend to want to get right to the point on things. If you want them to hear you out, you can't hand them a 300 page 'white paper' and demand that they read it. When presenting to technical, esp sysadmin and networking types, use the RFCs as a template for how you should be presenting your idea to them. It also helps to target your audience well - while most people here do consider spam a serious problem, many of them are not in a position to professionally do anything about it, or have the time to do anything about it. Your proper audience is Mailops and people like me (ie: former DNSbl maintainers, postmasters, abuse desks). Just going to come right out and say this too - your 'solution', no matter how good you may think it is, depends on people paying you as a service. That means I have zero interest in it. I have enough subscriptions and payments I have to make for things which are much more important as it is. Dare I bring up Spamhaus's .mail proposal and the shitshow that was? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bill at herrin.us Mon Feb 18 17:00:08 2019 From: bill at herrin.us (William Herrin) Date: Mon, 18 Feb 2019 09:00:08 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: On Sun, Feb 17, 2019 at 10:58 PM Viruthagiri Thirumavalavan wrote: > Literally everyone attacking me here. Could you tell me why? Because we disapprove of argumentum ad hominem and assume that if your reasoning leads with that fallacy right out of the gate it will contain the other errors as well. https://thebestschools.org/magazine/15-logical-fallacies-know/ Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From giri at dombox.org Mon Feb 18 17:02:53 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 18 Feb 2019 22:32:53 +0530 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: @Everyone I'm not gonna justify my behaviour. Yes my post was rude. I made a mistake. I was way over in my head. When I typed the original message I was obsessed with the man John Levine. He was responsible for the attacks on me in 4 mailing lists. DMARC, DKIM, IETF and this one (the old thread). I didn't want to face the same thing again. So I was rude. I'm not gonna make him responsible for this thread. This one is my mistake. I could have been more professional in my original post. But I screwed up. My apologies to everyone here for making you witness my rant. I'm leaving this mailing list too. But if anyone complete my white paper in the future, I would love to hear your feedback. I won't be receiving any mails from nanog. So contact me off-list in that case. Thanks for the guys who helped in my other threads. Good luck to you all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Mon Feb 18 17:34:12 2019 From: john at essenz.com (John Von Essen) Date: Mon, 18 Feb 2019 12:34:12 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: <2D72B7FB-DA43-4171-867D-8F862068F067@essenz.com> This is great news... > On Feb 18, 2019, at 12:02 PM, Viruthagiri Thirumavalavan wrote: > > I'm leaving this mailing list too. Can a Nanog Op please ban this guy from joining again? From michel.py at tsisemi.com Mon Feb 18 18:38:16 2019 From: michel.py at tsisemi.com (Michel Py) Date: Mon, 18 Feb 2019 18:38:16 +0000 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <711a2d33dcc64052804e7af537afae13@CRA114.am.necel.com> <4F179CD7-DC4A-449E-B101-63682CF18102@gmail.com> Message-ID: > Ross Tajvar wrote : > Not to derail this highly relevant thread, and forgive my ignorance, but what's the issue with IPv6 multihoming? In the original spec of IPv6, there were no PI addresses, only PA; one of the unfulfilled promises of IPv6 was that the IPv6 DFZ would remain very small. This made IPv6 multihoming very difficult, and lots of people wasted a lot of time trying to accommodate the "no PI" thing. What happenned is that the RIRs, against the IETF, started to issue IPv6 PI addresses, which solved the multihoming problem by doing it the IPv4 way : a prefix in the DFZ. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From aaron at wholesaleinternet.net Mon Feb 18 19:06:19 2019 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Mon, 18 Feb 2019 11:06:19 -0800 Subject: fs.com dwdm equipment In-Reply-To: References: Message-ID: <7227B1E2-5BE2-4DD1-8E3A-721A106812B2@wholesaleinternet.net> We use it. A lot of it. No problems. Never a need for warranty support. Aaron Sent from my iPad > On Feb 17, 2019, at 12:42 PM, Samir Rana wrote: > > Hello All, > > Does anybody have experience with fs.com dwdm equipment in their production environment? Are you they working without any issue? How's their warranty support if the issue arises? > > Thanks in advance for all the answers and help. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Mon Feb 18 19:28:14 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 18 Feb 2019 12:28:14 -0700 Subject: Craigslist technical contact - IP Ranges blocked In-Reply-To: References: Message-ID: Erik, please contact me offlist with details (IP block, etc.). We'll shake the tree for you. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance GDPR, CCPA (CA) & CCDPA (CO) Compliance Consulting http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Board Member, Board of Directors, Denver Internet Exchange Board Member, Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Ret. Professor of Law, Lincoln Law School of San Jose > On Feb 17, 2019, at 11:01 PM, Erik Zhu wrote: > > Hello All, > > Does anyone know the best way to get connect to Craiglist technical > support regarding the blocked IP ranges. We are an ISP in Canada, and > since early this year we noticed that most of our IP blocks are blocked > on some of the Craigslist's servers. One easy example is finding any > items on Craigslist, hit reply, and gives an error "Sorry, something > went wrong", the web analyzer indicates status code 403 forbidden. > > I understand that if individual subscriber IP could be automatically > blocked due to certain reasons by Craigslist, but I don't know why our > entire IP blocks could be blocked, even some IP ranges are never > assigned to any active services. > > Did anyone have the encountered the same issue before, how can we get it > resolved? > > > Thanks, > > Erik > From amitchell at isipp.com Mon Feb 18 19:29:54 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 18 Feb 2019 12:29:54 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: > On Feb 17, 2019, at 7:14 PM, Ross Tajvar wrote: > > I'd be a lot more inclined to read your paper if you weren't so self-righteous about it. Rehashing all the times people disagreed with ("attacked") you is a poor way to encourage others to earnestly engage with your ideas. Especially when they are well-respected members of both NANOG and the greater email community. Seriously?? Attacking John and Suresh?? Anne *Typed with 1.5 eyes as I'm recuperating from a torn retina, so apologies for any typos. Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From briansupport at hotmail.com Mon Feb 18 19:47:10 2019 From: briansupport at hotmail.com (Brian R) Date: Mon, 18 Feb 2019 19:47:10 +0000 Subject: fs.com dwdm equipment In-Reply-To: References: Message-ID: Samir, I have purchased over a thousand SFPs from Fiber Store. I can recall less than 5 having problems when we received them (not all even DOA) and I know less than 10 dead even after deployment. Some we have ad running for 4+ years. We have done very little with their SFP+ equipment, really only testing and a few lower priority links. The only downside to the SFPs that we found was the variance of power. Say an Adtran, Cisco, Juniper, HP SFP is rated from -3dB to -8 db (all units I have used them with), the equivalent FS direct SFP we have seen as hot as 3dB and as weak as -15dB. These extremes are fairly rare but we have still seen them. Distribution (approximate): 80% SM single fiber SFPs (mostly 10km - 40km, some 60km & 80km) 7% 1Gb Copper 5% MM SFPs 5% SM dual fiber SFPs 3% others (SFP+, GPON, testing, etc) I have not used them for any DWDM applications and only used them a few times on an older CWDM link that used standard SFPs into a MUX. This was not over great distances (less than 40 miles). With WDM SFP power consistency was important so we did not play much with it, granted most of the SFPs I am purchasing are in the $10-$25 range so take the extremes with a grain of salt. Their sales has always been very responsive and helpful. The support/engineering, the few times I worked with them, were helpful but the language barrier was harder here. Brian ________________________________ From: NANOG on behalf of Samir Rana Sent: Sunday, February 17, 2019 12:42 PM To: nanog at nanog.org Subject: fs.com dwdm equipment Hello All, Does anybody have experience with fs.com dwdm equipment in their production environment? Are you they working without any issue? How's their warranty support if the issue arises? Thanks in advance for all the answers and help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at wpi.edu Mon Feb 18 19:54:23 2019 From: cra at wpi.edu (Anderson, Charles R) Date: Mon, 18 Feb 2019 19:54:23 +0000 Subject: fs.com dwdm equipment In-Reply-To: References: Message-ID: <20190218195420.ykvkul4lvyius4to@angus.ind.wpi.edu> I concur. I have also used CWDM and DWDM optics and they are fine. I have had one QSFP+ optic go bad. On Mon, Feb 18, 2019 at 07:47:10PM +0000, Brian R wrote: > Samir, > > I have purchased over a thousand SFPs from Fiber Store. I can recall less than 5 having problems when we received them (not all even DOA) and I know less than 10 dead even after deployment. Some we have ad running for 4+ years. We have done very little with their SFP+ equipment, really only testing and a few lower priority links. > The only downside to the SFPs that we found was the variance of power. Say an Adtran, Cisco, Juniper, HP SFP is rated from -3dB to -8 db (all units I have used them with), the equivalent FS direct SFP we have seen as hot as 3dB and as weak as -15dB. These extremes are fairly rare but we have still seen them. > Distribution (approximate): > 80% SM single fiber SFPs (mostly 10km - 40km, some 60km & 80km) > 7% 1Gb Copper > 5% MM SFPs > 5% SM dual fiber SFPs > 3% others (SFP+, GPON, testing, etc) > > I have not used them for any DWDM applications and only used them a few times on an older CWDM link that used standard SFPs into a MUX. This was not over great distances (less than 40 miles). With WDM SFP power consistency was important so we did not play much with it, granted most of the SFPs I am purchasing are in the $10-$25 range so take the extremes with a grain of salt. > > Their sales has always been very responsive and helpful. The support/engineering, the few times I worked with them, were helpful but the language barrier was harder here. > > Brian > > ________________________________ > From: NANOG on behalf of Samir Rana > Sent: Sunday, February 17, 2019 12:42 PM > To: nanog at nanog.org > Subject: fs.com dwdm equipment > > Hello All, > > Does anybody have experience with fs.com > Thanks in advance for all the answers and help. From martin at airwire.ie Mon Feb 18 21:17:18 2019 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 18 Feb 2019 21:17:18 +0000 Subject: fs.com dwdm equipment In-Reply-To: <20190218195420.ykvkul4lvyius4to@angus.ind.wpi.edu> References: <20190218195420.ykvkul4lvyius4to@angus.ind.wpi.edu> Message-ID: Hi, I have both 1Gig and 10Gig DWDM optics from SF.com being using in Cisco and Mikrotik switches. Never had an issue with them. Work flawless .. for years. Kind regards, Martin List-Petersen Airwire Ltd. On 18/02/2019 19:54, Anderson, Charles R wrote: > I concur. I have also used CWDM and DWDM optics and they are fine. I have had one QSFP+ optic go bad. > > On Mon, Feb 18, 2019 at 07:47:10PM +0000, Brian R wrote: >> Samir, >> >> I have purchased over a thousand SFPs from Fiber Store. I can recall less than 5 having problems when we received them (not all even DOA) and I know less than 10 dead even after deployment. Some we have ad running for 4+ years. We have done very little with their SFP+ equipment, really only testing and a few lower priority links. >> The only downside to the SFPs that we found was the variance of power. Say an Adtran, Cisco, Juniper, HP SFP is rated from -3dB to -8 db (all units I have used them with), the equivalent FS direct SFP we have seen as hot as 3dB and as weak as -15dB. These extremes are fairly rare but we have still seen them. >> Distribution (approximate): >> 80% SM single fiber SFPs (mostly 10km - 40km, some 60km & 80km) >> 7% 1Gb Copper >> 5% MM SFPs >> 5% SM dual fiber SFPs >> 3% others (SFP+, GPON, testing, etc) >> >> I have not used them for any DWDM applications and only used them a few times on an older CWDM link that used standard SFPs into a MUX. This was not over great distances (less than 40 miles). With WDM SFP power consistency was important so we did not play much with it, granted most of the SFPs I am purchasing are in the $10-$25 range so take the extremes with a grain of salt. >> >> Their sales has always been very responsive and helpful. The support/engineering, the few times I worked with them, were helpful but the language barrier was harder here. >> >> Brian >> >> ________________________________ >> From: NANOG on behalf of Samir Rana >> Sent: Sunday, February 17, 2019 12:42 PM >> To: nanog at nanog.org >> Subject: fs.com dwdm equipment >> >> Hello All, >> >> Does anybody have experience with fs.com> >> Thanks in advance for all the answers and help. -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961 From bzs at theworld.com Mon Feb 18 21:24:27 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 18 Feb 2019 16:24:27 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <23659.8843.302818.664055@gargle.gargle.HOWL> On February 18, 2019 at 12:29 amitchell at isipp.com (Anne P. Mitchell, Esq.) wrote: > > > > On Feb 17, 2019, at 7:14 PM, Ross Tajvar wrote: > > > > I'd be a lot more inclined to read your paper if you weren't so self-righteous about it. Rehashing all the times people disagreed with ("attacked") you is a poor way to encourage others to earnestly engage with your ideas. > > Especially when they are well-respected members of both NANOG and the greater email community. Seriously?? Attacking John and Suresh?? Uh-oh, this leads to "Why didn't he attack me? Don't I rate as well-respected?" I suppose in the proximal case because I didn't attack him :-) -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From john at essenz.com Mon Feb 18 21:50:45 2019 From: john at essenz.com (John Von Essen) Date: Mon, 18 Feb 2019 16:50:45 -0500 Subject: Cisco ASR's with RSP440 engines... Message-ID: <8d9a26b2-9d6d-2f64-000f-aad5619b6179@essenz.com> If anyone on here has experience with the ASR series running the RSP440-SE or -TR, please contact me off-list. I'm trying to better understand real world performance when it comes to handling a few full BGP tables on these, it would be running as very basic edge router primarily just doing BGP. I know the RSP440 is EOL, but the plan would be to upgrade to RSP880 within a year. Thanks John From valdis.kletnieks at vt.edu Mon Feb 18 21:57:18 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 18 Feb 2019 16:57:18 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <10173.1550527038@turing-police.cc.vt.edu> On Mon, 18 Feb 2019 12:29:54 -0700, "Anne P. Mitchell, Esq." said: > Especially when they are well-respected members of both NANOG and the greater > email community. Seriously?? Attacking John and Suresh?? It's been a while since the time somebody was dorksplaining RIP to Tony Li. :) From beecher at beecher.cc Mon Feb 18 22:57:04 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 18 Feb 2019 14:57:04 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: Every single person on this list has either sent an email they later regret , or will do so eventually. Full credit to you for acknowledging and owning this. Best of luck to you. On Mon, Feb 18, 2019 at 09:08 Viruthagiri Thirumavalavan wrote: > @Everyone > > I'm not gonna justify my behaviour. Yes my post was rude. I made a > mistake. I was way over in my head. When I typed the original message I was > obsessed with the man John Levine. He was responsible for the attacks on me > in 4 mailing lists. DMARC, DKIM, IETF and this one (the old thread). > > I didn't want to face the same thing again. So I was rude. I'm not gonna > make him responsible for this thread. This one is my mistake. I could have > been more professional in my original post. But I screwed up. > > My apologies to everyone here for making you witness my rant. I'm leaving > this mailing list too. But if anyone complete my white paper in the future, > I would love to hear your feedback. I won't be receiving any mails from > nanog. So contact me off-list in that case. > > Thanks for the guys who helped in my other threads. > > Good luck to you all. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Tue Feb 19 01:36:05 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 18 Feb 2019 19:36:05 -0600 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: <2163.1550460090@turing-police.cc.vt.edu> <1423F10C-49FA-4DD2-99D3-FE3CF61D4DA1@retina.net> Message-ID: <666F7652-8852-4C86-A6BE-21ED26D23B08@dataix.net> http://4.bp.blogspot.com/-nRlbTO3RH1s/Uo-X_PX6WBI/AAAAAAAAJLU/mirPbTYFa6U/s1600/unnamed.jpg -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Feb 18, 2019, at 16:57, Tom Beecher wrote: > > Every single person on this list has either sent an email they later regret , or will do so eventually. > > Full credit to you for acknowledging and owning this. > > Best of luck to you. > >> On Mon, Feb 18, 2019 at 09:08 Viruthagiri Thirumavalavan wrote: >> @Everyone >> >> I'm not gonna justify my behaviour. Yes my post was rude. I made a mistake. I was way over in my head. When I typed the original message I was obsessed with the man John Levine. He was responsible for the attacks on me in 4 mailing lists. DMARC, DKIM, IETF and this one (the old thread). >> >> I didn't want to face the same thing again. So I was rude. I'm not gonna make him responsible for this thread. This one is my mistake. I could have been more professional in my original post. But I screwed up. >> >> My apologies to everyone here for making you witness my rant. I'm leaving this mailing list too. But if anyone complete my white paper in the future, I would love to hear your feedback. I won't be receiving any mails from nanog. So contact me off-list in that case. >> >> Thanks for the guys who helped in my other threads. >> >> Good luck to you all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Tue Feb 19 02:56:03 2019 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 18 Feb 2019 20:56:03 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <5f85c788-2f43-ba05-e1fd-986a6bc364d2@seacom.mu> References: <5f85c788-2f43-ba05-e1fd-986a6bc364d2@seacom.mu> Message-ID: Mark, What does this Viavi's QT-600 platform cost? Does it test 10G or only 1G? On Tue, Jan 22, 2019 at 3:26 AM Mark Tinka wrote: > After faffing about for quite some time with Ookla and iPerf, we have now > settled on Viavi's QT-600 platform: > > > https://www.viavisolutions.com/en-us/products/qt-600-ethernet-probe-portfolio > > We shall use it as a private system, primarily to activate and handover > customer services, and on rare occasions, perform post-delivery testing. > > We are no longer interested in indulging endless speed tests that are > practically meaningless and leave ISP's with the burden of explaining > things they can't control. > > Mark. > > On 16/Jan/19 18:52, Colton Conor wrote: > > As an internet service provider with many small business and residential > customers, our most common tech support calls are speed related. Customers > complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells > us up-time and if data is flowing across the interface. We can of course > see the link speed, but customer call in saying the are not getting that > speed. > > We are looking for a way to remotely test customers internet connections > besides telling the customer to go to speedtest.net, or worse sending a > tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Feb 19 04:19:11 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 19 Feb 2019 06:19:11 +0200 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: <5f85c788-2f43-ba05-e1fd-986a6bc364d2@seacom.mu> Message-ID: On 19/Feb/19 04:56, Colton Conor wrote: > Mark, > > What does this Viavi's QT-600 platform cost? Does it test 10G or only 1G? They have units that will test up to 1Gbps and 10Gbps. You're looking at several thousand US$ per unit, under US$10,000. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Tue Feb 19 04:56:38 2019 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Feb 2019 20:56:38 -0800 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: > On Jan 16, 2019, at 08:52, Colton Conor wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. So one of the properties of customer experience of internet performance is that their first hop is not going to be exposed in testing from the CPE. This is one of the enduring motivations of internet speed tests run inside clients. Setting aside claims about buffer bloat. Radio interfaces can have dramatic impact on the first hop latency that propagate to everything upstream. > > What opensource and commercial options are out there? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Tue Feb 19 05:37:37 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 18 Feb 2019 21:37:37 -0800 Subject: A Zero Spam Mail System [Feedback Request] Message-ID: <20190218213737.E3A6BC60@m0117568.ppops.net> --- beecher at beecher.cc wrote: From: Tom Beecher Every single person on this list has either sent an email they later regret[...] ------------------------------------------ Not me. No way. Never. ;) scott From list at satchell.net Tue Feb 19 13:11:02 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 19 Feb 2019 05:11:02 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <20190218213737.E3A6BC60@m0117568.ppops.net> References: <20190218213737.E3A6BC60@m0117568.ppops.net> Message-ID: <75791eed-b1d4-c7fb-da05-c234cd18902a@satchell.net> On 2/18/19 9:37 PM, Scott Weeks wrote: > Not me. No way. Never. ;) Then why is Mr. Murphy tapping you on the shoulder? Didn't your Mom and Dad ever tell you to never say "never"? From cvuljanic at gmail.com Tue Feb 19 13:11:30 2019 From: cvuljanic at gmail.com (Craig) Date: Tue, 19 Feb 2019 08:11:30 -0500 Subject: Microsoft Peering IPv4 BGP Table Message-ID: If someone could please send me a IPv4 BGP table for the Microsoft Express Routes Microsoft Peer for the prefixes you are receiving, I would appreciate it. thanks; CPV -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Tue Feb 19 15:26:38 2019 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 19 Feb 2019 15:26:38 +0000 Subject: Cisco ASR's with RSP440 engines... In-Reply-To: <8d9a26b2-9d6d-2f64-000f-aad5619b6179@essenz.com> References: <8d9a26b2-9d6d-2f64-000f-aad5619b6179@essenz.com> Message-ID: <1f671fcd-1f1a-0e78-611d-f4aa36026b79@ninjabadger.net> On 18/02/2019 21:50, John Von Essen wrote: > If anyone on here has experience with the ASR series running the > RSP440-SE or -TR, please contact me off-list. I'm trying to better > understand real world performance when it comes to handling a few full > BGP tables on these, it would be running as very basic edge router > primarily just doing BGP. I know the RSP440 is EOL, but the plan would > be to upgrade to RSP880 within a year. The 440 is a beast. Faster even than the 9001's RP. You'll be fine with a LOT of BGP edge work. :) The RSP880 is faster on paper, but I'll be impressed if you notice a difference over the 440 in terms of solely basic BGP edge functions. It of course has support for other things that you might need, however. (No idea why this would need to be offlist...) -- Tom From mfidelman at meetinghouse.net Tue Feb 19 15:27:51 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 19 Feb 2019 10:27:51 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <20190218213737.E3A6BC60@m0117568.ppops.net> References: <20190218213737.E3A6BC60@m0117568.ppops.net> Message-ID: On 2/19/19 12:37 AM, Scott Weeks wrote: > > --- beecher at beecher.cc wrote: > From: Tom Beecher > > Every single person on this list has either > sent an email they later regret[...] > ------------------------------------------ > > > Not me. No way. Never. ;) > > scott Bet you're about to regret this one. :-) Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From adamv0025 at netconsultings.com Tue Feb 19 15:28:43 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 19 Feb 2019 15:28:43 -0000 Subject: BGP topological vs centralized route reflector In-Reply-To: References: Message-ID: <003601d4c867$ce729730$6b57c590$@netconsultings.com> I seem to remember there were some good old (really old now) books on BGP discussing various design aspects of BGP infrastructure including topology-based or address-based route reflection, etc... Topology-based doesn’t need to mean in-path you can still have a whole fleet of out-of-the-path RRs servicing say south-east region. My advice is: -Keep your RR-1 infra separate form RR-2 infra (when RR1&RR2=same cluster). -Keep your Internet-RRs and Services-RRs infrastructures separate (ships in night), which is very easy to pull off with current virtualized RRs. -Type-1 RDs will help you simulate full-mesh. adam From: NANOG On Behalf Of Mohammad Khalil Sent: Sunday, February 10, 2019 8:10 PM To: nanog at nanog.org Subject: BGP topological vs centralized route reflector Dears Am trying to find some documents and practical implementations regarding bgp topological vs centralized route reflector(In-band vs out-of-band) Any good shares are appreciated -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Tue Feb 19 15:34:39 2019 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 19 Feb 2019 15:34:39 +0000 Subject: Cisco ASR's with RSP440 engines... In-Reply-To: <1f671fcd-1f1a-0e78-611d-f4aa36026b79@ninjabadger.net> References: <8d9a26b2-9d6d-2f64-000f-aad5619b6179@essenz.com> <1f671fcd-1f1a-0e78-611d-f4aa36026b79@ninjabadger.net> Message-ID: <658f7ca3-dd49-1053-32f9-43cca9852b82@ninjabadger.net> On 19/02/2019 15:26, Tom Hill wrote: > I know the RSP440 is EOL, but the plan would > be to upgrade to RSP880 within a year. Also, the RSP880-RL is available for the same price as 440 on list. If you certainly need 880 later, I might be wondering if Cisco will 'help' with securing a discount for the upgrade license later in the day. Just a thought. :) Regards, -- Tom From jwbensley at gmail.com Tue Feb 19 15:57:49 2019 From: jwbensley at gmail.com (James Bensley) Date: Tue, 19 Feb 2019 15:57:49 +0000 Subject: Cisco ASR's with RSP440 engines... In-Reply-To: <1f671fcd-1f1a-0e78-611d-f4aa36026b79@ninjabadger.net> References: <8d9a26b2-9d6d-2f64-000f-aad5619b6179@essenz.com> <1f671fcd-1f1a-0e78-611d-f4aa36026b79@ninjabadger.net> Message-ID: On Tue, 19 Feb 2019 at 15:29, Tom Hill wrote: > > On 18/02/2019 21:50, John Von Essen wrote: Hi John, > > If anyone on here has experience with the ASR series running the > > RSP440-SE or -TR, please contact me off-list. I'm trying to better > > understand real world performance when it comes to handling a few full > > BGP tables on these, it would be running as very basic edge router > > primarily just doing BGP. I know the RSP440 is EOL, but the plan would > > be to upgrade to RSP880 within a year. > > The 440 is a beast. Faster even than the 9001's RP. You'll be fine with > a LOT of BGP edge work. :) Tom's experiances mirror my own, the 440 is a work horse, a few BGP feeds will be no problems. Cheers, James. From adamv0025 at netconsultings.com Tue Feb 19 16:04:28 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 19 Feb 2019 16:04:28 -0000 Subject: MX204 applications, (was about BGP RR design) In-Reply-To: References: <0b450bc5-a502-278c-17ee-d05491db40d8@seacom.mu> <9b066691-a4d6-ad08-9ad4-2c2f106731fb@pubnix.net> <89970d9e-d51f-c611-131f-717d773c7f9a@seacom.mu> <000301d4c476$41364e10$c3a2ea30$@gvtc.com> Message-ID: <004c01d4c86c$ccf97270$66ec5750$@netconsultings.com> > Saku Ytti > Sent: Friday, February 15, 2019 8:41 AM > > On Fri, Feb 15, 2019 at 9:55 AM Mark Tinka wrote: > > > > MX204 be good for that ? > > > > I'm sure it will be - it's an MPC7 in a cage :-). > > Anyone know why MX204 has so few ports? It seems like it only has WAN > side used, leaving FAB side entirely unused, throwing away 50% of free > capacity. > I don't think aiming for good PPS is the case. See KB33477, if the "spare" capacity was there to boost the available pps budget for the artificially limited number of ports I don't think there would be any KB33477. Maybe some other architectural challenge, don't know? Also this could be asked of any platform from any vendor, just give us 48x 40/100GE ports for each NPU and we'll figure out what to do with those. Maybe there will be use-cases where I enable all of them as I don't expect much traffic/pps to be generated on each port and maybe there will be cases where I enable just one port as I expect 64b frames @ line-rate and have 100k lines in the filter matching for packet size. You actually reminded me of the A9K-24X10GE vs A9K-36X10GE (yes please, I'll have 36 ports variant and I'll decide what to do with them). adam From jason+nanog at lixfeld.ca Tue Feb 19 16:06:13 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Tue, 19 Feb 2019 11:06:13 -0500 Subject: BGP topological vs centralized route reflector In-Reply-To: <003601d4c867$ce729730$6b57c590$@netconsultings.com> References: <003601d4c867$ce729730$6b57c590$@netconsultings.com> Message-ID: Hi Adam, > On Feb 19, 2019, at 10:28 AM, wrote: > > -Type-1 RDs will help you simulate full-mesh. By “Type-1 RD”, are you referring to a unique RD per PE? -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Tue Feb 19 16:28:03 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 19 Feb 2019 16:28:03 -0000 Subject: BGP topological vs centralized route reflector In-Reply-To: References: <003601d4c867$ce729730$6b57c590$@netconsultings.com> Message-ID: <005401d4c870$187cc730$49765590$@netconsultings.com> yes From: Jason Lixfeld Sent: Tuesday, February 19, 2019 4:06 PM To: adamv0025 at netconsultings.com Cc: Mohammad Khalil ; nanog at nanog.org Subject: Re: BGP topological vs centralized route reflector Hi Adam, On Feb 19, 2019, at 10:28 AM, > > wrote: -Type-1 RDs will help you simulate full-mesh. By “Type-1 RD”, are you referring to a unique RD per PE? -------------- next part -------------- An HTML attachment was scrubbed... URL: From samir.rana at cybera.ca Tue Feb 19 19:50:55 2019 From: samir.rana at cybera.ca (Samir Rana) Date: Tue, 19 Feb 2019 12:50:55 -0700 Subject: fs.com dwdm equipment In-Reply-To: References: <20190218195420.ykvkul4lvyius4to@angus.ind.wpi.edu> Message-ID: > > Hi All, Thank you very much all of you for the valuable feedback. Regards, Samir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bclaise at cisco.com Wed Feb 20 17:19:08 2019 From: bclaise at cisco.com (Benoit Claise) Date: Wed, 20 Feb 2019 18:19:08 +0100 Subject: Quick Script to check the uptime of ASR920's In-Reply-To: References: Message-ID: <7b231933-44c1-3264-8dd5-a6dccc9e2824@cisco.com> Erik, Just in case you want to go into/learn the data model-driven management, here is a NETCONF/YANG script. CiscoRouterUptimeNETCONF) dvulovic at DVULOVIC-D2DW2:~/python-venv/CiscoRouterUptimeNETCONF$ ./CiscoRouterUptimeNETCONF.py testinput CiscoRouterUptimeNETCONF by Djordje Vulovic (dvulovic at cisco.com) ---------------------------------------------------------------- Router 10.1.2.1 has uptime of 5724548.0 seconds (66 days, 6:09:08) Router 10.1.2.2 has uptime of 5724551.0 seconds (66 days, 6:09:11) Router 10.1.2.3 has uptime of 5724555.0 seconds (66 days, 6:09:15) Router 10.1.2.4 has uptime of 5724557.0 seconds (66 days, 6:09:17) Router 10.1.2.5 has uptime of 5724497.0 seconds (66 days, 6:08:17) (CiscoRouterUptimeNETCONF) dvulovic at DVULOVIC-D2DW2:~/python-venv/CiscoRouterUptimeNETCONF$ ./CiscoRouterUptimeNETCONF.py CiscoRouterUptimeNETCONF by Djordje Vulovic (dvulovic at cisco.com) ---------------------------------------------------------------- Usage: CiscoRouterUptimeNETCONF File consists of lines ,,, The script was tested on a real ASR920, running IOS 16.8.1 See the source code at https://github.com/djordjevulovic/CiscoRouterUptimeNETCONF Thanks to Djordje for developing this script. Regards, Benoit > All, > > I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday > > Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime > It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. > > > Output Format in CSV > DeviceName, IP, Uptime in Days, OK/Warning > > I set my warning to 800 Days, you can change this in the code > > > ASR920list.txt > ------------- > ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey > ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey > ~~~~snip you get the idea~~~~ > > > Output > > [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt > ASR920-1.SEA1, 192.168.28.1, 827, WARNING > ASR920-2.SEA1, 192.168.28.2, 827, WARNING > ASR920-2.ATL1, 192.168.23.2, 828, WARNING > ASR920-1.ATL1, 192.168.23.1, 813, WARNING > ASR920-1.CHI1, 192.168.21.3, 828, WARNING > ASR920-1.NYC1, 192.168.25.1, 787, OK > ASR920-2.CHI1, 192.168.21.4, 720, OK > ASR920-3.CHI1, 192.168.21.5, 720, OK > ASR920-1.DAL1, 192.168.26.3, 488, OK > ASR920-4.CHI1, 192.168.21.6, 142, OK > > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. > . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjohn at ethoplex.com Wed Feb 20 17:51:45 2019 From: kjohn at ethoplex.com (Keefe John) Date: Wed, 20 Feb 2019 11:51:45 -0600 Subject: Ticketmaster Message-ID: Can someone from Ticketmaster contact me off-list? We have a customer who seems to be partially blocked from your website. Keefe John CEO Ethoplex Direct: 262.345.5200 -------------------- Ethoplex Business Internet http://www.ethoplex.com/ Signal Residential Internet http://www.signalisp.com/ https://www.linkedin.com/in/keefejohn/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Wed Feb 20 19:20:18 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 20 Feb 2019 19:20:18 +0000 Subject: Quick Script to check the uptime of ASR920's In-Reply-To: <7b231933-44c1-3264-8dd5-a6dccc9e2824@cisco.com> References: , <7b231933-44c1-3264-8dd5-a6dccc9e2824@cisco.com> Message-ID: <800FEB44-4A27-4C46-9065-4B55EA03DBE2@beckman.org> I realize you’re aiming for the NETCONF paradigm, but for anyone interested, a more consistent, device- and release-independent method is to just query the SNMP uptime variable: $ snmpget -v 1 -c demopublic 10.1.2.1 system.sysUpTime.0 system.sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77 -mel beckman On Feb 20, 2019, at 11:00 AM, Benoit Claise via NANOG > wrote: Erik, Just in case you want to go into/learn the data model-driven management, here is a NETCONF/YANG script. CiscoRouterUptimeNETCONF) dvulovic at DVULOVIC-D2DW2:~/python-venv/CiscoRouterUptimeNETCONF$ ./CiscoRouterUptimeNETCONF.py testinput CiscoRouterUptimeNETCONF by Djordje Vulovic (dvulovic at cisco.com) ---------------------------------------------------------------- Router 10.1.2.1 has uptime of 5724548.0 seconds (66 days, 6:09:08) Router 10.1.2.2 has uptime of 5724551.0 seconds (66 days, 6:09:11) Router 10.1.2.3 has uptime of 5724555.0 seconds (66 days, 6:09:15) Router 10.1.2.4 has uptime of 5724557.0 seconds (66 days, 6:09:17) Router 10.1.2.5 has uptime of 5724497.0 seconds (66 days, 6:08:17) (CiscoRouterUptimeNETCONF) dvulovic at DVULOVIC-D2DW2:~/python-venv/CiscoRouterUptimeNETCONF$ ./CiscoRouterUptimeNETCONF.py CiscoRouterUptimeNETCONF by Djordje Vulovic (dvulovic at cisco.com) ---------------------------------------------------------------- Usage: CiscoRouterUptimeNETCONF File consists of lines ,,, The script was tested on a real ASR920, running IOS 16.8.1 See the source code at https://github.com/djordjevulovic/CiscoRouterUptimeNETCONF Thanks to Djordje for developing this script. Regards, Benoit All, I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. Output Format in CSV DeviceName, IP, Uptime in Days, OK/Warning I set my warning to 800 Days, you can change this in the code ASR920list.txt ------------- ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey ~~~~snip you get the idea~~~~ Output [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, OK ASR920-4.CHI1, 192.168.21.6, 142, OK ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. . -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.lyon at gmail.com Wed Feb 20 19:52:32 2019 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 20 Feb 2019 11:52:32 -0800 Subject: Ticketmaster In-Reply-To: References: Message-ID: <9A33B71A-4492-495B-ADFE-44A028567A37@gmail.com> Good luck. They are assholes. Never found any if them on NANOG before in my past experiences. -Mike > On Feb 20, 2019, at 09:51, Keefe John wrote: > > Can someone from Ticketmaster contact me off-list? We have a customer who seems to be partially blocked from your website. > > Keefe John > CEO > Ethoplex > Direct: 262.345.5200 > -------------------- > Ethoplex Business Internet > http://www.ethoplex.com/ > Signal Residential Internet > http://www.signalisp.com/ > > https://www.linkedin.com/in/keefejohn/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthew.Black at csulb.edu Wed Feb 20 20:22:51 2019 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 20 Feb 2019 20:22:51 +0000 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: SIGH. I am far more inclined to listen to John Levine or Suresh Ramasubramanian, both who have been around for decades and have earned their chops with DMARC and Sendmail. Both with a proven track record, rather than someone lacking credentials. Since spam is a subjective term, I’d personally like to know how someone can design a solution that works for billions of people. Heck, you need to improve over existing technology that provides a false negative rate p < 0.01 and false positive p < 0.005. Someone who thinks Gmail is e-mail 1.0 fails to grasp history. Have you ever created a sendmail.cf without using M4? [This message represents views of the author and not any employer (present or former).] From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Viruthagiri Thirumavalavan Sent: Sunday, February 17, 2019 6:04 PM To: nanog list Subject: A Zero Spam Mail System [Feedback Request] Hello Everyone, My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP over TLS on Port 26 last month. I'm also the guy who attacked (???) John Levine. Today I have something to show you. Long story short.... I solved the email spam problem. Well... Actually I solved it long time back. I'm just ready to disclose it today. Again... Yeah.. Yeah.. Yeah... If only I had a dime for every time people insult me for saying "I solved the spam problem" They usually start with the insult like "You think you are the inventor of FUSSP?" These guys always are the know-it-all assholes. They don't listen. They don't want to listen. They are like barking dogs. If one started to bark, everyone else gets the courage to do the same thing. I'm tired of fighting these assholes in every mailing list. I'm on your side morons. So how about you all knock it off? Six months back, it was John Levine who humiliated me in the DMARC list. Apparently, for him 50 words are enough to attack me. Töma Gavrichenkov and Suresh Ramasubramanian even started to defend this man saying 50 words are enough to judge a 50,000 words paper. [We are gonna figure it out today] ---------------------------------- @Töma Gavrichenkov In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment. How can you be so sure that you didn't fuck up none of the lives of these "few cases"? Or in more technical terms, How can you be absolutely sure that there is no "False Positives"? ---------------------------------- @Suresh Ramasubramanian Yes, 50 words are more than enough to decide a bad idea is bad. You don't have to like that, or like any of us, but facts are facts Merely appending the text "facts are facts" not gonna convert a bullshit statement into a fact. You know what's the meaning of the word "fact"? It's a statement that can be proved TRUE. Let's do a little experiment. 100 researchers presents their lifetime work to us. Each of their research paper contain 50,000 words. We are gonna judge them. You are gonna judge them based on only the first 50 words. And I'm gonna judge them by tossing a coin. Can you guess who is gonna fuck up less number of researcher lives? I'm claiming that I solved the email spam problem. If that's true, then you should know, common sense is one of the very basic requirement for that. I designed my email system. Every inch of it. I wrote my research paper. Every word of it. I made my prototype video. Every second of it. So I'm the captain of my ship. Not you. But you all think you know my system better than me? That too, with only 50 words? My research paper has around 50,000 words. And you think 50 words are enough to judge my work? Let me make sure I get this right. You are all saying, you know what's in the rest of the 49,950 words based on only the first 50 words? That's stupid on so many levels. If you are gonna do a half-assed job and relay that misinformation to thousands of people, why volunteer in the first place? And by the way, by saying you are all doing half-assed job, I'm actually insulting the people who are REALLY doing the half-assed job. ---------------------------------- John Levine vs. me One month back, some of you may have noticed a thread created by John Levine where he goes like "He's Forum Shopping". The whole gist of that message was "We already have DANE and MTA-STS. We don't a third solution". And then I used some harsh words to defend myself. But that was the Season 2 of his "Shitshow". The Season 1 was aired 6 months back. You all missed that show. This is what happened in Season 1. 1. Six months back, I posted on three mailing list saying "I solved the email spam problem" and asked them to provide feedback on my invention. Those three mailing lists were SPF, DKIM and DMARC. That's because my solution relied on them and those three were the only email related mailing lists I knew at that time. 2. In DMARC community, John Levine started to insult me after reading only the first 50 words. 3. Dave Crocker joined the cast and did a flawless job on abusing me. He asked me to kill my project. I told him he is being rude. And this is what he replied for that. He is one of the most radical and ignorant person I have seen in tech. He didn't even stop for a moment and think "Am I attacking an Innocent person?". He even went to other mailing lists to attack me. He abused all his power and kept on attacking me just to have some "dopamine orgasm". Something tells me he slept peacefully on that day. 4. And then bunch of other guys joined. So the whole thread gone crazy. This is because John Levine successfully distributed wrong version of the story to thousands of people with only 50 words. 5. Both Dave Crocker and John Levine are the bigshots there. So I knew no matter how much I cry for help, no one is gonna help me. 6. John seemed like a "decent-asshole" while compared to Dave Crocker. So I sent a private mail to John saying "John, I'm not really sure whether I can afford you since I have not raised any money yet. But let me give it a shot. Could you tell me how much you would charge to go through my presentation, demo video and give me a detailed feedback about my system?" [The reason I was ready to pay him is because he made it very clear in the DMARC thread by saying "Sorry, but I don't provide consulting for free". I thought if I make him read my document, he would go back and correct his mistake] 7. And this is what he replied for that. "Really, even if you had money, it wouldn't be worth your money or my time". [For the record, he come to this conclusion without even knowing what's inside in my document] 8. I said only "ok, thankyou" and then unsubscribed from the DMARC mailing list. [What more can you argue with a bunch of know-it-all morons who thinks they are all right?] 9. Six month later (last month), John started his shitshow again attacking my IETF proposal. He tried to make me look like an idiot again. And that's when I started to defend myself by using harsh words. 10. You all know the rest. ---------------------------------- One person told me on that thread to take John Levine's words as criticism. You see I have no problems with criticism. I usually thank people when they criticize my work. The best criticism usually follows this format. "I went through your paper (#1), your work is full of shit (#2), Here are the reasons (#3)" #1 says, the critic really knows what the author is talking about. #2 says, the critic is speaking his mind without any bullshit. #3 says, the critic has valid points for his criticism. However, I can't consider someone as critic who straightly go for #2. Especially when the whole argument was all about killing my work just because he is one of the inventor of MTA-STS. If I start to listen his words, then next time he will create a new thread to attack me for creating saying "He's forum shopping. I already told him it's not worth his money and my time". What you want me to do in this case? Take that as criticism and move on? It's my 5 fucking years of research. I can't just let it go just because someone doesn't like my work. ---------------------------------- @Valdis Kletnieks You missed the part where the RFC says you *MUST* fall back to A if there's no MX. "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself; Therefore all progress depends on the unreasonable man" - George Bernard Shaw ---------------------------------- @John Levine I was trying to contribute to IETF the other day. One of the guy from DMARC list uses your words as a reason to attack me and asking me to turn down the proposal. You were watching that. If I really solved the email spam problem, that puts me in the "best problem solvers in the world" category. So how about you go back to the DMARC list and write a decent apology for posting misinformation to everyone? [Of course only if I solved the spam problem. That was my claim from the beginning right?] ---------------------------------- @Everyone Here is what you all should know. It's my 5 years of research. So it's worth more than 50 words. I started my work back in 2013 and I used to call my work "XMail" at that time. It's now called "Dombox" My prototype codebase has around 200,000 lines of code. [To be exact: 466,965 ++ 254,169 --] Sequoia Capital is one of the well known venture firm in the world. They have invested in over 250 companies since 1972, including Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp. Bill Coughran is a senior investor in Sequoia Capital. According to his linkedin profile, he started as a Programmer in the late 60s and held many engineering related positions over the years. Worked in Bell Laboratories for 20 years. Worked as SVP of Engineering in Google for 8.5 years. To quote his words "I have some level of expertise about the current email systems, which is why I was did some investigating". So this man is one of the toughest person to impress. But he is one of the nicest investor I have met. When I asked him whether he can take a look, he didn't insult me with words like "You think you are the inventor of FUSSP?" He just told me "Sure, I'd be happy to." He went through my entire paper and then sent me this mail. He later turned me down because it's hard for a startup to distribute a new solution. Maybe he is right. Or maybe I'll overcome that too. [Today's discussion is about whether I solved the spam problem. Not about how I'm gonna distribute the solution] Yesterday I published my work on a medium blog post and linked my white paper. An engineer read my white paper and sent me this mail. These guys see value in my white paper because they completed my ~300 pages white paper. To the "50 words are enough" band members, let me tell you something. I'm the author of my work. It's my job to decide "what to show you" and "when to show you". I have posted my system summary in a medium blog post. When you reach 75% of the article, you will see a title called "Hot Gates Strategy". Everything you see above is pointless without the remaining 25% of the content. Put it this way, I have designed 75% of that system, only to have remaining 25% of the system. So yeah, even if you had 75% of the content, you still can't judge my work. Whether you all believe it or not, I'm the goddamn inventor of FUSSP. I can proudly say that because my system doesn't have the "spam" folder. So how about you all appreciate the guy who spent 5 years in chasing for a solution like a madman and succeeded in solving a challenging problem rather than spending your time in attacking me? [For the record, my single white paper plenty of problems. Email Spam is one of them] Looking forward to hear your feedback. People who complete my white paper, please post whether my claims are true or I'm just wasting everyone's time. [I'm going to bed now. So I may not be online for the next 8 hours. I'll respond to your queries after that] Thanks ---------------------------------- Materials: System Overview - https://medium.com/@Viruthagiri/dombox-the-zero-spam-mail-system-2b08ff7432cd White Paper - https://www.dombox.org/dombox.pdf Flowcharts - https://www.dombox.org/flowcharts.pdf Prototype - https://www.youtube.com/watch?v=VK2eSfCurx4 [This is the video I uploaded before posting to DMARC list. So the interface is little outdated] -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhc2 at dcrocker.net Wed Feb 20 22:02:18 2019 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 20 Feb 2019 14:02:18 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: On 2/20/2019 12:22 PM, Matthew Black wrote: > SIGH. I am far more inclined to listen to John Levine or Suresh > Ramasubramanian, both who have been around for decades and have earned > their chops with DMARC and Sendmail. Both with a proven track record, > rather than someone lacking credentials. Since spam is a subjective > term, I’d personally like to know how someone can design a solution that > works for billions of people. Listen to them, by all means, but I'll suggest something simpler: This is already a long thread and has been both unproductive and unpleasant. Most folk who experience such a pattern in a mailing list do not ever see it change until the actors or the topic changes, and usually it takes both... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From bzs at theworld.com Wed Feb 20 22:14:11 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 20 Feb 2019 17:14:11 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <23661.53555.895993.581385@gargle.gargle.HOWL> Just to put my unwelcome, OT 2 cents in... Spammers, individual spamming operations, send on the order of one billion emails per day, per each. Their business model depends on doing that. That's why we all see the same sort of spams over and over to the point one can make a joke about them (YOU JUST WON THE EUROLOTTERY!) and everyone knows what you're referring to, everyone. Anything which slows that down to a trickle -- what honest source needs to send a billion emails per day? -- would likely make the worst of the spamming business not worthwhile in general. (yeah yeah don't explain bots or snowshoeing to me, thanks.) The problem is that most proposals along those lines, somehow volume limiting or charging for email (say beyond 100K/day might do it, even 1M/day might do it) are met with instant hostility usually in the form of vague straw men about how something like that would have to work and rejection of that straw man. Which mostly just amounts to "I don't like volume limiting or charging schemes for email so here's a really dumb way it would have to work and why it's dumb". (please don't reply with your straw men interpretations of how it would have to work which you just thought up.) Or the vague "acceptance" argument, that could take 10 YEARS they've been saying for the past 20+ years. Or "spam is no longer a problem". Whatever. I didn't mean to start a discussion on the specifics. Just that in very broad terms those two, somehow rate-limiting or charging or both, probably are the only which might make sense in the abstract because they actually address the vast volume of email spammers need to send to stay in business. Spam has accomplished one thing while many fiddled uncomfortable with the most likely mitigations: It's raised the cost of managing public email services to the point that only someone like google/gmail can afford it w/o some subsidizing income stream, and even for google it's probably a cross-subsidized loss leader tho I really don't know. P.S. If you PERSONALLY don't ever want to see a spam message again in your inbox that's really easy: Hire A Secretary or Personal Assistant! -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bruns at 2mbit.com Wed Feb 20 22:29:39 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 20 Feb 2019 15:29:39 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> On 2/20/2019 1:22 PM, Matthew Black wrote: > Have you ever created a sendmail.cf without using M4? Well, that brought back memories I did not want to revisit. You are going to make me want to take up drinking. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From ops.lists at gmail.com Wed Feb 20 23:25:15 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 20 Feb 2019 23:25:15 +0000 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> References: , <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> Message-ID: I've tried never to hand write a sendmail.cf, to be honest - I doubt even the sendmail authors recommended being that brave :). And I haven't done all that much with dmarc beyond using it. --srs ________________________________ From: NANOG on behalf of Brielle Bruns Sent: Thursday, February 21, 2019 4:01 AM To: nanog at nanog.org Subject: Re: A Zero Spam Mail System [Feedback Request] On 2/20/2019 1:22 PM, Matthew Black wrote: > Have you ever created a sendmail.cf without using M4? Well, that brought back memories I did not want to revisit. You are going to make me want to take up drinking. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheitz at cisco.com Wed Feb 20 23:57:25 2019 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Wed, 20 Feb 2019 23:57:25 +0000 Subject: Cisco ASR's with RSP440 engines... Message-ID: Wheeee! Thanks man! Jakob. -----Original Message----- Date: Tue, 19 Feb 2019 15:26:38 +0000 From: Tom Hill On 18/02/2019 21:50, John Von Essen wrote: > If anyone on here has experience with the ASR series running the > RSP440-SE or -TR, please contact me off-list. I'm trying to better > understand real world performance when it comes to handling a few full > BGP tables on these, it would be running as very basic edge router > primarily just doing BGP. I know the RSP440 is EOL, but the plan would > be to upgrade to RSP880 within a year. The 440 is a beast. Faster even than the 9001's RP. You'll be fine with a LOT of BGP edge work. :) The RSP880 is faster on paper, but I'll be impressed if you notice a difference over the 440 in terms of solely basic BGP edge functions. It of course has support for other things that you might need, however. (No idea why this would need to be offlist...) -- Tom From valdis.kletnieks at vt.edu Wed Feb 20 23:59:49 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 20 Feb 2019 18:59:49 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <24168.1550707189@turing-police.cc.vt.edu> On Wed, 20 Feb 2019 20:22:51 +0000, Matthew Black said: > Have you ever created a sendmail.cf without using M4? Sendmail 5.6mumble or so, for a machine that was on UUCP, Arpa/Milnet, and Bitnet and gatewayed between them. Bitnet was particularly ugly because (a) EBCDIC and (b) no way to represent a null line in NJE. Bonus points for the bisync interface card that claimed to do DLE stuffing for SDLC but didn't... And of course, approaching any address that had all 3 of %, ! and @ in them was loads of fun because the semantics depended on which interface they came in on... From cabo at tzi.org Thu Feb 21 01:24:06 2019 From: cabo at tzi.org (Carsten Bormann) Date: Thu, 21 Feb 2019 02:24:06 +0100 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <24168.1550707189@turing-police.cc.vt.edu> References: <24168.1550707189@turing-police.cc.vt.edu> Message-ID: Been there, done that (I wrote my own driver for the bisync card, so I didn’t have the latter problem, just had to tame a barely documented Motorola chip “helping” with the already weird DLE handling). I’d still prefer doing that again over today’s spam problem. (There actually is a teachable lesson here, which is about getting rid of gateways. But that’s for another day…) Grüße, Carsten > On Feb 21, 2019, at 00:59, valdis.kletnieks at vt.edu wrote: > > On Wed, 20 Feb 2019 20:22:51 +0000, Matthew Black said: >> Have you ever created a sendmail.cf without using M4? > > Sendmail 5.6mumble or so, for a machine that was on UUCP, Arpa/Milnet, and > Bitnet and gatewayed between them. Bitnet was particularly ugly because (a) > EBCDIC and (b) no way to represent a null line in NJE. Bonus points for the > bisync interface card that claimed to do DLE stuffing for SDLC but didn't... > > And of course, approaching any address that had all 3 of %, ! and @ in them > was loads of fun because the semantics depended on which interface they > came in on... > > From lists at packetflux.com Thu Feb 21 02:01:40 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Wed, 20 Feb 2019 19:01:40 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: On Wed, Feb 20, 2019 at 1:24 PM Matthew Black wrote: > Have you ever created a sendmail.cf without using M4? I still believe that sendmail is Alien technology. How else can one explain sendmail.cf? And although I can't say for sure that I created a sendmail.cf from scratch without using the M4 macros, I can say for sure that I've definitely edited/modified/hacked an existing sendmail.cf file which wasn't working as one would expect. I'm also not 100% certain that m4 was even an option for the first sendmail install I did... my first sendmail setup was probably 25 years ago at this point. I guess I can add my $0.02 to this thread since it resurrected: There have been lots and lots of solutions proposed over the years which would have 'solved' spam in one way or another. Micropayments, authentication, encryption, etc. Each had their strengths and weaknesses. But at this point, pretty much every 'new' solution seems to just be a rehash of an old idea, quite possibly because the person proposing the new solution isn't aware of the past history. I do wonder if some of the old suggested solutions might be more viable today, just because of the increase of computing power available. For example, some of the cryptographic signature-based systems might pay to be revisited since cryptography has become relatively inexpensive CPU-wise. From bzs at theworld.com Thu Feb 21 03:16:31 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 20 Feb 2019 22:16:31 -0500 Subject: A Zero Spam Mail System [Feedback Request]...sendmail.cf In-Reply-To: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> Message-ID: <23662.6159.617659.431411@gargle.gargle.HOWL> On February 20, 2019 at 15:29 bruns at 2mbit.com (Brielle Bruns) wrote: > On 2/20/2019 1:22 PM, Matthew Black wrote: > > Have you ever created a sendmail.cf without using M4? I've certainly maintained them, one usually started with whatever came with the source distr or maybe you'd get someone to share something with you to bang on. One reason sendmail.cf's seem so complicated is because sendmail was designed to gateway and route between very different email systems. For example UUCP where email addresses looked like uunet!bu!bzs and berknet (UCB) where it looked like host:user (Berknet was largly written by Eric Schmidt, as in the former Google CEO), and chaosnet (MIT), DECNET, IBM/SNA, BITNET, etc. The "internet" really meant to many that we were going to tie all those together at least somewhat and it was fairly successful for email. I know I regularly used and admin'd decnet, bitnet, uucp, as well as the usual ARPA stuff. P.S. ISTR that someone wrote an adventure ("Collosal Cave") type game as a sendmail config, it may have even produced a paper but I can't find it (Usenix?) -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bill at herrin.us Thu Feb 21 03:44:36 2019 From: bill at herrin.us (William Herrin) Date: Wed, 20 Feb 2019 19:44:36 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: On Wed, Feb 20, 2019 at 12:23 PM Matthew Black wrote: > Have you ever created a sendmail.cf without using M4? I started using sendmail before sendmail started using M4. I'm still using the hand-hacked sendmail.cf I built up over time. I had to muck with the sendmail package on my Linux distro which really strongly wanted to generate sendmail.cf's from the M4 instead of using mine. I only wish postfix had as good diagnostic tools for analyzing address transform and delivery selection. [magic:root:/etc/mail:1202] sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter
> 3,0 bill at herrin.us 3 input: bill @ herrin . us 6 input: bill < @ herrin . us > 6 returns: bill < @ herrin . us > 3 returns: bill < @ herrin . us > 0 input: bill < @ herrin . us > 47 input: bill < @ herrin . us > 46 input: bill @ herrin . us . < O > . bill @ herrin . us . < > . 46 input: bill @ herrin . us . < O > . herrin @ dirtside . com . < > . 46 input: bill @ herrin . us . < O > . herrin @ magic . dirtside . com . < > . 46 returns: bill @ herrin . us . < O > . herrin @ magic . dirtside . com . < unchd > . < > . 46 returns: bill @ herrin . us . < O > . herrin @ magic . dirtside . com . < unchd > . < > . 46 returns: bill @ herrin . us . < O > . herrin @ magic . dirtside . com . < unchd > . < > . 47 returns: herrin < @ magic . LOCAL > 30 input: herrin 3 input: herrin 3 returns: herrin 0 input: herrin 9 input: herrin 9 returns: herrin 0 returns: $# local $: herrin 30 returns: $# local $: herrin 0 returns: $# local $: herrin Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Feb 21 04:34:07 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 20 Feb 2019 21:34:07 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: On 2/20/19 8:44 PM, William Herrin wrote: > I only wish postfix had as good diagnostic tools for analyzing address > transform and delivery selection. ~chuckle~ It's been a while since I've seen someone say they wished Postfix had something that Sendmail has. I agree that Sendmail's rule test mode is quite powerful. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From bruns at 2mbit.com Thu Feb 21 06:07:02 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 20 Feb 2019 23:07:02 -0700 Subject: sendmail.cf In-Reply-To: References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> Message-ID: <1c43b26b-64df-3eeb-59cb-4ae5762f6dfb@2mbit.com> On 2/20/2019 4:25 PM, Suresh Ramasubramanian wrote: > I've tried never to hand write a sendmail.cf, to be honest - I doubt > even the sendmail authors recommended being that brave :). And I haven't > done all that much with dmarc beyond using it. I was 16 when I wrote my first sendmail.cf. Got a rather large check and my first employment ever due to that config file. My brain hurts thinking about that. Can you believe its been _36_ years since the first version of sendmail? *holds up a glass of maker's mark* To the people who made the internet possible. Cheers! -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bzs at theworld.com Fri Feb 22 02:07:42 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 21 Feb 2019 21:07:42 -0500 Subject: sendmail.cf In-Reply-To: <1c43b26b-64df-3eeb-59cb-4ae5762f6dfb@2mbit.com> References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <1c43b26b-64df-3eeb-59cb-4ae5762f6dfb@2mbit.com> Message-ID: <23663.22894.637849.525720@gargle.gargle.HOWL> The predecessor to sendmail was delivermail, 1979, also written by Eric Allman. https://en.wikipedia.org/wiki/Delivermail On February 20, 2019 at 23:07 bruns at 2mbit.com (Brielle Bruns) wrote: > On 2/20/2019 4:25 PM, Suresh Ramasubramanian wrote: > > I've tried never to hand write a sendmail.cf, to be honest - I doubt > > even the sendmail authors recommended being that brave :). And I haven't > > done all that much with dmarc beyond using it. > > > I was 16 when I wrote my first sendmail.cf. Got a rather large check > and my first employment ever due to that config file. > > My brain hurts thinking about that. > > Can you believe its been _36_ years since the first version of sendmail? > > *holds up a glass of maker's mark* > > To the people who made the internet possible. Cheers! > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From feldman at twincreeks.net Fri Feb 22 02:23:22 2019 From: feldman at twincreeks.net (Steve Feldman) Date: Thu, 21 Feb 2019 18:23:22 -0800 Subject: A Zero Spam Mail System [Feedback Request]...sendmail.cf In-Reply-To: <23662.6159.617659.431411@gargle.gargle.HOWL> References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <23662.6159.617659.431411@gargle.gargle.HOWL> Message-ID: <7F35645B-D34E-4B8C-9F97-377E8F23FDD3@twincreeks.net> On Feb 20, 2019, at 7:16 PM, bzs at theworld.com wrote: > > (Berknet was largly written by Eric Schmidt, as in the former Google CEO) I'm pretty sure that was Eric Allman, though I had the privilege of being a lowly Masters student at Berkeley while both Erics, along with Bill Joy and a host of other Internet pioneers, were there. Steve From brett at the-watsons.org Fri Feb 22 03:21:49 2019 From: brett at the-watsons.org (Brett Watson) Date: Thu, 21 Feb 2019 20:21:49 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <663B8F40-0974-49F0-B00C-4B642914102B@the-watsons.org> On Feb 20, 2019, at 19:01, Forrest Christian (List Account) wrote: > > I still believe that sendmail is Alien technology. How else can one > explain sendmail.cf? Eric Altman and scotch, lots of scotch (as I remember it from Usenix). -b From brett at the-watsons.org Fri Feb 22 03:23:30 2019 From: brett at the-watsons.org (Brett Watson) Date: Thu, 21 Feb 2019 20:23:30 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <663B8F40-0974-49F0-B00C-4B642914102B@the-watsons.org> References: <663B8F40-0974-49F0-B00C-4B642914102B@the-watsons.org> Message-ID: <0C971451-B6FE-4BF0-98EF-8D5A9D8F9DD5@the-watsons.org> > On Feb 21, 2019, at 20:21, Brett Watson wrote: > >> On Feb 20, 2019, at 19:01, Forrest Christian (List Account) wrote: >> >> I still believe that sendmail is Alien technology. How else can one >> explain sendmail.cf? > > Eric Altman and scotch, lots of scotch (as I remember it from Usenix). Right, *Allman* of course I meant. From bzs at theworld.com Fri Feb 22 03:33:11 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 21 Feb 2019 22:33:11 -0500 Subject: A Zero Spam Mail System [Feedback Request]...sendmail.cf In-Reply-To: <7F35645B-D34E-4B8C-9F97-377E8F23FDD3@twincreeks.net> References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <23662.6159.617659.431411@gargle.gargle.HOWL> <7F35645B-D34E-4B8C-9F97-377E8F23FDD3@twincreeks.net> Message-ID: <23663.28023.882118.782227@gargle.gargle.HOWL> On February 21, 2019 at 18:23 feldman at twincreeks.net (Steve Feldman) wrote: > On Feb 20, 2019, at 7:16 PM, bzs at theworld.com wrote: > > > > (Berknet was largly written by Eric Schmidt, as in the former Google CEO) > > I'm pretty sure that was Eric Allman, though I had the privilege of being a lowly Masters student at Berkeley while both Erics, along with Bill Joy and a host of other Internet pioneers, were there. I don't have personal knowledge about this but the wikipedia page on berknet credits Eric Schmidt: https://en.wikipedia.org/wiki/Berknet and links to Eric Schmidt's master thesis on Berknet (postscript): http://web.mit.edu/daveg/Info/Links/doc/unix.manual.misc/berknet/berknet.PS Eric Schmidt and Mike Lesk also wrote "lex", the unix lexical analyzer program used primarily for compiler contruction, rewritten as 'flex' (fast lex) on more modern systems. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From jcurran at istaff.org Fri Feb 22 04:27:31 2019 From: jcurran at istaff.org (John Curran) Date: Thu, 21 Feb 2019 22:27:31 -0600 Subject: A Zero Spam Mail System [Feedback Request]...sendmail.cf In-Reply-To: <23662.6159.617659.431411@gargle.gargle.HOWL> References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <23662.6159.617659.431411@gargle.gargle.HOWL> Message-ID: On 20 Feb 2019, at 9:16 PM, bzs at theworld.com wrote: > On February 20, 2019 at 15:29 bruns at 2mbit.com (Brielle Bruns) wrote: >> On 2/20/2019 1:22 PM, Matthew Black wrote: >>> Have you ever created a sendmail.cf without using M4? > > I've certainly maintained them, one usually started with whatever came > with the source distr or maybe you'd get someone to share something > with you to bang on. > > One reason sendmail.cf's seem so complicated is because sendmail was > designed to gateway and route between very different email systems. > ... sendmail.cf was fun, but MMDF channels were so much more amusing – and rather necessary in order to deal with gatewaying BITNET, phonenet, DECNET, X25NET, uunp, and ondemand dialup-ip ppp and cslip domains in a semi-reliable manner on the relay.cs.net and relay2.cs.net servers. It didn’t help that many sendmail.cf files in those days shipped relay.cs.net preset as their default smtp relay host… always made for large queues and careful editing. /John -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Fri Feb 22 05:02:42 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 21 Feb 2019 21:02:42 -0800 Subject: SpaceX Starlink progress, external analysis Message-ID: ISPs throughout the United States that currently operate 11 GHz FCC Part 101 licensed microwave links have begun receiving PCCNs from Starlink. These specify the RF parameters and lat/long locations of the Starlink earth stations. If you have received one of these, I'd be very interested in taking a look at it. The eventual as-built locations of the earth stations will all be public in the FCC's databases (ULS, international bureau, etc). It appears as though the first generation of Starlink satellites will operate as relays in a bent pipe configuration. The design goal for satellite-to-satellite trunk links has been scrapped or postponed. In this method, a satellite or set of satellites in the same orbital plane will need to have LOS visibility to both a CPE terminal and a Starlink earth station. For example, an earth station located near the fiber huts and ISP POPs in Cheyenne, WY would provide the uplink for customers in the same moving spot beam, while it was over WY, such as rural CPEs on remote ranches. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at istaff.org Fri Feb 22 05:03:02 2019 From: jcurran at istaff.org (John Curran) Date: Thu, 21 Feb 2019 23:03:02 -0600 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> On 17 Feb 2019, at 8:03 PM, Viruthagiri Thirumavalavan wrote: > ... > White Paper - https://www.dombox.org/dombox.pdf Viruthagiri - It does not appear that you require anything from this community, as it appears from reading your white paper that your proposed solution relies upon existing Internet protocols and extensions (e.g. SMTP, SPF, DNS, DNS TXT RR types, etc.) One of the nice things about the Internet is that folks can generally innovate without seeking permission from anyone – the protocols are mostly agnostic about the things running over them, so you can implement and promote your solution today – nothing prevents you from moving ahead, and if you have created something that is truly valuable, then you should have no trouble finding investors, customers, and partners for your proposed solution. If your proposed solution doesn’t prove to have a useful return on investment, then that instead shall become apparent. Either way, until such time your solution is deployed widely enough to significantly impact network operations, it’s unlikely to be a particularly relevant topic for discussion here. /John -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Fri Feb 22 06:06:09 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 22 Feb 2019 01:06:09 -0500 Subject: A Zero Spam Mail System [Feedback Request]...sendmail.cf In-Reply-To: References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <23662.6159.617659.431411@gargle.gargle.HOWL> Message-ID: <23663.37201.877553.669707@gargle.gargle.HOWL> Boston Univ Computing Center Director: Barry, is it true that all our BITNET email to/from the academic mainframe goes to our TCP/IP sites (mostly computer science) via a gateway at the University Wisconsin? Me: Yes that is correct, I set that up, they're ok with that. BUCCD: So every email is traveling about 3,000 miles to get 150 feet down the hall??? Me: That sounds about right. BUCCD: *ARE YOU NUTS?!* Me: Never, ever, feel sorry for the wires. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bjorn at mork.no Fri Feb 22 09:50:35 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 22 Feb 2019 10:50:35 +0100 Subject: sendmail.cf In-Reply-To: <23663.22894.637849.525720@gargle.gargle.HOWL> (bzs's message of "Thu, 21 Feb 2019 21:07:42 -0500") References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <1c43b26b-64df-3eeb-59cb-4ae5762f6dfb@2mbit.com> <23663.22894.637849.525720@gargle.gargle.HOWL> Message-ID: <871s40jgno.fsf@miraculix.mork.no> bzs at theworld.com writes: > The predecessor to sendmail was delivermail, 1979, also written by > Eric Allman. > > https://en.wikipedia.org/wiki/Delivermail Damn. Now you made me read RFC801 and wonder why we didn't have an updated version for the IPv6 transition. Or: Where would the Internet have been today without that very explicit "complete switch over" goal? Bjørn From mfidelman at meetinghouse.net Fri Feb 22 13:08:50 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 22 Feb 2019 08:08:50 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> Message-ID: <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> On 2/22/19 12:03 AM, John Curran wrote: > Either way, until such time your solution is deployed widely enough to > significantly impact network operations, it’s unlikely to be a > particularly relevant topic for discussion here. > Notable exception:  DMARC.  Broke email lists everywhere - including those that folks use to solve problems on the net. Heck, it broke the ietf email list. There might be a warning in there - when someone big "innovates" - say Google turning on DMARC rejection, for gmail - that can have rather huge operational impacts.  Still gives me nightmares on occasion (I run a bunch of small lists). Sigh... Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mike.meredith at port.ac.uk Fri Feb 22 14:53:07 2019 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Fri, 22 Feb 2019 14:53:07 +0000 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: References: Message-ID: <20190222145307.41780148@scrofula.eps.is.port.ac.uk> On Wed, 20 Feb 2019 19:01:40 -0700, "Forrest Christian (List Account)" may have written: > On Wed, Feb 20, 2019 at 1:24 PM Matthew Black > wrote: > > Have you ever created a sendmail.cf without using M4? > > I still believe that sendmail is Alien technology. How else can one > explain sendmail.cf? And although I can't say for sure that I I always thought of sendmail.cf as a language for writing MTAs in. I did do *bits* in sendmail.cf but switched to Exim before I got too damaged. > sendmail.cf file which wasn't working as one would expect. I'm also > not 100% certain that m4 was even an option for the first sendmail It wasn't a Sendmail 8 introduction perhaps? -- Mike Meredith, University of Portsmouth Chief Systems Engineer, Hostmaster, Security, and Timelord! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jcurran at istaff.org Fri Feb 22 15:07:49 2019 From: jcurran at istaff.org (John Curran) Date: Fri, 22 Feb 2019 09:07:49 -0600 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> Message-ID: <4DCC699B-A85E-40FE-9044-4399C2FD4AE6@istaff.org> On 22 Feb 2019, at 7:08 AM, Miles Fidelman wrote: > > On 2/22/19 12:03 AM, John Curran wrote: > >> Either way, until such time your solution is deployed widely enough to significantly impact network operations, it’s unlikely to be a particularly relevant topic for discussion here. >> > Notable exception: DMARC. Broke email lists everywhere - including those that folks use to solve problems on the net. Heck, it broke the ietf email list. Indeed - while a self-inflicted injury on its customers, the network effects of massive operating scale effectively transition the problem space from private actor to public… hence not an notable exception, but an actual example of "deployed widely enough” /John From mfidelman at meetinghouse.net Fri Feb 22 15:58:32 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 22 Feb 2019 10:58:32 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <4DCC699B-A85E-40FE-9044-4399C2FD4AE6@istaff.org> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> <4DCC699B-A85E-40FE-9044-4399C2FD4AE6@istaff.org> Message-ID: <570ce331-be30-081c-e1e2-ebc7d467f062@meetinghouse.net> On 2/22/19 10:07 AM, John Curran wrote: > On 22 Feb 2019, at 7:08 AM, Miles Fidelman wrote: >> On 2/22/19 12:03 AM, John Curran wrote: >> >>> Either way, until such time your solution is deployed widely enough to significantly impact network operations, it’s unlikely to be a particularly relevant topic for discussion here. >>> >> Notable exception: DMARC. Broke email lists everywhere - including those that folks use to solve problems on the net. Heck, it broke the ietf email list. > Indeed - while a self-inflicted injury on its customers, the network effects of massive operating scale effectively transition the problem space from private actor to public… > > hence not an notable exception, but an actual example of "deployed widely enough” Hmmm....  But wasn't the initial impact of DMARC that so few senders of email had implemented it?  Also, the impact wasn't just on customers, but on trading partners & communities - communications being a two way street and all. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jcurran at istaff.org Fri Feb 22 16:28:08 2019 From: jcurran at istaff.org (John Curran) Date: Fri, 22 Feb 2019 10:28:08 -0600 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <570ce331-be30-081c-e1e2-ebc7d467f062@meetinghouse.net> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> <4DCC699B-A85E-40FE-9044-4399C2FD4AE6@istaff.org> <570ce331-be30-081c-e1e2-ebc7d467f062@meetinghouse.net> Message-ID: <68D38BD0-6F18-4260-ABDD-6B5331D1D921@istaff.org> On 22 Feb 2019, at 9:58 AM, Miles Fidelman wrote: > > On 2/22/19 10:07 AM, John Curran wrote: > >> On 22 Feb 2019, at 7:08 AM, Miles Fidelman wrote: >>> On 2/22/19 12:03 AM, John Curran wrote: >>> >>>> Either way, until such time your solution is deployed widely enough to significantly impact network operations, it’s unlikely to be a particularly relevant topic for discussion here. >>>> >>> Notable exception: DMARC. Broke email lists everywhere - including those that folks use to solve problems on the net. Heck, it broke the ietf email list. >> Indeed - while a self-inflicted injury on its customers, the network effects of massive operating scale effectively transition the problem space from private actor to public… >> >> hence not an notable exception, but an actual example of "deployed widely enough” > > Hmmm.... But wasn't the initial impact of DMARC that so few senders of email had implemented it? If you (or your email service provider) deploy an optional solution (e.g. DMARC p=reject) that prevents you from receiving email from mailing lists sending in conformance with existing standards, then that’s your choice. Expecting that others will automatically change their behavior (such as wrapping email from mailing lists) isn’t reasonable - you’ve effectively decided (or let your provider decide) that you don’t want existing communications to work for some categories of standard-compliant email. The alternative is ‘Internet Coordination’, but that requires actually coordination before making major changes that will break things. > Also, the impact wasn't just on customers, but on trading partners & communities - communications being a two way street and all. One doesn’t communicate with folks who chose (or let their service provider chose) not to receive email accordingly existing standards. In any case, irrelevant to the dombox situation, unless/until someone actually deploys at a scale large enough to require consideration. /John From mfidelman at meetinghouse.net Fri Feb 22 16:36:03 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 22 Feb 2019 11:36:03 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <68D38BD0-6F18-4260-ABDD-6B5331D1D921@istaff.org> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> <4DCC699B-A85E-40FE-9044-4399C2FD4AE6@istaff.org> <570ce331-be30-081c-e1e2-ebc7d467f062@meetinghouse.net> <68D38BD0-6F18-4260-ABDD-6B5331D1D921@istaff.org> Message-ID: <1fe14288-9b08-1ea6-3d16-065f5497faf0@meetinghouse.net> On 2/22/19 11:28 AM, John Curran wrote: > On 22 Feb 2019, at 9:58 AM, Miles Fidelman wrote: >> On 2/22/19 10:07 AM, John Curran wrote: >> >>> On 22 Feb 2019, at 7:08 AM, Miles Fidelman wrote: >>>> On 2/22/19 12:03 AM, John Curran wrote: >>>> >>>>> Either way, until such time your solution is deployed widely enough to significantly impact network operations, it’s unlikely to be a particularly relevant topic for discussion here. >>>>> >>>> Notable exception: DMARC. Broke email lists everywhere - including those that folks use to solve problems on the net. Heck, it broke the ietf email list. >>> Indeed - while a self-inflicted injury on its customers, the network effects of massive operating scale effectively transition the problem space from private actor to public… >>> >>> hence not an notable exception, but an actual example of "deployed widely enough” >> Hmmm.... But wasn't the initial impact of DMARC that so few senders of email had implemented it? > If you (or your email service provider) deploy an optional solution (e.g. DMARC p=reject) that prevents you from receiving email from mailing lists sending in conformance with existing standards, then that’s your choice. > > Expecting that others will automatically change their behavior (such as wrapping email from mailing lists) isn’t reasonable - you’ve effectively decided (or let your provider decide) that you don’t want existing communications to work for some categories of standard-compliant email. The alternative is ‘Internet Coordination’, but that requires actually coordination before making major changes that will break things. > >> Also, the impact wasn't just on customers, but on trading partners & communities - communications being a two way street and all. > One doesn’t communicate with folks who chose (or let their service provider chose) not to receive email accordingly existing standards. > In any case, irrelevant to the dombox situation, unless/until someone actually deploys at a scale large enough to require consideration. > Not relevant to the dombox approach - though, in fairness, haven't waded into it deep enough to conclude that. But re. "one doesn't communicate with folks .. etc." --- when one has ongoing communication with a large group of people (e.g., an email list) --- and a large provider shuts a door, the impact is on more than just the customers of that provider Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From kmedcalf at dessus.com Fri Feb 22 17:01:54 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 22 Feb 2019 10:01:54 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <1fe14288-9b08-1ea6-3d16-065f5497faf0@meetinghouse.net> Message-ID: <1551f44f8dec3a4aadfed2f634f48317@mail.dessus.com> On Friday, 22 February, 2019 09:36, Miles Fidelman : > But re. "one doesn't communicate with folks .. etc." --- when one has > ongoing communication with a large group of people (e.g., an email > list) --- and a large provider shuts a door, the impact is on more than > just the customers of that provider It affects the self-selected group of folks who chose to invest an inherently untrustworthy "provider" with trusted status. In other words they chose their petard willingly and with full knowledge and were hoisted by it. Their swinging and choking is merely the logical outcome of their own choices. You could be a good nanny and not allow folks to do stupid things -- but where would that get you? As a responsible adult it is far better to allow children to make their own foolish mistakes and suffer the consequences thereof in the hopes that they will not be so foolish the next time around. Some, however, never learn and the attempts to remedy ignorance with a clue-by-four are fruitless. When being chased by bears and wolves it is clearly advantageous to permit the feeble and slow to jolly-along so they may preferentially satiate the bears and wolves. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From cscora at apnic.net Fri Feb 22 18:03:28 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Feb 2019 04:03:28 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190222180328.8D285C55A0@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Feb, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 738085 Prefixes after maximum aggregation (per Origin AS): 285259 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 355452 Total ASes present in the Internet Routing Table: 63351 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54573 Origin ASes announcing only one prefix: 23640 Transit ASes present in the Internet Routing Table: 8778 Transit-only ASes present in the Internet Routing Table: 273 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 28 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 33 Number of instances of unregistered ASNs: 36 Number of 32-bit ASNs allocated by the RIRs: 25890 Number of 32-bit ASNs visible in the Routing Table: 21087 Prefixes from 32-bit ASNs in the Routing Table: 91866 Number of bogon 32-bit ASNs visible in the Routing Table: 24 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 266 Number of addresses announced to Internet: 2843064419 Equivalent to 169 /8s, 117 /16s and 184 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 247477 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200761 Total APNIC prefixes after maximum aggregation: 57719 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 197814 Unique aggregates announced from the APNIC address blocks: 81690 APNIC Region origin ASes present in the Internet Routing Table: 9461 APNIC Prefixes per ASN: 20.91 APNIC Region origin ASes announcing only one prefix: 2664 APNIC Region transit ASes present in the Internet Routing Table: 1406 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4462 Number of APNIC addresses announced to Internet: 769878530 Equivalent to 45 /8s, 227 /16s and 106 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 218439 Total ARIN prefixes after maximum aggregation: 103601 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 217467 Unique aggregates announced from the ARIN address blocks: 104185 ARIN Region origin ASes present in the Internet Routing Table: 18390 ARIN Prefixes per ASN: 11.83 ARIN Region origin ASes announcing only one prefix: 6858 ARIN Region transit ASes present in the Internet Routing Table: 1855 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2587 Number of ARIN addresses announced to Internet: 1079283360 Equivalent to 64 /8s, 84 /16s and 142 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 202798 Total RIPE prefixes after maximum aggregation: 96883 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 199086 Unique aggregates announced from the RIPE address blocks: 118225 RIPE Region origin ASes present in the Internet Routing Table: 25850 RIPE Prefixes per ASN: 7.70 RIPE Region origin ASes announcing only one prefix: 11486 RIPE Region transit ASes present in the Internet Routing Table: 3635 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7860 Number of RIPE addresses announced to Internet: 716922304 Equivalent to 42 /8s, 187 /16s and 93 /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-210331 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: 95402 Total LACNIC prefixes after maximum aggregation: 22763 LACNIC Deaggregation factor: 4.19 Prefixes being announced from the LACNIC address blocks: 96829 Unique aggregates announced from the LACNIC address blocks: 41885 LACNIC Region origin ASes present in the Internet Routing Table: 8110 LACNIC Prefixes per ASN: 11.94 LACNIC Region origin ASes announcing only one prefix: 2206 LACNIC Region transit ASes present in the Internet Routing Table: 1523 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5656 Number of LACNIC addresses announced to Internet: 173272832 Equivalent to 10 /8s, 83 /16s and 239 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20651 Total AfriNIC prefixes after maximum aggregation: 4271 AfriNIC Deaggregation factor: 4.84 Prefixes being announced from the AfriNIC address blocks: 26623 Unique aggregates announced from the AfriNIC address blocks: 9235 AfriNIC Region origin ASes present in the Internet Routing Table: 1247 AfriNIC Prefixes per ASN: 21.35 AfriNIC Region origin ASes announcing only one prefix: 426 AfriNIC Region transit ASes present in the Internet Routing Table: 245 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 522 Number of AfriNIC addresses announced to Internet: 103365888 Equivalent to 6 /8s, 41 /16s and 61 /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 7545 4654 542 544 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 45899 3244 1737 111 VNPT-AS-VN VNPT Corp, VN 7552 3094 1240 49 VIETEL-AS-AP Viettel Group, VN 4766 2805 11127 770 KIXS-AS-KR Korea Telecom, KR 9829 2752 1496 552 BSNL-NIB National Internet Backbone, IN 9808 2524 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2326 4906 29 CTTNET China TieTong Telecommunications 4755 2143 422 180 TATACOMM-AS TATA Communications formerl 17974 2005 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3584 1326 92 SHAW - Shaw Communications Inc., CA 11492 3517 227 602 CABLEONE - CABLE ONE, INC., US 22773 3303 2977 165 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2491 5369 1051 AMAZON-02 - Amazon.com, Inc., US 16625 2272 1261 1743 AKAMAI-AS - Akamai Technologies, Inc., 20115 2151 2744 535 CHARTER-20115 - Charter Communications, 18566 2123 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2105 349 221 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2090 5094 584 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 5650 2089 3074 1462 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5337 1626 137 UNI2-AS, ES 39891 3649 195 21 ALJAWWALSTC-AS, SA 8551 3249 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2635 550 1911 AKAMAI-ASN1, US 12389 2224 2221 637 ROSTELECOM-AS, RU 34984 2060 340 533 TELLCOM-AS, TR 9121 1679 1692 18 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 9009 1344 145 747 M247, GB 8402 1298 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5579 3330 591 Uninet S.A. de C.V., MX 10620 2745 411 1053 Telmex Colombia S.A., CO 11830 2699 384 34 Instituto Costarricense de Electricidad 6503 1508 433 54 Axtel, S.A.B. de C.V., MX 7303 1418 947 237 Telecom Argentina S.A., AR 28573 1284 2246 195 CLARO S.A., BR 6147 1269 377 28 Telefonica del Peru S.A.A., PE 3816 1022 506 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 931 144 66 Alestra, S. de R.L. de C.V., MX 13999 929 533 244 Mega Cable, S.A. 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 1226 393 21 LINKdotNET-AS, EG 37611 926 107 9 Afrihost, ZA 24835 847 636 22 RAYA-AS, EG 36992 808 1534 57 ETISALAT-MISR, EG 36903 807 406 151 MT-MPLS, MA 8452 688 1731 20 TE-AS TE-AS, EG 29571 486 70 13 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15399 428 45 11 WANANCHI-, KE 37342 420 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5579 3330 591 Uninet S.A. de C.V., MX 12479 5337 1626 137 UNI2-AS, ES 7545 4654 542 544 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3649 195 21 ALJAWWALSTC-AS, SA 6327 3584 1326 92 SHAW - Shaw Communications Inc., CA 11492 3517 227 602 CABLEONE - CABLE ONE, INC., US 22773 3303 2977 165 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3249 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 45899 3244 1737 111 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5337 5200 UNI2-AS, ES 4538 4653 4579 ERX-CERNET-BKB China Education and Research Net 7545 4654 4110 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3649 3628 ALJAWWALSTC-AS, SA 6327 3584 3492 SHAW - Shaw Communications Inc., CA 8551 3249 3204 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3303 3138 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 45899 3244 3133 VNPT-AS-VN VNPT Corp, VN 7552 3094 3045 VIETEL-AS-AP Viettel Group, VN 11492 3517 2915 CABLEONE - CABLE ONE, INC., 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 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 268721 UNALLOCATED 45.171.152.0/22 263877 rede banda larga, BR 268721 UNALLOCATED 45.171.152.0/23 263877 rede banda larga, BR 268721 UNALLOCATED 45.171.152.0/24 263877 rede banda larga, BR 268721 UNALLOCATED 45.171.153.0/24 263877 rede banda larga, BR 268721 UNALLOCATED 45.171.154.0/23 263877 rede banda larga, BR 268721 UNALLOCATED 45.171.154.0/24 263877 rede banda larga, BR 268721 UNALLOCATED 45.171.155.0/24 263877 rede banda larga, BR 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 1358592 UNALLOCATED 103.134.14.0/23 63956 COLO-AS-AP Colocation Australi Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.175.32.0/24 4508 NEUSTYLE - NeuStyle, CA 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -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:12 /9:10 /10:36 /11:100 /12:291 /13:567 /14:1134 /15:1906 /16:13369 /17:7906 /18:13896 /19:25719 /20:39953 /21:46096 /22:92157 /23:75178 /24:416835 /25:949 /26:833 /27:892 /28:27 /29:7 /30:15 /31:0 /32:197 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4216 5337 UNI2-AS, ES 6327 3358 3584 SHAW - Shaw Communications Inc., CA 39891 2946 3649 ALJAWWALSTC-AS, SA 11492 2770 3517 CABLEONE - CABLE ONE, INC., US 8551 2705 3249 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2543 3303 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2044 2699 Instituto Costarricense de Electricidad y Telec 18566 2018 2123 MEGAPATH5-US - MegaPath Corporation, US 30036 1852 2105 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2089 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1606 2:885 4:22 5:2755 6:47 7:1 8:1179 12:1859 13:313 14:1905 15:38 16:4 17:221 18:59 20:49 23:2583 24:2521 25:2 27:2560 31:2075 32:94 35:36 36:823 37:3033 38:1689 39:294 40:122 41:3139 42:739 43:2007 44:143 45:6726 46:3262 47:250 49:1343 50:1094 51:191 52:1024 54:289 55:1 56:6 57:41 58:1708 59:1064 60:494 61:2054 62:2040 63:1794 64:4986 65:2194 66:4821 67:2697 68:1161 69:3514 70:1326 71:600 72:2375 74:2755 75:512 76:547 77:1689 78:1764 79:2325 80:1710 81:1446 82:1115 83:867 84:1104 85:2164 86:553 87:1537 88:1014 89:2426 90:216 91:6573 92:1234 93:2473 94:2494 95:3246 96:921 97:346 98:940 99:206 100:86 101:1149 102:416 103:20069 104:3513 105:247 106:871 107:1761 108:697 109:3685 110:1629 111:1874 112:1395 113:1438 114:1132 115:1716 116:1697 117:1917 118:2140 119:1617 120:1048 121:1031 122:2286 123:1639 124:1448 125:1959 128:1245 129:680 130:526 131:1626 132:721 133:218 134:1050 135:240 136:555 137:707 138:2037 139:842 140:574 141:820 142:801 143:1042 144:838 145:505 146:1259 147:794 148:1690 149:782 150:779 151:1008 152:1013 153:321 154:2584 155:984 156:1689 157:907 158:670 159:1923 160:1517 161:916 162:2674 163:784 164:1133 165:1569 166:434 167:1393 168:3266 169:869 170:4010 171:557 172:1106 173:2182 174:1012 175:880 176:2314 177:4012 178:2542 179:1347 180:2104 181:2430 182:2674 183:1090 184:1164 185:14787 186:3741 187:2403 188:2890 189:1956 190:8346 191:1455 192:10044 193:6583 194:5376 195:4055 196:3001 197:1649 198:5786 199:5967 200:7174 201:5069 202:10185 203:10184 204:4612 205:2991 206:3237 207:3294 208:3967 209:4234 210:3931 211:1990 212:3055 213:2891 214:1076 215:52 216:5970 217:2195 218:916 219:579 220:1857 221:996 222:993 223:1444 End of report From gtaylor at tnetconsulting.net Fri Feb 22 18:10:43 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 22 Feb 2019 11:10:43 -0700 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <68D38BD0-6F18-4260-ABDD-6B5331D1D921@istaff.org> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> <4DCC699B-A85E-40FE-9044-4399C2FD4AE6@istaff.org> <570ce331-be30-081c-e1e2-ebc7d467f062@meetinghouse.net> <68D38BD0-6F18-4260-ABDD-6B5331D1D921@istaff.org> Message-ID: On 02/22/2019 09:28 AM, John Curran wrote: > If you (or your email service provider) deploy an optional solution > (e.g. DMARC p=reject) that prevents you from receiving email from mailing > lists sending in conformance with existing standards, then that’s > your choice. From the perspective of inbound email (as that sounds like the focus of your statement) I would want my email server / service to use all current standards. If the current standards are to employ DMARC filtering, then I would expect my email server / service provider to do so. In some ways, I view DMARC as the latest in the line evolving standards; DKIM, SPF, reverse DNS. Each of which have been controversial on their own. I also believe in actually honoring what domain owners publish. I believe that actually rejecting with SPF's "-all" and DMARC's "p=reject". I say this because I want to provide — hopefully gentle — push back against / feedback to the publisher for them to fix their problems. Even if you don't reject despite domain owner's indication of the preference, I think you should use that signal in the rest of your hygiene filters. I also believe that mailing lists need to evolve with the times to support the current standards. IMHO they don't get a pass because they are mailing lists and have always worked that way. > One doesn’t communicate with folks who chose (or let their service > provider chose) not to receive email accordingly existing standards. Industry standards change, and senders need to keep up with the times. What those standards are and how appropriate they are is independent. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From john at essenz.com Fri Feb 22 18:14:40 2019 From: john at essenz.com (John Von Essen) Date: Fri, 22 Feb 2019 13:14:40 -0500 Subject: Cogent v6 Blackhole server issues??? Message-ID: 2 days ago my IPv6 BGP session to Cogent's Blackhole server went down (2001:550:0:1000::421C:802), I've spent all morning emailing their NOC and I'm getting nowhere. Anyone else seeing this? Im in the Phila Metro area. -John From dmburgess at linktechs.net Fri Feb 22 18:18:02 2019 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 22 Feb 2019 18:18:02 +0000 Subject: Cogent v6 Blackhole server issues??? In-Reply-To: References: Message-ID: Out of St. Louis, mine has been up since the last reboot of my router. 2001:550:0:1000::421c:802 is my peering.. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition” Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270  Website: http://www.linktechs.net Create Wireless Coverage’s with www.towercoverage.com -----Original Message----- From: NANOG On Behalf Of John Von Essen Sent: Friday, February 22, 2019 12:15 PM To: nanog at nanog.org Subject: Cogent v6 Blackhole server issues??? 2 days ago my IPv6 BGP session to Cogent's Blackhole server went down (2001:550:0:1000::421C:802), I've spent all morning emailing their NOC and I'm getting nowhere. Anyone else seeing this? Im in the Phila Metro area. -John From john at essenz.com Fri Feb 22 18:52:42 2019 From: john at essenz.com (John Von Essen) Date: Fri, 22 Feb 2019 13:52:42 -0500 Subject: Cogent v6 Blackhole server issues??? In-Reply-To: References: Message-ID: Looks like they finally fixed it.. it just sporadically came back up. My v4 and v6 transit sessions were never effected. Who knows... -John On 2/22/19 1:18 PM, Dennis Burgess via NANOG wrote: > Out of St. Louis, mine has been up since the last reboot of my router. > > 2001:550:0:1000::421c:802 is my peering.. > > > > > > Dennis Burgess, Mikrotik Certified Trainer > Author of "Learn RouterOS- Second Edition” > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270  Website: http://www.linktechs.net > Create Wireless Coverage’s with www.towercoverage.com > > -----Original Message----- > From: NANOG On Behalf Of John Von Essen > Sent: Friday, February 22, 2019 12:15 PM > To: nanog at nanog.org > Subject: Cogent v6 Blackhole server issues??? > > 2 days ago my IPv6 BGP session to Cogent's Blackhole server went down (2001:550:0:1000::421C:802), I've spent all morning emailing their NOC and I'm getting nowhere. Anyone else seeing this? Im in the Phila Metro area. > > -John > > > > > From bzs at theworld.com Fri Feb 22 19:27:35 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 22 Feb 2019 14:27:35 -0500 Subject: sendmail.cf In-Reply-To: <871s40jgno.fsf@miraculix.mork.no> References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <1c43b26b-64df-3eeb-59cb-4ae5762f6dfb@2mbit.com> <23663.22894.637849.525720@gargle.gargle.HOWL> <871s40jgno.fsf@miraculix.mork.no> Message-ID: <23664.19751.464246.191628@gargle.gargle.HOWL> On February 22, 2019 at 10:50 bjorn at mork.no (Bjørn Mork) wrote: > bzs at theworld.com writes: > > > The predecessor to sendmail was delivermail, 1979, also written by > > Eric Allman. > > > > https://en.wikipedia.org/wiki/Delivermail > > Damn. Now you made me read RFC801 and wonder why we didn't have an > updated version for the IPv6 transition. Or: Where would the Internet > have been today without that very explicit "complete switch over" goal? Not sure what you mean but reasonably late-model sendmail works with IPv6, it's a compile option which is on by default. Or do you mean the NCP->TCP transition? The internet was a lot smaller and one could actually get all the ducks in a line back then. And almost everyone (if not everyone) was connected via IMPs rather than CPE routers and the IMPs were more or less centrally managed or if you managed one you accepted responsibility to work in concert with the others. I don't know the high-water mark for the number of IMPs or more specifically how many existed on the NCP->TCP flag day but I'm pretty sure the theoretical maximum was 256 tho no doubt someone had a way to extend that. But, w/o extensive changes, 256, probably 254, not sure 0 or 255 could be an IMP number, whatever! Largely because your IMP was identified by the last octet of an IP address (I think that's right) so Boston University was 10.4.0.44 which meant port 4 on IMP 44 (which sat at MIT on the 9th floor of 545 tech square.) Of course to speak to the net via your IMP connection your computer(s) also had to switch over to TCP. But, again, these were usually just one or a few big machines per site likely all in the same room or same administration group anyhow. Life was much simpler back then. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Fri Feb 22 19:41:18 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 22 Feb 2019 14:41:18 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> Message-ID: <23664.20574.107138.576736@gargle.gargle.HOWL> I'm sure some will react to this viscerally but I'd argue that a large chunk of the spam issue is an operational issue due to factors like: 1. Volume, bandwidth 2. Spammers' address block hijacking and other misuse of resources 3. Revenge (typically DDoS) attacks by spammers 4. General operational, related to #1, but for example how spam stresses capex. No doubt some others. But when someone says to me spam isn't much of a problem because it's mostly blocked by local filtering (i.e., they don't see much spam in their inbox), usually in an attempt to shut down any discussion entirely, I know I'm hearing from someone who hasn't a clue what problems it causes operationally. That's not to argue for opening the floodgates on spam mitigation on nanog. Only that it's not necessarily off-topic depending on the aspect raised. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From list at satchell.net Fri Feb 22 19:47:40 2019 From: list at satchell.net (Stephen Satchell) Date: Fri, 22 Feb 2019 11:47:40 -0800 Subject: sendmail.cf In-Reply-To: <23664.19751.464246.191628@gargle.gargle.HOWL> References: <74532ca0-af46-58d1-95d5-cb9fbc9de0f7@2mbit.com> <1c43b26b-64df-3eeb-59cb-4ae5762f6dfb@2mbit.com> <23663.22894.637849.525720@gargle.gargle.HOWL> <871s40jgno.fsf@miraculix.mork.no> <23664.19751.464246.191628@gargle.gargle.HOWL> Message-ID: <002123e8-8547-77b3-fdc6-1baee8b4f4d1@satchell.net> On 2/22/19 11:27 AM, bzs at theworld.com wrote: > I don't know the high-water mark for the number of IMPs or more > specifically how many existed on the NCP->TCP flag day but I'm pretty > sure the theoretical maximum was 256 tho no doubt someone had a way to > extend that. But, w/o extensive changes, 256, probably 254, not sure 0 > or 255 could be an IMP number, whatever! There was no node 0 or 255. So the number of nodes was capped at 254. For each node, there were subnodes so that multiple computers at each location could be addressed. It wasn't a full 8-bit field. From bill at herrin.us Fri Feb 22 22:05:07 2019 From: bill at herrin.us (William Herrin) Date: Fri, 22 Feb 2019 14:05:07 -0800 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <23664.20574.107138.576736@gargle.gargle.HOWL> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> <23664.20574.107138.576736@gargle.gargle.HOWL> Message-ID: On Fri, Feb 22, 2019 at 11:42 AM wrote: > But when someone says to me spam isn't much of a problem because it's > mostly blocked by local filtering (i.e., they don't see much spam in > their inbox), usually in an attempt to shut down any discussion > entirely, I know I'm hearing from someone who hasn't a clue what > problems it causes operationally. Hear hear. 99% of the email reaching my server is spam. That means I need 100 times the server capacity to process mail than I would need without spam. 100 times. Two orders of magnitude. I defy anyone to tell me that's not an operational issue. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bzs at theworld.com Fri Feb 22 22:29:56 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 22 Feb 2019 17:29:56 -0500 Subject: A Zero Spam Mail System [Feedback Request] In-Reply-To: <68D38BD0-6F18-4260-ABDD-6B5331D1D921@istaff.org> References: <1478B373-A6AC-49DC-B9DD-F7AA3A4F71E7@istaff.org> <13de24ae-df2a-0756-5aeb-5be97fdb2d2d@meetinghouse.net> <4DCC699B-A85E-40FE-9044-4399C2FD4AE6@istaff.org> <570ce331-be30-081c-e1e2-ebc7d467f062@meetinghouse.net> <68D38BD0-6F18-4260-ABDD-6B5331D1D921@istaff.org> Message-ID: <23664.30692.583139.446534@gargle.gargle.HOWL> I don't think there's anything wrong with sounding out some ideas if they arose from careful thought and sufficient experience and subject knowledge. Just saying call us when you've got a unicorn in hand is a brush-off. But one has to find the right venue for such brainstorming which I think is the real problem here. And of course being willing to be shot down and just go back to the drawing board if one ever really got so far as a "drawing board". I'll admit this dombox thing has gotten that far even if some were dissatisfied with the "drawings", clearly a lot of work has gone into the idea. But venue might be everything. A very large list oriented towards operational issues is probably not the right venue unless one really believes most everyone will see the brilliance of a solution after reading a short paragraph and perhaps even want to help or at least become motivated to read further. And if you don't get that then, well, time for some introspection. Quite a few of us, myself included, did go and read at least enough of the long whitepaper to respond with a lot more in specifics than "call us when you have your unicorn". -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bortzmeyer at nic.fr Sat Feb 23 17:02:33 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 23 Feb 2019 18:02:33 +0100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking Attacks Message-ID: <20190223170233.ovt7mpb62sn6h34k@sources.org> Very good article, very detailed, with a lot of technical precisions, about the recent domain name hijackings (not using the DNS, just good old hijackings at registrar or hoster). https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ From kmedcalf at dessus.com Sat Feb 23 19:13:41 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 23 Feb 2019 12:13:41 -0700 Subject: A Deep Dive on the Recent Widespread DNS Hijacking Attacks In-Reply-To: <20190223170233.ovt7mpb62sn6h34k@sources.org> Message-ID: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: >Very good article, very detailed, with a lot of technical precisions, >about the recent domain name hijackings (not using the DNS, just good >old hijackings at registrar or hoster). >https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ So in other words this was just an old school script kiddie taking advantage of DNS registrars, the only difference being this was a whole whack of script kiddies acting in concert directed by a not-quite-so-stupid script kiddie, with some "modernz" thrown in for good measure. (Sounds like an NSA operation to me -- and the targets perfectly match those that the NSA would choose -- plus some good old misdirection just for the jollies of it) The second takeaway being that DNSSEC is useless in preventing such an occurrence because the script kiddies can merely turn it off at the same time as they redirect DNS. However, having DNSSEC can protect you from incompetent script-kiddies. It can also give you a false sense of security. Did I miss anything? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From woody at pch.net Sat Feb 23 19:29:20 2019 From: woody at pch.net (Bill Woodcock) Date: Sat, 23 Feb 2019 11:29:20 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking Attacks In-Reply-To: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> References: <6e31d305aee69c4d85116e6a81d0c91d@mail.dessus.com> Message-ID: <486349D6-F57F-4324-B603-3818E6ACDC1A@pch.net> > On Feb 23, 2019, at 11:13 AM, Keith Medcalf wrote: > > So in other words this was just an old school script kiddie taking advantage of DNS registrars, the only difference being this was a whole whack of script kiddies acting in concert directed by a not-quite-so-stupid script kiddie, with some "modernz" thrown in for good measure. It’s Iranian military. If you want to call them script kiddies, that’s up to you, but people familiar with the campaign characterize it as an APT, and have been for the several years that it’s been going on. > the targets perfectly match those that the NSA would choose Amusing bedfellows, if they weren’t so annoying. > The second takeaway being that DNSSEC is useless You seem to have gotten that one backwards, by over-straining yourself in an effort to seem clever. > Did I miss anything? Apparently, yes. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From dougm at nist.gov Sun Feb 24 22:38:07 2019 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Sun, 24 Feb 2019 22:38:07 +0000 Subject: A Deep Dive on the Recent Widespread DNS Hijacking Message-ID: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> You might have missed reading the very article you cite. "Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. .... Aside from that, DNSSEC saved us from being really, thoroughly owned.” Or maybe ACME .. https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-11.2 "It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.” I am not sure how many of the domains listed as being hijacked are DNSSEC signed, but it seems if they were, and had a reasonable long TTL on a DS record at their parent, many if not most of these could have been prevented/detected. ICANN seems to think that is the case: ICANN Calls for Full DNSSEC Deployment https://www.icann.org/news/announcement-2019-02-22-en Of course, DNSSEC is often blamed for not protecting those who did not deploy/use it. Not sure what can be said about that line of reasoning. Dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST ============ Date: Sat, 23 Feb 2019 12:13:41 -0700 From: "Keith Medcalf" To: "nanog at nanog.org" Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking Attacks Message-ID: <6e31d305aee69c4d85116e6a81d0c91d at mail.dessus.com> Content-Type: text/plain; charset="us-ascii" On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: >Very good article, very detailed, with a lot of technical precisions, >about the recent domain name hijackings (not using the DNS, just good >old hijackings at registrar or hoster). >https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ So in other words this was just an old school script kiddie taking advantage of DNS registrars, the only difference being this was a whole whack of script kiddies acting in concert directed by a not-quite-so-stupid script kiddie, with some "modernz" thrown in for good measure. (Sounds like an NSA operation to me -- and the targets perfectly match those that the NSA would choose -- plus some good old misdirection just for the jollies of it) The second takeaway being that DNSSEC is useless in preventing such an occurrence because the script kiddies can merely turn it off at the same time as they redirect DNS. However, having DNSSEC can protect you from incompetent script-kiddies. It can also give you a false sense of security. Did I miss anything? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From kmedcalf at dessus.com Mon Feb 25 01:51:51 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 24 Feb 2019 18:51:51 -0700 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> Message-ID: Obviously none of y'all read the report. Here is the relevant quote: """" DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region. Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC. However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers. Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic. “Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """ If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: Montgomery, Douglas (Fed) [mailto:dougm at nist.gov] >Sent: Sunday, 24 February, 2019 15:38 >To: nanog at nanog.org >Cc: kmedcalf at dessus.com >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > >You might have missed reading the very article you cite. > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked >that attack, but that it managed to snare email credentials for two >employees who were traveling at the time. >.... >Aside from that, DNSSEC saved us from being really, thoroughly >owned.” > > > >Or maybe ACME .. https://tools.ietf.org/html/draft-ietf-acme-acme- >12#section-11.2 > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries >via DNSSEC-validating stub or recursive resolvers. This provides >additional protection to domains which choose to make use of DNSSEC.” > >I am not sure how many of the domains listed as being hijacked are >DNSSEC signed, but it seems if they were, and had a reasonable long >TTL on a DS record at their parent, many if not most of these could >have been prevented/detected. > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC >Deployment >https://www.icann.org/news/announcement-2019-02-22-en > >Of course, DNSSEC is often blamed for not protecting those who did >not deploy/use it. Not sure what can be said about that line of >reasoning. > >Dougm >-- >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > >============ > Date: Sat, 23 Feb 2019 12:13:41 -0700 > From: "Keith Medcalf" > To: "nanog at nanog.org" > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > Attacks > Message-ID: <6e31d305aee69c4d85116e6a81d0c91d at mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > >Very good article, very detailed, with a lot of technical >precisions, > >about the recent domain name hijackings (not using the DNS, just >good > >old hijackings at registrar or hoster). > > >https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent- >widespread-dns-hijacking-attacks/ > > So in other words this was just an old school script kiddie >taking advantage of DNS registrars, the only difference being this >was a whole whack of script kiddies acting in concert directed by a >not-quite-so-stupid script kiddie, with some "modernz" thrown in for >good measure. (Sounds like an NSA operation to me -- and the targets >perfectly match those that the NSA would choose -- plus some good old >misdirection just for the jollies of it) > > The second takeaway being that DNSSEC is useless in preventing >such an occurrence because the script kiddies can merely turn it off >at the same time as they redirect DNS. However, having DNSSEC can >protect you from incompetent script-kiddies. It can also give you a >false sense of security. > > Did I miss anything? > > --- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > > From dougm at nist.gov Mon Feb 25 03:41:46 2019 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Mon, 25 Feb 2019 03:41:46 +0000 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> Message-ID: Keith, You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS. If that makes DNSSEC irrelevant in this specific scenario is in the eye of the beholder I guess. I agree in that specific scenario it is not preventative. In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? Hopefully folks who deploy DNSSEC signed zones test validation on their domains on a regular basis, and I would hope that a CA issuing DV CERTS would do DNSSEC validation on signed zones in their DNS challenges. Given that this is only one vector for attacks of a similar style, it seems like locking down the underlying infrastructure is still a good idea. The paper below mentioned in a NANOG talk last week gives food for thought. Bamboozling Certificate Authorities with BGP https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee dougm -- DougM at NIST On 2/24/19, 8:52 PM, "Keith Medcalf" wrote: Obviously none of y'all read the report. Here is the relevant quote: """" DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region. Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC. However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers. Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic. “Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """ If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: Montgomery, Douglas (Fed) [mailto:dougm at nist.gov] >Sent: Sunday, 24 February, 2019 15:38 >To: nanog at nanog.org >Cc: kmedcalf at dessus.com >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > >You might have missed reading the very article you cite. > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked >that attack, but that it managed to snare email credentials for two >employees who were traveling at the time. >.... >Aside from that, DNSSEC saved us from being really, thoroughly >owned.” > > > >Or maybe ACME .. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-acme-acme-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&reserved=0 >12#section-11.2 > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries >via DNSSEC-validating stub or recursive resolvers. This provides >additional protection to domains which choose to make use of DNSSEC.” > >I am not sure how many of the domains listed as being hijacked are >DNSSEC signed, but it seems if they were, and had a reasonable long >TTL on a DS record at their parent, many if not most of these could >have been prevented/detected. > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC >Deployment >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fnews%2Fannouncement-2019-02-22-en&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&reserved=0 > >Of course, DNSSEC is often blamed for not protecting those who did >not deploy/use it. Not sure what can be said about that line of >reasoning. > >Dougm >-- >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > >============ > Date: Sat, 23 Feb 2019 12:13:41 -0700 > From: "Keith Medcalf" > To: "nanog at nanog.org" > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > Attacks > Message-ID: <6e31d305aee69c4d85116e6a81d0c91d at mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > >Very good article, very detailed, with a lot of technical >precisions, > >about the recent domain name hijackings (not using the DNS, just >good > >old hijackings at registrar or hoster). > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&reserved=0 >widespread-dns-hijacking-attacks/ > > So in other words this was just an old school script kiddie >taking advantage of DNS registrars, the only difference being this >was a whole whack of script kiddies acting in concert directed by a >not-quite-so-stupid script kiddie, with some "modernz" thrown in for >good measure. (Sounds like an NSA operation to me -- and the targets >perfectly match those that the NSA would choose -- plus some good old >misdirection just for the jollies of it) > > The second takeaway being that DNSSEC is useless in preventing >such an occurrence because the script kiddies can merely turn it off >at the same time as they redirect DNS. However, having DNSSEC can >protect you from incompetent script-kiddies. It can also give you a >false sense of security. > > Did I miss anything? > > --- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > > From cb.list6 at gmail.com Mon Feb 25 04:06:09 2019 From: cb.list6 at gmail.com (Ca By) Date: Sun, 24 Feb 2019 20:06:09 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> Message-ID: I just checked Bing.com Google.com Amazon.com Facebook.com Netflix.com Twitter.com Chase.com Coinbase.com None of them have dnssec signed domains. They are smart. They make money on the web. And they have, likely consciously, made a cost / benefit risk driven evaluation of dnssec that it is not worth using. More specifically, their inaction implies dnssec is more risk than benefit, which i agree with. Those FANG companies have the resources to lead the way, but if they are balkiing .... it’s a tall order to ask the rest of us (we have to buy our own lunch crowd) to jump in the pool. But, icann is rationally raising the “never waste a good outage” to advance your tired agenda. CB On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) wrote: > Keith, > > You are right, if you can compromise a registrar that permits DNSSEC to be > disabled (without notification/confirmation to POCs etc), then you only > have a limited period (max of DS TTL) of protection for those resolvers > that have already cached the DS. > > If that makes DNSSEC irrelevant in this specific scenario is in the eye of > the beholder I guess. I agree in that specific scenario it is not > preventative. > > In the 3rd attack noted below, do we know if the CA that issued the DV > CERTS does DNSSEC validation on its DNS challenge queries? > > Hopefully folks who deploy DNSSEC signed zones test validation on their > domains on a regular basis, and I would hope that a CA issuing DV CERTS > would do DNSSEC validation on signed zones in their DNS challenges. > > Given that this is only one vector for attacks of a similar style, it > seems like locking down the underlying infrastructure is still a good idea. > > The paper below mentioned in a NANOG talk last week gives food for thought. > > Bamboozling Certificate Authorities with BGP > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > > dougm > -- > DougM at NIST > > > On 2/24/19, 8:52 PM, "Keith Medcalf" wrote: > > > Obviously none of y'all read the report. Here is the relevant quote: > > """" > DNSSEC protects applications from using forged or manipulated DNS > data, by requiring that all DNS queries for a given domain or set of > domains be digitally signed. In DNSSEC, if a name server determines that > the address record for a given domain has not been modified in transit, it > resolves the domain and lets the user visit the site. If, however, that > record has been modified in some way or doesn’t match the domain requested, > the name server blocks the user from reaching the fraudulent address. > > While DNSSEC can be an effective tool for mitigating attacks such as > those launched by DNSpionage, only about 20 percent of the world’s major > networks and Web sites have enabled it, according to measurements gathered > by APNIC, the regional Internet address registry for the Asia-Pacific > region. > > Jogbäck said Netnod’s infrastructure suffered three separate attacks > from the DNSpionage attackers. The first two occurred in a two-week window > between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that > were not protected by DNSSEC. > > However, he said the third attack between Dec. 29 and Jan. 2 targeted > Netnod infrastructure that was protected by DNSSEC and serving its own > internal email network. Yet, because the attackers already had access to > its registrar’s systems, they were able to briefly disable that safeguard — > or at least long enough to obtain SSL certificates for two of Netnod’s > email servers. > > Jogbäck told KrebsOnSecurity that once the attackers had those > certificates, they re-enabled DNSSEC for the company’s targeted servers > while apparently preparing to launch the second stage of the attack — > diverting traffic flowing through its mail servers to machines the > attackers controlled. But Jogbäck said that for whatever reason, the > attackers neglected to use their unauthorized access to its registrar to > disable DNSSEC before later attempting to siphon Internet traffic. > > “Luckily for us, they forgot to remove that when they launched their > man-in-the-middle attack,” he said. “If they had been more skilled they > would have removed DNSSEC on the domain, which they could have done.” > """ > > If you manage to get access to the change the dns delegation at the > parent you can also turn DNSSEC off. Clearly the scripties managed to do > this once but "forgot" to do it the second time around ... That they also > "forgot" to disable DNSSEC on PCH is not particularly relevant. It only > goes to prove my point that DNSSEC is irrelevant and only gives a false > sense of security (for this particular attack vector). I suppose you could > have really long timeouts on your DS records, but that would merely > "complicate" matters for the scripties and would not be protective ... > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven > says a lot about anticipated traffic volume. > > >-----Original Message----- > >From: Montgomery, Douglas (Fed) [mailto:dougm at nist.gov] > >Sent: Sunday, 24 February, 2019 15:38 > >To: nanog at nanog.org > >Cc: kmedcalf at dessus.com > >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > > >You might have missed reading the very article you cite. > > > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked > >that attack, but that it managed to snare email credentials for two > >employees who were traveling at the time. > >.... > >Aside from that, DNSSEC saved us from being really, thoroughly > >owned.” > > > > > > > >Or maybe ACME .. > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-acme-acme-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&reserved=0 > >12#section-11.2 > > > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries > >via DNSSEC-validating stub or recursive resolvers. This provides > >additional protection to domains which choose to make use of DNSSEC.” > > > >I am not sure how many of the domains listed as being hijacked are > >DNSSEC signed, but it seems if they were, and had a reasonable long > >TTL on a DS record at their parent, many if not most of these could > >have been prevented/detected. > > > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC > >Deployment > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fnews%2Fannouncement-2019-02-22-en&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&reserved=0 > > > >Of course, DNSSEC is often blamed for not protecting those who did > >not deploy/use it. Not sure what can be said about that line of > >reasoning. > > > >Dougm > >-- > >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > > > > > >============ > > Date: Sat, 23 Feb 2019 12:13:41 -0700 > > From: "Keith Medcalf" > > To: "nanog at nanog.org" > > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > Attacks > > Message-ID: <6e31d305aee69c4d85116e6a81d0c91d at mail.dessus.com> > > Content-Type: text/plain; charset="us-ascii" > > > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > > > >Very good article, very detailed, with a lot of technical > >precisions, > > >about the recent domain name hijackings (not using the DNS, just > >good > > >old hijackings at registrar or hoster). > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&reserved=0 > >widespread-dns-hijacking-attacks/ > > > > So in other words this was just an old school script kiddie > >taking advantage of DNS registrars, the only difference being this > >was a whole whack of script kiddies acting in concert directed by a > >not-quite-so-stupid script kiddie, with some "modernz" thrown in for > >good measure. (Sounds like an NSA operation to me -- and the targets > >perfectly match those that the NSA would choose -- plus some good old > >misdirection just for the jollies of it) > > > > The second takeaway being that DNSSEC is useless in preventing > >such an occurrence because the script kiddies can merely turn it off > >at the same time as they redirect DNS. However, having DNSSEC can > >protect you from incompetent script-kiddies. It can also give you a > >false sense of security. > > > > Did I miss anything? > > > > --- > > The fact that there's a Highway to Hell but only a Stairway to > >Heaven says a lot about anticipated traffic volume. > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at iecc.com Mon Feb 25 04:29:45 2019 From: johnl at iecc.com (John Levine) Date: 24 Feb 2019 23:29:45 -0500 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: Message-ID: <20190225042945.909B2200EA8313@ary.local> In article you write: >You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs >etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS. As far as I can tell, that's roughly all of them. If you have the credentials to log in and change the NS, you can change or remove the DS, too. As someone else noted, the only reason DNSSEC made any difference was that the script kiddies sometimes forgot to turn it off or install their own DS. If you are actually interested in preventing this stuff, 2FA will be orders of magnitude more effective than messing with DNSSEC. There are certainly threats that DNSSEC addresses, but getting your registrar account pwned isn't one of them. R's, John From ximaera at gmail.com Mon Feb 25 04:42:59 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 25 Feb 2019 13:42:59 +0900 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190225042945.909B2200EA8313@ary.local> References: <20190225042945.909B2200EA8313@ary.local> Message-ID: On Mon, Feb 25, 2019, 1:30 PM John Levine wrote: > > You are right, if you can compromise a registrar that permits DNSSEC to > be disabled (without notification/confirmation to POCs > > etc), then you only have a limited period (max of DS TTL) of protection > for those resolvers that have already cached the DS. > > As far as I can tell, that's roughly all of them. If you have the > credentials to log in and change the NS, you can change or remove the > DS, too. > And, that wouldn't change in the nearest future, because the concept of "hostile pinning" as it was present with HTTPS Public Key Pinning could also be ported to DNSSEC this way. "Hostile signing"... doesn't that sound scary. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Mon Feb 25 04:48:19 2019 From: marka at isc.org (Mark Andrews) Date: Mon, 25 Feb 2019 15:48:19 +1100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> Message-ID: <40C2003C-7D0B-47C3-ADD2-630F0B22C8D2@isc.org> Google has been validating on 8.8.8.8 for years now though they only properly enabled EDNS for Google.com on Jan 10, 2019. Prior to that you needed to include a EDNS ECS option to get a EDNS response. They also DNSSEC sign some of their zones. https://developers.google.com/speed/public-dns/faq > On 25 Feb 2019, at 3:06 pm, Ca By wrote: > > I just checked > > Bing.com > Google.com > Amazon.com > Facebook.com > Netflix.com > Twitter.com > Chase.com > Coinbase.com > > None of them have dnssec signed domains. > > They are smart. They make money on the web. And they have, likely consciously, made a cost / benefit risk driven evaluation of dnssec that it is not worth using. More specifically, their inaction implies dnssec is more risk than benefit, which i agree with. > > Those FANG companies have the resources to lead the way, but if they are balkiing .... it’s a tall order to ask the rest of us (we have to buy our own lunch crowd) to jump in the pool. > > But, icann is rationally raising the “never waste a good outage” to advance your tired agenda. > > CB > > > > On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) wrote: > Keith, > > You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS. > > If that makes DNSSEC irrelevant in this specific scenario is in the eye of the beholder I guess. I agree in that specific scenario it is not preventative. > > In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? > > Hopefully folks who deploy DNSSEC signed zones test validation on their domains on a regular basis, and I would hope that a CA issuing DV CERTS would do DNSSEC validation on signed zones in their DNS challenges. > > Given that this is only one vector for attacks of a similar style, it seems like locking down the underlying infrastructure is still a good idea. > > The paper below mentioned in a NANOG talk last week gives food for thought. > > Bamboozling Certificate Authorities with BGP > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > > dougm > -- > DougM at NIST > > > On 2/24/19, 8:52 PM, "Keith Medcalf" wrote: > > > Obviously none of y'all read the report. Here is the relevant quote: > > """" > DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. > > While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region. > > Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC. > > However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers. > > Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic. > > “Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” > """ > > If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ... > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > >-----Original Message----- > >From: Montgomery, Douglas (Fed) [mailto:dougm at nist.gov] > >Sent: Sunday, 24 February, 2019 15:38 > >To: nanog at nanog.org > >Cc: kmedcalf at dessus.com > >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > > >You might have missed reading the very article you cite. > > > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked > >that attack, but that it managed to snare email credentials for two > >employees who were traveling at the time. > >.... > >Aside from that, DNSSEC saved us from being really, thoroughly > >owned.” > > > > > > > >Or maybe ACME .. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-acme-acme-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&reserved=0 > >12#section-11.2 > > > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries > >via DNSSEC-validating stub or recursive resolvers. This provides > >additional protection to domains which choose to make use of DNSSEC.” > > > >I am not sure how many of the domains listed as being hijacked are > >DNSSEC signed, but it seems if they were, and had a reasonable long > >TTL on a DS record at their parent, many if not most of these could > >have been prevented/detected. > > > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC > >Deployment > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fnews%2Fannouncement-2019-02-22-en&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&reserved=0 > > > >Of course, DNSSEC is often blamed for not protecting those who did > >not deploy/use it. Not sure what can be said about that line of > >reasoning. > > > >Dougm > >-- > >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > > > > > >============ > > Date: Sat, 23 Feb 2019 12:13:41 -0700 > > From: "Keith Medcalf" > > To: "nanog at nanog.org" > > Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > Attacks > > Message-ID: <6e31d305aee69c4d85116e6a81d0c91d at mail.dessus.com> > > Content-Type: text/plain; charset="us-ascii" > > > > On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > > > >Very good article, very detailed, with a lot of technical > >precisions, > > >about the recent domain name hijackings (not using the DNS, just > >good > > >old hijackings at registrar or hoster). > > > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&reserved=0 > >widespread-dns-hijacking-attacks/ > > > > So in other words this was just an old school script kiddie > >taking advantage of DNS registrars, the only difference being this > >was a whole whack of script kiddies acting in concert directed by a > >not-quite-so-stupid script kiddie, with some "modernz" thrown in for > >good measure. (Sounds like an NSA operation to me -- and the targets > >perfectly match those that the NSA would choose -- plus some good old > >misdirection just for the jollies of it) > > > > The second takeaway being that DNSSEC is useless in preventing > >such an occurrence because the script kiddies can merely turn it off > >at the same time as they redirect DNS. However, having DNSSEC can > >protect you from incompetent script-kiddies. It can also give you a > >false sense of security. > > > > Did I miss anything? > > > > --- > > The fact that there's a Highway to Hell but only a Stairway to > >Heaven says a lot about anticipated traffic volume. > > > > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From woody at pch.net Mon Feb 25 05:20:59 2019 From: woody at pch.net (Bill Woodcock) Date: Sun, 24 Feb 2019 21:20:59 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> Message-ID: > On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) wrote: > In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From woody at pch.net Mon Feb 25 05:34:42 2019 From: woody at pch.net (Bill Woodcock) Date: Sun, 24 Feb 2019 21:34:42 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: Message-ID: > On Feb 24, 2019, at 5:51 PM, Keith Medcalf wrote: > > That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). For those watching from the sidelines, This guy is perfectly encapsulating one of the arguments that seem to pop up in the wake of attacks: “What actually happened is irrelevant, because I can imagine other things that could hypothetically have happened, but didn’t, which would have reinforced my view of the world.” I can’t say that I understand the psychology behind people thinking this way, but as we’re choosing to be transparent about our experience for the benefit of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is far from alone (not about DNSSEC specifically, but apparently attacks bring people with all manner of chips on their shoulders out of the woodwork). It’s a particularly self-defeating logical fallacy, so being aware of it is the first step to recognizing it and avoiding it. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From hank at efes.iucc.ac.il Mon Feb 25 06:03:50 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 25 Feb 2019 08:03:50 +0200 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> Message-ID: <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> On 25/02/2019 07:20, Bill Woodcock wrote: >> On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) wrote: >> In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? > We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo. > > -Bill Bill, Did you have a CAA record defined and if not, why not? -Hank From marka at isc.org Mon Feb 25 06:04:39 2019 From: marka at isc.org (Mark Andrews) Date: Mon, 25 Feb 2019 17:04:39 +1100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: Message-ID: <5ADEA327-C590-4360-BC00-B7FD155E7ACD@isc.org> > On 25 Feb 2019, at 4:34 pm, Bill Woodcock wrote: > > > >> On Feb 24, 2019, at 5:51 PM, Keith Medcalf wrote: >> >> That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). > > For those watching from the sidelines, This guy is perfectly encapsulating one of the arguments that seem to pop up in the wake of attacks: “What actually happened is irrelevant, because I can imagine other things that could hypothetically have happened, but didn’t, which would have reinforced my view of the world.” > > I can’t say that I understand the psychology behind people thinking this way, but as we’re choosing to be transparent about our experience for the benefit of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is far from alone (not about DNSSEC specifically, but apparently attacks bring people with all manner of chips on their shoulders out of the woodwork). It’s a particularly self-defeating logical fallacy, so being aware of it is the first step to recognizing it and avoiding it. > > -Bill I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones. This isolates the organisation’s equipment from the parent zone’s management practices. I would also note that you can configure validating resolvers to expect secure responses for parts of the namespace and to reject insecure responses even when they validate as insecure. An organisation can also deploy DLV for their own zones using their own registry. While the current code DLV validating code is only invoked when the response validates as insecure, there is nothing preventing a policy which says that DLV trumps or must also validate for entries in a registry. At this stage is would be a minor code change to add such policy knobs. DLV is a just a in-band way of distributing trust anchors. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mansaxel at besserwisser.org Mon Feb 25 08:07:01 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 25 Feb 2019 09:07:01 +0100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <5ADEA327-C590-4360-BC00-B7FD155E7ACD@isc.org> References: <5ADEA327-C590-4360-BC00-B7FD155E7ACD@isc.org> Message-ID: <20190225080701.GL19240@besserwisser.org> Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking Date: Mon, Feb 25, 2019 at 05:04:39PM +1100 Quoting Mark Andrews (marka at isc.org): > I would also note that a organisation can deploy RFC 5011 for their own > zones and have their own equipment use DNSKEYs managed > using RFC 5011 for their own zones. This isolates the organisation’s > equipment from the parent zone’s management practices. > > I would also note that you can configure validating resolvers to expect > secure responses for parts of the namespace and to reject > insecure responses even when they validate as insecure. One thing that immediately struck me upon reading the Krebs post was that people got owned by having to downgrade the end-to-end model of the Internet into Proxy-land. A hotel wifi. Probably only challenged by "Free Wifi" in other spaces in its ability to demolish the Internet as thought out and envisioned. We can conclude in two different directions here; * We need to work on making the Internet more transparent to applications, and thus increasing security. * We're all doomed anyway. DNSSEC is useless. Pick whichever you like. Our children will judge us. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 My EARS are GONE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ask at develooper.com Mon Feb 25 09:37:45 2019 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Mon, 25 Feb 2019 01:37:45 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: <3DDE4E37-69CB-47E3-8B27-DDE0C4F7FE94@develooper.com> > On Feb 24, 2019, at 22:03, Hank Nussbacher wrote: > > Did you have a CAA record defined and if not, why not? If the attacker got a CA to issue the cert because they changed the DNS server to be their own, a CAA record wouldn’t have helped (or at least been even easier to thwart than DNSSEC). Ask From dot at dotat.at Mon Feb 25 11:42:01 2019 From: dot at dotat.at (Tony Finch) Date: Mon, 25 Feb 2019 11:42:01 +0000 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <5ADEA327-C590-4360-BC00-B7FD155E7ACD@isc.org> References: <5ADEA327-C590-4360-BC00-B7FD155E7ACD@isc.org> Message-ID: Mark Andrews wrote: > > An organisation can also deploy DLV for their own zones using their own > registry. While the current code DLV validating code is only invoked > when the response validates as insecure, there is nothing preventing a > policy which says that DLV trumps or must also validate for entries in a > registry. At this stage is would be a minor code change to add such > policy knobs. DLV is a just a in-band way of distributing trust > anchors. Yes (as Mark knows) I would like to be able to use DLV in this enterprisey way. It should also help validators to continue working for local domains when external connectivity is funted. Tony. -- f.anthony.n.finch http://dotat.at/ East Sole, Lundy, Fastnet, Irish Sea: Southeasterly 4 or 5. Rough or very rough, but slight or moderate in Irish Sea. Mainly fair. Good, occasionally poor. From hank at efes.iucc.ac.il Mon Feb 25 13:16:23 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 25 Feb 2019 15:16:23 +0200 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <3DDE4E37-69CB-47E3-8B27-DDE0C4F7FE94@develooper.com> References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> <3DDE4E37-69CB-47E3-8B27-DDE0C4F7FE94@develooper.com> Message-ID: On 25/02/2019 11:37, Ask Bjørn Hansen wrote: > >> On Feb 24, 2019, at 22:03, Hank Nussbacher wrote: >> >> Did you have a CAA record defined and if not, why not? > If the attacker got a CA to issue the cert because they changed the DNS server to be their own, a CAA record wouldn’t have helped (or at least been even easier to thwart than DNSSEC). Yes if an attacker pwned the DNS then game over no matter what. I go under the assumption that the attacker was not able to take over the DNS system but rather other things along the way, in which case CAA should be of some assistance. -Hank > > > Ask From list-nanog2 at dragon.net Mon Feb 25 17:18:44 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 25 Feb 2019 10:18:44 -0700 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190225042945.909B2200EA8313@ary.local> References: <20190225042945.909B2200EA8313@ary.local> Message-ID: <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> dougm> You are right, if you can compromise a registrar that permits dougm> DNSSEC to be disabled (without notification/confirmation to POCs dougm> etc), then you only have a limited period (max of DS TTL) of dougm> protection for those resolvers that have already cached the DS. johnl> As far as I can tell, that's roughly all of them. If you have johnl> the credentials to log in and change the NS, you can change or johnl> remove the DS, too. Yes, though with the 1 day TTL most registries put on DS records, you at least have the chance to notice your DS has changed or been deleted and attempt to recover your registry account. That is somewhat a "locking the barn door" approach, and 2FA and other account security is the best solution. However, we are in a world now where every layer of security we can add is probably a good idea and having a day to notice could be handy. DNSSEC isn't useless but it solves one specific problem, end to end data integrity. It also requires operational cleanliness and attention to detail. We shouldn't make claims about what it can't do; we're much better off getting everyone to understand what it does and doesn't do. And underline what other security best practices they should be following. If someone owns your registry account, you're screwed. And right now, it tends to be the most neglected part of the entire zone ownership world. Let's use this opportunity to help folks lock down their accounts, not muddying the waters with dubious claims. From list-nanog2 at dragon.net Mon Feb 25 17:25:25 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 25 Feb 2019 10:25:25 -0700 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> Message-ID: <20190225172525.1A328107EA63@fafnir.remote.dragon.net> ebersman> If someone owns your registry account, you're screwed. And ebersman> right now, it tends to be the most neglected part of the ebersman> entire zone ownership world. Let's use this opportunity to ebersman> help folks lock down their accounts, not muddying the waters ebersman> with dubious claims. Reread this and felt I should clarify that I realize that John and Doug are not the ones saying DNSSEC is useless. I just hate to see the knee jerk "oh, see, DNSSEC didn't save the day so it's obviously useless". Let's give the world a better explanation. From sander at steffann.nl Mon Feb 25 18:44:03 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 25 Feb 2019 19:44:03 +0100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190225172525.1A328107EA63@fafnir.remote.dragon.net> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> Message-ID: Hi Paul, > Reread this and felt I should clarify that I realize that John and Doug > are not the ones saying DNSSEC is useless. I just hate to see the knee > jerk "oh, see, DNSSEC didn't save the day so it's obviously > useless". Let's give the world a better explanation. Security is only as strong as its weakest link. No single link can be expected to protect the whole chain on its own. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From owen at delong.com Mon Feb 25 18:44:59 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Feb 2019 10:44:59 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190225172525.1A328107EA63@fafnir.remote.dragon.net> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> Message-ID: <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> > On Feb 25, 2019, at 09:25 , Paul Ebersman wrote: > > ebersman> If someone owns your registry account, you're screwed. And > ebersman> right now, it tends to be the most neglected part of the > ebersman> entire zone ownership world. Let's use this opportunity to > ebersman> help folks lock down their accounts, not muddying the waters > ebersman> with dubious claims. > > Reread this and felt I should clarify that I realize that John and Doug > are not the ones saying DNSSEC is useless. I just hate to see the knee > jerk "oh, see, DNSSEC didn't save the day so it's obviously > useless". Let's give the world a better explanation. @Paul — I think you meant “registrar account” rather than “registry account” since most domain holders don’t have registry accounts. Registry accounts are primarily held by registrars. If someone owns a registrar’s registry account, then all of their customers (and potentially many many others) are screwed. Owen From eric.kuhnke at gmail.com Mon Feb 25 19:05:47 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 25 Feb 2019 11:05:47 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> Message-ID: One thing to consider with authentication for domain registrar accounts: DO NOT USE 2FA VIA SMS. This is a known attack vector that's been used by SS7 hijacking techniques for several well documented thefts of cryptocurrency, from people who were known to be holding large amounts of (bitcoin, ethereum, whatever) on exchanges which supported 2FA authentication. In some cases there was no SS7 hijacking going on, but rather social engineering of (t-mobile, sprint, verizon, at&t) customer service representatives to get a new SIM card issued for the attack target's phone. tl;dr: ss7 considered harmful On Mon, Feb 25, 2019 at 10:48 AM Owen DeLong wrote: > > > > On Feb 25, 2019, at 09:25 , Paul Ebersman > wrote: > > > > ebersman> If someone owns your registry account, you're screwed. And > > ebersman> right now, it tends to be the most neglected part of the > > ebersman> entire zone ownership world. Let's use this opportunity to > > ebersman> help folks lock down their accounts, not muddying the waters > > ebersman> with dubious claims. > > > > Reread this and felt I should clarify that I realize that John and Doug > > are not the ones saying DNSSEC is useless. I just hate to see the knee > > jerk "oh, see, DNSSEC didn't save the day so it's obviously > > useless". Let's give the world a better explanation. > > @Paul — I think you meant “registrar account” rather than “registry > account” > since most domain holders don’t have registry accounts. Registry accounts > are > primarily held by registrars. If someone owns a registrar’s registry > account, then > all of their customers (and potentially many many others) are screwed. > > Owen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-nanog2 at dragon.net Mon Feb 25 19:09:28 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 25 Feb 2019 12:09:28 -0700 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> Message-ID: <20190225190928.3DDD8107FD84@fafnir.remote.dragon.net> ebersman> If someone owns your registry account, you're screwed. And ebersman> right now, it tends to be the most neglected part of the ebersman> entire zone ownership world. Let's use this opportunity to ebersman> help folks lock down their accounts, not muddying the waters ebersman> with dubious claims. owen> Paul, I think you meant "registrar account" rather than "registry owen> account" since most domain holders don't have registry accounts. Yes. I please ICANN jargon dyslexia brought on by excess blood in my caffeine stream. ;) From list-nanog2 at dragon.net Mon Feb 25 19:14:59 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 25 Feb 2019 12:14:59 -0700 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> Message-ID: <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> ekuhnke> One thing to consider with authentication for domain registrar ekuhnke> accounts: ekuhnke> DO NOT USE 2FA VIA SMS. Yup. This is a good example of what I'm advocating. Just saying "use 2FA" or "use DNSSEC" or "have a CAA" isn't sufficient detail to make informed decisions of risk/effort/reward tradeoffs. Simplistic suggestions without details or context isn't doing anyone any favors. That said, even SMS 2FA is better than no 2FA. Barely. Just like forcing lousy passwords is better than no password but still not a best practice. From valdis.kletnieks at vt.edu Mon Feb 25 20:36:41 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 25 Feb 2019 15:36:41 -0500 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> Message-ID: <31207.1551127001@turing-police.cc.vt.edu> On Mon, 25 Feb 2019 12:14:59 -0700, Paul Ebersman said: > ekuhnke> One thing to consider with authentication for domain registrar > ekuhnke> accounts: > > ekuhnke> DO NOT USE 2FA VIA SMS. > > Yup. This is a good example of what I'm advocating. Just saying "use > 2FA" or "use DNSSEC" or "have a CAA" isn't sufficient detail to make > informed decisions of risk/effort/reward tradeoffs. Simplistic > suggestions without details or context isn't doing anyone any favors. > > That said, even SMS 2FA is better than no 2FA. Barely. Just like forcing > lousy passwords is better than no password but still not a best > practice. Feel free to suggest a workable 2FA. Personally, I use a Yubikey where I can. Oath seems to be a reasonable approach for technically minded people, but I'm not sure that it scales well to the people who own the long tail domains in the 40 million .coms. I can get oathtool to behave the way I want, but I'm not sure the owner of joes-bait-tackle-and-gunshop.com will be able to deal with it. Unless you get it down to the SMS "wait for a msg, type in the 6 digit number" level, it's going to be a tough start... From ross at tajvar.io Mon Feb 25 21:30:42 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 25 Feb 2019 16:30:42 -0500 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> Message-ID: Speaking of registrars vs registries - I've noticed some companies have become their own registrar to improve their domain security (Cloudflare, Google, etc.). Is that a feasible path for smaller organizations? How much risk does that mitigate? It seems like it gives the organization control over more of the domain registration, which allows them to manage things better than a typical registrar might. But credentials can be compromised in either case. Does anyone have any experience with that setup? On Mon, Feb 25, 2019, 1:49 PM Owen DeLong wrote: > > > > On Feb 25, 2019, at 09:25 , Paul Ebersman > wrote: > > > > ebersman> If someone owns your registry account, you're screwed. And > > ebersman> right now, it tends to be the most neglected part of the > > ebersman> entire zone ownership world. Let's use this opportunity to > > ebersman> help folks lock down their accounts, not muddying the waters > > ebersman> with dubious claims. > > > > Reread this and felt I should clarify that I realize that John and Doug > > are not the ones saying DNSSEC is useless. I just hate to see the knee > > jerk "oh, see, DNSSEC didn't save the day so it's obviously > > useless". Let's give the world a better explanation. > > @Paul — I think you meant “registrar account” rather than “registry > account” > since most domain holders don’t have registry accounts. Registry accounts > are > primarily held by registrars. If someone owns a registrar’s registry > account, then > all of their customers (and potentially many many others) are screwed. > > Owen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-nanog2 at dragon.net Tue Feb 26 01:23:44 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 25 Feb 2019 18:23:44 -0700 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <31207.1551127001@turing-police.cc.vt.edu> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> <31207.1551127001@turing-police.cc.vt.edu> Message-ID: <20190226012344.669241085134@fafnir.remote.dragon.net> ebersman> Yup. This is a good example of what I'm advocating. Just ebersman> saying "use 2FA" or "use DNSSEC" or "have a CAA" isn't ebersman> sufficient detail to make informed decisions of ebersman> risk/effort/reward tradeoffs. Simplistic suggestions without ebersman> details or context isn't doing anyone any favors. ebersman> That said, even SMS 2FA is better than no 2FA. Barely. Just ebersman> like forcing lousy passwords is better than no password but ebersman> still not a best practice. valdis> Feel free to suggest a workable 2FA. Personally, I use a valdis> Yubikey where I can. Oath seems to be a reasonable approach for valdis> technically minded people, but I'm not sure that it scales well valdis> to the people who own the long tail domains in the 40 million valdis> .coms. I can get oathtool to behave the way I want, but I'm not valdis> sure the owner of joes-bait-tackle-and-gunshop.com will be able valdis> to deal with it. Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's Bait & Tackle Shop probably isn't getting attacked by nation states who can hack SS7, so SMS text might be good enough. And certainly better than just an 8 char plain text password. Risk/attack surface is part of that context I mention. Folks in sensitive jobs will need better protection and hopefully be more capable of using less "user friendly" tech. Folks protecting less and with less geek background should still have some protection but it doesn't need to be nearly as fancy. From valdis.kletnieks at vt.edu Tue Feb 26 02:02:11 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 25 Feb 2019 21:02:11 -0500 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190226012344.669241085134@fafnir.remote.dragon.net> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> <31207.1551127001@turing-police.cc.vt.edu> <20190226012344.669241085134@fafnir.remote.dragon.net> Message-ID: <24679.1551146531@turing-police.cc.vt.edu> On Mon, 25 Feb 2019 18:23:44 -0700, Paul Ebersman said: > Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's > Bait & Tackle Shop probably isn't getting attacked by nation states who > can hack SS7, so SMS text might be good enough. And certainly better > than just an 8 char plain text password. So what registries/registrars are supporting 2FA that's better than SMS? Or since 98% of domain names are Bait&Tackle type, is nobody bothering to support something for the 2% that could use it? Or is there a business opportunity lurking here? :) From eric.kuhnke at gmail.com Tue Feb 26 02:13:11 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 25 Feb 2019 18:13:11 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <24679.1551146531@turing-police.cc.vt.edu> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> <31207.1551127001@turing-police.cc.vt.edu> <20190226012344.669241085134@fafnir.remote.dragon.net> <24679.1551146531@turing-police.cc.vt.edu> Message-ID: Markmonitor runs a registrar popular with fortune 500s that implements additional security steps, and talking to a clued in live human in the loop to modify anything in your domain record. On Mon, Feb 25, 2019, 6:03 PM wrote: > On Mon, 25 Feb 2019 18:23:44 -0700, Paul Ebersman said: > > > Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's > > Bait & Tackle Shop probably isn't getting attacked by nation states who > > can hack SS7, so SMS text might be good enough. And certainly better > > than just an 8 char plain text password. > > So what registries/registrars are supporting 2FA that's better than SMS? > Or since 98% of domain names are Bait&Tackle type, is nobody bothering > to support something for the 2% that could use it? > > Or is there a business opportunity lurking here? :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hf0002+nanog at uah.edu Tue Feb 26 02:21:06 2019 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Mon, 25 Feb 2019 20:21:06 -0600 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <24679.1551146531@turing-police.cc.vt.edu> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> <31207.1551127001@turing-police.cc.vt.edu> <20190226012344.669241085134@fafnir.remote.dragon.net> <24679.1551146531@turing-police.cc.vt.edu> Message-ID: On Mon, Feb 25, 2019 at 8:02 PM wrote: > So what registries/registrars are supporting 2FA that's better than SMS? > Or since 98% of domain names are Bait&Tackle type, is nobody bothering > to support something for the 2% that could use it? If Joe's Bait and Tackle buys from Namecheap, they can utilize TOTP for their second factor. https://www.namecheap.com/support/knowledgebase/article.aspx/10073/45/how-can-i-use-the-totp-method-for-twofactor-authentication From johnl at iecc.com Tue Feb 26 03:13:46 2019 From: johnl at iecc.com (John Levine) Date: 25 Feb 2019 22:13:46 -0500 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <24679.1551146531@turing-police.cc.vt.edu> Message-ID: <20190226031347.1C422200EBFD8E@ary.local> In article <24679.1551146531 at turing-police.cc.vt.edu> you write: >So what registries/registrars are supporting 2FA that's better than SMS? Opensrs does TOTP. It's certainly not bulletproof, but it's tied to your actual phone rather than the phone number. (We careful folk put our TOTP keys on a couple of our devices in case the phone dies or gets lost.) It's very easy to implement, it's an IETF open specification, and there are lots of clients that support it. FIDO keys (like Yubikey) also seem OK but I haven't looked at how hard they are to implement. From rubensk at gmail.com Tue Feb 26 03:20:10 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 26 Feb 2019 00:20:10 -0300 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190226031347.1C422200EBFD8E@ary.local> References: <24679.1551146531@turing-police.cc.vt.edu> <20190226031347.1C422200EBFD8E@ary.local> Message-ID: On Tue, Feb 26, 2019 at 12:14 AM John Levine wrote: > In article <24679.1551146531 at turing-police.cc.vt.edu> you write: > >So what registries/registrars are supporting 2FA that's better than SMS? > > Opensrs does TOTP. It's certainly not bulletproof, but it's tied to > your actual phone rather than the phone number. (We careful folk put > our TOTP keys on a couple of our devices in case the phone dies or > gets lost.) It's very easy to implement, it's an IETF open > specification, and there are lots of clients that support it. > > FIDO keys (like Yubikey) also seem OK but I haven't looked at how hard > they are to implement. > > https://twofactorauth.org/#domains gives a good view of the domain management landscape regarding 2FA. Rubens -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Tue Feb 26 05:59:13 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 25 Feb 2019 22:59:13 -0700 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: Message-ID: >https://twofactorauth.org/#domains gives a good view of the domain >management landscape regarding 2FA. Seems to require the unfettered execution of third-party code ... Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From job at instituut.net Tue Feb 26 06:07:10 2019 From: job at instituut.net (Job Snijders) Date: Tue, 26 Feb 2019 06:07:10 +0000 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: Message-ID: Keith, On Tue, Feb 26, 2019 at 6:00 AM Keith Medcalf wrote: > >https://twofactorauth.org/#domains gives a good view of the domain > >management landscape regarding 2FA. > > Seems to require the unfettered execution of third-party code ... > > Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity? What are you talking about?! Are you ... trolling? If you don't trust the various (excellent) closed & open-source implementations of TOTP - you can write one yourself. The algorithm & specification are entirely open and free to use: https://tools.ietf.org/html/rfc6238 Using TOTP as 2FA is an excellent and recommended practice, and I am happy to see so many domain registrars support it. Regards, Job From saku at ytti.fi Tue Feb 26 09:12:17 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 26 Feb 2019 11:12:17 +0200 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <24679.1551146531@turing-police.cc.vt.edu> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> <31207.1551127001@turing-police.cc.vt.edu> <20190226012344.669241085134@fafnir.remote.dragon.net> <24679.1551146531@turing-police.cc.vt.edu> Message-ID: On Tue, Feb 26, 2019 at 4:05 AM wrote: > So what registries/registrars are supporting 2FA that's better than SMS? > Or since 98% of domain names are Bait&Tackle type, is nobody bothering > to support something for the 2% that could use it? Gandi does TOTP and CIDR filtering, that is, you can give them list of CIDRs from which login is permissible at all. -- ++ytti From woody at pch.net Tue Feb 26 09:56:34 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 26 Feb 2019 01:56:34 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher wrote: > Did you have a CAA record defined and if not, why not? It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped. I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system. We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sander at steffann.nl Tue Feb 26 10:04:33 2019 From: sander at steffann.nl (Sander Steffann) Date: Tue, 26 Feb 2019 11:04:33 +0100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: <6910D097-1620-468B-8291-CF7F2A96F256@steffann.nl> > Op 26 feb. 2019, om 10:56 heeft Bill Woodcock het volgende geschreven: > > We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids. +1 Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From mh at xalto.net Tue Feb 26 10:53:53 2019 From: mh at xalto.net (Michael Hallgren) Date: Tue, 26 Feb 2019 11:53:53 +0100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <6910D097-1620-468B-8291-CF7F2A96F256@steffann.nl> References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> <6910D097-1620-468B-8291-CF7F2A96F256@steffann.nl> Message-ID: <686390e7c4291f1f9e4f58aca7c5b0f4@webmail.xalto.net> Le 2019-02-26 11:04, Sander Steffann a écrit : >> Op 26 feb. 2019, om 10:56 heeft Bill Woodcock het >> volgende geschreven: >> >> We need to get switched over to DANE as quickly as possible, and stop >> wasting effort trying to keep the CA system alive with ever-hackier >> band-aids. > > +1 > Sander +1 mh From bjorn at mork.no Tue Feb 26 13:01:47 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 26 Feb 2019 14:01:47 +0100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: (Bill Woodcock's message of "Tue, 26 Feb 2019 01:56:34 -0800") References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: <87k1hmg0uc.fsf@miraculix.mork.no> Bill Woodcock writes: > We need to get switched over to DANE as quickly as possible, and stop > wasting effort trying to keep the CA system alive with ever-hackier > band-aids. Sure. Just won't happen as long as there is money left in the CA business. Bjørn From cb.list6 at gmail.com Tue Feb 26 13:35:18 2019 From: cb.list6 at gmail.com (Ca By) Date: Tue, 26 Feb 2019 05:35:18 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock wrote: > > > > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher > wrote: > > Did you have a CAA record defined and if not, why not? > > It’s something we’d been planning to do but, ironically, we’d been in the > process of switching to Let’s Encrypt, and they were one of the two CAs > whose process vulnerabilities the attackers were exploiting. So, in this > particular case, it wouldn’t have helped. > > I guess the combination of CAA with a very expensive, or very manual, CA, > might be an improvement. But it’s still a band-aid on a bankrupt system. > > We need to get switched over to DANE as quickly as possible, and stop > wasting effort trying to keep the CA system alive with ever-hackier > band-aids. > > -Bill DNS guy says the solution for insecure DNS is... wait for it.... more DNS ... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drc at virtualized.org Tue Feb 26 14:25:17 2019 From: drc at virtualized.org (David Conrad) Date: Tue, 26 Feb 2019 15:25:17 +0100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: <0D0DF9EE-CCE1-414E-A611-14433E8F38E5@virtualized.org> On Feb 26, 2019, at 2:35 PM, Ca By wrote: > On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock > wrote: > > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher > wrote: > > Did you have a CAA record defined and if not, why not? > > It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped. > > I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system. > > We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids. > > -Bill > > DNS guy says the solution for insecure DNS is... wait for it.... more DNS ... Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the solution for a fundamentally broken trust model is a different system to derive trust. Or do you think Let’s Encrypt/Comodo increase trust? Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From cb.list6 at gmail.com Tue Feb 26 15:08:28 2019 From: cb.list6 at gmail.com (Ca By) Date: Tue, 26 Feb 2019 07:08:28 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <0D0DF9EE-CCE1-414E-A611-14433E8F38E5@virtualized.org> References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> <0D0DF9EE-CCE1-414E-A611-14433E8F38E5@virtualized.org> Message-ID: On Tue, Feb 26, 2019 at 6:25 AM David Conrad wrote: > On Feb 26, 2019, at 2:35 PM, Ca By wrote: > > On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock wrote: > >> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher >> wrote: >> > Did you have a CAA record defined and if not, why not? >> >> It’s something we’d been planning to do but, ironically, we’d been in the >> process of switching to Let’s Encrypt, and they were one of the two CAs >> whose process vulnerabilities the attackers were exploiting. So, in this >> particular case, it wouldn’t have helped. >> >> I guess the combination of CAA with a very expensive, or very manual, CA, >> might be an improvement. But it’s still a band-aid on a bankrupt system. >> >> We need to get switched over to DANE as quickly as possible, and stop >> wasting effort trying to keep the CA system alive with ever-hackier >> band-aids. >> >> -Bill > > > DNS guy says the solution for insecure DNS is... wait for it.... more DNS > ... > > > Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the > solution for a fundamentally broken trust model is a different system to > derive trust. > > Or do you think Let’s Encrypt/Comodo increase trust? > The trust issue has not yet been solved on the internet. Swapping the DNS cabal for the CA cabal is not an improvement. Right? They are really the same arbitraging rent-seekers, just different layers. Using DANE to verify multiple layers is interesting, but the web folks aren’t playing so it won’t go anywhere. Right? Google, Wechat, FB, msft, and Apple aren’t coming along. Since you mentioned Let’s Encrypt, they have reduced plaint text, which is great. But trust is a harder issue. For example, Symantec has lost trust. But only after repeated bad actions. > Regards, > -drc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Tue Feb 26 15:10:57 2019 From: dot at dotat.at (Tony Finch) Date: Tue, 26 Feb 2019 15:10:57 +0000 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <31207.1551127001@turing-police.cc.vt.edu> References: <20190225042945.909B2200EA8313@ary.local> <20190225171844.D15D7107E96E@fafnir.remote.dragon.net> <20190225172525.1A328107EA63@fafnir.remote.dragon.net> <6EDCF70A-817E-4546-8197-602F6B39199E@delong.com> <20190225191459.64CEE107FE31@fafnir.remote.dragon.net> <31207.1551127001@turing-police.cc.vt.edu> Message-ID: valdis.kletnieks at vt.edu wrote: > > Unless you get it down to the SMS "wait for a msg, type in the 6 digit number" > level, it's going to be a tough start... Isn't this what Duo's business is based on? Usable TOTP? See also Google Authenticator, Authy, 1Password, etc. usw. Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Iceland: Southwesterly gale 8 to storm 10, veering westerly 5 to 7 later. High or very high, becoming rough or very rough later. Squally showers. Moderate or poor. From johnl at iecc.com Tue Feb 26 16:10:38 2019 From: johnl at iecc.com (John Levine) Date: 26 Feb 2019 11:10:38 -0500 Subject: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: Message-ID: <20190226161039.4C890200EDBD64@ary.local> In article you write: >We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with >ever-hackier band-aids. What's the DANE version of a green-bar cert? From johnl at iecc.com Tue Feb 26 16:12:26 2019 From: johnl at iecc.com (John Levine) Date: 26 Feb 2019 11:12:26 -0500 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: Message-ID: <20190226161227.29288200EDC0FE@ary.local> In article you write: >Swapping the DNS cabal for the CA cabal is not an improvement. Right? They >are really the same arbitraging rent-seekers, just different layers. The models are different. If I want to compromise your DNS I need to attack your specific registrar. If I want a bogus cert, any of the thousand CAs in my browser will do. From carl at five-ten-sg.com Tue Feb 26 16:29:35 2019 From: carl at five-ten-sg.com (Carl Byington) Date: Tue, 26 Feb 2019 08:29:35 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <5ADEA327-C590-4360-BC00-B7FD155E7ACD@isc.org> References: <5ADEA327-C590-4360-BC00-B7FD155E7ACD@isc.org> Message-ID: <1551198575.25122.5.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Mon, 2019-02-25 at 17:04 +1100, Mark Andrews wrote: > I would also note that a organisation can deploy RFC 5011 for their > own zones and have their own equipment use DNSKEYs managed using RFC > 5011 for their own zones. This isolates the organisation's equipment > from the parent zone's management practices. I want a registrar that can use TOTP 2fa for updates, but that interferes with automated KSK key rollovers. Are there any registrars that use rfc5011 to allow automated KSK key rollovers, combined with TOTP 2fa for web based updates like the initial transition to a secure zone, NS record changes, etc.? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlx1aWgACgkQL6j7milTFsF9mACfVIXUZNLTOEyzbjneuZDeIBEg 2GUAnjoWsNZXtu0PgTuTvPwK0Je9DpCG =nZy7 -----END PGP SIGNATURE----- From sethm at rollernet.us Tue Feb 26 16:36:11 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 Feb 2019 08:36:11 -0800 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: Message-ID: <4dd24cca-540c-aeb5-ab0f-ecfab83fa2ed@rollernet.us> On 2/25/19 9:59 PM, Keith Medcalf wrote: > Are you offering an indemnity in case that code is malicious? What are the terms and the amount of the indemnity? Anyone who is that paranoid should read the RFC and write their own TOTP client that lets them indemnify themselves from their own code. From Jacques.Latour at cira.ca Tue Feb 26 17:15:54 2019 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Tue, 26 Feb 2019 17:15:54 +0000 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: <6f0657fb227b4b788212f9272ca54706@cira.ca> DNSSEC should of never been part of the domain registration process, it was because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance and bootstrap. But if you keep DNSSEC maintenance outside the registrar control then it can be effective tool (amongst other) in identifying hijacks. Taking away he ability of the bad actors to disable DNSSEC via registrar control panel. This is what happens when you have all your eggs in one basket and you loose the keys to your kingdom. From: NANOG On Behalf Of Bill Woodcock Sent: February 26, 2019 4:57 AM To: Hank Nussbacher Cc: nanog at nanog.org Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher > wrote: > Did you have a CAA record defined and if not, why not? It’s something we’d been planning to do but, ironically, we’d been in the process of switching to Let’s Encrypt, and they were one of the two CAs whose process vulnerabilities the attackers were exploiting. So, in this particular case, it wouldn’t have helped. I guess the combination of CAA with a very expensive, or very manual, CA, might be an improvement. But it’s still a band-aid on a bankrupt system. We need to get switched over to DANE as quickly as possible, and stop wasting effort trying to keep the CA system alive with ever-hackier band-aids. -Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Tue Feb 26 17:49:30 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 26 Feb 2019 12:49:30 -0500 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <4dd24cca-540c-aeb5-ab0f-ecfab83fa2ed@rollernet.us> References: <4dd24cca-540c-aeb5-ab0f-ecfab83fa2ed@rollernet.us> Message-ID: <11529.1551203370@turing-police.cc.vt.edu> On Tue, 26 Feb 2019 08:36:11 -0800, Seth Mattinen said: > On 2/25/19 9:59 PM, Keith Medcalf wrote: > > Are you offering an indemnity in case that code is malicious? What are the > > terms and the amount of the indemnity? > Anyone who is that paranoid should read the RFC and write their own TOTP > client that lets them indemnify themselves from their own code. I seem to recall that the 1983 Turing Award lecture referenced a 1974 pen test of Multics that proved conclusively that level of paranoia isn't sufficient.... From woody at pch.net Tue Feb 26 19:46:32 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 26 Feb 2019 11:46:32 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <6f0657fb227b4b788212f9272ca54706@cira.ca> References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> <6f0657fb227b4b788212f9272ca54706@cira.ca> Message-ID: <93FE8654-FB5D-436E-BD25-B1F4AF145BD1@pch.net> > On Feb 26, 2019, at 9:15 AM, Jacques Latour wrote: > DNSSEC should of never been part of the domain registration process, it was because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance and bootstrap. But if you keep DNSSEC maintenance outside the registrar control then it can be effective tool (amongst other) in identifying hijacks. Taking away he ability of the bad actors to disable DNSSEC via registrar control panel. > This is what happens when you have all your eggs in one basket and you loose the keys to your kingdom. Agreed. There’s absolutely no reason for registrars to be involved with DS records of zones they’re not signing. And, for the same reason, there’s no reason for them to be involved with NS records, either, after an initial bootstrap. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mpetach at netflight.com Tue Feb 26 20:23:38 2019 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 26 Feb 2019 12:23:38 -0800 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <11529.1551203370@turing-police.cc.vt.edu> References: <4dd24cca-540c-aeb5-ab0f-ecfab83fa2ed@rollernet.us> <11529.1551203370@turing-police.cc.vt.edu> Message-ID: On Tue, Feb 26, 2019 at 9:51 AM wrote: > On Tue, 26 Feb 2019 08:36:11 -0800, Seth Mattinen said: > > On 2/25/19 9:59 PM, Keith Medcalf wrote: > > > Are you offering an indemnity in case that code is malicious? What > are the > > > terms and the amount of the indemnity? > > > Anyone who is that paranoid should read the RFC and write their own TOTP > > client that lets them indemnify themselves from their own code. > > I seem to recall that the 1983 Turing Award lecture referenced a 1974 pen > test > of Multics that proved conclusively that level of paranoia isn't > sufficient.... > > Well, the OP was probably just speaking in shorthand. What I'm sure they really meant was after developing your own silicon on your own hardware, and hand assembling your own compiler and linker, and then writing your own drivers for your hardware and building your own operating system, you could easily write your own TOTP implementation on your hardware running on your silicon with your operating system with your compiler and your linker...and then you could be sure. Right? Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Tue Feb 26 20:33:16 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 26 Feb 2019 12:33:16 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> Message-ID: <16CB4BC6-8B35-4256-83F8-8FEBFAEFED81@pch.net> > On Feb 26, 2019, at 5:35 AM, Ca By wrote: > DNS guy says the solution for insecure DNS… I am not a DNS guy. I’m a routing guy who became a routing-economics guy as my hair got pointier. Stephane and Allison and Bert and Olafur are DNS people, to pick a few examples. And I believe that, yes, DNS people believe that the solution to insecurity in the DNS is to replace insecure portions of the DNS with more secure improvements to the DNS. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From marka at isc.org Tue Feb 26 20:49:47 2019 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Feb 2019 07:49:47 +1100 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <93FE8654-FB5D-436E-BD25-B1F4AF145BD1@pch.net> References: <50EFCF39-ABD7-4054-B6E1-99C2F73771AF@nist.gov> <34d27875-54d5-2153-ebd3-2a20fed0a649@efes.iucc.ac.il> <6f0657fb227b4b788212f9272ca54706@cira.ca> <93FE8654-FB5D-436E-BD25-B1F4AF145BD1@pch.net> Message-ID: <8487D028-BBC7-4A80-AAC2-3005B36ABED4@isc.org> > On 27 Feb 2019, at 6:46 am, Bill Woodcock wrote: > > > >> On Feb 26, 2019, at 9:15 AM, Jacques Latour wrote: >> DNSSEC should of never been part of the domain registration process, it was because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance and bootstrap. But if you keep DNSSEC maintenance outside the registrar control then it can be effective tool (amongst other) in identifying hijacks. Taking away he ability of the bad actors to disable DNSSEC via registrar control panel. >> This is what happens when you have all your eggs in one basket and you loose the keys to your kingdom. > > Agreed. There’s absolutely no reason for registrars to be involved with DS records of zones they’re not signing. And, for the same reason, there’s no reason for them to be involved with NS records, either, after an initial bootstrap. > > -Bill Using https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ with TSIG or SIG(0) would have prevented this with TFA for updating the credentials required to authenticate the updates. The method works with either TSIG or SIG(0) and you can have specific keys to update DS records or NS records and glue records. You can’t MITM TSIG or SIG(0). TSIG and SIG(0) have time limited replay windows. This is just bolting together tried and proven technology with database lookups to determine which registrar authenticates the update. Nameservers already forward UPDATE messages to the primary server for processing using TSIG and SIG(0) between the UPDATE client and the primary server. The key name is in the clear so it is easy to use that to select how to redirect the update. This also works with existing DNS servers when EPP is not thrown into the mix. It also doesn’t require DNSSEC to be deployed. Tools to do this have been shipped with nameservers since UPDATE, TSIG and SIG(0) were invented. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From woody at pch.net Tue Feb 26 20:58:50 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 26 Feb 2019 12:58:50 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <20190226161227.29288200EDC0FE@ary.local> References: <20190226161227.29288200EDC0FE@ary.local> Message-ID: <70811CF1-0674-4D8E-8852-37897F506E17@pch.net> > On Feb 26, 2019, at 8:12 AM, John Levine wrote: > > In article you write: >> Swapping the DNS cabal for the CA cabal is not an improvement. Right? They >> are really the same arbitraging rent-seekers, just different layers. > > The models are different. If I want to compromise your DNS I need to > attack your specific registrar. If I want a bogus cert, any of the > thousand CAs in my browser will do. Exactly. And if you’re an organization that has money and pays attention to DNS and security, you can get yourself a TLD, and be your own registry, at which point you only need to worry about the security of the root zone. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From woody at pch.net Wed Feb 27 00:13:41 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 26 Feb 2019 16:13:41 -0800 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <20190226161227.29288200EDC0FE@ary.local> <70811CF1-0674-4D8E-8852-37897F506E17@pch.net> Message-ID: <3FD86D54-7FE4-4E1D-8C8D-A4D79F030DAD@pch.net> > On Feb 26, 2019, at 1:25 PM, Nico Cartron wrote: > > > >> On 26 Feb 2019, at 21:58, Bill Woodcock wrote: >> >> >> >>> On Feb 26, 2019, at 8:12 AM, John Levine wrote: >>> >>> In article you write: >>>> Swapping the DNS cabal for the CA cabal is not an improvement. Right? They >>>> are really the same arbitraging rent-seekers, just different layers. >>> >>> The models are different. If I want to compromise your DNS I need to >>> attack your specific registrar. If I want a bogus cert, any of the >>> thousand CAs in my browser will do. >> >> Exactly. And if you’re an organization that has money and pays attention to DNS and security, you can get yourself a TLD, and be your own registry, at which point you only need to worry about the security of the root zone. > > Interesting. > Never thought of new TLD from this angle :) That’s the main reason for having a brand TLD at this point, from my point of view. It’s the reason I’d get one in a heartbeat, if I could afford the fees. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From johnl at iecc.com Wed Feb 27 01:45:29 2019 From: johnl at iecc.com (John Levine) Date: 26 Feb 2019 20:45:29 -0500 Subject: A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <3FD86D54-7FE4-4E1D-8C8D-A4D79F030DAD@pch.net> Message-ID: <20190227014531.193F8200F2440B@ary.local> In article <3FD86D54-7FE4-4E1D-8C8D-A4D79F030DAD at pch.net> you write: >That’s the main reason for having a brand TLD at this point, from my point of view. It’s the reason I’d get one in a heartbeat, if I could afford the fees. Well, actually, you can't get one. The 2013 round is still working out some issues, e.g. two companies both named Merck who hate each other want .MERCK and neither will budge. There may be another round but given the stupendous non-success of the current round, I wouldn't hold my breath. Also, with only one exception, all of the brand TLDs are in fact run by a handful of of familiar back end services. (The exception is a phone company in the Philippines that rolled their own, pretty marginally.) PCH presumably has the infrastructure to run one, but you're really just as well off becoming a registrar and managing your 2LDs in well run TLDs. You can do that now, it's a lot cheaper. From kmedcalf at dessus.com Wed Feb 27 03:56:22 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 26 Feb 2019 20:56:22 -0700 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: <4dd24cca-540c-aeb5-ab0f-ecfab83fa2ed@rollernet.us> Message-ID: I did write my own TOTP client. However, why do you assume that I am talking about a TOTP client and not the referred webpage which requires the unfettered execution of third-party (likely malicious) javascript in order to view? Not to mention requiring the use of (also quite possibly malicious) downloaded fonts? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On >Behalf Of Seth Mattinen >Sent: Tuesday, 26 February, 2019 09:36 >To: nanog at nanog.org >Subject: Re: 2FA, was A Deep Dive on the Recent Widespread DNS >Hijacking > >On 2/25/19 9:59 PM, Keith Medcalf wrote: >> Are you offering an indemnity in case that code is malicious? What >are the terms and the amount of the indemnity? > > >Anyone who is that paranoid should read the RFC and write their own >TOTP >client that lets them indemnify themselves from their own code. From hf0002+nanog at uah.edu Wed Feb 27 04:02:05 2019 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Tue, 26 Feb 2019 22:02:05 -0600 Subject: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking In-Reply-To: References: <4dd24cca-540c-aeb5-ab0f-ecfab83fa2ed@rollernet.us> Message-ID: On Tue, Feb 26, 2019 at 9:56 PM Keith Medcalf wrote: > I did write my own TOTP client. However, why do you assume that I am talking about a TOTP client and not the referred webpage which requires the unfettered execution of third-party (likely malicious) javascript in order to view? Not to mention requiring the use of (also quite possibly malicious) downloaded fonts? Well, because: 1. the page's