- NANOG - lists.nanog.org

Heads-up: RFC 8212 on default EBGP route handling behavior
by Job Snijders 06 Jul '17

06 Jul '17

Dear NANOG, After a bit of tug-of-war common sense prevailed and RFC 8212 "External BGP (EBGP) Route Propagation Behavior without Policies" was published: https://tools.ietf.org/html/rfc8212 This industry has a long history of improving default behavior: DEC MOP is no longer enabled by default, telnet was swapped out in favor of SSH, and SHA-1 is now deprecated, so I'm confident we can manage this one too. TL;DR This mail offers advice on test scenarios to add to your evaluation checklist and a call to action to ask your vendor to implement RFC 8212. Please share this message with other communities. Background ---------- Prior to RFC 8212, the default behavior of BGP implementations (when no policy is configured on an EBGP session) was undefined, this resulted in a myriad of vendor defaults: some implementations not accepting routes and not advertising anything; some would accept anything, but announce nothing; some would announce only internal routes and accept anything; and some would indiscriminately accept everything and announce everything. The latter mode of operation is of course the most harmful one. An example minimal configuration: ! router bgp 15562 neighbor 192.0.2.1 remote-as 174 neighbor 192.0.2.5 remote-as 2914 ! Most of us have learned (the hard way) that on many platforms the above configuration will not only bring up two BGP sessions, but also immediately result in a "Lateral ISP-ISP-ISP Leak" [2], simply because no routing policy was associated with these EBGP sessions and an implicit 'permit-any' is assumed. The above configuration is of course an oversimplification of what happens in real life: operators may attempt to change a BGP peer to a peer-group which has missing configuration, or a copy+paste of a snippet of configuration only partially succeeds, or in an attempt to debug a BGP session some configuration is removed without realizing the full ramifications of doing so (until you see smoke coming off the circuit ;-). RFC 8212 updates the core BGP specification (RFC 4271) to specify that the above behavior is _incorrect_, and an implicit deny-all must be associated with the EBGP session. In other words: "fail closed" rather then "fail open and oops you tripped max-prefix all over the place (or worse [3])". The document purposefully does not cover IBGP, nor does it proscribe what the contents of configured policy on EBGP sessions should be. If an operator explicitly configures a 'permit-any' style policy, that is perfectly fine, it was a conscious choice to do so. Evaluation checklist -------------------- Going forward when you evaluate a BGP implementation or a new software release, it is advisable to take note of the default behavior of that specific release. As vendors come into compliance with RFC 8212 it may be beneficial to track this. I also strongly recommend to audit your network configurations for instances which depend on implicit 'permit-any' behavior and reconfigure those instances to be an explicit 'permit-any'. This way software upgrades are less likely to cause surprises, and as a bonus the readability of the device's configuration is improved! Call to action -------------- Some vendors will need encouragement to take their implementation from EBGP "fail open" to "fail closed", we are keeping track of the industry's current state of affairs here: https://github.com/bgp/RFC8212 Please contact your account management team and express your interest in them supporting RFC 8212. Also, make sure to include RFC 8212 in your next round of "Request for Proposals" (RFPs) as a 'must have'. Purchasing usually is an excellent opportunity to have meaningful dialogue with the vendor. Some vendors may argue "but our customers depend on our unsafe behavior!", but this only holds true if we don't speak up collectively and show them otherwise. EBGP is an internet-wide shared resource, we all benefit from sane defaults. Hat tip to Jared Mauch for initiating this project and to Greg Hankins for demonstrating change is possible [4]. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/idr/mqPltvvgEhpxBgAXET1y1Xow6t8 [2]: https://tools.ietf.org/html/rfc7908#section-3.2 [3]: https://bgpmon.net/massive-route-leak-cause-internet-slowdown/ [4]: https://mailarchive.ietf.org/arch/msg/idr/kgl6etbjUuR3jLHVeDSi4LLIs50

1 0

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?
by Josh Reynolds 06 Jul '17

06 Jul '17

- Josh On Jul 3, 2017 7:23 PM, "Josh Reynolds" <josh(a)kyneticwifi.com> wrote: > Specs... > > > - MIPS64 16 Core 1.8 GHz > - 16 GB DDR4 RAM > - 8 MB NOR Flash 4 GB eMMC NAND Flash > - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit > Ethernet Port > - 2 hotswap power supplies > > > No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not > done in hardware - this may eventually change. As far as the other stuff, > "telemetry" etc - no. > > As far as BGP crunching, plenty of routes, etc - it would easily and > happily be fine with that. > > As far as automation, it's a JunOS-like CLI originally based on vyatta, > which AT&T now owns - and one of the main reasons is it's scriptability, > use of Ansible and other tools right on the device, python, etc. > > - Josh > > On Jul 3, 2017 2:09 PM, "Job Snijders" <job(a)instituut.net> wrote: > >> Dear NANOG, >> >> Some friends of mine are operating a nonprofit (on shoe string) and >> looking >> to connect some CDN caches to an IX fabric. A BGP speaking device is >> needed >> between the caches and the BGP peers connected to the fabric. The BGP >> speaker is needed to present the peers on the IX with a unified view of >> the >> assemblage of CDN nodes. >> >> I was wondering whether anyone was experience with the "EdgeRouter >> Infinity >> XG" device, specifically in the role of a simple peering router for a >> couple of tens of thousands of routes. (I'd point default to the left and >> take just the on-net routes on the right to reduce the table size >> requirement). >> >> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >> automatable (supports idempotency), can forward IMIX at line-rate, *flow, >> and exposes some telemetry via SNMP. >> >> Any note sharing would be appreciated! >> >> Kind regards, >> >> Job >> >

4 5

Sign onto EFF's comment to the FCC on their net neutrality proposal
by Erica Portnoy 05 Jul '17

05 Jul '17

Dear colleagues, As many of you know, the FCC is currently engaging in the process of repealing its network neutrality rules and eliminating its Title II authority over broadband providers. I'm writing you today to ask you to sign on to a letter that EFF has prepared for filing, which explains several key engineering concepts that are vital to understanding how the Internet actually operates given that the FCC's own findings misinterpret how the Internet works. The letter stays away from legal arguments, and instead focuses on technical statements on the design and operation of the Internet. It is meant to establish a factual record for the FCC about the Internet and it is necessary because its initial findings in its Notice of Proposed Rulemaking <https://apps.fcc.gov/edocs_public/attachmatch/DOC-344614A1.pdf> are just wrong. For one, the FCC thinks that broadband Internet providers are the ones providing end users with the services of the entire Internet, from search engines to online newspapers to language translation tools. /*If you're willing to sign on and help, please email engineers-nn-comments(a)eff.org (off-list) by Friday, July 14 */and I will be happy to share a copy of the letter for you to review before you agree to sign on. The more signatures we can get, the more likely the FCC is to take notice as well as the courts should they move forward. All it takes is an email. Please help us make sure the FCC gets the facts from an engineer's standpoint. Thank you for your support, Erica Portnoy Staff Technologist Electronic Frontier Foundation

1 0

Armstrong Cable Services/AS27364 networking contact needed
by Darrin Veit 05 Jul '17

05 Jul '17

I'm hoping to find a networking contact at Armstrong that can ping me off list. We're investigating connectivity issues for some Armstrong customers when they are trying to connect to servers in AS8075. Thanks! -Darrin Veit, Xbox Platform Networking dveit(a)microsoft.com

1 0

Big Spam Burst
by Jay R. Ashworth 05 Jul '17

05 Jul '17

Am I the only person who got a big burst of spam -- 30 or 40 in about 5 minutes -- on Sunday night, from France? All forged with NANOG participant From names? I'm pretty sure Steve Bellovin and Rob Seastrom aren't sending me spam. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

1 0

Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017
by Jacques Latour 05 Jul '17

05 Jul '17

[with apologies to those who see this on multiple lists] Call For Presentations The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on September 29th and 30th 2017, the Friday and Saturday preceding NANOG 71. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we can accommodate those talks during the Members Only session on the morning of September 29th. A timeslot will also be available for lightning talks (5-10 minutes) on Saturday September 30th, for which submissions will be accepted during Friday 29th. Workshop Milestones: 26 May 2017, Call for Presentations posted and open for submissions 28 July 2017, Deadline for submission 11 August 2017, Draft Programme published 01 September 2017, Final Program published 15 September 2017, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/27/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Ray Bellis, for the OARC Programme Committee OARC depends on sponorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)

1 1

Call for presentations EPF12, 18th - 20th September, Lisbon sent to NANOG
by Arnold Nipper 05 Jul '17

05 Jul '17

Dear all, AMS-IX, DE-CIX, LINX, Netnod are happy to host the 12th European Peering Forum (EPF) in Lisbon, Portugal from the 18th - 20st September 2017. 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 and Peering Internet Governance and Regulatory TopicS * Economic and Product Trends * Peering/Interconnection Strategy * Interesting findings about peering * 100GE 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 * Presentation title * Abstract * Slides (if available) * Time requested Deadlines ========= Presentation Abstract Deadline 17/07/2017 12:00 UTC Final Selection of Speakers 28/07/2017 Presentation Slides Submission Deadline 04/09/2017 12:00 UTC More information about the event and other activities around EPF12 may be found at https://peering-forum.eu/ Best regards, Arnold On behalf of the EPF hosts -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 1

Call for presentations RIPE 75 and DCTM info
by Benno Overeinder 03 Jul '17

03 Jul '17

Dear colleagues, Please find the CFP for RIPE 75 below or at: https://ripe75.ripe.net/submit-topic/cfp/. The deadline for submissions is *20 August 2017*. Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Kind regards, Benno Overeinder RIPE PC Chair https://ripe75.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 75 will take place from 22-26 October in Dubai, UAE. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 75. See the full descriptions of the different presentation formats, https://ripe75.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *20 August 2017*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Please also note that speakers do not receive any discount or funding towards the meeting fee at RIPE Meetings. Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe75.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe75.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

IPv4 Hijacking For Idiots
by Ronald F. Guilmette 03 Jul '17

03 Jul '17

The more I know, the less I understand. Maybe some of you kind folks can help. Please explain for me the following scenario, and how this all actually works in practice. Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise. OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991. That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right? So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.) But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet?? I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?) Thanks in advance for any enlightenment. Regards, rfg P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia. Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April. And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far.

13 26

Transit Providers in Bracknell, UK
by Gary T. Giesen 03 Jul '17

03 Jul '17

Can anyone recommend a transit provider in Bracknell, UK? Not too picky on requirements, but IPv6 is a must; RTBH and good peering are a very good to have. We're looking to replace one of our current providers (Virgin Media - AS5089). I have no problem naming them as they treat prefix list updates like service changes (and charge £250 for the privilege). We gave in and paid it and and 2 weeks later they have still not processed the change. Cheers, GTG

3 3