August 2017 - Test - lists.nanog.org

IPv6 first hop security on a budget?
by Joel Whitehouse 11 Nov '17

11 Nov '17

What's a good budget option for switching a small lab or office ipv6 with RA Guard, DHCP6 snooping, and ICMP6 snooping?

5 4

Cogent BCP-38
by Ben Russell 07 Sep '17

07 Sep '17

Could someone from Cogent contact me off-list? We are having an issue with one of our downstream customers who is multi-homed to another carrier. The end customer is advertising their prefix to both us and the other carrier. Both us and the other carrier peer with 174. However, if the prefix is preferred through us and the outbound traffic flows over the other carrier it is dropped. We suspect uRPF-strict on the other carriers Cogent link. We are working together with the other carrier and have a ticket open the help desk seem to be confused. Any help would be appreciated. Thanks Ben Russell Senior Network Engineer Stratus Networks (309)370-3174 [logo]

13 14

Max Prefix Out, was Re: Verizon 701 Route leak?
by Michael Still 03 Sep '17

03 Sep '17

I agree a max-prefix outbound could potentially be useful and would hopefully not be too terribly difficult to implement for most vendors. Perhaps RFC4486 would need to be updated to reflect this as a possibility as well? On Mon, Aug 28, 2017 at 5:41 PM, Julien Goodwin <nanog(a)studio442.com.au> wrote: > On 28/08/17 18:34, Job Snijders wrote: >> Finally, it may be worthwhile exploring if we can standardize and >> promote maximum prefix limits applied on the the _sending_ side. This >> way you protect your neighbor (and the Internet at large) by >> self-destructing when you inadvertently announce more than what you'd >> expect to announce. BIRD has this functionality >> http://bird.network.cz/?get_doc&f=bird-3.html#proto-export-limit >> however I am not aware of other implementations. Feedback welcome! > > Having just dug up the reference for some strange reason... > > Back at NANOG38 (2006) Tom Scholl mentioned in a talk on max prefix: > "Perhaps maximum-prefix outbound? > (Suggested by Eric Bell years ago)" > https://www.nanog.org/meetings/nanog38/presentations/scholl-maxpfx.pdf > > Notably Juniper does now have prefix-export-limit, but only for > readvertisement into IS-IS or OSPF: > https://www.juniper.net/documentation/en_US/junos/topics/reference/configur… -- [stillwaxin(a)gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin(a)gmail.com ~]$

11 19

BGP Optimizers (Was: Validating possible BGP MITM attack)
by Job Snijders 01 Sep '17

01 Sep '17

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/

6 7

Hijacks: AS12506, AS327814, AS44582, AS62135
by Ronald F. Guilmette 31 Aug '17

31 Aug '17

