- Test - lists.nanog.org

Re: NANOG Digest, Vol 138, Issue 11
by Brandon Svec 11 Jul '19

11 Jul '19

Having a somewhat bell shaped head, this sums it up pretty well, “.. Maybe they don't actually care about this problem until they are 'forced' to care about it by their regulating body?” As I understand, currently carriers are required to pass spoofed caller ID because there are many legitimate reasons to do so. There was some recent legislation loosening that requirement and there is no requirement to define what legitimate is, but still the issue is some one needs to care about the problem. That will require legislation and incentives to get to. > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Christopher > >Morrow > >Sent: Wednesday, 10 July, 2019 22:10 > >To: Sean Donelan > >Cc: nanog list > >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > > > >On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan <sean(a)donelan.com> > >wrote: > >> > >> On Tue, 9 Jul 2019, Sean Donelan wrote: > >> > The agenda looks like lots of happy, happy talk from industry > >> > representatives. > >> > >> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a > >press > >> release announcing plans to automatically block robocalls for its > >> customers. > >> > >> https://about.att.com/story/2019/att_call_protect.html > >> > >> Automatic Blocking of Fraud Calls Coming to Millions of AT&T > >Customers > >> AT&T* will add automatic fraud blocking and suspected spam-call > >alerts to > >> millions of AT&T consumer lines at no charge. > > > >oh goodie! > > > >So, not being a bell shaped headed person... a question: > > The calling path and data available inside the phone network smells > >(to me) like: > > ingress trunk + ANI + CallerID + outgoing trunk of destination > >ds0/handset > > > >There seem like a bunch of pretty simple 'correlations' one could > >make, that actually look a heck of a lot like 'netflow/log analysis > >for ddos detection': > > o is this trunk sourcing calls to 'too many' of my subs in > >period-of-time-X > > o is this trunk sourcing calls from a low distribution of ANI but > >a different distribution of CallerID > > o is this trunk sourcing calls from unmatched (as a percent of > >total) ANI/CallerID > > > >I would think you could make similar correlations across the > >destinations on your phone-network: > > o Is there one ANI or CallerID talking to 'all' (a bunch, more > >than X of type Y customer end point) of my endpoints? > > o are there implausible callerid being used? (lots of 'NPA-NXX > >matches destination, yet from a very different geography?) > > > >I imagine that with the number of calls here, this is just a splunk > >correlation away from successful identification and then disabling of > >these nuisance calls... > >I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a > >whiff of a care" on the part of the carrier(s), right? > >Maybe they don't actually care about this problem until they are > >'forced' to care about it by their regulating body? > >'shaken' and 'stir' may not do anything at all useful for the > >problem, > >but they do make it appear that the carriers care about the > >problem... > >I'm certain that they know there are problems. The 5 items above > >can't > >be 'new and novel' concepts ... since this is basically 'logs > >analysis' that any security engineer worth their salt does as a > >matter > >of course daily, right? > > > >-chris > > > > > > End of NANOG Digest, Vol 138, Issue 11 > ************************************** > -- Brandon Svec 15106862204 voice | fax | sms teamonesolutions.com 14729 Catalina St. San Leandro, CA 94577 .ılı.ılı. Cisco Meraki CMNA

2 1

Reddit down
by Robert Webb 11 Jul '19

11 Jul '19

Are we having yet another CDN meltdown or is it isolated to just reddit?

8 9

Research survey about locating configuration errors
by Aaron Gember-Jacobson 10 Jul '19

10 Jul '19

Over the past decade, numerous tools have been developed to check the correctness of router configurations. However, there seems to be a gap between the information these tools provide and the information required to fix the configurations. As part of an ongoing research project at Colgate University, we seek to better understand how network engineers currently locate errors in router configurations. We would appreciate if you could take 2 minutes to complete our anonymous, 10-question survey: https://colgate.co1.qualtrics.com/jfe/form/SV_e3CQ3JMfCnLJHTL If you are willing to share more about your experience with configuration errors and/or current network analysis tools, please let us know. You can learn more about our research at: https://aaron.gember-jacobson.com/research/faultloc. Thanks, Aaron Gember-Jacobson *Assistant Professor of Computer Science, **Colgate University*

1 0

QoS for Office365
by Joe Yabuki 10 Jul '19

10 Jul '19

