August 2018 - Test - lists.nanog.org

celebrating 10 years of routing insecurity
by Job Snijders 10 Aug '18

10 Aug '18

Dear all, Today marks the 10th anniversary of the famous Kapela-Pilosov Man-in-the-middle BGP attack! It is a fantastic and innovative attack that would be worthy of referencing in the next Mr Robot season. :-) video: https://www.youtube.com/watch?v=S0BM6aB90n8 slide: https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-piloso… So, what is the state of routing security anno 2018? It seems that as an industry we're on an upwards trajectory: various IRR registries are locking themselves down to prevent creation of unauthorized route(6) objects, new filter generation tools are becoming available, RPKI based BGP Origin Validation is slowly seeing more and more deployment, and the concept of blocking route announcements with improbable AS_PATHs is gaining popularity as well. Let's see where we are 10 years from now! Kind regards, Job

1 0

Summer of Hijacks: My message to RIPE and the RIPE Executive Board
by Ronald F. Guilmette 09 Aug '18

09 Aug '18

Found yet another big hijacking operation. Coming out of RIPEland, again. See below for full details. I didn't really want to post again to NANOG on this topic (hijacks) quite this soon, but the bloody European crooks, spammers, and hijackers aren't really giving me a break, and I can't abide just sitting in silence and stewing about it for another month or three. I mean this stuff is just getting ridiculous. And I do wory that the Internet community is just starting to accept this stuff as "normal behavior", which it isn't. Maybe the following will finally get somebody's attention in RIPEland, but I'm not holding my breath for what I personally consider a Good Outcome (which would include full disclosure about what the hell they are actually going to do about any of this, which is probably far too much to even hope for). I'll probably be permanently banned from all of the relevant RIPE mailing lists for having posted this. I just skimmed over RIPE's Code of Conduct for their mailing lists and it basically says that Thou Shalt Not Say Anything Bad About Anybody Specifically, Ever, and I'm pretty sure that I just broke that rule, in spades. Oh well. May God bless the First Amendment, and may God bless NANOG! P.S. It was just now brough to my attention that AS197328, Istanbuldc, is -only- routing 176.116.0.0/19, which looks to be one of the few routes that are maintained by MNT-SERVERSGET that are actually for legitimately allocated IPv4 blocks. For the record, I do not dispute that some of the routes maintained by MNT-SERVERSGET are for legitimately allocated space. I will and do however dispute any assertion that ALL such routes are for IP space that has been legitimately allocated to either Mr. Alexander Samuilov or to his various corporate identities or corporate partners. That does not appear to be the case, based on the evidence. (note - minor edits applied) ========================================================================== From: "Ronald F. Guilmette" <rfg(a)tristatelogic.com> To: exec-board(a)ripe.net, db-wg(a)ripe.net, routing-wg(a)ripe.net, anti-abuse-wg(a)ripe.net, noc(a)ripe.net, Subject: The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top The entire set of objects in the RIPE WHOIS data base that are currently registered with mnt-by: MNT-SERVERSGET is listed here: https://pastebin.com/raw/GiYWxHMh Among this set of objects there are 235 separate route objects. Evidence indicates persuasively that some sizable fraction of these RIPE- registered route objects are fradulent and are simply there to provide cover for multiple IPv4 address block hijacks. The presence of these objects in the data base permits the following set of ASNs to claim that they are acting "legitimately" even as they route these hijacked blocks: AS9009 M247 Ltd (UK) AS43350 NFOrce Internet Sevices (Netherlands) AS57129 Optibit, LLC (Russia) AS197328 Istanbuldc Veri Merkezi Ltd. Sti (Turkey) -- SEE NOTE ABOVE AS202287 Men Danil Valentinovich (Russia) AS204895 Santa Plus, LLC (Russia) The total amount of IPv4 space encompassed within the set of route objects registered with mnt-by: MNT-SERVERSGET at the present time amounts to eight hundred and fifty nine (859) /24 blocks. Of these, only three hundred and five (305) actually have correctly functioning and properly delegated reverse DNS at the present time, and even among those, only two hundred and two (202) have functioning reverse DNS delegations to the prefered name servers of MNT-SERVERSGET, which is to say the name servers ns5.dnsget.top and ns6.dnsget.top. The bottom line is that it appears that, at the present time, something less than 1/4 of all of the IPv4 address space currently registered in the RIPE data base (via route objects) by and to MNT-SERVERSGET is space for which a plausible case could be made that the blocks in question are actually legitimately assigned to and/or under the legitimate control of MNT-SERVERSGET aka Mr. Alexander Samuilov. The other 3/4ths of the IPv4 space in question has provenance which is, at best, dubious. Due to its use of little country-of-registration flags for each IP address block, the web site bgp.he.net provides the most visually obvious indications of at least two of the specific block hijacks in this case, specifically the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129: https://bgp.he.net/AS57129#_prefixes Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake an immediate and conmprehensive review of all objects in the data base that are currently registered with mnt-by: MNT-SERVERSGET. Additionally, I also respectfully request RIPE NCC to publish the results of this review to the mailing lists of the Database Working Group and the Anti-Abuse Working Group. The charters of both of these Working Groups are directly relevant to this issue, and there exists neither need nor reason to simply sweep this issue quietly under the carpet, as has been done in previous and similar cases. Cases such as this, and the two others of similar magnitude that I have publicly disclosed just this summer, affect the operation of, the stability of, and the continued enjoyment of the entire planetary Internet and its billions of users. Despite its status as a strictly private corporation, RIPE has a public responsibility, not only to handle such incidents responsibly and competently, but to show the world that it is ready, willing, and able to do so. The responses of RIPE to prior instances of this exact type of bad behavior have been largely or entirely cloaked in secrecy, presumably to protect the guilty. This longstanding and antiquated tradition of omerta within the RIPE community is unambiguously counterproductive to the goal of a well-managed and properly fuctioning Internet. Just as importantly, it naturally gives rise to unavoidable questions about the actual competence of, and capabilities of RIPE NCC staff as they attempt to deal with such incidents. I personally feel that RIPE NCC staff are doing the best they can when responding to incidents such as this, but the tradition of playing "hide the ball" with respect to their actions in such cases reflects badly on them, and badly on RIPE generally. It certainly raises doubts about RIPE's claim to authority over even its own data base. Lastly, I respectfully request both the RIPE Executive Board and the RIPE membership to make plain and explicit their respective intentions with regards to the various bad actors that have been caught, and that may in future be caught red handed engaging in the deliberate and premeditated corruption of the RIPE data base. To date, the policies an actions that RIPE applies, or which RIPE may apply to such bad actors have been shrouded in apparently deliberate secrecy and mystery. To put this request in more concrete terms, I would like to know if RIPE and the Executive Board actually and deliberately intend to take no action whatsoever with respect to the ongoing RIPE memberships of clearly identified bad actors, specifically, in this case, whatever persons or entities are currently repreesented by the RIPE WHOIS handle MNT-SERVERSGET (aka AS202287 and AS202275), which would appear to be this specific entity / RIPE member: https://www.ripe.net/membership/indices/data/ru.danil.html Is it the express intention of both the Board and the RIPE membership to simply deprive this bad actor of just those fradulent data base entries that have effectively legitimized his/her/its fradulent routing announcements? Is it the express intention of both the Board and the RIPE membership to simply make this bad actor give back what he has stolen, and to otherwise take no action, just as the response has been in the two other and similar cases that have also arisen in the RIPE region and that I have also publicly reported on this summer? https://mailman.nanog.org/pipermail/nanog/2018-June/096034.html https://mailman.nanog.org/pipermail/nanog/2018-July/096437.html My question is prompted by the following simple facts. In the two prior cases cited above, and also in the one I am presenting here today, the bad actors involved were seen to have not only hijacked large swaths of IP address space that clearly didn't belong to them, but also, as in the case I am presenting today, these same bad actors additionally acted to corrupt the RIPE data base with premeditated and deliberately fradulent entries. Nonetheless, and regardless of these attacks on the reliability and trustworthyness of the RIPE data base, to date it appears that no action whatsoever has been taken which might affect the ongoing RIPE memberships of the relevant parties and bad actors involved, and they are all still members in good standing of RIPE at the present time: https://www.ripe.net/membership/indices/data/pt.bitcanal-pt.html https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html This is, to say the least, puzzling. I would like to know when, where, and how the Executive Board and/or the RIPE membership reached the altogether dubious conclusion that the best possible way to deal with bad actors such as these is to make them give back -just- the stuff the stole, and then to otherwise impose no penality of any kind, thus allowing them to live on, so that they may hijack another day. Whether this policy is a result of either deliberation or default, it *does* appear to be the policy, based on the evidence. Without intending to be rude, I feel that I must ask the obvious question: In what Universe does this otherwise admirable and generous Christian policy of "turning the other cheek" with respect to such verified bad actors have any effect other than encouraging the next hijacker, and then next one, and the one after that? Has either the Board or the membership even ever seriously debated what penalties should be imposed upon those members who are caught red handed deliberately corrupting the RIPE data base? Is the present RIPE policy of "forgive and forget" with respect to such travesties a product of anyone's intentional design, or is it instead merely the result of utter apathy and indifference on the part of the entire RIPE community? In either case, I believe it to be self evident that the time is... ummm... blooming, blossoming, burgeoning, flourishing, and flowering for this policy to be reexamined and revised. From where I am sitting it is self evident that the current policy of turning a blind eye to these events, and to the bad actors behind them is quite clearly encouraging others to follow suit and to themselves undertake the exact same sorts of travesties. Why shouldn't they? There is no downside. At the very worst, one is simply made to give back all of the stuff that one has stolen, and one is then allowed to go on one's merry way. Regards, rfg P.S. As incensed as I am at the fact that the above named bad actors have been allowed not only to retain their RIPE memberships, but also, apparently, 100% of their legitimately-allocated number resources, this is not even nearly as utterly appalling and inexplicable as the fact that two of the bad actors with direct and provable connections to the prior instances of hijacking that I have reported on publicly this summer have been allowed to remain as officially recognized RIPE IP brokers: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/bro… I am referring here specifically to Ebonyhorizon Telecomunicacoes Lda (aka Bitcanal) and also to NetAssist LLC (AS29632), which conveniently continues to maintain its association with, and peering arrangements with both AS57166 aka D2 International Investment Ukraine, Ltd. and, indirectly via D2, AS205869 aka Universal IP Solution Corp., both of which apparently continue to this day to try their best to hijack, either directly or indirectly, via AS Path fraud, a number of IPv4 blocks that clearly do not belong to any of these three Ukranian entities: https://bgp.he.net/AS57166#_peers https://bgp.he.net/AS205869#_peers https://bgp.he.net/AS29632#_peers What IP blocks are these two officially recognized RIPE IP brokers, Ebony Horizon and NetAssist brokering, exactly? Are they blocks that have been successfully hijacked? Does either RIPE or RIPE NCC even know? Does either RIPE or RIPE NCC even care? (One cannot help but wonder what might occur if RIPE were put in charge of distributing meat supplies within Europe. Would RIPE officially designate the McDonald's "Hamburglar" as RIPE's officially recognized agent for said distributions?) I guess that, in the end, all of the questions I have raised above can be boiled down to just one simple question: Who exactly does one need to either kill or maim or seriously wound in order to get kicked out of this organization (RIPE)? Regards, rfg P.P.S. Among the set of six companies / ASNs listed toward the top of this message as possible facilitators of the current hijacks of MNT-SERVERSGET, three are already fairly well known... at least in anti-spam circles... as being among "the usual suspects" when it comes to facilitating spamming and spammers. And no, I do not care to publicly specify which three. It may be true, as the saying goes that "On the Internet, nobody knows that you're a dog", but memories are long, and people don't forget if your company has been repeatedly caught acting like one.

