discuss November 2018

discuss@enog.org

2 participants
3 discussions

Программа RIPE по взаимодействию с научным сообществом/ RACI: Apply Now!

by Gergana Petrova

*English below* Уважаемые коллеги! Мы ищем талантливых исследователей в области Интернет-технологий, которые готовы поделиться результатами своих исследований с сообществом RIPE в рамках Программы RIPE по взаимодействию с научным сообществом (RACI). Прошедшим отбор кандидатам оплачиваются проездные расходы, проживание и билеты для участия в конференции, а также предоставляется возможность представить свою работу на рассмотрение ведущих специалистов Интернета. https://www.ripe.net/raci ------------------- Сроки подачи заявок ------------------- MENOG 18 (25-26 апреля, Тегеран): до 25 февраля RIPE 76 (14-18 мая, Марсель): до 4 марта ENOG 15 (4-5 июня, Москва): до 4 марта SEE 7 (18-19 июня, Тимишоара): до 4 марта На ENOG 14 можно представить доклад на русском или английском языке. ---------------------- Примеры интересных тем ---------------------- – Измерение и анализ сети; – Внедрение протокола IPv6; – Маршрутизация BGP; – Безопасность сети; – Управление Интернетом; – Пиринг и межсетевое взаимодействие; – Интернет вещей. ------------------------------------------------ Последние новости RACI и исследований в области Интернета: ------------------------------------------------ – Подписаться на список рассылки RACI: https://www.ripe.net/raci/mailing-list – Читайте нас в Twitter: @RACI_RIPE Пожалуйста, дайте мне знать, если у вас возникнут какие-либо вопросы. С уважением, Гергана Петрова Отдел внешних связей RIPE NCC -------------------------------------------------- Dear colleagues, The RIPE Academic Cooperation Initiative (RACI) is again looking for talented academics in the field of Internet technology. Successful applicants receive complimentary tickets, travel and accommodation to the meetings and the opportunity to present their research. If you are working on something interesting, please apply! If you know someone in your network who is, please forward them this message. https://www.ripe.net/raci --------------------- Application deadlines --------------------- MENOG 18 (25-26 April, Tehran): apply by 25 February RIPE 76 (14-18 May, Marseille): apply by 4 March ENOG 15 (4-5 June, Moscow): apply by 4 March SEE 7 (18-19 June, Timisoara): apply by 4 March At ENOG 15 you can present in either Russian or English. --------------------------- Examples of relevant topics --------------------------- - Network measurements and analyses - IPv6 deployment - BGP routing - Network security - Internet governance - Peering and interconnectivity - Internet of Things ------------------------------------------------- Get the latest news on RACI and Internet research ------------------------------------------------- - Subscribe to the RACI mailing list: https://www.ripe.net/raci/mailing-list - Follow us on Twitter: https://twitter.com/raci_ripe Please let me know if you have any questions. Have a lovely day! Best regards, Gergana -- Gergana Petrova External Relations RIPE NCC

4 years, 2 months

RACI: Call for Applications

by Gergana Petrova

Dear colleagues, The RIPE Academic Cooperation Initiative (RACI) is again looking for talented academics in the field of Internet technology. Successful applicants receive complimentary tickets, travel and accommodation to the meetings and the opportunity to present their research. If you are working on something interesting, please apply! If you know someone in your network who is, please forward them this message. https://www.ripe.net/raci --------------------- Application deadlines --------------------- MENOG 19, (TBC): apply by 3 February 2019 SEE 8 (16-17 April, Sarajevo): apply by 3 February 2019 RIPE 78 (20-24 May, Reykjavik): apply by 17 February 2019 ENOG 16 (3-4 June, Tbilisi): apply by 17 February 2019 At ENOG 16 you can present in either Russian or English. --------------------------- Examples of relevant topics --------------------------- - Network measurements and analyses - IPv6 deployment - BGP routing - Network security - Internet governance - Peering and interconnectivity - Internet of Things ------------------------------------------------- Get the latest news on RACI and Internet research ------------------------------------------------- - Subscribe to the RACI mailing list: https://www.ripe.net/raci/mailing-list - Follow us on Twitter: https://twitter.com/raci_ripe - Join our group on LinkedIn: https://www.ripe.net/raci/linkedin Please let me know if you have any questions. Have a lovely day! Best regards, Gergana -- Gergana Petrova External Relations RIPE NCC

4 years, 10 months

Fwd: Policies and Guidelines for Assignments for Network Infrastructure and End User Networks

by Töma Gavrichenkov