The following set of interrelated networks appear to be engaged in hijacking various IPv4 address blocks at the present time: AS12506 Inspiring Networks, B.V. (Netherlands) AS44582 Inspiring Networks, B.V. (Netherlands) AS62135 Inspiring Networks, B.V. (Netherlands) AS327814 Echoband, Ltd. (Ghana) The specific routes that are unambiguously being hijacked by each of these networks are as follows: AS12506: 152.108.0.0/16 155.159.0.0/16 196.15.64.0/18 AS327814: 163.198.0.0/18 164.88.0.0/16 168.80.0.0/17 168.80.128.0/17 AS44582: 175.53.0.0/17 175.53.128.0/17 175.54.0.0/17 175.54.128.0/17 AS62135: 160.116.32.0/20 160.116.128.0/20 160.116.240.0/20 160.122.144.0/20 Screenshots of the bgp.he.net prefixes reports for the above networks are archived here: http://i.imgur.com/5HuDRYX.png (AS12506) http://i.imgur.com/YishDCK.png (AS44582) http://i.imgur.com/lgiAKWz.png (AS62135) http://i.imgur.com/IM9Wf5h.png (AS327814) (Note that the set of routes announced by the four networks in question has changed slightly since the last bgp.he.net update -- 30 Aug 2017 14:48 PST. The route for 163.198.0.0/18 has been dropped and the routes for 160.116.128.0/20 and 160.122.144.0/20 have been added.) As seen in previous hijackings, and as is consistant with the general nature of such hijackings, no individual IP addresses within any of the above listed routes have any functioning reverse DNS delegation. Note that AS44582 (Inspiring Networks) and AS62135 (Inspiring Networks) really only have a single upstream connection to the Internet, at least as far as public BGP is concerned, and that is AS12506 (Inspiring Networks). Meanwhile, AS12506 (Inspiring Networks) has only a single BGP upstream, which is AS49544 i3D.net B.V (Netherlands). Therefore, the majority of this hijacking activity is only made possible via the generous help and assistance of AS49544, i3D.net B.V. Inspiring Networks is apparently run by one Maikel Jozef Gerardus Uerlings, <maikel(a)uerlings.nl>: https://labs.ripe.net/Members/maikel_uerlings https://nl.linkedin.com/in/maikel-uerlings-072aaa65 https://twitter.com/maikeluerlings (recently disappeared) https://www.facebook.com/maikel.uerlings http://uerlings.nl/ On February 24, 2013, over four years ago, Mr. Uerlings apparently promised his Facebook friends and fans that his new corporate web site would be "launched soon". As of today however, Mr. Uerlings' corporate web site for Inspiring Networks stil contains only generic/boilerplate "Lorem ipsum" type filler text: https://inspiringnetworks.com/ It would thus appear that Mr. Uerlings has other ways of attracting customers, other than his minimalist placeholder corporate web site. In any case, Mr. Uerlings has apparently gotten some bad press on a couple of occasions, for example the following blog post by some anonymous spammer who felt that Mr. Uerlings didn't actually deliver on his promises of "fresh IPs for mailing": http://maikel-uerlings-inspiring-networks.blogspot.com/ Mr. Uerlings' name also came up in the context of a 2013 attempt by Microsoft to take down a certain botnet: Microsoft v. Botnet United States Court for the Western District of Texas Case: A-13-CV-1014SS http://botnetlegalnotice.com/zeroaccess/files/Summons_Does_1-8.pdf (... Care of: Maikel Uerlings, cust597(a)serverius.com ...) Other folks also have, or had, a rather unfavorable opinion of Mr. Uerlings also, it would seem: https://www.mywot.com/en/scorecard/uerlings.nl https://www.scamwarners.com/forum/viewtopic.php?p=123180 https://unapprovedpharmacy.com/category/counterfeit-drugs-alert/page/12/ As usual, I wouldn't even mind about any of this hijacking activity if it were not for the fact that at least some porgtion of the hijacked IPv4 space appears to have been populated with snowshoe spammer domains: https://pastebin.com/raw/As9nVCMV I cannot help but wonder if there is something in the water supply in the Netherlands that may be causing so much hijacking activity to originate from that country. I do understand that Netherlands has what I gather is the best connectivity in all of Europe, but even that does not fully explain, I think, the Netherland's disproportionate share of these sorts of events and incidents, in this case involving Inspiring Networks, B.V. and clearly supported by AS49544, i3D.net B.V, also of the Netherlands. Regards, rfg P.s. Don't be fooled by hijackings of IP blocks that were historically allocated by AFRINIC to various corporate entities in the Seychelles Islands. Many of those corporate entities have long since died, and their associated IPv4 blocks have thus been abandoned. Unfortunately, due to the unique and very strict corporate secrecy laws in the Seychelles, it is not possible for any outsider to find out even if these entiries still exist or not, let alone who their corporate officers are or might have been. Thus, literally anybody can come along, after the fact (even lawyers) and claim to be representing the rightful owers of these blocks. And there is apparently no way, either verify or to disprove any such claims. Thus, hijacking the IP blocks of any defunct Seychelles Islands company is very nearly "The Perfect Crime". The only catch is that AFRINIC has, in its archives, the names of the actual corporate officers who originally requested (and were granted) the IP block allocations originally. And thus, they at least cannot be so easily fooled by any usurpers who are mearly pretending to be the rightful owners of these blocks. So it is actually pretty easy to tell which IPv4 blocks registered to Seychelles Islands companies have been hijacked. If they are hijacked by persons who are not actually acting on behalf of the true rightful owners of these blocks, then the thieves in question will not have been able to snooker AFRINIC into delegating reverse DNS authority for the blocks to them. So this is the simple acid test. If a given IP address block is allocated, from AFRINIC, to some corporate entity in the Seychelles Islands, and if that block has no working reverse DNS, then there's probably a very good reason for that, i.e. it's hijacked. And the hijacking has taken place without any knowledge of this event whatssoever on the part of AFRINIC.

2 1

Validating possible BGP MITM attack
by Andy Litzinger 31 Aug '17

31 Aug '17

Hello, we use BGPMon.net to monitor our BGP announcements. This morning we received two possible BGP MITM alerts for two of our prefixes detected by a single BGPMon probe located in China. I've reached out to BGPMon to see how much credence I should give to an alert from a single probe location, but I'm interested in community feedback as well. The alert detailed that one of our /23 prefixes has been broken into /24 specifics and the AS Path shows a peering relationship with us that does not exist: 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042 (me) We do not peer directly with PCCW Global. I'm going to reach out to them directly to see if they may have done anything by accident, but presuming they haven't and the path is spoofed, can I prove that? How can I detect if traffic is indeed swinging through that hijacked path? How worried should I be and what are my options for resolving the situation? thanks! -andy

4 5

BGP AS# migration from IOS to IOS-XR
by marcel.duregards＠yahoo.fr 31 Aug '17

31 Aug '17

Dear All, Does anybody had to migrate a entire BGP transit AS# from Cisco IOS to IOS-XR ? Our main concern is BGP, especially conversion from route-map, communities, conditional advertisement, template, peer-group up to RPL. Cisco offer a doc how to migrate from IOS to XR of about 40pages, but it's quite old (XR 3.2) and not so interesting. There are also a lot of documentation about XR/RPL, but I was not able to find a good doc about RPL, and how to translate complex IOS config to XR. Any experience on BGP best pratice with XR, af-group, session-group, neighbor-group, communities implementation from existing IOS config ? And how to you manage RPL editing? I mean with IOS you have some completion on TAB keystroke, but as RPL has to be edited within a text editor, you loose this kind of 'help'. Maybe we have to re-think our config from scrash :-). Thank in advance, Best regards, Marcel

3 2

SAFNOG-3: Agenda Finalized
by Mark Tinka 31 Aug '17

31 Aug '17

Hello all. Pleased to inform you that the SAFNOG-3 agenda is now full! You can view the agenda here: http://safnog.org/ We have a very detailed and exciting line-up, sure to appeal to different parts of our community, such as: - Data Centres. - Peering. - IPv4 Address exhaustion. - SDN/NFV. - FTTH. - Cloud Computing. - IPv6. - Internet Security. - DNS. - BGP. - e.t.c. We also have two very powerful keynote speakers delivering critical and vital information at this year's meeting: - Our opening keynote will be presented by Mr. Pascal Hoba, CEO of UbuntuNet Alliance. - Our closing keynote will be presented by Mr. Alan Barrett, CEO of AFRINIC. Bio information about all of this year's speakers will be available in the coming days. Please check the web site regularly for these updates. Please register your attendance for SAFNOG-3, if you have not yet done so. We look forward to seeing you all in Durban, next week! Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee

1 0

I-65 Alabama
by Mike Hammett 31 Aug '17

31 Aug '17

Is anyone aware of any non-AT&T, non-Charter fiber routes going up I-65 in Alabama? Most that even go close to there seem to be over on 231. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

1 0

B-Root to be renumbered in October
by Wes Hardaker 30 Aug '17

30 Aug '17

FYI, To help support anycast with more resilient routing, the IPv4 address for b.root-servers.net will be renumbered to 199.9.14.201, effective 2017-10-24. The old IPv4 address (192.228.79.201) will continue to answer queries for at least 6 months. -- Wes Hardaker B-Root Operations USC/ISI

1 0