swinog

swinog@lists.swinog.ch

6 participants
2924 discussions

##### SwiNOG #33 - RegOpen & CFP #####
by Simon Ryf 01 Mar '18

01 Mar '18

Dear SwiNOG supporter, Registration for SwiNOG #33 is open and we’re looking for Papers https://register.swinog.ch If you register until 11.05.2018 there will be a special surprise for you :-) Call for Paper!! this is the official Call for Paper email. Please send your proposal to swinog-core(a)swinog.ch The 33rd meeting of the Swiss Network Operators Group (SwiNOG) will be held in Berne on top of the Gurten on Thursday May 24th 2018. Important Dates for SwiNOG#33 01.03.2018 Call for Papers 01.03.2018 Registration opens 30.04.2018 Call for Papers closing 11.05.2018 Final publication of agenda 19.05.2018 Registration closes 22.05.2018 Deadline for all slides 24.05.2018 Meeting day Topics for Presentations/Talks The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 5 to 45 minutes. Here is a non-exhaustive list of typical SwiNOG meeting topics: - Security - DDOS Mitigation - AntiSpam - IPv6 - Open Source tools - International view of the internet (incidents, outages, measurements) - Routing - Server applications (DNS, Web, etc.) - Legal issues (B‹PF, etc.) - Telecommunication politics (Net Neutrality, Incumbent monopoly, etc.) -> PLEASE feel free to talk to us about any kind of topic and collaboration!!! You can always start a discussion on the list - I'm sure people join in. Language of Slides and Talks The whole day will be held in English, therefore we kindly ask you to produce your presentation in English. Submission Guidelines All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information to <swinog-core at swinog.ch>: * the name of the presenter (and if applicable your affiliation) * a working email-address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * a short abstract of the presentation (so we know what it is about) We also welcome suggestions for specific presentations which you feel would be valuable to the SwiNOG community. Please be aware that your presentation will be published on the SwiNOG website after the event. We can publish modified slides if requested - it might be that some confidential data will be presented by you which are not intended for publication on the internet. Greetings, Simon Ryf SwiNOG Core Team General Information (SwiNOG Community) The Swiss Network Operators Group (SwiNOG) is an informal group of people who are concerned with engineering and operation of the Swiss Internet. SwiNOG exists to enhance the quality of Internet services available in Switzerland. It does this by fostering the free exchange of technical ideas and information between different companies and organisations. SwiNOG is a community for professionals who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about SwiNOG can be found at http://www.swinog.ch , Facebook, Xing, Information about the meeting will be published at http://www.swinog.ch/meetings/swinog33 General Information (SwiNOG Organisation) The SwiNOG Organisation Association is a non-profit association under article 60 and further of the swiss civil law. It manages the SwiNOG community resources (domain, web, mailing-lists, etc..) and organises SwiNOG meetings. Contact: SwiNOG Organisation 8000 Zurich Switzerland

1 0

DNSSEC Training with PowerDNS
by Michael Hausding 28 Feb '18

28 Feb '18

Dear all SWITCH is organising a one day DNSSEC training together with PowerDNS The training will be given at the following dates: 9.4. Zurich, SWITCH 10.4. Bern, Uni 11.4. Carouge HESGE The one day training will give you an introduction into DNSSEC and show you how to sign DNS zones on an autoritative DNS server. We will use PowerDNS for the practical and hands on part. PowerDNS contains support for DNSSEC, enabling the easy serving of DNSSEC secured data, with minimal administrative overhead. Agenda: • Short introduction to DNSSEC • how DNSSEC works • keys / signatures / NSEC / NSEC3 • Working with DNSSEC and the PowerDNS Authoritative server • Short overview over PowerDNS Authoritative server backends (MySQL, PostgreSQL, BIND, pipe, ...) • DNSSEC signing • Pre-signed zones • Zone transfers • Utilities (pdnsutil) • The PowerDNS ALIAS record (and its future) Required skills: Unix system administrator skills and DNS server know how. The training will be delivered in english. More information and registration here: Zurich: https://www.eventbrite.com/e/dnssec-training-zurich-tickets-43350331007 Bern: https://www.eventbrite.com/e/dnssec-training-bern-tickets-43592055010 Carouge: https://www.eventbrite.com/e/dnssec-training-carouge-tickets-43592840359 Best regards Michael ------------------------------------ Michael Hausding, Competence Lead DNS & Domain Abuse SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 77, incident phone +41 44 268 15 40 michael.hausding(a)switch.ch http://securityblog.switch.ch

4 4

Mail to CNAME a thing?
by Markus Wild 22 Feb '18

22 Feb '18