1 0

Feedback - SBC Vendors.
by Ryan Finnesey 09 Aug '18

09 Aug '18

I am going to have to install a series of SBCs for a voice offering connected to Microsoft Teams. We are going to pass the SIP traffic off to a larger number of SIP providers. I would like to get some feedback from the group on SBC vendors. I have two options for vendors Ribbon or AudioCodes. I am leaning towards a software based SBC over an appliance. Would be helpful to get the other members feedback on Ribbon or AudioCodes deployments within their networks. Cheers Ryan

7 8

Yahoo Groups contact
by Andy Ringsmuth 09 Aug '18

09 Aug '18

Any chance someone here has admin/troubleshooting involvement with Yahoo Groups, or knows someone who does? Much appreciated. ---- Andy Ringsmuth andy(a)newslink.com 5609 Harding Dr. Lincoln, NE 68521 (402) 304-0083 cellular

1 0

Akamai Contact
by Jawaid Bazyar 09 Aug '18

09 Aug '18

Hi, having trouble engaging with an Akamai contact in relation to the server stack we have here. Feel free to contact me. -- Jawaid Bazyar President ph 303.815.1814 fax 303.815.1001 Jawaid.Bazyar(a)foreThought.net <email:Jawaid.Bazyar@foreThought.net> <http://www.foreThought.net>

