May 2018 - NANOG - lists.nanog.org

Re: BGP Optimizers (Was: Validating possible BGP MITM attack)
by Francois Devienne 17 May '18

17 May '18

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(a)expereo.com<mailto:francois.devienne@expereo.com> BORDER 6 S.A.S. - EXPEREO On Aug 31, 2017 (35), at 22:06, Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> 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/

2 1

Email security: PGP/GPG & S/MIME vulnerability drop imminent
by George William Herbert 17 May '18

17 May '18

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

21 24

Re: internet - sparkle
by Scott Weeks 16 May '18

16 May '18

--- aaron1(a)gvtc.com wrote: From: Aaron Gould <aaron1(a)gvtc.com> What's an eyeball network ? ----------------------------------------------- https://en.wikipedia.org/wiki/Eyeball_network scott

1 0

Verizon/UUNET AS701 blocking Tor "directory" server (IPv4 86.59.21.38)
by Neel Chauhan 16 May '18

16 May '18

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@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@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@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@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/

1 0

USB Ethernet Adapters
by Colton Conor 16 May '18

16 May '18

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.

11 13

ProofPoint
by ConsulTIC - Cyprien Laleau 16 May '18

16 May '18

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,

2 1

RE: is odd number of links in lag group ok
by Jakob Heitz (jheitz) 16 May '18

16 May '18

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 <ben(a)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 <mark.tinka(a)seacom.mu> 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.

1 0

ALTDB - Getting records removed
by John Hurley 16 May '18

16 May '18

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?

4 4

Level 3 Looking Glass Broken
by Gary T. Giesen 15 May '18

15 May '18

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

3 3

Needed: Verizon Wireless DNS technical contact
by Alan Clegg 15 May '18

15 May '18

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

1 0