Hi there, I've just come across a weird mail reception problem of some mails from Microsoft. Our servers insist that a specified MAIL FROM address can be resolved correctly, and this usually boils down to the following checks on the domain-part of the email-address specified: - is there an MX? Does the target resolve using an A record (not a CNAME), and does it resolve to a publically reachable address (not RFC1918 or localhost etc) - if there is no MX, is there an A record that fulfils the same criteria as the MX target above? - if none of these are true, the address is considered to be invalid and mail is rejected Since about Feb 15, I've now come across mails from account-security-noreply(a)accountprotection.microsoft.com that get rejected. When I manually perform the above steps, I can see why, and I also see a first: the domain part is actually a CNAME, something I've not encountered mentioned in standards as being a legal way to perform address resolution when delivering email. But, I also don't recall reading about rules that explicitly deny this, contrary to the very explicit rules that for example deny having MX point to CNAME. The domain setup here is borked in multiple ways however: $ host -t mx accountprotection.microsoft.com Host accountprotection.microsoft.com not found: 3(NXDOMAIN) $ host -t a accountprotection.microsoft.com Host accountprotection.microsoft.com not found: 3(NXDOMAIN) BUT: $ host -t cname accountprotection.microsoft.com accountprotection.microsoft.com is an alias for mail.msa.msidentity.com. and even if we should allow use of a CNAME here, we'd have to apply the same rules as stated initially on the CNAME target, and these fail as well: $ host -t mx mail.msa.msidentity.com. Host mail.msa.msidentity.com not found: 3(NXDOMAIN) $ host -t a mail.msa.msidentity.com. Host mail.msa.msidentity.com not found: 3(NXDOMAIN) So, what's your take on this? Does someone see a legal way to resolv this sender, that I've missed? Am I right in considering these addresses to be unresolvable and thus reject these mails? Who would I have to report this to at Microsoft to have any chance of a human person looking at the issue? Cheers, Markus

6 10

Call for presentations RIPE 76
by Franziska Lichtblau 18 Feb '18

18 Feb '18

Dear all, Please find the CFP for RIPE 76 below or at: https://ripe76.ripe.net/submit-topic/cfp/. The deadline for submissions is *11 March 2018*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Franziska Lichtblau RIPE PC Member https://ripe76.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 76 will take place from 14-18 May in Marseille, France. 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 76. See the full descriptions of the different presentation formats, https://ripe76.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *11 March 2018*. 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 Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc(a)ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship Submissions Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe76.ripe.net/plenary-or-wg/ 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 (during evening sessions) - 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://ripe76.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe76.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(a)ripe.net. -- Franziska Lichtblau, M.A. building MAR, 4th floor, room 4.004 Fachgebiet INET - Sekr. MAR 4-4 phone: +49 30 314 757 33 Technische Universität Berlin gpg-fp: 4FA0 F1BC 8B9A 7F64 797C Marchstrasse 23 - 10587 Berlin 221C C6C6 2786 91EC 5CD5

1 0

What email headers need to be understood by a PGP/MIME enabled email client?
by Benoit Panizzon 16 Feb '18

16 Feb '18

Hello fellow Swinogers To exchange emails containing potentially sensitive customer information with swisscom, we agreed to use PGP encrytped emails. Now when swisscom is sending an encrypted attachment to us, we get those MIME Headers: ------=_Part_5064522_1012233884.1518535424993 Content-Type: application/octet-stream; name=Attachment1.asc Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: application/pdf; name=Attachment1.asc X-Content-PGP-Universal-Saved-Content-Description: Example_Filename.pdf X-Content-PGP-Universal-Saved-Content-Disposition: attachment; filename=Attachment1.asc; size=143718; creation-date="Tue, 13 Feb 2018 14:56:05 GMT"; modification-date="Tue, 13 Feb 2018 14:56:05 GMT" X-Content-PGP-Universal-Saved-Content-ID: <F73FD4960576014A98D75D430AABA49B(a)swisscom.com> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Attachment1.asc -----BEGIN PGP MESSAGE----- Version: OpenPGP totemomail Comment: totemomail OpenPGP - http://www.totemo.com [encrypted content] Well, Neither Claws-Mail nor Firefox with Enigma Plugin do understand those X-Content-PGP Emails which would specify the correct content type and file name and just merely show a binary "Attachment1.asc" attachement. Of course, as experienced user reading the email source, you can save this to disk and then open it with a PDF reader, but using encrypted email should be easier than that :-) So I contacted the totemo support and they told me, that every PGP enabled email client should be able to correctly extract mime-type and filename from the X-Content-PGP Headers. Well I have found: https://www.ietf.org/rfc/rfc4880.txt https://binblog.info/2008/03/12/know-your-pgp-implementation/ Well, I know no clients which support RFC4880 when generating or decoding PGP encrypted emails. How about the SWINOG Community? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 1

Cloudmark and Bluewin
by Alex Faes 15 Feb '18

15 Feb '18

Hi @ll, We have some issue with sending email to @bluewin.ch. Since a few months, all Emails sent to bluewin.ch recipients are marked as junk. L That what we can see: X-Bluewin-Spam-Analysis: v=2.1 cv=eusSttdX c=1 sm=1 tr=0 p=9iobZdBrAAAA:8 a=UyOLZL4rDy101xZCZBNcuQ==:117 a=UyOLZL4rDy101xZCZBNcuQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=Op4juWPpsa0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=tmi9kOqBNXXKSUpxMQ4A:9 a=CjuIK1q_8ugA:10 a=ZsvHfuFSAAAA:8 a=DGG8EIu7HUducKyVYroA:9 a=IzkmhS4iMz_GUfKi:21 a=QEXdDO2ut3YA:10 a=SJFCsYi-t6UA:10 a=iZBDQVmU8otq4hDR5MHx:22 a=Ryc2fXeAP51dHFQ1qRxw:22 X-Bluewin-Spam-Score: 100.00 X-FXIT-IP: IPv4[94.100.136.225] Epoch[1518688233] X-Bluewin-Spam: Cloudmark If anybody from bluewin/Swisscom, please contact me off list Greetings alex