3 2

Re: Multicast traffic % in enterprise network ?
by Scott Weeks 08 Aug '18

08 Aug '18

--- jtk(a)depaul.edu wrote: From: John Kristoff <jtk(a)depaul.edu> :: In my experience, real world IP multicast experience :: and expertise is almost non-existent. :: but it tends to just work once setup and rarely :: changes. :: the setup was done a long time ago and people rarely :: touch it now. :: If I want to simplify and secure things a little :: more, I'd probably look at better limiting IGMP and :: PIM joins. Limiting as much of the possibility for :: anyone or anything to instantiate state in the :: network Major snippage, but these're my experiences, too. However, not in the .edu world. scott

2 1

Nokia SP Business Group Account Contact
by Brant Ian Stevens 08 Aug '18

08 Aug '18

Sorry to bother the list, but could someone help me get in touch with a Nokia account rep from their SP team for the NYC area? Specifically looking for information on the managed sp wireless solution. I've tried going through the website, but have made no progress reaching the right people to move my request forward. -- Regards, -- Brant I. Stevens

1 1

Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
by Marcus Leske 08 Aug '18

08 Aug '18

What do you mean ? Examples of Telemetry use cases are infinite? Are you asking for popular use cases that were not possible with snmp and netflow? Cheers On Sunday, August 5, 2018, Sami Joseph <sami.joseph(a)gmail.com> wrote: > On the topic of marketing hypes vs real requirements, does anyone see real > use cases for telemetry ? Can anyone pls give me examples? > > Thanks > > On Sunday, July 8, 2018, <adamv0025(a)netconsultings.com> wrote: > >> > From: Marcus Leske [mailto:marcusleskex@gmail.com] >> > Sent: Saturday, July 07, 2018 3:58 PM >> > >> > open APIs tops that funny abuse list IMHO : >> > https://github.com/OAI/OpenAPI-Specification/issues/568 >> > >> > can we change the topic of the thread to an informative one, instead of >> a >> > leaked video or not, to why exactly do network engineers are often >> > confused by the abusive marketing all over the place of what is open and >> > what is not and other computing terms. >> > >> > I guess this is happening in networking more often than other domains >> > because networking people didnt get a chance in their career to learn >> about >> > the world of computing, their heads were somewhere else, learning about >> > complex networking protocols and not the common computing interfaces, >> > the open source world, existing frameworks and paradigms, this video >> helps >> > a bit on how did this happen: >> > https://vimeo.com/262190505https://vimeo.com/262190505 >> > >> > has anyone here seen list of topics that network engineers usually miss >> on >> > their journey ? i know they never get exposed to software development >> > and engineering in general, databases, web technologies, operating >> system >> > fundamentals. >> > >> Well I guess if you stick around in networking for long time you kind of >> get exposed to some of these to a certain level on a day job, some of it >> was covered in school in various levels of detail, and to some of these >> concepts we (networkers) get a specific very narrow filed exposure I'd say, >> like in your example of databases -well various protocol tables are good >> examples of decentralized distributed databases, then some Network OS-es >> are good examples of distributed operating systems. So I guess it then just >> boils down to the willingness of and individual to understand these >> concepts on an ever more fundamental level -with every next interaction >> with these. Maybe it draws one more towards the software development side >> or perhaps more towards the somewhat holistic understanding of the >> networking discipline through graph theory and complex adaptive systems. >> >> >> adam >> >> netconsultings.com >> ::carrier-class solutions for the telecommunications industry:: >> >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp(a)puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >

1 0

Re: possible hawaii weather issue next week
by Scott Weeks 08 Aug '18

08 Aug '18

--- surfer(a)mauigateway.com wrote: From: "Scott Weeks" <surfer(a)mauigateway.com> If you have stuff in Hawaii, you might want to start thinking about your DR plan. ---------------------------------------- Whew, that was close! http://weather.hawaii.edu/satellite/jsanim.cgi?res=4km&chnl=ir&domain=nep&p… I don't know if anyone's interested in the discussion, (and perhaps it should go into another thread, if so) but I have been noticing a tendency among managers here to ignore getting ready for stuff like this. Is that normal for what you see or do managers where you are start dusting off and following your DR plan? "We don't have time to moved all that data off site to the mainland and all the other stuff in the plan. We need you to focus on XXX first". scott

1 0

Re: Multicast traffic % in enterprise network ?
by John Kristoff 08 Aug '18

08 Aug '18

On Wed, 8 Aug 2018 18:49:52 +0000 "Mankamana Mishra (mankamis) via NANOG" <nanog(a)nanog.org> wrote: > * If there is any data which can provide what % of traffic is > multicast traffic. And if multicast is removed, how much unicast > traffic it would add up? Good question about the volume (and frequency). I will see if I can measure here, but all I can say if it helps any, is that is still fairly widely used in the enterprise for "imaging" systems. That is, updating a set of systems and apps simultaneously from a single source. > * Since this forum has people from deployment area, I would love > to know if there is real deployment problems or its pain to deploy > multicast. In my experience, real world IP multicast experience and expertise is almost non-existent. This is the big problem potentially, because it is fairly popular on some campuses for niche applications, but it tends to just work once setup and rarely changes. For many R&E institutions, the setup was done a long time ago and people rarely touch it now. However, I rarely see IP multicast-related problems anymore. It helps that interdomain multicast is dying. Traditional PIM-SM with one or more anycast RPs isn't too complicated, and I can't remember the last time anything out of the ordinary came up. A decade or more ago at another institution that did IP/TV over IP multicast to dorms, we'd run into head-banging-against-the-wall problems about once a year. Very painful experiences usually due to buggy router code or interesting switch/router behavior with IGMP-snooping and/or joins/leaves. Those days seem to be behind us. > These questions is to work / discussion in IETF to see what is pain > points for multicast, and how can we simplify it. I can't think of too much that should change now. If I want to simplify and secure things a little more, I'd probably look at better limiting IGMP and PIM joins. Limiting as much of the possibility for anyone or anything to instantiate state in the network devices. SSM without the all the potential source-specific state would be nice. John

1 0