From nagarjun.govindraj at imaginea.com Wed Mar 1 10:49:07 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Wed, 01 Mar 2017 10:49:07 +0000 Subject: IRR database for local usage Message-ID: Hi nanog, Is it possible to maintian an IRR database locally for quering route objects from various RIR's and do a regular sync like what RPKI validator does for ROA's. - Nagarjun From rubensk at gmail.com Wed Mar 1 11:07:13 2017 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 1 Mar 2017 08:07:13 -0300 Subject: IRR database for local usage In-Reply-To: References: Message-ID: Yeap. If you look at http://irr.net/docs/list.html , all of them list FTP sites where you can get all information in bulk, load into your IRR daemon and have a fast look-up for all that data. Rubens On Wed, Mar 1, 2017 at 7:49 AM, Nagarjun Govindraj via NANOG < nanog at nanog.org> wrote: > Hi nanog, > > Is it possible to maintian an IRR database locally for quering route > objects from various RIR's and do a regular sync like what RPKI validator > does for ROA's. > > - Nagarjun > From job at instituut.net Wed Mar 1 11:28:11 2017 From: job at instituut.net (Job Snijders) Date: Wed, 1 Mar 2017 18:28:11 +0700 Subject: IRR database for local usage In-Reply-To: References: Message-ID: <20170301112811.GA1029@Vurt.local> On Wed, Mar 01, 2017 at 10:49:07AM +0000, Nagarjun Govindraj via NANOG wrote: > Is it possible to maintian an IRR database locally for quering route > objects from various RIR's and do a regular sync like what RPKI validator > does for ROA's. IRRExplorer's database is available as json blob, if you are only interested in route objects & as-sets this might be of use to you. IRRexplorer talks NRTM with various databases, and these dumps are refreshed every few minutes. wget http://irrexplorer.nlnog.net/static/dumps/irrexplorer-routes.json.bz2 wget http://irrexplorer.nlnog.net/static/dumps/irrexplorer-as_sets.json.bz2 Kind regards, Job From franziska at inet.tu-berlin.de Wed Mar 1 08:48:05 2017 From: franziska at inet.tu-berlin.de (Franziska Lichtblau) Date: Wed, 1 Mar 2017 09:48:05 +0100 Subject: Research project and survey: Network filtering and IP spoofing Message-ID: <20170301084805.GC28944@discordia> Hi, we are a team of researchers from TU Berlin [1] working on a measurement project to assess the ramifications of traffic with spoofed source IP addresses in the Internet. To better understand the operational challenges that you as network operators face when deploying (or not deploying) source IP address filtering techniques, we'd like to invite you to participate in our survey. If you could spare 5 minutes of your time, we'd be delighted if you could fill out our survey form and tell us about your current practices regarding network filtering. To participate, please visit: [2] http://filteringsurvey.inet.tu-berlin.de/ If you have any concerns or questions, you can reply on-list or contact us via [3] filtering-survey at inet.tu-berlin.de. We will only publish anonymized results of this study and once we've analyzed your feedback we'll publish a digest of the results on-list if you're interested. As you are probably subscribed to more network operator lists you might encounter this mail multiple times. We apologize for cross-posting, but in order to get results that will give us meaningful insights we need the widest coverage we can get. Thank you very much for your support! Franziska Lichtblau [1] www.inet.tu-berlin.de [2] http://filteringsurvey.inet.tu-berlin.de/ [3] filtering-survey at inet.tu-berlin.de -- Franziska Lichtblau, M.A. building MAR, 4th floor, room 4.004 Fachgebiet INET - Sekr. MAR 4-4 phone: +49 30 314 757 33 Technische Universit?t Berlin gpg-fp: 4FA0 F1BC 8B9A 7F64 797C Marchstrasse 23 - 10587 Berlin 221C C6C6 2786 91EC 5CD5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rpug at lp0.org Wed Mar 1 16:28:45 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 01 Mar 2017 11:28:45 -0500 Subject: Consumer networking head scratcher Message-ID: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> Hi everyone, I've got a real head scratcher that I have come across after replacing the router on my home network. I thought I'd share because it is a fascinating issue to me. At random times, my Windows machines (Win 7 and Win 10, attached to the network via WiFi, 5GHz) lose connectivity to the Internet. They can continue to access internal resources, such as the router's admin interface. Other devices including Macs, iPhones, Android phones, and Rokus never have this issue. I realized that on the Windows machines, when the connection drops, if I run a traceroute, it dies at a certain hop every time (out in Comcast's network, who is my ISP) even though a Mac sitting right next to it is able to go all the way through to the destination. The even stranger thing I discovered last night is that if I trace to the hop before the hop that it dies at, it then dies at the hop before that (and as I trace to closer and closer hops, it dies the hop before that!) This is illustrated in the traces I've captured here: http://pastebin.com/raw/R1UHLi0U For what it's worth, the router is a Linksys EA7300 that I just picked up. I can't even imagine what would cause this issue at this point. If anyone has any thoughts, I'd love to hear them! I'm going to start studying some packet captures to see if I can spot an issue. Best, Ryan From rpug at lp0.org Wed Mar 1 18:27:09 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 01 Mar 2017 13:27:09 -0500 Subject: Consumer networking head scratcher In-Reply-To: <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> Message-ID: <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> The issue doesn't happen with my previous router, and I've tested multiple computers (one that isn't mine.) It doesn't seem like it decrements over time.. it just dies sooner as I trace further up the path. I can consistently die at the 7th hop if I try to go to Google, but if I trace to the 6th hop, it'll die at the 5th hop! On Wed, Mar 1, 2017, at 01:23 PM, Aaron Gould wrote: > That's strange... it's like the TTL on all Windows IP packets are > decrementing more and more as time goes on causing you to get less and > less hops into the internet > > I wonder if it's a bug/virus/malware affecting only your windows > computers. > > -Aaron > > From bill at herrin.us Wed Mar 1 19:04:07 2017 From: bill at herrin.us (William Herrin) Date: Wed, 1 Mar 2017 14:04:07 -0500 Subject: Consumer networking head scratcher In-Reply-To: <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> Message-ID: > On Wed, Mar 1, 2017, at 01:23 PM, Aaron Gould wrote: >> That's strange... it's like the TTL on all Windows IP packets are >> decrementing more and more as time goes on causing you to get less and >> less hops into the internet Hi Ryan, Windows tracert uses ICMP echo-request packets to trace the path. It expects either an ICMP destination unreachable message or an ICMP echo response message to come back. The final hop in the trace will return an ICMP echo-response or an unreachable-prohibited. The ones prior to the final hop will return an unreachable-time-exceeded if they return anything at all. If the destination does not respond to ping, if those pings are dropped, or if it responds with an unreachable that's dropped you will not receive a response and the tracert will not find its end. That's why you're seeing the "decrementing" behavior you describe. I have no information about whether comcast blocks pings to its routers. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From valdis.kletnieks at vt.edu Wed Mar 1 19:27:51 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 01 Mar 2017 14:27:51 -0500 Subject: Consumer networking head scratcher In-Reply-To: References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> Message-ID: <20247.1488396471@turing-police.cc.vt.edu> On Wed, 01 Mar 2017 14:04:07 -0500, William Herrin said: > I have no information about whether comcast blocks pings to its routers. All the Comcast gear in the path from my home router to non-Comcast addresses will quite cheerfully rate-limit answer both pings and traceroutes. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From rpug at lp0.org Wed Mar 1 19:31:20 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 01 Mar 2017 14:31:20 -0500 Subject: Consumer networking head scratcher In-Reply-To: References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> Message-ID: <1488396680.98049.897208144.04400859@webmail.messagingengine.com> On Wed, Mar 1, 2017, at 02:04 PM, William Herrin wrote: > > On Wed, Mar 1, 2017, at 01:23 PM, Aaron Gould wrote: > >> That's strange... it's like the TTL on all Windows IP packets are > >> decrementing more and more as time goes on causing you to get less and > >> less hops into the internet > > Hi Ryan, > > Windows tracert uses ICMP echo-request packets to trace the path. It > expects either an ICMP destination unreachable message or an ICMP echo > response message to come back. The final hop in the trace will return > an ICMP echo-response or an unreachable-prohibited. The ones prior to > the final hop will return an unreachable-time-exceeded if they return > anything at all. > > If the destination does not respond to ping, if those pings are > dropped, or if it responds with an unreachable that's dropped you will > not receive a response and the tracert will not find its end. That's > why you're seeing the "decrementing" behavior you describe. > > I have no information about whether comcast blocks pings to its routers. > > Regards, > Bill Herrin > I see what you're saying, and that could explain the decrementing behavior I'm seeing which ultimately is not a real indicator of the problem I am having. So in that case, I would be back to my original issue where I stop being able to pass traffic to the Internet, and when that happens my traceroute always dies at the same hop. After disconnecting and reconnecting, the same traceroute will go all the way through. Thanks for the thoughts. From mpalmer at hezmatt.org Wed Mar 1 19:34:16 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 2 Mar 2017 06:34:16 +1100 Subject: SHA1 collisions proven possisble In-Reply-To: <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> Message-ID: <20170301193416.GS7463@hezmatt.org> On Tue, Feb 28, 2017 at 01:16:23PM -0600, James DeVincentis via NANOG wrote: > The CA signing the cert actually changes the fingerprint The what? RFC5280 does not contain the string "finger". > (and serial number, which is what is checked on revocation lists) The CA doesn't "change" the serial number (a CSR doesn't have a place to even ask for a serial), they pick one, and while it's *supposed* to be at least partially random, given the largely appalling state of CA operations (and, even worse, the competence of the auditors who are supposed to be making sure they're doing the right thing), I'd be awfully surprised if there wasn't at least one CA in a commonly-used trust store which was issuing certificates with predictable serial numbers. > Beyond that, SHA1 signing of certificates has long been deprecated and no > new public CAs will sign a CSR and cert with SHA1. Except all the ones that the payment industry (there's a group with no stake in good security, huh?) have managed to convince browsers to allow (thankfully, they get a good counter-cryptanalysis over them first), and all the ones that have been issued "by mistake" to inconsequential organisations like, say, HMRC (which just appear in CT logs, and the vigilance of the community finds and brings to the attention of trust stores). - Matt -- I remember going to my first tutorial in room 404. I was most upset when I found it. From bill at herrin.us Wed Mar 1 19:57:28 2017 From: bill at herrin.us (William Herrin) Date: Wed, 1 Mar 2017 14:57:28 -0500 Subject: Consumer networking head scratcher In-Reply-To: <1488396680.98049.897208144.04400859@webmail.messagingengine.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> <1488396680.98049.897208144.04400859@webmail.messagingengine.com> Message-ID: On Wed, Mar 1, 2017 at 2:31 PM, Ryan Pugatch wrote: > So in that case, I would be back to my original issue where I stop being > able to pass traffic to the Internet, and when that happens my > traceroute always dies at the same hop. After disconnecting and > reconnecting, the same traceroute will go all the way through. Hi Ryan, Next step: run Wireshark and see what you see during the traceroutes. Are they leaving with a reasonable TTL? Is it certain that nothing returns? Are the packets going to the ethernet MAC address you expect them to? I had a fun problem once when I cloned some VMs but neglected to change the source MAC address. They all seemed to work under light load but get two downloading at once and suddenly they both experienced major packet loss. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rpug at lp0.org Wed Mar 1 20:09:50 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 01 Mar 2017 15:09:50 -0500 Subject: Consumer networking head scratcher In-Reply-To: References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> <1488396680.98049.897208144.04400859@webmail.messagingengine.com> Message-ID: <1488398990.107177.897252352.5FFAE800@webmail.messagingengine.com> On Wed, Mar 1, 2017, at 02:57 PM, William Herrin wrote: > On Wed, Mar 1, 2017 at 2:31 PM, Ryan Pugatch wrote: > > So in that case, I would be back to my original issue where I stop being > > able to pass traffic to the Internet, and when that happens my > > traceroute always dies at the same hop. After disconnecting and > > reconnecting, the same traceroute will go all the way through. > > Hi Ryan, > > Next step: run Wireshark and see what you see during the traceroutes. > Are they leaving with a reasonable TTL? Is it certain that nothing > returns? Are the packets going to the ethernet MAC address you expect > them to? > > I had a fun problem once when I cloned some VMs but neglected to > change the source MAC address. They all seemed to work under light > load but get two downloading at once and suddenly they both > experienced major packet loss. > > Regards, > Bill > Definitely the direction I'm going. Even aside from the traceroutes, I'm going to capture some regular web traffic to see what is happening. Planning to send traffic to a machine I control to see if any packets are actually making it through at all. I'm not sure if this new Linksys router has any packet capture ability that is exposed to the end user, but I'd also love be able to see what's actually going through the router itself. Thanks, Ryan From iamzam at gmail.com Wed Mar 1 20:58:33 2017 From: iamzam at gmail.com (iamzam at gmail.com) Date: Wed, 1 Mar 2017 15:58:33 -0500 Subject: Consumer networking head scratcher In-Reply-To: <1488398990.107177.897252352.5FFAE800@webmail.messagingengine.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> <1488396680.98049.897208144.04400859@webmail.messagingengine.com> <1488398990.107177.897252352.5FFAE800@webmail.messagingengine.com> Message-ID: On many non-windows OS (Mac OSX, Linux, FreeBSD etc.) you can specify ICMP traceroute using -I: traceroute -I google.com I wonder if this would replicate your experience with Windows tracert From rpug at lp0.org Wed Mar 1 21:06:58 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 01 Mar 2017 16:06:58 -0500 Subject: Consumer networking head scratcher Message-ID: <1488402418.120923.897320696.62AE2695@webmail.messagingengine.com> On Wed, Mar 1, 2017, at 03:58 PM, iamzam at gmail.com wrote: > On many non-windows OS (Mac OSX, Linux, FreeBSD etc.) you can specify > ICMP > traceroute using -I: > > traceroute -I google.com > > I wonder if this would replicate your experience with Windows tracert Definitely on my list to test. Thanks. From james.d at hexhost.net Wed Mar 1 21:28:23 2017 From: james.d at hexhost.net (james.d at hexhost.net) Date: Wed, 1 Mar 2017 15:28:23 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <20170301193416.GS7463@hezmatt.org> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> Message-ID: <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> > The what? RFC5280 does not contain the string "finger". The fingerprint (or thumbprint) is the hash (sha1/sha256) of the certificate data in DER format, it's not part of the actual certificate. The fingerprint is largely used in the security and development community in order to quickly identify a unique certificate. Application developers (See: Google, Microsoft, Apple, etc) also hard-code fingerprints into applications to defend against anyone attempting to MITM the traffic (for obscurity or security purposes). Fingerprints are used instead of serial numbers since two CAs can issue two certificates with the same serial number. It's also the fastest way to determine the identity of a certificate without examining individual data in certificates. > The CA doesn't "change" the serial number (a CSR doesn't have a place to even ask for a serial), they pick one, and while it's *supposed* to be at least partially random, given the largely appalling state of CA operations (and, even worse, the competence of the auditors who are supposed to be making sure they're doing the right thing), I'd be awfully surprised if there wasn't at least one CA in a commonly-used trust store which was issuing certificates with predictable serial numbers. Predictable serial numbers still wouldn't help you here and certificates contain multiple unique identifiers. There's a massive brute force component to this attack as well, both the "good" and "bad" certificate would have to be brute forced. Let's also remember the ONLY example of this so far is PDF documents where massive amounts of data can be hidden in order to manipulate the hashes. This isn't the case with certificates. On the subject of the example documents. The example documents given are unbelievably basic in their differing appearances and the attack is _easily_ detected. > Except all the ones that the payment industry (there's a group with no stake in good security, huh?) have managed to convince browsers to allow (thankfully, they get a good counter-cryptanalysis over them first), and all the ones that have been issued "by mistake" to inconsequential organizations like, say, HMRC (which just appear in CT logs, and the vigilance of the community finds and brings to the attention of trust stores). Again, this attack doesn't work on any existing arbitrary item and is easily detected. So any existing item is safe until a preimage attack is found. The sky is not falling. The most this will affect is generation of unique identifiers (which is not security related) using the SHA1 algorithm. This has already been seen when trying to commit both of the example PDF documents to a git repository. This whole situation is being blown way out of proportion and significantly oversimplified. This is a PR stunt by Google to keep to their timeline from when they cried the sky was falling years ago about SHA1 (https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html). Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in total 6,500 years of CPU computation to complete the attack first phase = 56,940,000 hours CPU time 110 years of GPU computation to complete the second phase = 963,600 hours GPU time Those statistics are nowhere near real world for ROI. You'd have to invest at least 7 figures (USD) in resources. So the return must be millions of dollars before anyone can detect the attack. Except, it's already detectable. Google nullified their point of demonstrating the attack by showing it was easily detectable. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matt Palmer Sent: Wednesday, March 1, 2017 1:34 PM To: nanog at nanog.org Subject: Re: SHA1 collisions proven possisble On Tue, Feb 28, 2017 at 01:16:23PM -0600, James DeVincentis via NANOG wrote: > The CA signing the cert actually changes the fingerprint The what? RFC5280 does not contain the string "finger". > (and serial number, which is what is checked on revocation lists) The CA doesn't "change" the serial number (a CSR doesn't have a place to even ask for a serial), they pick one, and while it's *supposed* to be at least partially random, given the largely appalling state of CA operations (and, even worse, the competence of the auditors who are supposed to be making sure they're doing the right thing), I'd be awfully surprised if there wasn't at least one CA in a commonly-used trust store which was issuing certificates with predictable serial numbers. > Beyond that, SHA1 signing of certificates has long been deprecated and > no new public CAs will sign a CSR and cert with SHA1. Except all the ones that the payment industry (there's a group with no stake in good security, huh?) have managed to convince browsers to allow (thankfully, they get a good counter-cryptanalysis over them first), and all the ones that have been issued "by mistake" to inconsequential organisations like, say, HMRC (which just appear in CT logs, and the vigilance of the community finds and brings to the attention of trust stores). - Matt -- I remember going to my first tutorial in room 404. I was most upset when I found it. From jfmezei_nanog at vaxination.ca Wed Mar 1 23:35:40 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 1 Mar 2017 18:35:40 -0500 Subject: Consumer networking head scratcher In-Reply-To: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> Message-ID: <58B75ACC.4060309@vaxination.ca> On 2017-03-01 11:28, Ryan Pugatch wrote: > At random times, my Windows machines (Win 7 and Win 10, attached to the > network via WiFi, 5GHz) lose connectivity to the Internet. > For what it's worth, the router is a Linksys EA7300 that I just picked > up. Way back when, I have a netgear router. It ended having a limit on its NAT translation table, and when I had too many connections going at same time (or not yet timed out), I would lose connection. There was an unofficial patch to the firmware (litterally a patch in code that defined table size) to increase that table to 1000- as I recall. Does the Linksys have a means to display the NAT translation table and see if maybe connections are lost when that table is full and lots of connections have not yet timed out ? From valdis.kletnieks at vt.edu Thu Mar 2 00:22:27 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 01 Mar 2017 19:22:27 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> Message-ID: <43912.1488414147@turing-police.cc.vt.edu> On Wed, 01 Mar 2017 15:28:23 -0600, "james.d--- via NANOG" said: > Those statistics are nowhere near real world for ROI. You'd have to invest > at least 7 figures (USD) in resources. So the return must be millions of > dollars before anyone can detect the attack. Except, it's already > detectable. *Somebody* has to invest 7 figures in resources. Doesn't have to be you. Remember that if you have access to a 1M node botnet, you could have 56,940,000 hours of CPU time racked racked up in... under 60 hours. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From james.d at hexhost.net Thu Mar 2 00:38:25 2017 From: james.d at hexhost.net (James DeVincentis) Date: Wed, 1 Mar 2017 18:38:25 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <43912.1488414147@turing-police.cc.vt.edu> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> Message-ID: Keep in mind botnets that large are comprised largely of IoT devices which have very little processing power compared to the massive multi-core, high frequency, high memory bandwidth (this is especially important for cryptographic operations) CPUs in data centers. It doesn?t take much processing power to launch DDoS attacks so that?s why IoT is perfect for botnets. Those botnets which have desktop grade systems are also comprised of typically older machines that go unpatched and do not have high end server CPUs or GPUs. A botnet is also not going to get you the high end GPUs you need for phase 2. Generally the people with hardcore GPUs are gamers and workstation users that push those GPUs. They're going to notice the GPUs being utilized abnormally. On top of that, the calculations they did were for a stupidly simple document modification in a type of document where hiding extraneous data is easy. This will get exponentially computationally more expensive the more data you want to mask. It took nine quintillion computations in order to mask a background color change in a PDF. And again, the main counter-point is being missed. Both the good and bad documents have to be brute forced which largely defeats the purpose. Tthose numbers of computing hours are a brute force. It may be a simplified brute force, but still a brute force. The hype being generated is causing management at many places to cry exactly what Google wanted, ?Wolf! Wolf!?. > On Mar 1, 2017, at 6:22 PM, valdis.kletnieks at vt.edu wrote: > > On Wed, 01 Mar 2017 15:28:23 -0600, "james.d--- via NANOG" said: > >> Those statistics are nowhere near real world for ROI. You'd have to invest >> at least 7 figures (USD) in resources. So the return must be millions of >> dollars before anyone can detect the attack. Except, it's already >> detectable. > > *Somebody* has to invest 7 figures in resources. Doesn't have to be you. > > Remember that if you have access to a 1M node botnet, you could have 56,940,000 > hours of CPU time racked racked up in... under 60 hours. > From rpug at lp0.org Thu Mar 2 02:22:52 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 01 Mar 2017 21:22:52 -0500 Subject: Consumer networking head scratcher Message-ID: <1488421372.1877590.897588408.51538B2E@webmail.messagingengine.com> On Wed, Mar 1, 2017, at 06:35 PM, Jean-Francois Mezei wrote: > On 2017-03-01 11:28, Ryan Pugatch wrote: > > > At random times, my Windows machines (Win 7 and Win 10, attached to the > > network via WiFi, 5GHz) lose connectivity to the Internet. > > > For what it's worth, the router is a Linksys EA7300 that I just picked > > up. > > > Way back when, I have a netgear router. It ended having a limit on its > NAT translation table, and when I had too many connections going at same > time (or not yet timed out), I would lose connection. There was an > unofficial patch to the firmware (litterally a patch in code that > defined table size) to increase that table to 1000- as I recall. > > Does the Linksys have a means to display the NAT translation table and > see if maybe connections are lost when that table is full and lots of > connections have not yet timed out ? > It doesn't seem to provide visibility into the NAT tables. However, I'm starting to think you might be on to something. The issue actually happened to my Mac tonight, and sure enough the traceroute dies at the same time. So, it isn't just the Windows machines impacted. I did a packet capture on my end, and on a server somewhere that I control and sent pings from my laptop to the server. The server received my ICMP packets and responded, but those responses never made it back to my laptop. Meanwhile, my Roku is actively streaming from the Internet, so it's not like the Internet was down. From oliver.oboyle at gmail.com Thu Mar 2 02:29:46 2017 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Wed, 1 Mar 2017 21:29:46 -0500 Subject: Consumer networking head scratcher In-Reply-To: <1488421372.1877590.897588408.51538B2E@webmail.messagingengine.com> References: <1488421372.1877590.897588408.51538B2E@webmail.messagingengine.com> Message-ID: Each device associated with the AP consumes memory. Small low-end routers don't typically come with much memory. If you've got a lot of devices associated with the AP you will run out of memory. I'm not sure how many devices you're connecting, though. Three will not cause this problem. 30 might. O. On Wed, Mar 1, 2017 at 9:22 PM, Ryan Pugatch wrote: > > > On Wed, Mar 1, 2017, at 06:35 PM, Jean-Francois Mezei wrote: > > On 2017-03-01 11:28, Ryan Pugatch wrote: > > > > > At random times, my Windows machines (Win 7 and Win 10, attached to the > > > network via WiFi, 5GHz) lose connectivity to the Internet. > > > > > For what it's worth, the router is a Linksys EA7300 that I just picked > > > up. > > > > > > Way back when, I have a netgear router. It ended having a limit on its > > NAT translation table, and when I had too many connections going at same > > time (or not yet timed out), I would lose connection. There was an > > unofficial patch to the firmware (litterally a patch in code that > > defined table size) to increase that table to 1000- as I recall. > > > > Does the Linksys have a means to display the NAT translation table and > > see if maybe connections are lost when that table is full and lots of > > connections have not yet timed out ? > > > > > It doesn't seem to provide visibility into the NAT tables. However, I'm > starting to think you might be on to something. > > The issue actually happened to my Mac tonight, and sure enough the > traceroute dies at the same time. So, it isn't just the Windows > machines impacted. > > I did a packet capture on my end, and on a server somewhere that I > control and sent pings from my laptop to the server. > > The server received my ICMP packets and responded, but those responses > never made it back to my laptop. > > Meanwhile, my Roku is actively streaming from the Internet, so it's not > like the Internet was down. > -- :o@> From rpug at lp0.org Thu Mar 2 02:31:58 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Wed, 01 Mar 2017 21:31:58 -0500 Subject: Consumer networking head scratcher In-Reply-To: References: <1488421372.1877590.897588408.51538B2E@webmail.messagingengine.com> Message-ID: <1488421918.1879242.897594704.37D04404@webmail.messagingengine.com> On Wed, Mar 1, 2017, at 09:29 PM, Oliver O'Boyle wrote: > Each device associated with the AP consumes memory. Small low-end > routers don't typically come with much memory. If you've got a lot of > devices associated with the AP you will run out of memory. I'm not > sure how many devices you're connecting, though. Three will not cause > this problem. 30 might. > > O. > Currently, I have 3 devices connected. :) From oliver.oboyle at gmail.com Thu Mar 2 02:55:51 2017 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Wed, 01 Mar 2017 21:55:51 -0500 Subject: Consumer networking head scratcher Message-ID: <4jvv7uclu8pysdhrfj5mcnqo.1488423351405@email.android.com> Next --> On March 1, 2017, at 9:31 PM, Ryan Pugatch wrote: On Wed, Mar 1, 2017, at 09:29 PM, Oliver O'Boyle wrote: Each device associated with the AP consumes memory. Small low-end routers don't typically come with much memory. If you've got a lot of devices associated with the AP you will run out of memory. I'm not sure how many devices you're connecting, though. Three will not cause this problem. 30 might. O. Currently, I have 3 devices connected. :) From nick at foobar.org Thu Mar 2 03:42:12 2017 From: nick at foobar.org (Nick Hilliard) Date: Thu, 02 Mar 2017 03:42:12 +0000 Subject: SHA1 collisions proven possisble In-Reply-To: References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> Message-ID: <58B79494.6080909@foobar.org> James DeVincentis via NANOG wrote: > On top of that, the calculations they did were for a stupidly simple > document modification in a type of document where hiding extraneous > data is easy. This will get exponentially computationally more > expensive the more data you want to mask. It took nine quintillion > computations in order to mask a background color change in a PDF. > > And again, the main counter-point is being missed. Both the good and > bad documents have to be brute forced which largely defeats the > purpose. Tthose numbers of computing hours are a brute force. It may > be a simplified brute force, but still a brute force. > > The hype being generated is causing management at many places to cry > exactly what Google wanted, ?Wolf! Wolf!?. The Reaction state table described in https://valerieaurora.org/hash.html appears to be entertainingly accurate. Nick From mpalmer at hezmatt.org Thu Mar 2 03:49:12 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 2 Mar 2017 14:49:12 +1100 Subject: SHA1 collisions proven possisble In-Reply-To: <58B79494.6080909@foobar.org> References: <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> <58B79494.6080909@foobar.org> Message-ID: <20170302034912.GN7463@hezmatt.org> On Thu, Mar 02, 2017 at 03:42:12AM +0000, Nick Hilliard wrote: > James DeVincentis via NANOG wrote: > > On top of that, the calculations they did were for a stupidly simple > > document modification in a type of document where hiding extraneous > > data is easy. This will get exponentially computationally more > > expensive the more data you want to mask. It took nine quintillion > > computations in order to mask a background color change in a PDF. > > > > And again, the main counter-point is being missed. Both the good and > > bad documents have to be brute forced which largely defeats the > > purpose. Tthose numbers of computing hours are a brute force. It may > > be a simplified brute force, but still a brute force. > > > > The hype being generated is causing management at many places to cry > > exactly what Google wanted, ?Wolf! Wolf!?. > > The Reaction state table described in > https://valerieaurora.org/hash.html appears to be entertainingly accurate. With particular reference to the "slashdotter" column. - Matt From james.d at hexhost.net Thu Mar 2 03:50:32 2017 From: james.d at hexhost.net (James DeVincentis) Date: Wed, 1 Mar 2017 21:50:32 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <58B79494.6080909@foobar.org> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> <58B79494.6080909@foobar.org> Message-ID: I like the footnote they attached specifically for SHA1. "[3] Google spent 6500 CPU years and 110 GPU years to convince everyone we need to stop using SHA-1 for security critical applications. Also because it was cool." It?s also not preimage. This isn?t even a FIRST preimage attack. That table needs an additional field type: ?First non-preimage deliberate crafted collision created?. However, it proves a theory that maybe with some refining *could* turn into a preimage attack. Realistically any hash function *will* have collisions when two items are specifically crafted to collide after expending insane amounts of computing power, money, and? i wonder how much in power they burned for this little stunt. > On Mar 1, 2017, at 9:42 PM, Nick Hilliard wrote: > > James DeVincentis via NANOG wrote: >> On top of that, the calculations they did were for a stupidly simple >> document modification in a type of document where hiding extraneous >> data is easy. This will get exponentially computationally more >> expensive the more data you want to mask. It took nine quintillion >> computations in order to mask a background color change in a PDF. >> >> And again, the main counter-point is being missed. Both the good and >> bad documents have to be brute forced which largely defeats the >> purpose. Tthose numbers of computing hours are a brute force. It may >> be a simplified brute force, but still a brute force. >> >> The hype being generated is causing management at many places to cry >> exactly what Google wanted, ?Wolf! Wolf!?. > > The Reaction state table described in > https://valerieaurora.org/hash.html appears to be entertainingly accurate. > > Nick From james.d at hexhost.net Thu Mar 2 04:57:06 2017 From: james.d at hexhost.net (James DeVincentis) Date: Wed, 1 Mar 2017 22:57:06 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <20170302034912.GN7463@hezmatt.org> References: <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> <58B79494.6080909@foobar.org> <20170302034912.GN7463@hezmatt.org> Message-ID: <282798BA-220B-48D9-8800-AF1C5BF0131E@hexhost.net> Let me add some context to the discussion. I run threat and vulnerability management for a large financial institution. This attack falls under our realm. We?ve had a plan in progress for several years to migrate away from SHA-1. We?ve been carefully watching the progression of the weakening of SHA-1 as computing power has increased and access to large-scale computing has become standard over the last 5 years. This does nothing to change our timeline. The attack does nothing to prove anything we already didn?t know. As computing power increases we must change hashing mechanisms every few years. This is why this is no surprise to us in the security sphere. However the presentation of this particular information has been following a very troublesome trend we?ve been seeing in the security sphere. Naming a vulnerability something silly but easily rememberable by management types. ?HeartBleed?, ?Shattered?, ?CloudBleed?, ?SomethingBleed?? This is a publicity stunt by Google to whip up a hype and it worked. Case in point, are some of the posts in this thread that completely dismiss fact for assumption and embellishment. With specific regard to SSL certificates: "Are TLS/SSL certificates at risk? Any Certification Authority abiding by the CA/Browser Forum regulations is not allowed to issue SHA-1 certificates anymore. Furthermore, it is required that certificate authorities insert at least 64 bits of randomness inside the serial number field. If properly implemented this helps preventing a practical exploitation.? (https://shattered.it/ ). It seems not all of the news outlets read the entire page before typing up a sensationalist post claiming all your data is at risk suddenly. Here?s why this is sensationalist. If anyone with *actual* hands-on work in the *security* sphere in *recent* years disagrees, I?ll be happy to discuss. - Hardened SHA1 exists to prevent this exact type of attack. - Every hash function will eventually have collisions. It?s literally impossible to create a hashing function that will never have a collision. There are an infinite number of inputs that can go into a hash function. There are a finite number of outputs of a hash function. Hash functions create an implausibility of a collision. That?s it. There is no 100% certainty that any hash function will not have collisions. - Google created a weak example. The difference in the document they generated was a background color. They didn?t even go a full RGBA difference. They went from Red to Blue. That?s a difference of 4 bytes (R and B values). It took them nine quintillion computations to generate the correct spurious data to create a collision when they controlled both the documents with a 4 byte difference. That spurious data inflated the PDF by at least a few hundred KB. Imagine the computations it would take for the examples they give? Anyone know? No. They didn?t dare attempt it because they knew it?s not possible. - This wasn?t even an attack on a cryptographic method that utilizes SHA1. This was a unique identifier / integrity attack. Comparing an SHA1 hash is not the correct way to verify authenticity of a document. Comparing an SHA1 how you verify integrity of a document, looking for corruption. Authenticity is derived from having the data signed from a trusted source or encrypted using say PGP from a trusted source. - And last but not least.. which takes all of the bite out of the attack. Google also showed it was easily detectable. Is a weakness or attack on a hash function really viable of it?s easily and readily detectable? No. It?s not. (See: IDS, WAFs: They filter and detect attacks against systems that may be vulnerable and prevent them by checking for the attacks). So If I see a hash collision? I?ll modify the algorithm? Wait.. This sounds awfully familiar.. Oh yea? Hardened SHA1. With all of these reasons all wrapped up. It clearly shows the level of hype around this attack is the result of sensationalist articles and clickbait titles. It also appears the majority of those who embrace fact also abandoned this thread fairly early once it began to devolve into embracing sensationalism. I?m going to join them. *micdrop* *unsubscribe* > On Mar 1, 2017, at 9:49 PM, Matt Palmer wrote: > > On Thu, Mar 02, 2017 at 03:42:12AM +0000, Nick Hilliard wrote: >> James DeVincentis via NANOG wrote: >>> On top of that, the calculations they did were for a stupidly simple >>> document modification in a type of document where hiding extraneous >>> data is easy. This will get exponentially computationally more >>> expensive the more data you want to mask. It took nine quintillion >>> computations in order to mask a background color change in a PDF. >>> >>> And again, the main counter-point is being missed. Both the good and >>> bad documents have to be brute forced which largely defeats the >>> purpose. Tthose numbers of computing hours are a brute force. It may >>> be a simplified brute force, but still a brute force. >>> >>> The hype being generated is causing management at many places to cry >>> exactly what Google wanted, ?Wolf! Wolf!?. >> >> The Reaction state table described in >> https://valerieaurora.org/hash.html appears to be entertainingly accurate. > > With particular reference to the "slashdotter" column. > > - Matt > From rdobbins at arbor.net Thu Mar 2 05:24:38 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 2 Mar 2017 12:24:38 +0700 Subject: Consumer networking head scratcher In-Reply-To: <4jvv7uclu8pysdhrfj5mcnqo.1488423351405@email.android.com> References: <4jvv7uclu8pysdhrfj5mcnqo.1488423351405@email.android.com> Message-ID: <967E3441-E0A4-42DD-A424-DF97C19D5560@arbor.net> On 2 Mar 2017, at 9:55, Oliver O'Boyle wrote: > Currently, I have 3 devices connected. :) You could have one or more botted machines launching outbound DDoS attacks, potentially filling up the NAT translation table and/or getting squelched by your broadband access provider with layer-4 granularity. And the boxes themselves could be churning away due to being compromised (look at CPU and memory stats over time). Aggressive horizontal scanning is often a hallmark of botted machines, and it can interrupt normal network access on the botted hosts themselves. I don't actually think that's the case, given the symptomology you report, but just wanted to put it out there for the list archive. What about DNS issues? Are you sure that you really have a networking issue, or are you having intermittent DNS resolution problems caused by flaky/overloaded/attacked recursivs, EDNS0 problems (i.e., filtering on DNS responses > 512 bytes), or TCP/53 blockage? Different host OSes/browsers/apps exhibit differing re-query characteristics. Are the Windows boxes and the other boxes set to use the same recursors? Can you resolve DNS requests during the outages? Are your boxes statically-addressed, or are they using DHCP? Periodically-duplicate IPs can cause intermittent symptoms, too. If you're using the consumer router as a DHCP server, DHCP-lease nonsense could be a contributing factor. Are the Windows boxes running some common application/service which updates and/or churns periodically? Are they members of a Windows workgroup? All kinds of strange name-resolution stuff goes on with Windows-specific networking. Also, be sure to use -n with traceroute. tcptraceroute is useful, too. netstat -rn should work on Windows boxes, IIRC. ----------------------------------- Roland Dobbins From royce at techsolvency.com Thu Mar 2 05:25:18 2017 From: royce at techsolvency.com (Royce Williams) Date: Wed, 1 Mar 2017 20:25:18 -0900 Subject: SHA1 collisions proven possisble In-Reply-To: <282798BA-220B-48D9-8800-AF1C5BF0131E@hexhost.net> References: <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> <58B79494.6080909@foobar.org> <20170302034912.GN7463@hezmatt.org> <282798BA-220B-48D9-8800-AF1C5BF0131E@hexhost.net> Message-ID: On Wed, Mar 1, 2017 at 7:57 PM, James DeVincentis via NANOG wrote: [ reasonable analysis snipped :) ] > With all of these reasons all wrapped up. It clearly shows the level of hype around this attack is the result of sensationalist articles and clickbait titles. I have trouble believing that Sleevi, Whalley et al spent years championing the uphill slog of purging the global web PKI infrastructure of SHA-1 to culminate in a flash-in-the-pan clickbait party. Instead, consider how long it has historically taken to pry known-to-be-weak hashes and crypto from entrenched implementations. If this round of hype actually scares CxOs and compliance bodies into doing The Right Thing in advance ... then the hype doesn't bother me in the slightest. Royce From cra at WPI.EDU Thu Mar 2 05:45:14 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 2 Mar 2017 00:45:14 -0500 Subject: Consumer networking head scratcher In-Reply-To: <967E3441-E0A4-42DD-A424-DF97C19D5560@arbor.net> References: <4jvv7uclu8pysdhrfj5mcnqo.1488423351405@email.android.com> <967E3441-E0A4-42DD-A424-DF97C19D5560@arbor.net> Message-ID: <20170302054514.GK31731@angus.ind.wpi.edu> On Thu, Mar 02, 2017 at 12:24:38PM +0700, Roland Dobbins wrote: > On 2 Mar 2017, at 9:55, Oliver O'Boyle wrote: > > >Currently, I have 3 devices connected. :) > > What about DNS issues? Are you sure that you really have a > networking issue, or are you having intermittent DNS resolution > problems caused by flaky/overloaded/attacked recursivs, EDNS0 This reminded me of another possibility related to NAT table exhaustion. Are you running a full recursive resolver on a system behind the NAT? Especially one like unbound possibly w/dnssec? I had some strange issues caused during the time when unbound was priming its cache from a cold start... From alter3d at alter3d.ca Thu Mar 2 05:45:21 2017 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 2 Mar 2017 00:45:21 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> <58B79494.6080909@foobar.org> Message-ID: <8eea94c4-e43c-125d-f486-5da5c5abc188@alter3d.ca> On 3/1/2017 10:50 PM, James DeVincentis via NANOG wrote: > Realistically any hash function *will* have collisions when two items are specifically crafted to collide after expending insane amounts of computing power, money, and? i wonder how much in power they burned for this little stunt. Easy enough to estimate. A dual-socket server with 2 X5675 CPUs (12 cores total) draws about 225W under full load, or about 18.75W per core. 0.01875 kW * 8766 h/y * 6500 y = about 1,070,000 kWh For the GPU side, an NVIDIA Tesla K80 GPU accelerator draws 300W at full load. 0.3 kW * 8766 h/y * 110 y = about 290,000 kWh. So the total calculation consumed about 1.36M kWh. A quick Google search tells me the US national average industrial rate for electricity is $0.0667/kWh, for a cost of $90,712. That's not counting AC-DC conversion loss, or the power to run the cooling. Or the cost of the hardware, though it's fair to assume that in Google's case they didn't have to buy any new hardware just for this. From aaron1 at gvtc.com Wed Mar 1 18:23:24 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 1 Mar 2017 12:23:24 -0600 Subject: Consumer networking head scratcher In-Reply-To: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> Message-ID: <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> That's strange... it's like the TTL on all Windows IP packets are decrementing more and more as time goes on causing you to get less and less hops into the internet I wonder if it's a bug/virus/malware affecting only your windows computers. -Aaron From aaron1 at gvtc.com Wed Mar 1 18:32:36 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 1 Mar 2017 12:32:36 -0600 Subject: Consumer networking head scratcher In-Reply-To: <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> <1488392829.81700.897138240.34093D91@webmail.messagingengine.com> Message-ID: <000001d292ba$339ceba0$9ad6c2e0$@gvtc.com> What's the old router make/model ? What's the new router make/model ? -Aaron -----Original Message----- From: Ryan Pugatch [mailto:rpug at lp0.org] Sent: Wednesday, March 1, 2017 12:27 PM To: Aaron Gould ; nanog at nanog.org Subject: Re: Consumer networking head scratcher The issue doesn't happen with my previous router, and I've tested multiple computers (one that isn't mine.) It doesn't seem like it decrements over time.. it just dies sooner as I trace further up the path. I can consistently die at the 7th hop if I try to go to Google, but if I trace to the 6th hop, it'll die at the 5th hop! On Wed, Mar 1, 2017, at 01:23 PM, Aaron Gould wrote: > That's strange... it's like the TTL on all Windows IP packets are > decrementing more and more as time goes on causing you to get less and > less hops into the internet > > I wonder if it's a bug/virus/malware affecting only your windows > computers. > > -Aaron > > From aaron1 at gvtc.com Thu Mar 2 12:39:38 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 2 Mar 2017 06:39:38 -0600 Subject: Consumer networking head scratcher In-Reply-To: <20170302054514.GK31731@angus.ind.wpi.edu> References: <4jvv7uclu8pysdhrfj5mcnqo.1488423351405@email.android.com> <967E3441-E0A4-42DD-A424-DF97C19D5560@arbor.net> <20170302054514.GK31731@angus.ind.wpi.edu> Message-ID: <000201d29352$0e81bab0$2b853010$@gvtc.com> Nat translation limits might not only be related to his first hop nat device In the home, but these days with the exhaustion of ipv4, the second hop carrier grade nat (cgnat) device in his upstream provider could be limiting also. I run a cgnat for an isp and allow 2500 ports per customer private address, and time out those translations at 120 seconds. It's possible to hit a limit there. I see it sometimes. -Aaron From paula.wang at icann.org Wed Mar 1 20:15:26 2017 From: paula.wang at icann.org (Paula Wang) Date: Wed, 1 Mar 2017 12:15:26 -0800 Subject: IANA IPv4 Recovered Address Space registry updated Message-ID: <356EC437-1FA4-49B4-815E-A5C8B232B33B@icann.org> Hi, An update has been made to the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA (https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-05-08-en). The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ Kind regards, Paula Wang IANA Services Specialist PTI From mark.wiater at greybeam.com Wed Mar 1 21:18:28 2017 From: mark.wiater at greybeam.com (Mark Wiater) Date: Wed, 1 Mar 2017 16:18:28 -0500 Subject: Consumer networking head scratcher In-Reply-To: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> Message-ID: <9d3d650a-b23c-6315-ad9e-a61496b081cf@greybeam.com> On 3/1/2017 11:28 AM, Ryan Pugatch wrote: > At random times, my Windows machines (Win 7 and Win 10, attached to the > network via WiFi, 5GHz) lose connectivity to the Internet. They can > continue to access internal resources, such as the router's admin > interface. To the point of Windows reporting no internet access, MS does two things to determine if the machine has internet access, as outlined here. https://technet.microsoft.com/en-us/library/cc766017(v=ws.10).aspx (I think that's still valid) From a console, can these two machines do the http request and the dns lookup when they tell you they're offline? Can the other machines do these two things when the Windows machines can't or when the windows machines report offline? From nanog at ics-il.net Thu Mar 2 14:01:34 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 2 Mar 2017 08:01:34 -0600 (CST) Subject: google ipv6 routes via cogent In-Reply-To: <001801d28f7e$d063ac10$712b0430$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Message-ID: <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> http://bfy.tw/AOcZ There's even a NANOG thread or two in there. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Aaron" To: nanog at nanog.org Sent: Saturday, February 25, 2017 9:49:56 AM Subject: google ipv6 routes via cogent Hi, I'm new to the nanog list, hope this isn't out of scope for what is usually discussed here. Cogent is telling me that I can't route through cogent to get to google ipv6 routes (particularly the well known dns addresses 2001:4860:4860::88xx) because google decided not to advertise those route to one of their mutual peers. Anyone know anything about this ? .and why it happened and when it will be resolved ? -Aaron From marty at cloudflare.com Thu Mar 2 14:05:11 2017 From: marty at cloudflare.com (Marty Strong) Date: Thu, 2 Mar 2017 14:05:11 +0000 Subject: google ipv6 routes via cogent In-Reply-To: <001801d28f7e$d063ac10$712b0430$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Message-ID: <579332DA-2B0E-4522-8F26-5DB31BD10948@cloudflare.com> Cogent refuses to settlement-free peer on IPv6 to Google and Hurricane Electric. The problem *in my mind* rests with Cogent trying to extract $$$ from said parties. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 25 Feb 2017, at 15:49, Aaron wrote: > > Hi, I'm new to the nanog list, hope this isn't out of scope for what is > usually discussed here. > > > > Cogent is telling me that I can't route through cogent to get to google ipv6 > routes (particularly the well known dns addresses 2001:4860:4860::88xx) > because google decided not to advertise those route to one of their mutual > peers. > > > > Anyone know anything about this ? .and why it happened and when it will be > resolved ? > > > > -Aaron > > > > > From jlewis at lewis.org Thu Mar 2 14:07:01 2017 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 2 Mar 2017 09:07:01 -0500 (EST) Subject: google ipv6 routes via cogent In-Reply-To: <001801d28f7e$d063ac10$712b0430$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Message-ID: On Sat, 25 Feb 2017, Aaron wrote: > Hi, I'm new to the nanog list, hope this isn't out of scope for what is > usually discussed here. > > > > Cogent is telling me that I can't route through cogent to get to google ipv6 > routes (particularly the well known dns addresses 2001:4860:4860::88xx) > because google decided not to advertise those route to one of their mutual > peers. > > Anyone know anything about this ? .and why it happened and when it will be > resolved ? Google wants Cogent to peer with them. Cogent wants Google to buy transit or use another transit provider to reach Cogent. Check the archives for the dead horse. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From davidbass570 at gmail.com Thu Mar 2 14:08:41 2017 From: davidbass570 at gmail.com (David Bass) Date: Thu, 2 Mar 2017 09:08:41 -0500 Subject: Consumer networking head scratcher In-Reply-To: <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> Message-ID: This all goes away when he reconnects his old router from what I remember... If that is the case, then I would concentrate my effort on the new router, and its functionality (or lack of). Could be something simple that you are missing on it as a setting, or assuming it works a certain way when it does not. Sometimes these devices can be counter intuitive. On Wed, Mar 1, 2017 at 1:23 PM, Aaron Gould wrote: > That's strange... it's like the TTL on all Windows IP packets are > decrementing more and more as time goes on causing you to get less and less > hops into the internet > > I wonder if it's a bug/virus/malware affecting only your windows computers. > > -Aaron > > > From olivier.benghozi at wifirst.fr Thu Mar 2 14:11:14 2017 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 2 Mar 2017 15:11:14 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <001801d28f7e$d063ac10$712b0430$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Message-ID: Due to various peering disputes (notably with Hurricane Electric) Cogent just don't have all the routes in IPv6 (and should be regarded as a partial IPv6 transit only). One should not rely only on Cogent for its transit, anyway :) Don't count on any improvement soon. It was already discussed here one year ago... > On 25 feb. 2017 at 16:49, Aaron wrote : > > Cogent is telling me that I can't route through cogent to get to google ipv6 > routes (particularly the well known dns addresses 2001:4860:4860::88xx) > because google decided not to advertise those route to one of their mutual > peers. > > Anyone know anything about this ? .and why it happened and when it will be > resolved ? From faisal at snappytelecom.net Thu Mar 2 14:23:30 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 2 Mar 2017 14:23:30 +0000 (GMT) Subject: google ipv6 routes via cogent In-Reply-To: <001801d28f7e$d063ac10$712b0430$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Message-ID: <1834800172.1965561.1488464610096.JavaMail.zimbra@snappytelecom.net> Just Google for it.. this is probably one of the oldest running Klan dispute in the industry.. http://www.datacenterknowledge.com/archives/2009/10/22/peering-disputes-migrate-to-ipv6/ Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Aaron" > To: "nanog list" > Sent: Saturday, February 25, 2017 10:49:56 AM > Subject: google ipv6 routes via cogent > Hi, I'm new to the nanog list, hope this isn't out of scope for what is > usually discussed here. > > > > Cogent is telling me that I can't route through cogent to get to google ipv6 > routes (particularly the well known dns addresses 2001:4860:4860::88xx) > because google decided not to advertise those route to one of their mutual > peers. > > > > Anyone know anything about this ? .and why it happened and when it will be > resolved ? > > > > -Aaron From mysidia at gmail.com Thu Mar 2 14:26:32 2017 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 2 Mar 2017 08:26:32 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <282798BA-220B-48D9-8800-AF1C5BF0131E@hexhost.net> References: <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> <58B79494.6080909@foobar.org> <20170302034912.GN7463@hezmatt.org> <282798BA-220B-48D9-8800-AF1C5BF0131E@hexhost.net> Message-ID: On Wed, Mar 1, 2017 at 10:57 PM, James DeVincentis via NANOG wrote: > Let me add some context to the discussion. > With specific regard to SSL certificates: "Are TLS/SSL certificates at risk? Any Certification > Authority abiding by the CA/Browser Forum regulations is not allowed to issue SHA-1 certificates > anymore. Furthermore, it is required that certificate authorities insert at least 64 bits of randomness > inside the serial number field. If properly implemented this helps preventing a practical exploitation.? Yes, they are at risk, of course. This latest technique does not appear able to be used to attack certificates, however. Subscribers to a CA don't have sufficient control of the contents of the signed certificates a CA will issue; Even if they did, the computational requirement with the described attack is likely to be slightly out of reach. The attack is not such that certs can be directly spoiled, *YET*; However, It is almost surely a high likely possibility in the forseeable future, and the existence of this attack does serve as valid evidence further solidifying that the risk is very High now for crypto applications of the SHA1 digest, of further collision attacks against SHA1 being made practical in the forseeable future with very little or no further warning. If you are still using SHA1 and were expecting to use it forever.... This attack is what gives you your fair warning, that in 6 or 7 years, brute-forcing your SHA1 will likely be within reach of the average script kiddie. This does not fundamentally change security expectations for SHA1, such attack now being feasible with Google's resources is well-within expectations; However, the "Hype" should be a wake-up call to some developers who continue to write new software relying upon SHA1 for security under a false belief that SHA1 digest is still almost certain to be fundamentally sound crypto for many years to come. If you are writing a program expected to be in use 5 years from now, and believe SHA1 will continue to meet your existing security requirements. time to rethink that, and realize the risk is very high for SHA1 becoming insecure within a decade. If the "Hype" behind this Google thing is the catalyst that makes some developers think about the future of their choice of crypto algorithms more carefully before relying upon them, then that is a good thing. > - Hardened SHA1 exists to prevent this exact type of attack. I suppose hardened SHA1 is a non-standard kludge of questionable durability. Sure, implement as a work-around for the current attack. But the future-going risk of continuing to use SHA1 remains qualitatively high. > - Every hash function will eventually have collisions. It?s literally impossible > to create a hashing function that will never have a collision. [snip] There may be hashing functions which are likely to never have a practical collision discovered by humans, because of their size and improbability. It's mostly a matter of the computing power currently available VS size and qualities of the hash. > - Google created a weak example. The difference in the document they generated was a background color. They didn?t even go a full RGBA difference. They went from Red to Blue. That?s a difference of 4 bytes (R and B values). It took them nine quintillion computations to generate the With some applications; you'd be surprised what evil things you can do if you change 4 Bytes to a malicious value..... For example; If you're digitally signing a binary, 4 Bytes is maybe enough to overwrite a machine language instruction, introducing an exploitable bug into the machine code. That latest attack on SHA1 will not allow code signing following typical code signing algorithms to be attacked. -- -JH From alarig at swordarmor.fr Thu Mar 2 14:52:37 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Thu, 2 Mar 2017 15:52:37 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <001801d28f7e$d063ac10$712b0430$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Message-ID: <20170302145237.35ljpo2uszo3s2aj@mew.swordarmor.fr> On sam. 25 f?vr. 09:49:56 2017, Aaron wrote: > Hi, I'm new to the nanog list, hope this isn't out of scope for what is > usually discussed here. > > > > Cogent is telling me that I can't route through cogent to get to google ipv6 > routes (particularly the well known dns addresses 2001:4860:4860::88xx) > because google decided not to advertise those route to one of their mutual > peers. > > > > Anyone know anything about this ? .and why it happened and when it will be > resolved ? > > > > -Aaron Hi, Cogent is not able to receive traffic from Google since February 2016, the case is the same with HE since 2010. So, as a quick workaround, you have to connect your network to another IPv6 transit operator for these destinations. I you don?t have this possibility, you can set up an IPv6-in-IPv4 tunnel to HE; the IPv4 traffic flows normally. -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Mar 2 15:29:29 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Mar 2017 10:29:29 -0500 Subject: google ipv6 routes via cogent In-Reply-To: <20170302145237.35ljpo2uszo3s2aj@mew.swordarmor.fr> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <20170302145237.35ljpo2uszo3s2aj@mew.swordarmor.fr> Message-ID: On Thu, Mar 2, 2017 at 9:52 AM, Alarig Le Lay wrote: > On sam. 25 f?vr. 09:49:56 2017, Aaron wrote:Hi, > > Cogent is not able to receive traffic from Google since February 2016, > the case is the same with HE since 2010. > > I think maybe that wording isn't quite correct: "is not able to receive traffic from ...' isn't really what's going on is it? I mean, it's not like the interfaces aren't able to push packets, is it? From DannSchuler at hotmail.com Thu Mar 2 15:32:53 2017 From: DannSchuler at hotmail.com (Dann Schuler) Date: Thu, 2 Mar 2017 15:32:53 +0000 Subject: Consumer networking head scratcher In-Reply-To: References: <1488385725.3397306.896983592.15ECEEBE@webmail.messagingengine.com> <002401d292b8$ea5236e0$bef6a4a0$@gvtc.com> Message-ID: Just a quick sanity check here since I know we can occasionally overlook the simple things. You have updated the firmware to the latest available version correct? Have you checked for any odd services like QoS, parental controls or an IDS? Have you tried wiping it to factory default and reconfiguring it? What happens if you give the affected machine a new IP? Could it be some service on the device affecting that specific IP? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Bass Sent: Thursday, March 2, 2017 9:09 AM To: Aaron Gould Cc: Subject: Re: Consumer networking head scratcher This all goes away when he reconnects his old router from what I remember... If that is the case, then I would concentrate my effort on the new router, and its functionality (or lack of). Could be something simple that you are missing on it as a setting, or assuming it works a certain way when it does not. Sometimes these devices can be counter intuitive. On Wed, Mar 1, 2017 at 1:23 PM, Aaron Gould wrote: > That's strange... it's like the TTL on all Windows IP packets are > decrementing more and more as time goes on causing you to get less and > less hops into the internet > > I wonder if it's a bug/virus/malware affecting only your windows computers. > > -Aaron > > > From aaron1 at gvtc.com Thu Mar 2 15:48:03 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 2 Mar 2017 09:48:03 -0600 Subject: google ipv6 routes via cogent In-Reply-To: <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> Message-ID: <002201d2936c$61011e60$23035b20$@gvtc.com> Thanks everyone, and my apologies. After I sent that email to you all, I did google for it and found that this has been a problem since ~ February 2016. Dang, that long?! In that case, I'm shutting down my ipv6 neighboring with cogent. I have 2 other inet v6 connections. I only learn 0/0 from all 3 isp's and I am not controlling which packets outbound where. I may change that and learn their prefixes and their peers, and then re-enable my cogent ipv6 bgp session then, but until then, I'm leaving it down. Thanks again y'all. RP/0/RSP0/CPU0:9k#sh bgp vrf one ipv6 unicast summary .... Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 140 140 140 140 140 140 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd abcd:1234:efab:1212:1:1 0 174 55615 55615 0 0 0 17:35:34 Idle (Admin) -Aaron From aaron1 at gvtc.com Thu Mar 2 16:05:20 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 2 Mar 2017 10:05:20 -0600 Subject: google ipv6 routes via cogent In-Reply-To: <002201d2936c$61011e60$23035b20$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> Message-ID: <006001d2936e$cb058d30$6110a790$@gvtc.com> Correction... ::/0 is what I learn from those 3 :) From rpug at lp0.org Thu Mar 2 16:13:46 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Thu, 02 Mar 2017 11:13:46 -0500 Subject: Consumer networking head scratcher Message-ID: <1488471226.537655.898257136.4D85F401@webmail.messagingengine.com> On Thu, Mar 2, 2017, at 10:32 AM, Dann Schuler wrote: > Just a quick sanity check here since I know we can occasionally overlook > the simple things. You have updated the firmware to the latest available > version correct? Have you checked for any odd services like QoS, > parental controls or an IDS? Have you tried wiping it to factory default > and reconfiguring it? > > What happens if you give the affected machine a new IP? Could it be some > service on the device affecting that specific IP? > Yes, I've done all of these. It was running the latest version of code and I even tried rolling back. Disabled SPI firewalls, ipv6, verified QoS and parental controls are off, etc. The issue impacts multiple device so doesn't appear specific to one IP. Thanks From tom.kac at gmail.com Thu Mar 2 17:00:04 2017 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Thu, 2 Mar 2017 11:00:04 -0600 Subject: Call for Presentations - CHI-NOG 07 (May 18th) Message-ID: CHI-NOG 07 ? (Chicago Network Operators Group) May 18th 2017, Chicago, IL The Chicago Network Operators Group (CHI-NOG) is a vendor neutral organization. Our goal is to create a regional community of network professionals by presenting the latest technology trends, enabling collaboration and providing networking opportunities. CHI-NOG will be hosting its seventh annual conference on May 18th, 2017 in downtown Chicago. For more information on the conference please see event?s page (http://chinog.org/meetings/chi-nog-07/). The CHI-NOG Program Committee is seeking proposals for presentations on relevant networking technologies with a focus on the following topics: * Network Automation/ DevOps * Interconnection/Peering * Low Latency Networks/Financial Networks * Network Security * Academic Research in Networking and Related Infrastructure Fields. * Internet Monitoring * Advanced BGP/MPLS Technologies * Optical Networking/Data Center Interconnect * Content Delivery Networks (CDNs) * Software Defined Networking * Cloud Networking Technologies * Network Traffic Engineering * Open Source Networking Tools * Data Center Fabric * Wireless * IPv6 Session Format Each presentation is 30 minutes, which includes a question and answer time. The duration can be extended per individual request to 60 minutes and will be considered by the program committee. Presentations should not contain any marketing material and should avoid discussion of commercial products but rather focus on the underlying technology. Key Dates 3/24/2017 - Presentation Abstract Submission Deadline 3/31/2017 - Abstract Selection 4/15/2017 - Full Presentation Slides Submission Deadline 5/18/2017 - Conference Submission Please submit presentation?s abstract proposal by filling out the submission form at http://chinog.org/meetings/chi-nog-07/abstract-submission/ . Once your presentation is selected please provide the program committee with your photo and a short bio for web publication. All accepted speakers will receive complimentary tickets to the conference. For past presentation please see the archives at http://chinog.org/presentation-archive/. The program committee is looking forward to your submission and attendance. From rpug at lp0.org Thu Mar 2 17:00:30 2017 From: rpug at lp0.org (Ryan Pugatch) Date: Thu, 02 Mar 2017 12:00:30 -0500 Subject: Consumer networking head scratcher In-Reply-To: <967E3441-E0A4-42DD-A424-DF97C19D5560@arbor.net> References: <4jvv7uclu8pysdhrfj5mcnqo.1488423351405@email.android.com> <967E3441-E0A4-42DD-A424-DF97C19D5560@arbor.net> Message-ID: <1488474030.549219.898314128.6D939036@webmail.messagingengine.com> On Thu, Mar 2, 2017, at 12:24 AM, Roland Dobbins wrote: > On 2 Mar 2017, at 9:55, Oliver O'Boyle wrote: > > > Currently, I have 3 devices connected. :) > > You could have one or more botted machines launching outbound DDoS > attacks, potentially filling up the NAT translation table and/or getting > squelched by your broadband access provider with layer-4 granularity. > And the boxes themselves could be churning away due to being compromised > (look at CPU and memory stats over time). Aggressive horizontal > scanning is often a hallmark of botted machines, and it can interrupt > normal network access on the botted hosts themselves. > > I don't actually think that's the case, given the symptomology you > report, but just wanted to put it out there for the list archive. > > What about DNS issues? Are you sure that you really have a networking > issue, or are you having intermittent DNS resolution problems caused by > flaky/overloaded/attacked recursivs, EDNS0 problems (i.e., filtering on > DNS responses > 512 bytes), or TCP/53 blockage? Different host > OSes/browsers/apps exhibit differing re-query characteristics. Are the > Windows boxes and the other boxes set to use the same recursors? Can > you resolve DNS requests during the outages? > > Are your boxes statically-addressed, or are they using DHCP? > Periodically-duplicate IPs can cause intermittent symptoms, too. If > you're using the consumer router as a DHCP server, DHCP-lease nonsense > could be a contributing factor. > > Are the Windows boxes running some common application/service which > updates and/or churns periodically? Are they members of a Windows > workgroup? All kinds of strange name-resolution stuff goes on with > Windows-specific networking. > > Also, be sure to use -n with traceroute. tcptraceroute is useful, too. > netstat -rn should work on Windows boxes, IIRC. > > ----------------------------------- > Roland Dobbins It isn't a DNS issue as trying to access resources via IP address directly also have the issue. What became clear to me last night is that this actually also impacts my Mac, and that it has to do with traffic not properly making it back to my machines. When the issue occurs, my traffic makes it out to the destination, the destination responds, but that packet never makes it to my laptop, for example. I tested by sending traffic to a server I control and doing PCAPs on both ends. Thanks, Ryan From baldur.norddahl at gmail.com Thu Mar 2 17:20:31 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 2 Mar 2017 18:20:31 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <006001d2936e$cb058d30$6110a790$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> Message-ID: Shouldn't that be 2000::/3 ? Den 2. mar. 2017 17.06 skrev "Aaron Gould" : Correction... ::/0 is what I learn from those 3 :) From aaron1 at gvtc.com Thu Mar 2 18:36:04 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 2 Mar 2017 12:36:04 -0600 Subject: google ipv6 routes via cogent In-Reply-To: References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> Message-ID: <000001d29383$da01b6f0$8e0524d0$@gvtc.com> Well, I asked my (3) upstream providers to only send me a ipv6 default route and they sent me ::/0...here's one of them... RP/0/RSP0/CPU0: 9k#sh bgp vrf one ipv6 uni neighbors abcd:1234::1 routes Thu Mar 2 12:33:23.644 CST ... Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 10.101.0.2:1 (default for vrf one) *> ::/0 abcd:1234::1 0 1234 i Processed 1 prefixes, 1 paths -Aaron From alarig at swordarmor.fr Thu Mar 2 18:58:20 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Thu, 2 Mar 2017 19:58:20 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <000001d29383$da01b6f0$8e0524d0$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> Message-ID: <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > Well, I asked my (3) upstream providers to only send me a ipv6 default > route and they sent me ::/0...here's one of them... Why did you don?t ask for a full view? With that, you can easily deal with that kind of problem. -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From bryan at shout.net Thu Mar 2 19:11:53 2017 From: bryan at shout.net (Bryan Holloway) Date: Thu, 2 Mar 2017 13:11:53 -0600 Subject: Qwest/CenturyLink BGP contact? Message-ID: <93d5bc10-4b2b-412a-471d-035b5afac1f0@shout.net> Hello all, If someone from Qwest/Centurylink is lurking, could you contact me off-list? You are advertising a /24 out of a recently acquired /16, and I've been unsuccessful reaching anyone. Thanks! - bryan From jeff+nanog at waddellsolutions.com Thu Mar 2 19:12:40 2017 From: jeff+nanog at waddellsolutions.com (Jeff Waddell) Date: Thu, 2 Mar 2017 14:12:40 -0500 Subject: google ipv6 routes via cogent In-Reply-To: <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> Message-ID: Or at least ask for a full view from Cogent - then you won't get any routes they don't have On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay wrote: > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > route and they sent me ::/0...here's one of them... > > Why did you don?t ask for a full view? With that, you can easily deal > with that kind of problem. > > -- > alarig > From baldur.norddahl at gmail.com Thu Mar 2 19:30:37 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 2 Mar 2017 20:30:37 +0100 Subject: google ipv6 routes via cogent In-Reply-To: References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> Message-ID: That will have the effect of prioritizing Cogent routes as that would be more specific than the default routes from the other providers. Cogent are not that good that you would want to do that. Den 2. mar. 2017 20.16 skrev "Jeff Waddell" : Or at least ask for a full view from Cogent - then you won't get any routes they don't have On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay wrote: > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > route and they sent me ::/0...here's one of them... > > Why did you don?t ask for a full view? With that, you can easily deal > with that kind of problem. > > -- > alarig > From jeff+nanog at waddellsolutions.com Thu Mar 2 19:36:23 2017 From: jeff+nanog at waddellsolutions.com (Jeff Waddell) Date: Thu, 2 Mar 2017 14:36:23 -0500 Subject: google ipv6 routes via cogent In-Reply-To: References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> Message-ID: Ah - you are correct So - yeah what Alarig said - get full routes from all On Thu, Mar 2, 2017 at 2:30 PM, Baldur Norddahl wrote: > That will have the effect of prioritizing Cogent routes as that would be > more specific than the default routes from the other providers. Cogent are > not that good that you would want to do that. > > Den 2. mar. 2017 20.16 skrev "Jeff Waddell" com > >: > > Or at least ask for a full view from Cogent - then you won't get any routes > they don't have > > On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay > wrote: > > > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > > route and they sent me ::/0...here's one of them... > > > > Why did you don?t ask for a full view? With that, you can easily deal > > with that kind of problem. > > > > -- > > alarig > > > From aaron1 at gvtc.com Thu Mar 2 19:52:11 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 2 Mar 2017 13:52:11 -0600 Subject: google ipv6 routes via cogent In-Reply-To: References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> Message-ID: <000901d2938e$7be4d880$73ae8980$@gvtc.com> Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please. -Aaron From niels=nanog at bakker.net Thu Mar 2 19:57:35 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 2 Mar 2017 20:57:35 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <000901d2938e$7be4d880$73ae8980$@gvtc.com> References: <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <000901d2938e$7be4d880$73ae8980$@gvtc.com> Message-ID: <20170302195735.GD86663@excession.tpb.net> * aaron1 at gvtc.com (Aaron Gould) [Thu 02 Mar 2017, 20:52 CET]: >Yes, thanks, I am going to do that. But, is there a middle ground >between being default only and full routes ? Like is it >advantageous for me to ask for partial routes (like their routes and >direct peers and default route) ? This way I don't have millions of >routes but I guess only a few hundred thousand or less? Let me know >please. You should ask for full routes from all your providers + a default. Then you write per-upstream import policies to permit or deny specific subsets of the prefixes they announce to you. For example, you could accept all prefixes from Cogent and your other upstreams tagged with a BGP community indicating they're from customers, and accept default from all except Cogent to take care of the rest of the traffic while still pretty much sending traffic to downstream customers to their respective upstream. (Or you can accept default from all but also import networks with whom Cogent has no direct relationship from your other upstreams; but that's less failsafe.) Depending on what router hardware you have and what upstreams, you may have to filter out additional prefixes to not overflow its FIB. -- Niels. From cra at WPI.EDU Thu Mar 2 19:59:33 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 2 Mar 2017 14:59:33 -0500 Subject: google ipv6 routes via cogent In-Reply-To: References: <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> Message-ID: <20170302195932.GX6562@angus.ind.wpi.edu> Define "good" vs. "bad" transport of bits. As long as there is adequate bandwidth and low latency, who cares? On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote: > That will have the effect of prioritizing Cogent routes as that would be > more specific than the default routes from the other providers. Cogent are > not that good that you would want to do that. > > Den 2. mar. 2017 20.16 skrev "Jeff Waddell" >: > > Or at least ask for a full view from Cogent - then you won't get any routes > they don't have > > On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay wrote: > > > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > > route and they sent me ::/0...here's one of them... > > > > Why did you don?t ask for a full view? With that, you can easily deal > > with that kind of problem. From hf0002+nanog at uah.edu Thu Mar 2 20:06:55 2017 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Thu, 02 Mar 2017 20:06:55 +0000 Subject: google ipv6 routes via cogent In-Reply-To: <20170302195932.GX6562@angus.ind.wpi.edu> References: <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <20170302195932.GX6562@angus.ind.wpi.edu> Message-ID: I think the implication is that, on Cogent, there isn't. :) On Thu, Mar 2, 2017 at 14:00 Chuck Anderson wrote: > Define "good" vs. "bad" transport of bits. As long as there is > adequate bandwidth and low latency, who cares? > > On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote: > > That will have the effect of prioritizing Cogent routes as that would be > > more specific than the default routes from the other providers. Cogent > are > > not that good that you would want to do that. > > > > Den 2. mar. 2017 20.16 skrev "Jeff Waddell" < > jeff+nanog at waddellsolutions.com > > >: > > > > Or at least ask for a full view from Cogent - then you won't get any > routes > > they don't have > > > > On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay > wrote: > > > > > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > > > Well, I asked my (3) upstream providers to only send me a ipv6 > default > > > > route and they sent me ::/0...here's one of them... > > > > > > Why did you don?t ask for a full view? With that, you can easily deal > > > with that kind of problem. > From valdis.kletnieks at vt.edu Thu Mar 2 22:28:52 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 02 Mar 2017 17:28:52 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <282798BA-220B-48D9-8800-AF1C5BF0131E@hexhost.net> References: <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> <20170301193416.GS7463@hezmatt.org> <00e301d292d2$c1f6f360$45e4da20$@hexhost.net> <43912.1488414147@turing-police.cc.vt.edu> <58B79494.6080909@foobar.org> <20170302034912.GN7463@hezmatt.org> <282798BA-220B-48D9-8800-AF1C5BF0131E@hexhost.net> Message-ID: <93871.1488493732@turing-police.cc.vt.edu> On Wed, 01 Mar 2017 22:57:06 -0600, James DeVincentis via NANOG said: > - Google created a weak example. The difference in the document they > generated was a background color. They didn???t even go a full RGBA difference. > They went from Red to Blue. That???s a difference of 4 bytes (R and B values). It > took them nine quintillion computations to generate the correct spurious data > to create a collision when they controlled both the documents with a 4 byte > difference. That spurious data inflated the PDF by at least a few hundred KB. Note that we haven't actually seen the algorithm yet. And it's quite possible that Google intentionally limited it to a *very visible* 4 byte change, so that just opening a PDF viewer of both documents is sufficient to demonstrate that a change was made. As a result, we can't rule out the possibility that "size of altered data plus/ times size of spurious data" equals a constant - in other words, limiting the change to 4 bytes causes a lot of spurious data, but careful choice of a larger number of altered bits results in a smaller spurious pile of bits. It *may* be possible to totally stash all the spurious bits elsewhere in the object via steganographic means - consider for instance a video stream. It may be possible to splice in/out a significant segment of video (possibly CGI'ed), and hide all the spurious bits in one/two bit changes in the rest of the stream. Remember that in a good hash function, changing one input bit should on average change close to half the output bits. So how many bits get changed by 2, or 3, or 4 bit of input change? If the attack is based on the ability to bias that "on average" in one direction or another, it's quite possible that applying a bias across 128 changed input bits is actually *easier* than when you only have 32 bit of change bias to apply.... > They didn???t dare attempt it because they knew it???s not possible. As I point out above, we don't actually know that for a fact. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From mpalmer at hezmatt.org Thu Mar 2 23:15:22 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 3 Mar 2017 10:15:22 +1100 Subject: Serious Cloudflare bug exposed a potpourri of secret customer data In-Reply-To: <99FF5A5E-1E62-44E4-A306-4053D522005F@sep2.co.uk> References: <20170224222852.GA644@gsp.org> <99FF5A5E-1E62-44E4-A306-4053D522005F@sep2.co.uk> Message-ID: <20170302231522.GK16332@hezmatt.org> On Sat, Feb 25, 2017 at 07:21:48AM +0000, Mike Goodwin wrote: > Useful information on potentially compromised sites due to this: > > https://github.com/pirate/sites-using-cloudflare "This list contains all domains that use Cloudflare DNS" That's only marginally more useful than saying "any domain matching /^.*$/"; plenty of domains use Cloudflare's DNS without using the proxy service (and it is, barely, possible to use the proxy service which had the bug without using the DNS service). - Matt -- A byte walks into a bar and orders a pint. Bartender asks him "What's wrong?" The byte says "Parity error." Bartender nods and says "Yeah, I thought you looked a bit off." From jared at puck.nether.net Thu Mar 2 23:42:05 2017 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 2 Mar 2017 18:42:05 -0500 Subject: google ipv6 routes via cogent In-Reply-To: <000901d2938e$7be4d880$73ae8980$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <000901d2938e$7be4d880$73ae8980$@gvtc.com> Message-ID: <91BEAAEB-9913-4715-96D5-5D5613F0AC2D@puck.nether.net> Yes. Most providers can send you just their customer routes. If they send you full routes you want to discriminate customer vs peer routes. This is typically done with communities and is worthwhile as most people have capacity on customer links but via peer it may not always be the case. As is usual YMMV Jared Mauch > On Mar 2, 2017, at 2:52 PM, Aaron Gould wrote: > > Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please. > > -Aaron From howard at leadmon.net Thu Mar 2 20:25:20 2017 From: howard at leadmon.net (Howard Leadmon) Date: Thu, 2 Mar 2017 15:25:20 -0500 Subject: google ipv6 routes via cogent In-Reply-To: <20170302195735.GD86663@excession.tpb.net> References: <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> Message-ID: <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> On 3/2/2017 2:57 PM, Niels Bakker wrote: > You should ask for full routes from all your providers + a default. > > > -- Niels. If you taking full routes from everyone, why would you need a default? If they don't show a route for it, they probably can't reach it. I don't think I have run with a default route external for many years, and so far it hasn't bit me yet.. --- Howard Leadmon PBW Communications, LLC http://www.pbwcomm.com From mysidia at gmail.com Fri Mar 3 00:35:11 2017 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 2 Mar 2017 18:35:11 -0600 Subject: Serious Cloudflare bug exposed a potpourri of secret customer data In-Reply-To: <20170302231522.GK16332@hezmatt.org> References: <20170224222852.GA644@gsp.org> <99FF5A5E-1E62-44E4-A306-4053D522005F@sep2.co.uk> <20170302231522.GK16332@hezmatt.org> Message-ID: On Thu, Mar 2, 2017 at 5:15 PM, Matt Palmer wrote: > On Sat, Feb 25, 2017 at 07:21:48AM +0000, Mike Goodwin wrote: >> Useful information on potentially compromised sites due to this: >> https://github.com/pirate/sites-using-cloudflare > "This list contains all domains that use Cloudflare DNS" > That's only marginally more useful than saying "any domain matching /^.*$/"; Iirc; It's quite easy to use the Proxy service without the DNS service, as long as you are using a Paid CF account for the domain and not a free account. Also; Querying after the fact is not very scientific, Because there may be domains that _Were_ using CF proxy service During the incident which no longer use CF DNS or Proxy servers, for whatever reason. If you're going to scrape DNS records to decide, should probably be scraping A records for www, and then checking Reverse DNS or matching against possible CF IP addresses, not NS records. > - Matt -- -JH From bohn at adelphi.edu Fri Mar 3 02:01:08 2017 From: bohn at adelphi.edu (Dennis Bohn) Date: Thu, 2 Mar 2017 21:01:08 -0500 Subject: google ipv6 routes via cogent In-Reply-To: References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> Message-ID: Interesting question whether 2000::/3 or ::/0 is the better default route. >From what I can tell (as OP indicated) most are using ::/0. (I should probably add for those who have not been running V6 for long that for the forseeble future 2000::/3 is the extent of the V6 allocation, the rest being held back for future use. Which is why that could be a default.) Is there any case where 2000::/3 would hurt one? One person mentioned something like 64:ff9b::/96, which per http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml, is the v4 to v6 translator net. Does anyone actually use that? best, dennis Dennis Bohn Manager of Network and Systems (ret) Adelphi University bohn at adelphi.edu On Thu, Mar 2, 2017 at 12:20 PM, Baldur Norddahl wrote: > Shouldn't that be 2000::/3 ? > > Den 2. mar. 2017 17.06 skrev "Aaron Gould" : > > Correction... ::/0 is what I learn from those 3 :) > From theodore at ciscodude.net Fri Mar 3 03:12:40 2017 From: theodore at ciscodude.net (Theodore Baschak) Date: Thu, 2 Mar 2017 21:12:40 -0600 Subject: google ipv6 routes via cogent In-Reply-To: References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> Message-ID: My own experience was that I tried to use the 2000::/3 route initially and that was fine with static routes in my lab, but once dynamic routing protocols were introduced, ::/0 was the only thing recognized as "default" to propagate or not with default-route statements in BGP and OSPF. That may vary from platform to platform, however the ones I played with all exhibited this behaviour. Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ On Thu, Mar 2, 2017 at 8:01 PM, Dennis Bohn wrote: > Interesting question whether 2000::/3 or ::/0 is the better default route. > From what I can tell (as OP indicated) most are using ::/0. (I should > probably add for those who have not been running V6 for long that for the > forseeble future 2000::/3 is the extent of the V6 allocation, the rest > being held back for future use. Which is why that could be a default.) Is > there any case where 2000::/3 would hurt one? One person mentioned > something like 64:ff9b::/96, which per > http://www.iana.org/assignments/iana-ipv6-special- > registry/iana-ipv6-special-registry.xhtml, > is the v4 to v6 translator net. Does anyone actually use that? > best, > dennis > > Dennis Bohn > Manager of Network and Systems (ret) > Adelphi University > bohn at adelphi.edu > > > On Thu, Mar 2, 2017 at 12:20 PM, Baldur Norddahl < > baldur.norddahl at gmail.com> > wrote: > > > Shouldn't that be 2000::/3 ? > > > > Den 2. mar. 2017 17.06 skrev "Aaron Gould" : > > > > Correction... ::/0 is what I learn from those 3 :) > > > From niels=nanog at bakker.net Fri Mar 3 11:56:01 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 3 Mar 2017 12:56:01 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> References: <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> Message-ID: <20170303115601.GE86663@excession.tpb.net> * howard at leadmon.net (Howard Leadmon) [Fri 03 Mar 2017, 01:06 CET]: >On 3/2/2017 2:57 PM, Niels Bakker wrote: >>You should ask for full routes from all your providers + a default. > > If you taking full routes from everyone, why would you need a >default? If they don't show a route for it, they probably can't reach >it. I don't think I have run with a default route external for many >years, and so far it hasn't bit me yet.. As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table. -- Niels. From nick at foobar.org Fri Mar 3 12:00:28 2017 From: nick at foobar.org (Nick Hilliard) Date: Fri, 03 Mar 2017 12:00:28 +0000 Subject: google ipv6 routes via cogent In-Reply-To: <20170303115601.GE86663@excession.tpb.net> References: <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> <20170303115601.GE86663@excession.tpb.net> Message-ID: <58B95ADC.7080602@foobar.org> Niels Bakker wrote: > As I explained in the rest of my email that you conveniently didn't > quote, it's so that you can selectively import routes from all your > providers in situations where your router cannot handle a full table. it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit. OTOH, if you are single-homed, it is highly advisable to accept a default, the reason being that most transit providers provide bgp communities with "don't advertise to customers" semantics. So if you're single-homed and use a full dfz feed without default route, you will not have full connectivity to all the routes available from the transit provider. Nick From niels=nanog at bakker.net Fri Mar 3 14:17:37 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 3 Mar 2017 15:17:37 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <58B95ADC.7080602@foobar.org> References: <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> <20170303115601.GE86663@excession.tpb.net> <58B95ADC.7080602@foobar.org> Message-ID: <20170303141737.GF86663@excession.tpb.net> * nick at foobar.org (Nick Hilliard) [Fri 03 Mar 2017, 13:02 CET]: >Niels Bakker wrote: >>As I explained in the rest of my email that you conveniently >>didn't quote, it's so that you can selectively import routes from >>all your providers in situations where your router cannot handle a >>full table. > >it can also break horribly in situations where the provider is >providing "transit" but doesn't provide full transit. You don't need to import them into your border router's FIB. It's always good to be able to change your own routing policy without having to consult your upstream's NOC. -- Niels. From patrick at ianai.net Fri Mar 3 14:42:04 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 3 Mar 2017 09:42:04 -0500 Subject: google ipv6 routes via cogent In-Reply-To: <58B95ADC.7080602@foobar.org> References: <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> <20170303115601.GE86663@excession.tpb.net> <58B95ADC.7080602@foobar.org> Message-ID: On Mar 3, 2017, at 7:00 AM, Nick Hilliard wrote: > > Niels Bakker wrote: >> As I explained in the rest of my email that you conveniently didn't >> quote, it's so that you can selectively import routes from all your >> providers in situations where your router cannot handle a full table. > > it can also break horribly in situations where the provider is providing > "transit" but doesn't provide full transit. > > OTOH, if you are single-homed, it is highly advisable to accept a > default, the reason being that most transit providers provide bgp > communities with "don't advertise to customers" semantics. So if you're > single-homed and use a full dfz feed without default route, you will not > have full connectivity to all the routes available from the transit > provider. If you are single-homed, there is no need for BGP at all. And injecting your ASN into the table is probably not terribly useful to everyone else?s FIB. There are, of course, corner cases. But in general, single-homed people shouldn?t be using BGP. -- TTFN, patrick From bryan at shout.net Fri Mar 3 16:25:20 2017 From: bryan at shout.net (Bryan Holloway) Date: Fri, 3 Mar 2017 10:25:20 -0600 Subject: Qwest/CenturyLink BGP contact? In-Reply-To: <93d5bc10-4b2b-412a-471d-035b5afac1f0@shout.net> References: <93d5bc10-4b2b-412a-471d-035b5afac1f0@shout.net> Message-ID: <87af5df4-b2c0-7944-dcae-d57517c9e88c@shout.net> Someone has reached out -- I'm good to go. Thanks all! On 3/2/17 1:11 PM, Bryan Holloway wrote: > Hello all, > > If someone from Qwest/Centurylink is lurking, could you contact me > off-list? > > You are advertising a /24 out of a recently acquired /16, and I've been > unsuccessful reaching anyone. > > Thanks! > - bryan From cscora at apnic.net Fri Mar 3 18:02:39 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Mar 2017 04:02:39 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170303180239.5498DC44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 04 Mar, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 639225 Prefixes after maximum aggregation (per Origin AS): 248678 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 307752 Total ASes present in the Internet Routing Table: 56403 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 48853 Origin ASes announcing only one prefix: 21709 Transit ASes present in the Internet Routing Table: 7550 Transit-only ASes present in the Internet Routing Table: 207 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 42 Max AS path prepend of ASN ( 22394) 39 Prefixes from unregistered ASNs in the Routing Table: 68 Numnber of instances of unregistered ASNs: 69 Number of 32-bit ASNs allocated by the RIRs: 17548 Number of 32-bit ASNs visible in the Routing Table: 13633 Prefixes from 32-bit ASNs in the Routing Table: 55318 Number of bogon 32-bit ASNs visible in the Routing Table: 44 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 397 Number of addresses announced to Internet: 2836585604 Equivalent to 169 /8s, 18 /16s and 220 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.5 Total number of prefixes smaller than registry allocations: 213156 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 174750 Total APNIC prefixes after maximum aggregation: 49968 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 174086 Unique aggregates announced from the APNIC address blocks: 71703 APNIC Region origin ASes present in the Internet Routing Table: 7887 APNIC Prefixes per ASN: 22.07 APNIC Region origin ASes announcing only one prefix: 2205 APNIC Region transit ASes present in the Internet Routing Table: 1123 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2726 Number of APNIC addresses announced to Internet: 760850308 Equivalent to 45 /8s, 89 /16s and 167 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 194786 Total ARIN prefixes after maximum aggregation: 93195 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 197227 Unique aggregates announced from the ARIN address blocks: 90282 ARIN Region origin ASes present in the Internet Routing Table: 17817 ARIN Prefixes per ASN: 11.07 ARIN Region origin ASes announcing only one prefix: 6647 ARIN Region transit ASes present in the Internet Routing Table: 1771 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1813 Number of ARIN addresses announced to Internet: 1106472928 Equivalent to 65 /8s, 243 /16s and 111 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 170475 Total RIPE prefixes after maximum aggregation: 84124 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 165696 Unique aggregates announced from the RIPE address blocks: 100287 RIPE Region origin ASes present in the Internet Routing Table: 23765 RIPE Prefixes per ASN: 6.97 RIPE Region origin ASes announcing only one prefix: 10985 RIPE Region transit ASes present in the Internet Routing Table: 3355 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5601 Number of RIPE addresses announced to Internet: 710371200 Equivalent to 42 /8s, 87 /16s and 103 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 82580 Total LACNIC prefixes after maximum aggregation: 17633 LACNIC Deaggregation factor: 4.68 Prefixes being announced from the LACNIC address blocks: 83764 Unique aggregates announced from the LACNIC address blocks: 38289 LACNIC Region origin ASes present in the Internet Routing Table: 5677 LACNIC Prefixes per ASN: 14.75 LACNIC Region origin ASes announcing only one prefix: 1546 LACNIC Region transit ASes present in the Internet Routing Table: 1028 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3200 Number of LACNIC addresses announced to Internet: 171328672 Equivalent to 10 /8s, 54 /16s and 68 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16532 Total AfriNIC prefixes after maximum aggregation: 3700 AfriNIC Deaggregation factor: 4.47 Prefixes being announced from the AfriNIC address blocks: 18055 Unique aggregates announced from the AfriNIC address blocks: 6840 AfriNIC Region origin ASes present in the Internet Routing Table: 1024 AfriNIC Prefixes per ASN: 17.63 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 198 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 293 Number of AfriNIC addresses announced to Internet: 87054848 Equivalent to 5 /8s, 48 /16s and 90 /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 5556 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3735 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2985 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2743 11133 744 KIXS-AS-KR Korea Telecom, KR 9829 2722 1501 541 BSNL-NIB National Internet Backbone, IN 9808 2295 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2067 421 219 TATACOMM-AS TATA Communications formerl 45899 1875 1307 103 VNPT-AS-VN VNPT Corp, VN 4808 1658 1786 448 CHINA169-BJ China Unicom Beijing Provin 24560 1562 580 254 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3660 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3300 1333 83 SHAW - Shaw Communications Inc., CA 18566 2187 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2063 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1976 2050 405 CHARTER-NET-HKY-NC - Charter Communicat 209 1727 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1705 318 426 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16509 1704 3321 559 AMAZON-02 - Amazon.com, Inc., US 6983 1683 852 227 ITCDELTA - Earthlink, Inc., US 701 1581 10599 653 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3009 1124 2140 AKAMAI-ASN1 , US 9121 2644 1691 18 TTNET , TR 34984 1994 328 383 TELLCOM-AS , TR 13188 1654 99 58 TRIOLAN , UA 8551 1633 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 1498 1033 49 UNI2-AS , ES 12389 1274 1216 495 ROSTELECOM-AS , RU 9198 1270 352 22 KAZTELECOM-AS , KZ 6849 1268 355 22 UKRTELNET , UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3541 545 164 Telmex Colombia S.A., CO 26615 3018 2330 44 Tim Celular S.A., BR 8151 2500 3379 543 Uninet S.A. de C.V., MX 11830 1800 368 66 Instituto Costarricense de Electricidad 6503 1556 437 53 Axtel, S.A.B. de C.V., MX 7303 1552 999 251 Telecom Argentina S.A., AR 6147 1166 377 27 Telefonica del Peru S.A.A., PE 28573 1086 2285 180 CLARO S.A., BR 3816 1004 479 186 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 978 280 35 Techtel LMDS Comunicaciones Interactiva 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 1299 399 42 LINKdotNET-AS, EG 36903 718 361 122 MT-MPLS, MA 37611 693 67 6 Afrihost, ZA 36992 600 1375 26 ETISALAT-MISR, EG 24835 491 722 14 RAYA-AS, EG 8452 417 1474 16 TE-AS TE-AS, EG 37492 393 316 74 ORANGE-TN, TN 29571 368 36 10 CITelecom-AS, CI 15399 334 35 7 WANANCHI-KE, KE 2018 272 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5556 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3735 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3660 2968 148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3541 545 164 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3300 1333 83 SHAW - Shaw Communications Inc., CA 26615 3018 2330 44 Tim Celular S.A., BR 20940 3009 1124 2140 AKAMAI-ASN1 , US 17974 2985 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2743 11133 744 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3660 3512 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3735 3479 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3541 3377 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3300 3217 SHAW - Shaw Communications Inc., CA 26615 3018 2974 Tim Celular S.A., BR 17974 2985 2913 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2644 2626 TTNET , TR 9808 2295 2262 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2722 2181 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS , IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.157.128.0/17 393899 -Reserved AS-, ZZ 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG 41.73.21.0/24 37004 Suburban-Broadband-AS, NG 41.73.22.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:278 /13:537 /14:1046 /15:1794 /16:13200 /17:7788 /18:13239 /19:24772 /20:38244 /21:41013 /22:74772 /23:63160 /24:357847 /25:554 /26:415 /27:293 /28:34 /29:18 /30:26 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3096 3300 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2839 3660 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 26615 2534 3018 Tim Celular S.A., BR 18566 2080 2187 MEGAPATH5-US - MegaPath Corporation, US 9121 1856 2644 TTNET , TR 30036 1516 1705 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1457 3541 Telmex Colombia S.A., CO 13188 1378 1654 TRIOLAN , UA 6389 1372 2063 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1609 2:837 4:25 5:2454 6:34 8:1051 12:1812 13:85 14:1779 15:22 16:2 17:109 18:129 19:1 20:53 23:2375 24:1857 25:2 27:2373 31:1856 32:89 33:5 34:1 35:3 36:375 37:2560 38:1345 39:44 40:99 41:2811 42:463 43:1895 44:62 45:2389 46:2626 47:112 49:1224 50:965 51:18 52:746 54:356 55:5 56:4 57:41 58:1622 59:990 60:387 61:1935 62:1510 63:1921 64:4568 65:2182 66:4479 67:2263 68:1191 69:3339 70:1303 71:574 72:2141 74:2622 75:396 76:413 77:1429 78:1668 79:1311 80:1358 81:1403 82:964 83:727 84:861 85:1737 86:483 87:1137 88:804 89:2055 90:205 91:6130 92:994 93:2367 94:2369 95:2824 96:565 97:358 98:938 99:83 100:153 101:1243 103:13830 104:2776 105:165 106:484 107:1545 108:829 109:2594 110:1290 111:1722 112:1158 113:1309 114:1042 115:1733 116:1753 117:1660 118:2073 119:1604 120:946 121:1095 122:2335 123:2113 124:1538 125:1820 128:707 129:620 130:409 131:1383 132:522 133:190 134:528 135:215 136:512 137:420 138:1858 139:500 140:372 141:524 142:790 143:906 144:764 145:168 146:1036 147:710 148:1380 149:569 150:695 151:945 152:729 153:302 154:760 155:970 156:552 157:616 158:454 159:1424 160:564 161:737 162:2478 163:535 164:787 165:1156 166:385 167:1225 168:2577 169:749 170:2899 171:281 172:1012 173:1838 174:801 175:725 176:1775 177:4256 178:2476 179:1603 180:2184 181:2018 182:2218 183:1055 184:833 185:8884 186:3181 187:2664 188:2421 189:1814 190:8102 191:1885 192:9287 193:5768 194:4650 195:3836 196:1955 197:1283 198:5566 199:5838 200:7396 201:4096 202:10206 203:9813 204:4460 205:2773 206:2998 207:3130 208:3975 209:3971 210:3945 211:2116 212:2811 213:2477 214:864 215:65 216:5878 217:2008 218:839 219:615 220:1693 221:893 222:723 223:1152 End of report From job at instituut.net Sat Mar 4 02:05:15 2017 From: job at instituut.net (Job Snijders) Date: Sat, 4 Mar 2017 11:05:15 +0900 Subject: google ipv6 routes via cogent In-Reply-To: References: <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> <20170303115601.GE86663@excession.tpb.net> <58B95ADC.7080602@foobar.org> Message-ID: <20170304020515.GH1029@Vurt.local> On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote: > On Mar 3, 2017, at 7:00 AM, Nick Hilliard wrote: > > Niels Bakker wrote: > >> As I explained in the rest of my email that you conveniently didn't > >> quote, it's so that you can selectively import routes from all your > >> providers in situations where your router cannot handle a full table. > > > > it can also break horribly in situations where the provider is providing > > "transit" but doesn't provide full transit. > > > > OTOH, if you are single-homed, it is highly advisable to accept a > > default, the reason being that most transit providers provide bgp > > communities with "don't advertise to customers" semantics. So if you're > > single-homed and use a full dfz feed without default route, you will not > > have full connectivity to all the routes available from the transit > > provider. Correct. > If you are single-homed, there is no need for BGP at all. That is very strongly worded, and in plenty of cases a false assertion. > And injecting your ASN into the table is probably not terribly useful > to everyone else?s FIB. ASNs don't have anything to do with FIB. > There are, of course, corner cases. But in general, single-homed > people shouldn?t be using BGP. There are numerous reasons to use BGP when single-homed: - as preparation to multi-home in the (near) future - ability to quickly change providers - to use BGP based blackholing features - to save time on provisioning work (adding new prefixes becomes a matter of just announcing and updating IRR/RPKI). - loadbalanacing / loadsharing across multiple links - ability to use bgp communities for traffic engineering In other words, if you have your own IP space, I'd recommend to get your own ASN and use BGP. Kind regards, Job From jhaustin at gmail.com Sat Mar 4 03:59:20 2017 From: jhaustin at gmail.com (Jeremy Austin) Date: Fri, 3 Mar 2017 18:59:20 -0900 Subject: google ipv6 routes via cogent In-Reply-To: <20170304020515.GH1029@Vurt.local> References: <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> <20170303115601.GE86663@excession.tpb.net> <58B95ADC.7080602@foobar.org> <20170304020515.GH1029@Vurt.local> Message-ID: On Fri, Mar 3, 2017 at 5:05 PM, Job Snijders wrote: > > There are, of course, corner cases. But in general, single-homed > > people shouldn?t be using BGP. > > There are numerous reasons to use BGP when single-homed: > > - as preparation to multi-home in the (near) future > - ability to quickly change providers > - to use BGP based blackholing features > - to save time on provisioning work (adding new prefixes becomes a > matter of just announcing and updating IRR/RPKI). > - loadbalanacing / loadsharing across multiple links > - ability to use bgp communities for traffic engineering > > In other words, if you have your own IP space, I'd recommend to get your > own ASN and use BGP. I concur with Job. If you are single-homed but care about having proper L3 redundancy (not just VRRP or equivalent), BGP is a must. ARIN has a policy to allow this, but it is not spelled out with an excess of clarity. I suspect it is not often used; see NRPM section 5. -- Jeremy Austin From sean at donelan.com Sat Mar 4 06:54:23 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 4 Mar 2017 01:54:23 -0500 (EST) Subject: FCC emergency waiver: Jewish Community Centers Calling Party Number Identification Message-ID: The FCC granted an emergency temporary waiver to telecommunication carriers serving Jewish Community Centers, allowing access to the Caller-ID (Calling Party Number Identification) normally blocked at the calling party's request (i.e. star-67). Although per call Call-Trace (i.e. star-57) and permanent Trap-and-Trace court orders also report the Caller-ID and other call information, such as ANI to law enforcement; the FCC occasionally granted similar waivers in the past. Obviously this doesn't help with spoofed calling numbers. https://www.fcc.gov/document/fcc-grants-emergency-waiver-help-protect-jewish-community-centers From baldur.norddahl at gmail.com Sat Mar 4 18:12:17 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 4 Mar 2017 19:12:17 +0100 Subject: google ipv6 routes via cogent In-Reply-To: References: <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <20170302195932.GX6562@angus.ind.wpi.edu> Message-ID: In general I would not be single homed to a tier 1 ISP. You are better off using an ISP that has N upstream transit providers. That way they have multiple choices to select the best route. If you accept a default route from multiple upstreams you will be multi homed for inbound traffic but effectively single homed for outbound. Your router will select one default route and send 100% of the traffic that way. Instead of letting the router select a random default route, you should evaluate and rank your upstreams. Use a route map to set priority on the routes. Nobody has the best routes for all destinations, so you will have to find the one with the best average or perhaps the one that avoids bad routes. And that brings me to the point about Cogent. We used to have two upstreams. One was a local tier 2 ISP and the other was Cogent. Our quality was OK but if the tier 2 ISP link was down our customers would immediately call to claim downtime. We would not actually be down but quality was so low that people thought we were. The reason is that some major destinations from the Cogent network is routed from Europe to USA and back again. Latency go from a few milliseconds to 100 times worse. Available bandwidth is very reduced. Video from major streaming services will not play or only in lowest quality setting. I will claim that it is impossible to be single homed on Cogent in Denmark as an eyeball network. It is probably different if you are in the USA. This does not mean Cogent are useless. We were happy with the quality of the network and the price is good. What we experienced was bad peering. You just can't have them as your only transit. Regards Baldur Den 2. mar. 2017 21.02 skrev "Chuck Anderson" : Define "good" vs. "bad" transport of bits. As long as there is adequate bandwidth and low latency, who cares? On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote: > That will have the effect of prioritizing Cogent routes as that would be > more specific than the default routes from the other providers. Cogent are > not that good that you would want to do that. > > Den 2. mar. 2017 20.16 skrev "Jeff Waddell" >: > > Or at least ask for a full view from Cogent - then you won't get any routes > they don't have > > On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay wrote: > > > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > > route and they sent me ::/0...here's one of them... > > > > Why did you don?t ask for a full view? With that, you can easily deal > > with that kind of problem. From patrick at ianai.net Sat Mar 4 18:37:30 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 4 Mar 2017 13:37:30 -0500 Subject: google ipv6 routes via cogent In-Reply-To: <20170304020515.GH1029@Vurt.local> References: <000901d2938e$7be4d880$73ae8980$@gvtc.com> <20170302195735.GD86663@excession.tpb.net> <9246bb59-3da4-4135-7c64-bf7e0935580d@leadmon.net> <20170303115601.GE86663@excession.tpb.net> <58B95ADC.7080602@foobar.org> <20170304020515.GH1029@Vurt.local> Message-ID: On Mar 3, 2017, at 9:05 PM, Job Snijders wrote: > On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote: >> On Mar 3, 2017, at 7:00 AM, Nick Hilliard wrote: >>> Niels Bakker wrote: >>>> As I explained in the rest of my email that you conveniently didn't >>>> quote, it's so that you can selectively import routes from all your >>>> providers in situations where your router cannot handle a full table. >>> >>> it can also break horribly in situations where the provider is providing >>> "transit" but doesn't provide full transit. >>> >>> OTOH, if you are single-homed, it is highly advisable to accept a >>> default, the reason being that most transit providers provide bgp >>> communities with "don't advertise to customers" semantics. So if you're >>> single-homed and use a full dfz feed without default route, you will not >>> have full connectivity to all the routes available from the transit >>> provider. > > Correct. > >> If you are single-homed, there is no need for BGP at all. > > That is very strongly worded, and in plenty of cases a false assertion. > >> And injecting your ASN into the table is probably not terribly useful >> to everyone else?s FIB. > > ASNs don't have anything to do with FIB. > >> There are, of course, corner cases. But in general, single-homed >> people shouldn?t be using BGP. > > There are numerous reasons to use BGP when single-homed: > > - as preparation to multi-home in the (near) future > - ability to quickly change providers > - to use BGP based blackholing features > - to save time on provisioning work (adding new prefixes becomes a > matter of just announcing and updating IRR/RPKI). > - loadbalanacing / loadsharing across multiple links > - ability to use bgp communities for traffic engineering > > In other words, if you have your own IP space, I'd recommend to get your > own ASN and use BGP. First, I said specifically there are corner cases. Everything you say above is a corner case. The sum of everyone in need of the above is to the right of the decimal compared to all single homed networks. Limiting it to ?it you have your own IP space? makes the set even smaller. You are also reaching here. Preparation for multi-homing in the near future is just multi-homing. Adding prefixes is a very occasional thing, and in some cases is actually not easier with BGP. (Ever worked with some provider?s IRR implementation?) Etc. End of day, if you have your own space and only allow aggregates into the DFZ, even as a stub behind someone else, it doesn?t really save RIB slots compared to having the upstream announce it for you. My problem is making the exceptions sound normal. They are not, and we should not treat them as if they are. Else we will end up with people wanting to do it who do not understand what they are doing, polluting the table, etc. I stand by my statement. Single Homed Networks Should Not Use BGP. It is a good general rule. There are exceptions, but the exceptions are rare and should be approached with caution & clue. -- TTFN, patrick From dougb at dougbarton.us Sun Mar 5 00:25:28 2017 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 4 Mar 2017 16:25:28 -0800 Subject: IANA IPv4 Recovered Address Space registry updated In-Reply-To: <356EC437-1FA4-49B4-815E-A5C8B232B33B@icann.org> References: <356EC437-1FA4-49B4-815E-A5C8B232B33B@icann.org> Message-ID: <8cb8f7da-b070-0789-edca-b23d15695610@dougbarton.us> Paula, Thank you for this update. Is there a convenient resource for viewing the delta? Doug On 03/01/2017 12:15 PM, Paula Wang wrote: > Hi, > > > > An update has been made to the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA (https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-05-08-en). > > > > The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ > > > > Kind regards, > > > > Paula Wang > > IANA Services Specialist > > PTI > From Nathan.Brookfield at simtronic.com.au Sun Mar 5 01:03:32 2017 From: Nathan.Brookfield at simtronic.com.au (Nathan Brookfield) Date: Sun, 5 Mar 2017 01:03:32 +0000 Subject: IANA IPv4 Recovered Address Space registry updated In-Reply-To: <8cb8f7da-b070-0789-edca-b23d15695610@dougbarton.us> References: <356EC437-1FA4-49B4-815E-A5C8B232B33B@icann.org>, <8cb8f7da-b070-0789-edca-b23d15695610@dougbarton.us> Message-ID: <5E9FD166-CD7E-4E8C-93C8-A3CD9F8A79CA@simtronic.com.au> https://www.iana.org/assignments/ipv4-recovered-address-space/ Nathan Brookfield Chief Executive Officer Simtronic Technologies Pty Ltd http://www.simtronic.com.au On 5 Mar 2017, at 11:29, Doug Barton > wrote: Paula, Thank you for this update. Is there a convenient resource for viewing the delta? Doug On 03/01/2017 12:15 PM, Paula Wang wrote: Hi, An update has been made to the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA (https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-05-08-en). The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ Kind regards, Paula Wang IANA Services Specialist PTI From benno at NLnetLabs.nl Sun Mar 5 17:28:20 2017 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Sun, 5 Mar 2017 18:28:20 +0100 Subject: 2nd call for presentations RIPE 74 Message-ID: <54c0949d-2964-de64-ae28-62753e48811e@NLnetLabs.nl> Dear colleagues, Please note the approaching deadline of *12 March 2017* for RIPE 74 plenary programme submissions. You can find the CFP for RIPE 74 below or at https://ripe74.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://ripe74.ripe.net/programme/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 74 will take place from 8-12 May 2017 in Budapest, Hungary. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 74. See the full descriptions of the different presentation formats, https://ripe74.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 12 March 2017. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe74.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. Allocation of lightning talks will start a few days before the meeting, and will continue throughout the meeting. During the meeting, they may be announced on the day before the talk or even on the same day as the talk. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From joly at punkcast.com Mon Mar 6 08:08:35 2017 From: joly at punkcast.com (Joly MacFie) Date: Mon, 6 Mar 2017 03:08:35 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? Message-ID: To say that Mr. Chen's EZIP proposal has not, thus far, been received with open arms by the networking community would be an understatement. It is seen as delaying the inevitable and introducing an impractical extra routing hardware layer that will be hit & miss. Nevertheless, since much of the world is still IPv4 dependent, it just could take off. ISOC-NY is happy to give him the opportunity to expound on its merits. ? We'd welcome some expert respondents.? ?See: ? https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00 ?==================================================================? WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter (ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y. Chen, VP of Engineering, Avinta Communications, will present his EzIP proposal to reinvigorate the diminishing pool of IPv4 addresses. ?Optional registration at the link below. This will be recorded. What: WEBINAR: Can We Make IPv4 Great Again? When: Tuesday March 8 2017 Noon EST | 17:00 UTC Register + info: https://www.meetup.com/isoc-ny/events/238164448/ Computer: https://zoom.us/j/914492141 Phone: http://bit.ly/zoomphone ? ? ID: 914 492 141 Twitter: #ezip ?====================================================================? Permalink http://isoc-ny.org/p2/9031 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From msa at latt.net Mon Mar 6 08:55:08 2017 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 6 Mar 2017 03:55:08 -0500 Subject: WWV Broadcast Outages In-Reply-To: <20170222125953.C30D4406060@ip-64-139-1-69.sjc.megapath.net> References: <20170222125953.C30D4406060@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20170306085508.GA23723@puck.nether.net> On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote: > Any suggestions for gear and/or software that works with WWV (or CHU)? > Or general suggestions for non GPS sources of time? Hey Hal! In North America, WWV and CHU are pretty much it for accessible backups these days. Unfortunately time and frequency distribution is a niche that tends to get neglected (if not actively gutted) in US budgets. > Dave Mills had a driver in ntpd that used a PC audio port to listen to WWV. > I don't know anybody who ever used it. I think there was code to tell some > brand of receiver with a serial/USB port how to change frequencies so you > could use the one that worked best for that time of day. You do now. The WWV and CHU audio drivers work fine. If you want the auto-tuning functionality, you need to use an Icom receiver that supports their CI-V protocol. (This can be a full fledged tabletop like the R-75, or a more compact receiver like their PCR-100 or 1000. Some of these are no longer produced, but they're easy to come by on the secondary markets. I picked up multiple PCR-100s off eBay at $25 ea a while ago.) You can always use any shortwave receiver, and just tune it to a good frequency. There are also kit and prebuilt 10 MHz receivers out there in the $30-$40 range which will work. You accept a slight loss in daily coverage by selecting a compromise frequency, but it's better than nothing and independent of GPS. If you (or anyone else on NANOG) needs some help getting the audio refclocks working; drop me a line. > There used to be WWVB (60 KHz) receivers. The good ones phase locked > to the carrier. The general rise in EMI made those close to useless > in most locations. NIST finished the job when they changed the > modulation format a few years ago. As far as I know, there aren't any > replacements for the old gear that take advantage of the new modulation > format. GPS works too well. It's not so much that GPS works so well, as there's no way to produce a commercial receiver that uses the enhanced format. By gifting the developed IP back to the developer as part of the SIPR grant, it is all sitting under a patent umbrella. Unfortunately, the startup that developed it appears to have failed (at least, they've mostly vanished, folks seem to have moved on, and they're late on corporate reports at this point.) -- leaving the new format only usable by hackers and not something that can be rolled into a commercial timing receiver. My biggest beef with the new format was the rollout, 5 years ago now, before a commercial receiver was available on the market. I'm not sure why NIST has stuck with it. > There are some boxes that recover the time from nearby cell phone towers. I > think they will stop working as the towers get upgraded to the newer > protocols that use a different form of timing. That will probably take many > years. But the cell phone towers depend on GPS. (You can ususlly spot the > conical antenna(s) if you look around a bit.) CDMA was only ever good to +/- 10ms anyway, at least any of the boxes I ever used. You can actually outperform it with classic WWV or CHU, and those get you a real backup, rather than an indirect dependancy on GPS. --msa From akg1330 at gmail.com Mon Mar 6 14:12:02 2017 From: akg1330 at gmail.com (Andrew Gallo) Date: Mon, 6 Mar 2017 09:12:02 -0500 Subject: WWV Broadcast Outages In-Reply-To: <20170306085508.GA23723@puck.nether.net> References: <20170222125953.C30D4406060@ip-64-139-1-69.sjc.megapath.net> <20170306085508.GA23723@puck.nether.net> Message-ID: <05843cb6-2d20-aee4-af07-fbd43788883d@gmail.com> On 3/6/2017 3:55 AM, Majdi S. Abbas wrote: > On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote: >> Any suggestions for gear and/or software that works with WWV (or CHU)? >> Or general suggestions for non GPS sources of time? > Hey Hal! > > In North America, WWV and CHU are pretty much it for accessible > backups these days. Unfortunately time and frequency distribution is a > niche that tends to get neglected (if not actively gutted) in US > budgets. Agreed, but I'll share this- the recent FCC CSRIC V had a working group (4B) that studied the reliability of time and frequency distribution. https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability It may be of interest. From royce at techsolvency.com Mon Mar 6 14:56:25 2017 From: royce at techsolvency.com (Royce Williams) Date: Mon, 6 Mar 2017 05:56:25 -0900 Subject: WWV Broadcast Outages In-Reply-To: <05843cb6-2d20-aee4-af07-fbd43788883d@gmail.com> References: <20170222125953.C30D4406060@ip-64-139-1-69.sjc.megapath.net> <20170306085508.GA23723@puck.nether.net> <05843cb6-2d20-aee4-af07-fbd43788883d@gmail.com> Message-ID: On Mon, Mar 6, 2017 at 5:12 AM, Andrew Gallo wrote: > > On 3/6/2017 3:55 AM, Majdi S. Abbas wrote: >> >> On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote: >>> >>> Any suggestions for gear and/or software that works with WWV (or CHU)? >>> Or general suggestions for non GPS sources of time? >> >> Hey Hal! >> >> In North America, WWV and CHU are pretty much it for accessible >> backups these days. Unfortunately time and frequency distribution is a >> niche that tends to get neglected (if not actively gutted) in US >> budgets. > > Agreed, but I'll share this- the recent FCC CSRIC V had a working group (4B) that studied the reliability of time and frequency distribution. > https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability > > It may be of interest. Specifically, the "Network Timing Single Source Risk Reduction - Final Report" part: https://transition.fcc.gov/bureaus/pshs/advisory/csric5/WG4B_FinalReport_122116.docx My summary of its points: * Analysis of vulnerabilities in the "supply chain" of GPS * Assertion that GPS mitigations and alternatives are needed to reduce risk * Some likely characteristics of good mitigations and alternatives * A list of potential alternatives, their features, and their current state (L2C & L5 GPS, Galileo & GLONASS, LEO satelltes, commercial RF, antenna pattern optimization, NMA on L2C, sync over fiber, eLORAN, other RF sync, terrestrial beacons, and hybrid DME) >From the executive summary: The U.S. communications sector relies heavily on the Global Positioning System (GPS) to provide network time. GPS is a widely available, extremely precise timing source that is used across multiple infrastructure sectors. However, given the high dependence of the communications sector on GPS, the Federal Communications Commission (Commission) is interested in identifying ways to increase the resilience of communications networks by exploring complementary or backup solutions that could be employed to offer similar time precision as GPS in the event that GPS signals are lost. These solutions also need to be completely independent of GPS to significantly reduce any risk. This report addresses the problems associated with relying on GPS solutions, the ideal technical characteristics for systems to backup or supplement GPS, and our recommendations for possible backup solutions by the communications industry and others reliant on communications network timing sources. Royce From brandon at burn.net Mon Mar 6 15:55:18 2017 From: brandon at burn.net (Brandon Applegate) Date: Mon, 6 Mar 2017 10:55:18 -0500 Subject: IPv6 doc. prefix (2001:db8::/32) - APNIC object ? Message-ID: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> Just did a whois on the documentation prefix and was surprised to see what looks like a user object registered for it: % Information related to '2001:0DB8::/32AS132111' route6: 2001:0DB8::/32 descr: FUTURE D SDN BHD origin: AS132111 country: MY mnt-by: MAINT-FUTUREDSDNBHD-MY changed: hm-changed at apnic.net 20160523 source: APNIC Any idea what this is ? I would have thought there might be some sanity check that would have stopped this from getting registered ? -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 "SH1-0151. This is the serial number, of our orbital gun." From alarig at swordarmor.fr Mon Mar 6 16:03:13 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Mon, 6 Mar 2017 17:03:13 +0100 Subject: IPv6 doc. prefix (2001:db8::/32) - APNIC object ? In-Reply-To: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> References: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> Message-ID: <20170306160313.pywykwmaqwq4kfko@mew.swordarmor.fr> On lun. 6 mars 10:55:18 2017, Brandon Applegate wrote: > Just did a whois on the documentation prefix and was surprised to see what looks like a user object registered for it: > > % Information related to '2001:0DB8::/32AS132111' > > route6: 2001:0DB8::/32 > descr: FUTURE D SDN BHD > origin: AS132111 > country: MY > mnt-by: MAINT-FUTUREDSDNBHD-MY > changed: hm-changed at apnic.net 20160523 > source: APNIC > > Any idea what this is ? I would have thought there might be some sanity check that would have stopped this from getting registered ? Hi, If you look for TEST-NET-3, it is also registered to APNIC: alarig at pikachu ~ % whois 203.0.113.1 % [whois.apnic.net] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html % Information related to '203.0.113.0 - 203.0.113.255' inetnum: 203.0.113.0 - 203.0.113.255 netname: TEST-NET-3 descr: IANA descr: RFC5737 Documentation Address Block country: AU admin-c: HM20-AP tech-c: HM20-AP mnt-by: APNIC-HM mnt-routes: APNIC-HM status: ASSIGNED PORTABLE remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ remarks: This block is reserved for use in documentation and remarks: should not be used in any real networks. remarks: Please see more details at remarks: http://www.iana.org/go/rfc5737 remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ source: APNIC mnt-irt: IRT-APNICRANDNET-AU changed: hm-changed at apnic.net 20100617 irt: IRT-APNICRANDNET-AU address: PO Box 3646 address: South Brisbane, QLD 4101 address: Australia e-mail: abuse at apnic.net abuse-mailbox: abuse at apnic.net admin-c: AR302-AP tech-c: AR302-AP auth: # Filtered mnt-by: MAINT-AU-APNIC-GM85-AP changed: hm-changed at apnic.net 20110922 source: APNIC role: APNIC Hostmaster address: 6 Cordelia Street address: South Brisbane address: QLD 4101 country: AU phone: +61 7 3858 3100 fax-no: +61 7 3858 3199 e-mail: helpdesk at apnic.net admin-c: AMS11-AP tech-c: AH256-AP nic-hdl: HM20-AP remarks: Administrator for APNIC notify: hostmaster at apnic.net mnt-by: MAINT-APNIC-AP changed: hm-changed at apnic.net 19981111 changed: hm-changed at apnic.net 20020211 changed: hm-changed at apnic.net 20070612 changed: hm-changed at apnic.net 20100217 changed: hm-changed at apnic.net 20101217 changed: hm-changed at apnic.net 20110815 changed: hm-changed at apnic.net 20121024 changed: hm-changed at apnic.net 20131023 source: APNIC % This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 (UNDEFINED) As long as APNIC is a RIR, I don?t see a big issue with that. -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From job at instituut.net Mon Mar 6 16:04:20 2017 From: job at instituut.net (Job Snijders) Date: Mon, 6 Mar 2017 17:04:20 +0100 Subject: IPv6 doc. prefix (2001:db8::/32) - APNIC object ? In-Reply-To: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> References: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> Message-ID: Hi, On Mon, Mar 6, 2017 at 4:55 PM, Brandon Applegate wrote: > Just did a whois on the documentation prefix and was surprised to see what looks like a user object registered for it: > > % Information related to '2001:0DB8::/32AS132111' > > route6: 2001:0DB8::/32 > descr: FUTURE D SDN BHD > origin: AS132111 > country: MY > mnt-by: MAINT-FUTUREDSDNBHD-MY > changed: hm-changed at apnic.net 20160523 > source: APNIC > > Any idea what this is ? I would have thought there might be some sanity check that would have stopped this from getting registered ? This registration is an error, and APNIC should remove it. It would be good if IRRs ensure that special IANA prefixes cannot be registered. The URL in the inetnum is broken: Vurt:~ job$ whois 2001:0DB8::/32 | grep remarks remarks: This address range is to be used for documentation remarks: purpose only. For more information please see remarks: http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html Kind regards, Job From job at instituut.net Mon Mar 6 16:06:07 2017 From: job at instituut.net (Job Snijders) Date: Mon, 6 Mar 2017 17:06:07 +0100 Subject: IPv6 doc. prefix (2001:db8::/32) - APNIC object ? In-Reply-To: <20170306160313.pywykwmaqwq4kfko@mew.swordarmor.fr> References: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> <20170306160313.pywykwmaqwq4kfko@mew.swordarmor.fr> Message-ID: Hi. On Mon, Mar 6, 2017 at 5:03 PM, Alarig Le Lay wrote: > On lun. 6 mars 10:55:18 2017, Brandon Applegate wrote: >> Just did a whois on the documentation prefix and was surprised to see what looks like a user object registered for it: >> >> % Information related to '2001:0DB8::/32AS132111' >> >> route6: 2001:0DB8::/32 >> descr: FUTURE D SDN BHD >> origin: AS132111 >> country: MY >> mnt-by: MAINT-FUTUREDSDNBHD-MY >> changed: hm-changed at apnic.net 20160523 >> source: APNIC >> >> Any idea what this is ? I would have thought there might be some sanity check that would have stopped this from getting registered ? > > Hi, > > If you look for TEST-NET-3, it is also registered to APNIC: > [snip] > > As long as APNIC is a RIR, I don?t see a big issue with that. Don't confuse an 'inetnum' and a 'route' object. Inetnum's are fine, as long as their documented purpose is correct. The route object the OP mentioned makes no sense. AS132111 is not authorised to announce the IPv6 Documentation prefix. Kind regards, Job From bill at herrin.us Mon Mar 6 16:12:01 2017 From: bill at herrin.us (William Herrin) Date: Mon, 6 Mar 2017 11:12:01 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: Message-ID: On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie wrote: > To say that Mr. Chen's EZIP proposal has not, thus far, been received with > open arms by the networking community would be an understatement. It is > seen as delaying the inevitable and introducing an impractical extra > routing hardware layer that will be hit & miss. Nevertheless, since much of > the world is still IPv4 dependent, it just could take off. ISOC-NY is happy > to give him the opportunity to expound on its merits. > We'd welcome some expert respondents. > > See: > https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00 Hi Joly, If something like this was going to happen, we could have expanded the v4 address space to 64 bits with IPxl: http://bill.herrin.us/network/ipxl.html At this point IPv6 has enough momentum that it can be safely expected to happen. That means all proposals for extending the IPv4 address space are basically dead in the water, especially complicated ones. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From joly at punkcast.com Mon Mar 6 16:32:15 2017 From: joly at punkcast.com (Joly MacFie) Date: Mon, 6 Mar 2017 11:32:15 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: Message-ID: I believe that. However it behooves us to give any of our members' ideas a fair hearing. I'm hoping he'll get some good push back in the session. Joly MacFie joly at punkcast.com 218 565 9365 On Mar 6, 2017 11:14 AM, "William Herrin" wrote: > On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie wrote: > > To say that Mr. Chen's EZIP proposal has not, thus far, been received > with > > open arms by the networking community would be an understatement. It is > > seen as delaying the inevitable and introducing an impractical extra > > routing hardware layer that will be hit & miss. Nevertheless, since much > of > > the world is still IPv4 dependent, it just could take off. ISOC-NY is > happy > > to give him the opportunity to expound on its merits. > > We'd welcome some expert respondents. > > > > See: > > https://tools.ietf.org/html/draft-chen-ati-ipv4-with- > adaptive-address-space-00 > > Hi Joly, > > If something like this was going to happen, we could have expanded the > v4 address space to 64 bits with IPxl: > http://bill.herrin.us/network/ipxl.html > > At this point IPv6 has enough momentum that it can be safely expected > to happen. That means all proposals for extending the IPv4 address > space are basically dead in the water, especially complicated ones. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From valdis.kletnieks at vt.edu Mon Mar 6 17:16:32 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 06 Mar 2017 12:16:32 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: Message-ID: <7641.1488820592@turing-police.cc.vt.edu> On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said: > routing hardware layer that will be hit & miss. Nevertheless, since much of > the world is still IPv4 dependent, it just could take off. For it to "take off", the very same people who have dragged their heels deploying IPv6 will need to suddenly jump up and upgrade all their gear and personnel to support a *third* protocol. Oh, and you're going to need support buy-in from *at least* Microsoft, Apple, Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear. What's the business case for all these stakeholders to buy into EZIP? For both the "We already do IPv6" and "We don't do IP6v" cases? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From pkranz at unwiredltd.com Mon Mar 6 17:24:08 2017 From: pkranz at unwiredltd.com (Peter Kranz) Date: Mon, 6 Mar 2017 09:24:08 -0800 Subject: www.netflix.com / EC2 problem -- Persistent problems from Palo Alto to destinations to Netflix and other destinations with content on Amazon EC2 - 2000ms latency Message-ID: <017601d2969e$769cea80$63d6bf80$@unwiredltd.com> I'm not making progress with GTT's NOC on this issue, can someone clued in at Netflix or Amazon comment on this problem. I believe it started after Amazons outage last week. This is an MTR to www.netflix.com (52.5.161.36) from 208.71.159.3 . this should be just a couple of ms away from Palo Alto: Via GTT's own looking glass tool: IPv4 traceroute to 52.5.161.36 HOST: pao11-re0 Loss% Snt Last Avg Best Wrst StDev 1. et-2-1-0.cr4-dal3.ip4.gtt.ne 0.0% 5 42.3 39.4 36.1 42.3 2.2 2. ip4.gtt.net 0.0% 5 36.1 38.6 36.1 41.5 2.4 3. 176.32.125.140 0.0% 5 48.5 55.2 48.5 61.9 5.0 4. 176.32.125.145 0.0% 5 39.5 41.2 36.2 45.0 3.4 5. 54.239.43.200 20.0% 5 1417. 1784. 1417. 2112. 306.6 6. 54.239.43.98 20.0% 5 1413. 1770. 1413. 2116. 312.0 7. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 8. 54.239.110.157 20.0% 5 1420. 1749. 1420. 2104. 306.9 9. 54.239.109.9 20.0% 5 1394. 1720. 1394. 2081. 308.7 10. 205.251.245.65 20.0% 5 1395. 1706. 1395. 2072. 305.4 11. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From bicknell at ufp.org Mon Mar 6 17:26:53 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Mar 2017 09:26:53 -0800 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: <7641.1488820592@turing-police.cc.vt.edu> References: <7641.1488820592@turing-police.cc.vt.edu> Message-ID: <20170306172653.GA45528@ussenterprise.ufp.org> In a message written on Mon, Mar 06, 2017 at 12:16:32PM -0500, valdis.kletnieks at vt.edu wrote: > Oh, and you're going to need support buy-in from *at least* Microsoft, Apple, > Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear. Valdis is just spouting a bunch of fake requirements. It's all lies folks. I mean the thing is called "EZIP", the EZ is right in the name. We're going to drain that IETF swamp of all their so-called experts and make sure simple proposals like this that regular people can understand get a fair shot. It's going to change the Internet, bigly. And, what about the e-mails? I mean, come on, what are those SMTP people hiding? [For the humor impared, it's a joke folks.] -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From pkranz at unwiredltd.com Mon Mar 6 17:33:04 2017 From: pkranz at unwiredltd.com (Peter Kranz) Date: Mon, 6 Mar 2017 09:33:04 -0800 Subject: www.netflix.com / EC2 problem -- Persistent problems from Palo Alto to destinations to Netflix and other destinations with content on Amazon EC2 - 2000ms latency In-Reply-To: <017601d2969e$769cea80$63d6bf80$@unwiredltd.com> References: <017601d2969e$769cea80$63d6bf80$@unwiredltd.com> Message-ID: <02cb01d2969f$b5f0f680$21d2e380$@unwiredltd.com> First version got a little munged: I'm not making progress with GTT's NOC on this issue, can someone clued in at Netflix or Amazon comment on this problem. I believe it started after Amazons outage last week. This is an MTR to www.netflix.com (52.5.161.36) from 208.71.159.3 . this should be just a couple of ms away from Palo Alto: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 208.71.159.113 0.0% 9 0.4 0.5 0.4 0.7 0.0 2. 204.11.106.45 0.0% 9 2.1 2.1 2.0 2.2 0.0 3. 173.205.47.153 0.0% 9 36.4 5.8 1.9 36.4 11.5 4. 89.149.184.177 0.0% 9 37.8 38.1 37.6 40.5 0.6 5. 173.205.39.122 0.0% 9 37.9 37.8 37.6 38.3 0.0 6. 176.32.125.164 0.0% 9 50.0 48.4 39.0 55.5 5.8 7. 176.32.125.169 0.0% 9 38.0 37.9 37.7 38.5 0.0 8. 54.239.43.200 12.5% 9 1117. 1096. 862.8 1662. 274.5 9. 54.239.43.174 12.5% 8 1146. 1092. 872.1 1627. 261.4 10. ??? 11. 54.239.110.227 12.5% 8 1266. 1247. 908.7 1566. 236.7 12. 54.239.111.67 12.5% 8 1230. 1075. 883.4 1511. 227.7 13. 205.251.244.193 12.5% 8 1247. 1068. 890.1 1477. 219.1 14. ??? Via GTT's own looking glass tool: (Note the latency and packet loss starting at hop 5) IPv4 traceroute to 52.5.161.36 HOST: pao11-re0 Loss% Snt Last Avg Best Wrst StDev 1. et-2-1-0.cr4-dal3.ip4.gtt.ne 0.0% 5 42.3 39.4 36.1 42.3 2.2 2. ip4.gtt.net 0.0% 5 36.1 38.6 36.1 41.5 2.4 3. 176.32.125.140 0.0% 5 48.5 55.2 48.5 61.9 5.0 4. 176.32.125.145 0.0% 5 39.5 41.2 36.2 45.0 3.4 5. 54.239.43.200 20.0% 5 1417. 1784. 1417. 2112. 306.6 6. 54.239.43.98 20.0% 5 1413. 1770. 1413. 2116. 312.0 7. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 8. 54.239.110.157 20.0% 5 1420. 1749. 1420. 2104. 306.9 9. 54.239.109.9 20.0% 5 1394. 1720. 1394. 2081. 308.7 10. 205.251.245.65 20.0% 5 1395. 1706. 1395. 2072. 305.4 11. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From baldur.norddahl at gmail.com Mon Mar 6 21:00:45 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 6 Mar 2017 22:00:45 +0100 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: Message-ID: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> That proposal is far too wordy. Here is the executive summary: Encode extra address bits in extension headers. Add a network element near the destination that converts such that the destination IP of a packet to IP a.b.c.d with extension header containing e.f is translated to 192.168.e.f. In the reverse direction translate source address 192.168.e.f to a.b.c.d and add option header with e.f. Executive summary end. As far as I can tell, the only advantage of this proposal over IPv6 is that the network core does not need to be changed. You could communicate with someone that had an EZIP address regardless that your ISP did nothing to support EZIP. The disadvantage is that every single server out there would need to be changed so it does not just drop the option headers on the reply packets. All firewalls updated so they do not block packets with option headers. All applications updated so they understand a new address format. Servers and applications could also confuse TCP or UDP streams that are apparently from the same source, same port numbers, only thing that differentiates the streams is some option header that the server does not understand. The customers of the ISP that deploys EZIP would not need to update anything (unless they need to communicate with other poor souls that got assigned EZIP addresses), however everyone else would. This is not a good balance. The customers would experience an internet where almost nothing works. It would be magnitudes worse than the experience of an IPv6 only network with NAT64. It is a fix for the wrong problem. Major ISPs have IPv6 support now. It is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 why would you expect them to deploy EZIP? Why would some old forgotten site with old song texts in some backwater country somewhere? We already have better solutions such as CGN with dual stack, NAT64, DS-Lite, MAP etc. None of that is discussed in the RFC. Is the author aware of it? Regards, Baldur Den 06/03/2017 kl. 09.08 skrev Joly MacFie: > To say that Mr. Chen's EZIP proposal has not, thus far, been received with > open arms by the networking community would be an understatement. It is > seen as delaying the inevitable and introducing an impractical extra > routing hardware layer that will be hit & miss. Nevertheless, since much of > the world is still IPv4 dependent, it just could take off. ISOC-NY is happy > to give him the opportunity to expound on its merits. > ? We'd welcome some expert respondents.? > > ?See: ? > https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00 > > > ?==================================================================? > > WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen > > On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter > (ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y. > Chen, VP of Engineering, Avinta Communications, will present his EzIP > proposal to reinvigorate the diminishing pool of IPv4 addresses. > ?Optional registration > at the link below. This will be recorded. > > What: WEBINAR: Can We Make IPv4 Great Again? > When: Tuesday March 8 2017 Noon EST | 17:00 UTC > Register + info: https://www.meetup.com/isoc-ny/events/238164448/ > Computer: https://zoom.us/j/914492141 > Phone: http://bit.ly/zoomphone > ? ? > ID: 914 492 141 > Twitter: #ezip > > ?====================================================================? > > > > > > > > > > > Permalink > > http://isoc-ny.org/p2/9031 > > > > > > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > -------------------------------------------------------------- > - From bill at herrin.us Mon Mar 6 21:11:35 2017 From: bill at herrin.us (William Herrin) Date: Mon, 6 Mar 2017 16:11:35 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> References: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> Message-ID: On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl wrote: > Major ISPs have IPv6 support now. It is > the sites (=servers) that are lacking. Hi Baldur, Not exactly. My Verizon FiOS does not support IPv6. Neither does my Cox Cable Internet. My Verizon Wireless service supports IPv6 but my AT&T Wireless service does not. All four of these entities have IPv6 somewhere in their networks but that's not at all the same thing as saying they "have IPv6 support." IPv6 deployment has gathered some momentum, enough that it's unlikely to sputter out, but it's still laughably weak. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bob at FiberInternetCenter.com Mon Mar 6 21:34:16 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 6 Mar 2017 13:34:16 -0800 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> Message-ID: I think only 22% of networks with an AS announce IPv6 space. Is that correct ? Thank You Bob Evans CTO > On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl > wrote: >> Major ISPs have IPv6 support now. It is >> the sites (=servers) that are lacking. > > Hi Baldur, > > Not exactly. My Verizon FiOS does not support IPv6. Neither does my > Cox Cable Internet. My Verizon Wireless service supports IPv6 but my > AT&T Wireless service does not. > > All four of these entities have IPv6 somewhere in their networks but > that's not at all the same thing as saying they "have IPv6 support." > > IPv6 deployment has gathered some momentum, enough that it's unlikely > to sputter out, but it's still laughably weak. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From dmburgess at linktechs.net Mon Mar 6 22:04:20 2017 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 6 Mar 2017 22:04:20 +0000 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> Message-ID: Well try to get ATT to announce IPv6 though our AS! Lol Been on the phone with the for over a month. Still no ETA :( Dennis Burgess - Network Solution Engineer - Consultant MikroTik Certified Trainer/Consultant - MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE For Wireless Hardware/Routers visit www.linktechs.net Radio Frequiency Coverages: www.towercoverage.com Office: 314-735-0270 E-Mail: dmburgess at linktechs.net -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans Sent: Monday, March 6, 2017 3:34 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again? I think only 22% of networks with an AS announce IPv6 space. Is that correct ? Thank You Bob Evans CTO > On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl > wrote: >> Major ISPs have IPv6 support now. It is the sites (=servers) that are >> lacking. > > Hi Baldur, > > Not exactly. My Verizon FiOS does not support IPv6. Neither does my > Cox Cable Internet. My Verizon Wireless service supports IPv6 but my > AT&T Wireless service does not. > > All four of these entities have IPv6 somewhere in their networks but > that's not at all the same thing as saying they "have IPv6 support." > > IPv6 deployment has gathered some momentum, enough that it's unlikely > to sputter out, but it's still laughably weak. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From sethm at rollernet.us Mon Mar 6 22:34:50 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 6 Mar 2017 14:34:50 -0800 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> Message-ID: On 3/6/17 14:04, Dennis Burgess wrote: > Well try to get ATT to announce IPv6 though our AS! Lol Been on the phone with the for over a month. Still no ETA :( Requests driven from the sales side should have the best results. Before Charter's sales turned into a hole of poor service, I had a account manager that actually cared about the whole picture. I told him the reason nobody before him was able to sell to us is because we have requirements that need to be deliverable (no native IPv6 no sale), can't deal in promises. Of course he's no longer there and I'm back to idiots that just want to see how high of a price they can get you to sign for, especially if you're already a customer there's no need to pretend to care further. ~Seth From cabo at tzi.org Mon Mar 6 22:45:39 2017 From: cabo at tzi.org (Carsten Bormann) Date: Mon, 6 Mar 2017 23:45:39 +0100 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> References: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> Message-ID: <34CE0D19-9CEE-4610-88B7-4D799E58B526@tzi.org> On 6 Mar 2017, at 22:00, Baldur Norddahl wrote: > > Encode extra address bits in extension headers. Add a network element near the destination that converts such that the destination IP of a packet to IP a.b.c.d with extension header containing e.f is translated to 192.168.e.f. In the reverse direction translate source address 192.168.e.f to a.b.c.d and add option header with e.f. 6to4 essentially did this already. The main problem with 6to4 that made us stop using it was communicating to non-6to4 (?native?) IPv6 addresses; if you don?t want that, you have running code for both router and host side and plenty of gear that already works. (All this is still complete nonsense in the face of accelerating native IPv6 adoption; I write this just to show that the idea already has been implemented out there.) Gr??e, Carsten From bob at FiberInternetCenter.com Mon Mar 6 22:48:50 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 6 Mar 2017 14:48:50 -0800 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> Message-ID: <59f04cec29296d59f589ee671c65edc8.squirrel@66.201.44.180> I have had ipv4 transit with ATT for years (one provider of many)....and the order originally placed was for both ipv4 and 6....yep still waiting. Thank You Bob Evans CTO > On 3/6/17 14:04, Dennis Burgess wrote: >> Well try to get ATT to announce IPv6 though our AS! Lol Been on the >> phone with the for over a month. Still no ETA :( > > > Requests driven from the sales side should have the best results. > > Before Charter's sales turned into a hole of poor service, I had a > account manager that actually cared about the whole picture. I told him > the reason nobody before him was able to sell to us is because we have > requirements that need to be deliverable (no native IPv6 no sale), can't > deal in promises. Of course he's no longer there and I'm back to idiots > that just want to see how high of a price they can get you to sign for, > especially if you're already a customer there's no need to pretend to > care further. > > ~Seth > From marka at isc.org Tue Mar 7 00:50:59 2017 From: marka at isc.org (Mark Andrews) Date: Tue, 07 Mar 2017 11:50:59 +1100 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: Your message of "Mon, 06 Mar 2017 14:48:50 -0800." <59f04cec29296d59f589ee671c65edc8.squirrel@66.201.44.180> References: <5645714e-e468-4655-34cf-6e70aa7cfa26@gmail.com> <59f04cec29296d59f589ee671c65edc8.squirrel@66.201.44.180> Message-ID: <20170307005059.3E158660E768@rock.dv.isc.org> In message <59f04cec29296d59f589ee671c65edc8.squirrel at 66.201.44.180>, "Bob Evans" writes: > I have had ipv4 transit with ATT for years (one provider of many)....and > the order originally placed was for both ipv4 and 6....yep still waiting. > > Thank You > Bob Evans > CTO Cancel your service and say it is because they failed to deliver IPv6. If they try to fight you for breaking the contract they don't have a leg to stand on because they have failed to deliver on their part of the contract. I more people did this you would see IPv6 move up the priority stack. Mark > > On 3/6/17 14:04, Dennis Burgess wrote: > >> Well try to get ATT to announce IPv6 though our AS! Lol Been on the > >> phone with the for over a month. Still no ETA :( > > > > > > Requests driven from the sales side should have the best results. > > > > Before Charter's sales turned into a hole of poor service, I had a > > account manager that actually cared about the whole picture. I told him > > the reason nobody before him was able to sell to us is because we have > > requirements that need to be deliverable (no native IPv6 no sale), can't > > deal in promises. Of course he's no longer there and I'm back to idiots > > that just want to see how high of a price they can get you to sign for, > > especially if you're already a customer there's no need to pretend to > > care further. > > > > ~Seth > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bruns at 2mbit.com Tue Mar 7 02:13:10 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 6 Mar 2017 19:13:10 -0700 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: <7641.1488820592@turing-police.cc.vt.edu> References: <7641.1488820592@turing-police.cc.vt.edu> Message-ID: <608f5c96-3134-9cdf-6f93-41d14d371d5d@2mbit.com> On 3/6/17 10:16 AM, valdis.kletnieks at vt.edu wrote: > On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said: > >> routing hardware layer that will be hit & miss. Nevertheless, since much of >> the world is still IPv4 dependent, it just could take off. > > For it to "take off", the very same people who have dragged their heels > deploying IPv6 will need to suddenly jump up and upgrade all their gear > and personnel to support a *third* protocol. > > Oh, and you're going to need support buy-in from *at least* Microsoft, Apple, > Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear. > > What's the business case for all these stakeholders to buy into EZIP? For > both the "We already do IPv6" and "We don't do IP6v" cases? > Lets not even get into the fact that we still can't fully utilize things like already established standards such as ECN, EDNS, and PMTUD effectively because firewall and security vendors still can't extricate their heads from backside and handle basic functionality of IPv4 without throwing the packets on the floor. If the average 'security' device these days chokes and drops a packet due to not recognizing the ECN option, what makes anyone think shoving more special stuff in the headers just for IoT crap is a good idea? Wouldn't it just be easier to use IPv6 tunneled over Teredo? Oh wait, that would require the IoT vendors to actually build decent products with software that works. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bill at herrin.us Tue Mar 7 03:59:34 2017 From: bill at herrin.us (William Herrin) Date: Mon, 6 Mar 2017 22:59:34 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: <608f5c96-3134-9cdf-6f93-41d14d371d5d@2mbit.com> References: <7641.1488820592@turing-police.cc.vt.edu> <608f5c96-3134-9cdf-6f93-41d14d371d5d@2mbit.com> Message-ID: On Mon, Mar 6, 2017 at 9:13 PM, Brielle Bruns wrote: > Lets not even get into the fact that we still can't fully utilize things > like already established standards such as ECN, EDNS, and PMTUD effectively > because firewall and security vendors still can't extricate their heads from > backside and handle basic functionality of IPv4 without throwing the packets > on the floor. PMTUD is broken as designed, the one thing about TCP which directly violates the end-to-end principle. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From marka at isc.org Tue Mar 7 04:10:31 2017 From: marka at isc.org (Mark Andrews) Date: Tue, 07 Mar 2017 15:10:31 +1100 Subject: IPv6 doc. prefix (2001:db8::/32) - APNIC object ? In-Reply-To: Your message of "Mon, 06 Mar 2017 10:55:18 -0500." <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> References: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> Message-ID: <20170307041031.A353E6611009@rock.dv.isc.org> In message <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E at burn.net>, Brandon Applegate writes: > Just did a whois on the documentation prefix and was surprised to see > what looks like a user object registered for it: > > % Information related to '2001:0DB8::/32AS132111' > > route6: 2001:0DB8::/32 > descr: FUTURE D SDN BHD > origin: AS132111 > country: MY > mnt-by: MAINT-FUTUREDSDNBHD-MY > changed: hm-changed at apnic.net 20160523 > source: APNIC > > Any idea what this is ? I would have thought there might be some sanity > check that would have stopped this from getting registered ? Open a ticket with APNIC to get it fixed. > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 > "SH1-0151. This is the serial number, of our orbital gun." -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Tue Mar 7 16:28:43 2017 From: joelja at bogus.com (joel jaeggli) Date: Tue, 7 Mar 2017 08:28:43 -0800 Subject: google ipv6 routes via cogent In-Reply-To: <91BEAAEB-9913-4715-96D5-5D5613F0AC2D@puck.nether.net> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <139584545.18898.1488463289724.JavaMail.mhammett@ThunderFuck> <002201d2936c$61011e60$23035b20$@gvtc.com> <006001d2936e$cb058d30$6110a790$@gvtc.com> <000001d29383$da01b6f0$8e0524d0$@gvtc.com> <20170302185820.e3cqwcnvmzcgek2o@mew.swordarmor.fr> <000901d2938e$7be4d880$73ae8980$@gvtc.com> <91BEAAEB-9913-4715-96D5-5D5613F0AC2D@puck.nether.net> Message-ID: On 3/2/17 3:42 PM, Jared Mauch wrote: > Yes. Most providers can send you just their customer routes. If they send you full routes you want to discriminate customer vs peer routes. This is typically done with communities and is worthwhile as most people have capacity on customer links but via peer it may not always be the case. > > As is usual YMMV It's relatively straight-forward to take a full table feed and accept into your fib only the routes you want from that table. I presented on variant of that based on my need for partial fib peering switches; but other reasons for doing so exist, e.g. defailt + te-overrides, prefix filters weighted by per prefix utilization and so on. In general I'd get the full table and the default if you intend to take the default but need recourse to over-rides (for example if your fib won't hold full table is an element of the design). if the Rib won't hold three full tables well that's a different sort of problem, and this may be the wrong router platform. joel > Jared Mauch > >> On Mar 2, 2017, at 2:52 PM, Aaron Gould wrote: >> >> Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please. >> >> -Aaron > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From jheitz at cisco.com Tue Mar 7 17:46:12 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Tue, 7 Mar 2017 17:46:12 +0000 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? Message-ID: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> 1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f. Some higher layer protocols embed IP addresses into their data. These points make changing IP so difficult. In addition, IPv6 has link local addresses. This one seemingly insignificant detail causes so much code churn and is probably responsible for 10 years of the IPv6 drag. Thakfully, site local was deprecated. Thanks, Jakob. > Date: Mon, 6 Mar 2017 22:00:45 +0100 > From: Baldur Norddahl > To: nanog at nanog.org > Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again? > Message-ID: <5645714e-e468-4655-34cf-6e70aa7cfa26 at gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > That proposal is far too wordy. Here is the executive summary: > > Encode extra address bits in extension headers. Add a network element > near the destination that converts such that the destination IP of a > packet to IP a.b.c.d with extension header containing e.f is translated > to 192.168.e.f. In the reverse direction translate source address > 192.168.e.f to a.b.c.d and add option header with e.f. > > Executive summary end. > > As far as I can tell, the only advantage of this proposal over IPv6 is > that the network core does not need to be changed. You could communicate > with someone that had an EZIP address regardless that your ISP did > nothing to support EZIP. > > The disadvantage is that every single server out there would need to be > changed so it does not just drop the option headers on the reply > packets. All firewalls updated so they do not block packets with option > headers. All applications updated so they understand a new address format. > > Servers and applications could also confuse TCP or UDP streams that are > apparently from the same source, same port numbers, only thing that > differentiates the streams is some option header that the server does > not understand. > > The customers of the ISP that deploys EZIP would not need to update > anything (unless they need to communicate with other poor souls that got > assigned EZIP addresses), however everyone else would. This is not a > good balance. The customers would experience an internet where almost > nothing works. It would be magnitudes worse than the experience of an > IPv6 only network with NAT64. > > It is a fix for the wrong problem. Major ISPs have IPv6 support now. It > is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 > why would you expect them to deploy EZIP? Why would some old forgotten > site with old song texts in some backwater country somewhere? > > We already have better solutions such as CGN with dual stack, NAT64, > DS-Lite, MAP etc. > > None of that is discussed in the RFC. Is the author aware of it? > > Regards, > > Baldur > From marka at isc.org Tue Mar 7 23:25:09 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Mar 2017 10:25:09 +1100 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: Your message of "Mon, 06 Mar 2017 19:13:10 -0700." <608f5c96-3134-9cdf-6f93-41d14d371d5d@2mbit.com> References: <7641.1488820592@turing-police.cc.vt.edu> <608f5c96-3134-9cdf-6f93-41d14d371d5d@2mbit.com> Message-ID: <20170307232509.9860F661F0A5@rock.dv.isc.org> In message <608f5c96-3134-9cdf-6f93-41d14d371d5d at 2mbit.com>, Brielle Bruns writ es: > On 3/6/17 10:16 AM, valdis.kletnieks at vt.edu wrote: > > On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said: > > > >> routing hardware layer that will be hit & miss. Nevertheless, since much o > f > >> the world is still IPv4 dependent, it just could take off. > > > > For it to "take off", the very same people who have dragged their heels > > deploying IPv6 will need to suddenly jump up and upgrade all their gear > > and personnel to support a *third* protocol. > > > > Oh, and you're going to need support buy-in from *at least* Microsoft, Appl > e, > > Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear. > > > > What's the business case for all these stakeholders to buy into EZIP? For > > both the "We already do IPv6" and "We don't do IP6v" cases? > > > > > Lets not even get into the fact that we still can't fully utilize things > like already established standards such as ECN, EDNS, and PMTUD > effectively because firewall and security vendors still can't extricate > their heads from backside and handle basic functionality of IPv4 without > throwing the packets on the floor. While this is a Checkpoint example and Checkpoint are in the process of addressing this the issue is in no way limited to Checkpoint. Firewall R75.20 Administration Guide 20 May 2012 DNS verification of EDNS queries is supported. This allows use of BIND. EDNS headers are allowed if they contain all zeros, other than the field that controls the packet length (maximum payload size). BIND had the ability to send send and answer EDNS options for years by then so it should have read if it was honest: DNS verification of EDNS queries is supported. EDNS headers are allowed if they contain all zeros, other than the field that controls the packet length (maximum payload size). This breaks EDNS version negotiation and prevents the use of EDNS options by BIND and other name servers. This also breaks the ability to use new EDNS flags as specified by the IETF. db30f4bdcb (Mark Andrews 2008-04-03 02:01:08 +0000 6809) 2353. [func] Add support for Name Server ID (RFC 5001). 'dig +nsid' requests NSID from server. 'request-nsid yes;' causes recursive server to send NSID requests to upstream servers. Server responds to NSID requests with the string configured by 'server-id' option. [RT #17091] These sorts of checks should have never been there in the first place RFC 2671 already defined what to do with EDNS version != 0 queries which is to return a BADVERS error code. What purpose did blocking version != 0 serve? Similarly for EDNS flags. These are supposed to be ingored if you don't support them. What purpose does blocking these flags serve? RFC 6891 should have bumped the EDNS version number but it was impractical to do that because firewall vendors decided that only EDNS version 0 queries are valid rather than letting the nameserver perform EDNS version negotiation. RFC 6891 cleaned up the handling of unknown EDNS options (it was under specified) and bumping the EDNS version number would, in theory, give consistent handling (ignore unknown options) in EDNS(1) queries. You are buying this stuff. You need to understand what it is doing and the vendors need to be clear about how it is breaking stuff. Mark > If the average 'security' device these days chokes and drops a packet > due to not recognizing the ECN option, what makes anyone think shoving > more special stuff in the headers just for IoT crap is a good idea? > > Wouldn't it just be easier to use IPv6 tunneled over Teredo? > > Oh wait, that would require the IoT vendors to actually build decent > products with software that works. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bohn at adelphi.edu Tue Mar 7 23:27:06 2017 From: bohn at adelphi.edu (Dennis Bohn) Date: Tue, 7 Mar 2017 18:27:06 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> References: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> Message-ID: > > > In addition, IPv6 has link local addresses. > This one seemingly insignificant detail causes so much code churn > and is probably responsible for 10 years of the IPv6 drag. AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to try to figure something out, a coincidence that this is in reply to Jakob from Cisco but is based on what he wrote) relies on Link Local addresses. I didn't understand why link locals should be there in the first place seemed klugey and have googled, looked at rfcs and tried to understand why link local addresses were baked into V6. The only thing I found was that it enabled interfaces on point to point links to be unaddressed in V6. (To save address space!??) Can anyone point me in a direction to understand the reasoning for link local addressing? dennis From valdis.kletnieks at vt.edu Tue Mar 7 23:46:50 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 07 Mar 2017 18:46:50 -0500 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> Message-ID: <29242.1488930410@turing-police.cc.vt.edu> On Tue, 07 Mar 2017 18:27:06 -0500, Dennis Bohn said: > AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to > try to figure something out, a coincidence that this is in reply to Jakob > from Cisco but is based on what he wrote) relies on Link Local addresses. > I didn't understand why link locals should be there in the first place > seemed klugey and have googled, looked at rfcs and tried to understand why > link local addresses were baked into V6. The only thing I found was that it > enabled interfaces on point to point links to be unaddressed in V6. (To > save address space!??) Can anyone point me in a direction to understand the > reasoning for link local addressing? Because there are a lot of corner cases where you may want to talk to the network before you find out what your network address is. And if it's a stand-alone network, it may not *have* a well-define network prefix to use for SLAAC auto-config addressing. Think about all the places in IPv4 where you toss packets on the net with your MAC address or a bogus placeholder IP address because you don't have an IP address yet (ARP, DHCP for starters). Link-Local is basically the same thing in the IPv6 world. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From mike at mikejones.in Wed Mar 8 00:15:20 2017 From: mike at mikejones.in (Mike Jones) Date: Wed, 8 Mar 2017 00:15:20 +0000 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> Message-ID: On 7 March 2017 at 23:27, Dennis Bohn wrote: > > > > > > In addition, IPv6 has link local addresses. > > This one seemingly insignificant detail causes so much code churn > > and is probably responsible for 10 years of the IPv6 drag. > > AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to > try to figure something out, a coincidence that this is in reply to Jakob > from Cisco but is based on what he wrote) relies on Link Local addresses. > I didn't understand why link locals should be there in the first place > seemed klugey and have googled, looked at rfcs and tried to understand why > link local addresses were baked into V6. The only thing I found was that it > enabled interfaces on point to point links to be unaddressed in V6. (To > save address space!??) Can anyone point me in a direction to understand the > reasoning for link local addressing? > So you can print whilst your Internet connection is down. IPv6 allowed people to rethink IPv4 assumptions, and they realised that a lot of IPv4 things were hacks to work around a lack of functionality in the protocol. NAT has polluted peoples minds when it comes to the distinctions between local and global addressing. Why would you use a global address, with an extra code check to make sure it is on a directly attached interface, to point a route at? "Router 2 on interface B" makes more sense to me than "Router with global address 12345" in this context. I would also have loved it if the all-routers-anycast thing had been better defined rather than deprecated. One of the potential default behaviours could have been fe80:: as a default gateway on every segment, with a logical meaning of "All upstream routers on this interface". - Mike From alarig at swordarmor.fr Wed Mar 8 07:18:01 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Wed, 8 Mar 2017 08:18:01 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <001801d28f7e$d063ac10$712b0430$@gvtc.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Message-ID: <20170308071801.ux6ac2tzrrrqfn7x@mew.swordarmor.fr> On sam. 25 f?vr. 09:49:56 2017, Aaron wrote: > Hi, I'm new to the nanog list, hope this isn't out of scope for what is > usually discussed here. > > > > Cogent is telling me that I can't route through cogent to get to google ipv6 > routes (particularly the well known dns addresses 2001:4860:4860::88xx) > because google decided not to advertise those route to one of their mutual > peers. > > > > Anyone know anything about this ? .and why it happened and when it will be > resolved ? > > > > -Aaron Hi, Since this morning, I see again google routes from cogent: https://paste.swordarmor.fr/raw/wnFQ But, with very bad latency. To go from Rennes (France) to Frankfurt (Germany), it transits via Sydney, and still thought other ASes: https://paste.swordarmor.fr/raw/PlSM -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From marty at cloudflare.com Wed Mar 8 09:29:11 2017 From: marty at cloudflare.com (Marty Strong) Date: Wed, 8 Mar 2017 09:29:11 +0000 Subject: google ipv6 routes via cogent In-Reply-To: <20170308071801.ux6ac2tzrrrqfn7x@mew.swordarmor.fr> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <20170308071801.ux6ac2tzrrrqfn7x@mew.swordarmor.fr> Message-ID: <41981676-2734-4176-9A52-D1F941157D91@cloudflare.com> I wouldn?t be surprised if that?s unwanted, where Telstra domestic is announcing to Telstra International, who in turn announces to Cogent. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 8 Mar 2017, at 07:18, Alarig Le Lay wrote: > > On sam. 25 f?vr. 09:49:56 2017, Aaron wrote: >> Hi, I'm new to the nanog list, hope this isn't out of scope for what is >> usually discussed here. >> >> >> >> Cogent is telling me that I can't route through cogent to get to google ipv6 >> routes (particularly the well known dns addresses 2001:4860:4860::88xx) >> because google decided not to advertise those route to one of their mutual >> peers. >> >> >> >> Anyone know anything about this ? .and why it happened and when it will be >> resolved ? >> >> >> >> -Aaron > > Hi, > > Since this morning, I see again google routes from cogent: > https://paste.swordarmor.fr/raw/wnFQ > > But, with very bad latency. To go from Rennes (France) to Frankfurt > (Germany), it transits via Sydney, and still thought other ASes: > https://paste.swordarmor.fr/raw/PlSM > > -- > alarig From baldur.norddahl at gmail.com Wed Mar 8 10:00:19 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 8 Mar 2017 11:00:19 +0100 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> References: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> Message-ID: <5651642f-93a0-7fe2-2ccc-8797ce1f825b@gmail.com> EZIP has no transition strategy and is not backwards compatible with IPv4. The scheme is unworkable. It is not possible to dual stack EZIP because it pretends to be IPv4. The author of EZIP should demonstrate a working prototype. We need to see a setup with two clients on a shared external IP address. Then demonstrate that the clients can access an EZIP enabled site and also that the clients can access unmodified IPv4 sites such as Google.com and Facebook.com. The later test will fail and there is no fix. EZIP requires a big bang transition where the whole world implements EZIP on the same day. EZIP embeds extra address information in IP option headers. The remote site needs to take that extra address information and send back in the replies. The remote site needs to read the extra "source EZIP" option header and put that as an "destination EZIP" option header on reply packets. Legacy IPv4 sites do not know the meaning the extra option headers and can not do send them back. Packets will arrive at the EZIP gateway without option headers. The EZIP gateway will have no option other than to drop the packets, because without option headers nothing will differentiate the multiple clients behind the gateway. The EZIP gateway could fall back to NAT when the remote site does not have EZIP support. However no method is provided that can tell the EZIP gateway wether the remote has EZIP support or not. Since the EZIP gateway works on the IP level, we can not use some DNS tricks like NAT64/DNS64. Regards, Baldur On 07-03-2017 18:46, Jakob Heitz (jheitz) wrote: > 1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f. > > Some higher layer protocols embed IP addresses into their data. > > These points make changing IP so difficult. > > In addition, IPv6 has link local addresses. > This one seemingly insignificant detail causes so much code churn > and is probably responsible for 10 years of the IPv6 drag. > Thakfully, site local was deprecated. > > Thanks, > Jakob. > >> Date: Mon, 6 Mar 2017 22:00:45 +0100 >> From: Baldur Norddahl >> To: nanog at nanog.org >> Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again? >> Message-ID: <5645714e-e468-4655-34cf-6e70aa7cfa26 at gmail.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> That proposal is far too wordy. Here is the executive summary: >> >> Encode extra address bits in extension headers. Add a network element >> near the destination that converts such that the destination IP of a >> packet to IP a.b.c.d with extension header containing e.f is translated >> to 192.168.e.f. In the reverse direction translate source address >> 192.168.e.f to a.b.c.d and add option header with e.f. >> >> Executive summary end. >> >> As far as I can tell, the only advantage of this proposal over IPv6 is >> that the network core does not need to be changed. You could communicate >> with someone that had an EZIP address regardless that your ISP did >> nothing to support EZIP. >> >> The disadvantage is that every single server out there would need to be >> changed so it does not just drop the option headers on the reply >> packets. All firewalls updated so they do not block packets with option >> headers. All applications updated so they understand a new address format. >> >> Servers and applications could also confuse TCP or UDP streams that are >> apparently from the same source, same port numbers, only thing that >> differentiates the streams is some option header that the server does >> not understand. >> >> The customers of the ISP that deploys EZIP would not need to update >> anything (unless they need to communicate with other poor souls that got >> assigned EZIP addresses), however everyone else would. This is not a >> good balance. The customers would experience an internet where almost >> nothing works. It would be magnitudes worse than the experience of an >> IPv6 only network with NAT64. >> >> It is a fix for the wrong problem. Major ISPs have IPv6 support now. It >> is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 >> why would you expect them to deploy EZIP? Why would some old forgotten >> site with old song texts in some backwater country somewhere? >> >> We already have better solutions such as CGN with dual stack, NAT64, >> DS-Lite, MAP etc. >> >> None of that is discussed in the RFC. Is the author aware of it? >> >> Regards, >> >> Baldur >> From baldur.norddahl at gmail.com Wed Mar 8 10:27:52 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 8 Mar 2017 11:27:52 +0100 Subject: WEBINAR TUESDAY: Can We Make IPv4 Great Again? In-Reply-To: References: <88c3738508144001bde3f0de7460b623@XCH-ALN-014.cisco.com> Message-ID: <22be287a-5aaa-54ab-8a37-89a40905827e@gmail.com> On 08-03-2017 00:27, Dennis Bohn wrote: >> >> In addition, IPv6 has link local addresses. >> This one seemingly insignificant detail causes so much code churn >> and is probably responsible for 10 years of the IPv6 drag. > AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to > try to figure something out, a coincidence that this is in reply to Jakob > from Cisco but is based on what he wrote) relies on Link Local addresses. > I didn't understand why link locals should be there in the first place > seemed klugey and have googled, looked at rfcs and tried to understand why > link local addresses were baked into V6. The only thing I found was that it > enabled interfaces on point to point links to be unaddressed in V6. (To > save address space!??) Can anyone point me in a direction to understand the > reasoning for link local addressing? > > dennis Many features of IPv6 depends on link local. Take a look at the routing table of your computer - you will find that most routes have a next hop with a link local address. Many buildin protocols, such as RA and DHCPv6, use link local to communicate without depending on any configuration. Many protocols with automatic discovery will use link local - why would you want your printer or local NAS server to use a public IP when link local works? In fact, you may prefer the printer to be only on link local so it can not be accessed from outside. The public IP is something your ISP assigns to you, so using that unnecessary only makes your setup vulnerable to problems if the internet is down. You could assign an ULA prefix https://en.wikipedia.org/wiki/Unique_local_address for your network but most people wont. Regards, Baldur From manager at monmouth.com Wed Mar 8 13:55:14 2017 From: manager at monmouth.com (Mark Stevens) Date: Wed, 8 Mar 2017 08:55:14 -0500 Subject: scalematrix network access Message-ID: <212cff2c-c7a3-8e19-0613-d0caa6366a8b@monmouth.com> Good Morning, Is anyone having access issues into sites within scalematrix.net network? Our traces make it out of Cogent and into Level3 and either die in Level3 or a couple hops past Level3 into scalematrix.net network. If someone from Scalmatrix or Level3 reads this, can you email me offline to discuss? Thanks Mark From alarig at swordarmor.fr Wed Mar 8 14:47:24 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Wed, 8 Mar 2017 15:47:24 +0100 Subject: google ipv6 routes via cogent In-Reply-To: <41981676-2734-4176-9A52-D1F941157D91@cloudflare.com> References: <001801d28f7e$d063ac10$712b0430$@gvtc.com> <20170308071801.ux6ac2tzrrrqfn7x@mew.swordarmor.fr> <41981676-2734-4176-9A52-D1F941157D91@cloudflare.com> Message-ID: <20170308144724.ls5nr7jtthojbcog@mew.swordarmor.fr> On mer. 8 mars 09:29:11 2017, Marty Strong via NANOG wrote: > I wouldn?t be surprised if that?s unwanted, where Telstra domestic is > announcing to Telstra International, who in turn announces to Cogent. I wouldn?t too, especially since I don?t see it anymore: alarig at nominoe:~ % birdc6 show route for 2a00:1450:4001:811::2003 BIRD 1.5.0 ready. 2a00:1450:4001::/48 via 2a06:e040:3501:101:2::1 on em0.21 [bgp_quantic 13:09:29] * (100) [AS15169i] via 2a00:5881:8100:ff00::142 on gre0 [bgp_arn_hwhost1 2017-01-30] (50) [AS15169i] via 2a00:5884:ff::13 on gre1 [bgp_arn_hwhost2 2017-01-30] (50) [AS15169i] And quantic now reaches them via HE. -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From tom.smyth at wirelessconnect.eu Wed Mar 8 15:17:15 2017 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Wed, 8 Mar 2017 15:17:15 +0000 Subject: Fwd: CIA Exploits on Mikrotik Hardware /Software In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Tom Smyth Date: Wed, Mar 8, 2017 at 3:02 PM Subject: CIA Exploits on Mikrotik Hardware /Software To: INEX Members Technical Mailing List Hi Lads, For MikroTik Users in the community there are apparently live exploits for MikroTik software and apparently this was used by the CIA, if the tools are released in the wild this would represent a significant threat to your ISPs for those of you who have MikroTik Routers with public IPs on them and if they are not adequately filtered, I would humbly suggest that you apply best practices and filter the management services and disable any management services that you dont absolutely need, for further details please find the following More Details on the MikroTik CIA Exploits https://forum.mikrotik.com/viewtopic.php?t=119255 you can disable un needed administration services in IP/services menu, and I would suggest filtering access to the management ports and disabling the web management interface altogether and disable ftp If you want to protect the Routers apply filters on the input chain of the Firewall Filter, tcp dstport 22 for ssh tcp dstport 8291 for winbox tcp dstport 23 for telnet tcp dstport 8729 api tcp dstport 8728 api tcp dstport 20,21 ftp be aware that the api interfaces could have been enabled if you were upgrading the software from an older version I have included a sample configuration script below just to help But make sure to adjust it to suit your own needs... /ip service set telnet disabled=yes set ftp disabled=yes set www disabled=yes set www-ssl certificate=cert1 disabled=yes set api disabled=yes set api-ssl disabled=yes /ip firewall address-list add address=5.134.88.0/29 list=Management #STOP REPLACE the address above with your management ip ranges #copy the lines to add more ips /ip firewall filter add action=accept chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=22 src-address-list=Management_ipprotocol=tcp add action=accept chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8291 src-address-list=Management_ipprotocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=22 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8291 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=23 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=21 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8729 protocol=tcp add action=drop chain=input comment="Drop input Rule to protect MikroTik Devices" dst-port=8728 protocol=tcp after running that script on your mikrotik Firewall ensure the rules that you added are moved straight to the top of the firewall rule set .... it is important to note that full details on the exploits are not available but any service that Mikrotik is running could be an entry point so bear that in mind , eg , NTP DNS ... Hotspot , CDP / MNDP / and the long list of VPN services that can be configured on MikroTik... -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. From tom.smyth at wirelessconnect.eu Wed Mar 8 15:31:19 2017 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Wed, 8 Mar 2017 15:31:19 +0000 Subject: CIA Exploits on Mikrotik Hardware /Software In-Reply-To: References: Message-ID: Hello, there were 2 typos on that maiil 1) I used lads (sorry force of habit) was meant in the sense of Gender Neutrality as opposed to excluding ladies, 2) the sample firewall rules had a space missing with the wrong address list name :/ I have corrected them below On Wed, Mar 8, 2017 at 3:17 PM, Tom Smyth wrote: > ---------- Forwarded message ---------- > From: Tom Smyth > Date: Wed, Mar 8, 2017 at 3:02 PM > Subject: CIA Exploits on Mikrotik Hardware /Software > To: INEX Members Technical Mailing List > > Hello > > For MikroTik Users in the community there are apparently live exploits > for MikroTik software and apparently this was used by the CIA, if the > tools are released in the wild this would represent a significant > threat to your ISPs for those of you who have MikroTik Routers with > public IPs on them and if they are not adequately filtered, > > I would humbly suggest that you apply best practices and filter the > management services and disable any management services that you dont > absolutely need, > > for further details please find the following > > More Details on the MikroTik CIA Exploits > https://forum.mikrotik.com/viewtopic.php?t=119255 > > you can disable un needed administration services in > IP/services menu, > > and I would suggest filtering access to the management ports and > disabling the web management interface altogether and disable ftp > > If you want to protect the Routers apply filters on the input chain of > the Firewall Filter, > > tcp dstport 22 for ssh > tcp dstport 8291 for winbox > tcp dstport 23 for telnet > tcp dstport 8729 api > tcp dstport 8728 api > tcp dstport 20,21 ftp > be aware that the api interfaces could have been enabled if you were > upgrading the software from an older version > > > I have included a sample configuration script below just to help But > make sure to adjust it to suit your own needs... > > /ip service > set telnet disabled=yes > set ftp disabled=yes > set www disabled=yes > set www-ssl certificate=cert1 disabled=yes > set api disabled=yes > set api-ssl disabled=yes > > /ip firewall address-list > add address=5.134.88.0/29 list=Management > > #STOP REPLACE the address above with your management ip ranges > #copy the lines to add more ips > > > > /ip firewall filter > add action=accept chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=22 > src-address-list=Management protocol=tcp > add action=accept chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=8291 > src-address-list=Management protocol=tcp > > add action=drop chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=22 protocol=tcp > add action=drop chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=8291 protocol=tcp > add action=drop chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=23 protocol=tcp > add action=drop chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=21 protocol=tcp > add action=drop chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=8729 protocol=tcp > add action=drop chain=input comment="Drop input Rule to protect > MikroTik Devices" dst-port=8728 protocol=tcp > > > after running that script on your mikrotik Firewall ensure the rules > that you added are moved straight to the top of the firewall rule set > .... > > > > it is important to note that full details on the exploits are not > available but any service that Mikrotik is running could be an entry > point so bear that in mind , > > eg , NTP DNS ... Hotspot , CDP / MNDP / and the long list of VPN > services that can be configured on MikroTik... > > > -- > Kindest regards, > Tom Smyth > > Mobile: +353 87 6193172 > --------------------------------- > PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL > This email contains information which may be confidential or > privileged. The information is intended solely for the use of the > individual or entity named above. If you are not the intended > recipient, be aware that > any disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic > transmission in error, please notify me by telephone or by electronic > mail immediately. Any opinions expressed are those of the author, not > the company's .This email does not constitute either offer or > acceptance of any contractually binding agreement. Such offer or > acceptance must be communicated in > writing. You are requested to carry out your own virus check before > opening any attachment. Thomas Smyth accepts no liability for any loss > or damage which may be caused by malicious software or attachments. -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. From dhubbard at dino.hostasaurus.com Wed Mar 8 17:16:28 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 8 Mar 2017 17:16:28 +0000 Subject: Verizon wireless to stop issuing static IPv4 Message-ID: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> Thought the list would find this interesting. Just received an email from VZ wireless that they?re going to stop selling static IPv4 for wireless subscribers in June. That should make for some interesting support calls on the broadband/fios side; one half of the company is forcing ipv6, the other can?t provide it. At least now we have a big name forcing the issue though. David Here?s complete text: On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses due to a shortage of available addresses. Customers that currently have active Public Static IPv4 addresses will retain those addresses, and Verizon will continue to fully support existing Public Static IPv4 addresses. In order to reserve new IP addresses, your company will need to convert to the Persistent Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices. Why should you make the move to Persistent Prefix IPv6? ? Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 128-bit addressing scheme, which aligns to current international agreements and standards. ? Persistent Prefix IPv6 will provide the device with an IP address unique to that device that will remain with that device until the address is relinquished by the user (i.e., when the user moves the device off the Verizon Wireless network). ? IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses. From rcarpen at network1.net Wed Mar 8 17:29:02 2017 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 8 Mar 2017 12:29:02 -0500 (EST) Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> Message-ID: <266215644.112467.1488994142701.JavaMail.zimbra@network1.net> It would have been nice if Verizon had starting issuing IPv6 while still issuing IPv4 for an easy transition. The current situation is that you can't get static IPv6 at all. I have been bugging them about this for many years. thanks, -Randy ----- On Mar 8, 2017, at 12:16 PM, David Hubbard dhubbard at dino.hostasaurus.com wrote: > Thought the list would find this interesting. Just received an email from VZ > wireless that they?re going to stop selling static IPv4 for wireless > subscribers in June. That should make for some interesting support calls on > the broadband/fios side; one half of the company is forcing ipv6, the other > can?t provide it. At least now we have a big name forcing the issue though. > > David > > Here?s complete text: > > On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses due > to a shortage of available addresses. Customers that currently have active > Public Static IPv4 addresses will retain those addresses, and Verizon will > continue to fully support existing Public Static IPv4 addresses. In order to > reserve new IP addresses, your company will need to convert to the Persistent > Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices. > > > > > > Why should you make the move to Persistent Prefix IPv6? > > > > > > ? > > Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has > 128-bit addressing scheme, which aligns to current international agreements and > standards. > > > > ? > > Persistent Prefix IPv6 will provide the device with an IP address unique to that > device that will remain with that device until the address is relinquished by > the user (i.e., when the user moves the device off the Verizon Wireless > network). > > > > ? > > IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses. From ed.lopez at corsa.com Wed Mar 8 17:43:47 2017 From: ed.lopez at corsa.com (Ed Lopez) Date: Wed, 08 Mar 2017 17:43:47 +0000 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <266215644.112467.1488994142701.JavaMail.zimbra@network1.net> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> <266215644.112467.1488994142701.JavaMail.zimbra@network1.net> Message-ID: I'm assuming no consideration for using RFC-6598 addresses (100.64.0.0/10) and performing CGN as a bridge, perhaps via LW4o6 On Wed, Mar 8, 2017 at 12:31 PM Randy Carpenter wrote: > > It would have been nice if Verizon had starting issuing IPv6 while still > issuing IPv4 for an easy transition. The current situation is that you > can't get static IPv6 at all. I have been bugging them about this for many > years. > > thanks, > -Randy > > > ----- On Mar 8, 2017, at 12:16 PM, David Hubbard > dhubbard at dino.hostasaurus.com wrote: > > > Thought the list would find this interesting. Just received an email > from VZ > > wireless that they?re going to stop selling static IPv4 for wireless > > subscribers in June. That should make for some interesting support > calls on > > the broadband/fios side; one half of the company is forcing ipv6, the > other > > can?t provide it. At least now we have a big name forcing the issue > though. > > > > David > > > > Here?s complete text: > > > > On June 30, 2017, Verizon will stop issuing new Public Static IPv4 > addresses due > > to a shortage of available addresses. Customers that currently have > active > > Public Static IPv4 addresses will retain those addresses, and Verizon > will > > continue to fully support existing Public Static IPv4 addresses. In > order to > > reserve new IP addresses, your company will need to convert to the > Persistent > > Prefix IPv6 requirements and implement new Verizon-certified IPv6 > devices. > > > > > > > > > > > > Why should you make the move to Persistent Prefix IPv6? > > > > > > > > > > > > ? > > > > Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 > has > > 128-bit addressing scheme, which aligns to current international > agreements and > > standards. > > > > > > > > ? > > > > Persistent Prefix IPv6 will provide the device with an IP address unique > to that > > device that will remain with that device until the address is > relinquished by > > the user (i.e., when the user moves the device off the Verizon Wireless > > network). > > > > > > > > ? > > > > IPv4-only devices are not compatible with Persistent Prefix IPv6 > addresses. > -- Ed Lopez | Security Architect | Corsa Technology Email: ed.lopez at corsa.com Mobile: +1.703.220.0988 www.corsa.com sent from my iPad ... I apologize for any auto-correct errors From tom.smyth at wirelessconnect.eu Wed Mar 8 20:47:33 2017 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Wed, 8 Mar 2017 20:47:33 +0000 Subject: CIA Exploits on Mikrotik Hardware /Software In-Reply-To: References: Message-ID: I got a question from a colleague that highlights an omission / lack of clarification on my initial mail and i wanted to share... As far as im aware and from tests i carried out about 7 or 8 years ago The allowed from ip addresses in ip services menu uses tcp wrapers and actually allows tcp connections from any address (regardless of what ips you specified) the decision to allow or deny a user login is taken after the connection is made so there could be a window for the exploit to be uploaded. That is why i recommended using the ip firewall instead to enforce the policy as the ip firewall will act on connection attempts and prevent an unauthorised src address from making a connection to the box in the first place I hope this helps Tom Smyth On 8 Mar 2017 3:31 PM, "Tom Smyth" wrote: > Hello, > there were 2 typos on that maiil > > 1) I used lads (sorry force of habit) was meant in the sense of > Gender Neutrality as opposed to excluding ladies, > > 2) the sample firewall rules had a space missing with the wrong > address list name :/ > > I have corrected them below > > On Wed, Mar 8, 2017 at 3:17 PM, Tom Smyth > wrote: > > ---------- Forwarded message ---------- > > From: Tom Smyth > > Date: Wed, Mar 8, 2017 at 3:02 PM > > Subject: CIA Exploits on Mikrotik Hardware /Software > > To: INEX Members Technical Mailing List > > > > > Hello > > > > For MikroTik Users in the community there are apparently live exploits > > for MikroTik software and apparently this was used by the CIA, if the > > tools are released in the wild this would represent a significant > > threat to your ISPs for those of you who have MikroTik Routers with > > public IPs on them and if they are not adequately filtered, > > > > I would humbly suggest that you apply best practices and filter the > > management services and disable any management services that you dont > > absolutely need, > > > > for further details please find the following > > > > More Details on the MikroTik CIA Exploits > > https://forum.mikrotik.com/viewtopic.php?t=119255 > > > > you can disable un needed administration services in > > IP/services menu, > > > > and I would suggest filtering access to the management ports and > > disabling the web management interface altogether and disable ftp > > > > If you want to protect the Routers apply filters on the input chain of > > the Firewall Filter, > > > > tcp dstport 22 for ssh > > tcp dstport 8291 for winbox > > tcp dstport 23 for telnet > > tcp dstport 8729 api > > tcp dstport 8728 api > > tcp dstport 20,21 ftp > > be aware that the api interfaces could have been enabled if you were > > upgrading the software from an older version > > > > > > I have included a sample configuration script below just to help But > > make sure to adjust it to suit your own needs... > > > > /ip service > > set telnet disabled=yes > > set ftp disabled=yes > > set www disabled=yes > > set www-ssl certificate=cert1 disabled=yes > > set api disabled=yes > > set api-ssl disabled=yes > > > > /ip firewall address-list > > add address=5.134.88.0/29 list=Management > > > > #STOP REPLACE the address above with your management ip ranges > > #copy the lines to add more ips > > > > > > > > /ip firewall filter > > add action=accept chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=22 > > src-address-list=Management protocol=tcp > > add action=accept chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=8291 > > src-address-list=Management protocol=tcp > > > > add action=drop chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=22 protocol=tcp > > add action=drop chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=8291 protocol=tcp > > add action=drop chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=23 protocol=tcp > > add action=drop chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=21 protocol=tcp > > add action=drop chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=8729 protocol=tcp > > add action=drop chain=input comment="Drop input Rule to protect > > MikroTik Devices" dst-port=8728 protocol=tcp > > > > > > after running that script on your mikrotik Firewall ensure the rules > > that you added are moved straight to the top of the firewall rule set > > .... > > > > > > > > it is important to note that full details on the exploits are not > > available but any service that Mikrotik is running could be an entry > > point so bear that in mind , > > > > eg , NTP DNS ... Hotspot , CDP / MNDP / and the long list of VPN > > services that can be configured on MikroTik... > > > > > > -- > > Kindest regards, > > Tom Smyth > > > > Mobile: +353 87 6193172 > > --------------------------------- > > PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL > > This email contains information which may be confidential or > > privileged. The information is intended solely for the use of the > > individual or entity named above. If you are not the intended > > recipient, be aware that > > any disclosure, copying, distribution or use of the contents of this > > information is prohibited. If you have received this electronic > > transmission in error, please notify me by telephone or by electronic > > mail immediately. Any opinions expressed are those of the author, not > > the company's .This email does not constitute either offer or > > acceptance of any contractually binding agreement. Such offer or > > acceptance must be communicated in > > writing. You are requested to carry out your own virus check before > > opening any attachment. Thomas Smyth accepts no liability for any loss > > or damage which may be caused by malicious software or attachments. > > > > -- > Kindest regards, > Tom Smyth > > Mobile: +353 87 6193172 > --------------------------------- > PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL > This email contains information which may be confidential or > privileged. The information is intended solely for the use of the > individual or entity named above. If you are not the intended > recipient, be aware that > any disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic > transmission in error, please notify me by telephone or by electronic > mail immediately. Any opinions expressed are those of the author, not > the company's .This email does not constitute either offer or > acceptance of any contractually binding agreement. Such offer or > acceptance must be communicated in > writing. You are requested to carry out your own virus check before > opening any attachment. Thomas Smyth accepts no liability for any loss > or damage which may be caused by malicious software or attachments. > From keiths at neilltech.com Thu Mar 9 00:42:43 2017 From: keiths at neilltech.com (Keith Stokes) Date: Thu, 9 Mar 2017 00:42:43 +0000 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> Message-ID: You said the e-mail was from VZ wireless but the e-mail text says Verizon. Is it really all of Verizon, VZ Wireless, home, business or some combination? On Mar 8, 2017, at 11:16 AM, David Hubbard > wrote: Thought the list would find this interesting. Just received an email from VZ wireless that they?re going to stop selling static IPv4 for wireless subscribers in June. That should make for some interesting support calls on the broadband/fios side; one half of the company is forcing ipv6, the other can?t provide it. At least now we have a big name forcing the issue though. David Here?s complete text: On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses due to a shortage of available addresses. Customers that currently have active Public Static IPv4 addresses will retain those addresses, and Verizon will continue to fully support existing Public Static IPv4 addresses. In order to reserve new IP addresses, your company will need to convert to the Persistent Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices. Why should you make the move to Persistent Prefix IPv6? ? Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 128-bit addressing scheme, which aligns to current international agreements and standards. ? Persistent Prefix IPv6 will provide the device with an IP address unique to that device that will remain with that device until the address is relinquished by the user (i.e., when the user moves the device off the Verizon Wireless network). ? IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses. --- Keith Stokes From lguillory at reservetele.com Thu Mar 9 01:13:31 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 9 Mar 2017 01:13:31 +0000 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com>, Message-ID: <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> My customer got the email and the only service they have is wireless. Also notice the email address. From: Verizon Wireless > Sent from my iPad On Mar 8, 2017, at 6:44 PM, Keith Stokes > wrote: You said the e-mail was from VZ wireless but the e-mail text says Verizon. Is it really all of Verizon, VZ Wireless, home, business or some combination? On Mar 8, 2017, at 11:16 AM, David Hubbard > wrote: Thought the list would find this interesting. Just received an email from VZ wireless that they?re going to stop selling static IPv4 for wireless subscribers in June. That should make for some interesting support calls on the broadband/fios side; one half of the company is forcing ipv6, the other can?t provide it. At least now we have a big name forcing the issue though. David Here?s complete text: On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses due to a shortage of available addresses. Customers that currently have active Public Static IPv4 addresses will retain those addresses, and Verizon will continue to fully support existing Public Static IPv4 addresses. In order to reserve new IP addresses, your company will need to convert to the Persistent Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices. Why should you make the move to Persistent Prefix IPv6? ? Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 128-bit addressing scheme, which aligns to current international agreements and standards. ? Persistent Prefix IPv6 will provide the device with an IP address unique to that device that will remain with that device until the address is relinquished by the user (i.e., when the user moves the device off the Verizon Wireless network). ? IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses. --- Keith Stokes Luke Guillory Network Operations Manager [cid:imagefe9475.JPG at ae2f04c2.45884860] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From mfidelman at meetinghouse.net Thu Mar 9 02:27:39 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 8 Mar 2017 19:27:39 -0700 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> Message-ID: <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> Seems to me that the only people who get static, wireless, IP addresses are people who put sensors on vehicles and IoT applications. Who gets a static IP for a phone? This might cause some serious heartburn for my previous employer - who built CAD systems for transit buses. Miles Fidelman On 3/8/17 6:13 PM, Luke Guillory wrote: > My customer got the email and the only service they have is wireless. Also notice the email address. > > From: Verizon Wireless > > > > > > Sent from my iPad > > On Mar 8, 2017, at 6:44 PM, Keith Stokes > wrote: > > You said the e-mail was from VZ wireless but the e-mail text says Verizon. Is it really all of Verizon, VZ Wireless, home, business or some combination? > > On Mar 8, 2017, at 11:16 AM, David Hubbard > wrote: > > Thought the list would find this interesting. Just received an email from VZ wireless that they?re going to stop selling static IPv4 for wireless subscribers in June. That should make for some interesting support calls on the broadband/fios side; one half of the company is forcing ipv6, the other can?t provide it. At least now we have a big name forcing the issue though. > > David > > Here?s complete text: > > On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses due to a shortage of available addresses. Customers that currently have active Public Static IPv4 addresses will retain those addresses, and Verizon will continue to fully support existing Public Static IPv4 addresses. In order to reserve new IP addresses, your company will need to convert to the Persistent Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices. > > > > > > Why should you make the move to Persistent Prefix IPv6? > > > > > > ? > > Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 128-bit addressing scheme, which aligns to current international agreements and standards. > > > > ? > > Persistent Prefix IPv6 will provide the device with an IP address unique to that device that will remain with that device until the address is relinquished by the user (i.e., when the user moves the device off the Verizon Wireless network). > > > > ? > > IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses. > > > > > > > > > > --- > > Keith Stokes > > > > > > > > Luke Guillory > Network Operations Manager > > > [cid:imagefe9475.JPG at ae2f04c2.45884860] > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > > > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From morrowc.lists at gmail.com Thu Mar 9 03:08:59 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Mar 2017 22:08:59 -0500 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> Message-ID: On Wed, Mar 8, 2017 at 9:27 PM, Miles Fidelman wrote: > Seems to me that the only people who get static, wireless, IP addresses > are people who put sensors on vehicles and IoT applications. Who gets a > static IP for a phone? This might cause some serious heartburn for my > previous employer - who built CAD systems for transit buses. > > on the bright side they can just get fios or dsl (depending on location) .. you know you can still get v4 there, and won't even have to worry about that pesky new fangled ipv6 . From cb.list6 at gmail.com Thu Mar 9 03:39:04 2017 From: cb.list6 at gmail.com (Ca By) Date: Thu, 09 Mar 2017 03:39:04 +0000 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> Message-ID: On Wed, Mar 8, 2017 at 7:10 PM Christopher Morrow wrote: > On Wed, Mar 8, 2017 at 9:27 PM, Miles Fidelman > > wrote: > > > Seems to me that the only people who get static, wireless, IP addresses > > are people who put sensors on vehicles and IoT applications. Who gets a > > static IP for a phone? This might cause some serious heartburn for my > > previous employer - who built CAD systems for transit buses. > > > > > on the bright side they can just get fios or dsl (depending on location) .. > you know you can still get v4 there, and won't even have to worry about > that pesky new fangled The economics of this is very interesting. Normally, with scarcity, i would expect price to go up. VZW is running low on ipv4 addresses, so they raise prices to stem demand. They acquire ipv4 on the secondary market and pass cost along with mark up to customers .... But -- vzw knows if they raise prices customers will just go elsewhere. Also, their growth model simply may show that there is no way to meet demand with ipv4, ipv4 is fundamentally holding back iot growth, so they need to pivot / move to ipv6 to unchain the growth. Seems smart. The runway for ipv4 is too short for iot growth. Forcing the hand to scalable ipv6 now will pay dividends and prevent investment in unscalable ipv4 solutions From valdis.kletnieks at vt.edu Thu Mar 9 03:58:15 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 08 Mar 2017 22:58:15 -0500 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> Message-ID: <139937.1489031895@turing-police.cc.vt.edu> On Wed, 08 Mar 2017 22:08:59 -0500, Christopher Morrow said: > > previous employer - who built CAD systems for transit buses. > on the bright side they can just get fios or dsl (depending on location) .. > you know you can still get v4 there, and won't even have to worry about > that pesky new fangled ipv6 . FIOS for a transit bus? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Mar 9 04:09:39 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Mar 2017 23:09:39 -0500 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <139937.1489031895@turing-police.cc.vt.edu> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> <139937.1489031895@turing-police.cc.vt.edu> Message-ID: On Wed, Mar 8, 2017 at 10:58 PM, wrote: > On Wed, 08 Mar 2017 22:08:59 -0500, Christopher Morrow said: > > > previous employer - who built CAD systems for transit buses. > > on the bright side they can just get fios or dsl (depending on location) > .. > > you know you can still get v4 there, and won't even have to worry about > > that pesky new fangled ipv6 . > > FIOS for a transit bus? > > it seems as likely to be true as ipv6 on fios, yes. From mureninc at gmail.com Thu Mar 9 05:31:15 2017 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 8 Mar 2017 23:31:15 -0600 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> <2801BE85-BAB7-43CA-9E40-7FD8FE6CC0F0@reservetele.com> <020b42e1-9a7e-5cfc-0b9a-e441a1990c77@meetinghouse.net> Message-ID: On 08/03/2017, Miles Fidelman wrote: > Seems to me that the only people who get static, wireless, IP addresses > are people who put sensors on vehicles and IoT applications. Who gets a > static IP for a phone? This might cause some serious heartburn for my > previous employer - who built CAD systems for transit buses. > > Miles Fidelman With how much memory and processing power any modern internet-connected device has, plus the ever ubiquitous cloud, I don't understand why IoT, especially non-consumer-grade IoT, should have any need for public IPv4 addresses. Even if you have a very legacy app, and IPsec is too complex for your needs, doing an SSH session with OpenSSH and its port forwarding feature is just too simple to pass up. http://mdoc.su/o/ssh.1 I mean, come on, if malware vendors have no need for public IP addresses to take control of your IoT and perform C&C, you're clearly doing something wrong if your own shit doesn't work without it. Cheers, http://Constantine.SU/ From jwbensley at gmail.com Thu Mar 9 08:24:34 2017 From: jwbensley at gmail.com (James Bensley) Date: Thu, 9 Mar 2017 08:24:34 +0000 Subject: RNP Santa Catarina Point of Presence (PoP-SC) Message-ID: Hi All, Anyone from RNP on-list that can reach out to me off-list, minor technical problem in your network. Thanks, James. From jwbensley at gmail.com Thu Mar 9 12:27:46 2017 From: jwbensley at gmail.com (James Bensley) Date: Thu, 9 Mar 2017 12:27:46 +0000 Subject: RNP Santa Catarina Point of Presence (PoP-SC) In-Reply-To: References: Message-ID: On 9 March 2017 at 08:24, James Bensley wrote: > Hi All, > > Anyone from RNP on-list that can reach out to me off-list, minor > technical problem in your network. > > Thanks, > James. Thanks all, contact has been made off-list! Cheers, James. From Steve.Mikulasik at civeo.com Thu Mar 9 17:27:36 2017 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 9 Mar 2017 17:27:36 +0000 Subject: Verizon wireless to stop issuing static IPv4 In-Reply-To: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> References: <5E5BD27A-260B-4E52-8C99-305156E6FD61@dino.hostasaurus.com> Message-ID: Verizon Wireless has been pushing their clients away from static IPv4 for some time. I inquired last year about getting one for a specific project and was told it would be a large upfront cost, limited to certain accounts and required justification. I imagine in the years coming this will become the norm for carriers. From ggm at algebras.org Thu Mar 9 22:35:22 2017 From: ggm at algebras.org (George Michaelson) Date: Fri, 10 Mar 2017 08:35:22 +1000 Subject: IPv6 doc. prefix (2001:db8::/32) - APNIC object ? In-Reply-To: <20170307041031.A353E6611009@rock.dv.isc.org> References: <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E@burn.net> <20170307041031.A353E6611009@rock.dv.isc.org> Message-ID: Don't bother: It was removed 24+ h ago after we got alerted George On Tue, Mar 7, 2017 at 2:10 PM, Mark Andrews wrote: > > In message <6BCDA810-52CD-4EFE-9A69-4B1AABC9003E at burn.net>, Brandon Applegate writes: >> Just did a whois on the documentation prefix and was surprised to see >> what looks like a user object registered for it: >> >> % Information related to '2001:0DB8::/32AS132111' >> >> route6: 2001:0DB8::/32 >> descr: FUTURE D SDN BHD >> origin: AS132111 >> country: MY >> mnt-by: MAINT-FUTUREDSDNBHD-MY >> changed: hm-changed at apnic.net 20160523 >> source: APNIC >> >> Any idea what this is ? I would have thought there might be some sanity >> check that would have stopped this from getting registered ? > > Open a ticket with APNIC to get it fixed. > >> -- >> Brandon Applegate - CCIE 10273 >> PGP Key fingerprint: >> 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 >> "SH1-0151. This is the serial number, of our orbital gun." > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From leandrobachero at gmail.com Thu Mar 9 11:10:20 2017 From: leandrobachero at gmail.com (Leandro de Lima Camargo) Date: Thu, 9 Mar 2017 08:10:20 -0300 Subject: RNP Santa Catarina Point of Presence (PoP-SC) In-Reply-To: References: Message-ID: <7826AE22-4039-42C7-8619-6662E53C0AC0@gmail.com> Have you tried contacting from this website? https://www.pop-sc.rnp.br/home/equipe/ Regards, Leandro de Lima Camargo > On Mar 92017, at 5:24 AM, James Bensley wrote: > > Hi All, > > Anyone from RNP on-list that can reach out to me off-list, minor > technical problem in your network. > > Thanks, > James. From cb.list6 at gmail.com Fri Mar 10 16:17:45 2017 From: cb.list6 at gmail.com (Ca By) Date: Fri, 10 Mar 2017 08:17:45 -0800 Subject: critical mass update on IPv6 Message-ID: Just update for those that care. As you may know, all the major cellular providers in the USA (VZ, AT&T, T-Mobile, Sprint) support IPv6 by default on many models of phones. Comcast and AT&T and other large broadband players also have IPv6 widely deployed by default http://www.worldipv6launch.org/measurements/ Most of the major (elephants) content is IPv6 (Google, FB, Netflix, ...) And now the other end in the cloud is coming along nicely https://aws.amazon.com/blogs/aws/aws-ipv6-update-global-support-spanning-15-regions-multiple-aws-services/ https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ipv6-overview https://cloud.google.com/compute/docs/load-balancing/ipv6 Not to mention that Digital Ocean , Softlayer / IBM, Linode, and others also support IPv6 And now you are seeing ipv4 lose support in various classes of products like set-top boxes ( http://corporate.comcast.com/comcast-voices/world-ipv6-launch-four-years-later-taking-stock-and-looking-forward ) and static IPs ( https://www.theregister.co.uk/2017/03/10/verizon_running_out_of_ipv4_addresses/ ) From pete at tccmail.ca Fri Mar 10 17:00:47 2017 From: pete at tccmail.ca (Pete Baldwin) Date: Fri, 10 Mar 2017 12:00:47 -0500 Subject: Purchased IPv4 Woes Message-ID: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> Hi All, Hopefully this is not taken in bad taste. Our organization purchased some IP space last year (163.182.192.0/18 to be specific), and it appears that this block must have been used for less-than-admirable purposes in the past. We have been trying to clean up the reputation where possible, and we do not appear to be on any blacklists, but we do appear to be blocked from a lot of networks across the US/Canada. I am noticing a lot of name servers blocking our requests, many web servers, gaming servers, mail etc. This is a transition block for us to move towards v6 everywhere, but we have many systems that will need to rely on this block of space for some time to come. We are a small rural co-op ISP in Ontario, and I am just writing this email as an extra plea so that if you happen to run a network that has this entire range on your naughty list, we would appreciate you giving it another chance. I can be contacted on or off list, thanks. -- ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 From Jason_Livingood at comcast.com Fri Mar 10 17:13:20 2017 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 10 Mar 2017 17:13:20 +0000 Subject: Bitly Contact? Message-ID: <05DB35EF-AEBA-4A62-81C2-C1ADDB498CAD@cable.comcast.com> Anyone on the NANOG list here from Bitly? I?m trying to find a contact. Thanks Jason From cgrundemann at gmail.com Fri Mar 10 17:25:34 2017 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 10 Mar 2017 12:25:34 -0500 Subject: Multi-CDN Strategies Message-ID: Hail NANOG; Is anyone here leveraging multiple CDN providers for resiliency and have best practices or other advice they'd be willing to share? Thanks, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From Jason_Livingood at comcast.com Fri Mar 10 17:36:01 2017 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Fri, 10 Mar 2017 17:36:01 +0000 Subject: Bitly Contact? In-Reply-To: <05DB35EF-AEBA-4A62-81C2-C1ADDB498CAD@cable.comcast.com> References: <05DB35EF-AEBA-4A62-81C2-C1ADDB498CAD@cable.comcast.com> Message-ID: <92361511-6E17-4738-9B17-C43C48AF6EAB@cable.comcast.com> Contact person found! Thanks NANOG! ? On 3/10/17, 12:13 PM, "NANOG on behalf of Livingood, Jason" wrote: Anyone on the NANOG list here from Bitly? I?m trying to find a contact. Thanks Jason From cscora at apnic.net Fri Mar 10 18:02:33 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Mar 2017 04:02:33 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170310180233.73C40C44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 11 Mar, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 639763 Prefixes after maximum aggregation (per Origin AS): 249160 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 308424 Total ASes present in the Internet Routing Table: 56466 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 48885 Origin ASes announcing only one prefix: 21729 Transit ASes present in the Internet Routing Table: 7581 Transit-only ASes present in the Internet Routing Table: 211 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 69 Numnber of instances of unregistered ASNs: 70 Number of 32-bit ASNs allocated by the RIRs: 17648 Number of 32-bit ASNs visible in the Routing Table: 13695 Prefixes from 32-bit ASNs in the Routing Table: 55367 Number of bogon 32-bit ASNs visible in the Routing Table: 45 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 408 Number of addresses announced to Internet: 2837876068 Equivalent to 169 /8s, 38 /16s and 141 /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: 98.5 Total number of prefixes smaller than registry allocations: 213848 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 174984 Total APNIC prefixes after maximum aggregation: 50104 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 174317 Unique aggregates announced from the APNIC address blocks: 71873 APNIC Region origin ASes present in the Internet Routing Table: 7908 APNIC Prefixes per ASN: 22.04 APNIC Region origin ASes announcing only one prefix: 2220 APNIC Region transit ASes present in the Internet Routing Table: 1131 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2748 Number of APNIC addresses announced to Internet: 760936068 Equivalent to 45 /8s, 90 /16s and 246 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 194699 Total ARIN prefixes after maximum aggregation: 93351 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 197144 Unique aggregates announced from the ARIN address blocks: 90309 ARIN Region origin ASes present in the Internet Routing Table: 17824 ARIN Prefixes per ASN: 11.06 ARIN Region origin ASes announcing only one prefix: 6638 ARIN Region transit ASes present in the Internet Routing Table: 1772 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1825 Number of ARIN addresses announced to Internet: 1107678144 Equivalent to 66 /8s, 5 /16s and 211 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 171000 Total RIPE prefixes after maximum aggregation: 84309 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 166169 Unique aggregates announced from the RIPE address blocks: 100699 RIPE Region origin ASes present in the Internet Routing Table: 23774 RIPE Prefixes per ASN: 6.99 RIPE Region origin ASes announcing only one prefix: 10981 RIPE Region transit ASes present in the Internet Routing Table: 3357 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5614 Number of RIPE addresses announced to Internet: 710346112 Equivalent to 42 /8s, 87 /16s and 5 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 82674 Total LACNIC prefixes after maximum aggregation: 17651 LACNIC Deaggregation factor: 4.68 Prefixes being announced from the LACNIC address blocks: 83870 Unique aggregates announced from the LACNIC address blocks: 38378 LACNIC Region origin ASes present in the Internet Routing Table: 5693 LACNIC Prefixes per ASN: 14.73 LACNIC Region origin ASes announcing only one prefix: 1562 LACNIC Region transit ASes present in the Internet Routing Table: 1036 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3211 Number of LACNIC addresses announced to Internet: 171430816 Equivalent to 10 /8s, 55 /16s and 211 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16303 Total AfriNIC prefixes after maximum aggregation: 3686 AfriNIC Deaggregation factor: 4.42 Prefixes being announced from the AfriNIC address blocks: 17855 Unique aggregates announced from the AfriNIC address blocks: 6810 AfriNIC Region origin ASes present in the Internet Routing Table: 1029 AfriNIC Prefixes per ASN: 17.35 AfriNIC Region origin ASes announcing only one prefix: 328 AfriNIC Region transit ASes present in the Internet Routing Table: 200 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 297 Number of AfriNIC addresses announced to Internet: 87023872 Equivalent to 5 /8s, 47 /16s and 225 /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 5564 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3737 391 257 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2989 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2750 11134 751 KIXS-AS-KR Korea Telecom, KR 9829 2729 1501 541 BSNL-NIB National Internet Backbone, IN 9808 2295 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2067 421 219 TATACOMM-AS TATA Communications formerl 45899 1882 1307 103 VNPT-AS-VN VNPT Corp, VN 4808 1646 1786 448 CHINA169-BJ China Unicom Beijing Provin 24560 1562 580 257 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3663 2969 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3325 1333 83 SHAW - Shaw Communications Inc., CA 18566 2186 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1974 2066 388 CHARTER-NET-HKY-NC - Charter Communicat 209 1781 5065 641 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1727 3323 562 AMAZON-02 - Amazon.com, Inc., US 30036 1712 319 416 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1682 852 227 ITCDELTA - Earthlink, Inc., US 701 1579 10583 651 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3081 1143 2188 AKAMAI-ASN1 , US 9121 2636 1691 18 TTNET , TR 34984 2000 328 384 TELLCOM-AS , TR 13188 1652 99 58 TRIOLAN , UA 8551 1635 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 1509 1033 50 UNI2-AS , ES 9198 1316 352 23 KAZTELECOM-AS , KZ 12389 1299 1235 518 ROSTELECOM-AS , RU 6849 1266 355 21 UKRTELNET , UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3542 545 156 Telmex Colombia S.A., CO 26615 3123 2330 44 Tim Celular S.A., BR 8151 2498 3378 545 Uninet S.A. de C.V., MX 11830 1800 368 66 Instituto Costarricense de Electricidad 6503 1572 437 53 Axtel, S.A.B. de C.V., MX 7303 1555 1002 248 Telecom Argentina S.A., AR 6147 1169 377 27 Telefonica del Peru S.A.A., PE 28573 1083 2289 185 CLARO S.A., BR 3816 1005 479 185 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 977 280 35 Techtel LMDS Comunicaciones Interactiva 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 1308 399 45 LINKdotNET-AS, EG 36903 718 361 122 MT-MPLS, MA 37611 696 67 6 Afrihost, ZA 36992 598 1375 26 ETISALAT-MISR, EG 24835 491 722 14 RAYA-AS, EG 8452 384 1474 16 TE-AS TE-AS, EG 29571 368 36 10 CITelecom-AS, CI 37492 339 300 77 ORANGE-TN, TN 15399 336 35 7 WANANCHI-KE, KE 2018 272 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5564 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3737 391 257 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3663 2969 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3542 545 156 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3325 1333 83 SHAW - Shaw Communications Inc., CA 26615 3123 2330 44 Tim Celular S.A., BR 20940 3081 1143 2188 AKAMAI-ASN1 , US 17974 2989 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2750 11134 751 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3663 3514 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3737 3480 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3542 3386 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3325 3242 SHAW - Shaw Communications Inc., CA 26615 3123 3079 Tim Celular S.A., BR 17974 2989 2917 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2636 2618 TTNET , TR 9808 2295 2262 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2729 2188 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS , IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM , RU 41.77.248.0/21 203496 AB-TELECOM , RU 41.78.12.0/23 203496 AB-TELECOM , RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM , RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.142.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.143.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:279 /13:538 /14:1047 /15:1793 /16:13205 /17:7758 /18:13304 /19:24677 /20:38268 /21:41012 /22:75019 /23:63356 /24:357987 /25:548 /26:411 /27:287 /28:35 /29:19 /30:25 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3121 3325 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2840 3663 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 26615 2639 3123 Tim Celular S.A., BR 18566 2079 2186 MEGAPATH5-US - MegaPath Corporation, US 9121 1852 2636 TTNET , TR 30036 1523 1712 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1458 3542 Telmex Colombia S.A., CO 13188 1377 1652 TRIOLAN , UA 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1617 2:842 4:25 5:2477 6:34 8:1048 12:1817 13:92 14:1787 15:22 16:2 17:113 18:128 19:1 20:54 23:2132 24:1862 25:2 27:2376 31:1885 32:89 33:5 34:1 35:19 36:382 37:2564 38:1348 39:45 40:99 41:2844 42:464 43:1901 44:62 45:2409 46:2649 47:114 49:1214 50:966 51:18 52:751 54:356 55:7 56:4 57:41 58:1620 59:995 60:388 61:1928 62:1492 63:1921 64:4577 65:2191 66:4540 67:2265 68:1192 69:3334 70:1305 71:577 72:2146 74:2624 75:401 76:415 77:1428 78:1661 79:1312 80:1345 81:1400 82:963 83:728 84:860 85:1743 86:482 87:1139 88:800 89:2061 90:205 91:6146 92:992 93:2370 94:2376 95:2812 96:566 97:359 98:939 99:84 100:153 101:1244 103:13921 104:2792 105:165 106:483 107:1549 108:809 109:2599 110:1296 111:1721 112:1161 113:1308 114:1042 115:1720 116:1762 117:1671 118:2070 119:1605 120:951 121:1092 122:2334 123:2104 124:1537 125:1816 128:711 129:508 130:415 131:1387 132:522 133:190 134:531 135:216 136:514 137:423 138:1824 139:508 140:373 141:506 142:734 143:905 144:773 145:168 146:1037 147:662 148:1380 149:559 150:701 151:944 152:729 153:307 154:759 155:977 156:554 157:612 158:452 159:1424 160:563 161:743 162:2449 163:527 164:788 165:1157 166:387 167:1236 168:2583 169:756 170:2933 171:282 172:964 173:1838 174:805 175:727 176:1764 177:4242 178:2491 179:1612 180:2192 181:2036 182:2230 183:1045 184:840 185:8998 186:3191 187:2668 188:2437 189:1810 190:8093 191:1897 192:9285 193:5766 194:4646 195:3842 196:1940 197:1272 198:5564 199:5842 200:7393 201:4097 202:10227 203:9816 204:4465 205:2766 206:3002 207:3140 208:3979 209:3962 210:3947 211:2116 212:2814 213:2490 214:870 215:65 216:5897 217:2022 218:833 219:621 220:1693 221:893 222:724 223:1154 End of report From rekoil at semihuman.com Fri Mar 10 22:19:44 2017 From: rekoil at semihuman.com (Chris Woodfield) Date: Fri, 10 Mar 2017 14:19:44 -0800 Subject: Multi-CDN Strategies In-Reply-To: References: Message-ID: <112EB79C-9BF4-4D95-B303-21081472926B@semihuman.com> I have some experience with this; a few things off the top of my head: - It?s usually best to leverage some sort of ?smart? DNS to handle CNAME distribution, giving you the ability to weight your CNAME distribution vs. only using one CDN all the time, or prefer different CDNs in various global regions. I?ve had decent experience with Dyn here, but Route53 has all the features you?d want as well. If possible, write tooling towards your DNS provider?s API to automate your failovers. - Weight your distribution such that you never have one CDN turned off completely; you?ll want a small trickle of user traffic hitting every CDN so that the caches won?t be cold when you switch over to it. - Make sure you have a distributed metrics service (ThousandEyes, WebMetrics, et al) testing your CDNs individually as well as the external hostname. - Stay away from HTML- or Header-munging features when possible; stick with feature sets that are common (and implementable in similar ways) across your providers. (Similar advice goes for multi-vendor *anything*, TBH) I could keep going, but if so, I might as well stick them into a powerpoint and submit a talk for Bellevue :) -C > On Mar 10, 2017, at 9:25 AM, Chris Grundemann wrote: > > Hail NANOG; > > Is anyone here leveraging multiple CDN providers for resiliency and have > best practices or other advice they'd be willing to share? > > Thanks, > ~Chris > > -- > @ChrisGrundemann > http://chrisgrundemann.com From rod.beck at unitedcablecompany.com Fri Mar 10 22:22:35 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 10 Mar 2017 22:22:35 +0000 Subject: AIMS Data Center - Cyberjaya - Malaysia In-Reply-To: <02cb01d2969f$b5f0f680$21d2e380$@unwiredltd.com> References: <017601d2969e$769cea80$63d6bf80$@unwiredltd.com>, <02cb01d2969f$b5f0f680$21d2e380$@unwiredltd.com> Message-ID: Gentlemen and Ladies, Looking for a customer list with a focus on carriers and ISPs. Thanks! - Roderick. From ryan.landry at gmail.com Sat Mar 11 02:38:04 2017 From: ryan.landry at gmail.com (Ryan Landry) Date: Sat, 11 Mar 2017 02:38:04 +0000 Subject: Multi-CDN Strategies In-Reply-To: References: Message-ID: Some folks just let Cedexis do the work. https://www.cedexis.com/solutions/multi-cdn/ On Fri, Mar 10, 2017 at 09:27 Chris Grundemann wrote: > Hail NANOG; > > Is anyone here leveraging multiple CDN providers for resiliency and have > best practices or other advice they'd be willing to share? > > Thanks, > ~Chris > > -- > @ChrisGrundemann > http://chrisgrundemann.com > From admin at coldnorthadmin.com Sat Mar 11 06:01:39 2017 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Sat, 11 Mar 2017 01:01:39 -0500 Subject: Purchased IPv4 Woes In-Reply-To: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> Message-ID: <288e55d6-a1f8-b94b-c64b-feb354db5db5@coldnorthadmin.com> Out of curiosity, who were the previous owner(s), it seems that ARIN only shows the current owner with any history? If it was a Chinese/Russian block, you might be out of luck. On 03/10/2017 12:00 PM, Pete Baldwin wrote: > Hi All, > > Hopefully this is not taken in bad taste. Our organization > purchased some IP space last year (163.182.192.0/18 to be specific), > and it appears that this block must have been used for > less-than-admirable purposes in the past. > > We have been trying to clean up the reputation where possible, and we > do not appear to be on any blacklists, but we do appear to be blocked > from a lot of networks across the US/Canada. I am noticing a lot of > name servers blocking our requests, many web servers, gaming servers, > mail etc. > > This is a transition block for us to move towards v6 everywhere, but > we have many systems that will need to rely on this block of space for > some time to come. > > We are a small rural co-op ISP in Ontario, and I am just writing this > email as an extra plea so that if you happen to run a network that has > this entire range on your naughty list, we would appreciate you giving > it another chance. I can be contacted on or off list, thanks. > > From eyeronic.design at gmail.com Sat Mar 11 06:53:13 2017 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 10 Mar 2017 22:53:13 -0800 Subject: Purchased IPv4 Woes In-Reply-To: <288e55d6-a1f8-b94b-c64b-feb354db5db5@coldnorthadmin.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <288e55d6-a1f8-b94b-c64b-feb354db5db5@coldnorthadmin.com> Message-ID: It looks like Spamhaus has your entire /16. https://stat.ripe.net/163.182.192.0%2F18#tabId=anti-abuse On Fri, Mar 10, 2017 at 10:01 PM, Laurent Dumont wrote: > Out of curiosity, who were the previous owner(s), it seems that ARIN only > shows the current owner with any history? If it was a Chinese/Russian block, > you might be out of luck. > > > > On 03/10/2017 12:00 PM, Pete Baldwin wrote: >> >> Hi All, >> >> Hopefully this is not taken in bad taste. Our organization purchased >> some IP space last year (163.182.192.0/18 to be specific), and it appears >> that this block must have been used for less-than-admirable purposes in the >> past. >> >> We have been trying to clean up the reputation where possible, and we do >> not appear to be on any blacklists, but we do appear to be blocked from a >> lot of networks across the US/Canada. I am noticing a lot of name servers >> blocking our requests, many web servers, gaming servers, mail etc. >> >> This is a transition block for us to move towards v6 everywhere, but we >> have many systems that will need to rely on this block of space for some >> time to come. >> >> We are a small rural co-op ISP in Ontario, and I am just writing this >> email as an extra plea so that if you happen to run a network that has this >> entire range on your naughty list, we would appreciate you giving it another >> chance. I can be contacted on or off list, thanks. >> >> > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From hannigan at gmail.com Sat Mar 11 21:13:25 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 11 Mar 2017 21:13:25 +0000 Subject: Purchased IPv4 Woes In-Reply-To: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> Message-ID: Which broker did you use fot the transaction? Did you get a discount for knowingly accepting a dirty block or is this a surprise? Are folks asking for warranties on acquired addresses these days? Cheers, -M< Best, -M< On Fri, Mar 10, 2017 at 12:11 Pete Baldwin wrote: > Hi All, > > Hopefully this is not taken in bad taste. Our organization > purchased some IP space last year (163.182.192.0/18 to be specific), and > it appears that this block must have been used for less-than-admirable > purposes in the past. > > We have been trying to clean up the reputation where possible, and we do > not appear to be on any blacklists, but we do appear to be blocked from > a lot of networks across the US/Canada. I am noticing a lot of name > servers blocking our requests, many web servers, gaming servers, mail etc. > > This is a transition block for us to move towards v6 everywhere, but we > have many systems that will need to rely on this block of space for some > time to come. > > We are a small rural co-op ISP in Ontario, and I am just writing this > email as an extra plea so that if you happen to run a network that has > this entire range on your naughty list, we would appreciate you giving > it another chance. I can be contacted on or off list, thanks. > > > -- > > > ----- > > Pete Baldwin > Tuckersmith Communications > (P) 519-565-2400 > (C) 519-441-7383 > > From bryan at shout.net Sun Mar 12 04:27:13 2017 From: bryan at shout.net (Bryan Holloway) Date: Sat, 11 Mar 2017 22:27:13 -0600 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> Message-ID: <1aefba75-9fb8-5a91-7997-b7f59580ae0f@shout.net> Indeed. Let this be a lesson: when purchasing blocks, one MUST do their due diligence. Check the RBLs, senderbase, previous owner reputation, etc. before buying. Caveat emptor. On 3/11/17 3:13 PM, Martin Hannigan wrote: > Which broker did you use fot the transaction? > > Did you get a discount for knowingly accepting a dirty block or is this a > surprise? > > Are folks asking for warranties on acquired addresses these days? > > Cheers, > > -M< > > > > > > > Best, > > -M< > > > > > On Fri, Mar 10, 2017 at 12:11 Pete Baldwin wrote: > >> Hi All, >> >> Hopefully this is not taken in bad taste. Our organization >> purchased some IP space last year (163.182.192.0/18 to be specific), and >> it appears that this block must have been used for less-than-admirable >> purposes in the past. >> >> We have been trying to clean up the reputation where possible, and we do >> not appear to be on any blacklists, but we do appear to be blocked from >> a lot of networks across the US/Canada. I am noticing a lot of name >> servers blocking our requests, many web servers, gaming servers, mail etc. >> >> This is a transition block for us to move towards v6 everywhere, but we >> have many systems that will need to rely on this block of space for some >> time to come. >> >> We are a small rural co-op ISP in Ontario, and I am just writing this >> email as an extra plea so that if you happen to run a network that has >> this entire range on your naughty list, we would appreciate you giving >> it another chance. I can be contacted on or off list, thanks. >> >> >> -- >> >> >> ----- >> >> Pete Baldwin >> Tuckersmith Communications >> (P) 519-565-2400 >> (C) 519-441-7383 >> >> From bob at FiberInternetCenter.com Sun Mar 12 05:02:08 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 11 Mar 2017 21:02:08 -0800 Subject: Purchased IPv4 Woes In-Reply-To: <1aefba75-9fb8-5a91-7997-b7f59580ae0f@shout.net> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <1aefba75-9fb8-5a91-7997-b7f59580ae0f@shout.net> Message-ID: <4c5b5121d9593bc84d0cb7ba15ed28fa.squirrel@66.201.44.180> Validating is a lot of work, but you have to do it. I know there are lots of blocks with RBL problems. Some spammers make so much money, they easily afford to buy small blocks , abuse them to make money, buy more blocks and put the olds up for sale. Careful price is rarely a tell about a bad block. Only the cost of their first block is their initial sunk cost, as they cycle through blocks. Thank You Bob Evans CTO > Indeed. > > Let this be a lesson: when purchasing blocks, one MUST do their due > diligence. Check the RBLs, senderbase, previous owner reputation, etc. > before buying. > > Caveat emptor. > > > On 3/11/17 3:13 PM, Martin Hannigan wrote: >> Which broker did you use fot the transaction? >> >> Did you get a discount for knowingly accepting a dirty block or is this >> a >> surprise? >> >> Are folks asking for warranties on acquired addresses these days? >> >> Cheers, >> >> -M< >> >> >> >> >> >> >> Best, >> >> -M< >> >> >> >> >> On Fri, Mar 10, 2017 at 12:11 Pete Baldwin wrote: >> >>> Hi All, >>> >>> Hopefully this is not taken in bad taste. Our organization >>> purchased some IP space last year (163.182.192.0/18 to be specific), >>> and >>> it appears that this block must have been used for less-than-admirable >>> purposes in the past. >>> >>> We have been trying to clean up the reputation where possible, and we >>> do >>> not appear to be on any blacklists, but we do appear to be blocked from >>> a lot of networks across the US/Canada. I am noticing a lot of name >>> servers blocking our requests, many web servers, gaming servers, mail >>> etc. >>> >>> This is a transition block for us to move towards v6 everywhere, but we >>> have many systems that will need to rely on this block of space for >>> some >>> time to come. >>> >>> We are a small rural co-op ISP in Ontario, and I am just writing this >>> email as an extra plea so that if you happen to run a network that has >>> this entire range on your naughty list, we would appreciate you giving >>> it another chance. I can be contacted on or off list, thanks. >>> >>> >>> -- >>> >>> >>> ----- >>> >>> Pete Baldwin >>> Tuckersmith Communications >>> (P) 519-565-2400 >>> (C) 519-441-7383 >>> >>> > From lists at mtin.net Sun Mar 12 14:51:20 2017 From: lists at mtin.net (Justin Wilson) Date: Sun, 12 Mar 2017 10:51:20 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> Message-ID: <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> I am interested in what broker you used as well. We have used a few that do a little due diligence on their end, but we still do our own. We have seen an auction pulled due to the space having a bad reputation, but we were the ones who had to step up and say something. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Mar 10, 2017, at 12:00 PM, Pete Baldwin wrote: > > Hi All, > > Hopefully this is not taken in bad taste. Our organization purchased some IP space last year (163.182.192.0/18 to be specific), and it appears that this block must have been used for less-than-admirable purposes in the past. > > We have been trying to clean up the reputation where possible, and we do not appear to be on any blacklists, but we do appear to be blocked from a lot of networks across the US/Canada. I am noticing a lot of name servers blocking our requests, many web servers, gaming servers, mail etc. > > This is a transition block for us to move towards v6 everywhere, but we have many systems that will need to rely on this block of space for some time to come. > > We are a small rural co-op ISP in Ontario, and I am just writing this email as an extra plea so that if you happen to run a network that has this entire range on your naughty list, we would appreciate you giving it another chance. I can be contacted on or off list, thanks. > > > -- > > > ----- > > Pete Baldwin > Tuckersmith Communications > (P) 519-565-2400 > (C) 519-441-7383 > From chuckchurch at gmail.com Sun Mar 12 15:11:41 2017 From: chuckchurch at gmail.com (Chuck Church) Date: Sun, 12 Mar 2017 11:11:41 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> Message-ID: <006401d29b42$f9b85640$ed2902c0$@gmail.com> Maybe a silly idea, but shouldn't the sale of a block of addresses (RIR ownership change) trigger a removal of that block from all reputation list databases? If I buy a car from a police auction, I'm fairly sure the FBI doesn't start tailing me, because the car was once used for less than legal purposes. New owner, clean slate. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Wilson Sent: Sunday, March 12, 2017 10:51 AM To: NANOG Subject: Re: Purchased IPv4 Woes I am interested in what broker you used as well. We have used a few that do a little due diligence on their end, but we still do our own. We have seen an auction pulled due to the space having a bad reputation, but we were the ones who had to step up and say something. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Mar 10, 2017, at 12:00 PM, Pete Baldwin wrote: > > Hi All, > > Hopefully this is not taken in bad taste. Our organization purchased some IP space last year (163.182.192.0/18 to be specific), and it appears that this block must have been used for less-than-admirable purposes in the past. > > We have been trying to clean up the reputation where possible, and we do not appear to be on any blacklists, but we do appear to be blocked from a lot of networks across the US/Canada. I am noticing a lot of name servers blocking our requests, many web servers, gaming servers, mail etc. > > This is a transition block for us to move towards v6 everywhere, but we have many systems that will need to rely on this block of space for some time to come. > > We are a small rural co-op ISP in Ontario, and I am just writing this email as an extra plea so that if you happen to run a network that has this entire range on your naughty list, we would appreciate you giving it another chance. I can be contacted on or off list, thanks. > > > -- > > > ----- > > Pete Baldwin > Tuckersmith Communications > (P) 519-565-2400 > (C) 519-441-7383 > From clayton at MNSi.Net Sun Mar 12 15:16:16 2017 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sun, 12 Mar 2017 11:16:16 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <006401d29b42$f9b85640$ed2902c0$@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> Message-ID: <1489331781_22375@surgemail.mnsi.net> What should and does happen are two different things. The reputation lists aren't a regulated entity. The FBI is. At 11:11 AM 12/03/2017, Chuck Church wrote: >Maybe a silly idea, but shouldn't the sale of a >block of addresses (RIR ownership change) >trigger a removal of that block from all >reputation list databases? If I buy a car from >a police auction, I'm fairly sure the FBI >doesn't start tailing me, because the car was >once used for less than legal purposes. New owner, clean slate. > >Chuck > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Wilson >Sent: Sunday, March 12, 2017 10:51 AM >To: NANOG >Subject: Re: Purchased IPv4 Woes > >I am interested in what broker you used as >well. We have used a few that do a little due >diligence on their end, but we still do our >own. We have seen an auction pulled due to the >space having a bad reputation, but we were the >ones who had to step up and say something. > > >Justin Wilson >j2sw at mtin.net > >--- >http://www.mtin.net Owner/CEO >xISP Solutions- Consulting ? Data Centers - Bandwidth >http://www.midwest-ix.com COO/Chairman >Internet Exchange - Peering - Distributed Fabric > > > On Mar 10, 2017, at 12:00 PM, Pete Baldwin wrote: > > > > Hi All, > > > > Hopefully this is not taken in bad > taste. Our organization purchased some IP > space last year (163.182.192.0/18 to be > specific), and it appears that this block must > have been used for less-than-admirable purposes in the past. > > > > We have been trying to clean up the > reputation where possible, and we do not appear > to be on any blacklists, but we do appear to be > blocked from a lot of networks across the > US/Canada. I am noticing a lot of name > servers blocking our requests, many web servers, gaming servers, mail etc. > > > > This is a transition block for us to move > towards v6 everywhere, but we have many systems > that will need to rely on this block of space for some time to come. > > > > We are a small rural co-op ISP in Ontario, > and I am just writing this email as an extra > plea so that if you happen to run a network > that has this entire range on your naughty > list, we would appreciate you giving it another > chance. I can be contacted on or off list, thanks. > > > > > > -- > > > > > > ----- > > > > Pete Baldwin > > Tuckersmith Communications > > (P) 519-565-2400 > > (C) 519-441-7383 > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From sfrost at snowman.net Sun Mar 12 15:20:59 2017 From: sfrost at snowman.net (Stephen Frost) Date: Sun, 12 Mar 2017 11:20:59 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <006401d29b42$f9b85640$ed2902c0$@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> Message-ID: <20170312152059.GS9812@tamriel.snowman.net> Chuck, * Chuck Church (chuckchurch at gmail.com) wrote: > Maybe a silly idea, but shouldn't the sale of a block of addresses (RIR ownership change) trigger a removal of that block from all reputation list databases? If I buy a car from a police auction, I'm fairly sure the FBI doesn't start tailing me, because the car was once used for less than legal purposes. New owner, clean slate. That would be an awful easy way to allow people to game the entire reputation list system by simply creating more companies and passing ownership around. This could work if the system "knows" that the buyer isn't going to use the netblock for spamming, but that's next to impossible to do in any kind of automated fashion. Thanks! Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From valdis.kletnieks at vt.edu Sun Mar 12 15:40:28 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 12 Mar 2017 11:40:28 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <006401d29b42$f9b85640$ed2902c0$@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> Message-ID: <143324.1489333228@turing-police.cc.vt.edu> On Sun, 12 Mar 2017 11:11:41 -0400, "Chuck Church" said: > Maybe a silly idea, but shouldn't the sale of a block of addresses (RIR > ownership change) trigger a removal of that block from all reputation list > databases? If I buy a car from a police auction, I'm fairly sure the FBI > doesn't start tailing me, because the car was once used for less than legal > purposes. New owner, clean slate. How does Spamhaus find out the block has been resold? How do other DNS-based blacklist operators find out? How do all the AS's that have their own internal blacklists find out that they should fix their old listings? (Note that this is the exact same problem as "We got blacklisted because of a bad customer, we axed the customer, but we're still blacklisted", which has been a an unsolved problem for decades now). And it's awfully easy to game the system by just reselling the block between a group of shell companies run by bad actors. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From rsk at gsp.org Sun Mar 12 15:43:55 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 12 Mar 2017 11:43:55 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <006401d29b42$f9b85640$ed2902c0$@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> Message-ID: <20170312154355.GA2633@gsp.org> On Sun, Mar 12, 2017 at 11:11:41AM -0400, Chuck Church wrote: > Maybe a silly idea, but shouldn't the sale of a block of addresses (RIR > ownership change) trigger a removal of that block from all reputation > list databases? If we'd not seen many, MANY instances where this was done as a ruse to present the appearance of an ownership change while a block was actually still controlled by the same entity (or their partners or similar) then yes, maybe this might be a viable approach. --rsk From baldur.norddahl at gmail.com Sun Mar 12 15:59:04 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 12 Mar 2017 16:59:04 +0100 Subject: Purchased IPv4 Woes In-Reply-To: <143324.1489333228@turing-police.cc.vt.edu> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: They could watch the routing table and notice which ASN is actually using the address space. In fact ASN reputation might work better than IP space reputation. Fact is that the current approach does nothing to stop spammers from swapping space when they are done abusing one space. The argument that clearing the slate for sold space would make it easy to game the system does not hold. It is already trivial. The sad fact is that entities like Spamhaus simply do not care. Not even though they are not succeeding in hurting actual spammers. Not even though they are making their own service less useful. Regards Baldur Den 12. mar. 2017 16.41 skrev : On Sun, 12 Mar 2017 11:11:41 -0400, "Chuck Church" said: > Maybe a silly idea, but shouldn't the sale of a block of addresses (RIR > ownership change) trigger a removal of that block from all reputation list > databases? If I buy a car from a police auction, I'm fairly sure the FBI > doesn't start tailing me, because the car was once used for less than legal > purposes. New owner, clean slate. How does Spamhaus find out the block has been resold? How do other DNS-based blacklist operators find out? How do all the AS's that have their own internal blacklists find out that they should fix their old listings? (Note that this is the exact same problem as "We got blacklisted because of a bad customer, we axed the customer, but we're still blacklisted", which has been a an unsolved problem for decades now). And it's awfully easy to game the system by just reselling the block between a group of shell companies run by bad actors. From savage at savage.za.org Sun Mar 12 15:59:59 2017 From: savage at savage.za.org (Chris Knipe) Date: Sun, 12 Mar 2017 17:59:59 +0200 Subject: Purchased IPv4 Woes In-Reply-To: <143324.1489333228@turing-police.cc.vt.edu> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: On Sun, Mar 12, 2017 at 5:40 PM, wrote: > > How does Spamhaus find out the block has been resold? > > How do other DNS-based blacklist operators find out? > > >From the REGISTRY as the ultimate custodian of the IP block. > How do all the AS's that have their own internal blacklists find out that > they should fix their old listings? (Note that this is the exact same > problem > as "We got blacklisted because of a bad customer, we axed the customer, but > we're still blacklisted", which has been a an unsolved problem for decades > now). > > >From the REGISTRY as the ultimate custodian of the IP block. "We got blacklisted because of a bad customer, we axed the customer, but we're still blacklisted" is a FAR call from what this discussion is about. "I got blacklisted because someone else that has NO relevance to me what so ever was stupid" is more accurate. You can't punish the purchaser of an IP block, because of what previous owners of the IP block did. If I receive a dynamic IP from my ISP on dialup, and the previous user using that IP hacked the FBI... Am I now to blame because the FBI got hacked? NO! The previous user of the IP is responsible! > And it's awfully easy to game the system by just reselling the block > between > a group of shell companies run by bad actors. > > Yes - just like we're playing ping pong with NetFlix (and others) and VPN providers because of geo restricted content too :-) It's a loosing battle, and a failed system. Don't blame the purchaser, it's a lack of oversight on the part of who ever does the blacklisting. And that, should form part of being RESPONSIBLE when you DO decide to blacklist / unblacklist IP blocks. There are FAR to many companies on the Internet that simply does what they want, when they want. I (or anyone else - I haven't purchased IP space from any other source other than registries, yet), can't be held liable for what others have done. Whether it's IP space, whether it's breaking an entering, whether it's fraud, it doesn't matter. I did not commit the act, and I can't be held liable. Your punishing the wrong person, for the wrong reason. The fact that there's companies out there, CAMPING on /8s which they do not use and yet refuse to return, is exactly why the internet is sitting in this predicament. From savage at savage.za.org Sun Mar 12 16:02:29 2017 From: savage at savage.za.org (Chris Knipe) Date: Sun, 12 Mar 2017 18:02:29 +0200 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: On Sun, Mar 12, 2017 at 5:59 PM, Baldur Norddahl wrote: > They could watch the routing table and notice which ASN is actually using > the address space. In fact ASN reputation might work better than IP space > reputation. > +1 And not only the originating ASN, but to a lesser extend, adjacent ASNs too From valdis.kletnieks at vt.edu Sun Mar 12 16:17:35 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 12 Mar 2017 12:17:35 -0400 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: <145954.1489335455@turing-police.cc.vt.edu> On Sun, 12 Mar 2017 17:59:59 +0200, Chris Knipe said: > > How do all the AS's that have their own internal blacklists find out that > > they should fix their old listings? (Note that this is the exact same > > problem > > as "We got blacklisted because of a bad customer, we axed the customer, but > > we're still blacklisted", which has been a an unsolved problem for decades > > now). > > > > > From the REGISTRY as the ultimate custodian of the IP block. >From Friday's routing table report. BGP routing table entries examined: 639225 Prefixes after maximum aggregation (per Origin AS): 248678 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 307752 Total ASes present in the Internet Routing Table: 56403 As 56,000 AS's all start querying each of the registries (ARIN, RIPE, APnic, LACNIC, and AfriNic) for all 639,000 objects once a day, to see which dozen of those got sold yesterday. Sure, that will work. (And no, the problem isn't the number of http hits on the registries. 35,840,000,000 hits per day is the easy part...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From savage at savage.za.org Sun Mar 12 16:38:21 2017 From: savage at savage.za.org (Chris Knipe) Date: Sun, 12 Mar 2017 18:38:21 +0200 Subject: Purchased IPv4 Woes In-Reply-To: <145954.1489335455@turing-police.cc.vt.edu> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <145954.1489335455@turing-police.cc.vt.edu> Message-ID: On Sun, Mar 12, 2017 at 6:17 PM, wrote: > On Sun, 12 Mar 2017 17:59:59 +0200, Chris Knipe said: > > > Sure, that will work. (And no, the problem isn't the number of http hits > on the registries. 35,840,000,000 hits per day is the easy part...) > And yet, there's no problems of BILLIONS of queries against RBL DNS servers? -- Regards, Chris Knipe From valdis.kletnieks at vt.edu Sun Mar 12 17:03:46 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 12 Mar 2017 13:03:46 -0400 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <145954.1489335455@turing-police.cc.vt.edu> Message-ID: <148865.1489338226@turing-police.cc.vt.edu> On Sun, 12 Mar 2017 18:38:21 +0200, Chris Knipe said: > On Sun, Mar 12, 2017 at 6:17 PM, wrote: > > on the registries. 35,840,000,000 hits per day is the easy part...) > And yet, there's no problems of BILLIONS of queries against RBL DNS servers? As I said, that's not the problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From bruns at 2mbit.com Sun Mar 12 17:11:59 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 12 Mar 2017 11:11:59 -0600 Subject: Purchased IPv4 Woes In-Reply-To: <006401d29b42$f9b85640$ed2902c0$@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> Message-ID: <331effa8-c9bc-ab4e-0ed8-cc09fed172f0@2mbit.com> On 3/12/17 9:11 AM, Chuck Church wrote: > Maybe a silly idea, but shouldn't the sale of a block of addresses > (RIR ownership change) trigger a removal of that block from all > reputation list databases? If I buy a car from a police auction, I'm > fairly sure the FBI doesn't start tailing me, because the car was > once used for less than legal purposes. New owner, clean slate. > No. No verifiable way to confirm that a block has actually changed hands, and not just had its user/POC renamed, sold to 'new' owner to dodge bankruptcy/creditors, etc. And just because a car was bought at police auction doesn't mean it has no bad things associated with it anymore - such as drugs in the walls of the passenger doors, or the FBI tracking device under the front driver wheel well. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Sun Mar 12 17:14:49 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 12 Mar 2017 11:14:49 -0600 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <145954.1489335455@turing-police.cc.vt.edu> Message-ID: <51060783-4f3d-b572-b90a-35fbc461804f@2mbit.com> On 3/12/17 10:38 AM, Chris Knipe wrote: > On Sun, Mar 12, 2017 at 6:17 PM, wrote: > >> On Sun, 12 Mar 2017 17:59:59 +0200, Chris Knipe said: >> >> >> Sure, that will work. (And no, the problem isn't the number of http hits >> on the registries. 35,840,000,000 hits per day is the easy part...) >> > > > And yet, there's no problems of BILLIONS of queries against RBL DNS servers? > > > http == TCP DNS == (usually) UDP Big difference here. One requires a three way handshake tearup/teardown, the other does not. It is not an apples to apples comparison. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From rsk at gsp.org Sun Mar 12 17:33:44 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 12 Mar 2017 13:33:44 -0400 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: <20170312173344.GA7477@gsp.org> On Sun, Mar 12, 2017 at 05:59:59PM +0200, Chris Knipe wrote: > It's a loosing battle, and a failed system. Don't blame the purchaser, > it's a lack of oversight on the part of who ever does the blacklisting. You bought damaged goods which aren't fit for the purpose you have in mind. If you had performed due diligence research before finalizing the purchase, perhaps you would have chosen not to do so. If the seller had done their due diligence research, perhaps they could have more accurately described what they were selling to you. There's certainly a lack of "oversight" here, but it's not on the part of the various blacklists which have *correctly* noted the dubious history of the allocation in question. And which, I might add, are not in possession of proof that it doesn't still belong to the same people who generated that dubious history. In other words, everything said here thus far might be precisely the truth, or it might be the 14,273th iteration of a ruse designed to get the block unlisted so that it can be once again utilized for abuse. ---rsk From bill at herrin.us Sun Mar 12 17:42:37 2017 From: bill at herrin.us (William Herrin) Date: Sun, 12 Mar 2017 13:42:37 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <006401d29b42$f9b85640$ed2902c0$@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> Message-ID: On Sun, Mar 12, 2017 at 11:11 AM, Chuck Church wrote: > Maybe a silly idea, but shouldn't the sale of a block of addresses > (RIR ownership change) trigger a removal of that block from all reputation > list databases? Hi Chuck, You're talking about 50+ database operators half of which don't identify their principals and offer no way contact staff or interact with them except, sometimes, through narrowly defined reporting tools. Google is a prime example of the problem. They write great algorithms but their confidence in those algorithms far exceeds their greatness. The current catastrophic mess with Recaptcha should offer a cautionary tale for all. > If I buy a car from a police auction, I'm fairly sure the FBI doesn't start > tailing me, because the car was once used for less than legal purposes. You would think so, but I have a friend who is visited by police every few months because the prior owner of his house is a petty criminal still committing crimes and their database shows the house as his last known residence. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From rob at invaluement.com Sun Mar 12 17:49:04 2017 From: rob at invaluement.com (Rob McEwen) Date: Sun, 12 Mar 2017 13:49:04 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <143324.1489333228@turing-police.cc.vt.edu> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: On 3/12/2017 11:40 AM, valdis.kletnieks at vt.edu wrote: > How does Spamhaus find out the block has been resold? > How do other DNS-based blacklist operators find out? Spamhaus and other reasonable and well-run DNSBLs: (1) have reasonable auto-expiration mechanisms (which cover the vast majority of these situations where a block gets a new and more ethical owner) (2) and have all various different monitoring and feedback mechanisms - which may not be perfect and may not have God-like omniscience - but generally get things right before too long - they have overall very excellent telemetry and they don't get very much wrong at any one point in time. In contrast, much of the cause of this problem described on this thread is caused by system admins relying less on well-run blacklists, and rely more on "set it and forget it" manual blocking of IPs and subnets at their perimeter. (in contrast to well-run DNSBLs...) They then often have ZERO expirations happening - listing are basically permanent - until manually removed - and their telemetry/feedback is just horrific compared to a well-run DNSBL. There also are not any public lookup forms in the world where a sender can determine which such manual blocks are found on which ISP/hosters/datacenters. The good news here - is that this becomes further motivation for senders to be vigilant to protect their IPs reputation - knowing that a lack of such effort can quickly lead to their IP space becoming "damaged goods". This motivation goes a LONG way towards countering the profit motives that hosters/ISPs/Datacenters/ESPs have in selling services to spammers - there is MUCH money to be made doing so. But the longer term repercussions of damaged IP reputation makes that a *bad* long-term investment (even if the short-term gains are lucrative). Meanwhile, btw - moving all mail servers to IPv6 too fast... ELIMINATES that motivation. Almost everyone reading this paragraph on NANOG has no idea just (a) how much this incentive keeps email sane and manageable - and (b) just how bad things will get if this incentive is removed, via moving all MTAs to IPv6. (In an all-IPv6 world - if you ruin your IP reputation by making a ton of money selling to spammers - there are always vast amounts of new space to acquire) I can tell you that, ultimately, this is the ONLY thing keeping hosters/ISPs/Datacenters/ESPs from selling services to spammers. Some who deny that this statement applies to them - will at least move the goalposts somewhat, now matter how good of intentions they may think they have. (human nature always dominates) (but there is no problem moving all email *clients* to IPv6 - where their IPv6-sent mail then SMTP-authenticates to mail servers... which then send that message to other mail servers via IPv4 - at least for the foreseeable future) -- Rob McEwen From baldur.norddahl at gmail.com Sun Mar 12 17:53:46 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 12 Mar 2017 18:53:46 +0100 Subject: Purchased IPv4 Woes In-Reply-To: <51060783-4f3d-b572-b90a-35fbc461804f@2mbit.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <145954.1489335455@turing-police.cc.vt.edu> <51060783-4f3d-b572-b90a-35fbc461804f@2mbit.com> Message-ID: Den 12/03/2017 kl. 18.14 skrev Brielle Bruns: > http == TCP > DNS == (usually) UDP > > Big difference here. One requires a three way handshake > tearup/teardown, the other does not. > > It is not an apples to apples comparison. > You can replicate (download) the whole WHOIS if you need to. There is also no requirement that removal from reputation lists is instant. We would be good if it happened just within a month or even half a year. The situation now is however that you will never have it removed and many reputation services will ignore you if try to contact them for manual removal. At least in the RIPE managed space there IS a reliable way to know for sure who owns a block. Can you know that the new owner is any better than the old? Of course not, but that is true even for "fresh" address space. I am not a fan of reputation services that blacklist forever. It is just wrong and open for abuse of power. But not much I can do about that other than not using their service. Regards, Baldur From baldur.norddahl at gmail.com Sun Mar 12 18:00:02 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 12 Mar 2017 19:00:02 +0100 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> Den 12/03/2017 kl. 18.49 skrev Rob McEwen: > This motivation goes a LONG way towards countering the profit motives > that hosters/ISPs/Datacenters/ESPs have in selling services to > spammers - there is MUCH money to be made doing so. But the longer > term repercussions of damaged IP reputation makes that a *bad* > long-term investment (even if the short-term gains are lucrative). Sorry but this is not true. The address space does not lose that much in value and in fact most address space that has been used for end users is already tainted in the same way (due to botnets etc). From savage at savage.za.org Sun Mar 12 18:01:34 2017 From: savage at savage.za.org (Chris Knipe) Date: Sun, 12 Mar 2017 20:01:34 +0200 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <145954.1489335455@turing-police.cc.vt.edu> <51060783-4f3d-b572-b90a-35fbc461804f@2mbit.com> Message-ID: On Sun, Mar 12, 2017 at 7:53 PM, Baldur Norddahl wrote: > > > Den 12/03/2017 kl. 18.14 skrev Brielle Bruns: > >> http == TCP >> DNS == (usually) UDP >> >> Big difference here. One requires a three way handshake tearup/teardown, >> the other does not. >> >> It is not an apples to apples comparison. >> >> > You can replicate (download) the whole WHOIS if you need to. There is also > no requirement that removal from reputation lists is instant. We would be > good if it happened just within a month or even half a year. The situation > now is however that you will never have it removed and many reputation > services will ignore you if try to contact them for manual removal. > > At least in the RIPE managed space there IS a reliable way to know for > sure who owns a block. Can you know that the new owner is any better than > the old? Of course not, but that is true even for "fresh" address space. > > I am not a fan of reputation services that blacklist forever. It is just > wrong and open for abuse of power. But not much I can do about that other > than not using their service. > > Also, no reason why a UDP (or DNS based even) query can't be implemented to facilitate reputation lookups for ASNs, or even ownership. -- Regards, Chris Knipe From rob at invaluement.com Sun Mar 12 18:24:37 2017 From: rob at invaluement.com (Rob McEwen) Date: Sun, 12 Mar 2017 14:24:37 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> Message-ID: On 3/12/2017 2:00 PM, Baldur Norddahl wrote: > Den 12/03/2017 kl. 18.49 skrev Rob McEwen: >> This motivation goes a LONG way towards countering the profit motives >> that hosters/ISPs/Datacenters/ESPs have in selling services to >> spammers - there is MUCH money to be made doing so. But the longer >> term repercussions of damaged IP reputation makes that a *bad* >> long-term investment (even if the short-term gains are lucrative). > > Sorry but this is not true. The address space does not lose that much in > value and in fact most address space that has been used for end users is > already tainted in the same way (due to botnets etc). First, I'm on the front lines of this particular fight - and my conversations I have with mail senders (of all various types) gives me constant 1st-hand confirmation of these facts you deny. But don't take my word for it - consider the following article written by Brian Krebs: https://krebsonsecurity.com/2015/08/like-cutting-off-a-limb-to-save-the-body/ If what you said is true, then Hostwinds wouldn't have ever seen a need to reform - and they wouldn't have ever reformed. And many of the hosters who had more foresight and never had to learn this less the hard way - would have likewise followed hostwinds footsteps (except without the the reform part) Also, if any good hosting company just let their guard down and started allowing just any spammer to purchase services - their IP space reputation would nosedive across-the-board to the lowest of depths... that occasional random botnets on a residential dynamic IPs - could never get to. -- Rob McEwen From rob at invaluement.com Sun Mar 12 18:40:24 2017 From: rob at invaluement.com (Rob McEwen) Date: Sun, 12 Mar 2017 14:40:24 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> Message-ID: <5e9e848d-415f-3c39-6785-af772b275a79@invaluement.com> On 3/12/2017 2:00 PM, Baldur Norddahl wrote: > Sorry but this is not true. The address space does not lose that much in > value and in fact most address space that has been used for end users is > already tainted in the same way (due to botnets etc). Also, you're comparing apples-to-oranges. Dynamically allocated IPs for "end users" are not suppose to host mail and web servers - at least not professional and high-quality hosting services. This is why their outbound speed is almost always governed down to a trickle (often order of magnitudes slower then the download speeds), and port 25 is often blocked (when not headed to the mail server hosted by the particular ISP which controls that space). Such IPs are OFTEN preemptively blacklisted by Spamhaus's PBL list: https://www.spamhaus.org/pbl/ If someone wants to run a mail server (or even a web server) from such space - then they have a whole bunch of OTHER problems besides who/what damaged the space before they acquired it. Their first problem is that they are trying to tow a boat with their bicycle. -- Rob McEwen From cb.list6 at gmail.com Sun Mar 12 18:50:47 2017 From: cb.list6 at gmail.com (Ca By) Date: Sun, 12 Mar 2017 18:50:47 +0000 Subject: Purchased IPv4 Woes In-Reply-To: <5e9e848d-415f-3c39-6785-af772b275a79@invaluement.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> <5e9e848d-415f-3c39-6785-af772b275a79@invaluement.com> Message-ID: Their first problem is that > they are trying to tow a boat with their bicycle. > Fair statement for anyone who has not deployed ipv6 and thinks emailing nanog to get them off a blacklist will help. > -- > Rob McEwen > > > From pete at tccmail.ca Sun Mar 12 00:45:50 2017 From: pete at tccmail.ca (Pete Baldwin) Date: Sat, 11 Mar 2017 19:45:50 -0500 Subject: Purchased IPv4 Woes In-Reply-To: <288e55d6-a1f8-b94b-c64b-feb354db5db5@coldnorthadmin.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <288e55d6-a1f8-b94b-c64b-feb354db5db5@coldnorthadmin.com> Message-ID: <40a225c6-54b9-9004-68bb-be64eb5d63e7@tccmail.ca> The previous owner was XELAS Software in Marina Del Ray, California. I still see it listed on some geoIP databases, but those have been cleaned for the most part. I'm not sure if someone had it before them and they just got rid of it because of these issues, so I don't want to point fingers at XELAS by any means. ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 On 03/11/2017 01:01 AM, Laurent Dumont wrote: > Out of curiosity, who were the previous owner(s), it seems that ARIN > only shows the current owner with any history? If it was a > Chinese/Russian block, you might be out of luck. > > > On 03/10/2017 12:00 PM, Pete Baldwin wrote: >> Hi All, >> >> Hopefully this is not taken in bad taste. Our organization >> purchased some IP space last year (163.182.192.0/18 to be specific), >> and it appears that this block must have been used for >> less-than-admirable purposes in the past. >> >> We have been trying to clean up the reputation where possible, and we >> do not appear to be on any blacklists, but we do appear to be blocked >> from a lot of networks across the US/Canada. I am noticing a lot >> of name servers blocking our requests, many web servers, gaming >> servers, mail etc. >> >> This is a transition block for us to move towards v6 everywhere, but >> we have many systems that will need to rely on this block of space >> for some time to come. >> >> We are a small rural co-op ISP in Ontario, and I am just writing this >> email as an extra plea so that if you happen to run a network that >> has this entire range on your naughty list, we would appreciate you >> giving it another chance. I can be contacted on or off list, thanks. >> >> > From pete at tccmail.ca Sun Mar 12 01:08:01 2017 From: pete at tccmail.ca (Pete Baldwin) Date: Sat, 11 Mar 2017 20:08:01 -0500 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <288e55d6-a1f8-b94b-c64b-feb354db5db5@coldnorthadmin.com> Message-ID: <91d71f30-f80c-fe91-0e39-0692f90cbe3b@tccmail.ca> Looks like it was taken off the list in Sept 2016. I suppose this could be the reason why our block is still listed in various networks, even though it's not on a known 'official' list. Thanks for the tip Mike. ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 On 03/11/2017 01:53 AM, Mike Hale wrote: > It looks like Spamhaus has your entire /16. > > https://stat.ripe.net/163.182.192.0%2F18#tabId=anti-abuse > > > > On Fri, Mar 10, 2017 at 10:01 PM, Laurent Dumont > wrote: >> Out of curiosity, who were the previous owner(s), it seems that ARIN only >> shows the current owner with any history? If it was a Chinese/Russian block, >> you might be out of luck. >> >> >> >> On 03/10/2017 12:00 PM, Pete Baldwin wrote: >>> Hi All, >>> >>> Hopefully this is not taken in bad taste. Our organization purchased >>> some IP space last year (163.182.192.0/18 to be specific), and it appears >>> that this block must have been used for less-than-admirable purposes in the >>> past. >>> >>> We have been trying to clean up the reputation where possible, and we do >>> not appear to be on any blacklists, but we do appear to be blocked from a >>> lot of networks across the US/Canada. I am noticing a lot of name servers >>> blocking our requests, many web servers, gaming servers, mail etc. >>> >>> This is a transition block for us to move towards v6 everywhere, but we >>> have many systems that will need to rely on this block of space for some >>> time to come. >>> >>> We are a small rural co-op ISP in Ontario, and I am just writing this >>> email as an extra plea so that if you happen to run a network that has this >>> entire range on your naughty list, we would appreciate you giving it another >>> chance. I can be contacted on or off list, thanks. >>> >>> > > From pete at tccmail.ca Sun Mar 12 14:27:52 2017 From: pete at tccmail.ca (Pete Baldwin) Date: Sun, 12 Mar 2017 10:27:52 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <1aefba75-9fb8-5a91-7997-b7f59580ae0f@shout.net> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <1aefba75-9fb8-5a91-7997-b7f59580ae0f@shout.net> Message-ID: <3ad90166-07d7-923e-77e5-6539d6fb32e5@tccmail.ca> We used giglinx. There was a third party that was validating the blocks, and they/we caught a lot of issues with the first block for offer. This was the second block offered, and it looked decent, but I never personally checked the /16 parent. I was only looking at the /18. The reason I made this post is to try and catch the things I couldn't see. We don't appear to be on any lists (RBLs, senderbase look good), but obviously we are still in peoples filtering rules. The big one was Spamhaus DROP but that was removed before we purchased the block. The previous owner looked fine too, it was actually the owner before the last that seemed to have been the cause of a lot of the bad rep, but again that was cleaned up before we ever even made the request to buy. ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 On 03/11/2017 11:27 PM, Bryan Holloway wrote: > Indeed. > > Let this be a lesson: when purchasing blocks, one MUST do their due > diligence. Check the RBLs, senderbase, previous owner reputation, etc. > before buying. > > Caveat emptor. > > > On 3/11/17 3:13 PM, Martin Hannigan wrote: >> Which broker did you use fot the transaction? >> >> Did you get a discount for knowingly accepting a dirty block or is >> this a >> surprise? >> >> Are folks asking for warranties on acquired addresses these days? >> >> Cheers, >> >> -M< >> >> >> >> >> >> >> Best, >> >> -M< >> >> >> >> >> On Fri, Mar 10, 2017 at 12:11 Pete Baldwin wrote: >> >>> Hi All, >>> >>> Hopefully this is not taken in bad taste. Our organization >>> purchased some IP space last year (163.182.192.0/18 to be specific), >>> and >>> it appears that this block must have been used for less-than-admirable >>> purposes in the past. >>> >>> We have been trying to clean up the reputation where possible, and >>> we do >>> not appear to be on any blacklists, but we do appear to be blocked from >>> a lot of networks across the US/Canada. I am noticing a lot of name >>> servers blocking our requests, many web servers, gaming servers, >>> mail etc. >>> >>> This is a transition block for us to move towards v6 everywhere, but we >>> have many systems that will need to rely on this block of space for >>> some >>> time to come. >>> >>> We are a small rural co-op ISP in Ontario, and I am just writing this >>> email as an extra plea so that if you happen to run a network that has >>> this entire range on your naughty list, we would appreciate you giving >>> it another chance. I can be contacted on or off list, thanks. >>> >>> >>> -- >>> >>> >>> ----- >>> >>> Pete Baldwin >>> Tuckersmith Communications >>> (P) 519-565-2400 >>> (C) 519-441-7383 >>> >>> From baldur.norddahl at gmail.com Sun Mar 12 23:20:03 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Mar 2017 00:20:03 +0100 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> Message-ID: Den 12/03/2017 kl. 19.24 skrev Rob McEwen: > On 3/12/2017 2:00 PM, Baldur Norddahl wrote: >> Den 12/03/2017 kl. 18.49 skrev Rob McEwen: >>> This motivation goes a LONG way towards countering the profit motives >>> that hosters/ISPs/Datacenters/ESPs have in selling services to >>> spammers - there is MUCH money to be made doing so. But the longer >>> term repercussions of damaged IP reputation makes that a *bad* >>> long-term investment (even if the short-term gains are lucrative). >> >> Sorry but this is not true. The address space does not lose that much in >> value and in fact most address space that has been used for end users is >> already tainted in the same way (due to botnets etc). > > First, I'm on the front lines of this particular fight - and my > conversations I have with mail senders (of all various types) gives me > constant 1st-hand confirmation of these facts you deny. > > But don't take my word for it - consider the following article written > by Brian Krebs: How much IP address space have you bought or sold in the last year? Me? About 5k IP addresses, which might not be a lot but still more than most. The article says nothing about the pricing of selling or buying IP address space. Yes it is a fact that tainted address space is slightly cheaper than "pristine" address space. Slightly. And we will happily buy it because we are not using it for sending emails anyway. And so will a lot of other eyeball ISPs and that keeps the price up. I am not complaining about the space we got. Some of it is tainted. We just assign users that complain about that some address space from untainted space. Most users never notice. But I can see the pain on a smaller hosting provider just starting out and he got unlucky with his first buy. Having a spammer abuse your address space is very expensive, but NOT because the address space can not be sold. It can. But if you have to do that, you will have to tell all your other customers to change addresses and they will not be happy campers about that. Plus it is a lot of bother and I will bet you that spammers are generally not good paying customers. The assertion that refusing to unblock address space that got sold somehow influences spammers is wrong. Regards, Baldur From baldur.norddahl at gmail.com Sun Mar 12 23:24:47 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 13 Mar 2017 00:24:47 +0100 Subject: Purchased IPv4 Woes In-Reply-To: <5e9e848d-415f-3c39-6785-af772b275a79@invaluement.com> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <379d1bae-e9bb-c54b-1ebc-ab6bc5d7fccc@gmail.com> <5e9e848d-415f-3c39-6785-af772b275a79@invaluement.com> Message-ID: Den 12/03/2017 kl. 19.40 skrev Rob McEwen: > On 3/12/2017 2:00 PM, Baldur Norddahl wrote: >> Sorry but this is not true. The address space does not lose that much in >> value and in fact most address space that has been used for end users is >> already tainted in the same way (due to botnets etc). > > Also, you're comparing apples-to-oranges. Dynamically allocated IPs > for "end users" are not suppose to host mail and web servers - at > least not professional and high-quality hosting services. This is why > their outbound speed is almost always governed down to a trickle > (often order of magnitudes slower then the download speeds), and port > 25 is often blocked (when not headed to the mail server hosted by the > particular ISP which controls that space). We are talking about address space that got sold. It might have been used for dynamically allocated IPs in some previous live. Now some poor hosting provider took over and is trying to use it for his new enterprise. By the way we sell 1000 Mbps downstream, 1000 Mbps upstream and no ports are blocked. And we are not the only FTTH provider here doing that. We will not decide what our users are supposed to host in a closet in their homes. Regards, Baldur From pete at tccmail.ca Sun Mar 12 23:26:13 2017 From: pete at tccmail.ca (Pete Baldwin) Date: Sun, 12 Mar 2017 19:26:13 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <20170312173344.GA7477@gsp.org> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <20170312173344.GA7477@gsp.org> Message-ID: So just to be clear here, the reason I made this post isn't to have some help with removing our block from 'official' blacklists around the world. We checked the lists and we weren't on them. The last (known) list this block was on was in September 2016, so just over 6 months ago now, and before we purchased it. I made this post because it appears that various networks use/used some sort of black list at some point, but haven't checked the lists in quite some time, or the block behaviour was so bad that admins blocked it manually. I'm here to say that we now own it and we plan on taking care of it in a responsible manner. I'm not blaming blacklists for holding our block hostage, as I don't see our block IN any blacklists. This thread was for me to say "hey, whoever had this thing in the past must have messed with your network enough to block it for a long time, but now I own it and plan on keeping it clean, so if you could remove us it would be better for everyone." My contact information has been in each email, so it's easily verifiable. We had limited time with which to acquire space, and we back-checked the space as well as we could. I was not expecting so many networks to have it blocked when it isn't actually listed anywhere, and I didn't have a method to verify that. That being said, I like where the thread is going as far as discussing AS rep vs CIDR rep, and other ways with which to verify whether a block has been transferred to a 'safe' entity vs a 'potentially hostile' entity or same entity under a new name. ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 On 03/12/2017 01:33 PM, Rich Kulawiec wrote: > On Sun, Mar 12, 2017 at 05:59:59PM +0200, Chris Knipe wrote: >> It's a loosing battle, and a failed system. Don't blame the purchaser, >> it's a lack of oversight on the part of who ever does the blacklisting. > You bought damaged goods which aren't fit for the purpose you have in mind. > > If you had performed due diligence research before finalizing the purchase, > perhaps you would have chosen not to do so. > > If the seller had done their due diligence research, perhaps they could > have more accurately described what they were selling to you. > > There's certainly a lack of "oversight" here, but it's not on the part > of the various blacklists which have *correctly* noted the dubious history > of the allocation in question. And which, I might add, are not in > possession of proof that it doesn't still belong to the same people > who generated that dubious history. In other words, everything said > here thus far might be precisely the truth, or it might be the 14,273th > iteration of a ruse designed to get the block unlisted so that it can > be once again utilized for abuse. > > ---rsk From pete at tccmail.ca Sun Mar 12 23:51:17 2017 From: pete at tccmail.ca (Pete Baldwin) Date: Sun, 12 Mar 2017 19:51:17 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <143324.1489333228@turing-police.cc.vt.edu> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> Message-ID: <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> So this is is really the question I had, and this is why I was wanting to start a dialog here, hoping that it wasn't out of line for the list. I don't know of a way to let a bunch of operators know that they should remove something without using something like this mailing list. Blacklists are supposed to fill this role so that one operator doesn't have to try and contact thousands of other operators individually, he/she just has to appeal to the blacklist and once delisted all should be well in short order. In cases where companies have their own internal lists, or only update them a couple of times a year from the major lists, I don't know of another way to notify everyone. I get why people are more cautious and filter entire blocks when just a few hosts are attacking/spamming them, and everyone has a choice on how they want to handle these situations. As an ISP, I want to do as little filtering as possible. I want all of my customers to have access to everything possible. If a netblock changes hands, I want to give the new owner the benefit of the doubt and only filter traffic if it repeats the same old behaviour. We're all using this finite space and I don't want to let the hostile minority slowly ruin what's left of the ipv4 assignments. ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 On 03/12/2017 11:40 AM, valdis.kletnieks at vt.edu wrote: > How do all the AS's that have their own internal blacklists find out that > they should fix their old listings? From hmcgregor at biggeeks.org Mon Mar 13 00:02:04 2017 From: hmcgregor at biggeeks.org (Harry McGregor) Date: Sun, 12 Mar 2017 17:02:04 -0700 Subject: Purchased IPv4 Woes In-Reply-To: <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> Message-ID: <6df6b8ee-53f1-e367-2448-764eca60aaca@biggeeks.org> Hi, This is why I moved away from static black lists years ago. When the 68/8 and 24/8 blocks were released and tons of networks had it blocked since it was "reserved" I observed and felt the pain. My networks are small, and I rely on things such as fail2ban which auto remove the blocks. I would be willing to bet that many of the network operators/admins that blocked your range are either not in the job any more or even dead. No one in the company knows the blocks exist... -Harry On 03/12/2017 04:51 PM, Pete Baldwin wrote: > So this is is really the question I had, and this is why I was > wanting to start a dialog here, hoping that it wasn't out of line for > the list. I don't know of a way to let a bunch of operators know that > they should remove something without using something like this mailing > list. Blacklists are supposed to fill this role so that one > operator doesn't have to try and contact thousands of other operators > individually, he/she just has to appeal to the blacklist and once > delisted all should be well in short order. > > In cases where companies have their own internal lists, or only > update them a couple of times a year from the major lists, I don't > know of another way to notify everyone. > > I get why people are more cautious and filter entire blocks when > just a few hosts are attacking/spamming them, and everyone has a > choice on how they want to handle these situations. As an ISP, I want > to do as little filtering as possible. I want all of my customers to > have access to everything possible. If a netblock changes hands, I > want to give the new owner the benefit of the doubt and only filter > traffic if it repeats the same old behaviour. We're all using this > finite space and I don't want to let the hostile minority slowly ruin > what's left of the ipv4 assignments. > > > ----- > > Pete Baldwin > Tuckersmith Communications > (P) 519-565-2400 > (C) 519-441-7383 > > On 03/12/2017 11:40 AM, valdis.kletnieks at vt.edu wrote: >> How do all the AS's that have their own internal blacklists find out >> that >> they should fix their old listings? > From jlewis at lewis.org Mon Mar 13 00:52:15 2017 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 12 Mar 2017 20:52:15 -0400 (EDT) Subject: Purchased IPv4 Woes In-Reply-To: <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> Message-ID: On Sun, 12 Mar 2017, Pete Baldwin wrote: > So this is is really the question I had, and this is why I was wanting to > start a dialog here, hoping that it wasn't out of line for the list. I don't > know of a way to let a bunch of operators know that they should remove > something without using something like this mailing list. Blacklists are > supposed to fill this role so that one operator doesn't have to try and > contact thousands of other operators individually, he/she just has to appeal > to the blacklist and once delisted all should be well in short order. > > In cases where companies have their own internal lists, or only update > them a couple of times a year from the major lists, I don't know of another > way to notify everyone. I suspect you'll find many of the private "blacklistings" are hand maintained (added to as needed, never removed from unless requested) and you'll need to play whack-a-mole, reaching out to each network as you find they have the space blocked on their mail servers or null routed on their networks. I doubt your message here will be seen by many of the "right people." How many company mail server admins read NANOG? How many companies even do email in-house and have mail server admins anymore? :) Back when my [at that time] employer was issued some of 69/8, I found it useful to setup a host with IPs in 69/8 and in one of our older IP blocks, and then do both automated reachability testing and allow anyone to do a traceroute from both source IPs simultaneously, keeping the results in a DB. If you find there are many networks actually null routing your purchased space, you might setup something similar. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bob at FiberInternetCenter.com Mon Mar 13 01:10:28 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sun, 12 Mar 2017 18:10:28 -0700 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> Message-ID: <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> Pete's right about how IPs get put on the lists. In fact, let us not forget that these lists were mostly created with volunteers - some still today. Many are very old lists. Enterprise networks select lists by some sort of popularity / fame - etc.. Like how they decide to install 8.8.8.8 as first - its easy and they think its better than their local ISP they pay.... yet they always call the ISP about slowness when 8.8.8.8 is for consumers and doesn't always resolve quickly. It's a tough sale. Once had a customer's employee abuse their mail server - it made some lists. Customer complained our network is hosting spammers and sticking them in the middle of a problem that is our networks. Hard win. Took us months to get that IP off lists. That was one single IP. We did not allow them to renew their contract once the term was over. Now, they suffer with comcast for business. ;-) Thank You Bob Evans CTO > On Sun, 12 Mar 2017, Pete Baldwin wrote: > >> So this is is really the question I had, and this is why I was >> wanting to >> start a dialog here, hoping that it wasn't out of line for the list. I >> don't >> know of a way to let a bunch of operators know that they should remove >> something without using something like this mailing list. Blacklists >> are >> supposed to fill this role so that one operator doesn't have to try and >> contact thousands of other operators individually, he/she just has to >> appeal >> to the blacklist and once delisted all should be well in short order. >> >> In cases where companies have their own internal lists, or only >> update >> them a couple of times a year from the major lists, I don't know of >> another >> way to notify everyone. > > I suspect you'll find many of the private "blacklistings" are hand > maintained (added to as needed, never removed from unless requested) and > you'll need to play whack-a-mole, reaching out to each network as you find > they have the space blocked on their mail servers or null routed on their > networks. I doubt your message here will be seen by many of the "right > people." How many company mail server admins read NANOG? How many > companies even do email in-house and have mail server admins anymore? :) > > Back when my [at that time] employer was issued some of 69/8, I found it > useful to setup a host with IPs in 69/8 and in one of our older IP blocks, > and then do both automated reachability testing and allow anyone to do a > traceroute from both source IPs simultaneously, keeping the results in a > DB. If you find there are many networks actually null routing your > purchased space, you might setup something similar. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From nanog at ics-il.net Mon Mar 13 21:52:01 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 13 Mar 2017 16:52:01 -0500 (CDT) Subject: Conference Videos In-Reply-To: <2076145158.1492.1489441358855.JavaMail.mhammett@ThunderFuck> Message-ID: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> Another organization I'm in has a hard policy of no recordings of any sessions at their conferences. They think that recordings of content (even vendor-sponsored, vendor-specific sessions with vendor consent) would have a catastrophic effect on conference attendance. NANOG doesn't seem to have that issue. Any background on the process to get there? Any regrets? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From feldman at twincreeks.net Mon Mar 13 22:06:28 2017 From: feldman at twincreeks.net (Steve Feldman) Date: Mon, 13 Mar 2017 15:06:28 -0700 Subject: Conference Videos In-Reply-To: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> References: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> Message-ID: > On Mar 13, 2017, at 2:52 PM, Mike Hammett wrote: > > Another organization I'm in has a hard policy of no recordings of any sessions at their conferences. They think that recordings of content (even vendor-sponsored, vendor-specific sessions with vendor consent) would have a catastrophic effect on conference attendance. > > NANOG doesn't seem to have that issue. Any background on the process to get there? Any regrets? > Many attendees also find value in the parts of the conference that aren't recorded, like hallway conversations, informal meetings, and even social events. Keeping and maintaining the archive of slides and video recordings is an essential part of NANOG's educational mission, which was key to obtaining and maintaining the IRS 401(c)(3) nonprofit status. So at least for the time I was on the Board, not only were there no regrets, but we worked hard to maintain and enhance the video experience. Steve From egon at egon.cc Mon Mar 13 22:08:40 2017 From: egon at egon.cc (James Downs) Date: Mon, 13 Mar 2017 15:08:40 -0700 Subject: Conference Videos In-Reply-To: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> References: <2076145158.1492.1489441358855.JavaMail.mhammett@ThunderFuck> <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> Message-ID: <20170313220840.GA405@nemesis.egontech.com> On Mon, Mar 13, 2017 at 04:52:01PM -0500, Mike Hammett wrote: > Another organization I'm in has a hard policy of no recordings of any sessions at their conferences. They think that recordings of content (even vendor-sponsored, vendor-specific sessions with vendor consent) would have a catastrophic effect on conference attendance. Check out the Openstack Summits, a conference that records *everything*, and attendence keeps going up. Cheers, -j From patrick at ianai.net Mon Mar 13 22:10:34 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 13 Mar 2017 18:10:34 -0400 Subject: Conference Videos In-Reply-To: References: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> Message-ID: <7CD15FE2-038E-4B83-A19C-B9D27BDB2CD1@ianai.net> On Mar 13, 2017, at 6:06 PM, Steve Feldman wrote: > On Mar 13, 2017, at 2:52 PM, Mike Hammett wrote: >> >> Another organization I'm in has a hard policy of no recordings of any sessions at their conferences. They think that recordings of content (even vendor-sponsored, vendor-specific sessions with vendor consent) would have a catastrophic effect on conference attendance. >> >> NANOG doesn't seem to have that issue. Any background on the process to get there? Any regrets? >> > > Many attendees also find value in the parts of the conference that aren't recorded, like hallway conversations, informal meetings, and even social events. > > Keeping and maintaining the archive of slides and video recordings is an essential part of NANOG's educational mission, which was key to obtaining and maintaining the IRS 401(c)(3) nonprofit status. > > So at least for the time I was on the Board, not only were there no regrets, but we worked hard to maintain and enhance the video experience. Speakers are informed they are going to be recorded. If they have sensitive information, they can choose a track and ask it not be recorded. NANOG has done this in the past, but you should talk to the Program Committee if you are interested in this. -- TTFN, patrick From bob at FiberInternetCenter.com Mon Mar 13 22:17:53 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 13 Mar 2017 15:17:53 -0700 Subject: Conference Videos In-Reply-To: References: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> Message-ID: <301d87fdef3f4717a1625d9e91e4effa.squirrel@66.201.44.180> I have referred to online sessions from the past several times. NANOG is great at preserving information, compared to other conferences. In addition, if you attend a conference, say you have to missed a session due to business distractions, you can usually watch it that evening in your room. If you stayed out too late and you'd rather have a late breakfast and order room service, you can watch/attend sessions virtually from your room. Thank You Bob Evans CTO > >> On Mar 13, 2017, at 2:52 PM, Mike Hammett wrote: >> >> Another organization I'm in has a hard policy of no recordings of any >> sessions at their conferences. They think that recordings of content >> (even vendor-sponsored, vendor-specific sessions with vendor consent) >> would have a catastrophic effect on conference attendance. >> >> NANOG doesn't seem to have that issue. Any background on the process to >> get there? Any regrets? >> > > Many attendees also find value in the parts of the conference that aren't > recorded, like hallway conversations, informal meetings, and even social > events. > > Keeping and maintaining the archive of slides and video recordings is an > essential part of NANOG's educational mission, which was key to obtaining > and maintaining the IRS 401(c)(3) nonprofit status. > > So at least for the time I was on the Board, not only were there no > regrets, but we worked hard to maintain and enhance the video experience. > Steve > > > From brandon at rd.bbc.co.uk Mon Mar 13 22:43:48 2017 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 13 Mar 2017 22:43:48 +0000 Subject: Conference Videos In-Reply-To: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> References: <2076145158.1492.1489441358855.JavaMail.mhammett@ThunderFuck> <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> Message-ID: <20170313224348.GA1697@sunf10.rd.bbc.co.uk> On Mon Mar 13, 2017 at 04:52:01PM -0500, Mike Hammett wrote: > Another organization I'm in has a hard policy of no recordings of > any sessions at their conferences. They think that recordings of > content (even vendor-sponsored, vendor-specific sessions with > vendor consent) would have a catastrophic effect on conference > attendance. We record and put on youtube the uknof.org.uk meetings and it still gets bigger every time (around 3x growth since we started streaming). Hard to think anyone still doesn't understand internet. Video or it never happened. brandon From chris at nifry.com Tue Mar 14 07:46:09 2017 From: chris at nifry.com (Chris Russell) Date: Tue, 14 Mar 2017 07:46:09 +0000 Subject: Conference Videos In-Reply-To: <20170313224348.GA1697@sunf10.rd.bbc.co.uk> References: <2076145158.1492.1489441358855.JavaMail.mhammett@ThunderFuck> <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> <20170313224348.GA1697@sunf10.rd.bbc.co.uk> Message-ID: > We record and put on youtube the uknof.org.uk meetings and it still > gets bigger every time (around 3x growth since we started streaming). - and we at UKNOF are grateful for Brandon for doing this... :) In terms of UKNOF, we get complaints when we DON'T webcast content or make video's available on YouTube, overall, people coming to meetings is somewhere between coming to see the content and also to network. The YouTube presence helps us to spread the word of the meeting and be as inclusive as possible, on the other hand, we are entirely sponsor funded and try to avoid a charge for attendance. Chris From chris at nifry.com Tue Mar 14 08:23:07 2017 From: chris at nifry.com (Chris Russell) Date: Tue, 14 Mar 2017 08:23:07 +0000 Subject: Conference Videos In-Reply-To: <7CD15FE2-038E-4B83-A19C-B9D27BDB2CD1@ianai.net> References: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> <7CD15FE2-038E-4B83-A19C-B9D27BDB2CD1@ianai.net> Message-ID: <8446acf52dc1bdfdc2b428ea3f955c56@nifry.com> > Speakers are informed they are going to be recorded. If they have > sensitive information, they can choose a track and ask it not be > recorded. NANOG has done this in the past, but you should talk to the > Program Committee if you are interested in this. We've had this within UKNOF ... sometimes people do not wish to be recorded, mainly due to confidentiality reasons (ie: advance heads up, or personal thoughts delivered to a specific audience). Occasionally we have been asked to remove recordings at a later date due to changing circumstances etc. We explicitly mention the webcast/records on abstract submissions from memory, and also recently introduced shepherding to help presentations be more relevant (both to the speakers to help them in pushing a $clue or message, to our audience to ensure relevance and to us in terms of protection from litigation, etc). This applies to both submitted AND sponsor talks (the latter being incredibly useful and has shown a major increase in sponsor talk relevance and feedback ratings). People will always mention a lack of recording/webcast for this type of content ... but then arguably that is a driver to attend in person. Thanks Chris (UKNOF PC Chair) From edugas at unknowndevice.ca Tue Mar 14 14:03:44 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 14 Mar 2017 14:03:44 +0000 Subject: Regulatory Recovery Surcharge for Canadian corporations Message-ID: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> I recently negotiated a new contract with a tier1 for IP transit in Canada and just got the invoice. I saw a "new" Regulatory Recovery Surcharge of 10% the MRC (before taxes) that I've never seen before. Do any of my Canadian fellows on this list are paying this outrageous surcharge? Other than saying "it's in the MSA", our rep, their tax and billing department are not useful at all. The actual rate is not specified anywhere in the MSA or in the contract. From johnstong at westmancom.com Tue Mar 14 14:41:03 2017 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 14 Mar 2017 14:41:03 +0000 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> Message-ID: <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> We don't explicitly pay a charge like this for the transit bandwidth we purchase in Toronto from an international carrier, and I doubt that it is built into the cost without any mention of it. I've never heard of such a thing. Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas Sent: Tuesday, March 14, 2017 9:04 AM To: NANOG Subject: Regulatory Recovery Surcharge for Canadian corporations I recently negotiated a new contract with a tier1 for IP transit in Canada and just got the invoice. I saw a "new" Regulatory Recovery Surcharge of 10% the MRC (before taxes) that I've never seen before. Do any of my Canadian fellows on this list are paying this outrageous surcharge? Other than saying "it's in the MSA", our rep, their tax and billing department are not useful at all. The actual rate is not specified anywhere in the MSA or in the contract. From edugas at unknowndevice.ca Tue Mar 14 14:59:31 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 14 Mar 2017 14:59:31 +0000 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> Message-ID: >From what I've gathered so far, every other carriers that we use are either invoicing us from Canada or outside the US (e.g. Telia from Vancouver, BC and Cogent from Toronto, ON). A couple of minutes after firing my first email, our rep called me to follow up. He'll escalate this as far as he can with his COO and CFO and suggested two scenarios. On Mar 14 2017, at 10:41 am, Graham Johnston wrote: > We don't explicitly pay a charge like this for the transit bandwidth we purchase in Toronto from an international carrier, and I doubt that it is built into the cost without any mention of it. I've never heard of such a thing. > > Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com > > \-----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas Sent: Tuesday, March 14, 2017 9:04 AM To: NANOG Subject: Regulatory Recovery Surcharge for Canadian corporations > > I recently negotiated a new contract with a tier1 for IP transit in Canada and just got the invoice. I saw a "new" Regulatory Recovery Surcharge of 10% the MRC (before taxes) that I've never seen before. Do any of my Canadian fellows on this list are paying this outrageous surcharge? > > > > Other than saying "it's in the MSA", our rep, their tax and billing department are not useful at all. The actual rate is not specified anywhere in the MSA or in the contract. From tgrand at tgrand.com Tue Mar 14 15:55:58 2017 From: tgrand at tgrand.com (Todd Grand) Date: Tue, 14 Mar 2017 10:55:58 -0500 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> Message-ID: <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> These costs are related to federal, provincial and/or municipal mandates, programs and requirements such as provincial 9-1-1 fees, spectrum acquisition, licensing charges, and contribution charges to help subsidize telephone service in rural and remote areas. These costs are not taxes or amounts that the government requires carriers to collect. The specific amount of these costs can vary as the fees/costs of government mandates/programs change. I would have them outline what regulatory costs they incur, as they have to justify the extension of these costs, or in my opinion it is a form of fraud. Todd Grand -----Original Message----- From: NANOG [mailto:nanog-bounces+tgrand=tgrand.com at nanog.org] On Behalf Of Eric Dugas Sent: Tuesday, March 14, 2017 10:00 AM To: Graham Johnston Cc: NANOG Subject: Re: Regulatory Recovery Surcharge for Canadian corporations >From what I've gathered so far, every other carriers that we use are either invoicing us from Canada or outside the US (e.g. Telia from Vancouver, BC and Cogent from Toronto, ON). A couple of minutes after firing my first email, our rep called me to follow up. He'll escalate this as far as he can with his COO and CFO and suggested two scenarios. On Mar 14 2017, at 10:41 am, Graham Johnston wrote: > We don't explicitly pay a charge like this for the transit bandwidth > we purchase in Toronto from an international carrier, and I doubt that it is built into the cost without any mention of it. I've never heard of such a thing. > > Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com > > \-----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas Sent: Tuesday, March 14, 2017 9:04 AM To: NANOG Subject: Regulatory Recovery Surcharge for Canadian corporations > > I recently negotiated a new contract with a tier1 for IP transit in > Canada and just got the invoice. I saw a "new" Regulatory Recovery Surcharge of 10% the MRC (before taxes) that I've never seen before. Do any of my Canadian fellows on this list are paying this outrageous surcharge? > > > > Other than saying "it's in the MSA", our rep, their tax and billing department are not useful at all. The actual rate is not specified anywhere in the MSA or in the contract. From lguillory at reservetele.com Tue Mar 14 16:07:57 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 14 Mar 2017 16:07:57 +0000 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> , <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> Message-ID: <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com> On transit though? We in the US pay all of these types of fees as well though not on service outside of telephone. Sent from my iPad > Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . On Mar 14, 2017, at 10:58 AM, Todd Grand wrote: > > > These costs are related to federal, provincial and/or municipal mandates, > programs and requirements such as provincial 9-1-1 fees, spectrum > acquisition, licensing charges, and contribution charges to help subsidize > telephone service in rural and remote areas. These costs are not taxes or > amounts that the government requires carriers to collect. The specific > amount of these costs can vary as the fees/costs of government > mandates/programs change. > > I would have them outline what regulatory costs they incur, as they have to > justify the extension of these costs, or in my opinion it is a form of > fraud. > > Todd Grand > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+tgrand=tgrand.com at nanog.org] On Behalf Of > Eric Dugas > Sent: Tuesday, March 14, 2017 10:00 AM > To: Graham Johnston > Cc: NANOG > Subject: Re: Regulatory Recovery Surcharge for Canadian corporations > > From what I've gathered so far, every other carriers that we use are either > invoicing us from Canada or outside the US (e.g. Telia from Vancouver, BC > and Cogent from Toronto, ON). > > > > A couple of minutes after firing my first email, our rep called me to follow > up. He'll escalate this as far as he can with his COO and CFO and suggested > two scenarios. > > > On Mar 14 2017, at 10:41 am, Graham Johnston > wrote: > >> We don't explicitly pay a charge like this for the transit bandwidth >> we > purchase in Toronto from an international carrier, and I doubt that it is > built into the cost without any mention of it. I've never heard of such a > thing. > >> > >> Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > >> > >> \-----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas > Sent: Tuesday, March 14, 2017 9:04 AM > To: NANOG > Subject: Regulatory Recovery Surcharge for Canadian corporations > >> > >> I recently negotiated a new contract with a tier1 for IP transit in >> Canada > and > just got the invoice. I saw a "new" Regulatory Recovery Surcharge of 10% the > MRC (before taxes) that I've never seen before. Do any of my Canadian > fellows on this list are paying this outrageous surcharge? > >> > >> > >> > >> Other than saying "it's in the MSA", our rep, their tax and billing > department > are not useful at all. The actual rate is not specified anywhere in the MSA > or in the contract. > From math at sizone.org Tue Mar 14 16:23:58 2017 From: math at sizone.org (Ken Chase) Date: Tue, 14 Mar 2017 12:23:58 -0400 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com> References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com> Message-ID: <20170314162358.GH19061@sizone.org> We've never seen anything like this on our Canadian transit bills (Cogent, NAC, GTT, Hurricane.) /kc -- Ken Chase - math at sizone.org Guelph Canada From tgrand at tgrand.com Tue Mar 14 16:29:39 2017 From: tgrand at tgrand.com (Todd Grand) Date: Tue, 14 Mar 2017 11:29:39 -0500 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com> References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> , <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com> Message-ID: <7JsW9.92468faf66.001a01d29ce0$36afe470$a40fad50$@tgrand.com> In reply to the group as my reply was only to Luke. This is why I say, they should need to justify the extension of these costs. In my opinion a transit provider should not have any justification to extend said costs. One might suggest that the unjustified extension of these costs could be construed as fraudulent charges. Todd Grand -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Tuesday, March 14, 2017 11:08 AM To: Todd Grand Cc: Eric Dugas ; Graham Johnston ; NANOG Subject: Re: Regulatory Recovery Surcharge for Canadian corporations On transit though? We in the US pay all of these types of fees as well though not on service outside of telephone. Sent from my iPad > Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . On Mar 14, 2017, at 10:58 AM, Todd Grand wrote: > > > These costs are related to federal, provincial and/or municipal > mandates, programs and requirements such as provincial 9-1-1 fees, > spectrum acquisition, licensing charges, and contribution charges to > help subsidize telephone service in rural and remote areas. These > costs are not taxes or amounts that the government requires carriers > to collect. The specific amount of these costs can vary as the > fees/costs of government mandates/programs change. > > I would have them outline what regulatory costs they incur, as they > have to justify the extension of these costs, or in my opinion it is a > form of fraud. > > Todd Grand > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+tgrand=tgrand.com at nanog.org] On > Behalf Of Eric Dugas > Sent: Tuesday, March 14, 2017 10:00 AM > To: Graham Johnston > Cc: NANOG > Subject: Re: Regulatory Recovery Surcharge for Canadian corporations > > From what I've gathered so far, every other carriers that we use are > either invoicing us from Canada or outside the US (e.g. Telia from > Vancouver, BC and Cogent from Toronto, ON). > > > > A couple of minutes after firing my first email, our rep called me to > follow up. He'll escalate this as far as he can with his COO and CFO > and suggested two scenarios. > > > On Mar 14 2017, at 10:41 am, Graham Johnston > > wrote: > >> We don't explicitly pay a charge like this for the transit bandwidth >> we > purchase in Toronto from an international carrier, and I doubt that it > is built into the cost without any mention of it. I've never heard of > such a thing. > >> > >> Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > >> > >> \-----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas > Sent: Tuesday, March 14, 2017 9:04 AM > To: NANOG > Subject: Regulatory Recovery Surcharge for Canadian corporations > >> > >> I recently negotiated a new contract with a tier1 for IP transit in >> Canada > and > just got the invoice. I saw a "new" Regulatory Recovery Surcharge of > 10% the MRC (before taxes) that I've never seen before. Do any of my > Canadian fellows on this list are paying this outrageous surcharge? > >> > >> > >> > >> Other than saying "it's in the MSA", our rep, their tax and billing > department > are not useful at all. The actual rate is not specified anywhere in > the MSA or in the contract. > From lguillory at reservetele.com Tue Mar 14 16:39:20 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 14 Mar 2017 16:39:20 +0000 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: <7JsW9.92468faf66.001a01d29ce0$36afe470$a40fad50$@tgrand.com> References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> , <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com>, <7JsW9.92468faf66.001a01d29ce0$36afe470$a40fad50$@tgrand.com> Message-ID: I just went back over my email string with one of our transit providers since I recalled submitting an exempt form for something. They added the Federal Universal Service Fund Surcharge to our transit link, odd since this isn't a voice related circuit. This also wasn't on the quote or anything else, sales tax is assumed but this wasn't. I'm sure it's buried in an agreement somewhere. Sent from my iPad > On Mar 14, 2017, at 11:30 AM, Todd Grand wrote: > > In reply to the group as my reply was only to Luke. > > > This is why I say, they should need to justify the extension of these costs. > In my opinion a transit provider should not have any justification to extend said costs. > One might suggest that the unjustified extension of these costs could be construed as fraudulent charges. > > Todd Grand > > > -----Original Message----- > From: Luke Guillory [mailto:lguillory at reservetele.com] > Sent: Tuesday, March 14, 2017 11:08 AM > To: Todd Grand > Cc: Eric Dugas ; Graham Johnston ; NANOG > Subject: Re: Regulatory Recovery Surcharge for Canadian corporations > > On transit though? We in the US pay all of these types of fees as well though not on service outside of telephone. > > > > Sent from my iPad > >> > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > >> On Mar 14, 2017, at 10:58 AM, Todd Grand wrote: >> >> >> These costs are related to federal, provincial and/or municipal >> mandates, programs and requirements such as provincial 9-1-1 fees, >> spectrum acquisition, licensing charges, and contribution charges to >> help subsidize telephone service in rural and remote areas. These >> costs are not taxes or amounts that the government requires carriers >> to collect. The specific amount of these costs can vary as the >> fees/costs of government mandates/programs change. >> >> I would have them outline what regulatory costs they incur, as they >> have to justify the extension of these costs, or in my opinion it is a >> form of fraud. >> >> Todd Grand >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+tgrand=tgrand.com at nanog.org] On >> Behalf Of Eric Dugas >> Sent: Tuesday, March 14, 2017 10:00 AM >> To: Graham Johnston >> Cc: NANOG >> Subject: Re: Regulatory Recovery Surcharge for Canadian corporations >> >> From what I've gathered so far, every other carriers that we use are >> either invoicing us from Canada or outside the US (e.g. Telia from >> Vancouver, BC and Cogent from Toronto, ON). >> >> >> >> A couple of minutes after firing my first email, our rep called me to >> follow up. He'll escalate this as far as he can with his COO and CFO >> and suggested two scenarios. >> >> >> On Mar 14 2017, at 10:41 am, Graham Johnston >> >> wrote: >> >>> We don't explicitly pay a charge like this for the transit bandwidth >>> we >> purchase in Toronto from an international carrier, and I doubt that it >> is built into the cost without any mention of it. I've never heard of >> such a thing. >> >>> >> >>> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> >>> >> >>> \-----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas >> Sent: Tuesday, March 14, 2017 9:04 AM >> To: NANOG >> Subject: Regulatory Recovery Surcharge for Canadian corporations >> >>> >> >>> I recently negotiated a new contract with a tier1 for IP transit in >>> Canada >> and >> just got the invoice. I saw a "new" Regulatory Recovery Surcharge of >> 10% the MRC (before taxes) that I've never seen before. Do any of my >> Canadian fellows on this list are paying this outrageous surcharge? >> >>> >> >>> >> >>> >> >>> Other than saying "it's in the MSA", our rep, their tax and billing >> department >> are not useful at all. The actual rate is not specified anywhere in >> the MSA or in the contract. >> > From tgrand at tgrand.com Tue Mar 14 16:53:39 2017 From: tgrand at tgrand.com (Todd Grand) Date: Tue, 14 Mar 2017 11:53:39 -0500 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> , <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com>, <7JsW9.92468faf66.001a01d29ce0$36afe470$a40fad50$@tgrand.com> Message-ID: <7JsW9.724622c6ca.000201d29ce3$8aa1e260$9fe5a720$@tgrand.com> I still believe the onus is on them to justify the extension of these costs, regardless of what was in the agreement. Todd Grand -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Tuesday, March 14, 2017 11:39 AM To: Todd Grand Cc: NANOG Subject: Re: Regulatory Recovery Surcharge for Canadian corporations I just went back over my email string with one of our transit providers since I recalled submitting an exempt form for something. They added the Federal Universal Service Fund Surcharge to our transit link, odd since this isn't a voice related circuit. This also wasn't on the quote or anything else, sales tax is assumed but this wasn't. I'm sure it's buried in an agreement somewhere. Sent from my iPad > On Mar 14, 2017, at 11:30 AM, Todd Grand wrote: > > In reply to the group as my reply was only to Luke. > > > This is why I say, they should need to justify the extension of these costs. > In my opinion a transit provider should not have any justification to extend said costs. > One might suggest that the unjustified extension of these costs could be construed as fraudulent charges. > > Todd Grand > > > -----Original Message----- > From: Luke Guillory [mailto:lguillory at reservetele.com] > Sent: Tuesday, March 14, 2017 11:08 AM > To: Todd Grand > Cc: Eric Dugas ; Graham Johnston > ; NANOG > Subject: Re: Regulatory Recovery Surcharge for Canadian corporations > > On transit though? We in the US pay all of these types of fees as well though not on service outside of telephone. > > > > Sent from my iPad > >> > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ______________________________________________________________________ > ___________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > >> On Mar 14, 2017, at 10:58 AM, Todd Grand wrote: >> >> >> These costs are related to federal, provincial and/or municipal >> mandates, programs and requirements such as provincial 9-1-1 fees, >> spectrum acquisition, licensing charges, and contribution charges to >> help subsidize telephone service in rural and remote areas. These >> costs are not taxes or amounts that the government requires carriers >> to collect. The specific amount of these costs can vary as the >> fees/costs of government mandates/programs change. >> >> I would have them outline what regulatory costs they incur, as they >> have to justify the extension of these costs, or in my opinion it is >> a form of fraud. >> >> Todd Grand >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+tgrand=tgrand.com at nanog.org] On >> Behalf Of Eric Dugas >> Sent: Tuesday, March 14, 2017 10:00 AM >> To: Graham Johnston >> Cc: NANOG >> Subject: Re: Regulatory Recovery Surcharge for Canadian corporations >> >> From what I've gathered so far, every other carriers that we use are >> either invoicing us from Canada or outside the US (e.g. Telia from >> Vancouver, BC and Cogent from Toronto, ON). >> >> >> >> A couple of minutes after firing my first email, our rep called me to >> follow up. He'll escalate this as far as he can with his COO and CFO >> and suggested two scenarios. >> >> >> On Mar 14 2017, at 10:41 am, Graham Johnston >> >> wrote: >> >>> We don't explicitly pay a charge like this for the transit bandwidth >>> we >> purchase in Toronto from an international carrier, and I doubt that >> it is built into the cost without any mention of it. I've never heard >> of such a thing. >> >>> >> >>> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> >>> >> >>> \-----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas >> Sent: Tuesday, March 14, 2017 9:04 AM >> To: NANOG >> Subject: Regulatory Recovery Surcharge for Canadian corporations >> >>> >> >>> I recently negotiated a new contract with a tier1 for IP transit in >>> Canada >> and >> just got the invoice. I saw a "new" Regulatory Recovery Surcharge of >> 10% the MRC (before taxes) that I've never seen before. Do any of my >> Canadian fellows on this list are paying this outrageous surcharge? >> >>> >> >>> >> >>> >> >>> Other than saying "it's in the MSA", our rep, their tax and billing >> department >> are not useful at all. The actual rate is not specified anywhere in >> the MSA or in the contract. >> > From lguillory at reservetele.com Tue Mar 14 16:58:13 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 14 Mar 2017 16:58:13 +0000 Subject: Regulatory Recovery Surcharge for Canadian corporations In-Reply-To: <7JsW9.724622c6ca.000201d29ce3$8aa1e260$9fe5a720$@tgrand.com> References: <4lrpyz6ptzs9buqtoh9g8qiir-2147483647@mailer.nylas.com> <82C0CE81789FE64D8F4D15263191829715C02639@MSG6.westman.int> , <7JsW9.7246a916d2.001101d29cdb$7b7d8440$72788cc0$@tgrand.com> <05D56630-5D13-403B-B5E5-5B480AA69EA5@reservetele.com>, <7JsW9.92468faf66.001a01d29ce0$36afe470$a40fad50$@tgrand.com> , <7JsW9.724622c6ca.000201d29ce3$8aa1e260$9fe5a720$@tgrand.com> Message-ID: <1E78E750-B317-4A70-BC7B-C5BBEAD0C835@reservetele.com> For sure Sent from my iPad > On Mar 14, 2017, at 11:54 AM, Todd Grand wrote: > > I still believe the onus is on them to justify the extension of these costs, > regardless of what was in the agreement. > > Todd Grand > > -----Original Message----- > From: Luke Guillory [mailto:lguillory at reservetele.com] > Sent: Tuesday, March 14, 2017 11:39 AM > To: Todd Grand > Cc: NANOG > Subject: Re: Regulatory Recovery Surcharge for Canadian corporations > > I just went back over my email string with one of our transit providers > since I recalled submitting an exempt form for something. > > They added the Federal Universal Service Fund Surcharge to our transit link, > odd since this isn't a voice related circuit. This also wasn't on the quote > or anything else, sales tax is assumed but this wasn't. I'm sure it's buried > in an agreement somewhere. > > > > > > Sent from my iPad > >> On Mar 14, 2017, at 11:30 AM, Todd Grand wrote: >> >> In reply to the group as my reply was only to Luke. >> >> >> This is why I say, they should need to justify the extension of these > costs. >> In my opinion a transit provider should not have any justification to > extend said costs. >> One might suggest that the unjustified extension of these costs could be > construed as fraudulent charges. >> >> Todd Grand >> >> >> -----Original Message----- >> From: Luke Guillory [mailto:lguillory at reservetele.com] >> Sent: Tuesday, March 14, 2017 11:08 AM >> To: Todd Grand >> Cc: Eric Dugas ; Graham Johnston >> ; NANOG >> Subject: Re: Regulatory Recovery Surcharge for Canadian corporations >> >> On transit though? We in the US pay all of these types of fees as well > though not on service outside of telephone. >> >> >> >> Sent from my iPad >> >>> >> >> Luke Guillory >> Network Operations Manager >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> >> Reserve Telecommunications >> 100 RTC Dr >> Reserve, LA 70084 >> >> ______________________________________________________________________ >> ___________________________ >> >> Disclaimer: >> The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from your > system. E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, arrive late > or incomplete, or contain viruses. Luke Guillory therefore does not accept > liability for any errors or omissions in the contents of this message, which > arise as a result of e-mail transmission. . >> >>> On Mar 14, 2017, at 10:58 AM, Todd Grand wrote: >>> >>> >>> These costs are related to federal, provincial and/or municipal >>> mandates, programs and requirements such as provincial 9-1-1 fees, >>> spectrum acquisition, licensing charges, and contribution charges to >>> help subsidize telephone service in rural and remote areas. These >>> costs are not taxes or amounts that the government requires carriers >>> to collect. The specific amount of these costs can vary as the >>> fees/costs of government mandates/programs change. >>> >>> I would have them outline what regulatory costs they incur, as they >>> have to justify the extension of these costs, or in my opinion it is >>> a form of fraud. >>> >>> Todd Grand >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces+tgrand=tgrand.com at nanog.org] On >>> Behalf Of Eric Dugas >>> Sent: Tuesday, March 14, 2017 10:00 AM >>> To: Graham Johnston >>> Cc: NANOG >>> Subject: Re: Regulatory Recovery Surcharge for Canadian corporations >>> >>> From what I've gathered so far, every other carriers that we use are >>> either invoicing us from Canada or outside the US (e.g. Telia from >>> Vancouver, BC and Cogent from Toronto, ON). >>> >>> >>> >>> A couple of minutes after firing my first email, our rep called me to >>> follow up. He'll escalate this as far as he can with his COO and CFO >>> and suggested two scenarios. >>> >>> >>> On Mar 14 2017, at 10:41 am, Graham Johnston >>> >>> wrote: >>> >>>> We don't explicitly pay a charge like this for the transit bandwidth >>>> we >>> purchase in Toronto from an international carrier, and I doubt that >>> it is built into the cost without any mention of it. I've never heard >>> of such a thing. >>> >>>> >>> >>>> Graham Johnston >>> Network Planner >>> Westman Communications Group >>> 204.717.2829 >>> johnstong at westmancom.com >>> >>>> >>> >>>> \-----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas >>> Sent: Tuesday, March 14, 2017 9:04 AM >>> To: NANOG >>> Subject: Regulatory Recovery Surcharge for Canadian corporations >>> >>>> >>> >>>> I recently negotiated a new contract with a tier1 for IP transit in >>>> Canada >>> and >>> just got the invoice. I saw a "new" Regulatory Recovery Surcharge of >>> 10% the MRC (before taxes) that I've never seen before. Do any of my >>> Canadian fellows on this list are paying this outrageous surcharge? >>> >>>> >>> >>>> >>> >>>> >>> >>>> Other than saying "it's in the MSA", our rep, their tax and billing >>> department >>> are not useful at all. The actual rate is not specified anywhere in >>> the MSA or in the contract. >>> >> > From cdel at firsthand.net Tue Mar 14 17:47:18 2017 From: cdel at firsthand.net (Christian de Larrinaga) Date: Tue, 14 Mar 2017 17:47:18 +0000 Subject: Conference Videos In-Reply-To: <8446acf52dc1bdfdc2b428ea3f955c56@nifry.com> References: <508985852.1533.1489441920414.JavaMail.mhammett@ThunderFuck> <7CD15FE2-038E-4B83-A19C-B9D27BDB2CD1@ianai.net> <8446acf52dc1bdfdc2b428ea3f955c56@nifry.com> Message-ID: <58C82CA6.4090404@firsthand.net> Has there been some assessment of how justified have those seeking the "right to be forgotten" been in becoming forgotten? By doing so does it risk changing the record in a way that is not beneficial to the community and historical record? I warmly second the plaudit and thanks to Brandon for his support of UKNOF. He has played a very substantial part in making UKNOF what it is today. Christian > Chris Russell > 14 March 2017 at 08:23 > > > We've had this within UKNOF ... sometimes people do not wish to be > recorded, mainly due to confidentiality reasons (ie: advance heads up, > or personal thoughts delivered to a specific audience). Occasionally > we have been asked to remove recordings at a later date due to > changing circumstances etc. > > We explicitly mention the webcast/records on abstract submissions > from memory, and also recently introduced shepherding to help > presentations be more relevant (both to the speakers to help them in > pushing a $clue or message, to our audience to ensure relevance and to > us in terms of protection from litigation, etc). This applies to both > submitted AND sponsor talks (the latter being incredibly useful and > has shown a major increase in sponsor talk relevance and feedback > ratings). > > People will always mention a lack of recording/webcast for this type > of content ... but then arguably that is a driver to attend in person. > > Thanks > > Chris > (UKNOF PC Chair) > > > > Patrick W. Gilmore > 13 March 2017 at 22:10 > > > > Speakers are informed they are going to be recorded. If they have > sensitive information, they can choose a track and ask it not be > recorded. NANOG has done this in the past, but you should talk to the > Program Committee if you are interested in this. > > Steve Feldman > 13 March 2017 at 22:06 > > Many attendees also find value in the parts of the conference that > aren't recorded, like hallway conversations, informal meetings, and > even social events. > > Keeping and maintaining the archive of slides and video recordings is > an essential part of NANOG's educational mission, which was key to > obtaining and maintaining the IRS 401(c)(3) nonprofit status. > > So at least for the time I was on the Board, not only were there no > regrets, but we worked hard to maintain and enhance the video experience. > Steve > > > Mike Hammett > 13 March 2017 at 21:52 > Another organization I'm in has a hard policy of no recordings of any > sessions at their conferences. They think that recordings of content > (even vendor-sponsored, vendor-specific sessions with vendor consent) > would have a catastrophic effect on conference attendance. > > NANOG doesn't seem to have that issue. Any background on the process > to get there? Any regrets? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > -- Christian de Larrinaga FBCS, CITP, ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel at firsthand.net ------------------------- From cgrundemann at gmail.com Tue Mar 14 22:35:35 2017 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 14 Mar 2017 18:35:35 -0400 Subject: Multi-CDN Strategies In-Reply-To: <112EB79C-9BF4-4D95-B303-21081472926B@semihuman.com> References: <112EB79C-9BF4-4D95-B303-21081472926B@semihuman.com> Message-ID: On Fri, Mar 10, 2017 at 5:19 PM, Chris Woodfield wrote: > I could keep going, but if so, I might as well stick them into a > powerpoint and submit a talk for Bellevue :) Not a bad idea! Maybe there's a BCOP here..? -- @ChrisGrundemann http://chrisgrundemann.com From theghost101 at gmail.com Wed Mar 15 09:53:49 2017 From: theghost101 at gmail.com (Danijel Starman) Date: Wed, 15 Mar 2017 10:53:49 +0100 Subject: Multi-CDN Strategies In-Reply-To: <112EB79C-9BF4-4D95-B303-21081472926B@semihuman.com> References: <112EB79C-9BF4-4D95-B303-21081472926B@semihuman.com> Message-ID: On Fri, Mar 10, 2017 at 11:19 PM, Chris Woodfield wrote: > I have some experience with this; a few things off the top of my head: > > - It?s usually best to leverage some sort of ?smart? DNS to handle CNAME > distribution, giving you the ability to weight your CNAME distribution vs. > only using one CDN all the time, or prefer different CDNs in various global > regions. I?ve had decent experience with Dyn here, but Route53 has all the > features you?d want as well. If possible, write tooling towards your DNS > provider?s API to automate your failovers. > I've seen people do this in their code too, send approximate percentages of requests to different providers but then you need to do a code push for failover. From stl at wiredrive.com Wed Mar 15 18:00:27 2017 From: stl at wiredrive.com (Scott Larson) Date: Wed, 15 Mar 2017 11:00:27 -0700 Subject: Multi-CDN Strategies In-Reply-To: References: Message-ID: I'll second Cedexis. We use it to spread load across three CDNs plus our origin, it just works. *[image: userimage]Scott Larson[image: los angeles] Lead Systems Administrator[image: wdlogo] [image: linkedin] [image: facebook] [image: twitter] [image: instagram] * On Fri, Mar 10, 2017 at 6:38 PM, Ryan Landry wrote: > Some folks just let Cedexis do the work. > > https://www.cedexis.com/solutions/multi-cdn/ > > On Fri, Mar 10, 2017 at 09:27 Chris Grundemann > wrote: > > > Hail NANOG; > > > > Is anyone here leveraging multiple CDN providers for resiliency and have > > best practices or other advice they'd be willing to share? > > > > Thanks, > > ~Chris > > > > -- > > @ChrisGrundemann > > http://chrisgrundemann.com > > > From horsezip at earthlink.net Wed Mar 15 15:25:36 2017 From: horsezip at earthlink.net (jimmy keffer) Date: Wed, 15 Mar 2017 11:25:36 -0400 Subject: 4or6.con question Message-ID: does anyone know what ports 4or6.com uses for udp traceroute its failing on my windows firewall i opened 33434-33464 udp but no help i goggled but can't find jimmy From asuciu at arista.com Thu Mar 16 13:37:52 2017 From: asuciu at arista.com (Alexandru Suciu) Date: Thu, 16 Mar 2017 13:37:52 +0000 Subject: 4or6.con question In-Reply-To: References: Message-ID: If its a linux box and most likely it is....and depending on the number of hops from 4or6.com to your target machine it is possible that the probes reach you with higher port number the the ones you allowed. For example this is what I get when I trace to google which is 10 hops away. Probes that make it to 8.8.8.8 are 33462 and higher: 13:31:51.822851 IP 8.8.8.8 > 10.83.13.12: ICMP 8.8.8.8 udp port 33462 unreachable, length 68 13:31:51.822914 IP 8.8.8.8 > 10.83.13.12: ICMP 8.8.8.8 udp port 33461 unreachable, length 68 -------- 13:31:51.825698 IP 8.8.8.8 > 10.83.13.12: ICMP 8.8.8.8 udp port 33472 unreachable, length 68 13:31:51.828361 IP 8.8.8.8 > 10.83.13.12: ICMP 8.8.8.8 udp port 33473 unreachable, length 68 13:31:51.828375 IP 8.8.8.8 > 10.83.13.12: ICMP 8.8.8.8 udp port 33474 unreachable, length 68 Try and allow allow ports till 40k for the duration of the test and see if there is any change. Also might be worth to try a ICMP test, get the source IP and then permit all traffic for that IP and check if tht helps. Are you behind NAT? Maybe the probes stop at the router that is doing the NAT. Lastly, does the traceroute make it anywhere near you, like the subnet your public IP is in? Does it fail on the last hop(your machine) or does it fail somewhere in the middle? On Wed, Mar 15, 2017 at 3:25 PM, jimmy keffer wrote: > does anyone know what ports 4or6.com uses for udp traceroute its failing > on my windows firewall i opened 33434-33464 udp but no help i goggled > but can't find > jimmy > -- Software Driven Cloud Networking Alexandru Suciu Technical Solutions Engineer - EMEA e. asuciu at arista.com m. +1 866-476-0000 *www.arista.com* From horsezip at earthlink.net Thu Mar 16 19:20:03 2017 From: horsezip at earthlink.net (jimmy keffer) Date: Thu, 16 Mar 2017 15:20:03 -0400 Subject: 4or6.con question In-Reply-To: References: Message-ID: <7folccl9gr8r7k6nu82g2tdtrd5p1jui43@4ax.com> i finally got to wondows firewall hides some ports even when open calles stealth mode had to fix wirh this page https://docs.storj.io/docs/windows-firewall-with-advanced-security-stealth-mode-applies-to-windows-vista-and-server-2008-and-higher took 4 days find it From mel at beckman.org Thu Mar 16 23:12:36 2017 From: mel at beckman.org (Mel Beckman) Date: Thu, 16 Mar 2017 23:12:36 +0000 Subject: Government agency renting or selling IP space Message-ID: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> I have a government agency client with a number of /24s that they acquired back in the 1990s when they operated as an ISP for other agencies. They are interested in renting or selling these addresses. Are there any existing ARIN or other legal restrictions against government organizations doing this? -mel beckman From bill at herrin.us Thu Mar 16 23:31:01 2017 From: bill at herrin.us (William Herrin) Date: Thu, 16 Mar 2017 19:31:01 -0400 Subject: Government agency renting or selling IP space In-Reply-To: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> Message-ID: On Thu, Mar 16, 2017 at 7:12 PM, Mel Beckman wrote: > I have a government agency client with a number of /24s that they acquired back in the > 1990s when they operated as an ISP for other agencies. They are interested in renting > or selling these addresses. Are there any existing ARIN or other legal restrictions > against government organizations doing this? Hi Mel, The agency may follow the same "specified transfer" process as everyone else to sell the addresses. See ARIN NRPM section 8.5. There's probably a legal mess around a government entity renting IP addresses. If the entity is registered as an end user (instead of as an ISP) then such rentals might also be considered fraudulent. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Fri Mar 17 00:19:20 2017 From: bill at herrin.us (William Herrin) Date: Thu, 16 Mar 2017 20:19:20 -0400 Subject: Government agency renting or selling IP space In-Reply-To: References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> Message-ID: > There's probably a legal mess around a government entity renting IP > addresses. If the entity is registered as an end user (instead of as > an ISP) then such rentals might also be considered fraudulent. On a purely pragmatic level, it's also an exceedingly bad idea to let a private party who may turn out to be a criminal use IP addresses authentically registered to your government agency to commit crimes. As an end-user, you won't be able to SWIP information about the rental, leading angry law enforcement offers to knock upon your door. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From sethm at rollernet.us Fri Mar 17 00:27:57 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 16 Mar 2017 17:27:57 -0700 Subject: Government agency renting or selling IP space In-Reply-To: References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> Message-ID: <6c8db50a-27dc-be1c-72e2-ba9b77c3cea9@rollernet.us> On 3/16/17 17:19, William Herrin wrote: >> There's probably a legal mess around a government entity renting IP >> addresses. If the entity is registered as an end user (instead of as >> an ISP) then such rentals might also be considered fraudulent. > On a purely pragmatic level, it's also an exceedingly bad idea to let > a private party who may turn out to be a criminal use IP addresses > authentically registered to your government agency to commit crimes. > As an end-user, you won't be able to SWIP information about the > rental, leading angry law enforcement offers to knock upon your door. Or they're the perfect set of addresses to use for criminal purposes. ~Seth From mel at beckman.org Fri Mar 17 00:39:03 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 17 Mar 2017 00:39:03 +0000 Subject: Government agency renting or selling IP space In-Reply-To: <6c8db50a-27dc-be1c-72e2-ba9b77c3cea9@rollernet.us> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> , <6c8db50a-27dc-be1c-72e2-ba9b77c3cea9@rollernet.us> Message-ID: <79E9BE47-33F5-43B5-87B5-5ECB322310C0@beckman.org> Bill, Is there a technically a restriction preventing swiping of this IP space when it's being rented? How is that different from an ISP swiping its customers that are renting bandwidth? -mel via cell > On Mar 16, 2017, at 5:28 PM, Seth Mattinen wrote: > > On 3/16/17 17:19, William Herrin wrote: >>> There's probably a legal mess around a government entity renting IP >>> addresses. If the entity is registered as an end user (instead of as >>> an ISP) then such rentals might also be considered fraudulent. >> On a purely pragmatic level, it's also an exceedingly bad idea to let >> a private party who may turn out to be a criminal use IP addresses >> authentically registered to your government agency to commit crimes. >> As an end-user, you won't be able to SWIP information about the >> rental, leading angry law enforcement offers to knock upon your door. > > > Or they're the perfect set of addresses to use for criminal purposes. > > ~Seth From bill at herrin.us Fri Mar 17 00:44:03 2017 From: bill at herrin.us (William Herrin) Date: Thu, 16 Mar 2017 20:44:03 -0400 Subject: Government agency renting or selling IP space In-Reply-To: <79E9BE47-33F5-43B5-87B5-5ECB322310C0@beckman.org> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> <6c8db50a-27dc-be1c-72e2-ba9b77c3cea9@rollernet.us> <79E9BE47-33F5-43B5-87B5-5ECB322310C0@beckman.org> Message-ID: On Thu, Mar 16, 2017 at 8:39 PM, Mel Beckman wrote: > Is there a technically a restriction preventing swiping of this IP space when it's being rented? How is that different from an ISP swiping its customers that are renting bandwidth? Hi Mel, You'd have to ask ARIN to be sure, but I beleive they only accept SWIPs for ISP registrants. Nothing stops the agency from re-registering as an ISP (ARIN will accept you as an ISP if you want to be) but it means new signing new documents (which may be a problem with your legal dept) and possibly paying more money each year. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bob at FiberInternetCenter.com Fri Mar 17 00:50:11 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 16 Mar 2017 17:50:11 -0700 Subject: Government agency renting or selling IP space In-Reply-To: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> Message-ID: <2b438db150a70c9b8eae70cf1c193883.squirrel@66.201.44.180> Simple to check. Most likely legacy space if early 90s. Enter them in the ARIN search box and learn more. And note if the agency is paying arin annually? Possible? Thank You Bob Evans CTO > I have a government agency client with a number of /24s that they acquired > back in the 1990s when they operated as an ISP for other agencies. They > are interested in renting or selling these addresses. Are there any > existing ARIN or other legal restrictions against government organizations > doing this? > > -mel beckman From mysidia at gmail.com Fri Mar 17 01:08:31 2017 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 16 Mar 2017 20:08:31 -0500 Subject: Government agency renting or selling IP space In-Reply-To: <79E9BE47-33F5-43B5-87B5-5ECB322310C0@beckman.org> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> <6c8db50a-27dc-be1c-72e2-ba9b77c3cea9@rollernet.us> <79E9BE47-33F5-43B5-87B5-5ECB322310C0@beckman.org> Message-ID: On Thu, Mar 16, 2017 at 7:39 PM, Mel Beckman wrote: > Bill, > Is there a technically a restriction preventing swiping of this IP space when it's being rented? How is that different from an ISP swiping its customers that are renting bandwidth? This is a difference between an "Allocated" block of addresses to an ISP and an "Assigned" network prefix belonging to a end-user. End-User Orgs typically lack technical ability to create re-assignment records showing a different organization, b/c they have IPs assigned for a specific network.... ISPs / Co-location providers who are ARIN members with Allocated addresses can Re-Allocate to a downstream ISP or Assign a network prefix from allocated space to a downstream End-user organization. An End user can likely show they're an ISP, join ARIN as an ISP member, & request Direct Assignments from ARIN be combined into new Allocations; If the character of the network changes, I would expect the new ISP may have to show information to ARIN establishing that the change to an ISP Allocation will be consistent with the NRPM requirements..... (Seeing as Assignments to End-Users and Allocations to ISPs have different policies for creation described in the NRPM, and there's no mention in the Policy they can be directly converted without a Transfer or Renumber/Consolidate or Return & renumber....) > -mel via cell -- -JH From reuben-nanog at reub.net Fri Mar 17 01:14:41 2017 From: reuben-nanog at reub.net (Reuben Farrelly) Date: Fri, 17 Mar 2017 12:14:41 +1100 Subject: Microsoft Skype for Business Contact - Broken PMTUD Message-ID: Hi, Can someone from Microsoft who manages the network for the Skype for Business please contact me to help resolve what I believe is a problem with the S4B network? I am experiencing PMTUD issues whereby connections with an IPv4 TCP MSS above 1492 and an IPv6 TCP MSS of above 1432 do not function. I can run a clean 1500 byte MTU on both IPv4 and IPv6 from the connection I am testing with. External validation (thus ruling out my own link) from https://wand.net.nz/pmtud/ reports that the following URLs used by Lync/S4B are failing PMTUD: meet.lync.com webdir0b.online.lync.com ---------- tbit from 2001:df0:4:4000::1:115 to 2603:1047:0:a::12 server-mss 1440, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.010] TX SYN 64 seq = 0:0 [ 0.049] RX SYN/ACK 64 seq = 0:1 [ 0.049] TX 60 seq = 1:1 [ 0.049] TX 373 seq = 1:1(313) [ 0.097] RX 1500 seq = 1:314(1440) [ 0.097] RX 1500 seq = 1441:314(1440) [ 0.097] RX 868 seq = 2881:314(808) [ 0.097] TX PTB 1280 mtu = 1280 [ 0.097] TX 60 seq = 314:1 [ 0.399] RX 1500 seq = 1:314(1440) [ 0.399] TX PTB 1280 mtu = 1280 [ 0.994] RX 1500 seq = 1:314(1440) [ 0.994] TX PTB 1280 mtu = 1280 [ 2.197] RX 1500 seq = 1:314(1440) [ 2.197] TX PTB 1280 mtu = 1280 [ 4.603] RX 1500 seq = 1:314(1440) tbit from 130.217.250.115 to 52.113.65.78 server-mss 1460, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 44 seq = 0:0 c5c9 [ 0.152] RX SYN/ACK 44 seq = 0:1 56ef [ 0.152] TX 40 seq = 1:1 c5ca [ 0.153] TX 353 seq = 1:1(313) c5cb DF [ 0.299] RX 808 seq = 2921:314(768) 56f7 DF [ 0.299] RX 1500 seq = 1:314(1460) 56f5 DF [ 0.299] RX 1500 seq = 1461:314(1460) 56f6 DF [ 0.299] TX 40 seq = 314:1 c5cc [ 0.299] TX PTB 56 mtu = 1280 [ 0.763] RX 1500 seq = 1:314(1460) 5720 DF [ 0.764] TX PTB 56 mtu = 1280 [ 1.592] RX 1500 seq = 1:314(1460) 5750 DF [ 1.592] TX PTB 56 mtu = 1280 [ 3.232] RX 1500 seq = 1:314(1460) 57dc DF [ 3.232] TX PTB 56 mtu = 1280 [ 6.514] RX 1500 seq = 1:314(1460) 5910 DF --------- This is in the Asia Pacific region. Thanks, Reuben Farrelly From chkuhtz at microsoft.com Fri Mar 17 01:45:19 2017 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Fri, 17 Mar 2017 01:45:19 +0000 Subject: Microsoft Skype for Business Contact - Broken PMTUD In-Reply-To: References: Message-ID: Hi Reuben, I've responded offline. Thanks, Christian -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Reuben Farrelly via NANOG Sent: Thursday, March 16, 2017 6:15 PM To: nanog at nanog.org Subject: Microsoft Skype for Business Contact - Broken PMTUD Hi, Can someone from Microsoft who manages the network for the Skype for Business please contact me to help resolve what I believe is a problem with the S4B network? I am experiencing PMTUD issues whereby connections with an IPv4 TCP MSS above 1492 and an IPv6 TCP MSS of above 1432 do not function. I can run a clean 1500 byte MTU on both IPv4 and IPv6 from the connection I am testing with. External validation (thus ruling out my own link) from https://wand.net.nz/pmtud/ reports that the following URLs used by Lync/S4B are failing PMTUD: meet.lync.com webdir0b.online.lync.com ---------- tbit from 2001:df0:4:4000::1:115 to 2603:1047:0:a::12 server-mss 1440, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.010] TX SYN 64 seq = 0:0 [ 0.049] RX SYN/ACK 64 seq = 0:1 [ 0.049] TX 60 seq = 1:1 [ 0.049] TX 373 seq = 1:1(313) [ 0.097] RX 1500 seq = 1:314(1440) [ 0.097] RX 1500 seq = 1441:314(1440) [ 0.097] RX 868 seq = 2881:314(808) [ 0.097] TX PTB 1280 mtu = 1280 [ 0.097] TX 60 seq = 314:1 [ 0.399] RX 1500 seq = 1:314(1440) [ 0.399] TX PTB 1280 mtu = 1280 [ 0.994] RX 1500 seq = 1:314(1440) [ 0.994] TX PTB 1280 mtu = 1280 [ 2.197] RX 1500 seq = 1:314(1440) [ 2.197] TX PTB 1280 mtu = 1280 [ 4.603] RX 1500 seq = 1:314(1440) tbit from 130.217.250.115 to 52.113.65.78 server-mss 1460, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 44 seq = 0:0 c5c9 [ 0.152] RX SYN/ACK 44 seq = 0:1 56ef [ 0.152] TX 40 seq = 1:1 c5ca [ 0.153] TX 353 seq = 1:1(313) c5cb DF [ 0.299] RX 808 seq = 2921:314(768) 56f7 DF [ 0.299] RX 1500 seq = 1:314(1460) 56f5 DF [ 0.299] RX 1500 seq = 1461:314(1460) 56f6 DF [ 0.299] TX 40 seq = 314:1 c5cc [ 0.299] TX PTB 56 mtu = 1280 [ 0.763] RX 1500 seq = 1:314(1460) 5720 DF [ 0.764] TX PTB 56 mtu = 1280 [ 1.592] RX 1500 seq = 1:314(1460) 5750 DF [ 1.592] TX PTB 56 mtu = 1280 [ 3.232] RX 1500 seq = 1:314(1460) 57dc DF [ 3.232] TX PTB 56 mtu = 1280 [ 6.514] RX 1500 seq = 1:314(1460) 5910 DF --------- This is in the Asia Pacific region. Thanks, Reuben Farrelly From mel at beckman.org Fri Mar 17 03:13:16 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 17 Mar 2017 03:13:16 +0000 Subject: Government agency renting or selling IP space In-Reply-To: References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> <6c8db50a-27dc-be1c-72e2-ba9b77c3cea9@rollernet.us> <79E9BE47-33F5-43B5-87B5-5ECB322310C0@beckman.org>, Message-ID: This agency already is an ISP - they started out as an ISP for other government agencies. But I'll verify their ARIN records to be sure ARIN sees it that way, since they launched as an ISP back in the 1990s. -mel > On Mar 16, 2017, at 5:44 PM, William Herrin wrote: > >> On Thu, Mar 16, 2017 at 8:39 PM, Mel Beckman wrote: >> Is there a technically a restriction preventing swiping of this IP space when it's being rented? How is that different from an ISP swiping its customers that are renting bandwidth? > > Hi Mel, > > You'd have to ask ARIN to be sure, but I beleive they only accept > SWIPs for ISP registrants. Nothing stops the agency from > re-registering as an ISP (ARIN will accept you as an ISP if you want > to be) but it means new signing new documents (which may be a problem > with your legal dept) and possibly paying more money each year. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From mel at beckman.org Fri Mar 17 03:13:53 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 17 Mar 2017 03:13:53 +0000 Subject: Government agency renting or selling IP space In-Reply-To: <2b438db150a70c9b8eae70cf1c193883.squirrel@66.201.44.180> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org>, <2b438db150a70c9b8eae70cf1c193883.squirrel@66.201.44.180> Message-ID: Their space is legacy, and they don't pay ARIN. They declined the offer to pay ARIN some time ago :) -mel > On Mar 16, 2017, at 5:50 PM, Bob Evans wrote: > > Simple to check. Most likely legacy space if early 90s. Enter them in the > ARIN search box and learn more. And note if the agency is paying arin > annually? Possible? > Thank You > Bob Evans > CTO > > > > >> I have a government agency client with a number of /24s that they acquired >> back in the 1990s when they operated as an ISP for other agencies. They >> are interested in renting or selling these addresses. Are there any >> existing ARIN or other legal restrictions against government organizations >> doing this? >> >> -mel beckman > > From mel at beckman.org Fri Mar 17 03:17:54 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 17 Mar 2017 03:17:54 +0000 Subject: Government agency renting or selling IP space In-Reply-To: References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> <6c8db50a-27dc-be1c-72e2-ba9b77c3cea9@rollernet.us> <79E9BE47-33F5-43B5-87B5-5ECB322310C0@beckman.org>, Message-ID: <90B2AC14-2619-47CC-A872-6DA0B5287E2A@beckman.org> Jimmy, Their ARIN record says Direct Assignment rather than Direct Allocation, so it does appear ARIN considers them an end user. Also, I see no prior SWIPs, so possibly they never SWIPed their previous customers. I'll have to give ARIN a call. -mel > On Mar 16, 2017, at 6:08 PM, Jimmy Hess wrote: > >> On Thu, Mar 16, 2017 at 7:39 PM, Mel Beckman wrote: >> Bill, >> Is there a technically a restriction preventing swiping of this IP space when it's being rented? How is that different from an ISP swiping its customers that are renting bandwidth? > > This is a difference between an "Allocated" block of addresses to an > ISP and an "Assigned" network prefix belonging to a end-user. > > End-User Orgs typically lack technical ability to create re-assignment > records showing a different > organization, b/c they have IPs assigned for a specific network.... > > ISPs / Co-location providers who are ARIN members with Allocated addresses > can Re-Allocate to a downstream ISP or Assign a network prefix from allocated > space to a downstream End-user organization. > > An End user can likely show they're an ISP, join ARIN as an ISP member, & > request Direct Assignments from ARIN be combined into new Allocations; > > If the character of the network changes, I would expect the new ISP > may have to show information to ARIN establishing that the change to > an ISP Allocation will be consistent with the NRPM requirements..... > > (Seeing as Assignments to End-Users and Allocations to ISPs have > different policies for creation described in the NRPM, and there's > no mention in the Policy they can be directly converted without a > Transfer or Renumber/Consolidate or Return & renumber....) > > >> -mel via cell > -- > -JH From bill at herrin.us Fri Mar 17 04:00:46 2017 From: bill at herrin.us (William Herrin) Date: Fri, 17 Mar 2017 00:00:46 -0400 Subject: Government agency renting or selling IP space In-Reply-To: References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> <2b438db150a70c9b8eae70cf1c193883.squirrel@66.201.44.180> Message-ID: On Thu, Mar 16, 2017 at 11:13 PM, Mel Beckman wrote: > Their space is legacy, and they don't pay ARIN. They declined the offer to > pay ARIN some time ago :) > Ah, well good news and bad news. The good news is that they can do whatever they want with their space except make ARIN recognize a transfer. They are under no contractual or legal obligations to ARIN whatsoever. To transfer the block, the buyer will have to jump through all of ARIN's hoops after which your agency can sign an LRSA for the block to be sold just long enough to sell and transfer it (ending the LRSA contract). The bad news is that unless they become an ARIN ISP, pay up and sign contracts agreeing to obey ARIN's ISP rules, the whois information for any rented address blocks will continue to lead right back to them. That will make renting to private organizations challenging. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From jcurran at arin.net Fri Mar 17 04:52:56 2017 From: jcurran at arin.net (John Curran) Date: Fri, 17 Mar 2017 04:52:56 +0000 Subject: Government agency renting or selling IP space In-Reply-To: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> Message-ID: <59DDF12A-0E96-405D-A3C8-D7179C164CF0@arin.net> Mel - US Government agencies should contact GSA (or DoD/DISA, for those in military/intelligence communities) for advice on these matters. Thanks, /John John Curran President and CEO ARIN > On Mar 17, 2017, at 12:12 AM, Mel Beckman wrote: > > I have a government agency client with a number of /24s that they acquired back in the 1990s when they operated as an ISP for other agencies. They are interested in renting or selling these addresses. Are there any existing ARIN or other legal restrictions against government organizations doing this? > > -mel beckman From mel at beckman.org Fri Mar 17 05:07:44 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 17 Mar 2017 05:07:44 +0000 Subject: Government agency renting or selling IP space In-Reply-To: <59DDF12A-0E96-405D-A3C8-D7179C164CF0@arin.net> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org>, <59DDF12A-0E96-405D-A3C8-D7179C164CF0@arin.net> Message-ID: <3F45F4E3-4E92-4EF1-8F48-F5A1ABB20CAA@beckman.org> John, It's a California State government agency. Does that make a difference? -mel > On Mar 16, 2017, at 9:53 PM, John Curran wrote: > > Mel - > > US Government agencies should contact GSA (or DoD/DISA, for those in military/intelligence communities) for advice on these matters. > > Thanks, > /John > > John Curran > President and CEO > ARIN > >> On Mar 17, 2017, at 12:12 AM, Mel Beckman wrote: >> >> I have a government agency client with a number of /24s that they acquired back in the 1990s when they operated as an ISP for other agencies. They are interested in renting or selling these addresses. Are there any existing ARIN or other legal restrictions against government organizations doing this? >> >> -mel beckman From jcurran at arin.net Fri Mar 17 08:50:20 2017 From: jcurran at arin.net (John Curran) Date: Fri, 17 Mar 2017 08:50:20 +0000 Subject: Government agency renting or selling IP space In-Reply-To: <3F45F4E3-4E92-4EF1-8F48-F5A1ABB20CAA@beckman.org> References: <99CBBD03-C3F2-4326-A82C-DFE4D54A38D7@beckman.org> <59DDF12A-0E96-405D-A3C8-D7179C164CF0@arin.net> <3F45F4E3-4E92-4EF1-8F48-F5A1ABB20CAA@beckman.org> Message-ID: <9756A32E-6201-4E40-8D63-CD9AAAF8ECE6@arin.net> On 17 Mar 2017, at 6:07 AM, Mel Beckman wrote: > > John, > > It's a California State government agency. Does that make a difference? Yes - very much so. (US Government has interesting procedures stemming from the US Constitution for handling the release of any rights or interest, but the same does not apply to state governments.) Mr. Herrin?s remarks are correct - normal ARIN transfer procedures apply. Thanks, /John John Curran President and CEO ARIN From rea+nanog at grid.kiae.ru Fri Mar 17 09:03:58 2017 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Fri, 17 Mar 2017 12:03:58 +0300 Subject: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations Message-ID: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> We (at Kurchatov Insitute) still use 144.206.0.0/16, the legacy block, and seeing the breakage rooted at ARIN since this night, {{{ $ dig +trace -t soa 206.144.in-addr.arpa ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 206.144.in-addr.arpa ;; global options: +cmd . 206351 IN NS a.root-servers.net. . 206351 IN NS c.root-servers.net. . 206351 IN NS d.root-servers.net. . 206351 IN NS e.root-servers.net. . 206351 IN NS l.root-servers.net. . 206351 IN NS f.root-servers.net. . 206351 IN NS g.root-servers.net. . 206351 IN NS h.root-servers.net. . 206351 IN NS j.root-servers.net. . 206351 IN NS m.root-servers.net. . 206351 IN NS k.root-servers.net. . 206351 IN NS i.root-servers.net. . 206351 IN NS b.root-servers.net. . 514733 IN RRSIG NS 8 0 518400 20170329170000 20170316160000 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73 in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2 in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20170330000000 20170316230000 33786 arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU= ;; Received 733 bytes from 198.41.0.4#53(a.root-servers.net) in 64 ms 144.in-addr.arpa. 86400 IN NS r.arin.net. 144.in-addr.arpa. 86400 IN NS u.arin.net. 144.in-addr.arpa. 86400 IN NS x.arin.net. 144.in-addr.arpa. 86400 IN NS y.arin.net. 144.in-addr.arpa. 86400 IN NS z.arin.net. 144.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net. 144.in-addr.arpa. 86400 IN DS 62856 5 1 484154736CF9D4DC4F1C2B807BDC06E5B1645AFF 144.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170328085556 20170307105911 4341 in-addr.arpa. X3nPKgjQbRef6BxK3msEXi/IcfpG1rylY2xeWwfNO6fJB5x/QT38ZCA5 XMs6CBeXb59tpQFbgjwZX+prqSpjGFtZ+phFuzsaGmuPOF0FFypMHj7F swykEFvaPY5z4d8mo9FKFJetF2gZfzYthwJWW0x2oo2H2BG0lEedVUCb 1aGs/HE= ;; Received 380 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 48 ms 144.in-addr.arpa. 0 IN SOA z.arin.net. dns-ops.arin.net. 2017022432 1800 900 691200 10800 144.in-addr.arpa. 0 IN RRSIG SOA 5 3 86400 20170331083220 20170317073220 33345 144.in-addr.arpa. k2sZXuQQR3MyyRiB9Wd7fw45yZTbNokjQtFFNY+aCEa/85AnSyuomLlZ jZs4A0bO376/Z1v+bTHoeFqsyHr/xuWHX74r0QC/TCeP0amc+w8RqCvw Yox1TfoJxwhblGNRCgyLw52WszMYyr49EfWPfpHAKFU+G94gdilf3C6x GOM= 144.in-addr.arpa. 10800 IN NSEC 0.144.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY 144.in-addr.arpa. 10800 IN RRSIG NSEC 5 3 10800 20170331083220 20170317073220 33345 144.in-addr.arpa. opvG8SC7+UjHSTtBBtekWNkhLFMIxFxOdejJ7sM7t8lyGNzM6sOABeSI ADXfo8q3p4YFBHgBU5fRCAhBdiQ/AiZC0dLMnHb4WdKEv5bDsBbq5Pt6 vabJaIv7Gizw7kBy1JZ/ZrC4Jmp4EX0HiYA+Ak+aQggD7gdI/6tFDNpl N7M= 205.144.in-addr.arpa. 10800 IN NSEC 207.144.in-addr.arpa. NS RRSIG NSEC 205.144.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20170331083220 20170317073220 33345 144.in-addr.arpa. F1e5mA7C3Mx10YSaNtshzfzfER8pudDOQkUoe+jeDhHeDZeR8FM1FoqW dqrNh5X6JVNlTdWGio6evnSkxnaoJFYyeYJtc+tJ8dTd5APJxJCSOfhH VfRNy7VHs2PdElRo1rRwMw+5Zncc0u8uPdmFDv2ZG8Vv3zj5C6l7rMla 3SA= ;; Received 718 bytes from 199.212.0.63#53(z.arin.net) in 128 ms }}} Seems like the other /16 from 144.in-addr.arpa are affected too (at least). ARIN tickets are engaged, but I am seeking some live person: having the whole reverse zone being unavailable isn't the stuff that is to be handled in 5x8 or alike. If anybody knows what happened, can point me to my errors in assertions or give an e-mail/phone of 24x7-like person or service at ARIN -- will be tremendous. Thanks! -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From bortzmeyer at nic.fr Fri Mar 17 09:53:35 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 17 Mar 2017 10:53:35 +0100 Subject: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> Message-ID: <20170317095335.jlpxnl43iwrzx4fd@nic.fr> On Fri, Mar 17, 2017 at 12:03:58PM +0300, Eygene Ryabinkin wrote a message of 71 lines which said: > Seems like the other /16 from 144.in-addr.arpa are affected too > (at least). Also in 164.in-addr.arpa, it seems? From job at instituut.net Fri Mar 17 09:55:56 2017 From: job at instituut.net (Job Snijders) Date: Fri, 17 Mar 2017 09:55:56 +0000 Subject: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <20170317095335.jlpxnl43iwrzx4fd@nic.fr> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> Message-ID: 171 also seems affected. Job On Fri, 17 Mar 2017 at 10:54, Stephane Bortzmeyer wrote: > On Fri, Mar 17, 2017 at 12:03:58PM +0300, > Eygene Ryabinkin wrote > a message of 71 lines which said: > > > Seems like the other /16 from 144.in-addr.arpa are affected too > > (at least). > > Also in 164.in-addr.arpa, it seems? > From bortzmeyer at nic.fr Fri Mar 17 09:59:03 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 17 Mar 2017 10:59:03 +0100 Subject: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> Message-ID: <20170317095902.ydk523ug5oobo4bk@nic.fr> On Fri, Mar 17, 2017 at 12:03:58PM +0300, Eygene Ryabinkin wrote a message of 71 lines which said: > We (at Kurchatov Insitute) still use 144.206.0.0/16, the legacy > block, and seeing the breakage rooted at ARIN since this night, > {{{ > $ dig +trace -t soa 206.144.in-addr.arpa According to DNSDB, it arrived yesterday, around 1630 UTC. From rea+nanog at grid.kiae.ru Fri Mar 17 10:04:30 2017 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Fri, 17 Mar 2017 13:04:30 +0300 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> Message-ID: <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> Job, good day. Fri, Mar 17, 2017 at 09:55:56AM +0000, Job Snijders wrote: > 171 also seems affected. Not the whole one, it seems: {{{ $ dig +trace -t soa 1.171.in-addr.arpa ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa ;; global options: +cmd . 202634 IN NS m.root-servers.net. . 202634 IN NS i.root-servers.net. . 202634 IN NS k.root-servers.net. . 202634 IN NS c.root-servers.net. . 202634 IN NS a.root-servers.net. . 202634 IN NS d.root-servers.net. . 202634 IN NS l.root-servers.net. . 202634 IN NS e.root-servers.net. . 202634 IN NS g.root-servers.net. . 202634 IN NS b.root-servers.net. . 202634 IN NS j.root-servers.net. . 202634 IN NS h.root-servers.net. . 202634 IN NS f.root-servers.net. . 511016 IN RRSIG NS 8 0 518400 20170329170000 20170316160000 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2 in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73 in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20170330000000 20170316230000 33786 arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU= ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms 171.in-addr.arpa. 86400 IN NS ns1.apnic.net. 171.in-addr.arpa. 86400 IN NS ns2.lacnic.net. 171.in-addr.arpa. 86400 IN NS ns3.apnic.net. 171.in-addr.arpa. 86400 IN NS ns4.apnic.net. 171.in-addr.arpa. 86400 IN NS apnic.authdns.ripe.net. 171.in-addr.arpa. 86400 IN NS apnic1.dnsnode.net. 171.in-addr.arpa. 86400 IN NS tinnie.arin.net. 171.in-addr.arpa. 86400 IN DS 49699 5 1 0240801C96480900CC6D93130AF45CFE86EDE940 171.in-addr.arpa. 86400 IN DS 49699 5 2 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88 171.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170330042932 20170309125911 4341 in-addr.arpa. RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI= ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms 171.in-addr.arpa. 0 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 172800 171.in-addr.arpa. 0 IN RRSIG SOA 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU= 171.in-addr.arpa. 172800 IN NSEC 10.171.in-addr.arpa. NS SOA TXT RRSIG NSEC DNSKEY 171.in-addr.arpa. 172800 IN RRSIG NSEC 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf6Drx551oqOw1gmDIL4y6 +k4= ;; Received 530 bytes from 202.12.31.140#53(ns4.apnic.net) in 347 ms }}} since it is APNIC who respond to queries about it. Any more specific reverse records that are cross ARIN and die there from 171.x.y.z? -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From jcurran at istaff.org Fri Mar 17 11:31:06 2017 From: jcurran at istaff.org (John Curran) Date: Fri, 17 Mar 2017 12:31:06 +0100 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> Message-ID: <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> Eygene - We are aware there?s an issue and working on it presently with RIPE. Expect additional updates shortly. /John John Curran President and CEO ARIN > On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin wrote: > > Job, good day. > > Fri, Mar 17, 2017 at 09:55:56AM +0000, Job Snijders wrote: >> 171 also seems affected. > > Not the whole one, it seems: > {{{ > $ dig +trace -t soa 1.171.in-addr.arpa > > ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa > ;; global options: +cmd > . 202634 IN NS m.root-servers.net. > . 202634 IN NS i.root-servers.net. > . 202634 IN NS k.root-servers.net. > . 202634 IN NS c.root-servers.net. > . 202634 IN NS a.root-servers.net. > . 202634 IN NS d.root-servers.net. > . 202634 IN NS l.root-servers.net. > . 202634 IN NS e.root-servers.net. > . 202634 IN NS g.root-servers.net. > . 202634 IN NS b.root-servers.net. > . 202634 IN NS j.root-servers.net. > . 202634 IN NS h.root-servers.net. > . 202634 IN NS f.root-servers.net. > . 511016 IN RRSIG NS 8 0 518400 20170329170000 20170316160000 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w== > ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms > > in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. > in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2 > in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF > in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73 > in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20170330000000 20170316230000 33786 arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU= > ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms > > 171.in-addr.arpa. 86400 IN NS ns1.apnic.net. > 171.in-addr.arpa. 86400 IN NS ns2.lacnic.net. > 171.in-addr.arpa. 86400 IN NS ns3.apnic.net. > 171.in-addr.arpa. 86400 IN NS ns4.apnic.net. > 171.in-addr.arpa. 86400 IN NS apnic.authdns.ripe.net. > 171.in-addr.arpa. 86400 IN NS apnic1.dnsnode.net. > 171.in-addr.arpa. 86400 IN NS tinnie.arin.net. > 171.in-addr.arpa. 86400 IN DS 49699 5 1 0240801C96480900CC6D93130AF45CFE86EDE940 > 171.in-addr.arpa. 86400 IN DS 49699 5 2 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88 > 171.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170330042932 20170309125911 4341 in-addr.arpa. RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI= > ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms > > 171.in-addr.arpa. 0 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 172800 > 171.in-addr.arpa. 0 IN RRSIG SOA 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU= > 171.in-addr.arpa. 172800 IN NSEC 10.171.in-addr.arpa. NS SOA TXT RRSIG NSEC DNSKEY > 171.in-addr.arpa. 172800 IN RRSIG NSEC 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf6Drx551oqOw1gmDIL4y6 +k4= > ;; Received 530 bytes from 202.12.31.140#53(ns4.apnic.net) in 347 ms > }}} > since it is APNIC who respond to queries about it. Any more specific > reverse records that are cross ARIN and die there from 171.x.y.z? > -- > Eygene Ryabinkin, National Research Centre "Kurchatov Institute" > > Always code as if the guy who ends up maintaining your code will be > a violent psychopath who knows where you live. From alexb at ripe.net Fri Mar 17 11:50:48 2017 From: alexb at ripe.net (Alex Band) Date: Fri, 17 Mar 2017 12:50:48 +0100 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> Message-ID: You can find a detailed announcement from the RIPE NCC here: https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html -Alex Band > On 17 Mar 2017, at 12:31, John Curran wrote: > > Eygene - > > We are aware there?s an issue and working on it presently with RIPE. > Expect additional updates shortly. > > /John > > John Curran > President and CEO > ARIN > >> On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin wrote: >> >> Job, good day. >> >> Fri, Mar 17, 2017 at 09:55:56AM +0000, Job Snijders wrote: >>> 171 also seems affected. >> >> Not the whole one, it seems: >> {{{ >> $ dig +trace -t soa 1.171.in-addr.arpa >> >> ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa >> ;; global options: +cmd >> . 202634 IN NS m.root-servers.net. >> . 202634 IN NS i.root-servers.net. >> . 202634 IN NS k.root-servers.net. >> . 202634 IN NS c.root-servers.net. >> . 202634 IN NS a.root-servers.net. >> . 202634 IN NS d.root-servers.net. >> . 202634 IN NS l.root-servers.net. >> . 202634 IN NS e.root-servers.net. >> . 202634 IN NS g.root-servers.net. >> . 202634 IN NS b.root-servers.net. >> . 202634 IN NS j.root-servers.net. >> . 202634 IN NS h.root-servers.net. >> . 202634 IN NS f.root-servers.net. >> . 511016 IN RRSIG NS 8 0 518400 20170329170000 20170316160000 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w== >> ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms >> >> in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. >> in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2 >> in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF >> in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73 >> in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20170330000000 20170316230000 33786 arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU= >> ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms >> >> 171.in-addr.arpa. 86400 IN NS ns1.apnic.net. >> 171.in-addr.arpa. 86400 IN NS ns2.lacnic.net. >> 171.in-addr.arpa. 86400 IN NS ns3.apnic.net. >> 171.in-addr.arpa. 86400 IN NS ns4.apnic.net. >> 171.in-addr.arpa. 86400 IN NS apnic.authdns.ripe.net. >> 171.in-addr.arpa. 86400 IN NS apnic1.dnsnode.net. >> 171.in-addr.arpa. 86400 IN NS tinnie.arin.net. >> 171.in-addr.arpa. 86400 IN DS 49699 5 1 0240801C96480900CC6D93130AF45CFE86EDE940 >> 171.in-addr.arpa. 86400 IN DS 49699 5 2 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88 >> 171.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170330042932 20170309125911 4341 in-addr.arpa. RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI= >> ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms >> >> 171.in-addr.arpa. 0 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 172800 >> 171.in-addr.arpa. 0 IN RRSIG SOA 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU= >> 171.in-addr.arpa. 172800 IN NSEC 10.171.in-addr.arpa. NS SOA TXT RRSIG NSEC DNSKEY >> 171.in-addr.arpa. 172800 IN RRSIG NSEC 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf6Drx551oqOw1gmDIL4y6 +k4= >> ;; Received 530 bytes from 202.12.31.140#53(ns4.apnic.net) in 347 ms >> }}} >> since it is APNIC who respond to queries about it. Any more specific >> reverse records that are cross ARIN and die there from 171.x.y.z? >> -- >> Eygene Ryabinkin, National Research Centre "Kurchatov Institute" >> >> Always code as if the guy who ends up maintaining your code will be >> a violent psychopath who knows where you live. > > From rea+nanog at grid.kiae.ru Fri Mar 17 12:11:01 2017 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Fri, 17 Mar 2017 15:11:01 +0300 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> Message-ID: <20170317121101.GB2284light.codelabs.ru@light.codelabs.ru> John, Alex, Romeo, Fri, Mar 17, 2017 at 12:31:06PM +0100, John Curran wrote: > We are aware there?s an issue and working on it presently with RIPE. > Expect additional updates shortly. Fri, Mar 17, 2017 at 12:50:48PM +0100, Alex Band wrote: > You can find a detailed announcement from the RIPE NCC here: > https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html Fri, Mar 17, 2017 at 12:52:10PM +0100, Romeo Zwart wrote: > RIPE NCC have issued a statement about the issue here: > > https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html > > Our apologies for the inconvenience caused. Thanks for your work: the issue seem to be fixed. I am trying to verify if everything works as expected, there are some neats, {{{ 206.144.in-addr.arpa. 172800 IN NS ns1.rrcki.ru. 206.144.in-addr.arpa. 172800 IN NS ns.kiae.ru. 206.144.in-addr.arpa. 172800 IN NS ns3.rrcki.ru. 206.144.in-addr.arpa. 172800 IN NS ns2.grid.kiae.ru. 206.144.in-addr.arpa. 172800 IN NS ns.grid.kiae.ru. 206.144.in-addr.arpa. 10800 IN NSEC 207.144.in-addr.arpa. NS RRSIG NSEC 206.144.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20170331110430 20170317100430 33345 144.in-addr.arpa. vbFwaKdRa7Jd70aAbJ 5mC37BsTzMg3nWVI5gqQLLOqSaCZfH0XUez+Uk MbTNvepziCRzH+HgSLabuvRSo4nIUP1SjOd2WX0wySSdb/blqhfmjw3l n8laqOxy/lj8TDiIuxOdw2JhM1v5x/DH4aDnwdGFfUEOdgzCU5k8LdAT oyA= ;; Received 373 bytes from 199.180.180.63#53(r.arin.net) in 198 ms ;; Question section mismatch: got 206.144.0.0.in-addr.arpa/PTR/IN ;; Question section mismatch: got 206.144.0.0.in-addr.arpa/PTR/IN 206.144.in-addr.arpa. 3600 IN SOA ns.kiae.ru. noc.rrcki.ru. 2017020803 10800 3600 1800000 3600 ;; Received 105 bytes from 144.206.239.1#53(ns.grid.kiae.ru) in 0 ms }}} about question mismatch, though my guts feel that this is the local issue at rrcki.ru. Thanks again! And for a nicely-written summary -- too. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From jcurran at arin.net Fri Mar 17 12:35:15 2017 From: jcurran at arin.net (John Curran) Date: Fri, 17 Mar 2017 12:35:15 +0000 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> Message-ID: Folks - RIPE NCC has backed out the change at issue, and we are again processing zonelet files received from them. They?ve posted more details here - FYI, /John John Curran President and CEO ARIN On 17 Mar 2017, at 12:31 PM, John Curran > wrote: Eygene - We are aware there?s an issue and working on it presently with RIPE. Expect additional updates shortly. /John John Curran President and CEO ARIN On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin > wrote: Job, good day. Fri, Mar 17, 2017 at 09:55:56AM +0000, Job Snijders wrote: 171 also seems affected. Not the whole one, it seems: {{{ $ dig +trace -t soa 1.171.in-addr.arpa ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa ;; global options: +cmd . 202634 IN NS m.root-servers.net. . 202634 IN NS i.root-servers.net. . 202634 IN NS k.root-servers.net. . 202634 IN NS c.root-servers.net. . 202634 IN NS a.root-servers.net. . 202634 IN NS d.root-servers.net. . 202634 IN NS l.root-servers.net. . 202634 IN NS e.root-servers.net. . 202634 IN NS g.root-servers.net. . 202634 IN NS b.root-servers.net. . 202634 IN NS j.root-servers.net. . 202634 IN NS h.root-servers.net. . 202634 IN NS f.root-servers.net. . 511016 IN RRSIG NS 8 0 518400 20170329170000 20170316160000 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2 in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73 in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20170330000000 20170316230000 33786 arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU= ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms 171.in-addr.arpa. 86400 IN NS ns1.apnic.net. 171.in-addr.arpa. 86400 IN NS ns2.lacnic.net. 171.in-addr.arpa. 86400 IN NS ns3.apnic.net. 171.in-addr.arpa. 86400 IN NS ns4.apnic.net. 171.in-addr.arpa. 86400 IN NS apnic.authdns.ripe.net. 171.in-addr.arpa. 86400 IN NS apnic1.dnsnode.net. 171.in-addr.arpa. 86400 IN NS tinnie.arin.net. 171.in-addr.arpa. 86400 IN DS 49699 5 1 0240801C96480900CC6D93130AF45CFE86EDE940 171.in-addr.arpa. 86400 IN DS 49699 5 2 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88 171.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170330042932 20170309125911 4341 in-addr.arpa. RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI= ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms 171.in-addr.arpa. 0 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 172800 171.in-addr.arpa. 0 IN RRSIG SOA 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU= 171.in-addr.arpa. 172800 IN NSEC 10.171.in-addr.arpa. NS SOA TXT RRSIG NSEC DNSKEY 171.in-addr.arpa. 172800 IN RRSIG NSEC 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf6Drx551oqOw1gmDIL4y6 +k4= ;; Received 530 bytes from 202.12.31.140#53(ns4.apnic.net) in 347 ms }}} since it is APNIC who respond to queries about it. Any more specific reverse records that are cross ARIN and die there from 171.x.y.z? -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From albertod at cyberneticos.com Fri Mar 17 10:49:10 2017 From: albertod at cyberneticos.com (Alberto Delgado) Date: Fri, 17 Mar 2017 11:49:10 +0100 Subject: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <4d011e801d5d90b4937b6dad2ea5284f@cyberneticos.com> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <4d011e801d5d90b4937b6dad2ea5284f@cyberneticos.com> Message-ID: Me too. We have a 164.138.208.0/22 and we have issues with dns reverse too We sent an email to ripe support, but no answer yet El 2017-03-17 10:53, Stephane Bortzmeyer escribi?: > On Fri, Mar 17, 2017 at 12:03:58PM +0300, > Eygene Ryabinkin wrote > a message of 71 lines which said: > >> Seems like the other /16 from 144.in-addr.arpa are affected too >> (at least). > > Also in 164.in-addr.arpa, it seems? From albertod at cyberneticos.com Fri Mar 17 11:26:39 2017 From: albertod at cyberneticos.com (Alberto Delgado) Date: Fri, 17 Mar 2017 12:26:39 +0100 Subject: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <4d011e801d5d90b4937b6dad2ea5284f@cyberneticos.com> Message-ID: I just receive an answer from RIPE and now its working again: Dear Alberto, Our apologies for this. There was a bug in our DNS provisioning system, and it temporarily caused some delegations (where the parent zone is operated by ARIN) to be removed. The bug has been fixed, and the correct data is now being published on the RIPE NCC FTP server. We expect ARIN's DNS provisioning system to pick it up shortly, and the delegations will be restored. Regards, Anand Buddhdev RIPE NCC El 2017-03-17 11:49, Alberto Delgado escribi?: > Me too. > > We have a 164.138.208.0/22 and we have issues with dns reverse too > > We sent an email to ripe support, but no answer yet > > > El 2017-03-17 10:53, Stephane Bortzmeyer escribi?: >> On Fri, Mar 17, 2017 at 12:03:58PM +0300, >> Eygene Ryabinkin wrote >> a message of 71 lines which said: >> >>> Seems like the other /16 from 144.in-addr.arpa are affected too >>> (at least). >> >> Also in 164.in-addr.arpa, it seems? From rz+nng at zwart.com Fri Mar 17 11:52:10 2017 From: rz+nng at zwart.com (Romeo Zwart) Date: Fri, 17 Mar 2017 12:52:10 +0100 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> Message-ID: <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> Dear all, RIPE NCC have issued a statement about the issue here: https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html Our apologies for the inconvenience caused. Kind regards, Romeo Zwart RIPE NCC On 17/03/17 12:31 , John Curran wrote: > Eygene - > > We are aware there?s an issue and working on it presently with RIPE. > Expect additional updates shortly. > > /John > > John Curran > President and CEO > ARIN > >> On 17 Mar 2017, at 11:04 AM, Eygene Ryabinkin wrote: >> >> Job, good day. >> >> Fri, Mar 17, 2017 at 09:55:56AM +0000, Job Snijders wrote: >>> 171 also seems affected. >> >> Not the whole one, it seems: >> {{{ >> $ dig +trace -t soa 1.171.in-addr.arpa >> >> ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa >> ;; global options: +cmd >> . 202634 IN NS m.root-servers.net. >> . 202634 IN NS i.root-servers.net. >> . 202634 IN NS k.root-servers.net. >> . 202634 IN NS c.root-servers.net. >> . 202634 IN NS a.root-servers.net. >> . 202634 IN NS d.root-servers.net. >> . 202634 IN NS l.root-servers.net. >> . 202634 IN NS e.root-servers.net. >> . 202634 IN NS g.root-servers.net. >> . 202634 IN NS b.root-servers.net. >> . 202634 IN NS j.root-servers.net. >> . 202634 IN NS h.root-servers.net. >> . 202634 IN NS f.root-servers.net. >> . 511016 IN RRSIG NS 8 0 518400 20170329170000 20170316160000 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w== >> ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms >> >> in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. >> in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. >> in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2 >> in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF >> in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73 >> in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20170330000000 20170316230000 33786 arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU= >> ;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms >> >> 171.in-addr.arpa. 86400 IN NS ns1.apnic.net. >> 171.in-addr.arpa. 86400 IN NS ns2.lacnic.net. >> 171.in-addr.arpa. 86400 IN NS ns3.apnic.net. >> 171.in-addr.arpa. 86400 IN NS ns4.apnic.net. >> 171.in-addr.arpa. 86400 IN NS apnic.authdns.ripe.net. >> 171.in-addr.arpa. 86400 IN NS apnic1.dnsnode.net. >> 171.in-addr.arpa. 86400 IN NS tinnie.arin.net. >> 171.in-addr.arpa. 86400 IN DS 49699 5 1 0240801C96480900CC6D93130AF45CFE86EDE940 >> 171.in-addr.arpa. 86400 IN DS 49699 5 2 6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88 >> 171.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170330042932 20170309125911 4341 in-addr.arpa. RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI= >> ;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms >> >> 171.in-addr.arpa. 0 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 172800 >> 171.in-addr.arpa. 0 IN RRSIG SOA 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv 0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU= >> 171.in-addr.arpa. 172800 IN NSEC 10.171.in-addr.arpa. NS SOA TXT RRSIG NSEC DNSKEY >> 171.in-addr.arpa. 172800 IN RRSIG NSEC 5 3 172800 20170416100102 20170317090102 7858 171.in-addr.arpa. QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7 DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf6Drx551oqOw1gmDIL4y6 +k4= >> ;; Received 530 bytes from 202.12.31.140#53(ns4.apnic.net) in 347 ms >> }}} >> since it is APNIC who respond to queries about it. Any more specific >> reverse records that are cross ARIN and die there from 171.x.y.z? >> -- >> Eygene Ryabinkin, National Research Centre "Kurchatov Institute" >> >> Always code as if the guy who ends up maintaining your code will be >> a violent psychopath who knows where you live. > From nanog2011 at yahoo.com Fri Mar 17 12:35:20 2017 From: nanog2011 at yahoo.com (T Kawasaki) Date: Fri, 17 Mar 2017 12:35:20 +0000 (UTC) Subject: any issue with Centurylink yesterday References: <1922222399.2135620.1489754120192.ref@mail.yahoo.com> Message-ID: <1922222399.2135620.1489754120192@mail.yahoo.com> Guys, Is there any issues with centurylink yesterday? Through out day, peering from major iSPs to Centurylink had higher latency yesterday. I looked out now, it seems to settle down for now. Tatsuya From aaron1 at gvtc.com Fri Mar 17 14:58:35 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 17 Mar 2017 09:58:35 -0500 Subject: difference with caching when connected to telia internet Message-ID: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> Regarding, caching services like Netflix OCA and Google GGC, does anyone know if there is something strange that occurs when connected to Telia BGP AS1299 ? .meaning, if I have local Netflix/google caches, and then later I establish a BGP session for Internet with Telia/BGP 1299, would there be something that would make netflix and google caches reachable via Telia look better than my local ones ?! -Aaron From James at arenalgroup.co Fri Mar 17 15:32:52 2017 From: James at arenalgroup.co (James Breeden) Date: Fri, 17 Mar 2017 15:32:52 +0000 Subject: difference with caching when connected to telia internet In-Reply-To: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> Message-ID: Shouldn't be. It could just be that the content on the cache locally is not what the user is requesting. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Friday, March 17, 2017 9:59 AM To: 'NANOG' Subject: difference with caching when connected to telia internet Regarding, caching services like Netflix OCA and Google GGC, does anyone know if there is something strange that occurs when connected to Telia BGP AS1299 ? .meaning, if I have local Netflix/google caches, and then later I establish a BGP session for Internet with Telia/BGP 1299, would there be something that would make netflix and google caches reachable via Telia look better than my local ones ?! -Aaron From scott.pennington at cinbell.com Fri Mar 17 15:02:58 2017 From: scott.pennington at cinbell.com (Pennington, Scott) Date: Fri, 17 Mar 2017 15:02:58 +0000 Subject: any issue with Centurylink yesterday In-Reply-To: <1922222399.2135620.1489754120192@mail.yahoo.com> References: <1922222399.2135620.1489754120192.ref@mail.yahoo.com>, <1922222399.2135620.1489754120192@mail.yahoo.com> Message-ID: There may have been other events, but we were notified of a fiber cut in the Nashville area that impacted a few ckts for us around 6:30PM easter. -Scott ________________________________________ From: NANOG [nanog-bounces at nanog.org] on behalf of T Kawasaki via NANOG [nanog at nanog.org] Sent: Friday, March 17, 2017 8:35 AM To: NANOG Subject: any issue with Centurylink yesterday Guys, Is there any issues with centurylink yesterday? Through out day, peering from major iSPs to Centurylink had higher latency yesterday. I looked out now, it seems to settle down for now. Tatsuya The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. From matlockken at gmail.com Fri Mar 17 15:39:16 2017 From: matlockken at gmail.com (Ken Matlock) Date: Fri, 17 Mar 2017 09:39:16 -0600 Subject: any issue with Centurylink yesterday In-Reply-To: <1922222399.2135620.1489754120192@mail.yahoo.com> References: <1922222399.2135620.1489754120192.ref@mail.yahoo.com> <1922222399.2135620.1489754120192@mail.yahoo.com> Message-ID: I know most of the day yesterday my Centurylink DSL (Denver, CO) I was having.... odd... issues, but only to some sites, and intermittent. I'd have issues getting content from a URL (but pinging the host would be fine, and manual telnet to TCP/443 would work). Latencies were *slightly* higher than normal (36ms to a site vs 18ms normal), but I just chalked it up to 'Centurylink' and figured eventually it'd resolve itself. This morning it all seems well again, so no idea WTF the problem was (honestly I didn't look at it too much, as I was more motivated to go out and enjoy the gorgeous weather instead). Ken On Fri, Mar 17, 2017 at 6:35 AM, T Kawasaki via NANOG wrote: > Guys, > Is there any issues with centurylink yesterday? Through out day, peering > from major iSPs to Centurylink had higher latency yesterday. I looked out > now, it seems to settle down for now. > > Tatsuya > From matlockken at gmail.com Fri Mar 17 15:44:56 2017 From: matlockken at gmail.com (Ken Matlock) Date: Fri, 17 Mar 2017 09:44:56 -0600 Subject: any issue with Centurylink yesterday In-Reply-To: References: <1922222399.2135620.1489754120192.ref@mail.yahoo.com> <1922222399.2135620.1489754120192@mail.yahoo.com> Message-ID: Yeah, not sure that was related, as my issues started earlier in the day (about 8am-9am Mountain time). Either way it all seems fine today, no hiccups, no issues. so whatever it was got resolved. Ken On Fri, Mar 17, 2017 at 9:02 AM, Pennington, Scott < scott.pennington at cinbell.com> wrote: > There may have been other events, but we were notified of a fiber cut in > the Nashville area that impacted a few ckts for us around 6:30PM easter. > > -Scott > ________________________________________ > From: NANOG [nanog-bounces at nanog.org] on behalf of T Kawasaki via NANOG [ > nanog at nanog.org] > Sent: Friday, March 17, 2017 8:35 AM > To: NANOG > Subject: any issue with Centurylink yesterday > > Guys, > Is there any issues with centurylink yesterday? Through out day, peering > from major iSPs to Centurylink had higher latency yesterday. I looked out > now, it seems to settle down for now. > > Tatsuya > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and destroy any copies of this > document. > From aaron1 at gvtc.com Fri Mar 17 16:04:48 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 17 Mar 2017 11:04:48 -0500 Subject: difference with caching when connected to telia internet In-Reply-To: References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> Message-ID: <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> Thanks, but James, you would not believe how rapidly the traffic to my local caches drop off, *and* on the same day I brought up my new Telia internet connection. ...and furthermore, my internet inbound traffic went *through the roof* -Aaron From niels=nanog at bakker.net Fri Mar 17 16:15:27 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 17 Mar 2017 17:15:27 +0100 Subject: difference with caching when connected to telia internet In-Reply-To: <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> Message-ID: <20170317161527.GG86663@excession.tpb.net> * aaron1 at gvtc.com (Aaron Gould) [Fri 17 Mar 2017, 17:05 CET]: >Thanks, but James, you would not believe how rapidly the traffic to >my local caches drop off, *and* on the same day I brought up my new >Telia internet connection. ...and furthermore, my internet inbound >traffic went *through the roof* Did you talk to Netflix and to Google's GGC team to confirm that they were still directing your customer towards your on-net caches? -- Niels. From bill at herrin.us Fri Mar 17 16:15:50 2017 From: bill at herrin.us (William Herrin) Date: Fri, 17 Mar 2017 12:15:50 -0400 Subject: any issue with Centurylink yesterday In-Reply-To: References: <1922222399.2135620.1489754120192.ref@mail.yahoo.com> <1922222399.2135620.1489754120192@mail.yahoo.com> Message-ID: On Fri, Mar 17, 2017 at 11:39 AM, Ken Matlock wrote: > I know most of the day yesterday my Centurylink DSL (Denver, CO) I was > having.... odd... issues, but only to some sites, and intermittent. I'd > have issues getting content from a URL (but pinging the host would be fine, > and manual telnet to TCP/443 would work). Hi Ken, When I hear those symptoms my brain jumps to path MTU discovery. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nanog at ics-il.net Fri Mar 17 16:18:42 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 17 Mar 2017 11:18:42 -0500 (CDT) Subject: difference with caching when connected to telia internet In-Reply-To: <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> Message-ID: <1110425548.3419.1489767521926.JavaMail.mhammett@ThunderFuck> The cache box does need to fill. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Aaron Gould" To: "James Breeden" , "NANOG" Sent: Friday, March 17, 2017 11:04:48 AM Subject: RE: difference with caching when connected to telia internet Thanks, but James, you would not believe how rapidly the traffic to my local caches drop off, *and* on the same day I brought up my new Telia internet connection. ...and furthermore, my internet inbound traffic went *through the roof* -Aaron From bill at herrin.us Fri Mar 17 16:26:03 2017 From: bill at herrin.us (William Herrin) Date: Fri, 17 Mar 2017 12:26:03 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> Message-ID: On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart wrote: > RIPE NCC have issued a statement about the issue here: > > https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html > > Our apologies for the inconvenience caused. Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to corrupted data by zeroing out the data instead of using the last known good data. That's awfully brittle for such a critical service. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From matlockken at gmail.com Fri Mar 17 16:35:33 2017 From: matlockken at gmail.com (Ken Matlock) Date: Fri, 17 Mar 2017 10:35:33 -0600 Subject: any issue with Centurylink yesterday In-Reply-To: References: <1922222399.2135620.1489754120192.ref@mail.yahoo.com> <1922222399.2135620.1489754120192@mail.yahoo.com> Message-ID: Yeah, it sounds like it. ICMP echo/echo reply was working end-to-end, but it's possible they were blocking the Type 4 messages somewhere (I didn't resort to packet captures to get THAT in-depth). Ken On Fri, Mar 17, 2017 at 10:15 AM, William Herrin wrote: > On Fri, Mar 17, 2017 at 11:39 AM, Ken Matlock > wrote: > >> I know most of the day yesterday my Centurylink DSL (Denver, CO) I was >> having.... odd... issues, but only to some sites, and intermittent. I'd >> have issues getting content from a URL (but pinging the host would be >> fine, >> and manual telnet to TCP/443 would work). > > > Hi Ken, > > When I hear those symptoms my brain jumps to path MTU discovery. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From bjorn at mork.no Fri Mar 17 16:42:11 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 17 Mar 2017 17:42:11 +0100 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: (William Herrin's message of "Fri, 17 Mar 2017 12:26:03 -0400") References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> Message-ID: <87var76ejg.fsf@miraculix.mork.no> William Herrin writes: > On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart wrote: >> RIPE NCC have issued a statement about the issue here: >> >> https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html >> >> Our apologies for the inconvenience caused. > > Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to > corrupted data by zeroing out the data instead of using the last known good > data. That's awfully brittle for such a critical service. Well, it was a nice smoke test of the "RDNS required" anti-feature. All of a sudden we couldn't even send email to ourselves, having smarthosts in one of the affected zones. Nice. Maybe time to re-evaluate the usefulness of that config... Bj?rn From jared at puck.Nether.net Fri Mar 17 17:17:56 2017 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 17 Mar 2017 13:17:56 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <87var76ejg.fsf@miraculix.mork.no> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <87var76ejg.fsf@miraculix.mork.no> Message-ID: <20170317171756.GA12269@puck.nether.net> On Fri, Mar 17, 2017 at 05:42:11PM +0100, Bj?rn Mork wrote: > William Herrin writes: > > On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart wrote: > >> RIPE NCC have issued a statement about the issue here: > >> > >> https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html > >> > >> Our apologies for the inconvenience caused. > > > > Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to > > corrupted data by zeroing out the data instead of using the last known good > > data. That's awfully brittle for such a critical service. > > Well, it was a nice smoke test of the "RDNS required" anti-feature. All > of a sudden we couldn't even send email to ourselves, having smarthosts > in one of the affected zones. Nice. > > Maybe time to re-evaluate the usefulness of that config... or proper whitelisting of your own infrastructure :-) - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From valdis.kletnieks at vt.edu Fri Mar 17 17:28:20 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 17 Mar 2017 13:28:20 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <87var76ejg.fsf@miraculix.mork.no> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <87var76ejg.fsf@miraculix.mork.no> Message-ID: <6299.1489771700@turing-police.cc.vt.edu> On Fri, 17 Mar 2017 17:42:11 +0100, Bj?rn Mork said: > Well, it was a nice smoke test of the "RDNS required" anti-feature. All > of a sudden we couldn't even send email to ourselves, having smarthosts > in one of the affected zones. Nice. If you don't have a chaos monkey, the Internet will provide one free of charge. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From george.herbert at gmail.com Fri Mar 17 17:46:25 2017 From: george.herbert at gmail.com (George William Herbert) Date: Fri, 17 Mar 2017 10:46:25 -0700 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <6299.1489771700@turing-police.cc.vt.edu> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <87var76ejg.fsf@miraculix.mork.no> <6299.1489771700@turing-police.cc.vt.edu> Message-ID: > On Mar 17, 2017, at 10:28 AM, valdis.kletnieks at vt.edu wrote: > > On Fri, 17 Mar 2017 17:42:11 +0100, Bj?rn Mork said: >> Well, it was a nice smoke test of the "RDNS required" anti-feature. All >> of a sudden we couldn't even send email to ourselves, having smarthosts >> in one of the affected zones. Nice. > > If you don't have a chaos monkey, the Internet will provide one free of charge. Or to a service partner or underlying infrastructure you rely on. Isn't complexity grand... -george Sent from my iPhone From cscora at apnic.net Fri Mar 17 18:02:45 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Mar 2017 04:02:45 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170317180245.E01F7C44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 18 Mar, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 638006 Prefixes after maximum aggregation (per Origin AS): 249297 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 308468 Total ASes present in the Internet Routing Table: 56540 Prefixes per ASN: 11.28 Origin-only ASes present in the Internet Routing Table: 48937 Origin ASes announcing only one prefix: 21715 Transit ASes present in the Internet Routing Table: 7603 Transit-only ASes present in the Internet Routing Table: 215 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 72 Numnber of instances of unregistered ASNs: 73 Number of 32-bit ASNs allocated by the RIRs: 17731 Number of 32-bit ASNs visible in the Routing Table: 13780 Prefixes from 32-bit ASNs in the Routing Table: 55776 Number of bogon 32-bit ASNs visible in the Routing Table: 46 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 411 Number of addresses announced to Internet: 2837968708 Equivalent to 169 /8s, 39 /16s and 247 /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: 98.5 Total number of prefixes smaller than registry allocations: 211466 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 175063 Total APNIC prefixes after maximum aggregation: 50204 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 174394 Unique aggregates announced from the APNIC address blocks: 71975 APNIC Region origin ASes present in the Internet Routing Table: 7931 APNIC Prefixes per ASN: 21.99 APNIC Region origin ASes announcing only one prefix: 2219 APNIC Region transit ASes present in the Internet Routing Table: 1134 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2770 Number of APNIC addresses announced to Internet: 761082244 Equivalent to 45 /8s, 93 /16s and 49 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 194687 Total ARIN prefixes after maximum aggregation: 93337 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 197063 Unique aggregates announced from the ARIN address blocks: 90389 ARIN Region origin ASes present in the Internet Routing Table: 17842 ARIN Prefixes per ASN: 11.04 ARIN Region origin ASes announcing only one prefix: 6642 ARIN Region transit ASes present in the Internet Routing Table: 1771 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: 1850 Number of ARIN addresses announced to Internet: 1107752352 Equivalent to 66 /8s, 6 /16s and 245 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 171515 Total RIPE prefixes after maximum aggregation: 84327 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 166749 Unique aggregates announced from the RIPE address blocks: 100928 RIPE Region origin ASes present in the Internet Routing Table: 23788 RIPE Prefixes per ASN: 7.01 RIPE Region origin ASes announcing only one prefix: 10974 RIPE Region transit ASes present in the Internet Routing Table: 3370 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5632 Number of RIPE addresses announced to Internet: 710474624 Equivalent to 42 /8s, 88 /16s and 251 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 80095 Total LACNIC prefixes after maximum aggregation: 17673 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 81282 Unique aggregates announced from the LACNIC address blocks: 38006 LACNIC Region origin ASes present in the Internet Routing Table: 5705 LACNIC Prefixes per ASN: 14.25 LACNIC Region origin ASes announcing only one prefix: 1554 LACNIC Region transit ASes present in the Internet Routing Table: 1037 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3228 Number of LACNIC addresses announced to Internet: 170963616 Equivalent to 10 /8s, 48 /16s and 178 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16539 Total AfriNIC prefixes after maximum aggregation: 3694 AfriNIC Deaggregation factor: 4.48 Prefixes being announced from the AfriNIC address blocks: 18107 Unique aggregates announced from the AfriNIC address blocks: 6813 AfriNIC Region origin ASes present in the Internet Routing Table: 1031 AfriNIC Prefixes per ASN: 17.56 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 202 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 300 Number of AfriNIC addresses announced to Internet: 87176448 Equivalent to 5 /8s, 50 /16s and 53 /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 5564 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3761 391 259 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2994 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2751 11134 752 KIXS-AS-KR Korea Telecom, KR 9829 2728 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2297 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2070 421 220 TATACOMM-AS TATA Communications formerl 45899 1897 1320 108 VNPT-AS-VN VNPT Corp, VN 4808 1648 1786 447 CHINA169-BJ China Unicom Beijing Provin 24560 1561 579 256 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3667 2969 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3274 1333 84 SHAW - Shaw Communications Inc., CA 18566 2186 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1977 2079 392 CHARTER-NET-HKY-NC - Charter Communicat 209 1784 5068 643 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1737 3325 558 AMAZON-02 - Amazon.com, Inc., US 30036 1718 319 409 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1689 854 231 ITCDELTA - Earthlink, Inc., US 701 1578 10583 650 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3056 1124 2169 AKAMAI-ASN1 , US 9121 2656 1691 18 TTNET , TR 34984 2010 328 384 TELLCOM-AS , TR 8551 1650 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 13188 1646 99 58 TRIOLAN , UA 12479 1521 1033 50 UNI2-AS , ES 12389 1346 1263 551 ROSTELECOM-AS , RU 9198 1319 352 23 KAZTELECOM-AS , KZ 6849 1265 355 21 UKRTELNET , UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3544 545 160 Telmex Colombia S.A., CO 8151 2491 3375 542 Uninet S.A. de C.V., MX 11830 1817 369 57 Instituto Costarricense de Electricidad 7303 1553 998 249 Telecom Argentina S.A., AR 6503 1541 437 53 Axtel, S.A.B. de C.V., MX 6147 1167 377 27 Telefonica del Peru S.A.A., PE 28573 1066 2290 192 CLARO S.A., BR 3816 1004 479 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 983 280 35 Techtel LMDS Comunicaciones Interactiva 17072 933 118 407 TOTAL PLAY TELECOMUNICACIONES SA DE CV, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1309 399 45 LINKdotNET-AS, EG 36903 718 361 122 MT-MPLS, MA 37611 697 67 6 Afrihost, ZA 36992 598 1375 26 ETISALAT-MISR, EG 24835 497 722 14 RAYA-AS, EG 8452 426 1474 16 TE-AS TE-AS, EG 37492 399 318 73 ORANGE-TN, TN 29571 367 36 10 CITelecom-AS, CI 15399 339 35 7 WANANCHI-KE, KE 2018 271 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5564 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3761 391 259 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3667 2969 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3544 545 160 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3274 1333 84 SHAW - Shaw Communications Inc., CA 20940 3056 1124 2169 AKAMAI-ASN1 , US 17974 2994 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2751 11134 752 KIXS-AS-KR Korea Telecom, KR 9829 2728 1499 540 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3667 3517 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3761 3502 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3544 3384 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3274 3190 SHAW - Shaw Communications Inc., CA 17974 2994 2922 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2656 2638 TTNET , TR 9808 2297 2264 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2728 2188 BSNL-NIB National Internet Backbone, IN 18566 2186 2077 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65534 PRIVATE 36.37.120.0/24 4800 LINTASARTA-AS-AP Network Acces Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.69.225.0/24 18403 FPT-AS-AP The Corporation for Financing & Promo 100.123.218.0/24 18403 FPT-AS-AP The Corporation for Financing & Promo Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.157.128.0/17 393899 -Reserved AS-, ZZ 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM , RU 41.77.248.0/21 203496 AB-TELECOM , RU 41.78.12.0/23 203496 AB-TELECOM , RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM , RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:280 /13:536 /14:1047 /15:1794 /16:13223 /17:7759 /18:13378 /19:24653 /20:38326 /21:41114 /22:75220 /23:62526 /24:356617 /25:554 /26:413 /27:292 /28:35 /29:19 /30:25 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3068 3274 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2843 3667 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2079 2186 MEGAPATH5-US - MegaPath Corporation, US 9121 1872 2656 TTNET , TR 30036 1527 1718 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1461 3544 Telmex Colombia S.A., CO 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1371 1646 TRIOLAN , UA 6983 1326 1689 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1616 2:846 4:25 5:2495 6:34 8:1055 12:1817 13:92 14:1788 15:22 16:2 17:113 18:129 19:1 20:52 23:2142 24:1863 25:2 27:2379 31:1899 32:89 33:5 34:1 35:19 36:380 37:2551 38:1349 39:45 40:100 41:2904 42:461 43:1899 44:63 45:2448 46:2714 47:114 49:1220 50:972 51:18 52:746 54:358 55:6 56:4 57:41 58:1626 59:994 60:387 61:1937 62:1493 63:1922 64:4582 65:2188 66:4543 67:2265 68:1199 69:3334 70:1307 71:577 72:2146 74:2627 75:399 76:423 77:1435 78:1661 79:1316 80:1350 81:1399 82:960 83:727 84:869 85:1750 86:483 87:1147 88:786 89:2059 90:171 91:6160 92:992 93:2373 94:2370 95:2818 96:568 97:359 98:943 99:85 100:155 101:1249 103:14037 104:2801 105:165 106:485 107:1560 108:818 109:2610 110:1299 111:1723 112:1162 113:1329 114:1044 115:1730 116:1773 117:1688 118:2059 119:1615 120:952 121:1093 122:2354 123:2049 124:1530 125:1817 128:709 129:503 130:418 131:1399 132:506 133:190 134:607 135:220 136:517 137:422 138:1839 139:516 140:374 141:519 142:735 143:908 144:765 145:169 146:1036 147:662 148:1374 149:561 150:701 151:945 152:730 153:306 154:760 155:985 156:557 157:618 158:443 159:1434 160:565 161:734 162:2449 163:518 164:790 165:1158 166:388 167:1232 168:2585 169:763 170:2956 171:285 172:971 173:1806 174:802 175:728 176:1762 177:4034 178:2498 179:1120 180:2186 181:1911 182:2221 183:1052 184:835 185:9087 186:3210 187:2198 188:2447 189:1778 190:8100 191:1257 192:9284 193:5791 194:4654 195:3841 196:1965 197:1266 198:5549 199:5867 200:7387 201:4089 202:10221 203:9806 204:4472 205:2753 206:2999 207:3107 208:3904 209:3935 210:3952 211:2113 212:2810 213:2508 214:863 215:65 216:5893 217:2017 218:834 219:620 220:1708 221:908 222:723 223:1153 End of report From bill at herrin.us Fri Mar 17 18:08:01 2017 From: bill at herrin.us (William Herrin) Date: Fri, 17 Mar 2017 14:08:01 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> Message-ID: On Fri, Mar 17, 2017 at 1:42 PM, Mark Kosters wrote: > On 3/17/17, 12:26 PM, "NANOG on behalf of William Herrin" < nanog-bounces at nanog.org on behalf of bill at herrin.us> wrote: >> Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to >> corrupted data by zeroing out the data instead of using the last known good > > there were no bugs in ARIN?s software in regards to this issue. We followed exactly what RIPE told us to do. Hi Mark, That shot my eyebrow up. You misspoke here, right? There's no bug -solely because- you did what the design said to do? The design calls for some self-check information and it's not a critical design bug to zero-out the publish if the self-check fails? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From markk at arin.net Fri Mar 17 17:42:58 2017 From: markk at arin.net (Mark Kosters) Date: Fri, 17 Mar 2017 17:42:58 +0000 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> Message-ID: <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> On 3/17/17, 12:26 PM, "NANOG on behalf of William Herrin" wrote: On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart wrote: > RIPE NCC have issued a statement about the issue here: > > https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html > > Our apologies for the inconvenience caused. Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to corrupted data by zeroing out the data instead of using the last known good data. That's awfully brittle for such a critical service. Regards, Bill Herrin Hi Bill, The analysis was not yet complete when the notice went out from RIPE. After doing a post-mortum, there were no bugs in ARIN?s software in regards to this issue. We followed exactly what RIPE told us to do. When we noticed an issue with RIPE?s updates yesterday, we notified them as well. Two zones managed by APNIC that received delegations from RIPE were also affected by RIPE?s bug ? it was more than just a RIPE/ARIN thing. The three impacted RIR?s have been working closely together to get RIPE?s DNS entries correctly added into our respective authoritative DNS systems. Thanks, Mark ARIN CTO From jcurran at arin.net Fri Mar 17 18:14:45 2017 From: jcurran at arin.net (John Curran) Date: Fri, 17 Mar 2017 18:14:45 +0000 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> Message-ID: <0DA17FD5-A972-4977-A814-24825A41913E@arin.net> On 17 Mar 2017, at 12:26 PM, William Herrin > wrote: On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart > wrote: > RIPE NCC have issued a statement about the issue here: > > https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html > > Our apologies for the inconvenience caused. Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to corrupted data by zeroing out the data instead of using the last known good data. That's awfully brittle for such a critical service. Agreed in principle - receiving incorrect data (improperly formatted, corrupted, or not properly signed) should result in appropriate notice and no change to the running system. This is actually the case with ARIN?s systems. However, we received a properly formatted and signed zonelet file, albeit one which contained zero records. APNIC also received similar correctly formatted/signed zonelet files as a record of the RIPE bug, and the three RIRs have been working closely together to get the correct RIPE data loaded back into our authoritative DNS systems. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Fri Mar 17 18:14:46 2017 From: jcurran at arin.net (John Curran) Date: Fri, 17 Mar 2017 18:14:46 +0000 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> Message-ID: <02301941-2AEF-4EEA-B891-E2513418B2A4@arin.net> On 17 Mar 2017, at 2:08 PM, William Herrin wrote: > > On Fri, Mar 17, 2017 at 1:42 PM, Mark Kosters wrote: >> On 3/17/17, 12:26 PM, "NANOG on behalf of William Herrin" < > nanog-bounces at nanog.org on behalf of bill at herrin.us> wrote: >>> Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to >>> corrupted data by zeroing out the data instead of using the last > known good >> >> there were no bugs in ARIN?s software in regards to this issue. We > followed exactly what RIPE told us to do. > > Hi Mark, > > That shot my eyebrow up. You misspoke here, right? There's no bug -solely > because- you did what the design said to do? The design calls for some > self-check information and it's not a critical design bug to zero-out the > publish if the self-check fails? Bill - See previous reply. The data was both correctly formatted and signed, so the agreed integrity checks passed. Thanks, /John John Curran President and CEO ARIN From bill at herrin.us Fri Mar 17 18:17:01 2017 From: bill at herrin.us (William Herrin) Date: Fri, 17 Mar 2017 14:17:01 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <02301941-2AEF-4EEA-B891-E2513418B2A4@arin.net> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <02301941-2AEF-4EEA-B891-E2513418B2A4@arin.net> Message-ID: On Fri, Mar 17, 2017 at 2:14 PM, John Curran wrote: > See previous reply. The data was both correctly formatted and signed, > so the agreed integrity checks passed. > Ah, okay. So it wasn't bad counts as originally reported but no data with counts that confirmed no data. Thanks for the clarification! Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From denys at visp.net.lb Fri Mar 17 18:26:47 2017 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 17 Mar 2017 20:26:47 +0200 Subject: difference with caching when connected to telia internet In-Reply-To: <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> Message-ID: <7d0fcfa4aa0aa9711a62a2908677ccf9@visp.net.lb> On 2017-03-17 18:04, Aaron Gould wrote: > Thanks, but James, you would not believe how rapidly the traffic to my > local > caches drop off, *and* on the same day I brought up my new Telia > internet > connection. ...and furthermore, my internet inbound traffic went > *through > the roof* > > -Aaron Most probably they silently readvertise BGP announces of customers to their caches. Maybe just announce less specific prefixes to Telia, and more specific to caches? Also at least GGC has BGP communities for priorities. From jcurran at arin.net Fri Mar 17 18:31:56 2017 From: jcurran at arin.net (John Curran) Date: Fri, 17 Mar 2017 18:31:56 +0000 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <02301941-2AEF-4EEA-B891-E2513418B2A4@arin.net> Message-ID: On 17 Mar 2017, at 2:17 PM, William Herrin wrote: > > On Fri, Mar 17, 2017 at 2:14 PM, John Curran wrote: > >> See previous reply. The data was both correctly formatted and signed, >> so the agreed integrity checks passed. >> > > Ah, okay. So it wasn't bad counts as originally reported but no data with > counts that confirmed no data. Thanks for the clarification! Bill - Glad to help (and apologies for the information coming out in pieces ? we?ve opted to go with updates as we learn more rather than some for comprehensive but less timely report.) Thanks! /John John Curran President and CEO ARIN From aaron1 at gvtc.com Fri Mar 17 19:24:55 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 17 Mar 2017 14:24:55 -0500 Subject: difference with caching when connected to telia internet In-Reply-To: <20170317161527.GG86663@excession.tpb.net> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> <20170317161527.GG86663@excession.tpb.net> Message-ID: <006201d29f54$28ed3830$7ac7a890$@gvtc.com> Yes I did... Netflix said, they are rcv'ing same prefixes with lower cost in DFW !! I have no idea why. Netflix told me to advertise shorter prefixes to my local cluster... I'm doing it now. And strangely now the Netflix guy lost control plane to one of my (2) nodes. Someone is running out to put hands on it Ggc said, they are rcv'ing more specific routes at other locations! I have no idea why this suddenly happened. Then suddenly BOTH of my ggc node cluster bgp sessions are bouncing ! I don't touch these caches, hardly ever... suddenly all this :| -Aaron From aaron1 at gvtc.com Fri Mar 17 19:27:51 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 17 Mar 2017 14:27:51 -0500 Subject: difference with caching when connected to telia internet In-Reply-To: <7d0fcfa4aa0aa9711a62a2908677ccf9@visp.net.lb> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> <7d0fcfa4aa0aa9711a62a2908677ccf9@visp.net.lb> Message-ID: <006401d29f54$927fbd40$b77f37c0$@gvtc.com> Dang why would they "silently" do that !? wouldn't that shot holes in my caching purpose , also I just got off the phone with a Telia net eng in D.C. , he said he doesn't know anything about why this is happening. Thanks, I'm advertising more specific prefixes to local Netflix now... but as I said in another email post.. suddenly one nf cache isn't reachable to the nf engineer... and both ggc nodes bgp sessions are bouncing. :| - Aaron From bill at herrin.us Fri Mar 17 19:41:53 2017 From: bill at herrin.us (William Herrin) Date: Fri, 17 Mar 2017 15:41:53 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <02301941-2AEF-4EEA-B891-E2513418B2A4@arin.net> Message-ID: On Fri, Mar 17, 2017 at 2:31 PM, John Curran wrote: > Glad to help (and apologies for the information coming out in pieces ? > we?ve opted to go with updates as we learn more rather than some for > comprehensive but less timely report.) > Also very much appreciated. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From aaron1 at gvtc.com Sat Mar 18 05:05:40 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Sat, 18 Mar 2017 00:05:40 -0500 Subject: difference with caching when connected to telia internet In-Reply-To: <006401d29f54$927fbd40$b77f37c0$@gvtc.com> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> <7d0fcfa4aa0aa9711a62a2908677ccf9@visp.net.lb> <006401d29f54$927fbd40$b77f37c0$@gvtc.com> Message-ID: <006801d29fa5$4a6578f0$df306ad0$@gvtc.com> Thank you all for your advice and input. I wanted to circle back with you all on this. Turns out it was my fault. Doesn't seem that this was a Telia problem at all. What happened was, when I turned up my new 10 gig Telia Internet connection a few days ago, I needed to balance out my (4) 10 gig internet connections so I chopped up a /17 into (4) /19's. When I did this, I was still advertising the /17 to my local caches, but I was advertising the (4) /19's , one on each of my (4) 10 gig internet connections. So the caches out on the public internet were learning more specific prefixes (longer masks) then my local caches were learning... so the caches on the internet were being used instead of my local caches. Once google and Netflix tech support helped to make me aware of this, I correctly sent the additional (4) /19's to my caches and now all is well. - Aaron From tore at fud.no Sat Mar 18 11:09:05 2017 From: tore at fud.no (Tore Anderson) Date: Sat, 18 Mar 2017 12:09:05 +0100 Subject: difference with caching when connected to telia internet In-Reply-To: <006801d29fa5$4a6578f0$df306ad0$@gvtc.com> References: <004701d29f2e$f426ef30$dc74cd90$@gvtc.com> <005501d29f38$33f86ef0$9be94cd0$@gvtc.com> <7d0fcfa4aa0aa9711a62a2908677ccf9@visp.net.lb> <006401d29f54$927fbd40$b77f37c0$@gvtc.com> <006801d29fa5$4a6578f0$df306ad0$@gvtc.com> Message-ID: <20170318120905.2eb5b42d@envy.e1.y.home> Hi Aaron, > What happened was, when I turned up my new 10 gig Telia Internet > connection a few days ago, I needed to balance out my (4) 10 gig > internet connections so I chopped up a /17 into (4) /19's. When I > did this, I was still advertising the /17 to my local caches, but I > was advertising the (4) /19's , one on each of my (4) 10 gig internet > connections. So the caches out on the public internet were learning > more specific prefixes (longer masks) then my local caches were > learning... so the caches on the internet were being used instead of > my local caches. Once google and Netflix tech support helped to make > me aware of this, I correctly sent the additional (4) /19's to my > caches and now all is well. Please instead advertise the /17 on all your Telia uplinks. You should *additionally* advertise the four /19s to the different links, but make sure to tag them with the NO_EXPORT community so they don't propagate outside Telia. That way you get the traffic engineering you want (i.e., load balancing of ingress traffic from Telia), while at the same time avoiding coming across as a self-serving jerk to everyone else on the Internet by not polluting their routing tables/FIBs with four entirely superfluous /19s. Tore From dougb at dougbarton.us Sun Mar 19 01:58:52 2017 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 18 Mar 2017 18:58:52 -0700 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> Message-ID: <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> On 03/17/2017 10:42 AM, Mark Kosters wrote: > On 3/17/17, 12:26 PM, "NANOG on behalf of William Herrin" > wrote: > > On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart > wrote: >> RIPE NCC have issued a statement about the issue here: >> >> https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html > >> > >> Our apologies for the inconvenience caused. > > Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to > corrupted data by zeroing out the data instead of using the last > known good data. That's awfully brittle for such a critical service. > > Regards, Bill Herrin > > > Hi Bill, > > The analysis was not yet complete when the notice went out from RIPE. > After doing a post-mortum, there were no bugs in ARIN?s software in > regards to this issue. We followed exactly what RIPE told us to do. > When we noticed an issue with RIPE?s updates yesterday, we notified > them as well. My eyebrows reacted to this the same way Bill's did. It sounds like this is at least a semi-automated system. Such things should have sanity checks on the receiving side when told to remove large gobs of data, even if the instructions validate correctly. More fundamentally, according to the RIPE report they are sending you something called "zonelets" which you then process into actual DNS data. Can you say something about the relative merit of this system, vs. simply delegating the right zones to the right parties and letting the DNS do what it was intended to do? At minimum the fact that this automated system was allowed to wipe out great chunks of important data calls it into question. And sure, you can all 3 fix the bugs you found this time around, but up until these bugs were triggered you all thought the system was functioning perfectly, in spite of it ending up doing something that obviously was not intended. Doug From jcurran at istaff.org Sun Mar 19 03:58:06 2017 From: jcurran at istaff.org (John Curran) Date: Sat, 18 Mar 2017 23:58:06 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> Message-ID: <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> On 18 Mar 2017, at 9:58 PM, Doug Barton wrote: > > My eyebrows reacted to this the same way Bill's did. It sounds like this is at least a semi-automated system. Such things should have sanity checks on the receiving side when told to remove large gobs of data, even if the instructions validate correctly. > > More fundamentally, according to the RIPE report they are sending you something called "zonelets" which you then process into actual DNS data. Can you say something about the relative merit of this system, vs. simply delegating the right zones to the right parties and letting the DNS do what it was intended to do? > > At minimum the fact that this automated system was allowed to wipe out great chunks of important data calls it into question. And sure, you can all 3 fix the bugs you found this time around, but up until these bugs were triggered you all thought the system was functioning perfectly, in spite of it ending up doing something that obviously was not intended. Doug - We could indeed decide to ignore correctly formatted and signed information if it doesn?t match some heuristics that we put in place (e.g. empty zone, zone with only 1 entry, zone that changes more than 10% in size, etc.) Some downsides with this approach is that that: 1) we?d be establishing heuristics for data that originates with a different organization and absent knowledge of their business changes, and 2) this would be mean that there could be occasions where proper data cannot be installed without manual intervention (because the changes happens to be outside of whatever heuristics have previously been put in place.) Despite the associated risk, we are happy to install such checks if RIPE requests them, but are this time are processing them as we agreed to do so ? which is whenever we receive correctly formatted and properly signed requests from them. (You should inquire to RIPE for more detail regarding their future intentions in this regard.) As to why DNS-native zone operations are not utilized, the challenge is that reverse DNS zones for IPv4 and DNS operations are on octet boundaries, but IPv4 address blocks may be aligned on any bit boundary. Thus, a single IPv4 octet range may contain IPv4 address blocks that are administered by multiple RIRs, making it is necessary for one RIR to be authoritative for the entire zone and other RIRs to send information seperately on their IPv4 address blocks in that same range so that it gets included in the appropriate zone file. Excellent questions - thanks! /John John Curran President and CEO ARIN From dougb at dougbarton.us Sun Mar 19 04:27:11 2017 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 18 Mar 2017 21:27:11 -0700 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> Message-ID: <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> Thanks for the response, John. Some thoughts below. On 03/18/2017 08:58 PM, John Curran wrote: > On 18 Mar 2017, at 9:58 PM, Doug Barton > wrote: >> >> My eyebrows reacted to this the same way Bill's did. It sounds >> like this is at least a semi-automated system. Such things should >> have sanity checks on the receiving side when told to remove large >> gobs of data, even if the instructions validate correctly. >> >> More fundamentally, according to the RIPE report they are sending >> you something called "zonelets" which you then process into actual >> DNS data. Can you say something about the relative merit of this >> system, vs. simply delegating the right zones to the right parties >> and letting the DNS do what it was intended to do? >> >> At minimum the fact that this automated system was allowed to wipe >> out great chunks of important data calls it into question. And >> sure, you can all 3 fix the bugs you found this time around, but up >> until these bugs were triggered you all thought the system was >> functioning perfectly, in spite of it ending up doing something >> that obviously was not intended. > > Doug - > > We could indeed decide to ignore correctly formatted and signed > information if it doesn?t match some heuristics that we put in place > (e.g. empty zone, zone with only 1 entry, zone that changes more than > 10% in size, etc.) I have used the latter type of system with good results, for what it's worth. And funny you should mention 10%, as that's what I've found to be fairly commonly at least a yellow flag, if not a big red one. > Some downsides with this approach is that that: 1) we?d be > establishing heuristics for data that originates with a different > organization and absent knowledge of their business changes, If you're not already having ongoing discussions about said changes well in advance, your system is broken. > and 2) > this would be mean that there could be occasions where proper data > cannot be installed without manual intervention (because the changes > happens to be outside of whatever heuristics have previously been > put in place.) See above. Also, not putting in place *new* changes on a scale sufficient to trip the heuristics is far superior to automatically putting in place changes that take huge chunks of address space off the network. Or am I missing something? And if you're having regular conversations with your "customers" in this scenario about upcoming major changes, tripping the alarm should only happen if someone, somewhere, made a mistake. Thus, human intervention is required regardless. But, see below. > Despite the associated risk, we are happy to install such checks if > RIPE requests them, but are this time are processing them as we > agreed to do so ? which is whenever we receive correctly formatted > and properly signed requests from them. (You should inquire to RIPE > for more detail regarding their future intentions in this regard.) Already did, thanks. :) Meanwhile, one could make a legitimate argument that even absent specific guidance from RIPE, ARIN should have a sufficient level of concern for the health of the larger Internet to consider unilateral action here. At least in the form of delaying implementation until some human coordination takes place. Personally, I don't buy, "They told us to do it!" as a legitimate response here. > As to why DNS-native zone operations are not utilized, the challenge > is that reverse DNS zones for IPv4 and DNS operations are on octet > boundaries, but IPv4 address blocks may be aligned on any bit > boundary. Yes, deeply familiar with that problem. Are you dealing with any address blocks smaller than a /24? If the answer is no (which it almost certainly is), what challenges are you facing that you haven't figured out how to overcome yet? (Even < /24 blocks can be dealt with, obviously, but I'd be interested to learn that there are problems with /24 and up that are too difficult to solve.) Personally, I would be happy to donate my time to help y'all sort this out, and I'm sure there are others who would also be willing to help. Doug From jcurran at istaff.org Sun Mar 19 04:40:13 2017 From: jcurran at istaff.org (John Curran) Date: Sun, 19 Mar 2017 00:40:13 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> Message-ID: <183BCDD2-C800-497D-B466-2DC34AF8E197@istaff.org> On 19 Mar 2017, at 12:27 AM, Doug Barton wrote: > ... >> Despite the associated risk, we are happy to install such checks if >> RIPE requests them, but are this time are processing them as we >> agreed to do so ? which is whenever we receive correctly formatted >> and properly signed requests from them. (You should inquire to RIPE >> for more detail regarding their future intentions in this regard.) > > Already did, thanks. :) Meanwhile, one could make a legitimate argument that even absent specific guidance from RIPE, ARIN should have a sufficient level of concern for the health of the larger Internet to consider unilateral action here. At least in the form of delaying implementation until some human coordination takes place. We?ll process RIPE?s requests in whatever manner they direct, as it is their customers that are affected by whatever decision they make in this regard. Thanks! /John John Curran President and CEO ARIN From dougb at dougbarton.us Sun Mar 19 04:50:45 2017 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 18 Mar 2017 21:50:45 -0700 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <183BCDD2-C800-497D-B466-2DC34AF8E197@istaff.org> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> <183BCDD2-C800-497D-B466-2DC34AF8E197@istaff.org> Message-ID: On 03/18/2017 09:40 PM, John Curran wrote: > On 19 Mar 2017, at 12:27 AM, Doug Barton wrote: >> ... >>> Despite the associated risk, we are happy to install such checks if >>> RIPE requests them, but are this time are processing them as we >>> agreed to do so ? which is whenever we receive correctly formatted >>> and properly signed requests from them. (You should inquire to RIPE >>> for more detail regarding their future intentions in this regard.) >> >> Already did, thanks. :) Meanwhile, one could make a legitimate argument that even absent specific guidance from RIPE, ARIN should have a sufficient level of concern for the health of the larger Internet to consider unilateral action here. At least in the form of delaying implementation until some human coordination takes place. > > We?ll process RIPE?s requests in whatever manner they direct, as it is their > customers that are affected by whatever decision they make in this regard. I'll let others chime in on whether they they think that's a reasonable response. I've already said my piece. Meanwhile, my offer to help y'all fix your DNS was a sincere one. Feel free to hit me up off list. Doug From jcurran at arin.net Sun Mar 19 05:53:02 2017 From: jcurran at arin.net (John Curran) Date: Sun, 19 Mar 2017 05:53:02 +0000 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> <183BCDD2-C800-497D-B466-2DC34AF8E197@istaff.org> Message-ID: <5D523390-55FF-4A3E-9887-2E8D444E9D11@arin.net> On 19 Mar 2017, at 12:50 AM, Doug Barton > wrote: ... Meanwhile, my offer to help y'all fix your DNS was a sincere one. Feel free to hit me up off list. Doug - You?d want to make that offer to the RIPE NCC (as they experienced the issues with their DNS systems.) Let me know if you need contact info. Thanks, /John John Curran President and CEO ARIN From dougb at dougbarton.us Sun Mar 19 19:28:59 2017 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 19 Mar 2017 12:28:59 -0700 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <5D523390-55FF-4A3E-9887-2E8D444E9D11@arin.net> References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> <183BCDD2-C800-497D-B466-2DC34AF8E197@istaff.org> <5D523390-55FF-4A3E-9887-2E8D444E9D11@arin.net> Message-ID: <9ab8f60a-ab63-9f17-07e2-0ef9cf32025a@dougbarton.us> On 03/18/2017 10:53 PM, John Curran wrote: > On 19 Mar 2017, at 12:50 AM, Doug Barton > wrote: >> ... >> Meanwhile, my offer to help y'all fix your DNS was a sincere one. Feel >> free to hit me up off list. > > Doug - > > You?d want to make that offer to the RIPE NCC My offer was in response to your assertion that normal DNS techniques of delegation were not sufficient to the unique problems ARIN has to deal with in regards to the address space you manage delegations for. Subsequent to our conversation however, Shane Kerr was kind enough to explain the problem that the "zonelets" are designed to solve: https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003406.html Short version, ARIN maintains foo/8, but bar/16 within it is managed by RIPE, who wants to delegate it directly to the registered party for that block. They use a zonelet to tell ARIN how to do that. As you have indicated that ARIN will not make any changes to its existing practices without specific instructions from RIPE, I will offer my suggestions to them instead. :) best, Doug From valdis.kletnieks at vt.edu Sun Mar 19 23:16:11 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 19 Mar 2017 19:16:11 -0400 Subject: IPv6 oddness in Comcast land... Message-ID: <142420.1489965371@turing-police.cc.vt.edu> Trying to figure out what the heck is going on here. Any good explanations cheerfully accepted. Background: Home internet router is a Linksys WRT1200AC that had been running OpenWRT 15.05.01. IPv6 worked just fine - Comcast handed me a /60 via DHCP-PD and no issues. I reflashed it to Lede 17.01, and after doing all the reconfig, I'm hitting a really strange IPv6 issue. Symptoms - IPv6 still configures correctly, but IPv6 packets appear to go out and disappear into the ether when they leave the Linksys. Doing a traceroute to any IPv6 destination makes things work again - for a while (from 15 minutes to an hour or two). As seen from my laptop (I have the matching tcpdump from the outbound interface on the Linksys): [~] ping -6 -c 3 listserv.vt.edu PING listserv.vt.edu(listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769)) 56 data bytes --- listserv.vt.edu ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2070ms [~] traceroute -6 listserv.vt.edu traceroute to listserv.vt.edu (2001:468:c80:2105:211:43ff:feda:d769), 30 hops max, 80 byte packets 1 2601:5c0:c001:69e2::1 (2601:5c0:c001:69e2::1) 2.417 ms 3.077 ms 5.358 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * hu-0-10-0-7-pe04.ashburn.va.ibone.comcast.net (2001:558:0:f5c1::2) 31.478 ms 31.975 ms 7 2001:559::d16 (2001:559::d16) 32.406 ms 17.102 ms 24.751 ms 8 2001:550:2:2f::a (2001:550:2:2f::a) 23.245 ms 23.519 ms 22.185 ms 9 2607:b400:f0:2003::f0 (2607:b400:f0:2003::f0) 29.782 ms 28.604 ms 29.891 ms 10 2607:b400:90:ff05::f1 (2607:b400:90:ff05::f1) 30.423 ms * 30.680 ms 11 * * * 12 listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769) 34.562 ms 39.072 ms 24.633 ms [~] ping -6 -c 3 listserv.vt.edu PING listserv.vt.edu(listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769)) 56 data bytes 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): icmp_seq=1 ttl=53 time=33.3 ms 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): icmp_seq=2 ttl=53 time=24.3 ms 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): icmp_seq=3 ttl=53 time=46.0 ms --- listserv.vt.edu ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 24.334/34.595/46.093/8.927 ms So it looks like something times out somewhere and fails to pass packets back. TCP connections don't keep IPv6 alive. I have a browser window that auto-updates every 5 minutes, and a SmokePing process on a Raspberri Pi uploads to a server at work every few minutes, and those eventually drop back to IPv4 when the IPv6 TCP fails to connect. And normal UDP doesn't seem to keep it alive - NTP pointing at IPv6 peers loses connectivity as well. But a traceroute wakes it up. It's almost like some router is losing the route to me out of the FIB, and fixes it when it has to handle a packet on the CPU slow path (like send back a 'time exceeded'). But I'm mystified why this started when I reflashed my router. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From rz+nng at zwart.com Sat Mar 18 15:55:11 2017 From: rz+nng at zwart.com (Romeo Zwart) Date: Sat, 18 Mar 2017 16:55:11 +0100 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: References: <20170317090358.GG4408void.codelabs.ru@void.codelabs.ru> <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <02301941-2AEF-4EEA-B891-E2513418B2A4@arin.net> Message-ID: <29fe2d71-c1c1-9d77-2799-9dacbb4c6e68@zwart.com> Dear John, Bill and all, On 17/03/17 19:31 , John Curran wrote: > On 17 Mar 2017, at 2:17 PM, William Herrin wrote: >> >> On Fri, Mar 17, 2017 at 2:14 PM, John Curran wrote: >> >>> See previous reply. The data was both correctly formatted and signed, >>> so the agreed integrity checks passed. >>> >> Ah, okay. So it wasn't bad counts as originally reported but no data with >> counts that confirmed no data. Thanks for the clarification! > > Bill - > > Glad to help (and apologies for the information coming out in pieces ? > we?ve opted to go with updates as we learn more rather than some for > comprehensive but less timely report.) We have been slow to clarify this from the RIPE NCC end, for which I apologize. As was already mentioned by Mark and John in previous messages in this thread, the initial report from the RIPE NCC wasn't complete, which has lead to unnecessary confusion. A follow up message with additional detail was sent to the RIPE NCC DNS working group list earlier today: https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003401.html We hope that this clarifies matters sufficiently. Kind regards, Romeo Zwart RIPE NCC From scott at digicomm.net Sat Mar 18 02:00:56 2017 From: scott at digicomm.net (Scott Eiswirth) Date: Sat, 18 Mar 2017 02:00:56 +0000 Subject: AT&T ISP Customers: Streaming Issues Message-ID: <6d528765c5744992afb689c44862cb24@DSI-MAIL1.digicommsystems.com> Anyone an AT&T DSP or Fiber customer having issues with streaming music, videos, or games? [DigiComm Systems Inc.] Scott Eiswirth | Network Engineer Office: (504) 212-0486 Mobile: (504) 881-6006 Fax: (504) 212-6772 www.digicommsystems.com From lists at mtin.net Mon Mar 20 03:32:40 2017 From: lists at mtin.net (Justin Wilson) Date: Sun, 19 Mar 2017 23:32:40 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> Message-ID: <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> Then you have the lists which want money to be removed. I have an IP that was blacklisted by hotmail. Just a single IP. I have gone through the procedures that are referenced in the return e-mails. No response. My next step says something about a $2500 fee to have it investigated. I know several blacklists which are this way. Luckily, many admins do not use such lists. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Mar 12, 2017, at 9:10 PM, Bob Evans wrote: > > Pete's right about how IPs get put on the lists. In fact, let us not > forget that these lists were mostly created with volunteers - some still > today. Many are very old lists. Enterprise networks select lists by some > sort of popularity / fame - etc.. Like how they decide to install 8.8.8.8 > as first - its easy and they think its better than their local ISP they > pay.... yet they always call the ISP about slowness when 8.8.8.8 is for > consumers and doesn't always resolve quickly. It's a tough sale. > > Once had a customer's employee abuse their mail server - it made some > lists. Customer complained our network is hosting spammers and sticking > them in the middle of a problem that is our networks. Hard win. Took us > months to get that IP off lists. That was one single IP. We did not allow > them to renew their contract once the term was over. Now, they suffer with > comcast for business. ;-) > > Thank You > Bob Evans > CTO > > > > >> On Sun, 12 Mar 2017, Pete Baldwin wrote: >> >>> So this is is really the question I had, and this is why I was >>> wanting to >>> start a dialog here, hoping that it wasn't out of line for the list. I >>> don't >>> know of a way to let a bunch of operators know that they should remove >>> something without using something like this mailing list. Blacklists >>> are >>> supposed to fill this role so that one operator doesn't have to try and >>> contact thousands of other operators individually, he/she just has to >>> appeal >>> to the blacklist and once delisted all should be well in short order. >>> >>> In cases where companies have their own internal lists, or only >>> update >>> them a couple of times a year from the major lists, I don't know of >>> another >>> way to notify everyone. >> >> I suspect you'll find many of the private "blacklistings" are hand >> maintained (added to as needed, never removed from unless requested) and >> you'll need to play whack-a-mole, reaching out to each network as you find >> they have the space blocked on their mail servers or null routed on their >> networks. I doubt your message here will be seen by many of the "right >> people." How many company mail server admins read NANOG? How many >> companies even do email in-house and have mail server admins anymore? :) >> >> Back when my [at that time] employer was issued some of 69/8, I found it >> useful to setup a host with IPs in 69/8 and in one of our older IP blocks, >> and then do both automated reachability testing and allow anyone to do a >> traceroute from both source IPs simultaneously, keeping the results in a >> DB. If you find there are many networks actually null routing your >> purchased space, you might setup something similar. >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> | therefore you are >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> > > From ops.lists at gmail.com Mon Mar 20 03:54:40 2017 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 20 Mar 2017 09:24:40 +0530 Subject: Purchased IPv4 Woes In-Reply-To: <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> Message-ID: <71340DDD-1C07-4F9F-AA57-171DD87B8E5D@gmail.com> Which one was it that demanded 2500? There's only one reasonably well known pay for whitelisting type of blocklist but I'd have thought they're a lot cheaper. --srs > On 20-Mar-2017, at 9:02 AM, Justin Wilson wrote: > > Then you have the lists which want money to be removed. I have an IP that was blacklisted by hotmail. Just a single IP. I have gone through the procedures that are referenced in the return e-mails. No response. My next step says something about a $2500 fee to have it investigated. I know several blacklists which are this way. Luckily, many admins do not use such lists. From mark.tinka at seacom.mu Mon Mar 20 10:35:24 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Mar 2017 12:35:24 +0200 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <20170113223934.GA18835@radiological.warningg.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113223934.GA18835@radiological.warningg.com> Message-ID: <1f6a450c-fb19-d467-07ca-777c84d25542@seacom.mu> On 14/Jan/17 00:39, Brandon Ewing wrote: > One important thing to remember when migrating from full mesh to a RR design > is that you are reducing information available to the routers in the ASN. > When you had a full mesh, each router could select the best path from all > available paths, according to its position in the IGP. In a RR environment, > by default, routers only have available to them the best routes from the > RR's position in the IGP, which can lead to suboptimal exits being selected. > > Work is being done to allow RRs to compute metrics from the client's > position in the IGP: See > https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13 > for more information BGP-ORR is currently supported in Junos and IOS XR (ASR9000, I believe... I haven't confirmed for other IOS XR platforms). I'm getting Cisco to add support for it in IOS and IOS XE (CSR1000v). I'm now dealing with the usual "How large is the customer's spend for this feature" nonsense. BGP-ORR, I feel, is one of those features that doesn't need a business case - much like ketchup at a fast-food joint. That the IOS XR PI team have it in there and the IOS/IOS XE PI teams don't highlights the depth of the fundamental problem over at Cisco-land. 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 bengelly at gmail.com Mon Mar 20 10:46:32 2017 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Mon, 20 Mar 2017 11:46:32 +0100 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <1f6a450c-fb19-d467-07ca-777c84d25542@seacom.mu> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113223934.GA18835@radiological.warningg.com> <1f6a450c-fb19-d467-07ca-777c84d25542@seacom.mu> Message-ID: Same old same. Y. 2017-03-20 11:35 GMT+01:00 Mark Tinka : > > > On 14/Jan/17 00:39, Brandon Ewing wrote: > > > One important thing to remember when migrating from full mesh to a RR > design > > is that you are reducing information available to the routers in the ASN. > > When you had a full mesh, each router could select the best path from all > > available paths, according to its position in the IGP. In a RR > environment, > > by default, routers only have available to them the best routes from the > > RR's position in the IGP, which can lead to suboptimal exits being > selected. > > > > Work is being done to allow RRs to compute metrics from the client's > > position in the IGP: See > > https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal- > route-reflection-13 > > for more information > > BGP-ORR is currently supported in Junos and IOS XR (ASR9000, I > believe... I haven't confirmed for other IOS XR platforms). > > I'm getting Cisco to add support for it in IOS and IOS XE (CSR1000v). > I'm now dealing with the usual "How large is the customer's spend for > this feature" nonsense. BGP-ORR, I feel, is one of those features that > doesn't need a business case - much like ketchup at a fast-food joint. > > That the IOS XR PI team have it in there and the IOS/IOS XE PI teams > don't highlights the depth of the fundamental problem over at Cisco-land. > > Mark. > From ghankins at mindspring.com Mon Mar 20 11:03:49 2017 From: ghankins at mindspring.com (Greg Hankins) Date: Mon, 20 Mar 2017 07:03:49 -0400 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <1f6a450c-fb19-d467-07ca-777c84d25542@seacom.mu> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113223934.GA18835@radiological.warningg.com> <1f6a450c-fb19-d467-07ca-777c84d25542@seacom.mu> Message-ID: <20170320110349.GA31740@mindspring.com> On Mon, Mar 20, 2017 at 12:35:24PM +0200, Mark Tinka wrote: >On 14/Jan/17 00:39, Brandon Ewing wrote: >> Work is being done to allow RRs to compute metrics from the client's >> position in the IGP: See >> https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13 >> for more information > >BGP-ORR is currently supported in Junos and IOS XR (ASR9000, I >believe... I haven't confirmed for other IOS XR platforms). > >I feel, is one of those features that doesn't need a business case - >much like ketchup at a fast-food joint. Mark is spot on, this is an important point. We just added ORR to SR OS 15.0.R1 on the 7x50/VSR. Greg -- Greg Hankins From josh at kyneticwifi.com Mon Mar 20 14:06:00 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 20 Mar 2017 09:06:00 -0500 Subject: Purchased IPv4 Woes In-Reply-To: <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> Message-ID: Would you mind naming the company so that they can be publicly shamed? That is nothing sort of extortion. On Mar 19, 2017 10:36 PM, "Justin Wilson" wrote: > > Then you have the lists which want money to be removed. I have an IP that > was blacklisted by hotmail. Just a single IP. I have gone through the > procedures that are referenced in the return e-mails. No response. My > next step says something about a $2500 fee to have it investigated. I know > several blacklists which are this way. Luckily, many admins do not use > such lists. > > > Justin Wilson > j2sw at mtin.net > > --- > http://www.mtin.net Owner/CEO > xISP Solutions- Consulting ? Data Centers - Bandwidth > > http://www.midwest-ix.com COO/Chairman > Internet Exchange - Peering - Distributed Fabric > > > On Mar 12, 2017, at 9:10 PM, Bob Evans > wrote: > > > > Pete's right about how IPs get put on the lists. In fact, let us not > > forget that these lists were mostly created with volunteers - some still > > today. Many are very old lists. Enterprise networks select lists by some > > sort of popularity / fame - etc.. Like how they decide to install 8.8.8.8 > > as first - its easy and they think its better than their local ISP they > > pay.... yet they always call the ISP about slowness when 8.8.8.8 is for > > consumers and doesn't always resolve quickly. It's a tough sale. > > > > Once had a customer's employee abuse their mail server - it made some > > lists. Customer complained our network is hosting spammers and sticking > > them in the middle of a problem that is our networks. Hard win. Took us > > months to get that IP off lists. That was one single IP. We did not allow > > them to renew their contract once the term was over. Now, they suffer > with > > comcast for business. ;-) > > > > Thank You > > Bob Evans > > CTO > > > > > > > > > >> On Sun, 12 Mar 2017, Pete Baldwin wrote: > >> > >>> So this is is really the question I had, and this is why I was > >>> wanting to > >>> start a dialog here, hoping that it wasn't out of line for the list. I > >>> don't > >>> know of a way to let a bunch of operators know that they should remove > >>> something without using something like this mailing list. > Blacklists > >>> are > >>> supposed to fill this role so that one operator doesn't have to try and > >>> contact thousands of other operators individually, he/she just has to > >>> appeal > >>> to the blacklist and once delisted all should be well in short order. > >>> > >>> In cases where companies have their own internal lists, or only > >>> update > >>> them a couple of times a year from the major lists, I don't know of > >>> another > >>> way to notify everyone. > >> > >> I suspect you'll find many of the private "blacklistings" are hand > >> maintained (added to as needed, never removed from unless requested) and > >> you'll need to play whack-a-mole, reaching out to each network as you > find > >> they have the space blocked on their mail servers or null routed on > their > >> networks. I doubt your message here will be seen by many of the "right > >> people." How many company mail server admins read NANOG? How many > >> companies even do email in-house and have mail server admins anymore? :) > >> > >> Back when my [at that time] employer was issued some of 69/8, I found it > >> useful to setup a host with IPs in 69/8 and in one of our older IP > blocks, > >> and then do both automated reachability testing and allow anyone to do a > >> traceroute from both source IPs simultaneously, keeping the results in a > >> DB. If you find there are many networks actually null routing your > >> purchased space, you might setup something similar. > >> > >> ---------------------------------------------------------------------- > >> Jon Lewis, MCP :) | I route > >> | therefore you are > >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > >> > > > > > > From nanog at ics-il.net Mon Mar 20 14:25:16 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 20 Mar 2017 09:25:16 -0500 (CDT) Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> Message-ID: <777750185.7110.1490019912723.JavaMail.mhammett@ThunderFuck> He did mention Hotmail. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Reynolds" To: "Justin Wilson" Cc: "NANOG" Sent: Monday, March 20, 2017 9:06:00 AM Subject: Re: Purchased IPv4 Woes Would you mind naming the company so that they can be publicly shamed? That is nothing sort of extortion. On Mar 19, 2017 10:36 PM, "Justin Wilson" wrote: > > Then you have the lists which want money to be removed. I have an IP that > was blacklisted by hotmail. Just a single IP. I have gone through the > procedures that are referenced in the return e-mails. No response. My > next step says something about a $2500 fee to have it investigated. I know > several blacklists which are this way. Luckily, many admins do not use > such lists. > > > Justin Wilson > j2sw at mtin.net > > --- > http://www.mtin.net Owner/CEO > xISP Solutions- Consulting ? Data Centers - Bandwidth > > http://www.midwest-ix.com COO/Chairman > Internet Exchange - Peering - Distributed Fabric > > > On Mar 12, 2017, at 9:10 PM, Bob Evans > wrote: > > > > Pete's right about how IPs get put on the lists. In fact, let us not > > forget that these lists were mostly created with volunteers - some still > > today. Many are very old lists. Enterprise networks select lists by some > > sort of popularity / fame - etc.. Like how they decide to install 8.8.8.8 > > as first - its easy and they think its better than their local ISP they > > pay.... yet they always call the ISP about slowness when 8.8.8.8 is for > > consumers and doesn't always resolve quickly. It's a tough sale. > > > > Once had a customer's employee abuse their mail server - it made some > > lists. Customer complained our network is hosting spammers and sticking > > them in the middle of a problem that is our networks. Hard win. Took us > > months to get that IP off lists. That was one single IP. We did not allow > > them to renew their contract once the term was over. Now, they suffer > with > > comcast for business. ;-) > > > > Thank You > > Bob Evans > > CTO > > > > > > > > > >> On Sun, 12 Mar 2017, Pete Baldwin wrote: > >> > >>> So this is is really the question I had, and this is why I was > >>> wanting to > >>> start a dialog here, hoping that it wasn't out of line for the list. I > >>> don't > >>> know of a way to let a bunch of operators know that they should remove > >>> something without using something like this mailing list. > Blacklists > >>> are > >>> supposed to fill this role so that one operator doesn't have to try and > >>> contact thousands of other operators individually, he/she just has to > >>> appeal > >>> to the blacklist and once delisted all should be well in short order. > >>> > >>> In cases where companies have their own internal lists, or only > >>> update > >>> them a couple of times a year from the major lists, I don't know of > >>> another > >>> way to notify everyone. > >> > >> I suspect you'll find many of the private "blacklistings" are hand > >> maintained (added to as needed, never removed from unless requested) and > >> you'll need to play whack-a-mole, reaching out to each network as you > find > >> they have the space blocked on their mail servers or null routed on > their > >> networks. I doubt your message here will be seen by many of the "right > >> people." How many company mail server admins read NANOG? How many > >> companies even do email in-house and have mail server admins anymore? :) > >> > >> Back when my [at that time] employer was issued some of 69/8, I found it > >> useful to setup a host with IPs in 69/8 and in one of our older IP > blocks, > >> and then do both automated reachability testing and allow anyone to do a > >> traceroute from both source IPs simultaneously, keeping the results in a > >> DB. If you find there are many networks actually null routing your > >> purchased space, you might setup something similar. > >> > >> ---------------------------------------------------------------------- > >> Jon Lewis, MCP :) | I route > >> | therefore you are > >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > >> > > > > > > From josh at kyneticwifi.com Mon Mar 20 14:38:05 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 20 Mar 2017 09:38:05 -0500 Subject: Purchased IPv4 Woes In-Reply-To: <777750185.7110.1490019912723.JavaMail.mhammett@ThunderFuck> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> <777750185.7110.1490019912723.JavaMail.mhammett@ThunderFuck> Message-ID: Just because he choose poorly with his email provider doesn't mean he should be allowed to be exploited Mike, although a friendly ribbing is still justified IMO ;) On Mar 20, 2017 9:27 AM, "Mike Hammett" wrote: > He did mention Hotmail. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Josh Reynolds" > To: "Justin Wilson" > Cc: "NANOG" > Sent: Monday, March 20, 2017 9:06:00 AM > Subject: Re: Purchased IPv4 Woes > > Would you mind naming the company so that they can be publicly shamed? That > is nothing sort of extortion. > > On Mar 19, 2017 10:36 PM, "Justin Wilson" wrote: > > > > > Then you have the lists which want money to be removed. I have an IP that > > was blacklisted by hotmail. Just a single IP. I have gone through the > > procedures that are referenced in the return e-mails. No response. My > > next step says something about a $2500 fee to have it investigated. I > know > > several blacklists which are this way. Luckily, many admins do not use > > such lists. > > > > > > Justin Wilson > > j2sw at mtin.net > > > > --- > > http://www.mtin.net Owner/CEO > > xISP Solutions- Consulting ? Data Centers - Bandwidth > > > > http://www.midwest-ix.com COO/Chairman > > Internet Exchange - Peering - Distributed Fabric > > > > > On Mar 12, 2017, at 9:10 PM, Bob Evans > > wrote: > > > > > > Pete's right about how IPs get put on the lists. In fact, let us not > > > forget that these lists were mostly created with volunteers - some > still > > > today. Many are very old lists. Enterprise networks select lists by > some > > > sort of popularity / fame - etc.. Like how they decide to install > 8.8.8.8 > > > as first - its easy and they think its better than their local ISP they > > > pay.... yet they always call the ISP about slowness when 8.8.8.8 is for > > > consumers and doesn't always resolve quickly. It's a tough sale. > > > > > > Once had a customer's employee abuse their mail server - it made some > > > lists. Customer complained our network is hosting spammers and sticking > > > them in the middle of a problem that is our networks. Hard win. Took us > > > months to get that IP off lists. That was one single IP. We did not > allow > > > them to renew their contract once the term was over. Now, they suffer > > with > > > comcast for business. ;-) > > > > > > Thank You > > > Bob Evans > > > CTO > > > > > > > > > > > > > > >> On Sun, 12 Mar 2017, Pete Baldwin wrote: > > >> > > >>> So this is is really the question I had, and this is why I was > > >>> wanting to > > >>> start a dialog here, hoping that it wasn't out of line for the list. > I > > >>> don't > > >>> know of a way to let a bunch of operators know that they should > remove > > >>> something without using something like this mailing list. > > Blacklists > > >>> are > > >>> supposed to fill this role so that one operator doesn't have to try > and > > >>> contact thousands of other operators individually, he/she just has to > > >>> appeal > > >>> to the blacklist and once delisted all should be well in short order. > > >>> > > >>> In cases where companies have their own internal lists, or only > > >>> update > > >>> them a couple of times a year from the major lists, I don't know of > > >>> another > > >>> way to notify everyone. > > >> > > >> I suspect you'll find many of the private "blacklistings" are hand > > >> maintained (added to as needed, never removed from unless requested) > and > > >> you'll need to play whack-a-mole, reaching out to each network as you > > find > > >> they have the space blocked on their mail servers or null routed on > > their > > >> networks. I doubt your message here will be seen by many of the "right > > >> people." How many company mail server admins read NANOG? How many > > >> companies even do email in-house and have mail server admins anymore? > :) > > >> > > >> Back when my [at that time] employer was issued some of 69/8, I found > it > > >> useful to setup a host with IPs in 69/8 and in one of our older IP > > blocks, > > >> and then do both automated reachability testing and allow anyone to > do a > > >> traceroute from both source IPs simultaneously, keeping the results > in a > > >> DB. If you find there are many networks actually null routing your > > >> purchased space, you might setup something similar. > > >> > > >> ------------------------------------------------------------ > ---------- > > >> Jon Lewis, MCP :) | I route > > >> | therefore you are > > >> _________ http://www.lewis.org/~jlewis/pgp for PGP public > key_________ > > >> > > > > > > > > > > > > From steve at blighty.com Mon Mar 20 14:55:05 2017 From: steve at blighty.com (Steve Atkins) Date: Mon, 20 Mar 2017 07:55:05 -0700 Subject: Purchased IPv4 Woes In-Reply-To: <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> Message-ID: <5064034A-CA33-486C-993E-46C8F32A4186@blighty.com> > On Mar 19, 2017, at 8:32 PM, Justin Wilson wrote: > > > Then you have the lists which want money to be removed. I have an IP that was blacklisted by hotmail. Just a single IP. I have gone through the procedures that are referenced in the return e-mails. No response. My next step says something about a $2500 fee to have it investigated. I know several blacklists which are this way. Luckily, many admins do not use such lists. This reads like you're leaving out some critical details of the story. Cheers, Steve From crussell at kanren.net Mon Mar 20 15:16:53 2017 From: crussell at kanren.net (Casey Russell) Date: Mon, 20 Mar 2017 10:16:53 -0500 Subject: IPv6 oddness in Comcast land... In-Reply-To: <142420.1489965371@turing-police.cc.vt.edu> References: <142420.1489965371@turing-police.cc.vt.edu> Message-ID: (I first sent this directly to Valdis instead of the list, so my apologies to Valdis for getting this twice) Greetings, I'm afraid I can't hand the ultimate solution, but I can point you in a direction. Sounds like you probably have an IPv6 neighbor discovery problem. Most likely (since that's where the change occurred) it's between your WRT and the Comcast CPE (I assume a cable modem) or the first active piece of the upstream cable plant. But It'll be the first Comcast device actually speaking Ipv6 to your WRT. I've seen this happen several times in new (or changed) peering links with other providers (where dissimilar equipment, or new ACLs) are involved. Typically what's happening is that an ACL or firewall rule on one device isn't allowing that devices interface to speak fully over the new link, and that's preventing IPv6 neighbor discovery from happening properly between two adjacent devices. (In this case those devices are likely your WRT and the first upstream Comcast device speaking IPv6). Since it's your device that changed, you likely won't have a lot of luck convincing comcast to dig too deep into this issue, especially since their device "worked" before and these providers have few engineers on-staff that really understand v6. It's not that there's no one at comcast who can fix it, it'll just take you a while to find them. So without knowing your equipment, I can only offer a few general tips. Look for troubleshooting commands that will show you the ipv6 neighbor discovery status on your device interfaces. See what the status is before a traceroute (when things are broken) and after a traceroute (when things are fixed). If it appears I'm right, go to that Interface and create ACLs or firewall rules to allow the actual ipv6 addresse(s) on that interface to speak (outward) to their local subnet. Be sure to remember you may need to create a rule for the global (permanent, public) address, and also for the link-local address. Some vendors will put the link-local address in the ND solicitation and others will use the global unicast (if it's already been assigned). The RFC suggests the link-local, but also says that the source and destination addresses in the messages need be only "An address assigned to the interface from which the advertisement is sent." If that does help, remember to tighten those new ACLs as much as you can and still have things work. If it doesn't, you'll likely have to engage comcast about the issue, as it may, or may not be this at all. :-) good luck Sincerely, Casey Russell Network Engineer [image: KanREN] [image: phone]785-856-9809 2029 Becker Drive, Suite 282 Lawrence, Kansas 66047 [image: linkedin] [image: twitter] [image: twitter] need support? On Sun, Mar 19, 2017 at 6:16 PM, wrote: > Trying to figure out what the heck is going on here. Any good > explanations cheerfully accepted. > > Background: Home internet router is a Linksys WRT1200AC that had been > running OpenWRT 15.05.01. IPv6 worked just fine - Comcast handed me a /60 > via DHCP-PD and no issues. I reflashed it to Lede 17.01, and after doing > all the reconfig, I'm hitting a really strange IPv6 issue. > > Symptoms - IPv6 still configures correctly, but IPv6 packets appear to go > out > and disappear into the ether when they leave the Linksys. Doing a > traceroute > to any IPv6 destination makes things work again - for a while (from 15 > minutes > to an hour or two). > > As seen from my laptop (I have the matching tcpdump from the outbound > interface on the Linksys): > > [~] ping -6 -c 3 listserv.vt.edu > PING listserv.vt.edu(listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769)) > 56 data bytes > > --- listserv.vt.edu ping statistics --- > 3 packets transmitted, 0 received, 100% packet loss, time 2070ms > > [~] traceroute -6 listserv.vt.edu > traceroute to listserv.vt.edu (2001:468:c80:2105:211:43ff:feda:d769), 30 > hops max, 80 byte packets > 1 2601:5c0:c001:69e2::1 (2601:5c0:c001:69e2::1) 2.417 ms 3.077 ms > 5.358 ms > 2 * * * > 3 * * * > 4 * * * > 5 * * * > 6 * hu-0-10-0-7-pe04.ashburn.va.ibone.comcast.net (2001:558:0:f5c1::2) > 31.478 ms 31.975 ms > 7 2001:559::d16 (2001:559::d16) 32.406 ms 17.102 ms 24.751 ms > 8 2001:550:2:2f::a (2001:550:2:2f::a) 23.245 ms 23.519 ms 22.185 ms > 9 2607:b400:f0:2003::f0 (2607:b400:f0:2003::f0) 29.782 ms 28.604 ms > 29.891 ms > 10 2607:b400:90:ff05::f1 (2607:b400:90:ff05::f1) 30.423 ms * 30.680 ms > 11 * * * > 12 listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769) 34.562 > ms 39.072 ms 24.633 ms > [~] ping -6 -c 3 listserv.vt.edu > PING listserv.vt.edu(listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769)) > 56 data bytes > 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): > icmp_seq=1 ttl=53 time=33.3 ms > 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): > icmp_seq=2 ttl=53 time=24.3 ms > 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): > icmp_seq=3 ttl=53 time=46.0 ms > > --- listserv.vt.edu ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2003ms > rtt min/avg/max/mdev = 24.334/34.595/46.093/8.927 ms > > So it looks like something times out somewhere and fails to pass packets > back. > > TCP connections don't keep IPv6 alive. I have a browser window that > auto-updates every 5 minutes, and a SmokePing process on a Raspberri Pi > uploads > to a server at work every few minutes, and those eventually drop back to > IPv4 > when the IPv6 TCP fails to connect. And normal UDP doesn't seem to keep it > alive - NTP pointing at IPv6 peers loses connectivity as well. > > But a traceroute wakes it up. It's almost like some router is losing the > route to me out of the FIB, and fixes it when it has to handle a packet > on the CPU slow path (like send back a 'time exceeded'). But I'm mystified > why this started when I reflashed my router. > > From rob at invaluement.com Mon Mar 20 16:08:29 2017 From: rob at invaluement.com (Rob McEwen) Date: Mon, 20 Mar 2017 12:08:29 -0400 Subject: Purchased IPv4 Woes In-Reply-To: <777750185.7110.1490019912723.JavaMail.mhammett@ThunderFuck> References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> <777750185.7110.1490019912723.JavaMail.mhammett@ThunderFuck> Message-ID: On 3/20/2017 10:25 AM, Mike Hammett wrote: > He did mention Hotmail. I have no idea which blacklist is allegedly charging $2500 for investigating a listing. (I wonder if he meant to type $25.00?) Either way, I don't know who that is. But I will say that, in general, many requesting a delisting from a blacklist OFTEN assume that a particular hoster that is blocking their messages MUST therefore be caused by the particular "known" blacklist they found themselves to be on. But, in many such cases, the host had their own internal blacklist or was using some OTHER 3rd party blacklist - that was possibly responding to the same "root cause" that the other "known" blacklist was reacting to as well, but where that particular "known" blacklist wasn't actually the direct reason that this hoster was blocking that sender. So (absent more specific info proving such) this "known" blacklist that is allegedly charging a fee for research... could easily NOT be related to hotmail. (and probably isn't!) -- Rob McEwen From bob at FiberInternetCenter.com Mon Mar 20 16:19:58 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 20 Mar 2017 09:19:58 -0700 Subject: Purchased IPv4 Woes In-Reply-To: References: <69696d44-303a-6be6-cafd-24578db07f95@tccmail.ca> <875A3FA8-043E-4A8F-BD6D-D7CE74372564@mtin.net> <006401d29b42$f9b85640$ed2902c0$@gmail.com> <143324.1489333228@turing-police.cc.vt.edu> <1bc1078b-a7c5-cdb0-e134-1b60581af17f@tccmail.ca> <73bf1e2616574f1e5b61cfd47f80f0a4.squirrel@66.201.44.180> <3B914B1F-BA43-4AF6-AEBE-D555C7C0CF9D@mtin.net> Message-ID: <9b6a17881c0b18b113e600ea9737ddbe.squirrel@66.201.44.180> I am for naming the companies that extort for via RBLs. Spamming is so wide spread even the domain name company Godaddy leveraged it as a profit center. Godaddy, in it's early beginnings. Years ago. I know from experience that this happens....Godaddy demanded money from me for spamming. I had to pay $150 or $250 ? I had several domains with them that were not even being used, beyond a webpage placeholder and I ran my own DNS server for my domains. After paying, they released my domain to function again. They claimed and promised they would provide the proof "after I paid"... employees and all kinds of lines about why they could not show you until after you paid. I paid and Godaddy suddenly lost the proof. I am sure it was part of a profit center as I know others that had this happen with Godaddy. Think about it Godaddy didnt even provide me a service using an IP address of theirs. It was the domain they held hostage with their DNS server. There should be a class action against them - just to expose it - (people never get the real money the lawyers do in a class action). Now that they are public some lawyer should look into the records and find all the extortion money gathered years ago. Contact those domain owners at the time. Would surprise me if the RBL owners were ex Godaddy employees that saw this leverage opportunity. Thank You Bob Evans CTO > Would you mind naming the company so that they can be publicly shamed? > That > is nothing sort of extortion. > > On Mar 19, 2017 10:36 PM, "Justin Wilson" wrote: > >> >> Then you have the lists which want money to be removed. I have an IP >> that >> was blacklisted by hotmail. Just a single IP. I have gone through the >> procedures that are referenced in the return e-mails. No response. My >> next step says something about a $2500 fee to have it investigated. I >> know >> several blacklists which are this way. Luckily, many admins do not use >> such lists. >> >> >> Justin Wilson >> j2sw at mtin.net >> >> --- >> http://www.mtin.net Owner/CEO >> xISP Solutions- Consulting ??? Data Centers - Bandwidth >> >> http://www.midwest-ix.com COO/Chairman >> Internet Exchange - Peering - Distributed Fabric >> >> > On Mar 12, 2017, at 9:10 PM, Bob Evans >> wrote: >> > >> > Pete's right about how IPs get put on the lists. In fact, let us not >> > forget that these lists were mostly created with volunteers - some >> still >> > today. Many are very old lists. Enterprise networks select lists by >> some >> > sort of popularity / fame - etc.. Like how they decide to install >> 8.8.8.8 >> > as first - its easy and they think its better than their local ISP >> they >> > pay.... yet they always call the ISP about slowness when 8.8.8.8 is >> for >> > consumers and doesn't always resolve quickly. It's a tough sale. >> > >> > Once had a customer's employee abuse their mail server - it made some >> > lists. Customer complained our network is hosting spammers and >> sticking >> > them in the middle of a problem that is our networks. Hard win. Took >> us >> > months to get that IP off lists. That was one single IP. We did not >> allow >> > them to renew their contract once the term was over. Now, they suffer >> with >> > comcast for business. ;-) >> > >> > Thank You >> > Bob Evans >> > CTO >> > >> > >> > >> > >> >> On Sun, 12 Mar 2017, Pete Baldwin wrote: >> >> >> >>> So this is is really the question I had, and this is why I was >> >>> wanting to >> >>> start a dialog here, hoping that it wasn't out of line for the list. >> I >> >>> don't >> >>> know of a way to let a bunch of operators know that they should >> remove >> >>> something without using something like this mailing list. >> Blacklists >> >>> are >> >>> supposed to fill this role so that one operator doesn't have to try >> and >> >>> contact thousands of other operators individually, he/she just has >> to >> >>> appeal >> >>> to the blacklist and once delisted all should be well in short >> order. >> >>> >> >>> In cases where companies have their own internal lists, or only >> >>> update >> >>> them a couple of times a year from the major lists, I don't know of >> >>> another >> >>> way to notify everyone. >> >> >> >> I suspect you'll find many of the private "blacklistings" are hand >> >> maintained (added to as needed, never removed from unless requested) >> and >> >> you'll need to play whack-a-mole, reaching out to each network as you >> find >> >> they have the space blocked on their mail servers or null routed on >> their >> >> networks. I doubt your message here will be seen by many of the >> "right >> >> people." How many company mail server admins read NANOG? How many >> >> companies even do email in-house and have mail server admins anymore? >> :) >> >> >> >> Back when my [at that time] employer was issued some of 69/8, I found >> it >> >> useful to setup a host with IPs in 69/8 and in one of our older IP >> blocks, >> >> and then do both automated reachability testing and allow anyone to >> do a >> >> traceroute from both source IPs simultaneously, keeping the results >> in a >> >> DB. If you find there are many networks actually null routing your >> >> purchased space, you might setup something similar. >> >> >> >> ---------------------------------------------------------------------- >> >> Jon Lewis, MCP :) | I route >> >> | therefore you are >> >> _________ http://www.lewis.org/~jlewis/pgp for PGP public >> key_________ >> >> >> > >> > >> >> > From jwbensley at gmail.com Mon Mar 20 16:59:47 2017 From: jwbensley at gmail.com (James Bensley) Date: Mon, 20 Mar 2017 16:59:47 +0000 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <20170320110349.GA31740@mindspring.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113223934.GA18835@radiological.warningg.com> <1f6a450c-fb19-d467-07ca-777c84d25542@seacom.mu> <20170320110349.GA31740@mindspring.com> Message-ID: On 20 March 2017 at 11:03, Greg Hankins wrote: > On Mon, Mar 20, 2017 at 12:35:24PM +0200, Mark Tinka wrote: >>On 14/Jan/17 00:39, Brandon Ewing wrote: >>> Work is being done to allow RRs to compute metrics from the client's >>> position in the IGP: See >>> https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13 >>> for more information >> >>BGP-ORR is currently supported in Junos and IOS XR (ASR9000, I >>believe... I haven't confirmed for other IOS XR platforms). >> >>I feel, is one of those features that doesn't need a business case - >>much like ketchup at a fast-food joint. > > Mark is spot on, this is an important point. We just added ORR to SR OS > 15.0.R1 on the 7x50/VSR. Yes, which means we all know what we have do to. Everyone needs to join in to increase the pressure. Cheers, James. From stl at wiredrive.com Mon Mar 20 18:58:13 2017 From: stl at wiredrive.com (Scott Larson) Date: Mon, 20 Mar 2017 11:58:13 -0700 Subject: AS 9583 (Sify Corp) contact required Message-ID: Beginning at 10am UTC today, AS 9583 began announcing routes for our (AS 40041) IP space, the most significant damage of which has so far been caused in the UK. We're currently playing whack-a-mole on an ISP and exchange level, but having zero luck tracking down a contact capable of a proper resolution to this issue. Please contact me off list if you are that person or know who they are. *[image: userimage]Scott Larson[image: los angeles] Lead Systems Administrator[image: wdlogo] [image: linkedin] [image: facebook] [image: twitter] [image: instagram] T 310 823 8238 <310%20823%208238%20x1106> * From rbf+nanog at panix.com Mon Mar 20 19:27:52 2017 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Mon, 20 Mar 2017 14:27:52 -0500 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> References: <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> Message-ID: <20170320192752.GA14835@panix.com> On Sat, Mar 18, 2017 at 09:27:11PM -0700, Doug Barton wrote: > > > As to why DNS-native zone operations are not utilized, the challenge > > is that reverse DNS zones for IPv4 and DNS operations are on octet > > boundaries, but IPv4 address blocks may be aligned on any bit > > boundary. > > Yes, deeply familiar with that problem. Are you dealing with any address > blocks smaller than a /24? If the answer is no (which it almost certainly > is), what challenges are you facing that you haven't figured out how to > overcome yet? (Even < /24 blocks can be dealt with, obviously, but I'd be > interested to learn that there are problems with /24 and up that are too > difficult to solve.) Hypotheically: 10.11.0.0/16 (11.10.in-addr.arpa) is managed by ARIN 10.11.16.0/20 is ARIN space 10.11.32.0/20 is RIPE space If ARIN delegated 32.11.10.in-addr.arpa through 47.11.10.in-addr.arpa to a RIPE nameserver, there's no good way for RIPE to then delegate, say, 10.11.34.0/24 (34.11.10.in-addr.arpa) to the nameserver of the entity to which RIPE has allocated 10.11.34.0. (Sure, it can be done, using the same techniques as are used for allocations of longer-than-/24, but recipients of /24 and larger reasonably expect to have the X.X.X.in-addr.arpa delegated to their nameservers.) So, instead, RIPE communicates to ARIN the proper delegations for 32.11.10.in-addr.arpa through 47.11.10.in-addr.arpa, and ARIN merges those into 11.10.in-addr.arpa. One way for RIPE to communicate those delegations to ARIN is to put then into some other zone, which ARIN could then zone-transfer. But ARIN would still need a process to merge the data from that other e with the real 11.10.in-addr.arpa zone. But that has the same risks as the current process, which apparently communicates those delegations via something other than zone-transfer. -- Brett From jason at unlimitednet.us Mon Mar 20 19:54:50 2017 From: jason at unlimitednet.us (Jason Canady) Date: Mon, 20 Mar 2017 15:54:50 -0400 Subject: Google G Suite Email Contact Message-ID: Is anyone here from Google's G Suite or email department? I recently acquired a brand who's domain is being blocked by Google Mail ("G Suite"). I have followed all of the steps to be compliant (SPF and DKIM), but email is still going into customer's Spam folder at Google. There is not a massive amount of emails sent, just basic communication such as monthly invoices, support tickets, etc. If anyone has a contact, please share it with me on or off list. I would greatly appreciate it. Thank you! Jason Canady Unlimited Net, LLC From bill at herrin.us Mon Mar 20 20:56:39 2017 From: bill at herrin.us (William Herrin) Date: Mon, 20 Mar 2017 16:56:39 -0400 Subject: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations In-Reply-To: <20170320192752.GA14835@panix.com> References: <20170317095335.jlpxnl43iwrzx4fd@nic.fr> <20170317100430.GN4408void.codelabs.ru@void.codelabs.ru> <6B64BA41-9909-4C59-85EB-56B15C8EBAD6@istaff.org> <0b99b2ee-2a59-64ed-2a96-941807f08584@zwart.com> <1ECCAF19-D44B-4C13-88E8-F43A537078B4@arin.net> <9f95009a-1351-8cdd-75d5-ff98fd9c1695@dougbarton.us> <6834F716-EA15-4A68-B1A5-4F0A0D43A270@istaff.org> <0092c655-e1f2-a665-c118-7d8a53e0eb1f@dougbarton.us> <20170320192752.GA14835@panix.com> Message-ID: On Mon, Mar 20, 2017 at 3:27 PM, Brett Frankenberger wrote: > If ARIN delegated 32.11.10.in-addr.arpa through 47.11.10.in-addr.arpa > to a RIPE nameserver, there's no good way for RIPE to then delegate, > say, 10.11.34.0/24 (34.11.10.in-addr.arpa) to the nameserver of the > entity to which RIPE has allocated 10.11.34.0. (Sure, it can be done, > using the same techniques as are used for allocations of > longer-than-/24, but recipients of /24 and larger reasonably expect to > have the X.X.X.in-addr.arpa delegated to their nameservers.) > Hi Brett, The last I tried it, the servers which the glue claims are authoritative for a zone could assert that they themselves are not authoritative and offer new glue for completely different servers asserted to be authoritative. I had to fake a parent zone in Bind. This was before DNSSEC. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From saku at ytti.fi Mon Mar 20 21:46:24 2017 From: saku at ytti.fi (Saku Ytti) Date: Mon, 20 Mar 2017 23:46:24 +0200 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113223934.GA18835@radiological.warningg.com> <1f6a450c-fb19-d467-07ca-777c84d25542@seacom.mu> <20170320110349.GA31740@mindspring.com> Message-ID: On 20 March 2017 at 18:59, James Bensley wrote: >> Mark is spot on, this is an important point. We just added ORR to SR OS >> 15.0.R1 on the 7x50/VSR. > > Yes, which means we all know what we have do to. Everyone needs to > join in to increase the pressure. When talking to your vendors, ask what they do with ORR+ADD_PATH 2. Obviously desired behaviour is to advertise 1st and 2nd best from ORR POV. If you need ORR, you're clearly moving to out-of-path reflection, which is great. But you probably want that ADD_PATH 2, to retain full-mesh like convergence times. -- ++ytti From juergen at jaritsch.at Tue Mar 21 16:56:29 2017 From: juergen at jaritsch.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Tue, 21 Mar 2017 17:56:29 +0100 Subject: Facebook more specific via Level3 ? Message-ID: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> Hi, is anyone else receiving Facebook?s /24 more specific from Level3 (AS3356)? 31.13.70.0/24 *[BGP/170] 1w5d 17:21:28, MED 0, localpref 100, from a.b.c.d AS path: 3356 32934 I, validation-state: unverified This more specific is only visible via AS3356 Facebook isn?t even announcing it via direct peering. Any Facebook admin on or off list available to get this debugged and tracked down? Thanks & best regards J?rgen From zeusdadog at gmail.com Tue Mar 21 17:37:28 2017 From: zeusdadog at gmail.com (Jay Nakamura) Date: Tue, 21 Mar 2017 13:37:28 -0400 Subject: Facebook more specific via Level3 ? In-Reply-To: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> Message-ID: I see that specific route both of my upstreams and not going through level 3. Network Next Hop MED LocPrf Weight Path *>x 31.13.70.0/24 x.x.x.x 0 80 0 6461 32934 i *i 31.13.70.0/24 x.x.x.x 0 80 0 209 32934 i * 31.13.70.0/24 x.x.x.x 10 80 0 209 32934 i On Tue, Mar 21, 2017 at 12:56 PM, J?rgen Jaritsch wrote: > Hi, > > > > is anyone else receiving Facebook?s /24 more specific from Level3 (AS3356)? > > > > 31.13.70.0/24 *[BGP/170] 1w5d 17:21:28, MED 0, localpref 100, from > a.b.c.d > > AS path: 3356 32934 I, validation-state: unverified > > > > This more specific is only visible via AS3356 ? Facebook isn?t even > announcing it via direct peering. > > > > Any Facebook admin on or off list available to get this debugged and > tracked > down? > > > > > > Thanks & best regards > > J?rgen > > From dsp at fb.com Tue Mar 21 17:41:23 2017 From: dsp at fb.com (Doug Porter) Date: Tue, 21 Mar 2017 17:41:23 +0000 Subject: Facebook more specific via Level3 ? In-Reply-To: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> Message-ID: > 31.13.70.0/24 > > This more specific is only visible via AS3356 ... Facebook > isn?t even announcing it via direct peering. This specific, and many others, are only announced to peers in the metro they originate in. To receive this prefix directly you'll need to peer with us in Los Angeles. It appears you're in Austria though, which means there's likely no use in you peering with us in LA. We globally load balance people to the best point of presence. You shouldn't see much, if any, traffic to or from the above prefix. > Any Facebook admin on or off list available to get this > debugged and tracked down? Please reach out to noc at fb.com in the future. Regards, -- dsp From juergen at jaritsch.at Tue Mar 21 19:23:31 2017 From: juergen at jaritsch.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Tue, 21 Mar 2017 20:23:31 +0100 Subject: Facebook more specific via Level3 ? Message-ID: <01ef01d2a278$a1d016b0$e5704410$@jaritsch.at> Hi, > This specific, and many others, are only announced to peers in the > metro they originate in. To receive this prefix directly you'll > need to peer with us in Los Angeles. the point is: Level3 is exporting this prefix to the EU since ~1 week Telia is learning it from Level3 and they also started to re-export it: Telia Looking Glass (http://lg.telia.net/?query=bgp&protocol=IPv4&addr=31.13.71.0/24+exact&route r=Vienna) Command: show route protocol bgp 31.13.71.36 table inet.0 31.13.71.0/24 *[BGP/170] 18w5d 16:40:16, MED 0, localpref 150 AS path: 3356 32934 I, validation-state: unverified > to 80.239.128.178 via ae9.0 This is causing >120ms latency to Austrian (and some German ...) networks towards Facebook - current traceroute from source network 188.172.239.0/24: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 4 0.5 0.5 0.5 0.6 0.0 2. 192.168.8.3 0.0% 4 0.6 0.7 0.6 0.8 0.1 3. 37.252.236.88 0.0% 4 37.3 34.2 30.6 37.3 2.9 4. er-03.00-09-23.anx04.vie.at.anexia-it.com 0.0% 4 21.1 31.9 21.1 50.9 13.3 5. cr-02.0v-08-72.anx03.vie.at.anexia-it.com 0.0% 4 23.2 25.9 20.4 31.6 5.1 6. win-b4-link.telia.net 0.0% 4 22.1 25.0 22.1 30.1 3.5 7. level-ic-1573273-wien-b4.c.telia.net 0.0% 3 22.4 22.3 21.1 23.3 1.1 8. ae-3-3611.edge2.dallas1.level3.net 0.0% 3 150.5 150.6 150.4 150.8 0.2 9. facebook-in.edge2.dallas1.level3.net 0.0% 3 156.6 152.9 151.0 156.6 3.2 10. po102.psw02.dft4.tfbnw.net 0.0% 3 151.4 151.6 151.4 152.0 0.4 11. 173.252.67.57 0.0% 3 151.6 152.3 151.6 153.4 0.9 12. edge-star-mini-shv-01-dft4.facebook.com 0.0% 3 159.3 158.4 152.5 163.6 5.6 The admins of AS42473 started to drop the more specific from Level3 and now they get it from Telia (which is the Level3 re-export they learned). I guess you guys should talk to Level3 and ask them what the hell they are doing? :). Thanks & best regards J?rgen From juergen at jaritsch.at Tue Mar 21 19:38:02 2017 From: juergen at jaritsch.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Tue, 21 Mar 2017 20:38:02 +0100 Subject: AW: Facebook more specific via Level3 ? In-Reply-To: References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> Message-ID: <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> Hi Doug, looks like this is also affecting other prefixes: 157.240.3.0/24 *[BGP/170] 18w5d 16:50:37, MED 0, localpref 150 AS path: 3356 32934 I, validation-state: unverified > to 80.239.128.178 via ae9.0 I understand that FB is using some type of DNS geo-loadbalancing and other mechanism to redirect users to (possibly) nearer mirrors. The used DNS is directly requesting the root DNS and not any other public DNS (e.g. not 8.8.8.8). Running some requests within 3 minutes gives me the below results: www.facebook.com => star-mini.c10r.facebook.com. => 31.13.77.36 www.facebook.com => star-mini.c10r.facebook.com. => 157.240.2.35 www.facebook.com => star-mini.c10r.facebook.com. => 31.13.93.36 www.facebook.com => star-mini.c10r.facebook.com. => 31.13.76.68 Trace to 31.13.77.36: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev [...] 6. win-b4-link.telia.net 0.0% 3 21.5 27.5 21.5 35.7 7.3 7. level-ic-1573273-wien-b4.c.telia.net 0.0% 3 21.7 20.8 20.0 21.7 0.8 8. ae-1-9.edge2.sanjose3.level3.net 0.0% 3 177.1 179.8 177.1 182.6 2.8 9. 4.53.210.78 0.0% 3 178.3 178.8 178.3 179.2 0.5 10. po131.asw04.sjc1.tfbnw.net 0.0% 3 184.6 180.0 177.6 184.6 4.0 11. po241.psw02.sjc2.tfbnw.net 0.0% 3 177.8 177.6 177.3 177.8 0.3 12. 173.252.67.79 0.0% 3 176.3 177.4 176.3 177.9 0.9 13. edge-star-mini-shv-01-sjc2.facebook.com 0.0% 3 177.6 177.4 177.1 177.6 0.3 Trace to 157.240.2.35: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev [...] 6. win-b4-link.telia.net 0.0% 3 20.9 25.8 20.8 35.8 8.6 7. level-ic-1573273-wien-b4.c.telia.net 0.0% 3 20.5 21.4 20.2 23.4 1.8 8. ??? 9. 4.15.85.102 0.0% 3 142.9 138.5 135.8 142.9 3.8 10. po121.asw01.ord3.tfbnw.net 0.0% 3 135.5 135.7 135.5 136.0 0.4 11. po211.psw01c.ort2.tfbnw.net 0.0% 2 136.1 135.7 135.3 136.1 0.6 12. 173.252.67.127 0.0% 2 151.6 147.6 143.6 151.6 5.7 13. edge-star-mini-shv-01-ort2.facebook.com 0.0% 2 136.0 135.9 135.8 136.0 0.2 Trace to 31.13.93.36 => this one is going via the FB DE-CIX peering and latency of 34ms is perfect: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 5 0.5 0.5 0.5 0.6 0.0 2. 192.168.8.3 0.0% 4 0.7 0.7 0.7 0.8 0.1 3. 37.252.236.88 0.0% 4 37.8 38.0 31.8 46.1 6.0 4. er-03.00-09-23.anx04.vie.at.anexia-it.com 0.0% 4 25.3 25.2 23.1 29.2 2.9 5. cr-02.0v-08-72.anx03.vie.at.anexia-it.com 0.0% 4 21.3 30.4 20.6 40.1 10.9 6. cr-01.0v-08-73.anx25.fra.de.anexia-it.com 0.0% 4 45.7 39.1 33.1 45.7 5.3 7. ae1.br02.fra1.tfbnw.net 0.0% 4 33.0 34.6 32.1 40.3 3.8 8. po114.asw01.fra2.tfbnw.net 0.0% 4 33.6 35.6 33.3 41.7 4.0 9. po211.psw01d.fra3.tfbnw.net 0.0% 4 40.8 36.6 32.9 40.8 3.4 10. 173.252.67.171 0.0% 4 41.2 35.6 33.3 41.2 3.7 11. edge-star-mini-shv-01-fra3.facebook.com 0.0% 4 34.6 33.9 33.2 34.6 0.6 Trace to 31.13.76.68: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev [...] 6. win-b4-link.telia.net 0.0% 14 28.9 24.7 20.3 29.3 3.5 7. level-ic-1573273-wien-b4.c.telia.net 0.0% 14 22.8 22.5 20.0 30.9 3.7 8. ae-2-3613.edge1.seattle3.level3.net 0.0% 13 195.2 189.2 186.0 195.2 3.5 9. 4.59.232.46 0.0% 13 187.9 188.2 186.7 196.1 2.5 10. po101.psw03.sea1.tfbnw.net 0.0% 13 194.7 188.3 186.5 194.7 2.0 11. 173.252.67.125 0.0% 13 188.0 188.8 186.9 195.5 2.2 12. edge-star-mini-shv-01-sea1.facebook.com 0.0% 13 186.6 189.0 186.2 196.0 3.1 Best regards J?rgen -----Urspr?ngliche Nachricht----- Von: Doug Porter [mailto:dsp at fb.com] Gesendet: Dienstag, 21. M?rz 2017 18:41 An: J?rgen Jaritsch ; nanog at nanog.org Betreff: Re: Facebook more specific via Level3 ? > 31.13.70.0/24 > > This more specific is only visible via AS3356 ... Facebook isn?t even > announcing it via direct peering. This specific, and many others, are only announced to peers in the metro they originate in. To receive this prefix directly you'll need to peer with us in Los Angeles. It appears you're in Austria though, which means there's likely no use in you peering with us in LA. We globally load balance people to the best point of presence. You shouldn't see much, if any, traffic to or from the above prefix. > Any Facebook admin on or off list available to get this debugged and > tracked down? Please reach out to noc at fb.com in the future. Regards, -- dsp From lguillory at reservetele.com Tue Mar 21 19:38:23 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 21 Mar 2017 19:38:23 +0000 Subject: Facebook more specific via Level3 ? In-Reply-To: <01ef01d2a278$a1d016b0$e5704410$@jaritsch.at> References: <01ef01d2a278$a1d016b0$e5704410$@jaritsch.at> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB0E571B@RTC-EXCH01.RESERVE.LDS> Are they replying with that subnet via dns when requests are being made? Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J?rgen Jaritsch Sent: Tuesday, March 21, 2017 2:24 PM To: nanog at nanog.org Subject: Re: Facebook more specific via Level3 ? Hi, > This specific, and many others, are only announced to peers in the > metro they originate in. To receive this prefix directly you'll need > to peer with us in Los Angeles. the point is: Level3 is exporting this prefix to the EU since ~1 week ? Telia is learning it from Level3 and they also started to re-export it: Telia Looking Glass (http://lg.telia.net/?query=bgp&protocol=IPv4&addr=31.13.71.0/24+exact&route r=Vienna) Command: show route protocol bgp 31.13.71.36 table inet.0 31.13.71.0/24 *[BGP/170] 18w5d 16:40:16, MED 0, localpref 150 AS path: 3356 32934 I, validation-state: unverified > to 80.239.128.178 via ae9.0 This is causing >120ms latency to Austrian (and some German ...) networks towards Facebook - current traceroute from source network 188.172.239.0/24: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 4 0.5 0.5 0.5 0.6 0.0 2. 192.168.8.3 0.0% 4 0.6 0.7 0.6 0.8 0.1 3. 37.252.236.88 0.0% 4 37.3 34.2 30.6 37.3 2.9 4. er-03.00-09-23.anx04.vie.at.anexia-it.com 0.0% 4 21.1 31.9 21.1 50.9 13.3 5. cr-02.0v-08-72.anx03.vie.at.anexia-it.com 0.0% 4 23.2 25.9 20.4 31.6 5.1 6. win-b4-link.telia.net 0.0% 4 22.1 25.0 22.1 30.1 3.5 7. level-ic-1573273-wien-b4.c.telia.net 0.0% 3 22.4 22.3 21.1 23.3 1.1 8. ae-3-3611.edge2.dallas1.level3.net 0.0% 3 150.5 150.6 150.4 150.8 0.2 9. facebook-in.edge2.dallas1.level3.net 0.0% 3 156.6 152.9 151.0 156.6 3.2 10. po102.psw02.dft4.tfbnw.net 0.0% 3 151.4 151.6 151.4 152.0 0.4 11. 173.252.67.57 0.0% 3 151.6 152.3 151.6 153.4 0.9 12. edge-star-mini-shv-01-dft4.facebook.com 0.0% 3 159.3 158.4 152.5 163.6 5.6 The admins of AS42473 started to drop the more specific from Level3 and now they get it from Telia (which is the Level3 re-export they learned). I guess you guys should talk to Level3 and ask them what the hell they are doing? :). Thanks & best regards J?rgen From juergen at jaritsch.at Tue Mar 21 19:39:49 2017 From: juergen at jaritsch.at (=?UTF-8?Q?J=C3=BCrgen_Jaritsch?=) Date: Tue, 21 Mar 2017 20:39:49 +0100 Subject: AW: Facebook more specific via Level3 ? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB0E571B@RTC-EXCH01.RESERVE.LDS> References: <01ef01d2a278$a1d016b0$e5704410$@jaritsch.at> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB0E571B@RTC-EXCH01.RESERVE.LDS> Message-ID: <01fb01d2a27a$e8bc2580$ba347080$@jaritsch.at> Hi Luke, please see https://mailman.nanog.org/pipermail/nanog/2017-March/090658.html ... I did some tests a few min ago and yes, I'm receiving the 31.13.77.x and 31.13.76.x via DNS for www.facebook.com. Best regards J?rgen -----Urspr?ngliche Nachricht----- Von: Luke Guillory [mailto:lguillory at reservetele.com] Gesendet: Dienstag, 21. M?rz 2017 20:38 An: J?rgen Jaritsch ; nanog at nanog.org Betreff: RE: Facebook more specific via Level3 ? Are they replying with that subnet via dns when requests are being made? Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J?rgen Jaritsch Sent: Tuesday, March 21, 2017 2:24 PM To: nanog at nanog.org Subject: Re: Facebook more specific via Level3 ? Hi, > This specific, and many others, are only announced to peers in the > metro they originate in. To receive this prefix directly you'll need > to peer with us in Los Angeles. the point is: Level3 is exporting this prefix to the EU since ~1 week ? Telia is learning it from Level3 and they also started to re-export it: Telia Looking Glass (http://lg.telia.net/?query=bgp&protocol=IPv4&addr=31.13.71.0/24+exact&route r=Vienna) Command: show route protocol bgp 31.13.71.36 table inet.0 31.13.71.0/24 *[BGP/170] 18w5d 16:40:16, MED 0, localpref 150 AS path: 3356 32934 I, validation-state: unverified > to 80.239.128.178 via ae9.0 This is causing >120ms latency to Austrian (and some German ...) networks towards Facebook - current traceroute from source network 188.172.239.0/24: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 4 0.5 0.5 0.5 0.6 0.0 2. 192.168.8.3 0.0% 4 0.6 0.7 0.6 0.8 0.1 3. 37.252.236.88 0.0% 4 37.3 34.2 30.6 37.3 2.9 4. er-03.00-09-23.anx04.vie.at.anexia-it.com 0.0% 4 21.1 31.9 21.1 50.9 13.3 5. cr-02.0v-08-72.anx03.vie.at.anexia-it.com 0.0% 4 23.2 25.9 20.4 31.6 5.1 6. win-b4-link.telia.net 0.0% 4 22.1 25.0 22.1 30.1 3.5 7. level-ic-1573273-wien-b4.c.telia.net 0.0% 3 22.4 22.3 21.1 23.3 1.1 8. ae-3-3611.edge2.dallas1.level3.net 0.0% 3 150.5 150.6 150.4 150.8 0.2 9. facebook-in.edge2.dallas1.level3.net 0.0% 3 156.6 152.9 151.0 156.6 3.2 10. po102.psw02.dft4.tfbnw.net 0.0% 3 151.4 151.6 151.4 152.0 0.4 11. 173.252.67.57 0.0% 3 151.6 152.3 151.6 153.4 0.9 12. edge-star-mini-shv-01-dft4.facebook.com 0.0% 3 159.3 158.4 152.5 163.6 5.6 The admins of AS42473 started to drop the more specific from Level3 and now they get it from Telia (which is the Level3 re-export they learned). I guess you guys should talk to Level3 and ask them what the hell they are doing? :). Thanks & best regards J?rgen From dsp at fb.com Tue Mar 21 21:55:14 2017 From: dsp at fb.com (Doug Porter) Date: Tue, 21 Mar 2017 21:55:14 +0000 Subject: Facebook more specific via Level3 ? In-Reply-To: <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> , <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> Message-ID: > looks like this is also affecting other prefixes: Many of our prefixes are only announced to peers in the metro they originate in. Please stop obsessing about this detail; it's not the problem. > I understand that FB is using some type of DNS > geo-loadbalancing and other mechanism to redirect users to > (possibly) nearer mirrors. We target traffic two ways. One is relatively traditional dns global load balancing, using the resolver ip. The other method---which steers the vast majority of our traffic---vends urls that send people to a specific PoP based on their client ip. It appears you're having a targeting problem. Please reach out to our NOC to get support. -- dsp From plamengg17 at gmail.com Mon Mar 20 22:29:35 2017 From: plamengg17 at gmail.com (Plamen G Georgiev) Date: Mon, 20 Mar 2017 22:29:35 +0000 Subject: Google G Suite Email Contact In-Reply-To: References: Message-ID: Did you try on their support page ? On Mon, Mar 20, 2017 at 7:54 PM, Jason Canady wrote: > Is anyone here from Google's G Suite or email department? I recently > acquired a brand who's domain is being blocked by Google Mail ("G Suite"). > I have followed all of the steps to be compliant (SPF and DKIM), but email > is still going into customer's Spam folder at Google. There is not a > massive amount of emails sent, just basic communication such as monthly > invoices, support tickets, etc. > > If anyone has a contact, please share it with me on or off list. I would > greatly appreciate it. Thank you! > > Jason Canady > Unlimited Net, LLC > > From nanog at radu-adrian.feurdean.net Wed Mar 22 10:02:12 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Wed, 22 Mar 2017 11:02:12 +0100 Subject: Facebook more specific via Level3 ? In-Reply-To: <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> Message-ID: <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> On Tue, Mar 21, 2017, at 20:38, J?rgen Jaritsch wrote: > I understand that FB is using some type of DNS geo-loadbalancing and other > mechanism to redirect users to (possibly) nearer mirrors. The used DNS is > directly requesting the root DNS and not any other public DNS (e.g. not > 8.8.8.8). Running some requests within 3 minutes gives me the below > results: > > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.77.36 > www.facebook.com => star-mini.c10r.facebook.com. => 157.240.2.35 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.93.36 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.76.68 Hi, the load-balancing definitely doesn't choose the *nearest* mirror. We are in France and unless we do dirty tricks, we *always* get directed to US sites (as far as LA), with horrible performance. Everything since end of December. As a consequence we let the dirty tricks in place (query facebook.com and fbcdn.com on 8.8.8.8 instead of regular recursive resolving) and we get directed to Frankfurt or Amsterdam (never London or Paris). From juergen at jaritsch.at Wed Mar 22 10:06:47 2017 From: juergen at jaritsch.at (=?UTF-8?Q?J=C3=BCrgen_Jaritsch?=) Date: Wed, 22 Mar 2017 11:06:47 +0100 Subject: AW: Facebook more specific via Level3 ? In-Reply-To: <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> Message-ID: <023501d2a2f4$064ec070$12ec4150$@jaritsch.at> Hi, > (query facebook.com and fbcdn.com on 8.8.8.8 instead of regular recursive resolving) and we get directed to Frankfurt or Amsterdam (never London or Paris). This is exactly what I've implemented yesterday on my end :). Best regards J?rgen -----Urspr?ngliche Nachricht----- Von: Radu-Adrian Feurdean [mailto:nanog at radu-adrian.feurdean.net] Gesendet: Mittwoch, 22. M?rz 2017 11:02 An: J?rgen Jaritsch ; Doug Porter ; nanog at nanog.org Betreff: Re: Facebook more specific via Level3 ? On Tue, Mar 21, 2017, at 20:38, J?rgen Jaritsch wrote: > I understand that FB is using some type of DNS geo-loadbalancing and > other mechanism to redirect users to (possibly) nearer mirrors. The > used DNS is directly requesting the root DNS and not any other public > DNS (e.g. not 8.8.8.8). Running some requests within 3 minutes gives > me the below > results: > > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.77.36 > www.facebook.com => star-mini.c10r.facebook.com. => 157.240.2.35 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.93.36 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.76.68 Hi, the load-balancing definitely doesn't choose the *nearest* mirror. We are in France and unless we do dirty tricks, we *always* get directed to US sites (as far as LA), with horrible performance. Everything since end of December. As a consequence we let the dirty tricks in place (query facebook.com and fbcdn.com on 8.8.8.8 instead of regular recursive resolving) and we get directed to Frankfurt or Amsterdam (never London or Paris). From nanog at ics-il.net Wed Mar 22 11:25:49 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 22 Mar 2017 06:25:49 -0500 (CDT) Subject: Facebook more specific via Level3 ? In-Reply-To: <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> Message-ID: <1282715565.10388.1490181947874.JavaMail.mhammett@ThunderFuck> Are your DNS resolvers on your network? No DNS forwarding? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Radu-Adrian Feurdean" To: "J?rgen Jaritsch" , "Doug Porter" , nanog at nanog.org Sent: Wednesday, March 22, 2017 5:02:12 AM Subject: Re: Facebook more specific via Level3 ? On Tue, Mar 21, 2017, at 20:38, J?rgen Jaritsch wrote: > I understand that FB is using some type of DNS geo-loadbalancing and other > mechanism to redirect users to (possibly) nearer mirrors. The used DNS is > directly requesting the root DNS and not any other public DNS (e.g. not > 8.8.8.8). Running some requests within 3 minutes gives me the below > results: > > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.77.36 > www.facebook.com => star-mini.c10r.facebook.com. => 157.240.2.35 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.93.36 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.76.68 Hi, the load-balancing definitely doesn't choose the *nearest* mirror. We are in France and unless we do dirty tricks, we *always* get directed to US sites (as far as LA), with horrible performance. Everything since end of December. As a consequence we let the dirty tricks in place (query facebook.com and fbcdn.com on 8.8.8.8 instead of regular recursive resolving) and we get directed to Frankfurt or Amsterdam (never London or Paris). From juergen at jaritsch.at Wed Mar 22 13:23:25 2017 From: juergen at jaritsch.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Wed, 22 Mar 2017 14:23:25 +0100 Subject: Facebook more specific via Level3 ? Message-ID: <025401d2a30f$7edceb50$7c96c1f0$@jaritsch.at> Hi Mike, I?m running some DNS on my own for a few hundred users from an private community project. But this issue is also affecting DNS from smaller/other ISPs which do NOT use any forwarder but the root DNS. Best regards J?rgen From nanog at radu-adrian.feurdean.net Wed Mar 22 13:41:15 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Wed, 22 Mar 2017 14:41:15 +0100 Subject: Facebook more specific via Level3 ? In-Reply-To: <1282715565.10388.1490181947874.JavaMail.mhammett@ThunderFuck> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> <1282715565.10388.1490181947874.JavaMail.mhammett@ThunderFuck> Message-ID: <1490190075.3347067.919731960.1FCF29E8@webmail.messagingengine.com> On Wed, Mar 22, 2017, at 12:25, Mike Hammett wrote: > Are your DNS resolvers on your network? No DNS forwarding? Yes, DNS resolvers on our network. Forwarding only for facebook.com and fbcdn.com, in order to eliminate bad performance associated with "direct recursion". From faisal at snappytelecom.net Wed Mar 22 16:47:52 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 22 Mar 2017 16:47:52 +0000 (GMT) Subject: Americas II Landing Station (Hollywood, Florida). Message-ID: <535777428.2099777.1490201272803.JavaMail.zimbra@snappytelecom.net> Hello, I am looking for a contact who may be able to help us with getting more info (on getting space/power) so that we can terminate our Dark Fiber transport there. Not sure who is responsible for this facility, most of the Tel# I am finding are disconnected. Many Thanks in advance. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net From morrowc.lists at gmail.com Wed Mar 22 17:06:20 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 22 Mar 2017 13:06:20 -0400 Subject: Americas II Landing Station (Hollywood, Florida). In-Reply-To: <535777428.2099777.1490201272803.JavaMail.zimbra@snappytelecom.net> References: <535777428.2099777.1490201272803.JavaMail.zimbra@snappytelecom.net> Message-ID: don't most of the oceanic cable systems operate basically like: 1) some consortium pays/builds the stations and link(s) 2) that consortium (cabal?) is the only set of providers able to sell on the link(s) 3) sale on links and provisioning to the links happens away from the station, and back at 'network pops' owned by the individual consortium members. So, if you are a consortium member you already have gear a the station, if you aren't (and didn't arrange to buy an entire fiber from one consortium member) you don't get to the station, you get to one of the pops. On Wed, Mar 22, 2017 at 12:47 PM, Faisal Imtiaz wrote: > Hello, > > I am looking for a contact who may be able to help us with getting more > info (on getting space/power) so that we can terminate our Dark Fiber > transport there. > > Not sure who is responsible for this facility, most of the Tel# I am > finding are disconnected. > > Many Thanks in advance. > > Regards. > > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From James at arenalgroup.co Thu Mar 23 17:01:00 2017 From: James at arenalgroup.co (James Breeden) Date: Thu, 23 Mar 2017 17:01:00 +0000 Subject: New ASN Assignments in ARIN Message-ID: If requesting a new ASN assignment in the ARIN region these days, what block of ASNs is ARIN assigning from? More curiosity than anything. 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 From JKrejci at usinternet.com Thu Mar 23 17:09:53 2017 From: JKrejci at usinternet.com (Justin Krejci) Date: Thu, 23 Mar 2017 17:09:53 +0000 Subject: New ASN Assignments in ARIN In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211DCF0A48B4@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <58d40164.41fcca0a.987cf.7cb5SMTPIN_ADDED_BROKEN@mx.google.com> Last few new ASN additions ARIN has issued: Add AS396022 Add AS396023 Add AS396024 Add AS396025 Add AS396026 Add AS396027 ARIN has a daily mailing list where they indicate all of their newly updated number resource registrations. http://lists.arin.net/pipermail/arin-issued/ ________________________________________ From: James Breeden [James at arenalgroup.co] Sent: Thursday, March 23, 2017 12:01 PM To: 'NANOG' Subject: New ASN Assignments in ARIN If requesting a new ASN assignment in the ARIN region these days, what block of ASNs is ARIN assigning from? More curiosity than anything. 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 From theodore at ciscodude.net Thu Mar 23 17:10:38 2017 From: theodore at ciscodude.net (Theodore Baschak) Date: Thu, 23 Mar 2017 12:10:38 -0500 Subject: New ASN Assignments in ARIN In-Reply-To: References: Message-ID: Mostly 396xxx these days: http://lists.arin.net/pipermail/arin-issued/2017-March/005956.html Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/ On Thu, Mar 23, 2017 at 12:01 PM, James Breeden wrote: > If requesting a new ASN assignment in the ARIN region these days, what > block of ASNs is ARIN assigning from? > > More curiosity than anything. > > > 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 arenalgroup.co> > > From tspprmng at feec.vutbr.cz Thu Mar 23 11:08:50 2017 From: tspprmng at feec.vutbr.cz (TSP 2017 Final Call) Date: Thu, 23 Mar 2017 12:08:50 +0100 Subject: IEEE CASS ICECS 2017 | December 5-8, 2017, Batumi, Georgia | 2017 24th International Conference on Electronics, Circuits and Systems (ICECS) Message-ID: *2017 24th International Conference on Electronics, Circuits and Systems (ICECS) */December 5-8, 2017, Batumi, Georgia /Web: http://icecs2017.org/ *************************************************************************** Dear Colleagues, As the flagship conference of IEEE Circuits and Systems Society in Region 8 of IEEE (Europe, Middle East, and Africa), ICECS 2017, the 24th International Conference on Electronics, Circuits and Systems will be held in Batumi, Georgia on December 5-8, 2017. *TOPICS: * ICECS 2017 will consist of tutorials, plenary lectures, regular, special and poster sessions focusing on recent trends, emerging technologies and advances in all aspects of Circuits, Systems, Signals, Mathematical Methods, Computational Methods, Applications. Papers are solicited in, but not limited to, the following topics: ? VLSI Systems, NoC, SoC, CAD, and Layout ? Analog/Digital/Mixed Signals Circuits ? Signal Processing, Multimedia Systems ? MEMS/NEMS, Mechatronics, Robotics ? Communication Circuits & Systems ? Green and Power Electronics ? Low-Power Tech. and Harvesting Energy ? Linear/Non-linear Circuits and Systems ? Embedded and Systems Architectures ? Bioengineering Circuits and Systems ? Emerging Technologies ? Memristive Devices and Systems ? Neural Networks and Fuzzy Systems ? Simulation and Design Tools in EE *CONFERENCE PROCEEDINGS AND SPECIAL ISSUES: * ICECS 2017 Proceedings, containing presented papers at the Conference, will be submitted for indexing to IEEE Xplore? Digital Library, SCOPUS, Conference Proceedings Citation Index (CPCI) of Thomson Reuters and Google Scholar databases. Authors of selected among best rated and presented papers will be invited to publish their papers in special issues of international journals. *ORGANIZERS: * /Honorary Chairs / ? Franco Maloberti, University of Pavia, Italy ? Thanos Stouraitis, Khalifa University, United Arab Emirates ? Magdy Bayoumi, University of Louisiana at Lafayette, USA /General Co-Chairs / ? Cem Goknar, I??k University, Turkey ? Sidd?k B. Yarman, I??k University, Turkey /Technical Program Chairs / ? Ahmet Aksen, I??k University, Turkey ? Costas Psychalinos, University of Patras, Greece /Finance Chairs / ? Shahram Minaei, Do?u? University, Turkey /Tutorial Chairs / ? Onur Kaya, I??k University, Turkey ? Raj Senani, Netaji Subhas Institute of Technology, India ? Massimo Alioto, National University of Singapore, Singapore /Publication Chairs / ? Serdar ?zo?uz, Istanbul Technical University, Turkey ? Norbert Herencsar, Brno University of Technology, Czech Republic /Special Sessions Chairs / ? Neslihan Serap ?eng?r, Istanbul Technical University, Turkey ? Elena Blokhina, UCD School Of Electrical And Electronic Engineering, Ireland /Publicity and PR Chairs / ? Hakan Kuntman, Istanbul Technical University, Turkey ? Ricardo Reis, Federal University of Rio Grande do Sul, Brazil /Industrial Relations / ? Mohammed Ismail, Khalifa University, United Arab Emirates ? Herv? Barthelemy, University of Toulon, France /Web Management Chairs / ? Taner Eskil, I??k University, Turkey ? Serdar ?zo?uz, Istanbul Technical University, Turkey /Local Arrangements Chair / ? Aydo?an ?zdemir *IMPORTANT DATES: * Special Session and Tutorials Proposals: May 15, 2017 Notification of Special Session Acceptance: May 30, 2017 Paper Submissions: June 15, 2017 Notification of Paper Acceptance: September 15, 2017 Camera-Ready Paper Submission: October 15, 2017 *CONTACT: * For more details please visit the Conference website at http://icecs2017.org/. Please circulate this call for papers among your colleagues. Thank you and hope to see you at ICECS 2017. Best regards, Cem G?knar, IEEE Life Fellow ICECS 2017 General Co-Chair I?IK University, Turkey *************************************************************************** ICECS Organizers reserve the right to exclude a paper from distribution after the Conference (e.g., non-indexing in IEEE Xplore? and other databases) if the paper is not presented at the Conference. However, this paper will be distributed as part of the Conference proceedings issued on an USB drive. *************************************************************************** From pim at ipng.nl Thu Mar 23 18:03:01 2017 From: pim at ipng.nl (Pim van Pelt) Date: Thu, 23 Mar 2017 19:03:01 +0100 Subject: nanog: SixXS is shutting down Message-ID: Colleagues of nanog, In 1999, Jeroen and I started SixXS, a project which aimed to provide IPv6 connectivity to users who wanted to learn about the network protocol and gain experience operating IPv6 networks. Our vision was to facilitate migration to IPv6 in content and access providers. We were able to provide IPv6 to 50?000+ individual users and companies in 140+ countries, using servers hosted at 40+ Internet providers in 30+ countries. We are incredibly proud of what we?ve accomplished together, and how many people have gotten to know all about IPv6 due to our combined efforts. We have completed a retrospective and rationale document, which details our experience developing and operating the SixXS tunnelbroker over the last 18 years. We have worked through our plans with the many dedicated ISPs that have been involved: https://www.sixxs.net/sunset/ We have reached out to users recently, giving them 6 weeks to make alternative plans. We have chosen a somewhat symbolic date of 2017-06-06 to turn down the SixXS service. Our website will remain as a tombstone. Please feel free to pass this along to any group or list you feel would benefit from it, and reach out to or to myself directly if you have thoughts you?d like to share between now and then. Kindest Regards, Pim van Pelt and Jeroen Massar (SixXS founders) -- Pim van Pelt PBVP1-RIPE - http://www.ipng.nl/ From large.hadron.collider at gmx.com Thu Mar 23 18:35:05 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Thu, 23 Mar 2017 11:35:05 -0700 Subject: nanog: SixXS is shutting down In-Reply-To: References: Message-ID: <67D2E90F-8219-4B8A-A764-00ED6A44B23D@gmx.com> Many people still don't have native IPv6. Why must 6XS die? On March 23, 2017 11:03:01 AM PDT, Pim van Pelt wrote: >Colleagues of nanog, > >In 1999, Jeroen and I started SixXS, a project which aimed to provide >IPv6 connectivity to users who wanted to learn about the network >protocol and gain experience operating IPv6 networks. Our vision was >to facilitate migration to IPv6 in content and access providers. > >We were able to provide IPv6 to 50?000+ individual users and companies >in 140+ countries, using servers hosted at 40+ Internet providers in >30+ countries. We are incredibly proud of what we?ve accomplished >together, and how many people have gotten to know all about IPv6 due >to our combined efforts. > >We have completed a retrospective and rationale document, which >details our experience developing and operating the SixXS tunnelbroker >over the last 18 years. We have worked through our plans with the many >dedicated ISPs that have been involved: >https://www.sixxs.net/sunset/ > >We have reached out to users recently, giving them 6 weeks to make >alternative plans. We have chosen a somewhat symbolic date of >2017-06-06 to turn down the SixXS service. Our website will remain as >a tombstone. > >Please feel free to pass this along to any group or list you feel >would benefit from it, and reach out to or to myself >directly if you have thoughts you?d like to share >between now and then. > > >Kindest Regards, >Pim van Pelt and Jeroen Massar (SixXS founders) > >-- >Pim van Pelt >PBVP1-RIPE - http://www.ipng.nl/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From alarig at swordarmor.fr Thu Mar 23 18:47:44 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Thu, 23 Mar 2017 19:47:44 +0100 Subject: nanog: SixXS is shutting down In-Reply-To: <67D2E90F-8219-4B8A-A764-00ED6A44B23D@gmx.com> References: <67D2E90F-8219-4B8A-A764-00ED6A44B23D@gmx.com> Message-ID: <20170323184744.bfp4kcxwzzmdthox@mew.swordarmor.fr> On jeu. 23 mars 11:35:05 2017, LHC (k9m) wrote: > Many people still don't have native IPv6. Why must 6XS die? The whole reflection is explained here: https://www.sixxs.net/sunset/ but to abstract, it?s because SixXS became an argument for large provider to not deploy IPv6 to their end users, as those that want it can use a broker. -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From nanog-isp at mail.com Fri Mar 24 12:46:32 2017 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Fri, 24 Mar 2017 13:46:32 +0100 Subject: TRILL Message-ID: Hi all! Can anybody recommend any good resources on TRILL? Particularly anything that addresses do's and don'ts or any problems and pitfalls. Also any experiences deploying and using TRILL in networks that anybody would like to share would be welcome. For clarity, this is the TRILL I'm referring to: https://en.m.wikipedia.org/wiki/TRILL_(computing) Jared From d3e3e3 at gmail.com Fri Mar 24 13:37:39 2017 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 24 Mar 2017 09:37:39 -0400 Subject: TRILL In-Reply-To: References: Message-ID: On Fri, Mar 24, 2017 at 8:46 AM, wrote: > > Hi all! > > Can anybody recommend any good resources on TRILL? Particularly anything that addresses do's and don'ts or any problems and pitfalls. Also any experiences deploying and using TRILL in networks that anybody would like to share would be welcome. That might depend on your application and to some extent whose equipment you are using. You might want to contact the people at http://www.six.sk/?lang=en&page= or SANET https://www.infinera.com/how-sanet-created-a-different-kind-of-network-backbone-a-discussion-between-marian-durkovic-sanet-and-geoff-bennett-infinera/ Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com > For clarity, this is the TRILL I'm referring to: > https://en.m.wikipedia.org/wiki/TRILL_(computing) > > Jared From fw at deneb.enyo.de Fri Mar 24 15:07:50 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 24 Mar 2017 16:07:50 +0100 Subject: BCP 38 coverage if top x providers ... In-Reply-To: <9EB78A78-CC71-4DBE-ABA6-4B05FB7E6496@puck.nether.net> (Jared Mauch's message of "Tue, 22 Nov 2016 10:44:09 -0500") References: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> <9EB78A78-CC71-4DBE-ABA6-4B05FB7E6496@puck.nether.net> Message-ID: <87k27eaf21.fsf@mid.deneb.enyo.de> * Jared Mauch: >> On Nov 19, 2016, at 9:13 PM, Frank Bulk wrote: >> >> My google fu is failing me, but I believe there was a NANOG posting a year >> or two ago that mentioned that if the top x providers would >> implement BCP 38 >> then y% of the traffic (or Internet) would be de-spoofed. The point was >> that we don't even need everyone to implement BCP 38, but if the largest >> (transit?) providers did it, then UDP reflection attacks could be >> minimized. >> >> If someone can recall the key words in that posting and dig it up, that >> would be much appreciated. > A double lookup of the packet is twice as expensive and perhaps > impractical in some (or many) cases. Do you actually have to filter all packets? Or could you just sample a subset and police the offenders, on the assumption that if you don't implement an anti-spoofing policy, you end up with near-constant leakage? From cscora at apnic.net Fri Mar 24 18:02:52 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Mar 2017 04:02:52 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170324180252.11C0AC44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 25 Mar, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 639326 Prefixes after maximum aggregation (per Origin AS): 249732 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 309219 Total ASes present in the Internet Routing Table: 56642 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 49032 Origin ASes announcing only one prefix: 21726 Transit ASes present in the Internet Routing Table: 7610 Transit-only ASes present in the Internet Routing Table: 213 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 75 Numnber of instances of unregistered ASNs: 76 Number of 32-bit ASNs allocated by the RIRs: 17833 Number of 32-bit ASNs visible in the Routing Table: 13867 Prefixes from 32-bit ASNs in the Routing Table: 56285 Number of bogon 32-bit ASNs visible in the Routing Table: 46 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 412 Number of addresses announced to Internet: 2839257668 Equivalent to 169 /8s, 59 /16s and 162 /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: 98.5 Total number of prefixes smaller than registry allocations: 212171 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 175163 Total APNIC prefixes after maximum aggregation: 50255 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 174442 Unique aggregates announced from the APNIC address blocks: 72098 APNIC Region origin ASes present in the Internet Routing Table: 7950 APNIC Prefixes per ASN: 21.94 APNIC Region origin ASes announcing only one prefix: 2232 APNIC Region transit ASes present in the Internet Routing Table: 1126 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2789 Number of APNIC addresses announced to Internet: 762323332 Equivalent to 45 /8s, 112 /16s and 33 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 195124 Total ARIN prefixes after maximum aggregation: 93482 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 197529 Unique aggregates announced from the ARIN address blocks: 90549 ARIN Region origin ASes present in the Internet Routing Table: 17854 ARIN Prefixes per ASN: 11.06 ARIN Region origin ASes announcing only one prefix: 6629 ARIN Region transit ASes present in the Internet Routing Table: 1771 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: 1862 Number of ARIN addresses announced to Internet: 1107930528 Equivalent to 66 /8s, 9 /16s and 173 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 171945 Total RIPE prefixes after maximum aggregation: 84500 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 167206 Unique aggregates announced from the RIPE address blocks: 101222 RIPE Region origin ASes present in the Internet Routing Table: 23840 RIPE Prefixes per ASN: 7.01 RIPE Region origin ASes announcing only one prefix: 11007 RIPE Region transit ASes present in the Internet Routing Table: 3375 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5667 Number of RIPE addresses announced to Internet: 710463104 Equivalent to 42 /8s, 88 /16s and 206 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 80179 Total LACNIC prefixes after maximum aggregation: 17733 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 81383 Unique aggregates announced from the LACNIC address blocks: 38177 LACNIC Region origin ASes present in the Internet Routing Table: 5728 LACNIC Prefixes per ASN: 14.21 LACNIC Region origin ASes announcing only one prefix: 1539 LACNIC Region transit ASes present in the Internet Routing Table: 1045 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3250 Number of LACNIC addresses announced to Internet: 170312864 Equivalent to 10 /8s, 38 /16s and 196 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16805 Total AfriNIC prefixes after maximum aggregation: 3699 AfriNIC Deaggregation factor: 4.54 Prefixes being announced from the AfriNIC address blocks: 18354 Unique aggregates announced from the AfriNIC address blocks: 6815 AfriNIC Region origin ASes present in the Internet Routing Table: 1028 AfriNIC Prefixes per ASN: 17.85 AfriNIC Region origin ASes announcing only one prefix: 319 AfriNIC Region transit ASes present in the Internet Routing Table: 203 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 299 Number of AfriNIC addresses announced to Internet: 87706880 Equivalent to 5 /8s, 58 /16s and 77 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5563 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3773 391 262 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2998 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2761 11150 755 KIXS-AS-KR Korea Telecom, KR 9829 2719 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2276 8649 45 CMNET-GD Guangdong Mobile Communication 4755 2069 421 220 TATACOMM-AS TATA Communications formerl 45899 1902 1325 112 VNPT-AS-VN VNPT Corp, VN 9583 1571 121 540 SIFY-AS-IN Sify Limited, IN 24560 1563 579 256 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3678 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3355 1333 83 SHAW - Shaw Communications Inc., CA 18566 2186 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1981 2086 407 CHARTER-NET-HKY-NC - Charter Communicat 209 1783 5067 641 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1779 3325 568 AMAZON-02 - Amazon.com, Inc., US 30036 1726 320 391 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1690 854 231 ITCDELTA - Earthlink, Inc., US 701 1577 10586 649 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS, SA 20940 3064 1129 2171 AKAMAI-ASN1, US 9121 2670 1691 17 TTNET, TR 34984 2004 328 382 TELLCOM-AS, TR 8551 1648 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 13188 1647 99 59 TRIOLAN, UA 12479 1533 1043 53 UNI2-AS, ES 12389 1351 1273 553 ROSTELECOM-AS, RU 9198 1306 352 23 KAZTELECOM-AS, KZ 6849 1265 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3540 545 179 Telmex Colombia S.A., CO 8151 2510 3385 547 Uninet S.A. de C.V., MX 11830 1819 369 57 Instituto Costarricense de Electricidad 7303 1554 1002 247 Telecom Argentina S.A., AR 6503 1542 437 53 Axtel, S.A.B. de C.V., MX 6147 1252 377 27 Telefonica del Peru S.A.A., PE 28573 1066 2292 189 CLARO S.A., BR 3816 1002 479 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 990 280 35 Techtel LMDS Comunicaciones Interactiva 17072 936 118 409 TOTAL PLAY TELECOMUNICACIONES SA DE CV, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1312 399 43 LINKdotNET-AS, EG 36903 717 360 127 MT-MPLS, MA 37611 698 67 6 Afrihost, ZA 36992 601 1375 26 ETISALAT-MISR, EG 24835 497 722 14 RAYA-AS, EG 8452 442 1474 16 TE-AS TE-AS, EG 37492 399 318 73 ORANGE-, TN 29571 367 36 10 CITelecom-AS, CI 15399 340 35 7 WANANCHI-, KE 2018 287 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5563 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3773 391 262 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3678 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3540 545 179 Telmex Colombia S.A., CO 6327 3355 1333 83 SHAW - Shaw Communications Inc., CA 39891 3334 171 18 ALJAWWALSTC-AS, SA 20940 3064 1129 2171 AKAMAI-ASN1, US 17974 2998 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2761 11150 755 KIXS-AS-KR Korea Telecom, KR 9829 2719 1499 540 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3678 3526 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3773 3511 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3540 3361 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS, SA 6327 3355 3272 SHAW - Shaw Communications Inc., CA 17974 2998 2926 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2670 2653 TTNET, TR 9808 2276 2231 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2719 2179 BSNL-NIB National Internet Backbone, IN 18566 2186 2077 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS, IL 65555 UNALLOCATED 37.142.175.0/24 21450 MIRS-AS, IL 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.157.128.0/17 393899 -Reserved AS-, ZZ 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:281 /13:538 /14:1050 /15:1824 /16:13235 /17:7569 /18:13369 /19:24586 /20:38323 /21:41168 /22:75594 /23:62679 /24:357567 /25:554 /26:415 /27:296 /28:35 /29:23 /30:25 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3147 3355 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS, SA 22773 2848 3678 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2079 2186 MEGAPATH5-US - MegaPath Corporation, US 9121 1886 2670 TTNET, TR 30036 1533 1726 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1457 3540 Telmex Colombia S.A., CO 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1371 1647 TRIOLAN, UA 6983 1327 1690 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1615 2:844 4:26 5:2484 6:34 8:1057 12:1815 13:92 14:1790 15:22 16:2 17:113 18:129 19:1 20:55 23:2142 24:1856 25:2 27:2373 31:1890 32:89 33:5 35:19 36:386 37:2563 38:1354 39:45 40:100 41:2942 42:460 43:1900 44:64 45:2451 46:2709 47:114 49:1212 50:971 51:18 52:780 54:360 55:7 56:4 57:41 58:1630 59:991 60:388 61:1941 62:1499 63:1923 64:4587 65:2206 66:4545 67:2272 68:1195 69:3333 70:1305 71:578 72:2173 74:2635 75:406 76:425 77:1434 78:1647 79:1316 80:1354 81:1403 82:966 83:724 84:859 85:1757 86:485 87:1146 88:794 89:2056 90:172 91:6138 92:1029 93:2383 94:2380 95:2818 96:570 97:359 98:952 99:85 100:155 101:1256 103:14044 104:2781 105:165 106:489 107:1567 108:821 109:2598 110:1292 111:1719 112:1165 113:1328 114:1029 115:1735 116:1771 117:1688 118:2067 119:1604 120:969 121:1092 122:2358 123:2053 124:1539 125:1821 128:741 129:619 130:418 131:1399 132:521 133:190 134:605 135:221 136:519 137:428 138:1871 139:417 140:374 141:538 142:739 143:921 144:768 145:170 146:1030 147:666 148:1378 149:563 150:703 151:946 152:730 153:306 154:754 155:979 156:563 157:605 158:443 159:1434 160:562 161:735 162:2445 163:521 164:789 165:1199 166:389 167:1235 168:2583 169:771 170:3020 171:285 172:982 173:1812 174:803 175:730 176:1802 177:4022 178:2493 179:1130 180:2183 181:1913 182:2245 183:1050 184:835 185:9163 186:3215 187:2192 188:2506 189:1784 190:8120 191:1281 192:9366 193:5779 194:4661 195:3861 196:1981 197:1252 198:5555 199:5867 200:7421 201:4119 202:10244 203:9801 204:4480 205:2760 206:3004 207:3109 208:3912 209:3965 210:3959 211:2109 212:2802 213:2471 214:856 215:64 216:5929 217:2034 218:834 219:619 220:1705 221:906 222:723 223:1164 End of report From admin at coldnorthadmin.com Fri Mar 24 19:04:43 2017 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Fri, 24 Mar 2017 15:04:43 -0400 Subject: BCP 38 coverage if top x providers ... In-Reply-To: <87k27eaf21.fsf@mid.deneb.enyo.de> References: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> <9EB78A78-CC71-4DBE-ABA6-4B05FB7E6496@puck.nether.net> <87k27eaf21.fsf@mid.deneb.enyo.de> Message-ID: Wouldn't you want BCP38 policies to be as close as possible to the traffic sources? Instead of creating more "fake" traffic? And at the same time, partial filtering doesn't seem as a very effective way to fight spoofed traffic on a large scale. On 03/24/2017 11:07 AM, Florian Weimer wrote: > * Jared Mauch: > >>> On Nov 19, 2016, at 9:13 PM, Frank Bulk wrote: >>> >>> My google fu is failing me, but I believe there was a NANOG posting a year >>> or two ago that mentioned that if the top x providers would >>> implement BCP 38 >>> then y% of the traffic (or Internet) would be de-spoofed. The point was >>> that we don't even need everyone to implement BCP 38, but if the largest >>> (transit?) providers did it, then UDP reflection attacks could be >>> minimized. >>> >>> If someone can recall the key words in that posting and dig it up, that >>> would be much appreciated. >> A double lookup of the packet is twice as expensive and perhaps >> impractical in some (or many) cases. > Do you actually have to filter all packets? > > Or could you just sample a subset and police the offenders, on the > assumption that if you don't implement an anti-spoofing policy, you > end up with near-constant leakage? From fw at deneb.enyo.de Fri Mar 24 19:30:53 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 24 Mar 2017 20:30:53 +0100 Subject: BCP 38 coverage if top x providers ... In-Reply-To: (Laurent Dumont's message of "Fri, 24 Mar 2017 15:04:43 -0400") References: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> <9EB78A78-CC71-4DBE-ABA6-4B05FB7E6496@puck.nether.net> <87k27eaf21.fsf@mid.deneb.enyo.de> Message-ID: <8737e2wjyq.fsf@mid.deneb.enyo.de> * Laurent Dumont: > Wouldn't you want BCP38 policies to be as close as possible to the > traffic sources? Instead of creating more "fake" traffic? Maybe as close as possible, but still without sacrificing source network attribution is sufficient. > And at the same time, partial filtering doesn't seem as a very > effective way to fight spoofed traffic on a large scale. That depends on the problems caused by spoofed traffic. My hunch is that non-policing networks emit a constant trickle of spoofed traffic which does not cause any problems, and that traffic can be used to detect lack of policing even without actual abuse of the spoofing capability. From piotr.1234 at interia.pl Sat Mar 25 10:00:02 2017 From: piotr.1234 at interia.pl (Pedro) Date: Sat, 25 Mar 2017 11:00:02 +0100 Subject: How to secure link between switches in Layer2 Message-ID: Hello, Sometimes i have situation that i have to extend my layer2 (access, trunk mode) network to third parties with limited trust. Sometimes it's L2 MPLS links from isp (1x or 2x), sometimes it's just colocated switch. Mostly there are Juniper Ex4200/4300 or and Cisco 3750. Below i puts my config but maybe i miss something important ? Or i should correct ? Thanks for help 1. If two p2p links: aggregation with LACP 2. stp/rstp in portfast mode on access port stp/rstp without portfast mode on trunk port rstp root guard 3. on ports facing servers, in portfast mode, bpdu guard spanning-tree root guard 4. max amount of mac addresses ie 100 per port per vlan max mac address 5. 802.1q with vlans, but not vlan 1 6. broadcast storm for bum packets: 10 pps 7. static ip - no dhcp servers/clients in vlans 8. cpu monitoring with notification in ie zabbix 9. cdp disable (if cisco) dtp disable (if cisco) 10. eventually policer per port or per vlan. thanks in advance, Pedro From contact at winterei.se Sat Mar 25 12:21:22 2017 From: contact at winterei.se (Paul S.) Date: Sat, 25 Mar 2017 21:21:22 +0900 Subject: How to secure link between switches in Layer2 In-Reply-To: References: Message-ID: <3a2d8bd5-e1f0-a4aa-c231-a873f6898d7d@winterei.se> What exactly does "limited trust" mean? Are you worried they might sniff the data on the link, or? If so, macsec is really your only remedy. On 3/25/2017 07:00 PM, Pedro wrote: > Hello, > > Sometimes i have situation that i have to extend my layer2 (access, > trunk mode) network to third parties with limited trust. Sometimes > it's L2 MPLS links from isp (1x or 2x), sometimes it's just colocated > switch. Mostly there are Juniper Ex4200/4300 or and Cisco 3750. Below > i puts my config but maybe i miss something important ? Or i should > correct ? > > Thanks for help > > > 1. > If two p2p links: aggregation with LACP > > 2. > stp/rstp in portfast mode on access port > stp/rstp without portfast mode on trunk port > rstp root guard > > 3. > on ports facing servers, in portfast mode, bpdu guard > spanning-tree root guard > > 4. > max amount of mac addresses ie 100 > per port per vlan max mac address > > 5. > 802.1q with vlans, but not vlan 1 > > 6. > broadcast storm for bum packets: 10 pps > > > 7. > static ip - no dhcp servers/clients in vlans > > 8. > cpu monitoring with notification in ie zabbix > > 9. > cdp disable (if cisco) > dtp disable (if cisco) > > 10. > eventually policer per port or per vlan. > > > > thanks in advance, > Pedro > From piotr.1234 at interia.pl Sat Mar 25 13:21:44 2017 From: piotr.1234 at interia.pl (Pedro) Date: Sat, 25 Mar 2017 14:21:44 +0100 Subject: How to secure link between switches in Layer2 In-Reply-To: <3a2d8bd5-e1f0-a4aa-c231-a873f6898d7d@winterei.se> References: <3a2d8bd5-e1f0-a4aa-c231-a873f6898d7d@winterei.se> Message-ID: I mean loop, flood, high cpu because tcn/tca etc IMHO sniffing is not a case in my scenario, i suppose but i'll remember this W dniu 2017-03-25 o 13:21, Paul S. pisze: > What exactly does "limited trust" mean? > > Are you worried they might sniff the data on the link, or? > > If so, macsec is really your only remedy. > > On 3/25/2017 07:00 PM, Pedro wrote: >> Hello, >> >> Sometimes i have situation that i have to extend my layer2 (access, >> trunk mode) network to third parties with limited trust. Sometimes >> it's L2 MPLS links from isp (1x or 2x), sometimes it's just colocated >> switch. Mostly there are Juniper Ex4200/4300 or and Cisco 3750. Below >> i puts my config but maybe i miss something important ? Or i should >> correct ? >> >> Thanks for help >> >> >> 1. >> If two p2p links: aggregation with LACP >> >> 2. >> stp/rstp in portfast mode on access port >> stp/rstp without portfast mode on trunk port >> rstp root guard >> >> 3. >> on ports facing servers, in portfast mode, bpdu guard >> spanning-tree root guard >> >> 4. >> max amount of mac addresses ie 100 >> per port per vlan max mac address >> >> 5. >> 802.1q with vlans, but not vlan 1 >> >> 6. >> broadcast storm for bum packets: 10 pps >> >> >> 7. >> static ip - no dhcp servers/clients in vlans >> >> 8. >> cpu monitoring with notification in ie zabbix >> >> 9. >> cdp disable (if cisco) >> dtp disable (if cisco) >> >> 10. >> eventually policer per port or per vlan. >> >> >> >> thanks in advance, >> Pedro >> > > From pde at eff.org Sun Mar 26 23:05:34 2017 From: pde at eff.org (Peter Eckersley) Date: Sun, 26 Mar 2017 16:05:34 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Message-ID: <20170326230534.GA2707@eff.org> Dear network operators, I'm sure this is a controversial topic in the NANOG community, but EFF and a number of ISPs and networking companies are writing to Congress opposing the repeal of the FCC's broadband privacy rules, which require explicit opt-in consent before ISPs use or sell sensitive, non-anonymized data (including non-anonymized locations and browsing histories). If you or your employer would like to sign on to such a letter, please reply off-list by midday Monday with your name, and a one-sentence description of your affiliation and/or major career accomplishments. Back story on what's happening: https://www.eff.org/deeplinks/2017/03/five-creepy-things-your-isp-could-do-if-congress-repeals-fccs-privacy-protections https://www.eff.org/deeplinks/2017/03/senate-puts-isp-profits-over-your-privacy https://www.eff.org/deeplinks/2017/02/congress-contemplating-making-it-illegal-protect-consumer-privacy-online Summary of the FCC Broadband Privacy Rules themselves: https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-148A1.pdf -- Peter Eckersley pde at eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From starwars1070 at gmail.com Mon Mar 27 19:16:09 2017 From: starwars1070 at gmail.com (Samual Carman) Date: Mon, 27 Mar 2017 19:16:09 +0000 (UTC) Subject: VPS plus email Message-ID: <866A708316568DC5.17A4554D-95E9-4957-BF31-EF2404BAE8E5@mail.outlook.com> Howdy y'all?I would like to know if if anyone can recommend a good VPS to run a exchange server as well as host a website?I would like to set up an exchange server with a ?professional?email address unless you guys can recommend a different approach I should take to get a?professional????address so it would look better on resumes etc and I can consolidate all my various email accounts to one?I could consider switching to google apps and or Microsoft outlook unless there are other better providers out there?I am in college so if there are any special programs please feel free to advice me of such?Feel free to private message me? Not sure if this is allowed the rules where murkey on this? Get Outlook for iOS From mike.lyon at gmail.com Mon Mar 27 19:22:42 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Mon, 27 Mar 2017 12:22:42 -0700 Subject: VPS plus email In-Reply-To: <866A708316568DC5.17A4554D-95E9-4957-BF31-EF2404BAE8E5@mail.outlook.com> References: <866A708316568DC5.17A4554D-95E9-4957-BF31-EF2404BAE8E5@mail.outlook.com> Message-ID: <5764D40D-B577-457B-888B-030E662F2EA7@gmail.com> Keep it simple. Google Apps. > On Mar 27, 2017, at 12:16, Samual Carman wrote: > > Howdy y'all I would like to know if if anyone can recommend a good VPS to run a exchange server as well as host a website I would like to set up an exchange server with a professional email address unless you guys can recommend a different approach I should take to get a professional address so it would look better on resumes etc and I can consolidate all my various email accounts to one I could consider switching to google apps and or Microsoft outlook unless there are other better providers out there I am in college so if there are any special programs please feel free to advice me of such Feel free to private message me > Not sure if this is allowed the rules where murkey on this > Get Outlook for iOS From aaron at heyaaron.com Mon Mar 27 19:27:30 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 27 Mar 2017 12:27:30 -0700 Subject: VPS plus email In-Reply-To: <866A708316568DC5.17A4554D-95E9-4957-BF31-EF2404BAE8E5@mail.outlook.com> References: <866A708316568DC5.17A4554D-95E9-4957-BF31-EF2404BAE8E5@mail.outlook.com> Message-ID: Easy solution if you don't know how to configure e-mail: Google Apps for Business. $5/user/month. Cheaper solution than Exchange: $5/mo Digital Ocean server running something like Dovecot and Haraka to handle e-mail. If you don't want to leave Microsoft, I believe Outlook premium will do what you want: https://premium.outlook.com/ Or pony up for Office 365. -A On Mon, Mar 27, 2017 at 12:16 PM, Samual Carman wrote: > Howdy y'all I would like to know if if anyone can recommend a good VPS to run a exchange server as well as host a website I would like to set up an exchange server with a professional email address unless you guys can recommend a different approach I should take to get a professional address so it would look better on resumes etc and I can consolidate all my various email accounts to one I could consider switching to google apps and or Microsoft outlook unless there are other better providers out there I am in college so if there are any special programs please feel free to advice me of such Feel free to private message me > Not sure if this is allowed the rules where murkey on this > Get Outlook for iOS From jcurran at arin.net Mon Mar 27 19:52:08 2017 From: jcurran at arin.net (John Curran) Date: Mon, 27 Mar 2017 19:52:08 +0000 Subject: Fwd: [ARIN-consult] Community Consultation on CKN23-ARIN Now Open References: Message-ID: <489E58D6-D674-4AD0-A243-3B9E28FCF2E6@arin.net> NANOGers - We have initiated a community consultation on a possible restructuring of existing information in the ARIN registry ? this is to address the long-standing concern that some have expressed with the association of a ?No Contact Known? point-of-contact (POC) in some registry records that may have potentially valid Admin and Tech contact information. If you have hold a strong view on this matter, please see the attached consultation announcement and participate in the discussion on the open arin-consult at arin.net mailing list Thanks! /John John Curran President and CEO ARIN === Begin forwarded message: From: ARIN > Subject: [ARIN-consult] Community Consultation on CKN23-ARIN Now Open Date: 22 March 2017 at 1:24:12 PM EDT To: > There are thousands of instances of the ARIN Point of Contact (POC) handle ?No, Contact Known? or CKN23-ARIN registered in the ARIN database, most of them associated with legacy resource records. ARIN would like the community to review the history of this situation and the proposed solution and provide us with their feedback. The creation and addition of this POC handle was due to a combination of factors. * In 2002, a database conversion project was done at ARIN that created a new database structure and added a new record type (Organization ID) as well as new POC types (Admin, Tech, Abuse and NOC). When an Org ID didn?t have a clear POC that had been recently updated or vetted by ARIN staff, the original resource POC remained on the resource record only and no POCs were added to the Org record at all. * In a later 2011 database conversion, reverse DNS delegation switched from per-net to per-zone. This created significant hijacking potential by allowing resource POCs to change their reverse delegation without first being verified by staff as legitimate. * Also in 2011, ARIN added a new business rule that required an Admin and a Tech POC on all Org records as a way of enhancing data quality. * Policy 2010-14 was implemented in 2011 and required Abuse POCs on all Org records. In order to maintain ARIN?s business rules, comply with policy 2010-14, and prevent hijackings, several actions were initiated by staff: * CKN23-ARIN was created to become the Admin and Tech POC on Orgs that lacked them * Resource POCs of legacy networks that had never been updated or validated by ARIN were moved to the Organization record as the Abuse POC * ARIN?s verification and vetting requirements were thus reinstated as the Abuse POC had to be vetted before making any changes to the record, and therefore could not hijack the resource by adding or changing the nameservers Over time, the above actions have created several issues: * It is easy for hijackers to identify and target records with CKN23 (no contact known) as the handle * POCs that were moved from resource tech to Org abuse are not happy about no longer having control of their resource record There are several different courses of action that ARIN could take to resolve the current situation. Option 1 Retain the current status and do nothing Option 2 Restore the resource POCs back to their original state on the resource record keeping in mind that this would open up the hijacking risk by giving the original resource POC control of the network without a verification process * Retain the Abuse POC on the Org record * Retain CKN23-ARIN as Org POC Option 3 - **Recommended option** Restore the resource POC back to their original state on the resource record. This will allow contacts historically associated with a resource record to more readily administer that record going forward. * Retain the Abuse POC on the Org * Replace CKN23-ARIN with a handle that better explains the record?s status (e.g. ?Legacy Record ? See Resource POC?) * Lock all resources associated with these legacy records who have had their resource POC restored. This would ensure that any changes made by the resource POC would first have to be reviewed by ARIN. We would like to thank the ARIN Services Working Group (WG) for their helpful review of the proposed change ? while the ARIN Services WG did not take a formal position in support of or in opposition of the proposed change, their review led to improvements in presentation of the options We are seeking community feedback on this proposed change (Option #3) to the ARIN Registry database. This consultation will remain open for 60 days - Please provide comments to arin-consult at arin.net. Discussion on arin-consult at arin.net will close on 22 May 2017. If you have any questions, please contact us at info at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From nanog at brettglass.com Mon Mar 27 23:13:46 2017 From: nanog at brettglass.com (Brett Glass) Date: Mon, 27 Mar 2017 17:13:46 -0600 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <20170326230534.GA2707@eff.org> References: <20170326230534.GA2707@eff.org> Message-ID: <201703272314.RAA11157@mail.lariat.net> All: It's worth noting that most of EFF's list consists of individuals and/or politically connected organizations, not actual ISPs. This is for good reason. EFF was founded with the intention of creating a civil rights organization but has morphed into a captive corporate lobbying shop for Google, to which several of its board members have close financial ties. EFF opposes the interests of hard working ISPs and routinely denigrates them and attempts to foster promotes hatred of them. It also promotes and lobbies for regulations which advantage Google and disadvantage ISPs -- including the so-called "broadband privacy" regulations, which heavily burden ISPs while exempting Google from all oversight. No knowledgeable network professional or ISP would support the current FCC rules. Both they AND the FCC's illegal Title II classification of ISPs must be rolled back, restoring the FTC's ability to apply uniform and apolitical privacy standards to all of the players in the Internet ecosystem. The first step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution which would revoke the current FCC regulations that were written and paid for by Google and its lobbyists. So, DO contact your legislators... but do so in support of the resolutions that will repeal the regulations. It is vital to the future of the Internet. --Brett Glass, Owner and Founder, LARIAT.NET At 05:05 PM 3/26/2017, Peter Eckersley wrote: >Dear network operators, > >I'm sure this is a controversial topic in the NANOG community, but EFF and a >number of ISPs and networking companies are writing to Congress opposing the >repeal of the FCC's broadband privacy rules, which require explicit opt-in >consent before ISPs use or sell sensitive, non-anonymized data (including >non-anonymized locations and browsing histories). > >If you or your employer would like to sign on to such a letter, please reply >off-list by midday Monday with your name, and a one-sentence description of >your affiliation and/or major career accomplishments. From patrick at ianai.net Mon Mar 27 23:22:27 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 27 Mar 2017 19:22:27 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <201703272314.RAA11157@mail.lariat.net> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> Message-ID: <3212EB8D-2944-486B-A681-B78066BD9F3E@ianai.net> I am somehow please that Mr. Glass does not find me a ?knowledgeable network professional?. It feels like a badge of honor. Any other ?not? knowledgeable network professionals want to come forward and accept this badge? Personally, I find the FCC?s current rules to be sub-optimal. But saying a gov?t regulation is sub-optimal is like saying water is wet. The question is not whether the regulation could be improved. It is whether the proposed changes are an improvement. To be 10000% clear: I prefer the current privacy regime over the new one being proposed. Oh, and I do not believe the EFF is just a shill for Google. But then, I?m just a not knowledgeable network professional, so what do I know? -- TTFN, patrick > On Mar 27, 2017, at 7:13 PM, Brett Glass wrote: > > All: > > It's worth noting that most of EFF's list consists of individuals and/or politically connected organizations, not actual ISPs. This is for good reason. EFF was founded with the intention of creating a civil rights organization but has morphed into a captive corporate lobbying shop for Google, to which several of its board members have close financial ties. EFF opposes the interests of hard working ISPs and routinely denigrates them and attempts to foster promotes hatred of them. It also promotes and lobbies for regulations which advantage Google and disadvantage ISPs -- including the so-called "broadband privacy" regulations, which heavily burden ISPs while exempting Google from all oversight. > > No knowledgeable network professional or ISP would support the current FCC rules. Both they AND the FCC's illegal Title II classification of ISPs must be rolled back, restoring the FTC's ability to apply uniform and apolitical privacy standards to all of the players in the Internet ecosystem. The first step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution which would revoke the current FCC regulations that were written and paid for by Google and its lobbyists. So, DO contact your legislators... but do so in support of the resolutions that will repeal the regulations. It is vital to the future of the Internet. > > --Brett Glass, Owner and Founder, LARIAT.NET > > At 05:05 PM 3/26/2017, Peter Eckersley wrote: > >> Dear network operators, >> >> I'm sure this is a controversial topic in the NANOG community, but EFF and a >> number of ISPs and networking companies are writing to Congress opposing the >> repeal of the FCC's broadband privacy rules, which require explicit opt-in >> consent before ISPs use or sell sensitive, non-anonymized data (including >> non-anonymized locations and browsing histories). >> >> If you or your employer would like to sign on to such a letter, please reply >> off-list by midday Monday with your name, and a one-sentence description of >> your affiliation and/or major career accomplishments. From nanog at ics-il.net Tue Mar 28 12:33:21 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Mar 2017 07:33:21 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <3212EB8D-2944-486B-A681-B78066BD9F3E@ianai.net> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3212EB8D-2944-486B-A681-B78066BD9F3E@ianai.net> Message-ID: <1577761502.4254.1490704396224.JavaMail.mhammett@ThunderFuck> Many organizations clamor the FCC for regulation because they hate something about the top 10, 20, etc. ISPs. There is certainly something to hate about them, but almost every time, the baby gets thrown out with the bath water and little ISPs are harmed along the way. Extremes on both sides are what get attention, meanwhile nothing constructive for little ISPs gets done. The policy community forgets them. That same sort of forget about the little guys happens in technical discussions in NANOG as well. Most ISPs and most web hosts have less than 1G of upstream and likely from a single provider. The technical community forgets them. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Monday, March 27, 2017 6:22:27 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal I am somehow please that Mr. Glass does not find me a ?knowledgeable network professional?. It feels like a badge of honor. Any other ?not? knowledgeable network professionals want to come forward and accept this badge? Personally, I find the FCC?s current rules to be sub-optimal. But saying a gov?t regulation is sub-optimal is like saying water is wet. The question is not whether the regulation could be improved. It is whether the proposed changes are an improvement. To be 10000% clear: I prefer the current privacy regime over the new one being proposed. Oh, and I do not believe the EFF is just a shill for Google. But then, I?m just a not knowledgeable network professional, so what do I know? -- TTFN, patrick > On Mar 27, 2017, at 7:13 PM, Brett Glass wrote: > > All: > > It's worth noting that most of EFF's list consists of individuals and/or politically connected organizations, not actual ISPs. This is for good reason. EFF was founded with the intention of creating a civil rights organization but has morphed into a captive corporate lobbying shop for Google, to which several of its board members have close financial ties. EFF opposes the interests of hard working ISPs and routinely denigrates them and attempts to foster promotes hatred of them. It also promotes and lobbies for regulations which advantage Google and disadvantage ISPs -- including the so-called "broadband privacy" regulations, which heavily burden ISPs while exempting Google from all oversight. > > No knowledgeable network professional or ISP would support the current FCC rules. Both they AND the FCC's illegal Title II classification of ISPs must be rolled back, restoring the FTC's ability to apply uniform and apolitical privacy standards to all of the players in the Internet ecosystem. The first step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution which would revoke the current FCC regulations that were written and paid for by Google and its lobbyists. So, DO contact your legislators... but do so in support of the resolutions that will repeal the regulations. It is vital to the future of the Internet. > > --Brett Glass, Owner and Founder, LARIAT.NET > > At 05:05 PM 3/26/2017, Peter Eckersley wrote: > >> Dear network operators, >> >> I'm sure this is a controversial topic in the NANOG community, but EFF and a >> number of ISPs and networking companies are writing to Congress opposing the >> repeal of the FCC's broadband privacy rules, which require explicit opt-in >> consent before ISPs use or sell sensitive, non-anonymized data (including >> non-anonymized locations and browsing histories). >> >> If you or your employer would like to sign on to such a letter, please reply >> off-list by midday Monday with your name, and a one-sentence description of >> your affiliation and/or major career accomplishments. From patrick at ianai.net Tue Mar 28 13:56:04 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 28 Mar 2017 09:56:04 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <1577761502.4254.1490704396224.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3212EB8D-2944-486B-A681-B78066BD9F3E@ianai.net> <1577761502.4254.1490704396224.JavaMail.mhammett@ThunderFuck> Message-ID: <965B4ACD-16C1-41F9-8EF8-9A25162FCF3B@ianai.net> Having worked networks with massive bandwidth, networks with a single T1 (don?t ask, just Google what a T1 is, er, was), and now being somewhere in the middle, I agree that the large guys sometimes forget the little guys exist. However, I think the change in privacy being proposed hurts -all- users, and disproportionately helps the large guys. A tiny ISP with < 1 Gbps upstream does not have enough user data to sell or otherwise ?monetize?, while the top 5-10 ISPs have a ready and willing market for their users? data. Which is why this is so strange. Mr. Glass? ISP isn?t even a nat on the ass of national broadband ISPs. Not an indictment, like I said, I?ve run tiny networks myself. However, this change does not help ISPs in his position. Yet he is claiming the EFF is fighting for the big guy by opposing this change. Color me confused. But then again, I am a not knowledgeable network professional, so I am probably just confused. -- TTFN, patrick > On Mar 28, 2017, at 8:33 AM, Mike Hammett wrote: > > Many organizations clamor the FCC for regulation because they hate something about the top 10, 20, etc. ISPs. There is certainly something to hate about them, but almost every time, the baby gets thrown out with the bath water and little ISPs are harmed along the way. Extremes on both sides are what get attention, meanwhile nothing constructive for little ISPs gets done. The policy community forgets them. > > That same sort of forget about the little guys happens in technical discussions in NANOG as well. Most ISPs and most web hosts have less than 1G of upstream and likely from a single provider. The technical community forgets them. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Monday, March 27, 2017 6:22:27 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > I am somehow please that Mr. Glass does not find me a ?knowledgeable network professional?. It feels like a badge of honor. Any other ?not? knowledgeable network professionals want to come forward and accept this badge? > > Personally, I find the FCC?s current rules to be sub-optimal. But saying a gov?t regulation is sub-optimal is like saying water is wet. The question is not whether the regulation could be improved. It is whether the proposed changes are an improvement. > > To be 10000% clear: I prefer the current privacy regime over the new one being proposed. > > Oh, and I do not believe the EFF is just a shill for Google. But then, I?m just a not knowledgeable network professional, so what do I know? > > -- > TTFN, > patrick > >> On Mar 27, 2017, at 7:13 PM, Brett Glass wrote: >> >> All: >> >> It's worth noting that most of EFF's list consists of individuals and/or politically connected organizations, not actual ISPs. This is for good reason. EFF was founded with the intention of creating a civil rights organization but has morphed into a captive corporate lobbying shop for Google, to which several of its board members have close financial ties. EFF opposes the interests of hard working ISPs and routinely denigrates them and attempts to foster promotes hatred of them. It also promotes and lobbies for regulations which advantage Google and disadvantage ISPs -- including the so-called "broadband privacy" regulations, which heavily burden ISPs while exempting Google from all oversight. >> >> No knowledgeable network professional or ISP would support the current FCC rules. Both they AND the FCC's illegal Title II classification of ISPs must be rolled back, restoring the FTC's ability to apply uniform and apolitical privacy standards to all of the players in the Internet ecosystem. The first step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution which would revoke the current FCC regulations that were written and paid for by Google and its lobbyists. So, DO contact your legislators... but do so in support of the resolutions that will repeal the regulations. It is vital to the future of the Internet. >> >> --Brett Glass, Owner and Founder, LARIAT.NET >> >> At 05:05 PM 3/26/2017, Peter Eckersley wrote: >> >>> Dear network operators, >>> >>> I'm sure this is a controversial topic in the NANOG community, but EFF and a >>> number of ISPs and networking companies are writing to Congress opposing the >>> repeal of the FCC's broadband privacy rules, which require explicit opt-in >>> consent before ISPs use or sell sensitive, non-anonymized data (including >>> non-anonymized locations and browsing histories). >>> >>> If you or your employer would like to sign on to such a letter, please reply >>> off-list by midday Monday with your name, and a one-sentence description of >>> your affiliation and/or major career accomplishments. > From pozar at kumr.lns.com Mon Mar 27 23:34:40 2017 From: pozar at kumr.lns.com (Tim Pozar) Date: Mon, 27 Mar 2017 16:34:40 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <3212EB8D-2944-486B-A681-B78066BD9F3E@ianai.net> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3212EB8D-2944-486B-A681-B78066BD9F3E@ianai.net> Message-ID: <20170327233440.GA2156@lns.com> On 3/27/17 4:22 PM, Patrick W. Gilmore wrote: > I am somehow please that Mr. Glass does not find me a ?knowledgeable > network professional?. It feels like a badge of honor. Any other ?not? > knowledgeable network professionals want to come forward and accept > this badge? You will find me as cosignatory to the EFF's letter seen at: https://www.eff.org/deeplinks/2017/03/small-isps-oppose-congressess-move-abolish-privacy-protections Not like I have any experience running an ISP, Datacenter, Content provider, anti-spam provider, etc... Tim From rod.beck at unitedcablecompany.com Tue Mar 28 17:39:55 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 28 Mar 2017 17:39:55 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <201703272314.RAA11157@mail.lariat.net> References: <20170326230534.GA2707@eff.org>, <201703272314.RAA11157@mail.lariat.net> Message-ID: Last time I checked most European countries have stronger privacy protections than the US. Are they also idiots? Mr. Glass, would you care to respond? Regards, Roderick. ________________________________ From: NANOG on behalf of Brett Glass Sent: Tuesday, March 28, 2017 1:13 AM To: nanog at nanog.org Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal All: It's worth noting that most of EFF's list consists of individuals and/or politically connected organizations, not actual ISPs. This is for good reason. EFF was founded with the intention of creating a civil rights organization but has morphed into a captive corporate lobbying shop for Google, to which several of its board members have close financial ties. EFF opposes the interests of hard working ISPs and routinely denigrates them and attempts to foster promotes hatred of them. It also promotes and lobbies for regulations which advantage Google and disadvantage ISPs -- including the so-called "broadband privacy" regulations, which heavily burden ISPs while exempting Google from all oversight. No knowledgeable network professional or ISP would support the current FCC rules. Both they AND the FCC's illegal Title II classification of ISPs must be rolled back, restoring the FTC's ability to apply uniform and apolitical privacy standards to all of the players in the Internet ecosystem. The first step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution which would revoke the current FCC regulations that were written and paid for by Google and its lobbyists. So, DO contact your legislators... but do so in support of the resolutions that will repeal the regulations. It is vital to the future of the Internet. --Brett Glass, Owner and Founder, LARIAT.NET At 05:05 PM 3/26/2017, Peter Eckersley wrote: >Dear network operators, > >I'm sure this is a controversial topic in the NANOG community, but EFF and a >number of ISPs and networking companies are writing to Congress opposing the >repeal of the FCC's broadband privacy rules, which require explicit opt-in >consent before ISPs use or sell sensitive, non-anonymized data (including >non-anonymized locations and browsing histories). > >If you or your employer would like to sign on to such a letter, please reply >off-list by midday Monday with your name, and a one-sentence description of >your affiliation and/or major career accomplishments. From mel at beckman.org Tue Mar 28 18:45:04 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 28 Mar 2017 18:45:04 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org>, <201703272314.RAA11157@mail.lariat.net>, Message-ID: No ISPs have any right to market our customers browsing history, and currently that practice is illegal unless the customer opts in. In my opinion, only a fool wants to relieve ISPs of this restriction. The claim oft presented by people favoring this customer abuse is that the sold data is anonymous. But it's been well-established that very simple data aggregation techniques can develop signatures that reveal the identity of people in anonymized data. -mel beckman > On Mar 28, 2017, at 10:40 AM, Rod Beck wrote: > > Last time I checked most European countries have stronger privacy protections than the US. Are they also idiots? Mr. Glass, would you care to respond? > > > Regards, > > > Roderick. > > > ________________________________ > From: NANOG on behalf of Brett Glass > Sent: Tuesday, March 28, 2017 1:13 AM > To: nanog at nanog.org > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > All: > > It's worth noting that most of EFF's list consists of individuals > and/or politically connected organizations, not actual ISPs. This > is for good reason. EFF was founded with the intention of creating > a civil rights organization but has morphed into a captive > corporate lobbying shop for Google, to which several of its board > members have close financial ties. EFF opposes the interests of > hard working ISPs and routinely denigrates them and attempts to > foster promotes hatred of them. It also promotes and lobbies for > regulations which advantage Google and disadvantage ISPs -- > including the so-called "broadband privacy" regulations, which > heavily burden ISPs while exempting Google from all oversight. > > No knowledgeable network professional or ISP would support the > current FCC rules. Both they AND the FCC's illegal Title II > classification of ISPs must be rolled back, restoring the FTC's > ability to apply uniform and apolitical privacy standards to all of > the players in the Internet ecosystem. The first step is to support > S.J. Res 34/H.J. Res 86, the Congressional resolution which would > revoke the current FCC regulations that were written and paid for > by Google and its lobbyists. So, DO contact your legislators... > but do so in support of the resolutions that will repeal the > regulations. It is vital to the future of the Internet. > > --Brett Glass, Owner and Founder, LARIAT.NET > > At 05:05 PM 3/26/2017, Peter Eckersley wrote: > >> Dear network operators, >> >> I'm sure this is a controversial topic in the NANOG community, but EFF and a >> number of ISPs and networking companies are writing to Congress opposing the >> repeal of the FCC's broadband privacy rules, which require explicit opt-in >> consent before ISPs use or sell sensitive, non-anonymized data (including >> non-anonymized locations and browsing histories). >> >> If you or your employer would like to sign on to such a letter, please reply >> off-list by midday Monday with your name, and a one-sentence description of >> your affiliation and/or major career accomplishments. > From mel at beckman.org Tue Mar 28 19:53:05 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 28 Mar 2017 19:53:05 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> , <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> Message-ID: <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> Quoting an Alexa spokesperson: "We don't think we did anything wrong," Alexa Chief Executive Brewster Kahle said. "But instead of going all the way through the legal process, we thought this was the easiest way to go on with our business." ------ That capsulized the problem perfectly: providers don't get that they're doing anything wrong when they sell user's personal usage data. -mel via cell > On Mar 28, 2017, at 12:12 PM, Tim Pozar wrote: > > Alexa ran into this problem... > > https://www.cnet.com/news/amazon-unit-settles-privacy-lawsuit/ > > Tim > >> On 3/28/17 11:45 AM, Mel Beckman wrote: >> No ISPs have any right to market our customers browsing history, and currently that practice is illegal unless the customer opts in. In my opinion, only a fool wants to relieve ISPs of this restriction. >> >> The claim oft presented by people favoring this customer abuse is that the sold data is anonymous. But it's been well-established that very simple data aggregation techniques can develop signatures that reveal the identity of people in anonymized data. >> >> -mel beckman >> >>> On Mar 28, 2017, at 10:40 AM, Rod Beck wrote: >>> >>> Last time I checked most European countries have stronger privacy protections than the US. Are they also idiots? Mr. Glass, would you care to respond? >>> >>> >>> Regards, >>> >>> >>> Roderick. >>> >>> >>> ________________________________ >>> From: NANOG on behalf of Brett Glass >>> Sent: Tuesday, March 28, 2017 1:13 AM >>> To: nanog at nanog.org >>> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >>> >>> All: >>> >>> It's worth noting that most of EFF's list consists of individuals >>> and/or politically connected organizations, not actual ISPs. This >>> is for good reason. EFF was founded with the intention of creating >>> a civil rights organization but has morphed into a captive >>> corporate lobbying shop for Google, to which several of its board >>> members have close financial ties. EFF opposes the interests of >>> hard working ISPs and routinely denigrates them and attempts to >>> foster promotes hatred of them. It also promotes and lobbies for >>> regulations which advantage Google and disadvantage ISPs -- >>> including the so-called "broadband privacy" regulations, which >>> heavily burden ISPs while exempting Google from all oversight. >>> >>> No knowledgeable network professional or ISP would support the >>> current FCC rules. Both they AND the FCC's illegal Title II >>> classification of ISPs must be rolled back, restoring the FTC's >>> ability to apply uniform and apolitical privacy standards to all of >>> the players in the Internet ecosystem. The first step is to support >>> S.J. Res 34/H.J. Res 86, the Congressional resolution which would >>> revoke the current FCC regulations that were written and paid for >>> by Google and its lobbyists. So, DO contact your legislators... >>> but do so in support of the resolutions that will repeal the >>> regulations. It is vital to the future of the Internet. >>> >>> --Brett Glass, Owner and Founder, LARIAT.NET >>> >>> At 05:05 PM 3/26/2017, Peter Eckersley wrote: >>> >>>> Dear network operators, >>>> >>>> I'm sure this is a controversial topic in the NANOG community, but EFF and a >>>> number of ISPs and networking companies are writing to Congress opposing the >>>> repeal of the FCC's broadband privacy rules, which require explicit opt-in >>>> consent before ISPs use or sell sensitive, non-anonymized data (including >>>> non-anonymized locations and browsing histories). >>>> >>>> If you or your employer would like to sign on to such a letter, please reply >>>> off-list by midday Monday with your name, and a one-sentence description of >>>> your affiliation and/or major career accomplishments. >>> From feld at feld.me Tue Mar 28 20:54:26 2017 From: feld at feld.me (Mark Felder) Date: Tue, 28 Mar 2017 15:54:26 -0500 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <201703272314.RAA11157@mail.lariat.net> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> Message-ID: <1490734466.2571282.926595512.50AB5465@webmail.messagingengine.com> On Mon, Mar 27, 2017, at 18:13, Brett Glass wrote: > The first step is to support > S.J. Res 34/H.J. Res 86, the Congressional resolution which would > revoke the current FCC regulations that were written and paid for > by Google and its lobbyists. Please keep conspiracy theories off the list, thanks. -- Mark Felder feld at feld.me From rsk at gsp.org Tue Mar 28 21:45:25 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 28 Mar 2017 17:45:25 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> Message-ID: <20170328214525.GA6357@gsp.org> On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: > The claim oft presented by people favoring this customer abuse is that > the sold data is anonymous. But it's been well-established that very > simple data aggregation techniques can develop signatures that reveal > the identity of people in anonymized data. This needs to be repeated loudly and often at every possible opportunity. I've spent much of the past decade studying this issue and the most succinct way I can put it is that however good you (generic "you") think de-anonymization techniques are, you're wrong: they're way better than that. Billions, and I am not exaggerating even a little bit, have been spent on this problem, and they've been spent by smart people with essentially unlimited computational resources. And whaddaya know, they've succeeded. So if someone presents you a data corpus and says "this data is anonymized", the default response should be to mock them, because there is a very high probability they're either (a) lying or (b) wrong. Incidentally, I'm also a signatory of the EFF document, since of course with nearly 40 years in the field I'm a mere clueless newbie and despite ripping them a new one about once every other month, I'm clearly a tool of Google. ---rsk From nanog at ics-il.net Tue Mar 28 21:58:22 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Mar 2017 16:58:22 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <20170328214525.GA6357@gsp.org> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <20170328214525.GA6357@gsp.org> Message-ID: <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> Why am I supposed to care? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Rich Kulawiec" To: nanog at nanog.org Sent: Tuesday, March 28, 2017 4:45:25 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: > The claim oft presented by people favoring this customer abuse is that > the sold data is anonymous. But it's been well-established that very > simple data aggregation techniques can develop signatures that reveal > the identity of people in anonymized data. This needs to be repeated loudly and often at every possible opportunity. I've spent much of the past decade studying this issue and the most succinct way I can put it is that however good you (generic "you") think de-anonymization techniques are, you're wrong: they're way better than that. Billions, and I am not exaggerating even a little bit, have been spent on this problem, and they've been spent by smart people with essentially unlimited computational resources. And whaddaya know, they've succeeded. So if someone presents you a data corpus and says "this data is anonymized", the default response should be to mock them, because there is a very high probability they're either (a) lying or (b) wrong. Incidentally, I'm also a signatory of the EFF document, since of course with nearly 40 years in the field I'm a mere clueless newbie and despite ripping them a new one about once every other month, I'm clearly a tool of Google. ---rsk From sethm at rollernet.us Tue Mar 28 22:51:43 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 28 Mar 2017 15:51:43 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> Message-ID: <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> On 3/28/17 12:53, Mel Beckman wrote: > Quoting an Alexa spokesperson: > > "We don't think we did anything wrong," Alexa Chief Executive Brewster Kahle said. "But instead of going all the way through the legal process, we thought this was the easiest way to go on with our business." > > ------ > > That capsulized the problem perfectly: providers don't get that they're doing anything wrong when they sell user's personal usage data. Has there ever been a real survey that asks people where they think Google gets the money to support things like Gmail for "free"? ~Seth From valdis.kletnieks at vt.edu Tue Mar 28 23:08:30 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 28 Mar 2017 19:08:30 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> Message-ID: <32365.1490742510@turing-police.cc.vt.edu> On Tue, 28 Mar 2017 15:51:43 -0700, Seth Mattinen said: > Has there ever been a real survey that asks people where they think > Google gets the money to support things like Gmail for "free"? There's a difference. Google only gets to aggregate data you pass to Google. Your ISP gets to aggregate data you pass to *anybody*. The difference matters. Consider this example from the EFF: "They know you spoke with an HIV testing service, then your doctor, then your health insurance company in the same hour. But they don't know what was discussed." And the ISP is in that same position of being able to see all 3, and allowing anybody they sell the data to, to make conclusions. https://www.eff.org/deeplinks/2013/06/why-metadata-matters -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From morrowc.lists at gmail.com Tue Mar 28 23:10:23 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 28 Mar 2017 17:10:23 -0600 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> Message-ID: On Tue, Mar 28, 2017 at 4:51 PM, Seth Mattinen wrote: > Has there ever been a real survey that asks people where they think Google > gets the money to support things like Gmail for "free"? doesn't their 10k say: "ads" ? From eric-list at truenet.com Tue Mar 28 23:17:25 2017 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 28 Mar 2017 19:17:25 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <32365.1490742510@turing-police.cc.vt.edu> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu> Message-ID: <1C81A891-367D-47E2-882A-92B7083D3A0C@truenet.com> > On Mar 28, 2017, at 7:08 PM, valdis.kletnieks at vt.edu wrote: > > On Tue, 28 Mar 2017 15:51:43 -0700, Seth Mattinen said: > >> Has there ever been a real survey that asks people where they think >> Google gets the money to support things like Gmail for "free"? > > There's a difference. Google only gets to aggregate data you pass to Google. > Your ISP gets to aggregate data you pass to *anybody*. The difference matters. > > Consider this example from the EFF: > > "They know you spoke with an HIV testing service, then your doctor, then your > health insurance company in the same hour. But they don't know what was > discussed." > > And the ISP is in that same position of being able to see all 3, and allowing > anybody they sell the data to, to make conclusions. > > https://www.eff.org/deeplinks/2013/06/why-metadata-matters My first thought was your 6 year old watching sesame street videos, and your 10 year old playing minecraft. Sounds like the various COPPA lawsuits that I?ve seen from the FTC lawsuits, but IANAL. From sethm at rollernet.us Tue Mar 28 23:25:41 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 28 Mar 2017 16:25:41 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <32365.1490742510@turing-police.cc.vt.edu> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu> Message-ID: On 3/28/17 16:08, valdis.kletnieks at vt.edu wrote: > On Tue, 28 Mar 2017 15:51:43 -0700, Seth Mattinen said: > >> Has there ever been a real survey that asks people where they think >> Google gets the money to support things like Gmail for "free"? > There's a difference. Google only gets to aggregate data you pass to Google. > Your ISP gets to aggregate data you pass to *anybody*. The difference matters. I know, I'm not picking on Google like the other post was, other than to bring up that point that a lot of non-technical people don't connect that free Gmail means something has to pay for it. When I talk to people they have this expectation of free internet because ISPs charging for internet access is greedy when most most everything online is free. The internet is just a nebulous thing out there that's "free". So ultimately you have ISPs that sell data to marketers so they can meet the demands from sales/marketing to offer $10 gigabit internet access with no contracts and free install. ~Seth From mel at beckman.org Wed Mar 29 00:17:40 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 00:17:40 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu>, Message-ID: <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> Seth, Hmmm... I hadn't heard about the $10 Internet access with no contracts and free installation. I'm pretty sure that's a complete fantasy, and that every ISP on the planet makes sure they get a tidy profit from the contract fees that lock in customers, with zero advertising income. Money from stealing user browser data is just gravy. Not that I'm opposed to gravy, but not when I, as a customer, don't get any. Now, if ISPs want to PURCHASE browser data from customers directly, I'm sure they'll get some takers. But that strategy has never appeared in any business plan I've seen. -mel beckman > On Mar 28, 2017, at 4:26 PM, Seth Mattinen wrote: > >> On 3/28/17 16:08, valdis.kletnieks at vt.edu wrote: >> On Tue, 28 Mar 2017 15:51:43 -0700, Seth Mattinen said: >> >>> Has there ever been a real survey that asks people where they think >>> Google gets the money to support things like Gmail for "free"? >> There's a difference. Google only gets to aggregate data you pass to Google. >> Your ISP gets to aggregate data you pass to *anybody*. The difference matters. > > > I know, I'm not picking on Google like the other post was, other than to bring up that point that a lot of non-technical people don't connect that free Gmail means something has to pay for it. When I talk to people they have this expectation of free internet because ISPs charging for internet access is greedy when most most everything online is free. The internet is just a nebulous thing out there that's "free". > > So ultimately you have ISPs that sell data to marketers so they can meet the demands from sales/marketing to offer $10 gigabit internet access with no contracts and free install. > > ~Seth From mel at beckman.org Wed Mar 29 00:22:40 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 00:22:40 +0000 Subject: Microsoft O365 labels nanog potential fraud? Message-ID: Is anyone else getting this message on every nanog post today? "This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing" I don't know if this link itself is malware, as it goes to the MS store, or if something is broken in the Nanog Mail machine. If it's just me, never mind. I'll figure it out. -mel beckman From sethm at rollernet.us Wed Mar 29 00:36:10 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 28 Mar 2017 17:36:10 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu> <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> Message-ID: <82381906-05d3-25fc-2c6d-4b0896675dc0@rollernet.us> On 3/28/17 17:17, Mel Beckman wrote: > > Hmmm... I hadn't heard about the $10 Internet access with no contracts and free installation. I'm pretty sure that's a complete fantasy, and that every ISP on the planet makes sure they get a tidy profit from the contract fees that lock in customers, with zero advertising income. Money from stealing user browser data is just gravy. Not that I'm opposed to gravy, but not when I, as a customer, don't get any. I'm mostly being speculatively facetious. All I can say for sure is they do that NXDOMAIN thing unless you opt out, good for 1 year only, so remember to renew your opt out annually. But I just don't use their resolvers. ~Seth From hugo at slabnet.com Wed Mar 29 00:56:25 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 28 Mar 2017 17:56:25 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu>, <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> Message-ID: <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> >Now, if ISPs want to PURCHASE browser data from customers directly, I'm >sure they'll get some takers. But that strategy has never appeared in >any business plan I've seen. https://arstechnica.com/information-technology/2013/12/att-offers-gigabit-internet-discount-in-exchange-for-your-web-history/ ? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal From mel at beckman.org Wed Mar 29 01:08:19 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 01:08:19 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu>, <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org>, <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> Message-ID: <12967433-3782-456E-8C03-23642CBD08EA@beckman.org> Hugo, That's a great find! I note in the article: "Not only is the price of the premier service (with ads) only $70 a month, but it comes with a waiver of equipment, installation, and activation fees. The standard service without ads is $99 a month..." So that's $29 a month to let AT&T track your Web browsing, but only for targeting ads. ATT promises "And we won?t sell your personal information to anyone, for any reason." I would guess that the ability to sell that data would be worth several times the $29/month, so it's conceivable that a provider could offer $10/mo Gig Internet in exchange for browsing history. But nobody does. Because they think they can steal it. I think this pretty well demonstrates the greed of the big-ISP executives who lobbied for today's legislative atrocity, which lets them rob customers of browsing history that even AT&T execs acknowledge users own. -mel beckman On Mar 28, 2017, at 5:56 PM, Hugo Slabbert > wrote: Now, if ISPs want to PURCHASE browser data from customers directly, I'm sure they'll get some takers. But that strategy has never appeared in any business plan I've seen. https://arstechnica.com/information-technology/2013/12/att-offers-gigabit-internet-discount-in-exchange-for-your-web-history/ ? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal From nanog at ics-il.net Wed Mar 29 01:13:39 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Mar 2017 20:13:39 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <12967433-3782-456E-8C03-23642CBD08EA@beckman.org> References: <20170326230534.GA2707@eff.org> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu> <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> <12967433-3782-456E-8C03-23642CBD08EA@beckman.org> Message-ID: <218026656.5058.1490750017625.JavaMail.mhammett@ThunderFuck> What about little ISPs? There are already monetization platforms out there that can be resold to small ISPs. The company sells the aggregate data upstream. Not that I would, but in a small ISP, that money makes a big difference. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" To: "Hugo Slabbert" Cc: nanog at nanog.org Sent: Tuesday, March 28, 2017 8:08:19 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Hugo, That's a great find! I note in the article: "Not only is the price of the premier service (with ads) only $70 a month, but it comes with a waiver of equipment, installation, and activation fees. The standard service without ads is $99 a month..." So that's $29 a month to let AT&T track your Web browsing, but only for targeting ads. ATT promises "And we won?t sell your personal information to anyone, for any reason." I would guess that the ability to sell that data would be worth several times the $29/month, so it's conceivable that a provider could offer $10/mo Gig Internet in exchange for browsing history. But nobody does. Because they think they can steal it. I think this pretty well demonstrates the greed of the big-ISP executives who lobbied for today's legislative atrocity, which lets them rob customers of browsing history that even AT&T execs acknowledge users own. -mel beckman On Mar 28, 2017, at 5:56 PM, Hugo Slabbert > wrote: Now, if ISPs want to PURCHASE browser data from customers directly, I'm sure they'll get some takers. But that strategy has never appeared in any business plan I've seen. https://arstechnica.com/information-technology/2013/12/att-offers-gigabit-internet-discount-in-exchange-for-your-web-history/ ? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal From mel at beckman.org Wed Mar 29 01:19:08 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 01:19:08 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <218026656.5058.1490750017625.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu> <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> <12967433-3782-456E-8C03-23642CBD08EA@beckman.org>, <218026656.5058.1490750017625.JavaMail.mhammett@ThunderFuck> Message-ID: <24B54AFC-1A4B-4B90-928F-204B31BB3484@beckman.org> What about bank robbery? Little ISPs could supplement their incomes using that immoral revenue stream too. The ends don't justify the means. Browsing history belongs to the user, not the ISP. Robbing users of this data is not justified just because it would give ISPs -- of any size -- a new revenue stream. -mel beckman > On Mar 28, 2017, at 6:14 PM, Mike Hammett wrote: > > What about little ISPs? There are already monetization platforms out there that can be resold to small ISPs. The company sells the aggregate data upstream. Not that I would, but in a small ISP, that money makes a big difference. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Hugo Slabbert" > Cc: nanog at nanog.org > Sent: Tuesday, March 28, 2017 8:08:19 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Hugo, > > That's a great find! I note in the article: > > "Not only is the price of the premier service (with ads) only $70 a month, but it comes with a waiver of equipment, installation, and activation fees. The standard service without ads is $99 a month..." > > So that's $29 a month to let AT&T track your Web browsing, but only for targeting ads. ATT promises "And we won?t sell your personal information to anyone, for any reason." > > I would guess that the ability to sell that data would be worth several times the $29/month, so it's conceivable that a provider could offer $10/mo Gig Internet in exchange for browsing history. > > But nobody does. > > Because they think they can steal it. > > I think this pretty well demonstrates the greed of the big-ISP executives who lobbied for today's legislative atrocity, which lets them rob customers of browsing history that even AT&T execs acknowledge users own. > > -mel beckman > > On Mar 28, 2017, at 5:56 PM, Hugo Slabbert > wrote: > > Now, if ISPs want to PURCHASE browser data from customers directly, I'm > sure they'll get some takers. But that strategy has never appeared in > any business plan I've seen. > > https://arstechnica.com/information-technology/2013/12/att-offers-gigabit-internet-discount-in-exchange-for-your-web-history/ ? > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > From nanog at ics-il.net Wed Mar 29 01:29:31 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Mar 2017 20:29:31 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <24B54AFC-1A4B-4B90-928F-204B31BB3484@beckman.org> References: <20170326230534.GA2707@eff.org> <32365.1490742510@turing-police.cc.vt.edu> <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> <12967433-3782-456E-8C03-23642CBD08EA@beckman.org> <218026656.5058.1490750017625.JavaMail.mhammett@ThunderFuck> <24B54AFC-1A4B-4B90-928F-204B31BB3484@beckman.org> Message-ID: <821551502.5065.1490750966965.JavaMail.mhammett@ThunderFuck> Yeah, I think we're done here. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Tuesday, March 28, 2017 8:19:08 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal What about bank robbery? Little ISPs could supplement their incomes using that immoral revenue stream too. The ends don't justify the means. Browsing history belongs to the user, not the ISP. Robbing users of this data is not justified just because it would give ISPs -- of any size -- a new revenue stream. -mel beckman > On Mar 28, 2017, at 6:14 PM, Mike Hammett wrote: > > What about little ISPs? There are already monetization platforms out there that can be resold to small ISPs. The company sells the aggregate data upstream. Not that I would, but in a small ISP, that money makes a big difference. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Mel Beckman" > To: "Hugo Slabbert" > Cc: nanog at nanog.org > Sent: Tuesday, March 28, 2017 8:08:19 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Hugo, > > That's a great find! I note in the article: > > "Not only is the price of the premier service (with ads) only $70 a month, but it comes with a waiver of equipment, installation, and activation fees. The standard service without ads is $99 a month..." > > So that's $29 a month to let AT&T track your Web browsing, but only for targeting ads. ATT promises "And we won?t sell your personal information to anyone, for any reason." > > I would guess that the ability to sell that data would be worth several times the $29/month, so it's conceivable that a provider could offer $10/mo Gig Internet in exchange for browsing history. > > But nobody does. > > Because they think they can steal it. > > I think this pretty well demonstrates the greed of the big-ISP executives who lobbied for today's legislative atrocity, which lets them rob customers of browsing history that even AT&T execs acknowledge users own. > > -mel beckman > > On Mar 28, 2017, at 5:56 PM, Hugo Slabbert > wrote: > > Now, if ISPs want to PURCHASE browser data from customers directly, I'm > sure they'll get some takers. But that strategy has never appeared in > any business plan I've seen. > > https://arstechnica.com/information-technology/2013/12/att-offers-gigabit-internet-discount-in-exchange-for-your-web-history/ ? > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > From patrick at ianai.net Wed Mar 29 02:12:15 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 28 Mar 2017 22:12:15 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> Message-ID: <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> Mike: My guess is you do not. Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. Later in this thread you said ?we are done here?. Would that you were so lucky. -- TTFN, patrick > On Mar 28, 2017, at 5:58 PM, Mike Hammett wrote: > > Why am I supposed to care? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Rich Kulawiec" > To: nanog at nanog.org > Sent: Tuesday, March 28, 2017 4:45:25 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >> The claim oft presented by people favoring this customer abuse is that >> the sold data is anonymous. But it's been well-established that very >> simple data aggregation techniques can develop signatures that reveal >> the identity of people in anonymized data. > > This needs to be repeated loudly and often at every possible opportunity. > I've spent much of the past decade studying this issue and the most succinct > way I can put it is that however good you (generic "you") think > de-anonymization techniques are, you're wrong: they're way better than that. > Billions, and I am not exaggerating even a little bit, have been spent > on this problem, and they've been spent by smart people with essentially > unlimited computational resources. And whaddaya know, they've succeeded. > > So if someone presents you a data corpus and says "this data is anonymized", > the default response should be to mock them, because there is a very high > probability they're either (a) lying or (b) wrong. > > Incidentally, I'm also a signatory of the EFF document, since of course > with nearly 40 years in the field I'm a mere clueless newbie and despite > ripping them a new one about once every other month, I'm clearly a tool > of Google. > > ---rsk From nanog at ics-il.net Wed Mar 29 02:18:40 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Mar 2017 21:18:40 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> Message-ID: <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. Note that I don't intend to ever do this at my ISP, nor my IX. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Tuesday, March 28, 2017 9:12:15 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Mike: My guess is you do not. Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. Later in this thread you said ?we are done here?. Would that you were so lucky. -- TTFN, patrick > On Mar 28, 2017, at 5:58 PM, Mike Hammett wrote: > > Why am I supposed to care? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Rich Kulawiec" > To: nanog at nanog.org > Sent: Tuesday, March 28, 2017 4:45:25 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >> The claim oft presented by people favoring this customer abuse is that >> the sold data is anonymous. But it's been well-established that very >> simple data aggregation techniques can develop signatures that reveal >> the identity of people in anonymized data. > > This needs to be repeated loudly and often at every possible opportunity. > I've spent much of the past decade studying this issue and the most succinct > way I can put it is that however good you (generic "you") think > de-anonymization techniques are, you're wrong: they're way better than that. > Billions, and I am not exaggerating even a little bit, have been spent > on this problem, and they've been spent by smart people with essentially > unlimited computational resources. And whaddaya know, they've succeeded. > > So if someone presents you a data corpus and says "this data is anonymized", > the default response should be to mock them, because there is a very high > probability they're either (a) lying or (b) wrong. > > Incidentally, I'm also a signatory of the EFF document, since of course > with nearly 40 years in the field I'm a mere clueless newbie and despite > ripping them a new one about once every other month, I'm clearly a tool > of Google. > > ---rsk From patrick at ianai.net Wed Mar 29 02:25:54 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 28 Mar 2017 22:25:54 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> Message-ID: <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> Thanks, I was a bit confused why you said it, which is apparently because I was confused. :-) I agree we need to do a better job educating users why this is important. And just so my opinion is clear, if there were a true market, I would not mind ISPs who did this (with proper notice). Unfortunately, over half of all households in the US have one or fewer choices for broadband providers. I am one of them. What do I do if my ISP wants to collect my data? VPN everything? -- TTFN, patrick > On Mar 28, 2017, at 10:18 PM, Mike Hammett wrote: > > It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. > > Note that I don't intend to ever do this at my ISP, nor my IX. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Patrick W. Gilmore" > > To: "NANOG list" > > Sent: Tuesday, March 28, 2017 9:12:15 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Mike: > > My guess is you do not. > > Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. > > Later in this thread you said ?we are done here?. Would that you were so lucky. > > -- > TTFN, > patrick > > > On Mar 28, 2017, at 5:58 PM, Mike Hammett > wrote: > > > > Why am I supposed to care? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "Rich Kulawiec" > > > To: nanog at nanog.org > > Sent: Tuesday, March 28, 2017 4:45:25 PM > > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > > > On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: > >> The claim oft presented by people favoring this customer abuse is that > >> the sold data is anonymous. But it's been well-established that very > >> simple data aggregation techniques can develop signatures that reveal > >> the identity of people in anonymized data. > > > > This needs to be repeated loudly and often at every possible opportunity. > > I've spent much of the past decade studying this issue and the most succinct > > way I can put it is that however good you (generic "you") think > > de-anonymization techniques are, you're wrong: they're way better than that. > > Billions, and I am not exaggerating even a little bit, have been spent > > on this problem, and they've been spent by smart people with essentially > > unlimited computational resources. And whaddaya know, they've succeeded. > > > > So if someone presents you a data corpus and says "this data is anonymized", > > the default response should be to mock them, because there is a very high > > probability they're either (a) lying or (b) wrong. > > > > Incidentally, I'm also a signatory of the EFF document, since of course > > with nearly 40 years in the field I'm a mere clueless newbie and despite > > ripping them a new one about once every other month, I'm clearly a tool > > of Google. > > > > ---rsk From nanog at ics-il.net Wed Mar 29 02:26:21 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Mar 2017 21:26:21 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> Message-ID: <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> As I say often. Perhaps a better way of handling things is instead of running to the government every time we get a tear in our eyes, vote with feet\wallets. Support your local independent (well, the ones that believe whatever it is you believe). ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mike Hammett" To: "Patrick W. Gilmore" Cc: "NANOG list" Sent: Tuesday, March 28, 2017 9:18:40 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. Note that I don't intend to ever do this at my ISP, nor my IX. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Tuesday, March 28, 2017 9:12:15 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Mike: My guess is you do not. Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. Later in this thread you said ?we are done here?. Would that you were so lucky. -- TTFN, patrick > On Mar 28, 2017, at 5:58 PM, Mike Hammett wrote: > > Why am I supposed to care? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Rich Kulawiec" > To: nanog at nanog.org > Sent: Tuesday, March 28, 2017 4:45:25 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >> The claim oft presented by people favoring this customer abuse is that >> the sold data is anonymous. But it's been well-established that very >> simple data aggregation techniques can develop signatures that reveal >> the identity of people in anonymized data. > > This needs to be repeated loudly and often at every possible opportunity. > I've spent much of the past decade studying this issue and the most succinct > way I can put it is that however good you (generic "you") think > de-anonymization techniques are, you're wrong: they're way better than that. > Billions, and I am not exaggerating even a little bit, have been spent > on this problem, and they've been spent by smart people with essentially > unlimited computational resources. And whaddaya know, they've succeeded. > > So if someone presents you a data corpus and says "this data is anonymized", > the default response should be to mock them, because there is a very high > probability they're either (a) lying or (b) wrong. > > Incidentally, I'm also a signatory of the EFF document, since of course > with nearly 40 years in the field I'm a mere clueless newbie and despite > ripping them a new one about once every other month, I'm clearly a tool > of Google. > > ---rsk From mel at beckman.org Wed Mar 29 03:11:57 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 03:11:57 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck>, <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> Message-ID: I generally believe less government is better government. But government is still necessary for a few things, such as the military. And privacy. Because privacy invasion is a crime committed in secret, so economic "voting" doesn't work. Without a law prohibiting selling of browser data, ISPs will simply lie and say they don't do it (as many already have). A VPN is no help. Every browser has to jump on the bare Internet somewhere, and where it does, data can be captured and then analyzed to identify individual user signatures. As the NSA (thank you Snowden) has so ably demonstrated. A law gives victims access to the power of legal discovery, civil damages, and even criminal prosecution. Where data privacy is concerned, we must have it. -mel beckman > On Mar 28, 2017, at 7:30 PM, Mike Hammett wrote: > > As I say often. Perhaps a better way of handling things is instead of running to the government every time we get a tear in our eyes, vote with feet\wallets. Support your local independent (well, the ones that believe whatever it is you believe). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Mike Hammett" > To: "Patrick W. Gilmore" > Cc: "NANOG list" > Sent: Tuesday, March 28, 2017 9:18:40 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. > > Note that I don't intend to ever do this at my ISP, nor my IX. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Tuesday, March 28, 2017 9:12:15 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Mike: > > My guess is you do not. > > Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. > > Later in this thread you said ?we are done here?. Would that you were so lucky. > > -- > TTFN, > patrick > >> On Mar 28, 2017, at 5:58 PM, Mike Hammett wrote: >> >> Why am I supposed to care? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Rich Kulawiec" >> To: nanog at nanog.org >> Sent: Tuesday, March 28, 2017 4:45:25 PM >> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >> >>> On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >>> The claim oft presented by people favoring this customer abuse is that >>> the sold data is anonymous. But it's been well-established that very >>> simple data aggregation techniques can develop signatures that reveal >>> the identity of people in anonymized data. >> >> This needs to be repeated loudly and often at every possible opportunity. >> I've spent much of the past decade studying this issue and the most succinct >> way I can put it is that however good you (generic "you") think >> de-anonymization techniques are, you're wrong: they're way better than that. >> Billions, and I am not exaggerating even a little bit, have been spent >> on this problem, and they've been spent by smart people with essentially >> unlimited computational resources. And whaddaya know, they've succeeded. >> >> So if someone presents you a data corpus and says "this data is anonymized", >> the default response should be to mock them, because there is a very high >> probability they're either (a) lying or (b) wrong. >> >> Incidentally, I'm also a signatory of the EFF document, since of course >> with nearly 40 years in the field I'm a mere clueless newbie and despite >> ripping them a new one about once every other month, I'm clearly a tool >> of Google. >> >> ---rsk > > > From daknob.mac at gmail.com Wed Mar 29 07:04:16 2017 From: daknob.mac at gmail.com (DaKnOb) Date: Wed, 29 Mar 2017 10:04:16 +0300 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: Message-ID: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following: SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf. DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS. When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address. However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail. Typically the behavior of the recipient if one or both of these checks failed is described in yet another DNS record, called a DMARC Policy. Some set this to very strict levels (reject e-mail / send to spam), some others to warn the user (like what you saw?), and some others, knowing this happens, to ignore/notify. This message probably appears because of the above SPF / DKIM / DMARC combo but I can't be 100% sure from the provided info. In any case, this is likely not your fault. If you want to be sure, verify the contents of the e-mail against the public NANOG archive which is available over HTTPS. My guess is that nothing has been changed. Thanks, Antonios > On 29 Mar 2017, at 03:22, Mel Beckman wrote: > > Is anyone else getting this message on every nanog post today? > > "This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing" > > I don't know if this link itself is malware, as it goes to the MS store, or if something is broken in the Nanog Mail machine. > > If it's just me, never mind. I'll figure it out. > > -mel beckman From diotonante at gmail.com Wed Mar 29 07:05:51 2017 From: diotonante at gmail.com (Davide Davini) Date: Wed, 29 Mar 2017 09:05:51 +0200 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <24B54AFC-1A4B-4B90-928F-204B31BB3484@beckman.org> References: <20170326230534.GA2707@eff.org> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu> <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> <12967433-3782-456E-8C03-23642CBD08EA@beckman.org> <218026656.5058.1490750017625.JavaMail.mhammett@ThunderFuck> <24B54AFC-1A4B-4B90-928F-204B31BB3484@beckman.org> Message-ID: <9464d0e4-4c14-45ed-9af3-b06fb877a7df@gmail.com> Even though your example is a bit melodramatic I agree with the concept, all the arguments against the ownership that users have on their own data is just hogwash. If there needs to be government imposed regulations to ensure it, I have zero problems with it. On 29/03/2017 03:19, Mel Beckman wrote: > What about bank robbery? Little ISPs could supplement their incomes using that immoral revenue stream too. The ends don't justify the means. Browsing history belongs to the user, not the ISP. Robbing users of this data is not justified just because it would give ISPs -- of any size -- a new revenue stream. > > -mel beckman > >> On Mar 28, 2017, at 6:14 PM, Mike Hammett wrote: >> >> What about little ISPs? There are already monetization platforms out there that can be resold to small ISPs. The company sells the aggregate data upstream. Not that I would, but in a small ISP, that money makes a big difference. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Mel Beckman" >> To: "Hugo Slabbert" >> Cc: nanog at nanog.org >> Sent: Tuesday, March 28, 2017 8:08:19 PM >> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >> >> Hugo, >> >> That's a great find! I note in the article: >> >> "Not only is the price of the premier service (with ads) only $70 a month, but it comes with a waiver of equipment, installation, and activation fees. The standard service without ads is $99 a month..." >> >> So that's $29 a month to let AT&T track your Web browsing, but only for targeting ads. ATT promises "And we won?t sell your personal information to anyone, for any reason." >> >> I would guess that the ability to sell that data would be worth several times the $29/month, so it's conceivable that a provider could offer $10/mo Gig Internet in exchange for browsing history. >> >> But nobody does. >> >> Because they think they can steal it. >> >> I think this pretty well demonstrates the greed of the big-ISP executives who lobbied for today's legislative atrocity, which lets them rob customers of browsing history that even AT&T execs acknowledge users own. >> >> -mel beckman >> >> On Mar 28, 2017, at 5:56 PM, Hugo Slabbert > wrote: >> >> Now, if ISPs want to PURCHASE browser data from customers directly, I'm >> sure they'll get some takers. But that strategy has never appeared in >> any business plan I've seen. >> >> https://arstechnica.com/information-technology/2013/12/att-offers-gigabit-internet-discount-in-exchange-for-your-web-history/ ? >> -- >> Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >> pgp key: B178313E | also on Signal >> From mel at beckman.org Wed Mar 29 10:17:17 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 10:17:17 +0000 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> References: , <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Message-ID: Antonia's, Thanks for the very clear explanation. I use DKIM and SPF, but didn't know about this corner case. I'm surprised the SPF, etc architects missed it, or seem to have. In any event, I seem to be getting all the messages. -mel beckman > On Mar 29, 2017, at 12:04 AM, DaKnOb wrote: > > Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following: > > SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf. > > DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS. > > When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address. > > However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail. > > Typically the behavior of the recipient if one or both of these checks failed is described in yet another DNS record, called a DMARC Policy. Some set this to very strict levels (reject e-mail / send to spam), some others to warn the user (like what you saw?), and some others, knowing this happens, to ignore/notify. > > This message probably appears because of the above SPF / DKIM / DMARC combo but I can't be 100% sure from the provided info. > > In any case, this is likely not your fault. If you want to be sure, verify the contents of the e-mail against the public NANOG archive which is available over HTTPS. My guess is that nothing has been changed. > > Thanks, > Antonios > >> On 29 Mar 2017, at 03:22, Mel Beckman wrote: >> >> Is anyone else getting this message on every nanog post today? >> >> "This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing" >> >> I don't know if this link itself is malware, as it goes to the MS store, or if something is broken in the Nanog Mail machine. >> >> If it's just me, never mind. I'll figure it out. >> >> -mel beckman From mel at beckman.org Wed Mar 29 10:21:09 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 10:21:09 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <9464d0e4-4c14-45ed-9af3-b06fb877a7df@gmail.com> References: <20170326230534.GA2707@eff.org> <1EA0512C-C3EE-4DA6-8E46-F9BAB640E6DE@beckman.org> <0a224039-5bdb-5036-fb82-7f89b228ea4c@rollernet.us> <32365.1490742510@turing-police.cc.vt.edu> <31C4EDD3-24F2-43D8-A90B-57AB11454A6C@beckman.org> <74228BE3-9B73-4CF7-9894-F09C1C3ADEB2@slabnet.com> <12967433-3782-456E-8C03-23642CBD08EA@beckman.org> <218026656.5058.1490750017625.JavaMail.mhammett@ThunderFuck> <24B54AFC-1A4B-4B90-928F-204B31BB3484@beckman.org>, <9464d0e4-4c14-45ed-9af3-b06fb877a7df@gmail.com> Message-ID: <43CC0B2C-500C-43D2-8166-2A5508B04FBC@beckman.org> Davide, My example is simply a reductio ad absurdum, to demonstrate the error of the idea that ISPs should be allowed to resell data "because money". :) -mel > On Mar 29, 2017, at 12:08 AM, Davide Davini wrote: > > Even though your example is a bit melodramatic I agree with the concept, > all the arguments against the ownership that users have on their own > data is just hogwash. > > If there needs to be government imposed regulations to ensure it, I have > zero problems with it. > >> On 29/03/2017 03:19, Mel Beckman wrote: >> What about bank robbery? Little ISPs could supplement their incomes using that immoral revenue stream too. The ends don't justify the means. Browsing history belongs to the user, not the ISP. Robbing users of this data is not justified just because it would give ISPs -- of any size -- a new revenue stream. >> >> -mel beckman >> >>> On Mar 28, 2017, at 6:14 PM, Mike Hammett wrote: >>> >>> What about little ISPs? There are already monetization platforms out there that can be resold to small ISPs. The company sells the aggregate data upstream. Not that I would, but in a small ISP, that money makes a big difference. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> >>> Midwest Internet Exchange >>> >>> The Brothers WISP >>> >>> ----- Original Message ----- >>> >>> From: "Mel Beckman" >>> To: "Hugo Slabbert" >>> Cc: nanog at nanog.org >>> Sent: Tuesday, March 28, 2017 8:08:19 PM >>> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >>> >>> Hugo, >>> >>> That's a great find! I note in the article: >>> >>> "Not only is the price of the premier service (with ads) only $70 a month, but it comes with a waiver of equipment, installation, and activation fees. The standard service without ads is $99 a month..." >>> >>> So that's $29 a month to let AT&T track your Web browsing, but only for targeting ads. ATT promises "And we won?t sell your personal information to anyone, for any reason." >>> >>> I would guess that the ability to sell that data would be worth several times the $29/month, so it's conceivable that a provider could offer $10/mo Gig Internet in exchange for browsing history. >>> >>> But nobody does. >>> >>> Because they think they can steal it. >>> >>> I think this pretty well demonstrates the greed of the big-ISP executives who lobbied for today's legislative atrocity, which lets them rob customers of browsing history that even AT&T execs acknowledge users own. >>> >>> -mel beckman >>> >>> On Mar 28, 2017, at 5:56 PM, Hugo Slabbert > wrote: >>> >>> Now, if ISPs want to PURCHASE browser data from customers directly, I'm >>> sure they'll get some takers. But that strategy has never appeared in >>> any business plan I've seen. >>> >>> https://arstechnica.com/information-technology/2013/12/att-offers-gigabit-internet-discount-in-exchange-for-your-web-history/ ? >>> -- >>> Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >>> pgp key: B178313E | also on Signal > > From nanog at ics-il.net Wed Mar 29 10:35:50 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 29 Mar 2017 05:35:50 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> Message-ID: <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> Are there really no others or are the ones that are there just marketing themselves poorly? Any nearby you could convince to expand? Over my WISP's coverage, I have at least 13 WISP competitors, 7 broadband wireline and nearly that many enterprise fiber. I admit that may be exceptional. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Tuesday, March 28, 2017 9:25:54 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Thanks, I was a bit confused why you said it, which is apparently because I was confused. :-) I agree we need to do a better job educating users why this is important. And just so my opinion is clear, if there were a true market, I would not mind ISPs who did this (with proper notice). Unfortunately, over half of all households in the US have one or fewer choices for broadband providers. I am one of them. What do I do if my ISP wants to collect my data? VPN everything? -- TTFN, patrick > On Mar 28, 2017, at 10:18 PM, Mike Hammett wrote: > > It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. > > Note that I don't intend to ever do this at my ISP, nor my IX. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Patrick W. Gilmore" > > To: "NANOG list" > > Sent: Tuesday, March 28, 2017 9:12:15 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Mike: > > My guess is you do not. > > Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. > > Later in this thread you said ?we are done here?. Would that you were so lucky. > > -- > TTFN, > patrick > > > On Mar 28, 2017, at 5:58 PM, Mike Hammett > wrote: > > > > Why am I supposed to care? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "Rich Kulawiec" > > > To: nanog at nanog.org > > Sent: Tuesday, March 28, 2017 4:45:25 PM > > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > > > On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: > >> The claim oft presented by people favoring this customer abuse is that > >> the sold data is anonymous. But it's been well-established that very > >> simple data aggregation techniques can develop signatures that reveal > >> the identity of people in anonymized data. > > > > This needs to be repeated loudly and often at every possible opportunity. > > I've spent much of the past decade studying this issue and the most succinct > > way I can put it is that however good you (generic "you") think > > de-anonymization techniques are, you're wrong: they're way better than that. > > Billions, and I am not exaggerating even a little bit, have been spent > > on this problem, and they've been spent by smart people with essentially > > unlimited computational resources. And whaddaya know, they've succeeded. > > > > So if someone presents you a data corpus and says "this data is anonymized", > > the default response should be to mock them, because there is a very high > > probability they're either (a) lying or (b) wrong. > > > > Incidentally, I'm also a signatory of the EFF document, since of course > > with nearly 40 years in the field I'm a mere clueless newbie and despite > > ripping them a new one about once every other month, I'm clearly a tool > > of Google. > > > > ---rsk From nanog at ics-il.net Wed Mar 29 10:48:11 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 29 Mar 2017 05:48:11 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> Message-ID: <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> What is lost if AT&T or Comcast sells my anonymized usage habits? Quite frankly I think targeting advertising is a great thing. On TV I see all kinds of commercials for medicine for diseases I've never heard of, old people complications I won't have for another 40 or 50 years, etc. Waste of my time, waste of their dollars. Targeted advertising brings me Hurricane Electric advertisements, network gear, servers, etc. Things I'm likely to be shopping for. Seems better in every way. You'd have better luck getting regulation passed with precise language. The collected information can (or cannot) be used in these specific ways. ISPs lying? Sounds like something for the courts, not capitol hill. Otherwise it just sounds like whining. I don't like them either, but certain groups will do whatever they can do "get back" at AT&T, Comcast, etc. regardless of what flag they're flying at the time (privacy, net neutrality, doughnut selections, whatever). ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mel Beckman" To: "Mike Hammett" Cc: "NANOG list" Sent: Tuesday, March 28, 2017 10:11:57 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal I generally believe less government is better government. But government is still necessary for a few things, such as the military. And privacy. Because privacy invasion is a crime committed in secret, so economic "voting" doesn't work. Without a law prohibiting selling of browser data, ISPs will simply lie and say they don't do it (as many already have). A VPN is no help. Every browser has to jump on the bare Internet somewhere, and where it does, data can be captured and then analyzed to identify individual user signatures. As the NSA (thank you Snowden) has so ably demonstrated. A law gives victims access to the power of legal discovery, civil damages, and even criminal prosecution. Where data privacy is concerned, we must have it. -mel beckman > On Mar 28, 2017, at 7:30 PM, Mike Hammett wrote: > > As I say often. Perhaps a better way of handling things is instead of running to the government every time we get a tear in our eyes, vote with feet\wallets. Support your local independent (well, the ones that believe whatever it is you believe). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Mike Hammett" > To: "Patrick W. Gilmore" > Cc: "NANOG list" > Sent: Tuesday, March 28, 2017 9:18:40 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. > > Note that I don't intend to ever do this at my ISP, nor my IX. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Tuesday, March 28, 2017 9:12:15 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Mike: > > My guess is you do not. > > Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. > > Later in this thread you said ?we are done here?. Would that you were so lucky. > > -- > TTFN, > patrick > >> On Mar 28, 2017, at 5:58 PM, Mike Hammett wrote: >> >> Why am I supposed to care? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Rich Kulawiec" >> To: nanog at nanog.org >> Sent: Tuesday, March 28, 2017 4:45:25 PM >> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >> >>> On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >>> The claim oft presented by people favoring this customer abuse is that >>> the sold data is anonymous. But it's been well-established that very >>> simple data aggregation techniques can develop signatures that reveal >>> the identity of people in anonymized data. >> >> This needs to be repeated loudly and often at every possible opportunity. >> I've spent much of the past decade studying this issue and the most succinct >> way I can put it is that however good you (generic "you") think >> de-anonymization techniques are, you're wrong: they're way better than that. >> Billions, and I am not exaggerating even a little bit, have been spent >> on this problem, and they've been spent by smart people with essentially >> unlimited computational resources. And whaddaya know, they've succeeded. >> >> So if someone presents you a data corpus and says "this data is anonymized", >> the default response should be to mock them, because there is a very high >> probability they're either (a) lying or (b) wrong. >> >> Incidentally, I'm also a signatory of the EFF document, since of course >> with nearly 40 years in the field I'm a mere clueless newbie and despite >> ripping them a new one about once every other month, I'm clearly a tool >> of Google. >> >> ---rsk > > > From rsk at gsp.org Wed Mar 29 11:24:31 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 29 Mar 2017 07:24:31 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> Message-ID: <20170329112431.GA19734@gsp.org> On Wed, Mar 29, 2017 at 05:48:11AM -0500, Mike Hammett wrote: > What is lost if AT&T or Comcast sells my anonymized usage habits? They're NOT anonymized. Aren't you paying attention? Anonymization -- *real* anonymization -- is hard. Hard means expensive. It also reduces the sale price of the data. There is no reason for any of these companies to spend the required money in order to sell the data for less than they could get otherwise. Why should they reduce their obscene profits? (a) Nobody's going to make them and (b) most people are as ignorant as you are and therefore aren't demanding it. It's much easier and more profitable to *claim* that the data is anonymized, maybe make a token (and worthless) gesture at making it so, and laugh all the way to the bank. And let me note that in passing that even if -- and this is a very faint "if" -- they're really anonymizing your data, it's not anonymized at the point of collection. Sooner or later, someone with access -- whether authorized or not -- will tap into that. Of course they will, it's far too valuable to be ignored indefinitely. Maybe it'll be an insider operation, maybe it'll be just one person, maybe it'll be outside attackers, maybe it'll be an intelligence or law enforcement agency. The point is that these data collection operations are obvious, high-value targets, therefore they WILL be attacked, and given the thoroughly miserable history of the security postures in play, they WILL be attacked succcessfully. So even if you're foolish and naive enough to believe the professional spokesliars at AT&T and Comcast, you should always keep in mind that this data will *not* be confined to those operations. It will be for sale, in raw unredacted form, on the darknet to anyone who can pay and/or it will be loaded into the data warehouses of any agency that chooses to acquire it. ---rsk From nanog at ics-il.net Wed Mar 29 11:30:45 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 29 Mar 2017 06:30:45 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <20170329112431.GA19734@gsp.org> References: <20170326230534.GA2707@eff.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> <20170329112431.GA19734@gsp.org> Message-ID: <1738824213.5453.1490787043398.JavaMail.mhammett@ThunderFuck> And so what if it is? What's the downside here? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Rich Kulawiec" To: nanog at nanog.org Sent: Wednesday, March 29, 2017 6:24:31 AM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal On Wed, Mar 29, 2017 at 05:48:11AM -0500, Mike Hammett wrote: > What is lost if AT&T or Comcast sells my anonymized usage habits? They're NOT anonymized. Aren't you paying attention? Anonymization -- *real* anonymization -- is hard. Hard means expensive. It also reduces the sale price of the data. There is no reason for any of these companies to spend the required money in order to sell the data for less than they could get otherwise. Why should they reduce their obscene profits? (a) Nobody's going to make them and (b) most people are as ignorant as you are and therefore aren't demanding it. It's much easier and more profitable to *claim* that the data is anonymized, maybe make a token (and worthless) gesture at making it so, and laugh all the way to the bank. And let me note that in passing that even if -- and this is a very faint "if" -- they're really anonymizing your data, it's not anonymized at the point of collection. Sooner or later, someone with access -- whether authorized or not -- will tap into that. Of course they will, it's far too valuable to be ignored indefinitely. Maybe it'll be an insider operation, maybe it'll be just one person, maybe it'll be outside attackers, maybe it'll be an intelligence or law enforcement agency. The point is that these data collection operations are obvious, high-value targets, therefore they WILL be attacked, and given the thoroughly miserable history of the security postures in play, they WILL be attacked succcessfully. So even if you're foolish and naive enough to believe the professional spokesliars at AT&T and Comcast, you should always keep in mind that this data will *not* be confined to those operations. It will be for sale, in raw unredacted form, on the darknet to anyone who can pay and/or it will be loaded into the data warehouses of any agency that chooses to acquire it. ---rsk From patrick at ianai.net Wed Mar 29 12:58:57 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 29 Mar 2017 08:58:57 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> Message-ID: <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> Mike: I know Mr. Glass thinks of me as a not knowledgeable network professional, but I hope you know I?ve been doing ?ISP stuff? for a couple decades. I know how to work the system. There really are not any other broadband providers in my area. Hell, LTE doesn?t even work well in my house, and I am less than a dozen miles from the center of Boston. But more importantly, even if there were a second provider, how do you expect Joe & Mary User to find that provider if I cannot? (Not trying to be arrogant, just saying I am more experience in this field than the average consumer.) Broadband competition in the US is a myth, at least for most people. At best, competition is the exception, not the rule. At worst, it?s a thinly veiled monopoly. Hell, they brag about it being a duopoly where they can, as if that?s a great thing. Comcast?s chairman brags that Time Warner & Comcast do not compete in any cities. -- TTFN, patrick > On Mar 29, 2017, at 6:35 AM, Mike Hammett wrote: > > Are there really no others or are the ones that are there just marketing themselves poorly? Any nearby you could convince to expand? > > Over my WISP's coverage, I have at least 13 WISP competitors, 7 broadband wireline and nearly that many enterprise fiber. I admit that may be exceptional. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Tuesday, March 28, 2017 9:25:54 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Thanks, I was a bit confused why you said it, which is apparently because I was confused. :-) > > I agree we need to do a better job educating users why this is important. > > And just so my opinion is clear, if there were a true market, I would not mind ISPs who did this (with proper notice). Unfortunately, over half of all households in the US have one or fewer choices for broadband providers. I am one of them. What do I do if my ISP wants to collect my data? VPN everything? > > -- > TTFN, > patrick > >> On Mar 28, 2017, at 10:18 PM, Mike Hammett wrote: >> >> It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. >> >> Note that I don't intend to ever do this at my ISP, nor my IX. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> From: "Patrick W. Gilmore" > >> To: "NANOG list" > >> Sent: Tuesday, March 28, 2017 9:12:15 PM >> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >> >> Mike: >> >> My guess is you do not. >> >> Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. >> >> Later in this thread you said ?we are done here?. Would that you were so lucky. >> >> -- >> TTFN, >> patrick >> >>> On Mar 28, 2017, at 5:58 PM, Mike Hammett > wrote: >>> >>> Why am I supposed to care? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> >>> Midwest Internet Exchange >>> >>> The Brothers WISP >>> >>> ----- Original Message ----- >>> >>> From: "Rich Kulawiec" > >>> To: nanog at nanog.org >>> Sent: Tuesday, March 28, 2017 4:45:25 PM >>> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >>> >>> On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >>>> The claim oft presented by people favoring this customer abuse is that >>>> the sold data is anonymous. But it's been well-established that very >>>> simple data aggregation techniques can develop signatures that reveal >>>> the identity of people in anonymized data. >>> >>> This needs to be repeated loudly and often at every possible opportunity. >>> I've spent much of the past decade studying this issue and the most succinct >>> way I can put it is that however good you (generic "you") think >>> de-anonymization techniques are, you're wrong: they're way better than that. >>> Billions, and I am not exaggerating even a little bit, have been spent >>> on this problem, and they've been spent by smart people with essentially >>> unlimited computational resources. And whaddaya know, they've succeeded. >>> >>> So if someone presents you a data corpus and says "this data is anonymized", >>> the default response should be to mock them, because there is a very high >>> probability they're either (a) lying or (b) wrong. >>> >>> Incidentally, I'm also a signatory of the EFF document, since of course >>> with nearly 40 years in the field I'm a mere clueless newbie and despite >>> ripping them a new one about once every other month, I'm clearly a tool >>> of Google. >>> >>> ---rsk > From patrick at ianai.net Wed Mar 29 13:05:15 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 29 Mar 2017 09:05:15 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> Message-ID: <6529F468-D857-4857-91D5-969DE9B583D5@ianai.net> On Mar 29, 2017, at 6:48 AM, Mike Hammett wrote: > > ISPs lying? Sounds like something for the courts, not capitol hill. You can?t sue someone because they do something you do not like. Well, you can, but you won?t win. I guess you could ask for the providers to put it in their terms of service so you have something actionable to sue on. Now see my previous post. I tell my provider ?put in a clause that says you won?t sell my data?. They reply ?no?. And I do ? what exactly? . . . . . . . . . Not sure we will get closure here. Some people think ISPs should be allowed to see data. Others do not. I am in the latter camp. The law is on the desk of POTUS which will do exactly what I do not want. My guess is he will sign it. Posting to NANOG will not change that. Shall we agree to disagree and move on? -- TTFN, patrick From nanog at ics-il.net Wed Mar 29 13:11:04 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 29 Mar 2017 08:11:04 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> Message-ID: <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> I know most of the people in the thread have been doing this a long time, the others I just don't know anything about them. FWIW: Glass has been running an ISP for 20 - 25 years, has given Congressional\FCC testimony, etc. He's not an industry slouch either, just with a different political standing. Certainly independents need better marketing machines, but the past 10 - 15 years, they've been beaten down pretty badly with the general public flocking to the incumbents and the masochism that entails. As my ISP tries to grow, in the same conversation I've had a property manager complain about Comcast and then say they don't need me because they have Comcast. I know that's not a technical battle. Heck, I've been trying to hire a sales\biz dev guy for the better part of two years. I never get anyone reasonable responding. One guy asked what B2B was. We need those anchor enterprise, government, MDU accounts in an area to justify the expense and low ROI of single family homes. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Wednesday, March 29, 2017 7:58:57 AM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Mike: I know Mr. Glass thinks of me as a not knowledgeable network professional, but I hope you know I?ve been doing ?ISP stuff? for a couple decades. I know how to work the system. There really are not any other broadband providers in my area. Hell, LTE doesn?t even work well in my house, and I am less than a dozen miles from the center of Boston. But more importantly, even if there were a second provider, how do you expect Joe & Mary User to find that provider if I cannot? (Not trying to be arrogant, just saying I am more experience in this field than the average consumer.) Broadband competition in the US is a myth, at least for most people. At best, competition is the exception, not the rule. At worst, it?s a thinly veiled monopoly. Hell, they brag about it being a duopoly where they can, as if that?s a great thing. Comcast?s chairman brags that Time Warner & Comcast do not compete in any cities. -- TTFN, patrick > On Mar 29, 2017, at 6:35 AM, Mike Hammett wrote: > > Are there really no others or are the ones that are there just marketing themselves poorly? Any nearby you could convince to expand? > > Over my WISP's coverage, I have at least 13 WISP competitors, 7 broadband wireline and nearly that many enterprise fiber. I admit that may be exceptional. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Tuesday, March 28, 2017 9:25:54 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Thanks, I was a bit confused why you said it, which is apparently because I was confused. :-) > > I agree we need to do a better job educating users why this is important. > > And just so my opinion is clear, if there were a true market, I would not mind ISPs who did this (with proper notice). Unfortunately, over half of all households in the US have one or fewer choices for broadband providers. I am one of them. What do I do if my ISP wants to collect my data? VPN everything? > > -- > TTFN, > patrick > >> On Mar 28, 2017, at 10:18 PM, Mike Hammett wrote: >> >> It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. >> >> Note that I don't intend to ever do this at my ISP, nor my IX. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> From: "Patrick W. Gilmore" > >> To: "NANOG list" > >> Sent: Tuesday, March 28, 2017 9:12:15 PM >> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >> >> Mike: >> >> My guess is you do not. >> >> Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. >> >> Later in this thread you said ?we are done here?. Would that you were so lucky. >> >> -- >> TTFN, >> patrick >> >>> On Mar 28, 2017, at 5:58 PM, Mike Hammett > wrote: >>> >>> Why am I supposed to care? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> >>> Midwest Internet Exchange >>> >>> The Brothers WISP >>> >>> ----- Original Message ----- >>> >>> From: "Rich Kulawiec" > >>> To: nanog at nanog.org >>> Sent: Tuesday, March 28, 2017 4:45:25 PM >>> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >>> >>> On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >>>> The claim oft presented by people favoring this customer abuse is that >>>> the sold data is anonymous. But it's been well-established that very >>>> simple data aggregation techniques can develop signatures that reveal >>>> the identity of people in anonymized data. >>> >>> This needs to be repeated loudly and often at every possible opportunity. >>> I've spent much of the past decade studying this issue and the most succinct >>> way I can put it is that however good you (generic "you") think >>> de-anonymization techniques are, you're wrong: they're way better than that. >>> Billions, and I am not exaggerating even a little bit, have been spent >>> on this problem, and they've been spent by smart people with essentially >>> unlimited computational resources. And whaddaya know, they've succeeded. >>> >>> So if someone presents you a data corpus and says "this data is anonymized", >>> the default response should be to mock them, because there is a very high >>> probability they're either (a) lying or (b) wrong. >>> >>> Incidentally, I'm also a signatory of the EFF document, since of course >>> with nearly 40 years in the field I'm a mere clueless newbie and despite >>> ripping them a new one about once every other month, I'm clearly a tool >>> of Google. >>> >>> ---rsk > From jloiacon at csc.com Wed Mar 29 13:59:33 2017 From: jloiacon at csc.com (Joe Loiacono) Date: Wed, 29 Mar 2017 09:59:33 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> Message-ID: Lowering barriers to entry is where the next political focus should be. Joe Loiacono From: Mike Hammett To: Cc: NANOG list Date: 03/29/2017 09:13 AM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Sent by: "NANOG" I know most of the people in the thread have been doing this a long time, the others I just don't know anything about them. FWIW: Glass has been running an ISP for 20 - 25 years, has given Congressional\FCC testimony, etc. He's not an industry slouch either, just with a different political standing. Certainly independents need better marketing machines, but the past 10 - 15 years, they've been beaten down pretty badly with the general public flocking to the incumbents and the masochism that entails. As my ISP tries to grow, in the same conversation I've had a property manager complain about Comcast and then say they don't need me because they have Comcast. I know that's not a technical battle. Heck, I've been trying to hire a sales\biz dev guy for the better part of two years. I never get anyone reasonable responding. One guy asked what B2B was. We need those anchor enterprise, government, MDU accounts in an area to justify the expense and low ROI of single family homes. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Wednesday, March 29, 2017 7:58:57 AM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal Mike: I know Mr. Glass thinks of me as a not knowledgeable network professional, but I hope you know I?ve been doing ?ISP stuff? for a couple decades. I know how to work the system. There really are not any other broadband providers in my area. Hell, LTE doesn?t even work well in my house, and I am less than a dozen miles from the center of Boston. But more importantly, even if there were a second provider, how do you expect Joe & Mary User to find that provider if I cannot? (Not trying to be arrogant, just saying I am more experience in this field than the average consumer.) Broadband competition in the US is a myth, at least for most people. At best, competition is the exception, not the rule. At worst, it?s a thinly veiled monopoly. Hell, they brag about it being a duopoly where they can, as if that?s a great thing. Comcast?s chairman brags that Time Warner & Comcast do not compete in any cities. -- TTFN, patrick > On Mar 29, 2017, at 6:35 AM, Mike Hammett wrote: > > Are there really no others or are the ones that are there just marketing themselves poorly? Any nearby you could convince to expand? > > Over my WISP's coverage, I have at least 13 WISP competitors, 7 broadband wireline and nearly that many enterprise fiber. I admit that may be exceptional. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Tuesday, March 28, 2017 9:25:54 PM > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > > Thanks, I was a bit confused why you said it, which is apparently because I was confused. :-) > > I agree we need to do a better job educating users why this is important. > > And just so my opinion is clear, if there were a true market, I would not mind ISPs who did this (with proper notice). Unfortunately, over half of all households in the US have one or fewer choices for broadband providers. I am one of them. What do I do if my ISP wants to collect my data? VPN everything? > > -- > TTFN, > patrick > >> On Mar 28, 2017, at 10:18 PM, Mike Hammett wrote: >> >> It was more a plea to educate the list on why this matters vs. doom and gloom with a little more gloom and a little less Carmack. Instead I got more of the sky is falling. >> >> Note that I don't intend to ever do this at my ISP, nor my IX. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> < https://plus.google.com/+IntelligentComputingSolutionsDeKalb> < https://www.linkedin.com/company/intelligent-computing-solutions> < https://twitter.com/ICSIL> >> Midwest Internet Exchange >> < https://www.linkedin.com/company/midwest-internet-exchange> < https://twitter.com/mdwestix> >> The Brothers WISP >> < https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >> From: "Patrick W. Gilmore" > >> To: "NANOG list" > >> Sent: Tuesday, March 28, 2017 9:12:15 PM >> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >> >> Mike: >> >> My guess is you do not. >> >> Which is -precisely- why the users (proletariat?) need to find a way to stop you. Hence laws & regulations. >> >> Later in this thread you said ?we are done here?. Would that you were so lucky. >> >> -- >> TTFN, >> patrick >> >>> On Mar 28, 2017, at 5:58 PM, Mike Hammett > wrote: >>> >>> Why am I supposed to care? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> >>> Midwest Internet Exchange >>> >>> The Brothers WISP >>> >>> ----- Original Message ----- >>> >>> From: "Rich Kulawiec" > >>> To: nanog at nanog.org >>> Sent: Tuesday, March 28, 2017 4:45:25 PM >>> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >>> >>> On Tue, Mar 28, 2017 at 06:45:04PM +0000, Mel Beckman wrote: >>>> The claim oft presented by people favoring this customer abuse is that >>>> the sold data is anonymous. But it's been well-established that very >>>> simple data aggregation techniques can develop signatures that reveal >>>> the identity of people in anonymized data. >>> >>> This needs to be repeated loudly and often at every possible opportunity. >>> I've spent much of the past decade studying this issue and the most succinct >>> way I can put it is that however good you (generic "you") think >>> de-anonymization techniques are, you're wrong: they're way better than that. >>> Billions, and I am not exaggerating even a little bit, have been spent >>> on this problem, and they've been spent by smart people with essentially >>> unlimited computational resources. And whaddaya know, they've succeeded. >>> >>> So if someone presents you a data corpus and says "this data is anonymized", >>> the default response should be to mock them, because there is a very high >>> probability they're either (a) lying or (b) wrong. >>> >>> Incidentally, I'm also a signatory of the EFF document, since of course >>> with nearly 40 years in the field I'm a mere clueless newbie and despite >>> ripping them a new one about once every other month, I'm clearly a tool >>> of Google. >>> >>> ---rsk > From gtaylor at tnetconsulting.net Wed Mar 29 14:58:38 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Mar 2017 08:58:38 -0600 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Message-ID: On 03/29/2017 04:17 AM, Mel Beckman wrote: > Thanks for the very clear explanation. I use DKIM and SPF, but didn't > know about this corner case. I'm surprised the SPF, etc architects > missed it, or seem to have. In any event, I seem to be getting all > the messages. I don't think they did miss it per say. SPF is specifically meant to say where senders are allowed to send from. Mailing lists (in some configurations), forwarders, et. al. (inadvertently) violate this when they re-send the message with the original sender from a not-explicitly-allowed source. Sender Rewriting Scheme is a way that these forwarding services can re-write the SMTP Envelope From address to not run afoul of SPF (et al). Mailing list managers, in particular, can also change the message in a few different ways to avoid some of these pitfalls. - Remove all but a subset of headers. - Alter the RFC 822 From: header such that the message appears to come from the mailing list its self. I also strongly recommend that mailing lists be viewed as an entity unto themselves. I.e. they receive the email, process it, and generate a new email /from/ /their/ /own/ /address/ with very similar content as the message they received. I strongly encourage mailing list admins to enable Variable Envelope Return Path to help identify which subscribed recipient causes each individual bounce, even if the problem is from downstream forwards. The problem with this is that it takes more processing power and bandwidth. Most people simply want an old school expansion that re-sends the same, unmodified, message to multiple recipients. - That methodology's heyday has come and mostly gone. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: From bill at herrin.us Wed Mar 29 15:12:33 2017 From: bill at herrin.us (William Herrin) Date: Wed, 29 Mar 2017 11:12:33 -0400 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Message-ID: On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb wrote: > Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is > concerned. These two systems above try to minimize spoofed e-mail by doing > the following: > > SPF: Each domain adds a list of IP Addresses that are allowed to send > e-mail on their behalf. > > DKIM: Each email sent by an "original" mail server is cryptographically > signed with a key available, again, in the DNS. > > When you send an e-mail to a list, you send it to the mailing list mail > server. After that, of the server forwards that e-mail to the recipients, > its original address is shown, therefore if Outlook checks for SPF records, > that check will fail. An easy way to get around this is for the list to > change the From field to something else, like "Mel Beckman via NANOG" and a > local email address. > > However, when you send that email, it may also be signed with DKIM: any > change in subject (say "[NANOG]" is added) or the body (say "You received > this email because you subscribed to NANOG" is appended) will also cause > that check to fail. > Hello, Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces at nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mel at beckman.org Wed Mar 29 15:17:27 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 15:17:27 +0000 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com>, Message-ID: <7582D3C4-8BCA-4266-8417-8899B6D9B79E@beckman.org> Bill, If that's the case, then Microsoft appears to be at fault here. I'll try opening a ticket (I know. Windmills :) -mel On Mar 29, 2017, at 8:13 AM, William Herrin > wrote: On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb > wrote: Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is concerned. These two systems above try to minimize spoofed e-mail by doing the following: SPF: Each domain adds a list of IP Addresses that are allowed to send e-mail on their behalf. DKIM: Each email sent by an "original" mail server is cryptographically signed with a key available, again, in the DNS. When you send an e-mail to a list, you send it to the mailing list mail server. After that, of the server forwards that e-mail to the recipients, its original address is shown, therefore if Outlook checks for SPF records, that check will fail. An easy way to get around this is for the list to change the From field to something else, like "Mel Beckman via NANOG" and a local email address. However, when you send that email, it may also be signed with DKIM: any change in subject (say "[NANOG]" is added) or the body (say "You received this email because you subscribed to NANOG" is appended) will also cause that check to fail. Hello, Both SPF and DKIM are meant to be checked against the domain in the envelope sender (SMTP protocol-level return address) which the NANOG list sets to nanog-bounces at nanog.org. Checking against the message header "from" address is an incorrect implementation which will break essentially all mailing lists. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From gtaylor at tnetconsulting.net Wed Mar 29 15:25:44 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Mar 2017 09:25:44 -0600 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Message-ID: <470c9743-1f90-4b65-29d9-a4176dae4896@tnetconsulting.net> On 03/29/2017 09:12 AM, William Herrin wrote: > Both SPF and DKIM are meant to be checked against the domain in the > envelope sender (SMTP protocol-level return address) which the NANOG list > sets to nanog-bounces at nanog.org. Checking against the message header "from" > address is an incorrect implementation which will break essentially all > mailing lists. That may be what the original intent was. Every SPF implementation I've seen has checked the SMTP envelope FROM address /and/ the RFC 822 From: header address. Granted, that does not mean that it's the correct behavior. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: From bill at herrin.us Wed Mar 29 15:32:35 2017 From: bill at herrin.us (William Herrin) Date: Wed, 29 Mar 2017 11:32:35 -0400 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <470c9743-1f90-4b65-29d9-a4176dae4896@tnetconsulting.net> References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> <470c9743-1f90-4b65-29d9-a4176dae4896@tnetconsulting.net> Message-ID: On Wed, Mar 29, 2017 at 11:25 AM, Grant Taylor via NANOG wrote: > Every SPF implementation I've seen has checked the SMTP envelope FROM > address /and/ the RFC 822 From: header address. > Hi Grant, The gold standard, Spamassassin, does not. Indeed, the message to which I reply was scored by spam assassin as "SPF_PASS" even though you do not include NANOG's servers in the SPF record for tnetconsulting.net. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From daknob.mac at gmail.com Wed Mar 29 15:38:34 2017 From: daknob.mac at gmail.com (DaKnOb) Date: Wed, 29 Mar 2017 18:38:34 +0300 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> <470c9743-1f90-4b65-29d9-a4176dae4896@tnetconsulting.net> Message-ID: Indeed, in more detail (which I omitted for simplicity), these checks are performed in a series of headers, the last of which is the From: header. I think the ?envelope-from? is either the first or the second in this 5-point list. That said, there are a lot of implementations out there that do not respect that and treat the From address as the sender whose honesty must be verified. Every time I send mail to a mailing list from my own domain, due to DMARC I get back several reports of SPF and DKIM fail, mainly because the mailing list messed up something. > On 29 Mar 2017, at 18:32, William Herrin wrote: > > On Wed, Mar 29, 2017 at 11:25 AM, Grant Taylor via NANOG > wrote: > >> Every SPF implementation I've seen has checked the SMTP envelope FROM >> address /and/ the RFC 822 From: header address. >> > > Hi Grant, > > The gold standard, Spamassassin, does not. Indeed, the message to which I > reply was scored by spam assassin as "SPF_PASS" even though you do not > include NANOG's servers in the SPF record for tnetconsulting.net. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From pozar at lns.com Tue Mar 28 19:11:53 2017 From: pozar at lns.com (Tim Pozar) Date: Tue, 28 Mar 2017 12:11:53 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> Message-ID: <3e907601-9227-6df7-4e78-e6c1426346b8@lns.com> Alexa ran into this problem... https://www.cnet.com/news/amazon-unit-settles-privacy-lawsuit/ Tim On 3/28/17 11:45 AM, Mel Beckman wrote: > No ISPs have any right to market our customers browsing history, and currently that practice is illegal unless the customer opts in. In my opinion, only a fool wants to relieve ISPs of this restriction. > > The claim oft presented by people favoring this customer abuse is that the sold data is anonymous. But it's been well-established that very simple data aggregation techniques can develop signatures that reveal the identity of people in anonymized data. > > -mel beckman > >> On Mar 28, 2017, at 10:40 AM, Rod Beck wrote: >> >> Last time I checked most European countries have stronger privacy protections than the US. Are they also idiots? Mr. Glass, would you care to respond? >> >> >> Regards, >> >> >> Roderick. >> >> >> ________________________________ >> From: NANOG on behalf of Brett Glass >> Sent: Tuesday, March 28, 2017 1:13 AM >> To: nanog at nanog.org >> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal >> >> All: >> >> It's worth noting that most of EFF's list consists of individuals >> and/or politically connected organizations, not actual ISPs. This >> is for good reason. EFF was founded with the intention of creating >> a civil rights organization but has morphed into a captive >> corporate lobbying shop for Google, to which several of its board >> members have close financial ties. EFF opposes the interests of >> hard working ISPs and routinely denigrates them and attempts to >> foster promotes hatred of them. It also promotes and lobbies for >> regulations which advantage Google and disadvantage ISPs -- >> including the so-called "broadband privacy" regulations, which >> heavily burden ISPs while exempting Google from all oversight. >> >> No knowledgeable network professional or ISP would support the >> current FCC rules. Both they AND the FCC's illegal Title II >> classification of ISPs must be rolled back, restoring the FTC's >> ability to apply uniform and apolitical privacy standards to all of >> the players in the Internet ecosystem. The first step is to support >> S.J. Res 34/H.J. Res 86, the Congressional resolution which would >> revoke the current FCC regulations that were written and paid for >> by Google and its lobbyists. So, DO contact your legislators... >> but do so in support of the resolutions that will repeal the >> regulations. It is vital to the future of the Internet. >> >> --Brett Glass, Owner and Founder, LARIAT.NET >> >> At 05:05 PM 3/26/2017, Peter Eckersley wrote: >> >>> Dear network operators, >>> >>> I'm sure this is a controversial topic in the NANOG community, but EFF and a >>> number of ISPs and networking companies are writing to Congress opposing the >>> repeal of the FCC's broadband privacy rules, which require explicit opt-in >>> consent before ISPs use or sell sensitive, non-anonymized data (including >>> non-anonymized locations and browsing histories). >>> >>> If you or your employer would like to sign on to such a letter, please reply >>> off-list by midday Monday with your name, and a one-sentence description of >>> your affiliation and/or major career accomplishments. >> From jason at schwerberg.com Wed Mar 29 00:17:15 2017 From: jason at schwerberg.com (Jason Schwerberg) Date: Tue, 28 Mar 2017 17:17:15 -0700 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <965B4ACD-16C1-41F9-8EF8-9A25162FCF3B@ianai.net> References: <20170326230534.GA2707@eff.org> <201703272314.RAA11157@mail.lariat.net> <3212EB8D-2944-486B-A681-B78066BD9F3E@ianai.net> <1577761502.4254.1490704396224.JavaMail.mhammett@ThunderFuck> <965B4ACD-16C1-41F9-8EF8-9A25162FCF3B@ianai.net> Message-ID: On 3/28/2017 6:56 AM, Patrick W. Gilmore wrote: > Having worked networks with massive bandwidth, networks with a single T1 (don?t ask, just Google what a T1 is, er, was) I've lurked on this mailing list for months, and never felt obligated to chime in until now. Thanks for reminding me exactly how dated my network is. :) Signed, an also not knowledgeable network professional who has a few hundred T1s scattered across the country. With 56k dial backup. Jason Schwerberg -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x782DA39E.asc Type: application/pgp-keys Size: 5468 bytes Desc: not available URL: From ryanstoner7 at gmail.com Wed Mar 29 11:34:50 2017 From: ryanstoner7 at gmail.com (Ryan Stoner) Date: Wed, 29 Mar 2017 06:34:50 -0500 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <20170329112431.GA19734@gsp.org> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> <20170329112431.GA19734@gsp.org> Message-ID: All if you are in a tizzy over a policy that's been dead for a while. < https://www.google.com/amp/amp.timeinc.net/fortune/2016/09/30/att-internet-fees-privacy/%3Fsource%3Ddam > -- Ryan Stoner On Mar 29, 2017 6:26 AM, "Rich Kulawiec" wrote: On Wed, Mar 29, 2017 at 05:48:11AM -0500, Mike Hammett wrote: > What is lost if AT&T or Comcast sells my anonymized usage habits? They're NOT anonymized. Aren't you paying attention? Anonymization -- *real* anonymization -- is hard. Hard means expensive. It also reduces the sale price of the data. There is no reason for any of these companies to spend the required money in order to sell the data for less than they could get otherwise. Why should they reduce their obscene profits? (a) Nobody's going to make them and (b) most people are as ignorant as you are and therefore aren't demanding it. It's much easier and more profitable to *claim* that the data is anonymized, maybe make a token (and worthless) gesture at making it so, and laugh all the way to the bank. And let me note that in passing that even if -- and this is a very faint "if" -- they're really anonymizing your data, it's not anonymized at the point of collection. Sooner or later, someone with access -- whether authorized or not -- will tap into that. Of course they will, it's far too valuable to be ignored indefinitely. Maybe it'll be an insider operation, maybe it'll be just one person, maybe it'll be outside attackers, maybe it'll be an intelligence or law enforcement agency. The point is that these data collection operations are obvious, high-value targets, therefore they WILL be attacked, and given the thoroughly miserable history of the security postures in play, they WILL be attacked succcessfully. So even if you're foolish and naive enough to believe the professional spokesliars at AT&T and Comcast, you should always keep in mind that this data will *not* be confined to those operations. It will be for sale, in raw unredacted form, on the darknet to anyone who can pay and/or it will be loaded into the data warehouses of any agency that chooses to acquire it. ---rsk From carl at five-ten-sg.com Wed Mar 29 16:00:02 2017 From: carl at five-ten-sg.com (Carl Byington) Date: Wed, 29 Mar 2017 09:00:02 -0700 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> <470c9743-1f90-4b65-29d9-a4176dae4896@tnetconsulting.net> Message-ID: <1490803202.20966.6.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2017-03-29 at 11:32 -0400, William Herrin wrote: > The gold standard, Spamassassin, does not. Indeed, the message to > which I reply was scored by spam assassin as "SPF_PASS" even though > you do not include NANOG's servers in the SPF record for > tnetconsulting.net. The message from Mr. Taylor (to which Mr. Herrin is replying) arrived here with: Return-path: From: Grant Taylor via NANOG Reply-to: Grant Taylor So an SPF implementation that checks either or both of the (rfc2821 envelope from / rfc2822 header from) domains will pass. The original was DKIM signed by d=tnetconsulting.net (c=simple/simple - you might want to change that) but of course that signature was broken by the nanog list handling. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAljb2dEACgkQL6j7milTFsGoxwCePikWwzhrqSLFV3QQIKNR8FfO eoAAnjjH7TgYcTSJC8DWe2l139iQfkkI =SEM6 -----END PGP SIGNATURE----- From bicknell at ufp.org Wed Mar 29 16:06:19 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 29 Mar 2017 09:06:19 -0700 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Message-ID: <20170329160619.GA88244@ussenterprise.ufp.org> In a message written on Wed, Mar 29, 2017 at 08:58:38AM -0600, Grant Taylor via NANOG wrote: > I also strongly recommend that mailing lists be viewed as an entity unto > themselves. I.e. they receive the email, process it, and generate a new > email /from/ /their/ /own/ /address/ with very similar content as the > message they received. > > I strongly encourage mailing list admins to enable Variable Envelope > Return Path to help identify which subscribed recipient causes each > individual bounce, even if the problem is from downstream forwards. > > The problem with this is that it takes more processing power and > bandwidth. Most people simply want an old school expansion that > re-sends the same, unmodified, message to multiple recipients. - That > methodology's heyday has come and mostly gone. Actually, my problem is not so much processing power and bandwidth, but that every time I've encountered this problem I found a morass of painfully broken, horribly documented, super-complex software. With sendmail/postfix you can edit an alias file and say: bob: joe, tim, alex And boom, done. If I could enable some feature/module/whatever in either one with a line or two of config to make that do Variable Envelope Return Path I would, but every solution I know of requires setting up a complex milter, running some external daemon, which often depends on 3 different interpreted languages to be installed and so on down a dependency hell. While I haven't looked at real mailing list software recently (e.g. mailman) when I last did they didn't suport this either and it took a pile of 3rd party hacks to make it work. Why o why in 2017 can this not be a checkbox, a line of config, or so on. For that matter, setting up DKIM is horrendously complicated for no good reason... -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From ahodgson at lists.simkin.ca Wed Mar 29 16:24:34 2017 From: ahodgson at lists.simkin.ca (Alan Hodgson) Date: Wed, 29 Mar 2017 09:24:34 -0700 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Message-ID: <15539534.4rWtqb57Ip@skynet.simkin.ca> On Wednesday 29 March 2017 11:12:33 William Herrin wrote: > On Wed, Mar 29, 2017 at 3:04 AM, DaKnOb wrote: > > Usually mailing lists act like e-mail spoofers as far as SPF and DKIM is > > concerned. These two systems above try to minimize spoofed e-mail by doing > > the following: > > > > SPF: Each domain adds a list of IP Addresses that are allowed to send > > e-mail on their behalf. > > > > DKIM: Each email sent by an "original" mail server is cryptographically > > signed with a key available, again, in the DNS. > > > > When you send an e-mail to a list, you send it to the mailing list mail > > server. After that, of the server forwards that e-mail to the recipients, > > its original address is shown, therefore if Outlook checks for SPF > > records, > > that check will fail. An easy way to get around this is for the list to > > change the From field to something else, like "Mel Beckman via NANOG" and > > a > > local email address. > > > > However, when you send that email, it may also be signed with DKIM: any > > change in subject (say "[NANOG]" is added) or the body (say "You received > > this email because you subscribed to NANOG" is appended) will also cause > > that check to fail. > > Hello, > > Both SPF and DKIM are meant to be checked against the domain in the > envelope sender (SMTP protocol-level return address) which the NANOG list > sets to nanog-bounces at nanog.org. Checking against the message header "from" > address is an incorrect implementation which will break essentially all > mailing lists. > This is incomplete. TL;DR: SPF checks the envelope sender. DKIM doesn't check anything except to test that parts of the message haven't been altered. DMARC adds policy to both to check them against the header From:. Mailing list software may not work with DMARC-reject senders (but Nanog does). ---- SPF checks the envelope sender only. Some Microsoft implementations purportedly check the header From:, but they aren't supposed to. Microsoft at one time tried to extend SPF to check the header Sender or From via SPF 2.0, which didn't catch on. Large mail receivers have also extended SPF checks internally in various ways to try to infer whether messages are forged, but that's not really SPF. DKIM doesn't by default check anything except that the headers and body that were signed have not been altered since the signature was added. It definitely has nothing to do with the envelope sender. There was an ADSP extension to DKIM to add policy to the header From: address, but it is superceded by DMARC. DMARC adds sender policy to both mechanisms. For DMARC to pass, either SPF or DKIM must pass and the identifier must be aligned with the header From:. So for DMARC+SPF to pass not only must the message come from a source authorized by the envelope sender domain, but that domain must be the same domain (or parent domain or subdomain) of the header From: address. For DMARC+DKIM to pass, the DKIM signature must pass and the DKIM signing domain must be the same domain (or parent domain or subdomain) of the header From: address. Again, DMARC requires only one or the other mechanism to pass. So messages forwarded intact should be OK if they have an aligned DKIM signature. Mailing lists run by mailing list software usually alter the envelope sender. They can therefore create and pass their own SPF policy. However, if the From: address is preserved, this will not be an aligned message and will not pass DMARC+SPF. And of course if they don't modify the envelope sender, SPF will never pass. Mailing lists often modify either the subject line or message body. This breaks the existing DKIM signature. If they preserve the From: address, they will therefore never pass DMARC because they can't create an aligned signature. To work with DMARC-reject senders, mailing lists should either: a) not alter the existing message headers or body, so that pre-existing signatures can pass (Nanog works fine, for instance, so I doubt the OP on this thread is related). or b) replace the From: address, remove existing DKIM signatures, and add their own DKIM signature or c) reject posts from senders in DMARC-reject domains Other mail forwarders should not alter signed message headers or the message bodies. Microsoft's forwarding in particular tends to break forwarded messages by running them through Exchange internally, which likes to rewrite the message. This often breaks the DKIM signatures. From fw at deneb.enyo.de Wed Mar 29 17:38:29 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 29 Mar 2017 19:38:29 +0200 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: (Grant Taylor via NANOG's message of "Wed, 29 Mar 2017 08:58:38 -0600") References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> Message-ID: <87d1d07zl6.fsf@mid.deneb.enyo.de> * Grant Taylor via NANOG: > On 03/29/2017 04:17 AM, Mel Beckman wrote: >> Thanks for the very clear explanation. I use DKIM and SPF, but didn't >> know about this corner case. I'm surprised the SPF, etc architects >> missed it, or seem to have. In any event, I seem to be getting all >> the messages. > > I don't think they did miss it per say. SPF is specifically meant to > say where senders are allowed to send from. Mailing lists (in some > configurations), forwarders, et. al. (inadvertently) violate this when > they re-send the message with the original sender from a > not-explicitly-allowed source. > > Sender Rewriting Scheme is a way that these forwarding services can > re-write the SMTP Envelope From address to not run afoul of SPF (et al). SPF (in its specified form) is very compatible with the way people have been running mailing lists since the mid-to-late 90s because the mailing list specifies itself as the SMTP envelope from address. This has the added benefit of enabling bounce processing. Unfortunately, the envelope from address is used for generating bounces only. Mail clients just show the header. That's why some SPF variants (like the one proposed by Microsoft) apply SPF rules to email headers as well, although this wasn't part of the original SPF spec (because it breaks too much). DKIM was designed from the start to (optionally) break mailing lists, and some mail providers now publish sender domain policies which other mail providers enforce. In effect, this requires pervasive header rewriting (within the mailing list software) before the message can be sent over the mailing list, obfuscating the true sender. It's a very unfortunate situation. The mailing list software could put the original sender address into a new header, and if that header is standardized, mail clients could just display that. But then, certain sender domains would just sign the absence of that header, and we are back to square one. Presumably, we could use a randomized header, so that at least DKIM protocol changes are required, but it is basically an arms race at this point. From brad at shub-internet.org Wed Mar 29 17:54:07 2017 From: brad at shub-internet.org (Brad Knowles) Date: Wed, 29 Mar 2017 12:54:07 -0500 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <20170329160619.GA88244@ussenterprise.ufp.org> References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> <20170329160619.GA88244@ussenterprise.ufp.org> Message-ID: <89950395-92AC-4645-8616-6342F3652979@shub-internet.org> On Mar 29, 2017, at 11:06 AM, Leo Bicknell wrote: > While I haven't looked at real mailing list software recently > (e.g. mailman) when I last did they didn't suport this either and > it took a pile of 3rd party hacks to make it work. The latest versions of Mailman (2.1.23 and 3.0.0) both work reasonably well out-of-the-box with SPF, DKIM, and DMARC. Some additional configuration tuning might be necessary for additional compatibility. However, those features are still available in an out-of-the-box configuration, they?re just not enabled by default because they might cause more problems than they would solve for certain types of typical installations. So, if you want those features, you need to turn them on. IMO, Mailman3 works better out-of-the-box with SPF, DKIM, and DMARC as compared to Mailman 2.1.x, but that codebase is still pretty fresh. We?re now using it by default for mailing lists hosted on python.org, but we have not yet converted any of the older Mailman 2.1.x lists over to Mailman 3. We haven?t noticed any major problems yet with the latest version of Mailman3, but we still want to be careful in our testing. > For that matter, setting up DKIM is horrendously complicated for > no good reason? Sites like DMARCian help with that process to a degree, but there?s still a lot of complexity there that I would like to see handled automatically. Unfortunately, that?s kind of the nature of the beast right now with these tools. The technology is still complex and difficult to configure, and it?s easy to set things up in a way that you wind up shooting yourself in the foot ? and possibly with a large thermonuclear device. No provider is immune to these mistakes, and some providers are more likely to make big mistakes than others. -- Brad Knowles From dhubbard at dino.hostasaurus.com Wed Mar 29 19:21:44 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 29 Mar 2017 19:21:44 +0000 Subject: Alternatives to bgpmon? In-Reply-To: References: Message-ID: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> Anyone have recommendations for an alternative service that works like bgpmon (external reachability/peer monitoring, route hijack alerts, etc)? Since their OpenDNS acquisition, I?ve found the service not working reliably, as in I receive no alerts even when I?m intentionally taking one of our peers offline, and after two attempts to find out why this is, I receive no response, so it seems support is now broken as well. Thanks, David From ryanstoner7 at gmail.com Wed Mar 29 19:25:34 2017 From: ryanstoner7 at gmail.com (Ryan Stoner) Date: Wed, 29 Mar 2017 14:25:34 -0500 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <963256394548349c5f313492d15de110@schwerberg.com> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <708078776.5154.1490754376476.JavaMail.mhammett@ThunderFuck> <163687951.5371.1490784489944.JavaMail.mhammett@ThunderFuck> <20170329112431.GA19734@gsp.org> <963256394548349c5f313492d15de110@schwerberg.com> Message-ID: Sorry guys. A bit of Percocet on the brain here. Yay broken spine! I meant a tizzy about AT&T and their spying on home fiber customers. They claim they don't do it anymore and offer the lower price to everyone. -- Ryan Stoner On Mar 29, 2017 2:17 PM, wrote: > Ryan, > > No, we're in a tizzy over a house resolution that was passed just > yesterday. > > http://thehill.com/policy/technology/326145-house-votes- > to-send-bill-undoing-obama-internet-privacy-rule-to-trumps-desk > > > On 2017-03-29 04:34, Ryan Stoner wrote: > > All if you are in a tizzy over a policy that's been dead for a while. > > < > https://www.google.com/amp/amp.timeinc.net/fortune/2016/ > 09/30/att-internet-fees-privacy/%3Fsource%3Ddam > -- > Ryan Stoner > > > On Mar 29, 2017 6:26 AM, "Rich Kulawiec" wrote: > > On Wed, Mar 29, 2017 at 05:48:11AM -0500, Mike Hammett wrote: > > What is lost if AT&T or Comcast sells my anonymized usage habits? > > > They're NOT anonymized. Aren't you paying attention? > > Anonymization -- *real* anonymization -- is hard. Hard means expensive. > It also reduces the sale price of the data. There is no reason for any > of these companies to spend the required money in order to sell the data > for less than they could get otherwise. Why should they reduce their > obscene profits? (a) Nobody's going to make them and (b) most people > are as ignorant as you are and therefore aren't demanding it. > > It's much easier and more profitable to *claim* that the data is > anonymized, > maybe make a token (and worthless) gesture at making it so, and laugh all > the way to the bank. > > And let me note that in passing that even if -- and this is a very faint > "if" -- they're really anonymizing your data, it's not anonymized > at the point of collection. Sooner or later, someone with access -- > whether authorized or not -- will tap into that. Of course they will, > it's far too valuable to be ignored indefinitely. Maybe it'll be an > insider operation, maybe it'll be just one person, maybe it'll be outside > attackers, maybe it'll be an intelligence or law enforcement agency. > > The point is that these data collection operations are obvious, > high-value targets, therefore they WILL be attacked, and given the > thoroughly miserable history of the security postures in play, they > WILL be attacked succcessfully. So even if you're foolish and naive > enough to believe the professional spokesliars at AT&T and Comcast, > you should always keep in mind that this data will *not* be confined to > those operations. It will be for sale, in raw unredacted form, on the > darknet to anyone who can pay and/or it will be loaded into the data > warehouses of any agency that chooses to acquire it. > > ---rsk > > > From bill at herrin.us Wed Mar 29 19:52:15 2017 From: bill at herrin.us (William Herrin) Date: Wed, 29 Mar 2017 15:52:15 -0400 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <15539534.4rWtqb57Ip@skynet.simkin.ca> References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> <15539534.4rWtqb57Ip@skynet.simkin.ca> Message-ID: On Wed, Mar 29, 2017 at 12:24 PM, Alan Hodgson wrote: > On Wednesday 29 March 2017 11:12:33 William Herrin wrote: > > Both SPF and DKIM are meant to be checked against the domain in the > > envelope sender (SMTP protocol-level return address) which the NANOG list > > sets to nanog-bounces at nanog.org. Checking against the message header > "from" > > address is an incorrect implementation which will break essentially all > > mailing lists. > > > > This is incomplete. > > TL;DR: SPF checks the envelope sender. DKIM doesn't check anything except > to > test that parts of the message haven't been altered. DMARC adds policy to > both > to check them against the header From:. Mailing list software may not work > with DMARC-reject senders (but Nanog does). > Hi Alan, I accept your explanation as the correct one. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mark at amplex.net Wed Mar 29 20:02:45 2017 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 29 Mar 2017 16:02:45 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> Message-ID: > On Mar 29, 2017, at 9:59 AM, Joe Loiacono wrote: > > Lowering barriers to entry is where the next political focus should be. > > Joe Loiacono > And there you have much of the problem with this privacy bill. Read the actual Report and Order: https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-148A1.pdf 219 pages You want to start a competitive ISP these days? Make sure you: Incorporate your business Obtain Liability, Workers Comp, Unemployment, Auto Insurance Comply with the FCC Privacy Act (short reading, requires considerable investment in tracking opt in, opt out, privacy policies) File the mandatory FCC 477 filings twice a year with detailed information on the geolocation of all of your customers and service area. If offering VoIP service file your 499-A and Quarterly 499-Q?s with the FCC Draft your ?Open Internet Disclosure Statement?, pay a FCC lawyer a couple grand to renew it, make sure it?s prominent on your website Build your website Obtain bandwidth and IP, fill out your ARIN information. Make up your ?Consumer Label? for Broadband: https://www.fcc.gov/consumers/guides/consumer-labels-broadband-services (probably need a lawyer for this too..) Pay the lawyer to write your ?Terms of Service? so that you have at least some chance of surviving the lawsuits Implement your CALEA plan and file that paperwork with the FBI so they can find you Register with the Copyright office so that you can deal with DMCA notices. Establish your copyright policy and procedures. Have your lawyer review it. Make sure you comply with 18 USC 2258A regarding reporting and registration for kiddie porn, train your employees Make sure you have a CPNI policy, training, and report to the FCC yearly Implement and file your Section 255 ?Disability Rights? policy and make sure you file yearly with the FCC your information Slap up a Ubiquiti access point and you can now make millions of dollars in short order. I?m sure I forgot a few things like ?build your network?, but that?s simple. Mark From jan-philipp.benecke at jpbe.de Wed Mar 29 20:19:47 2017 From: jan-philipp.benecke at jpbe.de (Jan-Philipp Benecke) Date: Wed, 29 Mar 2017 22:19:47 +0200 Subject: Alternatives to bgpmon? In-Reply-To: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> References: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> Message-ID: Hey, maybe is https://www.thousandeyes.com/ a option. Best, Jan-Philipp Am 29.03.17 um 21:21 schrieb David Hubbard: > Anyone have recommendations for an alternative service that works like bgpmon (external reachability/peer monitoring, route hijack alerts, etc)? Since their OpenDNS acquisition, I?ve found the service not working reliably, as in I receive no alerts even when I?m intentionally taking one of our peers offline, and after two attempts to find out why this is, I receive no response, so it seems support is now broken as well. > > Thanks, > > David > From afmug at zirkel.us Wed Mar 29 20:30:48 2017 From: afmug at zirkel.us (Sean Heskett) Date: Wed, 29 Mar 2017 20:30:48 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> Message-ID: +1bazillion What mark said! On Wed, Mar 29, 2017 at 2:26 PM Mark Radabaugh wrote: > > > On Mar 29, 2017, at 9:59 AM, Joe Loiacono wrote: > > > > Lowering barriers to entry is where the next political focus should be. > > > > Joe Loiacono > > > > And there you have much of the problem with this privacy bill. > > Read the actual Report and Order: > https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-148A1.pdf < > https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-148A1.pdf> > > 219 pages > > You want to start a competitive ISP these days? Make sure you: > > Incorporate your business > Obtain Liability, Workers Comp, Unemployment, Auto Insurance > Comply with the FCC Privacy Act (short reading, requires considerable > investment in tracking opt in, opt out, privacy policies) > File the mandatory FCC 477 filings twice a year with detailed information > on the geolocation of all of your customers and service area. > If offering VoIP service file your 499-A and Quarterly 499-Q?s with the FCC > Draft your ?Open Internet Disclosure Statement?, pay a FCC lawyer a couple > grand to renew it, make sure it?s prominent on your website > Build your website > Obtain bandwidth and IP, fill out your ARIN information. > Make up your ?Consumer Label? for Broadband: > https://www.fcc.gov/consumers/guides/consumer-labels-broadband-services < > https://www.fcc.gov/consumers/guides/consumer-labels-broadband-services> > (probably need a lawyer for this too..) > Pay the lawyer to write your ?Terms of Service? so that you have at least > some chance of surviving the lawsuits > Implement your CALEA plan and file that paperwork with the FBI so they can > find you > Register with the Copyright office so that you can deal with DMCA notices. > Establish your copyright policy and procedures. Have your lawyer review > it. > Make sure you comply with 18 USC 2258A regarding reporting and > registration for kiddie porn, train your employees > Make sure you have a CPNI policy, training, and report to the FCC yearly > Implement and file your Section 255 ?Disability Rights? policy and make > sure you file yearly with the FCC your information > > Slap up a Ubiquiti access point and you can now make millions of dollars > in short order. > > I?m sure I forgot a few things like ?build your network?, but that?s > simple. > > Mark > > From valdis.kletnieks at vt.edu Wed Mar 29 20:52:33 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 29 Mar 2017 16:52:33 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> Message-ID: <27265.1490820753@turing-police.cc.vt.edu> On Wed, 29 Mar 2017 16:02:45 -0400, Mark Radabaugh said: > And there you have much of the problem with this privacy bill. Hate to break it to you, but most of the gripes you have here are things you really *want* to do - they're things that reduce your personal liability and/or chance of ending up in prison. Just because you seem to be anti-regulation doesn't rule out the existence of regulations that are actually there to *help* you run your business. > Incorporate your business That's usually a given for *any* business unless you want to be sued to your skivvies... > Obtain Liability, Workers Comp, Unemployment, Auto Insurance Ditto. > Obtain bandwidth and IP, fill out your ARIN information. You're gonna need to do that no matter how anti-regulation you are. > Pay the lawyer to write your ???Terms of Service??? so that you have at least some chance of surviving the lawsuits Or you can gamble on the lawsuits you'll get if you have an abusive customer who doesn't want you to cut them off. > Implement your CALEA plan and file that paperwork with the FBI so they can find you > Register with the Copyright office so that you can deal with DMCA notices. > Establish your copyright policy and procedures. Have your lawyer review it. > Make sure you comply with 18 USC 2258A regarding reporting and registration for kiddie porn, train your employees Again, would you rather follow these requirements, or deal with the consequences of not following them? I'd recommend you make sure you have your safe harbors mapped out. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From andree+nanog at toonk.nl Wed Mar 29 20:53:55 2017 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 29 Mar 2017 13:53:55 -0700 Subject: Alternatives to bgpmon? In-Reply-To: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> References: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> Message-ID: <58DC1EE3.2030407@toonk.nl> Hi David, My secret spy satellite informs me that David Hubbard wrote On 2017-03-29, 12:21 PM: > Anyone have recommendations for an alternative service that works like bgpmon (external reachability/peer monitoring, route hijack alerts, etc)? Since their OpenDNS acquisition, I?ve found the service not working reliably, as in I receive no alerts even when I?m intentionally taking one of our peers offline, and after two attempts to find out why this is, I receive no response, so it seems support is now broken as well. The service still works the same as before. For support question folks can use support bgpmon.net (i see one ticket from you). I'll reach out off-list and see if we can figure out what you're running into. Cheers Andree (BGPmon) From kmedcalf at dessus.com Wed Mar 29 21:05:59 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 29 Mar 2017 15:05:59 -0600 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <470c9743-1f90-4b65-29d9-a4176dae4896@tnetconsulting.net> Message-ID: <233a8e312480794bb03ebc3d39d21a9b@mail.dessus.com> The purpose of SPF is to REJECT messages before the data phase. This cannot be done if you are checking the RFC-822 From: header since that requires accepting the message and invalidates the entire purpose of SPF. I have never seen an SPF implementation that uses the RFC-822 header From. Doing so would be pointless. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Grant Taylor via > NANOG > Sent: Wednesday, 29 March, 2017 09:26 > To: nanog at nanog.org > Subject: Re: Microsoft O365 labels nanog potential fraud? > > On 03/29/2017 09:12 AM, William Herrin wrote: > > Both SPF and DKIM are meant to be checked against the domain in the > > envelope sender (SMTP protocol-level return address) which the NANOG > list > > sets to nanog-bounces at nanog.org. Checking against the message header > "from" > > address is an incorrect implementation which will break essentially all > > mailing lists. > > That may be what the original intent was. > > Every SPF implementation I've seen has checked the SMTP envelope FROM > address /and/ the RFC 822 From: header address. > > Granted, that does not mean that it's the correct behavior. > > > > -- > Grant. . . . > unix || die From carl at five-ten-sg.com Wed Mar 29 21:28:30 2017 From: carl at five-ten-sg.com (Carl Byington) Date: Wed, 29 Mar 2017 14:28:30 -0700 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <15539534.4rWtqb57Ip@skynet.simkin.ca> References: <94D4DAA8-34FD-4104-B233-84585C590900@gmail.com> <15539534.4rWtqb57Ip@skynet.simkin.ca> Message-ID: <1490822910.16521.12.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2017-03-29 at 09:24 -0700, Alan Hodgson wrote: > So for DMARC+SPF to pass not only must the message come from a source > authorized by the envelope sender domain, but that domain must be the > same domain (or parent domain or subdomain) of the header From: > address. > For DMARC+DKIM to pass, the DKIM signature must pass and the DKIM > signing domain must be the same domain (or parent domain or subdomain) > of the header From: address. > Again, DMARC requires only one or the other mechanism to pass. So > messages forwarded intact should be OK if they have an aligned DKIM > signature. Brad Knowles wrote: > ...and it's easy to set things up in a way that you wind up shooting > yourself in the foot -- and possibly with a large thermonuclear > device. For an example of that (unless I am misunderstanding something), we have: --> Hello marketo-email.box.com [192.28.147.169], pleased to meet you <-- MAIL FROM:<$MUNGED at marketo-email.box.com> <-- RCPT TO: ... dkim pass header.d=mktdns.com rfc2822 from header = $MUNGED at email.box.com dig _dmarc.email.box.com txt +short "v=DMARC1; p=reject; ..." dig email.box.com txt +short "v=spf1 ip4:192.28.147.168 -all" So given the dmarc reject policy, it needs to pass either spf (which fails 192.28.147.168 != 192.28.147.169), or dkim (which fails since it is not signed by anything related to email.box.com. Am I missing something, or is that just broken? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAljcJe4ACgkQL6j7milTFsFUMwCfT4Wgr0kUHjhVPvi0wER3Nfz+ osAAni5YH25tTCGk49jESd5NOKVk3Okd =JL7y -----END PGP SIGNATURE----- From mel at beckman.org Wed Mar 29 21:32:08 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 29 Mar 2017 21:32:08 +0000 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <27265.1490820753@turing-police.cc.vt.edu> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> , <27265.1490820753@turing-police.cc.vt.edu> Message-ID: <05C3F1BC-6C02-48D7-866B-755A2A976559@beckman.org> I'm not saying such detailed regulation is really necessary, but it's not really a huge barrier either. Just try to open a food truck (all the rage these ads). You'll find many more regulations than this. The answer to over regulation is political lobbying. A good idea would be requiring retirement of existing obsolete rules before being allowed to create new ones. Oh, wait, that's actually being done now. -mel > On Mar 29, 2017, at 1:53 PM, "valdis.kletnieks at vt.edu" wrote: > > On Wed, 29 Mar 2017 16:02:45 -0400, Mark Radabaugh said: > >> And there you have much of the problem with this privacy bill. > > Hate to break it to you, but most of the gripes you have here are things > you really *want* to do - they're things that reduce your personal liability > and/or chance of ending up in prison. Just because you seem to be anti-regulation > doesn't rule out the existence of regulations that are actually there to *help* > you run your business. > >> Incorporate your business > > That's usually a given for *any* business unless you want to be sued to > your skivvies... > >> Obtain Liability, Workers Comp, Unemployment, Auto Insurance > > Ditto. > >> Obtain bandwidth and IP, fill out your ARIN information. > > You're gonna need to do that no matter how anti-regulation you are. > >> Pay the lawyer to write your ?Terms of Service? so that you have at least some chance of surviving the lawsuits > > Or you can gamble on the lawsuits you'll get if you have an abusive customer > who doesn't want you to cut them off. > >> Implement your CALEA plan and file that paperwork with the FBI so they can find you >> Register with the Copyright office so that you can deal with DMCA notices. >> Establish your copyright policy and procedures. Have your lawyer review it. >> Make sure you comply with 18 USC 2258A regarding reporting and registration for kiddie porn, train your employees > > Again, would you rather follow these requirements, or deal with the > consequences of not following them? I'd recommend you make sure you > have your safe harbors mapped out. > > > > From William.Murphy at uth.tmc.edu Wed Mar 29 21:50:57 2017 From: William.Murphy at uth.tmc.edu (Murphy, William) Date: Wed, 29 Mar 2017 21:50:57 +0000 Subject: Alternatives to bgpmon? In-Reply-To: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> References: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> Message-ID: <84ff8c94b38a494d95df09bc19ed0f3f@uth.tmc.edu> We are going to be trying ThousandEyes... They provide flexible alerting rules for various BGP issues and their visualization is excellent, kind of like BGPlay on steroids... Bill -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Wednesday, March 29, 2017 2:22 PM To: nanog at nanog.org Subject: Alternatives to bgpmon? Anyone have recommendations for an alternative service that works like bgpmon (external reachability/peer monitoring, route hijack alerts, etc)? Since their OpenDNS acquisition, I?ve found the service not working reliably, as in I receive no alerts even when I?m intentionally taking one of our peers offline, and after two attempts to find out why this is, I receive no response, so it seems support is now broken as well. Thanks, David From goemon at sasami.anime.net Wed Mar 29 21:53:11 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 29 Mar 2017 14:53:11 -0700 (PDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> Message-ID: Why aren't _ALL_ consumer privacy regulations managed by the FTC? Why is the FCC needed here? -Dan On Wed, 29 Mar 2017, Mark Radabaugh wrote: > >> On Mar 29, 2017, at 9:59 AM, Joe Loiacono wrote: >> >> Lowering barriers to entry is where the next political focus should be. >> >> Joe Loiacono >> > > And there you have much of the problem with this privacy bill. > > Read the actual Report and Order: https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-148A1.pdf > > 219 pages > > You want to start a competitive ISP these days? Make sure you: > > Incorporate your business > Obtain Liability, Workers Comp, Unemployment, Auto Insurance > Comply with the FCC Privacy Act (short reading, requires considerable investment in tracking opt in, opt out, privacy policies) > File the mandatory FCC 477 filings twice a year with detailed information on the geolocation of all of your customers and service area. > If offering VoIP service file your 499-A and Quarterly 499-Q?s with the FCC > Draft your ?Open Internet Disclosure Statement?, pay a FCC lawyer a couple grand to renew it, make sure it?s prominent on your website > Build your website > Obtain bandwidth and IP, fill out your ARIN information. > Make up your ?Consumer Label? for Broadband: https://www.fcc.gov/consumers/guides/consumer-labels-broadband-services (probably need a lawyer for this too..) > Pay the lawyer to write your ?Terms of Service? so that you have at least some chance of surviving the lawsuits > Implement your CALEA plan and file that paperwork with the FBI so they can find you > Register with the Copyright office so that you can deal with DMCA notices. > Establish your copyright policy and procedures. Have your lawyer review it. > Make sure you comply with 18 USC 2258A regarding reporting and registration for kiddie porn, train your employees > Make sure you have a CPNI policy, training, and report to the FCC yearly > Implement and file your Section 255 ?Disability Rights? policy and make sure you file yearly with the FCC your information > > Slap up a Ubiquiti access point and you can now make millions of dollars in short order. > > I?m sure I forgot a few things like ?build your network?, but that?s simple. > > Mark > > From ahodgson at lists.simkin.ca Wed Mar 29 22:03:20 2017 From: ahodgson at lists.simkin.ca (Alan Hodgson) Date: Wed, 29 Mar 2017 15:03:20 -0700 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <1490822910.16521.12.camel@ns.five-ten-sg.com> References: <15539534.4rWtqb57Ip@skynet.simkin.ca> <1490822910.16521.12.camel@ns.five-ten-sg.com> Message-ID: <2066629.BbQ8KXnJic@skynet.simkin.ca> On Wednesday 29 March 2017 14:28:30 Carl Byington wrote: > For an example of that (unless I am misunderstanding something), we > have: > > --> Hello marketo-email.box.com [192.28.147.169], pleased to meet you > <-- MAIL FROM:<$MUNGED at marketo-email.box.com> > <-- RCPT TO: ... > > dkim pass header.d=mktdns.com > rfc2822 from header = $MUNGED at email.box.com > > > dig _dmarc.email.box.com txt +short > "v=DMARC1; p=reject; ..." > > dig email.box.com txt +short > "v=spf1 ip4:192.28.147.168 -all" > > So given the dmarc reject policy, it needs to pass either spf (which > fails 192.28.147.168 != 192.28.147.169), or dkim (which fails since it > is not signed by anything related to email.box.com. > > Am I missing something, or is that just broken? That appears to be broken. The -all on the SPF record alone breaks it, since receivers should refuse it at that point. But yeah the DMARC is also broken. Interestingly, the mail I've seen recently from email.box.com has multiple signatures, one of which is from email.box.com. And it originated from 192.28.147.168. Weird. From fkittred at gwi.net Wed Mar 29 20:43:22 2017 From: fkittred at gwi.net (Fletcher Kittredge) Date: Wed, 29 Mar 2017 16:43:22 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> Message-ID: The vast majority of obligations you describe continue to exist and don't have anything to do with this bill. On Wed, Mar 29, 2017 at 4:02 PM, Mark Radabaugh wrote: > > > On Mar 29, 2017, at 9:59 AM, Joe Loiacono wrote: > > > > Lowering barriers to entry is where the next political focus should be. > > > > Joe Loiacono > > > > And there you have much of the problem with this privacy bill. > > Read the actual Report and Order: https://apps.fcc.gov/edocs_ > public/attachmatch/FCC-16-148A1.pdf public/attachmatch/FCC-16-148A1.pdf> > > 219 pages > > You want to start a competitive ISP these days? Make sure you: > > Incorporate your business > Obtain Liability, Workers Comp, Unemployment, Auto Insurance > Comply with the FCC Privacy Act (short reading, requires considerable > investment in tracking opt in, opt out, privacy policies) > File the mandatory FCC 477 filings twice a year with detailed information > on the geolocation of all of your customers and service area. > If offering VoIP service file your 499-A and Quarterly 499-Q?s with the FCC > Draft your ?Open Internet Disclosure Statement?, pay a FCC lawyer a couple > grand to renew it, make sure it?s prominent on your website > Build your website > Obtain bandwidth and IP, fill out your ARIN information. > Make up your ?Consumer Label? for Broadband: > https://www.fcc.gov/consumers/guides/consumer-labels-broadband-services < > https://www.fcc.gov/consumers/guides/consumer-labels-broadband-services> > (probably need a lawyer for this too..) > Pay the lawyer to write your ?Terms of Service? so that you have at least > some chance of surviving the lawsuits > Implement your CALEA plan and file that paperwork with the FBI so they can > find you > Register with the Copyright office so that you can deal with DMCA notices. > Establish your copyright policy and procedures. Have your lawyer review > it. > Make sure you comply with 18 USC 2258A regarding reporting and > registration for kiddie porn, train your employees > Make sure you have a CPNI policy, training, and report to the FCC yearly > Implement and file your Section 255 ?Disability Rights? policy and make > sure you file yearly with the FCC your information > > Slap up a Ubiquiti access point and you can now make millions of dollars > in short order. > > I?m sure I forgot a few things like ?build your network?, but that?s > simple. > > Mark > > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net From mark at amplex.net Wed Mar 29 21:13:59 2017 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 29 Mar 2017 17:13:59 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <27265.1490820753@turing-police.cc.vt.edu> References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> <27265.1490820753@turing-police.cc.vt.edu> Message-ID: > On Mar 29, 2017, at 4:52 PM, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 29 Mar 2017 16:02:45 -0400, Mark Radabaugh said: > >> And there you have much of the problem with this privacy bill. > > Hate to break it to you, but most of the gripes you have here are things > you really *want* to do - they're things that reduce your personal liability > and/or chance of ending up in prison. Just because you seem to be anti-regulation > doesn't rule out the existence of regulations that are actually there to *help* > you run your business. > >> Incorporate your business > > That's usually a given for *any* business unless you want to be sued to > your skivvies... > >> Obtain Liability, Workers Comp, Unemployment, Auto Insurance > > Ditto. > >> Obtain bandwidth and IP, fill out your ARIN information. > > You're gonna need to do that no matter how anti-regulation you are. > >> Pay the lawyer to write your ?Terms of Service? so that you have at least some chance of surviving the lawsuits > > Or you can gamble on the lawsuits you'll get if you have an abusive customer > who doesn't want you to cut them off. > >> Implement your CALEA plan and file that paperwork with the FBI so they can find you >> Register with the Copyright office so that you can deal with DMCA notices. >> Establish your copyright policy and procedures. Have your lawyer review it. >> Make sure you comply with 18 USC 2258A regarding reporting and registration for kiddie porn, train your employees > > Again, would you rather follow these requirements, or deal with the > consequences of not following them? I'd recommend you make sure you > have your safe harbors mapped out. > Valdis, You miss my point. One of the major reasons you have a limited number of ISP?s to choose from is that it?s not that simple to start an ISP. There is a lot of regulation and cost involved, much of which is essentially nonsense regulation that has very little application to a small provider, yet can results in significant fines from regulators for doing nothing other than failing to file a annual certification. Did Congress go a bit too far in the CRA? Probably - but at the same time the FCC went way too far with the regulation. Mark From mark at amplex.net Wed Mar 29 22:06:08 2017 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 29 Mar 2017 18:06:08 -0400 Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: References: <20170326230534.GA2707@eff.org> <20170328214525.GA6357@gsp.org> <1466975642.4813.1490738299811.JavaMail.mhammett@ThunderFuck> <373B8D77-0C6F-4192-8F6D-D6989591B9D3@ianai.net> <910954015.5141.1490753919520.JavaMail.mhammett@ThunderFuck> <736DFDB0-BD45-4E76-840B-931BF58FC8BD@ianai.net> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> Message-ID: <5956FC45-A133-4027-A368-EA0EBD896287@amplex.net> > On Mar 29, 2017, at 5:53 PM, Dan Hollis wrote: > > Why aren't _ALL_ consumer privacy regulations managed by the FTC? > > Why is the FCC needed here? > > -Dan This was a consequence of the FCC declaring "information services? a Title II service in an attempt to avoid losing yet another lawsuit over the ?Open Internet Principals? of No Blocking, No Throttling, and No Paid Prioritization. Once the FCC declared the internet (information service) a common carrier service that removed all authority of the FTC to regulate. The rules the FCC had in place on privacy are geared toward phone services, not the Internet. The rules didn?t fit so they attempted to write internet specific regulations. There was some good stuff in what the FCC wrote but a whole lot of overkill as well. So what happens now? If Trump signs the CRA (expected) the FCC can not recreate the rules until Congress authorizes them to. Getting legislation allowing more regulation through Congress is pretty unlikely for the next couple of years. If the FCC decides to roll back Title II that takes ?information service? out of Title II. The FTC regains the authority to regulate Internet Service. Congress is looking at a complete rewrite of the Communications Act. Everything is up for grabs if this happens. Mark From VictorG at sabey.com Wed Mar 29 21:54:20 2017 From: VictorG at sabey.com (Victor Gonzalez) Date: Wed, 29 Mar 2017 21:54:20 +0000 Subject: Alternatives to bgpmon? In-Reply-To: <84ff8c94b38a494d95df09bc19ed0f3f@uth.tmc.edu> References: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> <84ff8c94b38a494d95df09bc19ed0f3f@uth.tmc.edu> Message-ID: I just signed up for the free account .. gonna give a spin Victor -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Murphy, William Sent: Wednesday, March 29, 2017 2:51 PM To: 'David Hubbard' ; nanog at nanog.org Subject: RE: Alternatives to bgpmon? We are going to be trying ThousandEyes... They provide flexible alerting rules for various BGP issues and their visualization is excellent, kind of like BGPlay on steroids... Bill -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard Sent: Wednesday, March 29, 2017 2:22 PM To: nanog at nanog.org Subject: Alternatives to bgpmon? Anyone have recommendations for an alternative service that works like bgpmon (external reachability/peer monitoring, route hijack alerts, etc)? Since their OpenDNS acquisition, I?ve found the service not working reliably, as in I receive no alerts even when I?m intentionally taking one of our peers offline, and after two attempts to find out why this is, I receive no response, so it seems support is now broken as well. Thanks, David From marka at isc.org Thu Mar 30 04:21:30 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 30 Mar 2017 15:21:30 +1100 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: Your message of "Wed, 29 Mar 2017 15:03:20 -0700." <2066629.BbQ8KXnJic@skynet.simkin.ca> References: <15539534.4rWtqb57Ip@skynet.simkin.ca> <1490822910.16521.12.camel@ns.five-ten-sg.com> <2066629.BbQ8KXnJic@skynet.simkin.ca> Message-ID: <20170330042130.3B3846A49BF3@rock.dv.isc.org> In message <2066629.BbQ8KXnJic at skynet.simkin.ca>, Alan Hodgson writes: > On Wednesday 29 March 2017 14:28:30 Carl Byington wrote: > > For an example of that (unless I am misunderstanding something), we > > have: > > > > --> Hello marketo-email.box.com [192.28.147.169], pleased to meet you > > <-- MAIL FROM:<$MUNGED at marketo-email.box.com> > > <-- RCPT TO: ... > > > > dkim pass header.d=mktdns.com > > rfc2822 from header = $MUNGED at email.box.com > > > > > > dig _dmarc.email.box.com txt +short > > "v=DMARC1; p=reject; ..." > > > > dig email.box.com txt +short > > "v=spf1 ip4:192.28.147.168 -all" Well you should be checking the correct TXT record for SPF. dig marketo-email.box.com txt +short "v=spf1 ip4:192.28.147.168 ip4:192.28.147.169 -all" > > So given the dmarc reject policy, it needs to pass either spf (which > > fails 192.28.147.168 != 192.28.147.169), or dkim (which fails since it > > is not signed by anything related to email.box.com. > > > > Am I missing something, or is that just broken? > > That appears to be broken. The -all on the SPF record alone breaks it, since > receivers should refuse it at that point. But yeah the DMARC is also broken. > > Interestingly, the mail I've seen recently from email.box.com has multiple > signatures, one of which is from email.box.com. And it originated from > 192.28.147.168. Weird. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From carl at five-ten-sg.com Thu Mar 30 06:28:18 2017 From: carl at five-ten-sg.com (Carl Byington) Date: Wed, 29 Mar 2017 23:28:18 -0700 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <20170330042130.3B3846A49BF3@rock.dv.isc.org> References: <15539534.4rWtqb57Ip@skynet.simkin.ca> <1490822910.16521.12.camel@ns.five-ten-sg.com> <2066629.BbQ8KXnJic@skynet.simkin.ca> <20170330042130.3B3846A49BF3@rock.dv.isc.org> Message-ID: <1490855298.3179.21.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2017-03-30 at 15:21 +1100, Mark Andrews wrote: > Well you should be checking the correct TXT record for SPF. > dig marketo-email.box.com txt +short > "v=spf1 ip4:192.28.147.168 ip4:192.28.147.169 -all" Hm, a closer reading of rfc7489 sheds some light on this: Would dmarc-spf consider marketo-email.box.com to be 'aligned' with the from header email.box.com domain? It is neither a child nor parent of email.box.com. The _dmarc txt record for email.box.com has no aspf: tag, so we should be operating in spf/dkim relaxed alignment mode. rfc7489, when discussing relaxed identifier alignment, says the "Organizational Domain" of the identifiers must match. But there is no explicit example of that. Instead, the examples talk about one of the identifiers being a parent of the other identifier. The envelope from marketo-email.box.com and the 2822 header from email.box.com have the same box.com organizational domain. If we ignore the examples in rfc7489, it looks like this is NOT broken. I am probably not the only one that wrote code matching on the parent/child relationship of the identifiers, rather than computing the Organizational Domains and matching those. As Mr. Hodgson pointed out, box.com has very recently started sending mail with multiple dkim signatures, header.d=email.box.com and 2822 header from = email.box.com. Now off to fix my code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAljcpTkACgkQL6j7milTFsHROACfYDmp1Vv7kUwWZQ9m1YCgSB+C y9kAnitNWUvORSQNgOv5AsyUL35Y8Yhc =CDq3 -----END PGP SIGNATURE----- From nanog at ics-il.net Thu Mar 30 13:12:43 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 30 Mar 2017 08:12:43 -0500 (CDT) Subject: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal In-Reply-To: <5956FC45-A133-4027-A368-EA0EBD896287@amplex.net> References: <20170326230534.GA2707@eff.org> <924720740.5345.1490783749164.JavaMail.mhammett@ThunderFuck> <01FC2F16-B4D5-4238-AE9F-957E4C1A380D@ianai.net> <133093107.5521.1490793063839.JavaMail.mhammett@ThunderFuck> <5956FC45-A133-4027-A368-EA0EBD896287@amplex.net> Message-ID: <2077913626.122.1490879559826.JavaMail.mhammett@ThunderFuck> Wait, so are you saying that the "journalists" and fanboys that pushes so hard for Title II had no idea of the implications of their desires? Say it isn't so. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Radabaugh" To: "Dan Hollis" Cc: "NANOG list" , "NANOG" Sent: Wednesday, March 29, 2017 5:06:08 PM Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal > On Mar 29, 2017, at 5:53 PM, Dan Hollis wrote: > > Why aren't _ALL_ consumer privacy regulations managed by the FTC? > > Why is the FCC needed here? > > -Dan This was a consequence of the FCC declaring "information services? a Title II service in an attempt to avoid losing yet another lawsuit over the ?Open Internet Principals? of No Blocking, No Throttling, and No Paid Prioritization. Once the FCC declared the internet (information service) a common carrier service that removed all authority of the FTC to regulate. The rules the FCC had in place on privacy are geared toward phone services, not the Internet. The rules didn?t fit so they attempted to write internet specific regulations. There was some good stuff in what the FCC wrote but a whole lot of overkill as well. So what happens now? If Trump signs the CRA (expected) the FCC can not recreate the rules until Congress authorizes them to. Getting legislation allowing more regulation through Congress is pretty unlikely for the next couple of years. If the FCC decides to roll back Title II that takes ?information service? out of Title II. The FTC regains the authority to regulate Internet Service. Congress is looking at a complete rewrite of the Communications Act. Everything is up for grabs if this happens. Mark From m4rtntns at gmail.com Thu Mar 30 15:50:34 2017 From: m4rtntns at gmail.com (Martin T) Date: Thu, 30 Mar 2017 18:50:34 +0300 Subject: association between ASN and company name in ARIN region Message-ID: Hi, how to associate AS number with company name in ARIN region? For example in a small European country, where I leave, it can be done roughly like that: 1) ISP named "XYZ" and IP transit customer named "KLM Inc." sign an IP transit contract 2) IP transit customer "KLM Inc." tells to ISP that their AS number is 123 3) ISP engineers, who configure the service, check the "org" attribute value from AS123 "aut-num" object from RIPE database. This is a RIPE NCC managed value. For example it is ORG-KLM-RIPE. 4) then they check "org-name" attribute value for ORG-KLM-RIPE organisation object. Again, this is RIPE NCC managed value. "org-name" value(organization name) is exactly the same as in company registration papers. 5) now they can search for this organization name from country centre of registers and information systems database which contains registration papers for all the companies in this country and contact with this company if anything looks suspicious This is obviously simply an example to show that it is possible to trace from AS number back to company registration papers and thus to even people behind the company(listed in company registration papers). Is it possible to make a similar connection between AS number and company name in ARIN region? In other words, how do you find out that company is eligible to use AS number? thanks, Martin From arnold at nipper.de Thu Mar 30 16:44:42 2017 From: arnold at nipper.de (Arnold Nipper) Date: Thu, 30 Mar 2017 18:44:42 +0200 Subject: association between ASN and company name in ARIN region In-Reply-To: References: Message-ID: <67f61a68-0aa3-b26b-2c97-051cd707011d@nipper.de> On 30.03.2017 17:50, Martin T wrote: > Is it possible to make a similar connection between AS number and > company name in ARIN region? In other words, how do you find out that > company is eligible to use AS number? > This doesn't work for you? whois -h whois.arin.net as174 | egrep '^ASNumber|OrgName|Address|City|StateProv|PostalCode|Country' ASNumber: 174 OrgName: Cogent Communications Address: 2450 N Street NW City: Washington StateProv: DC PostalCode: 20037 Country: US whois -h whois.arin.net as714 | egrep '^ASNumber|OrgName|Address|City|StateProv|PostalCode|Country' ASNumber: 714 OrgName: Apple Inc. Address: 20400 Stevens Creek Blvd., City Center Bldg 3 City: Cupertino StateProv: CA PostalCode: 95014 Country: US And then lookup companies here: https://en.wikipedia.org/wiki/List_of_company_registers#United_States Arnold -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From ahodgson at lists.simkin.ca Thu Mar 30 15:14:19 2017 From: ahodgson at lists.simkin.ca (Alan Hodgson) Date: Thu, 30 Mar 2017 08:14:19 -0700 Subject: Microsoft O365 labels nanog potential fraud? In-Reply-To: <1490855298.3179.21.camel@ns.five-ten-sg.com> References: <20170330042130.3B3846A49BF3@rock.dv.isc.org> <1490855298.3179.21.camel@ns.five-ten-sg.com> Message-ID: <62130604.ngmuSqsYZd@skynet.simkin.ca> On Wednesday 29 March 2017 23:28:18 Carl Byington wrote: > Would dmarc-spf consider marketo-email.box.com to be 'aligned' with the > from header email.box.com domain? It is neither a child nor parent of > email.box.com. > As long as they're under the same Organizational Domain they should pass a relaxed mode test. The examples are somewhat meager in the RFC but the wording in section 3.1 seems clear. If senders want a tighter policy they have strict mode available. From fw at deneb.enyo.de Fri Mar 31 08:59:40 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 31 Mar 2017 10:59:40 +0200 Subject: association between ASN and company name in ARIN region In-Reply-To: <67f61a68-0aa3-b26b-2c97-051cd707011d@nipper.de> (Arnold Nipper's message of "Thu, 30 Mar 2017 18:44:42 +0200") References: <67f61a68-0aa3-b26b-2c97-051cd707011d@nipper.de> Message-ID: <87pogxn7nn.fsf@mid.deneb.enyo.de> * Arnold Nipper: > On 30.03.2017 17:50, Martin T wrote: > >> Is it possible to make a similar connection between AS number and >> company name in ARIN region? In other words, how do you find out that >> company is eligible to use AS number? >> > > > This doesn't work for you? > > whois -h whois.arin.net as174 | egrep Note that depending on the WHOIS client, this does not work. The correct AS number query syntax for whois.arin.net does not include an ?AS? prefix. The difference is only visibile for AS numbers with in an AS range object. 14745 is an example that shows the difference. From cscora at apnic.net Fri Mar 31 18:02:41 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Apr 2017 04:02:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170331180241.E199DC44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 01 Apr, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 640530 Prefixes after maximum aggregation (per Origin AS): 249983 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 309623 Total ASes present in the Internet Routing Table: 56735 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 49101 Origin ASes announcing only one prefix: 21741 Transit ASes present in the Internet Routing Table: 7634 Transit-only ASes present in the Internet Routing Table: 218 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 76 Numnber of instances of unregistered ASNs: 77 Number of 32-bit ASNs allocated by the RIRs: 17957 Number of 32-bit ASNs visible in the Routing Table: 13960 Prefixes from 32-bit ASNs in the Routing Table: 56752 Number of bogon 32-bit ASNs visible in the Routing Table: 46 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 407 Number of addresses announced to Internet: 2840219780 Equivalent to 169 /8s, 74 /16s and 80 /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: 98.5 Total number of prefixes smaller than registry allocations: 212596 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 175385 Total APNIC prefixes after maximum aggregation: 50122 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 174735 Unique aggregates announced from the APNIC address blocks: 72195 APNIC Region origin ASes present in the Internet Routing Table: 7980 APNIC Prefixes per ASN: 21.90 APNIC Region origin ASes announcing only one prefix: 2239 APNIC Region transit ASes present in the Internet Routing Table: 1126 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2813 Number of APNIC addresses announced to Internet: 762402692 Equivalent to 45 /8s, 113 /16s and 87 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 195495 Total ARIN prefixes after maximum aggregation: 93596 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 197776 Unique aggregates announced from the ARIN address blocks: 90567 ARIN Region origin ASes present in the Internet Routing Table: 17861 ARIN Prefixes per ASN: 11.07 ARIN Region origin ASes announcing only one prefix: 6625 ARIN Region transit ASes present in the Internet Routing Table: 1767 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: 1874 Number of ARIN addresses announced to Internet: 1108038560 Equivalent to 66 /8s, 11 /16s and 83 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 172535 Total RIPE prefixes after maximum aggregation: 84680 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 167831 Unique aggregates announced from the RIPE address blocks: 101427 RIPE Region origin ASes present in the Internet Routing Table: 23855 RIPE Prefixes per ASN: 7.04 RIPE Region origin ASes announcing only one prefix: 11015 RIPE Region transit ASes present in the Internet Routing Table: 3399 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5692 Number of RIPE addresses announced to Internet: 710893696 Equivalent to 42 /8s, 95 /16s and 96 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 80218 Total LACNIC prefixes after maximum aggregation: 17811 LACNIC Deaggregation factor: 4.50 Prefixes being announced from the LACNIC address blocks: 81413 Unique aggregates announced from the LACNIC address blocks: 38215 LACNIC Region origin ASes present in the Internet Routing Table: 5758 LACNIC Prefixes per ASN: 14.14 LACNIC Region origin ASes announcing only one prefix: 1536 LACNIC Region transit ASes present in the Internet Routing Table: 1051 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3279 Number of LACNIC addresses announced to Internet: 170316512 Equivalent to 10 /8s, 38 /16s and 210 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16786 Total AfriNIC prefixes after maximum aggregation: 3711 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 18368 Unique aggregates announced from the AfriNIC address blocks: 6864 AfriNIC Region origin ASes present in the Internet Routing Table: 1033 AfriNIC Prefixes per ASN: 17.78 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 201 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 302 Number of AfriNIC addresses announced to Internet: 88060160 Equivalent to 5 /8s, 63 /16s and 177 /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 5566 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3778 391 262 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2992 904 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2762 11150 756 KIXS-AS-KR Korea Telecom, KR 9829 2729 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2271 8649 45 CMNET-GD Guangdong Mobile Communication 4755 2071 421 220 TATACOMM-AS TATA Communications formerl 45899 1947 1332 113 VNPT-AS-VN VNPT Corp, VN 9583 1573 121 541 SIFY-AS-IN Sify Limited, IN 4808 1566 1791 447 CHINA169-BJ China Unicom Beijing Provin Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3687 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3348 1333 83 SHAW - Shaw Communications Inc., CA 18566 2186 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1982 2094 408 CHARTER-NET-HKY-NC - Charter Communicat 16509 1792 3357 573 AMAZON-02 - Amazon.com, Inc., US 209 1789 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1728 321 392 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1684 854 231 ITCDELTA - Earthlink, Inc., US 701 1573 10582 647 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS, SA 20940 3056 1125 2171 AKAMAI-ASN1, US 9121 2685 1691 17 TTNET, TR 34984 2005 328 384 TELLCOM-AS, TR 8551 1649 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 13188 1645 99 59 TRIOLAN, UA 12479 1548 1043 53 UNI2-AS, ES 12389 1379 1288 572 ROSTELECOM-AS, RU 9198 1281 352 23 KAZTELECOM-AS, KZ 6849 1265 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3541 545 174 Telmex Colombia S.A., CO 8151 2516 3389 549 Uninet S.A. de C.V., MX 11830 1820 369 57 Instituto Costarricense de Electricidad 7303 1555 1003 248 Telecom Argentina S.A., AR 6503 1541 437 53 Axtel, S.A.B. de C.V., MX 6147 1214 377 27 Telefonica del Peru S.A.A., PE 28573 1066 2293 185 CLARO S.A., BR 3816 1020 488 182 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 988 280 35 Techtel LMDS Comunicaciones Interactiva 11172 925 126 79 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1313 399 43 LINKdotNET-AS, EG 36903 717 360 127 MT-MPLS, MA 37611 700 67 6 Afrihost, ZA 36992 598 1375 26 ETISALAT-MISR, EG 24835 497 722 14 RAYA-AS, EG 8452 438 1474 16 TE-AS TE-AS, EG 37492 399 318 73 ORANGE-, TN 29571 368 36 10 CITelecom-AS, CI 15399 341 35 7 WANANCHI-, KE 2018 287 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5566 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3778 391 262 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3687 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3541 545 174 Telmex Colombia S.A., CO 6327 3348 1333 83 SHAW - Shaw Communications Inc., CA 39891 3334 171 18 ALJAWWALSTC-AS, SA 20940 3056 1125 2171 AKAMAI-ASN1, US 17974 2992 904 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2762 11150 756 KIXS-AS-KR Korea Telecom, KR 9829 2729 1499 540 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3687 3535 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3778 3516 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3541 3367 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS, SA 6327 3348 3265 SHAW - Shaw Communications Inc., CA 17974 2992 2919 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2685 2668 TTNET, TR 9808 2271 2226 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2729 2189 BSNL-NIB National Internet Backbone, IN 18566 2186 2077 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS, IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.157.128.0/17 393899 -Reserved AS-, ZZ 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:280 /13:538 /14:1051 /15:1827 /16:13229 /17:7571 /18:13365 /19:24622 /20:38269 /21:41237 /22:75790 /23:63097 /24:358116 /25:551 /26:413 /27:291 /28:39 /29:25 /30:24 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3139 3348 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS, SA 22773 2854 3687 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2079 2186 MEGAPATH5-US - MegaPath Corporation, US 9121 1901 2685 TTNET, TR 30036 1534 1728 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1458 3541 Telmex Colombia S.A., CO 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1369 1645 TRIOLAN, UA 6983 1323 1684 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1617 2:842 4:26 5:2479 6:34 8:1062 12:1819 13:107 14:1797 15:22 16:2 17:113 18:129 19:1 20:55 23:2179 24:1852 25:2 27:2380 31:1897 32:89 33:5 34:1 35:19 36:384 37:2563 38:1358 39:45 40:99 41:2924 42:461 43:1909 44:67 45:2487 46:2754 47:114 49:1207 50:964 51:18 52:799 54:360 55:7 56:4 57:41 58:1657 59:1019 60:388 61:1950 62:1524 63:1920 64:4611 65:2206 66:4534 67:2272 68:1192 69:3329 70:1306 71:570 72:2162 74:2636 75:405 76:425 77:1467 78:1656 79:1317 80:1361 81:1415 82:968 83:726 84:877 85:1787 86:487 87:1150 88:798 89:2068 90:167 91:6142 92:1024 93:2389 94:2373 95:2828 96:565 97:359 98:952 99:85 100:155 101:1282 103:14176 104:2799 105:163 106:494 107:1561 108:814 109:2603 110:1285 111:1733 112:1169 113:1342 114:1033 115:1799 116:1786 117:1687 118:2073 119:1581 120:956 121:1099 122:2181 123:1845 124:1536 125:1852 128:735 129:619 130:419 131:1415 132:517 133:190 134:606 135:219 136:518 137:429 138:1886 139:422 140:377 141:540 142:737 143:917 144:769 145:170 146:1029 147:663 148:1376 149:552 150:705 151:948 152:748 153:314 154:783 155:982 156:564 157:610 158:442 159:1458 160:568 161:751 162:2460 163:517 164:798 165:1169 166:390 167:1233 168:2600 169:771 170:3052 171:289 172:995 173:1819 174:808 175:740 176:1803 177:4060 178:2490 179:1120 180:2203 181:1895 182:2293 183:978 184:835 185:9232 186:3270 187:2199 188:2535 189:1779 190:8041 191:1271 192:9377 193:5773 194:4657 195:3844 196:1986 197:1263 198:5549 199:5876 200:7353 201:4099 202:10293 203:9840 204:4479 205:2758 206:3002 207:3112 208:3912 209:3954 210:3960 211:2113 212:2806 213:2506 214:864 215:64 216:5872 217:2039 218:840 219:612 220:1714 221:910 222:735 223:1166 End of report