From benno at NLnetLabs.nl Tue May 1 12:07:28 2018 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 1 May 2018 14:07:28 +0200 Subject: RIPE 76: Call for Late Submissions and Lightning Talks Message-ID: Dear colleagues, Summary: The RIPE PC invites late submissions (30 min) and Lightning Talks (10 min) for RIPE 76 Plenary. Similar to RIPE 74, and distinct from other previous RIPE Meetings, the RIPE Programme Committee decided to keep one plenary slot open for a so-called "late submission". This plenary slot gives the community the opportunity to submit presentations that report on recent developments, issues, security incidents, etc., that are relevant to the RIPE audience. Also please consider submitting a Lightning Talk for the Monday plenary. During the meeting week, we will accept Lightning Talk submissions for Tuesday and Friday. Please submit your plenary "late submission" or Lightning Talk via the PC submission system: https://ripe76.ripe.net/submission-form/ The deadline for the late submission is *Monday, 7 May*. Kind regards, Benno Overeinder RIPE PC Chair https://ripe76.ripe.net/programme/ripe-pc/ -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From EPers at ansencorp.com Tue May 1 13:25:48 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Tue, 1 May 2018 13:25:48 +0000 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: <9ffa07075d7c4e5c86238a9f648c2497@ansencorp.com> MFI was abandoned by ubnt some time ago. I've got a few of their environmental monitoring devices from that line in place and wouldn't really recommend any of it. The controller software is flakey, finicky, and hasn't been updated in years. -Ed -----Original Message----- From: NANOG On Behalf Of Michel 'ic' Luczak Sent: Monday, April 30, 2018 3:19 PM To: Andy Ringsmuth Cc: North American Network Operators' Group Subject: Re: Remote power cycle recommendations If rack-mount is not a hard requirement, I would definitely look into Ubiquiti’s mPower range. You will find anything from a single socket (WiFi only) to a 6 socket PDU (WiFi and Ethernet, probably 8 sockets for US but I’m in Europe) with central management system (free) and detailed consumption graphs and costs if you provide the kWh cost. I’m running many of those with the controller/management software installed remotely in a central location and have several alerts and automation scripts setup when consumption goes beyond a certain level (meaning the equipment has crashed). https://www.ubnt.com/mfi/mpower/ Regards, Michel > On 27 Apr 2018, at 17:46, Andy Ringsmuth wrote: > > I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. > > I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. > > What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. > > Thanks in advance. > > ---- > Andy Ringsmuth > andy at newslink.com > News Link – Manager Technology, Travel & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > From nanog at ics-il.net Tue May 1 13:28:16 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 1 May 2018 08:28:16 -0500 (CDT) Subject: "Weird" Traffic about 10 hours ago In-Reply-To: <1099732532.5828.1525180611753.JavaMail.mhammett@ThunderFuck> Message-ID: <1657390686.5861.1525181294397.JavaMail.mhammett@ThunderFuck> This is going to be extremely scientific. Did anyone else see "weird" stuff going on about 10 hours ago, about 6 PM Central on April 30th? I'm based in the Chicago area and have a large client on the east coast. I saw about a 25% drop in traffic for a half hour to an hour. Another Midwestern ISP also saw about 25% drops on two different upstream connections. A friend of mine runs an ISP in Virginia. He reported a dip in traffic (though didn't report how much of a drop), but also pings and IPSEC\L2TP worked, but couldn't SSH or do other activities. That friend reported another ISP in Virginia had problems at that same time. An ISP in Cyprus reported issues at that time. I'm looking to firm up what kind of issues and verify the time. Yet other ISPs report no problems at all. Smooth ramps on traffic graphs as one would expect at the beginning of prime time. I thought maybe "something" happened in Ashburn (fiber cut, DWDM card failure, etc.) as my client has a wave from the east coast to me in Chicago, but then the Midwestern ISP shouldn't have any dependency on Ashburn, given Chicago and Dallas. Then there's the guy in Cyprus, which shouldn't have any bearing on anything that happens over here in the States. I thought maybe it was an epic failure at one of the CDNs or other content networks, but then that wouldn't impact SSH or other management activities. Anyone else have any other data to help figure out what caused this? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From aaron at heyaaron.com Tue May 1 14:44:52 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 01 May 2018 14:44:52 +0000 Subject: "Weird" Traffic about 10 hours ago In-Reply-To: <1657390686.5861.1525181294397.JavaMail.mhammett@ThunderFuck> References: <1099732532.5828.1525180611753.JavaMail.mhammett@ThunderFuck> <1657390686.5861.1525181294397.JavaMail.mhammett@ThunderFuck> Message-ID: My extremely un-scientific reply: I make a lot of connections from Washington State to Virginia every day. Around 5 PM PDT yesterday, I got booted and had trouble re-connecting for about 10 minutes. I figured it was just me, but then a handful of sites wouldn't load for me while others had no trouble. I started to do some traceroutes and they all succeeded, then I noticed my connections to Virginia were restored. I don't think it lasted for more than 10 minutes whatever it was. -A On Tue, May 1, 2018 at 6:31 AM Mike Hammett wrote: > This is going to be extremely scientific. > > Did anyone else see "weird" stuff going on about 10 hours ago, about 6 PM > Central on April 30th? I'm based in the Chicago area and have a large > client on the east coast. I saw about a 25% drop in traffic for a half hour > to an hour. > Another Midwestern ISP also saw about 25% drops on two different upstream > connections. > A friend of mine runs an ISP in Virginia. He reported a dip in traffic > (though didn't report how much of a drop), but also pings and IPSEC\L2TP > worked, but couldn't SSH or do other activities. > That friend reported another ISP in Virginia had problems at that same > time. > An ISP in Cyprus reported issues at that time. I'm looking to firm up what > kind of issues and verify the time. > > > Yet other ISPs report no problems at all. Smooth ramps on traffic graphs > as one would expect at the beginning of prime time. > > > I thought maybe "something" happened in Ashburn (fiber cut, DWDM card > failure, etc.) as my client has a wave from the east coast to me in > Chicago, but then the Midwestern ISP shouldn't have any dependency on > Ashburn, given Chicago and Dallas. > Then there's the guy in Cyprus, which shouldn't have any bearing on > anything that happens over here in the States. > > I thought maybe it was an epic failure at one of the CDNs or other content > networks, but then that wouldn't impact SSH or other management activities. > > > Anyone else have any other data to help figure out what caused this? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From Jacques.Latour at cira.ca Tue May 1 16:11:58 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Tue, 1 May 2018 16:11:58 +0000 Subject: Announcement - Joint CENTR-Tech / DNS-OARC Workshop, Amsterdam, NL, 13th/14th October 2018 Message-ID: <01a3825e65ba47ab955e46e625471d92@cira.ca> Hi all! The 29th DNS-OARC Workshop will be a joint workshop combined with CENTR-Tech and will take place at the Hotel Okura, Amsterdam, Netherlands, on October 13th and 14th 2018. Workshop Milestones: - 01 May 2018 - Workshop Announcement - 01 Jun 2018 - Submissions and Registrations open via Indico - 13 Jul 2018 - Deadline for submission - 17 Aug 2018 - Contribution list published - 14 Sep 2018 - Full agenda published - 06 Oct 2018 - Deadline for slideset submission - 13 Oct 2018 - Workshop Jacques , on behalf of the joint Programme Committee OARC depends on sponsorship to fund its workshops and associated social events.  Please contact if your organization is interested in becoming a sponsor. From sean at donelan.com Wed May 2 02:55:32 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 1 May 2018 22:55:32 -0400 (EDT) Subject: Company threatens to cut Northern Marianas cable Message-ID: In 2015, the only submarine cable connecting the Northern Marianas Islands, a U.S. Territory, was damaged by a boulder. It cut off all telecommunications to the U.S. Territory for several weeks. To obtain a second cable for the islands, the CNMI government signed an agreement to subsidize a second fiber optic cable. Apparently there is now a dispute about the subsidy. https://www.radionz.co.nz/international/pacific-news/356123/company-threatens-to-cut-northern-marianas-cable A telecommunications company in the Northern Marianas is threatening to cut the fibre optic cable that connects Tinian and Rota to Saipan if the government fails to provide $US1.3 million it promised to pay for the service. Under a memorandum of agreement signed with the CNMI government in 2016, Docomo Pacific agreed to include Tinian and Rota in connecting their fibre optic cable 'ATISA' at a fee of $US650,000 per island. Earlier this week, the House of Representative included the $US1.3 million commitment to the telco in the $US15 million appropriations bill that also gave $US7 million to the CNMI Judiciary to fix its mould and air-conditioning problems. The legislation still needs to be passed by the senate and supported by the governor. From surfer at mauigateway.com Wed May 2 03:39:24 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 1 May 2018 20:39:24 -0700 Subject: Company threatens to cut Northern Marianas cable Message-ID: <20180501203924.17BCCD2C@m0117565.ppops.net> ------ sean at donelan.com wrote: -------- From: Sean Donelan In 2015, the only submarine cable connecting the Northern Marianas Islands, a U.S. Territory, was damaged by a boulder. It cut off all telecommunications to the U.S. Territory for several weeks. To obtain a second cable for the islands, the CNMI government signed an agreement to subsidize a second fiber optic cable. -------------------------------------------------------- Note that's the second cable; for redundancy. http://www.pireport.org/articles/2016/11/03/saipans-sugar-dock-beaches-be-closed-during-undersea-cable-installation "Last year, the severance of IT&E’s fiber optic cable—the CNMI’s lone undersea cable—effectively disconnected the islands from the rest of the world as Internet and phone lines went down and put commerce at a standstill." "Docomo Pacific, owned by NTT Docomo Inc. of Japan, decided to place its own fiber optic cable along the main islands of Saipan, Rota and Tinian." “Should there be a natural phenomenon, we don’t want to have all our eggs in the same basket. Having that separation would minimize that risk. We were also looking to create as much separation to existing cables as possible,” That they didn't have much satellite backup is surprising to say the least. Especially with O3B and others soon coming up. https://en.wikipedia.org/wiki/O3b_%28satellite%29 "The O3b constellation began offering service in March 2014" scott --- sean at donelan.com wrote: From: Sean Donelan In 2015, the only submarine cable connecting the Northern Marianas Islands, a U.S. Territory, was damaged by a boulder. It cut off all telecommunications to the U.S. Territory for several weeks. To obtain a second cable for the islands, the CNMI government signed an agreement to subsidize a second fiber optic cable. Apparently there is now a dispute about the subsidy. https://www.radionz.co.nz/international/pacific-news/356123/company-threatens-to-cut-northern-marianas-cable A telecommunications company in the Northern Marianas is threatening to cut the fibre optic cable that connects Tinian and Rota to Saipan if the government fails to provide $US1.3 million it promised to pay for the service. Under a memorandum of agreement signed with the CNMI government in 2016, Docomo Pacific agreed to include Tinian and Rota in connecting their fibre optic cable 'ATISA' at a fee of $US650,000 per island. Earlier this week, the House of Representative included the $US1.3 million commitment to the telco in the $US15 million appropriations bill that also gave $US7 million to the CNMI Judiciary to fix its mould and air-conditioning problems. The legislation still needs to be passed by the senate and supported by the governor. From Alex.Lembesis at tevapharm.com Wed May 2 13:33:45 2018 From: Alex.Lembesis at tevapharm.com (Alex Lembesis) Date: Wed, 2 May 2018 13:33:45 +0000 Subject: Internap Contact (Market St. Philadelphia) Message-ID: <78933a269a8444c98552348dd4b3a94f@USEXCAPP13.Teva.Corp> Does anyone have a contact @ Internap that could help me off list? Our peering with them is down. Any help is appreciated, thanks! This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. From deepak7ravi at gmail.com Tue May 1 18:58:26 2018 From: deepak7ravi at gmail.com (Deepak Ravi) Date: Tue, 1 May 2018 13:58:26 -0500 Subject: "Weird" Traffic about 10 hours ago In-Reply-To: <1657390686.5861.1525181294397.JavaMail.mhammett@ThunderFuck> References: <1099732532.5828.1525180611753.JavaMail.mhammett@ThunderFuck> <1657390686.5861.1525181294397.JavaMail.mhammett@ThunderFuck> Message-ID: Based on the data we’ve, it looks like there was a noticeable spike in packet loss within the AWS's Ashburn and Ohio datacenter around 17:50-18:10 Central Time. It is possible that this had something to do with the drops and dips in traffic you listed. If you’d like some additional data, feel free to email me off list. Disclaimer : I work for ThousandEyes. -Deepak On Tue, May 1, 2018 at 8:28 AM, Mike Hammett wrote: > This is going to be extremely scientific. > > Did anyone else see "weird" stuff going on about 10 hours ago, about 6 PM > Central on April 30th? I'm based in the Chicago area and have a large > client on the east coast. I saw about a 25% drop in traffic for a half hour > to an hour. > Another Midwestern ISP also saw about 25% drops on two different upstream > connections. > A friend of mine runs an ISP in Virginia. He reported a dip in traffic > (though didn't report how much of a drop), but also pings and IPSEC\L2TP > worked, but couldn't SSH or do other activities. > That friend reported another ISP in Virginia had problems at that same > time. > An ISP in Cyprus reported issues at that time. I'm looking to firm up what > kind of issues and verify the time. > > > Yet other ISPs report no problems at all. Smooth ramps on traffic graphs > as one would expect at the beginning of prime time. > > > I thought maybe "something" happened in Ashburn (fiber cut, DWDM card > failure, etc.) as my client has a wave from the east coast to me in > Chicago, but then the Midwestern ISP shouldn't have any dependency on > Ashburn, given Chicago and Dallas. > Then there's the guy in Cyprus, which shouldn't have any bearing on > anything that happens over here in the States. > > I thought maybe it was an epic failure at one of the CDNs or other content > networks, but then that wouldn't impact SSH or other management activities. > > > Anyone else have any other data to help figure out what caused this? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > -- *~Deepak* From alberto at caida.org Wed May 2 23:21:31 2018 From: alberto at caida.org (Alberto Dainotti) Date: Wed, 2 May 2018 16:21:31 -0700 Subject: survey on BGP prefix hijacking In-Reply-To: References: Message-ID: Dear NANOG, The results of our survey are finally out https://ccronline.sigcomm.org/2018/ccr-january-2018/a-survey-among-network-operators-on-bgp-prefix-hijacking/ https://ccronline.sigcomm.org/wp-content/uploads/2018/05/sigcomm-ccr-final187.pdf Thanks to all who participated and/or provided feedback, and apologies for the slow (for reasons beyond my control) publishing process. Best, Alberto From karim.adel at gmail.com Thu May 3 07:29:39 2018 From: karim.adel at gmail.com (Kasper Adel) Date: Thu, 3 May 2018 00:29:39 -0700 Subject: Open Souce Network Operating Systems In-Reply-To: References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: Feedback about Cumulus has been positive : https://www.mail-archive.com/cisco-nsp at puck.nether.net/msg66192.html if i am not mistaken, they have added lots of networking enhancements to the OS, they have videos on youtube that will paint the picture. On Sat, Jan 20, 2018 at 11:26 AM, Colton Conor wrote: > Peter, > > Thanks for the information. Do you have a recommendation of which > distribution of Linux to use for this? Is there one that is more network > centric than another? > > On Sat, Jan 20, 2018 at 1:11 PM, Peter Phaal > wrote: > > > On Sat, Jan 20, 2018 at 9:32 AM, Colton Conor > > wrote: > >> > >> My understanding if Free Range Routing is a package of software that > runs > >> in linux, but not a full and true NOS right? > >> > > > > Why not consider Linux a NOS? Installing Free Range Routing adds control > > plane protocols: BGP, OSPF, ISIS, etc. > > > > > >> I looked into Cumulus Linux, but it seems to only run on the supported > >> hardware which is while box switches. Can you run Cumulus Linux on a X86 > >> server with intel NICs? Can you run Cumulus on a raspberry pi? > >> > > > > Cumulus Linux is basically Ubuntu with Free Range Routing pre-installed > > along with a daemon that offloads forwarding from the Linux kernel to an > > ASIC. CumulusVX is a free Cumulus Linux virtual machine that is useful > for > > staging / testing configurations since it has the same behavior as the > > hardware switch. > > > > On X86 servers with Intel NICs, just run Linux. Cumulus Host Pack can be > > installed to add Free Range Routing and other Cumulus tools on the > server. > > Alternatively, you can choose any Linux control plane, automation, or > > monitoring tools and install them on the hosts and Cumulus Linux switches > > to unify management and control, e.g. Bird, collectd, telegraf, Puppet, > > Chef, Ansible, etc. > > > > Linux distros (including Ubuntu) are available for non-X86 hardware like > > Raspberry Pi etc. > > > > > >> > >> Ideally I think I am looking to a Linux operating system that can run on > >> multiple CPU architectures, has device support for Broadcom and other > >> Merchant silicon switching and wifi adapters. > > > > > > If you consider Linux as the NOS then it already meets these > requirements. > > > From frederic.jutzet at sig-telecom.net Thu May 3 04:51:50 2018 From: frederic.jutzet at sig-telecom.net (frederic.jutzet at sig-telecom.net) Date: Thu, 03 May 2018 06:51:50 +0200 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces Message-ID: <5AEA9566.7000808@sig-telecom.net> Hi, We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 which have TCP port 6154 listening on all interfaces. Any idea what it could be ? #show tcp brief all TCB Local Address Foreign Address (state) ... 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< #show tcp tcb 5A529430 Connection state is LISTEN, I/O status: 1, unread input bytes: 0 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 Local host: 0.0.0.0, Local port: 6154 Foreign host: UNKNOWN, Foreign port: 0 Connection tableid (VRF): 1 Maximum output segment queue size: 50 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is 0xF58354): Timer Starts Wakeups Next Retrans 0 0 0x0 TimeWait 0 0 0x0 AckHold 0 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 Linger 0 0 0x0 ProcessQ 0 0 0x0 iss: 0 snduna: 0 sndnxt: 0 irs: 0 rcvnxt: 0 sndwnd: 0 scale: 0 maxrcvwnd: 4128 rcvwnd: 4128 scale: 0 delrcvwnd: 0 SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms Status Flags: gen tcbs Option Flags: VRF id set, keepalive running, nagle, Reuse local address Retrans timeout IP Precedence value : 0 Datagrams (max data segment is 516 bytes): Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 0, total data bytes: 0 Packets received in fast path: 0, fast processed: 0, slow path: 0 fast lock acquisition failures: 0, slow path: 0 TCP Semaphore 0x5BEB9B10 FREE (The command "show control-plane host open-ports" is not available on this platform/code) I also think that if it would be a local socket for internal process communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. So this is listening on all interfaces, virtuals and physicals and seam not to be for internal internal process communication. Fred From khomyakov.andrey at gmail.com Thu May 3 20:39:19 2018 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 3 May 2018 13:39:19 -0700 Subject: Open Souce Network Operating Systems In-Reply-To: References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: Colton, Maybe it is obvious to some, but I just want to point out that the reason Cumulus Linux publishes list of supported hardware is kind of two fold: 1st is Linux inherently doesn't program the hardware. So if you install Ubuntu on some Quanta switch, you still need a way to program the ASIC. Cumulus Linux is open source with the exception of switchd, which is what they use to take network state from the kernel and program the silicone with it. switchd can only program "supported" silicon. 2nd (and I think that applies to any OS, not just a NOS) is that supported hardware is the one they know how to (or taught linux to) control the LEDs, the power supplies, the fans, etc. Technically you can run Cumulus Linux on some unsupported switches, but I would not put that in production. So if you accept that linux is an OS and it needs drivers to drive the hardware, you can, hopefully, see that you can't just take any linux distro and run it on just any switch. You will need drivers that this linux OS can use to drive the hardware (including the ASIC) that you chose to run this linux on. Cumulus Networks does just that. They provide you with the drivers for the ASIC and environmentals. And since they do it, they list the hardware they support (aka provided the drivers for). Hope this helps. -Andrey. --Andrey On Thu, May 3, 2018 at 12:29 AM, Kasper Adel wrote: > Feedback about Cumulus has been positive : > > https://www.mail-archive.com/cisco-nsp at puck.nether.net/msg66192.html > > if i am not mistaken, they have added lots of networking enhancements to > the OS, they have videos on youtube that will paint the picture. > > > > On Sat, Jan 20, 2018 at 11:26 AM, Colton Conor > wrote: > > > Peter, > > > > Thanks for the information. Do you have a recommendation of which > > distribution of Linux to use for this? Is there one that is more network > > centric than another? > > > > On Sat, Jan 20, 2018 at 1:11 PM, Peter Phaal > > wrote: > > > > > On Sat, Jan 20, 2018 at 9:32 AM, Colton Conor > > > wrote: > > >> > > >> My understanding if Free Range Routing is a package of software that > > runs > > >> in linux, but not a full and true NOS right? > > >> > > > > > > Why not consider Linux a NOS? Installing Free Range Routing adds > control > > > plane protocols: BGP, OSPF, ISIS, etc. > > > > > > > > >> I looked into Cumulus Linux, but it seems to only run on the supported > > >> hardware which is while box switches. Can you run Cumulus Linux on a > X86 > > >> server with intel NICs? Can you run Cumulus on a raspberry pi? > > >> > > > > > > Cumulus Linux is basically Ubuntu with Free Range Routing pre-installed > > > along with a daemon that offloads forwarding from the Linux kernel to > an > > > ASIC. CumulusVX is a free Cumulus Linux virtual machine that is useful > > for > > > staging / testing configurations since it has the same behavior as the > > > hardware switch. > > > > > > On X86 servers with Intel NICs, just run Linux. Cumulus Host Pack can > be > > > installed to add Free Range Routing and other Cumulus tools on the > > server. > > > Alternatively, you can choose any Linux control plane, automation, or > > > monitoring tools and install them on the hosts and Cumulus Linux > switches > > > to unify management and control, e.g. Bird, collectd, telegraf, Puppet, > > > Chef, Ansible, etc. > > > > > > Linux distros (including Ubuntu) are available for non-X86 hardware > like > > > Raspberry Pi etc. > > > > > > > > >> > > >> Ideally I think I am looking to a Linux operating system that can run > on > > >> multiple CPU architectures, has device support for Broadcom and other > > >> Merchant silicon switching and wifi adapters. > > > > > > > > > If you consider Linux as the NOS then it already meets these > > requirements. > > > > > > From ESundberg at nitelusa.com Fri May 4 06:01:39 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 4 May 2018 06:01:39 +0000 Subject: Route Reflector Client Design Question Message-ID: I have a RR Client design question...... CORE1-------------------2x10G-----------------------CORE2 | | | | | 10G Ring | | | | | PE1----------PE2----------PE3----------PE4----------PE5 -Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K) -MPLS LDP Enabled -IGP is ISIS -Each PE peers only with Core1 and Core2 as RR Clients with iBGP -PE's are only receiving a default route from the Core Routers due to TCAM size of 20K (ASR920's\ME3800's) -The ring does not have that much traffic on it <500m, so I do not want to use additional 10G ports on the Core's and is why I have it in a 10G U ring. -Primary link to the cores is via the PE1 --- CORE1 Like......... For this discussion the link between PE5 to CORE2 is set up as a backup link. The scenario is I have traffic between PE2 and PE3. Since the PE's are only receiving a default route from the Cores. Traffic is label switch from PE2 - PE1 - Core1 does a IP lookup at Ingress then label switches back to PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link to the Cores. My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. 3. Is this one of the down sides to U Rings? 4. Leave it alone and move on to bigger and better things.... Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From bernat at luffy.cx Fri May 4 07:49:12 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 04 May 2018 09:49:12 +0200 Subject: Open Souce Network Operating Systems In-Reply-To: (Andrey Khomyakov's message of "Thu, 3 May 2018 13:39:19 -0700") References: <1413312135.78963.1516332356885.JavaMail.zimbra@mawcom.com> Message-ID: <877eojyi6f.fsf@luffy.cx> ❦ 3 mai 2018 13:39 -0700, Andrey Khomyakov  : > 1st is Linux inherently doesn't program the hardware. So if you install > Ubuntu on some Quanta switch, you still need a way to program the ASIC. > Cumulus Linux is open source with the exception of switchd, which is what > they use to take network state from the kernel and program the silicone > with it. switchd can only program "supported" silicon. Since a few years, Linux has an offload framework for L2/L3 (switchdev). There is a toy driver (Rocker, supported by QEMU) and several silicons supported (at least Mellanox Spectrum, but it seems there are a few others). -- The mind is its own place, and in itself Can make a Heav'n of Hell, a Hell of Heav'n. -- John Milton From s.kakaroukas at connecticore.com Fri May 4 10:44:12 2018 From: s.kakaroukas at connecticore.com (Spyros Kakaroukas) Date: Fri, 4 May 2018 10:44:12 +0000 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: <42962C5D-2B24-42C5-9ABB-43A856E74AFB@connecticore.com> Hey Erik, 1) This messes up the design and introduces unnecessary complexity. As your issue is not directly caused by having a RR topology, I’d avoid doing that. 2) That, IMHO, would be the optimal solution, assuming you don’t have enough internal routes to overflow the TCAM of your PEs in the near future. This would also solve some potential loops if you ever want to pass unlabelled traffic. 3) That’s a very generic question with broad potential answers. 4) You could, but you’d have to evaluate that trade-off yourself ;) Kind regards, My thoughts and words are my own. Spyros On 04/05/2018, 09:02, "NANOG on behalf of Erik Sundberg" wrote: I have a RR Client design question...... CORE1-------------------2x10G-----------------------CORE2 | | | | | 10G Ring | | | | | PE1----------PE2----------PE3----------PE4----------PE5 -Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K) -MPLS LDP Enabled -IGP is ISIS -Each PE peers only with Core1 and Core2 as RR Clients with iBGP -PE's are only receiving a default route from the Core Routers due to TCAM size of 20K (ASR920's\ME3800's) -The ring does not have that much traffic on it <500m, so I do not want to use additional 10G ports on the Core's and is why I have it in a 10G U ring. -Primary link to the cores is via the PE1 --- CORE1 Like......... For this discussion the link between PE5 to CORE2 is set up as a backup link. The scenario is I have traffic between PE2 and PE3. Since the PE's are only receiving a default route from the Cores. Traffic is label switch from PE2 - PE1 - Core1 does a IP lookup at Ingress then label switches back to PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link to the Cores. My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. 3. Is this one of the down sides to U Rings? 4. Leave it alone and move on to bigger and better things.... Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From cb.list6 at gmail.com Fri May 4 12:41:22 2018 From: cb.list6 at gmail.com (Ca By) Date: Fri, 04 May 2018 12:41:22 +0000 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: On Thu, May 3, 2018 at 11:03 PM Erik Sundberg wrote: > I have a RR Client design question...... > > > CORE1-------------------2x10G-----------------------CORE2 > | > | > | > | > | 10G Ring > | > | > | > | > | > PE1----------PE2----------PE3----------PE4----------PE5 > > > -Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K) > -MPLS LDP Enabled > -IGP is ISIS > -Each PE peers only with Core1 and Core2 as RR Clients with iBGP > -PE's are only receiving a default route from the Core Routers due to TCAM > size of 20K (ASR920's\ME3800's) > -The ring does not have that much traffic on it <500m, so I do not want to > use additional 10G ports on the Core's and is why I have it in a 10G U ring. > -Primary link to the cores is via the PE1 --- CORE1 Like......... For this > discussion the link between PE5 to CORE2 is set up as a backup link. > > The scenario is I have traffic between PE2 and PE3. Since the PE's are > only receiving a default route from the Cores. Traffic is label switch from > PE2 - PE1 - Core1 does a IP lookup at Ingress then label switches back to > PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link > to the Cores. > > My questions is how do I get traffic to go directly between the PE's > without going to the Core Routers? > > 1. Can I enable iBGP between the PE's in a full mesh to allow traffic > between the PE's without going to the core's. Or does this break the Route > Reflector model? #1 is fine and works > 2. Create a route policy on the Core's advertising routes learned from the > PE's back to all the PE's on the ring. > 3. Is this one of the down sides to U Rings? > 4. Leave it alone and move on to bigger and better things.... > > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From michalis.bersimis at hq.cyta.gr Fri May 4 12:58:14 2018 From: michalis.bersimis at hq.cyta.gr (michalis.bersimis at hq.cyta.gr) Date: Fri, 4 May 2018 12:58:14 +0000 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: <1872ea7a3f7d4c9296e051168cf2e08c@PLAMAIL01.corp.cyta> Hello, In order to accept only the default route, I assume that you want to have internet access to the ASR920 inside a vrf. ?!? If this is the case, your consideration of the default route and the TCAM size is correct. But, if there is internet traffic between the PE2-PE3 in the same vrf , then I think that its ok to leak more specific prefixes from PE2 to PE3 (by using specific Route Targets) from the CORE1 & CORE2 (RR). Unless there is something that I miss, option #2, is more favorable. Michalis Bersimis -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Erik Sundberg Sent: Friday, May 04, 2018 9:02 AM To: NANOG Subject: Route Reflector Client Design Question I have a RR Client design question...... CORE1-------------------2x10G-----------------------CORE2 | | | | | 10G Ring | | | | | | PE1----------PE2----------PE3----------PE4----------PE5 -Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K) -MPLS LDP Enabled -IGP is ISIS -Each PE peers only with Core1 and Core2 as RR Clients with iBGP -PE's are only receiving a default route from the Core Routers due to TCAM size of 20K (ASR920's\ME3800's) -The ring does not have that much traffic on it <500m, so I do not want to use additional 10G ports on the Core's and is why I have it in a 10G U ring. -Primary link to the cores is via the PE1 --- CORE1 Like......... For this discussion the link between PE5 to CORE2 is set up as a backup link. The scenario is I have traffic between PE2 and PE3. Since the PE's are only receiving a default route from the Cores. Traffic is label switch from PE2 - PE1 - Core1 does a IP lookup at Ingress then label switches back to PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link to the Cores. My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. 3. Is this one of the down sides to U Rings? 4. Leave it alone and move on to bigger and better things.... Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From jwbensley at gmail.com Fri May 4 13:37:10 2018 From: jwbensley at gmail.com (James Bensley) Date: Fri, 4 May 2018 14:37:10 +0100 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: On 4 May 2018 at 07:01, Erik Sundberg wrote: > 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? If I have understood your design correctly then don't use next-hop-self on the RR's. Ideally you'd have out of band RRs so you don't need NHS but I can see that you're are both RRs and PEs so NHS is required. If you enabled iBGP sessions between all your PEs you have defeated the point of RRs :) I don't know your setup in detail but is there something you can do on your RRs to allow you to remove NHS? eBGP routes will have NHS by default so you just need to check the impact on iBGP routes, maybe you can remove NHS at the expense of redistributing a couple of connected routes. Cheers, James. From ahad at swiftelnetworks.com Fri May 4 14:15:34 2018 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Sat, 5 May 2018 00:15:34 +1000 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: Erik, Before I email my suggestions, can you clarify the followings; Do Core1 and Core2 also provide the function of BDRs peering with your upstream/s? Or Just acting as Core/RRs with 500Mbps of traffic traversing through them? Cheers Ahad On Fri, May 4, 2018 at 4:01 PM, Erik Sundberg wrote: > I have a RR Client design question...... > > > CORE1-------------------2x10G-----------------------CORE2 > | > | > | > | > | 10G Ring > | > | > | > | > | > PE1----------PE2----------PE3----------PE4----------PE5 > > > -Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K) > -MPLS LDP Enabled > -IGP is ISIS > -Each PE peers only with Core1 and Core2 as RR Clients with iBGP > -PE's are only receiving a default route from the Core Routers due to TCAM > size of 20K (ASR920's\ME3800's) > -The ring does not have that much traffic on it <500m, so I do not want to > use additional 10G ports on the Core's and is why I have it in a 10G U ring. > -Primary link to the cores is via the PE1 --- CORE1 Like......... For this > discussion the link between PE5 to CORE2 is set up as a backup link. > > The scenario is I have traffic between PE2 and PE3. Since the PE's are > only receiving a default route from the Cores. Traffic is label switch from > PE2 - PE1 - Core1 does a IP lookup at Ingress then label switches back to > PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link > to the Cores. > > My questions is how do I get traffic to go directly between the PE's > without going to the Core Routers? > > 1. Can I enable iBGP between the PE's in a full mesh to allow traffic > between the PE's without going to the core's. Or does this break the Route > Reflector model? > 2. Create a route policy on the Core's advertising routes learned from the > PE's back to all the PE's on the ring. > 3. Is this one of the down sides to U Rings? > 4. Leave it alone and move on to bigger and better things.... > > > Thanks > > Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From cscora at apnic.net Fri May 4 18:03:19 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 May 2018 04:03:19 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180504180319.2D9A1C450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 05 May, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 698222 Prefixes after maximum aggregation (per Origin AS): 268829 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 336897 Total ASes present in the Internet Routing Table: 60652 Prefixes per ASN: 11.51 Origin-only ASes present in the Internet Routing Table: 52419 Origin ASes announcing only one prefix: 22938 Transit ASes present in the Internet Routing Table: 8233 Transit-only ASes present in the Internet Routing Table: 267 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 51 Number of instances of unregistered ASNs: 51 Number of 32-bit ASNs allocated by the RIRs: 22423 Number of 32-bit ASNs visible in the Routing Table: 18107 Prefixes from 32-bit ASNs in the Routing Table: 75449 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 297 Number of addresses announced to Internet: 2858741122 Equivalent to 170 /8s, 100 /16s and 237 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 232759 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 191019 Total APNIC prefixes after maximum aggregation: 54116 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 189798 Unique aggregates announced from the APNIC address blocks: 77981 APNIC Region origin ASes present in the Internet Routing Table: 8773 APNIC Prefixes per ASN: 21.63 APNIC Region origin ASes announcing only one prefix: 2452 APNIC Region transit ASes present in the Internet Routing Table: 1307 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3737 Number of APNIC addresses announced to Internet: 766870786 Equivalent to 45 /8s, 181 /16s and 133 /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: 207973 Total ARIN prefixes after maximum aggregation: 99038 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209004 Unique aggregates announced from the ARIN address blocks: 98978 ARIN Region origin ASes present in the Internet Routing Table: 18167 ARIN Prefixes per ASN: 11.50 ARIN Region origin ASes announcing only one prefix: 6717 ARIN Region transit ASes present in the Internet Routing Table: 1794 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2346 Number of ARIN addresses announced to Internet: 1104906784 Equivalent to 65 /8s, 219 /16s and 138 /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: 190494 Total RIPE prefixes after maximum aggregation: 91847 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 186369 Unique aggregates announced from the RIPE address blocks: 111090 RIPE Region origin ASes present in the Internet Routing Table: 25164 RIPE Prefixes per ASN: 7.41 RIPE Region origin ASes announcing only one prefix: 11421 RIPE Region transit ASes present in the Internet Routing Table: 3507 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6956 Number of RIPE addresses announced to Internet: 715766144 Equivalent to 42 /8s, 169 /16s and 185 /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: 90085 Total LACNIC prefixes after maximum aggregation: 19812 LACNIC Deaggregation factor: 4.55 Prefixes being announced from the LACNIC address blocks: 91488 Unique aggregates announced from the LACNIC address blocks: 40942 LACNIC Region origin ASes present in the Internet Routing Table: 7111 LACNIC Prefixes per ASN: 12.87 LACNIC Region origin ASes announcing only one prefix: 1966 LACNIC Region transit ASes present in the Internet Routing Table: 1306 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4651 Number of LACNIC addresses announced to Internet: 172820960 Equivalent to 10 /8s, 77 /16s and 9 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18598 Total AfriNIC prefixes after maximum aggregation: 3969 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 21266 Unique aggregates announced from the AfriNIC address blocks: 7658 AfriNIC Region origin ASes present in the Internet Routing Table: 1142 AfriNIC Prefixes per ASN: 18.62 AfriNIC Region origin ASes announcing only one prefix: 381 AfriNIC Region transit ASes present in the Internet Routing Table: 230 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 417 Number of AfriNIC addresses announced to Internet: 97989120 Equivalent to 5 /8s, 215 /16s and 50 /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 5392 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4393 415 430 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2892 11137 791 KIXS-AS-KR Korea Telecom, KR 7552 2807 1156 71 VIETEL-AS-AP Viettel Group, VN 9829 2761 1498 543 BSNL-NIB National Internet Backbone, IN 9394 2614 4922 26 CTTNET China TieTong Telecommunications 45899 2528 1574 160 VNPT-AS-VN VNPT Corp, VN 17974 2293 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2190 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2100 417 206 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3389 1323 84 SHAW - Shaw Communications Inc., CA 22773 3289 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2168 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2099 2503 455 CHARTER-NET-HKY-NC - Charter Communicat 16509 2086 4590 650 AMAZON-02 - Amazon.com, Inc., US 11492 2005 240 450 CABLEONE - CABLE ONE, INC., US 209 1969 5070 607 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1968 339 177 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1760 862 1261 AKAMAI-AS - Akamai Technologies, Inc., 7018 1704 20213 1257 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4116 1519 499 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2662 719 1958 AKAMAI-ASN1, US 8551 2079 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2040 1876 707 ROSTELECOM-AS, RU 34984 2018 334 484 TELLCOM-AS, TR 9121 1979 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1237 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 4445 3387 586 Uninet S.A. de C.V., MX 10620 3591 542 244 Telmex Colombia S.A., CO 11830 2647 369 78 Instituto Costarricense de Electricidad 6503 1612 437 53 Axtel, S.A.B. de C.V., MX 7303 1517 1025 193 Telecom Argentina S.A., AR 28573 1036 2251 184 CLARO S.A., BR 3816 1009 505 123 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 998 377 31 Telefonica del Peru S.A.A., PE 11172 927 126 85 Alestra, S. de R.L. de C.V., MX 18881 909 1074 29 TELEF�NICA BRASIL S.A, BR 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 1185 396 45 LINKdotNET-AS, EG 37611 835 107 9 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 697 1412 42 ETISALAT-MISR, EG 8452 683 1730 18 TE-AS TE-AS, EG 24835 608 850 15 RAYA-AS, EG 37492 452 376 81 ORANGE-, TN 29571 422 68 10 ORANGE-COTE-IVOIRE, CI 15399 362 35 7 WANANCHI-, KE 37342 361 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5392 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4445 3387 586 Uninet S.A. de C.V., MX 7545 4393 415 430 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4116 1519 499 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3591 542 244 Telmex Colombia S.A., CO 6327 3389 1323 84 SHAW - Shaw Communications Inc., CA 22773 3289 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2892 11137 791 KIXS-AS-KR Korea Telecom, KR 7552 2807 1156 71 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4393 3963 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 4445 3859 Uninet S.A. de C.V., MX 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4116 3617 UNI2-AS, ES 10620 3591 3347 Telmex Colombia S.A., CO 6327 3389 3305 SHAW - Shaw Communications Inc., CA 22773 3289 3142 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2807 2736 VIETEL-AS-AP Viettel Group, VN 9394 2614 2588 CTTNET China TieTong Telecommunications Corpora 11830 2647 2569 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.232.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.233.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU 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.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:37 /11:100 /12:288 /13:564 /14:1093 /15:1904 /16:13393 /17:7876 /18:13601 /19:25214 /20:39396 /21:45121 /22:86865 /23:70104 /24:390366 /25:848 /26:649 /27:648 /28:36 /29:20 /30:17 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3178 3389 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 12479 2860 4116 UNI2-AS, ES 22773 2545 3289 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2168 MEGAPATH5-US - MegaPath Corporation, US 11830 1994 2647 Instituto Costarricense de Electricidad y Telec 11492 1745 2005 CABLEONE - CABLE ONE, INC., US 30036 1720 1968 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1601 3591 Telmex Colombia S.A., CO 8551 1541 2079 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1581 2:840 4:19 5:2840 6:65 7:1 8:1116 12:1878 13:185 14:1750 15:28 16:3 17:203 18:68 20:49 21:7 23:2650 24:2212 25:2 27:2362 31:1973 32:87 35:27 36:505 37:2769 38:1451 39:262 40:118 41:3142 42:571 43:1944 44:112 45:4422 46:3046 47:204 49:1313 50:1056 51:307 52:1020 54:370 55:3 56:12 57:42 58:1602 59:991 60:433 61:2162 62:1828 63:1795 64:5021 65:2209 66:4666 67:2367 68:1139 69:3191 70:1150 71:563 72:2105 74:2715 75:414 76:437 77:1551 78:1705 79:1851 80:1511 81:1412 82:1077 83:777 84:1055 85:2055 86:589 87:1306 88:939 89:2325 90:206 91:6357 92:1172 93:2368 94:2382 95:2823 96:658 97:357 98:942 99:133 100:80 101:1280 102:47 103:17676 104:3623 105:231 106:659 107:1862 108:713 109:2728 110:1605 111:1773 112:1275 113:1263 114:1115 115:1632 116:1641 117:1729 118:2194 119:1661 120:987 121:1052 122:2450 123:1807 124:1430 125:1895 128:1012 129:649 130:457 131:1588 132:670 133:195 134:1017 135:224 136:469 137:494 138:1924 139:604 140:393 141:695 142:819 143:961 144:794 145:461 146:1190 147:780 148:1593 149:703 150:726 151:1058 152:768 153:312 154:1066 155:765 156:934 157:779 158:657 159:1739 160:933 161:753 162:2586 163:554 164:1049 165:1580 166:439 167:1405 168:3108 169:800 170:3699 171:433 172:1127 173:1995 174:907 175:769 176:1885 177:4053 178:2439 179:1196 180:2251 181:2217 182:2393 183:1149 184:987 185:13459 186:3625 187:2377 188:2781 189:2017 190:8101 191:1473 192:9827 193:5910 194:4767 195:3953 196:2499 197:1454 198:5541 199:5880 200:7387 201:4989 202:10349 203:10172 204:4561 205:2904 206:3104 207:3206 208:3992 209:3948 210:4037 211:2113 212:3009 213:2735 214:952 215:60 216:5924 217:2132 218:909 219:628 220:1752 221:993 222:1032 223:1249 End of report From jheitz at cisco.com Fri May 4 19:06:59 2018 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Fri, 4 May 2018 19:06:59 +0000 Subject: Route Reflector Client Design Question Message-ID: <3a192ede5e3443fbb11e0baebda1b455@XCH-ALN-014.cisco.com> You could optimize the packet hop count by making smaller but more rings. For example, make one ring with CORE1, CORE2, PE1, PE2, PE3. And another ring with CORE1, CORE2, PE4, PE5. If you configure "route-reflector-client" on the CORE, and mesh the clients, then you can additionally configure "bgp client-to-client reflection disable". However, if the CORE is just sending a default route, then you probably have default-originate and no RR clients on the CORE. Then you don't need to disable reflection, because it's not reflecting anyway. (reflection refers to the reflection of routes, not reflection of packets). You could send limited important or heavily used prefixes between the PEs using route policy without blowing up the TCAM. Regards, Jakob. -----Original Message----- From: Erik Sundberg I have a RR Client design question...... CORE1-------------------2x10G-----------------------CORE2 | | | | | 10G Ring | | | | | PE1----------PE2----------PE3----------PE4----------PE5 -Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K) -MPLS LDP Enabled -IGP is ISIS -Each PE peers only with Core1 and Core2 as RR Clients with iBGP -PE's are only receiving a default route from the Core Routers due to TCAM size of 20K (ASR920's\ME3800's) -The ring does not have that much traffic on it <500m, so I do not want to use additional 10G ports on the Core's and is why I have it in a 10G U ring. -Primary link to the cores is via the PE1 --- CORE1 Like......... For this discussion the link between PE5 to CORE2 is set up as a backup link. The scenario is I have traffic between PE2 and PE3. Since the PE's are only receiving a default route from the Cores. Traffic is label switch from PE2 - PE1 - Core1 does a IP lookup at Ingress then label switches back to PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link to the Cores. My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. 3. Is this one of the down sides to U Rings? 4. Leave it alone and move on to bigger and better things.... From ESundberg at nitelusa.com Fri May 4 21:02:16 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 4 May 2018 21:02:16 +0000 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: Ahad, The Cores have Connections to other POPs Transiting IX circuits connected on them Also have some Customer on them so they do also act like a PE. Thanks Erik Erik Sundberg Sr. Network Engineering Network Engineering Department p: 773.661.5532 c: 708.710.7419 e: esundberg at nitelusa.com Main: 888.450.2100 NOC 24/7: 866.892.0915 350 North Orleans Street, Suite 1300N Chicago, IL 60654 www.nitelusa.com [Nitel] Managed Telecom Services MPLS | Ethernet | Private Line | Internet | Voice | Security From: Ahad Aboss [mailto:ahad at swiftelnetworks.com] Sent: Friday, May 4, 2018 9:16 AM To: Erik Sundberg Cc: NANOG Subject: Re: Route Reflector Client Design Question Erik, Before I email my suggestions, can you clarify the followings; Do Core1 and Core2 also provide the function of BDRs peering with your upstream/s? Or Just acting as Core/RRs with 500Mbps of traffic traversing through them? Cheers Ahad On Fri, May 4, 2018 at 4:01 PM, Erik Sundberg > wrote: I have a RR Client design question...... CORE1-------------------2x10G-----------------------CORE2 | | | | | 10G Ring | | | | | PE1----------PE2----------PE3----------PE4----------PE5 -Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K) -MPLS LDP Enabled -IGP is ISIS -Each PE peers only with Core1 and Core2 as RR Clients with iBGP -PE's are only receiving a default route from the Core Routers due to TCAM size of 20K (ASR920's\ME3800's) -The ring does not have that much traffic on it <500m, so I do not want to use additional 10G ports on the Core's and is why I have it in a 10G U ring. -Primary link to the cores is via the PE1 --- CORE1 Like......... For this discussion the link between PE5 to CORE2 is set up as a backup link. The scenario is I have traffic between PE2 and PE3. Since the PE's are only receiving a default route from the Cores. Traffic is label switch from PE2 - PE1 - Core1 does a IP lookup at Ingress then label switches back to PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link to the Cores. My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. 3. Is this one of the down sides to U Rings? 4. Leave it alone and move on to bigger and better things.... Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From marcel.duregards at yahoo.fr Sat May 5 11:22:56 2018 From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr) Date: Sat, 05 May 2018 13:22:56 +0200 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <5AEA9566.7000808@sig-telecom.net> References: <5AEA9566.7000808@sig-telecom.net> Message-ID: <5AED9410.30903@yahoo.fr> As the zero touch feature is on TCP 4786 (SMI), I vote for either: - a nsa backdoor :-) - a default active service Have you tried to zeroize the config and restart then check if TCP 6154 is still on LISTEN state ? - Marcel On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote: > Hi, > > We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 > which have TCP port 6154 listening on all interfaces. > > Any idea what it could be ? > > #show tcp brief all > TCB Local Address Foreign Address (state) > ... > 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< > > > #show tcp tcb 5A529430 > Connection state is LISTEN, I/O status: 1, unread input bytes: 0 > Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 > Local host: 0.0.0.0, Local port: 6154 > Foreign host: UNKNOWN, Foreign port: 0 > Connection tableid (VRF): 1 > Maximum output segment queue size: 50 > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) > > Event Timers (current time is 0xF58354): > Timer Starts Wakeups Next > Retrans 0 0 0x0 > TimeWait 0 0 0x0 > AckHold 0 0 0x0 > SendWnd 0 0 0x0 > KeepAlive 0 0 0x0 > GiveUp 0 0 0x0 > PmtuAger 0 0 0x0 > DeadWait 0 0 0x0 > Linger 0 0 0x0 > ProcessQ 0 0 0x0 > > iss: 0 snduna: 0 sndnxt: 0 > irs: 0 rcvnxt: 0 > > sndwnd: 0 scale: 0 maxrcvwnd: 4128 > rcvwnd: 4128 scale: 0 delrcvwnd: 0 > > SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms > minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms > uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms > Status Flags: gen tcbs > Option Flags: VRF id set, keepalive running, nagle, Reuse local address > Retrans timeout > IP Precedence value : 0 > > Datagrams (max data segment is 516 bytes): > Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 > Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second > Congestion: 0), with data: 0, total data bytes: 0 > > Packets received in fast path: 0, fast processed: 0, slow path: 0 > fast lock acquisition failures: 0, slow path: 0 > TCP Semaphore 0x5BEB9B10 FREE > > > > > > (The command "show control-plane host open-ports" is not available on > this platform/code) > > > > I also think that if it would be a local socket for internal process > communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. > So this is listening on all interfaces, virtuals and physicals and seam > not to be for internal internal process communication. > > > Fred > From mark.tinka at seacom.mu Sat May 5 23:38:01 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 6 May 2018 01:38:01 +0200 Subject: How are you configuring BFD timers? In-Reply-To: <99345192-C286-4004-A859-49D0E9633759@lixfeld.ca> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <4ab3d464-a423-d856-eddc-8c984fe0a5fa@shout.net> <99345192-C286-4004-A859-49D0E9633759@lixfeld.ca> Message-ID: <6f87c568-f561-8739-0541-6bf2f5ede8de@seacom.mu> On 21/Mar/18 19:10, Jason Lixfeld wrote: > A few years ago I did some testing and found that the time between the transceiver detecting LOS and the routing protocol (ISIS in this case) being informed that the link was down (triggering the recalculation) took longer than it took BFD to signal ISIS to recalculate. You also have the issues of: * Deciding whether you want to have a uniform standard when deploying BFD. If your standard is not to on dark links and should do lit links, you can quickly run into an administrative scenario as your network grows, and keeping track of which link is what re: BFD or not can be someone's untangling project 10 years later. * Circuit providers delivering hybrid links and not telling you because they are either afraid to or don't fully understand the scope of their (very large) network. In this case, you're told the link is dark, but somewhere along the path is their active gear. (not so) Strange, but true. Mark. From mark.tinka at seacom.mu Sat May 5 23:38:06 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 6 May 2018 01:38:06 +0200 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> Message-ID: <42c6d1bb-683c-99f4-4df2-d39dad6e98e1@seacom.mu> On 22/Mar/18 10:47, James Bensley wrote: > Have you looked at testing and adding this command to your IOS devices: > > ip routing protocol purge interface In all recent versions of IOS, this command is now standard and is elided from the running configuration. Mark. From mark.tinka at seacom.mu Sat May 5 23:38:09 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 6 May 2018 01:38:09 +0200 Subject: NSR / NSF In-Reply-To: References: Message-ID: <94223109-c44d-0b3e-bcb6-f736ecd96905@seacom.mu> On 17/Mar/18 12:29, Hari . wrote: > Checking on best practice being followed with regards to enabling NSF or NSR or both on ASR 9k. Which option can be beneficial and considered to be a standard approach. See https://mailman.nanog.org/pipermail/nanog/2014-November/071600.html from 2014. In 2018, the only routers we have that don't support NSR are not carrying essential production traffic, e.g., looking glass routers based on the Cisco 7201. GR would be useful here, but no mileage for us since all other devices have the hardware to do NSR. We do run our RR's on CSR1000v, which would put them into the GR category, but redundancy here is caused by discrete hardware duplication. Mark. From mark.tinka at seacom.mu Sat May 5 23:38:16 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 6 May 2018 01:38:16 +0200 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: On 4/May/18 08:01, Erik Sundberg wrote: > My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? > > 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? You could do, but then you lose the point of the RR in the first place, as it's likely your Metro-E nodes will continue to grow, making this iBGP mesh thing, well, messy. > 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. You could do, but adds unnecessary routing complexity since the role of an RR is to, well, reflect. > 3. Is this one of the down sides to U Rings? Not really a downside, just the perks of extending IP/MPLS all the way into the Access (I drink to the death of Layer 2 Metro-E networks - my liver will probably give out before I do, though...). > 4. Leave it alone and move on to bigger and better things.... Now where's the fun in that :-)? So we've solved this problem by using BGP-SD (Selective Download): * For every prefix each Metro-E node handles, originate that toward both RR's with NEXT_HOP=self. * Attach a BGP community along with the routes originated toward the RR's. For maximum saving of your precious FIB in your Metro-E nodes, use a BGP community that is unique to the ring. This way, you don't need to accept routes into each Metro-E's FIB that don't require the "local" forwarding. * Ensure the RR's reflect the routes they learn from each Metro-E node to the other Metro-E nodes. * Setup BGP-SD on each Metro-E node. Match the ring-specific BGP community you added to each Metro-E node's prefix origination. Accept those routes into FIB + default. Reject everything else (from populating the FIB). That should give you local forwarding within the ring, while maintaining very sparse population of your Metro-E nodes' FIB's. Mark. From ESundberg at nitelusa.com Sun May 6 05:33:43 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Sun, 6 May 2018 05:33:43 +0000 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: Mark, Your solutions sounds like the best one. We have just started to mess with Selective download and we have only turned it on for one of the PE’s in our network. I am in the process of upgrading our Core routers from Cisco12410 to ASR9906’s, before I turn this one. Having the PE decide what to import is a better solution than trying to do router filtering on the core routers. Thanks for the info Erik From: Mark Tinka [mailto:mark.tinka at seacom.mu] Sent: Saturday, May 5, 2018 6:38 PM To: Erik Sundberg ; NANOG Subject: Re: Route Reflector Client Design Question On 4/May/18 08:01, Erik Sundberg wrote: My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? You could do, but then you lose the point of the RR in the first place, as it's likely your Metro-E nodes will continue to grow, making this iBGP mesh thing, well, messy. 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. You could do, but adds unnecessary routing complexity since the role of an RR is to, well, reflect. 3. Is this one of the down sides to U Rings? Not really a downside, just the perks of extending IP/MPLS all the way into the Access (I drink to the death of Layer 2 Metro-E networks - my liver will probably give out before I do, though...). 4. Leave it alone and move on to bigger and better things.... Now where's the fun in that :-)? So we've solved this problem by using BGP-SD (Selective Download): * For every prefix each Metro-E node handles, originate that toward both RR's with NEXT_HOP=self. * Attach a BGP community along with the routes originated toward the RR's. For maximum saving of your precious FIB in your Metro-E nodes, use a BGP community that is unique to the ring. This way, you don't need to accept routes into each Metro-E's FIB that don't require the "local" forwarding. * Ensure the RR's reflect the routes they learn from each Metro-E node to the other Metro-E nodes. * Setup BGP-SD on each Metro-E node. Match the ring-specific BGP community you added to each Metro-E node's prefix origination. Accept those routes into FIB + default. Reject everything else (from populating the FIB). That should give you local forwarding within the ring, while maintaining very sparse population of your Metro-E nodes' FIB's. Mark. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From ESundberg at nitelusa.com Sun May 6 05:41:01 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Sun, 6 May 2018 05:41:01 +0000 Subject: How are you configuring BFD timers? In-Reply-To: <42c6d1bb-683c-99f4-4df2-d39dad6e98e1@seacom.mu> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> <42c6d1bb-683c-99f4-4df2-d39dad6e98e1@seacom.mu> Message-ID: Here is what we do... router isis xxxx interface TenGigabitEthernet0/0/0/0 circuit-type level-2-only bfd minimum-interval 50 bfd multiplier 5 bfd fast-detect ipv4 We keep the same config for local and long haul core links. Works like a champ every time. Also as a FYI if you are running ASR9K, you are able to offload the BFD process from the Linecard CPU to the NPU. This allows BFD timers down to 3.3 milliseconds. https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-1/routing/configuration/guide/b_routing_cg51xasr9k/b_routing_cg51xasr9k_chapter_011.html -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Tinka Sent: Saturday, May 5, 2018 6:38 PM To: James Bensley ; NANOG Subject: Re: How are you configuring BFD timers? On 22/Mar/18 10:47, James Bensley wrote: > Have you looked at testing and adding this command to your IOS devices: > > ip routing protocol purge interface In all recent versions of IOS, this command is now standard and is elided from the running configuration. Mark. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From nick at foobar.org Sun May 6 10:29:09 2018 From: nick at foobar.org (Nick Hilliard) Date: Sun, 6 May 2018 11:29:09 +0100 Subject: Route Reflector Client Design Question In-Reply-To: References: Message-ID: <806bba27-4e79-3ebc-1a21-b09b3a97635a@foobar.org> Mark Tinka wrote: > On 4/May/18 08:01, Erik Sundberg wrote: >> My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? >> >> 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? > > You could do, but then you lose the point of the RR in the first place, > as it's likely your Metro-E nodes will continue to grow, making this one option potentially worth looking at here would be optimal route reflection. "Potentially" because vendors haven't been shipping ORR for long and some implementations are still working themselves through the design kink stage. Nick From mark.tinka at seacom.mu Sun May 6 12:20:05 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 6 May 2018 14:20:05 +0200 Subject: Route Reflector Client Design Question In-Reply-To: <806bba27-4e79-3ebc-1a21-b09b3a97635a@foobar.org> References: <806bba27-4e79-3ebc-1a21-b09b3a97635a@foobar.org> Message-ID: <0e2cded9-85cc-a786-4774-330c65b308b1@seacom.mu> On 6/May/18 12:29, Nick Hilliard wrote: >   > one option potentially worth looking at here would be optimal route > reflection.  "Potentially" because vendors haven't been shipping ORR > for long and some implementations are still working themselves through > the design kink stage. So our good friends at Cisco, after promising that they'd have code for IOS XE/CSR1000v by this time 2018, told me that implementation for it on this code base has moved to 2H'19, no guarantees. I'm too bored with them to even be irritated. Someone was telling me that the IOS XR implementation only supports the main IPv4/IPv6 address families, so their 6PE network cannot enjoy their ORR deployment yet. Mark. From mark.tinka at seacom.mu Sun May 6 12:23:11 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 6 May 2018 14:23:11 +0200 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> <42c6d1bb-683c-99f4-4df2-d39dad6e98e1@seacom.mu> Message-ID: <1af8cf9f-5355-b38e-698a-335957b5a972@seacom.mu> On 6/May/18 07:41, Erik Sundberg wrote: > Here is what we do... > > router isis xxxx > interface TenGigabitEthernet0/0/0/0 > circuit-type level-2-only > bfd minimum-interval 50 > bfd multiplier 5 > bfd fast-detect ipv4 > > We keep the same config for local and long haul core links. Works like a champ every time. We use the same timers for all links, but different multipliers depending on the link length. We have links as short as 5km, all the way to 14,500km. Mark. From aaron1 at gvtc.com Mon May 7 00:31:57 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Sun, 6 May 2018 19:31:57 -0500 Subject: Route Reflector Client Design Question In-Reply-To: <0e2cded9-85cc-a786-4774-330c65b308b1@seacom.mu> References: <806bba27-4e79-3ebc-1a21-b09b3a97635a@foobar.org> <0e2cded9-85cc-a786-4774-330c65b308b1@seacom.mu> Message-ID: <7ED9B407-6B59-495E-A7D2-5098076A5CC3@gvtc.com> I'm not sure what you are taking about with ORR, but I use dual RR's for a redundant cluster with me ASR9k's in IOS XR, and I have them handling routes for ... Family l2vpn VPLS Family vpnv4 Family vpnv6 ...so my 6PE mpls l3vpn has been working fine Aaron > On May 6, 2018, at 7:20 AM, Mark Tinka wrote: > > > >> On 6/May/18 12:29, Nick Hilliard wrote: >> >> >> one option potentially worth looking at here would be optimal route >> reflection. "Potentially" because vendors haven't been shipping ORR >> for long and some implementations are still working themselves through >> the design kink stage. > > So our good friends at Cisco, after promising that they'd have code for > IOS XE/CSR1000v by this time 2018, told me that implementation for it on > this code base has moved to 2H'19, no guarantees. I'm too bored with > them to even be irritated. > > Someone was telling me that the IOS XR implementation only supports the > main IPv4/IPv6 address families, so their 6PE network cannot enjoy their > ORR deployment yet. > > Mark. From mark.tinka at seacom.mu Mon May 7 12:14:09 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 7 May 2018 14:14:09 +0200 Subject: Route Reflector Client Design Question In-Reply-To: <7ED9B407-6B59-495E-A7D2-5098076A5CC3@gvtc.com> References: <806bba27-4e79-3ebc-1a21-b09b3a97635a@foobar.org> <0e2cded9-85cc-a786-4774-330c65b308b1@seacom.mu> <7ED9B407-6B59-495E-A7D2-5098076A5CC3@gvtc.com> Message-ID: <5d21ba6f-6a9a-c58f-bc96-c26254bfeab1@seacom.mu> On 7/May/18 02:31, Aaron Gould wrote: > I'm not sure what you are taking about with ORR, https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-16 Mark. From frederic.jutzet at sig-telecom.net Mon May 7 07:06:31 2018 From: frederic.jutzet at sig-telecom.net (frederic.jutzet at sig-telecom.net) Date: Mon, 07 May 2018 09:06:31 +0200 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <5AED9410.30903@yahoo.fr> References: <5AEA9566.7000808@sig-telecom.net> <5AED9410.30903@yahoo.fr> Message-ID: <5AEFFAF7.40704@sig-telecom.net> > - a nsa backdoor :-) it would be a very bad backdoor as it's really easy to see the port listening... > - a default active service Maybe, but a service which is not officially registered: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6154 in contrary to the SMI (zero touch feature on tcp 4786) which is registered since almost 10y: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4786 Could it be possible that this kind of tcp port is not registered by Iana because it meant to be used for internal communication only (internal to the device), or should you register any port usage (even 'private') ? And yes I've tried to reset to default the config, shutdown all interface, remove all L3 ip/feature (no ip blabla), and I still see by default 2 TCP ports on listening state: Cat4500-SUP7L-E#sh ip prot *** IP Routing is NSF aware *** Cat4500-SUP7L-E# Cat4500-SUP7L-E#sh run | in ip address-family ipv4 address-family ipv6 no ip routing ip vrf Liin-vrf no ip mfib no ip bootp server no ip dhcp-client broadcast-flag no ip igmp snooping no ipv6 traffic interface-statistics no ip address no ip route-cache no ip address no ip route-cache no ip forward-protocol nd no ip http server no ip http secure-server Cat4500-SUP7L-E# Cat4500-SUP7L-E# Cat4500-SUP7L-E#show tcp br all TCB Local Address Foreign Address (state) 5B40BB30 0.0.0.0.4786 *.* LISTEN 5CD5D2D8 0.0.0.0.6154 *.* LISTEN Cat4500-SUP7L-E# I will now try to negate all potential active service from the 'show run all' config but it's not optimal as for example 'vstack' (port 4786) does not appear in the default config so it would not be disable by this trivial method. Fred On 05.05.2018 13:22, marcel.duregards at yahoo.fr wrote: > As the zero touch feature is on TCP 4786 (SMI), I vote for either: > > - a nsa backdoor :-) > - a default active service > > Have you tried to zeroize the config and restart then check if TCP 6154 > is still on LISTEN state ? > > > - > Marcel > > > > On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote: >> Hi, >> >> We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 >> which have TCP port 6154 listening on all interfaces. >> >> Any idea what it could be ? >> >> #show tcp brief all >> TCB Local Address Foreign Address (state) >> ... >> 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< >> >> >> #show tcp tcb 5A529430 >> Connection state is LISTEN, I/O status: 1, unread input bytes: 0 >> Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 >> Local host: 0.0.0.0, Local port: 6154 >> Foreign host: UNKNOWN, Foreign port: 0 >> Connection tableid (VRF): 1 >> Maximum output segment queue size: 50 >> >> Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) >> >> Event Timers (current time is 0xF58354): >> Timer Starts Wakeups Next >> Retrans 0 0 0x0 >> TimeWait 0 0 0x0 >> AckHold 0 0 0x0 >> SendWnd 0 0 0x0 >> KeepAlive 0 0 0x0 >> GiveUp 0 0 0x0 >> PmtuAger 0 0 0x0 >> DeadWait 0 0 0x0 >> Linger 0 0 0x0 >> ProcessQ 0 0 0x0 >> >> iss: 0 snduna: 0 sndnxt: 0 >> irs: 0 rcvnxt: 0 >> >> sndwnd: 0 scale: 0 maxrcvwnd: 4128 >> rcvwnd: 4128 scale: 0 delrcvwnd: 0 >> >> SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms >> minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms >> uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms >> Status Flags: gen tcbs >> Option Flags: VRF id set, keepalive running, nagle, Reuse local address >> Retrans timeout >> IP Precedence value : 0 >> >> Datagrams (max data segment is 516 bytes): >> Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 >> Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second >> Congestion: 0), with data: 0, total data bytes: 0 >> >> Packets received in fast path: 0, fast processed: 0, slow path: 0 >> fast lock acquisition failures: 0, slow path: 0 >> TCP Semaphore 0x5BEB9B10 FREE >> >> >> >> >> >> (The command "show control-plane host open-ports" is not available on >> this platform/code) >> >> >> >> I also think that if it would be a local socket for internal process >> communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. >> So this is listening on all interfaces, virtuals and physicals and seam >> not to be for internal internal process communication. >> >> >> Fred >> From jayfar at jayfar.com Mon May 7 14:59:08 2018 From: jayfar at jayfar.com (Jay Farrell) Date: Mon, 7 May 2018 10:59:08 -0400 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <5AEFFAF7.40704@sig-telecom.net> References: <5AEA9566.7000808@sig-telecom.net> <5AED9410.30903@yahoo.fr> <5AEFFAF7.40704@sig-telecom.net> Message-ID: Just a wild thought – why not open a TAC case with Cisco and ask them? On Mon, May 7, 2018 at 3:06 AM, frederic.jutzet at sig-telecom.net < frederic.jutzet at sig-telecom.net> wrote: > > - a nsa backdoor :-) > > it would be a very bad backdoor as it's really easy to see the port > listening... > > > > - a default active service > > Maybe, but a service which is not officially registered: > https://www.iana.org/assignments/service-names-port-numbers/service-names- > port-numbers.xhtml?search=6154 > > in contrary to the SMI (zero touch feature on tcp 4786) which is > registered since almost 10y: > https://www.iana.org/assignments/service-names-port-numbers/service-names- > port-numbers.xhtml?search=4786 > > > > Could it be possible that this kind of tcp port is not registered by > Iana because it meant to be used for internal communication only > (internal to the device), or should you register any port usage (even > 'private') ? > > > And yes I've tried to reset to default the config, shutdown all > interface, remove all L3 ip/feature (no ip blabla), and I still see by > default 2 TCP ports on listening state: > > Cat4500-SUP7L-E#sh ip prot > *** IP Routing is NSF aware *** > > Cat4500-SUP7L-E# > Cat4500-SUP7L-E#sh run | in ip > address-family ipv4 > address-family ipv6 > no ip routing > ip vrf Liin-vrf > no ip mfib > no ip bootp server > no ip dhcp-client broadcast-flag > no ip igmp snooping > no ipv6 traffic interface-statistics > no ip address > no ip route-cache > no ip address > no ip route-cache > no ip forward-protocol nd > no ip http server > no ip http secure-server > Cat4500-SUP7L-E# > Cat4500-SUP7L-E# > Cat4500-SUP7L-E#show tcp br all > TCB Local Address Foreign Address (state) > 5B40BB30 0.0.0.0.4786 *.* LISTEN > 5CD5D2D8 0.0.0.0.6154 *.* LISTEN > Cat4500-SUP7L-E# > > > > I will now try to negate all potential active service from the 'show run > all' config but it's not optimal as for example 'vstack' (port 4786) > does not appear in the default config so it would not be disable by this > trivial method. > > > Fred > > > On 05.05.2018 13:22, marcel.duregards at yahoo.fr wrote: > > As the zero touch feature is on TCP 4786 (SMI), I vote for either: > > > > - a nsa backdoor :-) > > - a default active service > > > > Have you tried to zeroize the config and restart then check if TCP 6154 > > is still on LISTEN state ? > > > > > > - > > Marcel > > > > > > > > On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote: > >> Hi, > >> > >> We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 > >> which have TCP port 6154 listening on all interfaces. > >> > >> Any idea what it could be ? > >> > >> #show tcp brief all > >> TCB Local Address Foreign Address > (state) > >> ... > >> 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< > >> > >> > >> #show tcp tcb 5A529430 > >> Connection state is LISTEN, I/O status: 1, unread input bytes: 0 > > >> Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 > >> Local host: 0.0.0.0, Local port: 6154 > >> Foreign host: UNKNOWN, Foreign port: 0 > >> Connection tableid (VRF): 1 > >> Maximum output segment queue size: 50 > >> > >> Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) > >> > >> Event Timers (current time is 0xF58354): > >> Timer Starts Wakeups Next > >> Retrans 0 0 0x0 > >> TimeWait 0 0 0x0 > >> AckHold 0 0 0x0 > >> SendWnd 0 0 0x0 > >> KeepAlive 0 0 0x0 > >> GiveUp 0 0 0x0 > >> PmtuAger 0 0 0x0 > >> DeadWait 0 0 0x0 > >> Linger 0 0 0x0 > >> ProcessQ 0 0 0x0 > >> > >> iss: 0 snduna: 0 sndnxt: 0 > >> irs: 0 rcvnxt: 0 > >> > >> sndwnd: 0 scale: 0 maxrcvwnd: 4128 > >> rcvwnd: 4128 scale: 0 delrcvwnd: 0 > >> > >> SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms > >> minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms > >> uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms > >> Status Flags: gen tcbs > >> Option Flags: VRF id set, keepalive running, nagle, Reuse local address > >> Retrans timeout > >> IP Precedence value : 0 > >> > >> Datagrams (max data segment is 516 bytes): > >> Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 > >> Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second > >> Congestion: 0), with data: 0, total data bytes: 0 > >> > >> Packets received in fast path: 0, fast processed: 0, slow path: 0 > >> fast lock acquisition failures: 0, slow path: 0 > >> TCP Semaphore 0x5BEB9B10 FREE > >> > >> > >> > >> > >> > >> (The command "show control-plane host open-ports" is not available on > >> this platform/code) > >> > >> > >> > >> I also think that if it would be a local socket for internal process > >> communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. > >> So this is listening on all interfaces, virtuals and physicals and seam > >> not to be for internal internal process communication. > >> > >> > >> Fred > >> > From bruce.curtis at ndsu.edu Mon May 7 16:24:47 2018 From: bruce.curtis at ndsu.edu (Curtis, Bruce) Date: Mon, 7 May 2018 16:24:47 +0000 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <5AED9410.30903@yahoo.fr> References: <5AEA9566.7000808@sig-telecom.net> <5AED9410.30903@yahoo.fr> Message-ID: <9311BFDC-D569-417E-A5FB-432A64CCEF8C@ndus.edu> Some Cisco devices use 6154 for ypxfrd. 6154 ypxfrd Portmap Request (Info, Atomic*) Triggers when a request is made to the portmapper for the YP transfer daemon (ypxfrd) port. https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfids.html https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/protect_tools.html On May 5, 2018, at 6:22 AM, marcel.duregards--- via NANOG > wrote: As the zero touch feature is on TCP 4786 (SMI), I vote for either: - a nsa backdoor :-) - a default active service Have you tried to zeroize the config and restart then check if TCP 6154 is still on LISTEN state ? - Marcel On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote: Hi, We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 which have TCP port 6154 listening on all interfaces. Any idea what it could be ? #show tcp brief all TCB Local Address Foreign Address (state) ... 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< #show tcp tcb 5A529430 Connection state is LISTEN, I/O status: 1, unread input bytes: 0 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 Local host: 0.0.0.0, Local port: 6154 Foreign host: UNKNOWN, Foreign port: 0 Connection tableid (VRF): 1 Maximum output segment queue size: 50 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is 0xF58354): Timer Starts Wakeups Next Retrans 0 0 0x0 TimeWait 0 0 0x0 AckHold 0 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 Linger 0 0 0x0 ProcessQ 0 0 0x0 iss: 0 snduna: 0 sndnxt: 0 irs: 0 rcvnxt: 0 sndwnd: 0 scale: 0 maxrcvwnd: 4128 rcvwnd: 4128 scale: 0 delrcvwnd: 0 SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms Status Flags: gen tcbs Option Flags: VRF id set, keepalive running, nagle, Reuse local address Retrans timeout IP Precedence value : 0 Datagrams (max data segment is 516 bytes): Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 0, total data bytes: 0 Packets received in fast path: 0, fast processed: 0, slow path: 0 fast lock acquisition failures: 0, slow path: 0 TCP Semaphore 0x5BEB9B10 FREE (The command "show control-plane host open-ports" is not available on this platform/code) I also think that if it would be a local socket for internal process communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. So this is listening on all interfaces, virtuals and physicals and seam not to be for internal internal process communication. Fred --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From niels=nanog at bakker.net Mon May 7 16:44:29 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 7 May 2018 18:44:29 +0200 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <9311BFDC-D569-417E-A5FB-432A64CCEF8C@ndus.edu> References: <5AEA9566.7000808@sig-telecom.net> <5AED9410.30903@yahoo.fr> <9311BFDC-D569-417E-A5FB-432A64CCEF8C@ndus.edu> Message-ID: <20180507164429.GA53693@excession.tpb.net> * bruce.curtis at ndsu.edu (Curtis, Bruce) [Mon 07 May 2018, 18:25 CEST]: >Some Cisco devices use 6154 for ypxfrd. No, they don't. >6154 ypxfrd Portmap Request (Info, Atomic*) > >Triggers when a request is made to the portmapper for the YP transfer daemon (ypxfrd) port. >https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfids.html That's a list of supported IDS signatures, not a list of protocols running on a Cisco device. >https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/protect_tools.html Same. Did you just do a Google search for "site:cisco.com 6141" and paste the results in an email? What made you think the original poster hadn't done their homework? -- Niels. -- From valdis.kletnieks at vt.edu Mon May 7 16:46:07 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 07 May 2018 12:46:07 -0400 Subject: How are you configuring BFD timers? In-Reply-To: <1af8cf9f-5355-b38e-698a-335957b5a972@seacom.mu> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> <42c6d1bb-683c-99f4-4df2-d39dad6e98e1@seacom.mu> <1af8cf9f-5355-b38e-698a-335957b5a972@seacom.mu> Message-ID: <15410.1525711567@turing-police.cc.vt.edu> On Sun, 06 May 2018 14:23:11 +0200, Mark Tinka said: > We have links as short as 5km, all the way to 14,500km. Any words of wisdom / battle scars regarding running links that are in the 10K+ distance? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From janets at nairial.net Mon May 7 17:11:43 2018 From: janets at nairial.net (Janet Sullivan) Date: Mon, 7 May 2018 17:11:43 +0000 Subject: Anyone on from Comcast? Message-ID: I've spent my morning in customer support hell. Sorry for the noise, but if someone with clue could help a gig residential customer getting 3 Mbit/s, I'd love you. From mark.tinka at seacom.mu Mon May 7 17:16:19 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 7 May 2018 19:16:19 +0200 Subject: How are you configuring BFD timers? In-Reply-To: <15410.1525711567@turing-police.cc.vt.edu> References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB4FFB2F@RTC-EXCH01.RESERVE.LDS> <42c6d1bb-683c-99f4-4df2-d39dad6e98e1@seacom.mu> <1af8cf9f-5355-b38e-698a-335957b5a972@seacom.mu> <15410.1525711567@turing-police.cc.vt.edu> Message-ID: On 7/May/18 18:46, valdis.kletnieks at vt.edu wrote: > Any words of wisdom / battle scars regarding running links that > are in the 10K+ distance? Keep repair ships nearby :-). >From a submarine perspective, things that are out-of-scope here. >From an IP perspective, we've had good experience with 250ms * 5 for BFD. Actual RTT latency is 140ms, so there is enough headroom to account for false positives. Mark. From frederic.jutzet at sig-telecom.net Mon May 7 15:45:14 2018 From: frederic.jutzet at sig-telecom.net (frederic.jutzet at sig-telecom.net) Date: Mon, 07 May 2018 17:45:14 +0200 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: References: <5AEA9566.7000808@sig-telecom.net> <5AED9410.30903@yahoo.fr> <5AEFFAF7.40704@sig-telecom.net> Message-ID: <5AF0748A.6070301@sig-telecom.net> I've been told that the TAC center will not take the time to answer as it's not a 'real' problem, service affecting issue. And the Cisco community forum on that topic was useless (nobody answer to a person which already open a topic about this issue 10 months ago). But you are the 4rd person to tell me to open a TAC, I could have tried first. In the meantime Cisco contact me off-list, so I will try with them. On 07.05.2018 16:59, Jay Farrell via NANOG wrote: > Just a wild thought – why not open a TAC case with Cisco and ask them? > > On Mon, May 7, 2018 at 3:06 AM, frederic.jutzet at sig-telecom.net < > frederic.jutzet at sig-telecom.net> wrote: > >>> - a nsa backdoor :-) >> it would be a very bad backdoor as it's really easy to see the port >> listening... >> >> >>> - a default active service >> Maybe, but a service which is not officially registered: >> https://www.iana.org/assignments/service-names-port-numbers/service-names- >> port-numbers.xhtml?search=6154 >> >> in contrary to the SMI (zero touch feature on tcp 4786) which is >> registered since almost 10y: >> https://www.iana.org/assignments/service-names-port-numbers/service-names- >> port-numbers.xhtml?search=4786 >> >> >> >> Could it be possible that this kind of tcp port is not registered by >> Iana because it meant to be used for internal communication only >> (internal to the device), or should you register any port usage (even >> 'private') ? >> >> >> And yes I've tried to reset to default the config, shutdown all >> interface, remove all L3 ip/feature (no ip blabla), and I still see by >> default 2 TCP ports on listening state: >> >> Cat4500-SUP7L-E#sh ip prot >> *** IP Routing is NSF aware *** >> >> Cat4500-SUP7L-E# >> Cat4500-SUP7L-E#sh run | in ip >> address-family ipv4 >> address-family ipv6 >> no ip routing >> ip vrf Liin-vrf >> no ip mfib >> no ip bootp server >> no ip dhcp-client broadcast-flag >> no ip igmp snooping >> no ipv6 traffic interface-statistics >> no ip address >> no ip route-cache >> no ip address >> no ip route-cache >> no ip forward-protocol nd >> no ip http server >> no ip http secure-server >> Cat4500-SUP7L-E# >> Cat4500-SUP7L-E# >> Cat4500-SUP7L-E#show tcp br all >> TCB Local Address Foreign Address (state) >> 5B40BB30 0.0.0.0.4786 *.* LISTEN >> 5CD5D2D8 0.0.0.0.6154 *.* LISTEN >> Cat4500-SUP7L-E# >> >> >> >> I will now try to negate all potential active service from the 'show run >> all' config but it's not optimal as for example 'vstack' (port 4786) >> does not appear in the default config so it would not be disable by this >> trivial method. >> >> >> Fred >> >> >> On 05.05.2018 13:22, marcel.duregards at yahoo.fr wrote: >>> As the zero touch feature is on TCP 4786 (SMI), I vote for either: >>> >>> - a nsa backdoor :-) >>> - a default active service >>> >>> Have you tried to zeroize the config and restart then check if TCP 6154 >>> is still on LISTEN state ? >>> >>> >>> - >>> Marcel >>> >>> >>> >>> On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote: >>>> Hi, >>>> >>>> We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 >>>> which have TCP port 6154 listening on all interfaces. >>>> >>>> Any idea what it could be ? >>>> >>>> #show tcp brief all >>>> TCB Local Address Foreign Address >> (state) >>>> ... >>>> 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< >>>> >>>> >>>> #show tcp tcb 5A529430 >>>> Connection state is LISTEN, I/O status: 1, unread input bytes: 0 >>>> Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 >>>> Local host: 0.0.0.0, Local port: 6154 >>>> Foreign host: UNKNOWN, Foreign port: 0 >>>> Connection tableid (VRF): 1 >>>> Maximum output segment queue size: 50 >>>> >>>> Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) >>>> >>>> Event Timers (current time is 0xF58354): >>>> Timer Starts Wakeups Next >>>> Retrans 0 0 0x0 >>>> TimeWait 0 0 0x0 >>>> AckHold 0 0 0x0 >>>> SendWnd 0 0 0x0 >>>> KeepAlive 0 0 0x0 >>>> GiveUp 0 0 0x0 >>>> PmtuAger 0 0 0x0 >>>> DeadWait 0 0 0x0 >>>> Linger 0 0 0x0 >>>> ProcessQ 0 0 0x0 >>>> >>>> iss: 0 snduna: 0 sndnxt: 0 >>>> irs: 0 rcvnxt: 0 >>>> >>>> sndwnd: 0 scale: 0 maxrcvwnd: 4128 >>>> rcvwnd: 4128 scale: 0 delrcvwnd: 0 >>>> >>>> SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms >>>> minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms >>>> uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms >>>> Status Flags: gen tcbs >>>> Option Flags: VRF id set, keepalive running, nagle, Reuse local address >>>> Retrans timeout >>>> IP Precedence value : 0 >>>> >>>> Datagrams (max data segment is 516 bytes): >>>> Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 >>>> Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second >>>> Congestion: 0), with data: 0, total data bytes: 0 >>>> >>>> Packets received in fast path: 0, fast processed: 0, slow path: 0 >>>> fast lock acquisition failures: 0, slow path: 0 >>>> TCP Semaphore 0x5BEB9B10 FREE >>>> >>>> >>>> >>>> >>>> >>>> (The command "show control-plane host open-ports" is not available on >>>> this platform/code) >>>> >>>> >>>> >>>> I also think that if it would be a local socket for internal process >>>> communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. >>>> So this is listening on all interfaces, virtuals and physicals and seam >>>> not to be for internal internal process communication. >>>> >>>> >>>> Fred >>>> From sfischer1967 at gmail.com Mon May 7 17:55:07 2018 From: sfischer1967 at gmail.com (Stephen Fischer) Date: Mon, 7 May 2018 13:55:07 -0400 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <5AEA9566.7000808@sig-telecom.net> References: <5AEA9566.7000808@sig-telecom.net> Message-ID: reading this - just wondering....do you use the SmartCall home service? I wonder if that's what is using this. try this: no service smart-call-home and see if that disables it... just a thought On Thu, May 3, 2018 at 12:51 AM, frederic.jutzet at sig-telecom.net < frederic.jutzet at sig-telecom.net> wrote: > Hi, > > We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 > which have TCP port 6154 listening on all interfaces. > > Any idea what it could be ? > > #show tcp brief all > TCB Local Address Foreign Address (state) > ... > 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< > > > #show tcp tcb 5A529430 > Connection state is LISTEN, I/O status: 1, unread input bytes: 0 > Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 > Local host: 0.0.0.0, Local port: 6154 > Foreign host: UNKNOWN, Foreign port: 0 > Connection tableid (VRF): 1 > Maximum output segment queue size: 50 > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) > > Event Timers (current time is 0xF58354): > Timer Starts Wakeups Next > Retrans 0 0 0x0 > TimeWait 0 0 0x0 > AckHold 0 0 0x0 > SendWnd 0 0 0x0 > KeepAlive 0 0 0x0 > GiveUp 0 0 0x0 > PmtuAger 0 0 0x0 > DeadWait 0 0 0x0 > Linger 0 0 0x0 > ProcessQ 0 0 0x0 > > iss: 0 snduna: 0 sndnxt: 0 > irs: 0 rcvnxt: 0 > > sndwnd: 0 scale: 0 maxrcvwnd: 4128 > rcvwnd: 4128 scale: 0 delrcvwnd: 0 > > SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms > minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms > uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms > Status Flags: gen tcbs > Option Flags: VRF id set, keepalive running, nagle, Reuse local address > Retrans timeout > IP Precedence value : 0 > > Datagrams (max data segment is 516 bytes): > Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 > Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second > Congestion: 0), with data: 0, total data bytes: 0 > > Packets received in fast path: 0, fast processed: 0, slow path: 0 > fast lock acquisition failures: 0, slow path: 0 > TCP Semaphore 0x5BEB9B10 FREE > > > > > > (The command "show control-plane host open-ports" is not available on > this platform/code) > > > > I also think that if it would be a local socket for internal process > communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. > So this is listening on all interfaces, virtuals and physicals and seam > not to be for internal internal process communication. > > > Fred > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From jayfar at jayfar.com Mon May 7 19:58:54 2018 From: jayfar at jayfar.com (Jay Farrell) Date: Mon, 7 May 2018 15:58:54 -0400 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces Message-ID: I saw that list, but understood the numbers there to be IDS signature numbers, rather than port numbers. Am I misreading something? On Mon, May 7, 2018 at 12:24 PM, Curtis, Bruce wrote: > Some Cisco devices use 6154 for ypxfrd. > > > 6154 ypxfrd Portmap Request (Info, Atomic*) > > Triggers when a request is made to the portmapper for the YP transfer > daemon (ypxfrd) port. > > https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/ > configuration/guide/fsecur_c/scfids.html > > https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/ > configuration/guide/asa_84_cli_config/protect_tools.html > > From bruce.curtis at ndsu.edu Mon May 7 20:52:45 2018 From: bruce.curtis at ndsu.edu (Curtis, Bruce) Date: Mon, 7 May 2018 20:52:45 +0000 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: References: Message-ID: <51936E11-F8EA-42BF-A99E-06540BB46447@ndus.edu> On May 7, 2018, at 2:58 PM, Jay Farrell via NANOG > wrote: I saw that list, but understood the numbers there to be IDS signature numbers, rather than port numbers. Am I misreading something? No, you are correct. As Niels Bakker pointed out that is a list of IDS signatures, not a list of ports that Cisco devices listen on. I just skimmed the pages, I should have read them more thoroughly before sending to the list. On Mon, May 7, 2018 at 12:24 PM, Curtis, Bruce > wrote: Some Cisco devices use 6154 for ypxfrd. 6154 ypxfrd Portmap Request (Info, Atomic*) Triggers when a request is made to the portmapper for the YP transfer daemon (ypxfrd) port. https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/ configuration/guide/fsecur_c/scfids.html https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/ configuration/guide/asa_84_cli_config/protect_tools.html --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From dbrain at mcnc.org Mon May 7 18:25:29 2018 From: dbrain at mcnc.org (David Brain) Date: Mon, 07 May 2018 18:25:29 +0000 Subject: Hulu Contact Message-ID: Is there a good Hulu contact for situations where IP addresses are being incorrectly flagged as anonymous proxy? I see 'ipadmin at hulu' but suspect that's not exactly what I need. Thanks, David. -- David Brain - MCNC - 919.248.1998 From frederic.jutzet at sig-telecom.net Mon May 7 20:02:12 2018 From: frederic.jutzet at sig-telecom.net (frederic.jutzet at sig-telecom.net) Date: Mon, 07 May 2018 22:02:12 +0200 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: References: <5AEA9566.7000808@sig-telecom.net> <5AED9410.30903@yahoo.fr> <5AEFFAF7.40704@sig-telecom.net> <5AF0748A.6070301@sig-telecom.net> Message-ID: <5AF0B0C4.70205@sig-telecom.net> Cisco contact me off-line and ask me to share my datas. They will open a bug id and investigate. Nothing to say, very pro active. The bug id is CSCvj35885 Cisco also confirmed that this tcp port is for internal communication (internal to the device) only and should not be exposed. Next time I will follow your recommendation about opening a tac case for information request, and not bother the community. Thank to all for your tips and ideas. Best regards, Fred On 07.05.2018 21:22, Spaans, Joel H wrote: > This has not been my experience. TAC specifically has an option when opening a case to "Ask a question". It's purpose is for non-outage queries such as these. I've asked them things such as "How many ARP entries does an ASA 5585X support?" Sometimes I find conflicting information so I need to ask TAC or I'm just too busy to find the answer. > > I've learned not to be hesitant to engage them, we pay for the support after all. > > Yes, sometimes you will get an engineer who is not helpful. Let them close the case and open another case or insist that the case be moved to another engineer. > > -----Original Message----- > From: NANOG On Behalf Of frederic.jutzet at sig-telecom.net > Sent: Monday, May 7, 2018 10:45 AM > To: Jay Farrell ; nanog at nanog.org > Subject: Re: Catalyst 4500 listening on TCP 6154 on all interfaces > > I've been told that the TAC center will not take the time to answer as it's not a 'real' problem, service affecting issue. > And the Cisco community forum on that topic was useless (nobody answer to a person which already open a topic about this issue 10 months ago). > But you are the 4rd person to tell me to open a TAC, I could have tried first. > In the meantime Cisco contact me off-list, so I will try with them. > > > > > On 07.05.2018 16:59, Jay Farrell via NANOG wrote: >> Just a wild thought – why not open a TAC case with Cisco and ask them? >> >> On Mon, May 7, 2018 at 3:06 AM, frederic.jutzet at sig-telecom.net < >> frederic.jutzet at sig-telecom.net> wrote: >> >>>> - a nsa backdoor :-) >>> it would be a very bad backdoor as it's really easy to see the port >>> listening... >>> >>> >>>> - a default active service >>> Maybe, but a service which is not officially registered: >>> https://www.iana.org/assignments/service-names-port-numbers/service-n >>> ames- >>> port-numbers.xhtml?search=6154 >>> >>> in contrary to the SMI (zero touch feature on tcp 4786) which is >>> registered since almost 10y: >>> https://www.iana.org/assignments/service-names-port-numbers/service-n >>> ames- >>> port-numbers.xhtml?search=4786 >>> >>> >>> >>> Could it be possible that this kind of tcp port is not registered by >>> Iana because it meant to be used for internal communication only >>> (internal to the device), or should you register any port usage (even >>> 'private') ? >>> >>> >>> And yes I've tried to reset to default the config, shutdown all >>> interface, remove all L3 ip/feature (no ip blabla), and I still see >>> by default 2 TCP ports on listening state: >>> >>> Cat4500-SUP7L-E#sh ip prot >>> *** IP Routing is NSF aware *** >>> >>> Cat4500-SUP7L-E# >>> Cat4500-SUP7L-E#sh run | in ip >>> address-family ipv4 >>> address-family ipv6 >>> no ip routing >>> ip vrf Liin-vrf >>> no ip mfib >>> no ip bootp server >>> no ip dhcp-client broadcast-flag >>> no ip igmp snooping >>> no ipv6 traffic interface-statistics >>> no ip address >>> no ip route-cache >>> no ip address >>> no ip route-cache >>> no ip forward-protocol nd >>> no ip http server >>> no ip http secure-server >>> Cat4500-SUP7L-E# >>> Cat4500-SUP7L-E# >>> Cat4500-SUP7L-E#show tcp br all >>> TCB Local Address Foreign Address (state) >>> 5B40BB30 0.0.0.0.4786 *.* LISTEN >>> 5CD5D2D8 0.0.0.0.6154 *.* LISTEN >>> Cat4500-SUP7L-E# >>> >>> >>> >>> I will now try to negate all potential active service from the 'show >>> run all' config but it's not optimal as for example 'vstack' (port >>> 4786) does not appear in the default config so it would not be >>> disable by this trivial method. >>> >>> >>> Fred >>> >>> >>> On 05.05.2018 13:22, marcel.duregards at yahoo.fr wrote: >>>> As the zero touch feature is on TCP 4786 (SMI), I vote for either: >>>> >>>> - a nsa backdoor :-) >>>> - a default active service >>>> >>>> Have you tried to zeroize the config and restart then check if TCP >>>> 6154 is still on LISTEN state ? >>>> >>>> >>>> - >>>> Marcel >>>> >>>> >>>> >>>> On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote: >>>>> Hi, >>>>> >>>>> We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 >>>>> which have TCP port 6154 listening on all interfaces. >>>>> >>>>> Any idea what it could be ? >>>>> >>>>> #show tcp brief all >>>>> TCB Local Address Foreign Address >>> (state) >>>>> ... >>>>> 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< >>>>> >>>>> >>>>> #show tcp tcb 5A529430 >>>>> Connection state is LISTEN, I/O status: 1, unread input bytes: 0 >>>>> Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL >>>>> 255 Local host: 0.0.0.0, Local port: 6154 Foreign host: UNKNOWN, >>>>> Foreign port: 0 Connection tableid (VRF): 1 Maximum output segment >>>>> queue size: 50 >>>>> >>>>> Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 >>>>> bytes) >>>>> >>>>> Event Timers (current time is 0xF58354): >>>>> Timer Starts Wakeups Next >>>>> Retrans 0 0 0x0 >>>>> TimeWait 0 0 0x0 >>>>> AckHold 0 0 0x0 >>>>> SendWnd 0 0 0x0 >>>>> KeepAlive 0 0 0x0 >>>>> GiveUp 0 0 0x0 >>>>> PmtuAger 0 0 0x0 >>>>> DeadWait 0 0 0x0 >>>>> Linger 0 0 0x0 >>>>> ProcessQ 0 0 0x0 >>>>> >>>>> iss: 0 snduna: 0 sndnxt: 0 >>>>> irs: 0 rcvnxt: 0 >>>>> >>>>> sndwnd: 0 scale: 0 maxrcvwnd: 4128 >>>>> rcvwnd: 4128 scale: 0 delrcvwnd: 0 >>>>> >>>>> SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms >>>>> minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms >>>>> uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms Status >>>>> Flags: gen tcbs Option Flags: VRF id set, keepalive running, nagle, >>>>> Reuse local address >>>>> Retrans timeout >>>>> IP Precedence value : 0 >>>>> >>>>> Datagrams (max data segment is 516 bytes): >>>>> Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 >>>>> Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second >>>>> Congestion: 0), with data: 0, total data bytes: 0 >>>>> >>>>> Packets received in fast path: 0, fast processed: 0, slow path: 0 >>>>> fast lock acquisition failures: 0, slow path: 0 >>>>> TCP Semaphore 0x5BEB9B10 FREE >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> (The command "show control-plane host open-ports" is not available >>>>> on this platform/code) >>>>> >>>>> >>>>> >>>>> I also think that if it would be a local socket for internal >>>>> process communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. >>>>> So this is listening on all interfaces, virtuals and physicals and >>>>> seam not to be for internal internal process communication. >>>>> >>>>> >>>>> Fred >>>>> > > From Joel.Spaans at usd.edu Mon May 7 19:22:20 2018 From: Joel.Spaans at usd.edu (Spaans, Joel H) Date: Mon, 7 May 2018 19:22:20 +0000 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <5AF0748A.6070301@sig-telecom.net> References: <5AEA9566.7000808@sig-telecom.net> <5AED9410.30903@yahoo.fr> <5AEFFAF7.40704@sig-telecom.net> <5AF0748A.6070301@sig-telecom.net> Message-ID: This has not been my experience. TAC specifically has an option when opening a case to "Ask a question". It's purpose is for non-outage queries such as these. I've asked them things such as "How many ARP entries does an ASA 5585X support?" Sometimes I find conflicting information so I need to ask TAC or I'm just too busy to find the answer. I've learned not to be hesitant to engage them, we pay for the support after all. Yes, sometimes you will get an engineer who is not helpful. Let them close the case and open another case or insist that the case be moved to another engineer. -----Original Message----- From: NANOG On Behalf Of frederic.jutzet at sig-telecom.net Sent: Monday, May 7, 2018 10:45 AM To: Jay Farrell ; nanog at nanog.org Subject: Re: Catalyst 4500 listening on TCP 6154 on all interfaces I've been told that the TAC center will not take the time to answer as it's not a 'real' problem, service affecting issue. And the Cisco community forum on that topic was useless (nobody answer to a person which already open a topic about this issue 10 months ago). But you are the 4rd person to tell me to open a TAC, I could have tried first. In the meantime Cisco contact me off-list, so I will try with them. On 07.05.2018 16:59, Jay Farrell via NANOG wrote: > Just a wild thought – why not open a TAC case with Cisco and ask them? > > On Mon, May 7, 2018 at 3:06 AM, frederic.jutzet at sig-telecom.net < > frederic.jutzet at sig-telecom.net> wrote: > >>> - a nsa backdoor :-) >> it would be a very bad backdoor as it's really easy to see the port >> listening... >> >> >>> - a default active service >> Maybe, but a service which is not officially registered: >> https://www.iana.org/assignments/service-names-port-numbers/service-n >> ames- >> port-numbers.xhtml?search=6154 >> >> in contrary to the SMI (zero touch feature on tcp 4786) which is >> registered since almost 10y: >> https://www.iana.org/assignments/service-names-port-numbers/service-n >> ames- >> port-numbers.xhtml?search=4786 >> >> >> >> Could it be possible that this kind of tcp port is not registered by >> Iana because it meant to be used for internal communication only >> (internal to the device), or should you register any port usage (even >> 'private') ? >> >> >> And yes I've tried to reset to default the config, shutdown all >> interface, remove all L3 ip/feature (no ip blabla), and I still see >> by default 2 TCP ports on listening state: >> >> Cat4500-SUP7L-E#sh ip prot >> *** IP Routing is NSF aware *** >> >> Cat4500-SUP7L-E# >> Cat4500-SUP7L-E#sh run | in ip >> address-family ipv4 >> address-family ipv6 >> no ip routing >> ip vrf Liin-vrf >> no ip mfib >> no ip bootp server >> no ip dhcp-client broadcast-flag >> no ip igmp snooping >> no ipv6 traffic interface-statistics >> no ip address >> no ip route-cache >> no ip address >> no ip route-cache >> no ip forward-protocol nd >> no ip http server >> no ip http secure-server >> Cat4500-SUP7L-E# >> Cat4500-SUP7L-E# >> Cat4500-SUP7L-E#show tcp br all >> TCB Local Address Foreign Address (state) >> 5B40BB30 0.0.0.0.4786 *.* LISTEN >> 5CD5D2D8 0.0.0.0.6154 *.* LISTEN >> Cat4500-SUP7L-E# >> >> >> >> I will now try to negate all potential active service from the 'show >> run all' config but it's not optimal as for example 'vstack' (port >> 4786) does not appear in the default config so it would not be >> disable by this trivial method. >> >> >> Fred >> >> >> On 05.05.2018 13:22, marcel.duregards at yahoo.fr wrote: >>> As the zero touch feature is on TCP 4786 (SMI), I vote for either: >>> >>> - a nsa backdoor :-) >>> - a default active service >>> >>> Have you tried to zeroize the config and restart then check if TCP >>> 6154 is still on LISTEN state ? >>> >>> >>> - >>> Marcel >>> >>> >>> >>> On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote: >>>> Hi, >>>> >>>> We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 >>>> which have TCP port 6154 listening on all interfaces. >>>> >>>> Any idea what it could be ? >>>> >>>> #show tcp brief all >>>> TCB Local Address Foreign Address >> (state) >>>> ... >>>> 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< >>>> >>>> >>>> #show tcp tcb 5A529430 >>>> Connection state is LISTEN, I/O status: 1, unread input bytes: 0 >>>> Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL >>>> 255 Local host: 0.0.0.0, Local port: 6154 Foreign host: UNKNOWN, >>>> Foreign port: 0 Connection tableid (VRF): 1 Maximum output segment >>>> queue size: 50 >>>> >>>> Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 >>>> bytes) >>>> >>>> Event Timers (current time is 0xF58354): >>>> Timer Starts Wakeups Next >>>> Retrans 0 0 0x0 >>>> TimeWait 0 0 0x0 >>>> AckHold 0 0 0x0 >>>> SendWnd 0 0 0x0 >>>> KeepAlive 0 0 0x0 >>>> GiveUp 0 0 0x0 >>>> PmtuAger 0 0 0x0 >>>> DeadWait 0 0 0x0 >>>> Linger 0 0 0x0 >>>> ProcessQ 0 0 0x0 >>>> >>>> iss: 0 snduna: 0 sndnxt: 0 >>>> irs: 0 rcvnxt: 0 >>>> >>>> sndwnd: 0 scale: 0 maxrcvwnd: 4128 >>>> rcvwnd: 4128 scale: 0 delrcvwnd: 0 >>>> >>>> SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms >>>> minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms >>>> uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms Status >>>> Flags: gen tcbs Option Flags: VRF id set, keepalive running, nagle, >>>> Reuse local address >>>> Retrans timeout >>>> IP Precedence value : 0 >>>> >>>> Datagrams (max data segment is 516 bytes): >>>> Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 >>>> Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second >>>> Congestion: 0), with data: 0, total data bytes: 0 >>>> >>>> Packets received in fast path: 0, fast processed: 0, slow path: 0 >>>> fast lock acquisition failures: 0, slow path: 0 >>>> TCP Semaphore 0x5BEB9B10 FREE >>>> >>>> >>>> >>>> >>>> >>>> (The command "show control-plane host open-ports" is not available >>>> on this platform/code) >>>> >>>> >>>> >>>> I also think that if it would be a local socket for internal >>>> process communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. >>>> So this is listening on all interfaces, virtuals and physicals and >>>> seam not to be for internal internal process communication. >>>> >>>> >>>> Fred >>>> From walt at wollny.org Mon May 7 18:26:46 2018 From: walt at wollny.org (Walt) Date: Mon, 7 May 2018 18:26:46 +0000 Subject: would someone from AS7363 contact me off list please Message-ID: From nanog at ics-il.net Tue May 8 14:12:21 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 8 May 2018 09:12:21 -0500 (CDT) Subject: DSL Operators Mailing List? In-Reply-To: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> References: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> Message-ID: <370512299.4846.1525788737015.JavaMail.mhammett@ThunderFuck> I made a Facebook group for xLEC-related things. https://www.facebook.com/groups/198986590901754/ ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG" Sent: Sunday, January 7, 2018 11:10:11 AM Subject: DSL Operators Mailing List? Is there a good mailing list for DSL operators? A cursory search really only came up with DSL Reports, which is far from what I'm looking for. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From list at satchell.net Tue May 8 16:19:30 2018 From: list at satchell.net (Stephen Satchell) Date: Tue, 8 May 2018 09:19:30 -0700 Subject: DSL Operators Mailing List? In-Reply-To: <370512299.4846.1525788737015.JavaMail.mhammett@ThunderFuck> References: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> <370512299.4846.1525788737015.JavaMail.mhammett@ThunderFuck> Message-ID: <871f1713-7867-e8fc-4f5b-860c43fc29df@satchell.net> On 05/08/2018 07:12 AM, Mike Hammett wrote: > I made a Facebook group for xLEC-related things. (Not useful for those of us not on Facebook.) From cboyd at gizmopartners.com Tue May 8 16:43:45 2018 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 8 May 2018 11:43:45 -0500 Subject: DSL Operators Mailing List? In-Reply-To: <871f1713-7867-e8fc-4f5b-860c43fc29df@satchell.net> References: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> <370512299.4846.1525788737015.JavaMail.mhammett@ThunderFuck> <871f1713-7867-e8fc-4f5b-860c43fc29df@satchell.net> Message-ID: <0AF566D2-E659-4AEF-B3A9-A24EA6B1AD36@gizmopartners.com> > On May 8, 2018, at 11:19 AM, Stephen Satchell wrote: > > (Not useful for those of us not on Facebook.) LIKE From nanog at ics-il.net Tue May 8 17:16:29 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 8 May 2018 12:16:29 -0500 (CDT) Subject: DSL Operators Mailing List? In-Reply-To: <871f1713-7867-e8fc-4f5b-860c43fc29df@satchell.net> References: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> <370512299.4846.1525788737015.JavaMail.mhammett@ThunderFuck> <871f1713-7867-e8fc-4f5b-860c43fc29df@satchell.net> Message-ID: <614044284.4927.1525799786885.JavaMail.mhammett@ThunderFuck> Then don't participate and move on? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Stephen Satchell" To: nanog at nanog.org Sent: Tuesday, May 8, 2018 11:19:30 AM Subject: Re: DSL Operators Mailing List? On 05/08/2018 07:12 AM, Mike Hammett wrote: > I made a Facebook group for xLEC-related things. (Not useful for those of us not on Facebook.) From list at satchell.net Tue May 8 21:42:14 2018 From: list at satchell.net (Stephen Satchell) Date: Tue, 8 May 2018 14:42:14 -0700 Subject: DSL Operators Mailing List? In-Reply-To: <614044284.4927.1525799786885.JavaMail.mhammett@ThunderFuck> References: <1900061265.18702.1515345008301.JavaMail.mhammett@ThunderFuck> <370512299.4846.1525788737015.JavaMail.mhammett@ThunderFuck> <871f1713-7867-e8fc-4f5b-860c43fc29df@satchell.net> <614044284.4927.1525799786885.JavaMail.mhammett@ThunderFuck> Message-ID: <4d1fc549-2faf-7b4a-0e41-cc5e543e5cf2@satchell.net> In other words, status quo ante? On 05/08/2018 10:16 AM, Mike Hammett wrote: > Then don't participate and move on? > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Stephen Satchell" > To: nanog at nanog.org > Sent: Tuesday, May 8, 2018 11:19:30 AM > Subject: Re: DSL Operators Mailing List? > > On 05/08/2018 07:12 AM, Mike Hammett wrote: >> I made a Facebook group for xLEC-related things. > > > (Not useful for those of us not on Facebook.) > From Jacques.Latour at cira.ca Wed May 9 14:41:30 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 9 May 2018 14:41:30 +0000 Subject: REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN62 Panama City, Panama - June 25, 2018 Message-ID: <5b335e0cacc54cb5b7d51c8ca8129b39@cira.ca> Hi All! ****Apologies there was some earlier problems with the mailing list so if you have submitted prior to today we may have not received the request. Would you please resubmit to the list and we will be sure to get a response to you as soon as possible? Thank you. **** The next ICANN DNSSEC Workshop will be on Monday, June 25, 2018 in Panama City, Panama. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-panamacity at isoc.org by **18 May 2018** The committee is also thinking of having a panel on the Post-KSK-Rollover. We’d like to see if anyone from the DNSSEC community can identify ways that can help end users have a better idea of what they should look for and how they might be able to know if the KSK rollover has or has not effected them & their use of DNS (i.e. 1 second after the change). Thanks, Jack REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN62, Panama City, Panama. June 25, 2018 The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN62 meeting held from 25-28 June 2018 in Panama City, Panama. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Community Forum in San Juan, Puerto Rico on 14 March 2018. The presentations and transcripts are available at: https://61.schedule.icann.org/meetings/647563[61.schedule.icann.org],https://61.schedule.icann.org/meetings/647564[61.schedule.icann.org], and https://61.schedule.icann.org/meetings/647565[61.schedule.icann.org]. The DNSSEC Workshop Program Committee is developing a 3-hour program. Proposals will be considered for the following topic areas and included if space permits. In addition, we welcome suggestions for additional topics either for inclusion in the ICANN62 workshop, or for consideration for future workshops. 1. DNSSEC Activities Panel (Regional and global) For this panel, we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment, including Root Key Signing Key (KSK) Rollover activities. Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you. 2. DNSSEC Deployment Challenges The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC. In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature: - Are there any policies directly or indirectly impeding your DNSSEC deployment? (RRR model, CDS/CDNSKEY automation) - What are your most significant concerns with DNSSEC, e.g., complexity, training, implementation, operation or something else? - What do you expect DNSSEC to do for you and what doesn't it do? - What do you see as the most important trade-offs with respect to doing or not doing DNSSEC? We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc. In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-panamacity at isoc.org by **Friday, 18 May 2018** Thank you, Kathy and Julie On behalf of the DNSSEC Workshop Program Committee: Mark Elkins, DNS/ZACR Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, Chinese Academy of Sciences (CAS) Russ Mundy, Parsons Ondrej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From cgreco at mbay.net Tue May 8 16:58:45 2018 From: cgreco at mbay.net (cgreco at mbay.net) Date: Tue, 08 May 2018 09:58:45 -0700 Subject: Wave service providers in Hong Kong metro area Message-ID: <20180508095845.Horde.hbHZIp09Va5TUV0h6SjlVDE@webmail.mbay.net> Hi Folks, Can anyone recommend wave providers on the Hong Kong area? I need to reach between two colo facilities there. Feel free to ping me off-list. Best, -Chuck From spoofer-info at caida.org Tue May 8 17:00:01 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Tue, 8 May 2018 10:00:01 -0700 Subject: Spoofer Report for NANOG for Apr 2018 Message-ID: <201805081700.w48H01Ys069490@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Apr 2018: ASN Name First-Fixed 11796 AIRSTREAMCOMM-NET 2018-04-12 7922 COMCAST-7922 2018-04-15 7018 ATT-INTERNET4 2018-04-30 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Apr 2018: ASN Name First-Spoofed Last-Spoofed 577 BACOM 2016-03-09 2018-04-29 4323 TWTC 2016-04-22 2018-04-17 1280 ISC-AS-1280 2016-05-27 2018-04-18 7029 WINDSTREAM 2016-06-21 2018-04-24 2828 XO-AS15 2016-07-27 2018-04-20 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-04-29 6128 CABLE-NET-1 2016-09-03 2018-04-26 19165 WEBPASS 2016-09-19 2018-04-19 11232 MIDCO-NET 2016-09-22 2018-04-18 20412 CLARITY-TELECOM 2016-09-30 2018-04-30 20001 ROADRUNNER-WEST 2016-10-08 2018-04-19 6181 FUSE-NET 2016-10-10 2018-04-30 15305 SYRINGANETWORKS 2016-10-21 2018-04-25 25787 ROWE-NETWORKS 2016-10-21 2018-04-27 174 COGENT-174 2016-10-21 2018-04-27 271 BCNET-AS 2016-10-24 2018-04-30 32440 LONI 2016-11-03 2018-04-28 33182 DimeNOC 2016-11-08 2018-04-25 12083 WOW-INTERNET 2016-11-09 2018-04-29 5056 AUREON-5056 2016-11-10 2018-04-30 39939 RISE-CO-AS39939 2016-11-11 2018-04-15 11404 AS-VOBIZ 2016-11-11 2018-04-09 1403 EBOX 2016-11-12 2018-04-30 20105 URICHMOND 2016-11-15 2018-04-24 3549 LVLT-3549 2016-11-16 2018-04-30 54858 AS-SBI 2016-12-25 2018-04-27 2152 CSUNET-NW 2017-02-02 2018-04-21 21832 KELLINCOM-1 2017-02-03 2018-04-25 62593 SILOWIRELESS 2017-06-09 2018-04-28 6461 ZAYO-6461 2017-06-21 2018-04-30 26793 ICS-LLC 2017-08-16 2018-04-24 63296 AMARILLO-WIRELESS 2017-09-01 2018-04-25 7233 YAHOO-US 2017-09-07 2018-04-26 33523 ROWANUNIVERSITY 2017-10-29 2018-04-25 1680 NV-ASN 2017-11-14 2018-04-17 11796 AIRSTREAMCOMM-NET 2017-11-30 2018-04-02 12222 AKAMAI 2018-02-14 2018-04-25 55236 CBC 2018-03-03 2018-04-21 3257 GTT-BACKBONE 2018-03-06 2018-04-27 29384 Qatar-Foundation 2018-03-08 2018-04-29 23148 TERRENAP 2018-03-15 2018-04-25 226 LOS-NETTOS-AS 2018-03-26 2018-04-26 54417 STIMULUS-TECHNOLOGIES 2018-03-29 2018-04-24 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2018-04-29 15176 AS-INOC 2018-04-09 2018-04-12 20009 WADSNET 2018-04-13 2018-04-29 4201 ORST-AS 2018-04-19 2018-04-26 11827 WSU-AS 2018-04-19 2018-04-26 31863 DACEN-2 2018-04-26 2018-04-26 11427 SCRR-11427 2018-04-28 2018-04-28 14615 ROCK-HILL-TELEPHONE 2018-04-30 2018-04-30 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From dciccaro at cisco.com Wed May 9 16:51:35 2018 From: dciccaro at cisco.com (Dario Ciccarone) Date: Wed, 9 May 2018 12:51:35 -0400 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: <5AEA9566.7000808@sig-telecom.net> References: <5AEA9566.7000808@sig-telecom.net> Message-ID: NANOG mailing list subscribers:     Hi there. My name is Dario Ciccarone and I work as an Incident Manager on the Cisco PSIRT. The Cisco Product Security Incident Response Team (PSIRT) is responsible for responding to Cisco product security incidents. The Cisco PSIRT is a dedicated, global team that manages the receipt, investigation, and public reporting of information about security vulnerabilities and issues related to Cisco products and networks. Cisco defines a security vulnerability as an unintended weakness in a product that could allow an attacker to compromise the integrity, availability, or confidentiality of the product.     Frederic's email caught our attention, and we would like to provide some additional context and answers to the behavior by him observed. The issue observed by Frederic (port 6154/tcp showing up in LISTEN state on some IOS XE releases) is documented on Cisco bug ID CSCut14378, with the title "Port 6154/tcp (XTF Agent) shown in LISTEN state on some Cisco IOS XE releases". The details of this bug can be found on our Bug Search Tool at the following URL:     https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut14378     While access to the Bug Search Tool is generally offered as part of a support contract and requires of an account on cisco.com, Cisco users *without a support contract* can register for a Guest account by filling the form at the following URL:     https://idreg.cloudapps.cisco.com/idreg/register.do     This guest account will provide limited privileges on cisco.com - but enough to be able to access the Bug Search Tool and read the complete Release Note Enclosure for the bug in question. For those NANOG members that would prefer not to register for a Guest account with Cisco - I will be providing the full Release Note Enclosure text at the end of this email.     I would also like to use this opportunity to invite the NANOG subscribers to reach out to the Cisco PSIRT whenever you observe a behavior on a Cisco device that may create a concern in regards to the device's general security posture. The Cisco PSIRT can be reached by email at psirt at cisco.com - additional information on how to reach us can be found at the following URL:     https://www.cisco.com/c/en/us/about/security-center/security-vulnerability-policy.html#roosfassv     Thanks,     Dario Dario Ciccarone Incident Manager - CCIE #10395 Product Security Incident Response Team (PSIRT) Cisco Systems, Inc. PGP Key ID: 0xBA1AE0F0 http://www.cisco.com/go/psirt CSCut14378, - "Port 6154/tcp (XTF Agent) shown in LISTEN state on some Cisco IOS XE releases" *Symptom:* The output of the "show tcp brief all" command or the "show ip ports all" command on a Cisco device running a subset of Cisco IOS XE releases may show port 6154/tcp in LISTEN state. Example output from "show tcp brief all" exhibiting this behavior: IOS-XE#show tcp brief all TCB       Local Address               Foreign Address             (state) 386F0098  10.122.163.49.23           10.118.116.244.59674        ESTAB 3D639184  10.122.163.49.23           10.118.116.244.59671        TIMEWAIT 38720150  0.0.0.0.4786               *.*                         LISTEN 3D4B6A78  0.0.0.0.6154               *.*                         LISTEN 3A7CC28C  ::.443                     *.*                         LISTEN 391EDBF4  0.0.0.0.443                *.*                         LISTEN 3C8C480C  ::.80                      *.*                         LISTEN 39B48F38  0.0.0.0.80                 *.*                         LISTEN 9626:37  192.168.1.1.9010       0.0.0.0.*             LISTEN IOS-XE# Example output from "show ip ports all" exhibiting this behavior: (truncated) IOS-XE#show ip ports all tcp   *:6154                     *:*                         LISTEN      309/[IOS]XTF Agent IOS-XE# *Conditions:* No special conditions. *Workaround:* There are no workarounds needed. *Further Problem Description:* The Cisco XTF (Cross-OS Test Framework) is a Cisco internal tool to perform product testing during development. Due to an issue with a build tool, a limited number of Cisco IOS XE releases were shipped with an embedded Cisco XTF Agent. The Cisco XTF Agent accepts connections from the XTF manager on port 6154/TCP. It is important to note that even if the "Local Address" and "Foreign Address" are shown as wildcards  on the output of the "show tcp brief all" command or the "show ip ports all" command (which would imply the XTF Agent listens on all interfaces, and would accept connections from any remote source IP address), the XTF Agent is started up with a set of socket options that only allows it to accept connections sourced from the Cisco IOS XE Internal VRF. The Cisco IOS XE Internal VRF is used for internal inter-process communications and is not accessible from outside the box nor from any other VRF on the box. Attempts to connect to port 6154/TCP coming from any other VRF on the box (no VRF, default VRF, Management VRF or any user-defined VRFs) will be answered with a TCP RST, tearing down the connection. There is no way to establish a TCP connection to the XTF Agent from outside the internal VRF. The following is a complete list of all Cisco IOS XE releases that shipped with an embedded XTF Agent and will show port 6154/TCP as being on LISTEN state when executing a "show tcp brief all" command : * 3.2.0SE, 3.2.1SE, 3.2.2SE, 3.2.3SE * 3.3.0SE, 3.3.1SE, 3.3.2SE, 3.3.3SE, 3.3.4SE, 3.3.5SE * 3.5.0E, 3.5.1E, 3.5.2E, 3.5.3E * 3.6.0E, 3.6.0aE, 3.6.0bE, 3.6.1E, 3.6.2E, 3.6.2aE, 3.6.3E, 3.6.4E, 3.6.5E, 3.6.5aE, 3.6.6E, 3.6.7E, 3.6.7aE, 3.6.7bE, 3.6.8E, 3.6.9E * 3.7.0E, 3.7.1E *PSIRT Evaluation:* The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal resolution channels. If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt at cisco.com for another evaluation. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html PSIRT-0353552144 On 5/3/18 12:51 AM, frederic.jutzet at sig-telecom.net wrote: > Hi, > > We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 > which have TCP port 6154 listening on all interfaces. > > Any idea what it could be ? > > #show tcp brief all > TCB Local Address Foreign Address (state) > ... > 5A529430 0.0.0.0.6154 <<<<<<<<<<<<<<<< > > > #show tcp tcb 5A529430 > Connection state is LISTEN, I/O status: 1, unread input bytes: 0 > Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 > Local host: 0.0.0.0, Local port: 6154 > Foreign host: UNKNOWN, Foreign port: 0 > Connection tableid (VRF): 1 > Maximum output segment queue size: 50 > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) > > Event Timers (current time is 0xF58354): > Timer Starts Wakeups Next > Retrans 0 0 0x0 > TimeWait 0 0 0x0 > AckHold 0 0 0x0 > SendWnd 0 0 0x0 > KeepAlive 0 0 0x0 > GiveUp 0 0 0x0 > PmtuAger 0 0 0x0 > DeadWait 0 0 0x0 > Linger 0 0 0x0 > ProcessQ 0 0 0x0 > > iss: 0 snduna: 0 sndnxt: 0 > irs: 0 rcvnxt: 0 > > sndwnd: 0 scale: 0 maxrcvwnd: 4128 > rcvwnd: 4128 scale: 0 delrcvwnd: 0 > > SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms > minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms > uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms > Status Flags: gen tcbs > Option Flags: VRF id set, keepalive running, nagle, Reuse local address > Retrans timeout > IP Precedence value : 0 > > Datagrams (max data segment is 516 bytes): > Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0 > Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second > Congestion: 0), with data: 0, total data bytes: 0 > > Packets received in fast path: 0, fast processed: 0, slow path: 0 > fast lock acquisition failures: 0, slow path: 0 > TCP Semaphore 0x5BEB9B10 FREE > > > > > > (The command "show control-plane host open-ports" is not available on > this platform/code) > > > > I also think that if it would be a local socket for internal process > communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154. > So this is listening on all interfaces, virtuals and physicals and seam > not to be for internal internal process communication. > > > Fred -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3504 bytes Desc: S/MIME Cryptographic Signature URL: From alan.buxey at gmail.com Wed May 9 17:58:54 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Wed, 9 May 2018 18:58:54 +0100 Subject: Catalyst 4500 listening on TCP 6154 on all interfaces In-Reply-To: References: <5AEA9566.7000808@sig-telecom.net> Message-ID: hi, thank-you Dario for your input and response from Cisco PSIRT - very useful and welcome. alan From stahr at mailbag.com Wed May 9 19:48:54 2018 From: stahr at mailbag.com (James Stahr) Date: Wed, 09 May 2018 14:48:54 -0500 Subject: Unusually High traffic from Akamai/Oracle - public-yum.oracle.com Message-ID: <5de062addc004e66832fa388c7543a58@mailbag.com> Hi, Since I'm not a customer of either organization, I'm reaching out to NANOG for a contact and perhaps others may also be experiencing similar symptoms over the past 3-4 weeks. The situation appears to be that customers of ours have Oracle Linux and when they attempt to download updates, their traffic goes through the roof for hours on end. While researching this phenomenon, I found this discussion which coincides with the traffic I've seen, however there is no mention of excessive traffic resulting from this "corruption" nor have their been any additional reports: https://community.oracle.com/thread/4138810 Currently, I have two customer environments which are hitting about ~2Gb/s when normally their traffic levels are nearly zero. At first I thought it was an isolated incident but then we observed the same issue with another customer. All of this traffic is coming from 23.35.204.188:80, which belongs to Akamai. Since that's somewhat of a dead end, we examined the hosts which are requesting the data from Akamai and found that they are all Oracle Linux boxes and it's a yum process on Oracle Linux which appears to be repeatedly downloading the same content for hours on end: [root at xyzzy noc]# netstat -plutan | grep :80 tcp 0 0 172.16.122.112:14272 23.35.204.188:80 ESTABLISHED 58880/python [root at xyzzy noc]# ps auxww | grep python root 41015 0.0 0.3 401940 52044 ? S Apr30 0:02 /usr/bin/python2 /usr/share/system-config-lvm/system-config-lvm.py root 58880 59.7 1.0 479680 164140 ? R 18:24 27:18 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py get-updates none I can only assume that the data being downloaded is corrupt as this multiple hour download does not consume any disk space and because the file(s) are repeatedly downloaded, the logic behind the yum routines are also at fault for 1TB of I don't expect anyone at Akamai to reach out to me since they are simply the middle man here, but I'm hoping that someone at Oracle will because the cost to Oracle for Akamai to deliver this junk traffic is not zero and I have a hard time seeing how this issue is isolated to our network. I'd also be interested to hear from anyone else who has been seeing traffic spikes from public-yum.oracle.com. -James Stahr From surfer at mauigateway.com Wed May 9 20:52:04 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 9 May 2018 13:52:04 -0700 Subject: DSL Operators Mailing List? Message-ID: <20180509135204.21BB7DD3@m0117458.ppops.net> >> I made a Facebook group for xLEC-related things. > (Not useful for those of us not on Facebook.) Whaaat??? Someone's not on FB? Because...like totally...all the cool kids are doing it! Don't you want to be one of the cool kids, too? >>> Then don't participate and move on? Awww, too bad. They're not going to let the uncool kids sit at the cool kid's high school lunch table. You'll have to sit at the nerd table for not conforming. :-) >>>>In other words, status quo ante? Yep, 'same as it ever was' (Brian Eno). scott From karsten_thomann at linfre.de Wed May 9 21:01:13 2018 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Wed, 09 May 2018 23:01:13 +0200 Subject: AW: DSL Operators Mailing List? In-Reply-To: <20180509135204.21BB7DD3@m0117458.ppops.net> References: <20180509135204.21BB7DD3@m0117458.ppops.net> Message-ID: <20180509210113.6291539.57084.21578@linfre.de> ‎If there is real interest just let me know and I'll set up a mailman for a mailing list.  I think it is the simplest solution for all...   Originalnachricht   Von: Scott Weeks Gesendet: Mittwoch, 9. Mai 2018 22:54 An: nanog at nanog.org Antwort an: surfer at mauigateway.com Betreff: Re: DSL Operators Mailing List? >> I made a Facebook group for xLEC-related things. > (Not useful for those of us not on Facebook.) Whaaat??? Someone's not on FB? Because...like totally...all the cool kids are doing it! Don't you want to be one of the cool kids, too? >>> Then don't participate and move on? Awww, too bad. They're not going to let the uncool kids sit at the cool kid's high school lunch table. You'll have to sit at the nerd table for not conforming. :-) >>>>In other words, status quo ante? Yep, 'same as it ever was' (Brian Eno). scott From Ryan.Hamel at quadranet.com Wed May 9 21:58:20 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 9 May 2018 21:58:20 +0000 Subject: Intuit - IP Block - Connection Timed Out Message-ID: <54437c56225a40009220196b6258febd@LAX-MBX01.quadranet.local> Greetings, If someone from Intuit can contact me off list, I would highly appreciate it. We have a client that is not able to access QuickBooks Online from one of our specific IP blocks. The IP for https://qbo.intuit.com/ responds to ping, but any web request results in a connection timed out. Thanks! -- Ryan Hamel ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud From colinj at gt86car.org.uk Thu May 10 07:39:08 2018 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 10 May 2018 08:39:08 +0100 Subject: Unusually High traffic from Akamai/Oracle - public-yum.oracle.com In-Reply-To: <5de062addc004e66832fa388c7543a58@mailbag.com> References: <5de062addc004e66832fa388c7543a58@mailbag.com> Message-ID: latest yum oracle linux applied ok today fine, 153mb Have not seen looking content either Colin > On 9 May 2018, at 20:48, James Stahr wrote: > > > > Hi, > > Since I'm not a customer of either organization, I'm reaching out to NANOG for a contact and perhaps others may also be experiencing similar symptoms over the past 3-4 weeks. The situation appears to be that customers of ours have Oracle Linux and when they attempt to download updates, their traffic goes through the roof for hours on end. While researching this phenomenon, I found this discussion which coincides with the traffic I've seen, however there is no mention of excessive traffic resulting from this "corruption" nor have their been any additional reports: > > https://community.oracle.com/thread/4138810 > > > Currently, I have two customer environments which are hitting about ~2Gb/s when normally their traffic levels are nearly zero. At first I thought it was an isolated incident but then we observed the same issue with another customer. All of this traffic is coming from 23.35.204.188:80, which belongs to Akamai. Since that's somewhat of a dead end, we examined the hosts which are requesting the data from Akamai and found that they are all Oracle Linux boxes and it's a yum process on Oracle Linux which appears to be repeatedly downloading the same content for hours on end: > > > [root at xyzzy noc]# netstat -plutan | grep :80 > tcp 0 0 172.16.122.112:14272 23.35.204.188:80 ESTABLISHED 58880/python > [root at xyzzy noc]# ps auxww | grep python > root 41015 0.0 0.3 401940 52044 ? S Apr30 0:02 /usr/bin/python2 /usr/share/system-config-lvm/system-config-lvm.py > root 58880 59.7 1.0 479680 164140 ? R 18:24 27:18 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py get-updates none > > I can only assume that the data being downloaded is corrupt as this multiple hour download does not consume any disk space and because the file(s) are repeatedly downloaded, the logic behind the yum routines are also at fault for 1TB of > > I don't expect anyone at Akamai to reach out to me since they are simply the middle man here, but I'm hoping that someone at Oracle will because the cost to Oracle for Akamai to deliver this junk traffic is not zero and I have a hard time seeing how this issue is isolated to our network. I'd also be interested to hear from anyone else who has been seeing traffic spikes from public-yum.oracle.com. > > > -James Stahr From matthew at walster.org Thu May 10 12:09:08 2018 From: matthew at walster.org (Matthew Walster) Date: Thu, 10 May 2018 14:09:08 +0200 Subject: Wave service providers in Hong Kong metro area In-Reply-To: <20180508095845.Horde.hbHZIp09Va5TUV0h6SjlVDE@webmail.mbay.net> References: <20180508095845.Horde.hbHZIp09Va5TUV0h6SjlVDE@webmail.mbay.net> Message-ID: On 8 May 2018 at 18:58, wrote: > Can anyone recommend wave providers on the Hong Kong area? I need to reach > between two colo facilities there. Feel free to ping me off-list. > ​Hong Kong island (e.g. REACH near Admiralty or Mega i-advantage near Chai Wan) or in the Tsuen Wan area​ (e.g. Equinix HK1 etc) or somewhere else? All the providers have waves throughout the main districts, but some are far better if it's within the boundaries of their specific service areas. I've used Wharf T&T in the past, now known as WTT HK, for waves between office buildings in Central / Admiralty and colo in Tseung Kwan O. They were very fast to install, reasonably priced (for cross-harbour circuits at least) and were happy to handle arrangement of wayleaves without too much hand holding. M From marco at paesani.it Thu May 10 13:14:28 2018 From: marco at paesani.it (Marco Paesani) Date: Thu, 10 May 2018 13:14:28 +0000 Subject: Contact Phase Layer AS51852 Message-ID: Hi, I need contact with AS51852 about peering session at DE-CIX and AMS-IX. Thanks ! Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From tom at cloudflare.com Thu May 10 17:49:52 2018 From: tom at cloudflare.com (Tom Paseka) Date: Thu, 10 May 2018 12:49:52 -0500 Subject: Wave service providers in Hong Kong metro area In-Reply-To: References: <20180508095845.Horde.hbHZIp09Va5TUV0h6SjlVDE@webmail.mbay.net> Message-ID: HKBN are great, highly recommend them Traxcomm (owned by the MTR/subways) Towngas (fiber in the natural gas lines) Superloop - new entrant. good guys. On Thu, May 10, 2018 at 7:09 AM, Matthew Walster wrote: > On 8 May 2018 at 18:58, wrote: > > > Can anyone recommend wave providers on the Hong Kong area? I need to > reach > > between two colo facilities there. Feel free to ping me off-list. > > > > ​Hong Kong island (e.g. REACH near Admiralty or Mega i-advantage near Chai > Wan) or in the Tsuen Wan area​ (e.g. Equinix HK1 etc) or somewhere else? > All the providers have waves throughout the main districts, but some are > far better if it's within the boundaries of their specific service areas. > > I've used Wharf T&T in the past, now known as WTT HK, for waves between > office buildings in Central / Admiralty and colo in Tseung Kwan O. They > were very fast to install, reasonably priced (for cross-harbour circuits at > least) and were happy to handle arrangement of wayleaves without too much > hand holding. > > M > From ryangard at gmail.com Fri May 11 02:35:24 2018 From: ryangard at gmail.com (Ryan Gard) Date: Thu, 10 May 2018 22:35:24 -0400 Subject: Apple Contact Message-ID: Hello, If someone from Apple could contact me off list. Need to resolve some Geo-location issues. Thanks! -- Ryan Gard From jonathan.roach at oracle.com Thu May 10 21:02:43 2018 From: jonathan.roach at oracle.com (Jonathan Roach) Date: Thu, 10 May 2018 22:02:43 +0100 Subject: Unusually High traffic from Akamai/Oracle - public-yum.oracle.com In-Reply-To: <5de062addc004e66832fa388c7543a58@mailbag.com> References: <5de062addc004e66832fa388c7543a58@mailbag.com> Message-ID: <89322675-0bbe-d080-8b45-a70d684751f6@oracle.com> Hi James, I've forwarded your email to the yum.oracle.com team internally; they've acknowledged receipt and asked me to let the list know. Apologies for the delay - I only noticed this thread today. Kind regards, Jon On 09/05/18 20:48, James Stahr wrote: > > > Hi, > > Since I'm not a customer of either organization, I'm reaching out to > NANOG for a contact and perhaps others may also be experiencing similar > symptoms over the past 3-4 weeks.  The situation appears to be that > customers of ours have Oracle Linux and when they attempt to download > updates, their traffic goes through the roof for hours on end.  While > researching this phenomenon, I found this discussion which coincides > with the traffic I've seen, however there is no mention of excessive > traffic resulting from this "corruption" nor have their been any > additional reports: > > https://community.oracle.com/thread/4138810 > > > Currently, I have two customer environments which are hitting about > ~2Gb/s when normally their traffic levels are nearly zero.   At first I > thought it was an isolated incident but then we observed the same issue > with another customer.  All of this traffic is coming from > 23.35.204.188:80, which belongs to Akamai.  Since that's somewhat of a > dead end, we examined the hosts which are requesting the data from > Akamai and found that they are all Oracle Linux boxes and it's a yum > process on Oracle Linux which appears to be repeatedly downloading the > same content for hours on end: > > > [root at xyzzy noc]# netstat -plutan | grep :80 > tcp        0      0 172.16.122.112:14272        23.35.204.188:80         >    ESTABLISHED 58880/python > [root at xyzzy noc]# ps auxww | grep python > root     41015  0.0  0.3 401940 52044 ?        S    Apr30   0:02 > /usr/bin/python2 /usr/share/system-config-lvm/system-config-lvm.py > root     58880 59.7  1.0 479680 164140 ?       R    18:24  27:18 > /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py > get-updates none > > I can only assume that the data being downloaded is corrupt as this > multiple hour download does not consume any disk space and because the > file(s) are repeatedly downloaded, the logic behind the yum routines are > also at fault for 1TB of > > I don't expect anyone at Akamai to reach out to me since they are simply > the middle man here, but I'm hoping that someone at Oracle will because > the cost to Oracle for Akamai to deliver this junk traffic is not zero > and I have a hard time seeing how this issue is isolated to our network. >  I'd also be interested to hear from anyone else who has been seeing > traffic spikes from public-yum.oracle.com. > > > -James Stahr -- From cscora at apnic.net Fri May 11 18:03:13 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 May 2018 04:03:13 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180511180313.2C7E0C450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 12 May, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 699099 Prefixes after maximum aggregation (per Origin AS): 269055 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 336810 Total ASes present in the Internet Routing Table: 60733 Prefixes per ASN: 11.51 Origin-only ASes present in the Internet Routing Table: 52477 Origin ASes announcing only one prefix: 22967 Transit ASes present in the Internet Routing Table: 8256 Transit-only ASes present in the Internet Routing Table: 269 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 51 Number of instances of unregistered ASNs: 51 Number of 32-bit ASNs allocated by the RIRs: 22508 Number of 32-bit ASNs visible in the Routing Table: 18184 Prefixes from 32-bit ASNs in the Routing Table: 75633 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 309 Number of addresses announced to Internet: 2859146114 Equivalent to 170 /8s, 107 /16s and 27 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 233007 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 191299 Total APNIC prefixes after maximum aggregation: 54176 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 190152 Unique aggregates announced from the APNIC address blocks: 77850 APNIC Region origin ASes present in the Internet Routing Table: 8802 APNIC Prefixes per ASN: 21.60 APNIC Region origin ASes announcing only one prefix: 2465 APNIC Region transit ASes present in the Internet Routing Table: 1312 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3762 Number of APNIC addresses announced to Internet: 766828290 Equivalent to 45 /8s, 180 /16s and 223 /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: 208203 Total ARIN prefixes after maximum aggregation: 99080 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209083 Unique aggregates announced from the ARIN address blocks: 98841 ARIN Region origin ASes present in the Internet Routing Table: 18167 ARIN Prefixes per ASN: 11.51 ARIN Region origin ASes announcing only one prefix: 6708 ARIN Region transit ASes present in the Internet Routing Table: 1799 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2349 Number of ARIN addresses announced to Internet: 1105293088 Equivalent to 65 /8s, 225 /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: 190744 Total RIPE prefixes after maximum aggregation: 91945 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 186665 Unique aggregates announced from the RIPE address blocks: 111183 RIPE Region origin ASes present in the Internet Routing Table: 25184 RIPE Prefixes per ASN: 7.41 RIPE Region origin ASes announcing only one prefix: 11419 RIPE Region transit ASes present in the Internet Routing Table: 3505 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6978 Number of RIPE addresses announced to Internet: 715758464 Equivalent to 42 /8s, 169 /16s and 155 /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: 90142 Total LACNIC prefixes after maximum aggregation: 19844 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 91536 Unique aggregates announced from the LACNIC address blocks: 41016 LACNIC Region origin ASes present in the Internet Routing Table: 7139 LACNIC Prefixes per ASN: 12.82 LACNIC Region origin ASes announcing only one prefix: 1995 LACNIC Region transit ASes present in the Internet Routing Table: 1314 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 34 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4677 Number of LACNIC addresses announced to Internet: 172818912 Equivalent to 10 /8s, 77 /16s and 1 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18658 Total AfriNIC prefixes after maximum aggregation: 3963 AfriNIC Deaggregation factor: 4.71 Prefixes being announced from the AfriNIC address blocks: 21354 Unique aggregates announced from the AfriNIC address blocks: 7653 AfriNIC Region origin ASes present in the Internet Routing Table: 1144 AfriNIC Prefixes per ASN: 18.67 AfriNIC Region origin ASes announcing only one prefix: 379 AfriNIC Region transit ASes present in the Internet Routing Table: 234 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 418 Number of AfriNIC addresses announced to Internet: 97981184 Equivalent to 5 /8s, 215 /16s and 19 /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 5397 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4395 419 431 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2907 11137 792 KIXS-AS-KR Korea Telecom, KR 7552 2835 1154 70 VIETEL-AS-AP Viettel Group, VN 9829 2812 1498 543 BSNL-NIB National Internet Backbone, IN 9394 2622 4922 25 CTTNET China TieTong Telecommunications 45899 2528 1574 160 VNPT-AS-VN VNPT Corp, VN 17974 2294 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2191 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2101 417 206 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3386 1323 84 SHAW - Shaw Communications Inc., CA 22773 3288 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2101 2508 451 CHARTER-NET-HKY-NC - Charter Communicat 16509 2097 4687 662 AMAZON-02 - Amazon.com, Inc., US 11492 2062 241 436 CABLEONE - CABLE ONE, INC., US 30036 1972 339 175 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1967 5070 605 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 1779 873 1267 AKAMAI-AS - Akamai Technologies, Inc., 7018 1714 20216 1257 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4113 1519 500 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2646 706 1943 AKAMAI-ASN1, US 8551 2076 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2043 1876 708 ROSTELECOM-AS, RU 34984 2019 334 485 TELLCOM-AS, TR 9121 1888 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 8402 1246 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 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 8151 4549 3355 577 Uninet S.A. de C.V., MX 10620 3585 540 251 Telmex Colombia S.A., CO 11830 2647 369 78 Instituto Costarricense de Electricidad 6503 1599 437 53 Axtel, S.A.B. de C.V., MX 7303 1513 1025 187 Telecom Argentina S.A., AR 28573 1034 2252 185 CLARO S.A., BR 3816 1008 505 123 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 971 377 31 Telefonica del Peru S.A.A., PE 11172 927 126 85 Alestra, S. de R.L. de C.V., MX 18881 909 1074 29 TELEF�NICA BRASIL S.A, BR 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 1183 396 45 LINKdotNET-AS, EG 37611 839 107 9 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 702 1412 42 ETISALAT-MISR, EG 8452 693 1730 18 TE-AS TE-AS, EG 24835 639 850 15 RAYA-AS, EG 37492 453 376 82 ORANGE-, TN 29571 436 68 10 ORANGE-COTE-IVOIRE, CI 15399 363 35 7 WANANCHI-, KE 37342 362 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5397 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4549 3355 577 Uninet S.A. de C.V., MX 7545 4395 419 431 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4113 1519 500 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3585 540 251 Telmex Colombia S.A., CO 6327 3386 1323 84 SHAW - Shaw Communications Inc., CA 22773 3288 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2907 11137 792 KIXS-AS-KR Korea Telecom, KR 7552 2835 1154 70 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4549 3972 Uninet S.A. de C.V., MX 7545 4395 3964 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4113 3613 UNI2-AS, ES 10620 3585 3334 Telmex Colombia S.A., CO 6327 3386 3302 SHAW - Shaw Communications Inc., CA 22773 3288 3141 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2835 2765 VIETEL-AS-AP Viettel Group, VN 9394 2622 2597 CTTNET China TieTong Telecommunications Corpora 11830 2647 2569 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.232.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.233.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU 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.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 36.50.254.0/23 48964 ENTERRA-AS, UA 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:37 /11:100 /12:288 /13:564 /14:1094 /15:1904 /16:13394 /17:7871 /18:13718 /19:25269 /20:39354 /21:45196 /22:87028 /23:70237 /24:390744 /25:847 /26:650 /27:649 /28:36 /29:20 /30:17 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3174 3386 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 12479 2892 4113 UNI2-AS, ES 22773 2544 3288 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2060 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1995 2647 Instituto Costarricense de Electricidad y Telec 11492 1804 2062 CABLEONE - CABLE ONE, INC., US 30036 1724 1972 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1604 3585 Telmex Colombia S.A., CO 8551 1538 2076 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1580 2:850 4:19 5:2842 6:65 7:1 8:1125 12:1870 13:186 14:1753 15:28 16:3 17:205 18:65 20:49 21:8 23:2631 24:2219 25:2 27:2362 31:1992 32:88 35:27 36:505 37:2803 38:1457 39:262 40:119 41:3134 42:572 43:1930 44:114 45:4460 46:3061 47:204 49:1317 50:1059 51:307 52:1021 54:369 55:4 56:12 57:42 58:1601 59:991 60:431 61:2166 62:1827 63:1801 64:5039 65:2216 66:4676 67:2417 68:1141 69:3200 70:1148 71:564 72:2126 74:2724 75:413 76:450 77:1529 78:1694 79:1862 80:1514 81:1409 82:1075 83:782 84:1058 85:2037 86:586 87:1316 88:926 89:2324 90:209 91:6351 92:1200 93:2374 94:2401 95:2807 96:659 97:358 98:941 99:133 100:81 101:1282 102:60 103:17680 104:3598 105:239 106:662 107:1874 108:704 109:2692 110:1611 111:1778 112:1276 113:1265 114:1118 115:1633 116:1648 117:1737 118:2194 119:1661 120:978 121:1051 122:2444 123:1802 124:1427 125:1906 128:1022 129:643 130:455 131:1600 132:665 133:194 134:1019 135:225 136:472 137:556 138:1924 139:580 140:393 141:704 142:822 143:978 144:796 145:462 146:1180 147:697 148:1597 149:711 150:724 151:1057 152:768 153:312 154:1066 155:765 156:938 157:792 158:659 159:1739 160:908 161:761 162:2579 163:563 164:1056 165:1584 166:448 167:1407 168:3084 169:808 170:3707 171:434 172:1054 173:1998 174:906 175:769 176:1889 177:3998 178:2450 179:1189 180:2249 181:2189 182:2415 183:1152 184:1001 185:13458 186:3594 187:2391 188:2812 189:2031 190:8078 191:1462 192:9830 193:5915 194:4761 195:3960 196:2538 197:1452 198:5545 199:5903 200:7406 201:5013 202:10412 203:10182 204:4572 205:2896 206:3099 207:3203 208:3992 209:3953 210:4044 211:2111 212:3035 213:2736 214:966 215:60 216:5920 217:2127 218:909 219:628 220:1763 221:985 222:1039 223:1251 End of report From ggiesen+nanog at giesen.me Fri May 11 21:15:09 2018 From: ggiesen+nanog at giesen.me (=?utf-8?q?Gary_T=2E_Giesen?=) Date: Fri, 11 May 2018 17:15:09 -0400 Subject: Level 3 Looking Glass Broken Message-ID: <6e76-5af60800-3-49112800@97288033> I'm seeing issues with Level 3's looking glass (https://lookingglass.level3.net) since they rolled out the new one with the CenturyLink branding. Any query results in "Invalid usage. POST variable not set.". Also, the radio buttons under the "Information Category" selection allow more than one selection (and no way of deselecting anything). I tried opening a ticket L3 under one of my transit circuits and was told that the NOC doesn't deal with it, and I should talk to our account team (as fun as that sounds, I'd rather stick my head in a blender). Anyone on this list have any clout inside L3 to get this fixed? Cheers, GTG From ggiesen+nanog at giesen.me Sat May 12 13:23:46 2018 From: ggiesen+nanog at giesen.me (=?utf-8?q?Gary_T=2E_Giesen?=) Date: Sat, 12 May 2018 09:23:46 -0400 Subject: =?utf-8?q?RE=3A?= Level 3 Looking Glass Broken In-Reply-To: Message-ID: <4339-5af6eb00-3-1e151d60@210845534> It's working now, thanks all for the assist! Cheers, GTG On Friday, May 11, 2018 18:15 EDT, "Don Fanning" wrote:  Maybe try the team reference in the apache debug of the looking glass server: DL-SystemsAndTools at Level3.com -----Original Message----- From: NANOG On Behalf Of Gary T. Giesen via NANOG Sent: Friday, May 11, 2018 02:15 PM To: nanog at nanog.org Subject: Level 3 Looking Glass Broken I'm seeing issues with Level 3's looking glass (https://lookingglass.level3.net) since they rolled out the new one with the CenturyLink branding. Any query results in "Invalid usage. POST variable not set.". Also, the radio buttons under the "Information Category" selection allow more than one selection (and no way of deselecting anything). I tried opening a ticket L3 under one of my transit circuits and was told that the NOC doesn't deal with it, and I should talk to our account team (as fun as that sounds, I'd rather stick my head in a blender). Anyone on this list have any clout inside L3 to get this fixed? Cheers, GTG     From karsten_thomann at linfre.de Sat May 12 18:02:03 2018 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Sat, 12 May 2018 11:02:03 -0700 (PDT) Subject: AW: DSL Operators Mailing List? In-Reply-To: <20180509210113.6291539.57084.21578@linfre.de> References: <20180509135204.21BB7DD3@m0117458.ppops.net> <20180509210113.6291539.57084.21578@linfre.de> Message-ID: <1674531.IrhRQiIvjZ@linne> Until now I've got only four replies... I don't think it justifies the effort to operate a mailing list. There should be a bit more interest before I would set it up. Am Mittwoch, 9. Mai 2018, 23:01:13 schrieb Karsten Thomann via NANOG: > ?If there is real interest just let me know and I'll set up a mailman for a > mailing list. > > I think it is the simplest solution for all... > > Originalnachricht > Von: Scott Weeks > Gesendet: Mittwoch, 9. Mai 2018 22:54 > An: nanog at nanog.org > Antwort an: surfer at mauigateway.com > Betreff: Re: DSL Operators Mailing List? > > >> I made a Facebook group for xLEC-related things. > > > > (Not useful for those of us not on Facebook.) > > Whaaat??? Someone's not on FB? Because...like > totally...all the cool kids are doing it! Don't > you want to be one of the cool kids, too? > > >>> Then don't participate and move on? > > Awww, too bad. They're not going to let the uncool > kids sit at the cool kid's high school lunch table. > You'll have to sit at the nerd table for not > conforming. :-) > > >>>>In other words, status quo ante? > > Yep, 'same as it ever was' (Brian Eno). > > scott From george.herbert at gmail.com Mon May 14 07:43:25 2018 From: george.herbert at gmail.com (George William Herbert) Date: Mon, 14 May 2018 00:43:25 -0700 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent Message-ID: This is likely bad enough operators need to pay attention. @seecurity tweeted: "We'll publish critical vulnerabilities in PGP/GPG and S/MIME email encryption on 2018-05-15 07:00 UTC. They might reveal the plaintext of encrypted emails, including encrypted emails sent in the past. #efail 1/4" Thread starts here: https://twitter.com/seecurity/status/995906576170053633?s=21 I have no particular insight into what it is other than presuming from thread that decryption can be tricked to do bad things. They recommend temporary disabling downthread: "There are currently no reliable fixes for the vulnerability. If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now. Also read @EFF’s blog post on this issue: eff.org/deeplinks/2018… #efail 2/4" -george Sent from my iPhone From ops.lists at gmail.com Mon May 14 08:17:50 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 14 May 2018 13:47:50 +0530 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: References: Message-ID: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> Seems to be a set of MUA bugs that are being overblown and hyped up. TL;DR = Don't use HTML email with some mail clients when sending pgp encrypted mail. https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html --srs On 14/05/18, 1:15 PM, "NANOG on behalf of George William Herbert" wrote: This is likely bad enough operators need to pay attention. @seecurity tweeted: "We'll publish critical vulnerabilities in PGP/GPG and S/MIME email encryption on 2018-05-15 07:00 UTC. They might reveal the plaintext of encrypted emails, including encrypted emails sent in the past. #efail 1/4" Thread starts here: https://twitter.com/seecurity/status/995906576170053633?s=21 I have no particular insight into what it is other than presuming from thread that decryption can be tricked to do bad things. They recommend temporary disabling downthread: "There are currently no reliable fixes for the vulnerability. If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now. Also read @EFF’s blog post on this issue: eff.org/deeplinks/2018… #efail 2/4" -george Sent from my iPhone From ryan at finnesey.com Mon May 14 15:11:38 2018 From: ryan at finnesey.com (Ryan Finnesey) Date: Mon, 14 May 2018 15:11:38 +0000 Subject: Donuts Inc Message-ID: Good Morning Is there someone monitoring this list from Donuts Inc? I would appreciate them contacting me off-list I have a few technical questions about their EPP interfaces. Cheers Ryan From colton.conor at gmail.com Mon May 14 17:45:39 2018 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 14 May 2018 12:45:39 -0500 Subject: USB Ethernet Adapters Message-ID: Our new laptops like most do not have an Ethernet adapter build in as they are too slim. What USB to Ethernet adapter do you recommend and why? Ideally it would be compatible with Windows 10, and have the ability to set speed, duplex and VLAN IDs if possible. From tj at pcguys.us Mon May 14 17:57:50 2018 From: tj at pcguys.us (TJ Trout) Date: Mon, 14 May 2018 10:57:50 -0700 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: https://www.amazon.com/gp/product/B00BBD7NFU/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 and https://www.amazon.com/gp/product/B00X4S587K/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 have both been working great for me on windows ten using an xps 13 TJ On Mon, May 14, 2018 at 10:45 AM, Colton Conor wrote: > Our new laptops like most do not have an Ethernet adapter build in as they > are too slim. What USB to Ethernet adapter do you recommend and why? > Ideally it would be compatible with Windows 10, and have the ability to set > speed, duplex and VLAN IDs if possible. > From hf0002+nanog at uah.edu Mon May 14 18:04:05 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Mon, 14 May 2018 13:04:05 -0500 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: We have been recommending the AmazonBasics ones for this. The reason is because they are cheap and reliable, and everyone has Amazon Prime. I have not tested the VLAN functionality under Windows, but the adapter itself works fine under Windows, and the VLAN functionality works fine under RHEL. On Mon, May 14, 2018 at 12:57 PM TJ Trout wrote: > > https://www.amazon.com/gp/product/B00BBD7NFU/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 > > and > > > https://www.amazon.com/gp/product/B00X4S587K/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 > > have both been working great for me on windows ten using an xps 13 > > TJ > > On Mon, May 14, 2018 at 10:45 AM, Colton Conor > wrote: > > > Our new laptops like most do not have an Ethernet adapter build in as > they > > are too slim. What USB to Ethernet adapter do you recommend and why? > > Ideally it would be compatible with Windows 10, and have the ability to > set > > speed, duplex and VLAN IDs if possible. > > > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From dovid at telecurve.com Mon May 14 18:24:25 2018 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 14 May 2018 14:24:25 -0400 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: I would stay away from the Amazon Basics 1 gig device. After a while of using it the metal housing slides out and it falls apart. On Mon, May 14, 2018 at 2:04 PM, Hunter Fuller wrote: > We have been recommending the AmazonBasics ones for this. The reason is > because they are cheap and reliable, and everyone has Amazon Prime. I have > not tested the VLAN functionality under Windows, but the adapter itself > works fine under Windows, and the VLAN functionality works fine under RHEL. > > On Mon, May 14, 2018 at 12:57 PM TJ Trout wrote: > > > > > https://www.amazon.com/gp/product/B00BBD7NFU/ref=oh_aui_ > search_detailpage?ie=UTF8&psc=1 > > > > and > > > > > > https://www.amazon.com/gp/product/B00X4S587K/ref=oh_aui_ > search_detailpage?ie=UTF8&psc=1 > > > > have both been working great for me on windows ten using an xps 13 > > > > TJ > > > > On Mon, May 14, 2018 at 10:45 AM, Colton Conor > > wrote: > > > > > Our new laptops like most do not have an Ethernet adapter build in as > > they > > > are too slim. What USB to Ethernet adapter do you recommend and why? > > > Ideally it would be compatible with Windows 10, and have the ability to > > set > > > speed, duplex and VLAN IDs if possible. > > > > > > -- > > -- > Hunter Fuller > Network Engineer > VBH Annex B-5 > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Systems and Infrastructure > From nate at santafe.edu Mon May 14 18:47:28 2018 From: nate at santafe.edu (Nate Metheny) Date: Mon, 14 May 2018 12:47:28 -0600 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: <0d9b6e6b-735f-5156-1750-09ba6a8085d1@santafe.edu> I have had very good success with PC/Mac/Linux with these: https://www.amazon.com/Belkin-USB-Ethernet-Adapter-F4U047bt/dp/B00E9655LU and the USB 3 counterpart: https://www.amazon.com/Belkin-Gigabit-Ethernet-Adapter-B2B048/dp/B00BE67N3Q On 05/14/2018 11:45 AM, Colton Conor wrote: > Our new laptops like most do not have an Ethernet adapter build in as they > are too slim. What USB to Ethernet adapter do you recommend and why? > Ideally it would be compatible with Windows 10, and have the ability to set > speed, duplex and VLAN IDs if possible. > -- .==== === -- - -- - - - - - ---. | Nate Metheny Director, Technology | | Santa Fe Institute office 505.946.2730 | | cell 505.930.9390 fax 505.982.0565 | | http://www.santafe.edu nate at santafe.edu | `--- - -- - - -- - = == ===' -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3804 bytes Desc: S/MIME Cryptographic Signature URL: From karsten.elfenbein at gmail.com Mon May 14 19:56:34 2018 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Mon, 14 May 2018 21:56:34 +0200 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: Hi, as you want to connect your laptop I would recommend something like a usb3 hub with ethernet. https://www.amazon.com/Anker-Aluminum-Portable-Gigabit-Ethernet/dp/B00PC07T02/ There are also displays with usb3 type-c connector that have an ethernet port. Karsten 2018-05-14 19:45 GMT+02:00 Colton Conor : > Our new laptops like most do not have an Ethernet adapter build in as they > are too slim. What USB to Ethernet adapter do you recommend and why? > Ideally it would be compatible with Windows 10, and have the ability to set > speed, duplex and VLAN IDs if possible. From meirea at charterschoolit.com Mon May 14 20:53:53 2018 From: meirea at charterschoolit.com (Mario Eirea) Date: Mon, 14 May 2018 20:53:53 +0000 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: https://www.amazon.com/gp/product/B013G4C8RE USB3 full gig with VLAN support in Windows. Install Win10Pcap if you want vlan support in wireshark. -----Original Message----- From: NANOG On Behalf Of Colton Conor Sent: Monday, May 14, 2018 1:46 PM To: NANOG Subject: USB Ethernet Adapters Our new laptops like most do not have an Ethernet adapter build in as they are too slim. What USB to Ethernet adapter do you recommend and why? Ideally it would be compatible with Windows 10, and have the ability to set speed, duplex and VLAN IDs if possible. From colton.conor at gmail.com Tue May 15 01:20:10 2018 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 14 May 2018 20:20:10 -0500 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: Thanks for the responses so far. I am surprised to see the wide array of responses. A couple of more things: 1. I like the ones that have lights on the Ethernet port so you can see if the device is up/down. I find that critical as we go to a lot of sites where we don't know if the cable is good/bad, so a indication on the lights is critical. 2. Techs are constantly doing speedtest.net tests on 1Gbps Ethernet connections, so ideally an adapter that can constantly push the 1Gbps speeds is ideally. Seems that most of these adapters use a common chipset. Anyone done research on which chipset is the best, and why? On Mon, May 14, 2018 at 12:45 PM, Colton Conor wrote: > Our new laptops like most do not have an Ethernet adapter build in as they > are too slim. What USB to Ethernet adapter do you recommend and why? > Ideally it would be compatible with Windows 10, and have the ability to set > speed, duplex and VLAN IDs if possible. > From brad at shub-internet.org Tue May 15 01:53:27 2018 From: brad at shub-internet.org (Brad Knowles) Date: Mon, 14 May 2018 20:53:27 -0500 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: On May 14, 2018, at 8:20 PM, Colton Conor wrote: > 1. I like the ones that have lights on the Ethernet port so you can see if > the device is up/down. I find that critical as we go to a lot of sites > where we don't know if the cable is good/bad, so a indication on the lights > is critical. If you're going to do network testing, then an NETool is recommended. That's a complete Linux network testing system in what looks like a larger-than-usual dongle. Beyond that, if you're using an older Mac, then in my experience Apple's Thunderbolt 2/GigE adapter can't be beat. I do not yet have enough experience with USB, or USB-C, or Thunderbolt 3 adapters to be able to make any recommendations. -- Brad Knowles -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: Message signed with OpenPGP URL: From cma at cmadams.net Tue May 15 02:03:16 2018 From: cma at cmadams.net (Chris Adams) Date: Mon, 14 May 2018 21:03:16 -0500 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: <20180515020316.GA14177@cmadams.net> Once upon a time, Brad Knowles said: > If you're going to do network testing, then an NETool is recommended. That's a complete Linux network testing system in what looks like a larger-than-usual dongle. I like the Pockethernet for a portable diagnostic tool (haven't tried the Netool). -- Chris Adams From meirea at charterschoolit.com Tue May 15 02:35:00 2018 From: meirea at charterschoolit.com (Mario Eirea) Date: Tue, 15 May 2018 02:35:00 +0000 Subject: USB Ethernet Adapters In-Reply-To: References: , Message-ID: My recommendation was based on the Realtek RTL8153 chipset. It's the only USB chip I had found at the time that did VLANs and full gigabit, in Windows. I have had this for a while now, I would hope there are more things on the market. -ME ________________________________ From: NANOG on behalf of Colton Conor Sent: Monday, May 14, 2018 9:20 PM To: NANOG Subject: Re: USB Ethernet Adapters Thanks for the responses so far. I am surprised to see the wide array of responses. A couple of more things: 1. I like the ones that have lights on the Ethernet port so you can see if the device is up/down. I find that critical as we go to a lot of sites where we don't know if the cable is good/bad, so a indication on the lights is critical. 2. Techs are constantly doing speedtest.net tests on 1Gbps Ethernet connections, so ideally an adapter that can constantly push the 1Gbps speeds is ideally. Seems that most of these adapters use a common chipset. Anyone done research on which chipset is the best, and why? On Mon, May 14, 2018 at 12:45 PM, Colton Conor wrote: > Our new laptops like most do not have an Ethernet adapter build in as they > are too slim. What USB to Ethernet adapter do you recommend and why? > Ideally it would be compatible with Windows 10, and have the ability to set > speed, duplex and VLAN IDs if possible. > From meirea at charterschoolit.com Tue May 15 06:47:27 2018 From: meirea at charterschoolit.com (Mario Eirea) Date: Tue, 15 May 2018 06:47:27 +0000 Subject: WiFi Technical Book Recommendations Message-ID: Salutations Looking for recommendations on books with a deepdive of WiFi infrastructure, protocol layout, best practices, etc. Hopefully including the newest specs. Input would be greatly appreciated. Thanks -ME Sent from Nine From labguy at gmail.com Tue May 15 07:16:03 2018 From: labguy at gmail.com (Troy Martin) Date: Tue, 15 May 2018 01:16:03 -0600 Subject: WiFi Technical Book Recommendations In-Reply-To: References: Message-ID: <6E946954-AD80-4E41-B32B-18E60D23A588@gmail.com> A series of 4 books from CWNP.com offers a vendor neutral perspective on of the Wi-Fi protocol and best practices. CWNA - “Wi-Fi 101” CWSP - Wi-Fi security deep dive CWDP - Wi-Fi design best practices CWAP - Wi-Fi protocol analysis deep dive or “the one ring to rule them all” Hope this helps! Kindest regards, -- Troy Martin > On May 15, 2018, at 12:47 AM, Mario Eirea wrote: > > Salutations > > Looking for recommendations on books with a deepdive of WiFi infrastructure, protocol layout, best practices, etc. Hopefully including the newest specs. Input would be greatly appreciated. > > Thanks > -ME > > Sent from Nine > From jbothe at me.com Tue May 15 09:00:46 2018 From: jbothe at me.com (JASON BOTHE) Date: Tue, 15 May 2018 04:00:46 -0500 Subject: WiFi Technical Book Recommendations In-Reply-To: <6E946954-AD80-4E41-B32B-18E60D23A588@gmail.com> References: <6E946954-AD80-4E41-B32B-18E60D23A588@gmail.com> Message-ID: <940E235B-ECD2-46F4-8495-D11EFBD3E2F9@me.com> Not quite a book in the paperback sense but George Stefanick’s site is worth having a look at. It’s full of good info. www.my80211.com J~ > On May 15, 2018, at 02:16, Troy Martin wrote: > > A series of 4 books from CWNP.com offers a vendor neutral perspective on > of the Wi-Fi protocol and best practices. > > CWNA - “Wi-Fi 101” > CWSP - Wi-Fi security deep dive > CWDP - Wi-Fi design best practices > CWAP - Wi-Fi protocol analysis deep dive or “the one ring to rule them all” > > Hope this helps! > > Kindest regards, > > -- > Troy Martin > > >> On May 15, 2018, at 12:47 AM, Mario Eirea wrote: >> >> Salutations >> >> Looking for recommendations on books with a deepdive of WiFi infrastructure, protocol layout, best practices, etc. Hopefully including the newest specs. Input would be greatly appreciated. >> >> Thanks >> -ME >> >> Sent from Nine >> From rsk at gsp.org Tue May 15 09:34:31 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 15 May 2018 05:34:31 -0400 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> Message-ID: <20180515093431.GB13432@gsp.org> On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: > TL;DR = Don't use HTML email [snip] That's enough right there. HTML markup in email is used exclusively by three kinds of people: (1) ignorant newbies who don't know any better (2) ineducable morons who refuse to learn (3) spammers. There are no exceptions. ---rsk From brandon at rd.bbc.co.uk Tue May 15 09:42:31 2018 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 15 May 2018 10:42:31 +0100 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: <20180515094231.GA23124@sunf10.rd.bbc.co.uk> On Tue May 15, 2018 at 05:34:31AM -0400, Rich Kulawiec wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: > > TL;DR = Don't use HTML email [snip] > > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. and phishers/exploiters. HTML markup in email is used exclusively by four kinds of people brandon From Brian at ampr.org Tue May 15 09:59:00 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 15 May 2018 02:59:00 -0700 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: <20180515095900.GA43153@meow.BKantor.net> On Tue, May 15, 2018 at 05:34:31AM -0400, Rich Kulawiec wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: > > TL;DR = Don't use HTML email [snip] > > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. > > ---rsk Ah, if it only were those. But the infestation has spread; nearly every corporate communication these days is polluted by HTML, with a very high percentage of that containing no content other than hyperlinks that say, in one form or another, "click on this link to read your message." Banks especially. I imagine some fool told them this improves security, and they were stupid enough to believe it. - Brian From bjorn at mork.no Tue May 15 12:13:17 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 15 May 2018 14:13:17 +0200 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515095900.GA43153@meow.BKantor.net> (Brian Kantor's message of "Tue, 15 May 2018 02:59:00 -0700") References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> <20180515095900.GA43153@meow.BKantor.net> Message-ID: <87vabp86ci.fsf@miraculix.mork.no> Brian Kantor writes: > On Tue, May 15, 2018 at 05:34:31AM -0400, Rich Kulawiec wrote: >> On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: >> > TL;DR = Don't use HTML email [snip] >> >> That's enough right there. HTML markup in email is used exclusively >> by three kinds of people: (1) ignorant newbies who don't know any >> better (2) ineducable morons who refuse to learn (3) spammers. >> There are no exceptions. >> >> ---rsk > > Ah, if it only were those. But the infestation has spread; nearly > every corporate communication these days is polluted by HTML, with > a very high percentage of that containing no content other than > hyperlinks that say, in one form or another, "click on this link > to read your message." I don't see any contradiction here. > Banks especially. All three combined. Bjørn From nanog at ics-il.net Tue May 15 12:43:35 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 15 May 2018 07:43:35 -0500 (CDT) Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: References: Message-ID: <240538927.8145.1526388210820.JavaMail.mhammett@ThunderFuck> Encrypted e-mail is so incredibly niche, this won't affect almost everyone. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "George William Herbert" To: nanog at nanog.org Sent: Monday, May 14, 2018 2:43:25 AM Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent This is likely bad enough operators need to pay attention. @seecurity tweeted: "We'll publish critical vulnerabilities in PGP/GPG and S/MIME email encryption on 2018-05-15 07:00 UTC. They might reveal the plaintext of encrypted emails, including encrypted emails sent in the past. #efail 1/4" Thread starts here: https://twitter.com/seecurity/status/995906576170053633?s=21 I have no particular insight into what it is other than presuming from thread that decryption can be tricked to do bad things. They recommend temporary disabling downthread: "There are currently no reliable fixes for the vulnerability. If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now. Also read @EFF’s blog post on this issue: eff.org/deeplinks/2018… #efail 2/4" -george Sent from my iPhone From nanog at ics-il.net Tue May 15 12:44:20 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 15 May 2018 07:44:20 -0500 (CDT) Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: <1471792172.8148.1526388258786.JavaMail.mhammett@ThunderFuck> Do kids often go on your lawn as well? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Rich Kulawiec" To: nanog at nanog.org Sent: Tuesday, May 15, 2018 4:34:31 AM Subject: Re: Email security: PGP/GPG & S/MIME vulnerability drop imminent On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: > TL;DR = Don't use HTML email [snip] That's enough right there. HTML markup in email is used exclusively by three kinds of people: (1) ignorant newbies who don't know any better (2) ineducable morons who refuse to learn (3) spammers. There are no exceptions. ---rsk From list at satchell.net Tue May 15 13:00:03 2018 From: list at satchell.net (Stephen Satchell) Date: Tue, 15 May 2018 06:00:03 -0700 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: On 05/15/2018 02:34 AM, Rich Kulawiec wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: >> TL;DR = Don't use HTML email [snip] > > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. Yes, there are exceptions. Particularly, chemists (and chemical engineers) and physicists who need to embed formulas into their e-mail. They use HTML because it's fast and easy, instead of using the preferred method of building a PDF and sending that. (I had a long, unfruitful argument with my brother the chem engineer at the time my mail server rejected all incoming HTML mail. I had to change.) Another exception is that most webmail is HTML and plaintext in MIME format. I get around the problem of triggering code in Thunderbird by only using the plain text view, dropping to "simplified HTML" view only when necessary, and only when I know the sender. From lists at mtin.net Tue May 15 13:29:24 2018 From: lists at mtin.net (Justin Wilson) Date: Tue, 15 May 2018 09:29:24 -0400 Subject: WiFi Technical Book Recommendations In-Reply-To: <940E235B-ECD2-46F4-8495-D11EFBD3E2F9@me.com> References: <6E946954-AD80-4E41-B32B-18E60D23A588@gmail.com> <940E235B-ECD2-46F4-8495-D11EFBD3E2F9@me.com> Message-ID: <7D640C5E-78F5-4789-A58E-F0C6CE36D577@mtin.net> https://www.amazon.com/Deploying-License-Free-Wireless-Wide-Area-Networks/dp/1587057905 Not necessarily wifi. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On May 15, 2018, at 5:00 AM, JASON BOTHE wrote: > > Not quite a book in the paperback sense but George Stefanick’s site is worth having a look at. It’s full of good info. > > www.my80211.com > > J~ > > > >> On May 15, 2018, at 02:16, Troy Martin wrote: >> >> A series of 4 books from CWNP.com offers a vendor neutral perspective on >> of the Wi-Fi protocol and best practices. >> >> CWNA - “Wi-Fi 101” >> CWSP - Wi-Fi security deep dive >> CWDP - Wi-Fi design best practices >> CWAP - Wi-Fi protocol analysis deep dive or “the one ring to rule them all” >> >> Hope this helps! >> >> Kindest regards, >> >> -- >> Troy Martin >> >> >>> On May 15, 2018, at 12:47 AM, Mario Eirea wrote: >>> >>> Salutations >>> >>> Looking for recommendations on books with a deepdive of WiFi infrastructure, protocol layout, best practices, etc. Hopefully including the newest specs. Input would be greatly appreciated. >>> >>> Thanks >>> -ME >>> >>> Sent from Nine >>> > From rob at invaluement.com Tue May 15 13:59:27 2018 From: rob at invaluement.com (Rob McEwen) Date: Tue, 15 May 2018 09:59:27 -0400 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: On 5/15/2018 5:34 AM, Rich Kulawiec wrote: > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. For years, I was very disciplined about using plain-text only for my outbound messages... but then I got frustrated with seeing email I had posted (to lists like this) - come back with horribly bad line wrapping - that made for very choppy readability. (This may have been better or worse depending on which software or device I was reading it on?) Then, when I switched to using my Thunderbird client's "plain and html" setting, that problem went away, and posts that I made didn't look like someone high on drugs typed them. -- Rob McEwen https://www.invaluement.com From brak at gameservers.com Tue May 15 14:03:23 2018 From: brak at gameservers.com (Brian Rak) Date: Tue, 15 May 2018 10:03:23 -0400 Subject: AltDB bouncing emails Message-ID: I've been trying to get some super old entries removed from altdb, however the db-admin email bounces: The mail system : host pobox.rubinbroadcasting.com[65.50.205.32] said: 550     5.7.1 Unable to relay (in reply to RCPT TO command) Is there another contact here? Also, if anyone from Internap/Voxel.net is around... I've been trying to find someone with a clue to remove some IRR entries, ref ticket 3190091 From aaron1 at gvtc.com Tue May 15 15:15:19 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 15 May 2018 10:15:19 -0500 Subject: is odd number of links in lag group ok Message-ID: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> I have (2) 10 gig links bundled in a lag to my upstream internet provider. and we need more internet capacity. Is it cool to add a third 10 gig to my existing 20 gig lag internet connection? I'm asking since I heard in the past something negative about odd numbers of lag members. .but I also have heard that it's not a big deal. Let me know please -Aaron From jared at puck.nether.net Tue May 15 15:20:47 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 15 May 2018 11:20:47 -0400 Subject: is odd number of links in lag group ok In-Reply-To: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> Message-ID: > On May 15, 2018, at 11:15 AM, Aaron Gould wrote: > > I have (2) 10 gig links bundled in a lag to my upstream internet provider. > and we need more internet capacity. Is it cool to add a third 10 gig to my > existing 20 gig lag internet connection? > > > > I'm asking since I heard in the past something negative about odd numbers of > lag members. .but I also have heard that it's not a big deal. Let me know > please Much of this depends on the hardware, software and what hashing is used inbound outbound traffic directions, etc. It will likely work the way you expect, but one may be warmer than the other if traffic ends up overloading a single bucket in the hash. - Jared From mark.tinka at seacom.mu Tue May 15 15:28:11 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 15 May 2018 17:28:11 +0200 Subject: is odd number of links in lag group ok In-Reply-To: References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> Message-ID: On 15/May/18 17:20, Jared Mauch wrote: > Much of this depends on the hardware, software and what hashing is used inbound > outbound traffic directions, etc. > > It will likely work the way you expect, but one may be warmer than the other if > traffic ends up overloading a single bucket in the hash. We haven't had a major issue when loading traffic over even or odd links. If you have decent hardware and software, it should all be fine, particularly if your traffic is all or mostly IP. If you've got non-IP traffic in there, and your box cannot look into the payload to determine entropy, then things could get interesting. But this will happen even when you have even links... it's not anything specific to how many member links you have in the LAG, but rather, the router's need to maintain per-flow load balancing with limited information beyond Layer 2 data. That said, an even number of links just leaves the warm & fuzzies turned on :-)... Mark. From johnl at iecc.com Tue May 15 15:47:53 2018 From: johnl at iecc.com (John Levine) Date: 15 May 2018 11:47:53 -0400 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <240538927.8145.1526388210820.JavaMail.mhammett@ThunderFuck> Message-ID: <20180515154754.3DFB02695C5E@ary.qy> In article <240538927.8145.1526388210820.JavaMail.mhammett at ThunderFuck> you write: >Encrypted e-mail is so incredibly niche, this won't affect almost everyone. Bruce Schneier's blog entry on this arcane buglet ended by saying that if you care about encryption use Signal or WhatsApp. R's, John PS: I don't see any point in following up the discussion of HTML mail because it appears to have fallen through a wormhole from 15 years ago. From maxtul at netassist.ua Tue May 15 16:27:25 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 15 May 2018 19:27:25 +0300 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515154754.3DFB02695C5E@ary.qy> References: <20180515154754.3DFB02695C5E@ary.qy> Message-ID: <47acebac-7df1-0dbb-9584-27062a945584@netassist.ua> Really? Use extremely centralized closed source "solution"? LOL. 15.05.18 18:47, John Levine пише: > In article <240538927.8145.1526388210820.JavaMail.mhammett at ThunderFuck> you write: >> Encrypted e-mail is so incredibly niche, this won't affect almost everyone. > > Bruce Schneier's blog entry on this arcane buglet ended by saying that > if you care about encryption use Signal or WhatsApp. > > R's, > John > > PS: I don't see any point in following up the discussion of HTML mail > because it appears to have fallen through a wormhole from 15 years ago. > From woody at pch.net Tue May 15 16:32:52 2018 From: woody at pch.net (Bill Woodcock) Date: Tue, 15 May 2018 09:32:52 -0700 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515154754.3DFB02695C5E@ary.qy> References: <20180515154754.3DFB02695C5E@ary.qy> Message-ID: <71D1BEA5-E008-4E66-9C86-A623B344F94D@pch.net> > On May 15, 2018, at 8:47 AM, John Levine wrote: > Bruce Schneier's blog entry ended by saying that > if you care about encryption use Signal or WhatsApp. I didn’t even. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From johnl at iecc.com Tue May 15 16:36:21 2018 From: johnl at iecc.com (John Levine) Date: 15 May 2018 12:36:21 -0400 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <47acebac-7df1-0dbb-9584-27062a945584@netassist.ua> Message-ID: <20180515163621.9681F269690A@ary.qy> In article <47acebac-7df1-0dbb-9584-27062a945584 at netassist.ua> you write: >Really? Use extremely centralized closed source "solution"? You might want to learn a little about Signal. R's, John > >LOL. > >15.05.18 18:47, John Levine пише: >> In article <240538927.8145.1526388210820.JavaMail.mhammett at ThunderFuck> you write: >>> Encrypted e-mail is so incredibly niche, this won't affect almost everyone. >> >> Bruce Schneier's blog entry on this arcane buglet ended by saying that >> if you care about encryption use Signal or WhatsApp. From maxtul at netassist.ua Tue May 15 16:43:05 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 15 May 2018 19:43:05 +0300 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515163621.9681F269690A@ary.qy> References: <20180515163621.9681F269690A@ary.qy> Message-ID: <6ef9e6a1-ba0c-1f16-4491-6b54d7351511@netassist.ua> I did a lot. Centralized proprietary messenger with a lot of noise around. Unlike for example clear p2p tox, federalized own jabber server, with TOR to hide a metadata. 15.05.18 19:36, John Levine пише: > In article <47acebac-7df1-0dbb-9584-27062a945584 at netassist.ua> you write: >> Really? Use extremely centralized closed source "solution"? > > You might want to learn a little about Signal. > > R's, > John > >> >> LOL. >> >> 15.05.18 18:47, John Levine пише: >>> In article <240538927.8145.1526388210820.JavaMail.mhammett at ThunderFuck> you write: >>>> Encrypted e-mail is so incredibly niche, this won't affect almost everyone. >>> >>> Bruce Schneier's blog entry on this arcane buglet ended by saying that >>> if you care about encryption use Signal or WhatsApp. > From nanog at shankland.org Tue May 15 17:22:25 2018 From: nanog at shankland.org (Jim Shankland) Date: Tue, 15 May 2018 10:22:25 -0700 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: <99184a16-d653-11ef-bda2-188ca6132ee7@shankland.org> On 5/15/18 2:34 AM, Rich Kulawiec wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: >> TL;DR = Don't use HTML email [snip] > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. > Which category best describes my wonderful, intelligent (but decidedly non-technical), 84-year-old mother-in-law, who has been using email for a couple of decades (thus certainly not a "newbie"), and is definitely not a spammer. Do you have any advice for how I break it to her that she's an ineducable moron? You know, since there are no exceptions and all. Jim From nanog at jack.fr.eu.org Tue May 15 17:37:10 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Tue, 15 May 2018 19:37:10 +0200 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <99184a16-d653-11ef-bda2-188ca6132ee7@shankland.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> <99184a16-d653-11ef-bda2-188ca6132ee7@shankland.org> Message-ID: <5AFB1AC6.5080000@jack.fr.eu.org> On 05/15/2018 07:22 PM, Jim Shankland wrote: > On 5/15/18 2:34 AM, Rich Kulawiec wrote: >> On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: >>> TL;DR = Don't use HTML email [snip] >> That's enough right there. HTML markup in email is used exclusively >> by three kinds of people: (1) ignorant newbies who don't know any >> better (2) ineducable morons who refuse to learn (3) spammers. >> There are no exceptions. >> > non-technical She is a noob, thus the first :) From bzs at theworld.com Tue May 15 17:46:03 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 15 May 2018 13:46:03 -0400 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: <23291.7387.66052.85140@gargle.gargle.HOWL> On May 15, 2018 at 05:34 rsk at gsp.org (Rich Kulawiec) wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: > > TL;DR = Don't use HTML email [snip] > > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. Thirty years ago we thought graphical and even interactive email would soon be the cat's pajamas (or possibly the bee's knees.) Now we live in a world of seemingly ever-shrinking and pessimistic expectations -- ok perhaps that's overstating a little -- largely due to security considerations. Don't do that, you'll poke your eye out! Admittedly I never send HTML email and mostly find it annoying when I receive it, tho not always. We need to figure out how to have our cake and eat it too, "the k00l kidz don't use html email" won't accomplish much except maybe among the k00l kidz. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From alan.buxey at gmail.com Tue May 15 19:30:51 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Tue, 15 May 2018 20:30:51 +0100 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: real ones send such formulae as LaTeX attachments - where their recipients can have a simple plugin to view/display it inline (then save to edit/modify etc). HTML is horrible for formula...but at least I guess a little better than MS Word. alan From hf0002+nanog at uah.edu Tue May 15 19:41:26 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Tue, 15 May 2018 14:41:26 -0500 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: On Tue, May 15, 2018 at 2:31 PM Alan Buxey wrote: > real ones > Ah, the classic "no true Scotsman." I haven't seen one of these in a while. I think the vast majority of HTML email use is due to "email formatting and markup" being somewhere near the end of the priority list. I know that's where it resides on mine. -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From don at 00100100.net Fri May 11 22:15:55 2018 From: don at 00100100.net (Don Fanning) Date: Fri, 11 May 2018 15:15:55 -0700 Subject: Level 3 Looking Glass Broken In-Reply-To: <6e76-5af60800-3-49112800@97288033> References: <6e76-5af60800-3-49112800@97288033> Message-ID: Maybe try the team reference in the apache debug of the looking glass server: DL-SystemsAndTools at Level3.com -----Original Message----- From: NANOG On Behalf Of Gary T. Giesen via NANOG Sent: Friday, May 11, 2018 02:15 PM To: nanog at nanog.org Subject: Level 3 Looking Glass Broken I'm seeing issues with Level 3's looking glass (https://lookingglass.level3.net) since they rolled out the new one with the CenturyLink branding. Any query results in "Invalid usage. POST variable not set.". Also, the radio buttons under the "Information Category" selection allow more than one selection (and no way of deselecting anything). I tried opening a ticket L3 under one of my transit circuits and was told that the NOC doesn't deal with it, and I should talk to our account team (as fun as that sounds, I'd rather stick my head in a blender). Anyone on this list have any clout inside L3 to get this fixed? Cheers, GTG From j0hn.hurl3y at gmail.com Sat May 12 16:15:37 2018 From: j0hn.hurl3y at gmail.com (John Hurley) Date: Sat, 12 May 2018 12:15:37 -0400 Subject: ALTDB - Getting records removed Message-ID: Hi All, Recently acquired a new 2-byte AS number from ARIN. It had a previous owner whom had records setup at ALTDB. I've sent emails to request removal but haven't heard anything back. Any tips or a different venue I can use to get in touch with the altdb folks? From chano79thstreet at gmail.com Mon May 14 12:19:45 2018 From: chano79thstreet at gmail.com (~) Date: Mon, 14 May 2018 13:19:45 +0100 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> Message-ID: Embargo has been broken. Here's the full details: https://efail.de (h/t Martjin Grooten) On Mon, 14 May 2018, 09:19 Suresh Ramasubramanian, wrote: > Seems to be a set of MUA bugs that are being overblown and hyped up. > > TL;DR = Don't use HTML email with some mail clients when sending pgp > encrypted mail. > > https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html > > --srs > > On 14/05/18, 1:15 PM, "NANOG on behalf of George William Herbert" < > nanog-bounces at nanog.org on behalf of george.herbert at gmail.com> wrote: > > > This is likely bad enough operators need to pay attention. > > @seecurity tweeted: > > "We'll publish critical vulnerabilities in PGP/GPG and S/MIME email > encryption on 2018-05-15 07:00 UTC. They might reveal the plaintext of > encrypted emails, including encrypted emails sent in the past. #efail 1/4" > > Thread starts here: > https://twitter.com/seecurity/status/995906576170053633?s=21 > > I have no particular insight into what it is other than presuming from > thread that decryption can be tricked to do bad things. > > They recommend temporary disabling downthread: > > "There are currently no reliable fixes for the vulnerability. If you > use PGP/GPG or S/MIME for very sensitive communication, you should disable > it in your email client for now. Also read @EFF’s blog post on this issue: > eff.org/deeplinks/2018… #efail 2/4" > > -george > > Sent from my iPhone > > > From markr at signal100.com Tue May 15 09:52:16 2018 From: markr at signal100.com (Mark Rousell) Date: Tue, 15 May 2018 10:52:16 +0100 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: <5AFAADD0.7060204@signal100.com> On 15/05/2018 10:34, Rich Kulawiec wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: >> TL;DR = Don't use HTML email [snip] > > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. > > ---rsk If only life were so simple. I used to be a resolute user of plain text-only email. It was good enough for me. And then I realised how absurdly old fashioned this appeared to my clients. I'd send them emails explaining what I was going to do or about the new product or service, and it just looked boring and backward. I realised that I could no longer stick to plain text: It was actually harming my business. The world has moved on and rich content everywhere is now a must. It's no longer optional (although of course it depends on with whom one communicates). Yes, you can blame this on "ignorant newbies who don't know any better" but bear in mind that they are now the vast majority of users. They are the ones ultimately paying the bills and we have to adapt to their preferences, and not them to us. P.S. And I agree with Suresh in the previous message. It is true that there is a real problem here (more with S/MIME than PGP/GPG in practice) but it's being hyped up and overblown. The content does not fully support the headlines. -- Mark Rousell From jason at tiesystems.com Tue May 15 02:59:09 2018 From: jason at tiesystems.com (Jason Rowsell) Date: Mon, 14 May 2018 19:59:09 -0700 Subject: USB Ethernet Adapters Message-ID: FWIW - I have had a GREAT experience with the IOGear GUC3C01 on Windows 10. Every other USB NIC I have ever used I have given away or thrown in the garbage after no more than a day's worth of use (many "Gigabit" adapters will not do over 330 Mbps and / or have TERRIBLE reliability issues in my experience). This thing pulls 970+ Mbps, support VLANs, Jumbo Frames, etc. and has never failed me or let me down once to date (Realtek Chipset). It does use the newer USB-C (aka 3.1) reversible style connector, so you *may* need an adapter which is the only possible downside I can think of. Just my $ .02, HTH. Jason *Jason Rowsell * | Account Manager 206.299.2197 | *www.tiesystems.com * *jason at tiesystems.com **IT Solutions that fit.* On Mon, May 14, 2018 at 7:03 PM, Chris Adams wrote: > Once upon a time, Brad Knowles said: > > If you're going to do network testing, then an NETool is recommended. > That's a complete Linux network testing system in what looks like a > larger-than-usual dongle. > > I like the Pockethernet for a portable diagnostic tool (haven't tried > the Netool). > > -- > Chris Adams > From jason at viviotech.net Tue May 15 04:49:16 2018 From: jason at viviotech.net (jason) Date: Mon, 14 May 2018 21:49:16 -0700 Subject: Bank of America Email Contact Message-ID: Hello, Looking for a bank of america email admin to contact me off-list regarding email failing to deliver to a specific email account. -- -- Jason Technical Support - Tier 2 Vivio Technologies From dcorbe at hammerfiber.com Tue May 15 10:37:25 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 15 May 2018 06:37:25 -0400 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515095900.GA43153@meow.BKantor.net> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> <20180515095900.GA43153@meow.BKantor.net> Message-ID: <11a68e5d-8705-786d-460c-4c303f7a4e71@hammerfiber.com> On 5/15/2018 05:59, Brian Kantor wrote: > > I imagine some fool told them this improves security, and they were > stupid enough to believe it. > - Brian > It's a bit simpler than that. Too many people are dazzled by polished presentations. It's a sad fact of life that there are way too many people walking around that are distracted by shiny things. From akajtar at wadsworthcity.org Tue May 15 14:10:57 2018 From: akajtar at wadsworthcity.org (Adam Kajtar) Date: Tue, 15 May 2018 10:10:57 -0400 Subject: Juniper BGP Convergence Time Message-ID: Hello: I'm running two Juniper MX104s. Each MX has 1 ISP connected running BGP(full routes). iBGP is running between the routers via a two port 20G lag. When one of the ISPs fails, it can take upwards of 2 minutes for traffic to start flowing correctly. The router has the correct route in the routing table, but it doesn't install it in the forwarding table for the full two mins. I have a few questions if anyone could answer them. - What would a usual convergence time be for this setup? - Is there anything I could do speed this process up? (I tried Multipath) - Any tips and tricks would be much appreciated Thanks in Advance -- Adam Kajtar Systems Administrator City of Wadsworth akajtar at wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook * |* Twitter *|* Instagram *|* YouTube From ghira at mistral.co.uk Tue May 15 18:46:37 2018 From: ghira at mistral.co.uk (Adam Atkinson) Date: Tue, 15 May 2018 19:46:37 +0100 Subject: is odd number of links in lag group ok In-Reply-To: References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> Message-ID: <5d31afb0-c8a5-d4f9-a25c-e9c8b66f8246@mistral.co.uk> On 15/05/18 16:28, Mark Tinka wrote: > That said, an even number of links just leaves the warm & fuzzies turned > on :-)... Well, power of two, surely? 6 is even, but is not a "good" number of links for a lag group. (Extreme X8 supports up to 64 links in a group, and Enterasys up to 127 if I recall correctly. Though Enterasys, unusually, seems to support round-robin load balancing in which case the argument for powers of 2 numbers of links ceases to make sense.) From ben at 6by7.net Tue May 15 19:18:57 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 15 May 2018 12:18:57 -0700 Subject: is odd number of links in lag group ok In-Reply-To: References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> Message-ID: <34010B51-9C3F-4523-A455-6A886FED045E@6by7.net> It will work fine if you have a good modern router. Consider this; all evenly grouped LAGs are odd in their failed conditions. -Ben > On May 15, 2018, at 8:28 AM, Mark Tinka wrote: > > > >> On 15/May/18 17:20, Jared Mauch wrote: >> >> Much of this depends on the hardware, software and what hashing is used inbound >> outbound traffic directions, etc. >> >> It will likely work the way you expect, but one may be warmer than the other if >> traffic ends up overloading a single bucket in the hash. > > We haven't had a major issue when loading traffic over even or odd > links. If you have decent hardware and software, it should all be fine, > particularly if your traffic is all or mostly IP. > > If you've got non-IP traffic in there, and your box cannot look into the > payload to determine entropy, then things could get interesting. But > this will happen even when you have even links... it's not anything > specific to how many member links you have in the LAG, but rather, the > router's need to maintain per-flow load balancing with limited > information beyond Layer 2 data. > > That said, an even number of links just leaves the warm & fuzzies turned > on :-)... > > Mark. From alan at clegg.com Tue May 15 19:51:06 2018 From: alan at clegg.com (Alan Clegg) Date: Tue, 15 May 2018 15:51:06 -0400 Subject: Needed: Verizon Wireless DNS technical contact Message-ID: <9cf0cb15-89a5-75d6-5b39-30d4432e4a66@clegg.com> Hi! I'm dealing with an issue with the mnc480.mcc311.3gppnetwork.org zone and need to talk to someone at Verizon Wireless. Any direct contacts or pointers would be very much appreciated. Thanks! AlanC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: OpenPGP digital signature URL: From amitchell at isipp.com Tue May 15 21:35:26 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Tue, 15 May 2018 15:35:26 -0600 Subject: Level 3 Looking Glass Broken In-Reply-To: <6e76-5af60800-3-49112800@97288033> References: <6e76-5af60800-3-49112800@97288033> Message-ID: <46C2D6FB-D0D1-466E-BAA1-815BE9600AB0@isipp.com> Gary, may we share this with our Level3 contacts? > > I'm seeing issues with Level 3's looking glass (https://lookingglass.level3.net) since they rolled out the new one with the CenturyLink branding. Any query results in "Invalid usage. POST variable not set.". Also, the radio buttons under the "Information Category" selection allow more than one selection (and no way of deselecting anything). I tried opening a ticket L3 under one of my transit circuits and was told that the NOC doesn't deal with it, and I should talk to our account team (as fun as that sounds, I'd rather stick my head in a blender). > > Anyone on this list have any clout inside L3 to get this fixed? > > Cheers, > > GTG From mike.lyon at gmail.com Tue May 15 21:36:06 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Tue, 15 May 2018 14:36:06 -0700 Subject: ALTDB - Getting records removed In-Reply-To: References: Message-ID: <0F9FFA12-9E75-48CC-9778-ADFE44E7A168@gmail.com> The altdb email system should have been fixed earlier today. You may want to try to reach out to them again. Thanks, Mike > On May 12, 2018, at 09:15, John Hurley wrote: > > Hi All, > > Recently acquired a new 2-byte AS number from ARIN. It had a previous owner > whom had records setup at ALTDB. > > I've sent emails to request removal but haven't heard anything back. > > Any tips or a different venue I can use to get in touch with the altdb > folks? From joshbaird at gmail.com Tue May 15 21:56:20 2018 From: joshbaird at gmail.com (Josh Baird) Date: Tue, 15 May 2018 17:56:20 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: References: Message-ID: The MX104 has a notoriously slow PPC-based RE unfortunately. Josh On Tue, May 15, 2018 at 10:10 AM, Adam Kajtar wrote: > Hello: > > I'm running two Juniper MX104s. Each MX has 1 ISP connected running > BGP(full routes). iBGP is running between the routers via a two port 20G > lag. When one of the ISPs fails, it can take upwards of 2 minutes for > traffic to start flowing correctly. The router has the correct route in the > routing table, but it doesn't install it in the forwarding table for the > full two mins. > > I have a few questions if anyone could answer them. > > - What would a usual convergence time be for this setup? > - Is there anything I could do speed this process up? (I tried > Multipath) > - Any tips and tricks would be much appreciated > > Thanks in Advance > -- > Adam Kajtar > Systems Administrator > City of Wadsworth > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > > From lobna_gouda at hotmail.com Tue May 15 22:16:14 2018 From: lobna_gouda at hotmail.com (lobna gouda) Date: Tue, 15 May 2018 22:16:14 +0000 Subject: Juniper BGP Convergence Time In-Reply-To: References: , Message-ID: That's true. But are you using per-packet load balance policy in your configuration? ________________________________ From: NANOG on behalf of Josh Baird Sent: Tuesday, May 15, 2018 5:56 PM To: Adam Kajtar Cc: nanog at nanog.org Subject: Re: Juniper BGP Convergence Time The MX104 has a notoriously slow PPC-based RE unfortunately. Josh On Tue, May 15, 2018 at 10:10 AM, Adam Kajtar wrote: > Hello: > > I'm running two Juniper MX104s. Each MX has 1 ISP connected running > BGP(full routes). iBGP is running between the routers via a two port 20G > lag. When one of the ISPs fails, it can take upwards of 2 minutes for > traffic to start flowing correctly. The router has the correct route in the > routing table, but it doesn't install it in the forwarding table for the > full two mins. > > I have a few questions if anyone could answer them. > > - What would a usual convergence time be for this setup? > - Is there anything I could do speed this process up? (I tried > Multipath) > - Any tips and tricks would be much appreciated > > Thanks in Advance > -- > Adam Kajtar > Systems Administrator > City of Wadsworth > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com Wadsworth, OH | Official Website www.wadsworthcity.com Starting in February, the City of Wadsworth will be replacing water lines on both the north and south sides of Broad Street, between North Lyman and Summit Street. > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > > From ruairi.carroll at gmail.com Tue May 15 22:26:33 2018 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Tue, 15 May 2018 15:26:33 -0700 Subject: Juniper BGP Convergence Time In-Reply-To: References: Message-ID: On 15 May 2018 at 07:10, Adam Kajtar wrote: > Hello: > > I'm running two Juniper MX104s. Each MX has 1 ISP connected running > BGP(full routes). iBGP is running between the routers via a two port 20G > lag. When one of the ISPs fails, it can take upwards of 2 minutes for > traffic to start flowing correctly. The router has the correct route in the > routing table, but it doesn't install it in the forwarding table for the > full two mins. > > I have a few questions if anyone could answer them. > > - What would a usual convergence time be for this setup? > With MX104, between 50 seconds and many minutes. The RE is not really dimensioned for full tables, unfortunately. - Is there anything I could do speed this process up? (I tried Multipath) > Covering floating static route. > - Any tips and tricks would be much appreciated > > Thanks in Advance > -- > Adam Kajtar > Systems Administrator > City of Wadsworth > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > > From aaron1 at gvtc.com Tue May 15 22:38:02 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 15 May 2018 17:38:02 -0500 Subject: Juniper BGP Convergence Time In-Reply-To: References: Message-ID: You sure it doesn't have something to do with 60 seconds * 3 = 180 secs of BGP neighbor Time out before it believes neighbor is dead and remove routes to that neighbor? Aaron > On May 15, 2018, at 9:10 AM, Adam Kajtar wrote: > > Hello: > > I'm running two Juniper MX104s. Each MX has 1 ISP connected running > BGP(full routes). iBGP is running between the routers via a two port 20G > lag. When one of the ISPs fails, it can take upwards of 2 minutes for > traffic to start flowing correctly. The router has the correct route in the > routing table, but it doesn't install it in the forwarding table for the > full two mins. > > I have a few questions if anyone could answer them. > > - What would a usual convergence time be for this setup? > - Is there anything I could do speed this process up? (I tried Multipath) > - Any tips and tricks would be much appreciated > > Thanks in Advance > -- > Adam Kajtar > Systems Administrator > City of Wadsworth > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > From erich at gotfusion.net Tue May 15 23:09:32 2018 From: erich at gotfusion.net (Kaiser, Erich) Date: Tue, 15 May 2018 18:09:32 -0500 Subject: Juniper BGP Convergence Time In-Reply-To: References: Message-ID: Do you need full routes? What about just a default route from BGP? Erich Kaiser The Fusion Network erich at gotfusion.net Office: 815-570-3101 On Tue, May 15, 2018 at 5:38 PM, Aaron Gould wrote: > You sure it doesn't have something to do with 60 seconds * 3 = 180 secs of > BGP neighbor Time out before it believes neighbor is dead and remove routes > to that neighbor? > > Aaron > > > On May 15, 2018, at 9:10 AM, Adam Kajtar > wrote: > > > > Hello: > > > > I'm running two Juniper MX104s. Each MX has 1 ISP connected running > > BGP(full routes). iBGP is running between the routers via a two port 20G > > lag. When one of the ISPs fails, it can take upwards of 2 minutes for > > traffic to start flowing correctly. The router has the correct route in > the > > routing table, but it doesn't install it in the forwarding table for the > > full two mins. > > > > I have a few questions if anyone could answer them. > > > > - What would a usual convergence time be for this setup? > > - Is there anything I could do speed this process up? (I tried > Multipath) > > - Any tips and tricks would be much appreciated > > > > Thanks in Advance > > -- > > Adam Kajtar > > Systems Administrator > > City of Wadsworth > > akajtar at wadsworthcity.org > > ----------------------------------------------------- > > http://www.wadsworthcity.com > > > > Facebook * |* Twitter > > *|* Instagram > > *|* YouTube > > > > From ben at 6by7.net Wed May 16 00:28:01 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 15 May 2018 17:28:01 -0700 Subject: Juniper BGP Convergence Time In-Reply-To: References: Message-ID: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Have you checked your timeouts ? -Ben > On May 15, 2018, at 4:09 PM, Kaiser, Erich wrote: > > Do you need full routes? What about just a default route from BGP? > > Erich Kaiser > The Fusion Network > erich at gotfusion.net > Office: 815-570-3101 > > > > >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould wrote: >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180 secs of >> BGP neighbor Time out before it believes neighbor is dead and remove routes >> to that neighbor? >> >> Aaron >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar >> wrote: >>> >>> Hello: >>> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running >>> BGP(full routes). iBGP is running between the routers via a two port 20G >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes for >>> traffic to start flowing correctly. The router has the correct route in >> the >>> routing table, but it doesn't install it in the forwarding table for the >>> full two mins. >>> >>> I have a few questions if anyone could answer them. >>> >>> - What would a usual convergence time be for this setup? >>> - Is there anything I could do speed this process up? (I tried >> Multipath) >>> - Any tips and tricks would be much appreciated >>> >>> Thanks in Advance >>> -- >>> Adam Kajtar >>> Systems Administrator >>> City of Wadsworth >>> akajtar at wadsworthcity.org >>> ----------------------------------------------------- >>> http://www.wadsworthcity.com >>> >>> Facebook * |* Twitter >>> *|* Instagram >>> *|* YouTube >>> >> >> From colton.conor at gmail.com Wed May 16 00:49:44 2018 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 15 May 2018 19:49:44 -0500 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: Mario, Thanks for the recommendation. I am leaning towards the devices with a Realtek RTL8153 chipset over the devices with the Axis AX88179. I have more faith in Realtek than AXIS as I have had serveral laptops in the past with Realtek NIC's, but never a single device with AXIS. Plus Realtek seems to be more standards based whereas AXIS only supports 4k Jumbo frames? On Mon, May 14, 2018 at 9:35 PM, Mario Eirea wrote: > My recommendation was based on the Realtek RTL8153 chipset. It's the only > USB chip I had found at the time that did VLANs and full gigabit, in > Windows. I have had this for a while now, I would hope there are more > things on the market. > > > -ME > ------------------------------ > *From:* NANOG on behalf of Colton Conor < > colton.conor at gmail.com> > *Sent:* Monday, May 14, 2018 9:20 PM > *To:* NANOG > *Subject:* Re: USB Ethernet Adapters > > Thanks for the responses so far. I am surprised to see the wide array of > responses. A couple of more things: > > 1. I like the ones that have lights on the Ethernet port so you can see if > the device is up/down. I find that critical as we go to a lot of sites > where we don't know if the cable is good/bad, so a indication on the lights > is critical. > 2. Techs are constantly doing speedtest.net tests on 1Gbps Ethernet > connections, so ideally an adapter that can constantly push the 1Gbps > speeds is ideally. > > Seems that most of these adapters use a common chipset. Anyone done > research on which chipset is the best, and why? > > On Mon, May 14, 2018 at 12:45 PM, Colton Conor > wrote: > > > Our new laptops like most do not have an Ethernet adapter build in as > they > > are too slim. What USB to Ethernet adapter do you recommend and why? > > Ideally it would be compatible with Windows 10, and have the ability to > set > > speed, duplex and VLAN IDs if possible. > > > From rsk at gsp.org Wed May 16 12:34:16 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 16 May 2018 08:34:16 -0400 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515094231.GA23124@sunf10.rd.bbc.co.uk> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> <20180515094231.GA23124@sunf10.rd.bbc.co.uk> Message-ID: <20180516123416.GA20745@gsp.org> On Tue, May 15, 2018 at 10:42:31AM +0100, Brandon Butterworth wrote: > and phishers/exploiters. HTML markup in email is used exclusively > by four kinds of people I'll accept that as a friendly amendment. ;) It is -- to Brian Kantor's point elsewhere in the thread -- very unfortunate that many banks and financial institutions have spent much of the past couple of decades assiduously training their customers to be phish victims. Some of them, including a very well-known, very large company I'm communicating with at the moment, have compounded that blunder by handing over lists of the email addresses of all their customers to third parties, thus making it vastly easier for phishers to get their hands on them. (If the latter isn't clear, consider: suppose you were in the professional phishing business. "professional" as in doing it competently, not sending messages full of fractured syntax. Can you think of some places where you would like to have one of your employees positioned? How about some place that handles customer email data for *many* banks/financial institutions? One-stop shopping, as it were. No need to get people into 27 different operations when all you need to do is get one person into one. And, most likely, every one of those 27 has done you the favor of knocking themselves out to make their customers vulnerable to you. You're welcome.) ---rsk From saku at ytti.fi Wed May 16 13:10:39 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 16 May 2018 16:10:39 +0300 Subject: is odd number of links in lag group ok In-Reply-To: <5d31afb0-c8a5-d4f9-a25c-e9c8b66f8246@mistral.co.uk> References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> <5d31afb0-c8a5-d4f9-a25c-e9c8b66f8246@mistral.co.uk> Message-ID: This is implementation specific. Consider hash result returning range 0-15. Then number of port count as divisor of 16/n must result in an integer value. To workaround this issue, you either have larger range of hash results, in which case unequal distribution has small bias, or you have different hash functions depending on port count so that that hash returns appropriate range for given port count. Certainly solvable problem, and generally non-issue. On 15 May 2018 at 21:46, Adam Atkinson wrote: > On 15/05/18 16:28, Mark Tinka wrote: > >> That said, an even number of links just leaves the warm & fuzzies turned >> on :-)... > > > Well, power of two, surely? 6 is even, but is not a "good" number of links > for a lag group. > > (Extreme X8 supports up to 64 links in a group, and Enterasys up to 127 if I > recall correctly. Though Enterasys, unusually, seems to support round-robin > load balancing in which case the argument for powers of 2 numbers of links > ceases to make sense.) -- ++ytti From erich at gotfusion.net Wed May 16 14:00:24 2018 From: erich at gotfusion.net (Kaiser, Erich) Date: Wed, 16 May 2018 09:00:24 -0500 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: A last resort route (default route) could still be good to take from your ISP(s) even if you still do full routes, as the propagation is happening on the internet side, you should at least have a path inbound through the other provider. The default route at least would send the traffic out if it does not see the route locally. Just an idea. On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar wrote: > I could use static routes but I noticed since I moved to full routes I > have had a lot fewer customer complaints about latency(especially when it > comes to Voice and VPN traffic). > > I wasn't using per-packet load balancing. I believe juniper default is per > IP. > > My timers are as follows > Active Holdtime: 90 > Keepalive Interval: 30 > > Would I be correct in thinking I need to contact my ISP to lower these > values? > > An interesting note is when I had both ISPs connected into a single MX104 > the failover was just a few seconds. > > Thanks again. > > > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > >> Have you checked your timeouts ? >> >> -Ben >> >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich wrote: >> > >> > Do you need full routes? What about just a default route from BGP? >> > >> > Erich Kaiser >> > The Fusion Network >> > erich at gotfusion.net >> > Office: 815-570-3101 >> > >> > >> > >> > >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould wrote: >> >> >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180 >> secs of >> >> BGP neighbor Time out before it believes neighbor is dead and remove >> routes >> >> to that neighbor? >> >> >> >> Aaron >> >> >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar >> >> wrote: >> >>> >> >>> Hello: >> >>> >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running >> >>> BGP(full routes). iBGP is running between the routers via a two port >> 20G >> >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes for >> >>> traffic to start flowing correctly. The router has the correct route >> in >> >> the >> >>> routing table, but it doesn't install it in the forwarding table for >> the >> >>> full two mins. >> >>> >> >>> I have a few questions if anyone could answer them. >> >>> >> >>> - What would a usual convergence time be for this setup? >> >>> - Is there anything I could do speed this process up? (I tried >> >> Multipath) >> >>> - Any tips and tricks would be much appreciated >> >>> >> >>> Thanks in Advance >> >>> -- >> >>> Adam Kajtar >> >>> Systems Administrator >> >>> City of Wadsworth >> >>> akajtar at wadsworthcity.org >> >>> ----------------------------------------------------- >> >>> http://www.wadsworthcity.com >> >>> >> >>> Facebook * |* Twitter >> >>> *|* Instagram >> >>> *|* YouTube >> >>> >> >> >> >> >> > > > -- > Adam Kajtar > Systems Administrator, Safety Services > City of Wadsworth > Office 330.335.2865 > Cell 330.485.6510 > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > > From aaron1 at gvtc.com Wed May 16 14:54:54 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 16 May 2018 09:54:54 -0500 Subject: internet - sparkle Message-ID: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> http://icaruswept.com/2016/06/28/who-owns-the-internet/ .written in 12/2015 - do y'all think this is accurate, and, in 2018, is it still accurate ? (asking since my next question is related to Sparkle, since they are listed in that previous article as a significant Internet presence) Also, please tell me your feelings/experiences of Sparkle as an Internet uplink provider. like for 10/100 gig. My coworker just got back from ITW/Chicago and he is considering Sparkle as an additional Internet provider for the ISP I work for in San Antonio, TX . we would need to uplink to Sparkle in the central Texas area somehow. He mentioned that Sparkle may be in McAllen / Dallas and could possibly, in the future be in Austin or San Antonio - Aaron From edugas at unknowndevice.ca Wed May 16 15:05:24 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Wed, 16 May 2018 11:05:24 -0400 Subject: internet - sparkle In-Reply-To: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> Message-ID: <1526482775.local-9a47e3e8-0ba9-v1.2.1-7e7447b6@getmailspring.com> Replace Level3 with CenturyLink as they're basically taking over AS33566. Would add Zayo (AS6461) to the list. I'm not familiar with Sparkle/Seabone to be honest as we're operating an eyeball network exclusively in the NA. On May 16 2018, at 10:54 am, Aaron Gould wrote: > > http://icaruswept.com/2016/06/28/who-owns-the-internet/ > > > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is it > still accurate ? (asking since my next question is related to Sparkle, since > they are listed in that previous article as a significant Internet presence) > > > > Also, please tell me your feelings/experiences of Sparkle as an Internet > uplink provider. like for 10/100 gig. > > > > My coworker just got back from ITW/Chicago and he is considering Sparkle as > an additional Internet provider for the ISP I work for in San Antonio, TX . > we would need to uplink to Sparkle in the central Texas area somehow. He > mentioned that Sparkle may be in McAllen / Dallas and could possibly, in the > future be in Austin or San Antonio > > > > > > - Aaron From Anthony.DeLaCruz at CenturyLink.com Wed May 16 15:55:13 2018 From: Anthony.DeLaCruz at CenturyLink.com (Delacruz, Anthony B) Date: Wed, 16 May 2018 15:55:13 +0000 Subject: ALTDB - Getting records removed In-Reply-To: References: Message-ID: <398B250423578A4E97AFE1B8B67C686C6503B50B@PDDCWMBXEX503.ctl.intranet> Ditto also interested have dozens of old entries from previous delegations would like to see cleaned up but my google-foo tells me it's been a nonresponsive black hole several years now that probably should just go away if it's not going to be maintained properly. I think my favorite is the "Is anyone still maintaining altdb.net? thread from April 2011. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Hurley Sent: Saturday, May 12, 2018 11:16 AM To: nanog at nanog.org Subject: ALTDB - Getting records removed Hi All, Recently acquired a new 2-byte AS number from ARIN. It had a previous owner whom had records setup at ALTDB. I've sent emails to request removal but haven't heard anything back. Any tips or a different venue I can use to get in touch with the altdb folks? This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From michael at wi-fiber.io Wed May 16 16:12:22 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Wed, 16 May 2018 09:12:22 -0700 Subject: internet - sparkle In-Reply-To: <1526482775.local-9a47e3e8-0ba9-v1.2.1-7e7447b6@getmailspring.com> References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <1526482775.local-9a47e3e8-0ba9-v1.2.1-7e7447b6@getmailspring.com> Message-ID: Additionally, whilst not "technically" a tier 1 provider, Hurricane electric should be high on that list. Especially as one of the best providers of and proponents for IPv6. We'll see into the future, HE may have one of the most critical infrastructures, and should be a "part-owner" of the internet. On Wed, May 16, 2018, 8:08 AM Eric Dugas wrote: > Replace Level3 with CenturyLink as they're basically taking over AS33566. > Would add Zayo (AS6461) to the list. > > I'm not familiar with Sparkle/Seabone to be honest as we're operating an > eyeball network exclusively in the NA. > On May 16 2018, at 10:54 am, Aaron Gould wrote: > > > > http://icaruswept.com/2016/06/28/who-owns-the-internet/ > > > > > > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is > it > > still accurate ? (asking since my next question is related to Sparkle, > since > > they are listed in that previous article as a significant Internet > presence) > > > > > > > > Also, please tell me your feelings/experiences of Sparkle as an Internet > > uplink provider. like for 10/100 gig. > > > > > > > > My coworker just got back from ITW/Chicago and he is considering Sparkle > as > > an additional Internet provider for the ISP I work for in San Antonio, > TX . > > we would need to uplink to Sparkle in the central Texas area somehow. He > > mentioned that Sparkle may be in McAllen / Dallas and could possibly, in > the > > future be in Austin or San Antonio > > > > > > > > > > > > - Aaron > From mike.lyon at gmail.com Wed May 16 16:17:28 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 16 May 2018 09:17:28 -0700 Subject: ALTDB - Getting records removed In-Reply-To: <398B250423578A4E97AFE1B8B67C686C6503B50B@PDDCWMBXEX503.ctl.intranet> References: <398B250423578A4E97AFE1B8B67C686C6503B50B@PDDCWMBXEX503.ctl.intranet> Message-ID: As stated yesterday, email was fixed on AltDB yesterday. Please try again. Thanks, Mike > On May 16, 2018, at 08:55, Delacruz, Anthony B wrote: > > Ditto also interested have dozens of old entries from previous delegations would like to see cleaned up but my google-foo tells me it's been a nonresponsive black hole several years now that probably should just go away if it's not going to be maintained properly. I think my favorite is the "Is anyone still maintaining altdb.net? thread from April 2011. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Hurley > Sent: Saturday, May 12, 2018 11:16 AM > To: nanog at nanog.org > Subject: ALTDB - Getting records removed > > Hi All, > > Recently acquired a new 2-byte AS number from ARIN. It had a previous owner > whom had records setup at ALTDB. > > I've sent emails to request removal but haven't heard anything back. > > Any tips or a different venue I can use to get in touch with the altdb > folks? > > > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From cb.list6 at gmail.com Wed May 16 16:33:12 2018 From: cb.list6 at gmail.com (Ca By) Date: Wed, 16 May 2018 09:33:12 -0700 Subject: internet - sparkle In-Reply-To: References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <1526482775.local-9a47e3e8-0ba9-v1.2.1-7e7447b6@getmailspring.com> Message-ID: On Wed, May 16, 2018 at 9:14 AM Michael Crapse wrote: > Additionally, whilst not "technically" a tier 1 provider, Hurricane > electric should be high on that list. Especially as one of the best > providers of and proponents for IPv6. We'll see into the future, HE may > have one of the most critical infrastructures, and should be a "part-owner" > of the internet. > Fully disagree. 1). HE cant reach cogent on v6. Forget whos fault it is, it is a liability for anyone that relies on HE 2). They dont support common bgp communities like no-export, so trying to do TE is a mess. 3). They are at the center of nearly every bgp hijacking fiasco because they dont have reasonable route controls. HE is a liability to us all until they fix their bgp filters https://www.internetsociety.org/blog/2018/04/amazons-route-53-bgp-hijack/ > On Wed, May 16, 2018, 8:08 AM Eric Dugas wrote: > > > Replace Level3 with CenturyLink as they're basically taking over AS33566. > > Would add Zayo (AS6461) to the list. > > > > I'm not familiar with Sparkle/Seabone to be honest as we're operating an > > eyeball network exclusively in the NA. > > On May 16 2018, at 10:54 am, Aaron Gould wrote: > > > > > > http://icaruswept.com/2016/06/28/who-owns-the-internet/ > > > > > > > > > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is > > it > > > still accurate ? (asking since my next question is related to Sparkle, > > since > > > they are listed in that previous article as a significant Internet > > presence) > > > > > > > > > > > > Also, please tell me your feelings/experiences of Sparkle as an > Internet > > > uplink provider. like for 10/100 gig. > > > > > > > > > > > > My coworker just got back from ITW/Chicago and he is considering > Sparkle > > as > > > an additional Internet provider for the ISP I work for in San Antonio, > > TX . > > > we would need to uplink to Sparkle in the central Texas area somehow. > He > > > mentioned that Sparkle may be in McAllen / Dallas and could possibly, > in > > the > > > future be in Austin or San Antonio > > > > > > > > > > > > > > > > > > - Aaron > > > From brak at gameservers.com Wed May 16 16:38:11 2018 From: brak at gameservers.com (Brian Rak) Date: Wed, 16 May 2018 12:38:11 -0400 Subject: ALTDB - Getting records removed In-Reply-To: References: <398B250423578A4E97AFE1B8B67C686C6503B50B@PDDCWMBXEX503.ctl.intranet> Message-ID: <27c4f17a-b859-e0af-405e-3a2a2d71c111@gameservers.com> Are you referring to auto-dbm@ email, or the db-admin@ one?  I emailed db-admin@ about 15 hours ago, and haven't heard back (although it didn't bounce this time!)  Not sure what sort of response time to expect from a free service though. On 5/16/2018 12:17 PM, mike.lyon at gmail.com wrote: > As stated yesterday, email was fixed on AltDB yesterday. Please try again. > > Thanks, > Mike > >> On May 16, 2018, at 08:55, Delacruz, Anthony B wrote: >> >> Ditto also interested have dozens of old entries from previous delegations would like to see cleaned up but my google-foo tells me it's been a nonresponsive black hole several years now that probably should just go away if it's not going to be maintained properly. I think my favorite is the "Is anyone still maintaining altdb.net? thread from April 2011. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Hurley >> Sent: Saturday, May 12, 2018 11:16 AM >> To: nanog at nanog.org >> Subject: ALTDB - Getting records removed >> >> Hi All, >> >> Recently acquired a new 2-byte AS number from ARIN. It had a previous owner >> whom had records setup at ALTDB. >> >> I've sent emails to request removal but haven't heard anything back. >> >> Any tips or a different venue I can use to get in touch with the altdb >> folks? >> >> >> This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From hank at efes.iucc.ac.il Wed May 16 16:40:44 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 16 May 2018 19:40:44 +0300 Subject: internet - sparkle In-Reply-To: References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <1526482775.local-9a47e3e8-0ba9-v1.2.1-7e7447b6@getmailspring.com> Message-ID: On 16/05/2018 19:12, Michael Crapse wrote: HE listed currently in 7th place: http://as-rank.caida.org/ -Hank > Additionally, whilst not "technically" a tier 1 provider, Hurricane > electric should be high on that list. Especially as one of the best > providers of and proponents for IPv6. We'll see into the future, HE may > have one of the most critical infrastructures, and should be a "part-owner" > of the internet. > From akajtar at wadsworthcity.org Wed May 16 13:22:54 2018 From: akajtar at wadsworthcity.org (Adam Kajtar) Date: Wed, 16 May 2018 09:22:54 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: I could use static routes but I noticed since I moved to full routes I have had a lot fewer customer complaints about latency(especially when it comes to Voice and VPN traffic). I wasn't using per-packet load balancing. I believe juniper default is per IP. My timers are as follows Active Holdtime: 90 Keepalive Interval: 30 Would I be correct in thinking I need to contact my ISP to lower these values? An interesting note is when I had both ISPs connected into a single MX104 the failover was just a few seconds. Thanks again. On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > Have you checked your timeouts ? > > -Ben > > > On May 15, 2018, at 4:09 PM, Kaiser, Erich wrote: > > > > Do you need full routes? What about just a default route from BGP? > > > > Erich Kaiser > > The Fusion Network > > erich at gotfusion.net > > Office: 815-570-3101 > > > > > > > > > >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould wrote: > >> > >> You sure it doesn't have something to do with 60 seconds * 3 = 180 secs > of > >> BGP neighbor Time out before it believes neighbor is dead and remove > routes > >> to that neighbor? > >> > >> Aaron > >> > >>> On May 15, 2018, at 9:10 AM, Adam Kajtar > >> wrote: > >>> > >>> Hello: > >>> > >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running > >>> BGP(full routes). iBGP is running between the routers via a two port > 20G > >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes for > >>> traffic to start flowing correctly. The router has the correct route in > >> the > >>> routing table, but it doesn't install it in the forwarding table for > the > >>> full two mins. > >>> > >>> I have a few questions if anyone could answer them. > >>> > >>> - What would a usual convergence time be for this setup? > >>> - Is there anything I could do speed this process up? (I tried > >> Multipath) > >>> - Any tips and tricks would be much appreciated > >>> > >>> Thanks in Advance > >>> -- > >>> Adam Kajtar > >>> Systems Administrator > >>> City of Wadsworth > >>> akajtar at wadsworthcity.org > >>> ----------------------------------------------------- > >>> http://www.wadsworthcity.com > >>> > >>> Facebook * |* Twitter > >>> *|* Instagram > >>> *|* YouTube > >>> > >> > >> > -- Adam Kajtar Systems Administrator, Safety Services City of Wadsworth Office 330.335.2865 Cell 330.485.6510 akajtar at wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook * |* Twitter *|* Instagram *|* YouTube From akajtar at wadsworthcity.org Wed May 16 14:32:27 2018 From: akajtar at wadsworthcity.org (Adam Kajtar) Date: Wed, 16 May 2018 10:32:27 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: Erich, Good Idea. I can't believe I didn't think of that earlier. Simple and effective. I will go ahead and request the defaults from my ISP and update the thread of the findings. Thanks! On Wed, May 16, 2018 at 10:03 AM Kaiser, Erich wrote: > A last resort route (default route) could still be good to take from your > ISP(s) even if you still do full routes, as the propagation is happening on > the internet side, you should at least have a path inbound through the > other provider. The default route at least would send the traffic out if > it does not see the route locally. Just an idea. > > > > On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar > wrote: > > > I could use static routes but I noticed since I moved to full routes I > > have had a lot fewer customer complaints about latency(especially when it > > comes to Voice and VPN traffic). > > > > I wasn't using per-packet load balancing. I believe juniper default is > per > > IP. > > > > My timers are as follows > > Active Holdtime: 90 > > Keepalive Interval: 30 > > > > Would I be correct in thinking I need to contact my ISP to lower these > > values? > > > > An interesting note is when I had both ISPs connected into a single MX104 > > the failover was just a few seconds. > > > > Thanks again. > > > > > > > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > > > >> Have you checked your timeouts ? > >> > >> -Ben > >> > >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich > wrote: > >> > > >> > Do you need full routes? What about just a default route from BGP? > >> > > >> > Erich Kaiser > >> > The Fusion Network > >> > erich at gotfusion.net > >> > Office: 815-570-3101 > >> > > >> > > >> > > >> > > >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould > wrote: > >> >> > >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180 > >> secs of > >> >> BGP neighbor Time out before it believes neighbor is dead and remove > >> routes > >> >> to that neighbor? > >> >> > >> >> Aaron > >> >> > >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar > > >> >> wrote: > >> >>> > >> >>> Hello: > >> >>> > >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running > >> >>> BGP(full routes). iBGP is running between the routers via a two port > >> 20G > >> >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes > for > >> >>> traffic to start flowing correctly. The router has the correct route > >> in > >> >> the > >> >>> routing table, but it doesn't install it in the forwarding table for > >> the > >> >>> full two mins. > >> >>> > >> >>> I have a few questions if anyone could answer them. > >> >>> > >> >>> - What would a usual convergence time be for this setup? > >> >>> - Is there anything I could do speed this process up? (I tried > >> >> Multipath) > >> >>> - Any tips and tricks would be much appreciated > >> >>> > >> >>> Thanks in Advance > >> >>> -- > >> >>> Adam Kajtar > >> >>> Systems Administrator > >> >>> City of Wadsworth > >> >>> akajtar at wadsworthcity.org > >> >>> ----------------------------------------------------- > >> >>> http://www.wadsworthcity.com > >> >>> > >> >>> Facebook * |* Twitter > >> >>> *|* Instagram > >> >>> *|* YouTube > >> >>> > >> >> > >> >> > >> > > > > > > -- > > Adam Kajtar > > Systems Administrator, Safety Services > > City of Wadsworth > > Office 330.335.2865 > > Cell 330.485.6510 > > akajtar at wadsworthcity.org > > ----------------------------------------------------- > > http://www.wadsworthcity.com > > > > Facebook * |* Twitter > > *|* Instagram > > *|* YouTube > > > > > -- Adam Kajtar Systems Administrator, Safety Services City of Wadsworth Office 330.335.2865 Cell 330.485.6510 akajtar at wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook * |* Twitter *|* Instagram *|* YouTube From chano79thstreet at gmail.com Wed May 16 09:55:58 2018 From: chano79thstreet at gmail.com (~) Date: Wed, 16 May 2018 10:55:58 +0100 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: To me then the Anker AK-A7611011 sounds perfect. It has indicator lights, good build quality and uses said Realtek chip. On Wed, 16 May 2018, 01:51 Colton Conor, wrote: > Mario, > > Thanks for the recommendation. I am leaning towards the devices with > a Realtek RTL8153 chipset over the devices with the Axis AX88179. I have > more faith in Realtek than AXIS as I have had serveral laptops in the past > with Realtek NIC's, but never a single device with AXIS. Plus Realtek seems > to be more standards based whereas AXIS only supports 4k Jumbo frames? > > On Mon, May 14, 2018 at 9:35 PM, Mario Eirea > wrote: > > > My recommendation was based on the Realtek RTL8153 chipset. It's the only > > USB chip I had found at the time that did VLANs and full gigabit, in > > Windows. I have had this for a while now, I would hope there are more > > things on the market. > > > > > > -ME > > ------------------------------ > > *From:* NANOG on behalf of Colton Conor < > > colton.conor at gmail.com> > > *Sent:* Monday, May 14, 2018 9:20 PM > > *To:* NANOG > > *Subject:* Re: USB Ethernet Adapters > > > > Thanks for the responses so far. I am surprised to see the wide array of > > responses. A couple of more things: > > > > 1. I like the ones that have lights on the Ethernet port so you can see > if > > the device is up/down. I find that critical as we go to a lot of sites > > where we don't know if the cable is good/bad, so a indication on the > lights > > is critical. > > 2. Techs are constantly doing speedtest.net tests on 1Gbps Ethernet > > connections, so ideally an adapter that can constantly push the 1Gbps > > speeds is ideally. > > > > Seems that most of these adapters use a common chipset. Anyone done > > research on which chipset is the best, and why? > > > > On Mon, May 14, 2018 at 12:45 PM, Colton Conor > > wrote: > > > > > Our new laptops like most do not have an Ethernet adapter build in as > > they > > > are too slim. What USB to Ethernet adapter do you recommend and why? > > > Ideally it would be compatible with Windows 10, and have the ability to > > set > > > speed, duplex and VLAN IDs if possible. > > > > > > From cyprien at consultic.be Wed May 16 12:13:23 2018 From: cyprien at consultic.be (ConsulTIC - Cyprien Laleau) Date: Wed, 16 May 2018 12:13:23 +0000 Subject: ProofPoint Message-ID: Could a proofpoint e-mail blacklist contact, contact me? We are trying to solve undelivered mails and can't get ahold of anyone. Thank you in advance, From dhubbard at dino.hostasaurus.com Wed May 16 16:59:42 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 16 May 2018 16:59:42 +0000 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) Message-ID: I’m curious if anyone who’s used 3356 for transit has found shortcomings in how their peering and redundancy is configured, or what a normal expectation to have is. The Tampa Bay market has been completely down for 3356 IP services twice so far this year, each for what I’d consider an unacceptable period of time (many hours). I’m learning that the entire market is served by just two fiber routes, through cities hundreds of miles away in either direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes the entire region down. The most recent occurrence was a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP services down for hours. It did not take point to point circuits to out of market locations down, so that suggests they even have the ability to be more redundant and simply choose not to. I feel like it’s not unreasonable to expect more redundancy, or a much smaller attack surface given a disgruntled lineman who knows the routes could take an entire region down with a planned cut four states apart. Maybe other regions are better designed? Or are my expectations unreasonable? I carry three peers in that market, so it hasn’t been outage-causing, but I use 3356 in other markets too, and have plans for more, but it makes me wonder if I just haven't had the pleasure of similar outages elsewhere yet and I should factor that expectation into the design. It creates a problem for me in one location where I can only get them and Cogent, since Cogent can't be relied on for IPv6 service, which I need. Thanks From jheitz at cisco.com Wed May 16 17:06:45 2018 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Wed, 16 May 2018 17:06:45 +0000 Subject: is odd number of links in lag group ok Message-ID: Many routers do not rehash everything when a link breaks. Doing so would disturb flows that were not broken, causing possible misordered packets or jitter. The flows on the broken link will get rehashed, of course. Note that even if a hash function can distribute the flows evenly, you may get some heavy flows, so you need to expect some imbalance. Regards, Jakob -----Original Message----- From: Ben Cannon It will work fine if you have a good modern router. Consider this; all evenly grouped LAGs are odd in their failed conditions. -Ben > On May 15, 2018, at 8:28 AM, Mark Tinka wrote: > > > >> On 15/May/18 17:20, Jared Mauch wrote: >> >> Much of this depends on the hardware, software and what hashing is used inbound >> outbound traffic directions, etc. >> >> It will likely work the way you expect, but one may be warmer than the other if >> traffic ends up overloading a single bucket in the hash. > > We haven't had a major issue when loading traffic over even or odd > links. If you have decent hardware and software, it should all be fine, > particularly if your traffic is all or mostly IP. > > If you've got non-IP traffic in there, and your box cannot look into the > payload to determine entropy, then things could get interesting. But > this will happen even when you have even links... it's not anything > specific to how many member links you have in the LAG, but rather, the > router's need to maintain per-flow load balancing with limited > information beyond Layer 2 data. > > That said, an even number of links just leaves the warm & fuzzies turned > on :-)... > > Mark. From jarenangerbauer at gmail.com Wed May 16 17:21:49 2018 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Wed, 16 May 2018 10:21:49 -0700 Subject: ProofPoint In-Reply-To: References: Message-ID: On Wed, May 16, 2018 at 5:13 AM, ConsulTIC - Cyprien Laleau via NANOG < nanog at nanog.org> wrote: > Could a proofpoint e-mail blacklist contact, contact me? > We are trying to solve undelivered mails and can't get ahold of anyone. > > Thank you in advance, > Responded off list. Thanks, --Jaren From james.cutler at consultant.com Wed May 16 17:23:41 2018 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 16 May 2018 13:23:41 -0400 Subject: USB Ethernet Adapters In-Reply-To: References: Message-ID: <1B65C8D3-2226-4BBC-905C-5BA478D02EB6@consultant.com> > On May 16, 2018, at 5:55 AM, ~ wrote: > > AK-A7611011 The Anker USB-C to Ethernet adapter also uses the Realtek 0x8153 chip. From akajtar at wadsworthcity.org Wed May 16 17:43:24 2018 From: akajtar at wadsworthcity.org (Adam Kajtar) Date: Wed, 16 May 2018 13:43:24 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: I did exactly that when I called. One is looking into the other hasn't called yet. I will let you know what they say. On Wed, May 16, 2018 at 12:59 PM Phil Lavin wrote: > Ask if they will configure BFD for you. I’ve not found many transit > providers that will, but it’s worth a shot and it will lower failure > detection to circa 1 second. > > > > On 16 May 2018, at 17:49, Adam Kajtar wrote: > > > > I could use static routes but I noticed since I moved to full routes I > have > > had a lot fewer customer complaints about latency(especially when it > comes > > to Voice and VPN traffic). > > > > I wasn't using per-packet load balancing. I believe juniper default is > per > > IP. > > > > My timers are as follows > > Active Holdtime: 90 > > Keepalive Interval: 30 > > > > Would I be correct in thinking I need to contact my ISP to lower these > > values? > > > > An interesting note is when I had both ISPs connected into a single MX104 > > the failover was just a few seconds. > > > > Thanks again. > > > > > > > >> On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > >> > >> Have you checked your timeouts ? > >> > >> -Ben > >> > >>> On May 15, 2018, at 4:09 PM, Kaiser, Erich > wrote: > >>> > >>> Do you need full routes? What about just a default route from BGP? > >>> > >>> Erich Kaiser > >>> The Fusion Network > >>> erich at gotfusion.net > >>> Office: 815-570-3101 > >>> > >>> > >>> > >>> > >>>> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould wrote: > >>>> > >>>> You sure it doesn't have something to do with 60 seconds * 3 = 180 > secs > >> of > >>>> BGP neighbor Time out before it believes neighbor is dead and remove > >> routes > >>>> to that neighbor? > >>>> > >>>> Aaron > >>>> > >>>>> On May 15, 2018, at 9:10 AM, Adam Kajtar > >>>> wrote: > >>>>> > >>>>> Hello: > >>>>> > >>>>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running > >>>>> BGP(full routes). iBGP is running between the routers via a two port > >> 20G > >>>>> lag. When one of the ISPs fails, it can take upwards of 2 minutes for > >>>>> traffic to start flowing correctly. The router has the correct route > in > >>>> the > >>>>> routing table, but it doesn't install it in the forwarding table for > >> the > >>>>> full two mins. > >>>>> > >>>>> I have a few questions if anyone could answer them. > >>>>> > >>>>> - What would a usual convergence time be for this setup? > >>>>> - Is there anything I could do speed this process up? (I tried > >>>> Multipath) > >>>>> - Any tips and tricks would be much appreciated > >>>>> > >>>>> Thanks in Advance > >>>>> -- > >>>>> Adam Kajtar > >>>>> Systems Administrator > >>>>> City of Wadsworth > >>>>> akajtar at wadsworthcity.org > >>>>> ----------------------------------------------------- > >>>>> http://www.wadsworthcity.com > >>>>> > >>>>> Facebook * |* Twitter > >>>>> *|* Instagram > >>>>> *|* YouTube > >>>>> > >>>> > >>>> > >> > > > > > > -- > > Adam Kajtar > > Systems Administrator, Safety Services > > City of Wadsworth > > Office 330.335.2865 > > Cell 330.485.6510 > > akajtar at wadsworthcity.org > > ----------------------------------------------------- > > http://www.wadsworthcity.com > > > > Facebook * |* Twitter > > *|* Instagram > > *|* YouTube > > > -- Adam Kajtar Systems Administrator, Safety Services City of Wadsworth Office 330.335.2865 Cell 330.485.6510 akajtar at wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook * |* Twitter *|* Instagram *|* YouTube From mark.tinka at seacom.mu Wed May 16 18:34:30 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 16 May 2018 20:34:30 +0200 Subject: internet - sparkle In-Reply-To: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> Message-ID: <0f08ee8c-55ba-c1a1-7b1b-17bf85878b1d@seacom.mu> On 16/May/18 16:54, Aaron Gould wrote: > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is it > still accurate ? (asking since my next question is related to Sparkle, since > they are listed in that previous article as a significant Internet presence) I don't know about "owning" the Internet, but I would agree with the article re: the 7 key global transit providers as things stand in 2018. It matches up with our own compliment of transit providers in our network (AS37100). > > > My coworker just got back from ITW/Chicago and he is considering Sparkle as > an additional Internet provider for the ISP I work for in San Antonio, TX . > we would need to uplink to Sparkle in the central Texas area somehow. He > mentioned that Sparkle may be in McAllen / Dallas and could possibly, in the > future be in Austin or San Antonio My initial experience with TI Sparkle was in South East Asia back in '08. They were decent. We have them in our stable, and like them for their South American coverage. Mark. From jared at compuwizz.net Wed May 16 19:31:35 2018 From: jared at compuwizz.net (Jared Geiger) Date: Wed, 16 May 2018 12:31:35 -0700 Subject: internet - sparkle In-Reply-To: <0f08ee8c-55ba-c1a1-7b1b-17bf85878b1d@seacom.mu> References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <0f08ee8c-55ba-c1a1-7b1b-17bf85878b1d@seacom.mu> Message-ID: If most of your traffic is for US based destinations, you might see worse performance since Sparkle doesn't seem to have many US POPs/Peering locations compared to Centurylink/Level3 or HE. You'd probably benefit more by pulling in some peering from Dallas than adding or replacing a transit provider as your current mix is decent for an eyeball network. Pick up peering with Cloudflare, Netflix, Amazon, EdgeCast, Facebook, Apple, Akamai, and Microsoft in Dallas and you might even be able to get rid of one of your transit providers. Sparkle would "shine" if you were a US hosting provider with many eyeballs in Europe/Africa/Middle East. On Wed, May 16, 2018 at 11:34 AM, Mark Tinka wrote: > > > On 16/May/18 16:54, Aaron Gould wrote: > > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is > it > > still accurate ? (asking since my next question is related to Sparkle, > since > > they are listed in that previous article as a significant Internet > presence) > > I don't know about "owning" the Internet, but I would agree with the > article re: the 7 key global transit providers as things stand in 2018. > > It matches up with our own compliment of transit providers in our > network (AS37100). > > > > > > > > My coworker just got back from ITW/Chicago and he is considering Sparkle > as > > an additional Internet provider for the ISP I work for in San Antonio, > TX . > > we would need to uplink to Sparkle in the central Texas area somehow. He > > mentioned that Sparkle may be in McAllen / Dallas and could possibly, in > the > > future be in Austin or San Antonio > > My initial experience with TI Sparkle was in South East Asia back in > '08. They were decent. > > We have them in our stable, and like them for their South American > coverage. > > Mark. > From listas at kurtkraut.net Wed May 16 19:52:24 2018 From: listas at kurtkraut.net (Kurt Kraut) Date: Wed, 16 May 2018 16:52:24 -0300 Subject: internet - sparkle In-Reply-To: References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <0f08ee8c-55ba-c1a1-7b1b-17bf85878b1d@seacom.mu> Message-ID: Hello, Also Sparkle (AS6762) has a significant footprint in South America, I'd say even bigger than Level 3 because they have mobile telco and broadband ISP in Brazil. I wouldn't worry much with latency in NA because at least in South America they do hot potato (as everyone does) and all their PoPs exchange traffic with at least Level 3. So I suspect traffic hardly ever exits their PoP within their network. Best regards, Kurt Kraut Em qua, 16 de mai de 2018 às 16:32, Jared Geiger escreveu: > If most of your traffic is for US based destinations, you might see worse > performance since Sparkle doesn't seem to have many US POPs/Peering > locations compared to Centurylink/Level3 or HE. You'd probably benefit more > by pulling in some peering from Dallas than adding or replacing a transit > provider as your current mix is decent for an eyeball network. Pick up > peering with Cloudflare, Netflix, Amazon, EdgeCast, Facebook, Apple, > Akamai, and Microsoft in Dallas and you might even be able to get rid of > one of your transit providers. > > Sparkle would "shine" if you were a US hosting provider with many eyeballs > in Europe/Africa/Middle East. > > On Wed, May 16, 2018 at 11:34 AM, Mark Tinka wrote: > > > > > > > On 16/May/18 16:54, Aaron Gould wrote: > > > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is > > it > > > still accurate ? (asking since my next question is related to Sparkle, > > since > > > they are listed in that previous article as a significant Internet > > presence) > > > > I don't know about "owning" the Internet, but I would agree with the > > article re: the 7 key global transit providers as things stand in 2018. > > > > It matches up with our own compliment of transit providers in our > > network (AS37100). > > > > > > > > > > > > > My coworker just got back from ITW/Chicago and he is considering > Sparkle > > as > > > an additional Internet provider for the ISP I work for in San Antonio, > > TX . > > > we would need to uplink to Sparkle in the central Texas area somehow. > He > > > mentioned that Sparkle may be in McAllen / Dallas and could possibly, > in > > the > > > future be in Austin or San Antonio > > > > My initial experience with TI Sparkle was in South East Asia back in > > '08. They were decent. > > > > We have them in our stable, and like them for their South American > > coverage. > > > > Mark. > > > From Brian at ampr.org Wed May 16 21:02:00 2018 From: Brian at ampr.org (Brian Kantor) Date: Wed, 16 May 2018 14:02:00 -0700 Subject: Whois vs GDPR, latest news Message-ID: <20180516210200.GA50835@meow.BKantor.net> A draft of the new ICANN Whois policy was published a few days ago. https://www.icann.org/en/system/files/files/proposed-gtld-registration-data-temp-specs-14may18-en.pdf >From that document: "This Temporary Specification for gTLD Registration Data (Temporary Specification) establishes temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies in light of the GDPR. Consistent with ICANN’s stated objective to comply with the GDPR, while maintaining the existing WHOIS system to the greatest extent possible, the Temporary Specification maintains robust collection of Registration Data (including Registrant, Administrative, and Technical contact information), but restricts most Personal Data to layered/tiered access. Users with a legitimate and proportionate purpose for accessing the non-public Personal Data will be able to request such access through Registrars and Registry Operators. Users will also maintain the ability to contact the Registrant or Administrative and Technical contacts through an anonymized email or web form. The Temporary Specification shall be implemented where required by the GDPR, while providing flexibility to Registry Operators and Registrars to choose to apply the requirements on a global basis based on implementation, commercial reasonableness and fairness considerations. The Temporary Specification applies to all registrations, without requiring Registrars to differentiate between registrations of legal and natural persons. It also covers data processing arrangements between and among ICANN, Registry Operators, Registrars, and Data Escrow Agents as necessary for compliance with the GDPR." From mureninc at gmail.com Wed May 16 21:10:13 2018 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 16 May 2018 16:10:13 -0500 Subject: Whois vs GDPR, latest news In-Reply-To: <20180516210200.GA50835@meow.BKantor.net> References: <20180516210200.GA50835@meow.BKantor.net> Message-ID: I think this is the worst of both worlds. The data is basically still public, but you cannot access it unless someone marks you as a "friend". This policy is basically what Facebook is. And how well it played out once folks realised that their shared data wasn't actually private? C. On 16 May 2018 at 16:02, Brian Kantor wrote: > A draft of the new ICANN Whois policy was published a few days ago. > > https://www.icann.org/en/system/files/files/proposed-gtld-registration-data-temp-specs-14may18-en.pdf > > From that document: > > "This Temporary Specification for gTLD Registration Data (Temporary > Specification) establishes temporary requirements to allow ICANN > and gTLD registry operators and registrars to continue to comply > with existing ICANN contractual requirements and community-developed > policies in light of the GDPR. Consistent with ICANN’s stated > objective to comply with the GDPR, while maintaining the existing > WHOIS system to the greatest extent possible, the Temporary > Specification maintains robust collection of Registration Data > (including Registrant, Administrative, and Technical contact > information), but restricts most Personal Data to layered/tiered > access. Users with a legitimate and proportionate purpose for > accessing the non-public Personal Data will be able to request > such access through Registrars and Registry Operators. Users will > also maintain the ability to contact the Registrant or Administrative > and Technical contacts through an anonymized email or web form. The > Temporary Specification shall be implemented where required by the > GDPR, while providing flexibility to Registry Operators and Registrars > to choose to apply the requirements on a global basis based on > implementation, commercial reasonableness and fairness considerations. > The Temporary Specification applies to all registrations, without > requiring Registrars to differentiate between registrations of legal > and natural persons. It also covers data processing arrangements > between and among ICANN, Registry Operators, Registrars, and Data > Escrow Agents as necessary for compliance with the GDPR." From aaron1 at gvtc.com Wed May 16 21:35:54 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 16 May 2018 16:35:54 -0500 Subject: internet - sparkle In-Reply-To: References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <0f08ee8c-55ba-c1a1-7b1b-17bf85878b1d@seacom.mu> Message-ID: <78A466DD-834F-4F67-B84F-A35F99B03D2F@gvtc.com> Thanks. What's an eyeball network ? How do you know my "current mix is decent" ? Btw, I have onsite the cdn's aanp, ggc, oca, fna, so only about ~60% of my customer traffic is from Internet uplinks... ~40% is served from local cdn's Aaron > On May 16, 2018, at 2:31 PM, Jared Geiger wrote: > > If most of your traffic is for US based destinations, you might see worse performance since Sparkle doesn't seem to have many US POPs/Peering locations compared to Centurylink/Level3 or HE. You'd probably benefit more by pulling in some peering from Dallas than adding or replacing a transit provider as your current mix is decent for an eyeball network. Pick up peering with Cloudflare, Netflix, Amazon, EdgeCast, Facebook, Apple, Akamai, and Microsoft in Dallas and you might even be able to get rid of one of your transit providers. > > Sparkle would "shine" if you were a US hosting provider with many eyeballs in Europe/Africa/Middle East. > >> On Wed, May 16, 2018 at 11:34 AM, Mark Tinka wrote: >> >> >> On 16/May/18 16:54, Aaron Gould wrote: >> > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is it >> > still accurate ? (asking since my next question is related to Sparkle, since >> > they are listed in that previous article as a significant Internet presence) >> >> I don't know about "owning" the Internet, but I would agree with the >> article re: the 7 key global transit providers as things stand in 2018. >> >> It matches up with our own compliment of transit providers in our >> network (AS37100). >> >> >> > >> > >> > My coworker just got back from ITW/Chicago and he is considering Sparkle as >> > an additional Internet provider for the ISP I work for in San Antonio, TX . >> > we would need to uplink to Sparkle in the central Texas area somehow. He >> > mentioned that Sparkle may be in McAllen / Dallas and could possibly, in the >> > future be in Austin or San Antonio >> >> My initial experience with TI Sparkle was in South East Asia back in >> '08. They were decent. >> >> We have them in our stable, and like them for their South American coverage. >> >> Mark. > From surfer at mauigateway.com Wed May 16 21:40:54 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 16 May 2018 14:40:54 -0700 Subject: internet - sparkle Message-ID: <20180516144054.69C27383@m0117568.ppops.net> --- aaron1 at gvtc.com wrote: From: Aaron Gould What's an eyeball network ? ----------------------------------------------- https://en.wikipedia.org/wiki/Eyeball_network scott From craigwashington01 at hotmail.com Wed May 16 21:45:00 2018 From: craigwashington01 at hotmail.com (craig washington) Date: Wed, 16 May 2018 21:45:00 +0000 Subject: internet - sparkle In-Reply-To: References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <1526482775.local-9a47e3e8-0ba9-v1.2.1-7e7447b6@getmailspring.com> Message-ID: Agree with this 💯 Traffic engineering is non existent making it a pain to move your traffic besides not advertising the prefix to them Sent from my iPhone > On May 16, 2018, at 12:33 PM, Ca By wrote: > >> On Wed, May 16, 2018 at 9:14 AM Michael Crapse wrote: >> >> Additionally, whilst not "technically" a tier 1 provider, Hurricane >> electric should be high on that list. Especially as one of the best >> providers of and proponents for IPv6. We'll see into the future, HE may >> have one of the most critical infrastructures, and should be a "part-owner" >> of the internet. >> > > Fully disagree. > > 1). HE cant reach cogent on v6. Forget whos fault it is, it is a liability > for anyone that relies on HE > > 2). They dont support common bgp communities like no-export, so trying to > do TE is a mess. > > 3). They are at the center of nearly every bgp hijacking fiasco because > they dont have reasonable route controls. > > HE is a liability to us all until they fix their bgp filters > > https://www.internetsociety.org/blog/2018/04/amazons-route-53-bgp-hijack/ > > > > >>> On Wed, May 16, 2018, 8:08 AM Eric Dugas wrote: >>> >>> Replace Level3 with CenturyLink as they're basically taking over AS33566. >>> Would add Zayo (AS6461) to the list. >>> >>> I'm not familiar with Sparkle/Seabone to be honest as we're operating an >>> eyeball network exclusively in the NA. >>>> On May 16 2018, at 10:54 am, Aaron Gould wrote: >>>> >>>> http://icaruswept.com/2016/06/28/who-owns-the-internet/ >>>> >>>> >>>> .written in 12/2015 - do y'all think this is accurate, and, in 2018, is >>> it >>>> still accurate ? (asking since my next question is related to Sparkle, >>> since >>>> they are listed in that previous article as a significant Internet >>> presence) >>>> >>>> >>>> >>>> Also, please tell me your feelings/experiences of Sparkle as an >> Internet >>>> uplink provider. like for 10/100 gig. >>>> >>>> >>>> >>>> My coworker just got back from ITW/Chicago and he is considering >> Sparkle >>> as >>>> an additional Internet provider for the ISP I work for in San Antonio, >>> TX . >>>> we would need to uplink to Sparkle in the central Texas area somehow. >> He >>>> mentioned that Sparkle may be in McAllen / Dallas and could possibly, >> in >>> the >>>> future be in Austin or San Antonio >>>> >>>> >>>> >>>> >>>> >>>> - Aaron >>> >> From mark.tinka at seacom.mu Wed May 16 22:39:22 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 17 May 2018 00:39:22 +0200 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: <0c9539e3-b8a1-eb34-b701-2a0ae39ae5da@seacom.mu> On 16/May/18 18:59, David Hubbard wrote: > I’m curious if anyone who’s used 3356 for transit has found shortcomings in how their peering and redundancy is configured, or what a normal expectation to have is. The Tampa Bay market has been completely down for 3356 IP services twice so far this year, each for what I’d consider an unacceptable period of time (many hours). I’m learning that the entire market is served by just two fiber routes, through cities hundreds of miles away in either direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes the entire region down. The most recent occurrence was a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP services down for hours. It did not take point to point circuits to out of market locations down, so that suggests they even have the ability to be more redundant and simply choose not to. > > I feel like it’s not unreasonable to expect more redundancy, or a much smaller attack surface given a disgruntled lineman who knows the routes could take an entire region down with a planned cut four states apart. Maybe other regions are better designed? Or are my expectations unreasonable? I carry three peers in that market, so it hasn’t been outage-causing, but I use 3356 in other markets too, and have plans for more, but it makes me wonder if I just haven't had the pleasure of similar outages elsewhere yet and I should factor that expectation into the design. It creates a problem for me in one location where I can only get them and Cogent, since Cogent can't be relied on for IPv6 service, which I need. Are Century Link your only option? Mark. From web at typo.org Wed May 16 22:48:24 2018 From: web at typo.org (Wayne Bouchard) Date: Wed, 16 May 2018 15:48:24 -0700 Subject: is odd number of links in lag group ok In-Reply-To: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> Message-ID: <20180516224824.GA85770@spider.typo.org> As others have noted, there can be implementation specific issues that you can't necessarily predict but most typically when I hear "odd vs even" discussions, usually the caveat is not a trunk but a redundant connection. Putting three links on router A and two links on router B obviously doesn't work well. On Tue, May 15, 2018 at 10:15:19AM -0500, Aaron Gould wrote: > I have (2) 10 gig links bundled in a lag to my upstream internet provider. > and we need more internet capacity. Is it cool to add a third 10 gig to my > existing 20 gig lag internet connection? > > > > I'm asking since I heard in the past something negative about odd numbers of > lag members. .but I also have heard that it's not a big deal. Let me know > please > > > > -Aaron > > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From bellman at nsc.liu.se Wed May 16 23:32:53 2018 From: bellman at nsc.liu.se (Thomas Bellman) Date: Thu, 17 May 2018 01:32:53 +0200 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: <5aa1ca2f-f36a-5a37-4cfd-18b1a8507554@nsc.liu.se> On 2018-05-16 15:22, Adam Kajtar wrote: > I wasn't using per-packet load balancing. I believe juniper default is per > IP. The Juniper default is to not do ECMP at all. Only a single route is programmed into the FIB for each prefix in your RIB. If you e.g. have routes to 198.51.100.0/24 pointing to ten different ports, all traffic to that entire /24 will go out over a single port, unless you have explicitly enabled ECMP. To enable ECMP, you need this: policy-options { policy-statement ecmp { then { load-balance per-packet; } } } routing-options { forwarding-table { export ecmp; } } in your configuration. Note also that "per-packet" is a mis-nomer; it is really "per flow", based on a hash of the L3/L4 headers. 'show route forwarding-table destination 198.51.100.0/24' shows if you actually have multiple routes in your FIB. /Bellman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jared at compuwizz.net Wed May 16 23:41:56 2018 From: jared at compuwizz.net (Jared Geiger) Date: Wed, 16 May 2018 16:41:56 -0700 Subject: internet - sparkle In-Reply-To: <78A466DD-834F-4F67-B84F-A35F99B03D2F@gvtc.com> References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <0f08ee8c-55ba-c1a1-7b1b-17bf85878b1d@seacom.mu> <78A466DD-834F-4F67-B84F-A35F99B03D2F@gvtc.com> Message-ID: I assumed your AS number is 16527 and looked up who you currently are peering with. On Wed, May 16, 2018 at 2:35 PM, Aaron Gould wrote: > Thanks. > > What's an eyeball network ? > > How do you know my "current mix is decent" ? > > Btw, I have onsite the cdn's aanp, ggc, oca, fna, so only about ~60% of my > customer traffic is from Internet uplinks... ~40% is served from local > cdn's > > > Aaron > > > On May 16, 2018, at 2:31 PM, Jared Geiger wrote: > > > > If most of your traffic is for US based destinations, you might see > worse performance since Sparkle doesn't seem to have many US POPs/Peering > locations compared to Centurylink/Level3 or HE. You'd probably benefit more > by pulling in some peering from Dallas than adding or replacing a transit > provider as your current mix is decent for an eyeball network. Pick up > peering with Cloudflare, Netflix, Amazon, EdgeCast, Facebook, Apple, > Akamai, and Microsoft in Dallas and you might even be able to get rid of > one of your transit providers. > > > > Sparkle would "shine" if you were a US hosting provider with many > eyeballs in Europe/Africa/Middle East. > > > >> On Wed, May 16, 2018 at 11:34 AM, Mark Tinka > wrote: > >> > >> > >> On 16/May/18 16:54, Aaron Gould wrote: > >> > .written in 12/2015 - do y'all think this is accurate, and, in 2018, > is it > >> > still accurate ? (asking since my next question is related to > Sparkle, since > >> > they are listed in that previous article as a significant Internet > presence) > >> > >> I don't know about "owning" the Internet, but I would agree with the > >> article re: the 7 key global transit providers as things stand in 2018. > >> > >> It matches up with our own compliment of transit providers in our > >> network (AS37100). > >> > >> > >> > > >> > > >> > My coworker just got back from ITW/Chicago and he is considering > Sparkle as > >> > an additional Internet provider for the ISP I work for in San > Antonio, TX . > >> > we would need to uplink to Sparkle in the central Texas area > somehow. He > >> > mentioned that Sparkle may be in McAllen / Dallas and could possibly, > in the > >> > future be in Austin or San Antonio > >> > >> My initial experience with TI Sparkle was in South East Asia back in > >> '08. They were decent. > >> > >> We have them in our stable, and like them for their South American > coverage. > >> > >> Mark. > > > From aaron1 at gvtc.com Thu May 17 00:00:51 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 16 May 2018 19:00:51 -0500 Subject: Juniper BGP Convergence Time In-Reply-To: <5aa1ca2f-f36a-5a37-4cfd-18b1a8507554@nsc.liu.se> References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <5aa1ca2f-f36a-5a37-4cfd-18b1a8507554@nsc.liu.se> Message-ID: <5BBE1978-610D-4200-A2D7-86B675E6C90F@gvtc.com> While we are on ECMP topic... In L3VPN, when I've learned say, 3 different routes all using different MPLS tags to the 3 remote PE's, is there a way to ECMP hash across all of the paths to load balance? Aaron > On May 16, 2018, at 6:32 PM, Thomas Bellman wrote: > >> On 2018-05-16 15:22, Adam Kajtar wrote: >> >> I wasn't using per-packet load balancing. I believe juniper default is per >> IP. > > The Juniper default is to not do ECMP at all. Only a single route is > programmed into the FIB for each prefix in your RIB. If you e.g. have > routes to 198.51.100.0/24 pointing to ten different ports, all traffic > to that entire /24 will go out over a single port, unless you have > explicitly enabled ECMP. > > To enable ECMP, you need this: > > policy-options { > policy-statement ecmp { > then { > load-balance per-packet; > } > } > } > routing-options { > forwarding-table { > export ecmp; > } > } > > in your configuration. Note also that "per-packet" is a mis-nomer; it > is really "per flow", based on a hash of the L3/L4 headers. > > 'show route forwarding-table destination 198.51.100.0/24' shows if you > actually have multiple routes in your FIB. > > > /Bellman > From bzs at theworld.com Thu May 17 00:26:13 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 16 May 2018 20:26:13 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> Message-ID: <23292.52261.130019.955632@gargle.gargle.HOWL> On May 16, 2018 at 16:10 mureninc at gmail.com (Constantine A. Murenin) wrote: > I think this is the worst of both worlds. The data is basically still > public, but you cannot access it unless someone marks you as a > "friend". > > This policy is basically what Facebook is. And how well it played out > once folks realised that their shared data wasn't actually private? The problem is that once the data gets out it's out and in many cases such as this WHOIS data only stales very slowly. So one malicious breach or outlaw/misbehaving assignee and you may as well have done nothing. I suppose one could /reductio ad absurdum/ and ask so therefore do nothing? No, but perhaps more focus on misuse would be more productive. The penalties for violations of GDPR are eye-watering like 4% of gross revenues. That is, could be billions of dollars (or euros if you prefer.) We know how well all this has worked in 20+ years of spam-fighting which is to say not really well at all. It relies on this rather blue-sky model of the problem which is that abuse can be reigned in by putting pressure on people who actually answer their phone rather than abusers who generally don't. Another problem is the relatively unilateral approach of GDPR coming out of the EU yet promising application to any company with an EU nexus (or direct jurisdiction of course.) In that it resembles a tariff war. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From octalnanog at alvarezp.org Thu May 17 00:28:26 2018 From: octalnanog at alvarezp.org (Octavio Alvarez) Date: Wed, 16 May 2018 19:28:26 -0500 Subject: Email security: PGP/GPG & S/MIME vulnerability drop imminent In-Reply-To: <20180515093431.GB13432@gsp.org> References: <55F001A9-8F06-4C2D-8A6B-268319361B1E@gmail.com> <20180515093431.GB13432@gsp.org> Message-ID: <5ff50f79-779c-51ce-aa58-b7cff4babaa7@alvarezp.org> On 05/15/2018 04:34 AM, Rich Kulawiec wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: >> TL;DR = Don't use HTML email [snip] > > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. There is a need for rich-text these days. What is your proposal? From owen at delong.com Thu May 17 01:18:54 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2018 18:18:54 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <23292.52261.130019.955632@gargle.gargle.HOWL> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> Message-ID: At this point if I were a registrar or registry doing business in such a way as to be subject to gdpr, I’d seriously consider spinning up a subsidiary only for that purpose and leave it with minimal revenues and nothing to collect in the event of a lawsuit. Either that or simply stop doing business with Europeans until their government comes to its senses. Fortunately For now I get to watch from the sidelines with amusement as this unfolds. Owen > On May 16, 2018, at 17:26, bzs at theworld.com wrote: > > >> On May 16, 2018 at 16:10 mureninc at gmail.com (Constantine A. Murenin) wrote: >> I think this is the worst of both worlds. The data is basically still >> public, but you cannot access it unless someone marks you as a >> "friend". >> >> This policy is basically what Facebook is. And how well it played out >> once folks realised that their shared data wasn't actually private? > > The problem is that once the data gets out it's out and in many cases > such as this WHOIS data only stales very slowly. > > So one malicious breach or outlaw/misbehaving assignee and you may as > well have done nothing. > > I suppose one could /reductio ad absurdum/ and ask so therefore do > nothing? > > No, but perhaps more focus on misuse would be more productive. The > penalties for violations of GDPR are eye-watering like 4% of gross > revenues. That is, could be billions of dollars (or euros if you > prefer.) > > We know how well all this has worked in 20+ years of spam-fighting > which is to say not really well at all. > > It relies on this rather blue-sky model of the problem which is that > abuse can be reigned in by putting pressure on people who actually > answer their phone rather than abusers who generally don't. > > Another problem is the relatively unilateral approach of GDPR coming > out of the EU yet promising application to any company with an EU > nexus (or direct jurisdiction of course.) > > In that it resembles a tariff war. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Thu May 17 01:36:04 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 16 May 2018 21:36:04 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> Message-ID: <23292.56452.969767.766199@gargle.gargle.HOWL> On May 16, 2018 at 18:18 owen at delong.com (Owen DeLong) wrote: > At this point if I were a registrar or registry doing business in such a way as to be subject to gdpr, I’d seriously consider spinning up a subsidiary only for that purpose and leave it with minimal revenues and nothing to collect in the event of a lawsuit. Either that or simply stop doing business with Europeans until their government comes to its senses. 2018-04-19, The Guardian... https://www.theguardian.com/technology/2018/apr/19/facebook-moves-15bn-users-out-of-reach-of-new-european-privacy-law or http://tinyurl.com/yaeqguhz Headline: Facebook moves 1.5bn users out of reach of new European privacy law ... "The move is due to come into effect shortly before General Data Protection Regulation (GDPR) comes into force in Europe on 25 May. Facebook is liable under GDPR for fines of up to 4% of its global turnover – around $1.6bn – if it breaks the new data protection rules." ... "The company follows other US multinationals in the switch. LinkedIn, for instance, is to move its own non-EU users to its US branch on 8 May. “We’ve simply streamlined the contract location to ensure all members understand the LinkedIn entity responsible for their personal data,” it told Reuters." -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From niels=nanog at bakker.net Thu May 17 08:29:44 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 17 May 2018 10:29:44 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> Message-ID: <20180517082944.GB53693@excession.tpb.net> * owen at delong.com (Owen DeLong) [Thu 17 May 2018, 03:19 CEST]: >At this point if I were a registrar or registry doing business in >such a way as to be subject to gdpr, I’d seriously consider spinning >up a subsidiary only for that purpose and leave it with minimal >revenues and nothing to collect in the event of a lawsuit. Either >that or simply stop doing business with Europeans until their >government comes to its senses. > >Fortunately For now I get to watch from the sidelines with amusement >as this unfolds. I'm happy as a European to finally do business with companies that will have at least a modicum of respect for my privacy. We cannot escape UDRP but at least we now have a say in what we are forced to publish about ourselves. -- Niels. From job at ntt.net Thu May 17 11:13:52 2018 From: job at ntt.net (Job Snijders) Date: Thu, 17 May 2018 11:13:52 +0000 Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: References: <22961-b6.nogs.nanog-31082017210501-C0@news.border6.com> Message-ID: <20180517111352.GA91015@vurt.meerval.net> Dear Francois, On Thu, May 17, 2018 at 10:14:19AM +0000, Francois Devienne wrote: > The examples you mention confirm the issues are mainly due to poorly > configured networks where routes are leaked out although they > shouldn’t be. Adequate routers are able to filter out prefixes based > on attributes like communities, which we set by default. Question: is your implementation setting NO_EXPORT by default, or some other communities? Not all BGP "Optimizers" set NO_EXPORT by default... in that context I am not sure it is fair to say "the network is poorly configured" - when an "optimizer" doesn't set NO_EXPORT it is the "optimizer" that is comes with poor defaults. And there is another challenge: NO_EXPORT does not always work correctly. Software defects happen, and are unpredictable. All major routing platforms have seen bugs where for one reason or another NO_EXPORT does not (or no longer) work correctly. Heavy reliance on NO_EXPORT can be a weakness in network architecture. > There actually is a reason for operating BGP optimizers. The BGP > protocol, while robust and scalable, doesn't know anything about link > capacity, doesn’t apply performance analytics and can easily drive > links into saturation, introducing packet loss. Also, it is not aware > of commercial agreements like CDR, generating costs that could be > prevented. It also, of course, ignores the performance of available > paths. All of the above actually impacts customer traffic and > business performance. Since a few years we see our Customers take > more care of quality and capacity management… and stop relying on BGP > « blindly ». You are correct that there is a need (and a market) for BGP optimizers. BGP is terrible for routing around problematic parts of the topology if we look at metrics such as latency or packetloss. In my opinion, what the "optimizer" vendors _should_ have done (years ago), is go to IETF to the IDR working group and help standardize a safe and robust way to extend the BGP protocol to allow for better traffic engineering. Think along the lines what flowspec is for firewalls, perhaps there should be a "traffic engineering spec (tespec)" for routers. This should happen in a different Subsequent AFI to avoid the extremely risky behaviour we now see in the Unicast SAFI. I have no problem with software that automatically interacts with routers to manipulate LOCALPREF, there is no issue if software supresses more-specifics, prepends of the own ASN is no issue either, but what _is_ an issue is any software that generates fake routes and distributes those fake routes in the IPv4/IPv6 Unicast AFI/SAFI on boxes connected to the BGP DFZ. To phrase and summarize the isuse, using the terminology you provided: The "optimized" paths MUST NEVER be distributed in the same AFI/SAFI as the "natural" paths. Overloading the "natural" AFI/SAFI with fake generated more-specifics, which only exist for the purpose of outbound traffic engineering (even with communities) is a very dangerous thing. Yes, this will be a bit of work, but that is the cost of doing business. > (I’m a product engineer at Border 6 - Expereo, a BGP optimization > software company.) I appreciate your outreach in this public forum and the disclosure. Kind regards, Job From nanog at ics-il.net Thu May 17 12:43:19 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 May 2018 07:43:19 -0500 (CDT) Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> Message-ID: <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> Agreed. This is garbage, un-needed legislation. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong" To: bzs at theworld.com Cc: "Constantine A. Murenin" , "North American Network Operators' Group" Sent: Wednesday, May 16, 2018 8:18:54 PM Subject: Re: Whois vs GDPR, latest news At this point if I were a registrar or registry doing business in such a way as to be subject to gdpr, I’d seriously consider spinning up a subsidiary only for that purpose and leave it with minimal revenues and nothing to collect in the event of a lawsuit. Either that or simply stop doing business with Europeans until their government comes to its senses. Fortunately For now I get to watch from the sidelines with amusement as this unfolds. Owen > On May 16, 2018, at 17:26, bzs at theworld.com wrote: > > >> On May 16, 2018 at 16:10 mureninc at gmail.com (Constantine A. Murenin) wrote: >> I think this is the worst of both worlds. The data is basically still >> public, but you cannot access it unless someone marks you as a >> "friend". >> >> This policy is basically what Facebook is. And how well it played out >> once folks realised that their shared data wasn't actually private? > > The problem is that once the data gets out it's out and in many cases > such as this WHOIS data only stales very slowly. > > So one malicious breach or outlaw/misbehaving assignee and you may as > well have done nothing. > > I suppose one could /reductio ad absurdum/ and ask so therefore do > nothing? > > No, but perhaps more focus on misuse would be more productive. The > penalties for violations of GDPR are eye-watering like 4% of gross > revenues. That is, could be billions of dollars (or euros if you > prefer.) > > We know how well all this has worked in 20+ years of spam-fighting > which is to say not really well at all. > > It relies on this rather blue-sky model of the problem which is that > abuse can be reigned in by putting pressure on people who actually > answer their phone rather than abusers who generally don't. > > Another problem is the relatively unilateral approach of GDPR coming > out of the EU yet promising application to any company with an EU > nexus (or direct jurisdiction of course.) > > In that it resembles a tariff war. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From nanog at ics-il.net Thu May 17 12:55:20 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 May 2018 07:55:20 -0500 (CDT) Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: <791752116.9884.1526561715701.JavaMail.mhammett@ThunderFuck> Just be aware of the impact a default route can have on your infrastructure, such as uRPF no longer works as expected as everything has a valid route. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Adam Kajtar" To: erich at gotfusion.net Cc: nanog at nanog.org Sent: Wednesday, May 16, 2018 9:32:27 AM Subject: Re: Juniper BGP Convergence Time Erich, Good Idea. I can't believe I didn't think of that earlier. Simple and effective. I will go ahead and request the defaults from my ISP and update the thread of the findings. Thanks! On Wed, May 16, 2018 at 10:03 AM Kaiser, Erich wrote: > A last resort route (default route) could still be good to take from your > ISP(s) even if you still do full routes, as the propagation is happening on > the internet side, you should at least have a path inbound through the > other provider. The default route at least would send the traffic out if > it does not see the route locally. Just an idea. > > > > On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar > wrote: > > > I could use static routes but I noticed since I moved to full routes I > > have had a lot fewer customer complaints about latency(especially when it > > comes to Voice and VPN traffic). > > > > I wasn't using per-packet load balancing. I believe juniper default is > per > > IP. > > > > My timers are as follows > > Active Holdtime: 90 > > Keepalive Interval: 30 > > > > Would I be correct in thinking I need to contact my ISP to lower these > > values? > > > > An interesting note is when I had both ISPs connected into a single MX104 > > the failover was just a few seconds. > > > > Thanks again. > > > > > > > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > > > >> Have you checked your timeouts ? > >> > >> -Ben > >> > >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich > wrote: > >> > > >> > Do you need full routes? What about just a default route from BGP? > >> > > >> > Erich Kaiser > >> > The Fusion Network > >> > erich at gotfusion.net > >> > Office: 815-570-3101 > >> > > >> > > >> > > >> > > >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould > wrote: > >> >> > >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180 > >> secs of > >> >> BGP neighbor Time out before it believes neighbor is dead and remove > >> routes > >> >> to that neighbor? > >> >> > >> >> Aaron > >> >> > >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar > > >> >> wrote: > >> >>> > >> >>> Hello: > >> >>> > >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running > >> >>> BGP(full routes). iBGP is running between the routers via a two port > >> 20G > >> >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes > for > >> >>> traffic to start flowing correctly. The router has the correct route > >> in > >> >> the > >> >>> routing table, but it doesn't install it in the forwarding table for > >> the > >> >>> full two mins. > >> >>> > >> >>> I have a few questions if anyone could answer them. > >> >>> > >> >>> - What would a usual convergence time be for this setup? > >> >>> - Is there anything I could do speed this process up? (I tried > >> >> Multipath) > >> >>> - Any tips and tricks would be much appreciated > >> >>> > >> >>> Thanks in Advance > >> >>> -- > >> >>> Adam Kajtar > >> >>> Systems Administrator > >> >>> City of Wadsworth > >> >>> akajtar at wadsworthcity.org > >> >>> ----------------------------------------------------- > >> >>> http://www.wadsworthcity.com > >> >>> > >> >>> Facebook * |* Twitter > >> >>> *|* Instagram > >> >>> *|* YouTube > >> >>> > >> >> > >> >> > >> > > > > > > -- > > Adam Kajtar > > Systems Administrator, Safety Services > > City of Wadsworth > > Office 330.335.2865 > > Cell 330.485.6510 > > akajtar at wadsworthcity.org > > ----------------------------------------------------- > > http://www.wadsworthcity.com > > > > Facebook * |* Twitter > > *|* Instagram > > *|* YouTube > > > > > -- Adam Kajtar Systems Administrator, Safety Services City of Wadsworth Office 330.335.2865 Cell 330.485.6510 akajtar at wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook * |* Twitter *|* Instagram *|* YouTube From nanog at ics-il.net Thu May 17 12:59:51 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 May 2018 07:59:51 -0500 (CDT) Subject: internet - sparkle In-Reply-To: References: <000101d3ed25$d9ef7c40$8dce74c0$@gvtc.com> <0f08ee8c-55ba-c1a1-7b1b-17bf85878b1d@seacom.mu> Message-ID: <415359945.9892.1526561989368.JavaMail.mhammett@ThunderFuck> IXes are generally a far better use of eyeball resources than additional transit networks. Obviously, there are some edge exceptions. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Geiger" To: "Aaron Gould" , Nanog at nanog.org Sent: Wednesday, May 16, 2018 2:31:35 PM Subject: Re: internet - sparkle If most of your traffic is for US based destinations, you might see worse performance since Sparkle doesn't seem to have many US POPs/Peering locations compared to Centurylink/Level3 or HE. You'd probably benefit more by pulling in some peering from Dallas than adding or replacing a transit provider as your current mix is decent for an eyeball network. Pick up peering with Cloudflare, Netflix, Amazon, EdgeCast, Facebook, Apple, Akamai, and Microsoft in Dallas and you might even be able to get rid of one of your transit providers. Sparkle would "shine" if you were a US hosting provider with many eyeballs in Europe/Africa/Middle East. On Wed, May 16, 2018 at 11:34 AM, Mark Tinka wrote: > > > On 16/May/18 16:54, Aaron Gould wrote: > > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is > it > > still accurate ? (asking since my next question is related to Sparkle, > since > > they are listed in that previous article as a significant Internet > presence) > > I don't know about "owning" the Internet, but I would agree with the > article re: the 7 key global transit providers as things stand in 2018. > > It matches up with our own compliment of transit providers in our > network (AS37100). > > > > > > > > My coworker just got back from ITW/Chicago and he is considering Sparkle > as > > an additional Internet provider for the ISP I work for in San Antonio, > TX . > > we would need to uplink to Sparkle in the central Texas area somehow. He > > mentioned that Sparkle may be in McAllen / Dallas and could possibly, in > the > > future be in Austin or San Antonio > > My initial experience with TI Sparkle was in South East Asia back in > '08. They were decent. > > We have them in our stable, and like them for their South American > coverage. > > Mark. > From niels=nanog at bakker.net Thu May 17 13:03:30 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 17 May 2018 15:03:30 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> Message-ID: <20180517130330.GC53693@excession.tpb.net> * nanog at ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]: >Agreed. This is garbage, un-needed legislation. Disagreed. These are great and necessary regulations. I'm loving the flood of convoluted unsubscribe notices this month from companies that had stored PII for no reason. -- Niels. From nanog at ics-il.net Thu May 17 13:24:53 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 May 2018 08:24:53 -0500 (CDT) Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> I often question why\how people build networks the way they do. There's some industry hard-on with having a few ginormous routers instead of many smaller ones. I've learned that when building Internet Exchanges, the number of networks that don't have BGP edge routers in major markets where they have a presence is quite a bit larger than one would expect. I heard a podcast once (I forget if it was Packet Pushers or Network Collective) postulating that the reason why everything runs back to a few big ass routers is that someone decided to spend a crap-load of money on big ass routers for bragging rights, so now they have to run everything they can through them to A) "prove" their purchase wasn't foolish and B) because they now can't afford to buy anything else. There's no reason why Tampa doesn't have a direct L3 adjacency to Miami, Atlanta, Houston, and Charlotte over diverse infrastructure to all four. Obviously there's room to add\drop from that list, but it gets the point across. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "David Hubbard" To: nanog at nanog.org Sent: Wednesday, May 16, 2018 11:59:42 AM Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) I’m curious if anyone who’s used 3356 for transit has found shortcomings in how their peering and redundancy is configured, or what a normal expectation to have is. The Tampa Bay market has been completely down for 3356 IP services twice so far this year, each for what I’d consider an unacceptable period of time (many hours). I’m learning that the entire market is served by just two fiber routes, through cities hundreds of miles away in either direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes the entire region down. The most recent occurrence was a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP services down for hours. It did not take point to point circuits to out of market locations down, so that suggests they even have the ability to be more redundant and simply choose not to. I feel like it’s not unreasonable to expect more redundancy, or a much smaller attack surface given a disgruntled lineman who knows the routes could take an entire region down with a planned cut four states apart. Maybe other regions are better designed? Or are my expectations unreasonable? I carry three peers in that market, so it hasn’t been outage-causing, but I use 3356 in other markets too, and have plans for more, but it makes me wonder if I just haven't had the pleasure of similar outages elsewhere yet and I should factor that expectation into the design. It creates a problem for me in one location where I can only get them and Cogent, since Cogent can't be relied on for IPv6 service, which I need. Thanks From Brian at ampr.org Thu May 17 14:23:22 2018 From: Brian at ampr.org (Brian Kantor) Date: Thu, 17 May 2018 07:23:22 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> Message-ID: <20180517142322.GA54033@meow.BKantor.net> An article in The Register on the current status of Whois and the GDPR. https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/ From akajtar at wadsworthcity.org Thu May 17 14:49:37 2018 From: akajtar at wadsworthcity.org (Adam Kajtar) Date: Thu, 17 May 2018 10:49:37 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: <791752116.9884.1526561715701.JavaMail.mhammett@ThunderFuck> References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <791752116.9884.1526561715701.JavaMail.mhammett@ThunderFuck> Message-ID: Thomas, Thanks for the info. This is probably why my multipath configuration wasn't working as I thought it would. I will give this a test run also. Mike, Interesting thought. This would mean rpf-check wouldn't work on my outside interfaces. Good to know. On Thu, May 17, 2018 at 8:55 AM Mike Hammett wrote: > Just be aware of the impact a default route can have on your > infrastructure, such as uRPF no longer works as expected as everything has > a valid route. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Adam Kajtar" > *To: *erich at gotfusion.net > *Cc: *nanog at nanog.org > *Sent: *Wednesday, May 16, 2018 9:32:27 AM > *Subject: *Re: Juniper BGP Convergence Time > > Erich, > > Good Idea. I can't believe I didn't think of that earlier. Simple and > effective. I will go ahead and request the defaults from my ISP and update > the thread of the findings. > > Thanks! > > On Wed, May 16, 2018 at 10:03 AM Kaiser, Erich > wrote: > > > A last resort route (default route) could still be good to take from your > > ISP(s) even if you still do full routes, as the propagation is happening > on > > the internet side, you should at least have a path inbound through the > > other provider. The default route at least would send the traffic out if > > it does not see the route locally. Just an idea. > > > > > > > > On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar > > wrote: > > > > > I could use static routes but I noticed since I moved to full routes I > > > have had a lot fewer customer complaints about latency(especially when > it > > > comes to Voice and VPN traffic). > > > > > > I wasn't using per-packet load balancing. I believe juniper default is > > per > > > IP. > > > > > > My timers are as follows > > > Active Holdtime: 90 > > > Keepalive Interval: 30 > > > > > > Would I be correct in thinking I need to contact my ISP to lower these > > > values? > > > > > > An interesting note is when I had both ISPs connected into a single > MX104 > > > the failover was just a few seconds. > > > > > > Thanks again. > > > > > > > > > > > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > > > > > >> Have you checked your timeouts ? > > >> > > >> -Ben > > >> > > >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich > > wrote: > > >> > > > >> > Do you need full routes? What about just a default route from BGP? > > >> > > > >> > Erich Kaiser > > >> > The Fusion Network > > >> > erich at gotfusion.net > > >> > Office: 815-570-3101 > > >> > > > >> > > > >> > > > >> > > > >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould > > wrote: > > >> >> > > >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180 > > >> secs of > > >> >> BGP neighbor Time out before it believes neighbor is dead and > remove > > >> routes > > >> >> to that neighbor? > > >> >> > > >> >> Aaron > > >> >> > > >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar < > akajtar at wadsworthcity.org > > > > > >> >> wrote: > > >> >>> > > >> >>> Hello: > > >> >>> > > >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected > running > > >> >>> BGP(full routes). iBGP is running between the routers via a two > port > > >> 20G > > >> >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes > > for > > >> >>> traffic to start flowing correctly. The router has the correct > route > > >> in > > >> >> the > > >> >>> routing table, but it doesn't install it in the forwarding table > for > > >> the > > >> >>> full two mins. > > >> >>> > > >> >>> I have a few questions if anyone could answer them. > > >> >>> > > >> >>> - What would a usual convergence time be for this setup? > > >> >>> - Is there anything I could do speed this process up? (I tried > > >> >> Multipath) > > >> >>> - Any tips and tricks would be much appreciated > > >> >>> > > >> >>> Thanks in Advance > > >> >>> -- > > >> >>> Adam Kajtar > > >> >>> Systems Administrator > > >> >>> City of Wadsworth > > >> >>> akajtar at wadsworthcity.org > > >> >>> ----------------------------------------------------- > > >> >>> http://www.wadsworthcity.com > > >> >>> > > >> >>> Facebook * |* Twitter > > >> >>> *|* Instagram > > >> >>> *|* YouTube > > >> >>> > > >> >> > > >> >> > > >> > > > > > > > > > -- > > > Adam Kajtar > > > Systems Administrator, Safety Services > > > City of Wadsworth > > > Office 330.335.2865 > > > Cell 330.485.6510 > > > akajtar at wadsworthcity.org > > > ----------------------------------------------------- > > > http://www.wadsworthcity.com > > > > > > Facebook * |* Twitter > > > *|* Instagram > > > *|* YouTube > > > > > > > > > > > -- > Adam Kajtar > Systems Administrator, Safety Services > City of Wadsworth > Office 330.335.2865 > Cell 330.485.6510 > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > > > -- Adam Kajtar Systems Administrator, Safety Services City of Wadsworth Office 330.335.2865 Cell 330.485.6510 akajtar at wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook * |* Twitter *|* Instagram *|* YouTube From hugo at slabnet.com Thu May 17 15:17:11 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 17 May 2018 08:17:11 -0700 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <791752116.9884.1526561715701.JavaMail.mhammett@ThunderFuck> Message-ID: <20180517151711.GA27928@bamboo.slabnet.com> On Thu 2018-May-17 10:49:37 -0400, Adam Kajtar wrote: >Thomas, > >Thanks for the info. This is probably why my multipath configuration wasn't >working as I thought it would. I will give this a test run also. > >Mike, > >Interesting thought. This would mean rpf-check wouldn't work on my outside >interfaces. Good to know. Not necessarily that it doesn't work at all, but there are platform-specific differences in terms of loose vs. strict, whether the default route is considered in RPF evaluation, etc. From https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html#jd0e50 > # Unicast RPF Behavior with a Default Route > > On all routers except those with MPCs and the MX80 router, unicast RPF > behaves as follows if you configure a default route that uses an interface > configured with unicast RPF: > > * Loose mode—All packets are automatically accepted. For this reason, we > recommend that you not configure unicast RPF loose mode on interfaces * > that the default route uses. > * Strict mode—The packet is accepted when the source address of the > packet matches any of the routes (either default or learned) that can be > reachable through the interface. Note that routes can have multiple > destinations associated with them; therefore, if one of the destinations > atches the incoming interface of the packet, the packet is accepted. > > On all routers with MPCs and the MX80 router, unicast RPF behaves as > follows if you configure a default route that uses an interface configured > with unicast RPF: > > * Loose mode—All packets except the packets whose source is learned from > the default route are accepted. All packets whose source is learned from > the default route are dropped at the Packet Forwarding Engine. The > default route is treated as if the route does not exist. > * Strict mode—The packet is accepted when the source address of the > packet matches any of the routes (either default or learned) that can be > reachable through the interface. Note that routes can have multiple > destinations associated with them; therefore, if one of the destinations > matches the incoming interface of the packet, the packet is accepted. > > On all routers, the packet is not accepted when either of the following is > true: > > * The source address of the packet does not match a prefix in the routing > table. > * The interface does not expect to receive a packet with this source > address prefix. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From eric.sieg at gmail.com Thu May 17 15:19:44 2018 From: eric.sieg at gmail.com (Eric Sieg) Date: Thu, 17 May 2018 11:19:44 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: You shouldn't need to contact your ISP on the lowered BGP timers as BGP should establish based on the lowest value. That said, they may have a value limit where anything lower than that, is set at your own risk. You can look at running BFD over the BGP session as well. Technically it has nothing to do with convergence, but it can quickly detect a down issue and drop BGP right away. On Wed, May 16, 2018 at 9:22 AM, Adam Kajtar wrote: > I could use static routes but I noticed since I moved to full routes I have > had a lot fewer customer complaints about latency(especially when it comes > to Voice and VPN traffic). > > I wasn't using per-packet load balancing. I believe juniper default is per > IP. > > My timers are as follows > Active Holdtime: 90 > Keepalive Interval: 30 > > Would I be correct in thinking I need to contact my ISP to lower these > values? > > An interesting note is when I had both ISPs connected into a single MX104 > the failover was just a few seconds. > > Thanks again. > > > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > > > Have you checked your timeouts ? > > > > -Ben > > > > > On May 15, 2018, at 4:09 PM, Kaiser, Erich > wrote: > > > > > > Do you need full routes? What about just a default route from BGP? > > > > > > Erich Kaiser > > > The Fusion Network > > > erich at gotfusion.net > > > Office: 815-570-3101 > > > > > > > > > > > > > > >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould wrote: > > >> > > >> You sure it doesn't have something to do with 60 seconds * 3 = 180 > secs > > of > > >> BGP neighbor Time out before it believes neighbor is dead and remove > > routes > > >> to that neighbor? > > >> > > >> Aaron > > >> > > >>> On May 15, 2018, at 9:10 AM, Adam Kajtar > > >> wrote: > > >>> > > >>> Hello: > > >>> > > >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running > > >>> BGP(full routes). iBGP is running between the routers via a two port > > 20G > > >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes for > > >>> traffic to start flowing correctly. The router has the correct route > in > > >> the > > >>> routing table, but it doesn't install it in the forwarding table for > > the > > >>> full two mins. > > >>> > > >>> I have a few questions if anyone could answer them. > > >>> > > >>> - What would a usual convergence time be for this setup? > > >>> - Is there anything I could do speed this process up? (I tried > > >> Multipath) > > >>> - Any tips and tricks would be much appreciated > > >>> > > >>> Thanks in Advance > > >>> -- > > >>> Adam Kajtar > > >>> Systems Administrator > > >>> City of Wadsworth > > >>> akajtar at wadsworthcity.org > > >>> ----------------------------------------------------- > > >>> http://www.wadsworthcity.com > > >>> > > >>> Facebook * |* Twitter > > >>> *|* Instagram > > >>> *|* YouTube > > >>> > > >> > > >> > > > > > -- > Adam Kajtar > Systems Administrator, Safety Services > City of Wadsworth > Office 330.335.2865 > Cell 330.485.6510 > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > > From niels=nanog at bakker.net Thu May 17 15:29:16 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 17 May 2018 17:29:16 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <20180517142322.GA54033@meow.BKantor.net> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517142322.GA54033@meow.BKantor.net> Message-ID: <20180517152916.GE53693@excession.tpb.net> * Brian at ampr.org (Brian Kantor) [Thu 17 May 2018, 16:23 CEST]: >An article in The Register on the current status of Whois and the >GDPR. > >https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/ My registrar already does all the things listed in this article that registrars supposedly don't yet do. American companies that think they have a need, or even the right, to see the billing address for my personal domain can go pound sand. -- Niels. From zbynek at dialtelecom.cz Thu May 17 15:30:32 2018 From: zbynek at dialtelecom.cz (=?UTF-8?B?WmJ5bsSbayBQb3Nww61jaGFs?=) Date: Thu, 17 May 2018 17:30:32 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <20180517130330.GC53693@excession.tpb.net> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> Message-ID: <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> Dne 17/05/2018 v 15:03 Niels Bakker napsal(a): > * nanog at ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]: >> Agreed. This is garbage, un-needed legislation. > > Disagreed.  These are great and necessary regulations.> > I'm loving the flood of convoluted unsubscribe notices this month from > companies that had stored PII for no reason. Those who would give up essential liberty, to purchase a little temporary safety(*), deserve neither liberty nor safety(*). (*) you can replace this word with comfort in this case without loosing the point This is what all the regulation fans still not understood. Regards, Zbynek From list at satchell.net Thu May 17 16:12:34 2018 From: list at satchell.net (Stephen Satchell) Date: Thu, 17 May 2018 09:12:34 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <20180517152916.GE53693@excession.tpb.net> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517142322.GA54033@meow.BKantor.net> <20180517152916.GE53693@excession.tpb.net> Message-ID: <9ea59948-a081-6b10-b999-161060a3e9fc@satchell.net> In a related note, I received a note from my registrar this morning telling me that, per current ICANN rules, I need to verify all the personal identifying information for the domains I control. 1. I checked WHOIS for all my domains, and they point to the proxy service that my registrar offers. So, I have no PII visible via WHOIS. 2. I checked the contact information page, and all my (hidden) PII is correct. So, at least for my domains, everything is GDPR compliant as far as public display is concerned. The question about the proxy service providing an anonymous tunnel for, say, abuse e-mail is open to question. As well as all the other bells and whistles I've seen discussed. By the way, setting up the proxy service just takes money, not time, in the old school. The fines are heavy enough that the registrars can consider forcing proxy service on all domains, and figure out how to recoup the costs later. Months? I don't think so. But then again, I'm not a registrar, only a customer of those folks. On 05/17/2018 08:29 AM, Niels Bakker wrote: > * Brian at ampr.org (Brian Kantor) [Thu 17 May 2018, 16:23 CEST]: >> An article in The Register on the current status of Whois and the GDPR. >> >> https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/ > > My registrar already does all the things listed in this article that > registrars supposedly don't yet do. > > American companies that think they have a need, or even the right, to > see the billing address for my personal domain can go pound sand. > > >     -- Niels. From sander at steffann.nl Thu May 17 16:14:22 2018 From: sander at steffann.nl (Sander Steffann) Date: Thu, 17 May 2018 18:14:22 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> Message-ID: Hi, > Dne 17/05/2018 v 15:03 Niels Bakker napsal(a): >> * nanog at ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]: >>> Agreed. This is garbage, un-needed legislation. >> >> Disagreed. These are great and necessary regulations.> >> I'm loving the flood of convoluted unsubscribe notices this month from >> companies that had stored PII for no reason. > > Those who would give up essential liberty, to purchase a little > temporary safety(*), deserve neither liberty nor safety(*). But this regulation increases essential liberty for individuals, so I don't understand your argument... Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From zbynek at dialtelecom.cz Thu May 17 18:03:00 2018 From: zbynek at dialtelecom.cz (=?UTF-8?B?WmJ5bsSbayBQb3Nww61jaGFs?=) Date: Thu, 17 May 2018 20:03:00 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> Message-ID: <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> Dne 17/05/2018 v 18:14 Sander Steffann napsal(a): > Hi, > > But this regulation increases essential liberty for individuals, so I don't understand your argument... No, it don't. It has two aspects: 1. It brings new positive defined rights. But as with any other positive defined rights, it brings an obligation for anyone other to provide such rights, it requires enforcement, inspections/whatever which anyone in Europe must pay from taxes and it requires implementation of a lot of rules, possible changing of existing internal systems etc. etc. in companies which will be paid from their revenue, so again from consumer money. 2. It would be the true in an ideal situation. In the real world, there is no ideal situation. Accept the fact that if you would like to keep any data private, you must not tell them to anyone. You. You are the one who can decide about your data and who can really protect your data, no one else, no government, no GDPR. There is a lot of anonymization techniques, strong encryption and other things helping to cover who used/published/steal your private data when it is done by experienced professionals. It could help a little bit to keep private data protected againest beginner and intermediate data thieves and perhaps againest some kinds of stupid mistakes, maybe. Nothing more. Is it enough when we mention all the costs, including hidden? I don't think so. BTW, nobody told me he is going to propose such regulation before the last EP elections, no party I have been able to vote has anything like this nor oposing anything like this in their program. -- Regards, Zbynek From lguillory at reservetele.com Thu May 17 19:24:49 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 17 May 2018 19:24:49 +0000 Subject: Equinix Fire Alarm - IBX was Evacuated Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F99C101@RTC-EXCH01.RESERVE.LDS> Just got this. Dear Equinix Customer, IBX(s): DA6 IBX Address: 1950 North Stemmons Freeway Suites 2049 & 3050 Dallas, TX 75207 Ticket#: 5-152980676699 Date and Time of Occurrence: 17-MAY-2018 14:04 Site Local Time INCIDENT SUMMARY: Fire Alarm - IBX was Evacuated INCIDENT DESCRIPTION: Equinix IBX Site Staff reports that a fire alarm has been triggered and the IBX is being evacuated. IBX Engineers are currently investigating the issue. Next update will be when a significant change to the situation occurs. Sincerely, Equinix Service Desk Ns From merculiani at gmail.com Thu May 17 19:28:08 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Thu, 17 May 2018 14:28:08 -0500 Subject: Equinix Fire Alarm - IBX was Evacuated In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F99C101@RTC-EXCH01.RESERVE.LDS> References: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F99C101@RTC-EXCH01.RESERVE.LDS> Message-ID: Appears to have just been a drill. They let us all back in within 15 mins. -Matt On Thu, May 17, 2018, 14:26 Luke Guillory wrote: > Just got this. > > > > > Dear Equinix Customer, > > IBX(s): DA6 > IBX Address: 1950 North Stemmons Freeway Suites 2049 & 3050 Dallas, TX > 75207 > Ticket#: 5-152980676699 > Date and Time of Occurrence: 17-MAY-2018 14:04 Site Local Time > > INCIDENT SUMMARY: Fire Alarm - IBX was Evacuated > > INCIDENT DESCRIPTION: > > Equinix IBX Site Staff reports that a fire alarm has been triggered and > the IBX is being evacuated. IBX Engineers are currently investigating the > issue. > > > > Next update will be when a significant change to the situation occurs. > > Sincerely, > Equinix Service Desk > > > > > Ns > > > > From bzs at theworld.com Thu May 17 19:47:06 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 17 May 2018 15:47:06 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <20180517082944.GB53693@excession.tpb.net> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <20180517082944.GB53693@excession.tpb.net> Message-ID: <23293.56378.431650.497965@gargle.gargle.HOWL> On May 17, 2018 at 10:29 niels=nanog at bakker.net (Niels Bakker) wrote: > We cannot escape UDRP but at least we now have a say in what we are > forced to publish about ourselves. Just curious, what does UDRP have to do with any of this? UDRP is an ICANN process which allows someone who believes they have intellectual property rights in a domain to challenge an ownership. Granted it's been abused (but so have baseball bats) creating the new dreaded acronym RDNH (reverse domain name hijacking) but I don't see how that's related. Even under GDPR a litigant can get the owner's contact information or, if the info is false or not practically available, pursue a default judgement which if successful would result in the domain's transfer to them. FWIW for new TLDs (.RODEO or whatever) the equivalent process is URS. Gratuitous Side Note: One of the more publicized cases of late involved FRANCE.COM which apparently the French govt seized ownership of via WEB.COM without any UDRP process or notice to the owner. Overview article, you can find others: https://www.sgtreport.com/2018/04/france-seizes-france-com-from-man-whos-had-it-since-94-so-he-sues/ Legal filing: https://domainnamewire.com/wp-content/france-com.pdf -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From mureninc at gmail.com Thu May 17 22:04:52 2018 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 17 May 2018 17:04:52 -0500 Subject: Whois vs GDPR, latest news In-Reply-To: <20180517130330.GC53693@excession.tpb.net> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> Message-ID: On 17 May 2018 at 08:03, Niels Bakker wrote: > * nanog at ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]: >> >> Agreed. This is garbage, un-needed legislation. > > > Disagreed. These are great and necessary regulations. > > I'm loving the flood of convoluted unsubscribe notices this month from > companies that had stored PII for no reason. I don't. I have better things to do than babysit various accounts I've signed up over the years. Just because someone signs up for an account and forgets about it is not a good enough reason to have my information DESTROYED WITHOUT MY PERMISSION if I do happen to be busy that week to sign in somewhere to accept a legal disclaimer. GDPR is touted as a policy to tackle the issue of the larger players abusing their market positions and our trust; instead, so far, my lack of response would just ensure that I am unsubscribed from my alumni association in the UK; what good does it do to me?! C. From internetplumber at gmail.com Fri May 18 01:18:29 2018 From: internetplumber at gmail.com (Rob Evans) Date: Fri, 18 May 2018 03:18:29 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> Message-ID: > I don't. I have better things to do than babysit various accounts > I've signed up over the years. Just because someone signs up for an > account and forgets about it is not a good enough reason to have my > information DESTROYED WITHOUT MY PERMISSION if I do happen to be busy > that week to sign in somewhere to accept a legal disclaimer. It’s only ‘{one|that} week’ from today. The people that hold your personal data appear to have not planned in advance. Why should people (“data processors”) have the right to forward your personal contact details in perpetuity? Isn’t that a problem? They don’t need to ask permission to use those details for purposes for which you’ve already granted permission. > GDPR is touted as a policy to tackle the issue of the larger players > abusing their market positions and our trust; instead, so far, my lack > of response would just ensure that I am unsubscribed from my alumni > association in the UK; what good does it do to me?! This may be a misunderstanding, or a cautious approach, from your alma mater. If you’ve given them permission for them to hold your data about their activities all is well. Many companies are choosing this as an opportunity to confirm that permission for the sake of future legal argument. Rob From tom at ninjabadger.net Fri May 18 11:20:05 2018 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 18 May 2018 12:20:05 +0100 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> Message-ID: <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> On 17/05/18 14:24, Mike Hammett wrote: > There's some industry hard-on with having a few ginormous routers instead of many smaller ones. "Industry hard-on", ITYM "Greedy vendors". Try finding a 'small' router with a lot of ports (1 & 10GE) for your customers, and the right features/TCAM/CP performance, for a price that permits you to buy a lot of them. -- Tom From list at satchell.net Fri May 18 13:55:47 2018 From: list at satchell.net (Stephen Satchell) Date: Fri, 18 May 2018 06:55:47 -0700 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> Message-ID: <6cf11791-5b5d-9d94-9f1f-e3d083d7767b@satchell.net> On 05/18/2018 04:20 AM, Tom Hill wrote: > On 17/05/18 14:24, Mike Hammett wrote: >> There's some industry hard-on with having a few ginormous routers instead of many smaller ones. > > "Industry hard-on", ITYM "Greedy vendors". I think this view (both versions) are a little over the top. "Never attribute to malice that which can be explained by stupidity." The "stupidity" in this instance is poor market analysis, perhaps with the market research folks concentrating on large service provider customers at the expense of enterprise customers with very, very large data traffic needs but fewer ports per location. They could also be concentrating on the very large providers working on the theory that the rate of return on boxes requiring a fork lift to install is higher than the rate of return on the 1U or 2U variety. > Try finding a 'small' router with a lot of ports (1 & 10GE) for your > customers, and the right features/TCAM/CP performance, for a price that > permits you to buy a lot of them. What happened when you sent out your last RPQ to the vendors with these requirements? From lists at mtin.net Fri May 18 14:22:45 2018 From: lists at mtin.net (Justin Wilson) Date: Fri, 18 May 2018 10:22:45 -0400 Subject: Akamai WAF Message-ID: <8854A276-AE16-4852-83FA-4C8A03F5C068@mtin.net> I have a client with a /24 that has somehow been blocked by folks using the Akamai WAF. This is the response we received back from Akamai when we contacted them. >On checking the machine logs for ups.com , we found that there is WAF (web application firewall) configured by ups.com , this has to be fixed from the site owners end. This is happening with multiple sites, southwest.com is another. I find it odd multiple sites are doing this at the same time. If just one I would believe it was a manual configuration. It seems like something has triggered it. Can someone shed some light on how the WAF works? Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com From lists at benappy.com Fri May 18 14:43:26 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Fri, 18 May 2018 16:43:26 +0200 Subject: Akamai WAF In-Reply-To: <8854A276-AE16-4852-83FA-4C8A03F5C068@mtin.net> References: <8854A276-AE16-4852-83FA-4C8A03F5C068@mtin.net> Message-ID: <8CB6CE00-E6C2-425A-B236-ACA4B43B1979@benappy.com> Hi, > On 18 May 2018, at 16:22, Justin Wilson wrote: > > I have a client with a /24 that has somehow been blocked by folks using the Akamai WAF. This is the response we received back from Akamai when we contacted them. > >> On checking the machine logs for ups.com , we found that there is WAF (web application firewall) configured by ups.com , this has to be fixed from the site owners end. > > This is happening with multiple sites, southwest.com is another. I find it odd multiple sites are doing this at the same time. If just one I would believe it was a manual configuration. It seems like something has triggered it. Can someone shed some light on how the WAF works? As far as I know they have some kind of scoring in place for end users IPs so if there is a malicious IP inside the /24 (from Akamai’s WAF point of view) then the scoring can affect other WAFed services as well. BR, ic From Sam at SanDiegoBroadband.com Fri May 18 16:34:50 2018 From: Sam at SanDiegoBroadband.com (Sam Norris) Date: Fri, 18 May 2018 09:34:50 -0700 Subject: EDGECAST / AlphaCDN Message-ID: <0f4e01d3eec6$2659c8f0$730d5ad0$@SanDiegoBroadband.com> Anyone know EDGECAST / Verizon contact and can help with geolocation / anonymizer listings? We finally got off the Amazon / MaxMind lists but seems this one is stuck. Thx, Sam Norris San Diego Broadband From cscora at apnic.net Fri May 18 18:03:11 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 May 2018 04:03:11 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180518180311.3B859C450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 19 May, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 700789 Prefixes after maximum aggregation (per Origin AS): 269276 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 336765 Total ASes present in the Internet Routing Table: 60726 Prefixes per ASN: 11.54 Origin-only ASes present in the Internet Routing Table: 52444 Origin ASes announcing only one prefix: 22914 Transit ASes present in the Internet Routing Table: 8282 Transit-only ASes present in the Internet Routing Table: 270 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 53 Number of instances of unregistered ASNs: 53 Number of 32-bit ASNs allocated by the RIRs: 22616 Number of 32-bit ASNs visible in the Routing Table: 18220 Prefixes from 32-bit ASNs in the Routing Table: 75897 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 304 Number of addresses announced to Internet: 2859596354 Equivalent to 170 /8s, 113 /16s and 250 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 233976 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 191663 Total APNIC prefixes after maximum aggregation: 54291 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 190476 Unique aggregates announced from the APNIC address blocks: 77546 APNIC Region origin ASes present in the Internet Routing Table: 8813 APNIC Prefixes per ASN: 21.61 APNIC Region origin ASes announcing only one prefix: 2460 APNIC Region transit ASes present in the Internet Routing Table: 1316 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3775 Number of APNIC addresses announced to Internet: 767033858 Equivalent to 45 /8s, 184 /16s and 2 /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: 208375 Total ARIN prefixes after maximum aggregation: 99076 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209145 Unique aggregates announced from the ARIN address blocks: 98869 ARIN Region origin ASes present in the Internet Routing Table: 18163 ARIN Prefixes per ASN: 11.51 ARIN Region origin ASes announcing only one prefix: 6711 ARIN Region transit ASes present in the Internet Routing Table: 1793 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2349 Number of ARIN addresses announced to Internet: 1105502240 Equivalent to 65 /8s, 228 /16s and 160 /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: 191469 Total RIPE prefixes after maximum aggregation: 92029 RIPE Deaggregation factor: 2.08 Prefixes being announced from the RIPE address blocks: 187444 Unique aggregates announced from the RIPE address blocks: 111353 RIPE Region origin ASes present in the Internet Routing Table: 25153 RIPE Prefixes per ASN: 7.45 RIPE Region origin ASes announcing only one prefix: 11385 RIPE Region transit ASes present in the Internet Routing Table: 3505 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6987 Number of RIPE addresses announced to Internet: 716083840 Equivalent to 42 /8s, 174 /16s and 146 /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: 90587 Total LACNIC prefixes after maximum aggregation: 19869 LACNIC Deaggregation factor: 4.56 Prefixes being announced from the LACNIC address blocks: 92016 Unique aggregates announced from the LACNIC address blocks: 41067 LACNIC Region origin ASes present in the Internet Routing Table: 7156 LACNIC Prefixes per ASN: 12.86 LACNIC Region origin ASes announcing only one prefix: 1979 LACNIC Region transit ASes present in the Internet Routing Table: 1334 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4692 Number of LACNIC addresses announced to Internet: 172671904 Equivalent to 10 /8s, 74 /16s and 195 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18640 Total AfriNIC prefixes after maximum aggregation: 3963 AfriNIC Deaggregation factor: 4.70 Prefixes being announced from the AfriNIC address blocks: 21404 Unique aggregates announced from the AfriNIC address blocks: 7662 AfriNIC Region origin ASes present in the Internet Routing Table: 1142 AfriNIC Prefixes per ASN: 18.74 AfriNIC Region origin ASes announcing only one prefix: 378 AfriNIC Region transit ASes present in the Internet Routing Table: 232 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 417 Number of AfriNIC addresses announced to Internet: 97854720 Equivalent to 5 /8s, 213 /16s and 37 /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 5415 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4403 419 431 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2908 11137 790 KIXS-AS-KR Korea Telecom, KR 7552 2862 1155 74 VIETEL-AS-AP Viettel Group, VN 9829 2812 1498 543 BSNL-NIB National Internet Backbone, IN 9394 2537 4922 25 CTTNET China TieTong Telecommunications 45899 2526 1574 160 VNPT-AS-VN VNPT Corp, VN 17974 2216 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2195 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2104 417 207 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3416 1323 84 SHAW - Shaw Communications Inc., CA 22773 3295 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 109 MEGAPATH5-US - MegaPath Corporation, US 16509 2107 4687 661 AMAZON-02 - Amazon.com, Inc., US 11492 2102 243 436 CABLEONE - CABLE ONE, INC., US 20115 2102 2510 452 CHARTER-NET-HKY-NC - Charter Communicat 209 1987 5070 606 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1982 342 166 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 1803 891 1285 AKAMAI-AS - Akamai Technologies, Inc., 7018 1718 20215 1260 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4151 1519 516 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2880 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2630 691 1932 AKAMAI-ASN1, US 12389 2047 1876 709 ROSTELECOM-AS, RU 34984 2015 334 487 TELLCOM-AS, TR 9121 1885 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 8402 1243 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 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 8151 4812 3358 591 Uninet S.A. de C.V., MX 10620 3594 542 244 Telmex Colombia S.A., CO 11830 2648 369 77 Instituto Costarricense de Electricidad 6503 1611 437 53 Axtel, S.A.B. de C.V., MX 7303 1514 1026 188 Telecom Argentina S.A., AR 28573 1026 2249 191 CLARO S.A., BR 3816 1008 505 123 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 982 377 31 Telefonica del Peru S.A.A., PE 11172 929 126 85 Alestra, S. de R.L. de C.V., MX 18881 910 1076 29 TELEF�NICA BRASIL S.A, BR 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 1183 396 45 LINKdotNET-AS, EG 37611 851 107 9 Afrihost, ZA 36903 740 372 140 MT-MPLS, MA 36992 703 1412 42 ETISALAT-MISR, EG 8452 693 1730 18 TE-AS TE-AS, EG 24835 567 818 18 RAYA-AS, EG 37492 452 376 82 ORANGE-, TN 29571 439 68 10 ORANGE-COTE-IVOIRE, CI 15399 363 35 7 WANANCHI-, KE 23889 363 103 14 MauritiusTelecom, MU 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 5415 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4812 3358 591 Uninet S.A. de C.V., MX 7545 4403 419 431 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4151 1519 516 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3594 542 244 Telmex Colombia S.A., CO 6327 3416 1323 84 SHAW - Shaw Communications Inc., CA 22773 3295 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2908 11137 790 KIXS-AS-KR Korea Telecom, KR 8551 2880 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4812 4221 Uninet S.A. de C.V., MX 7545 4403 3972 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4151 3635 UNI2-AS, ES 10620 3594 3350 Telmex Colombia S.A., CO 6327 3416 3332 SHAW - Shaw Communications Inc., CA 22773 3295 3148 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2880 2837 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2862 2788 VIETEL-AS-AP Viettel Group, VN 11830 2648 2571 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64514 PRIVATE 5.42.231.0/24 35753 ITC ITC AS number, SA 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.232.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.233.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 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.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 36.50.254.0/23 48964 ENTERRA-AS, UA 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:37 /11:100 /12:288 /13:566 /14:1093 /15:1908 /16:13390 /17:7879 /18:13632 /19:25180 /20:39356 /21:45390 /22:87183 /23:70455 /24:392031 /25:847 /26:651 /27:647 /28:36 /29:20 /30:18 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3204 3416 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 12479 2931 4151 UNI2-AS, ES 22773 2551 3295 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2342 2880 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2060 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1996 2648 Instituto Costarricense de Electricidad y Telec 11492 1845 2102 CABLEONE - CABLE ONE, INC., US 30036 1733 1982 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1609 3594 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1583 2:847 4:19 5:2844 6:65 7:1 8:1124 12:1860 13:185 14:1749 15:28 16:3 17:206 18:65 20:49 21:8 23:2664 24:2221 25:2 27:2368 31:1977 32:88 35:27 36:507 37:2797 38:1463 39:262 40:121 41:3159 42:592 43:1926 44:116 45:4570 46:3042 47:204 49:1318 50:1052 51:311 52:1032 54:369 55:3 56:12 57:42 58:1606 59:991 60:431 61:2160 62:1824 63:1800 64:5044 65:2214 66:4690 67:2436 68:1134 69:3197 70:1144 71:565 72:2112 74:2729 75:414 76:451 77:1544 78:1693 79:1851 80:1510 81:1394 82:1075 83:779 84:1044 85:2031 86:575 87:1317 88:929 89:2332 90:211 91:6350 92:1197 93:2372 94:2393 95:2813 96:668 97:357 98:946 99:133 100:81 101:1282 102:61 103:17730 104:3636 105:239 106:656 107:1889 108:699 109:3484 110:1625 111:1778 112:1274 113:1266 114:1118 115:1631 116:1643 117:1741 118:2202 119:1655 120:978 121:1051 122:2444 123:1820 124:1430 125:1901 128:1026 129:649 130:455 131:1592 132:666 133:195 134:1024 135:226 136:471 137:555 138:1927 139:584 140:396 141:704 142:825 143:990 144:791 145:461 146:1177 147:716 148:1633 149:699 150:725 151:1057 152:763 153:312 154:1088 155:759 156:957 157:788 158:650 159:1743 160:939 161:762 162:2576 163:565 164:1056 165:1592 166:453 167:1406 168:3074 169:802 170:3716 171:435 172:1068 173:1998 174:906 175:773 176:1886 177:4049 178:2451 179:1200 180:2230 181:2204 182:2423 183:1166 184:1010 185:13491 186:3568 187:2376 188:2822 189:2028 190:8076 191:1448 192:9840 193:5944 194:4756 195:3971 196:2543 197:1468 198:5542 199:5894 200:7380 201:5015 202:10467 203:10200 204:4564 205:2897 206:3107 207:3176 208:3976 209:3948 210:4036 211:2109 212:3039 213:2743 214:958 215:61 216:5915 217:2128 218:905 219:629 220:1750 221:986 222:1025 223:1255 End of report From nanog at ics-il.net Sat May 19 00:23:26 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 18 May 2018 19:23:26 -0500 (CDT) Subject: Akamai WAF In-Reply-To: <8CB6CE00-E6C2-425A-B236-ACA4B43B1979@benappy.com> References: <8854A276-AE16-4852-83FA-4C8A03F5C068@mtin.net> <8CB6CE00-E6C2-425A-B236-ACA4B43B1979@benappy.com> Message-ID: <594989715.11387.1526689400876.JavaMail.mhammett@ThunderFuck> Seems like they need a mechanism for stuff like this and not just pushing it off to their clients whose first line support systems aren't geared towards dealing with this kind of stuff. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Michel 'ic' Luczak" To: "Justin Wilson" Cc: "NANOG" Sent: Friday, May 18, 2018 9:43:26 AM Subject: Re: Akamai WAF Hi, > On 18 May 2018, at 16:22, Justin Wilson wrote: > > I have a client with a /24 that has somehow been blocked by folks using the Akamai WAF. This is the response we received back from Akamai when we contacted them. > >> On checking the machine logs for ups.com , we found that there is WAF (web application firewall) configured by ups.com , this has to be fixed from the site owners end. > > This is happening with multiple sites, southwest.com is another. I find it odd multiple sites are doing this at the same time. If just one I would believe it was a manual configuration. It seems like something has triggered it. Can someone shed some light on how the WAF works? As far as I know they have some kind of scoring in place for end users IPs so if there is a malicious IP inside the /24 (from Akamai’s WAF point of view) then the scoring can affect other WAFed services as well. BR, ic From jam at zoidtechnologies.com Sat May 19 04:25:04 2018 From: jam at zoidtechnologies.com (Jeff) Date: Sat, 19 May 2018 00:25:04 -0400 Subject: Akamai WAF In-Reply-To: <594989715.11387.1526689400876.JavaMail.mhammett@ThunderFuck> References: <8854A276-AE16-4852-83FA-4C8A03F5C068@mtin.net> <8CB6CE00-E6C2-425A-B236-ACA4B43B1979@benappy.com> <594989715.11387.1526689400876.JavaMail.mhammett@ThunderFuck> Message-ID: <3e277756-15fd-7951-8402-9cbcad458b57@zoidtechnologies.com> Greetings, On 05/18/2018 08:23 PM, Mike Hammett wrote: > Seems like they need a mechanism for stuff like this and not just pushing it off to their clients whose first line support systems aren't geared towards dealing with this kind of stuff. > I agree that 1st level in 2018, for the most part, is not geared for this kind of thing. the UCE abuse lists as well as various filters on the network ought to have a way to block something more specific than a /24. regards, J From baldur.norddahl at gmail.com Sat May 19 20:28:07 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 19 May 2018 22:28:07 +0200 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: What happened to do not trust anyone? Create your own resiliency by being multihomed to as many transits you can afford. You need the ability to shutdown a transit that is having trouble. It happens to all of them. Regards Baldur ons. 16. maj 2018 19.02 skrev David Hubbard : > I’m curious if anyone who’s used 3356 for transit has found shortcomings > in how their peering and redundancy is configured, or what a normal > expectation to have is. The Tampa Bay market has been completely down for > 3356 IP services twice so far this year, each for what I’d consider an > unacceptable period of time (many hours). I’m learning that the entire > market is served by just two fiber routes, through cities hundreds of miles > away in either direction. So, basically two fiber cuts, potentially 1000+ > miles apart, takes the entire region down. The most recent occurrence was > a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 > driving miles apart) took IP services down for hours. It did not take > point to point circuits to out of market locations down, so that suggests > they even have the ability to be more redundant and simply choose not to. > > I feel like it’s not unreasonable to expect more redundancy, or a much > smaller attack surface given a disgruntled lineman who knows the routes > could take an entire region down with a planned cut four states apart. > Maybe other regions are better designed? Or are my expectations > unreasonable? I carry three peers in that market, so it hasn’t been > outage-causing, but I use 3356 in other markets too, and have plans for > more, but it makes me wonder if I just haven't had the pleasure of similar > outages elsewhere yet and I should factor that expectation into the > design. It creates a problem for me in one location where I can only get > them and Cogent, since Cogent can't be relied on for IPv6 service, which I > need. > > Thanks > > > From dhubbard at dino.hostasaurus.com Sat May 19 21:54:51 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sat, 19 May 2018 21:54:51 +0000 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: , Message-ID: Yes, I do, as stated in my initial email. My inquiry is about whether this level of downtime, and lack of redundancy for a given region, is normal for 3356. There are some markets where diverse paths are not so easy to acquire. ________________________________ From: Robert DeVita Sent: Saturday, May 19, 2018 5:36:23 PM To: David Hubbard; nanog at nanog.org Subject: Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) If this is a know issue and has happened before and point to point circuits aren’t effected you always have the opportunity to diversify your own network and get private lines back to Miami, Jax, Atlanta or Dallas to create your own diversity don’t you? Robert DeVita Managing Director Mejeticks c. 469-441-8864 e. radevita at mejeticks.com _____________________________ From: David Hubbard Sent: Wednesday, May 16, 2018 12:03 PM Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) To: I’m curious if anyone who’s used 3356 for transit has found shortcomings in how their peering and redundancy is configured, or what a normal expectation to have is. The Tampa Bay market has been completely down for 3356 IP services twice so far this year, each for what I’d consider an unacceptable period of time (many hours). I’m learning that the entire market is served by just two fiber routes, through cities hundreds of miles away in either direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes the entire region down. The most recent occurrence was a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP services down for hours. It did not take point to point circuits to out of market locations down, so that suggests they even have the ability to be more redundant and simply choose not to. I feel like it’s not unreasonable to expect more redundancy, or a much smaller attack surface given a disgruntled lineman who knows the routes could take an entire region down with a planned cut four states apart. Maybe other regions are better designed? Or are my expectations unreasonable? I carry three peers in that market, so it hasn’t been outage-causing, but I use 3356 in other markets too, and have plans for more, but it makes me wonder if I just haven't had the pleasure of similar outages elsewhere yet and I should factor that expectation into the design. It creates a problem for me in one location where I can only get them and Cogent, since Cogent can't be relied on for IPv6 service, which I need. Thanks From valdis.kletnieks at vt.edu Sun May 20 03:43:07 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 19 May 2018 23:43:07 -0400 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: <93316.1526787787@turing-police.cc.vt.edu> On Sat, 19 May 2018 22:28:07 +0200, Baldur Norddahl said: > What happened to do not trust anyone? Create your own resiliency by being > multihomed to as many transits you can afford. Re-read what David Hubbard said: > unacceptable period of time (many hours). I���m learning that the entire > market is served by just two fiber routes, through cities hundreds of miles > away in either direction. So, basically two fiber cuts, potentially 1000+ > miles apart, takes the entire region down. If in fact there's only two fiber conduit approaches to the area, he's basically stuck no matter how many companies sell him bandwidth in those two conduits. He can contract with 8 companies to have 4 paths through each conduit, and 2 cable cuts *still* leave him dead in the water. (Bonus points for estimating the chances that at least one of those 8 companies will do one or more of the following: (a) not knowing which conduit the path will be in, (b) actively lie about the conduit in order to seal the deal, or (c) re-provision the path several weeks later into the other conduit....) And he probably doesn't have the budget to dig a third trench several hundred miles to a third city... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From baldur.norddahl at gmail.com Sun May 20 07:16:25 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 20 May 2018 09:16:25 +0200 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <93316.1526787787@turing-police.cc.vt.edu> References: <93316.1526787787@turing-police.cc.vt.edu> Message-ID: <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> Den 20/05/2018 kl. 05.43 skrev valdis.kletnieks at vt.edu: > On Sat, 19 May 2018 22:28:07 +0200, Baldur Norddahl said: >> What happened to do not trust anyone? Create your own resiliency by being >> multihomed to as many transits you can afford. > Re-read what David Hubbard said: > >> unacceptable period of time (many hours). I’m learning that the entire >> market is served by just two fiber routes, through cities hundreds of miles >> away in either direction. So, basically two fiber cuts, potentially 1000+ >> miles apart, takes the entire region down. > If in fact there's only two fiber conduit approaches to the area, he's > basically stuck no matter how many companies sell him bandwidth in those two > conduits. He can contract with 8 companies to have 4 paths through each > conduit, and 2 cable cuts *still* leave him dead in the water. He is complaining about AS3356 in specific and claiming they COULD reroute around it but choose not to. This leads me to assume there are alternatives. Two places, Miami and Texas, are mentioned and that a double fault, one in Miami and another in Texas would bring down the network. I am from Europe, but am I to believe that Miami and Texas (or anywhere between those two) are served by only two fiber conduits? This would have several big states only connected two ways. The question was if downtime on a transit provider of many hours is unacceptable. I am offering my experience that this happens to all of them. Some of them can have problems that last days not hours. Do not ever assume that a so called "tier 1" network is good as your only transit. Also a total cut of from the world is the good kind of trouble they can have. That would just lead them to lose a large part of the global routing table. Your router will automatically choose one of your other transits. The bad kind of trouble is when they have packet loss to some few (but important) destinations and your customer thinks it is you that is having issues. And basically all you can do about it is to "shutdown" the session and wait until they fixed the issue. I am offering the view that one might consider that kind of downtime unacceptable, but it is just a matter of fact that they all have it. The two options to avoid it is to buy from a smaller local ISP instead - one that has multiple transits. Or to have multiple transits yourself and be prepared to deal with it. Regards Baldur From mark.tinka at seacom.mu Sun May 20 15:16:10 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 20 May 2018 17:16:10 +0200 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: On 19/May/18 22:28, Baldur Norddahl wrote: > What happened to do not trust anyone? Create your own resiliency by being > multihomed to as many transits you can afford. > > You need the ability to shutdown a transit that is having trouble. It > happens to all of them. Agreed. Mark. From mark.tinka at seacom.mu Sun May 20 15:19:33 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 20 May 2018 17:19:33 +0200 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> References: <93316.1526787787@turing-police.cc.vt.edu> <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> Message-ID: <835392c6-63bd-b685-0118-e7ed3cbdd22f@seacom.mu> On 20/May/18 09:16, Baldur Norddahl wrote: > > The question was if downtime on a transit provider of many hours is > unacceptable. I am offering my experience that this happens to all of > them. Some of them can have problems that last days not hours. Do not > ever assume that a so called "tier 1" network is good as your only > transit. And that is where the sage advice is... Just because they are "large", "global", "transit-free", "international", "Tier this or Tier that", don't think they are beyond fault. And more importantly, don't allow your customers to assume they are beyond fault, just because you aren't them. Take control of your situation, especially if you can. Mark. From joelja at bogus.com Sun May 20 18:12:02 2018 From: joelja at bogus.com (joel jaeggli) Date: Sun, 20 May 2018 11:12:02 -0700 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> Message-ID: <45e908ca-21f1-8d80-237f-60e2a476e0b9@bogus.com> On 5/17/18 6:24 AM, Mike Hammett wrote: > I often question why\how people build networks the way they do. There's some industry hard-on with having a few ginormous routers instead of many smaller ones. I've learned that when building Internet Exchanges, the number of networks that don't have BGP edge routers in major markets where they have a presence is quite a bit larger than one would expect. I heard a podcast once (I forget if it was Packet Pushers or Network Collective) postulating that the reason why everything runs back to a few big ass routers is that someone decided to spend a crap-load of money on big ass routers for bragging rights, so now they have to run everything they can through them to A) "prove" their purchase wasn't foolish and B) because they now can't afford to buy anything else. There  seems to be a bit of overstatement with respect to how large these are... alcatel/nokia 7750 (L3's newer PE platform) is large but not outlandish and they've been deployed for a couple years. it's relatively similar in capacity  or a to to the devices that many of us interconnect with them using.  Most of their customers probably though not always need less fib then they need on a PE router. There is a longer time-scale overhang from the choice to design of MPLS core networks 15-20 years ago where PE routers have more to do fib wise then do cores (which may well be larger and simpler, since most of what they do is label switching), that drives the selection of what hardware goes in the edge in ways than an IP only carrier might make different choices (e.g. this big fib/queue/buffer router might have been a large l3 switch). > There's no reason why Tampa doesn't have a direct L3 adjacency to Miami, Atlanta, Houston, and Charlotte over diverse infrastructure to all four. Obviously there's room to add\drop from that list, but it gets the point across. the number of paths available into and out a market seems somewhat orthogonal to the number of routers. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "David Hubbard" > To: nanog at nanog.org > Sent: Wednesday, May 16, 2018 11:59:42 AM > Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) > > I’m curious if anyone who’s used 3356 for transit has found shortcomings in how their peering and redundancy is configured, or what a normal expectation to have is. The Tampa Bay market has been completely down for 3356 IP services twice so far this year, each for what I’d consider an unacceptable period of time (many hours). I’m learning that the entire market is served by just two fiber routes, through cities hundreds of miles away in either direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes the entire region down. The most recent occurrence was a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP services down for hours. It did not take point to point circuits to out of market locations down, so that suggests they even have the ability to be more redundant and simply choose not to. > > I feel like it’s not unreasonable to expect more redundancy, or a much smaller attack surface given a disgruntled lineman who knows the routes could take an entire region down with a planned cut four states apart. Maybe other regions are better designed? Or are my expectations unreasonable? I carry three peers in that market, so it hasn’t been outage-causing, but I use 3356 in other markets too, and have plans for more, but it makes me wonder if I just haven't had the pleasure of similar outages elsewhere yet and I should factor that expectation into the design. It creates a problem for me in one location where I can only get them and Cogent, since Cogent can't be relied on for IPv6 service, which I need. > > Thanks > > > > From rubensk at gmail.com Sun May 20 19:32:32 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 20 May 2018 16:32:32 -0300 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: CenturyLink bought Level 3, which bought Global Crossing, which bought Impsat; this makes every market unique, for the good and bad of it. What I have as a customer feeling is that Global Crossing was the most quality-minded of the 4, while the other 3 is/were more "take what we give you and shut up". Rubens On Wed, May 16, 2018 at 1:59 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > I’m curious if anyone who’s used 3356 for transit has found shortcomings > in how their peering and redundancy is configured, or what a normal > expectation to have is. The Tampa Bay market has been completely down for > 3356 IP services twice so far this year, each for what I’d consider an > unacceptable period of time (many hours). I’m learning that the entire > market is served by just two fiber routes, through cities hundreds of miles > away in either direction. So, basically two fiber cuts, potentially 1000+ > miles apart, takes the entire region down. The most recent occurrence was > a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 > driving miles apart) took IP services down for hours. It did not take > point to point circuits to out of market locations down, so that suggests > they even have the ability to be more redundant and simply choose not to. > > I feel like it’s not unreasonable to expect more redundancy, or a much > smaller attack surface given a disgruntled lineman who knows the routes > could take an entire region down with a planned cut four states apart. > Maybe other regions are better designed? Or are my expectations > unreasonable? I carry three peers in that market, so it hasn’t been > outage-causing, but I use 3356 in other markets too, and have plans for > more, but it makes me wonder if I just haven't had the pleasure of similar > outages elsewhere yet and I should factor that expectation into the > design. It creates a problem for me in one location where I can only get > them and Cogent, since Cogent can't be relied on for IPv6 service, which I > need. > > Thanks > > > From morrowc.lists at gmail.com Sun May 20 19:47:01 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 20 May 2018 12:47:01 -0700 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: On Sun, May 20, 2018 at 12:33 PM Rubens Kuhl wrote: > > CenturyLink bought Level 3, which bought Global Crossing, which bought > Impsat; this makes every market unique, for the good and bad of it. > > What I have as a customer feeling is that Global Crossing was the most > quality-minded of the 4, while the other 3 is/were more "take what we give > you and shut up". that might be a thing related to the time when GC was around individually though, right? they could have been considered 'boutique' network provider at the time... The L3/GC merger was ~10 yrs ago? much has changed in the carrier space since... being bigger dpesn't often make companies higher touch :) From valdis.kletnieks at vt.edu Sun May 20 22:43:42 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 20 May 2018 18:43:42 -0400 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> References: <93316.1526787787@turing-police.cc.vt.edu> <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> Message-ID: <202449.1526856222@turing-police.cc.vt.edu> On Sun, 20 May 2018 09:16:25 +0200, Baldur Norddahl said: > He is complaining about AS3356 in specific and claiming they COULD > reroute around it but choose not to. This leads me to assume there are > alternatives. Two places, Miami and Texas, are mentioned and that a > double fault, one in Miami and another in Texas would bring down the > network. I am from Europe, but am I to believe that Miami and Texas (or > anywhere between those two) are served by only two fiber conduits? There's a difference between "route around it by flipping some BGP magic" and "route around it by digging a ditch to a third city". The fact that other places have other conduits doesn't change the fact that a given city may only have two physical conduits handy. Often, there are other *possible* paths that could be built out, but other providers have looked at the cost of digging a ditch from the city, out a third path, to their closest POP, and decided it's not economically feasible. You can only route across the fiber that's actually there and lit up. You're from Europe? OK, consider this setup: Andorra. Two providers, one of who backhaul that path all the way to Madrid, and the other that backhauls to Marseilles. Sure, there's other cities along the way, but there's no fiber path from where you are to there. For instance, the fiber path may run from Madrid to Zaragoza, where it splits 3 ways to Pamplona, Andorra, and Barcelona - but if Barcelona and Pamplona don't provide alternate paths out to the net, you're still going to Madrid. Meanwhile, other companies may provide service to lots of smaller places along the border on the Spain side, and other companies provide service to lots of places on the French side, but not into Andorra itself. You don't like that, consider any one of the many European cities that are in a deep river valley, so the only realistic ways to the outside world are "upstream" and "downstream". > The question was if downtime on a transit provider of many hours is > unacceptable. I am offering my experience that this happens to all of > them. Some of them can have problems that last days not hours. Do not > ever assume that a so called "tier 1" network is good as your only transit. The gotcha here is the very high danger than with only two paths out of the city, your second and third choices are fate-sharing with that Tier 1. If you're in Andorra, and you have 8 providers that share a path through a tunnel to Toulouse, and another 6 that share a bridge to Barcelona, you still have a problem. (That, and anybody who buys transit only from one Tier 1 is going to have a really hard time getting routes to the *rest* of the internet...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at ics-il.net Mon May 21 01:04:57 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 20 May 2018 20:04:57 -0500 (CDT) Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <202449.1526856222@turing-police.cc.vt.edu> References: <93316.1526787787@turing-police.cc.vt.edu> <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> <202449.1526856222@turing-police.cc.vt.edu> Message-ID: <552100549.12116.1526864696620.JavaMail.mhammett@ThunderFuck> To circle back to the original post... Level 3 does have multiple routes out of Tampa. They just apparently don't use them all for their transit service. Why not? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "valdis kletnieks" To: "Baldur Norddahl" Cc: nanog at nanog.org Sent: Sunday, May 20, 2018 5:43:42 PM Subject: Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) On Sun, 20 May 2018 09:16:25 +0200, Baldur Norddahl said: > He is complaining about AS3356 in specific and claiming they COULD > reroute around it but choose not to. This leads me to assume there are > alternatives. Two places, Miami and Texas, are mentioned and that a > double fault, one in Miami and another in Texas would bring down the > network. I am from Europe, but am I to believe that Miami and Texas (or > anywhere between those two) are served by only two fiber conduits? There's a difference between "route around it by flipping some BGP magic" and "route around it by digging a ditch to a third city". The fact that other places have other conduits doesn't change the fact that a given city may only have two physical conduits handy. Often, there are other *possible* paths that could be built out, but other providers have looked at the cost of digging a ditch from the city, out a third path, to their closest POP, and decided it's not economically feasible. You can only route across the fiber that's actually there and lit up. You're from Europe? OK, consider this setup: Andorra. Two providers, one of who backhaul that path all the way to Madrid, and the other that backhauls to Marseilles. Sure, there's other cities along the way, but there's no fiber path from where you are to there. For instance, the fiber path may run from Madrid to Zaragoza, where it splits 3 ways to Pamplona, Andorra, and Barcelona - but if Barcelona and Pamplona don't provide alternate paths out to the net, you're still going to Madrid. Meanwhile, other companies may provide service to lots of smaller places along the border on the Spain side, and other companies provide service to lots of places on the French side, but not into Andorra itself. You don't like that, consider any one of the many European cities that are in a deep river valley, so the only realistic ways to the outside world are "upstream" and "downstream". > The question was if downtime on a transit provider of many hours is > unacceptable. I am offering my experience that this happens to all of > them. Some of them can have problems that last days not hours. Do not > ever assume that a so called "tier 1" network is good as your only transit. The gotcha here is the very high danger than with only two paths out of the city, your second and third choices are fate-sharing with that Tier 1. If you're in Andorra, and you have 8 providers that share a path through a tunnel to Toulouse, and another 6 that share a bridge to Barcelona, you still have a problem. (That, and anybody who buys transit only from one Tier 1 is going to have a really hard time getting routes to the *rest* of the internet...) From wjhns61 at hardakers.net Mon May 21 15:21:27 2018 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Mon, 21 May 2018 08:21:27 -0700 Subject: Need AT&T / Ameritech DNS contact Message-ID: Every other path at filing a bug has failed me... If there is someone here with control over ameritech.net's name servers, can you reach out to me please? -- Wes Hardaker USC/ISI From large.hadron.collider at gmx.com Mon May 21 16:10:51 2018 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Mon, 21 May 2018 16:10:51 +0000 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <835392c6-63bd-b685-0118-e7ed3cbdd22f@seacom.mu> References: <93316.1526787787@turing-police.cc.vt.edu> <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> <835392c6-63bd-b685-0118-e7ed3cbdd22f@seacom.mu> Message-ID: <2c9df2d1-8fa7-3c55-a5b5-62c915d54b52@gmx.com> I would go as far as to say that Tier 1 is a derogatory designation, but I have a beef with Cogent because they're expecting otherwise Tier 1 IPv6 ISP Hurricane Electric to bow to the altar of Cogent. On 05/20/2018 15:19, Mark Tinka wrote: > > On 20/May/18 09:16, Baldur Norddahl wrote: > >> The question was if downtime on a transit provider of many hours is >> unacceptable. I am offering my experience that this happens to all of >> them. Some of them can have problems that last days not hours. Do not >> ever assume that a so called "tier 1" network is good as your only >> transit. > And that is where the sage advice is... > > Just because they are "large", "global", "transit-free", > "international", "Tier this or Tier that", don't think they are beyond > fault. And more importantly, don't allow your customers to assume they > are beyond fault, just because you aren't them. > > Take control of your situation, especially if you can. > > Mark. From cma at cmadams.net Mon May 21 19:35:55 2018 From: cma at cmadams.net (Chris Adams) Date: Mon, 21 May 2018 14:35:55 -0500 Subject: AT&T mobile intercepting TCP sockets? Message-ID: <20180521193555.GA13683@cmadams.net> I ran into an odd issue with access to a website I manage from AT&T mobile devices this weekend. The website worked for everybody not on AT&T mobile, and AT&T mobile users could access other sites; the problem was just this combination. Android and iOS phones, as well as a Linux system tethered to an Android phone, all had the same problem. On the Linux system, I disabled IPv6 in Firefox, and it could then connect. Browsers got various "connection reset" type errors; on Linux, I could telnet to port 80 or 443, and it would connect and immediately close. The site does have an IPv6 address, but I had missed getting the webserver to listen on IPv6 (my mistake). Adding that looks to have solved the problem. When I ran tcpdump on the server and had someone try to connect from their AT&T mobile iPhone, I saw three connection attempts a few tenths of a second apart (all refused by the server). My question is this: is AT&T mobile intercepting the TCP socket (and not handling "connection refused" correctly)? Is that a known thing? -- Chris Adams From jared at puck.nether.net Mon May 21 19:39:52 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 21 May 2018 15:39:52 -0400 Subject: AT&T mobile intercepting TCP sockets? In-Reply-To: <20180521193555.GA13683@cmadams.net> References: <20180521193555.GA13683@cmadams.net> Message-ID: <57489D45-A6C5-44F9-BE1F-99AA1A26A9A0@puck.nether.net> > On May 21, 2018, at 3:35 PM, Chris Adams wrote: > > I ran into an odd issue with access to a website I manage from AT&T > mobile devices this weekend. The website worked for everybody not on > AT&T mobile, and AT&T mobile users could access other sites; the problem > was just this combination. > > Android and iOS phones, as well as a Linux system tethered to an Android > phone, all had the same problem. On the Linux system, I disabled IPv6 > in Firefox, and it could then connect. Browsers got various "connection > reset" type errors; on Linux, I could telnet to port 80 or 443, and it > would connect and immediately close. > > The site does have an IPv6 address, but I had missed getting the > webserver to listen on IPv6 (my mistake). Adding that looks to have > solved the problem. > > When I ran tcpdump on the server and had someone try to connect from > their AT&T mobile iPhone, I saw three connection attempts a few tenths > of a second apart (all refused by the server). > > My question is this: is AT&T mobile intercepting the TCP socket (and > not handling "connection refused" correctly)? Is that a known thing? Yes they are. You can see this in test-ipv6.com it will report the proxy/Via Header addition. - jared From surfer at mauigateway.com Mon May 21 20:05:10 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 21 May 2018 13:05:10 -0700 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) Message-ID: <20180521130510.7534A3CB@m0117458.ppops.net> --- joelja at bogus.com wrote: From: joel jaeggli alcatel/nokia 7750 (L3's newer PE platform) is large but not outlandish and they've been deployed for a couple years. -------------------------------------- More than a couple... I was using them for MPLS over 10 years ago. They're really good. Also, they have different sizes; from the itty bitty 7750 SR-1 (2ru) all the way to the BFR 7750 SR-12e (22ru) https://onestore.nokia.com/asset/164728/Nokia_7750_SR_R15-1_Data_Sheet_EN.pdf scott From lists at as23738.net Mon May 21 20:10:43 2018 From: lists at as23738.net (lists at as23738.net) Date: Mon, 21 May 2018 13:10:43 -0700 Subject: AT&T mobile intercepting TCP sockets? In-Reply-To: <20180521193555.GA13683@cmadams.net> References: <20180521193555.GA13683@cmadams.net> Message-ID: <1526933443.118135.1379823168.4C684FB0@webmail.messagingengine.com> IME ATT has intercepted virtually everything on mobile (this is on a hotspot) - If I curl a HTTP vs HTTPS site, I get a different IP on each (one is obviously a shared web proxy); if I download images, they won't match md5-wise with the original version, etc. I have trouble connecting to VPNs that aren't standard SSL VPNs. They appear to MITM all web traffic they can. Using third party DNS servers has questionable results. On Mon, May 21, 2018, at 12:35 PM, Chris Adams wrote: > I ran into an odd issue with access to a website I manage from AT&T > mobile devices this weekend. The website worked for everybody not on > AT&T mobile, and AT&T mobile users could access other sites; the problem > was just this combination. > > Android and iOS phones, as well as a Linux system tethered to an Android > phone, all had the same problem. On the Linux system, I disabled IPv6 > in Firefox, and it could then connect. Browsers got various "connection > reset" type errors; on Linux, I could telnet to port 80 or 443, and it > would connect and immediately close. > > The site does have an IPv6 address, but I had missed getting the > webserver to listen on IPv6 (my mistake). Adding that looks to have > solved the problem. > > When I ran tcpdump on the server and had someone try to connect from > their AT&T mobile iPhone, I saw three connection attempts a few tenths > of a second apart (all refused by the server). > > My question is this: is AT&T mobile intercepting the TCP socket (and > not handling "connection refused" correctly)? Is that a known thing? > > -- > Chris Adams From neel at neelc.org Wed May 16 17:50:06 2018 From: neel at neelc.org (Neel Chauhan) Date: Wed, 16 May 2018 13:50:06 -0400 Subject: Verizon/UUNET AS701 blocking Tor "directory" server (IPv4 86.59.21.38) Message-ID: Hi nanog mailing list, Keep in mind that I am not a practicing network engineer, although I do have interest and knowledge on networking topics. I do not work for Verizon. I subscribe to Verizon FiOS, but not Verizon Wireless or Verizon's enterprise services. The Tor "directory" server with the IPv4 address 86.59.21.38 has been blocked by Verizon's AS701 backbone for a few months now. AS701 provides Internet connectivity to Verizon FiOS and Wireless. The design of Tor is that even though anyone can set up a "relay", there are a few central directory servers which clients go to first to get a list of relay servers and build a circuit (which is a path of three relays to reach a destination). A more descriptive overview of Tor is available here: https://www.torproject.org/about/overview.html.en . While I can still access other Tor directory servers from Verizon FiOS as running Tor as a client or relay does not require every directory server be unblocked, blocking one of them could possibly mean breaking some part of the Internet for a Verizon customer. A traceroute to 86.59.21.38 from FiOS shows that I can get through verizon-gni.net which is Verizon's internal FiOS network, but not ALTER.NET, which is Verizon's UUNet backbone: neel at xb2:~ % traceroute 86.59.21.38 traceroute to 86.59.21.38 (86.59.21.38), 64 hops max, 40 byte packets 1 unknown (192.168.1.1) 1.128 ms 0.780 ms 0.613 ms 2 lo0-100.NYCMNY-VFTTP-401.verizon-gni.net (173.68.77.1) 1.001 ms 3.632 ms 0.900 ms 3 B3401.NYCMNY-LCR-22.verizon-gni.net (100.41.137.96) 2.291 ms B3401.NYCMNY-LCR-21.verizon-gni.net (100.41.137.94) 3.172 ms 4.046 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * ^C neel at xb2:~ % In a normal traceroute, I would see ALTER.NET on hop 5. Also, this filtering is not a subnet filtering. A traceroute to 86.59.21.1 works: neel at xb2:~ % traceroute 86.59.21.1 traceroute to 86.59.21.1 (86.59.21.1), 64 hops max, 40 byte packets 1 unknown (192.168.1.1) 0.863 ms 0.757 ms 0.579 ms 2 lo0-100.NYCMNY-VFTTP-401.verizon-gni.net (173.68.77.1) 1.010 ms 1.545 ms 1.034 ms 3 B3401.NYCMNY-LCR-22.verizon-gni.net (100.41.137.96) 3.616 ms B3401.NYCMNY-LCR-21.verizon-gni.net (100.41.137.94) 5.696 ms 10.062 ms 4 * * * 5 0.et-5-1-5.BR3.NYC4.ALTER.NET (140.222.2.127) 3.492 ms 3.506 ms 2.996 ms 6 204.255.168.118 (204.255.168.118) 8.462 ms 7.479 ms 7.252 ms 7 144.232.4.84 (144.232.4.84) 5.041 ms 4.688 ms sl-crs3-lon-0-6-3-0.sprintlink.net (144.232.9.165) 71.865 ms 8 sl-crs2-lon-0-0-3-0.sprintlink.net (213.206.128.181) 72.214 ms 73.579 ms 72.339 ms 9 213.206.129.142 (213.206.129.142) 81.390 ms sl-crs4-ams-0-7-0-3.sprintlink.net (213.206.129.139) 85.854 ms 93.238 ms 10 217.149.47.46 (217.149.47.46) 79.004 ms 85.669 ms 79.392 ms 11 ams5-core-1.bundle-ether1.tele2.net (130.244.82.54) 86.507 ms 78.374 ms 77.740 ms 12 ams-core-2.bundle-ether9.tele2.net (130.244.82.57) 79.642 ms 77.926 ms 81.515 ms 13 wen3-core-2.bundle-ether15.tele2.net (130.244.71.47) 105.400 ms 105.089 ms 109.751 ms 14 tele2at-bundle2-vie3.net.uta.at (212.152.189.65) 122.716 ms 110.820 ms 114.354 ms 15 86.59.21.1 (86.59.21.1) 106.389 ms * 105.379 ms neel at xb2:~ % I had posted this finding on Tor's mailing list (https://lists.torproject.org/pipermail/tor-relays/2018-May/015218.html). I am posting here as (I believe) Verizon NOC people are more likely to read NANOG mailing lists than Tor mailing lists, although this post is modified from the original because not all network engineers may know how Tor works. From Tor developer Roger Dingledine (at the Tor mailing list), the reason why Verizon blocked 86.59.21.38 in the first place is probably the WannaCry ransomware, and the VZ NOC didn't realize it was a Tor IP address (or how Tor works), and then whoever did this block forgot about it and moved on. I can understand that you all may not know how Tor works either, so I included an overview link above. It could also be possible that it's the NN repeal (but less likely since it is on the level of UUNET not FiOS). I also contacted the operator of 86.59.21.38 as well as Verizon FiOS support, and neither were of much help (the former is obvious as he's Austrian). Well, thank you for reading. Best, Neel Chauhan === https://www.neelc.org/ From ben at 6by7.net Wed May 16 23:32:34 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 16 May 2018 16:32:34 -0700 Subject: is odd number of links in lag group ok In-Reply-To: <20180516224824.GA85770@spider.typo.org> References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> <20180516224824.GA85770@spider.typo.org> Message-ID: <542A8BE4-DE14-4954-AB81-3306236CE556@6by7.net> While it goes without saying that you need the same (can be 5!) number of links to each router in a multichassis LAG, what isn’t so obvious are things like port groups etc. If you have an oversubscribed platform, you might need to look at running each wire in a LAG to different port groups, and then look at things like switch ASICs and span those as well. Even try to span diverse slots/modules if you can. But 5 6 or 4 per chassis shouldn’t make a huge difference. -Ben > On May 16, 2018, at 3:48 PM, Wayne Bouchard wrote: > > As others have noted, there can be implementation specific issues that > you can't necessarily predict but most typically when I hear "odd vs > even" discussions, usually the caveat is not a trunk but a redundant > connection. Putting three links on router A and two links on router B > obviously doesn't work well. > >> On Tue, May 15, 2018 at 10:15:19AM -0500, Aaron Gould wrote: >> I have (2) 10 gig links bundled in a lag to my upstream internet provider. >> and we need more internet capacity. Is it cool to add a third 10 gig to my >> existing 20 gig lag internet connection? >> >> >> >> I'm asking since I heard in the past something negative about odd numbers of >> lag members. .but I also have heard that it's not a big deal. Let me know >> please >> >> >> >> -Aaron >> >> >> >> > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ From ben at 6by7.net Sat May 19 20:51:15 2018 From: ben at 6by7.net (Ben Cannon) Date: Sat, 19 May 2018 13:51:15 -0700 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> Message-ID: <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> Isn’t that the ASR9010? (And before that 7609?) -Ben > On May 18, 2018, at 4:20 AM, Tom Hill wrote: > >> On 17/05/18 14:24, Mike Hammett wrote: >> There's some industry hard-on with having a few ginormous routers instead of many smaller ones. > > "Industry hard-on", ITYM "Greedy vendors". > > Try finding a 'small' router with a lot of ports (1 & 10GE) for your > customers, and the right features/TCAM/CP performance, for a price that > permits you to buy a lot of them. > > -- > Tom From C-Mack.McBride at charter.com Mon May 21 16:20:19 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Mon, 21 May 2018 16:20:19 +0000 Subject: AS 205869 - BGP hijacking source Message-ID: <27f58787aeb34eef84686bdc84fa4cec@SC58MEXGP032.CORP.CHARTERCOM.com> I am sending this notification as I have become aware that 205869 appears to be performing BGP hijacking and spoofing AS paths as well. Impacted organizations may wish to contact the upstream providers of this ASN. Mack McBride Contractor The contents of this message are my own and are not the opinions or nor do they represent my employer. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From francois.devienne at expereo.com Thu May 17 10:14:19 2018 From: francois.devienne at expereo.com (Francois Devienne) Date: Thu, 17 May 2018 10:14:19 +0000 Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) In-Reply-To: <22961-b6.nogs.nanog-31082017210501-C0@news.border6.com> References: <22961-b6.nogs.nanog-31082017210501-C0@news.border6.com> Message-ID: Hi Job, I believe your disclaimer makes a lot of sense. From our perspective using more specifics is one of the options to make BGP follow the optimized path instead of the « natural » path. We used to be doing more specifics because with the same prefix being announced, we were simply not getting a best route announced back to the optimiser. Since the adoption of BGP ADD-PATH, our solution does not need to use more specifics to maintain a full collection of the routers BGP table. (In addition, it has actually never been a strong a requirement due to the use of other SNMP collection processes.) Therefore LOCAL_PREF is the option we advise and implement. The examples you mention confirm the issues are mainly due to poorly configured networks where routes are leaked out although they shouldn’t be. Adequate routers are able to filter out prefixes based on attributes like communities, which we set by default. We’ve had an instance of such an issue with one of our customers a few years ago; it turned out to be mistaken CLI commands that the engineer gave to the router. Our XCA software service and platform has hundreds of ASs running for years and none are making any noise. Another point of discussion is the fact that transit and large content providers actually accept thousands of routes coming from anywhere, there is a lot of room for optimization. And I know how much you personally try to contribute to enhance this. There actually is a reason for operating BGP optimizers. The BGP protocol, while robust and scalable, doesn't know anything about link capacity, doesn’t apply performance analytics and can easily drive links into saturation, introducing packet loss. Also, it is not aware of commercial agreements like CDR, generating costs that could be prevented. It also, of course, ignores the performance of available paths. All of the above actually impacts customer traffic and business performance. Since a few years we see our Customers take more care of quality and capacity management… and stop relying on BGP « blindly ». Most transit providers like to explain that their service are premium and that’s the reason why their prices are premium. But when you look at actual performance measurements, some premium providers are actually just behind the cheaper ones. I’m in RIPE 76 tomorrow, I’ll be more than happy to discuss this topic further with you. Kind regards, François (I’m a product engineer at Border 6 - Expereo, a BGP optimization software company.) François DEVIENNE Mobile: +33.651.937.927 E-mail: francois.devienne at expereo.com BORDER 6 S.A.S. - EXPEREO On Aug 31, 2017 (35), at 22:06, Job Snijders > wrote: Dear all, disclaimer: [ The following is targetted at the context where a BGP optimizer generates BGP announcement that are ordinarily not seen in the Default-Free Zone. The OP indicated they announce a /23, and were unpleasantly surprised to see two unauthorized announcements for /24 more-specifics pop up in their alerting system. No permission was granted to create and announce these more-specifics. The AS_PATH for those /24 announcements was entirely fabricated. Original thread https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ] On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: Presuming it was a route optimizer and the issue was ongoing, what would be the suggested course of action? I strongly recommend to turn off those BGP optimizers, glue the ports shut, burn the hardware, and salt the grounds on which the BGP optimizer sales people walked. It is extremely irresponsible behavior to use software that generates _fake_ BGP more-specifics for the purpose of traffic engineering. You simply cannot expect that those more-specifics will never escape into the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see software bugs related to NO_EXPORT, and community-squashing configuration mistakes happen all the time. Consider the following: if you leak your own internal more-specifics, at least you are the legitimate destination. (You may suffer from suboptimal routing, but it isn't guaranteed downtime.) However if you generate fake more-specifics for prefixes belonging to OTHER organisations, you essentially are complicit in BGP hijacking. If those fake more-specifics accidentally leak into the DFZ, you are bringing down the actual owner of such prefixes, and depriving people from access to the Internet. Example case: https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html reach out to those 2 AS owners and see if they could stop it? Yes, absolutely! And if everyone of the affected parties of this localized hijack leak (or should we say 'victims') reaches out to the wrongdoers, they contribute peer pressure to rectify the situation. Just make sure you assign blame to the correct party. :) Or is it something I just have to live with as a traffic engineering solution they are using and mark the alerts as false positives? No, this is not something we should just accept. The Default-Free Zone is a shared resource. Anyone using "BGP optimizers" is not only risking their own online presence, but also everyone else's. Using a BGP optimizer is essentially trading a degree of risk to society for the purpose of saving a few bucks or milliseconds. It is basically saying: "The optimizer helps me, but may hurt others, and I am fine with that". An analogy: We don't want transporters of radioactive material to cut corners by using non-existant roads to bring the spent nuclear fuels from A to B faster, nor do we want them to rely on non-robust shielding that works "most of the time". We share the BGP DFZ environment, 'BGP optimizers' are downright pollution contributors. Kind regards, Job ps. If you want to do BGP optimization: don't have the BGP optimizer generate fake BGP announcements, but focus only on manipulating non-transitive attributes (like LOCAL_PREF) on real announcements you actually received from others. Or Perhaps BGP optimizers shouldn't even talk BGP but rather push freshly generated TE-optimized routing-policy to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate real announcements)... there are ways to do this, without risk to others! p.s. providing a publicly available BGP looking glasses will contribute to proving your innocence in cases like these. Since in many cases the AS_PATH is a complete fabrication, we need to manually check every AS in the AS_PATH to see whether the AS carries the fake more-specific. A public looking glass speeds up this fault-finding process. If you don't want to host a webinterface yourself, please consider sending a BGP feed to the Route Views Project or RIPE RIS, or for something queryable in a real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ From farzi at gatech.edu Thu May 17 15:42:40 2018 From: farzi at gatech.edu (Badiei, Farzaneh) Date: Thu, 17 May 2018 15:42:40 +0000 Subject: Whois vs GDPR, latest news In-Reply-To: <20180517142322.GA54033@meow.BKantor.net> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck>, <20180517142322.GA54033@meow.BKantor.net> Message-ID: The privacy implications that WHOIS had for domain name registrants was not only acknowledged by Europe. For a long time we were in a battle to get minimum privacy for domain registrants and the privacy proxy services provided some sort of relief. But the intellectual property interest with the backing of governments always dominated the discussions. otherwise IETF had recognized the privacy issues of WHOIS as early as 2002 and protocols were recommended that could respect registrants privacy rights. This was not solely a European issue. It was a global issue and with GDPR coming into effect it only made the process faster and diluted the power of ip people and those who were piggy backing on their power. It's time to move on. GDPR is not a great law but a community that for so many years violated the privacy rights of domain name registrants had to be somehow stopped. It's unfortunate that we didn't deal with this through innovative ways... But saying Europe and GDPR brought this upon us is false. Get Outlook for iOS ________________________________ From: NANOG on behalf of Brian Kantor Sent: Thursday, May 17, 2018 10:23:22 AM To: North American Network Operators' Group Subject: Re: Whois vs GDPR, latest news An article in The Register on the current status of Whois and the GDPR. https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/ From fkittred at gwi.net Thu May 17 18:06:27 2018 From: fkittred at gwi.net (Fletcher Kittredge) Date: Thu, 17 May 2018 14:06:27 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> Message-ID: What about my right to not have this crap on NANOG? On Thu, May 17, 2018 at 2:03 PM, Zbyněk Pospíchal wrote: > Dne 17/05/2018 v 18:14 Sander Steffann napsal(a): > > Hi, > > > > But this regulation increases essential liberty for individuals, so I > don't understand your argument... > > No, it don't. It has two aspects: > > 1. It brings new positive defined rights. But as with any other positive > defined rights, it brings an obligation for anyone other to provide such > rights, it requires enforcement, inspections/whatever which anyone in > Europe must pay from taxes and it requires implementation of a lot of > rules, possible changing of existing internal systems etc. etc. in > companies which will be paid from their revenue, so again from consumer > money. > > 2. It would be the true in an ideal situation. In the real world, there > is no ideal situation. Accept the fact that if you would like to keep > any data private, you must not tell them to anyone. You. You are the one > who can decide about your data and who can really protect your data, no > one else, no government, no GDPR. There is a lot of anonymization > techniques, strong encryption and other things helping to cover who > used/published/steal your private data when it is done by experienced > professionals. It could help a little bit to keep private data protected > againest beginner and intermediate data thieves and perhaps againest > some kinds of stupid mistakes, maybe. Nothing more. Is it enough when we > mention all the costs, including hidden? I don't think so. > > > BTW, nobody told me he is going to propose such regulation before the > last EP elections, no party I have been able to vote has anything like > this nor oposing anything like this in their program. > > -- > Regards, > Zbynek > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net From luca at digitalocean.com Sat May 19 23:47:14 2018 From: luca at digitalocean.com (Luca Salvatore) Date: Sat, 19 May 2018 19:47:14 -0400 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: To answer your specific question - In the regions we use 3356 (NYC and SFO/Bay Area) 3356 have been solid. I’d even say they have less issues than the other usual tier 1 providers... for example 1299 had a hell of a week last week around SFO was 3356 was stable. Can’t comment on what I’d say are small regions like Tampa though. On Sat, May 19, 2018 at 5:56 PM David Hubbard wrote: > Yes, I do, as stated in my initial email. My inquiry is about whether > this level of downtime, and lack of redundancy for a given region, is > normal for 3356. There are some markets where diverse paths are not so > easy to acquire. > ________________________________ > From: Robert DeVita > Sent: Saturday, May 19, 2018 5:36:23 PM > To: David Hubbard; nanog at nanog.org > Subject: Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in > general) > > If this is a know issue and has happened before and point to point > circuits aren’t effected you always have the opportunity to diversify your > own network and get private lines back to Miami, Jax, Atlanta or Dallas to > create your own diversity don’t you? > > Robert DeVita > Managing Director > Mejeticks > c. 469-441-8864 > e. radevita at mejeticks.com > _____________________________ > From: David Hubbard > Sent: Wednesday, May 16, 2018 12:03 PM > Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in > general) > To: > > > I’m curious if anyone who’s used 3356 for transit has found shortcomings > in how their peering and redundancy is configured, or what a normal > expectation to have is. The Tampa Bay market has been completely down for > 3356 IP services twice so far this year, each for what I’d consider an > unacceptable period of time (many hours). I’m learning that the entire > market is served by just two fiber routes, through cities hundreds of miles > away in either direction. So, basically two fiber cuts, potentially 1000+ > miles apart, takes the entire region down. The most recent occurrence was a > week or so ago when a Miami-area cut and an Orange, Texas cut (1287 driving > miles apart) took IP services down for hours. It did not take point to > point circuits to out of market locations down, so that suggests they even > have the ability to be more redundant and simply choose not to. > > I feel like it’s not unreasonable to expect more redundancy, or a much > smaller attack surface given a disgruntled lineman who knows the routes > could take an entire region down with a planned cut four states apart. > Maybe other regions are better designed? Or are my expectations > unreasonable? I carry three peers in that market, so it hasn’t been > outage-causing, but I use 3356 in other markets too, and have plans for > more, but it makes me wonder if I just haven't had the pleasure of similar > outages elsewhere yet and I should factor that expectation into the design. > It creates a problem for me in one location where I can only get them and > Cogent, since Cogent can't be relied on for IPv6 service, which I need. > > Thanks > > > > > From marcusleskex at gmail.com Mon May 21 04:30:34 2018 From: marcusleskex at gmail.com (Marcus Leske) Date: Mon, 21 May 2018 04:30:34 +0000 Subject: Writing a Book about Open Networking and Dis-aggregation Message-ID: Hi, Is anyone interested in working on a book that covers topics like: ``` . Network Operating System types. . Classic vs Open Networking. . Open Networking and SDN. . Forwarding Chips. . The new stack. . Disaggregation. . Automation. . Telemetry. ``` I'm thinking of covering the reasons why dis-aggregation was delayed with networking, what are the advantages and disadvantages of that approach, the new stack on new platforms...etc The goal of the book is to educate and not to promote one vendor over the other, but i'd prefer providing exmaples using Cumulus Linux VX, Open Networking Linux, Sonic. Direct Msg me if interested to talk more. Thanks, Marcus From markr at signal100.com Thu May 17 19:29:01 2018 From: markr at signal100.com (Mark Rousell) Date: Thu, 17 May 2018 20:29:01 +0100 Subject: Whois vs GDPR, latest news In-Reply-To: <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> Message-ID: <5AFDD7FD.20506@signal100.com> On 17/05/2018 19:03, Zbyněk Pospíchal wrote: > Dne 17/05/2018 v 18:14 Sander Steffann napsal(a): >> Hi, >> >> But this regulation increases essential liberty for individuals, so I don't understand your argument... > No, it don't. It has two aspects: > > [...] Very well said. -- Mark Rousell From matt.geary at gmail.com Fri May 18 10:11:27 2018 From: matt.geary at gmail.com (Matt Geary) Date: Fri, 18 May 2018 12:11:27 +0200 Subject: Segment Routing Message-ID: Hello maillist anyone had any experience with segment routing and its performance over LDP? We are evaluating the option to move to SR over LDP so we can label switch across our Nexus L3 switching environment. Thanks Packet Plumber From ngerencser at team-meta.net Fri May 18 17:31:18 2018 From: ngerencser at team-meta.net (Nathaniel Gerencser) Date: Fri, 18 May 2018 17:31:18 +0000 Subject: PlayStation Network Contact Message-ID: Anybody have a contact that can help me with a prefix that is blocked from access to PlayStation Network? Nathan Gerencser, Network Engineer MetaLINK Technologies * 417 Wayne Ave * Defiance, OH 43512 office 419.990.0352 * cell 419.438.6356 ngerencser at team-meta.net | www.metalink.net [http://www.metalink.net/emailsigs/MetaLINK_Technologies_Logo.png] From phil.lavin at cloudcall.com Wed May 16 16:59:44 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 16 May 2018 16:59:44 +0000 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net>, Message-ID: Ask if they will configure BFD for you. I’ve not found many transit providers that will, but it’s worth a shot and it will lower failure detection to circa 1 second. > On 16 May 2018, at 17:49, Adam Kajtar wrote: > > I could use static routes but I noticed since I moved to full routes I have > had a lot fewer customer complaints about latency(especially when it comes > to Voice and VPN traffic). > > I wasn't using per-packet load balancing. I believe juniper default is per > IP. > > My timers are as follows > Active Holdtime: 90 > Keepalive Interval: 30 > > Would I be correct in thinking I need to contact my ISP to lower these > values? > > An interesting note is when I had both ISPs connected into a single MX104 > the failover was just a few seconds. > > Thanks again. > > > >> On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: >> >> Have you checked your timeouts ? >> >> -Ben >> >>> On May 15, 2018, at 4:09 PM, Kaiser, Erich wrote: >>> >>> Do you need full routes? What about just a default route from BGP? >>> >>> Erich Kaiser >>> The Fusion Network >>> erich at gotfusion.net >>> Office: 815-570-3101 >>> >>> >>> >>> >>>> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould wrote: >>>> >>>> You sure it doesn't have something to do with 60 seconds * 3 = 180 secs >> of >>>> BGP neighbor Time out before it believes neighbor is dead and remove >> routes >>>> to that neighbor? >>>> >>>> Aaron >>>> >>>>> On May 15, 2018, at 9:10 AM, Adam Kajtar >>>> wrote: >>>>> >>>>> Hello: >>>>> >>>>> I'm running two Juniper MX104s. Each MX has 1 ISP connected running >>>>> BGP(full routes). iBGP is running between the routers via a two port >> 20G >>>>> lag. When one of the ISPs fails, it can take upwards of 2 minutes for >>>>> traffic to start flowing correctly. The router has the correct route in >>>> the >>>>> routing table, but it doesn't install it in the forwarding table for >> the >>>>> full two mins. >>>>> >>>>> I have a few questions if anyone could answer them. >>>>> >>>>> - What would a usual convergence time be for this setup? >>>>> - Is there anything I could do speed this process up? (I tried >>>> Multipath) >>>>> - Any tips and tricks would be much appreciated >>>>> >>>>> Thanks in Advance >>>>> -- >>>>> Adam Kajtar >>>>> Systems Administrator >>>>> City of Wadsworth >>>>> akajtar at wadsworthcity.org >>>>> ----------------------------------------------------- >>>>> http://www.wadsworthcity.com >>>>> >>>>> Facebook * |* Twitter >>>>> *|* Instagram >>>>> *|* YouTube >>>>> >>>> >>>> >> > > > -- > Adam Kajtar > Systems Administrator, Safety Services > City of Wadsworth > Office 330.335.2865 > Cell 330.485.6510 > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > From president at isoc-ny.org Thu May 17 16:24:56 2018 From: president at isoc-ny.org (Joly MacFie) Date: Thu, 17 May 2018 12:24:56 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> Message-ID: If of use, last Monday I recorded and posted video of Jonathan Zuck's briefing to NARALO on ICANN's interim plan . > ​https://youtu.be/9WVI4aFg0Lc​ -- Joly MacFie President - Internet Society New York Chapter (ISOC-NY) http://isoc-ny.org 218 565 9365 From radevita at mejeticks.com Sat May 19 21:36:23 2018 From: radevita at mejeticks.com (Robert DeVita) Date: Sat, 19 May 2018 21:36:23 +0000 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: If this is a know issue and has happened before and point to point circuits aren’t effected you always have the opportunity to diversify your own network and get private lines back to Miami, Jax, Atlanta or Dallas to create your own diversity don’t you? Robert DeVita Managing Director Mejeticks c. 469-441-8864 e. radevita at mejeticks.com _____________________________ From: David Hubbard Sent: Wednesday, May 16, 2018 12:03 PM Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) To: I’m curious if anyone who’s used 3356 for transit has found shortcomings in how their peering and redundancy is configured, or what a normal expectation to have is. The Tampa Bay market has been completely down for 3356 IP services twice so far this year, each for what I’d consider an unacceptable period of time (many hours). I’m learning that the entire market is served by just two fiber routes, through cities hundreds of miles away in either direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes the entire region down. The most recent occurrence was a week or so ago when a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP services down for hours. It did not take point to point circuits to out of market locations down, so that suggests they even have the ability to be more redundant and simply choose not to. I feel like it’s not unreasonable to expect more redundancy, or a much smaller attack surface given a disgruntled lineman who knows the routes could take an entire region down with a planned cut four states apart. Maybe other regions are better designed? Or are my expectations unreasonable? I carry three peers in that market, so it hasn’t been outage-causing, but I use 3356 in other markets too, and have plans for more, but it makes me wonder if I just haven't had the pleasure of similar outages elsewhere yet and I should factor that expectation into the design. It creates a problem for me in one location where I can only get them and Cogent, since Cogent can't be relied on for IPv6 service, which I need. Thanks From eric.kuhnke at gmail.com Mon May 21 20:50:51 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 21 May 2018 13:50:51 -0700 Subject: AT&T mobile intercepting TCP sockets? In-Reply-To: <20180521193555.GA13683@cmadams.net> References: <20180521193555.GA13683@cmadams.net> Message-ID: The short answer is, yes. This is a strong argument in favor of three things: a) Redirect all http trafifc on webservers you control to https , such as the following apache2 configuration file snippet for a virtualhost RewriteEngine on RewriteCond %{SERVER_NAME} =domainname.com [OR] RewriteCond %{SERVER_NAME} =www.domainname.com RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent] b) Force TLS1.2 on all connections, the population of web browsers that do not understand TLS1.2 is now less than 1% by market share. c) Use HTTPS strict transport security On Mon, May 21, 2018 at 12:35 PM, Chris Adams wrote: > I ran into an odd issue with access to a website I manage from AT&T > mobile devices this weekend. The website worked for everybody not on > AT&T mobile, and AT&T mobile users could access other sites; the problem > was just this combination. > > Android and iOS phones, as well as a Linux system tethered to an Android > phone, all had the same problem. On the Linux system, I disabled IPv6 > in Firefox, and it could then connect. Browsers got various "connection > reset" type errors; on Linux, I could telnet to port 80 or 443, and it > would connect and immediately close. > > The site does have an IPv6 address, but I had missed getting the > webserver to listen on IPv6 (my mistake). Adding that looks to have > solved the problem. > > When I ran tcpdump on the server and had someone try to connect from > their AT&T mobile iPhone, I saw three connection attempts a few tenths > of a second apart (all refused by the server). > > My question is this: is AT&T mobile intercepting the TCP socket (and > not handling "connection refused" correctly)? Is that a known thing? > > -- > Chris Adams > From cb.list6 at gmail.com Mon May 21 20:53:43 2018 From: cb.list6 at gmail.com (Ca By) Date: Mon, 21 May 2018 13:53:43 -0700 Subject: AT&T mobile intercepting TCP sockets? In-Reply-To: <1526933443.118135.1379823168.4C684FB0@webmail.messagingengine.com> References: <20180521193555.GA13683@cmadams.net> <1526933443.118135.1379823168.4C684FB0@webmail.messagingengine.com> Message-ID: On Mon, May 21, 2018 at 1:11 PM wrote: > IME ATT has intercepted virtually everything on mobile (this is on a > hotspot) - > > If I curl a HTTP vs HTTPS site, I get a different IP on each (one is > obviously a shared web proxy); if I download images, they won't match > md5-wise with the original version, etc. I have trouble connecting to VPNs > that aren't standard SSL VPNs. They appear to MITM all web traffic they > can. Using third party DNS servers has questionable results. > AT&Fee is also a key player in undermining http2 security with their “trusted proxy” https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01 > > On Mon, May 21, 2018, at 12:35 PM, Chris Adams wrote: > > I ran into an odd issue with access to a website I manage from AT&T > > mobile devices this weekend. The website worked for everybody not on > > AT&T mobile, and AT&T mobile users could access other sites; the problem > > was just this combination. > > > > Android and iOS phones, as well as a Linux system tethered to an Android > > phone, all had the same problem. On the Linux system, I disabled IPv6 > > in Firefox, and it could then connect. Browsers got various "connection > > reset" type errors; on Linux, I could telnet to port 80 or 443, and it > > would connect and immediately close. > > > > The site does have an IPv6 address, but I had missed getting the > > webserver to listen on IPv6 (my mistake). Adding that looks to have > > solved the problem. > > > > When I ran tcpdump on the server and had someone try to connect from > > their AT&T mobile iPhone, I saw three connection attempts a few tenths > > of a second apart (all refused by the server). > > > > My question is this: is AT&T mobile intercepting the TCP socket (and > > not handling "connection refused" correctly)? Is that a known thing? > > > > -- > > Chris Adams > From valdis.kletnieks at vt.edu Mon May 21 21:55:19 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 21 May 2018 17:55:19 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> Message-ID: <93231.1526939719@turing-police.cc.vt.edu> On Thu, 17 May 2018 14:06:27 -0400, Fletcher Kittredge said: > What about my right to not have this crap on NANOG? procmail is your friend. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From eric.kuhnke at gmail.com Mon May 21 22:08:12 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 21 May 2018 15:08:12 -0700 Subject: AT&T mobile intercepting TCP sockets? In-Reply-To: References: <20180521193555.GA13683@cmadams.net> <1526933443.118135.1379823168.4C684FB0@webmail.messagingengine.com> Message-ID: Oh, I'm sure that'll never be abused by any hostile nation-state-owned monopoly telecom that likes to block/ban/MITM traffic, ever! On Mon, May 21, 2018 at 1:53 PM, Ca By wrote: > On Mon, May 21, 2018 at 1:11 PM wrote: > > > IME ATT has intercepted virtually everything on mobile (this is on a > > hotspot) - > > > > If I curl a HTTP vs HTTPS site, I get a different IP on each (one is > > obviously a shared web proxy); if I download images, they won't match > > md5-wise with the original version, etc. I have trouble connecting to > VPNs > > that aren't standard SSL VPNs. They appear to MITM all web traffic they > > can. Using third party DNS servers has questionable results. > > > > AT&Fee is also a key player in undermining http2 security with their > “trusted proxy” > > https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01 > > > > > > > > On Mon, May 21, 2018, at 12:35 PM, Chris Adams wrote: > > > I ran into an odd issue with access to a website I manage from AT&T > > > mobile devices this weekend. The website worked for everybody not on > > > AT&T mobile, and AT&T mobile users could access other sites; the > problem > > > was just this combination. > > > > > > Android and iOS phones, as well as a Linux system tethered to an > Android > > > phone, all had the same problem. On the Linux system, I disabled IPv6 > > > in Firefox, and it could then connect. Browsers got various > "connection > > > reset" type errors; on Linux, I could telnet to port 80 or 443, and it > > > would connect and immediately close. > > > > > > The site does have an IPv6 address, but I had missed getting the > > > webserver to listen on IPv6 (my mistake). Adding that looks to have > > > solved the problem. > > > > > > When I ran tcpdump on the server and had someone try to connect from > > > their AT&T mobile iPhone, I saw three connection attempts a few tenths > > > of a second apart (all refused by the server). > > > > > > My question is this: is AT&T mobile intercepting the TCP socket (and > > > not handling "connection refused" correctly)? Is that a known thing? > > > > > > -- > > > Chris Adams > > > From diptanshu.singh at gmail.com Tue May 22 00:58:56 2018 From: diptanshu.singh at gmail.com (dip) Date: Mon, 21 May 2018 17:58:56 -0700 Subject: Segment Routing In-Reply-To: References: Message-ID: Matt, Just to clarify, Are you asking for SR and LDP interop or SR over LDP? Two different things. Thanks Dip On Fri, May 18, 2018 at 3:11 AM, Matt Geary wrote: > Hello maillist anyone had any experience with segment routing and its > performance over LDP? We are evaluating the option to move to SR over LDP > so we can label switch across our Nexus L3 switching environment. > > Thanks > Packet Plumber > -- Sent from iPhone From matthew at matthew.at Tue May 22 01:07:15 2018 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 21 May 2018 18:07:15 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> Message-ID: On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge wrote: > What about my right to not have this crap on NANOG? > What about the likely truth that if anyone from Europe mails the list, then every mail server operator with subscribers to the list must follow the GDPR Article 14 notification requirements, as the few exceptions appear to not apply (unless you’re just running an archive). Matthew From aaron1 at gvtc.com Tue May 22 01:37:44 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 21 May 2018 20:37:44 -0500 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> Message-ID: <3D6E4FCC-DF62-4660-9999-491D06468F51@gvtc.com> 9010 and 7609.... Small? Aaron > On May 19, 2018, at 3:51 PM, Ben Cannon wrote: > > Isn’t that the ASR9010? (And before that 7609?) > > -Ben > >>> On May 18, 2018, at 4:20 AM, Tom Hill wrote: >>> >>> On 17/05/18 14:24, Mike Hammett wrote: >>> There's some industry hard-on with having a few ginormous routers instead of many smaller ones. >> >> "Industry hard-on", ITYM "Greedy vendors". >> >> Try finding a 'small' router with a lot of ports (1 & 10GE) for your >> customers, and the right features/TCAM/CP performance, for a price that >> permits you to buy a lot of them. >> >> -- >> Tom From jhellenthal at dataix.net Tue May 22 02:03:27 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 21 May 2018 21:03:27 -0500 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> Message-ID: <0B02D387-0307-482A-AC84-A2BA5E026A93@dataix.net> Mind pointing out where in the GDPR that it directly relates to these types of mail services ? > On May 21, 2018, at 20:07, Matthew Kaufman wrote: > > On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge wrote: > >> What about my right to not have this crap on NANOG? >> > > > What about the likely truth that if anyone from Europe mails the list, then > every mail server operator with subscribers to the list must follow the > GDPR Article 14 notification requirements, as the few exceptions appear to > not apply (unless you’re just running an archive). > > Matthew -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. From sean at donelan.com Tue May 22 04:49:45 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 22 May 2018 00:49:45 -0400 (EDT) Subject: Telecommunications Outage Report: Northern California Firestorm 2017 Message-ID: A report on the telecommunications outages that affected Mendocino, Napa and Sonoma Counties in the wake of the devastating fires of 2017. http://www.mendocinobroadband.org/wp-content/uploads/1.-NBNCBC-Telecommunications-Outage-Report-2017-Firestorm.pdf [...] Results show that in the 3-county area, 66% of residents lost landline services, 74% of residents lost cellular services, and 66% of residents lost Internet services with Napa County experiencing the most severe impacts. The 3-county average of service loss for these combined technologies is 71%. Many of these outages impacted residents that were geographically far from the actual burn areas. [...] During the 2017 wildfires, there were no forms of communications or technologies that worked better than the rest. Each method used for emergency notification played a crucial role in preparing residents for disaster. Technologies used by residents varied from many conventional methods to many non-conventional forms of communications. Regardless of the ways residents were notified, collectively the different methods played a major role in saving lives. [...] In the entire 2017 Northern California wildfires’ footprint, it is estimated that 160,000 wireline and 85,000 wireless customers lost service, including 11-15 Public Safety Answering points losing service. Over 340 cell sites were completely destroyed or damaged. [...] Internet outages affected (22) internet provider services over the 3-county region; however, not all (22) providers are available within each County. [...] When you evacuated your residence, how did you receive warning/notice to evacuate? did not receive any warning from anyone outside my own home (23.48%) other response (17.15%) received a phone alert of some kind (text alert, amber alert) (15.67%) received a phone call from a neighbor, family, friend (13.52%) received warning from a neighbor physically at my door (12.05%) received warning from public safety official physically at my door (6.88%) received a reverse 9-1-1 call (3.5%) heard sirens/bullhorns/public safety officials outside my home (3.44%) received notice on the radio (2.03%) heard a power outage alarm at my home (1.23%) received notice from a press event (0.86%) received notice from a ham radio operator (0.18%) From mehmet at akcin.net Tue May 22 05:11:58 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 21 May 2018 22:11:58 -0700 Subject: Subsea availability Message-ID: Hello there, I am working on a masters project idea to create an interactive map of the world’s subsea cables (cls to cla without local loops from cls to dc) I would like to know if anyone have worked with something like this in the past, and whether you think it would be cool to have a map where you can see subsea cable availability. I am also going to be at nanog denver to talk about this project with people. Let me know if you are available and interested in talking on ways to collaborate. I have few ideas on how to make this work with using ripe atlas probe like devices installed in strategic locations. Mehmet From maxsec at gmail.com Tue May 22 05:35:12 2018 From: maxsec at gmail.com (Martin Hepworth) Date: Tue, 22 May 2018 06:35:12 +0100 Subject: Subsea availability In-Reply-To: References: Message-ID: I'll put this as a starter http://submarine-cable-map-2018.telegeography.com/ There's probably better by now Martin On Tue, 22 May 2018 at 06:13, Mehmet Akcin wrote: > Hello there, > > I am working on a masters project idea to create an interactive map of the > world’s subsea cables (cls to cla without local loops from cls to dc) > > I would like to know if anyone have worked with something like this in the > past, and whether you think it would be cool to have a map where you can > see subsea cable availability. > > I am also going to be at nanog denver to talk about this project with > people. Let me know if you are available and interested in talking on ways > to collaborate. > > I have few ideas on how to make this work with using ripe atlas probe like > devices installed in strategic locations. > > Mehmet > -- -- Martin Hepworth, CISSP Oxford, UK From mehmet at akcin.net Tue May 22 05:37:23 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 21 May 2018 22:37:23 -0700 Subject: Subsea availability In-Reply-To: References: Message-ID: yeah, I know and already reached out to my friends at Telegeography on how to make www.submarinecablemap.com interactive On Mon, May 21, 2018 at 10:35 PM, Martin Hepworth wrote: > I'll put this as a starter > > http://submarine-cable-map-2018.telegeography.com/ > > There's probably better by now > > Martin > > On Tue, 22 May 2018 at 06:13, Mehmet Akcin wrote: > >> Hello there, >> >> I am working on a masters project idea to create an interactive map of the >> world’s subsea cables (cls to cla without local loops from cls to dc) >> >> I would like to know if anyone have worked with something like this in the >> past, and whether you think it would be cool to have a map where you can >> see subsea cable availability. >> >> I am also going to be at nanog denver to talk about this project with >> people. Let me know if you are available and interested in talking on ways >> to collaborate. >> >> I have few ideas on how to make this work with using ripe atlas probe like >> devices installed in strategic locations. >> >> Mehmet >> > -- > -- > Martin Hepworth, CISSP > Oxford, UK > From matthew at matthew.at Tue May 22 05:45:49 2018 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 21 May 2018 22:45:49 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <0B02D387-0307-482A-AC84-A2BA5E026A93@dataix.net> References: <20180516210200.GA50835@meow.BKantor.net> <23292.52261.130019.955632@gargle.gargle.HOWL> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> <0B02D387-0307-482A-AC84-A2BA5E026A93@dataix.net> Message-ID: On Mon, May 21, 2018 at 7:03 PM Jason Hellenthal wrote: > Mind pointing out where in the GDPR that it directly relates to these > types of mail services ? > > > Like most regulations, it doesn’t call out a specific thing like email or social networking sites or ecommerce. But it follows quite directly: GDPR covers processing of personal data of EU subjects. Email addresses are personal data. Article 14 says that if you receive personal data but not directly from the subject, you must notify the subject and provide them with a variety of information. There are exceptions for things like scientific studies and archival purposes... but not because it is simply inconvenient to do so. That this probably just isn’t going to happen for any email servers or search engine crawlers doesn’t mean the law doesn’t say what it says. Matthew From james.voip at gmail.com Tue May 22 05:46:41 2018 From: james.voip at gmail.com (james jones) Date: Tue, 22 May 2018 01:46:41 -0400 Subject: Subsea availability In-Reply-To: References: Message-ID: Not interactive but cool animation: https://www.youtube.com/watch?v=IlAJJI-qG2k On Tue, May 22, 2018 at 1:37 AM, Mehmet Akcin wrote: > yeah, I know and already reached out to my friends at Telegeography on how > to make www.submarinecablemap.com interactive > > On Mon, May 21, 2018 at 10:35 PM, Martin Hepworth > wrote: > > > I'll put this as a starter > > > > http://submarine-cable-map-2018.telegeography.com/ > > > > There's probably better by now > > > > Martin > > > > On Tue, 22 May 2018 at 06:13, Mehmet Akcin wrote: > > > >> Hello there, > >> > >> I am working on a masters project idea to create an interactive map of > the > >> world’s subsea cables (cls to cla without local loops from cls to dc) > >> > >> I would like to know if anyone have worked with something like this in > the > >> past, and whether you think it would be cool to have a map where you can > >> see subsea cable availability. > >> > >> I am also going to be at nanog denver to talk about this project with > >> people. Let me know if you are available and interested in talking on > ways > >> to collaborate. > >> > >> I have few ideas on how to make this work with using ripe atlas probe > like > >> devices installed in strategic locations. > >> > >> Mehmet > >> > > -- > > -- > > Martin Hepworth, CISSP > > Oxford, UK > > > From mehmet at akcin.net Tue May 22 05:57:01 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 21 May 2018 22:57:01 -0700 Subject: Subsea availability In-Reply-To: References: Message-ID: yup that one too, i have noticed. the issue with this one, it does not load for me unless i accept some scripts to load. I will speak to Greg about how to get around it and i am already using his database. On Mon, May 21, 2018 at 10:54 PM, Reid Fishler wrote: > Not to mention: > https://www.cablemap.info/ > > Reid > > > On Tue, May 22, 2018 at 1:46 AM james jones wrote: > >> Not interactive but cool animation: >> >> https://www.youtube.com/watch?v=IlAJJI-qG2k >> >> On Tue, May 22, 2018 at 1:37 AM, Mehmet Akcin wrote: >> >> > yeah, I know and already reached out to my friends at Telegeography on >> how >> > to make www.submarinecablemap.com interactive >> > >> > On Mon, May 21, 2018 at 10:35 PM, Martin Hepworth >> > wrote: >> > >> > > I'll put this as a starter >> > > >> > > http://submarine-cable-map-2018.telegeography.com/ >> > > >> > > There's probably better by now >> > > >> > > Martin >> > > >> > > On Tue, 22 May 2018 at 06:13, Mehmet Akcin wrote: >> > > >> > >> Hello there, >> > >> >> > >> I am working on a masters project idea to create an interactive map >> of >> > the >> > >> world’s subsea cables (cls to cla without local loops from cls to dc) >> > >> >> > >> I would like to know if anyone have worked with something like this >> in >> > the >> > >> past, and whether you think it would be cool to have a map where you >> can >> > >> see subsea cable availability. >> > >> >> > >> I am also going to be at nanog denver to talk about this project with >> > >> people. Let me know if you are available and interested in talking on >> > ways >> > >> to collaborate. >> > >> >> > >> I have few ideas on how to make this work with using ripe atlas probe >> > like >> > >> devices installed in strategic locations. >> > >> >> > >> Mehmet >> > >> >> > > -- >> > > -- >> > > Martin Hepworth, CISSP >> > > Oxford, UK >> > > >> > > > From mark.tinka at seacom.mu Tue May 22 08:03:01 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 10:03:01 +0200 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: <801f0f65-4c9a-7b0d-6a76-c3297ec682f1@seacom.mu> On 16/May/18 18:59, Phil Lavin wrote: > Ask if they will configure BFD for you. I’ve not found many transit providers that will, but it’s worth a shot and it will lower failure detection to circa 1 second. We've tended to shy away from it, but we have 2 customers we've done it for. Mark. From mark.tinka at seacom.mu Tue May 22 08:04:03 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 10:04:03 +0200 Subject: is odd number of links in lag group ok In-Reply-To: <542A8BE4-DE14-4954-AB81-3306236CE556@6by7.net> References: <000301d3ec5f$89a645a0$9cf2d0e0$@gvtc.com> <20180516224824.GA85770@spider.typo.org> <542A8BE4-DE14-4954-AB81-3306236CE556@6by7.net> Message-ID: <974a2d35-a311-a177-4923-16594f342e1a@seacom.mu> On 17/May/18 01:32, Ben Cannon wrote: > While it goes without saying that you need the same (can be 5!) number of links to each router in a multichassis LAG, what isn’t so obvious are things like port groups etc. I'm not sure the OP was talking about MC-LAG. Just a regular LAG. Mark. From mark.tinka at seacom.mu Tue May 22 08:05:06 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 10:05:06 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: On 18/May/18 12:11, Matt Geary wrote: > Hello maillist anyone had any experience with segment routing and its > performance over LDP? We are evaluating the option to move to SR over LDP > so we can label switch across our Nexus L3 switching environment. Is your use-case because you need label switching and the Nexus does not support LDP? Mark. From mark.tinka at seacom.mu Tue May 22 08:07:13 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 10:07:13 +0200 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> Message-ID: On 19/May/18 22:51, Ben Cannon wrote: > Isn’t that the ASR9010? (And before that 7609?) The ASR9901 comes reasonably close - as close as the MX204 could get (although 1Gbps ports might be an issue). Mark. From mark.tinka at seacom.mu Tue May 22 08:14:33 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 10:14:33 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: On 22/May/18 10:06, Matt Geary wrote: > Yes we are considering changing to SR on our backbone because LDP is > not supported on the nexus switches. Although, we have no experience > with SR and looks plainly simple but we loose some of the LSP path > selection. Got you. I'm more curious about use-cases for folk considering SR, than SR itself. 4 years on, and I still can't find a reason to replace my LDP network with SR. Your use-case makes sense, as it sounds like Cisco deliberately left LDP out of your box, considering SR is in. But that's a whole other discussion :-)... Mark. From ben at 6by7.net Tue May 22 08:25:05 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 22 May 2018 01:25:05 -0700 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <3D6E4FCC-DF62-4660-9999-491D06468F51@gvtc.com> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> <3D6E4FCC-DF62-4660-9999-491D06468F51@gvtc.com> Message-ID: <43093F8C-B8AE-4192-89E2-715C05076342@6by7.net> Yep? -------------- next part -------------- -Ben > On May 21, 2018, at 6:37 PM, Aaron Gould wrote: > > 9010 and 7609.... Small? > > Aaron > >> On May 19, 2018, at 3:51 PM, Ben Cannon wrote: >> >> Isn’t that the ASR9010? (And before that 7609?) >> >> -Ben >> >>>> On May 18, 2018, at 4:20 AM, Tom Hill wrote: >>>> >>>> On 17/05/18 14:24, Mike Hammett wrote: >>>> There's some industry hard-on with having a few ginormous routers instead of many smaller ones. >>> >>> "Industry hard-on", ITYM "Greedy vendors". >>> >>> Try finding a 'small' router with a lot of ports (1 & 10GE) for your >>> customers, and the right features/TCAM/CP performance, for a price that >>> permits you to buy a lot of them. >>> >>> -- >>> Tom > From jwbensley at gmail.com Tue May 22 08:51:05 2018 From: jwbensley at gmail.com (James Bensley) Date: Tue, 22 May 2018 09:51:05 +0100 Subject: Segment Routing In-Reply-To: References: Message-ID: On 22 May 2018 at 09:14, Mark Tinka wrote: > I'm more curious about use-cases for folk considering SR, than SR itself. > > 4 years on, and I still can't find a reason to replace my LDP network > with SR. > > Your use-case makes sense, as it sounds like Cisco deliberately left LDP > out of your box, considering SR is in. But that's a whole other > discussion :-)... I'm also interested in the uses cases. As a "typical" service provider (whatever that means) who doesn't have any SR specific requirements such as service chaining, the only reason/feature SR has which currently makes me want to deploy it is TI-FLA (to improve our (r)LFA coverage) - but this is only for failure scenarios so under normal working conditions as far as I know, there is no benefit available to us right now. Cheers, James. From mark.tinka at seacom.mu Tue May 22 09:34:12 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 11:34:12 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: <80eba7a8-2698-d57a-a4d3-8926f828ad8a@seacom.mu> On 22/May/18 10:19, Matt Geary wrote: > Yeah Cisco rep commented that adding LDP to nexus would make ASR > obsolete. 48x10g with LDP for $5-7k Yeah no brainer. Gee, someone at Cisco had their thinking cap on. Let's hope Gert isn't reading this, lest he vent-off about the 6500/7600 debacle (and rightly so) :-). Seriously though, crippling one box to help ship another has never sat well with me. In the first instance, what business does a switch have being a label switching router? Maybe I'm too purist, but when functions begin to overlap like this, it's headache for operators and multiple sources of revenue for equipment vendors, despite what their "portfolio positioning" suggests. They are very aware about the confusion they are causing, at our expense. At least there are some new entrants into the space that haven't yet been totally corrupted by the silo-based approach that leads to the same company appearing like 1,200 different ones. > Although on other point I am not really seeing the value of SR to > replace LDP on my backbone. With some scripting and lots of software > tools I can make it just like LDP, but why? So break the ease of LDP > just to get label switching on my hub core not really seeing it, > unless someone has done it and they are seeing the value. Yep, my point exactly. Mark. From mark.tinka at seacom.mu Tue May 22 09:36:10 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 11:36:10 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> On 22/May/18 10:51, James Bensley wrote: > I'm also interested in the uses cases. > > As a "typical" service provider (whatever that means) who doesn't have > any SR specific requirements such as service chaining, the only > reason/feature SR has which currently makes me want to deploy it is > TI-FLA (to improve our (r)LFA coverage) - but this is only for failure > scenarios so under normal working conditions as far as I know, there > is no benefit available to us right now. +1. I was excited about SR because I thought it would finally enable native MPLSv6 forwarding. But alas... I've heard of "quiet" tests going on within some operator networks, but if you look around, SR is being pushed by the vendors, and none of them can give me a concrete example of a deployment in the wild worth talking about. Of course, always open to correction... Mark. From cb.list6 at gmail.com Tue May 22 12:10:34 2018 From: cb.list6 at gmail.com (Ca By) Date: Tue, 22 May 2018 05:10:34 -0700 Subject: Segment Routing In-Reply-To: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> Message-ID: On Tue, May 22, 2018 at 2:39 AM Mark Tinka wrote: > > > On 22/May/18 10:51, James Bensley wrote: > > > I'm also interested in the uses cases. > > > > As a "typical" service provider (whatever that means) who doesn't have > > any SR specific requirements such as service chaining, the only > > reason/feature SR has which currently makes me want to deploy it is > > TI-FLA (to improve our (r)LFA coverage) - but this is only for failure > > scenarios so under normal working conditions as far as I know, there > > is no benefit available to us right now. > > +1. > > I was excited about SR because I thought it would finally enable native > MPLSv6 forwarding. But alas... > > I've heard of "quiet" tests going on within some operator networks, but > if you look around, SR is being pushed by the vendors, and none of them > can give me a concrete example of a deployment in the wild worth talking > about. > > Of course, always open to correction... Well look at how many authors are on this rfc, that means it is super good right? More authors, more brains https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 Actually it is just an embarasssing marketing technique. Sad! > > Mark. > From mark.tinka at seacom.mu Tue May 22 12:17:16 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 14:17:16 +0200 Subject: Segment Routing In-Reply-To: References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> Message-ID: <1c67eb41-2002-4485-2702-c95af5133e17@seacom.mu> On 22/May/18 14:10, Ca By wrote: > > > > Well look at how many authors are on this rfc, that means it is super > good right? More authors, more brains > > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 > > > Actually it is just an embarasssing marketing technique. Sad! Let's hope it doesn't suffer the same fate as LDPv6 did, whose implementation across all platforms within one specific vendor is very poor, meaning you can't really use it in real life, never mind a multi-vendor network. Mark. From matt.geary at gmail.com Tue May 22 08:06:55 2018 From: matt.geary at gmail.com (Matt Geary) Date: Tue, 22 May 2018 10:06:55 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: Yes we are considering changing to SR on our backbone because LDP is not supported on the nexus switches. Although, we have no experience with SR and looks plainly simple but we loose some of the LSP path selection. On Tue, May 22, 2018, 10:05 Mark Tinka wrote: > > > On 18/May/18 12:11, Matt Geary wrote: > > Hello maillist anyone had any experience with segment routing and its > performance over LDP? We are evaluating the option to move to SR over LDP > so we can label switch across our Nexus L3 switching environment. > > > Is your use-case because you need label switching and the Nexus does not > support LDP? > > Mark. > From matt.geary at gmail.com Tue May 22 08:19:21 2018 From: matt.geary at gmail.com (Matt Geary) Date: Tue, 22 May 2018 10:19:21 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: Yeah Cisco rep commented that adding LDP to nexus would make ASR obsolete. 48x10g with LDP for $5-7k Yeah no brainer. Although on other point I am not really seeing the value of SR to replace LDP on my backbone. With some scripting and lots of software tools I can make it just like LDP, but why? So break the ease of LDP just to get label switching on my hub core not really seeing it, unless someone has done it and they are seeing the value. On Tue, May 22, 2018, 10:14 Mark Tinka wrote: > > > On 22/May/18 10:06, Matt Geary wrote: > > Yes we are considering changing to SR on our backbone because LDP is not > supported on the nexus switches. Although, we have no experience with SR > and looks plainly simple but we loose some of the LSP path selection. > > > Got you. > > I'm more curious about use-cases for folk considering SR, than SR itself. > > 4 years on, and I still can't find a reason to replace my LDP network with > SR. > > Your use-case makes sense, as it sounds like Cisco deliberately left LDP > out of your box, considering SR is in. But that's a whole other discussion > :-)... > > Mark. > From matt.geary at gmail.com Tue May 22 08:31:46 2018 From: matt.geary at gmail.com (Matt Geary) Date: Tue, 22 May 2018 10:31:46 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: SR as a replacement for LDP, but SR-LDP imterop is imteresting too. Do.you have any experience with that? On May 22, 2018 02:59, "dip" wrote: Matt, Just to clarify, Are you asking for SR and LDP interop or SR over LDP? Two different things. Thanks Dip On Fri, May 18, 2018 at 3:11 AM, Matt Geary wrote: > Hello maillist anyone had any experience with segment routing and its > performance over LDP? We are evaluating the option to move to SR over LDP > so we can label switch across our Nexus L3 switching environment. > > Thanks > Packet Plumber > -- Sent from iPhone From redhead at linux.redbird.com Tue May 22 05:54:18 2018 From: redhead at linux.redbird.com (Reid Fishler) Date: Tue, 22 May 2018 01:54:18 -0400 Subject: Subsea availability In-Reply-To: References: Message-ID: Not to mention: https://www.cablemap.info/ Reid On Tue, May 22, 2018 at 1:46 AM james jones wrote: > Not interactive but cool animation: > > https://www.youtube.com/watch?v=IlAJJI-qG2k > > On Tue, May 22, 2018 at 1:37 AM, Mehmet Akcin wrote: > > > yeah, I know and already reached out to my friends at Telegeography on > how > > to make www.submarinecablemap.com interactive > > > > On Mon, May 21, 2018 at 10:35 PM, Martin Hepworth > > wrote: > > > > > I'll put this as a starter > > > > > > http://submarine-cable-map-2018.telegeography.com/ > > > > > > There's probably better by now > > > > > > Martin > > > > > > On Tue, 22 May 2018 at 06:13, Mehmet Akcin wrote: > > > > > >> Hello there, > > >> > > >> I am working on a masters project idea to create an interactive map of > > the > > >> world’s subsea cables (cls to cla without local loops from cls to dc) > > >> > > >> I would like to know if anyone have worked with something like this in > > the > > >> past, and whether you think it would be cool to have a map where you > can > > >> see subsea cable availability. > > >> > > >> I am also going to be at nanog denver to talk about this project with > > >> people. Let me know if you are available and interested in talking on > > ways > > >> to collaborate. > > >> > > >> I have few ideas on how to make this work with using ripe atlas probe > > like > > >> devices installed in strategic locations. > > >> > > >> Mehmet > > >> > > > -- > > > -- > > > Martin Hepworth, CISSP > > > Oxford, UK > > > > > From sebastian at karotte.org Tue May 22 11:36:12 2018 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Tue, 22 May 2018 13:36:12 +0200 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: References: Message-ID: <20180522113612.dlz6ylrgewlz5vyj@danton.fire-world.de> * David Hubbard [2018-05-16 19:01]: > I’m curious if anyone who’s used 3356 for transit has found > shortcomings in how their peering and redundancy is configured, or >From a recent experience I can tell you that a change request to change a peering from "full table" to "default route only" has resulted in now 3+ weeks of conversation and an outage when they misconfigured their session without them realising it. Colleague of mine is now trying to send them the exact required set commands for the Juniper gear they're using. This is not what I would expect from a carrier like 3356. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From saku at ytti.fi Tue May 22 13:38:17 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 16:38:17 +0300 Subject: Segment Routing In-Reply-To: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> Message-ID: On 22 May 2018 at 12:36, Mark Tinka wrote: > I was excited about SR because I thought it would finally enable native > MPLSv6 forwarding. But alas... Why 'alas'? In ISIS you're free to signal Prefix-SID on IPv4 or IPv6, there isn't anything inherently IPv4 in the standard. -- ++ytti From saku at ytti.fi Tue May 22 13:43:01 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 16:43:01 +0300 Subject: Segment Routing In-Reply-To: References: Message-ID: On 22 May 2018 at 11:19, Matt Geary wrote: > really seeing the value of SR to replace LDP on my backbone. With some > scripting and lots of software tools I can make it just like LDP, but why? > So break the ease of LDP just to get label switching on my hub core not > really seeing it, unless someone has done it and they are seeing the value. Can you elaborate what scripting and software tools are needed? If you'd talk about RSVP particularly AutoBW and SR, then yeah, but SR on itself should be less of a chore than LDP. SR is what MPLS was intended to be day1, it just wasn't very marketable idea to sell MPLS and sell need for changing all the IGPs as well. LDP is added state, added signalling, added complexity with reduced visibility. SR is like full-mesh LDP (everyone has everyone's label POV), while also removing one protocol entirely. -- ++ytti From maxtul at netassist.ua Tue May 22 13:44:33 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 22 May 2018 16:44:33 +0300 Subject: Subsea availability In-Reply-To: References: Message-ID: <9bf09a97-7cd5-5b31-18ad-537dc25ee27c@netassist.ua> May be there is something similar, but with the sales contact for each cable system? ;) 22.05.18 08:54, Reid Fishler пише: > Not to mention: > https://www.cablemap.info/ > > Reid > > > On Tue, May 22, 2018 at 1:46 AM james jones wrote: > >> Not interactive but cool animation: >> >> https://www.youtube.com/watch?v=IlAJJI-qG2k >> >> On Tue, May 22, 2018 at 1:37 AM, Mehmet Akcin wrote: >> >>> yeah, I know and already reached out to my friends at Telegeography on >> how >>> to make www.submarinecablemap.com interactive >>> >>> On Mon, May 21, 2018 at 10:35 PM, Martin Hepworth >>> wrote: >>> >>>> I'll put this as a starter >>>> >>>> http://submarine-cable-map-2018.telegeography.com/ >>>> >>>> There's probably better by now >>>> >>>> Martin >>>> >>>> On Tue, 22 May 2018 at 06:13, Mehmet Akcin wrote: >>>> >>>>> Hello there, >>>>> >>>>> I am working on a masters project idea to create an interactive map of >>> the >>>>> world’s subsea cables (cls to cla without local loops from cls to dc) >>>>> >>>>> I would like to know if anyone have worked with something like this in >>> the >>>>> past, and whether you think it would be cool to have a map where you >> can >>>>> see subsea cable availability. >>>>> >>>>> I am also going to be at nanog denver to talk about this project with >>>>> people. Let me know if you are available and interested in talking on >>> ways >>>>> to collaborate. >>>>> >>>>> I have few ideas on how to make this work with using ripe atlas probe >>> like >>>>> devices installed in strategic locations. >>>>> >>>>> Mehmet >>>>> >>>> -- >>>> -- >>>> Martin Hepworth, CISSP >>>> Oxford, UK >>>> >>> > From mark.tinka at seacom.mu Tue May 22 14:01:11 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 16:01:11 +0200 Subject: Segment Routing In-Reply-To: References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> Message-ID: On 22/May/18 15:38, Saku Ytti wrote: > Why 'alas'? In ISIS you're free to signal Prefix-SID on IPv4 or IPv6, > there isn't anything inherently IPv4 in the standard. Can I use that to create MPLS LSP's to carry IPv6 traffic over an IPv6 next-hop, like LDPv6 has been designed to, i.e., not need for IPv4 in any way to forward MPLS frames carrying an IPv6 payload? Don't remember that being the case the last time I checked, but things could have moved on since then. Mark. From saku at ytti.fi Tue May 22 14:14:16 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 17:14:16 +0300 Subject: Segment Routing In-Reply-To: References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> Message-ID: Hey Mark, > Can I use that to create MPLS LSP's to carry IPv6 traffic over an IPv6 > next-hop, like LDPv6 has been designed to, i.e., not need for IPv4 in any > way to forward MPLS frames carrying an IPv6 payload? Yes. In ISIS you'd use Prefix-SID sTLV and attach it to TLV-236 (IPv6) or TLV-237 (Multitopo IPv6). The standard itself has not had any IPv4 bias, IPv6 has had first class support since first draft. -- ++ytti From mark.tinka at seacom.mu Tue May 22 14:17:41 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 16:17:41 +0200 Subject: Segment Routing In-Reply-To: References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> Message-ID: <05188fd2-62c4-454c-e74a-ef688c837075@seacom.mu> On 22/May/18 16:14, Saku Ytti wrote: > Yes. In ISIS you'd use Prefix-SID sTLV and attach it to TLV-236 (IPv6) > or TLV-237 (Multitopo IPv6). > > The standard itself has not had any IPv4 bias, IPv6 has had first > class support since first draft. Have you seen an actual deployment in the field, forwarding IPv6 traffic inside MPLS? My use-case would be to remove BGPv6 in the core, the same way I removed BGPv4 from the core back in 2008. I know LDPv6 can do this, but support across multiple platforms is not where it needs to be yet, making network-wide deployment impractical. Mark. From saku at ytti.fi Tue May 22 14:19:41 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 17:19:41 +0300 Subject: Segment Routing In-Reply-To: References: Message-ID: Hey Steve, > the data plane behavior on LDP is swap oriented, while the data plane on SR > is pop oriented. depending on the hardware capabilities in use this may > have (subtle) traffic engineering or diagnostic implications at a minimum. > folks will likely have to build tooling to address this. I think you're thinking of SR-TE, SR in normal LDP-like use case would be single egress label with swap on LSRs. Ingress PE would figure out label by using egress PE index as an offset to next-hop P's label range. Nexthop P would swap the label determining out label using same mechanism. I practice operators would configure same label range in every box, so swap would be from same label to same label. But that is purely due to operator configuration, and it's still swap. -- ++ytti From saku at ytti.fi Tue May 22 14:21:15 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 17:21:15 +0300 Subject: Segment Routing In-Reply-To: <05188fd2-62c4-454c-e74a-ef688c837075@seacom.mu> References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> <05188fd2-62c4-454c-e74a-ef688c837075@seacom.mu> Message-ID: On 22 May 2018 at 17:17, Mark Tinka wrote: > Have you seen an actual deployment in the field, forwarding IPv6 traffic > inside MPLS? My use-case would be to remove BGPv6 in the core, the same way > I removed BGPv4 from the core back in 2008. I have not, but I'm not good source as I don't track this. I'm just pointing out that LDP was/is IPv4 protocol, where as SR IGP extensions are from day1 IPv4+IPv6 with no particular bias. -- ++ytti From mark.tinka at seacom.mu Tue May 22 14:29:45 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 16:29:45 +0200 Subject: Segment Routing In-Reply-To: References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> <05188fd2-62c4-454c-e74a-ef688c837075@seacom.mu> Message-ID: <9536dfb0-8187-29a5-8a24-92fa3e09a804@seacom.mu> On 22/May/18 16:21, Saku Ytti wrote: > I have not, but I'm not good source as I don't track this. This is what I'm struggling to find, as for me, this would be the ideal use-case for SR. > I'm just > pointing out that LDP > was/is IPv4 protocol, where as SR IGP extensions are from day1 IPv4+IPv6 with no > particular bias. RFC7552 has been shipping since 2015, and this I know works well. If it wasn't for Cisco's spotty support in the various platforms in their portfolio, I'd have taken BGPv6 out of my core ages ago, as Juniper (our other vendor) has had LDPv6 support for quite a while now. Mark. From saku at ytti.fi Tue May 22 14:35:39 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 17:35:39 +0300 Subject: Segment Routing In-Reply-To: <9536dfb0-8187-29a5-8a24-92fa3e09a804@seacom.mu> References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> <05188fd2-62c4-454c-e74a-ef688c837075@seacom.mu> <9536dfb0-8187-29a5-8a24-92fa3e09a804@seacom.mu> Message-ID: On 22 May 2018 at 17:29, Mark Tinka wrote: > This is what I'm struggling to find, as for me, this would be the ideal > use-case for SR. My first google hit shows IPv6 support: https://www.juniper.net/documentation/en_US/junos/topics/example/example-configuring-spring-srgb.html I think there may be some confusing with MPLS and IPv6 dataplane carrying IPv4/IPv6. MPLS dataplane seems to support in JunOS both IPv4 and IPV6 labeled prefixes. IPv6 dataplane I could not be less interested in, I think it's trash. -- ++ytti From mark.tinka at seacom.mu Tue May 22 14:43:40 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 May 2018 16:43:40 +0200 Subject: Segment Routing In-Reply-To: References: <657a75e2-72b9-b1b9-25da-769a123a319a@seacom.mu> <05188fd2-62c4-454c-e74a-ef688c837075@seacom.mu> <9536dfb0-8187-29a5-8a24-92fa3e09a804@seacom.mu> Message-ID: <4852b6c5-cb61-f0f4-a729-eb748bf3a148@seacom.mu> On 22/May/18 16:35, Saku Ytti wrote: > My first google hit shows IPv6 support: > > https://www.juniper.net/documentation/en_US/junos/topics/example/example-configuring-spring-srgb.html I meant as a field deployment in an operator network, and not what documentation says code can do. > I think there may be some confusing with MPLS and IPv6 dataplane > carrying IPv4/IPv6. MPLS dataplane seems to support in JunOS both IPv4 > and IPV6 labeled prefixes. IPv6 dataplane I could not be less > interested in, I think it's trash. Well, I want to forward IPv6 traffic in an MPLS data plane, the same way I am currently forwarding IPv4 and Ethernet traffic in an MPLS data plane. And I want to do this as ships-in-the-night to avoid shared risk by combining 2 protocols into one (the way 6PE depends on IPv4, for example). If IPv6 traffic is being forwarded in the core purely on labels (generated purely either by LDPv6 or SRv6, and not by 6PE-and-friends-type sorcery), then I can disable BGPv6 in the core. Mark. From saku at ytti.fi Tue May 22 14:59:34 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 17:59:34 +0300 Subject: Segment Routing In-Reply-To: References: Message-ID: On 22 May 2018 at 17:43, steve ulrich wrote: Hey, > sorry, yes. i was referring to SRTE wrt the pop operation. Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is unambiguous win. > not labels but they are encoded as labels. i hope operators have the option > to configure common/consistent label ranges, but i don't necessarily assume > it. tooling to resolve this will be required just as in the LDP world. I've not had this tooling in LDP world, and not anticipating to need it in SR world. But maybe I'm missing something, what kind of information do you need in LDP world which you need to develop tooling for, and how does the problem+solution translate to SR world? -- ++ytti From matt.geary at gmail.com Tue May 22 15:14:13 2018 From: matt.geary at gmail.com (Matt Geary) Date: Tue, 22 May 2018 17:14:13 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: I guess my point is why go through the extra config to program labels for each box when LDP does it for you? Why loose potential visibility to network traffic? Cisco sales and marketing is digging huge into the SR game for enterprise and SDWAN like backbone networking. They are touting about the whole industry changing, but I'm not seeing it anywhere in the large network or provider space. Hench my original question why SR over LDP? Seems SR is a lot of extra config to give you all the program options for white box like networking, when basic LDP in a Cisco variant works just fine. On Tue, May 22, 2018, 16:19 Saku Ytti wrote: > Hey Steve, > > > the data plane behavior on LDP is swap oriented, while the data plane on > SR > > is pop oriented. depending on the hardware capabilities in use this may > > have (subtle) traffic engineering or diagnostic implications at a > minimum. > > folks will likely have to build tooling to address this. > > I think you're thinking of SR-TE, SR in normal LDP-like use case would be > single > egress label with swap on LSRs. > > Ingress PE would figure out label by using egress PE index as an > offset to next-hop > P's label range. > Nexthop P would swap the label determining out label using same mechanism. > > I practice operators would configure same label range in every box, so > swap would be > from same label to same label. But that is purely due to operator > configuration, and > it's still swap. > > -- > ++ytti > From saku at ytti.fi Tue May 22 15:48:48 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 18:48:48 +0300 Subject: Segment Routing In-Reply-To: References: Message-ID: Hey Matt, > I guess my point is why go through the extra config to program labels for > each box when LDP does it for you? Why loose potential visibility to network > traffic? Cisco sales and marketing is digging huge into the SR game for > enterprise and SDWAN like backbone networking. They are touting about the > whole industry changing, but I'm not seeing it anywhere in the large network > or provider space. Hench my original question why SR over LDP? Seems SR is a > lot of extra config to give you all the program options for white box like > networking, when basic LDP in a Cisco variant works just fine. There isn't inherently anything you need to configure in SR, it's all implementation detail. Juniper requires you configure your 'index', but just as well 'index' could be inferred from your loopback0 or router-id. And indeed in your configuration generation where you generate your router-id, you can use static method to turn router-id into unique index and configure it once. Or you could ask vendor to implement feature to auto-assign index. Much like some devices can auto-assign unique RD to VRF, some require operator to assign them. Entirely implementation detail, not a valid argument between protocols. The upside of SR to LDP - removal of entire protocol - full-mesh visibility - guaranteed IGP+Label sync The amount of configuration needed to do SR like LDP should be less than LDP. Confusion may arise by looking at SR examples, as SR can also be used like RSVP, which indeed is far more complex use-case. -- ++ytti From matt.geary at gmail.com Tue May 22 16:16:06 2018 From: matt.geary at gmail.com (Matt Geary) Date: Tue, 22 May 2018 18:16:06 +0200 Subject: Segment Routing In-Reply-To: References: Message-ID: Hi Saku gotcha and I see most config examples are RSVP/SR-TE like, where in most of the networks I have come across basic LDP is more than acceptable. On Tue, May 22, 2018, 17:48 Saku Ytti wrote: > Hey Matt, > > > I guess my point is why go through the extra config to program labels for > > each box when LDP does it for you? Why loose potential visibility to > network > > traffic? Cisco sales and marketing is digging huge into the SR game for > > enterprise and SDWAN like backbone networking. They are touting about the > > whole industry changing, but I'm not seeing it anywhere in the large > network > > or provider space. Hench my original question why SR over LDP? Seems SR > is a > > lot of extra config to give you all the program options for white box > like > > networking, when basic LDP in a Cisco variant works just fine. > > There isn't inherently anything you need to configure in SR, it's all > implementation detail. > Juniper requires you configure your 'index', but just as well 'index' > could be inferred from your loopback0 or router-id. > > And indeed in your configuration generation where you generate your > router-id, you can use static method to turn router-id into unique > index and configure it once. > Or you could ask vendor to implement feature to auto-assign index. > > Much like some devices can auto-assign unique RD to VRF, some require > operator to assign them. Entirely implementation detail, not a valid > argument between protocols. > > > The upside of SR to LDP > - removal of entire protocol > - full-mesh visibility > - guaranteed IGP+Label sync > > The amount of configuration needed to do SR like LDP should be less > than LDP. Confusion may arise by looking at SR examples, as SR can > also be used like RSVP, which indeed is far more complex use-case. > > -- > ++ytti > From rol at witbe.net Tue May 22 16:28:48 2018 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Tue, 22 May 2018 18:28:48 +0200 Subject: Subsea availability In-Reply-To: References: Message-ID: <20180522182848.6292a82f@riri.DEF.witbe.net> Hello, On Tue, 22 May 2018 06:35:12 +0100 Martin Hepworth wrote: > I'll put this as a starter > > http://submarine-cable-map-2018.telegeography.com/ This one is rather cool too: http://he.net/3d-map/ Paul -- Paul Rolland E-Mail : rol(at)witbe.net CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La Defense RIPE : PR12-RIPE LinkedIn : http://www.linkedin.com/in/paulrolland Skype : rollandpaul "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From jheitz at cisco.com Tue May 22 17:52:00 2018 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Tue, 22 May 2018 17:52:00 +0000 Subject: Segment Routing Message-ID: <7db9162643f5496eae2ecabcc6624c1d@XCH-ALN-014.cisco.com> Nexus supports LDP. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mpls_cg/mp_ldp_overview.html Regards, Jakob From michael at wi-fiber.io Tue May 22 18:08:21 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 22 May 2018 12:08:21 -0600 Subject: DirecTV Now contact Message-ID: Our eyeball network is consistently having some streaming issues(buffering) with DirecTV now. Our main recourse is to sell them on youtube TV and netflix. fixes the issue, no more complaints from our customers. Issues mainly occur during peak times and even on 300+mbps low latency/jitter customers. However, if someone from DirecTV could contact me off list and we can debug this issue so that we don't have to keep pulling people to other services that would be great. Alternatively, if anyone could suggest with whom to peer to reduce the impact of this issue, that would be great. A solution that would be even better is if someone from Youtube TV would contact us off list and we can set up something commissioned based for all the good things we say about your service, and of course give our tech support people a reason to not be frustrated with the calls we receive for this issue. From sulrich at botwerks.org Tue May 22 14:04:44 2018 From: sulrich at botwerks.org (steve ulrich) Date: Tue, 22 May 2018 09:04:44 -0500 Subject: Segment Routing In-Reply-To: References: Message-ID: fwiw - there's a potentially significant loss of visibility w/SR from a traffic management perspective depending on how it's deployed. though, i doubt the OP is really driving at this point. the data plane behavior on LDP is swap oriented, while the data plane on SR is pop oriented. depending on the hardware capabilities in use this may have (subtle) traffic engineering or diagnostic implications at a minimum. folks will likely have to build tooling to address this. we're pushing the bubble of complexity around. On Tue, May 22, 2018 at 8:47 AM Saku Ytti wrote: > On 22 May 2018 at 11:19, Matt Geary wrote: > > > really seeing the value of SR to replace LDP on my backbone. With some > > scripting and lots of software tools I can make it just like LDP, but > why? > > So break the ease of LDP just to get label switching on my hub core not > > really seeing it, unless someone has done it and they are seeing the > value. > > Can you elaborate what scripting and software tools are needed? If you'd > talk > about RSVP particularly AutoBW and SR, then yeah, but SR on itself should > be less of a chore than LDP. > > SR is what MPLS was intended to be day1, it just wasn't very marketable > idea > to sell MPLS and sell need for changing all the IGPs as well. > LDP is added state, added signalling, added complexity with reduced > visibility. > SR is like full-mesh LDP (everyone has everyone's label POV), while also > removing one protocol entirely. > > -- > ++ytti > -- steve ulrich (sulrich at botwerks.*) From sulrich at botwerks.org Tue May 22 14:43:33 2018 From: sulrich at botwerks.org (steve ulrich) Date: Tue, 22 May 2018 09:43:33 -0500 Subject: Segment Routing In-Reply-To: References: Message-ID: sorry, yes. i was referring to SRTE wrt the pop operation. in most of the implementations i've poked at, there is the ability to specify a consistent label range, but it's not always the case. SIDs are not labels but they are encoded as labels. i hope operators have the option to configure common/consistent label ranges, but i don't necessarily assume it. tooling to resolve this will be required just as in the LDP world. On Tue, May 22, 2018 at 9:19 AM Saku Ytti wrote: > Hey Steve, > > > the data plane behavior on LDP is swap oriented, while the data plane on > SR > > is pop oriented. depending on the hardware capabilities in use this may > > have (subtle) traffic engineering or diagnostic implications at a > minimum. > > folks will likely have to build tooling to address this. > > I think you're thinking of SR-TE, SR in normal LDP-like use case would be > single > egress label with swap on LSRs. > > Ingress PE would figure out label by using egress PE index as an > offset to next-hop > P's label range. > Nexthop P would swap the label determining out label using same mechanism. > > I practice operators would configure same label range in every box, so > swap would be > from same label to same label. But that is purely due to operator > configuration, and > it's still swap. > > -- > ++ytti > -- steve ulrich (sulrich at botwerks.*) From mike.lyon at gmail.com Tue May 22 18:29:02 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Tue, 22 May 2018 11:29:02 -0700 Subject: DirecTV Now contact In-Reply-To: References: Message-ID: <2E74AB65-B445-4E3B-A0F6-AF84B41B42AA@gmail.com> Yeah, our eyeball network has problems with DirecTV too. Would be nice if they were at the various peering exchanges... -Mike > On May 22, 2018, at 11:08, Michael Crapse wrote: > > Our eyeball network is consistently having some streaming issues(buffering) > with DirecTV now. Our main recourse is to sell them on youtube TV and > netflix. fixes the issue, no more complaints from our customers. Issues > mainly occur during peak times and even on 300+mbps low latency/jitter > customers. > However, if someone from DirecTV could contact me off list and we can debug > this issue so that we don't have to keep pulling people to other services > that would be great. > Alternatively, if anyone could suggest with whom to peer to reduce the > impact of this issue, that would be great. > A solution that would be even better is if someone from Youtube TV would > contact us off list and we can set up something commissioned based for all > the good things we say about your service, and of course give our tech > support people a reason to not be frustrated with the calls we receive for > this issue. From jstump at fourway.net Tue May 22 18:59:27 2018 From: jstump at fourway.net (Joshua Stump) Date: Tue, 22 May 2018 14:59:27 -0400 Subject: DirecTV Now contact In-Reply-To: <2E74AB65-B445-4E3B-A0F6-AF84B41B42AA@gmail.com> References: <2E74AB65-B445-4E3B-A0F6-AF84B41B42AA@gmail.com> Message-ID: <019b01d3f1ff$0231d0d0$06957270$@fourway.net> Similar experience for us as well. Joshua Stump Network Admin Fourway.NET 800-733-0062 -----Original Message----- From: NANOG On Behalf Of mike.lyon at gmail.com Sent: Tuesday, May 22, 2018 2:29 PM To: Michael Crapse Cc: NANOG list Subject: Re: DirecTV Now contact Yeah, our eyeball network has problems with DirecTV too. Would be nice if they were at the various peering exchanges... -Mike > On May 22, 2018, at 11:08, Michael Crapse wrote: > > Our eyeball network is consistently having some streaming > issues(buffering) with DirecTV now. Our main recourse is to sell them > on youtube TV and netflix. fixes the issue, no more complaints from > our customers. Issues mainly occur during peak times and even on > 300+mbps low latency/jitter customers. > However, if someone from DirecTV could contact me off list and we can > debug this issue so that we don't have to keep pulling people to other > services that would be great. > Alternatively, if anyone could suggest with whom to peer to reduce the > impact of this issue, that would be great. > A solution that would be even better is if someone from Youtube TV > would contact us off list and we can set up something commissioned > based for all the good things we say about your service, and of course > give our tech support people a reason to not be frustrated with the > calls we receive for this issue. From horsezip at earthlink.net Tue May 22 19:00:50 2018 From: horsezip at earthlink.net (jimmy keffer) Date: Tue, 22 May 2018 15:00:50 -0400 Subject: earthlink email problems Message-ID: <8fp8gd5ec45sfrkoa4nhhaj3es1a167g7o@4ax.com> my has problems sending mail to earthlink.net the sever has a ptr abd reverse dns set but i get this To: jimmy at horsezipsworld.com Subject: Message undeliverable: MegaBBS Forum horsezip's world : New user alert From: mailer-daemon at horsezipsworld.com Date: Sun, 20 May 2018 23:40:41 -0400 Your message did not reach some or all of the intended recipients. Sent: Sun, 20 May 2018 23:40:40 -0400 Subject: MegaBBS Forum horsezip's world : New user alert The following recipient(s) could not be reached: horsezip at earthlink.net Error Type: SMTP Remote server (209.86.93.228) issued an error. hMailServer sent: MAIL FROM: Remote server replied: 550 ERROR: No or mismatched reverse DNS (PTR) entries for 23.227.197.10 hMailServer any one here who can help my server sends mail to servers fine gmail etc jimmy From nanog at ics-il.net Tue May 22 19:02:05 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 22 May 2018 14:02:05 -0500 (CDT) Subject: DirecTV Now contact In-Reply-To: <019b01d3f1ff$0231d0d0$06957270$@fourway.net> References: <2E74AB65-B445-4E3B-A0F6-AF84B41B42AA@gmail.com> <019b01d3f1ff$0231d0d0$06957270$@fourway.net> Message-ID: <129890931.13791.1527015724375.JavaMail.mhammett@ThunderFuck> I don't have DirecTV Now. What CDN are they using? Fire up a stream and use Torch to see what IP it's coming from. Torch is a tool in Mikrotik RouterOS. I recognize those three as likely being familiar with RouterOS, so I sent them that way. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Joshua Stump" To: "mike lyon" , "Michael Crapse" Cc: "NANOG list" Sent: Tuesday, May 22, 2018 1:59:27 PM Subject: RE: DirecTV Now contact Similar experience for us as well. Joshua Stump Network Admin Fourway.NET 800-733-0062 -----Original Message----- From: NANOG On Behalf Of mike.lyon at gmail.com Sent: Tuesday, May 22, 2018 2:29 PM To: Michael Crapse Cc: NANOG list Subject: Re: DirecTV Now contact Yeah, our eyeball network has problems with DirecTV too. Would be nice if they were at the various peering exchanges... -Mike > On May 22, 2018, at 11:08, Michael Crapse wrote: > > Our eyeball network is consistently having some streaming > issues(buffering) with DirecTV now. Our main recourse is to sell them > on youtube TV and netflix. fixes the issue, no more complaints from > our customers. Issues mainly occur during peak times and even on > 300+mbps low latency/jitter customers. > However, if someone from DirecTV could contact me off list and we can > debug this issue so that we don't have to keep pulling people to other > services that would be great. > Alternatively, if anyone could suggest with whom to peer to reduce the > impact of this issue, that would be great. > A solution that would be even better is if someone from Youtube TV > would contact us off list and we can set up something commissioned > based for all the good things we say about your service, and of course > give our tech support people a reason to not be frustrated with the > calls we receive for this issue. From matt at netfire.net Tue May 22 19:14:55 2018 From: matt at netfire.net (Matt Harris) Date: Tue, 22 May 2018 14:14:55 -0500 Subject: earthlink email problems In-Reply-To: <8fp8gd5ec45sfrkoa4nhhaj3es1a167g7o@4ax.com> References: <8fp8gd5ec45sfrkoa4nhhaj3es1a167g7o@4ax.com> Message-ID: On Tue, May 22, 2018 at 2:00 PM, jimmy keffer wrote: > my has problems sending mail to earthlink.net the sever has a ptr abd > reverse dns set but i get this To: jimmy at horsezipsworld.com > > Remote server replied: 550 ERROR: No or mismatched reverse DNS (PTR) > entries for 23.227.197.10 > > any one here who can help my server sends mail to servers fine gmail etc > jimmy > Your A record does not match that IPv4 addr: (mdh at kirin) [~/]# host 23.227.197.10 10.197.227.23.in-addr.arpa domain name pointer horsezipsworld.com. (mdh at kirin) [~/]# host horsezipsworld.com horsezipsworld.com has address 23.227.197.11 You may want to set something up like mail. which points to 23.227.197.10 and then set the PTR for 23.227.197.10 to mail. so that you have a matching set. PTR's that don't match are unreliable - I can set a PTR for my IP addresses to matt.google.com, but that doesn't mean I have any authority regarding google.com. Take care, Matt From swhyte at gmail.com Tue May 22 19:54:47 2018 From: swhyte at gmail.com (Scott Whyte) Date: Tue, 22 May 2018 12:54:47 -0700 Subject: Segment Routing In-Reply-To: References: Message-ID: <9e1a07ea-a5e5-36c4-edbc-1625866981a0@gmail.com> On 5/22/18 7:04 AM, steve ulrich wrote: > fwiw - there's a potentially significant loss of visibility w/SR from a > traffic management perspective depending on how it's deployed. though, i > doubt the OP is really driving at this point. > > the data plane behavior on LDP is swap oriented, while the data plane on SR > is pop oriented. depending on the hardware capabilities in use this may > have (subtle) traffic engineering or diagnostic implications at a minimum. > folks will likely have to build tooling to address this. > > we're pushing the bubble of complexity around. Moving the complexity to where it scales better is a win all by itself. > > On Tue, May 22, 2018 at 8:47 AM Saku Ytti wrote: > >> On 22 May 2018 at 11:19, Matt Geary wrote: >> >>> really seeing the value of SR to replace LDP on my backbone. With some >>> scripting and lots of software tools I can make it just like LDP, but >> why? >>> So break the ease of LDP just to get label switching on my hub core not >>> really seeing it, unless someone has done it and they are seeing the >> value. >> >> Can you elaborate what scripting and software tools are needed? If you'd >> talk >> about RSVP particularly AutoBW and SR, then yeah, but SR on itself should >> be less of a chore than LDP. >> >> SR is what MPLS was intended to be day1, it just wasn't very marketable >> idea >> to sell MPLS and sell need for changing all the IGPs as well. >> LDP is added state, added signalling, added complexity with reduced >> visibility. >> SR is like full-mesh LDP (everyone has everyone's label POV), while also >> removing one protocol entirely. >> >> -- >> ++ytti >> > From kmedcalf at dessus.com Tue May 22 20:19:35 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 22 May 2018 14:19:35 -0600 Subject: earthlink email problems In-Reply-To: <8fp8gd5ec45sfrkoa4nhhaj3es1a167g7o@4ax.com> Message-ID: >host 23.227.197.10 10.197.227.23.in-addr.arpa domain name pointer horsezipsworld.com. >host horsezipsworld.com horsezipsworld.com has address 23.227.197.11 horsezipsworld.com mail is handled by 10 mail.horsezipsworld.com. >host mail.horsezipsworld.com mail.horsezipsworld.com has address 23.227.197.11 >host 23.227.197.11 11.197.227.23.in-addr.arpa domain name pointer horsezipsworld.com. The above are inconsistent. IPAddress -> Name =/= the found name -> IPAddress >host 209.86.93.228 228.93.86.209.in-addr.arpa domain name pointer mx3.earthlink.net. >host mx3.earthlink.net mx3.earthlink.net has address 209.86.93.228 Thee appear to be consistent ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of jimmy >keffer >Sent: Tuesday, 22 May, 2018 13:01 >To: nanog at nanog.org >Subject: earthlink email problems > >my has problems sending mail to earthlink.net the sever has a ptr abd >reverse dns set but i get this To: jimmy at horsezipsworld.com >Subject: Message undeliverable: MegaBBS Forum horsezip's world : New >user alert >From: mailer-daemon at horsezipsworld.com >Date: Sun, 20 May 2018 23:40:41 -0400 > >Your message did not reach some or all of the intended recipients. > > Sent: Sun, 20 May 2018 23:40:40 -0400 > Subject: MegaBBS Forum horsezip's world : New user alert > >The following recipient(s) could not be reached: > >horsezip at earthlink.net > Error Type: SMTP > Remote server (209.86.93.228) issued an error. > hMailServer sent: MAIL FROM: > Remote server replied: 550 ERROR: No or mismatched reverse DNS >(PTR) >entries for 23.227.197.10 > > > >hMailServer > >any one here who can help my server sends mail to servers fine gmail >etc >jimmy From surfer at mauigateway.com Tue May 22 20:27:01 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 22 May 2018 13:27:01 -0700 Subject: Telecommunications Outage Report: Northern California Firestorm 2017 Message-ID: <20180522132701.75346438@m0117459.ppops.net> --- sean at donelan.com wrote: From: Sean Donelan :: During the 2017 wildfires, there were no forms of :: communications or technologies that worked better :: than the rest. I don't have time to read all 80+ pages and don't see it in the contents. Do you know what services restored first? scott From saku at ytti.fi Tue May 22 20:48:23 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 22 May 2018 23:48:23 +0300 Subject: Segment Routing In-Reply-To: References: Message-ID: > in the day's of yore, i know a few folks who built tooling to validate > and/or detect failure to sync between the IGP and LDP or detect data plane > black holing behaviors caused by resolution in the RIB w/no complementary > label allocation (or LDP convergence lagging significantly). implementations > have come a long way since then. but yeah, IGP-LDP sync lag has been a > thing for some folks. No matter what the protocol, there will be occasional bugs, and we will continue to develop ad-hoc scripts to detect and workaround those when possible until such time that software upgrade is practical. None of these are practical to write ahead of time, as we won't know what the bug is we're trying to detect. This is not protocol discussion in itself, but we can make an argument that if there is bug probability per SLOC, less SLOC is less bugs, and label signalling in IGP is far simpler than LDP. -- ++ytti From nanog-announce at nanog.org Tue May 22 22:43:43 2018 From: nanog-announce at nanog.org (Ryan Woolley via NANOG-announce) Date: Tue, 22 May 2018 22:43:43 +0000 (UTC) Subject: [NANOG-announce] NANOG 73 Agenda is Published Message-ID: This message has been wrapped due to the DMARC policy setting to prevent NANOG subscribers from being unsubscribed due to bounces. -------------- next part -------------- An embedded message was scrubbed... From: Ryan Woolley Subject: NANOG 73 Agenda is Published Date: Tue, 22 May 2018 18:43:39 -0400 Size: 6260 URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From rwoolleynanog at gmail.com Tue May 22 22:50:54 2018 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Tue, 22 May 2018 18:50:54 -0400 Subject: NANOG 73 Agenda is Published Message-ID: NANOG Community, The NANOG 73 Agenda is published at http://www.cvent.com/d/ttqv1z/16K and available as an iCal feed at https://pc.nanog.org/static/published/meetings/NANOG73/agenda.ics The Program Committee has worked closely with our speakers to develop a first-rate program, and we encourage all attendees to enjoy the whole conference. As we review submitted content, minor changes to the agenda are possible and will be reflected in the online feed. Thank you to the many members of our community who submitted interesting content for NANOG 73! Close to 500 attendees have registered and the NANOG family looks forward to welcoming all of you to Denver. Useful Information: - NANOG 73 General Information and Registration: http://www.cvent.com/d/ttqv1z - Hotel Room Block(s) Information: http://www.cvent.com/d/ttqv1z/8K - There are a few remaining spots to register for the NANOG 73 Hackathon: http://www.cvent.com/d/ttqv1z/4K - A welcome message that will be sent to registered NANOG 73 attendees shortly will provide more information on scheduled events and applications to help you to make the most of your time in Denver - Register to attend NANOG On The Road Washington, DC, taking place in September at http://www.cvent.com/d/ygqk8s/4W Safe travels and see you in Denver. Sincerely, Ryan Woolley, on behalf of the NANOG Program Committee From johnl at iecc.com Wed May 23 01:50:17 2018 From: johnl at iecc.com (John Levine) Date: 22 May 2018 21:50:17 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: Message-ID: <20180523015019.26B6326FB73E@ary.qy> >What about the likely truth that if anyone from Europe mails the list, then >every mail server operator with subscribers to the list must follow the >GDPR Article 14 notification requirements, as the few exceptions appear to >not apply (unless you’re just running an archive). Some of us whose businesses and equipment are entirely in North America will take our chances. This is NANOG, not EUNOG, you know. Also, one thing that has become painfully clear is that the number of people who imagine that they understand the GDPR exceeds the number who actually understand it by several orders of magnitude. The "you have to delete all my messages from the archive if I unsubscribe" nonsense is a good indicator. R's, John From mysidia at gmail.com Wed May 23 02:07:24 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 22 May 2018 21:07:24 -0500 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> Message-ID: Perhaps it's time that some would consider new RBLs and Blackhole feeds based on.... : Domains with deliberately unavailable WHOIS data. Including domains whose registrant has failed to cause their domain registrar and/or registry to list personally identifiable details for registrant and contacts on servers available to the public using the TCP port 43 WHOIS service. For any reason, whether use of a privacy service, or by a Default "Opt-to-Privacy Rule" enforced by a local / country-specific regulation such as GPDR. Stance * Ultimate burden goes to the REGISTRANT of any Internet Domain to take the steps to ensure their domain or IP address registry makes public contacts appear in WHOIS at all times for their Domain and/or IP address(es) --- including a traceable registrant name AND direct Telephone and E-mail contacts to a responsible party specific to the domain from which a timely response is available and are not through a re-mailer or proxy service. People may have in their country a legal right to secure control of a domain on a registry And anonymize their registration: "Choose not to have personal information listed in WHOIS". HOWEVER, Making this choice might then result in adverse consequences towards connectivity AND accessibility to your resources from others during such times as you exercise your option to have no identifiable WHOIS data. The registration of a domain with hidden or anonymous data only ensures exclusivity of control. Registration of a domain with questionable or unverifiable personal registrant or contact information does not guarantee that ISPs or other sites connected to the internet will choose to allow their own users and DNS infrastructure access to un-WHOISable domains. Then have: ------------------- * Right-hand sided BLs for Internet domains with no direct WHOIS-listed registrant address and real-person contacts including name, address, direct e-mail and phone number valid for contact during the domain's operational hours. * Addons/Extensions for Common Web Browsers to check the BLs before allowing access to a HTTP or HTTPS URL. Then display a prominent "Anonymized Domain: Probable Scam/Phishing Site" within the Web Browser MUA; And limit or disable high-risk functions for anonymous sites: such as Web Form Submissions, Scripting, Cookies, Etc to Non-WHOIS'd domains. if the domain's WHOIS listing is missing or showed a privacy service, or had appeared t runcated or anonymized. * IP Address DNSBL for IP Address allocations with no direct WHOIS-listed holder address real-person contacts. including name, address, direct e-mail and phone number valid for contact during the hours when that IP address is connected to the internet. * DNS response policy zones (for resolver blacklists) for internet domains with no WHOIS-listed registrant & real-person contacts including name, address, direct e-mail and phone number valid for contact. The EU GDPR _might_ require your registrar to offer you the ability Opt by default to mask your personal information and e-mail from domain or IP WHOIS data, But should you choose to Not opt to have identifiable contacts and ownership published: There may be networks and resources that will refuse access, Or whose users will not be allowed to resolve your DNS names, due to your refusal to identify yourself/provide contacts for vetting, identifying and reporting technical issues, abuse, etc. Real-Life equivalent would be.... Directories/Listings of Recommended businesses that refuse to accept listings from businesses whose Owner wants to stay Anonymous. Or people who don't want to buy their groceries from random shady buildings that don't even have a proper sign out..... -- -JH On Wed, May 16, 2018 at 4:10 PM, Constantine A. Murenin wrote: > I think this is the worst of both worlds. The data is basically still > public, but you cannot access it unless someone marks you as a > "friend". > > This policy is basically what Facebook is. And how well it played out > once folks realised that their shared data wasn't actually private? > > C. > > On 16 May 2018 at 16:02, Brian Kantor wrote: >> A draft of the new ICANN Whois policy was published a few days ago. >> >> https://www.icann.org/en/system/files/files/proposed-gtld-registration-data-temp-specs-14may18-en.pdf >> >> From that document: >> >> "This Temporary Specification for gTLD Registration Data (Temporary >> Specification) establishes temporary requirements to allow ICANN >> and gTLD registry operators and registrars to continue to comply >> with existing ICANN contractual requirements and community-developed >> policies in light of the GDPR. Consistent with ICANN’s stated >> objective to comply with the GDPR, while maintaining the existing >> WHOIS system to the greatest extent possible, the Temporary >> Specification maintains robust collection of Registration Data >> (including Registrant, Administrative, and Technical contact >> information), but restricts most Personal Data to layered/tiered >> access. Users with a legitimate and proportionate purpose for >> accessing the non-public Personal Data will be able to request >> such access through Registrars and Registry Operators. Users will >> also maintain the ability to contact the Registrant or Administrative >> and Technical contacts through an anonymized email or web form. The >> Temporary Specification shall be implemented where required by the >> GDPR, while providing flexibility to Registry Operators and Registrars >> to choose to apply the requirements on a global basis based on >> implementation, commercial reasonableness and fairness considerations. >> The Temporary Specification applies to all registrations, without >> requiring Registrars to differentiate between registrations of legal >> and natural persons. It also covers data processing arrangements >> between and among ICANN, Registry Operators, Registrars, and Data >> Escrow Agents as necessary for compliance with the GDPR." -- -Mysid From don at bowenvale.co.nz Wed May 23 02:27:50 2018 From: don at bowenvale.co.nz (Don Gould) Date: Wed, 23 May 2018 14:27:50 +1200 Subject: Whois vs GDPR, latest news In-Reply-To: <20180523015019.26B6326FB73E@ary.qy> References: <20180523015019.26B6326FB73E@ary.qy> Message-ID: <9BD67E20-CBEE-44AF-8AAD-5B1E9FEC6794@bowenvale.co.nz> What is GDPR? My current guess is "Just another thing to learn since whois is now broken because to many of us just abused a once useful tool" On 23 May 2018 1:50:17 PM NZST, John Levine wrote: >>What about the likely truth that if anyone from Europe mails the list, >then >>every mail server operator with subscribers to the list must follow >the >>GDPR Article 14 notification requirements, as the few exceptions >appear to >>not apply (unless you’re just running an archive). > >Some of us whose businesses and equipment are entirely in North >America will take our chances. This is NANOG, not EUNOG, you know. > >Also, one thing that has become painfully clear is that the number of >people who imagine that they understand the GDPR exceeds the number >who actually understand it by several orders of magnitude. > >The "you have to delete all my messages from the archive if I >unsubscribe" nonsense is a good indicator. > >R's, >John -- Don Gould 5 Cargill Place Richmond Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) www.bowenvale.co.nz skype: don.gould.nz From matt at netfire.net Wed May 23 02:37:00 2018 From: matt at netfire.net (Matt Harris) Date: Tue, 22 May 2018 21:37:00 -0500 Subject: Whois vs GDPR, latest news In-Reply-To: <9BD67E20-CBEE-44AF-8AAD-5B1E9FEC6794@bowenvale.co.nz> References: <20180523015019.26B6326FB73E@ary.qy> <9BD67E20-CBEE-44AF-8AAD-5B1E9FEC6794@bowenvale.co.nz> Message-ID: Maybe I'm going out on a limb here, but was domain whois ever really that useful? I can't remember ever using it for any legitimate sort of activity, and I know it gets scraped quite a bit by spammers. Most of the data is bogus these days on a lot of TLDs which allow "anonymous registrations" and which registrars often charge an extra dollar or two for. Showing the authoritative nameservers is neat, but a simple NS record query against the next level up would suffice to provide that information as well. The date of expiration may be useful if you're trying to grab a domain when it expires, but registrar policies often drag that out anyways and half the time the registrar squats on any decent domain when it expires anyhow. Date of original registration may be interesting for one reason or another... but none of this data is personally identifiable information anyhow. Now on the other hand, RIR whois is actually very useful for determining the rightful owner and abuse contacts for IP address space... Since RIRs are designated by region and, afaik, only RIPE NCC data would be impacted by GDPR... well, I'm surprised this isn't being talked about more than the domain name side of things. Take care, Matt From cstewart at scsbroadband.com Tue May 22 20:50:16 2018 From: cstewart at scsbroadband.com (Clay Stewart) Date: Tue, 22 May 2018 16:50:16 -0400 Subject: Geolocation issue with a twist Message-ID: Can someone point me for help with the following issue? I purchased a /24 late last year on auction which was originally owned by Cox communications in Europe. It had Geolocation in a lot of bad places, and Cox got it 'cleared' up for me. But there is still one issue, an ISP in Spain has it in a Geo database which is pointed to my correct location, but because it is a Spain ISP, the block has lots of issues in block apps and redirects to spam sites. Attach is a snapshot with the incorrect ISP highlight and Geo database. I cannot get any info from the Geo database. I am new to this list, so I hope this is an appropriate question. From sulrich at botwerks.org Tue May 22 20:40:40 2018 From: sulrich at botwerks.org (steve ulrich) Date: Tue, 22 May 2018 15:40:40 -0500 Subject: Segment Routing In-Reply-To: References: Message-ID: On Tue, May 22, 2018 at 9:59 AM Saku Ytti wrote: > On 22 May 2018 at 17:43, steve ulrich wrote: > > Hey, > > > sorry, yes. i was referring to SRTE wrt the pop operation. > > Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is > unambiguous win. > > > not labels but they are encoded as labels. i hope operators have the > option > > to configure common/consistent label ranges, but i don't necessarily > assume > > it. tooling to resolve this will be required just as in the LDP world. > > I've not had this tooling in LDP world, and not anticipating to need > it in SR world. But maybe I'm missing something, what kind of > information do you need in LDP world which you need to develop tooling > for, and how does the problem+solution translate to SR world? > in the day's of yore, i know a few folks who built tooling to validate and/or detect failure to sync between the IGP and LDP or detect data plane black holing behaviors caused by resolution in the RIB w/no complementary label allocation (or LDP convergence lagging significantly). implementations have come a long way since then. but yeah, IGP-LDP sync lag has been a thing for some folks. in a world of anycast/prefix-SIDs some of this doesn't necessarily go away, it just looks kind of different. though to be fair, this alignment improves (the IGP/LDP convergence sync case goes away) for all the reasons you've cited previously in this thread. -- steve ulrich (sulrich at botwerks.*) From marka at isc.org Wed May 23 03:21:51 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 23 May 2018 13:21:51 +1000 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523015019.26B6326FB73E@ary.qy> <9BD67E20-CBEE-44AF-8AAD-5B1E9FEC6794@bowenvale.co.nz> Message-ID: <80CD0E33-5DC0-4724-A4A3-A9E71C709EC8@isc.org> Domain whois is absolutely useful. Try contacting a site to report that their nameservers are hosed without it. People forget that the primary purpose of whois is to report faults. You don’t need to do it very often but when you do it is crucial. Remember that about 50% of zones have not RFC compliant name servers (the software is broken) and that newer resolver depend on default behaviour working correctly. > On 23 May 2018, at 12:37 pm, Matt Harris wrote: > > Maybe I'm going out on a limb here, but was domain whois ever really that > useful? I can't remember ever using it for any legitimate sort of > activity, and I know it gets scraped quite a bit by spammers. Most of the > data is bogus these days on a lot of TLDs which allow "anonymous > registrations" and which registrars often charge an extra dollar or two > for. Showing the authoritative nameservers is neat, but a simple NS record > query against the next level up would suffice to provide that information > as well. The date of expiration may be useful if you're trying to grab a > domain when it expires, but registrar policies often drag that out anyways > and half the time the registrar squats on any decent domain when it expires > anyhow. Date of original registration may be interesting for one reason or > another... but none of this data is personally identifiable information > anyhow. > > Now on the other hand, RIR whois is actually very useful for determining > the rightful owner and abuse contacts for IP address space... Since RIRs > are designated by region and, afaik, only RIPE NCC data would be impacted > by GDPR... well, I'm surprised this isn't being talked about more than the > domain name side of things. > > Take care, > Matt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jhellenthal at dataix.net Wed May 23 03:22:15 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 22 May 2018 22:22:15 -0500 Subject: Geolocation issue with a twist In-Reply-To: References: Message-ID: You will probably need to host that attachment elsewhere and post a link to it. Attachments don’t really fly to mailing lists. > On May 22, 2018, at 15:50, Clay Stewart wrote: > > Can someone point me for help with the following issue? > > I purchased a /24 late last year on auction which was originally owned by > Cox communications in Europe. It had Geolocation in a lot of bad places, > and Cox got it 'cleared' up for me. > > But there is still one issue, an ISP in Spain has it in a Geo database > which is pointed to my correct location, but because it is a Spain ISP, the > block has lots of issues in block apps and redirects to spam sites. > > Attach is a snapshot with the incorrect ISP highlight and Geo database. I > cannot get any info from the Geo database. > > I am new to this list, so I hope this is an appropriate question. -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. From darin.steffl at mnwifi.com Wed May 23 03:57:48 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Tue, 22 May 2018 22:57:48 -0500 Subject: DirecTV Now contact In-Reply-To: <129890931.13791.1527015724375.JavaMail.mhammett@ThunderFuck> References: <2E74AB65-B445-4E3B-A0F6-AF84B41B42AA@gmail.com> <019b01d3f1ff$0231d0d0$06957270$@fourway.net> <129890931.13791.1527015724375.JavaMail.mhammett@ThunderFuck> Message-ID: In my testing, I see Directv now coming from akamai. We peer with them directly and we're only 4ms away and I sometimes still see buffering. So I'd say there's something more going on. I have no trouble with Netflix, YouTube, real choice demo. On Tue, May 22, 2018, 2:07 PM Mike Hammett wrote: > I don't have DirecTV Now. What CDN are they using? Fire up a stream and > use Torch to see what IP it's coming from. > > Torch is a tool in Mikrotik RouterOS. I recognize those three as likely > being familiar with RouterOS, so I sent them that way. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Joshua Stump" > To: "mike lyon" , "Michael Crapse" < > michael at wi-fiber.io> > Cc: "NANOG list" > Sent: Tuesday, May 22, 2018 1:59:27 PM > Subject: RE: DirecTV Now contact > > Similar experience for us as well. > > Joshua Stump > Network Admin > Fourway.NET > 800-733-0062 > > -----Original Message----- > From: NANOG On Behalf Of mike.lyon at gmail.com > Sent: Tuesday, May 22, 2018 2:29 PM > To: Michael Crapse > Cc: NANOG list > Subject: Re: DirecTV Now contact > > Yeah, our eyeball network has problems with DirecTV too. > > Would be nice if they were at the various peering exchanges... > > -Mike > > > On May 22, 2018, at 11:08, Michael Crapse wrote: > > > > Our eyeball network is consistently having some streaming > > issues(buffering) with DirecTV now. Our main recourse is to sell them > > on youtube TV and netflix. fixes the issue, no more complaints from > > our customers. Issues mainly occur during peak times and even on > > 300+mbps low latency/jitter customers. > > However, if someone from DirecTV could contact me off list and we can > > debug this issue so that we don't have to keep pulling people to other > > services that would be great. > > Alternatively, if anyone could suggest with whom to peer to reduce the > > impact of this issue, that would be great. > > A solution that would be even better is if someone from Youtube TV > > would contact us off list and we can set up something commissioned > > based for all the good things we say about your service, and of course > > give our tech support people a reason to not be frustrated with the > > calls we receive for this issue. > > > From hank at efes.iucc.ac.il Wed May 23 04:45:33 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 23 May 2018 07:45:33 +0300 Subject: Whois vs GDPR, latest news In-Reply-To: <20180523015019.26B6326FB73E@ary.qy> References: <20180523015019.26B6326FB73E@ary.qy> Message-ID: <82d0cd2a-be3b-afba-e3cf-ac42f77f728b@efes.iucc.ac.il> On 23/05/2018 04:50, John Levine wrote: >> What about the likely truth that if anyone from Europe mails the list, then >> every mail server operator with subscribers to the list must follow the >> GDPR Article 14 notification requirements, as the few exceptions appear to >> not apply (unless you’re just running an archive). > Some of us whose businesses and equipment are entirely in North > America will take our chances. This is NANOG, not EUNOG, you know. > Also, one thing that has become painfully clear is that the number of > people who imagine that they understand the GDPR exceeds the number > who actually understand it by several orders of magnitude. The "you > have to delete all my messages from the archive if I unsubscribe" > nonsense is a good indicator. R's, John Every generation needs its religious wars.  Unix vs Windows.  OSI vs TCPIP.  Now there is GDPR vs Theworld. -Hank From goemon at sasami.anime.net Wed May 23 07:41:49 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 23 May 2018 00:41:49 -0700 (PDT) Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> Message-ID: On Tue, 22 May 2018, Jimmy Hess wrote: > Perhaps it's time that some would consider new RBLs and Blackhole > feeds based on.... : > Domains with deliberately unavailable WHOIS data. How about the ones with broken contact data - deliberately or not? A whois blacklist sounds good to me. DNS WBL? exhibit A: ========== https://whois.arin.net/rest/net/NET-66-111-32-0-1/pft?s=66.111.56.98 ----- Transcript of session follows ----- ... while talking to aspmx.l.google.com.: >>> DATA <<< 550-5.1.1 The email account that you tried to reach does not exist. Please try <<< 550-5.1.1 double-checking the recipient's email address for typos or <<< 550-5.1.1 unnecessary spaces. Learn more at <<< 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser d26-v6si14042755pge.500 - gsmtp 550 5.1.1 ... User unknown <<< 503 5.5.1 RCPT first. d26-v6si14042755pge.500 - gsmtp exhibit B: ========= https://apps.db.ripe.net/db-web-ui/#/query?searchtext=79.121.0.5#resultsSection ----- Transcript of session follows ----- ... while talking to mail.kabelnet.hu.: >>> DATA <<< 451 Could not complete sender verify callout ... Deferred: 451 Could not complete sender verify callout <<< 503-All RCPT commands were rejected with this error: <<< 503-Could not complete sender verify callout <<< 503 Valid RCPT command must precede DATA Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old -Dan From cstewart at scsbroadband.com Wed May 23 03:39:38 2018 From: cstewart at scsbroadband.com (Clay Stewart) Date: Tue, 22 May 2018 23:39:38 -0400 Subject: Geolocation issue with a twist In-Reply-To: References: Message-ID: https://scsbroadband.com/geolocation/ Here is snapshot of Geolocation issue showing a Spanish ISP registered with a GeoLocation database our IP block, pointed to the correct location. But customers are getting railroaded with spam and failing apps (due to Spain). On Tue, May 22, 2018 at 4:50 PM, Clay Stewart wrote: > Can someone point me for help with the following issue? > > I purchased a /24 late last year on auction which was originally owned by > Cox communications in Europe. It had Geolocation in a lot of bad places, > and Cox got it 'cleared' up for me. > > But there is still one issue, an ISP in Spain has it in a Geo database > which is pointed to my correct location, but because it is a Spain ISP, the > block has lots of issues in block apps and redirects to spam sites. > > Attach is a snapshot with the incorrect ISP highlight and Geo database. I > cannot get any info from the Geo database. > > I am new to this list, so I hope this is an appropriate question. > From nanog at ics-il.net Wed May 23 12:33:06 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 23 May 2018 07:33:06 -0500 (CDT) Subject: Geolocation issue with a twist In-Reply-To: References: Message-ID: <1180385376.14160.1527078782342.JavaMail.mhammett@ThunderFuck> Well that's lovely.., Our site is temporarily unavailable Please contact us at contact-us at eurekapi.com ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Clay Stewart" To: nanog at nanog.org Sent: Tuesday, May 22, 2018 10:39:38 PM Subject: Re: Geolocation issue with a twist https://scsbroadband.com/geolocation/ Here is snapshot of Geolocation issue showing a Spanish ISP registered with a GeoLocation database our IP block, pointed to the correct location. But customers are getting railroaded with spam and failing apps (due to Spain). On Tue, May 22, 2018 at 4:50 PM, Clay Stewart wrote: > Can someone point me for help with the following issue? > > I purchased a /24 late last year on auction which was originally owned by > Cox communications in Europe. It had Geolocation in a lot of bad places, > and Cox got it 'cleared' up for me. > > But there is still one issue, an ISP in Spain has it in a Geo database > which is pointed to my correct location, but because it is a Spain ISP, the > block has lots of issues in block apps and redirects to spam sites. > > Attach is a snapshot with the incorrect ISP highlight and Geo database. I > cannot get any info from the Geo database. > > I am new to this list, so I hope this is an appropriate question. > From nanog at ics-il.net Wed May 23 12:36:06 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 23 May 2018 07:36:06 -0500 (CDT) Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> Message-ID: <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> If you don't have operations in the EU, you can not so politely tell the EU to piss off. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Matthew Kaufman" To: "Fletcher Kittredge" Cc: "NANOG list" Sent: Monday, May 21, 2018 8:07:15 PM Subject: Re: Whois vs GDPR, latest news On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge wrote: > What about my right to not have this crap on NANOG? > What about the likely truth that if anyone from Europe mails the list, then every mail server operator with subscribers to the list must follow the GDPR Article 14 notification requirements, as the few exceptions appear to not apply (unless you’re just running an archive). Matthew From kscotthelms at gmail.com Wed May 23 12:46:19 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Wed, 23 May 2018 08:46:19 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> References: <20180516210200.GA50835@meow.BKantor.net> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> Message-ID: Sadly this isn't true. While I doubt the EU regulators are going to come head hunting for companies any time soon they do have mechanisms in place to sanction companies who don't do business in the EU and the scope is clearly intended to reach where ever the data of EU natural persons is being held. https://gdpr-info.eu/art-3-gdpr/ I asked one of the EU regulators at RSA how they intended to enforce GDPR violations on businesses that don't operate in their jurisdiction and without hesitation he told me they'd use civil courts to sue the offending companies. On Wed, May 23, 2018 at 8:36 AM, Mike Hammett wrote: > If you don't have operations in the EU, you can not so politely tell the > EU to piss off. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Matthew Kaufman" > To: "Fletcher Kittredge" > Cc: "NANOG list" > Sent: Monday, May 21, 2018 8:07:15 PM > Subject: Re: Whois vs GDPR, latest news > > On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge > wrote: > > > What about my right to not have this crap on NANOG? > > > > > What about the likely truth that if anyone from Europe mails the list, > then > every mail server operator with subscribers to the list must follow the > GDPR Article 14 notification requirements, as the few exceptions appear to > not apply (unless you’re just running an archive). > > Matthew > > From nanog at ics-il.net Wed May 23 12:49:58 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 23 May 2018 07:49:58 -0500 (CDT) Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> Message-ID: <38618324.14256.1527079793283.JavaMail.mhammett@ThunderFuck> *shrugs* Me hurting the EU's feelings is rather low on the list of things I care about. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" To: "Mike Hammett" Cc: "NANOG list" Sent: Wednesday, May 23, 2018 7:46:19 AM Subject: Re: Whois vs GDPR, latest news Sadly this isn't true. While I doubt the EU regulators are going to come head hunting for companies any time soon they do have mechanisms in place to sanction companies who don't do business in the EU and the scope is clearly intended to reach where ever the data of EU natural persons is being held. https://gdpr-info.eu/art-3-gdpr/ I asked one of the EU regulators at RSA how they intended to enforce GDPR violations on businesses that don't operate in their jurisdiction and without hesitation he told me they'd use civil courts to sue the offending companies. On Wed, May 23, 2018 at 8:36 AM, Mike Hammett < nanog at ics-il.net > wrote: If you don't have operations in the EU, you can not so politely tell the EU to piss off. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Matthew Kaufman" < matthew at matthew.at > To: "Fletcher Kittredge" < fkittred at gwi.net > Cc: "NANOG list" < nanog at nanog.org > Sent: Monday, May 21, 2018 8:07:15 PM Subject: Re: Whois vs GDPR, latest news On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge < fkittred at gwi.net > wrote: > What about my right to not have this crap on NANOG? > What about the likely truth that if anyone from Europe mails the list, then every mail server operator with subscribers to the list must follow the GDPR Article 14 notification requirements, as the few exceptions appear to not apply (unless you’re just running an archive). Matthew From kscotthelms at gmail.com Wed May 23 13:06:46 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Wed, 23 May 2018 09:06:46 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <38618324.14256.1527079793283.JavaMail.mhammett@ThunderFuck> References: <20180516210200.GA50835@meow.BKantor.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> <38618324.14256.1527079793283.JavaMail.mhammett@ThunderFuck> Message-ID: Of course not, but do you really want to be sued? Even if the US courts decline to accept GDPR cases, which is not at all a given since we have a long history of bilateral enforcement, it costs money to deal with and I don't want to worry that I'm going to fly one day to a country that will enforce civil penalties. While I don't tell most people or companies to worry if they only do business in the US I also don't think it's a good idea to simply thumb your nose at the EU regulators. Some North American direct marketing and data collection firms are definitely going to get a rude, and expensive, awakening despite not having any EU operations. On Wed, May 23, 2018 at 8:49 AM, Mike Hammett wrote: > *shrugs* Me hurting the EU's feelings is rather low on the list of things > I care about. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "K. Scott Helms" > To: "Mike Hammett" > Cc: "NANOG list" > Sent: Wednesday, May 23, 2018 7:46:19 AM > Subject: Re: Whois vs GDPR, latest news > > > Sadly this isn't true. While I doubt the EU regulators are going to come > head hunting for companies any time soon they do have mechanisms in place > to sanction companies who don't do business in the EU and the scope is > clearly intended to reach where ever the data of EU natural persons is > being held. > > > https://gdpr-info.eu/art-3-gdpr/ > > > > I asked one of the EU regulators at RSA how they intended to enforce GDPR > violations on businesses that don't operate in their jurisdiction and > without hesitation he told me they'd use civil courts to sue the offending > companies. > > > On Wed, May 23, 2018 at 8:36 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > If you don't have operations in the EU, you can not so politely tell the > EU to piss off. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Matthew Kaufman" < matthew at matthew.at > > To: "Fletcher Kittredge" < fkittred at gwi.net > > Cc: "NANOG list" < nanog at nanog.org > > Sent: Monday, May 21, 2018 8:07:15 PM > Subject: Re: Whois vs GDPR, latest news > > > > On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge < fkittred at gwi.net > > wrote: > > > What about my right to not have this crap on NANOG? > > > > > What about the likely truth that if anyone from Europe mails the list, > then > every mail server operator with subscribers to the list must follow the > GDPR Article 14 notification requirements, as the few exceptions appear to > not apply (unless you’re just running an archive). > > Matthew > > > > > > From joeyabukiyin at gmail.com Wed May 23 12:01:57 2018 From: joeyabukiyin at gmail.com (Joe Yabuki) Date: Wed, 23 May 2018 14:01:57 +0200 Subject: How to leak aggregate/generated routes into another VRF Message-ID: Hey all, Is there a method of leaking aggregate/generated routes to other VRFs so that the next-hop is modified to actually point to table where the agg/gen routes where created ? One way to do this, is to create a Null0 route and redistribute it into the BGP VRF process, but I would like to know if there is another way to do this ? Many thanks, Joe From lobna_gouda at hotmail.com Wed May 23 14:04:24 2018 From: lobna_gouda at hotmail.com (lobna gouda) Date: Wed, 23 May 2018 14:04:24 +0000 Subject: How to leak aggregate/generated routes into another VRF In-Reply-To: References: Message-ID: Juniper allows you to use next-hop table. Yet this next-hop as to be statically added in the Forwarding table first Brgds, LG ________________________________ From: NANOG on behalf of Joe Yabuki Sent: Wednesday, May 23, 2018 8:01 AM To: nanog at nanog.org Subject: How to leak aggregate/generated routes into another VRF Hey all, Is there a method of leaking aggregate/generated routes to other VRFs so that the next-hop is modified to actually point to table where the agg/gen routes where created ? One way to do this, is to create a Null0 route and redistribute it into the BGP VRF process, but I would like to know if there is another way to do this ? Many thanks, Joe From wingar at team-metro.net Wed May 23 14:08:19 2018 From: wingar at team-metro.net (Emily Scarlett) Date: Wed, 23 May 2018 08:08:19 -0600 Subject: IX's and DC's in Denver Message-ID: <8ce718dd-28b7-1955-a6b7-adb2f82ab42b@team-metro.net> Hey all, We're currently looking at expanding our presence in H5 in Denver, one question on our mind is what our options are for IX connectivity around the area, and if anyone has any experience dealing with them. Any info is useful, thanks! -- ~ Em From nanog at ics-il.net Wed May 23 14:16:37 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 23 May 2018 09:16:37 -0500 (CDT) Subject: IX's and DC's in Denver In-Reply-To: <8ce718dd-28b7-1955-a6b7-adb2f82ab42b@team-metro.net> References: <8ce718dd-28b7-1955-a6b7-adb2f82ab42b@team-metro.net> Message-ID: <2141834589.14357.1527084995439.JavaMail.mhammett@ThunderFuck> https://ix-denver.org/ https://peeringdb.com/advanced_search?city=Denver&reftag=ix ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Emily Scarlett" To: nanog at nanog.org Sent: Wednesday, May 23, 2018 9:08:19 AM Subject: IX's and DC's in Denver Hey all, We're currently looking at expanding our presence in H5 in Denver, one question on our mind is what our options are for IX connectivity around the area, and if anyone has any experience dealing with them. Any info is useful, thanks! -- ~ Em From nanog at ics-il.net Wed May 23 14:53:12 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 23 May 2018 09:53:12 -0500 (CDT) Subject: Geolocation issue with a twist In-Reply-To: <1180385376.14160.1527078782342.JavaMail.mhammett@ThunderFuck> References: <1180385376.14160.1527078782342.JavaMail.mhammett@ThunderFuck> Message-ID: <1856504927.45.1527087188532.JavaMail.mhammett@ThunderFuck> Often people have issues with their IP blocks being geolocated incorrectly. Sometimes it's an error on the database or website's behalf, while other times it's due to a transfer. There used to be a wiki that had a few websites to go to solve these issues, but that site has been gone for years (https://web.archive.org/web/20130122055317/http://nanog.cluepon.net/index.php/GeoIP). We've made a site to hopefully collect this information. Please fill out this form if you have information to contribute. https://goo.gl/forms/jWsaJL1Vgi3yIxFp2 View responses here: https://docs.google.com/spreadsheets/d/1-p7PenqfxnQB1cvq7m3lkmFzLMdxqlgBzaVtsvJ4qZM/edit?usp=sharing ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mike Hammett" To: "Clay Stewart" Cc: nanog at nanog.org Sent: Wednesday, May 23, 2018 7:33:06 AM Subject: Re: Geolocation issue with a twist Well that's lovely.., Our site is temporarily unavailable Please contact us at contact-us at eurekapi.com ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Clay Stewart" To: nanog at nanog.org Sent: Tuesday, May 22, 2018 10:39:38 PM Subject: Re: Geolocation issue with a twist https://scsbroadband.com/geolocation/ Here is snapshot of Geolocation issue showing a Spanish ISP registered with a GeoLocation database our IP block, pointed to the correct location. But customers are getting railroaded with spam and failing apps (due to Spain). On Tue, May 22, 2018 at 4:50 PM, Clay Stewart wrote: > Can someone point me for help with the following issue? > > I purchased a /24 late last year on auction which was originally owned by > Cox communications in Europe. It had Geolocation in a lot of bad places, > and Cox got it 'cleared' up for me. > > But there is still one issue, an ISP in Spain has it in a Geo database > which is pointed to my correct location, but because it is a Spain ISP, the > block has lots of issues in block apps and redirects to spam sites. > > Attach is a snapshot with the incorrect ISP highlight and Geo database. I > cannot get any info from the Geo database. > > I am new to this list, so I hope this is an appropriate question. > From cstewart at scsbroadband.com Wed May 23 14:50:04 2018 From: cstewart at scsbroadband.com (Clay Stewart) Date: Wed, 23 May 2018 10:50:04 -0400 Subject: Geolocation issue with a twist In-Reply-To: <1180385376.14160.1527078782342.JavaMail.mhammett@ThunderFuck> References: <1180385376.14160.1527078782342.JavaMail.mhammett@ThunderFuck> Message-ID: Yes, I can't find a way to contact the Geolocation eurkapi to get this removed, and I have to move two multi-million dollar businesses to this subnet like last month.... but afraid of impacts on their operations from email servers, web servers, and VOIP. And of course, Pandora.... for music to their employees, which we know fails to work due to this issue. On Wed, May 23, 2018 at 8:33 AM, Mike Hammett wrote: > Well that's lovely.., > > Our site is temporarily unavailable > Please contact us at contact-us at eurekapi.com > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Clay Stewart" > *To: *nanog at nanog.org > *Sent: *Tuesday, May 22, 2018 10:39:38 PM > *Subject: *Re: Geolocation issue with a twist > > > https://scsbroadband.com/geolocation/ > > Here is snapshot of Geolocation issue showing a Spanish ISP registered with > a GeoLocation database our IP block, pointed to the correct location. But > customers are getting railroaded with spam and failing apps (due to Spain). > > On Tue, May 22, 2018 at 4:50 PM, Clay Stewart > wrote: > > > Can someone point me for help with the following issue? > > > > I purchased a /24 late last year on auction which was originally owned by > > Cox communications in Europe. It had Geolocation in a lot of bad places, > > and Cox got it 'cleared' up for me. > > > > But there is still one issue, an ISP in Spain has it in a Geo database > > which is pointed to my correct location, but because it is a Spain ISP, > the > > block has lots of issues in block apps and redirects to spam sites. > > > > Attach is a snapshot with the incorrect ISP highlight and Geo database. I > > cannot get any info from the Geo database. > > > > I am new to this list, so I hope this is an appropriate question. > > > > From marquis at roble.com Wed May 23 14:35:25 2018 From: marquis at roble.com (Roger Marquis) Date: Wed, 23 May 2018 07:35:25 -0700 (PDT) Subject: Whois vs GDPR, latest news Message-ID: Dan Hollis wrote: > How about the ones with broken contact data - deliberately or not? > A whois blacklist sounds good to me. DNS WBL? Many sites are already doing this locally. It's just a matter of time before Spamhaus or an up-and-coming entity has an RBL for it. The data is perhaps not precise enough for a blacklist but obfuscated whois records are certainly useful in calculating the reputation of ingress/egress SMTP, HTTP and other services. This is not a new idea and similar to the (unmaintained?) whois.abuse.net contact lookup service, razor/pyzor, and other useful SIEM and Spamassassin inputs. Roger Marquis From johnl at iecc.com Wed May 23 15:53:13 2018 From: johnl at iecc.com (John Levine) Date: 23 May 2018 11:53:13 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: Message-ID: <20180523155314.50F5427017BC@ary.qy> In article you write: >I asked one of the EU regulators at RSA how they intended to enforce GDPR >violations on businesses that don't operate in their jurisdiction and >without hesitation he told me they'd use civil courts to sue the offending >companies. He probably thought you meant if he's in France and the business is in Ireland, since they're both in the EU. Outside the EU, on the other hand, ... If they try to sue in, say, US courts, the US court will ask them to explain why a US court should try a suit under foreign law. There is a very short list of reasons to do that, and this isn't on it. I'm not saying that one should gratuitously poke EU regulators in the eye but it's pretty silly to imagine that they will waste time harassing people over whom they have no jurisdiction and against whom they have no recourse. R's, John From owen at delong.com Wed May 23 15:56:14 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 23 May 2018 08:56:14 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> References: <20180516210200.GA50835@meow.BKantor.net> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> Message-ID: Not really. If you don’t offer services to EU persons, then you are right. However, due to treaties signed by the US and other countries, many places outside the EU are subject to GDPR overreach. Owen > On May 23, 2018, at 05:36, Mike Hammett wrote: > > If you don't have operations in the EU, you can not so politely tell the EU to piss off. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Matthew Kaufman" > To: "Fletcher Kittredge" > Cc: "NANOG list" > Sent: Monday, May 21, 2018 8:07:15 PM > Subject: Re: Whois vs GDPR, latest news > >> On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge wrote: >> >> What about my right to not have this crap on NANOG? >> > > > What about the likely truth that if anyone from Europe mails the list, then > every mail server operator with subscribers to the list must follow the > GDPR Article 14 notification requirements, as the few exceptions appear to > not apply (unless you’re just running an archive). > > Matthew > From owen at delong.com Wed May 23 15:59:57 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 23 May 2018 08:59:57 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <20180523155314.50F5427017BC@ary.qy> References: <20180523155314.50F5427017BC@ary.qy> Message-ID: <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> > On May 23, 2018, at 08:53, John Levine wrote: > > In article you write: >> I asked one of the EU regulators at RSA how they intended to enforce GDPR >> violations on businesses that don't operate in their jurisdiction and >> without hesitation he told me they'd use civil courts to sue the offending >> companies. > > He probably thought you meant if he's in France and the business is in > Ireland, since they're both in the EU. Outside the EU, on the other > hand, ... > > If they try to sue in, say, US courts, the US court will ask them to > explain why a US court should try a suit under foreign law. There is > a very short list of reasons to do that, and this isn't on it. Actually, due to treaty, it is. At least according to some lawyers that have been advising ICANN stakeholder group(s). > > I'm not saying that one should gratuitously poke EU regulators in the > eye but it's pretty silly to imagine that they will waste time > harassing people over whom they have no jurisdiction and against whom > they have no recourse. True. But unfortunately, companies in the US (and many other places with treaties with the EU, including Mauritius, for example) don’t fit that description. Owen From amitchell at isipp.com Wed May 23 16:09:49 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Wed, 23 May 2018 10:09:49 -0600 Subject: Whois vs GDPR, latest news In-Reply-To: <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> Message-ID: <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> > On May 23, 2018, at 9:59 AM, Owen DeLong wrote: > > > >> On May 23, 2018, at 08:53, John Levine wrote: >> >> In article you write: >>> I asked one of the EU regulators at RSA how they intended to enforce GDPR >>> violations on businesses that don't operate in their jurisdiction and >>> without hesitation he told me they'd use civil courts to sue the offending >>> companies. >> >> He probably thought you meant if he's in France and the business is in >> Ireland, since they're both in the EU. Outside the EU, on the other >> hand, ... >> >> If they try to sue in, say, US courts, the US court will ask them to >> explain why a US court should try a suit under foreign law. There is >> a very short list of reasons to do that, and this isn't on it. > > Actually, due to treaty, it is. At least according to some lawyers that have been advising ICANN stakeholder group(s). > Also, don't forget the private right of action. Anyone can file anything in the U.S. courts... you may get it dismissed (although then again you may not) but either way, it's going to be time and money out of your pocket fighting it. MUCH better to just get compliant than to end up a test case. Anne Anne P. Mitchell, Attorney at Law GDPR Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Association Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From list at satchell.net Wed May 23 16:19:03 2018 From: list at satchell.net (Stephen Satchell) Date: Wed, 23 May 2018 09:19:03 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> Message-ID: <50b3e55b-0729-374b-a884-0631436a550c@satchell.net> On 05/23/2018 09:09 AM, Anne P. Mitchell Esq. wrote: > Also, don't forget the private right of action. Anyone can file > anything in the U.S. courts... you may get it dismissed (although > then again you may not) but either way, it's going to be time and > money out of your pocket fighting it. MUCH better to just get > compliant than to end up a test case. And that's why my domains use Register.com's proxy service. I'm risk-adverse, especially with the revenue (pennies) my domains earn. Better to just bite the bullet. That said, I have abuse contacts listed for my domains. You just have to ask the proxy for them. (In 15 years, the only abuse mail I've received is mail from people who HATED what I said on NANAE newsgroup...and I've not used USENET for 10 of those years.) From dbrisson at uvm.edu Wed May 23 16:21:35 2018 From: dbrisson at uvm.edu (Daniel Brisson) Date: Wed, 23 May 2018 16:21:35 +0000 Subject: Whois vs GDPR, latest news In-Reply-To: <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> Message-ID: On 5/23/18, 12:10 PM, "NANOG on behalf of Anne P. Mitchell Esq." wrote: > On May 23, 2018, at 9:59 AM, Owen DeLong wrote: > > > >> On May 23, 2018, at 08:53, John Levine wrote: >> >> In article you write: >>> I asked one of the EU regulators at RSA how they intended to enforce GDPR >>> violations on businesses that don't operate in their jurisdiction and >>> without hesitation he told me they'd use civil courts to sue the offending >>> companies. >> >> He probably thought you meant if he's in France and the business is in >> Ireland, since they're both in the EU. Outside the EU, on the other >> hand, ... >> >> If they try to sue in, say, US courts, the US court will ask them to >> explain why a US court should try a suit under foreign law. There is >> a very short list of reasons to do that, and this isn't on it. > > Actually, due to treaty, it is. At least according to some lawyers that have been advising ICANN stakeholder group(s). > > Also, don't forget the private right of action. Anyone can file anything in the U.S. courts... you may get it dismissed (although then again you may not) but either way, it's going to be time and money out of your pocket fighting it. MUCH better to just get compliant than to end up a test case. Isn't "better" a factor of how much it costs to become compliant with GPDR? I'm no expert, but some of the things I've heard sounded not trivial to implement (read potentially BIG investment). -dan From amitchell at isipp.com Wed May 23 16:29:17 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Wed, 23 May 2018 10:29:17 -0600 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> Message-ID: > On May 23, 2018, at 10:21 AM, Daniel Brisson wrote: > >> Also, don't forget the private right of action. Anyone can file anything in the U.S. courts... you may get it dismissed (although then again you may not) but either way, it's going to be time and money out of your pocket fighting it. MUCH better to just get compliant than to end up a test case. > > Isn't "better" a factor of how much it costs to become compliant with GPDR? I'm no expert, but some of the things I've heard sounded not trivial to implement (read potentially BIG investment). > > -dan In our experience, orgs that are already following all industry best practices are, generally, at least 70% of the way to becoming compliant already. Where it can get expensive for the ones who aren't is in hardening their systems to provide for better security/privacy. U.S. companies are used to being able to drink at the firehose of data that is collected here in the U.S., and use it however they want.. this is the real major change. I suppose you could say it's expensive in that it is reducing the ways they can monetize that data. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance GDPR Compliance Consultant GDPR Compliance Certification http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitchell at isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell From kscotthelms at gmail.com Wed May 23 17:01:42 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Wed, 23 May 2018 13:01:42 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180516210200.GA50835@meow.BKantor.net> <1410320840.9778.1526560997688.JavaMail.mhammett@ThunderFuck> <20180517130330.GC53693@excession.tpb.net> <2f0ae191-3bad-4c38-13b6-4bac442a03ab@dialtelecom.cz> <58627d41-a59c-e497-1bdd-41c81b868cc9@dialtelecom.cz> <443010845.14212.1527078962324.JavaMail.mhammett@ThunderFuck> Message-ID: Yeah, that's not accurate. US organizations sue EU organizations in US courts (and vice versus) on a regular basis but have EU courts collect the damages. Congress can carve out an exemption, but I haven't heard of an effort in that direction getting started yet. In the absence of a legislative exemption the EU regulators can absolutely sue a US entity in US civil courts and get a ruling based on EU laws and regulations. Here's a completely unrelated civil case, on libel, that references the bilateral enforcement and how NY state carved out an exemption. https://www.npr.org/sections/parallels/2015/03/21/394273902/on-libel-and-the-law-u-s-and-u-k-go-separate-ways Scott Helms -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Wed, May 23, 2018 at 11:56 AM, Owen DeLong wrote: > Not really. If you don’t offer services to EU persons, then you are right. > However, due to treaties signed by the US and other countries, many places > outside the EU are subject to GDPR overreach. > > Owen > > > > On May 23, 2018, at 05:36, Mike Hammett wrote: > > > > If you don't have operations in the EU, you can not so politely tell the > EU to piss off. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Matthew Kaufman" > > To: "Fletcher Kittredge" > > Cc: "NANOG list" > > Sent: Monday, May 21, 2018 8:07:15 PM > > Subject: Re: Whois vs GDPR, latest news > > > >> On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge > wrote: > >> > >> What about my right to not have this crap on NANOG? > >> > > > > > > What about the likely truth that if anyone from Europe mails the list, > then > > every mail server operator with subscribers to the list must follow the > > GDPR Article 14 notification requirements, as the few exceptions appear > to > > not apply (unless you’re just running an archive). > > > > Matthew > > > > From kscotthelms at gmail.com Wed May 23 17:05:54 2018 From: kscotthelms at gmail.com (K. Scott Helms) Date: Wed, 23 May 2018 13:05:54 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> Message-ID: Anne, Yep, if you're doing a decent job around securing data then you don't have much to be worried about on that side of things. The problem for most companies is that GDPR isn't really a security law, it's a privacy law (and set of regulations). That's where it's hard because there are a limited number of ways you can, from the EU's standpoint, lawfully process someone's PII. Things like opting out and blanket agreements to use all of someone's data for any reason a company may want are specifically prohibited. Even companies that don't intentionally sell into the EU (or the UK) can find themselves dealing with this if they have customers with employees in the EU. On Wed, May 23, 2018 at 12:29 PM, Anne P. Mitchell Esq. wrote: > > > > On May 23, 2018, at 10:21 AM, Daniel Brisson wrote: > > > >> Also, don't forget the private right of action. Anyone can file > anything in the U.S. courts... you may get it dismissed (although then > again you may not) but either way, it's going to be time and money out of > your pocket fighting it. MUCH better to just get compliant than to end up > a test case. > > > > Isn't "better" a factor of how much it costs to become compliant with > GPDR? I'm no expert, but some of the things I've heard sounded not trivial > to implement (read potentially BIG investment). > > > > -dan > > In our experience, orgs that are already following all industry best > practices are, generally, at least 70% of the way to becoming compliant > already. Where it can get expensive for the ones who aren't is in > hardening their systems to provide for better security/privacy. U.S. > companies are used to being able to drink at the firehose of data that is > collected here in the U.S., and use it however they want.. this is the real > major change. I suppose you could say it's expensive in that it is > reducing the ways they can monetize that data. > > Anne > > Anne P. Mitchell, > Attorney at Law > CEO/President, > SuretyMail Email Reputation Certification and Inbox Delivery Assistance > GDPR Compliance Consultant > GDPR Compliance Certification > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Attorney at Law / Legislative Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Author: The Email Deliverability Handbook > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > Member, California Bar Cyberspace Law Committee > Member, Colorado Cybersecurity Consortium > Member, Board of Directors, Asilomar Microcomputer Workshop > Member, Advisory Board, Cause for Awareness > Member, Elevations Credit Union Member Council > Former Chair, Asilomar Microcomputer Workshop > Ret. Professor of Law, Lincoln Law School of San Jose > > Available for consultations by special arrangement. > amitchell at isipp.com | @AnnePMitchell > Facebook/AnnePMitchell | LinkedIn/in/annemitchell > > From amitchell at isipp.com Wed May 23 17:12:49 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Wed, 23 May 2018 11:12:49 -0600 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> Message-ID: <9AB9FF22-B725-475C-B5B6-CA0708BE2931@isipp.com> > On May 23, 2018, at 11:05 AM, K. Scott Helms wrote: > > Yep, if you're doing a decent job around securing data then you don't have much to be worried about on that side of things. The problem for most companies is that GDPR isn't really a security law, it's a privacy law (and set of regulations). That's where it's hard because there are a limited number of ways you can, from the EU's standpoint, lawfully process someone's PII. Things like opting out and blanket agreements to use all of someone's data for any reason a company may want are specifically prohibited. Even companies that don't intentionally sell into the EU (or the UK) can find themselves dealing with this if they have customers with employees in the EU. Or if someone who is a U.S. citizen and resident goes to the org's U.S.-based website and orders something (or even just provides their PII)... but happens to be in a plane flying over an EU country at the time. Because GDPR doesn't talk about residence or citizenship, it talks only about a vague and ambiguous "in the Union", and I can certainly envision an argument in which the person in the plane claims that they were, technically, "in the Union" at the time. Anne Anne P. Mitchell, Attorney at Law GDPR Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Association Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From surfer at mauigateway.com Wed May 23 20:53:34 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 23 May 2018 13:53:34 -0700 Subject: BGP Battleships Message-ID: <20180523135334.8A5D887E@m0117459.ppops.net> I saw the below on SWINOG and thought it might add some fun in the middle of all this General Data Protection Regulation conversation. :) scott --- Begin forwarded message: From: Gregor Riepl To: swinog at lists.swinog.ch Subject: [swinog] BGP Battleships Date: Tue, 22 May 2018 23:18:51 +0200 Some good ol' fun with BGP: https://blog.benjojo.co.uk/post/bgp-battleships Please (don't?) try this at home! From tom at ninjabadger.net Wed May 23 22:10:43 2018 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 23 May 2018 23:10:43 +0100 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> <5739E3F9-E2CF-4B22-9720-10348510D2E3@6by7.net> Message-ID: <03103fc1-a000-694c-d693-eb34aaaf2bf3@ninjabadger.net> On 19/05/18 21:51, Ben Cannon wrote: > Isn’t that the ASR9010? (And before that 7609?) I can't tell if you're taking the piss or not. -- Tom From tom at ninjabadger.net Wed May 23 22:37:15 2018 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 23 May 2018 23:37:15 +0100 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <6cf11791-5b5d-9d94-9f1f-e3d083d7767b@satchell.net> References: <142000214.9945.1526563493079.JavaMail.mhammett@ThunderFuck> <69949e98-adbd-c246-07b4-8a00149c959c@ninjabadger.net> <6cf11791-5b5d-9d94-9f1f-e3d083d7767b@satchell.net> Message-ID: On 18/05/18 14:55, Stephen Satchell wrote: > What happened when you sent out your last RPQ to the vendors with these > requirements? Why bother? There are so few products, with so few vendors, and their list prices & discount levels are easily researchable in less than a day. If you thought someone was going to build you a tailored device of that ilk then you're surely going to need to commit to buying a lot more than you actually need... Whilst small-to-medium providers still need to play in the DFZ, they don't often buy hundreds (let alone thousands) of small edge routers. -- Tom From tom at ninjabadger.net Wed May 23 22:38:55 2018 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 23 May 2018 23:38:55 +0100 Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in general) In-Reply-To: <2c9df2d1-8fa7-3c55-a5b5-62c915d54b52@gmx.com> References: <93316.1526787787@turing-police.cc.vt.edu> <7dd5f8b5-8a2f-de16-df8a-2bdd487c697f@gmail.com> <835392c6-63bd-b685-0118-e7ed3cbdd22f@seacom.mu> <2c9df2d1-8fa7-3c55-a5b5-62c915d54b52@gmx.com> Message-ID: <4647cc78-eac6-3dbf-3d4b-890190c3bd06@ninjabadger.net> On 21/05/18 17:10, Large Hadron Collider wrote: > I would go as far as to say that Tier 1 is a derogatory designation, but > I have a beef with Cogent because they're expecting otherwise Tier 1 > IPv6 ISP Hurricane Electric to bow to the altar of Cogent. Owen, is dat yew?! -- Tom From goemon at sasami.anime.net Wed May 23 23:22:47 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 23 May 2018 16:22:47 -0700 (PDT) Subject: Whois vs GDPR, latest news In-Reply-To: <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> Message-ID: On Wed, 23 May 2018, Owen DeLong wrote: >> On May 23, 2018, at 08:53, John Levine wrote: >> If they try to sue in, say, US courts, the US court will ask them to >> explain why a US court should try a suit under foreign law. There is >> a very short list of reasons to do that, and this isn't on it. > Actually, due to treaty, it is. At least according to some lawyers that have been advising ICANN stakeholder group(s). can treaties supercede US law? -Dan From owen at delong.com Wed May 23 23:33:27 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 23 May 2018 16:33:27 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> Message-ID: <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> > On May 23, 2018, at 9:29 AM, Anne P. Mitchell Esq. wrote: > > > >> On May 23, 2018, at 10:21 AM, Daniel Brisson wrote: >> >>> Also, don't forget the private right of action. Anyone can file anything in the U.S. courts... you may get it dismissed (although then again you may not) but either way, it's going to be time and money out of your pocket fighting it. MUCH better to just get compliant than to end up a test case. >> >> Isn't "better" a factor of how much it costs to become compliant with GPDR? I'm no expert, but some of the things I've heard sounded not trivial to implement (read potentially BIG investment). >> >> -dan > > In our experience, orgs that are already following all industry best practices are, generally, at least 70% of the way to becoming compliant already. Where it can get expensive for the ones who aren't is in hardening their systems to provide for better security/privacy. U.S. companies are used to being able to drink at the firehose of data that is collected here in the U.S., and use it however they want.. this is the real major change. I suppose you could say it's expensive in that it is reducing the ways they can monetize that data. Of course a perfectly valid alternative is to refuse to do business with EU persons. Then GDPR compliance becomes entirely unnecessary. Owen > > Anne > > Anne P. Mitchell, > Attorney at Law > CEO/President, > SuretyMail Email Reputation Certification and Inbox Delivery Assistance > GDPR Compliance Consultant > GDPR Compliance Certification > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Attorney at Law / Legislative Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Author: The Email Deliverability Handbook > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > Member, California Bar Cyberspace Law Committee > Member, Colorado Cybersecurity Consortium > Member, Board of Directors, Asilomar Microcomputer Workshop > Member, Advisory Board, Cause for Awareness > Member, Elevations Credit Union Member Council > Former Chair, Asilomar Microcomputer Workshop > Ret. Professor of Law, Lincoln Law School of San Jose > > Available for consultations by special arrangement. > amitchell at isipp.com | @AnnePMitchell > Facebook/AnnePMitchell | LinkedIn/in/annemitchell > From johnl at iecc.com Wed May 23 23:38:25 2018 From: johnl at iecc.com (John Levine) Date: Wed, 23 May 2018 19:38:25 -0400 (EDT) Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> Message-ID: > No, but in the absence of a law that specifically bars the courts from > doing so the will under current reciprocal treaty arrangements. No, really, what treaties? I understand treaties about domesticating a tort judgement but this isn't a tort, this is a regulation. R's, John PS: >> can treaties supercede US law? That question has a very complicated answer. tl;dr: sometimes From owen at delong.com Wed May 23 23:53:39 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 23 May 2018 16:53:39 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> Message-ID: <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> How is it false? If you don’t do business in the EU or with EU persons, then you are not included in the class of organizations which GDPR says are subject to GDPR. Owen > On May 23, 2018, at 4:36 PM, K. Scott Helms wrote: > > Owen, > > That's false, please don't spread misinformation. > > Scott Helms > > On Wed, May 23, 2018, 7:34 PM Owen DeLong > wrote: > > > > On May 23, 2018, at 9:29 AM, Anne P. Mitchell Esq. > wrote: > > > > > > > >> On May 23, 2018, at 10:21 AM, Daniel Brisson > wrote: > >> > >>> Also, don't forget the private right of action. Anyone can file anything in the U.S. courts... you may get it dismissed (although then again you may not) but either way, it's going to be time and money out of your pocket fighting it. MUCH better to just get compliant than to end up a test case. > >> > >> Isn't "better" a factor of how much it costs to become compliant with GPDR? I'm no expert, but some of the things I've heard sounded not trivial to implement (read potentially BIG investment). > >> > >> -dan > > > > In our experience, orgs that are already following all industry best practices are, generally, at least 70% of the way to becoming compliant already. Where it can get expensive for the ones who aren't is in hardening their systems to provide for better security/privacy. U.S. companies are used to being able to drink at the firehose of data that is collected here in the U.S., and use it however they want.. this is the real major change. I suppose you could say it's expensive in that it is reducing the ways they can monetize that data. > > Of course a perfectly valid alternative is to refuse to do business with EU persons. Then GDPR compliance becomes entirely unnecessary. > > Owen > > > > > Anne > > > > Anne P. Mitchell, > > Attorney at Law > > CEO/President, > > SuretyMail Email Reputation Certification and Inbox Delivery Assistance > > GDPR Compliance Consultant > > GDPR Compliance Certification > > http://www.SuretyMail.com/ > > http://www.SuretyMail.eu/ > > > > Attorney at Law / Legislative Consultant > > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > > Author: The Email Deliverability Handbook > > Legal Counsel: The CyberGreen Institute > > Legal Counsel: The Earth Law Center > > Member, California Bar Cyberspace Law Committee > > Member, Colorado Cybersecurity Consortium > > Member, Board of Directors, Asilomar Microcomputer Workshop > > Member, Advisory Board, Cause for Awareness > > Member, Elevations Credit Union Member Council > > Former Chair, Asilomar Microcomputer Workshop > > Ret. Professor of Law, Lincoln Law School of San Jose > > > > Available for consultations by special arrangement. > > amitchell at isipp.com | @AnnePMitchell > > Facebook/AnnePMitchell | LinkedIn/in/annemitchell > > > From surfer at mauigateway.com Thu May 24 02:04:05 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 23 May 2018 19:04:05 -0700 Subject: VPN Filter: botnet of routers Message-ID: <20180523190405.8A5DE741@m0117459.ppops.net> Kaboom! https://www.thedailybeast.com/exclusive-fbi-seizes-control-of-russian-botnet "FBI agents armed with a court order have seized control of a key server in the Kremlin’s global botnet of 500,000 hacked routers..." "The FBI counter-operation goes after “VPN Filter,” a piece of sophisticated malware linked to the same Russian hacking group, known as Fancy Bear, that breached the Democratic National Committee and the Hillary Clinton campaign during the 2016 election." https://blog.talosintelligence.com/2018/05/VPNFilter.html "The known devices affected by VPNFilter are Linksys, MikroTik, NETGEAR and TP-Link networking equipment in the small and home office (SOHO) space, as well at QNAP network-attached storage (NAS) devices. No other vendors, including Cisco, have been observed as infected by VPNFilter, but our research continues. The behavior of this malware on networking equipment is particularly concerning, as components of the VPNFilter malware allows for theft of website credentials and monitoring of Modbus SCADA protocols." scott From akajtar at wadsworthcity.org Thu May 24 03:21:27 2018 From: akajtar at wadsworthcity.org (Adam Kajtar) Date: Wed, 23 May 2018 23:21:27 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: <801f0f65-4c9a-7b0d-6a76-c3297ec682f1@seacom.mu> References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <801f0f65-4c9a-7b0d-6a76-c3297ec682f1@seacom.mu> Message-ID: Hello again: I've tried using the default route, adjusting bgp timers, and mutlipath. Unfortunately, these changes haven't helped much. Juniper support hasn't been very helpful also. Although, I think I might have found the solution. https://www.juniper.net/documentation/en_US/junos/topics/topic-map/forwarding-indirect-next-hop.html Let me know what you think. On Tue, May 22, 2018, 4:03 AM Mark Tinka wrote: > > > On 16/May/18 18:59, Phil Lavin wrote: > > Ask if they will configure BFD for you. I’ve not found many transit providers that will, but it’s worth a shot and it will lower failure detection to circa 1 second. > > We've tended to shy away from it, but we have 2 customers we've done it > for. > > Mark. > From bzs at theworld.com Thu May 24 04:22:51 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 24 May 2018 00:22:51 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <82d0cd2a-be3b-afba-e3cf-ac42f77f728b@efes.iucc.ac.il> References: <20180523015019.26B6326FB73E@ary.qy> <82d0cd2a-be3b-afba-e3cf-ac42f77f728b@efes.iucc.ac.il> Message-ID: <23302.15899.579999.395101@gargle.gargle.HOWL> On May 23, 2018 at 07:45 hank at efes.iucc.ac.il (Hank Nussbacher) wrote: > ...Now there is GDPR vs Theworld. Or vice-versa. Sincerely, TheWorld.com. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Thu May 24 04:57:46 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 24 May 2018 00:57:46 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> Message-ID: <23302.17994.923743.288186@gargle.gargle.HOWL> In a nutshell this is a tariff war. They should have pursued their ideas about data privacy etc in international, multilateral venues. The EU is only about 10% of the world's population and perhaps 20% of the world's GDP. What does, for example, China or India think about all this? Is the EU going to seek enforcement against Alibaba or Baidu or FlipKart (ok Walmart owns most of FlipKart now but you get my point I hope)? Latin America? Africa? Brooklyn?! Are APEC, ASEAN, CIS, GCC, DJT, etc (regional trade organizations) each going to launch their own "GDPR"? My guess: Some noise, some lawyers make a buttload* of money, other countries and multinational trade orgs begin resisting which attracts attention from their non-EU nation members, and then it's modified into oblivion. * Note: a "butt" is a standard English barrel measure, a large barrel, 108 imperial gallons. https://en.wikipedia.org/wiki/English_brewery_cask_units#Butt -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bernat at luffy.cx Thu May 24 07:20:36 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Thu, 24 May 2018 09:20:36 +0200 Subject: Juniper BGP Convergence Time In-Reply-To: (Adam Kajtar's message of "Wed, 23 May 2018 23:21:27 -0400") References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <801f0f65-4c9a-7b0d-6a76-c3297ec682f1@seacom.mu> Message-ID: Hey! This feature is already enabled on MX with MPC cards. -- Make it right before you make it faster. - The Elements of Programming Style (Kernighan & Plauger) ――――――― Original Message ――――――― From: Adam Kajtar Sent: 23 mai 2018 23:21 -0400 Subject: Re: Juniper BGP Convergence Time To: Mark Tinka Cc: nanog at nanog.org > Hello again: > > I've tried using the default route, adjusting bgp timers, and mutlipath. > Unfortunately, these changes haven't helped much. Juniper support hasn't > been very helpful also. Although, I think I might have found the solution. > > https://www.juniper.net/documentation/en_US/junos/topics/topic-map/forwarding-indirect-next-hop.html > > Let me know what you think. > > On Tue, May 22, 2018, 4:03 AM Mark Tinka wrote: > >> >> >> On 16/May/18 18:59, Phil Lavin wrote: >> >> Ask if they will configure BFD for you. I’ve not found many transit >> providers that will, but it’s worth a shot and it will lower failure >> detection to circa 1 second. >> >> We've tended to shy away from it, but we have 2 customers we've done it >> for. >> >> Mark. >> From mark.tinka at seacom.mu Thu May 24 08:44:18 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 24 May 2018 10:44:18 +0200 Subject: BGP Battleships In-Reply-To: <20180523135334.8A5D887E@m0117459.ppops.net> References: <20180523135334.8A5D887E@m0117459.ppops.net> Message-ID: <693fb33d-5fa7-7899-1cd4-bf999df2253c@seacom.mu> So the moral of the story is... "former Level(3)" must step into the bar and have a beer with the rest of us :-)? Mark. On 23/May/18 22:53, Scott Weeks wrote: > > I saw the below on SWINOG and thought it might add > some fun in the middle of all this General Data > Protection Regulation conversation. :) > > scott > > > --- Begin forwarded message: > > From: Gregor Riepl > To: swinog at lists.swinog.ch > Subject: [swinog] BGP Battleships > Date: Tue, 22 May 2018 23:18:51 +0200 > > Some good ol' fun with BGP: > > https://blog.benjojo.co.uk/post/bgp-battleships > > Please (don't?) try this at home! > > > > > . > From olivier.benghozi at wifirst.fr Thu May 24 10:36:28 2018 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 24 May 2018 12:36:28 +0200 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <801f0f65-4c9a-7b0d-6a76-c3297ec682f1@seacom.mu> Message-ID: <1EC3BB06-5DD8-4889-8C85-0690FADD76BE@wifirst.fr> I wonder if this convergence time issue wouldn't be a typical mission for «BGP PIC Edge for MPLS Layer 3 VPNs». But it would be necessary to migrate the DFZ to a VPN MPLS (and configure composite nexthop and BGP PIC / «Provider Edge Link Protection»). > Le 24 mai 2018 à 09:20, Vincent Bernat a écrit : > > This feature is already enabled on MX with MPC cards. > > ――――――― Original Message ――――――― > From: Adam Kajtar > Sent: 23 mai 2018 23:21 -0400 > Subject: Re: Juniper BGP Convergence Time > To: Mark Tinka > Cc: nanog at nanog.org > >> Hello again: >> >> I've tried using the default route, adjusting bgp timers, and mutlipath. >> Unfortunately, these changes haven't helped much. Juniper support hasn't >> been very helpful also. Although, I think I might have found the solution. >> >> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/forwarding-indirect-next-hop.html >> >> Let me know what you think. >> >> On Tue, May 22, 2018, 4:03 AM Mark Tinka wrote: >> >>> >>> >>> On 16/May/18 18:59, Phil Lavin wrote: >>> >>> Ask if they will configure BFD for you. I’ve not found many transit >>> providers that will, but it’s worth a shot and it will lower failure >>> detection to circa 1 second. >>> >>> We've tended to shy away from it, but we have 2 customers we've done it >>> for. From bernat at luffy.cx Thu May 24 11:39:51 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Thu, 24 May 2018 13:39:51 +0200 Subject: Juniper BGP Convergence Time In-Reply-To: <1EC3BB06-5DD8-4889-8C85-0690FADD76BE@wifirst.fr> (Olivier Benghozi's message of "Thu, 24 May 2018 12:36:28 +0200") References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <801f0f65-4c9a-7b0d-6a76-c3297ec682f1@seacom.mu> <1EC3BB06-5DD8-4889-8C85-0690FADD76BE@wifirst.fr> Message-ID: <87sh6hth88.fsf@luffy.cx> ❦ 24 mai 2018 12:36 +0200, Olivier Benghozi  : > I wonder if this convergence time issue wouldn't be a typical mission for «BGP PIC Edge for MPLS Layer 3 VPNs». > But it would be necessary to migrate the DFZ to a VPN MPLS (and > configure composite nexthop and BGP PIC / «Provider Edge Link > Protection»). BGP PIC is also available with IP now: https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/bgp-configuring-bgp-pic-for-inet.html I've asked the question two years ago on j-nsp. Here is the thread: https://lists.gt.net/nsp/juniper/57149 There is a step by step guide about in the middle of the guide. I didn't have the right version to test at the time. I didn't try again since then. -- Make sure comments and code agree. - The Elements of Programming Style (Kernighan & Plauger) From olivier.benghozi at wifirst.fr Thu May 24 11:53:49 2018 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Thu, 24 May 2018 13:53:49 +0200 Subject: Juniper BGP Convergence Time In-Reply-To: <87sh6hth88.fsf@luffy.cx> References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> <801f0f65-4c9a-7b0d-6a76-c3297ec682f1@seacom.mu> <1EC3BB06-5DD8-4889-8C85-0690FADD76BE@wifirst.fr> <87sh6hth88.fsf@luffy.cx> Message-ID: Yep, feature naming in JunOS... In fact I meant «Provider Edge Link Protection», which is only for VPN (and Labeled Unicast), and that applies here (eBGP paths are protected using iBGP paths). > Le 24 mai 2018 à 13:39, Vincent Bernat a écrit : > > ❦ 24 mai 2018 12:36 +0200, Olivier Benghozi : > >> I wonder if this convergence time issue wouldn't be a typical mission for «BGP PIC Edge for MPLS Layer 3 VPNs». >> But it would be necessary to migrate the DFZ to a VPN MPLS (and >> configure composite nexthop and BGP PIC / «Provider Edge Link >> Protection»). > > BGP PIC is also available with IP now: > https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/bgp-configuring-bgp-pic-for-inet.html > > I've asked the question two years ago on j-nsp. Here is the thread: > https://lists.gt.net/nsp/juniper/57149 > > There is a step by step guide about in the middle of the guide. I didn't > have the right version to test at the time. I didn't try again since > then. From dmburgess at linktechs.net Thu May 24 13:18:29 2018 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 24 May 2018 13:18:29 +0000 Subject: BGP Battleships In-Reply-To: <693fb33d-5fa7-7899-1cd4-bf999df2253c@seacom.mu> References: <20180523135334.8A5D887E@m0117459.ppops.net> <693fb33d-5fa7-7899-1cd4-bf999df2253c@seacom.mu> Message-ID: MikroTik Official Response: Cisco informed us on May 22nd of 2018, that a malicious tool was found on several manufacturer devices, including three devices made by MikroTik. We are highly certain that this malware was installed on these devices through a vulnerability in MikroTik RouterOS software, which was already patched by MikroTik in March 2017. Simply upgrading RouterOS software deletes the malware, any other 3rd party files and closes the vulnerability. Let us know if you need more details. Upgrading RouterOS is done by a few clicks and takes only a minute. https://forum.mikrotik.com/viewtopic.php?f=21&t=134776&p=663825#p663825 Dennis Burgess, MikroTik Certified Trainer -----Original Message----- From: NANOG On Behalf Of Mark Tinka Sent: Thursday, May 24, 2018 3:44 AM To: surfer at mauigateway.com; nanog at nanog.org Subject: Re: BGP Battleships So the moral of the story is... "former Level(3)" must step into the bar and have a beer with the rest of us :-)? Mark. On 23/May/18 22:53, Scott Weeks wrote: > > I saw the below on SWINOG and thought it might add some fun in the > middle of all this General Data Protection Regulation conversation. :) > > scott > > > --- Begin forwarded message: > > From: Gregor Riepl > To: swinog at lists.swinog.ch > Subject: [swinog] BGP Battleships > Date: Tue, 22 May 2018 23:18:51 +0200 > > Some good ol' fun with BGP: > > https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=http > s%3a%2f%2fblog.benjojo.co.uk%2fpost%2fbgp%2dbattleships&umid=11F39436- > 6CEF-A905-AF98-203A0AD563EA&auth=079c058f437b7c6303d36c6513e5e8848d0c5 > ac4-9d1558ea3856dddcaa08f2ee54a6060b4ee27e65 > > Please (don't?) try this at home! > > > > > . > From C-Mack.McBride at charter.com Wed May 23 23:52:37 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Wed, 23 May 2018 23:52:37 +0000 Subject: Geolocation issue with a twist In-Reply-To: References: <1180385376.14160.1527078782342.JavaMail.mhammett@ThunderFuck> Message-ID: <67af44ef4324452f9eff669081916c93@SC58MEXGP032.CORP.CHARTERCOM.com> Send them an email at the listed email address. Geolocation is always a pain. It can take months to get it straight. Mack Contractor -----Original Message----- From: NANOG [mailto:nanog-bounces+c-mack.mcbride=charter.com at nanog.org] On Behalf Of Clay Stewart Sent: Wednesday, May 23, 2018 8:50 AM To: nanog at nanog.org Subject: Re: Geolocation issue with a twist Yes, I can't find a way to contact the Geolocation eurkapi to get this removed, and I have to move two multi-million dollar businesses to this subnet like last month.... but afraid of impacts on their operations from email servers, web servers, and VOIP. And of course, Pandora.... for music to their employees, which we know fails to work due to this issue. On Wed, May 23, 2018 at 8:33 AM, Mike Hammett wrote: > Well that's lovely.., > > Our site is temporarily unavailable > Please contact us at contact-us at eurekapi.com > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Clay Stewart" > *To: *nanog at nanog.org > *Sent: *Tuesday, May 22, 2018 10:39:38 PM > *Subject: *Re: Geolocation issue with a twist > > > https://scsbroadband.com/geolocation/ > > Here is snapshot of Geolocation issue showing a Spanish ISP registered > with a GeoLocation database our IP block, pointed to the correct > location. But customers are getting railroaded with spam and failing apps (due to Spain). > > On Tue, May 22, 2018 at 4:50 PM, Clay Stewart > > wrote: > > > Can someone point me for help with the following issue? > > > > I purchased a /24 late last year on auction which was originally > > owned by Cox communications in Europe. It had Geolocation in a lot > > of bad places, and Cox got it 'cleared' up for me. > > > > But there is still one issue, an ISP in Spain has it in a Geo > > database which is pointed to my correct location, but because it is > > a Spain ISP, > the > > block has lots of issues in block apps and redirects to spam sites. > > > > Attach is a snapshot with the incorrect ISP highlight and Geo > > database. I cannot get any info from the Geo database. > > > > I am new to this list, so I hope this is an appropriate question. > > > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From jcmurphy at jeffmurphy.org Thu May 24 00:10:40 2018 From: jcmurphy at jeffmurphy.org (jeff murphy) Date: Wed, 23 May 2018 20:10:40 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> Message-ID: <0BB31BBB-388D-4832-85DD-30C01C187BA1@jeffmurphy.org> There’s speculation that enforcement could occur via the FTC Privacy Shield program. > On May 23, 2018, at 7:38 PM, John Levine wrote: > >> No, but in the absence of a law that specifically bars the courts from >> doing so the will under current reciprocal treaty arrangements. > > No, really, what treaties? I understand treaties about domesticating a tort judgement but this isn't a tort, this is a regulation. > > R's, > John > > PS: > >>> can treaties supercede US law? > > That question has a very complicated answer. tl;dr: sometimes From sabina at auxes.is Thu May 24 12:43:12 2018 From: sabina at auxes.is (Sabina M.) Date: Thu, 24 May 2018 08:43:12 -0400 Subject: SD-WAN Solutions Message-ID: Has anyone worked with Nuage from around here? Additionally, is anyone familiar with what RFC Alcatel/Nokia is implementing for the VXLAN part of the solution? It looks a bit non-standard but I can't find any clear documentation regarding this anywhere Cheers, S. From amitchell at isipp.com Thu May 24 14:21:43 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Thu, 24 May 2018 08:21:43 -0600 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> Message-ID: <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> > On May 23, 2018, at 7:18 PM, K. Scott Helms wrote: > > Anything that can tie back to an individual data subject is PII, that means email addresses, names in combination with addresses or phone numbers, finger prints, or even insufficiently abstracted internal ID numbers/codes. Don't forget IP addresses, as part of the wonderfully vague "online identifiers". > Notice I didn't say EU citizen there, that's because the law and regulations (GDPR consists of both) intentionally cover any natural person in any of the 28 EU nations including the citizens of non-EU nations. > I don't go as far as I think Anne was suggesting, in that someone in EU airspace who sent an email or made a purchase is now suddenly an EU data subject. You may accuse me of being a lawyer here (and rightly so :-) ), but "in", as in "in the Union" (which is the actual language) is very much open to interpretation. In a judicial system where lawsuits have turned on - I kid you not - the interpretation of what a comma meant, I can almost guarantee you that "in the Union" is going to get interpreted through lawsuits, and it is absolutely not outside the realm of possibility that a U.S. citizen visiting in the EU will bring a lawsuit based on something happening with their PII while they were "in the Union". > Any company that is covered by the GDPR must be extremely careful that any company they do business with is also compliant if that company will have access or act as a data processor. That means that if you are a US company that has US only customers, but some of your customers have employees that are US citizens but who live in an EU nation then they are bound to only use providers that are GDPR compliant. Now, this will result in contractual disputes and/or loss of business rather than having EU regulators fine your company directly. The end result is that many many many companies that don't sell or market to the EU are finding themselves needing to comply in the same way that companies that sell services to medical companies often have to follow HIPAA (and be audited) even though they provide medical services themselves. > Actually, GDPR specifically requires processors to include statements of compliance right in their contracts; we also strongly recommend that controllers insist on indemnification clauses in their contracts with processors, because if the processor screws up and there is a breach, the _controller_ can also be held liable, and the financial penalties in GDPR are very stiff. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance GDPR Compliance Consultant GDPR Compliance Certification http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitchell at isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell From kscott.helms at gmail.com Thu May 24 15:19:16 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Thu, 24 May 2018 11:19:16 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: Anne, While I was re-reading some of the emails last night I realized that I mischaracterized your description here, *"You may accuse me of being a lawyer here (and rightly so :-) ), but "in", as in "in the Union" (which is the actual language) is very much open to interpretation. In a judicial system where lawsuits have turned on - I kid you not - the interpretation of what a comma meant, I can almost guarantee you that "in the Union" is going to get interpreted through lawsuits, and it is absolutely not outside the realm of possibility that a U.S. citizen visiting in the EU will bring a lawsuit based on something happening with their PII while they were "in the Union".* I didn't make it clear that you were suggesting that some would make this claim rather than you making that claim. Mea culpa :) Our counselors made it clear (as did the regulators I was able to ask) that short term visits weren't intended to be covered *in their opinion.* There are and will be many questions that won't be fully answered until adjudicated or more precise language is used to make the meaning clear. Juhan Lepassaar (Head of VP Ansip Cabinet, European Commission) was one of the speakers and we were able to ask questions of him. It looks like the video of one of the presentations I was at is now publicly available and I encourage those with questions to watch it. https://www.rsaconference.com/speakers/juhan-lepassaar *" Actually, GDPR specifically requires processors to include statements of compliance right in their contracts; we also strongly recommend that controllers insist on indemnification clauses in their contracts with processors, because if the processor screws up and there is a breach, the _controller_ can also be held liable, and the financial penalties in GDPR are very stiff."* Yep, this is better (clearer) wording than what I used and is absolutely correct. On Thu, May 24, 2018 at 10:21 AM Anne P. Mitchell Esq. wrote: > > > > On May 23, 2018, at 7:18 PM, K. Scott Helms > wrote: > > > > Anything that can tie back to an individual data subject is PII, that > means email addresses, names in combination with addresses or phone > numbers, finger prints, or even insufficiently abstracted internal ID > numbers/codes. > > Don't forget IP addresses, as part of the wonderfully vague "online > identifiers". > > > Notice I didn't say EU citizen there, that's because the law and > regulations (GDPR consists of both) intentionally cover any natural person > in any of the 28 EU nations including the citizens of non-EU nations. > > I don't go as far as I think Anne was suggesting, in that someone in EU > airspace who sent an email or made a purchase is now suddenly an EU data > subject. > > You may accuse me of being a lawyer here (and rightly so :-) ), but "in", > as in "in the Union" (which is the actual language) is very much open to > interpretation. In a judicial system where lawsuits have turned on - I > kid you not - the interpretation of what a comma meant, I can almost > guarantee you that "in the Union" is going to get interpreted through > lawsuits, and it is absolutely not outside the realm of possibility that a > U.S. citizen visiting in the EU will bring a lawsuit based on something > happening with their PII while they were "in the Union". > > > Any company that is covered by the GDPR must be extremely careful that > any company they do business with is also compliant if that company will > have access or act as a data processor. That means that if you are a US > company that has US only customers, but some of your customers have > employees that are US citizens but who live in an EU nation then they are > bound to only use providers that are GDPR compliant. Now, this will result > in contractual disputes and/or loss of business rather than having EU > regulators fine your company directly. The end result is that many many > many companies that don't sell or market to the EU are finding themselves > needing to comply in the same way that companies that sell services to > medical companies often have to follow HIPAA (and be audited) even though > they provide medical services themselves. > > > > Actually, GDPR specifically requires processors to include statements of > compliance right in their contracts; we also strongly recommend that > controllers insist on indemnification clauses in their contracts with > processors, because if the processor screws up and there is a breach, the > _controller_ can also be held liable, and the financial penalties in GDPR > are very stiff. > > Anne > > Anne P. Mitchell, > Attorney at Law > CEO/President, > SuretyMail Email Reputation Certification and Inbox Delivery Assistance > GDPR Compliance Consultant > GDPR Compliance Certification > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Attorney at Law / Legislative Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Author: The Email Deliverability Handbook > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > Member, California Bar Cyberspace Law Committee > Member, Colorado Cybersecurity Consortium > Member, Board of Directors, Asilomar Microcomputer Workshop > Member, Advisory Board, Cause for Awareness > Member, Elevations Credit Union Member Council > Former Chair, Asilomar Microcomputer Workshop > Ret. Professor of Law, Lincoln Law School of San Jose > > Available for consultations by special arrangement. > amitchell at isipp.com | @AnnePMitchell > Facebook/AnnePMitchell | LinkedIn/in/annemitchell > > > > > > From elmi at 4ever.de Thu May 24 16:20:29 2018 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 24 May 2018 18:20:29 +0200 Subject: Bezeq Internet (IL) around? Message-ID: <20180524162028.GC1007@anx-nb3810.local> Hi Bezeq people, I hope you're subscribed here, I could use your immediate help, probably leading to a contract... Yours, Elmar. From surfer at mauigateway.com Thu May 24 19:24:47 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 24 May 2018 12:24:47 -0700 Subject: SD-WAN Solutions Message-ID: <20180524122447.92EBB771@m0117459.ppops.net> --- sabina at auxes.is wrote: From: "Sabina M." Additionally, is anyone familiar with what RFC Alcatel/Nokia is implementing for the VXLAN part of the solution? It looks a bit non-standard but I can't find any clear documentation regarding this anywhere ------------------------------------------- You might try over on alcatel-nsp at puck.nether.net. Alcatel folks used to (still do?) hang out over there to answer questions. scott From aj at sneep.net Thu May 24 21:45:52 2018 From: aj at sneep.net (Alastair Johnson) Date: Thu, 24 May 2018 14:45:52 -0700 Subject: SD-WAN Solutions In-Reply-To: <20180524122447.92EBB771@m0117459.ppops.net> References: <20180524122447.92EBB771@m0117459.ppops.net> Message-ID: <0d4d45ed-b886-9860-3086-619cc7627d4a@sneep.net> On 5/24/18 12:24 PM, Scott Weeks wrote: > > > --- sabina at auxes.is wrote: > From: "Sabina M." > > Additionally, is anyone familiar with what RFC Alcatel/Nokia > is implementing for the VXLAN part of the solution? It looks > a bit non-standard but I can't find any clear documentation > regarding this anywhere > ------------------------------------------- > > > You might try over on alcatel-nsp at puck.nether.net. Alcatel > folks used to (still do?) hang out over there to answer > questions. That is a good list to use indeed. Many employees are subscribed there, although traffic is pretty low. ...Or for questions about Nuage, feel free to reach out to me. AJ aj at nuagenetworks.net Nuage Networks from Nokia (and Alcatel-Lucent/Alcatel). From johnl at iecc.com Thu May 24 22:30:14 2018 From: johnl at iecc.com (John Levine) Date: 24 May 2018 18:30:14 -0400 Subject: GDPR outside Europe, was Whois vs GDPR, latest news In-Reply-To: <0BB31BBB-388D-4832-85DD-30C01C187BA1@jeffmurphy.org> Message-ID: <20180524223015.745502714F99@ary.qy> In article <0BB31BBB-388D-4832-85DD-30C01C187BA1 at jeffmurphy.org> you write: >There’s speculation that enforcement could occur via the FTC Privacy Shield program. Privacy Shield is entirely optional. Joining it requires a lot of paperwork and a substantial administrative fee. If you don't do all that, it doesn't apply to you. Please see my previous comment about people who think they understand the GDPR vs. people who actually do. https://www.privacyshield.gov/welcome Also, Privacy Shield is a retread of the Safe Harbour deal which EU courts invalidated in 2015. Max Schrems, the guy who filed the case against Safe Harbour, has filed a similar suit against Privacy Shield, with Facebook as the defendant. I wouldn't bet a lot on Privacy Shield lasting any better than Safe Harbour did. https://techcrunch.com/2018/04/13/privacy-shield-now-facing-questions-via-legal-challenge-to-facebook-data-flows/ R's, John PS: For anyone who came into the middle of this argument, my point is that if you have no EU nexus, the realistic chances of the EU taking action against you round to zero. If you do have EU nexus, you better behave. From kscott.helms at gmail.com Fri May 25 12:47:06 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Fri, 25 May 2018 08:47:06 -0400 Subject: GDPR outside Europe, was Whois vs GDPR, latest news In-Reply-To: <20180524223015.745502714F99@ary.qy> References: <0BB31BBB-388D-4832-85DD-30C01C187BA1@jeffmurphy.org> <20180524223015.745502714F99@ary.qy> Message-ID: *" PS: For anyone who came into the middle of this argument, my point isthat if you have no EU nexus, the realistic chances of the EU takingaction against you round to zero. If you do have EU nexus, you betterbehave."* I'd say this is accurate with a few caveats and most of those won't apply to NANOG folks. One, if you or your company is involved in direct marketing then you'd better pay attention now even if you don't intentionally market to people in the EU. Two, if you work on sensitive PII (by the GDPR definitions) and you may have EU data subjects' PII. Three, if you or your company are making public statements about GDPR not applying to you or making false statements publicly about how your opt out set up is GDPR compliant (when it can't be). When I first was involved with international contracts we had a series of meetings with our executives and legal. The first thing we heard from legal were things like, "your contracts aren't enforceable in Europe or Asia". When we dived into those statements what we found was that was practically true, because enforcing them required us to go down one of two (both expensive) pathways. Establish a corporate identify in all the places we wanted to do business and then we could more easily sue in the local court system where our customers were located _or_ we could sue in US court and then (provided we won) take that US ruling to the local courts with jurisdiction over the customer in question. Both were entirely possible from a legal standpoint, but neither were practical since the cost of taking either path would greatly exceed the value of the contract in question. Instead of doing that we simply set things up so that we can quickly turn off services and we billed a month in advance rather than post billing the way we did in North America. What I'm getting at is that international enforcement of decisions is expensive and while the EU has a lot of resources, lawyers, and money they're still going to be prioritizing their "target" selection. They're definitely (as we see from the Facebook fine) going after the big, and in their minds, egregious abusers of privacy. Unless you or your company is very large, international in nature, or doing something they'd consider very abusive then you're not likely to be at the top of that list. Having said that, once things shake out and the big fish are all either compliant or in court then the regulators will start looking down list. In fairness, the regulators I spoke with emphasized that they're not "head hunting" (their words) and that don't want to harm companies that might inadvertently be violating GDPR in small ways. I expect that many more warning letters will be sent than actual fines or regulatory actions this year. On Thu, May 24, 2018 at 6:31 PM John Levine wrote: > In article <0BB31BBB-388D-4832-85DD-30C01C187BA1 at jeffmurphy.org> you > write: > >There’s speculation that enforcement could occur via the FTC Privacy > Shield program. > > Privacy Shield is entirely optional. Joining it requires a lot of > paperwork and a substantial administrative fee. If you don't do all > that, it doesn't apply to you. Please see my previous comment about > people who think they understand the GDPR vs. people who actually do. > > https://www.privacyshield.gov/welcome > > Also, Privacy Shield is a retread of the Safe Harbour deal which EU > courts invalidated in 2015. Max Schrems, the guy who filed the case > against Safe Harbour, has filed a similar suit against Privacy Shield, > with Facebook as the defendant. I wouldn't bet a lot on Privacy > Shield lasting any better than Safe Harbour did. > > > https://techcrunch.com/2018/04/13/privacy-shield-now-facing-questions-via-legal-challenge-to-facebook-data-flows/ > > R's, > John > > PS: For anyone who came into the middle of this argument, my point is > that if you have no EU nexus, the realistic chances of the EU taking > action against you round to zero. If you do have EU nexus, you better > behave. > From ahebert at pubnix.net Fri May 25 15:47:04 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 25 May 2018 11:47:04 -0400 Subject: BGP Hijack/Sickness with AS4637 Message-ID:     Hi,     We're looking for a contact, *that works*, to get in touch with AS4637 (Telstra/HK) about some hijacking or router sickness.     BGPmon has been reporting an hijack of AS3's subnet 18.29.238.0/23.     After being contacted by AS3, we went over the advertisement with AS29909 and AS16532 to be sure.     Then we tried getting in touch with AS4637 (Telstra/HK) but it went nowhere at this point.     PS: If anyone has better observations that would be greatly appreciated. ----- Context:     A few times this month, BGPmon reported an hijack of 18.29.238.0/23  (AS3).     For this hijack I see AS4637 (Telstra/HK), AS3257( GTT) AS29909 (MOO) and AS16532 ( (which are peers I know and I'm in contact with).         And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as they're not the one advertising those routes to AS4637     AS16532 found it to come from AS4637 as you can see from this ColoAU LG output below ----- https://lg.coloau.com.au/ vrf-international.inet.0: 696533 destinations, 2248101 routes (696249 active, 0 holddown, 103835 hidden) + = Active Route, - = Last Active, * = Both 18.29.238.0/23     *[BGP/170] 1d 19:57:28, localpref 90, from 103.97.52.2                       AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified -- ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From nanog at ics-il.net Fri May 25 16:36:01 2018 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 25 May 2018 11:36:01 -0500 (CDT) Subject: IP Reputation In-Reply-To: <1814215848.1489.1527265265423.JavaMail.mhammett@ThunderFuck> Message-ID: <571778019.1519.1527266157407.JavaMail.mhammett@ThunderFuck> I would like to call on organizations that provide IP reputation information to have methods available for network operators to determine if they are on their lists, what their reputation is, what it means, optionally evidence, and a means of removal of negative information. Near real-time notice of changes in your status would be recommended as well. If those wants sound ridiculous, nearly that same list of wants is provided by e-mail SPAM DNSRBL maintainers so it isn't exactly unprecedented. I recently interacted with an organization that provides IP reputation information as a component in a larger security offering. A particular eyeball network couldn't get to a number of large web destinations. After some prodding of the company providing the security offering, it was determined that the prefix in question was because on a scale of 0 to 10 with 0 being the best and 10 being the worst, that prefix had a score of 1. They claimed they could do nothing about it as their client (the web site being visited) had that in their control. That's a half-truth. The company providing that IP reputation put them on the list (for whatever reason), while the web site chose whatever metrics to block. Their proposed solution was to contact every web site there were issues with and request that they fix it. Okay, so an eyeball is supposed to reach out to dozens of major brands and get someone that understands the situation and can resolve it in a reasonable time frame? Most of these brands take days to address core things dealing with their core product or service, much less getting someone in IT to whitelist a prefix. I'm sorry, that's not a realistic solution. If not a proactive alert (like a SPAM feedback loop), they need an easy form to fill out and after some automated means of verification (ASN or IP whois contact lookup), spill the beans on who, what, where, why, and how to get it fixed. I'm not saying there was no valid reason to put them on the list. There's no easy way to determine that they're on the list, why, and any means of getting removed from the list when the problem is fixed. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From cscora at apnic.net Fri May 25 18:02:57 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 May 2018 04:02:57 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180525180257.993BCC450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG 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 26 May, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 701902 Prefixes after maximum aggregation (per Origin AS): 269651 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 337566 Total ASes present in the Internet Routing Table: 60835 Prefixes per ASN: 11.54 Origin-only ASes present in the Internet Routing Table: 52547 Origin ASes announcing only one prefix: 22946 Transit ASes present in the Internet Routing Table: 8288 Transit-only ASes present in the Internet Routing Table: 271 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 48 Number of instances of unregistered ASNs: 48 Number of 32-bit ASNs allocated by the RIRs: 22716 Number of 32-bit ASNs visible in the Routing Table: 18310 Prefixes from 32-bit ASNs in the Routing Table: 76393 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 276 Number of addresses announced to Internet: 2860355907 Equivalent to 170 /8s, 125 /16s and 145 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 234647 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 191524 Total APNIC prefixes after maximum aggregation: 54361 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 190353 Unique aggregates announced from the APNIC address blocks: 77978 APNIC Region origin ASes present in the Internet Routing Table: 8831 APNIC Prefixes per ASN: 21.56 APNIC Region origin ASes announcing only one prefix: 2475 APNIC Region transit ASes present in the Internet Routing Table: 1317 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 22 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3802 Number of APNIC addresses announced to Internet: 766494466 Equivalent to 45 /8s, 175 /16s and 199 /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: 208837 Total ARIN prefixes after maximum aggregation: 99153 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 209554 Unique aggregates announced from the ARIN address blocks: 99034 ARIN Region origin ASes present in the Internet Routing Table: 18185 ARIN Prefixes per ASN: 11.52 ARIN Region origin ASes announcing only one prefix: 6713 ARIN Region transit ASes present in the Internet Routing Table: 1798 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2353 Number of ARIN addresses announced to Internet: 1106418720 Equivalent to 65 /8s, 242 /16s and 156 /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: 191947 Total RIPE prefixes after maximum aggregation: 92215 RIPE Deaggregation factor: 2.08 Prefixes being announced from the RIPE address blocks: 187983 Unique aggregates announced from the RIPE address blocks: 111588 RIPE Region origin ASes present in the Internet Routing Table: 25207 RIPE Prefixes per ASN: 7.46 RIPE Region origin ASes announcing only one prefix: 11384 RIPE Region transit ASes present in the Internet Routing Table: 3515 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7023 Number of RIPE addresses announced to Internet: 715946112 Equivalent to 42 /8s, 172 /16s and 120 /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: 90883 Total LACNIC prefixes after maximum aggregation: 19907 LACNIC Deaggregation factor: 4.57 Prefixes being announced from the LACNIC address blocks: 92294 Unique aggregates announced from the LACNIC address blocks: 41069 LACNIC Region origin ASes present in the Internet Routing Table: 7170 LACNIC Prefixes per ASN: 12.87 LACNIC Region origin ASes announcing only one prefix: 1993 LACNIC Region transit ASes present in the Internet Routing Table: 1324 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4711 Number of LACNIC addresses announced to Internet: 172631712 Equivalent to 10 /8s, 74 /16s and 38 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18661 Total AfriNIC prefixes after maximum aggregation: 3971 AfriNIC Deaggregation factor: 4.70 Prefixes being announced from the AfriNIC address blocks: 21442 Unique aggregates announced from the AfriNIC address blocks: 7656 AfriNIC Region origin ASes present in the Internet Routing Table: 1143 AfriNIC Prefixes per ASN: 18.76 AfriNIC Region origin ASes announcing only one prefix: 380 AfriNIC Region transit ASes present in the Internet Routing Table: 233 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 421 Number of AfriNIC addresses announced to Internet: 98415872 Equivalent to 5 /8s, 221 /16s and 181 /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 5404 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4406 419 433 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2908 11137 790 KIXS-AS-KR Korea Telecom, KR 7552 2871 1154 73 VIETEL-AS-AP Viettel Group, VN 9829 2812 1498 543 BSNL-NIB National Internet Backbone, IN 9394 2544 4923 26 CTTNET China TieTong Telecommunications 45899 2491 1574 160 VNPT-AS-VN VNPT Corp, VN 17974 2219 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2203 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2104 417 206 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3431 1324 85 SHAW - Shaw Communications Inc., CA 22773 3299 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 11492 2183 245 410 CABLEONE - CABLE ONE, INC., US 18566 2172 405 109 MEGAPATH5-US - MegaPath Corporation, US 16509 2124 4705 668 AMAZON-02 - Amazon.com, Inc., US 20115 2106 2530 456 CHARTER-NET-HKY-NC - Charter Communicat 30036 1989 342 157 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1986 5070 607 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 1838 908 1313 AKAMAI-AS - Akamai Technologies, Inc., 7018 1723 20216 1264 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4206 1518 532 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 2869 377 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2626 687 1925 AKAMAI-ASN1, US 12389 2068 1877 707 ROSTELECOM-AS, RU 34984 2010 334 491 TELLCOM-AS, TR 9121 1889 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1240 544 14 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 4895 3350 592 Uninet S.A. de C.V., MX 10620 3602 542 236 Telmex Colombia S.A., CO 11830 2649 369 77 Instituto Costarricense de Electricidad 6503 1616 438 58 Axtel, S.A.B. de C.V., MX 7303 1517 1026 191 Telecom Argentina S.A., AR 28573 1031 2253 173 CLARO S.A., BR 3816 1009 505 124 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 989 377 31 Telefonica del Peru S.A.A., PE 11172 926 126 85 Alestra, S. de R.L. de C.V., MX 18881 911 1078 30 TELEF�NICA BRASIL S.A, BR 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 1069 396 45 LINKdotNET-AS, EG 37611 854 107 9 Afrihost, ZA 36903 739 371 140 MT-MPLS, MA 36992 705 1412 43 ETISALAT-MISR, EG 8452 688 1730 17 TE-AS TE-AS, EG 24835 566 786 17 RAYA-AS, EG 37492 465 470 57 ORANGE-, TN 29571 441 68 10 ORANGE-COTE-IVOIRE, CI 37342 378 32 1 MOVITEL, MZ 15399 367 35 7 WANANCHI-, KE 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 5404 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4895 3350 592 Uninet S.A. de C.V., MX 7545 4406 419 433 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4206 1518 532 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3602 542 236 Telmex Colombia S.A., CO 6327 3431 1324 85 SHAW - Shaw Communications Inc., CA 22773 3299 2968 147 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2908 11137 790 KIXS-AS-KR Korea Telecom, KR 7552 2871 1154 73 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 8151 4895 4303 Uninet S.A. de C.V., MX 7545 4406 3973 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4206 3674 UNI2-AS, ES 10620 3602 3366 Telmex Colombia S.A., CO 6327 3431 3346 SHAW - Shaw Communications Inc., CA 22773 3299 3152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2869 2826 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2871 2798 VIETEL-AS-AP Viettel Group, VN 11830 2649 2572 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 64514 PRIVATE 5.42.231.0/24 35753 ITC ITC AS number, SA 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 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.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:37 /11:100 /12:290 /13:566 /14:1093 /15:1904 /16:13375 /17:7900 /18:13645 /19:25191 /20:39380 /21:45456 /22:87378 /23:70654 /24:392642 /25:847 /26:644 /27:644 /28:36 /29:20 /30:18 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3218 3431 SHAW - Shaw Communications Inc., CA 12479 2990 4206 UNI2-AS, ES 39891 2946 3778 ALJAWWALSTC-AS, SA 22773 2554 3299 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2331 2869 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2065 2172 MEGAPATH5-US - MegaPath Corporation, US 11830 1997 2649 Instituto Costarricense de Electricidad y Telec 11492 1926 2183 CABLEONE - CABLE ONE, INC., US 30036 1740 1989 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1613 3602 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1588 2:849 4:19 5:2810 6:65 7:1 8:1126 12:1861 13:189 14:1743 15:28 16:3 17:206 18:66 20:49 21:6 23:2658 24:2227 25:2 27:2349 31:1982 32:90 35:27 36:509 37:2752 38:1466 39:262 40:121 41:3187 42:588 43:1923 44:119 45:4613 46:3049 47:199 49:1322 50:1055 51:314 52:1041 54:369 55:3 56:12 57:41 58:1603 59:994 60:432 61:2162 62:1831 63:1800 64:5036 65:2220 66:4707 67:2439 68:1162 69:3199 70:1143 71:566 72:2112 74:2734 75:414 76:453 77:1542 78:1704 79:1837 80:1505 81:1394 82:1073 83:783 84:1043 85:2048 86:578 87:1333 88:930 89:2356 90:212 91:6367 92:1200 93:2365 94:2393 95:2818 96:721 97:357 98:947 99:133 100:81 101:1282 102:60 103:17764 104:3632 105:246 106:618 107:1891 108:699 109:3481 110:1628 111:1778 112:1266 113:1258 114:1120 115:1643 116:1649 117:1730 118:2156 119:1647 120:980 121:1051 122:2440 123:1801 124:1433 125:1902 128:1021 129:649 130:453 131:1587 132:660 133:195 134:1025 135:224 136:474 137:547 138:1969 139:597 140:407 141:706 142:818 143:993 144:802 145:465 146:1190 147:717 148:1635 149:733 150:728 151:1059 152:781 153:312 154:1100 155:760 156:963 157:790 158:650 159:1741 160:945 161:764 162:2586 163:564 164:1052 165:1603 166:455 167:1406 168:3078 169:805 170:3711 171:436 172:1065 173:1985 174:906 175:774 176:1891 177:4043 178:2454 179:1209 180:2213 181:2232 182:2361 183:1166 184:1029 185:13559 186:3559 187:2376 188:2832 189:2047 190:8120 191:1437 192:9842 193:5958 194:4789 195:3974 196:2555 197:1493 198:5522 199:5920 200:7377 201:5017 202:10456 203:10217 204:4571 205:2902 206:3106 207:3197 208:4006 209:3952 210:4042 211:2112 212:3043 213:2735 214:970 215:61 216:5960 217:2127 218:908 219:613 220:1760 221:986 222:1027 223:1259 End of report From nik at neko.id.au Fri May 25 18:59:03 2018 From: nik at neko.id.au (Nikolas Geyer) Date: Fri, 25 May 2018 18:59:03 +0000 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: References: Message-ID: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> Greetings! Actually, what you have provided below shows the exact opposite. It shows ColoAU have received the route from 4637 who have received it from 3257 who have received it from 29909 who have received it from 16532 who originated it. It infers nothing about who 16532 found the route to come from. It is evident that GTT are advertising that route to Telstra Global :) Regards, Nik. > > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as they're not the one advertising those routes to AS4637 > > AS16532 found it to come from AS4637 as you can see from this ColoAU LG output below > > > ----- https://lg.coloau.com.au/ > > vrf-international.inet.0: 696533 destinations, 2248101 routes (696249 active, 0 holddown, 103835 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from 103.97.52.2 > AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified > > -- > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > From ben at 6by7.net Fri May 25 19:56:56 2018 From: ben at 6by7.net (Ben Cannon) Date: Fri, 25 May 2018 12:56:56 -0700 Subject: IP Reputation In-Reply-To: <571778019.1519.1527266157407.JavaMail.mhammett@ThunderFuck> References: <571778019.1519.1527266157407.JavaMail.mhammett@ThunderFuck> Message-ID: With the horse trading of post-ipv4 depletion, we almost need a reg for this. -Ben > On May 25, 2018, at 9:36 AM, Mike Hammett wrote: > > I would like to call on organizations that provide IP reputation information to have methods available for network operators to determine if they are on their lists, what their reputation is, what it means, optionally evidence, and a means of removal of negative information. Near real-time notice of changes in your status would be recommended as well. If those wants sound ridiculous, nearly that same list of wants is provided by e-mail SPAM DNSRBL maintainers so it isn't exactly unprecedented. > > I recently interacted with an organization that provides IP reputation information as a component in a larger security offering. A particular eyeball network couldn't get to a number of large web destinations. After some prodding of the company providing the security offering, it was determined that the prefix in question was because on a scale of 0 to 10 with 0 being the best and 10 being the worst, that prefix had a score of 1. They claimed they could do nothing about it as their client (the web site being visited) had that in their control. That's a half-truth. The company providing that IP reputation put them on the list (for whatever reason), while the web site chose whatever metrics to block. > > > Their proposed solution was to contact every web site there were issues with and request that they fix it. Okay, so an eyeball is supposed to reach out to dozens of major brands and get someone that understands the situation and can resolve it in a reasonable time frame? Most of these brands take days to address core things dealing with their core product or service, much less getting someone in IT to whitelist a prefix. I'm sorry, that's not a realistic solution. > > If not a proactive alert (like a SPAM feedback loop), they need an easy form to fill out and after some automated means of verification (ASN or IP whois contact lookup), spill the beans on who, what, where, why, and how to get it fixed. > > I'm not saying there was no valid reason to put them on the list. There's no easy way to determine that they're on the list, why, and any means of getting removed from the list when the problem is fixed. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > From michael at wi-fiber.io Fri May 25 20:41:26 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 25 May 2018 14:41:26 -0600 Subject: IP Reputation In-Reply-To: References: <571778019.1519.1527266157407.JavaMail.mhammett@ThunderFuck> Message-ID: Not just horse trading, but underhanded businesses practices where a well known "grey services" or vpn provider will rent out their IPv4s at low low cost to force new/small ISPs into taking these IPv4s, cleaning them up(deblacklisting and deVPN block), and releasing them back to the services to effectively drag back through the mud. On 25 May 2018 at 13:56, Ben Cannon wrote: > With the horse trading of post-ipv4 depletion, we almost need a reg for > this. > > -Ben > > > On May 25, 2018, at 9:36 AM, Mike Hammett wrote: > > > > I would like to call on organizations that provide IP reputation > information to have methods available for network operators to determine if > they are on their lists, what their reputation is, what it means, > optionally evidence, and a means of removal of negative information. Near > real-time notice of changes in your status would be recommended as well. If > those wants sound ridiculous, nearly that same list of wants is provided by > e-mail SPAM DNSRBL maintainers so it isn't exactly unprecedented. > > > > I recently interacted with an organization that provides IP reputation > information as a component in a larger security offering. A particular > eyeball network couldn't get to a number of large web destinations. After > some prodding of the company providing the security offering, it was > determined that the prefix in question was because on a scale of 0 to 10 > with 0 being the best and 10 being the worst, that prefix had a score of 1. > They claimed they could do nothing about it as their client (the web site > being visited) had that in their control. That's a half-truth. The company > providing that IP reputation put them on the list (for whatever reason), > while the web site chose whatever metrics to block. > > > > > > Their proposed solution was to contact every web site there were issues > with and request that they fix it. Okay, so an eyeball is supposed to reach > out to dozens of major brands and get someone that understands the > situation and can resolve it in a reasonable time frame? Most of these > brands take days to address core things dealing with their core product or > service, much less getting someone in IT to whitelist a prefix. I'm sorry, > that's not a realistic solution. > > > > If not a proactive alert (like a SPAM feedback loop), they need an easy > form to fill out and after some automated means of verification (ASN or IP > whois contact lookup), spill the beans on who, what, where, why, and how to > get it fixed. > > > > I'm not saying there was no valid reason to put them on the list. > There's no easy way to determine that they're on the list, why, and any > means of getting removed from the list when the problem is fixed. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > From tom at cloudflare.com Fri May 25 22:00:55 2018 From: tom at cloudflare.com (Tom Paseka) Date: Fri, 25 May 2018 15:00:55 -0700 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> Message-ID: This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. Bouncing your session with 4637 would likely clear this. -Tom On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer wrote: > Greetings! > > Actually, what you have provided below shows the exact opposite. It shows > ColoAU have received the route from 4637 who have received it from 3257 who > have received it from 29909 who have received it from 16532 who originated > it. It infers nothing about who 16532 found the route to come from. > > It is evident that GTT are advertising that route to Telstra Global :) > > Regards, > Nik. > > > > > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as > they're not the one advertising those routes to AS4637 > > > > AS16532 found it to come from AS4637 as you can see from this ColoAU > LG output below > > > > > > ----- https://lg.coloau.com.au/ > > > > vrf-international.inet.0: 696533 destinations, 2248101 routes (696249 > active, 0 holddown, 103835 hidden) > > + = Active Route, - = Last Active, * = Both > > > > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from > 103.97.52.2 > > AS path: 4637 3257 29909 16532 16532 16532 16532 > I, validation-state: unverified > > > > -- > > ----- > > Alain Hebert ahebert at pubnix.net > > PubNIX Inc. > > 50 boul. St-Charles > > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > > From sethm at rollernet.us Sat May 26 07:41:15 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 26 May 2018 09:41:15 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: On 5/24/18 4:21 PM, Anne P. Mitchell Esq. wrote: > Actually, GDPR specifically requires processors to include statements of compliance right in their contracts; we also strongly recommend that controllers insist on indemnification clauses in their contracts with processors, because if the processor screws up and there is a breach, the_controller_ can also be held liable, and the financial penalties in GDPR are very stiff. Good luck getting multiple millions worth of fines out of small businesses that never even touch a million a year in revenue, let alone the added expenses of trying to do all the crap GDPR thinks everyone can suddenly afford out of nowhere. ~Seth From lists at benappy.com Sat May 26 08:31:29 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Sat, 26 May 2018 10:31:29 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <9AB9FF22-B725-475C-B5B6-CA0708BE2931@isipp.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <9AB9FF22-B725-475C-B5B6-CA0708BE2931@isipp.com> Message-ID: > On 23 May 2018, at 19:12, Anne P. Mitchell Esq. wrote: > > > >> On May 23, 2018, at 11:05 AM, K. Scott Helms wrote: >> >> Yep, if you're doing a decent job around securing data then you don't have much to be worried about on that side of things. The problem for most companies is that GDPR isn't really a security law, it's a privacy law (and set of regulations). That's where it's hard because there are a limited number of ways you can, from the EU's standpoint, lawfully process someone's PII. Things like opting out and blanket agreements to use all of someone's data for any reason a company may want are specifically prohibited. Even companies that don't intentionally sell into the EU (or the UK) can find themselves dealing with this if they have customers with employees in the EU. > > Or if someone who is a U.S. citizen and resident goes to the org's U.S.-based website and orders something (or even just provides their PII)... but happens to be in a plane flying over an EU country at the time. Because GDPR doesn't talk about residence or citizenship, it talks only about a vague and ambiguous "in the Union", and I can certainly envision an argument in which the person in the plane claims that they were, technically, "in the Union" at the time. > Actually, the EU Commission is pretty clear about the non-E.U. person travelling to E.U. and using a service not specifically targetting E.U. users : "When the regulation does not apply Your company is service provider based outside the EU. It provides services to customers outside the EU. Its clients can use its services when they travel to other countries, including within the EU. Provided your company doesn't specifically target its services at individuals in the EU, it is not subject to the rules of the GDPR.” https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en There are many other examples on their website which leave pretty little doubts about when it applies and when it does not. Regards, Michel From nick at foobar.org Sat May 26 09:26:34 2018 From: nick at foobar.org (Nick Hilliard) Date: Sat, 26 May 2018 10:26:34 +0100 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: <16d60208-0377-ddbd-7971-917667057c50@foobar.org> Seth Mattinen wrote on 26/05/2018 08:41: > Good luck getting multiple millions worth of fines out of small > businesses that never even touch a million a year in revenue, let alone > the added expenses of trying to do all the crap GDPR thinks everyone can > suddenly afford out of nowhere. You can put the straw man away - Europe isn't the US. No Data Protection Authority in Europe is going to sue a mom & pop business in the US for millions because they haven't clarified their cookies policy. The upper limits of the fines are aimed at the robber barons of the world. The DPAs in Europe are for the most part lawsuit-averse and engage with companies to build alignment rather than taking the punitive approach and liberally dishing out lawsuits and fines. The emphasis on GDPR compliance is aiming at reasonable steps rather than pretending that every organisation is going to end up redesigning their entire existence around GDPR on may 25. Nick From jordi.palet at consulintel.es Sat May 26 11:24:00 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 26 May 2018 13:24:00 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <9AB9FF22-B725-475C-B5B6-CA0708BE2931@isipp.com> Message-ID: <1D6873C2-DD9F-4FE2-8D80-117F59A0E86F@consulintel.es> However, if an EU citizen or resident uses the services of those companies, they are bound to comply with the GDPR. So, if you target your services to people outside the EU, you must have a way to DENY that anyone in the EU register to your services, or even sent a request via a form in your web, etc. I don't think that's so easy as to make 100% proof ... and maybe the cost of complying the GDPR is even cheaper/easier and you open your services to the EU as well (or EU people, for example, visiting US). Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Michel 'ic' Luczak Fecha: sábado, 26 de mayo de 2018, 10:34 Para: "Anne P. Mitchell Esq." CC: "Gary T. Giesen via NANOG" Asunto: Re: Whois vs GDPR, latest news > On 23 May 2018, at 19:12, Anne P. Mitchell Esq. wrote: > > > >> On May 23, 2018, at 11:05 AM, K. Scott Helms wrote: >> >> Yep, if you're doing a decent job around securing data then you don't have much to be worried about on that side of things. The problem for most companies is that GDPR isn't really a security law, it's a privacy law (and set of regulations). That's where it's hard because there are a limited number of ways you can, from the EU's standpoint, lawfully process someone's PII. Things like opting out and blanket agreements to use all of someone's data for any reason a company may want are specifically prohibited. Even companies that don't intentionally sell into the EU (or the UK) can find themselves dealing with this if they have customers with employees in the EU. > > Or if someone who is a U.S. citizen and resident goes to the org's U.S.-based website and orders something (or even just provides their PII)... but happens to be in a plane flying over an EU country at the time. Because GDPR doesn't talk about residence or citizenship, it talks only about a vague and ambiguous "in the Union", and I can certainly envision an argument in which the person in the plane claims that they were, technically, "in the Union" at the time. > Actually, the EU Commission is pretty clear about the non-E.U. person travelling to E.U. and using a service not specifically targetting E.U. users : "When the regulation does not apply Your company is service provider based outside the EU. It provides services to customers outside the EU. Its clients can use its services when they travel to other countries, including within the EU. Provided your company doesn't specifically target its services at individuals in the EU, it is not subject to the rules of the GDPR.” https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en There are many other examples on their website which leave pretty little doubts about when it applies and when it does not. Regards, Michel ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Sat May 26 11:30:45 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 26 May 2018 13:30:45 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <16d60208-0377-ddbd-7971-917667057c50@foobar.org> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> Message-ID: <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> I don't think, in general the DPAs need to use lawsuits. If they discover (by their own, or by means of a customer claim) that a company (never mind is from the EU or outside) is not following the GDPR, they will just fine it and the corresponding government authorities are the responsible to cash the fine, even with "bank account embargos". If the company is outside the EU, but there are agreements with that country, they can proceed to that via the third country authorities. Same as when you don't pay a traffic fine in the EU and you are from non-EU countries (some allow the embargo, others not). This has been happening, in most of the EU countries for a while. In recent months, the Spanish DPA has ordered fines of 600.000 euros (with the previous law, LOPD), to companies such as Facebook, Google, Whatsapp, and many others ... Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Nick Hilliard Fecha: sábado, 26 de mayo de 2018, 11:29 Para: Seth Mattinen CC: Asunto: Re: Whois vs GDPR, latest news Seth Mattinen wrote on 26/05/2018 08:41: > Good luck getting multiple millions worth of fines out of small > businesses that never even touch a million a year in revenue, let alone > the added expenses of trying to do all the crap GDPR thinks everyone can > suddenly afford out of nowhere. You can put the straw man away - Europe isn't the US. No Data Protection Authority in Europe is going to sue a mom & pop business in the US for millions because they haven't clarified their cookies policy. The upper limits of the fines are aimed at the robber barons of the world. The DPAs in Europe are for the most part lawsuit-averse and engage with companies to build alignment rather than taking the punitive approach and liberally dishing out lawsuits and fines. The emphasis on GDPR compliance is aiming at reasonable steps rather than pretending that every organisation is going to end up redesigning their entire existence around GDPR on may 25. Nick ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From sethm at rollernet.us Sat May 26 13:57:17 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 26 May 2018 15:57:17 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> Message-ID: On 5/26/18 1:30 PM, JORDI PALET MARTINEZ via NANOG wrote: > I don't think, in general the DPAs need to use lawsuits. > > If they discover (by their own, or by means of a customer claim) that a company (never mind is from the EU or outside) is not following the GDPR, they will just fine it and the corresponding government authorities are the responsible to cash the fine, even with "bank account embargos". If the company is outside the EU, but there are agreements with that country, they can proceed to that via the third country authorities. If someone were to show up and issue me a 10 or 20 million euro fine (more in USD), I'd just laugh since I'll never see that much money at one time in my whole life. I'm not convinced they will limit reach to the Facebooks and Googles of the world until a lower limit is codified. I suspect that won't happen until enough small guys are fined 10-20 million euros who could never hope to repay it in a lifetime. ~Seth From baldur.norddahl at gmail.com Sat May 26 16:14:17 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 26 May 2018 18:14:17 +0200 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: Add a static default route on both routers. This will be invalidated as soon the interface goes down. Should be faster than relying on the BGP process on withdrawing the route. Also does not require any config changes at your upstreams. Regards Baldur ons. 16. maj 2018 18.52 skrev Adam Kajtar : > Erich, > > Good Idea. I can't believe I didn't think of that earlier. Simple and > effective. I will go ahead and request the defaults from my ISP and update > the thread of the findings. > > Thanks! > > On Wed, May 16, 2018 at 10:03 AM Kaiser, Erich > wrote: > > > A last resort route (default route) could still be good to take from your > > ISP(s) even if you still do full routes, as the propagation is happening > on > > the internet side, you should at least have a path inbound through the > > other provider. The default route at least would send the traffic out if > > it does not see the route locally. Just an idea. > > > > > > > > On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar > > wrote: > > > > > I could use static routes but I noticed since I moved to full routes I > > > have had a lot fewer customer complaints about latency(especially when > it > > > comes to Voice and VPN traffic). > > > > > > I wasn't using per-packet load balancing. I believe juniper default is > > per > > > IP. > > > > > > My timers are as follows > > > Active Holdtime: 90 > > > Keepalive Interval: 30 > > > > > > Would I be correct in thinking I need to contact my ISP to lower these > > > values? > > > > > > An interesting note is when I had both ISPs connected into a single > MX104 > > > the failover was just a few seconds. > > > > > > Thanks again. > > > > > > > > > > > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > > > > > >> Have you checked your timeouts ? > > >> > > >> -Ben > > >> > > >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich > > wrote: > > >> > > > >> > Do you need full routes? What about just a default route from BGP? > > >> > > > >> > Erich Kaiser > > >> > The Fusion Network > > >> > erich at gotfusion.net > > >> > Office: 815-570-3101 > > >> > > > >> > > > >> > > > >> > > > >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould > > wrote: > > >> >> > > >> >> You sure it doesn't have something to do with 60 seconds * 3 = 180 > > >> secs of > > >> >> BGP neighbor Time out before it believes neighbor is dead and > remove > > >> routes > > >> >> to that neighbor? > > >> >> > > >> >> Aaron > > >> >> > > >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar < > akajtar at wadsworthcity.org > > > > > >> >> wrote: > > >> >>> > > >> >>> Hello: > > >> >>> > > >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected > running > > >> >>> BGP(full routes). iBGP is running between the routers via a two > port > > >> 20G > > >> >>> lag. When one of the ISPs fails, it can take upwards of 2 minutes > > for > > >> >>> traffic to start flowing correctly. The router has the correct > route > > >> in > > >> >> the > > >> >>> routing table, but it doesn't install it in the forwarding table > for > > >> the > > >> >>> full two mins. > > >> >>> > > >> >>> I have a few questions if anyone could answer them. > > >> >>> > > >> >>> - What would a usual convergence time be for this setup? > > >> >>> - Is there anything I could do speed this process up? (I tried > > >> >> Multipath) > > >> >>> - Any tips and tricks would be much appreciated > > >> >>> > > >> >>> Thanks in Advance > > >> >>> -- > > >> >>> Adam Kajtar > > >> >>> Systems Administrator > > >> >>> City of Wadsworth > > >> >>> akajtar at wadsworthcity.org > > >> >>> ----------------------------------------------------- > > >> >>> http://www.wadsworthcity.com > > >> >>> > > >> >>> Facebook * |* Twitter > > >> >>> *|* Instagram > > >> >>> *|* YouTube > > >> >>> > > >> >> > > >> >> > > >> > > > > > > > > > -- > > > Adam Kajtar > > > Systems Administrator, Safety Services > > > City of Wadsworth > > > Office 330.335.2865 > > > Cell 330.485.6510 > > > akajtar at wadsworthcity.org > > > ----------------------------------------------------- > > > http://www.wadsworthcity.com > > > > > > Facebook * |* Twitter > > > *|* Instagram > > > *|* YouTube > > > > > > > > > > > -- > Adam Kajtar > Systems Administrator, Safety Services > City of Wadsworth > Office 330.335.2865 > Cell 330.485.6510 > akajtar at wadsworthcity.org > ----------------------------------------------------- > http://www.wadsworthcity.com > > Facebook * |* Twitter > *|* Instagram > *|* YouTube > > From jordi.palet at consulintel.es Sat May 26 16:29:22 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 26 May 2018 18:29:22 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> Message-ID: <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> I don't recall right now the exact details about how they calculate the fine, which is appropriate for each case, but the 4% of turnover or 20 million Euros is just the maximum amount (per case). I'm sure there is something already documented, about that, or may be is each country DPA the one responsible to define the exact fine for each case. For example, up to now (with the previous law, LOPD for Spain), the maximum fine was 600.000 euros, and the "starting" fine was 1.500 euros. So, depending on the number of people affected, the degree of infringement, if it is the first time or if the company has been warned or fined before, you can get a fine in the "middle" of those figures. I'm sure it will be the same way for the GDPR. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Seth Mattinen Fecha: sábado, 26 de mayo de 2018, 16:00 Para: Asunto: Re: Whois vs GDPR, latest news On 5/26/18 1:30 PM, JORDI PALET MARTINEZ via NANOG wrote: > I don't think, in general the DPAs need to use lawsuits. > > If they discover (by their own, or by means of a customer claim) that a company (never mind is from the EU or outside) is not following the GDPR, they will just fine it and the corresponding government authorities are the responsible to cash the fine, even with "bank account embargos". If the company is outside the EU, but there are agreements with that country, they can proceed to that via the third country authorities. If someone were to show up and issue me a 10 or 20 million euro fine (more in USD), I'd just laugh since I'll never see that much money at one time in my whole life. I'm not convinced they will limit reach to the Facebooks and Googles of the world until a lower limit is codified. I suspect that won't happen until enough small guys are fined 10-20 million euros who could never hope to repay it in a lifetime. ~Seth ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From owen at delong.com Sat May 26 17:29:42 2018 From: owen at delong.com (Owen DeLong) Date: Sat, 26 May 2018 10:29:42 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> Message-ID: I’m not sure that’s true. I think that the notice is sufficient to indicate that I have no intention to have EU persons visiting my web site and thus should not be subject to their extraterritorial overreach. Obviously time will tell what happens. Owen > On May 26, 2018, at 09:29 , JORDI PALET MARTINEZ via NANOG wrote: > > I don't recall right now the exact details about how they calculate the fine, which is appropriate for each case, but the 4% of turnover or 20 million Euros is just the maximum amount (per case). I'm sure there is something already documented, about that, or may be is each country DPA the one responsible to define the exact fine for each case. > > For example, up to now (with the previous law, LOPD for Spain), the maximum fine was 600.000 euros, and the "starting" fine was 1.500 euros. So, depending on the number of people affected, the degree of infringement, if it is the first time or if the company has been warned or fined before, you can get a fine in the "middle" of those figures. > > I'm sure it will be the same way for the GDPR. > > Regards, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Seth Mattinen > Fecha: sábado, 26 de mayo de 2018, 16:00 > Para: > Asunto: Re: Whois vs GDPR, latest news > > > > On 5/26/18 1:30 PM, JORDI PALET MARTINEZ via NANOG wrote: >> I don't think, in general the DPAs need to use lawsuits. >> >> If they discover (by their own, or by means of a customer claim) that a company (never mind is from the EU or outside) is not following the GDPR, they will just fine it and the corresponding government authorities are the responsible to cash the fine, even with "bank account embargos". If the company is outside the EU, but there are agreements with that country, they can proceed to that via the third country authorities. > > > If someone were to show up and issue me a 10 or 20 million euro fine > (more in USD), I'd just laugh since I'll never see that much money at > one time in my whole life. > > I'm not convinced they will limit reach to the Facebooks and Googles of > the world until a lower limit is codified. I suspect that won't happen > until enough small guys are fined 10-20 million euros who could never > hope to repay it in a lifetime. > > ~Seth > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > From rob at invaluement.com Sat May 26 17:37:47 2018 From: rob at invaluement.com (Rob McEwen) Date: Sat, 26 May 2018 13:37:47 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> Message-ID: <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> On 5/26/2018 12:29 PM, JORDI PALET MARTINEZ via NANOG wrote: > I don't recall right now the exact details about how they calculate the fine The *MINIMUM* fine is 10M euros. SEE: https://www.gdpreu.org/compliance/fines-and-penalties/ This is true no matter how small the business, and (potentially) even if there was just one minor incident. And the law is so vague and expansive - and with such massive minimum fines - that I wonder if this might be exploited to target political rivals/enemies? Or those who donate to such? It certainly could easily be weaponized! And before it even gets nearly to that point, it could also turn into the equivalent of the tiny city of Waldo, Florida (USA) (population 1K)... who turned their police force into a speeding-ticket revenue factory for some time before the State of FL shut them down. Certainly, the Euro bureaucrats are incentivized. -- Rob McEwen https://www.invaluement.com From lists at benappy.com Sat May 26 18:15:28 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Sat, 26 May 2018 20:15:28 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> Message-ID: <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> > On 26 May 2018, at 19:37, Rob McEwen wrote: > > The *MINIMUM* fine is 10M euros. > > SEE: https://www.gdpreu.org/compliance/fines-and-penalties/ The two levels depend on the nature of the infringement, but it says clearly “up to 10M” (or 2% of your worldwide revenue, whichever is bigger) for the “less serious” infringements. So no, there is no minimum fine actually. From sethm at rollernet.us Sat May 26 18:28:08 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 26 May 2018 20:28:08 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> Message-ID: <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> On 5/26/18 8:15 PM, Michel 'ic' Luczak wrote: > The two levels depend on the nature of the infringement, but it says clearly “up to 10M” (or 2% of your worldwide revenue, whichever is bigger) for the “less serious” infringements. So no, there is no minimum fine actually. To me that says the fine is 10M if your 2% is lower than 10M. Or it wasn't originally written in English and the translation is flawed. From lists at benappy.com Sat May 26 18:36:15 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Sat, 26 May 2018 20:36:15 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> Message-ID: <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> > On 26 May 2018, at 20:28, Seth Mattinen wrote: > > > > On 5/26/18 8:15 PM, Michel 'ic' Luczak wrote: >> The two levels depend on the nature of the infringement, but it says clearly “up to 10M” (or 2% of your worldwide revenue, whichever is bigger) for the “less serious” infringements. So no, there is no minimum fine actually. > > > To me that says the fine is 10M if your 2% is lower than 10M. Or it wasn't originally written in English and the translation is flawed. Original text from EU Commission: "Infringements of the following provisions shall, in accordance with paragraph 2, be subject to administrative fines up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher” -> Administrative fines _up to_ 10M (or 2% if your 2% is higher than 10M). It’s a cap, not a minimum. From rob at invaluement.com Sat May 26 19:04:55 2018 From: rob at invaluement.com (Rob McEwen) Date: Sat, 26 May 2018 15:04:55 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> References: <20180523155314.50F5427017BC@ary.qy> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> Message-ID: On 5/26/2018 2:36 PM, Michel 'ic' Luczak wrote: > Original text from EU Commission: > "Infringements of the following provisions shall, in accordance with paragraph 2, be subject to administrative fines up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher” > > -> Administrative fines_up to_ 10M (or 2% if your 2% is higher than 10M). > > It’s a cap, not a minimum. Thanks for the clarification. But whether that fine will be less than 10M is extremely vague and (I guess?) left up to the opinions or whims of a Euro bureaucrat or judge panel, or something like that... based on very vague and subjective criteria. I've searched and nobody can seem to find any more specifics or assurances. Therefore, there is NOTHING that a very small business with a very small data breach or mistake, could point to... to give them confidence than their fine will be any less than 10M Euros, other than that "up to" wording - that is in the same sentence where it also clarifies "whichever is larger". All these people in this discussion who are expressing opinions that penalties in such situations won't be nearly so bad - are expressing what may very with be "wishful thinking" that isn't rooted in reality. -- Rob McEwen https://www.invaluement.com From fw at deneb.enyo.de Sat May 26 19:14:16 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 May 2018 21:14:16 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <80CD0E33-5DC0-4724-A4A3-A9E71C709EC8@isc.org> (Mark Andrews's message of "Wed, 23 May 2018 13:21:51 +1000") References: <20180523015019.26B6326FB73E@ary.qy> <9BD67E20-CBEE-44AF-8AAD-5B1E9FEC6794@bowenvale.co.nz> <80CD0E33-5DC0-4724-A4A3-A9E71C709EC8@isc.org> Message-ID: <87tvquz0tz.fsf@mid.deneb.enyo.de> * Mark Andrews: > Domain whois is absolutely useful. Try contacting a site to report > that their nameservers are hosed without it. A lot of WHOIS servers do not show who's running the name servers, or who maintains the data served by them. Those that do usually provide information which is provably wrong. > Remember that about 50% of zones have not RFC compliant name servers > (the software is broken) and that newer resolver depend on default > behaviour working correctly. If WHOIS records were useful for contacting operators, you wouldn't have to raise these issues on public lists periodically. From jordi.palet at consulintel.es Sat May 26 19:36:48 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 26 May 2018 21:36:48 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> Message-ID: Talking from the experience because the previous laws in Spain, LOPD and LSSI (which basically was the same across the different EU countries). They had "maximum" fines (it was 600.000 Euros). They start for small law infringement with 600 euros, 1.500 euros, unless is something very severe, then it come to something like 30.000 euros, etc. If you keep repeating the law infringement, then the 2nd time it may become 150.000 Euros. If it is massive infringement (for example massive spam), then it comes to 300.000 or even 600.000 euros. Here there is an explanation for the LOPD fines, is in Spanish, but a translator should work: http://www.cuidatusdatos.com/infracciones/ My guess is that the GDPR maximum fines are there just as maximum, and there will be agreements among the EU DPAs, to better define how much is the fine, in a similar way they are doing now. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Rob McEwen Fecha: sábado, 26 de mayo de 2018, 21:06 Para: Asunto: Re: Whois vs GDPR, latest news On 5/26/2018 2:36 PM, Michel 'ic' Luczak wrote: > Original text from EU Commission: > "Infringements of the following provisions shall, in accordance with paragraph 2, be subject to administrative fines up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher” > > -> Administrative fines_up to_ 10M (or 2% if your 2% is higher than 10M). > > It’s a cap, not a minimum. Thanks for the clarification. But whether that fine will be less than 10M is extremely vague and (I guess?) left up to the opinions or whims of a Euro bureaucrat or judge panel, or something like that... based on very vague and subjective criteria. I've searched and nobody can seem to find any more specifics or assurances. Therefore, there is NOTHING that a very small business with a very small data breach or mistake, could point to... to give them confidence than their fine will be any less than 10M Euros, other than that "up to" wording - that is in the same sentence where it also clarifies "whichever is larger". All these people in this discussion who are expressing opinions that penalties in such situations won't be nearly so bad - are expressing what may very with be "wishful thinking" that isn't rooted in reality. -- Rob McEwen https://www.invaluement.com ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From rob at invaluement.com Sat May 26 22:13:38 2018 From: rob at invaluement.com (Rob McEwen) Date: Sat, 26 May 2018 18:13:38 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> Message-ID: On 5/26/2018 3:36 PM, JORDI PALET MARTINEZ via NANOG wrote: > Talking from the experience because the previous laws in Spain, LOPD and LSSI Jordi, LOPD/LSSI does not = GDPR But even if there was a probability that GDPR would operate like they do: (1) it is alarming that the fines mentioned on GDPR are 10-20X higher than even LOPD/LSSI's higher fines -AND- regarding LOPD/LSSI's relatively low minimum fine of 600 EUROs that you mentioned - it was explicated mentioned on the page you referenced - HOWEVER there is NOT any similar official (relatively) low-cost fines mentioned for GDPR anywhere.... there is only that NOT-reassuring "up to" phrase. For someone hit with a GDPR fine, I don't think telling them, "JORDI PALET MARTINEZ claimed that the fine will be more reasonable for a smaller business that had a less egregious offense" - is going to necessarily make it so. Believe me, I WANT you to be my GDPR fairy. I really really do. But I have to operate my business more realistically. -- Rob McEwen https://www.invaluement.com From valdis.kletnieks at vt.edu Sat May 26 22:38:48 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 26 May 2018 18:38:48 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <9AB9FF22-B725-475C-B5B6-CA0708BE2931@isipp.com> Message-ID: <230722.1527374328@turing-police.cc.vt.edu> On Sat, 26 May 2018 10:31:29 +0200, "Michel 'ic' Luczak" said: > "When the regulation does not apply > Your company is service provider based outside the EU. It provides services > to customers outside the EU. Its clients can use its services when they travel > to other countries, including within the EU. Provided your company doesn't > specifically target its services at individuals in the EU, it is not subject to > the rules of the GDPR.��� Now here's the big question - a *lot* of companies are targeting "anybody with a freemail account like GMail and a valid Visa or Mastercard card" or similar business models - does that count as "specifically targeting at EU", or not? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From goemon at sasami.anime.net Sun May 27 00:57:34 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Sat, 26 May 2018 17:57:34 -0700 (PDT) Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: On Sat, 26 May 2018, Seth Mattinen wrote: > On 5/24/18 4:21 PM, Anne P. Mitchell Esq. wrote: >> Actually, GDPR specifically requires processors to include statements of >> compliance right in their contracts; we also strongly recommend that >> controllers insist on indemnification clauses in their contracts with >> processors, because if the processor screws up and there is a breach, >> the_controller_ can also be held liable, and the financial penalties in >> GDPR are very stiff. > Good luck getting multiple millions worth of fines out of small businesses > that never even touch a million a year in revenue, let alone the added > expenses of trying to do all the crap GDPR thinks everyone can suddenly > afford out of nowhere. I imagine small businesses who do a small percentage of revenue to EU citizens will simply decide to do zero percentage of revenue to EU citizens. The risk is simply too great. -Dan From royce at techsolvency.com Sun May 27 01:42:46 2018 From: royce at techsolvency.com (Royce Williams) Date: Sat, 26 May 2018 17:42:46 -0800 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: On Sat, May 26, 2018 at 4:57 PM Dan Hollis wrote: > I imagine small businesses who do a small percentage of revenue to EU > citizens will simply decide to do zero percentage of revenue to EU > citizens. The risk is simply too great. That would be a shame. I would expect the level of effort to be roughly commensurate with A) the size of the org, and B) the risk inherent in what data is being collected, processed, stored, etc. I would also expect compliance to at least partially derive from vendor/cloud/outsource/whatever partners, many of whom should be scaled/scaling up to minimally comply. I would also not be surprised if laws of similar scope start to emerge in other countries. If so, taking your ball and going home won't be sustainable. If small, vulnerable orgs panic and can't realistically engage the risk, they may be selecting themselves out of the market - an "I encourage my competitors to do this" variant. Naively ... to counter potential panic, it would be awesome to crowdsource some kind of CC-licensed GDPR toolkit for small orgs. Something like a boilerplate privacy policy (perhaps generated by answers to questions), plus some simplified checklists, could go a long way - towards both compliance and actual security benefit. In a larger sense ... can any org - regardless of size - afford to not know their data, understand (at least at a high level) how it could be abused, know who is accessing it, manage it so that it can be verifiably purged, and enable their customers to self-manage their portion of it?? I'm personally a big fan of undue diligence and all, but we need to advocate for some ... realistic scaling of response. Royce From goemon at sasami.anime.net Sun May 27 02:04:47 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Sat, 26 May 2018 19:04:47 -0700 (PDT) Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: On Sat, 26 May 2018, Royce Williams wrote: > Naively ... to counter potential panic, it would be awesome to crowdsource > some kind of CC-licensed GDPR toolkit for small orgs. Something like a > boilerplate privacy policy (perhaps generated by answers to questions), > plus some simplified checklists, could go a long way - towards both > compliance and actual security benefit. who is willing to accept the risk of being involved in creation of such a thing? would you? if someone uses it and ends up being hit by eu regulators, you can bet the toolkit creators will be sued. who would be willing to use a crowdsourced legal toolkit given the risks of a violation? would you? -Dan From jordi.palet at consulintel.es Sun May 27 07:36:48 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 27 May 2018 09:36:48 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> Message-ID: <3FA609EA-7141-4996-9AB5-D0111A34E0BC@consulintel.es> I know that LOPD and LSSI is not the same as GDPR. However, each country in the EU need to modify its own LOPD in order to adapt it to the GDPR. *I've done some further reading and according to the 1st and 2nd paragraphs of GDPR Art. 83 each DPA will establish the fines, which should respect what is said in 4, 5 and 6 (including the maximum fines, so clearly 10 and 20 MEuros or 2% and 4% of the previous year turnover). So after that, I found what is going on and in the case of Spain, the council of Ministers approved the law 24th Nov. 2017 (http://www.congreso.es/docu/docum/ddocum/dosieres/sleg/legislatura_12/spl_13/pdfs/1.pdf) and it was expected to be sanctioned by the Parliament last week, after some discussion and some changes. However seems to be delayed as the parliament asked for some amendments. In this document, again, it is indicated that the DPA will follow what is being said in GDPR (see * above) and doesn't mention the amount of each fine, because "Each supervisory authority shall ensure that the imposition of administrative fines pursuant to this Article in respect of infringements of this Regulation referred to in paragraphs 4, 5 and 6 shall in each individual case be effective, proportionate and dissuasive." See also the text in p. 2 of the GDPR. This facilitates the DPAs to take in consideration *each* individual case, or even to change the fines in the future. However, the Spanish law, talks about some specific fine amounts in the article 78, referred to the prescription of the infringements depending on the fine amount. For example, for fines up to 40.000 Euros, 300.000 euros and over 300.000 euros. What that means? Each DPA have to modify the "actual" LOPD and associated tables of fines, and the GDPR only stablishes the maximum amounts. Other countries already have done that: Italy: LEGGE 20 novembre 2017, n. 167 Germany: Bundesdatenschutzgesetz France: looks like a similar situation as Spain So, for the countries that have not yet finalized the approval of the "new LOPD", the fines are still the same as the ones defined in the "actual LOPD". So, I think I was right in my assertion, and the minimum fines in Spain, will be for sure lower than 40.000 euros, and my guess is that will start as today with 600 or so ... at the end in will depend on the "individual decision" (based in a categorization table, which the Spanish DPA for sure has already prepared, but will not make public until the new LOPD is approved by the parliament). Of course I'm not saying that you should ignore the GDPR because the fines are low. I think everybody really need to adapt their data protection procedures to it. Regards, Jordi PD: An informal document that I've found say that the new fines are in the ranges of 900-40.000, 40.001-300.000 and 300.000-600.000. -----Mensaje original----- De: NANOG en nombre de Rob McEwen Fecha: domingo, 27 de mayo de 2018, 0:16 Para: Asunto: Re: Whois vs GDPR, latest news On 5/26/2018 3:36 PM, JORDI PALET MARTINEZ via NANOG wrote: > Talking from the experience because the previous laws in Spain, LOPD and LSSI Jordi, LOPD/LSSI does not = GDPR But even if there was a probability that GDPR would operate like they do: (1) it is alarming that the fines mentioned on GDPR are 10-20X higher than even LOPD/LSSI's higher fines -AND- regarding LOPD/LSSI's relatively low minimum fine of 600 EUROs that you mentioned - it was explicated mentioned on the page you referenced - HOWEVER there is NOT any similar official (relatively) low-cost fines mentioned for GDPR anywhere.... there is only that NOT-reassuring "up to" phrase. For someone hit with a GDPR fine, I don't think telling them, "JORDI PALET MARTINEZ claimed that the fine will be more reasonable for a smaller business that had a less egregious offense" - is going to necessarily make it so. Believe me, I WANT you to be my GDPR fairy. I really really do. But I have to operate my business more realistically. -- Rob McEwen https://www.invaluement.com ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From lists at benappy.com Sun May 27 09:19:56 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Sun, 27 May 2018 11:19:56 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> Message-ID: > On 26 May 2018, at 21:04, Rob McEwen wrote: > > Thanks for the clarification. But whether that fine will be less than 10M is extremely vague and (I guess?) left up to the opinions or whims of a Euro bureaucrat or judge panel, or something like that... based on very vague and subjective criteria. I've searched and nobody can seem to find any more specifics or assurances. Therefore, there is NOTHING that a very small business with a very small data breach or mistake, could point to... to give them confidence than their fine will be any less than 10M Euros, other than that "up to" wording - that is in the same sentence where it also clarifies "whichever is larger". > > All these people in this discussion who are expressing opinions that penalties in such situations won't be nearly so bad - are expressing what may very with be "wishful thinking" that isn't rooted in reality. Still on ec.europa.eu they seem to try to reassure SMEs that the penalties will be “proportionate” both to the nature of the infringement and to the size to the company. It also seem to largely be related to whether you infringed the regulation in good faith or not. At least in France where I live the climate is pro-SMEs so I guess small mistakes will be forgiven. The head of our DPA also gave an interview recently saying that there will be no sanctions in the coming months and that they’re available to answer questions when in doubt about what to do. Lastly, our law firm told us that basically we have to wait until the first settlements to see what will be done… Regards, Michel From sander at steffann.nl Sun May 27 12:47:53 2018 From: sander at steffann.nl (Sander Steffann) Date: Sun, 27 May 2018 14:47:53 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> Message-ID: <5C98FF15-2045-4D49-A8F8-D81AA4BB687D@steffann.nl> Hi, >> Thanks for the clarification. But whether that fine will be less than 10M is extremely vague and (I guess?) left up to the opinions or whims of a Euro bureaucrat or judge panel, or something like that... based on very vague and subjective criteria. I've searched and nobody can seem to find any more specifics or assurances. Therefore, there is NOTHING that a very small business with a very small data breach or mistake, could point to... to give them confidence than their fine will be any less than 10M Euros, other than that "up to" wording - that is in the same sentence where it also clarifies "whichever is larger". >> >> All these people in this discussion who are expressing opinions that penalties in such situations won't be nearly so bad - are expressing what may very with be "wishful thinking" that isn't rooted in reality. > > Still on ec.europa.eu they seem to try to reassure SMEs that the penalties will be “proportionate” both to the nature of the infringement and to the size to the company. It also seem to largely be related to whether you infringed the regulation in good faith or not. At least in France where I live the climate is pro-SMEs so I guess small mistakes will be forgiven. The head of our DPA also gave an interview recently saying that there will be no sanctions in the coming months and that they’re available to answer questions when in doubt about what to do. That is also what I see in the Netherlands. > Lastly, our law firm told us that basically we have to wait until the first settlements to see what will be done… True. Considering that GDPR is an EU regulation and that in general European culture is a lot less litigious than in the US I don't expect massive fines unless the infractions are malignant + persistent + performed by a large corporation. Smaller companies (or people) that make mistakes will not get fines that would bankrupt them. That's just not the way the justice system works on this side of the pond :) Cheers, Sander From owen at delong.com Sun May 27 19:41:36 2018 From: owen at delong.com (Owen DeLong) Date: Sun, 27 May 2018 12:41:36 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: > On May 26, 2018, at 18:42 , Royce Williams wrote: > > On Sat, May 26, 2018 at 4:57 PM Dan Hollis wrote: > >> I imagine small businesses who do a small percentage of revenue to EU >> citizens will simply decide to do zero percentage of revenue to EU >> citizens. The risk is simply too great. > > That would be a shame. I would expect the level of effort to be roughly > commensurate with A) the size of the org, and B) the risk inherent in what > data is being collected, processed, stored, etc. I would also expect > compliance to at least partially derive from > vendor/cloud/outsource/whatever partners, many of whom should be > scaled/scaling up to minimally comply. Here’s the problem… The way GDPR is written, if you want to collect (and store) so much as the IP address of the potential customer who visited your website, you need their informed consent and you can’t require that they consent as a condition of providing service. Basically, the regulation is so poorly written that it is utterly nonsensical and I wonder how business in Europe intend to function when they can’t make collecting someone’s address a condition of allowing them to order something online. > I would also not be surprised if laws of similar scope start to emerge in > other countries. If so, taking your ball and going home won't be > sustainable. If small, vulnerable orgs panic and can't realistically engage > the risk, they may be selecting themselves out of the market - an "I > encourage my competitors to do this" variant. Let’s hope that if enough businesses take their ball and go home, the EU and other regulators will wake up and smell the hydrogen-sulfide and write better laws. I’m not opposed to privacy protection, but GDPR contains way too much overreach and way too little logic or common sense. > Naively ... to counter potential panic, it would be awesome to crowdsource > some kind of CC-licensed GDPR toolkit for small orgs. Something like a > boilerplate privacy policy (perhaps generated by answers to questions), > plus some simplified checklists, could go a long way - towards both > compliance and actual security benefit. The first word does a pretty good job of describing the rest of that paragraph as mentioned by others. > In a larger sense ... can any org - regardless of size - afford to not know > their data, understand (at least at a high level) how it could be abused, > know who is accessing it, manage it so that it can be verifiably purged, > and enable their customers to self-manage their portion of it?? Yes. But even if an org does all of that, there are still significant problems with GDPR. Owen From niels=nanog at bakker.net Sun May 27 19:54:35 2018 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Sun, 27 May 2018 21:54:35 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: <20180527195434.GA34704@excession.tpb.net> * owen at delong.com (Owen DeLong) [Sun 27 May 2018, 21:42 CEST]: >The way GDPR is written, if you want to collect (and store) so much >as the IP address of the potential customer who visited your >website, you need their informed consent and you can’t require that >they consent as a condition of providing service. You have this the wrong way around. You'll need permission to store their IP address in logs that you keep and to inform third parties about their visits to your site. And that is because that information belongs to the visitor, not to you. >Basically, the regulation is so poorly written that it is utterly >nonsensical and I wonder how business in Europe intend to function >when they can’t make collecting someone’s address a condition of >allowing them to order something online. Basically, this example is so bad that it's not even wrong. -- Niels. From lists at benappy.com Sun May 27 19:56:16 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Sun, 27 May 2018 21:56:16 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: <3F83A680-A1EC-4D47-80B2-517E793E4D6F@benappy.com> > On 27 May 2018, at 21:41, Owen DeLong wrote: > > The way GDPR is written, if you want to collect (and store) so much as > the IP address of the potential customer who visited your website, you > need their informed consent and you can’t require that they consent as > a condition of providing service. What we were told is that since security > GDPR, storing IPs in logs is obviously OK since it’s a legal requirement. Storing them in a database for targeting / marketing is not. What is a gray area so far is any use of IDS/IPS… + From sander at steffann.nl Sun May 27 20:28:05 2018 From: sander at steffann.nl (Sander Steffann) Date: Sun, 27 May 2018 22:28:05 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <3F83A680-A1EC-4D47-80B2-517E793E4D6F@benappy.com> References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <3F83A680-A1EC-4D47-80B2-517E793E4D6F@benappy.com> Message-ID: <9F2E25D9-F41C-4F6F-99FE-C5026106932A@steffann.nl> Hi, >> The way GDPR is written, if you want to collect (and store) so much as >> the IP address of the potential customer who visited your website, you >> need their informed consent and you can’t require that they consent as >> a condition of providing service. > > What we were told is that since security > GDPR, storing IPs in logs is obviously OK since it’s a legal requirement. GDPR article 6.1c (legal obligation) and 6.1f (legitimate interests) would probably both qualify for logging HTTP requests. In this context it's also not likely that the IP address is considered personal data at all. Personal data is defined as data related to "an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, [...]". If you have no way to determine who an IP address belongs to then it's not personal data to you. This can actually be a tricky point: the ISP who provides connectivity to a customer obviously knows which IP address they provided, so to that ISP the IP address is definitely personal data. If you ask for someone's name on your website and you log the IP address together with answers then you suddenly turn that IP address into personal data, even regarding you web server logs. To be safe, adding something like the following to the privacy notice on the website would be fine for this case: "In order to comply with law enforcement requirements and to be able to detect and investigate abuse of our website we log all requests in including the IP addresses of the requester. If our systems detect abuse they may block access to our services from that IP address. This data will be stored for up to 2 weeks and will then automatically be deleted.". Add boilerplate text for contact information etc and that should cover article 13. > Storing them in a database for targeting / marketing is not. > > What is a gray area so far is any use of IDS/IPS… Sounds like legitimate interests to me :) But it really depends on what is done with that information. Just protecting your servers should be fine. The big change with the GDPR is that you have to tell your users that you do this. Hmmm. It might be a good idea to write some boilerplate privacy policy text for common components like IDP/IDS, load balancers, web server logs, DDOS protection etc. Cheers, Sander From list at satchell.net Sun May 27 21:17:13 2018 From: list at satchell.net (Stephen Satchell) Date: Sun, 27 May 2018 14:17:13 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <20180527195434.GA34704@excession.tpb.net> References: <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <20180527195434.GA34704@excession.tpb.net> Message-ID: <57b5def1-6ebe-46e3-faff-d83b5305ec76@satchell.net> On 05/27/2018 12:54 PM, niels=nanog at bakker.net wrote: > You have this the wrong way around.  You'll need permission to store > their IP address in logs that you keep and to inform third parties about > their visits to your site.  And that is because that information belongs > to the visitor, not to you. This is going to run afoul of some data retention laws currently on the books in some places. You *have* to keep logs, WITH IP addresses... From niels=nanog at bakker.net Sun May 27 21:36:08 2018 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Sun, 27 May 2018 23:36:08 +0200 Subject: Whois vs GDPR, latest news In-Reply-To: <57b5def1-6ebe-46e3-faff-d83b5305ec76@satchell.net> References: <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <20180527195434.GA34704@excession.tpb.net> <57b5def1-6ebe-46e3-faff-d83b5305ec76@satchell.net> Message-ID: <20180527213608.GB34704@excession.tpb.net> * list at satchell.net (Stephen Satchell) [Sun 27 May 2018, 23:17 CEST]: >On 05/27/2018 12:54 PM, niels=nanog at bakker.net wrote: >>You have this the wrong way around.  You'll need permission to >>store their IP address in logs that you keep and to inform third >>parties about their visits to your site.  And that is because that >>information belongs to the visitor, not to you. > >This is going to run afoul of some data retention laws currently on >the books in some places. You *have* to keep logs, WITH IP >addresses... Owen doesn't. -- Niels. From johnl at iecc.com Mon May 28 03:01:41 2018 From: johnl at iecc.com (John Levine) Date: 27 May 2018 23:01:41 -0400 Subject: Whois vs GDPR, latest news In-Reply-To: <230722.1527374328@turing-police.cc.vt.edu> Message-ID: <20180528030141.9806E272B147@ary.qy> In article <230722.1527374328 at turing-police.cc.vt.edu> you write: >Now here's the big question - a *lot* of companies are targeting "anybody with >a freemail account like GMail and a valid Visa or Mastercard card" or similar >business models - does that count as "specifically targeting at EU", or not? This is an excellent question, because anyone who purports to give you an answer has self-identifed as a fool. The closest thing to an answer is that nobody knows, maybe after some rulings from various national authorities we'll have an idea, except that they'll probably be inconsistent and contradictory. R's, John From list at satchell.net Mon May 28 04:46:31 2018 From: list at satchell.net (Stephen Satchell) Date: Sun, 27 May 2018 21:46:31 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: <20180528030141.9806E272B147@ary.qy> References: <20180528030141.9806E272B147@ary.qy> Message-ID: This is really off-topic for NANOG. Is there a better place where this discussion can be found? From nanog at ics-il.net Mon May 28 14:23:09 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 28 May 2018 09:23:09 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) Message-ID: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Has anyone outside of tech media, Silicon Valley or academia (all places wildly out of touch with the real world) put much thought into the impacts of encryption everywhere? So often we hear about how we need the best modern encryption on all forms of communication because of whatever scary thing is trendy this week (Russia, NSA, Google, whatever). HTTPS your marketing information and generic education pieces because of the boogeyman! However, I recently came across a thread where someone was exploring getting a one megabit connection into their village and sharing it among many. The crowd I referenced earlier also believes you can't Internet under 100 megabit/s per home. Apparently, the current best Internet the residents of the village can get is 40 kilobit/s. Zero oversubscription gets a better service to up to 25 homes. Likely that could be stretched to at least 50 or 100 homes and be better than what they currently have. Forget about streaming video, let's just focus on web browsing and messaging. However, this could be wildly improved with caching ala squid or something similar. The problem is that encrypted content is difficult to impossible for your average Joe to cache. The rewards for implementing caching are greatly mitigated and people like this must suffer a worse Internet experience because of some ideological high horse in a far-off land. Some things certainly do need to be encrypted, but encrypting everything means people with limited Internet access get worse performance OR mechanisms have to be out in place to break ALL encryption, this compromising security and privacy when it's really needed. To circle back to being somewhat on-topic, what mechanisms are available to maximize the amount of traffic someone in this situation could cache? The performance of third-world Internet depends on you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From dtaylor at vocalabs.com Mon May 28 14:43:10 2018 From: dtaylor at vocalabs.com (1 651-307-9043) Date: Mon, 28 May 2018 09:43:10 -0500 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: <7a665473-b798-4fed-86f4-1b41eb6fd6ac@email.android.com> An HTML attachment was scrubbed... URL: From khomyakov.andrey at gmail.com Mon May 28 14:50:01 2018 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 28 May 2018 16:50:01 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: That is super interesting. While one can Internet fine at 5Mbps (save for streaming UHD movies maybe), I am not convinced 1Mbps can be successfully shared even if there was no encryption anywhere. My understanding is that some enterprises do decrypt traffic in flight with proxies such as bluecoat, though I'm not sure on the particulars of how that works. I think the overall theory is that the proxy acts as a trusted CA for all its client and generates the certificate for the destination hostname on the fly thus terminating the SSL connection and opening new one on behalf of the client. I do, however, recall that the solution is not cheap. Neither $ nor computationally or, I'm guessing, in case of a village if they can't get anything faster than 1Mbps, can they even get power to run a couple (does the proxy uptime matter?) of proxies of heavy compute? Another concern would be that caching implies the whole village visits the same content. I'm not even confident me and wife visit the same content (save for gmail maybe). And lastly, most modern websites are very media rich. Unless the whole village confines their usage to wikipedia.org, I can't imagine that the experience will be pleasant in anyway or form or there will be any benefit to caching. Save for the SSL proxy mentioned above, I have seen folks pull several crappy DLS connections (Let's say ~1Mbps each) and band them together. If the provider support the bonding option, great! If not, I've seen folks basically per flow load balance across the 4 connections. -Andrey --Andrey On Mon, May 28, 2018 at 4:23 PM, Mike Hammett wrote: > Has anyone outside of tech media, Silicon Valley or academia (all places > wildly out of touch with the real world) put much thought into the impacts > of encryption everywhere? So often we hear about how we need the best > modern encryption on all forms of communication because of whatever scary > thing is trendy this week (Russia, NSA, Google, whatever). HTTPS your > marketing information and generic education pieces because of the boogeyman! > > However, I recently came across a thread where someone was exploring > getting a one megabit connection into their village and sharing it among > many. The crowd I referenced earlier also believes you can't Internet under > 100 megabit/s per home. > > Apparently, the current best Internet the residents of the village can get > is 40 kilobit/s. Zero oversubscription gets a better service to up to 25 > homes. Likely that could be stretched to at least 50 or 100 homes and be > better than what they currently have. Forget about streaming video, let's > just focus on web browsing and messaging. > > However, this could be wildly improved with caching ala squid or something > similar. The problem is that encrypted content is difficult to impossible > for your average Joe to cache. The rewards for implementing caching are > greatly mitigated and people like this must suffer a worse Internet > experience because of some ideological high horse in a far-off land. > > Some things certainly do need to be encrypted, but encrypting everything > means people with limited Internet access get worse performance OR > mechanisms have to be out in place to break ALL encryption, this > compromising security and privacy when it's really needed. > > To circle back to being somewhat on-topic, what mechanisms are available > to maximize the amount of traffic someone in this situation could cache? > The performance of third-world Internet depends on you. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From rsk at gsp.org Mon May 28 15:00:36 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 28 May 2018 11:00:36 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: <20180528150036.GA19410@gsp.org> On Mon, May 28, 2018 at 09:23:09AM -0500, Mike Hammett wrote: > Some things certainly do need to be encrypted, but encrypting everything > means people with limited Internet access get worse performance OR > mechanisms have to be out in place to break ALL encryption, this > compromising security and privacy when it's really needed. There are better places to reduce traffic while simultaneously enhancing security and privacy. The new EU version of the home page of USA Today is about 20% the size of the one presented in the US -- because it's had all the tracking and scripting stripped out -- with a concomitant reduction in load time and rendering time. Much more drastic reductions are available elsewhere, e.g., mail messages composed of text only are typically 5% to 10% the size of the same messages marked up with HTML. The problem (part of the problem) is that the people doing these foolish things are new, ignorant, and privileged: they don't realize that bandwidth is still an expensive and scarce resource for most of the planet. I've said for years that every web designer should be forced to work in an environment bandlimited to 56K in order to instll in them the virtue of frugality and strongly discourage them from flattering their egos by creating all-singing all-dancing web sites...that look great in the portfolios they'll show to their peers but are horribly bloated, slow, unrenderable in a lot of browsers, and fraught with security and privacy problems. (Try pointing a text-only browser at your favorite website. Can you even read the home page?) ---rsk From fhr at fhrnet.eu Mon May 28 15:34:30 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Mon, 28 May 2018 15:34:30 +0000 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180528150036.GA19410@gsp.org> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180528150036.GA19410@gsp.org> Message-ID: <01020163a762f6ec-c2fb8d81-307a-436c-bd63-0e0e5e36c249-000000@eu-west-1.amazonses.com> Dne 28. 5. 2018 v 17:00 Rich Kulawiec napsal(a): > On Mon, May 28, 2018 at 09:23:09AM -0500, Mike Hammett wrote: >> Some things certainly do need to be encrypted, but encrypting everything >> means people with limited Internet access get worse performance OR >> mechanisms have to be out in place to break ALL encryption, this >> compromising security and privacy when it's really needed. > There are better places to reduce traffic while simultaneously enhancing > security and privacy. The new EU version of the home page of USA Today > is about 20% the size of the one presented in the US -- because it's > had all the tracking and scripting stripped out -- with a concomitant > reduction in load time and rendering time. That's awesome, that page fully loaded instantly (roughly in half a second) and uBlock Origin blocked 0 elements. 291KB for the home page. This is a sight I want to see more. Regards, Filip From nanog at ics-il.net Mon May 28 16:03:47 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 28 May 2018 11:03:47 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: <1342592581.96.1527523424976.JavaMail.mhammett@ThunderFuck> The increase in the subscriber base increases the likelihood of visiting the same content and thus the benefit. Before HTTPS-everywhere, caching was hugely beneficial. Currently they are making do with 40 kilobit/s, so it's certainly possible to Internet at that level. Just looking at ways the service can be even that much better. If they only have single digit megabit/s of Internet, you don't need multiple systems to add\drop the encryption. While I don't have anything to back this up, I'd suspect a couple hundred dollar single board computer (since session border controller seems to be a more popular use of the acronym SBC) would be sufficient. I'm not overly intimate with that space, but some little ARM-based machine could probably do it just fine. Move that to hundreds of megabit/s or gigabit/s and your concern is certainly much more relevant. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Andrey Khomyakov" To: "Mike Hammett" Cc: "NANOG list" Sent: Monday, May 28, 2018 9:50:01 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) That is super interesting. While one can Internet fine at 5Mbps (save for streaming UHD movies maybe), I am not convinced 1Mbps can be successfully shared even if there was no encryption anywhere. My understanding is that some enterprises do decrypt traffic in flight with proxies such as bluecoat, though I'm not sure on the particulars of how that works. I think the overall theory is that the proxy acts as a trusted CA for all its client and generates the certificate for the destination hostname on the fly thus terminating the SSL connection and opening new one on behalf of the client. I do, however, recall that the solution is not cheap. Neither $ nor computationally or, I'm guessing, in case of a village if they can't get anything faster than 1Mbps, can they even get power to run a couple (does the proxy uptime matter?) of proxies of heavy compute? Another concern would be that caching implies the whole village visits the same content. I'm not even confident me and wife visit the same content (save for gmail maybe). And lastly, most modern websites are very media rich. Unless the whole village confines their usage to wikipedia.org , I can't imagine that the experience will be pleasant in anyway or form or there will be any benefit to caching. Save for the SSL proxy mentioned above, I have seen folks pull several crappy DLS connections (Let's say ~1Mbps each) and band them together. If the provider support the bonding option, great! If not, I've seen folks basically per flow load balance across the 4 connections. -Andrey --Andrey On Mon, May 28, 2018 at 4:23 PM, Mike Hammett < nanog at ics-il.net > wrote: Has anyone outside of tech media, Silicon Valley or academia (all places wildly out of touch with the real world) put much thought into the impacts of encryption everywhere? So often we hear about how we need the best modern encryption on all forms of communication because of whatever scary thing is trendy this week (Russia, NSA, Google, whatever). HTTPS your marketing information and generic education pieces because of the boogeyman! However, I recently came across a thread where someone was exploring getting a one megabit connection into their village and sharing it among many. The crowd I referenced earlier also believes you can't Internet under 100 megabit/s per home. Apparently, the current best Internet the residents of the village can get is 40 kilobit/s. Zero oversubscription gets a better service to up to 25 homes. Likely that could be stretched to at least 50 or 100 homes and be better than what they currently have. Forget about streaming video, let's just focus on web browsing and messaging. However, this could be wildly improved with caching ala squid or something similar. The problem is that encrypted content is difficult to impossible for your average Joe to cache. The rewards for implementing caching are greatly mitigated and people like this must suffer a worse Internet experience because of some ideological high horse in a far-off land. Some things certainly do need to be encrypted, but encrypting everything means people with limited Internet access get worse performance OR mechanisms have to be out in place to break ALL encryption, this compromising security and privacy when it's really needed. To circle back to being somewhat on-topic, what mechanisms are available to maximize the amount of traffic someone in this situation could cache? The performance of third-world Internet depends on you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From nanog at ics-il.net Mon May 28 16:09:08 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 28 May 2018 11:09:08 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180528150036.GA19410@gsp.org> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180528150036.GA19410@gsp.org> Message-ID: <886392482.108.1527523744302.JavaMail.mhammett@ThunderFuck> I can't imagine rural third-country villages have much influence over the departments of the appropriate companies to affect all of the junk getting added to sites these days. I'm also not foolish enough to think this thread will affect the encrypt-everything crowd as it is more of a religion\ideology than a practical matter. However, maybe it'll shed some light on technical ways of dealing with this at the service-provider level or plant some doubt in someone's mind the next time they think they need to encrypt non-sensitive information. The same goes for all development. My phone is significantly slower today than a couple years ago when new without a significant change in the amount of stuff that I run because developers are lazy and fill the space the latest platforms offer them. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Rich Kulawiec" To: nanog at nanog.org Sent: Monday, May 28, 2018 10:00:36 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) On Mon, May 28, 2018 at 09:23:09AM -0500, Mike Hammett wrote: > Some things certainly do need to be encrypted, but encrypting everything > means people with limited Internet access get worse performance OR > mechanisms have to be out in place to break ALL encryption, this > compromising security and privacy when it's really needed. There are better places to reduce traffic while simultaneously enhancing security and privacy. The new EU version of the home page of USA Today is about 20% the size of the one presented in the US -- because it's had all the tracking and scripting stripped out -- with a concomitant reduction in load time and rendering time. Much more drastic reductions are available elsewhere, e.g., mail messages composed of text only are typically 5% to 10% the size of the same messages marked up with HTML. The problem (part of the problem) is that the people doing these foolish things are new, ignorant, and privileged: they don't realize that bandwidth is still an expensive and scarce resource for most of the planet. I've said for years that every web designer should be forced to work in an environment bandlimited to 56K in order to instll in them the virtue of frugality and strongly discourage them from flattering their egos by creating all-singing all-dancing web sites...that look great in the portfolios they'll show to their peers but are horribly bloated, slow, unrenderable in a lot of browsers, and fraught with security and privacy problems. (Try pointing a text-only browser at your favorite website. Can you even read the home page?) ---rsk From gtaylor at tnetconsulting.net Mon May 28 16:17:10 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 28 May 2018 10:17:10 -0600 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> On 05/28/2018 08:23 AM, Mike Hammett wrote: > To circle back to being somewhat on-topic, what mechanisms are available > to maximize the amount of traffic someone in this situation could > cache? The performance of third-world Internet depends on you. I've personally played with Squid's SSL-bump-in-the-wire mode (on my personal systems) and was moderately happy with it. - I think that such is a realistic possibility in the scenario that you describe. I would REQUIRE /open/ and /transparent/ communications from the ISP and a *VERY* strict security control to the caching proxy. I would naively like to believe that an ISP could establish a reputation with the community and build a trust relationship such that the community was somewhat okay with the SSL-bump-in-the-wire. It might even be worth leveraging WPAD or PAC to route specific URLs direct to some places (banks, etc) to mitigate some of the security risk. I would also advocate another proxy on the upstream side of the 1 Mbps connection (in the cloud if you will) primarily for the purpose of it doing as much traffic optimization as possible. Have it fetch things and deal with fragments so that it can homogenize the traffic before it's sent across the across the slow link. I'd think seriously about throwing some CPU (a single core off of any machine in the last 10 years should be sufficient) at compression to try to stretch the bandwidth between the two proxy servers. I'd also think seriously about a local root DNS zone slave downstream, and any other zone that I could slave, for the purpose of minimizing the number of queries that need to get pushed across the link. I've been assuming that this 1 Mbps link is terrestrial. Which means that I'd also explore something like a satellite link with more bandwidth. Sure the latency on it will be higher, but that can be worked with. Particularly if you can use some intelligence to route different CoS / ToS / DiffServ (DSCP) across the different links. I think there are options and things that can be done to make this viable. Also, considering that the village has been using a 40 kbps link, sharing a 1 Mbps (or 1,000 kbps) link is going to be a LOT better than it was. The question is, how do you stretch a good thing as far as possible. Finally, will you please provide some pointers to the discussion you're talking about? I'd like to read it if possible. -- Grant. . . . unix || die From bill at herrin.us Mon May 28 16:33:37 2018 From: bill at herrin.us (William Herrin) Date: Mon, 28 May 2018 12:33:37 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: On Mon, May 28, 2018 at 10:50 AM, Andrey Khomyakov wrote: > My understanding is that some enterprises do decrypt traffic in flight with > proxies such as bluecoat, though I'm not sure on the particulars of how > that works. PCs within the enterprise contain an enterprise-local root in their certificate store. The proxy re-encrypts using a key whose ephemeral cert chains up to the enterprise root. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nanog at jack.fr.eu.org Mon May 28 16:37:46 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Mon, 28 May 2018 18:37:46 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <886392482.108.1527523744302.JavaMail.mhammett@ThunderFuck> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180528150036.GA19410@gsp.org> <886392482.108.1527523744302.JavaMail.mhammett@ThunderFuck> Message-ID: <5B0C305A.3040906@jack.fr.eu.org> The "do not search a culprit" stuff: What is the point with encryption ? If your users have a very-low bandwidth, they will get a crappy service, with or without encryption This is our world, our http-based internet is NOT made for a 40k connection The "tip stuff": If you simply do not care about encryption, or are willing to trade privacy for caching because you have no-bandwidth, you can simply break SSL It costs nothing, and you will not mind the "red lock" (remember: trade-off) The "philosophical stuff": About your last part, you are absolutely right, this is a sad situation, yet not true Niklaus Wirth (the pascal guy) said in 1995: "Software gets slower faster than hardware gets faster." This has never been so true .. On 05/28/2018 06:09 PM, Mike Hammett wrote: > I can't imagine rural third-country villages have much influence over the departments of the appropriate companies to affect all of the junk getting added to sites these days. > > I'm also not foolish enough to think this thread will affect the encrypt-everything crowd as it is more of a religion\ideology than a practical matter. However, maybe it'll shed some light on technical ways of dealing with this at the service-provider level or plant some doubt in someone's mind the next time they think they need to encrypt non-sensitive information. > > The same goes for all development. My phone is significantly slower today than a couple years ago when new without a significant change in the amount of stuff that I run because developers are lazy and fill the space the latest platforms offer them. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Rich Kulawiec" > To: nanog at nanog.org > Sent: Monday, May 28, 2018 10:00:36 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > > On Mon, May 28, 2018 at 09:23:09AM -0500, Mike Hammett wrote: >> Some things certainly do need to be encrypted, but encrypting everything >> means people with limited Internet access get worse performance OR >> mechanisms have to be out in place to break ALL encryption, this >> compromising security and privacy when it's really needed. > > There are better places to reduce traffic while simultaneously enhancing > security and privacy. The new EU version of the home page of USA Today > is about 20% the size of the one presented in the US -- because it's > had all the tracking and scripting stripped out -- with a concomitant > reduction in load time and rendering time. Much more drastic reductions > are available elsewhere, e.g., mail messages composed of text only are > typically 5% to 10% the size of the same messages marked up with HTML. > > The problem (part of the problem) is that the people doing these foolish > things are new, ignorant, and privileged: they don't realize that bandwidth > is still an expensive and scarce resource for most of the planet. I've > said for years that every web designer should be forced to work in an > environment bandlimited to 56K in order to instll in them the virtue > of frugality and strongly discourage them from flattering their egos > by creating all-singing all-dancing web sites...that look great in the > portfolios they'll show to their peers but are horribly bloated, slow, > unrenderable in a lot of browsers, and fraught with security and privacy > problems. (Try pointing a text-only browser at your favorite website. > Can you even read the home page?) > > ---rsk > From Steve.Mikulasik at civeo.com Mon May 28 16:45:06 2018 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Mon, 28 May 2018 16:45:06 +0000 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: Look at the Steam cache project, the generic downloader can also cache Windows Updates and most gaming services. I imagine Windows Updates would eat a lot of traffic. https://github.com/steamcache From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Monday, May 28, 2018 8:23 AM To: 'NANOG list' Subject: Impacts of Encryption Everywhere (any solution?) Has anyone outside of tech media, Silicon Valley or academia (all places wildly out of touch with the real world) put much thought into the impacts of encryption everywhere? So often we hear about how we need the best modern encryption on all forms of communication because of whatever scary thing is trendy this week (Russia, NSA, Google, whatever). HTTPS your marketing information and generic education pieces because of the boogeyman! However, I recently came across a thread where someone was exploring getting a one megabit connection into their village and sharing it among many. The crowd I referenced earlier also believes you can't Internet under 100 megabit/s per home. Apparently, the current best Internet the residents of the village can get is 40 kilobit/s. Zero oversubscription gets a better service to up to 25 homes. Likely that could be stretched to at least 50 or 100 homes and be better than what they currently have. Forget about streaming video, let's just focus on web browsing and messaging. However, this could be wildly improved with caching ala squid or something similar. The problem is that encrypted content is difficult to impossible for your average Joe to cache. The rewards for implementing caching are greatly mitigated and people like this must suffer a worse Internet experience because of some ideological high horse in a far-off land. Some things certainly do need to be encrypted, but encrypting everything means people with limited Internet access get worse performance OR mechanisms have to be out in place to break ALL encryption, this compromising security and privacy when it's really needed. To circle back to being somewhat on-topic, what mechanisms are available to maximize the amount of traffic someone in this situation could cache? The performance of third-world Internet depends on you. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From merculiani at gmail.com Mon May 28 16:50:57 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Mon, 28 May 2018 11:50:57 -0500 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> Message-ID: In addition to the "bump in the wire" you could also enable larger frame sizes downstream since you're already completely disassembling and reassembling the packets. Large downloads or uploads could see overhead go from 3% at 1500B to about 0.5% at 9100B. It's not much but every little bit counts. (Preamble, Ethernet, IP, and TCP headers all need be sent accross the circuit less often to get the same amount of data through) Looking only at the throughput of L4 payloads, you get: 1500 MTU = 956 kbps 9100 MTU = 992 kbps That almost adds a whole additional home if my math is correct. -Matt On Mon, May 28, 2018, 11:17 Grant Taylor via NANOG wrote: > On 05/28/2018 08:23 AM, Mike Hammett wrote: > > To circle back to being somewhat on-topic, what mechanisms are available > > to maximize the amount of traffic someone in this situation could > > cache? The performance of third-world Internet depends on you. > > I've personally played with Squid's SSL-bump-in-the-wire mode (on my > personal systems) and was moderately happy with it. - I think that > such is a realistic possibility in the scenario that you describe. > > I would REQUIRE /open/ and /transparent/ communications from the ISP and > a *VERY* strict security control to the caching proxy. I would naively > like to believe that an ISP could establish a reputation with the > community and build a trust relationship such that the community was > somewhat okay with the SSL-bump-in-the-wire. > > It might even be worth leveraging WPAD or PAC to route specific URLs > direct to some places (banks, etc) to mitigate some of the security risk. > > I would also advocate another proxy on the upstream side of the 1 Mbps > connection (in the cloud if you will) primarily for the purpose of it > doing as much traffic optimization as possible. Have it fetch things > and deal with fragments so that it can homogenize the traffic before > it's sent across the across the slow link. I'd think seriously about > throwing some CPU (a single core off of any machine in the last 10 years > should be sufficient) at compression to try to stretch the bandwidth > between the two proxy servers. > > I'd also think seriously about a local root DNS zone slave downstream, > and any other zone that I could slave, for the purpose of minimizing the > number of queries that need to get pushed across the link. > > I've been assuming that this 1 Mbps link is terrestrial. Which means > that I'd also explore something like a satellite link with more > bandwidth. Sure the latency on it will be higher, but that can be > worked with. Particularly if you can use some intelligence to route > different CoS / ToS / DiffServ (DSCP) across the different links. > > I think there are options and things that can be done to make this viable. > > Also, considering that the village has been using a 40 kbps link, > sharing a 1 Mbps (or 1,000 kbps) link is going to be a LOT better than > it was. The question is, how do you stretch a good thing as far as > possible. > > Finally, will you please provide some pointers to the discussion you're > talking about? I'd like to read it if possible. > > > > -- > Grant. . . . > unix || die > From kmedcalf at dessus.com Mon May 28 16:55:21 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 28 May 2018 10:55:21 -0600 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <886392482.108.1527523744302.JavaMail.mhammett@ThunderFuck> Message-ID: <8b968ed591d43945bb401f12a95dc9ae@mail.dessus.com> >I'm also not foolish enough to think this thread will affect the >encrypt-everything crowd as it is more of a religion\ideology than a >practical matter. However, maybe it'll shed some light on technical >ways of dealing with this at the service-provider level or plant some >doubt in someone's mind the next time they think they need to encrypt >non-sensitive information. Good Luck, especially in light of the poo-for-brains at Google responsible for the Chrome browser who (wrongly) equate "secure" with Transport Encryption and "unsecure" with not having Transport Encryption; when all that Transport Encryption really implies is Transport Encryption and not much else. It has little to do with whether or not a site is "secure". Generally speaking, I have found that sites engaging Transport Security are much more "unsecure" (as in subject to security breaches and flaws) than those that do not engage Transport Security for no reason. However, the poo-for-brains crowd will get everyone to engage Transport Security so the will be called "Secure", whether trustworthy or not. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From amitchell at isipp.com Mon May 28 17:20:00 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Mon, 28 May 2018 11:20:00 -0600 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> <16d60208-0377-ddbd-7971-917667057c50@foobar.org> <2FDBD6F4-94F8-4811-A625-ED9AD9494B0E@consulintel.es> <6F926262-4491-4F79-ACF0-B0234E722268@consulintel.es> <0b497230-05a6-6e70-85b8-952728b8c3ba@invaluement.com> <270DD91B-3CA5-4B7A-BE16-B24B9F066697@benappy.com> <3b5c0f4a-d3fc-b737-c45d-8879b97bd49c@rollernet.us> <60199B3D-F0B7-40DD-9713-E4B5339BD804@benappy.com> Message-ID: <667463A9-D9DD-41B4-8AF6-3C8A71E53D37@isipp.com> > On May 27, 2018, at 3:19 AM, Michel 'ic' Luczak wrote: > > Still on ec.europa.eu they seem to try to reassure SMEs that the penalties will be “proportionate” both to the nature of the infringement and to the size to the company. It also seem to largely be related to whether you infringed the regulation in good faith or not. At least in France where I live the climate is pro-SMEs so I guess small mistakes will be forgiven. The head of our DPA also gave an interview recently saying that there will be no sanctions in the coming months and that they’re available to answer questions when in doubt about what to do. Here's the thing...unless the EU is vastly different from the US in terms of legislative construction, what any third-party says - even those involved in developing the law - is almost (not completely, but almost) immaterial to how the law will be applied. The law *is the law*, and nothing anybody says about it will have much impact on how it will be construed by a court of law. Which is why: > Lastly, our law firm told us that basically we have to wait until the first settlements to see what will be done… ..exactly. The law will have to be construed and refined by lawsuits (unless a newer law clarifies or supersedes it). And this is why we take a strict, conservative view of what one has to do to get into compliance. Because our job is to keep the entities with whom we consult on GDPR from becoming those test cases. Anne Anne P. Mitchell, Attorney at Law GDPR Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Association Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From rubensk at gmail.com Mon May 28 17:20:36 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 28 May 2018 14:20:36 -0300 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <8b968ed591d43945bb401f12a95dc9ae@mail.dessus.com> References: <886392482.108.1527523744302.JavaMail.mhammett@ThunderFuck> <8b968ed591d43945bb401f12a95dc9ae@mail.dessus.com> Message-ID: On Mon, May 28, 2018 at 1:55 PM, Keith Medcalf wrote: > > >I'm also not foolish enough to think this thread will affect the > >encrypt-everything crowd as it is more of a religion\ideology than a > >practical matter. However, maybe it'll shed some light on technical > >ways of dealing with this at the service-provider level or plant some > >doubt in someone's mind the next time they think they need to encrypt > >non-sensitive information. > > Good Luck, especially in light of the poo-for-brains at Google responsible > for the Chrome browser who (wrongly) equate "secure" with Transport > Encryption and "unsecure" with not having Transport Encryption; when all > that Transport Encryption really implies is Transport Encryption and not > much else. It has little to do with whether or not a site is "secure". > Generally speaking, I have found that sites engaging Transport Security are > much more "unsecure" (as in subject to security breaches and flaws) than > those that do not engage Transport Security for no reason. > > However, the poo-for-brains crowd will get everyone to engage Transport > Security so the will be called "Secure", whether trustworthy or not. > > Actually, starting July Chrome will no longer say "secure" for sites with Transport Security. It will only say "not secure" for sites without, so it will no longer provide the false impression of equating Transport Security with Application/Operational Security. Rubens From amitchell at isipp.com Mon May 28 17:23:50 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Mon, 28 May 2018 11:23:50 -0600 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180528030141.9806E272B147@ary.qy> Message-ID: <99A7A130-BFE6-41AC-AB4B-66A87D8D6E87@isipp.com> > > This is really off-topic for NANOG. Is there a better place where this > discussion can be found? ISIPP hosts several email groups where this conversation would be appropriate. Anybody who would like to continue the conversation there is welcome to ping me offlist requesting to join one or more of those groups...please include your full name, for whom you work (if relevant), and a one sentence description of your interest in/connection to network security, privacy, and/or policies. Anne Anne P. Mitchell, Attorney at Law GDPR Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Association Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From nanog at ics-il.net Mon May 28 17:57:58 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 28 May 2018 12:57:58 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> Message-ID: <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> To be fair, most of the conversation is people not realizing the OP is in a third world country and believe that 1 mbit/s isn't enough for a single user much less a village. https://www.facebook.com/groups/ubntedgeos/permalink/1046305928855488/ Also, I think it's 40 kilotbit/s per user (so probably dial-up), not 40 kilobit/s for the whole village. The whole village may very well have 1 megabit/s worth of dial-up connections, but everyone potentially able to go to 1 megabit is a lot more useful than capping each to 40 kilobit/s. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Grant Taylor via NANOG" To: nanog at nanog.org Sent: Monday, May 28, 2018 11:17:10 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) On 05/28/2018 08:23 AM, Mike Hammett wrote: > To circle back to being somewhat on-topic, what mechanisms are available > to maximize the amount of traffic someone in this situation could > cache? The performance of third-world Internet depends on you. I've personally played with Squid's SSL-bump-in-the-wire mode (on my personal systems) and was moderately happy with it. - I think that such is a realistic possibility in the scenario that you describe. I would REQUIRE /open/ and /transparent/ communications from the ISP and a *VERY* strict security control to the caching proxy. I would naively like to believe that an ISP could establish a reputation with the community and build a trust relationship such that the community was somewhat okay with the SSL-bump-in-the-wire. It might even be worth leveraging WPAD or PAC to route specific URLs direct to some places (banks, etc) to mitigate some of the security risk. I would also advocate another proxy on the upstream side of the 1 Mbps connection (in the cloud if you will) primarily for the purpose of it doing as much traffic optimization as possible. Have it fetch things and deal with fragments so that it can homogenize the traffic before it's sent across the across the slow link. I'd think seriously about throwing some CPU (a single core off of any machine in the last 10 years should be sufficient) at compression to try to stretch the bandwidth between the two proxy servers. I'd also think seriously about a local root DNS zone slave downstream, and any other zone that I could slave, for the purpose of minimizing the number of queries that need to get pushed across the link. I've been assuming that this 1 Mbps link is terrestrial. Which means that I'd also explore something like a satellite link with more bandwidth. Sure the latency on it will be higher, but that can be worked with. Particularly if you can use some intelligence to route different CoS / ToS / DiffServ (DSCP) across the different links. I think there are options and things that can be done to make this viable. Also, considering that the village has been using a 40 kbps link, sharing a 1 Mbps (or 1,000 kbps) link is going to be a LOT better than it was. The question is, how do you stretch a good thing as far as possible. Finally, will you please provide some pointers to the discussion you're talking about? I'd like to read it if possible. -- Grant. . . . unix || die From ben at 6by7.net Mon May 28 18:22:27 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 28 May 2018 11:22:27 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> Message-ID: <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> I’m sorry I simply believe that in 2018 with the advanced and cheap ptp radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over 10miles! Spend a bit more and go 100km) plus the advancements in cubesats about to be launched, even the 3rd world can simply get with the times. -Ben > On May 28, 2018, at 10:57 AM, Mike Hammett wrote: > > To be fair, most of the conversation is people not realizing the OP is in a third world country and believe that 1 mbit/s isn't enough for a single user much less a village. > > https://www.facebook.com/groups/ubntedgeos/permalink/1046305928855488/ > > > Also, I think it's 40 kilotbit/s per user (so probably dial-up), not 40 kilobit/s for the whole village. The whole village may very well have 1 megabit/s worth of dial-up connections, but everyone potentially able to go to 1 megabit is a lot more useful than capping each to 40 kilobit/s. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Grant Taylor via NANOG" > To: nanog at nanog.org > Sent: Monday, May 28, 2018 11:17:10 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > >> On 05/28/2018 08:23 AM, Mike Hammett wrote: >> To circle back to being somewhat on-topic, what mechanisms are available >> to maximize the amount of traffic someone in this situation could >> cache? The performance of third-world Internet depends on you. > > I've personally played with Squid's SSL-bump-in-the-wire mode (on my > personal systems) and was moderately happy with it. - I think that > such is a realistic possibility in the scenario that you describe. > > I would REQUIRE /open/ and /transparent/ communications from the ISP and > a *VERY* strict security control to the caching proxy. I would naively > like to believe that an ISP could establish a reputation with the > community and build a trust relationship such that the community was > somewhat okay with the SSL-bump-in-the-wire. > > It might even be worth leveraging WPAD or PAC to route specific URLs > direct to some places (banks, etc) to mitigate some of the security risk. > > I would also advocate another proxy on the upstream side of the 1 Mbps > connection (in the cloud if you will) primarily for the purpose of it > doing as much traffic optimization as possible. Have it fetch things > and deal with fragments so that it can homogenize the traffic before > it's sent across the across the slow link. I'd think seriously about > throwing some CPU (a single core off of any machine in the last 10 years > should be sufficient) at compression to try to stretch the bandwidth > between the two proxy servers. > > I'd also think seriously about a local root DNS zone slave downstream, > and any other zone that I could slave, for the purpose of minimizing the > number of queries that need to get pushed across the link. > > I've been assuming that this 1 Mbps link is terrestrial. Which means > that I'd also explore something like a satellite link with more > bandwidth. Sure the latency on it will be higher, but that can be > worked with. Particularly if you can use some intelligence to route > different CoS / ToS / DiffServ (DSCP) across the different links. > > I think there are options and things that can be done to make this viable. > > Also, considering that the village has been using a 40 kbps link, > sharing a 1 Mbps (or 1,000 kbps) link is going to be a LOT better than > it was. The question is, how do you stretch a good thing as far as > possible. > > Finally, will you please provide some pointers to the discussion you're > talking about? I'd like to read it if possible. > > > > -- > Grant. . . . > unix || die > From nanog at ics-il.net Mon May 28 19:13:16 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 28 May 2018 14:13:16 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <5B0C305A.3040906@jack.fr.eu.org> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180528150036.GA19410@gsp.org> <886392482.108.1527523744302.JavaMail.mhammett@ThunderFuck> <5B0C305A.3040906@jack.fr.eu.org> Message-ID: <606221933.263.1527534793814.JavaMail.mhammett@ThunderFuck> Once you become sensitized to the HTTPS warnings because www.dickandfartjokes.com needlessly has SSL (or your printer or switch's management interface for those of us not needing to proxy SSL traffic), you now no longer notice that your bank isn't secure. Being hyper-sensitive about SSL causes one to miss things that actually matter. HTTP works just fine over a 40 kb connection. That's all I could get out of my dial-up that I shared to four other computers until about 2004 when I started my WISP. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: nanog at jack.fr.eu.org To: nanog at nanog.org Sent: Monday, May 28, 2018 11:37:46 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) The "do not search a culprit" stuff: What is the point with encryption ? If your users have a very-low bandwidth, they will get a crappy service, with or without encryption This is our world, our http-based internet is NOT made for a 40k connection The "tip stuff": If you simply do not care about encryption, or are willing to trade privacy for caching because you have no-bandwidth, you can simply break SSL It costs nothing, and you will not mind the "red lock" (remember: trade-off) The "philosophical stuff": About your last part, you are absolutely right, this is a sad situation, yet not true Niklaus Wirth (the pascal guy) said in 1995: "Software gets slower faster than hardware gets faster." This has never been so true .. On 05/28/2018 06:09 PM, Mike Hammett wrote: > I can't imagine rural third-country villages have much influence over the departments of the appropriate companies to affect all of the junk getting added to sites these days. > > I'm also not foolish enough to think this thread will affect the encrypt-everything crowd as it is more of a religion\ideology than a practical matter. However, maybe it'll shed some light on technical ways of dealing with this at the service-provider level or plant some doubt in someone's mind the next time they think they need to encrypt non-sensitive information. > > The same goes for all development. My phone is significantly slower today than a couple years ago when new without a significant change in the amount of stuff that I run because developers are lazy and fill the space the latest platforms offer them. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Rich Kulawiec" > To: nanog at nanog.org > Sent: Monday, May 28, 2018 10:00:36 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > > On Mon, May 28, 2018 at 09:23:09AM -0500, Mike Hammett wrote: >> Some things certainly do need to be encrypted, but encrypting everything >> means people with limited Internet access get worse performance OR >> mechanisms have to be out in place to break ALL encryption, this >> compromising security and privacy when it's really needed. > > There are better places to reduce traffic while simultaneously enhancing > security and privacy. The new EU version of the home page of USA Today > is about 20% the size of the one presented in the US -- because it's > had all the tracking and scripting stripped out -- with a concomitant > reduction in load time and rendering time. Much more drastic reductions > are available elsewhere, e.g., mail messages composed of text only are > typically 5% to 10% the size of the same messages marked up with HTML. > > The problem (part of the problem) is that the people doing these foolish > things are new, ignorant, and privileged: they don't realize that bandwidth > is still an expensive and scarce resource for most of the planet. I've > said for years that every web designer should be forced to work in an > environment bandlimited to 56K in order to instll in them the virtue > of frugality and strongly discourage them from flattering their egos > by creating all-singing all-dancing web sites...that look great in the > portfolios they'll show to their peers but are horribly bloated, slow, > unrenderable in a lot of browsers, and fraught with security and privacy > problems. (Try pointing a text-only browser at your favorite website. > Can you even read the home page?) > > ---rsk > From nanog at ics-il.net Mon May 28 19:19:21 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 28 May 2018 14:19:21 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> Message-ID: <12964193.278.1527535157876.JavaMail.mhammett@ThunderFuck> I know the fixed wireless space quite well. If there's no Internet to be had, it doesn't matter how quickly you can distribute it. He did say that (for whatever reason), relaying off of mountain-top sites to get to better connectivity wasn't a viable option. The yet-to-be-deployed satellite constellations don't do anyone any good today. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ben Cannon" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Monday, May 28, 2018 1:22:27 PM Subject: Re: Impacts of Encryption Everywhere (any solution?) I’m sorry I simply believe that in 2018 with the advanced and cheap ptp radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over 10miles! Spend a bit more and go 100km) plus the advancements in cubesats about to be launched, even the 3rd world can simply get with the times. -Ben > On May 28, 2018, at 10:57 AM, Mike Hammett wrote: > > To be fair, most of the conversation is people not realizing the OP is in a third world country and believe that 1 mbit/s isn't enough for a single user much less a village. > > https://www.facebook.com/groups/ubntedgeos/permalink/1046305928855488/ > > > Also, I think it's 40 kilotbit/s per user (so probably dial-up), not 40 kilobit/s for the whole village. The whole village may very well have 1 megabit/s worth of dial-up connections, but everyone potentially able to go to 1 megabit is a lot more useful than capping each to 40 kilobit/s. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Grant Taylor via NANOG" > To: nanog at nanog.org > Sent: Monday, May 28, 2018 11:17:10 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > >> On 05/28/2018 08:23 AM, Mike Hammett wrote: >> To circle back to being somewhat on-topic, what mechanisms are available >> to maximize the amount of traffic someone in this situation could >> cache? The performance of third-world Internet depends on you. > > I've personally played with Squid's SSL-bump-in-the-wire mode (on my > personal systems) and was moderately happy with it. - I think that > such is a realistic possibility in the scenario that you describe. > > I would REQUIRE /open/ and /transparent/ communications from the ISP and > a *VERY* strict security control to the caching proxy. I would naively > like to believe that an ISP could establish a reputation with the > community and build a trust relationship such that the community was > somewhat okay with the SSL-bump-in-the-wire. > > It might even be worth leveraging WPAD or PAC to route specific URLs > direct to some places (banks, etc) to mitigate some of the security risk. > > I would also advocate another proxy on the upstream side of the 1 Mbps > connection (in the cloud if you will) primarily for the purpose of it > doing as much traffic optimization as possible. Have it fetch things > and deal with fragments so that it can homogenize the traffic before > it's sent across the across the slow link. I'd think seriously about > throwing some CPU (a single core off of any machine in the last 10 years > should be sufficient) at compression to try to stretch the bandwidth > between the two proxy servers. > > I'd also think seriously about a local root DNS zone slave downstream, > and any other zone that I could slave, for the purpose of minimizing the > number of queries that need to get pushed across the link. > > I've been assuming that this 1 Mbps link is terrestrial. Which means > that I'd also explore something like a satellite link with more > bandwidth. Sure the latency on it will be higher, but that can be > worked with. Particularly if you can use some intelligence to route > different CoS / ToS / DiffServ (DSCP) across the different links. > > I think there are options and things that can be done to make this viable. > > Also, considering that the village has been using a 40 kbps link, > sharing a 1 Mbps (or 1,000 kbps) link is going to be a LOT better than > it was. The question is, how do you stretch a good thing as far as > possible. > > Finally, will you please provide some pointers to the discussion you're > talking about? I'd like to read it if possible. > > > > -- > Grant. . . . > unix || die > From mpetach at netflight.com Mon May 28 22:13:35 2018 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 28 May 2018 15:13:35 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> Message-ID: On Mon, May 28, 2018 at 11:22 AM, Ben Cannon wrote: > I’m sorry I simply believe that in 2018 with the advanced and cheap ptp > radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over 10miles! > Spend a bit more and go 100km) plus the advancements in cubesats about to > be launched, even the 3rd world can simply get with the times. > > -Ben > Hi Ben, I do not think you adequately understand the economics of the situation. https://www.slideshare.net/InternetSociety/international-bandwidth-and-pricing-trends-in-subsahara-africa-79147043 slide 22, IP transit cost. Your 200mbit/sec link that costs you $300 in hardware is going to cost you $4960/month to actually get IP traffic across, in Nairobi. Yes, that's about $60,000/year. Could *you* afford to "get with the times" if that's what your bandwidth was going to cost you? Please, do a little research on what the real costs are before telling others they need to "simply get with the times." Thanks! Matt From surfer at mauigateway.com Tue May 29 00:06:56 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 28 May 2018 17:06:56 -0700 Subject: Impacts of Encryption Everywhere (any solution?) Message-ID: <20180528170656.946FF7FE@m0117567.ppops.net> --- mpetach at netflight.com wrote: From: Matthew Petach On Mon, May 28, 2018 at 11:22 AM, Ben Cannon wrote: > I’m sorry I simply believe that in 2018 with the advanced and cheap ptp > radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over 10miles! > Spend a bit more and go 100km) plus the advancements in cubesats about to > be launched, even the 3rd world can simply get with the times. I do not think you adequately understand the economics of the situation. https://www.slideshare.net/InternetSociety/international-bandwidth-and-pricing-trends-in-subsahara-africa-79147043 slide 22, IP transit cost. Your 200mbit/sec link that costs you $300 in hardware is going to cost you $4960/month to actually get IP traffic across, in Nairobi. Yes, that's about $60,000/year. Could *you* afford to "get with the times" if that's what your bandwidth was going to cost you? Please, do a little research on what the real costs are before telling others they need to "simply get with the times." ----------------------------------------- Also, please don't just look at continental countries when researching. Look at the small PICs (Pacific Island Countries). For example, search the posts from Christian on Kiribati on the PICISOC list. The cost is extraordinary and all the ego-flattering bloat rsk speaks (relevant part of the post id below) of in very expensive to download and is nearly impossible to stop. scott * > The problem (part of the problem) is that the people doing these foolish > things are new, ignorant, and privileged: they don't realize that bandwidth > is still an expensive and scarce resource for most of the planet. I've > said for years that every web designer should be forced to work in an > environment bandlimited to 56K in order to instll in them the virtue > of frugality and strongly discourage them from flattering their egos > by creating all-singing all-dancing web sites...that look great in the > portfolios they'll show to their peers but are horribly bloated, slow, > unrenderable in a lot of browsers, and fraught with security and privacy > problems. (Try pointing a text-only browser at your favorite website. > Can you even read the home page?) From johnl at iecc.com Tue May 29 02:24:30 2018 From: johnl at iecc.com (John R. Levine) Date: 28 May 2018 22:24:30 -0400 Subject: Impacts of Encryption Everywhere (any solution?) Message-ID: In article , Matthew Petach wrote: >Your 200mbit/sec link that costs you $300 in hardware >is going to cost you $4960/month to actually get IP traffic >across, in Nairobi. Yes, that's about $60,000/year. Nonetheless, Safaricom sells entirely usable data plans. A one day 1GB bundle on a prepaid SIM costs about $1, a monthly 1GB costs about $5. They have 4G, it works, I've used it. What do they know that Telegeography (who made that slide) doesn't? -- Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From mike.lyon at gmail.com Tue May 29 02:54:31 2018 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 28 May 2018 19:54:31 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: I am sure these third world nations have more important things to spend their money on rather than data plans and data devices. Things like food and medicine come to mind... In none of the Starving Children in Africa commercials have I ever seen anyone with a smart phone... It appears Nairobi proper has decent cell coverage, but the outskirt villages and such don't appear all that well covered. I am guessing these are the poorer areas. To check out the 3 cellular providers coverage maps in Kenya, check out the maps located here: https://opensignal.com/networks -Mike On Mon, May 28, 2018 at 7:24 PM, John R. Levine wrote: > In article gmail.com>, > Matthew Petach wrote: > >> Your 200mbit/sec link that costs you $300 in hardware >> is going to cost you $4960/month to actually get IP traffic >> across, in Nairobi. Yes, that's about $60,000/year. >> > > Nonetheless, Safaricom sells entirely usable data plans. A one day > 1GB bundle on a prepaid SIM costs about $1, a monthly 1GB costs about > $5. They have 4G, it works, I've used it. > > What do they know that Telegeography (who made that slide) doesn't? > > -- > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > -- Mike Lyon mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From mpetach at netflight.com Tue May 29 02:55:33 2018 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 28 May 2018 19:55:33 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: On Mon, May 28, 2018 at 7:24 PM, John R. Levine wrote: > In article gmail.com>, > Matthew Petach wrote: > >> Your 200mbit/sec link that costs you $300 in hardware >> is going to cost you $4960/month to actually get IP traffic >> across, in Nairobi. Yes, that's about $60,000/year. >> > > Nonetheless, Safaricom sells entirely usable data plans. A one day > 1GB bundle on a prepaid SIM costs about $1, a monthly 1GB costs about > $5. They have 4G, it works, I've used it. > > What do they know that Telegeography (who made that slide) doesn't? Math. ^_^; 1GB of volume over the course of a month is 3kb/sec sustained throughput over the month. (1000000000*8/(86400*30)) $5 per 3kbit/sec means that 155mbit link would cost...$251,100/month. (155000000/((1000000000*8)/(86400*30))*5) We call that "Time Domain Multiplexing-based profits". Comparing volumetric pricing with rate-based pricing is one of the best ways of tucking in *lots* of room for profit. :) Matt From mark.tinka at seacom.mu Tue May 29 05:00:10 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 07:00:10 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: On 29/May/18 04:24, John R. Levine wrote: >   > > Nonetheless, Safaricom sells entirely usable data plans.  A one day > 1GB bundle on a prepaid SIM costs about $1, a monthly 1GB costs about > $5.  They have 4G, it works, I've used it. > > What do they know that Telegeography (who made that slide) doesn't? 4G coverage is not country-wide. A lot of folk still earn less than US$1/day. Nairobi isn't Kenya... Mark. From mark.tinka at seacom.mu Tue May 29 05:02:55 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 07:02:55 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: On 29/May/18 04:55, Matthew Petach wrote: > > Math. ^_^; > > 1GB of volume over the course of a month is 3kb/sec sustained > throughput over the month. (1000000000*8/(86400*30)) > > $5 per 3kbit/sec means that 155mbit link would cost...$251,100/month. > (155000000/((1000000000*8)/(86400*30))*5) > > We call that "Time Domain Multiplexing-based profits". > > Comparing volumetric pricing with rate-based pricing > is one of the best ways of tucking in *lots* of room for > profit. :) Actual bandwidth isn't bad at all - so that 1GB can go rapidly. Practically, networks and customers all find ways to get that 1GB (or 50MB) to take them as far as it impossibly can. Mark. From ben at 6by7.net Tue May 29 06:36:19 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 28 May 2018 23:36:19 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180528170656.946FF7FE@m0117567.ppops.net> References: <20180528170656.946FF7FE@m0117567.ppops.net> Message-ID: Then Africa in particular is specifically disadvantaged - I spent a good deal of time in Haiti and 4G connectivity was abundant at good speeds, as were terrestrial fiber connections. Mirrors my experience in half a dozen other 3rd world countries. Unless there’s something particularly oppressive about Africa? > On May 28, 2018, at 5:06 PM, Scott Weeks wrote: > > --- mpetach at netflight.com wrote: > From: Matthew Petach > On Mon, May 28, 2018 at 11:22 AM, Ben Cannon wrote: > >> I’m sorry I simply believe that in 2018 with the advanced and cheap ptp >> radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over 10miles! >> Spend a bit more and go 100km) plus the advancements in cubesats about to >> be launched, even the 3rd world can simply get with the times. > > I do not think you adequately understand the economics of the > situation. > > https://www.slideshare.net/InternetSociety/international-bandwidth-and-pricing-trends-in-subsahara-africa-79147043 > > slide 22, IP transit cost. > > Your 200mbit/sec link that costs you $300 in hardware > is going to cost you $4960/month to actually get IP traffic > across, in Nairobi. Yes, that's about $60,000/year. > > Could *you* afford to "get with the times" if that's what > your bandwidth was going to cost you? > > Please, do a little research on what the real > costs are before telling others they need to > "simply get with the times." > ----------------------------------------- > > > > Also, please don't just look at continental countries > when researching. Look at the small PICs (Pacific > Island Countries). For example, search the posts from > Christian on Kiribati on the PICISOC list. The cost is > extraordinary and all the ego-flattering bloat rsk > speaks (relevant part of the post id below) of in very > expensive to download and is nearly impossible to stop. > > scott > > > > * >> The problem (part of the problem) is that the people doing these foolish >> things are new, ignorant, and privileged: they don't realize that bandwidth >> is still an expensive and scarce resource for most of the planet. I've >> said for years that every web designer should be forced to work in an >> environment bandlimited to 56K in order to instll in them the virtue >> of frugality and strongly discourage them from flattering their egos >> by creating all-singing all-dancing web sites...that look great in the >> portfolios they'll show to their peers but are horribly bloated, slow, >> unrenderable in a lot of browsers, and fraught with security and privacy >> problems. (Try pointing a text-only browser at your favorite website. >> Can you even read the home page?) > > > From surfer at mauigateway.com Tue May 29 07:05:02 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 29 May 2018 00:05:02 -0700 Subject: Impacts of Encryption Everywhere (any solution?) Message-ID: <20180529000502.946FF0B7@m0117567.ppops.net> I believe you were responding to me, but it was really hard to tell. If so, here's the conversation... > Also, please don't just look at continental countries > when researching. Look at the small PICs (Pacific > Island Countries). For example, search the posts from > Christian on Kiribati on the PICISOC list. The cost is > extraordinary and all the ego-flattering bloat rsk > speaks (relevant part of the post id below) of in very > expensive to download and is nearly impossible to stop. --- ben at 6by7.net wrote: From: Ben Cannon Then Africa in particular is specifically disadvantaged - I spent a good deal of time in Haiti and 4G connectivity was abundant at good speeds, as were terrestrial fiber connections. Mirrors my experience in half a dozen other 3rd world countries. Unless there’s something particularly oppressive about Africa? -------------------------------------- I guess I was more meaning in the Pacific, since I'm from there. And more particularly places like Kiribati, Cook Islands, Marquesas and other far flung Pacific Island Countries. My apologies for the confusion. Hati and other countries close to a rich mainland country do not suffer the same issues due to geography. scott ps. lately the SW Pacific countries (Vanuatu, Solomons, etc) are getting it together on circuits to main islands in the group from help by NZ, AUS and the Asian Development Bank. From mark.tinka at seacom.mu Tue May 29 07:20:36 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 09:20:36 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> Message-ID: On 29/May/18 08:36, Ben Cannon wrote: > Then Africa in particular is specifically disadvantaged - I spent a good deal of time in Haiti and 4G connectivity was abundant at good speeds, as were terrestrial fiber connections. Haiti isn't exactly a large country. Africa has a ton of countries Haiti could fit into 3 times over, if not more. > Mirrors my experience in half a dozen other 3rd world countries. Never quite understood (or like) the term "3rd world", but... > Unless there’s something particularly oppressive about Africa? There is a meeting in Cape Town coming up in September, AfPIF (Africa Peering & Interconnect Forum). If you have some time to kill and a bit of dosh lying around, come down and have a look at what all the fuss is about :-). Mark. From nick at foobar.org Tue May 29 08:40:36 2018 From: nick at foobar.org (Nick Hilliard) Date: Tue, 29 May 2018 09:40:36 +0100 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> Message-ID: <154d0296-b31f-7ab8-4487-d77a83ffc790@foobar.org> Mark Tinka wrote on 29/05/2018 08:20: > Never quite understood (or like) the term "3rd world", but... it's a term which refers to post-WWII militarily non-aligned countries, for example Kenya, Switzerland, Sweden or the DRC. Obviously there is a clear correlation between mobile data coverage quality and political neutrality stances - I don't understand why you can't see this. Nick From mark.tinka at seacom.mu Tue May 29 09:10:07 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 11:10:07 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <154d0296-b31f-7ab8-4487-d77a83ffc790@foobar.org> References: <20180528170656.946FF7FE@m0117567.ppops.net> <154d0296-b31f-7ab8-4487-d77a83ffc790@foobar.org> Message-ID: <4129ec56-51a2-be06-24cc-4201b426d169@seacom.mu> On 29/May/18 10:40, Nick Hilliard wrote: >   > > it's a term which refers to post-WWII militarily non-aligned > countries, for example Kenya, Switzerland, Sweden or the DRC.  > Obviously there is a clear correlation between mobile data coverage > quality and political neutrality stances - I don't understand why you > can't see this. My refrain was tongue-in-cheek. I know its etymology being rooted in military alignment. However, I'm referring to it from the evolution of the term being associated with poverty in recent years/decades. I've never quite heard anyone call Switzerland a 3rd world country. If someone thinks (lack of) political neutrality is a guaranteed measure of mobile data coverage and penetration, the Chinese and Malaysians must be doing something different; being 2nd and 3rd world countries and all :-)... But seriously, let's try to stay on-topic. Mark. From lowen at pari.edu Tue May 29 13:23:40 2018 From: lowen at pari.edu (Lamar Owen) Date: Tue, 29 May 2018 09:23:40 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> Message-ID: <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> On 05/28/2018 06:13 PM, Matthew Petach wrote: > Your 200mbit/sec link that costs you $300 in hardware > is going to cost you $4960/month to actually get IP traffic > across, in Nairobi. Yes, that's about $60,000/year. I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land.  Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here.  I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. The terrain here prevents fixed wireless.  The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight).  I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup.  If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank).  DSL started out here at 384k/128k.  On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) So it's not just '3rd-world' countries with expensive bandwidth. From mattlists at rivervalleyinternet.net Tue May 29 13:27:17 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 29 May 2018 09:27:17 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> Message-ID: <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> I am incredibly rural in Pennsylvania and pay about $.50 per megabit. > On May 29, 2018, at 09:23, Lamar Owen wrote: > >> On 05/28/2018 06:13 PM, Matthew Petach wrote: >> Your 200mbit/sec link that costs you $300 in hardware >> is going to cost you $4960/month to actually get IP traffic >> across, in Nairobi. Yes, that's about $60,000/year. > I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land. Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here. I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. > > The terrain here prevents fixed wireless. The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight). I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup. If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. > > I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. > > I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank). DSL started out here at 384k/128k. On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. > > (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) > > So it's not just '3rd-world' countries with expensive bandwidth. > From mark.tinka at seacom.mu Tue May 29 13:32:54 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 15:32:54 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> Message-ID: <302b830a-f270-141d-9652-9f7af840d547@seacom.mu> I guess not all rurals are the same. In my parts, being rural could mean not having a 2G/3G signal until you have to climb a tree... not literally, but you get my point. Mark. On 29/May/18 15:27, Matt Hoppes wrote: > I am incredibly rural in Pennsylvania and pay about $.50 per megabit. > >> On May 29, 2018, at 09:23, Lamar Owen wrote: >> >>> On 05/28/2018 06:13 PM, Matthew Petach wrote: >>> Your 200mbit/sec link that costs you $300 in hardware >>> is going to cost you $4960/month to actually get IP traffic >>> across, in Nairobi. Yes, that's about $60,000/year. >> I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land. Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here. I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. >> >> The terrain here prevents fixed wireless. The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight). I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup. If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. >> >> I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. >> >> I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank). DSL started out here at 384k/128k. On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. >> >> (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) >> >> So it's not just '3rd-world' countries with expensive bandwidth. >> > . > From johnl at iecc.com Tue May 29 14:16:17 2018 From: johnl at iecc.com (John R. Levine) Date: 29 May 2018 10:16:17 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: > I am sure these third world nations have more important things to spend > their money on rather than data plans and data devices. Things like food > and medicine come to mind... My goodness, aren't we condescending. Since we're talking about Kenya here, a few milliseconds of research reminds us that it's a significant agricultural exporter. Agricultural development there is generally about better use of existing land. You might also want to learn about M-Pesa, the mobile phone payment system that everybody uses. Stores all have a sign with their M-Pesa number so you can pay them, and there are kiosks all over Nairobi that will exchange M-Pesa credit and cash. The 1GB data bundles I mentioned are large ones. You can get 7MB for a day or 5MB for a week for 5c, which is plenty to check your messages or look up farm prices. People in Africa may be poorer than we are, but they are just as smart as we are, and they are just as able and interested in technology when it is useful to them. R's, John From nanog at ics-il.net Tue May 29 14:17:00 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 29 May 2018 09:17:00 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> Message-ID: <218566457.590.1527603418678.JavaMail.mhammett@ThunderFuck> Is that PennRen\Kinber? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Matt Hoppes" To: "Lamar Owen" Cc: nanog at nanog.org Sent: Tuesday, May 29, 2018 8:27:17 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) I am incredibly rural in Pennsylvania and pay about $.50 per megabit. > On May 29, 2018, at 09:23, Lamar Owen wrote: > >> On 05/28/2018 06:13 PM, Matthew Petach wrote: >> Your 200mbit/sec link that costs you $300 in hardware >> is going to cost you $4960/month to actually get IP traffic >> across, in Nairobi. Yes, that's about $60,000/year. > I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land. Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here. I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. > > The terrain here prevents fixed wireless. The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight). I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup. If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. > > I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. > > I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank). DSL started out here at 384k/128k. On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. > > (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) > > So it's not just '3rd-world' countries with expensive bandwidth. > From ml at kenweb.org Tue May 29 14:23:50 2018 From: ml at kenweb.org (ML) Date: Tue, 29 May 2018 10:23:50 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <218566457.590.1527603418678.JavaMail.mhammett@ThunderFuck> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> <218566457.590.1527603418678.JavaMail.mhammett@ThunderFuck> Message-ID: <5b483f0f-0a0b-dcdc-2491-9025626162ce@kenweb.org> $100M+ in federal dollars goes a long way. On 5/29/2018 10:17 AM, Mike Hammett wrote: > Is that PennRen\Kinber? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Matt Hoppes" > To: "Lamar Owen" > Cc: nanog at nanog.org > Sent: Tuesday, May 29, 2018 8:27:17 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > > I am incredibly rural in Pennsylvania and pay about $.50 per megabit. > >> On May 29, 2018, at 09:23, Lamar Owen wrote: >> >>> On 05/28/2018 06:13 PM, Matthew Petach wrote: >>> Your 200mbit/sec link that costs you $300 in hardware >>> is going to cost you $4960/month to actually get IP traffic >>> across, in Nairobi. Yes, that's about $60,000/year. >> I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land. Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here. I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. >> >> The terrain here prevents fixed wireless. The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight). I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup. If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. >> >> I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. >> >> I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank). DSL started out here at 384k/128k. On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. >> >> (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) >> >> So it's not just '3rd-world' countries with expensive bandwidth. >> From mattlists at rivervalleyinternet.net Tue May 29 14:24:41 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 29 May 2018 10:24:41 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <218566457.590.1527603418678.JavaMail.mhammett@ThunderFuck> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> <218566457.590.1527603418678.JavaMail.mhammett@ThunderFuck> Message-ID: Multiple providers. I don’t think I should publicly name them for various reasons. You are a smart man though and can probably figure it out from BGP peering tables. > On May 29, 2018, at 10:17, Mike Hammett wrote: > > Is that PennRen\Kinber? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Matt Hoppes" > To: "Lamar Owen" > Cc: nanog at nanog.org > Sent: Tuesday, May 29, 2018 8:27:17 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > > I am incredibly rural in Pennsylvania and pay about $.50 per megabit. > >>> On May 29, 2018, at 09:23, Lamar Owen wrote: >>> >>> On 05/28/2018 06:13 PM, Matthew Petach wrote: >>> Your 200mbit/sec link that costs you $300 in hardware >>> is going to cost you $4960/month to actually get IP traffic >>> across, in Nairobi. Yes, that's about $60,000/year. >> I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land. Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here. I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. >> >> The terrain here prevents fixed wireless. The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight). I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup. If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. >> >> I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. >> >> I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank). DSL started out here at 384k/128k. On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. >> >> (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) >> >> So it's not just '3rd-world' countries with expensive bandwidth. >> > From nanog at ics-il.net Tue May 29 14:27:56 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 29 May 2018 09:27:56 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> <218566457.590.1527603418678.JavaMail.mhammett@ThunderFuck> Message-ID: <1712848730.621.1527604072697.JavaMail.mhammett@ThunderFuck> I know who you have and it's easily found who you use. I was implying exactly what "ML" said". ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Matt Hoppes" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Tuesday, May 29, 2018 9:24:41 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) Multiple providers. I don’t think I should publicly name them for various reasons. You are a smart man though and can probably figure it out from BGP peering tables. > On May 29, 2018, at 10:17, Mike Hammett wrote: > > Is that PennRen\Kinber? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Matt Hoppes" > To: "Lamar Owen" > Cc: nanog at nanog.org > Sent: Tuesday, May 29, 2018 8:27:17 AM > Subject: Re: Impacts of Encryption Everywhere (any solution?) > > I am incredibly rural in Pennsylvania and pay about $.50 per megabit. > >>> On May 29, 2018, at 09:23, Lamar Owen wrote: >>> >>> On 05/28/2018 06:13 PM, Matthew Petach wrote: >>> Your 200mbit/sec link that costs you $300 in hardware >>> is going to cost you $4960/month to actually get IP traffic >>> across, in Nairobi. Yes, that's about $60,000/year. >> I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land. Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here. I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. >> >> The terrain here prevents fixed wireless. The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight). I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup. If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. >> >> I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. >> >> I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank). DSL started out here at 384k/128k. On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. >> >> (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) >> >> So it's not just '3rd-world' countries with expensive bandwidth. >> > From mark.tinka at seacom.mu Tue May 29 14:38:46 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 16:38:46 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> On 29/May/18 16:16, John R. Levine wrote: > > My goodness, aren't we condescending.  Since we're talking about Kenya > here, a few milliseconds of research reminds us that it's a > significant agricultural exporter.  Agricultural development there is > generally about better use of existing land. > > You might also want to learn about M-Pesa, the mobile phone payment > system that everybody uses.  Stores all have a sign with their M-Pesa > number so you can pay them, and there are kiosks all over Nairobi that > will exchange M-Pesa credit and cash.  The 1GB data bundles I > mentioned are large ones. You can get 7MB for a day or 5MB for a week > for 5c, which is plenty to check your messages or look up farm prices. > > People in Africa may be poorer than we are, but they are just as smart > as we are, and they are just as able and interested in technology when > it is useful to them. It's pretty difficult to articulate this sort of thing unless someone has actually traveled to and experienced a destination, and its peoples, on their own. Having had the opportunity to travel the world over the past 2 or more decades, I've been eagerly disillusioned by what I thought a lot of countries were either capable of, or not capable of. What I learned... you can't armchair reality. The Internet in Indonesia is the very same Internet in Eritrea, as it is in Canada. We can't quite split that... Mark. From bicknell at ufp.org Tue May 29 14:44:13 2018 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 29 May 2018 07:44:13 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: <20180529144413.GA36608@ussenterprise.ufp.org> In a message written on Mon, May 28, 2018 at 09:23:09AM -0500, Mike Hammett wrote: > However, this could be wildly improved with caching ala squid or something similar. The problem is that encrypted content is difficult to impossible for your average Joe to cache. The rewards for implementing caching are greatly mitigated and people like this must suffer a worse Internet experience because of some ideological high horse in a far-off land. > > Some things certainly do need to be encrypted, but encrypting everything means people with limited Internet access get worse performance OR mechanisms have to be out in place to break ALL encryption, this compromising security and privacy when it's really needed. I'm going to take this question head on, as opposed to the many tangents in this thread. The Internet lived in the world you described, and a lot of people learned a lot of things along the way. Perhaps the most important lessons: - Users cannot be trusted to check if there is a "secure" indicator before sending sensitive information. - Users cannot tell the difference between two "secure" sites, one of which is a phishing site that just happens to have a certificate. - There is no algorithmic way to determine if mixed mode content is "safe". - Web site operators seem incapable of maintaining white lists of safe mixed mode content. - Mixed mode content is not safe due to browser bugs. - Once users have been trained that it's ok to send content via some insecure channels, it's nearly impossible to untrain them of it later. Basically, while you presented the "pro" side of unencrypted content (being able to cache), you didn't present any of the negative side. I have to wonder if the villagers were given a choice of faster internet, where 5% of them had their bank account cleaned out, and 5% had their identity stolen, or slower, secure internet which they would choose? Want a technological solution? It exists! Signed content. I've always been baffled why there isn't a way to serve up HTTP signed (but not encrypted) content. I'd imagine the way it would work is: 1) Initial connection had to be HTTPS encrypted to create a full encrypted channel. 2) Additional assets could then be downloaded as HTTPS, or as HTTP + Signature. Signature must be from the same certificate as the HTTPS data. The http+signature data could then be cashed just fine, and stored in the clear. The web site could determine what to serve up that way to maintain security. All POST commands would have to be HTTPS (data from client to server), and of course sensitive information would be returned HTTPS only. Why doesn't that exist? -- 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 andy at newslink.com Tue May 29 15:09:04 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 29 May 2018 10:09:04 -0500 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180529144413.GA36608@ussenterprise.ufp.org> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180529144413.GA36608@ussenterprise.ufp.org> Message-ID: <04ECC70B-E38E-4B1D-AAC4-01F4C61E27D0@newslink.com> > On May 29, 2018, at 9:44 AM, Leo Bicknell wrote: > > Basically, while you presented the "pro" side of unencrypted content > (being able to cache), you didn't present any of the negative side. > I have to wonder if the villagers were given a choice of faster > internet, where 5% of them had their bank account cleaned out, and 5% > had their identity stolen, or slower, secure internet which they would > choose? If you’re in $TinyVillage in $PoorAfricanCountry, do you even have a bank account or an online identity that could be stolen? Just my $0.02 on this increasingly off-topic thread. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From mark.tinka at seacom.mu Tue May 29 15:14:36 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 17:14:36 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <04ECC70B-E38E-4B1D-AAC4-01F4C61E27D0@newslink.com> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180529144413.GA36608@ussenterprise.ufp.org> <04ECC70B-E38E-4B1D-AAC4-01F4C61E27D0@newslink.com> Message-ID: On 29/May/18 17:09, Andy Ringsmuth wrote: > If you’re in $TinyVillage in $PoorAfricanCountry, do you even have a bank account or an online identity that could be stolen? Bank accounts are so 2018...     https://en.wikipedia.org/wiki/M-Pesa Where've you been, man :-)... Mark. From randy at psg.com Tue May 29 15:23:37 2018 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2018 08:23:37 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <04ECC70B-E38E-4B1D-AAC4-01F4C61E27D0@newslink.com> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180529144413.GA36608@ussenterprise.ufp.org> <04ECC70B-E38E-4B1D-AAC4-01F4C61E27D0@newslink.com> Message-ID: northerners who have never traveled pontificating about africa might, or might not, be interested in https://afrinic.net/blog/333-revealing-latency-clusters-in-africa randy From eric.kuhnke at gmail.com Tue May 29 16:03:13 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 29 May 2018 09:03:13 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180529144413.GA36608@ussenterprise.ufp.org> <04ECC70B-E38E-4B1D-AAC4-01F4C61E27D0@newslink.com> Message-ID: Based on my experience a couple of years ago while in West Africa: If you look at the BGP adjacencies and bidirectional traceroutes for ISPs in Sierra Leone or Liberia; Freetown and Monrovia are both are logically suburbs of London. Just with much higher transport latencies via the submarine fiber link and then transport from UK cable landing station to the IX points in London. The situation is a bit different in Accra, Ghana which is a much larger and more economically developed market, and has IXes and ISPs that peer with each other domestically. On Tue, May 29, 2018 at 8:23 AM, Randy Bush wrote: > northerners who have never traveled pontificating about africa might, or > might not, be interested in > > https://afrinic.net/blog/333-revealing-latency-clusters-in-africa > > randy > From mark.tinka at seacom.mu Tue May 29 16:19:34 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 May 2018 18:19:34 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180529144413.GA36608@ussenterprise.ufp.org> <04ECC70B-E38E-4B1D-AAC4-01F4C61E27D0@newslink.com> Message-ID: On 29/May/18 18:03, Eric Kuhnke wrote: > Based on my experience a couple of years ago while in West Africa: > > If you look at the BGP adjacencies and bidirectional traceroutes for ISPs > in Sierra Leone or Liberia; Freetown and Monrovia are both are logically > suburbs of London. Just with much higher transport latencies via the > submarine fiber link and then transport from UK cable landing station to > the IX points in London. > > The situation is a bit different in Accra, Ghana which is a much larger and > more economically developed market, and has IXes and ISPs that peer with > each other domestically. West Africa has generally lagged a little behind compared to Eastern and Southern Africa, with regard to closing connectivity gaps within the local and regional space. The good news is that places such as Ghana and Nigeria have made excellent strides in fixing this, as you point out. The work being done by AfPIF (part of ISOC), AFRINIC and a bunch of country- and region-level NOG's has gone a long a way in promoting local and regional connectivity through traditional and other means, and we have seen the fruits of that labour. Mark. From owen at delong.com Tue May 29 17:15:24 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2018 10:15:24 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180529144413.GA36608@ussenterprise.ufp.org> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <20180529144413.GA36608@ussenterprise.ufp.org> Message-ID: <64B2F572-A61F-4594-A968-C5578104EA03@delong.com> > > The http+signature data could then be cashed just fine, and stored in > the clear. The web site could determine what to serve up that way to > maintain security. All POST commands would have to be HTTPS (data from > client to server), and of course sensitive information would be returned > HTTPS only. Makes a lot of sense, but… Wouldn’t you also have to require that all GET commands (or at lest GET commands for strings containing a ? character) be sent via HTTPS? In many cases, there’s little difference between the data disclosure of a POST form vs. the disclosure achieved with GET URL?attribute=value&… Indeed, there are multiple libraries out there which allow one to treat the variables from POST data and the variables from GET “query strings” as virtually identical. I suspect that in most cases, the only reason said libraries distinguish is to maintain namespace separation in case of collisions (since query strings can also be applied to POST requests). > Why doesn't that exist? Because developers are lazy? Owen From owen at delong.com Tue May 29 17:21:18 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2018 10:21:18 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> References: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> Message-ID: <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> > > The Internet in Indonesia is the very same Internet in Eritrea, as it is > in Canada. We can't quite split that… I admit that I haven’t been to Eritrea or Indonesia, but using Ethiopia and Malaysia as stand-ins (which I have been to), I can say that while they are the same internet, the level of development, the payment systems which are usable via said internet, and other aspects of the daily use and capabilities which can be utilized on the internet in those countries does vary greatly. For example, Apple Pay is somewhat ubiquitous in Canada. It’s virtually unheard of in Ethiopia. My travels to Malaysia were not recent enough for me to comment accurately on the current state of things. M-Pesa is widely accepted in Kenya, but not at all in the US or Canada. PayPal is popular in the US, but not so much in most of the rest of the world. YMMV. IPv6 is readily available on almost every mobile phone in the US. Less so in Kenya or Tanzania, Eritrea, Canada, or Indonesia. While all connected networks are part of the same big I Internet, not all networks are created or maintained equal and not all services on those networks are ubiquitously available to all users of the big I Internet. Owen From owen at delong.com Tue May 29 17:27:16 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2018 10:27:16 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <5b483f0f-0a0b-dcdc-2491-9025626162ce@kenweb.org> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> <15ed449c-f2ce-bb11-34ec-4881e363de6e@spamtrap.tnetconsulting.net> <2027657794.226.1527530274030.JavaMail.mhammett@ThunderFuck> <6BD7E413-02E7-420E-9E6F-C3B5443B5598@6by7.net> <738845c7-f3cc-ba1a-2a3e-6f6a0c12ec5f@pari.edu> <157CD1FE-5F46-405F-99DA-D04B5849E4D1@rivervalleyinternet.net> <218566457.590.1527603418678.JavaMail.mhammett@ThunderFuck> <5b483f0f-0a0b-dcdc-2491-9025626162ce@kenweb.org> Message-ID: Ah, the wonderful USF. Here’s my take on USF. It’s a perfectly wonderful intent whose implementation has gone horribly horribly wrong. Instead of equalizing economic incentives for infrastructure between rural, urban, and suburban areas, it has heavily tilted the incentives in favor of the highest densities that still qualify as rural while pretty much screwing over everyone else. Extremely high density urban areas still have sufficient economic opportunity over lower infrastructure cost per user to attract some development. However, Suburbia is the biggest loser in this equation. Don’t get me wrong… I’m perfectly fine with the idea that I need to make a small payment to subsidize delivery of decent network infrastructure to underserved areas. What bothers me is that I’m generally paying this tax to enable farmers in the middle of nowhere to have better network infrastructure than I can get at my own location. I’m happy to subsidize equality of connectivity, but it galls me to have to subsidize GPON for others while there’s not even a glimmer of hope that anyone will usefully lay fiber in my neighborhood in the foreseeable future. Owen > On May 29, 2018, at 07:23 , ML wrote: > > $100M+ in federal dollars goes a long way. > > > On 5/29/2018 10:17 AM, Mike Hammett wrote: >> Is that PennRen\Kinber? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Matt Hoppes" >> To: "Lamar Owen" >> Cc: nanog at nanog.org >> Sent: Tuesday, May 29, 2018 8:27:17 AM >> Subject: Re: Impacts of Encryption Everywhere (any solution?) >> >> I am incredibly rural in Pennsylvania and pay about $.50 per megabit. >> >>> On May 29, 2018, at 09:23, Lamar Owen wrote: >>> >>>> On 05/28/2018 06:13 PM, Matthew Petach wrote: >>>> Your 200mbit/sec link that costs you $300 in hardware >>>> is going to cost you $4960/month to actually get IP traffic >>>> across, in Nairobi. Yes, that's about $60,000/year. >>> I live in the US of A, and this is what 200Mb/s roughly would cost me as well here in Rural Monopoly-land. Rural ILEC also has the CATV business, and, well, they are _not_ going to run cable up here. I've actually priced 150Mb/s bandwidth from the ILEC over the years; in 2003 the cost would have been about $100,000 per month. As of five years ago 10Mb/s symmetrical cost roughly $1,000 per month, the lion's share of that being per-mile NECA Tariff 5 transport costs. >>> >>> The terrain here prevents fixed wireless. The terrain also prevents satellite comms to the Clarke belt (mountain to the south with trees on US Forest Service property in the line of sight). I get 1XRTT in one room of my house when the humidity is below 70% and it's winter, and once in a blue moon 3G will light up, but it's not stable enough to actually use; it's the speed of dialup. If I traipse about a hundred yards up the mountain to the south (onto US Forest Service property, so, no repeater for me) I can get semi-usable 4G; nothing like being in the middle of the woods with an active black bear population trying to get a usable signal. >>> >>> I'm paying $50 per month for 7/0.5 DSL (I might add that they provide excellent DSL that has been extremely reliable) from the only ISP available in the area. >>> >>> I remember a usable web experience not too long ago on 28.8K/33.6K dialup (it was quite a while before said ILEC got a 56K-capable modem bank). DSL started out here at 384k/128k. On the positive side, we have a very low oversubscription ratio, so I actually get the full bandwidth the majority of the time, even video streaming. I also know all the network engineers there, too, and that also has its advantages. >>> >>> (Yes, I am aware that rural living is a choice, and there are things worth a great deal more than bandwidth, that it's a tradeoff, etc.) >>> >>> So it's not just '3rd-world' countries with expensive bandwidth. >>> From owen at delong.com Tue May 29 17:47:31 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2018 10:47:31 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <20180529000502.946FF0B7@m0117567.ppops.net> References: <20180529000502.946FF0B7@m0117567.ppops.net> Message-ID: <94577246-833A-4153-95CB-AA70B044E14B@delong.com> > On May 29, 2018, at 00:05 , Scott Weeks wrote: > > > I believe you were responding to me, but it was really > hard to tell. If so, here's the conversation... > >> Also, please don't just look at continental countries >> when researching. Look at the small PICs (Pacific >> Island Countries). For example, search the posts from >> Christian on Kiribati on the PICISOC list. The cost is >> extraordinary and all the ego-flattering bloat rsk >> speaks (relevant part of the post id below) of in very >> expensive to download and is nearly impossible to stop. > > --- ben at 6by7.net wrote: > From: Ben Cannon > > Then Africa in particular is specifically disadvantaged > - I spent a good deal of time in Haiti and 4G connectivity > was abundant at good speeds, as were terrestrial fiber > connections. > > Mirrors my experience in half a dozen other 3rd world > countries. Unless there’s something particularly > oppressive about Africa? > -------------------------------------- > > > I guess I was more meaning in the Pacific, since I'm > from there. And more particularly places like Kiribati, > Cook Islands, Marquesas and other far flung Pacific > Island Countries. My apologies for the confusion. Hati > and other countries close to a rich mainland country > do not suffer the same issues due to geography. While Haiti is clos-ER to a rich mainland country than those you mentioned, I would not say that it lacks geographic challenges. They might be a bit less since (more importantly) fiber has to run past (and thus conveniently to) Hispañola (the Island containing Haiti and the DR) in order to traverse other destinations which obviously is not the case in the areas you mention above. Almost every area I am aware of in the developing world has some combination of challenges which drive its continued lagging behind more developed areas. This can, by the way, include parts of developed nations which are underserved due to geographic challenges such as some rural areas of the united States as mentioned earlier. These challenges can include any combination of economic, geographic, geologic, terrain, cultural, political, population density, etc. One thing I have found very interesting in my travels… Every area with challenges seems to think that their challenges are so unique that solutions that have proven elsewhere cannot possibly work for them. Every area with challenges almost always has more in common with the other areas with challenges than they perceive. I guess it is easier to talk about why things will not work than do the hard work of adapting solutions to the differences which do matter. Owen From owen at delong.com Tue May 29 17:55:49 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2018 10:55:49 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> Message-ID: <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> 4G depends on Radio. Radio works very well in an environment like Hispañola (the island containing Haiti and Dominican Republic). You’ve got some convenient very high central locations, lots of nice conductive ground-plane salt-water surrounding the area, and very little terrain interference from those high points to the vast majority of the island. Africa has a much larger and more diverse geography. The water surrounding it is much much further from the central locations and the central locations are NOT proportionately has high above (and in some cases even below) the surrounding terrain. Africa also has a wide variety of political and cultural issues and multiple distinct political frameworks to deal with. (Haiti has only one and if you throw in all of Hispañola, you still only have 2). There are parts of Africa where 4G works relatively well. There are parts where you’re lucky if you can get anything at all. There are parts where electricity, indoor plumbing, and safe drinking water would be a novelty. (Of course that last one is true in Haiti as well). Indeed, I think the biggest thing to realize is that speaking of Africa as if it were a single place is as big a failure as speaking of Asia like it is a single place. Both consist of many countries, many cultures, a wide variety of terrains and geological and geographical features, and a great diversity of experiences to be had. Angola is as different from Zambia as Afghanistan is from Vietnam. Owen > On May 28, 2018, at 23:36 , Ben Cannon wrote: > > Then Africa in particular is specifically disadvantaged - I spent a good deal of time in Haiti and 4G connectivity was abundant at good speeds, as were terrestrial fiber connections. > > Mirrors my experience in half a dozen other 3rd world countries. Unless there’s something particularly oppressive about Africa? > >> On May 28, 2018, at 5:06 PM, Scott Weeks wrote: >> >> --- mpetach at netflight.com wrote: >> From: Matthew Petach >> On Mon, May 28, 2018 at 11:22 AM, Ben Cannon wrote: >> >>> I’m sorry I simply believe that in 2018 with the advanced and cheap ptp >>> radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over 10miles! >>> Spend a bit more and go 100km) plus the advancements in cubesats about to >>> be launched, even the 3rd world can simply get with the times. >> >> I do not think you adequately understand the economics of the >> situation. >> >> https://www.slideshare.net/InternetSociety/international-bandwidth-and-pricing-trends-in-subsahara-africa-79147043 >> >> slide 22, IP transit cost. >> >> Your 200mbit/sec link that costs you $300 in hardware >> is going to cost you $4960/month to actually get IP traffic >> across, in Nairobi. Yes, that's about $60,000/year. >> >> Could *you* afford to "get with the times" if that's what >> your bandwidth was going to cost you? >> >> Please, do a little research on what the real >> costs are before telling others they need to >> "simply get with the times." >> ----------------------------------------- >> >> >> >> Also, please don't just look at continental countries >> when researching. Look at the small PICs (Pacific >> Island Countries). For example, search the posts from >> Christian on Kiribati on the PICISOC list. The cost is >> extraordinary and all the ego-flattering bloat rsk >> speaks (relevant part of the post id below) of in very >> expensive to download and is nearly impossible to stop. >> >> scott >> >> >> >> * >>> The problem (part of the problem) is that the people doing these foolish >>> things are new, ignorant, and privileged: they don't realize that bandwidth >>> is still an expensive and scarce resource for most of the planet. I've >>> said for years that every web designer should be forced to work in an >>> environment bandlimited to 56K in order to instll in them the virtue >>> of frugality and strongly discourage them from flattering their egos >>> by creating all-singing all-dancing web sites...that look great in the >>> portfolios they'll show to their peers but are horribly bloated, slow, >>> unrenderable in a lot of browsers, and fraught with security and privacy >>> problems. (Try pointing a text-only browser at your favorite website. >>> Can you even read the home page?) >> >> >> > From eric.kuhnke at gmail.com Tue May 29 17:58:25 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 29 May 2018 10:58:25 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> References: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> Message-ID: Ethiopia is significantly different and unique, in its own unusual way, because of the government monopoly telecom. Other people can correct me if I'm wrong, but unless the situation has changed in the past two years, all small to medium sized ISPs in Ethiopia are mandated by law to be downstream of the government run telecom ASN. Also the government owned national telecom has a monopoly on all international fiber connections to neighboring countries (at OSI layer 1), and for things like STM/SDH or 1/10/ Gbps Ethernet L2 transport services to any location outside of Ethiopia. The Ethiopian Internet is also subject to significant censorship and attempted blockage of VPN and VoIP services. https://www.google.com/search?q=ethiopia+internet+censorship&oq=ethiopia+internet+censorship&aqs=chrome.0.0j69i57.2857j0j7&sourceid=chrome&ie=UTF-8 On Tue, May 29, 2018 at 10:21 AM, Owen DeLong wrote: > > > > The Internet in Indonesia is the very same Internet in Eritrea, as it is > > in Canada. We can't quite split that… > > I admit that I haven’t been to Eritrea or Indonesia, but using Ethiopia > and Malaysia as stand-ins (which I have been to), I can say that while they > are the same internet, the level of development, the payment systems which > are usable via said internet, and other aspects of the daily use and > capabilities > which can be utilized on the internet in those countries does vary greatly. > > For example, Apple Pay is somewhat ubiquitous in Canada. It’s virtually > unheard > of in Ethiopia. My travels to Malaysia were not recent enough for me to > comment > accurately on the current state of things. > > M-Pesa is widely accepted in Kenya, but not at all in the US or Canada. > > PayPal is popular in the US, but not so much in most of the rest of the > world. > > YMMV. > > IPv6 is readily available on almost every mobile phone in the US. Less so > in > Kenya or Tanzania, Eritrea, Canada, or Indonesia. > > While all connected networks are part of the same big I Internet, not all > networks > are created or maintained equal and not all services on those networks are > ubiquitously available to all users of the big I Internet. > > Owen > > From owen at delong.com Tue May 29 18:00:22 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2018 11:00:22 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> Message-ID: <29F4DD8E-7177-4387-8E9D-C9644EB21D82@delong.com> It was a convenient example with which I had experience near Eritrea. My statement would apply equally for say, Zambia or Morocco. Owen > On May 29, 2018, at 10:58 , Eric Kuhnke wrote: > > Ethiopia is significantly different and unique, in its own unusual way, because of the government monopoly telecom. Other people can correct me if I'm wrong, but unless the situation has changed in the past two years, all small to medium sized ISPs in Ethiopia are mandated by law to be downstream of the government run telecom ASN. Also the government owned national telecom has a monopoly on all international fiber connections to neighboring countries (at OSI layer 1), and for things like STM/SDH or 1/10/ Gbps Ethernet L2 transport services to any location outside of Ethiopia. > > The Ethiopian Internet is also subject to significant censorship and attempted blockage of VPN and VoIP services. > > https://www.google.com/search?q=ethiopia+internet+censorship&oq=ethiopia+internet+censorship&aqs=chrome.0.0j69i57.2857j0j7&sourceid=chrome&ie=UTF-8 > > > > > > On Tue, May 29, 2018 at 10:21 AM, Owen DeLong > wrote: > > > > The Internet in Indonesia is the very same Internet in Eritrea, as it is > > in Canada. We can't quite split that… > > I admit that I haven’t been to Eritrea or Indonesia, but using Ethiopia > and Malaysia as stand-ins (which I have been to), I can say that while they > are the same internet, the level of development, the payment systems which > are usable via said internet, and other aspects of the daily use and capabilities > which can be utilized on the internet in those countries does vary greatly. > > For example, Apple Pay is somewhat ubiquitous in Canada. It’s virtually unheard > of in Ethiopia. My travels to Malaysia were not recent enough for me to comment > accurately on the current state of things. > > M-Pesa is widely accepted in Kenya, but not at all in the US or Canada. > > PayPal is popular in the US, but not so much in most of the rest of the world. > > YMMV. > > IPv6 is readily available on almost every mobile phone in the US. Less so in > Kenya or Tanzania, Eritrea, Canada, or Indonesia. > > While all connected networks are part of the same big I Internet, not all networks > are created or maintained equal and not all services on those networks are > ubiquitously available to all users of the big I Internet. > > Owen > > From eric.kuhnke at gmail.com Tue May 29 18:01:13 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 29 May 2018 11:01:13 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> Message-ID: The one thing that you CAN generalize about a great many developing nation telecom markets, which is different than the US and Western Europe: Many urban locations have a complete absence of functioning last mile, legacy copper telecom infrastructure, which in a US city you would see used for ADSL2+ or VDSL2 or g.fast on old POTS phone lines, or DOCSIS3.0/DOCSIS3.1 on 75 ohm coaxial cable TV plant. Leaving "4G" and various forms of fixed point to multipoint wireless, whether LTE based or not, as the only viable residential and SMB broadband service option. On Tue, May 29, 2018 at 10:55 AM, Owen DeLong wrote: > 4G depends on Radio. Radio works very well in an environment like > Hispañola (the island containing Haiti and Dominican Republic). > > You’ve got some convenient very high central locations, lots of nice > conductive ground-plane salt-water surrounding the area, and very little > terrain interference from those high points to the vast majority of the > island. > > Africa has a much larger and more diverse geography. The water surrounding > it is much much further from the central locations and the central > locations are NOT proportionately has high above (and in some cases even > below) the surrounding terrain. > > Africa also has a wide variety of political and cultural issues and > multiple distinct political frameworks to deal with. (Haiti has only one > and if you throw in all of Hispañola, you still only have 2). > > There are parts of Africa where 4G works relatively well. There are parts > where you’re lucky if you can get anything at all. There are parts where > electricity, indoor plumbing, and safe drinking water would be a novelty. > (Of course that last one is true in Haiti as well). > > Indeed, I think the biggest thing to realize is that speaking of Africa as > if it were a single place is as big a failure as speaking of Asia like it > is a single place. Both consist of many countries, many cultures, a wide > variety of terrains and geological and geographical features, and a great > diversity of experiences to be had. > > Angola is as different from Zambia as Afghanistan is from Vietnam. > > Owen > > > > On May 28, 2018, at 23:36 , Ben Cannon wrote: > > > > Then Africa in particular is specifically disadvantaged - I spent a good > deal of time in Haiti and 4G connectivity was abundant at good speeds, as > were terrestrial fiber connections. > > > > Mirrors my experience in half a dozen other 3rd world countries. Unless > there’s something particularly oppressive about Africa? > > > >> On May 28, 2018, at 5:06 PM, Scott Weeks > wrote: > >> > >> --- mpetach at netflight.com wrote: > >> From: Matthew Petach > >> On Mon, May 28, 2018 at 11:22 AM, Ben Cannon wrote: > >> > >>> I’m sorry I simply believe that in 2018 with the advanced and cheap ptp > >>> radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over > 10miles! > >>> Spend a bit more and go 100km) plus the advancements in cubesats about > to > >>> be launched, even the 3rd world can simply get with the times. > >> > >> I do not think you adequately understand the economics of the > >> situation. > >> > >> https://www.slideshare.net/InternetSociety/international- > bandwidth-and-pricing-trends-in-subsahara-africa-79147043 > >> > >> slide 22, IP transit cost. > >> > >> Your 200mbit/sec link that costs you $300 in hardware > >> is going to cost you $4960/month to actually get IP traffic > >> across, in Nairobi. Yes, that's about $60,000/year. > >> > >> Could *you* afford to "get with the times" if that's what > >> your bandwidth was going to cost you? > >> > >> Please, do a little research on what the real > >> costs are before telling others they need to > >> "simply get with the times." > >> ----------------------------------------- > >> > >> > >> > >> Also, please don't just look at continental countries > >> when researching. Look at the small PICs (Pacific > >> Island Countries). For example, search the posts from > >> Christian on Kiribati on the PICISOC list. The cost is > >> extraordinary and all the ego-flattering bloat rsk > >> speaks (relevant part of the post id below) of in very > >> expensive to download and is nearly impossible to stop. > >> > >> scott > >> > >> > >> > >> * > >>> The problem (part of the problem) is that the people doing these > foolish > >>> things are new, ignorant, and privileged: they don't realize that > bandwidth > >>> is still an expensive and scarce resource for most of the planet. I've > >>> said for years that every web designer should be forced to work in an > >>> environment bandlimited to 56K in order to instll in them the virtue > >>> of frugality and strongly discourage them from flattering their egos > >>> by creating all-singing all-dancing web sites...that look great in the > >>> portfolios they'll show to their peers but are horribly bloated, slow, > >>> unrenderable in a lot of browsers, and fraught with security and > privacy > >>> problems. (Try pointing a text-only browser at your favorite website. > >>> Can you even read the home page?) > >> > >> > >> > > > > From bz_siege_01 at hotmail.com Tue May 29 18:32:03 2018 From: bz_siege_01 at hotmail.com (LF OD) Date: Tue, 29 May 2018 18:32:03 +0000 Subject: Opinions on intent-based networking Message-ID: Been following the articles on "intent-based" networking from Cisco and other vendors for a couple years now, and I have a basic grasp of the concept of "define your goals/outcomes and automation will make it so", but I do not know the practical applications of it or how you are supposed to convey your "intent". However, $dayjob is a medium-sized enterprise and looking at a potential refresh in the upcoming budget. So... do any of you at ISPs, Cloud Providers, or Enterprises have any hands-on experience with "intent-based" networking products? If so, could you please provide some info on what caused you to look at it, who did you look at, why did you choose whoever you chose, and is it working out for you? If you looked at it very closely and decided not to bother with it, I'd also be interested on your take. At $dayjob we have been adopting automation at the application and workload level, but there hasn't been much need for it at the infrastructure level. However, if we can improve the services we offer while refreshing that infrastructure, it wouldn't hurt - depending on cost of course. Thanks in advance. LF0D From randy at psg.com Tue May 29 18:34:45 2018 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2018 11:34:45 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> Message-ID: > Ethiopia is significantly different and unique, in its own unusual > way, because of the government monopoly telecom. sadly, these are far from unique; not only in africa, but asia, oceania, even alyc, ... randy From mh at xalto.net Tue May 29 19:16:42 2018 From: mh at xalto.net (Michael Hallgren) Date: Tue, 29 May 2018 21:16:42 +0200 Subject: Opinions on intent-based networking In-Reply-To: References: Message-ID: BGP? :-) mh Le 2018-05-29 20:32, LF OD a écrit : > Been following the articles on "intent-based" networking from Cisco > and other vendors for a couple years now, and I have a basic grasp of > the concept of "define your goals/outcomes and automation will make it > so", but I do not know the practical applications of it or how you are > supposed to convey your "intent". However, $dayjob is a medium-sized > enterprise and looking at a potential refresh in the upcoming budget. > > > So... do any of you at ISPs, Cloud Providers, or Enterprises have any > hands-on experience with "intent-based" networking products? If so, > could you please provide some info on what caused you to look at it, > who did you look at, why did you choose whoever you chose, and is it > working out for you? > > > If you looked at it very closely and decided not to bother with it, > I'd also be interested on your take. At $dayjob we have been adopting > automation at the application and workload level, but there hasn't > been much need for it at the infrastructure level. However, if we can > improve the services we offer while refreshing that infrastructure, it > wouldn't hurt - depending on cost of course. > > > Thanks in advance. > > LF0D From mh at xalto.net Tue May 29 19:19:40 2018 From: mh at xalto.net (Michael Hallgren) Date: Tue, 29 May 2018 21:19:40 +0200 Subject: Impacts of Encryption Everywhere (any =?UTF-8?Q?solution=3F?= =?UTF-8?Q?=29?= In-Reply-To: <29F4DD8E-7177-4387-8E9D-C9644EB21D82@delong.com> References: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> <29F4DD8E-7177-4387-8E9D-C9644EB21D82@delong.com> Message-ID: <5a7feaaa1b0520227459f610442e835b@webmail.xalto.net> Morocco... Sure? Data points? mh Le 2018-05-29 20:00, Owen DeLong a écrit : > It was a convenient example with which I had experience near Eritrea. > > My statement would apply equally for say, Zambia or Morocco. > > Owen > > >> On May 29, 2018, at 10:58 , Eric Kuhnke wrote: >> >> Ethiopia is significantly different and unique, in its own unusual >> way, because of the government monopoly telecom. Other people can >> correct me if I'm wrong, but unless the situation has changed in the >> past two years, all small to medium sized ISPs in Ethiopia are >> mandated by law to be downstream of the government run telecom ASN. >> Also the government owned national telecom has a monopoly on all >> international fiber connections to neighboring countries (at OSI layer >> 1), and for things like STM/SDH or 1/10/ Gbps Ethernet L2 transport >> services to any location outside of Ethiopia. >> >> The Ethiopian Internet is also subject to significant censorship and >> attempted blockage of VPN and VoIP services. >> >> https://www.google.com/search?q=ethiopia+internet+censorship&oq=ethiopia+internet+censorship&aqs=chrome.0.0j69i57.2857j0j7&sourceid=chrome&ie=UTF-8 >> >> >> >> >> >> >> On Tue, May 29, 2018 at 10:21 AM, Owen DeLong > > wrote: >> > >> > The Internet in Indonesia is the very same Internet in Eritrea, as it is >> > in Canada. We can't quite split that… >> >> I admit that I haven’t been to Eritrea or Indonesia, but using >> Ethiopia >> and Malaysia as stand-ins (which I have been to), I can say that while >> they >> are the same internet, the level of development, the payment systems >> which >> are usable via said internet, and other aspects of the daily use and >> capabilities >> which can be utilized on the internet in those countries does vary >> greatly. >> >> For example, Apple Pay is somewhat ubiquitous in Canada. It’s >> virtually unheard >> of in Ethiopia. My travels to Malaysia were not recent enough for me >> to comment >> accurately on the current state of things. >> >> M-Pesa is widely accepted in Kenya, but not at all in the US or >> Canada. >> >> PayPal is popular in the US, but not so much in most of the rest of >> the world. >> >> YMMV. >> >> IPv6 is readily available on almost every mobile phone in the US. Less >> so in >> Kenya or Tanzania, Eritrea, Canada, or Indonesia. >> >> While all connected networks are part of the same big I Internet, not >> all networks >> are created or maintained equal and not all services on those networks >> are >> ubiquitously available to all users of the big I Internet. >> >> Owen >> >> From mel at beckman.org Tue May 29 19:21:38 2018 From: mel at beckman.org (Mel Beckman) Date: Tue, 29 May 2018 19:21:38 +0000 Subject: Opinions on intent-based networking In-Reply-To: References: Message-ID: It’s just another lame buzzword. As if all prior networking designs were random! Sheesh! The Montecarlo method is only used in statistics :) -mel > On May 29, 2018, at 12:16 PM, Michael Hallgren wrote: > > BGP? :-) > > mh > > Le 2018-05-29 20:32, LF OD a écrit : >> Been following the articles on "intent-based" networking from Cisco >> and other vendors for a couple years now, and I have a basic grasp of >> the concept of "define your goals/outcomes and automation will make it >> so", but I do not know the practical applications of it or how you are >> supposed to convey your "intent". However, $dayjob is a medium-sized >> enterprise and looking at a potential refresh in the upcoming budget. >> So... do any of you at ISPs, Cloud Providers, or Enterprises have any >> hands-on experience with "intent-based" networking products? If so, >> could you please provide some info on what caused you to look at it, >> who did you look at, why did you choose whoever you chose, and is it >> working out for you? >> If you looked at it very closely and decided not to bother with it, >> I'd also be interested on your take. At $dayjob we have been adopting >> automation at the application and workload level, but there hasn't >> been much need for it at the infrastructure level. However, if we can >> improve the services we offer while refreshing that infrastructure, it >> wouldn't hurt - depending on cost of course. >> Thanks in advance. >> LF0D > From kscott.helms at gmail.com Tue May 29 19:29:44 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Tue, 29 May 2018 15:29:44 -0400 Subject: Opinions on intent-based networking In-Reply-To: References: Message-ID: A substantial percentage, perhaps 100%, of the use case can be accomplished using micro-segmentation. On Tue, May 29, 2018 at 2:33 PM LF OD wrote: > Been following the articles on "intent-based" networking from Cisco and > other vendors for a couple years now, and I have a basic grasp of the > concept of "define your goals/outcomes and automation will make it so", but > I do not know the practical applications of it or how you are supposed to > convey your "intent". However, $dayjob is a medium-sized enterprise and > looking at a potential refresh in the upcoming budget. > > > So... do any of you at ISPs, Cloud Providers, or Enterprises have any > hands-on experience with "intent-based" networking products? If so, could > you please provide some info on what caused you to look at it, who did you > look at, why did you choose whoever you chose, and is it working out for > you? > > > If you looked at it very closely and decided not to bother with it, I'd > also be interested on your take. At $dayjob we have been adopting > automation at the application and workload level, but there hasn't been > much need for it at the infrastructure level. However, if we can improve > the services we offer while refreshing that infrastructure, it wouldn't > hurt - depending on cost of course. > > > Thanks in advance. > > LF0D > From ben at 6by7.net Tue May 29 19:49:14 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 29 May 2018 12:49:14 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: Everyone in Haiti had a cell phone. Everyone. Even the poorest of the poor. They skipped the enormous expense of copper infrastructure. The world is very different in person. And these pockets of extreme isolation sound like a prime opportunity for a WISP or other disruption. -Ben On May 29, 2018, at 7:16 AM, John R. Levine wrote: >> I am sure these third world nations have more important things to spend >> their money on rather than data plans and data devices. Things like food >> and medicine come to mind... > > My goodness, aren't we condescending. Since we're talking about Kenya here, a few milliseconds of research reminds us that it's a significant agricultural exporter. Agricultural development there is generally about better use of existing land. > > You might also want to learn about M-Pesa, the mobile phone payment system that everybody uses. Stores all have a sign with their M-Pesa number so you can pay them, and there are kiosks all over Nairobi that will exchange M-Pesa credit and cash. The 1GB data bundles I mentioned are large ones. You can get 7MB for a day or 5MB for a week for 5c, which is plenty to check your messages or look up farm prices. > > People in Africa may be poorer than we are, but they are just as smart as we are, and they are just as able and interested in technology when it is useful to them. > > R's, > John From owen at delong.com Tue May 29 21:50:57 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2018 14:50:57 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: <52BD7F20-9BE0-43A7-A6E7-669EC05BA04B@delong.com> > On May 29, 2018, at 12:49 , Ben Cannon wrote: > > Everyone in Haiti had a cell phone. Everyone. Even the poorest of the poor. They skipped the enormous expense of copper infrastructure. > > The world is very different in person. > > And these pockets of extreme isolation sound like a prime opportunity for a WISP or other disruption. In some cases, this is a viable solution. In others, not so much. There are places, for example, where one has to be concerned that your infrastructure will be creatively “recycled” by the locals when you aren’t looking. Also, deploying a WISP still requires the ability to bring Power to all and Wired Connectivity to some of your deployments. As I mentioned earlier, Haiti is a relatively easy Wireless deployment topography. Try doing the same thing in the Nevada desert, where the iron rich base minerals combined with the alkali top soil creates a kind of RF sink-hole that causes walkie-talkies that go 3-5 miles anywhere else to fail in as little as 1/4 mile and that’s in the flat areas. Add in the mountains and you’ve got a real interesting deployment where you might need 4 or 5 base stations just to reach 1-2 customers. There are solutions that can work just about everywhere, but there’s no one solution that works everywhere. Owen > > -Ben > > On May 29, 2018, at 7:16 AM, John R. Levine wrote: > >>> I am sure these third world nations have more important things to spend >>> their money on rather than data plans and data devices. Things like food >>> and medicine come to mind... >> >> My goodness, aren't we condescending. Since we're talking about Kenya here, a few milliseconds of research reminds us that it's a significant agricultural exporter. Agricultural development there is generally about better use of existing land. >> >> You might also want to learn about M-Pesa, the mobile phone payment system that everybody uses. Stores all have a sign with their M-Pesa number so you can pay them, and there are kiosks all over Nairobi that will exchange M-Pesa credit and cash. The 1GB data bundles I mentioned are large ones. You can get 7MB for a day or 5MB for a week for 5c, which is plenty to check your messages or look up farm prices. >> >> People in Africa may be poorer than we are, but they are just as smart as we are, and they are just as able and interested in technology when it is useful to them. >> >> R's, >> John From nanog at ics-il.net Tue May 29 21:53:50 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 29 May 2018 16:53:50 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: Message-ID: <578364899.953.1527630826566.JavaMail.mhammett@ThunderFuck> "And these pockets of extreme isolation sound like a prime opportunity for a WISP or other disruption. " Which is what the OP of the thread I was looking at was doing, starting a WISP. They could get a 100 - 200 megabit/s per AP access network, but their link to the outside world is currently limited to one meg. For some reason mountain to mountain links weren't a viable option. I don't know the reason why. I was looking for ways of him getting the most bang for the buck out of the connection. I've got a couple ideas (Steam Cache, Squid in "bump in the middle" configuration, and a squid - squid tunnel with the low speed link in the middle). ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ben Cannon" To: "John R. Levine" Cc: "NANOG" Sent: Tuesday, May 29, 2018 2:49:14 PM Subject: Re: Impacts of Encryption Everywhere (any solution?) Everyone in Haiti had a cell phone. Everyone. Even the poorest of the poor. They skipped the enormous expense of copper infrastructure. The world is very different in person. And these pockets of extreme isolation sound like a prime opportunity for a WISP or other disruption. -Ben On May 29, 2018, at 7:16 AM, John R. Levine wrote: >> I am sure these third world nations have more important things to spend >> their money on rather than data plans and data devices. Things like food >> and medicine come to mind... > > My goodness, aren't we condescending. Since we're talking about Kenya here, a few milliseconds of research reminds us that it's a significant agricultural exporter. Agricultural development there is generally about better use of existing land. > > You might also want to learn about M-Pesa, the mobile phone payment system that everybody uses. Stores all have a sign with their M-Pesa number so you can pay them, and there are kiosks all over Nairobi that will exchange M-Pesa credit and cash. The 1GB data bundles I mentioned are large ones. You can get 7MB for a day or 5MB for a week for 5c, which is plenty to check your messages or look up farm prices. > > People in Africa may be poorer than we are, but they are just as smart as we are, and they are just as able and interested in technology when it is useful to them. > > R's, > John From mark.tinka at seacom.mu Wed May 30 04:54:45 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 May 2018 06:54:45 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> References: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> Message-ID: On 29/May/18 19:21, Owen DeLong wrote: >> I admit that I haven’t been to Eritrea or Indonesia, but using Ethiopia >> and Malaysia as stand-ins (which I have been to), I can say that while they >> are the same internet, the level of development, the payment systems which >> are usable via said internet, and other aspects of the daily use and capabilities >> which can be utilized on the internet in those countries does vary greatly. >> >> For example, Apple Pay is somewhat ubiquitous in Canada. It’s virtually unheard >> of in Ethiopia. My travels to Malaysia were not recent enough for me to comment >> accurately on the current state of things. >> >> M-Pesa is widely accepted in Kenya, but not at all in the US or Canada. >> >> PayPal is popular in the US, but not so much in most of the rest of the world. >> >> YMMV. >> >> IPv6 is readily available on almost every mobile phone in the US. Less so in >> Kenya or Tanzania, Eritrea, Canada, or Indonesia. >> >> While all connected networks are part of the same big I Internet, not all networks >> are created or maintained equal and not all services on those networks are >> ubiquitously available to all users of the big I Internet. My point is the protocol is the same regardless of where in the world you are; and the global nature of the Internet levels the playing field. Who extracts the most out of it is a completely separate discussion. What I am saying is there are different ways many countries do things. Deciding on how computer communicate isn't one of them. Mark. From mark.tinka at seacom.mu Wed May 30 05:02:32 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 May 2018 07:02:32 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <2644b6f3-1b10-c12f-5442-b2571e242cc8@seacom.mu> <26FEBFE6-1D7A-45D8-AED2-76CA3E7CBE27@delong.com> Message-ID: On 29/May/18 19:58, Eric Kuhnke wrote: > Ethiopia is significantly different and unique, in its own unusual way, > because of the government monopoly telecom. Other people can correct me if > I'm wrong, but unless the situation has changed in the past two years, all > small to medium sized ISPs in Ethiopia are mandated by law to be downstream > of the government run telecom ASN. Also the government owned national > telecom has a monopoly on all international fiber connections to > neighboring countries (at OSI layer 1), and for things like STM/SDH or > 1/10/ Gbps Ethernet L2 transport services to any location outside of > Ethiopia. > > The Ethiopian Internet is also subject to significant censorship and > attempted blockage of VPN and VoIP services. Doesn't at all sound that different from China, North Korea, Saudi Arabia, Iran or Myanmar... and in the case of international connectivity openness, Swaziland... Mark. From mark.tinka at seacom.mu Wed May 30 05:19:21 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 May 2018 07:19:21 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> Message-ID: <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> On 29/May/18 20:01, Eric Kuhnke wrote: > The one thing that you CAN generalize about a great many developing nation > telecom markets, which is different than the US and Western Europe: > > Many urban locations have a complete absence of functioning last mile, > legacy copper telecom infrastructure, which in a US city you would see used > for ADSL2+ or VDSL2 or g.fast on old POTS phone lines, or > DOCSIS3.0/DOCSIS3.1 on 75 ohm coaxial cable TV plant. Leaving "4G" and > various forms of fixed point to multipoint wireless, whether LTE based or > not, as the only viable residential and SMB broadband service option. And this is a bad thing, because? Just because it is done differently doesn't mean it is any less effective. Mobile phones have significantly overtaken all other forms of physical infrastructure in most of Africa, and the amount of data being generated as well as the growing rate of penetration is some of the highest in the world. MNO's have taken slightly different approaches to how they build and scale for Africa (and other developing continents such as Asia) than they have for other regions of the world where physical infrastructure is more rife. Personally, I'm glad that the remaining bits of copper plant in Africa are losing steam as folk jump straight into 3G/4G and fibre in Africa. Coax was never really a hit in Africa (I know it was in Mozambique), but glad we don't have to deal with that legacy either. I am fortunate enough to live in a city where 4G/LTE is available, with a reasonably-priced 100Mbps FTTH service to my house, as do many others that live in major African cities where private companies are not sitting around waiting for the gubbermint to catch up. Is there a lot more that can and should be done? For sure! But things are happening... Mark. From ciscofreak at outlook.com Wed May 30 07:11:33 2018 From: ciscofreak at outlook.com (Hari .) Date: Wed, 30 May 2018 07:11:33 +0000 Subject: MVPN Question - profile 0 Message-ID: Hey - One question on MVPN behavior. Will the PIM JOIN from the customer will be received on all the MVPN members - encapsulated MDT group. ? Can we expect to see the state in all the MDT members? Thought it will be seen only on RPF neighbor? In our scenario, the multicast VRF in PE should be preferring Core2 (thanks to default from core2 with high preference). But still, we are seeing some state created in CORE1. Although the majority is on CORE2. Any thought on why the state created on CORE1 overriding the RPF check? Regards From ben at 6by7.net Wed May 30 07:53:56 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 30 May 2018 00:53:56 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> Message-ID: <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> Thank you Mark for your excellent firsthand account. I’ve observed this - the developing world (better? Same meaning but hey) does not miss copper infrastructure. That was always bad and was always going to be bad now that 4G is here. There’s just zero reason now. It’s an anchor. -Ben > On May 29, 2018, at 10:19 PM, Mark Tinka wrote: > > > >> On 29/May/18 20:01, Eric Kuhnke wrote: >> >> The one thing that you CAN generalize about a great many developing nation >> telecom markets, which is different than the US and Western Europe: >> >> Many urban locations have a complete absence of functioning last mile, >> legacy copper telecom infrastructure, which in a US city you would see used >> for ADSL2+ or VDSL2 or g.fast on old POTS phone lines, or >> DOCSIS3.0/DOCSIS3.1 on 75 ohm coaxial cable TV plant. Leaving "4G" and >> various forms of fixed point to multipoint wireless, whether LTE based or >> not, as the only viable residential and SMB broadband service option. > > And this is a bad thing, because? > > Just because it is done differently doesn't mean it is any less > effective. Mobile phones have significantly overtaken all other forms of > physical infrastructure in most of Africa, and the amount of data being > generated as well as the growing rate of penetration is some of the > highest in the world. > > MNO's have taken slightly different approaches to how they build and > scale for Africa (and other developing continents such as Asia) than > they have for other regions of the world where physical infrastructure > is more rife. > > Personally, I'm glad that the remaining bits of copper plant in Africa > are losing steam as folk jump straight into 3G/4G and fibre in Africa. > Coax was never really a hit in Africa (I know it was in Mozambique), but > glad we don't have to deal with that legacy either. > > I am fortunate enough to live in a city where 4G/LTE is available, with > a reasonably-priced 100Mbps FTTH service to my house, as do many others > that live in major African cities where private companies are not > sitting around waiting for the gubbermint to catch up. Is there a lot > more that can and should be done? For sure! But things are happening... > > Mark. From C-Mack.McBride at charter.com Wed May 30 15:11:43 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Wed, 30 May 2018 15:11:43 +0000 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> Message-ID: In high density urban areas last mile infrastructure (mostly copper) is considerably better than 4G. Localized carrier powered wifi is good as well but it is not and should not be confused with 4G. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ben Cannon Sent: Wednesday, May 30, 2018 1:54 AM To: Mark Tinka Cc: nanog at nanog.org list Subject: Re: Impacts of Encryption Everywhere (any solution?) Thank you Mark for your excellent firsthand account. I’ve observed this - the developing world (better? Same meaning but hey) does not miss copper infrastructure. That was always bad and was always going to be bad now that 4G is here. There’s just zero reason now. It’s an anchor. -Ben > On May 29, 2018, at 10:19 PM, Mark Tinka wrote: > > > >> On 29/May/18 20:01, Eric Kuhnke wrote: >> >> The one thing that you CAN generalize about a great many developing >> nation telecom markets, which is different than the US and Western Europe: >> >> Many urban locations have a complete absence of functioning last >> mile, legacy copper telecom infrastructure, which in a US city you >> would see used for ADSL2+ or VDSL2 or g.fast on old POTS phone lines, >> or >> DOCSIS3.0/DOCSIS3.1 on 75 ohm coaxial cable TV plant. Leaving "4G" >> and various forms of fixed point to multipoint wireless, whether LTE >> based or not, as the only viable residential and SMB broadband service option. > > And this is a bad thing, because? > > Just because it is done differently doesn't mean it is any less > effective. Mobile phones have significantly overtaken all other forms > of physical infrastructure in most of Africa, and the amount of data > being generated as well as the growing rate of penetration is some of > the highest in the world. > > MNO's have taken slightly different approaches to how they build and > scale for Africa (and other developing continents such as Asia) than > they have for other regions of the world where physical infrastructure > is more rife. > > Personally, I'm glad that the remaining bits of copper plant in Africa > are losing steam as folk jump straight into 3G/4G and fibre in Africa. > Coax was never really a hit in Africa (I know it was in Mozambique), > but glad we don't have to deal with that legacy either. > > I am fortunate enough to live in a city where 4G/LTE is available, > with a reasonably-priced 100Mbps FTTH service to my house, as do many > others that live in major African cities where private companies are > not sitting around waiting for the gubbermint to catch up. Is there a > lot more that can and should be done? For sure! But things are happening... > > Mark. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From mark.tinka at seacom.mu Wed May 30 16:59:45 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 May 2018 18:59:45 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> Message-ID: On 30/May/18 17:11, McBride, Mack wrote: > In high density urban areas last mile infrastructure (mostly copper) is considerably better than 4G. > Localized carrier powered wifi is good as well but it is not and should not be confused with 4G. I think it depends on what it is you're trying to do. If your application is linear IPTV streaming into your home, that probably isn't a great idea for any kind of non-wired media. On the other hand, in South Africa, where I live, it is routine to deliver video streaming services (Netflix, Youtube, ShowMax, e.t.c.) to one's home over 4G/LTE, to the extent that the service providers have special data plans that support these kinds of use-cases. In South Africa, I generally find wi-fi in the hotels to be pretty bad, as the majority of them tend to be on ADSL backhaul, which averages between 1Mbps - 4Mbps to support several dozen or more rooms. A few hotels have migrated to fibre, but between guessing what last mile they're on and how they operate the wi-fi network, I ALWAYS prefer to tether my iPhone to my laptop and work when I'm on the road within the country. In all major cities, my 3G/4G performs a lot more reliably, better and predictably than most cafe, hotel or mall wi-fi. I don't even bother when hotels offer their wi-fi vouchers upon check-in. With my 4G services (Vodacom and MTN), I can average between 30Mbps - 55Mbps when tethering, and that's plenty enough for me. I have a decent monthly data plan that I don't have to worry about running out. Of course, performance isn't as great if you're in a remote part of the country, but that's not unique to South Africa. Mark. From kscott.helms at gmail.com Wed May 30 17:10:08 2018 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 30 May 2018 13:10:08 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> Message-ID: Mark, A couple of things, first that kind of utilization isn't feasible once penetration rates in dense areas reach certain levels. There's a reason that NTT Docomo moved more than 70% of their data traffic to the 3.5 GHz band and that reason is that there's not (nor will there be) enough wireless spectrum to meet the needs of everyone with licensed space. (That same use case is why all the big North American providers are looking at CBRS.) Further, 4G/5G is going to have trouble scaling to the kinds of network demands going forward, again especially in dense areas. While it's certainly possible today to stream unicast video over LTE and will (for a while) even more feasible over 5G the physics simply aren't with the wireless world. I'd say that your example of poor DSL performance isn't unique, it happens in some spots in the US, but in general wired performance has much higher individual and even higher aggregate capacities *when correctly deployed. *I doubt your hotel example is a poor deployment though, it's more likely that the hotel owners are under paying for both the WAN connection and the WiFi infrastructure. On Wed, May 30, 2018 at 1:01 PM Mark Tinka wrote: > > > On 30/May/18 17:11, McBride, Mack wrote: > > > In high density urban areas last mile infrastructure (mostly copper) is > considerably better than 4G. > > Localized carrier powered wifi is good as well but it is not and should > not be confused with 4G. > > I think it depends on what it is you're trying to do. If your > application is linear IPTV streaming into your home, that probably isn't > a great idea for any kind of non-wired media. On the other hand, in > South Africa, where I live, it is routine to deliver video streaming > services (Netflix, Youtube, ShowMax, e.t.c.) to one's home over 4G/LTE, > to the extent that the service providers have special data plans that > support these kinds of use-cases. > > In South Africa, I generally find wi-fi in the hotels to be pretty bad, > as the majority of them tend to be on ADSL backhaul, which averages > between 1Mbps - 4Mbps to support several dozen or more rooms. A few > hotels have migrated to fibre, but between guessing what last mile > they're on and how they operate the wi-fi network, I ALWAYS prefer to > tether my iPhone to my laptop and work when I'm on the road within the > country. In all major cities, my 3G/4G performs a lot more reliably, > better and predictably than most cafe, hotel or mall wi-fi. I don't even > bother when hotels offer their wi-fi vouchers upon check-in. > > With my 4G services (Vodacom and MTN), I can average between 30Mbps - > 55Mbps when tethering, and that's plenty enough for me. I have a decent > monthly data plan that I don't have to worry about running out. Of > course, performance isn't as great if you're in a remote part of the > country, but that's not unique to South Africa. > > Mark. > From C-Mack.McBride at charter.com Wed May 30 17:47:08 2018 From: C-Mack.McBride at charter.com (McBride, Mack) Date: Wed, 30 May 2018 17:47:08 +0000 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> Message-ID: <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> Scott hit the nail on the head. Hotel/café/mall wifi is generally horrible for the same reason urban 4g is horrible. The backhaul and load on the available spectrum is usually excessive. Carrier wifi is usually (but not always) equipped with decent backhaul. However carrier wifi in stadiums usually suffers from problems with spectrum saturation. Any wifi or 4G will eventually run out of available bandwidth on assigned spectrum. Wifi has the advantage of being able to use smaller range restricted access points but the stadium example shows why even that is limited when you have 40K people trying to access the internet. Mack From: K. Scott Helms [mailto:kscott.helms at gmail.com] Sent: Wednesday, May 30, 2018 11:10 AM To: mark.tinka at seacom.mu Cc: McBride, Mack ; ben at 6by7.net; NANOG list Subject: Re: Impacts of Encryption Everywhere (any solution?) Mark, A couple of things, first that kind of utilization isn't feasible once penetration rates in dense areas reach certain levels. There's a reason that NTT Docomo moved more than 70% of their data traffic to the 3.5 GHz band and that reason is that there's not (nor will there be) enough wireless spectrum to meet the needs of everyone with licensed space. (That same use case is why all the big North American providers are looking at CBRS.) Further, 4G/5G is going to have trouble scaling to the kinds of network demands going forward, again especially in dense areas. While it's certainly possible today to stream unicast video over LTE and will (for a while) even more feasible over 5G the physics simply aren't with the wireless world. I'd say that your example of poor DSL performance isn't unique, it happens in some spots in the US, but in general wired performance has much higher individual and even higher aggregate capacities when correctly deployed. I doubt your hotel example is a poor deployment though, it's more likely that the hotel owners are under paying for both the WAN connection and the WiFi infrastructure. On Wed, May 30, 2018 at 1:01 PM Mark Tinka > wrote: On 30/May/18 17:11, McBride, Mack wrote: > In high density urban areas last mile infrastructure (mostly copper) is considerably better than 4G. > Localized carrier powered wifi is good as well but it is not and should not be confused with 4G. I think it depends on what it is you're trying to do. If your application is linear IPTV streaming into your home, that probably isn't a great idea for any kind of non-wired media. On the other hand, in South Africa, where I live, it is routine to deliver video streaming services (Netflix, Youtube, ShowMax, e.t.c.) to one's home over 4G/LTE, to the extent that the service providers have special data plans that support these kinds of use-cases. In South Africa, I generally find wi-fi in the hotels to be pretty bad, as the majority of them tend to be on ADSL backhaul, which averages between 1Mbps - 4Mbps to support several dozen or more rooms. A few hotels have migrated to fibre, but between guessing what last mile they're on and how they operate the wi-fi network, I ALWAYS prefer to tether my iPhone to my laptop and work when I'm on the road within the country. In all major cities, my 3G/4G performs a lot more reliably, better and predictably than most cafe, hotel or mall wi-fi. I don't even bother when hotels offer their wi-fi vouchers upon check-in. With my 4G services (Vodacom and MTN), I can average between 30Mbps - 55Mbps when tethering, and that's plenty enough for me. I have a decent monthly data plan that I don't have to worry about running out. Of course, performance isn't as great if you're in a remote part of the country, but that's not unique to South Africa. Mark. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From akajtar at wadsworthcity.org Wed May 30 19:49:53 2018 From: akajtar at wadsworthcity.org (Adam Kajtar) Date: Wed, 30 May 2018 15:49:53 -0400 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: “I'm running two Juniper MX104s. Each MX has 1 ISP connected running BGP(full routes). iBGP is running between the routers via a two port 20G lag. When one of the ISPs fails, it can take upwards of 2 minutes for traffic to start flowing correctly. The router has the correct route in the routing table, but it doesn't install it in the forwarding table for the full two mins.” I finished my testing and concluded that I would continue running full routes without any fanciness. I will detail some tests and what the outcomes were as well as explain why I decided to keep running full routes. *Receiving Full Routes* Convergence time was 180 seconds. The routing table updated and showed the correct path in under a minute but the forwarding table took 180 seconds for most the routes to update. *BGP Multipath* There was no effect on convergence speed. I think paths between eBGP neighbors are preferred over iBGP. Therefore, no routes are ever equal in this case. *BFD* The slower to converge ISP refused my request to setup BFD between our routers. This option is out of the question. *BGP Timers* I adjusted the BGP hold timer to 30 seconds and the stale route timer to 5 seconds. This change appeared to have no effect on convergence speed. *Receiving Full Routes with a Default* I suspected receiving a default route would fix the issue because the only route that would need to be updated in the forwarding table for traffic to flow. I assumed that it would process the lowest binary route first( 0.0.0.0/0) Once the full table was updated traffic would take the optimal path(This would avoid customer complaints due to latency with VPNs and Voice traffic). I also suspected exporting the default BGP default route into OSPF would speed up OSPF convergences avoiding a generated default route based on neighbor state. Unfortunately, it appears like the forwarding table of the MX104 converges abruptly instead of slowly as router processes them. Also, Traffic would fail as the ISP connection came back up due to BGP exporting the route into OSPF. *Receiving Full Routes with forwarding engine commands* After I completed the above tests, I concluded the forwarding engine would need to speed up, and some sort of hack was in order. I tested the following commands. https://www.juniper.net/documentation/en_US/junos/topics/concept/use-case-for-bgp-pic-for-inet-inet6-lu.html https://www.juniper.net/documentation/en_US/junos/topics/topic-map/forwarding-indirect-next-hop.html With these commands enabled equal cost routes installed into the forwarding table. Failover on equal cost routes was 40 – 50 seconds and 180 seconds on non-equal-cost routes. This was unacceptable because most of the routes are preferred out one ISP over the other. I disabled ECMP and the router began installing all routes into the forwarding table including the secondary route. The router would dump sections of the forwarding table and act very flakey. *Receiving Default Only* I tested filtering out all routes besides the default route. The speed of convergence was 30 - 45 seconds depending on which upstream ISP connection I disconnected. This solution was unacceptable due to the traffic not taking the optimal path outbound. I concluded that 180 seconds was an acceptable failover time given that I exhausted all other resources. I would prefer to have a more reliable failover mechanism than a faster one. Also, everyday speed and usability are more important that failover speed(which rarely happens and almost never during peak hours) in my use case. Thank you to anyone who gave me suggestions on this issue. It helped me understand and accept the outcome. On Sat, May 26, 2018 at 12:15 PM Baldur Norddahl wrote: > Add a static default route on both routers. This will be invalidated as > soon the interface goes down. Should be faster than relying on the BGP > process on withdrawing the route. Also does not require any config changes > at your upstreams. > > Regards > Baldur > > > ons. 16. maj 2018 18.52 skrev Adam Kajtar : > > > Erich, > > > > Good Idea. I can't believe I didn't think of that earlier. Simple and > > effective. I will go ahead and request the defaults from my ISP and > update > > the thread of the findings. > > > > Thanks! > > > > On Wed, May 16, 2018 at 10:03 AM Kaiser, Erich > > wrote: > > > > > A last resort route (default route) could still be good to take from > your > > > ISP(s) even if you still do full routes, as the propagation is > happening > > on > > > the internet side, you should at least have a path inbound through the > > > other provider. The default route at least would send the traffic out > if > > > it does not see the route locally. Just an idea. > > > > > > > > > > > > On Wed, May 16, 2018 at 8:22 AM, Adam Kajtar < > akajtar at wadsworthcity.org> > > > wrote: > > > > > > > I could use static routes but I noticed since I moved to full routes > I > > > > have had a lot fewer customer complaints about latency(especially > when > > it > > > > comes to Voice and VPN traffic). > > > > > > > > I wasn't using per-packet load balancing. I believe juniper default > is > > > per > > > > IP. > > > > > > > > My timers are as follows > > > > Active Holdtime: 90 > > > > Keepalive Interval: 30 > > > > > > > > Would I be correct in thinking I need to contact my ISP to lower > these > > > > values? > > > > > > > > An interesting note is when I had both ISPs connected into a single > > MX104 > > > > the failover was just a few seconds. > > > > > > > > Thanks again. > > > > > > > > > > > > > > > > On Tue, May 15, 2018 at 8:42 PM Ben Cannon wrote: > > > > > > > >> Have you checked your timeouts ? > > > >> > > > >> -Ben > > > >> > > > >> > On May 15, 2018, at 4:09 PM, Kaiser, Erich > > > wrote: > > > >> > > > > >> > Do you need full routes? What about just a default route from > BGP? > > > >> > > > > >> > Erich Kaiser > > > >> > The Fusion Network > > > >> > erich at gotfusion.net > > > >> > Office: 815-570-3101 > > > >> > > > > >> > > > > >> > > > > >> > > > > >> >> On Tue, May 15, 2018 at 5:38 PM, Aaron Gould > > > wrote: > > > >> >> > > > >> >> You sure it doesn't have something to do with 60 seconds * 3 = > 180 > > > >> secs of > > > >> >> BGP neighbor Time out before it believes neighbor is dead and > > remove > > > >> routes > > > >> >> to that neighbor? > > > >> >> > > > >> >> Aaron > > > >> >> > > > >> >>> On May 15, 2018, at 9:10 AM, Adam Kajtar < > > akajtar at wadsworthcity.org > > > > > > > >> >> wrote: > > > >> >>> > > > >> >>> Hello: > > > >> >>> > > > >> >>> I'm running two Juniper MX104s. Each MX has 1 ISP connected > > running > > > >> >>> BGP(full routes). iBGP is running between the routers via a two > > port > > > >> 20G > > > >> >>> lag. When one of the ISPs fails, it can take upwards of 2 > minutes > > > for > > > >> >>> traffic to start flowing correctly. The router has the correct > > route > > > >> in > > > >> >> the > > > >> >>> routing table, but it doesn't install it in the forwarding table > > for > > > >> the > > > >> >>> full two mins. > > > >> >>> > > > >> >>> I have a few questions if anyone could answer them. > > > >> >>> > > > >> >>> - What would a usual convergence time be for this setup? > > > >> >>> - Is there anything I could do speed this process up? (I tried > > > >> >> Multipath) > > > >> >>> - Any tips and tricks would be much appreciated > > > >> >>> > > > >> >>> Thanks in Advance > > > >> >>> -- > > > >> >>> Adam Kajtar > > > >> >>> Systems Administrator > > > >> >>> City of Wadsworth > > > >> >>> akajtar at wadsworthcity.org > > > >> >>> ----------------------------------------------------- > > > >> >>> http://www.wadsworthcity.com > > > >> >>> > > > >> >>> Facebook * |* Twitter > > > >> >>> *|* Instagram > > > >> >>> *|* YouTube > > > >> >>> > > > >> >> > > > >> >> > > > >> > > > > > > > > > > > > -- > > > > Adam Kajtar > > > > Systems Administrator, Safety Services > > > > City of Wadsworth > > > > Office 330.335.2865 > > > > Cell 330.485.6510 > > > > akajtar at wadsworthcity.org > > > > ----------------------------------------------------- > > > > http://www.wadsworthcity.com > > > > > > > > Facebook * |* Twitter > > > > *|* Instagram > > > > *|* YouTube > > > > > > > > > > > > > > > > > -- > > Adam Kajtar > > Systems Administrator, Safety Services > > City of Wadsworth > > Office 330.335.2865 > > Cell 330.485.6510 > > akajtar at wadsworthcity.org > > ----------------------------------------------------- > > http://www.wadsworthcity.com > > > > Facebook * |* Twitter > > *|* Instagram > > *|* YouTube > > > > > -- Adam Kajtar Systems Administrator, Safety Services City of Wadsworth Office 330.335.2865 Cell 330.485.6510 akajtar at wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook * |* Twitter *|* Instagram *|* YouTube From johnl at iecc.com Wed May 30 20:13:25 2018 From: johnl at iecc.com (John R. Levine) Date: 30 May 2018 16:13:25 -0400 Subject: SIP fax sending software? Message-ID: Can anyone recommend software that sends faxes over SIP? I have plenty of inbound fax to email services, but now and then I need to send a reply and it looks tacky to use one of the free web ones that put an ad on it. I know that if I wanted to pay $15/mo there are lots of lovely services but we're taking about one fax a month, maybe, here. Ideally it'd take a postscript or PDF or Word document and a phone number and fax it to that number. I have Ubuntu, FreeBSD, and MacOS boxes. Any suggestions? Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From mark.tinka at seacom.mu Wed May 30 20:35:15 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 May 2018 22:35:15 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> Message-ID: <994a96d3-f8f6-8e91-3431-eb0a6900d2ee@seacom.mu> On 30/May/18 19:10, K. Scott Helms wrote: > Mark, > > A couple of things, first that kind of utilization isn't feasible once > penetration rates in dense areas reach certain levels.  There's a > reason that NTT Docomo moved more than 70% of their data traffic to > the 3.5 GHz band and that reason is that there's not (nor will there > be) enough wireless spectrum to meet the needs of everyone with > licensed space.  (That same use case is why all the big North American > providers are looking at CBRS.) Further, 4G/5G is going to have > trouble scaling to the kinds of network demands going forward, again > especially in dense areas.  While it's certainly possible today to > stream unicast video over LTE and will (for a while) even more > feasible over 5G the physics simply aren't with the wireless world.  I don't disagree - fundamentally, one can't argue with the scalability of wired media vs. any kind of wireless media. In (South) Africa, two things are happening to scale out 4G: * Getting the regulators to issue new spectrum to MNO's. This is also aided by the country's migration plans from analog to digital for free-to-air TV, which will make new spectrum available for the MNO's. However... * ... the above isn't moving at the pace the MNO's would like, which is why they have become some of the most efficient mobile operators in the world by re-farming existing spectrum and scaling that way. > > I'd say that your example of poor DSL performance isn't unique, it > happens in some spots in the US, As with the Internet, the technology is the technology regardless of where it's applied in the world. ADSL scaling properties suffer in Africa the same way they do in any other continent. > but in general wired performance has much higher individual and even > higher aggregate capacities /when correctly deployed./ No argument from me there. I use 3G/4G for data when I travel within the country, as I mentioned before. When I'm at home, my FTTH service does the job. When I'm in the office, my backbone does the job. Wireless will never meet the demands, long-term, be it on 5G or 802.11ax. But for now, 3G/4G/LTE is the most appropriate technology for, pretty much, all of Africa. And to be fair, it is not doing a half-bad job, across the board. > /  /I doubt your hotel example is a poor deployment though, it's more > likely that the hotel owners are under paying for both the WAN > connection and the WiFi infrastructure. I'm a network engineer - I can tell when the issue is a pretty bad wi-fi setup, a pretty bad LAN switch, a pretty bad NAT44 translator, or a pretty bad ISP. I was in Paris in March for a conference, and I couldn't get the hotel staff to understand that the problem with the hotel Internet was both a combination of poorly deployed wi-fi on each floor + insufficient capacity from their ISP. Their solution to me was, "Reboot your laptop and check again". I don't have the luxury of data roaming when I'm outside of South Africa. When I'm in South Africa, tethering always works better, even when the hotel wi-fi has moments of being decent. Mark. From ben at 6by7.net Wed May 30 20:43:29 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 30 May 2018 13:43:29 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: There are some interesting developments with sector (down to 30* or narrower) and multi-band, multi-radio, 4x4MIMO wifi gear lately. Ubiquiti is making amazing strides in this space. Watch 40k wifi connections in a stadium become the norm soon. I disagree entirely, and counter that the residential traffic of a major city like San Francisco isn’t over a sustained 100GigE link or three. There is ample backhaul and tremendous fiber bandwidth. It’s just all in very slightly (sometimes by a block or less) the wrong places. For one, fiber is fixed and the audience is portable. But carrier backhaul solutions with last mile wireless delivery is going to continue to impress. Watch this space. (he says somewhat hypocritically over his gig symmetric GPON FTTH) > On May 30, 2018, at 10:47 AM, McBride, Mack wrote: > > Scott hit the nail on the head. > Hotel/café/mall wifi is generally horrible for the same reason urban 4g is horrible. > The backhaul and load on the available spectrum is usually excessive. > Carrier wifi is usually (but not always) equipped with decent backhaul. > However carrier wifi in stadiums usually suffers from problems with spectrum saturation. > Any wifi or 4G will eventually run out of available bandwidth on assigned spectrum. > Wifi has the advantage of being able to use smaller range restricted access points but > the stadium example shows why even that is limited when you have 40K people trying > to access the internet. > > Mack > > From: K. Scott Helms [mailto:kscott.helms at gmail.com] > Sent: Wednesday, May 30, 2018 11:10 AM > To: mark.tinka at seacom.mu > Cc: McBride, Mack ; ben at 6by7.net; NANOG list > Subject: Re: Impacts of Encryption Everywhere (any solution?) > > Mark, > > A couple of things, first that kind of utilization isn't feasible once penetration rates in dense areas reach certain levels. There's a reason that NTT Docomo moved more than 70% of their data traffic to the 3.5 GHz band and that reason is that there's not (nor will there be) enough wireless spectrum to meet the needs of everyone with licensed space. (That same use case is why all the big North American providers are looking at CBRS.) Further, 4G/5G is going to have trouble scaling to the kinds of network demands going forward, again especially in dense areas. While it's certainly possible today to stream unicast video over LTE and will (for a while) even more feasible over 5G the physics simply aren't with the wireless world. > > I'd say that your example of poor DSL performance isn't unique, it happens in some spots in the US, but in general wired performance has much higher individual and even higher aggregate capacities when correctly deployed. I doubt your hotel example is a poor deployment though, it's more likely that the hotel owners are under paying for both the WAN connection and the WiFi infrastructure. > > > On Wed, May 30, 2018 at 1:01 PM Mark Tinka > wrote: > > > On 30/May/18 17:11, McBride, Mack wrote: > > > In high density urban areas last mile infrastructure (mostly copper) is considerably better than 4G. > > Localized carrier powered wifi is good as well but it is not and should not be confused with 4G. > > I think it depends on what it is you're trying to do. If your > application is linear IPTV streaming into your home, that probably isn't > a great idea for any kind of non-wired media. On the other hand, in > South Africa, where I live, it is routine to deliver video streaming > services (Netflix, Youtube, ShowMax, e.t.c.) to one's home over 4G/LTE, > to the extent that the service providers have special data plans that > support these kinds of use-cases. > > In South Africa, I generally find wi-fi in the hotels to be pretty bad, > as the majority of them tend to be on ADSL backhaul, which averages > between 1Mbps - 4Mbps to support several dozen or more rooms. A few > hotels have migrated to fibre, but between guessing what last mile > they're on and how they operate the wi-fi network, I ALWAYS prefer to > tether my iPhone to my laptop and work when I'm on the road within the > country. In all major cities, my 3G/4G performs a lot more reliably, > better and predictably than most cafe, hotel or mall wi-fi. I don't even > bother when hotels offer their wi-fi vouchers upon check-in. > > With my 4G services (Vodacom and MTN), I can average between 30Mbps - > 55Mbps when tethering, and that's plenty enough for me. I have a decent > monthly data plan that I don't have to worry about running out. Of > course, performance isn't as great if you're in a remote part of the > country, but that's not unique to South Africa. > > Mark. > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. From mark.tinka at seacom.mu Wed May 30 20:44:52 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 May 2018 22:44:52 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> Message-ID: <60f8fa19-5ff2-c2d9-6b64-97395dfb636d@seacom.mu> On 30/May/18 19:47, McBride, Mack wrote: > Scott hit the nail on the head. > > Hotel/café/mall wifi is generally horrible for the same reason urban > 4g is horrible. > Urban 4G in Africa isn't that bad, actually. The factors are many - not all users are on smart phones, or if they are, may default to 2G/3G more often than 4G. Also, because data prices are not pocket-friendly in many cases, the amount of time spent on the radio network for data is not significant. On the other hand, I generally get poor coverage (i.e., 1 bar) even in urban cities when I travel the U.S., particularly on AT&T, and sometimes, T-Mobile. Never quite understood that, but I've been having a side discussion from this thread with some mates that has shed some light, which makes a bit of sense to me. So not sure if that's the issue you face, or if it's something else. My point is while the technology has its intrinsic limitations, user patterns and applications that differ between the developed and developing worlds may have their part to play. > The backhaul and load on the available spectrum is usually excessive. > Spectrum, yes... see my previous response to K. Scott. Backhaul isn't a major issue - pretty much, every MNO in Africa has their own Metro and national fibre backbone; and in some cases, even their own submarine backbone. > Carrier wifi is usually (but not always) equipped with decent backhaul. > Wi-fi offload has been attempted a few times by one or two MNO's in Africa. But they can't decide between beta testing or launching. Bottom line is wi-fi offload is not big in Africa, and yet the 3G/4G radio network is still able to support traffic levels. I suspect it will become more popular as the radio load increases, although one would say the MNO's are looking at 5G before they consider wi-fi offload seriously. > However carrier wifi in stadiums usually suffers from problems with > spectrum saturation. > > Any wifi or 4G will eventually run out of available bandwidth on > assigned spectrum. > > Wifi has the advantage of being able to use smaller range restricted > access points but > > the stadium example shows why even that is limited when you have 40K > people trying > > to access the internet. > Agreed. Mark. From ben at 6by7.net Wed May 30 20:49:20 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 30 May 2018 13:49:20 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <60f8fa19-5ff2-c2d9-6b64-97395dfb636d@seacom.mu> References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> <60f8fa19-5ff2-c2d9-6b64-97395dfb636d@seacom.mu> Message-ID: The reason you see one or two bars in inner cities in 2018, is that given fixed spectrum, bandwidth on the aggregate can only increase if you take many smaller lower power radios, and carpet the area with them. The only other solutions are radically increase the power, or radically increase the width of the spectrum. -Ben > On May 30, 2018, at 1:44 PM, Mark Tinka wrote: > > > > On 30/May/18 19:47, McBride, Mack wrote: > >> Scott hit the nail on the head. >> Hotel/café/mall wifi is generally horrible for the same reason urban 4g is horrible. > > Urban 4G in Africa isn't that bad, actually. The factors are many - not all users are on smart phones, or if they are, may default to 2G/3G more often than 4G. Also, because data prices are not pocket-friendly in many cases, the amount of time spent on the radio network for data is not significant. > > On the other hand, I generally get poor coverage (i.e., 1 bar) even in urban cities when I travel the U.S., particularly on AT&T, and sometimes, T-Mobile. Never quite understood that, but I've been having a side discussion from this thread with some mates that has shed some light, which makes a bit of sense to me. So not sure if that's the issue you face, or if it's something else. > > My point is while the technology has its intrinsic limitations, user patterns and applications that differ between the developed and developing worlds may have their part to play. > > >> The backhaul and load on the available spectrum is usually excessive. > > Spectrum, yes... see my previous response to K. Scott. > > Backhaul isn't a major issue - pretty much, every MNO in Africa has their own Metro and national fibre backbone; and in some cases, even their own submarine backbone. > > >> Carrier wifi is usually (but not always) equipped with decent backhaul. > > Wi-fi offload has been attempted a few times by one or two MNO's in Africa. But they can't decide between beta testing or launching. Bottom line is wi-fi offload is not big in Africa, and yet the 3G/4G radio network is still able to support traffic levels. I suspect it will become more popular as the radio load increases, although one would say the MNO's are looking at 5G before they consider wi-fi offload seriously. > > >> However carrier wifi in stadiums usually suffers from problems with spectrum saturation. >> Any wifi or 4G will eventually run out of available bandwidth on assigned spectrum. >> Wifi has the advantage of being able to use smaller range restricted access points but >> the stadium example shows why even that is limited when you have 40K people trying >> to access the internet. > > Agreed. > > Mark. From nanog at ics-il.net Wed May 30 20:51:46 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 30 May 2018 15:51:46 -0500 (CDT) Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <8b968ed591d43945bb401f12a95dc9ae@mail.dessus.com> References: <8b968ed591d43945bb401f12a95dc9ae@mail.dessus.com> Message-ID: <1036992284.1788.1527713503331.JavaMail.mhammett@ThunderFuck> *nods* The whole concept of SSL all of the things is severely misplaced... and the thread I caught exemplifies why. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Keith Medcalf" To: nanog at nanog.org Cc: "Mike Hammett" Sent: Monday, May 28, 2018 11:55:21 AM Subject: RE: Impacts of Encryption Everywhere (any solution?) >I'm also not foolish enough to think this thread will affect the >encrypt-everything crowd as it is more of a religion\ideology than a >practical matter. However, maybe it'll shed some light on technical >ways of dealing with this at the service-provider level or plant some >doubt in someone's mind the next time they think they need to encrypt >non-sensitive information. Good Luck, especially in light of the poo-for-brains at Google responsible for the Chrome browser who (wrongly) equate "secure" with Transport Encryption and "unsecure" with not having Transport Encryption; when all that Transport Encryption really implies is Transport Encryption and not much else. It has little to do with whether or not a site is "secure". Generally speaking, I have found that sites engaging Transport Security are much more "unsecure" (as in subject to security breaches and flaws) than those that do not engage Transport Security for no reason. However, the poo-for-brains crowd will get everyone to engage Transport Security so the will be called "Secure", whether trustworthy or not. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From mark.tinka at seacom.mu Wed May 30 20:52:00 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 May 2018 22:52:00 +0200 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> <60f8fa19-5ff2-c2d9-6b64-97395dfb636d@seacom.mu> Message-ID: <954d97be-39cb-988d-f22f-85ffe7b384b2@seacom.mu> On 30/May/18 22:49, Ben Cannon wrote: > The reason you see one or two bars in inner cities in 2018, is that > given fixed spectrum, bandwidth on the aggregate can only increase if > you take many smaller lower power radios, and carpet the area with > them.   > > The only other solutions are radically increase the power, or > radically increase the width of the spectrum. Not dissimilar problems with (SP) wi-fi scaling in dense applications. My point is we don't generally have this issue in the major African cities that I regularly visit, so any perspectives based on what the U.S. may be going through cannot be wholesomely applied to other global regions. Mark. From james.cutler at consultant.com Wed May 30 20:55:22 2018 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 30 May 2018 16:55:22 -0400 Subject: SIP fax sending software? In-Reply-To: References: Message-ID: <2E1F3E10-8807-4BA8-A5B4-361D48DC06F8@consultant.com> > On May 30, 2018, at 4:13 PM, John R. Levine wrote: > > Can anyone recommend software that sends faxes over SIP? I have plenty of inbound fax to email services, but now and then I need to send a reply and it looks tacky to use one of the free web ones that put an ad on it. > > I know that if I wanted to pay $15/mo there are lots of lovely services but we're taking about one fax a month, maybe, here. > > Ideally it'd take a postscript or PDF or Word document and a phone number and fax it to that number. I have Ubuntu, FreeBSD, and MacOS boxes. Any suggestions? > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly Not SIP, but over TCP/IP, I have been happy with iFax from www.ifaxapp.com which takes a document and a phone number and sends the document to that number. Charging is against credits which are available at varying prices. The iFax application is available for macOS, Windows, iOS, and Android. I use it on iOS and macOS. See the website for more details on inbound fax, document scanning, HIPAA, and other features. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu From lathama at gmail.com Wed May 30 21:10:44 2018 From: lathama at gmail.com (Andrew Latham) Date: Wed, 30 May 2018 16:10:44 -0500 Subject: SIP fax sending software? In-Reply-To: References: Message-ID: T.38 if your provider supports it Try https://github.com/hehol/t38modem On Wed, May 30, 2018 at 3:15 PM John R. Levine wrote: > Can anyone recommend software that sends faxes over SIP? I have plenty of > inbound fax to email services, but now and then I need to send a reply and > it looks tacky to use one of the free web ones that put an ad on it. > > I know that if I wanted to pay $15/mo there are lots of lovely services > but we're taking about one fax a month, maybe, here. > > Ideally it'd take a postscript or PDF or Word document and a phone number > and fax it to that number. I have Ubuntu, FreeBSD, and MacOS boxes. Any > suggestions? > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > -- - Andrew "lathama" Latham - From list at satchell.net Wed May 30 21:32:35 2018 From: list at satchell.net (Stephen Satchell) Date: Wed, 30 May 2018 14:32:35 -0700 Subject: SIP fax sending software? In-Reply-To: References: Message-ID: On 05/30/2018 01:13 PM, John R. Levine wrote: > Can anyone recommend software that sends faxes over SIP? No. Just NO. The problem is that all the modulation methods that FAX transmission use requires time stability in the analog channel, and there is no way that SIP is going to be that stable. How do I know this? A number of years ago, a cable system maker asked me to consult on why V.29 fax wouldn't work over their voice-over-coax solution. I used a 23-tone test on the analog channel for 24 hours, and found the phase jitter was off the charts -- no way that fax machines could send faxes over the analog channel. (Traced it to the timing chain oscillating across the system.) Have you considered paying the $0.50 per page to have the local copy shop send the once-a-month faxes? The other answers have far superior suggestions sending fax over TCP/IP. From andy at newslink.com Wed May 30 21:37:34 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Wed, 30 May 2018 16:37:34 -0500 Subject: SIP fax sending software? In-Reply-To: References: Message-ID: > On May 30, 2018, at 4:10 PM, Andrew Latham wrote: > > T.38 if your provider supports it > > Try https://github.com/hehol/t38modem > > On Wed, May 30, 2018 at 3:15 PM John R. Levine wrote: > >> Can anyone recommend software that sends faxes over SIP? I have plenty of >> inbound fax to email services, but now and then I need to send a reply and >> it looks tacky to use one of the free web ones that put an ad on it. >> >> I know that if I wanted to pay $15/mo there are lots of lovely services >> but we're taking about one fax a month, maybe, here. >> >> Ideally it'd take a postscript or PDF or Word document and a phone number >> and fax it to that number. I have Ubuntu, FreeBSD, and MacOS boxes. Any >> suggestions? I ran into this issue when we went to a SIP phone system earlier this year. We opted to go with HelloFax and it has worked well. They do have a free account which allows you to send up to 5 faxes a month. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From goemon at sasami.anime.net Wed May 30 21:43:05 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Wed, 30 May 2018 14:43:05 -0700 (PDT) Subject: ICANN GDPR lawsuit Message-ID: http://www.circleid.com/posts/20180527_icann_files_legal_action_against_domain_registrar_whois_data/ -Dan From johnl at iecc.com Thu May 31 03:14:12 2018 From: johnl at iecc.com (John Levine) Date: 30 May 2018 23:14:12 -0400 Subject: SIP fax sending software? In-Reply-To: Message-ID: <20180531031413.4B53727743AF@ary.qy> In article you write: >Have you considered paying the $0.50 per page to have the local copy >shop send the once-a-month faxes? Since the local copy shop is about a half hour drive from here, no. I don't really care if it's flaky. For one fax a month a few retries are not a big deal. But hellofax's free 5 pages a month will probably do the job. R's, John From johnl at iecc.com Thu May 31 03:16:08 2018 From: johnl at iecc.com (John Levine) Date: 30 May 2018 23:16:08 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: Message-ID: <20180531031609.81E8D277440B@ary.qy> In article you write: >http://www.circleid.com/posts/20180527_icann_files_legal_action_against_domain_registrar_whois_data/ Elliot said that if he had to choose between fighting ICANN and fighting governments, he'd fight ICANN. I can't blame him. http://www.tucows.com/tucows-statement-on-icann-legal-action/ R's, John From josmon at rigozsaurus.com Thu May 31 04:50:03 2018 From: josmon at rigozsaurus.com (John Osmon) Date: Wed, 30 May 2018 22:50:03 -0600 Subject: SIP fax sending software? In-Reply-To: <20180531031413.4B53727743AF@ary.qy> References: <20180531031413.4B53727743AF@ary.qy> Message-ID: <20180531045003.GA27742@jeeves.rigozsaurus.com> On Wed, May 30, 2018 at 11:14:12PM -0400, John Levine wrote: [...FAX over IP...] > I don't really care if it's flaky. For one fax a month a few retries > are not a big deal. But hellofax's free 5 pages a month will probably > do the job. For folks that have made it this far, you might be interested in this article that I've kept a link to for over a decade: https://www.soft-switch.org/foip.html You *can* get a fax across a G.711 connection if your throughput, latency, and jitter align and create what looks like a DS0 to the two modems. And if does it for a long enough time to get the entire fax through. Tune the fax machines so they only run 9600 bps or less, and you might just make it. Good luck. You're going to need it. From johnl at iecc.com Thu May 31 04:54:05 2018 From: johnl at iecc.com (John R. Levine) Date: 31 May 2018 00:54:05 -0400 Subject: SIP fax sending software? In-Reply-To: <20180531045003.GA27742@jeeves.rigozsaurus.com> References: <20180531031413.4B53727743AF@ary.qy> <20180531045003.GA27742@jeeves.rigozsaurus.com> Message-ID: > You *can* get a fax across a G.711 connection if your throughput, My SIP provider supports T.38. How much difference does that make? Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From bzs at theworld.com Thu May 31 05:43:31 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 31 May 2018 01:43:31 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: <20180531031609.81E8D277440B@ary.qy> References: <20180531031609.81E8D277440B@ary.qy> Message-ID: <23311.35715.83014.161912@gargle.gargle.HOWL> FWIW a German court has just ruled against ICANN's injunction and in favor of Tucows/EPAG. https://www.icann.org/news/announcement-4-2018-05-30-en -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From josmon at rigozsaurus.com Thu May 31 05:46:00 2018 From: josmon at rigozsaurus.com (John Osmon) Date: Wed, 30 May 2018 23:46:00 -0600 Subject: SIP fax sending software? In-Reply-To: References: <20180531031413.4B53727743AF@ary.qy> <20180531045003.GA27742@jeeves.rigozsaurus.com> Message-ID: <20180531054600.GF14755@jeeves.rigozsaurus.com> On Thu, May 31, 2018 at 12:54:05AM -0400, John R. Levine wrote: > >You *can* get a fax across a G.711 connection if your throughput, > > My SIP provider supports T.38. How much difference does that make? It can make a great deal of difference. You change the dynamics from: fax ------------ fax modem <-> VOIP <-> modem ------------ Into something more like: T.38 service fax ----------------------------- fax modem <-> modem <-> IP <-> modem <-> modem ----------------------------- Fax communications have a data envelope that don't play well with anything that has latency/jitter/loss issues that don't act/feel like a POTS system. Also, the envelope doesn't recover well from errors. So --- faxes fail. So, you terminate the envelop at each end, and plug them together with and IP connection. You may still have problems, but a single issue doesn't necessarily mean that you have to terminate the transmission and start over. More (and better/more accurate) details with the article I linked earlier: http://www.soft-switch.org/foip.html From saku at ytti.fi Thu May 31 10:34:48 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 31 May 2018 13:34:48 +0300 Subject: Juniper BGP Convergence Time In-Reply-To: References: <0E9C7597-6910-448E-8D50-F9CD4A22EF87@6by7.net> Message-ID: Hey Adam, On 30 May 2018 at 22:49, Adam Kajtar wrote: > *Receiving Full Routes* > > Convergence time was 180 seconds. The routing table updated and showed the > correct path in under a minute but the forwarding table took 180 seconds > for most the routes to update. How as this verified? Juniper is known to converge on software much faster than on hardware. You'd need to at least verify: - show krt queue => no updates queued - show system processes extensive |match rpd => state is 'kqread' not 'RUN' 180seconds seems unlikely for MX80/MX104, may in scenario where box doesn't have anything else to do, no where to sends routes out to, no inferior routes to replace with new superior routes etc. Like if you just have empty box not connected anywhere receiving eBGP from on peer, maybe. In actual box doing actual work, unlikely. We see 20-30min convergence times on large boxes at initial convergency, mostly due to full-mesh being chatty and causing lot of useless state changes as new data keeps coming in. -- ++ytti From ahebert at pubnix.net Thu May 31 13:49:47 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 31 May 2018 09:49:47 -0400 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> Message-ID: <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net>     Hi,     Well bad news on the ColoAU front, they refused to cooperate.     We'll pushback thru our GTT accounts...  But I'm running out of ideas.     If anyone has any good ideas how to proceed at this point feel free to share =D. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/29/18 16:31, Chris Conn wrote: > Hello, > > I am the contact for AS16532. > > We never announced nor are we currently advertising this prefix as we are not a transit AS for anyone. As well, it seems to appear and disappear from AS63956 looking glass. According to that LG, the route changed 6d ago, and is *still currently visible* at this very moment; > > https://lg.coloau.com.au/ > > Command: show route 18.29.238.0 protocol bgp table vrf-international.inet.0 active-path > > vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 holddown, 103994 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2 > AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified > > > AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA. > > There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path? > > I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change anything, as I am not seeing this prefix in their route-server > > public at route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp active-path > > inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.0.0/16 *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23 > AS path: 3257 174 3 I, validation-state: unverified > > to 141.136.111.13 via xe-1/0/0.0 > > {master} > public at route-server.as3257.net-re0> > > > {master} > public at route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp | find 16532 > > Pattern not found > {master} > > > > So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find. > > > Chris Conn > AS16532 > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tom Paseka via NANOG > Sent: Friday, May 25, 2018 6:01 PM > To: Nikolas Geyer > Cc: NANOG list > Subject: Re: BGP Hijack/Sickness with AS4637 > > This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. > > If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. > Bouncing your session with 4637 would likely clear this. > > -Tom > > On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer wrote: > >> Greetings! >> >> Actually, what you have provided below shows the exact opposite. It >> shows ColoAU have received the route from 4637 who have received it >> from 3257 who have received it from 29909 who have received it from >> 16532 who originated it. It infers nothing about who 16532 found the route to come from. >> >> It is evident that GTT are advertising that route to Telstra Global :) >> >> Regards, >> Nik. >> >>> And I'm pretty sure AS3257 (GTT ) is in the same boat as us, >>> as >> they're not the one advertising those routes to AS4637 >>> AS16532 found it to come from AS4637 as you can see from this >>> ColoAU >> LG output below >>> >>> ----- https://lg.coloau.com.au/ >>> >>> vrf-international.inet.0: 696533 destinations, 2248101 routes >>> (696249 >> active, 0 holddown, 103835 hidden) >>> + = Active Route, - = Last Active, * = Both >>> >>> 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from >> 103.97.52.2 >>> AS path: 4637 3257 29909 16532 16532 16532 >>> 16532 >> I, validation-state: unverified >>> -- >>> ----- >>> Alain Hebert ahebert at pubnix.net >>> PubNIX Inc. >>> 50 boul. St-Charles >>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >>> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >>> From ahebert at pubnix.net Thu May 31 14:12:52 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 31 May 2018 10:12:52 -0400 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> Message-ID: <18f4e8cf-9219-f2dc-74c6-415fd0d3466f@pubnix.net>     Well,     None beside they're advertising a fake route of part of a MIT subnet using ASNs I care about.  (Which include GTT and MIT)     Right now their getting it from their outfit in JP which do not have a LG, and we cannot find any other crumbs in most LG found on lookingglass.org.     Without any cooperation from the only place we can see it, there isn't much we can do.     PS; Might be a generational gap, but in the olden days we used to be able to get cooperation from other operators. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/31/18 09:58, Phil Lavin wrote: > What is the relationship of 103.97.52.2 (Colocation Australia - Japan) to you? Is this, for example, a peering over an IX? If so, did you learn the route from route servers or do you peer directly with them? > > > Phil > > -----Original Message----- > From: NANOG On Behalf Of Alain Hebert > Sent: 31 May 2018 14:50 > To: nanog at nanog.org > Subject: Re: BGP Hijack/Sickness with AS4637 > >     Hi, > >     Well bad news on the ColoAU front, they refused to cooperate. > >     We'll pushback thru our GTT accounts...  But I'm running out of ideas. > >     If anyone has any good ideas how to proceed at this point feel free to share =D. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 05/29/18 16:31, Chris Conn wrote: >> Hello, >> >> I am the contact for AS16532. >> >> We never announced nor are we currently advertising this prefix as we >> are not a transit AS for anyone. As well, it seems to appear and >> disappear from AS63956 looking glass. According to that LG, the route >> changed 6d ago, and is *still currently visible* at this very moment; >> >> https://lg.coloau.com.au/ >> >> Command: show route 18.29.238.0 protocol bgp table >> vrf-international.inet.0 active-path >> >> vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 >> active, 0 holddown, 103994 hidden) >> + = Active Route, - = Last Active, * = Both >> >> 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2 >> AS path: 4637 3257 29909 16532 16532 16532 >> 16532 I, validation-state: unverified >> >> >> AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA. >> >> There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path? >> >> I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would >> change anything, as I am not seeing this prefix in their route-server >> >> public at route-server.as3257.net-re0> show route 18.29.238.0 protocol >> bgp active-path >> >> inet.0: 691667 destinations, 11752983 routes (691665 active, 1 >> holddown, 1 hidden) >> + = Active Route, - = Last Active, * = Both >> >> 18.29.0.0/16 *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23 >> AS path: 3257 174 3 I, validation-state: unverified >> > to 141.136.111.13 via xe-1/0/0.0 >> >> {master} >> public at route-server.as3257.net-re0> >> >> >> {master} >> public at route-server.as3257.net-re0> show route 18.29.238.0 protocol >> bgp | find 16532 >> >> Pattern not found >> {master} >> >> >> >> So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find. >> >> >> Chris Conn >> AS16532 >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tom Paseka >> via NANOG >> Sent: Friday, May 25, 2018 6:01 PM >> To: Nikolas Geyer >> Cc: NANOG list >> Subject: Re: BGP Hijack/Sickness with AS4637 >> >> This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. >> >> If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. >> Bouncing your session with 4637 would likely clear this. >> >> -Tom >> >> On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer wrote: >> >>> Greetings! >>> >>> Actually, what you have provided below shows the exact opposite. It >>> shows ColoAU have received the route from 4637 who have received it >>> from 3257 who have received it from 29909 who have received it from >>> 16532 who originated it. It infers nothing about who 16532 found the route to come from. >>> >>> It is evident that GTT are advertising that route to Telstra Global >>> :) >>> >>> Regards, >>> Nik. >>> >>>> And I'm pretty sure AS3257 (GTT ) is in the same boat as >>>> us, as >>> they're not the one advertising those routes to AS4637 >>>> AS16532 found it to come from AS4637 as you can see from this >>>> ColoAU >>> LG output below >>>> ----- https://lg.coloau.com.au/ >>>> >>>> vrf-international.inet.0: 696533 destinations, 2248101 routes >>>> (696249 >>> active, 0 holddown, 103835 hidden) >>>> + = Active Route, - = Last Active, * = Both >>>> >>>> 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from >>> 103.97.52.2 >>>> AS path: 4637 3257 29909 16532 16532 16532 >>>> 16532 >>> I, validation-state: unverified >>>> -- >>>> ----- >>>> Alain Hebert ahebert at pubnix.net >>>> PubNIX Inc. >>>> 50 boul. St-Charles >>>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >>>> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >>>> From job at ntt.net Thu May 31 14:15:41 2018 From: job at ntt.net (Job Snijders) Date: Thu, 31 May 2018 14:15:41 +0000 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> Message-ID: <20180531141541.GA75485@vurt.meerval.net> On Thu, May 31, 2018 at 09:49:47AM -0400, Alain Hebert wrote: > Well bad news on the ColoAU front, they refused to cooperate. > > We'll pushback thru our GTT accounts...  But I'm running out of ideas. > > If anyone has any good ideas how to proceed at this point feel free to > share =D. This feels like a BGP "optimiser" at work inside AS 4637. >From the https://lg.coloau.com.au/ looking glass: BGP 'show route' 18.29.238.0/23 *[BGP/170] 1w0d 18:49:44, localpref 90, from 103.97.52.2 AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified However, a data-plane traceroute: AS path: 4637 -> 174 -> ... traceroute to 18.29.238.1 (18.29.238.1), 30 hops max, 40 byte packets 1 103.52.116.49 (103.52.116.49) 114.573 ms 113.965 ms 117.141 ms MPLS Label=691873 CoS=0 TTL=1 S=0 MPLS Label=17 CoS=0 TTL=1 S=1 2 202.127.69.34 (202.127.69.34) 113.768 ms 113.763 ms 113.731 ms 3 202.84.148.113 (202.84.148.113) [AS 4637] 114.759 ms 117.956 ms 115.796 ms 4 202.84.141.13 (202.84.141.13) [AS 4637] 181.873 ms 202.84.141.169 (202.84.141.169) [AS 4637] 181.618 ms 182.688 ms 5 202.84.253.82 (202.84.253.82) [AS 4637] 181.949 ms 202.40.149.226 (202.40.149.226) [AS 4637] 183.194 ms 202.84.253.82 (202.84.253.82) [AS 4637] 201.282 ms 6 154.54.10.133 (154.54.10.133) [AS 174] 181.055 ms 181.100 ms 181.065 ms 7 154.54.27.117 (154.54.27.117) [AS 174] 175.410 ms 182.956 ms 154.54.3.69 (154.54.3.69) [AS 174] 175.176 ms 8 154.54.45.161 (154.54.45.161) [AS 174] 212.531 ms 154.54.44.85 (154.54.44.85) [AS 174] 202.470 ms 187.361 ms 9 154.54.42.78 (154.54.42.78) [AS 174] 195.585 ms 195.812 ms 154.54.42.66 (154.54.42.66) [AS 174] 211.713 ms 10 154.54.30.161 (154.54.30.161) [AS 174] 235.896 ms 216.173 ms 211.246 ms 11 154.54.28.129 (154.54.28.129) [AS 174] 233.516 ms 225.413 ms 225.551 ms 12 154.54.24.221 (154.54.24.221) [AS 174] 236.432 ms 236.701 ms 236.595 ms 13 154.54.40.109 (154.54.40.109) [AS 174] 273.564 ms 279.452 ms 248.212 ms 14 154.54.46.33 (154.54.46.33) [AS 174] 248.098 ms 247.802 ms 248.084 ms 15 * * * Discongruity between RIB and FIB like this, and the hijack being a more-specific of a /16, is a typical sign of BGP 'optimisers'. I recommend you reach out to AUSNOG and APOPS and hope someone there knows someone at Telstra Hong Kong. More thoughts on BGP optimisers: http://seclists.org/nanog/2017/Aug/318 Kind regards, Job From ahebert at pubnix.net Thu May 31 14:31:26 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 31 May 2018 10:31:26 -0400 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <20180531141541.GA75485@vurt.meerval.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> <20180531141541.GA75485@vurt.meerval.net> Message-ID: <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net>     Thanks for the ideas and the hint.  Good read.     Will do.     PS: Still curious how, beside some RIB/FIB failure, how our AS ended up there. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/31/18 10:15, Job Snijders wrote: > On Thu, May 31, 2018 at 09:49:47AM -0400, Alain Hebert wrote: >> Well bad news on the ColoAU front, they refused to cooperate. >> >> We'll pushback thru our GTT accounts...  But I'm running out of ideas. >> >> If anyone has any good ideas how to proceed at this point feel free to >> share =D. > This feels like a BGP "optimiser" at work inside AS 4637. > > >From the https://lg.coloau.com.au/ looking glass: > > BGP 'show route' > 18.29.238.0/23 *[BGP/170] 1w0d 18:49:44, localpref 90, from 103.97.52.2 > AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified > > However, a data-plane traceroute: > > AS path: 4637 -> 174 -> ... > > traceroute to 18.29.238.1 (18.29.238.1), 30 hops max, 40 byte packets > 1 103.52.116.49 (103.52.116.49) 114.573 ms 113.965 ms 117.141 ms > MPLS Label=691873 CoS=0 TTL=1 S=0 > MPLS Label=17 CoS=0 TTL=1 S=1 > 2 202.127.69.34 (202.127.69.34) 113.768 ms 113.763 ms 113.731 ms > 3 202.84.148.113 (202.84.148.113) [AS 4637] 114.759 ms 117.956 ms 115.796 ms > 4 202.84.141.13 (202.84.141.13) [AS 4637] 181.873 ms 202.84.141.169 (202.84.141.169) [AS 4637] 181.618 ms 182.688 ms > 5 202.84.253.82 (202.84.253.82) [AS 4637] 181.949 ms 202.40.149.226 (202.40.149.226) [AS 4637] 183.194 ms 202.84.253.82 (202.84.253.82) [AS 4637] 201.282 ms > 6 154.54.10.133 (154.54.10.133) [AS 174] 181.055 ms 181.100 ms 181.065 ms > 7 154.54.27.117 (154.54.27.117) [AS 174] 175.410 ms 182.956 ms 154.54.3.69 (154.54.3.69) [AS 174] 175.176 ms > 8 154.54.45.161 (154.54.45.161) [AS 174] 212.531 ms 154.54.44.85 (154.54.44.85) [AS 174] 202.470 ms 187.361 ms > 9 154.54.42.78 (154.54.42.78) [AS 174] 195.585 ms 195.812 ms 154.54.42.66 (154.54.42.66) [AS 174] 211.713 ms > 10 154.54.30.161 (154.54.30.161) [AS 174] 235.896 ms 216.173 ms 211.246 ms > 11 154.54.28.129 (154.54.28.129) [AS 174] 233.516 ms 225.413 ms 225.551 ms > 12 154.54.24.221 (154.54.24.221) [AS 174] 236.432 ms 236.701 ms 236.595 ms > 13 154.54.40.109 (154.54.40.109) [AS 174] 273.564 ms 279.452 ms 248.212 ms > 14 154.54.46.33 (154.54.46.33) [AS 174] 248.098 ms 247.802 ms 248.084 ms > 15 * * * > > Discongruity between RIB and FIB like this, and the hijack being a > more-specific of a /16, is a typical sign of BGP 'optimisers'. > > I recommend you reach out to AUSNOG and APOPS and hope someone there > knows someone at Telstra Hong Kong. > > More thoughts on BGP optimisers: http://seclists.org/nanog/2017/Aug/318 > > Kind regards, > > Job > From mark.tinka at seacom.mu Thu May 31 14:38:36 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 May 2018 16:38:36 +0200 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <20180531141541.GA75485@vurt.meerval.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> <20180531141541.GA75485@vurt.meerval.net> Message-ID: On 31/May/18 16:15, Job Snijders wrote: > I recommend you reach out to AUSNOG and APOPS and hope someone there > knows someone at Telstra Hong Kong. I have a friend at Telstra HKG. He's not in the IP team, but he can summon a warm body if needed. Mark. From job at ntt.net Thu May 31 14:40:06 2018 From: job at ntt.net (Job Snijders) Date: Thu, 31 May 2018 14:40:06 +0000 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> <20180531141541.GA75485@vurt.meerval.net> <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net> Message-ID: <20180531144006.GB75485@vurt.meerval.net> On Thu, May 31, 2018 at 10:31:26AM -0400, Alain Hebert wrote: > Thanks for the ideas and the hint.  Good read. > > Will do. Upon further inspection, it seems more likely that the bgp optimiser is in ColoAU's network. Given the scale of AS 4637, if it were deployed inside Telstra I'd expect more problem reports. AS 4637 may actually just be an innocent bystander. It is interesting to note that the /23 only appears on their Sydney based routers on https://lg.coloau.com.au/ Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps you should just straight up ask whether they use any type of "network optimisation" appliance. > PS: Still curious how, beside some RIB/FIB failure, how our AS ended > up there. I don't know why, but often fabricating random AS_PATH stuff seems to be part of it. Kind regards, Job From mark.tinka at seacom.mu Thu May 31 14:40:42 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 May 2018 16:40:42 +0200 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> <20180531141541.GA75485@vurt.meerval.net> <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net> Message-ID: <257b7269-2ff6-e94b-368b-d43d15a69212@seacom.mu> On 31/May/18 16:31, Alain Hebert wrote: > >     PS: Still curious how, beside some RIB/FIB failure, how our AS > ended up there. We've suffered this many times as well, particularly when records show up on HE's BGP tool. It's a b**ch to get fixed, because too many fingers get pointed, and folk running BGP optimizers may not fully understand this side effect. Mark. From job at instituut.net Thu May 31 18:36:36 2018 From: job at instituut.net (Job Snijders) Date: Thu, 31 May 2018 18:36:36 +0000 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <20180531144006.GB75485@vurt.meerval.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> <20180531141541.GA75485@vurt.meerval.net> <0f9f25af-2aeb-b782-f270-c48c8b05260d@pubnix.net> <20180531144006.GB75485@vurt.meerval.net> Message-ID: <20180531183636.GD75485@vurt.meerval.net> On Thu, May 31, 2018 at 02:40:06PM +0000, Job Snijders wrote: > Upon further inspection, it seems more likely that the bgp optimiser is > in ColoAU's network. Given the scale of AS 4637, if it were deployed > inside Telstra I'd expect more problem reports. AS 4637 may actually > just be an innocent bystander. > > It is interesting to note that the /23 only appears on their Sydney > based routers on https://lg.coloau.com.au/ > > Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps > you should just straight up ask whether they use any type of "network > optimisation" appliance. I found a few more interesting routes inside ColoAU's looking glass: 128.10.4.0/24 - AS_PATH 63956 4637 3257 29909 16532 16532 16532 16532 (should be 128.10.0.0/16 originated by AS 17, Purdue University) 192.54.130.0/24 - AS path: 135069 9439 (does not exist in the DFZ, a peering lan prefix? a typo?) 67.215.73.0/24 - AS path: 2764 1221 36692 (does not exist in the DFZ, a peering lan prefix? a typo?) ColoAU propagated the above routes to their transit customers, so the 128.10.4.0/24 and 18.29.238.0/23 announcements definitely count as BGP hijacks with fabricated an AS_PATH. Kind regards, Job From goemon at sasami.anime.net Thu May 31 18:37:44 2018 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 31 May 2018 11:37:44 -0700 (PDT) Subject: ICANN GDPR lawsuit In-Reply-To: <23311.35715.83014.161912@gargle.gargle.HOWL> References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: On Thu, 31 May 2018, bzs at theworld.com wrote: > FWIW a German court has just ruled against ICANN's injunction and in > favor of Tucows/EPAG. > https://www.icann.org/news/announcement-4-2018-05-30-en Welcome to contact-free whois? -Dan From john-nanog at peachfamily.net Thu May 31 18:44:50 2018 From: john-nanog at peachfamily.net (John Peach) Date: Thu, 31 May 2018 14:44:50 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: On 05/31/2018 02:37 PM, Dan Hollis wrote: > On Thu, 31 May 2018, bzs at theworld.com wrote: >> FWIW a German court has just ruled against ICANN's injunction and in >> favor of Tucows/EPAG. >>   https://www.icann.org/news/announcement-4-2018-05-30-en > > Welcome to contact-free whois? > > -Dan Already been bitten by it and trying to get the contact info reinstated. -- John PGP Public Key: 412934AC From oliver.oboyle at gmail.com Thu May 31 18:49:40 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Thu, 31 May 2018 14:49:40 -0400 Subject: ICANN GDPR lawsuit In-Reply-To: References: <20180531031609.81E8D277440B@ary.qy> <23311.35715.83014.161912@gargle.gargle.HOWL> Message-ID: whoisnt On Thu, May 31, 2018 at 2:37 PM, Dan Hollis wrote: > On Thu, 31 May 2018, bzs at theworld.com wrote: >> >> FWIW a German court has just ruled against ICANN's injunction and in >> favor of Tucows/EPAG. >> https://www.icann.org/news/announcement-4-2018-05-30-en > > > Welcome to contact-free whois? > > -Dan -- :o@> From ross at tajvar.io Fri May 25 04:42:05 2018 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 25 May 2018 00:42:05 -0400 Subject: VPP-based router Message-ID: Hi all, Has anyone had any luck building their own routers on common compute (x86) with VPP? I'm considering it as I'm looking for a cheap, fast peering router. I haven't seen much written about that type of solution so I was wondering if anyone here has experience to share. Thanks, Ross From sabina at auxes.is Fri May 25 14:28:01 2018 From: sabina at auxes.is (Sabina M.) Date: Fri, 25 May 2018 10:28:01 -0400 Subject: SD-WAN Solutions In-Reply-To: <80a7f8ac-e72a-cd71-aa57-2e8c70c64d10@sneep.net> References: <80a7f8ac-e72a-cd71-aa57-2e8c70c64d10@sneep.net> Message-ID: <1ALeDfoh89kTC5ryAcVS66qVRESLXU5WLvdOKSsdrCFdTPYEmLIBF8MaSnFnM62zC9fA2-6JXQANqNLFgrO5D02AnJLPnDhUpK91rznoxTg=@auxes.is> Thanks everyone for replying! As for why I'm asking, working today together with a $customer in order to figure out integration with other VXLAN environments, and extending the control plane past just the nuage solution. There's plenty of customers that use either basic VXLAN (think Cisco N9k with barebone VXLAN EVPN, not ACI), Juniper Contrail and others. The "rumors" that I heard regarding the nuage solution is that so far, Nokia/Alcatel hasn't implemented the RFC for EVPN to the letter and that there there's quite a bit of custom stuff in there (from sym/asym routing methods) to signaling and all. My question boils down to when/how will nuage implement interoperability with other vendors at VXLAN level? In the SP market we've had it for years where you can have MPLS on a variety of boxes and the network wouldn't suffer from this. It seems with VXLAN it's less cooperative (and I understand there's more to it now than just the protocol and it's more a fabric approach) Also, can you maybe tell me/us more about these extensions? ​​ ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On May 24, 2018 11:40 PM, Alastair Johnson wrote: > ​​ > > On 5/24/18 5:43 AM, Sabina M. wrote: > > > Has anyone worked with Nuage from around here? Additionally, is anyone familiar with what RFC Alcatel/Nokia is implementing for the VXLAN part of the solution? It looks a bit non-standard but I can't find any clear documentation regarding this anywhere > > > > Cheers, > > > > S. > > Hi Sabina, > > I work for Nuage Networks. What can I help you with? Happy to discuss > > our architecture, but may I know why you are asking? > > VxLAN is just the datapath. Control plane is based on EVPN and is > > standards-based for our DC overlay platform, but the SD-WAN product uses > > a number of extensions. > > Regards, > > AJ > > aj at nuagenetworks.net From michel.py at tsisemi.com Fri May 25 19:05:48 2018 From: michel.py at tsisemi.com (Michel Py) Date: Fri, 25 May 2018 19:05:48 +0000 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> Message-ID: <2408ff7074d248a897dd4856d0f92489@CRA110.am.necel.com> There is a good possibility that AS 16532 was trying to prepend 3 times and did prepend 16532 3 instead of prepend 16532 16532 16532. That tends to happen with very low number AS Regards, Michel. Regards, Nik. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nikolas Geyer Sent: Friday, May 25, 2018 11:59 AM To: ahebert at pubnix.net Cc: NANOG list Subject: Re: BGP Hijack/Sickness with AS4637 Greetings! Actually, what you have provided below shows the exact opposite. It shows ColoAU have received the route from 4637 who have received it from 3257 who have received it from 29909 who have received it from 16532 who originated it. It infers nothing about who 16532 found the route to come from. It is evident that GTT are advertising that route to Telstra Global :) Regards, Nik. > > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as they're not the one advertising those routes to AS4637 > > AS16532 found it to come from AS4637 as you can see from this ColoAU LG output below > > > ----- https://lg.coloau.com.au/ > > vrf-international.inet.0: 696533 destinations, 2248101 routes (696249 active, 0 holddown, 103835 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from 103.97.52.2 > AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified > > -- > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From baldwinmathew at gmail.com Sun May 27 02:33:15 2018 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Sat, 26 May 2018 19:33:15 -0700 Subject: Whois vs GDPR, latest news In-Reply-To: References: <20180523155314.50F5427017BC@ary.qy> <23F95971-15FF-40FC-8734-9BED927FCB13@delong.com> <5A73E317-2769-486D-84BA-E425126B692A@isipp.com> <10D58470-EC7A-4DD8-85EB-8A6E5E8E6F6C@delong.com> <696751EE-EE6C-4B70-93EE-C30C6E8DD21D@delong.com> <977B4B87-C7A9-490C-A856-0C96E5A5D88D@isipp.com> Message-ID: You mean something like this? https://certikit.com/products/gdpr-toolkit/ While not CC licensed it might get you where you need to go. On Sat, May 26, 2018, 7:06 PM Dan Hollis wrote: > On Sat, 26 May 2018, Royce Williams wrote: > > Naively ... to counter potential panic, it would be awesome to > crowdsource > > some kind of CC-licensed GDPR toolkit for small orgs. Something like a > > boilerplate privacy policy (perhaps generated by answers to questions), > > plus some simplified checklists, could go a long way - towards both > > compliance and actual security benefit. > > who is willing to accept the risk of being involved in creation of such a > thing? would you? > > if someone uses it and ends up being hit by eu regulators, you can bet > the toolkit creators will be sued. > > who would be willing to use a crowdsourced legal toolkit given the risks > of a violation? would you? > > -Dan > From mail at theo-voss.de Sun May 27 14:32:25 2018 From: mail at theo-voss.de (Theo Voss) Date: Sun, 27 May 2018 14:32:25 +0000 Subject: Bezeq Internet (IL) around? In-Reply-To: <20180524162028.GC1007@anx-nb3810.local> References: <20180524162028.GC1007@anx-nb3810.local> Message-ID: <6E523F23-433F-4D15-9E2A-417281AA4761@theo-voss.de> Hi all, is there anyone from an Israeli ISP other than Bezeq around who is capable of providing colocation/transit in Tel Aviv? Best regards, Theo Voss Am 24.05.18, 18:23 schrieb "NANOG im Auftrag von Elmar K. Bins" : Hi Bezeq people, I hope you're subscribed here, I could use your immediate help, probably leading to a contract... Yours, Elmar. From edwin.salazar at wifitelecom.ec Mon May 28 16:28:26 2018 From: edwin.salazar at wifitelecom.ec (Ing. Edwin Salazar) Date: Mon, 28 May 2018 11:28:26 -0500 Subject: Satelite Internet Provider Message-ID: Hi, I would like to know if anyone knows any satellite internet provider for the Galapagos Islands in Ecuador that I can contact? Best regards, Edwin Salazar. From ringostarr0706 at gmail.com Tue May 29 12:48:16 2018 From: ringostarr0706 at gmail.com (Ryugo Kikuchi) Date: Tue, 29 May 2018 21:48:16 +0900 Subject: 3rd party QSFP-100G-LR4-S for Cisco Message-ID: Hey all, Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for Cisco ASR and Nexus? Cisco's original 100G SFP costs us an arm and a leg, so we want to try to use 3rd party 100g SFP. But we are not sure which manufacturer's SFP is reliable or has good performance. Does anyone have experience? Many thanks, Roy From lee.howard at retevia.net Tue May 29 14:55:18 2018 From: lee.howard at retevia.net (Lee Howard) Date: Tue, 29 May 2018 10:55:18 -0400 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> References: <1270254436.530118.1527517389505.JavaMail.zimbra@ics-il.net> Message-ID: <837f56b5-65f1-12e5-7b89-c1a387dbef9a@retevia.net> On 05/28/2018 10:23 AM, Mike Hammett wrote: > Has anyone outside of tech media, Silicon Valley or academia (all places wildly out of touch with the real world) put much thought into the impacts of encryption everywhere? See "Effects of Pervasive Encryption on Operators." https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/?include_text=1 TLS1.3 uses ephemeral keys, so even if you own both endpoints and everything in the middle, you can't decrypt a flow without some yet-to-be-developed technology. QUIC encrypts everything, and of course, HTTPS. > So often we hear about how we need the best modern encryption on all forms of communication because of whatever scary thing is trendy this week (Russia, NSA, Google, whatever). HTTPS your marketing information and generic education pieces because of the boogeyman! > > However, I recently came across a thread where someone was exploring getting a one megabit connection into their village and sharing it among many. The crowd I referenced earlier also believes you can't Internet under 100 megabit/s per home. Yeah. Too many people forget that most of the Internet is mobile, and mobile != LTE. People also assume packet loss < 0.1%, latency <100ms, and power reliability >99%. > However, this could be wildly improved with caching ala squid or something similar. The problem is that encrypted content is difficult to impossible for your average Joe to cache. The rewards for implementing caching are greatly mitigated and people like this must suffer a worse Internet experience because of some ideological high horse in a far-off land. > > Some things certainly do need to be encrypted, but encrypting everything means people with limited Internet access get worse performance OR mechanisms have to be out in place to break ALL encryption, this compromising security and privacy when it's really needed. > > To circle back to being somewhat on-topic, what mechanisms are available to maximize the amount of traffic someone in this situation could cache? The performance of third-world Internet depends on you. > A proxy is all I've thought of. But it means everything is dependent on the proxy, and it's even in-path for things that really should be encrypted, like email and messaging. I can't imagine why the weather should be encrypted, when everyone in a location wants to know the forecast. Lee From CConn at b2b2c.com Tue May 29 20:34:44 2018 From: CConn at b2b2c.com (Chris Conn) Date: Tue, 29 May 2018 20:34:44 +0000 Subject: FW: BGP Hijack/Sickness with AS4637 References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> Message-ID: Hello, I am the contact for AS16532. We never announced nor are we currently advertising this prefix as we are not a transit AS for anyone. As well, it seems to appear and disappear from AS63956 looking glass. According to that LG, the route changed 6d ago, and is *still currently visible* at this very moment; https://lg.coloau.com.au/ Command: show route 18.29.238.0 protocol bgp table vrf-international.inet.0 active-path vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 holddown, 103994 hidden) + = Active Route, - = Last Active, * = Both 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2 AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA. There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path? I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change anything, as I am not seeing this prefix in their route-server public at route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp active-path inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 18.29.0.0/16 *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23 AS path: 3257 174 3 I, validation-state: unverified > to 141.136.111.13 via xe-1/0/0.0 {master} public at route-server.as3257.net-re0> {master} public at route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp | find 16532 Pattern not found {master} So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find. Chris Conn AS16532 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tom Paseka via NANOG Sent: Friday, May 25, 2018 6:01 PM To: Nikolas Geyer Cc: NANOG list Subject: Re: BGP Hijack/Sickness with AS4637 This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. Bouncing your session with 4637 would likely clear this. -Tom On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer wrote: > Greetings! > > Actually, what you have provided below shows the exact opposite. It > shows ColoAU have received the route from 4637 who have received it > from 3257 who have received it from 29909 who have received it from > 16532 who originated it. It infers nothing about who 16532 found the route to come from. > > It is evident that GTT are advertising that route to Telstra Global :) > > Regards, > Nik. > > > > > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, > > as > they're not the one advertising those routes to AS4637 > > > > AS16532 found it to come from AS4637 as you can see from this > > ColoAU > LG output below > > > > > > ----- https://lg.coloau.com.au/ > > > > vrf-international.inet.0: 696533 destinations, 2248101 routes > > (696249 > active, 0 holddown, 103835 hidden) > > + = Active Route, - = Last Active, * = Both > > > > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from > 103.97.52.2 > > AS path: 4637 3257 29909 16532 16532 16532 > > 16532 > I, validation-state: unverified > > > > -- > > ----- > > Alain Hebert ahebert at pubnix.net > > PubNIX Inc. > > 50 boul. St-Charles > > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > > From marcusleskex at gmail.com Wed May 30 01:10:10 2018 From: marcusleskex at gmail.com (Marcus Leske) Date: Tue, 29 May 2018 18:10:10 -0700 Subject: Opinions on intent-based networking In-Reply-To: References: Message-ID: A Tier-1 deployed it today. http://www.lightreading.com/data-center/data-center-infrastructure/apstra-dell-emc-boast-tier-1-deployment-/d/d-id/743452 It can be a lot of things and nothing, it can be just a GUI with some UX built into it, relatively making it easy to configure stuff, and it can be just a bunch of well written automation scripts with all sorts of checks and whistles, it can be just a little bit more analytics on top of that, and it can definitely be something a lot more if done PROPERLY, I hear good things about Apstra but i cant confirm because it can easily be marketing. In my humble opinion, if done properly, the Network Operating System would send telemetry info on any change in the network, and the Intent Based Networking system would consume that, run it by a lot of policies and take automated/guided actions. There is a webinar tomorrow with their VP of Engneering, join it and ask your question: http://go.apstra.com/webinar-apstra-cumulus-disaggregation Cheers, Marcus > On Tue, May 29, 2018 at 7:29 PM, K. Scott Helms wrote: >> A substantial percentage, perhaps 100%, of the use case can be accomplished >> using micro-segmentation. >> >> On Tue, May 29, 2018 at 2:33 PM LF OD wrote: >> >>> Been following the articles on "intent-based" networking from Cisco and >>> other vendors for a couple years now, and I have a basic grasp of the >>> concept of "define your goals/outcomes and automation will make it so", but >>> I do not know the practical applications of it or how you are supposed to >>> convey your "intent". However, $dayjob is a medium-sized enterprise and >>> looking at a potential refresh in the upcoming budget. >>> >>> >>> So... do any of you at ISPs, Cloud Providers, or Enterprises have any >>> hands-on experience with "intent-based" networking products? If so, could >>> you please provide some info on what caused you to look at it, who did you >>> look at, why did you choose whoever you chose, and is it working out for >>> you? >>> >>> >>> If you looked at it very closely and decided not to bother with it, I'd >>> also be interested on your take. At $dayjob we have been adopting >>> automation at the application and workload level, but there hasn't been >>> much need for it at the infrastructure level. However, if we can improve >>> the services we offer while refreshing that infrastructure, it wouldn't >>> hurt - depending on cost of course. >>> >>> >>> Thanks in advance. >>> >>> LF0D >>> From CConn at b2b2c.com Wed May 30 12:50:11 2018 From: CConn at b2b2c.com (Chris Conn) Date: Wed, 30 May 2018 12:50:11 +0000 Subject: BGP Hijack/Sickness with AS4637 Message-ID: Hello, I am the contact for AS16532. We never announced nor are we currently advertising this prefix as we are not a transit AS for anyone. As well, it seems to appear and disappear from AS63956 looking glass. According to that LG, the route changed 6d ago, and is *still currently visible* at this very moment; https://lg.coloau.com.au/ Command: show route 18.29.238.0 protocol bgp table vrf-international.inet.0 active-path vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 holddown, 103994 hidden) + = Active Route, - = Last Active, * = Both 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2 AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA. There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path? I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change anything, as I am not seeing this prefix in their route-server public at route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp active-path inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 18.29.0.0/16 *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23 AS path: 3257 174 3 I, validation-state: unverified > to 141.136.111.13 via xe-1/0/0.0 {master} public at route-server.as3257.net-re0> {master} public at route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp | find 16532 Pattern not found {master} So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find. Chris Conn AS16532 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tom Paseka via NANOG Sent: Friday, May 25, 2018 6:01 PM To: Nikolas Geyer Cc: NANOG list Subject: Re: BGP Hijack/Sickness with AS4637 This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. Bouncing your session with 4637 would likely clear this. -Tom On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer wrote: > Greetings! > > Actually, what you have provided below shows the exact opposite. It > shows ColoAU have received the route from 4637 who have received it > from 3257 who have received it from 29909 who have received it from > 16532 who originated it. It infers nothing about who 16532 found the route to come from. > > It is evident that GTT are advertising that route to Telstra Global :) > > Regards, > Nik. > > > > > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, > > as > they're not the one advertising those routes to AS4637 > > > > AS16532 found it to come from AS4637 as you can see from this > > ColoAU > LG output below > > > > > > ----- https://lg.coloau.com.au/ > > > > vrf-international.inet.0: 696533 destinations, 2248101 routes > > (696249 > active, 0 holddown, 103835 hidden) > > + = Active Route, - = Last Active, * = Both > > > > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from > 103.97.52.2 > > AS path: 4637 3257 29909 16532 16532 16532 > > 16532 > I, validation-state: unverified > > > > -- > > ----- > > Alain Hebert ahebert at pubnix.net > > PubNIX Inc. > > 50 boul. St-Charles > > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > > From sghuter at nsrc.org Wed May 30 20:58:24 2018 From: sghuter at nsrc.org (Steven G. Huter) Date: Wed, 30 May 2018 13:58:24 -0700 Subject: Impacts of Encryption Everywhere (any solution?) In-Reply-To: <60f8fa19-5ff2-c2d9-6b64-97395dfb636d@seacom.mu> References: <20180528170656.946FF7FE@m0117567.ppops.net> <2DB53E80-E643-46FE-A0D8-89B2BDBD645D@delong.com> <6703f6dd-287f-af1e-5890-8c809fa4b264@seacom.mu> <6D15A7AA-E642-4276-8F6A-863D91E3459D@6by7.net> <66ba1843c3c84526aada24c6c908cb87@SC58MEXGP032.CORP.CHARTERCOM.com> <60f8fa19-5ff2-c2d9-6b64-97395dfb636d@seacom.mu> Message-ID: <1ca188d8-3160-2c43-3965-83aa29207863@nsrc.org> On 5/30/18 1:44 PM, Mark Tinka wrote: > Backhaul isn't a major issue - pretty much, every MNO in Africa has > their own Metro and national fibre backbone; and in some cases, even > their own submarine backbone. > > This map is still a work in progress, but it's clear that roll-out of fiber across the continent is steadily growing. https://afterfibre.nsrc.org/ Steve Huter From ross at tajvar.io Wed May 30 22:09:28 2018 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 30 May 2018 18:09:28 -0400 Subject: SIP fax sending software? In-Reply-To: References: Message-ID: I've found T.38 5o be very reliable. We have many customers using it daily. On Wed, May 30, 2018, 5:39 PM Andy Ringsmuth wrote: > > > On May 30, 2018, at 4:10 PM, Andrew Latham wrote: > > > > T.38 if your provider supports it > > > > Try https://github.com/hehol/t38modem > > > > On Wed, May 30, 2018 at 3:15 PM John R. Levine wrote: > > > >> Can anyone recommend software that sends faxes over SIP? I have plenty > of > >> inbound fax to email services, but now and then I need to send a reply > and > >> it looks tacky to use one of the free web ones that put an ad on it. > >> > >> I know that if I wanted to pay $15/mo there are lots of lovely services > >> but we're taking about one fax a month, maybe, here. > >> > >> Ideally it'd take a postscript or PDF or Word document and a phone > number > >> and fax it to that number. I have Ubuntu, FreeBSD, and MacOS boxes. > Any > >> suggestions? > > I ran into this issue when we went to a SIP phone system earlier this > year. We opted to go with HelloFax and it has worked well. > > They do have a free account which allows you to send up to 5 faxes a month. > > ---- > Andy Ringsmuth > andy at newslink.com > News Link – Manager Technology, Travel & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > > From farzi at gatech.edu Thu May 31 05:14:18 2018 From: farzi at gatech.edu (Badiei, Farzaneh) Date: Thu, 31 May 2018 05:14:18 +0000 Subject: ICANN GDPR lawsuit In-Reply-To: <20180531031609.81E8D277440B@ary.qy> References: , <20180531031609.81E8D277440B@ary.qy> Message-ID: And here is the court decision, https://www.icann.org/en/system/files/files/litigation-icann-v-epag-request-court-order-prelim-injunction-redacted-30may18-en.pdf gotta love the German wisdom: The Application for preliminary injunction of May 25, 2018 is rejected at the expense of the Applicant. "Insofar as the Applicant bases its claim to relief on a parallel of the so-called "WHOIS" system to international agreements on trade mark registers, the Chamber is unable to follow this. The legal basis for the trademark registers on the basis of international agreements is missing in relation to the "WHOIS" service claimed by the Applicant. The fundamental comparability of the respective general need for protection does not change this." ________________________________ From: NANOG on behalf of John Levine Sent: Wednesday, May 30, 2018 11:16:08 PM To: nanog at nanog.org Subject: Re: ICANN GDPR lawsuit In article you write: >http://www.circleid.com/posts/20180527_icann_files_legal_action_against_domain_registrar_whois_data/ Elliot said that if he had to choose between fighting ICANN and fighting governments, he'd fight ICANN. I can't blame him. http://www.tucows.com/tucows-statement-on-icann-legal-action/ R's, John From phil.lavin at cloudcall.com Thu May 31 13:58:20 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Thu, 31 May 2018 13:58:20 +0000 Subject: BGP Hijack/Sickness with AS4637 In-Reply-To: <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> References: <25C947D4-A1A8-4DEE-BA2C-67ABC1965E97@neko.id.au> <587c182d-b71d-33e3-18fe-32df5ee60d36@pubnix.net> Message-ID: What is the relationship of 103.97.52.2 (Colocation Australia - Japan) to you? Is this, for example, a peering over an IX? If so, did you learn the route from route servers or do you peer directly with them? Phil -----Original Message----- From: NANOG On Behalf Of Alain Hebert Sent: 31 May 2018 14:50 To: nanog at nanog.org Subject: Re: BGP Hijack/Sickness with AS4637     Hi,     Well bad news on the ColoAU front, they refused to cooperate.     We'll pushback thru our GTT accounts...  But I'm running out of ideas.     If anyone has any good ideas how to proceed at this point feel free to share =D. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/29/18 16:31, Chris Conn wrote: > Hello, > > I am the contact for AS16532. > > We never announced nor are we currently advertising this prefix as we > are not a transit AS for anyone. As well, it seems to appear and > disappear from AS63956 looking glass. According to that LG, the route > changed 6d ago, and is *still currently visible* at this very moment; > > https://lg.coloau.com.au/ > > Command: show route 18.29.238.0 protocol bgp table > vrf-international.inet.0 active-path > > vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 > active, 0 holddown, 103994 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2 > AS path: 4637 3257 29909 16532 16532 16532 > 16532 I, validation-state: unverified > > > AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA. > > There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path? > > I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would > change anything, as I am not seeing this prefix in their route-server > > public at route-server.as3257.net-re0> show route 18.29.238.0 protocol > bgp active-path > > inet.0: 691667 destinations, 11752983 routes (691665 active, 1 > holddown, 1 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.0.0/16 *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23 > AS path: 3257 174 3 I, validation-state: unverified > > to 141.136.111.13 via xe-1/0/0.0 > > {master} > public at route-server.as3257.net-re0> > > > {master} > public at route-server.as3257.net-re0> show route 18.29.238.0 protocol > bgp | find 16532 > > Pattern not found > {master} > > > > So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find. > > > Chris Conn > AS16532 > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tom Paseka > via NANOG > Sent: Friday, May 25, 2018 6:01 PM > To: Nikolas Geyer > Cc: NANOG list > Subject: Re: BGP Hijack/Sickness with AS4637 > > This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. > > If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. > Bouncing your session with 4637 would likely clear this. > > -Tom > > On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer wrote: > >> Greetings! >> >> Actually, what you have provided below shows the exact opposite. It >> shows ColoAU have received the route from 4637 who have received it >> from 3257 who have received it from 29909 who have received it from >> 16532 who originated it. It infers nothing about who 16532 found the route to come from. >> >> It is evident that GTT are advertising that route to Telstra Global >> :) >> >> Regards, >> Nik. >> >>> And I'm pretty sure AS3257 (GTT ) is in the same boat as >>> us, as >> they're not the one advertising those routes to AS4637 >>> AS16532 found it to come from AS4637 as you can see from this >>> ColoAU >> LG output below >>> >>> ----- https://lg.coloau.com.au/ >>> >>> vrf-international.inet.0: 696533 destinations, 2248101 routes >>> (696249 >> active, 0 holddown, 103835 hidden) >>> + = Active Route, - = Last Active, * = Both >>> >>> 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from >> 103.97.52.2 >>> AS path: 4637 3257 29909 16532 16532 16532 >>> 16532 >> I, validation-state: unverified >>> -- >>> ----- >>> Alain Hebert ahebert at pubnix.net >>> PubNIX Inc. >>> 50 boul. St-Charles >>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >>> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >>>