Hi all, How do you deal with QoS for Office365, since the IPs are subject to changes ? How can we mark the trafic while keeping the security (I fear the marking based on TCP/UDP Ports since they are not without an additional risk coming from worms/virus using those ports for example, and doing that directly on the PCs doesn't seem to be the best solution) ? Many thanks, Joe

24 48

Looking for a knowledgeable Level3 and GTT off-list contact
by ecdhe 10 Jul '19

10 Jul '19

Some of your resources are being used for organized crime and attacks (but not originating from your network). I would appreciate an off-list contact if anyone knows of one. Thank you.

2 1

[FYI] Call for Presentations European Peering Forum 14 (EPF14) // NANOG
by Arnold Nipper 10 Jul '19

10 Jul '19

Dear Community This is the Call for Presentations European Peering Forum 14 (EPF14) AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th September 2019. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu>. Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Presentation Abstract Deadline 15/07/2019 12:00 UTC Final Selection of Speakers 26/07/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC More information about the event and other activities around EPF14 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1486607564933665/ Best regards Arnold -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 1

.ARPA Zone DNSSEC Operational Update -- ZSK length change
by Wessels, Duane 10 Jul '19

10 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, Verisign is in the process of increasing the size and strength of the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that it operates. As part of this process, the ZSK for the .ARPA zone will be increased in size from 1024 to 2048 bits. On July 11, 2019 the 2048 bit ZSK will be pre-published in the .ARPA zone. On July 21, the .ARPA zone will be signed with the 2048 bit ZSK. On August 10, the 1024 bit ZSK will be removed from the zone. We do not anticipate any problems from this upgrade. In accordance with our normal operating procedures we have a rollback process should it become necessary to revert to the 1024 bit ZSK. DW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJdJQifAAoJEGyZpGmowJiNxjcH/3a+ox9KyGAT5vnrcxfEYYIQ X2iQ0dSEBCv9JPNwTnKkV2U2xzG3uZb6LHjq9tihtA4M04IaMvlLnZMUFUyGgzrl ACvn6j9qCE0q7sgDGo/RNWXBsAd58mKgBVMMRCBR6AklDHVA+grEH2CwDwP0eGYZ 8dy6Cf94jqXqiVDQIxoK31YhYFqNVRhZE4f72V+6lh1fg4GrsfXKeErYwQooxdYT 91H9TmffWmEpG+eYdgWMOPPS+nsrDr/MAuSVD0t5hT8H/HrCo45MNxxskmwLg0Ni QAHgy5Ao2jgJj6MkzZdwjldM8mn5YzMegiHUF9R5W5TRlnNm7uGTU32Irzu7b/8= =lJK6 -----END PGP SIGNATURE-----

1 0

.NET Zone DNSSEC Operational Update -- ZSK length change
by Wessels, Duane 10 Jul '19

10 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, Verisign is in the process of increasing the size and strength of the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that it operates. As part of this process, the ZSK for the .NET zone will be increased in size from 1024 to 1280 bits. On July 10, 2019 the 1280 bit ZSK will be pre-published in the .NET zone. On July 15, the .NET zone will be signed with the 1280 bit ZSK. On July 20, the 1024 bit ZSK will be removed from the zone. We do not anticipate any problems from this upgrade. In accordance with our normal operating procedures we have a rollback process should it become necessary to revert to the 1024 bit ZSK. DW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJdJQifAAoJEGyZpGmowJiNVEsH/2T8Qm/ZZiM7K1G+6XN4wMSR oqyuzY/0AiqXpw0C2aL3sE3VhYPZWTY+H5wwbvU+ZoAbiMfcOygBv/JTLizpjLLK NJD+Gh51Z6cQn5yk9cPjRtoxdQrV83T0gRQIlPeFW3sm9GrXgropfQ/Dw7O0lHkZ x2oiGwC0HF5npi6OWEHpETemtSMWl5HpFfmYZhzXoBSzEbzHgXQwr0Fie9wtNkDm qPjwaeq3drENOoum4egpAFxQZM7FclLtyqqT24h0m5GeunHIcXRRcfoOAEnEmjRJ b5ePCKxHqNY2Iz6MpiedTCpD2RIbI51wVhNGfmCiwyyl3500oqjvcmtYh00gCIU= =XP9d -----END PGP SIGNATURE-----

1 0

rVRRPd - A new open source VRRPv2 daemon
by Nicolas Chabbey 09 Jul '19

09 Jul '19

Hello, I released the first major version of rVRRPd, an open source and RFC3768-compliant VRRPv2 daemon. It actually only supports Linux but I will soon be adding support for additional operating systems and platforms. rVRRPd was born from my desire to develop skills in system development. I also wanted to provide another open and secure implementation of a FHRP to the network community. Here's a summary of what rVRRPd (v0.1.0) is: - Implemented almost entirely in Rust - Interoperable with RFC3768 compliant devices - Support for RFC2338 simple password authentication - Support for additional proprietary authentication methods - Easily configurable using TOML - Multithreaded operations - Fast, secure and scalable This implementation is aimed to be fast and secure, however please keep in mind, it is still in its infancy. It is not yet ready for production use but should be fairly stable. I'm the only developer at this time, and my resources are limited. However, I took the time to fuzz the latest version, and to do some interoperability testing. So far, the results have been great. Of course, I'm open to any suggestions and feedback. Anything that can improve the project constructively is more than welcome. I am also open to contributors. You can find the latest development version of rVRRPd at https://github.com/e3prom/rVRRPd Regards

1 0

Google Fiber
by Robert DeVita 09 Jul '19

09 Jul '19

Does anyone have a sales contact at Google Fiber, looking for Dark fiber in Pflugerville, TX back to Datafoundry TX1 Thanks Rob [photo] [https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_l…] Robert DeVita Managing Director, Mejeticks [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png]<http://www.linkedin.com/company/mejeticks> [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png]<http://twitter.com/mejeticks> [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png] 214-305-2444<tel:214-305-2444> [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png] 469-441-8864<tel:469-441-8864> [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png] radevita(a)mejeticks.com<mailto:radevita@mejeticks.com> [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png] www.mejeticks.com<http://www.mejeticks.com/> [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.p…] 1919 McKinney Ave, Dallas, TX 75201

2 1