July 2017 - NLNOG - mailman3.nlnog.net

Open Call - SIDN fonds - met extra aandacht voor privacy en veiligheid
by Vesna Manojlovic 21 Jul '17

21 Jul '17

(Dear all, here is a call - in Dutch - from SIDN. Please forward to your contacts who might be interested. Vesna) Nu open! Een aantal keer per jaar is het mogelijk om een aanvraag voor financiering in te dienen. Per jaar zijn er twee open calls voor innovatieve internetprojecten en een call voor wetenschappelijke onderzoeksprojecten. De najaarscall staat zoals gebruikelijk open voor alle internetprojecten die aansluiten bij onze doelstellingen. Daarnaast is er extra aandacht voor projecten die privacy EN veiligheid combineren. OPEN CALL VOOR INNOVATIEVE INTERNETPROJECTEN Heb jij (als individu, ondernemer, organisatie of onderzoeker) een idee of een project dat bijdraagt aan onze doelstellingen? Overtuig ons! Twee keer per jaar (voor- en najaarscall) kun je een aanvraag indienen. We bieden twee aanvraagmogelijkheden: * Pioniers (gericht op de uitwerking van een goed idee, max Euro 10.000,-) * Potentials (doorontwikkeling/opschaling van een bewezen concept, max Euro 75.000,-) Nu open! Deadline: 12 september 2017, 13.00 uur Gezocht: projecten met focus op privacy EN veiligheid In onze digitale samenleving zijn privacy en veiligheid urgente, actuele thema?s. Veel partijen houden zich bezig met privacy of veiligheid en in de praktijk lijkt het een het ander nogal eens uit te sluiten. Terwijl het juist nu (in tijden van cybercrime, eenvoudige privacyschending van individuele burgers en nieuwe wetgeving) van belang is om op beide aspecten te focussen. Privacy en veiligheid zijn twee kanten van dezelfde medaille. Ben jij ook van mening dat minder privacy niet automatisch leidt tot meer veiligheid en andersom meer privacy niet tot minder veiligheid hoeft te leiden? SIDN fonds roept op om met concrete oplossingen voor eindgebruikers te komen waarbij privacy en veiligheid geen tegenstelling vormen, maar elkaar juist versterken. Projecten die zich hier mee bezig houden worden nadrukkelijk uitgenodigd om tijdens de najaarscall een aanvraag in te dienen (deadline 12 september 13.00 uur). Zie voor meer informatie: https://www.sidnfonds.nl/privacy-en-veiligheid/ Mieke van Heesewijk Programmamanager Aanwezig op: ma | di | wo | do Meander 501 6825 MD Arnhem Postbus 3036 6802 DA Arnhem T +31 (0)26 352 55 21 M +31 (0)6 50839185 mieke.vanheesewijk(a)sidnfonds.nl www.sidnfonds.nl

1 0

New NOG Section on RIPE Labs
by Vesna Manojlovic 20 Jul '17

20 Jul '17

Dear colleagues at NLNOG, The RIPE NCC actively supports the establishment and development of network operator groups (NOGs) across its service region. To help with this goal, we have created a NOG section on RIPE Labs that contains useful articles and information for NOGs. https://labs.ripe.net/nogs There is also an article explaining exactly what the RIPE NCC can do to help with your NOG, whether it is just starting or is already well-developed. https://labs.ripe.net/Members/mirjam/how-the-ripe-ncc-can-help-network-oper… Please contact us (at labs(a)ripe.net) if you would like any support from the RIPE NCC for your NOG or if you would like to contribute an article about your NOG to the pages on RIPE Labs. Also, if you know of a NOG that is not included on our map of NOGs in the region, please let us know. Kind regards, Vesna Manojlovic Community Builder RIPE NCC

1 0

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