1 0

RIPE NCC Global IPv6 Deployment Survey
by Massimiliano Stucchi 14 Feb '18

14 Feb '18

Dear colleagues, The RIPE NCC would like to invite you to participate in its Global IPv6 Survey 2018. The goal of the survey is to get an overview IPv6 deployment across the world, and to assess how this is seen from the perspective of ISPs and Enterprise users. The 2018 survey is a follow up to similar surveys run between 2008 and 2013, and will serve as a comparison with the data acquired back then. You can find the survey at the following address: https://www.surveymonkey.com/r/GlobalIPv6survey2018 Responses can be submitted until 31 March 2018. We will then collect the data with the aim of presenting the preliminary results during the upcoming RIPE 76 meeting in Marseille. If you have any question about the survey, please feel free to email us at: ipv6survey2018(a)ripe.net. Thank you very much in advance for your participation! -- Massimiliano Stucchi IPv6 Programme Manager RIPE NCC mstucchi(a)ripe.net Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC

1 0

ALLOCATED UNSPECIFIED ranges [RIPE/alloc-unspecified]
by Paolo Moroni 08 Feb '18

08 Feb '18

Good afternoon from AS3303 (Swisscom/IP-Plus). This e-mail is intended as help information for those of you who operate IPv4 PI addresses within the following ranges: 193.5.0.0/16 193.134.0.0/15 193.246.0.0/15 for historical reasons, these ranges used to have a status of ALLOCATED UNSPECIFIED in the RIPE data base and were managed by the ch.unisource LIR (ourselves). In 2016 the RIPE-NCC has received a mandate from the RIPE Address Policy working group to transfer these addresses into standard ALLOCATED PA and ALLOCATED PI addresses, managed by the RIPE-NCC; if interested in the details, please see https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-October/0118… The transfer of these three ranges has been completed recently. This includes the management responsibility of the related PI assignments, although, for practical reasons, the Swisscom maintainer CH-UNISOURCE-MNT has not been removed from some objects yet. Please find enclosed below the guidelines we received from the RIPE-NCC with respect to the administration of the related RIPE data base objects. Thanks for your attention and understanding, Paolo Moroni IP-Plus Engineering ch.unisource ----------------------------------------------------------------------- Following the re-organisation of ALLOCATED UNSPECIFIED addresses blocks formerly managed by CH-UNISOURCE-MNT, the management of the PI assignments has been transferred to the RIPE-NCC. Each PI assignment will need to have a "Sponsoring LIR" (a RIPE NCC member responsible for maintenance, accuracy and communication with regards to a specific assignment). Please see http://www.ripe.net/ripe/docs/ripe-637#20 for details. Please contact your Sponsoring LIR if you have one. If not, please contact RIPE NCC, <ncc(a)ripe.net>

1 0

IPv6 Run Event
by Nico Schottelius 04 Feb '18

04 Feb '18

Good morning Swinog, we are planning our first IPv6 focused event this year. The main topic of the event is, how well the IPv6 deployment of Switzerland has come and to discuss the action points to reach 100% IPv6 coverage. Thus I would like to invite you to join and... ... showcase how and where you enabled sites with IPv6 ... show difficulties and solutions for IPv6 only networks ... meet players from industry to discuss your needs with others ... get a tasty Adler Bräu beer We are at an early planning stage, but wanted to begin to spread the word already (i.e. date to be defined, Website & CfP coming in the next weeks). The format will likely be a 1-2 day event, with talks during the day, discussion in the late afternoon and a networking event in the evening. To decide on the exact format, I would like to ask you to give me a heads up, if you are interested in this event and if you are interested in showcasing something. A simple "+1" or "+1 +talk_about_x" suffices. Depending on the feedback, we will plan for either a 1 or 2 day event. Thanks a lot and have a great snowy Sunday, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

1 0

datacomm/vtxnet and quicknet/kfsb are missing TLS on their mailservers
by Peter Keel 02 Feb '18

02 Feb '18

Hi I get these errors: | TLS is required, but was not offered by host mx1.datacomm.ch[212.40.2.32] and | TLS is required, but was not offered by host relay.kfsb.ch[213.202.32.8] Since I've made TLS for SMTP mandatory. The respective admins of these servers might want finally at least enable voluntary TLS; some of their customers apparently would like to receive mails from my server. And by the way, RFC 2487 that is referred to for instance in the postfix manpage and stated that one must not make TLS mandatory has been obsoleted by RFC 3207. Cheers Seegras -- "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin "It's also true that those who would give up privacy for security are likely to end up with neither." -- Bruce Schneier

7 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog