- NLNOG - NLNOG

Survey on the operators' perspective on security misconfigurations
by Constanze Dietrich 19 Jul '17

19 Jul '17

Hi everyone! As part of my master thesis, we are looking into the topic of security misconfigurations. We want to better understand why they occur and how the operations community perceives them. If you're hooked already, please participate in our research by filling out our anonymous survey on your experiences. Every input on that topic is valuable and it only takes about 10 to 20 minutes, depending on whether you're up for more detailed answers or not: https://goo.gl/forms/D3KYIOW91QSbjXQy1 For further detail on the study read the article on RIPE Labs: On the Operators' Perspective on Security Misconfigurations ㄧ The Survey https://labs.ripe.net/Members/constanze_dietrich/on-the-operators-perspecti… Thanks in advance and have a nice day! :) Kind regards, Constanze Dietrich

1 0

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

06 Jul '17

Beste NLNOGers, TL;DR - vraag je BGP vendor om support voor RFC 8212, neem het gedrag mee in het testen van nieuwe software releases en audit je huidige netwerk configurations of je afhankelijk bent van impliciet gedrag. - Job ------ 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

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

RFC 8195 - Use of Large BGP Communities
by Job Snijders 01 Jul '17

01 Jul '17

Beste allemaal, Gisteren is RFC 8195 gepubliceerd: https://tools.ietf.org/html/rfc8195 (Volgens mij is dit de eerste RFC waar NLNOG in wordt genoemd! ;-) Het document is bedoeld om voorbeelden en inspiratie te bieden hoe operationeel gebruik te maken van Large Communities. Door middel van het logisch groeperen van functies en parameters kun je makkelijk typische toepassingen binnen je routing policy maken. RFC 8195 is bedoeld als een soortgelijk "companion document" voor RFC 8092, net zoals RFC 1998 "An Application of the BGP Community Attribute in Multi-home Routing" dat was voor RFC 1997 "BGP Communities". Met bergen open source implementations [1] met support voor Large Communities beschikbaar, en de meer traditionele vendors zoals Junos, XR, Arista & Nokia die waarschijnlijk later dit jaar releases uitbrengen met support, hoop ik dat dit document helpt bij het ontwerpen van routing policies op basis Large Communities! Met vriendelijke groeten, Job [1]: http://largebgpcommunities.net/implementations/

1 0

Announcement: NLNOG Day 2017 - 8 September - Amsterdam - Register now!
by Job Snijders 29 Jun '17

29 Jun '17

Dear operators, Here we go, the only and only technical event for the Dutch network operator community is happening again! This will be an unforgettable day: awesome topics, inspiring presenters, and of course the traditional impossible end-boss pub quiz! The NLNOG day 2017 will take place on Friday September 8th in Amsterdam. We'll take excellent care of you: coffee, lunch, dinner, drinks & wifi will be available. The main language of this event is English, which means all stage activities (such as talks) are held in English. The venue can accomodate roughly 225 people - so don't hestitate! You can register via the following URL: https://nlnogday2017.eventbrite.nl/ Registration is free, but there are also a number of paid options (with receipt for expensing purposes!) for you to easily support NLNOG! Call for Presentations: ----------------------- You are all invited to use this opportunity to present to friends and colleagues about topics such as crazy automation projects, awesome tricks to save money, BGP wizardry, open source work, security, or share historical perspective. Please email stichting(a)nlnog.net with your proposals! The NLNOG community is wildly innovative and very appreciative when new ideas (or explorations to improve old ones) are shared. We prioritize submissions from first-time presenters as encouragement. Registration & Information: --------------------------- Date: September 8th, 2017 Location: Podium Mozaiek, Amsterdam, Netherlands Registration URL: https://nlnogday2017.eventbrite.nl/ General information: https://nlnog.net/nlnog-day-2017/ NLNOG Patreons: --------------- A massive shout-out to these fine organisations for making NLNOG possible! RIPE NCC, PowerDNS, Megaport, PCextreme, Leaseweb, Cybersprint, NTT Communications, ECIX, AMS-IX, and Duocast! Kind regards, Job

1 0

Lekker Weer NLNOG - Vrijdag 16 Juni
by Nathalie Trenaman 17 Jun '17

17 Jun '17