FYI ---------- Forwarded message --------- From: Töma Gavrichenkov <ximaera(a)gmail.com> Date: Mon, Nov 5, 2018 at 3:36 PM Subject: Policies and Guidelines for Assignments for Network Infrastructure and End User Networks To: <address-policy-wg(a)ripe.net> Cc: <db-wg(a)ripe.net> Hello WG (both, actually), A recent case of a Russian broadband ISP, roughly 6th in size in the country, exposing the personal data of their individual VIP customers by posting said data to RIPE DB(*) highlighted an important issue in RIPE-708, 6.2 "[policies and guidelines for assignments for] Network Infrastructure and End User Networks"(**). To quote: > IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. > When an End User has a network using public address space this _must_ be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. (note the "must", we'll soon get back to it) While it's out of question that posting individual users' personal data to RIPE DB is insane, what's interesting is that small business owners(***), when aware of the leak, seem to also be concerned that their B2B broadband data contract apparently included a clause they've missed, and their mobile telephone number is now published to a public database on the Internet, and, you know, one cannot simply remove an information from the Internet which is already there. But when we try to rely on 6.2 for a definitive advice, we don't get any: - There's no definition of what is exactly meant under "point-to-point links" (PTPL). Some speculate it's a historical term from the times of PPP/SLIP, meaning just "end-user access links", and, as such, includes individual and SMB customer links. Other read it as those IPv4 /30s ASes waste all the time for BGP session establishment, and argue that what's really meant by PTPL is just the IP addresses never ever communicating with the world outside of their own local net (BGP sessions included, SMB access obviously not included). (Personally, the second opinion looks more convincing for me, because this way only those IP addresses which never send or receive packets from the Internet may lack a proper abuse-c, which makes sense, and I like when things make sense, so. But at the same time the first opinion is backed by people I respect.) Anyway, RIPE-708 fails to provide an answer. - Another scary term is "a network using public address space" (NUPAS). Is IPv4 /32 a network? What about /31? What's "using public address space" after all, there's no doubt we won't report our usage of 192.168.0.0/16 to RIPE DB. This sentence was meant to clear our concerns but it just adds up to them. What is also meant to help us but adds to the mess is the RIPE NCC Local Internet Registry Training Course(****), slides 94-95: - Somehow, training material includes more specific definitions and corner cases (e.g. "points of presence") than the policy does. Is it only me, or such a thing should never ever happen? A policy training course must not be different from the policy itself, no matter if the difference is in being either more strict of more relaxed. If an NCC trainer just knows more about the subject than is stated in a policy, they'd better report to the WG first that the policy lacks an important consideration. - However, those definitions don't really clarify what's PTPL and NUPAS are, too. - Slide 95 is even better: it says there's a grey area around. Well, it might be again only me, but personally I feel very uncomfortable seeing "must" and "grey area" in the same sentence. If there's a grey area in an area, it must be "should" there, not "must". - There's apparently a border line between "when the End User has a few addresses out of a larger address block" and "If the End User has a separate subnet". Now again, (an occasional?) /31 is a subnet or just a few addresses? Who's going to check ISPs against this strict ("must") requirement, and how? - What if there's a customer with an pizza store (so, an office within their location) and their own equipment (Mikrotik) connected to a broadband pool? - What if a broadband customer sets up an HTTP server on their point-to-point link's public v4 address and starts serving whatever children drug suicide abuse torrents they have. All in all, RIPE-708 6.2 is a perfect example of an imperfect policy, too strict and too vague at the same time. Which is bad, because a) some ISPs would just prefer to ignore it, no matter the "must", and would be paying less attention to other "musts" they would encounter in other policy documents, b) those ISPs who would choose to be responsible about RIPE DB usage risk losing customers and wouldn't be able to defend their attitude against the customers, let alone courts, based on the RIPE DB policy. So here are two separate things I propose, and I'd prefer them to be discussed and evaluated separately: 1) Ask the author of LIR training material to provide the WG (both) with the historical insight on what was meant in 6.2, and how's that supposed to work. Afterwards, after a heated discussion on the mailing list (both), make a decision and amend a policy towards either a more relaxed, or a more constraining fashion, but do either of things anyway, as there's no SLIP anymore, and such an irresponsible wording of a policy as it stands today undermines the trust in policy process, especially in some Eastern European and Northeast countries where there's hardly any trust even now. My personal suggestion is that the only border line that should be there is between businesses/organizations with public IP addresses, on one side, and individual users/NAT pools, on the other. If a company is using a public IP address space for any purpose at all, it must publish at least an abuse-c contact to a public IP database. Fair enough IMO. 2) Change 6.2 to reflect the fact that the contact information of End Users who are individuals not MAY, but rather MUST be substituted with the contact data of the service provider. This perfectly reflects currently ongoing legislation trends as well as a concern in the society at large, and also would be seen as a responsible attitude of an ISP community towards the personal data safety — an attitude the ISP community hardly used to show before. (*) — https://www.bbc.com/russian/news-46083410. Here's a Google Translate link for your convenience: https://translate.google.com/translate?sl=ru&tl=en&js=n&u=https%3A%2F%2Fwww… (**) — https://www.ripe.net/publications/docs/ripe-708#62 (***) — My definition of a "small business" here might seem too broad, but if's fully grounded: e.g. Main Directorate for Drugs Control of the Ministry of Internal Affairs of Russia, as a business, is definitely not so big; Alfa Bank is a large bank in Russia but Russian banking system is comparatively small when compared to the rest of the world; etc. (****) — https://www.ripe.net/support/training/material/lir-training-course/lir-slid… | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

4 years, 11 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

discuss November 2018