Hoi allemaal, Aankomende vrijdag is het dan zo ver! We gaan een middag en avond naar onze vrienden van BIT in Ede, voor Lekker Weer NLNOG. Er zijn nog maar 14 plaatsen, dus als je van plan was om te komen, schrijf je dan nog snel even in: https://www.eventbrite.nl/e/lekker-weer-nlnog-registration-34193066382 <https://www.eventbrite.nl/e/lekker-weer-nlnog-registration-34193066382> We willen graag weten of je komt, zodat we genoeg bier, fris en pizza hebben. Over de talks kunnen we kort zijn, die zijn weer top-notch en moet je gewoon gezien hebben. Martin Pels, Daan Keuper, Henk-Jan Agteresch, Mark Schouten, Fabian Labohm en Robin Gilijamse zorgen ervoor dat je met een berg verse kennis de deur uit gaat. Vergeet ook niet je oude harddisks mee te nemen, we hebben de grootste mobiele shredder van Europa geregeld. Mocht je met het OV komen, regel even een lift vanaf en naar het station op IRC. Parkeren bij BIT is gratis. Je bent welkom vanaf 14:00 uur. Het adres is: BIT-MeetMe Galileïlaan 17 6716 BP Ede Tot vrijdag! Nathalie Trenaman NLNOG

3 2

Guided Tour through the Quantum Internet at Tu Delft on 22 June
by Vesna Manojlovic 09 Jun '17

09 Jun '17

Hi, Some of you might have seen the Quantum Internet presentation at RIPE 74, by Stephanie Wehner, Professor at the University of Technology in Delft. Stephanie and her colleagues are organising an Open Day at QuTech in Delft and there is still space. Please find more details in RIPE Labs post: https://labs.ripe.net/Members/becha/introduction-to-the-quantum-internet The link to the registration form: https://goo.gl/forms/JBZTQkZ4Y8dJmHnA3 Kind regards, Vesna Manojlovic RIPE NCC

1 0

Guided Tour through the Quantum Internet at Tu Delft on 22 June
by Mirjam Kuehne 07 Jun '17

07 Jun '17

Hi, Some of you might have seen the Quantum Internet presentation by Stephanie Wehner, Professor at the University of Technology in Delft at RIPE 74. Stephanie and her colleagues are organising an Open Day at QuTech in Delft and there is still space. Please find more details and a link to the registration form at the end of this RIPE Labs post: https://labs.ripe.net/Members/becha/introduction-to-the-quantum-internet Kind regards, Mirjam Kuhne RIPE NCC

1 0

BGP Filter Guide
by Job Snijders 18 May '17

18 May '17

Dear NLNOGers, We recently kickstarted a small effort to create a repository of guidance on developing sane BGP filters. http://bgpfilterguide.nlnog.net/guides/ The goal is to provide a go-to place which will help you develop a comprehensive route filtering policy tailored to your specific context. The guide is not meant as "blindly copy+paste this", but it should provide you with sufficient guidance to help you create your own filters. Afterall, each network operates in autonomy and will have their own considerations. The filtering guide is in its early stages: there is work to be done to improve the readability and internal consistency, and additional topics and aspects need to be added. If you want to contribute, just submit a pull-request via https://github.com/nlnog/bgpfilterguide . The guides themselves are simple markdown files as is visible here https://github.com/NLNOG/bgpfilterguide/tree/master/guides In case you identify an area which is not yet covered by one of the guides please consider opening a 'github issue' at https://github.com/nlnog/bgpfilterguide/issues so someone else can consider writing the guide. The entire project is hosted on github and using github's jekyll service for publication. So if you clone the repository you have everything it is. Please consider contributing in the following areas: - add new guides or extend use cases - readability improvements - open issues on topics that need to be addressed I'd like to thank Erik Bais for proposing and contributing to this initiative. Kind regards, Job

3 2

Re: [NLNOG] BGP Filter Guide
by Job Snijders 17 May '17

17 May '17

On Wed, May 17, 2017 at 01:50:55PM +0200, Paul Hoogsteder wrote: > ik ben niet git-bekwaam maar ik heb wel een classic IOS / IOS XE small > prefix filter in de aanbieding: > > ## > ip prefix-list peerfilter seq 5 deny 0.0.0.0/0 > ip prefix-list peerfilter seq 10 permit 0.0.0.0/0 ge 8 le 28 Github is easy peasy! Maak een account via https://github.com/join en vervolgens kun je niet alleen via de CLI maar ook via de webinterface contributies maken, via bijvoorbeeld deze URL: https://github.com/NLNOG/bgpfilterguide/edit/master/guides/small_prefixes.md Groeten, Job

1 0