From ximaera at gmail.com Mon Nov 5 09:36:47 2018 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 5 Nov 2018 15:36:47 +0700 Subject: [address-policy-wg] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks Message-ID: 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.bbc.com%2Frussian%2Fnews-46083410 (**) ? 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-slides.pdf | T?ma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera at gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 From nick at foobar.org Mon Nov 5 11:50:26 2018 From: nick at foobar.org (Nick Hilliard) Date: Mon, 5 Nov 2018 12:50:26 +0200 Subject: [address-policy-wg] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks In-Reply-To: References: Message-ID: <9c661611-b969-4cd3-0e74-f93039b6a6f1@foobar.org> T?ma Gavrichenkov wrote on 05/11/2018 10:36: > But when we try to rely on6.2 for a definitive advice, we don't get any: The general practice is to treat /30-/32 as LIR infrastructure assignments, i.e. not register them. /29s are borderline - there are cases where a /29 could be considered as a point-to-point link, e.g. single customer address + VRRP config on routers. Ambiguity allows common sense to be used. There is a bigger issue of whether personal information should be exposed in public whois for any resource registration. Nick From ximaera at gmail.com Mon Nov 5 11:55:36 2018 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 5 Nov 2018 17:55:36 +0700 Subject: [address-policy-wg] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks In-Reply-To: <9c661611-b969-4cd3-0e74-f93039b6a6f1@foobar.org> References: <9c661611-b969-4cd3-0e74-f93039b6a6f1@foobar.org> Message-ID: On Mon, Nov 5, 2018 at 5:50 PM Nick Hilliard wrote: > /29s are borderline - there are cases where a /29 could be considered as > a point-to-point link, e.g. single customer address + VRRP config on > routers. I've discussed that one before in ENOG. I've heard a concern that an ISP is not really going to figure out the usage of leased IP addresses, and if at some point the backup address in VRRP would start to be used separately for its own purposes, the ISP would miss that. So, like I said, there's apparently no real reason to be so specific about those borderlines. > Ambiguity allows common sense to be used. The issue with common sense is that common sense just doesn't scale. I've heard about 5 different opinions on this one already in ENOG. All those five are based on what the respective backers believe to be their common sense. | T?ma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera at gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 From leo.vegoda at icann.org Mon Nov 5 17:12:11 2018 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 5 Nov 2018 16:12:11 +0000 Subject: [address-policy-wg] [Ext] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks In-Reply-To: References: Message-ID: <074c4bd8e0384415802de2ff7cde00e3@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Hi, T?ma Gavrichenkov wrote: [...] > > 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. [...] > 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. Over 20 years ago, the ISP at which I worked had a number of customers with home networks using public IP address space. The ISP placed its own contact information in the RIPE Whois Database with a comment that the address space was assigned to an individual customer. If I remember correctly this was done for two key reasons: 1. RIPE policy does not override the law of the land. 2. There was very little value in placing those customers' contact details in the RIPE Whois Database because they were network users and not network administrators. The ISP's NOC staff had skills, tools, processes, and training and were in a much stronger position to provide meaningful assistance to anyone with a genuine reason to make contact about the administration of one of those customer networks. As I remember, the RIPE NCC was happy with the rationale back then. While the specific wording of RIPE policy might have changed somewhat in the last 20 years, I don't think the intent has. The contact details of the End User do not have to mean their personal phone number or e-mail address. And if they do not have the skills, tools, processes, and training to provide meaningful assistance to anyone with a genuine reason to make contact about a specific network, providing a personal phone number or e-mail address is arguably unhelpful. Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3739 bytes Desc: not available URL: From ximaera at gmail.com Mon Nov 5 18:03:10 2018 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 6 Nov 2018 00:03:10 +0700 Subject: [address-policy-wg] [Ext] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks In-Reply-To: <074c4bd8e0384415802de2ff7cde00e3@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <074c4bd8e0384415802de2ff7cde00e3@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: Hi Leo, Just to make it 100% clear for me: do you mean to say that you support my proposal No. 2? ??, 5 ????. 2018 ?., 23:12 Leo Vegoda : > Hi, > > T?ma Gavrichenkov wrote: > > [...] > > > > 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. > > [...] > > > 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. > > Over 20 years ago, the ISP at which I worked had a number of customers > with home networks using public IP address space. The ISP placed its own > contact information in the RIPE Whois Database with a comment that the > address space was assigned to an individual customer. > > If I remember correctly this was done for two key reasons: > > 1. RIPE policy does not override the law of the land. > 2. There was very little value in placing those customers' contact details > in the RIPE Whois Database because they were network users and not network > administrators. The ISP's NOC staff had skills, tools, processes, and > training and were in a much stronger position to provide meaningful > assistance to anyone with a genuine reason to make contact about the > administration of one of those customer networks. > > As I remember, the RIPE NCC was happy with the rationale back then. While > the specific wording of RIPE policy might have changed somewhat in the last > 20 years, I don't think the intent has. > > The contact details of the End User do not have to mean their personal > phone number or e-mail address. And if they do not have the skills, tools, > processes, and training to provide meaningful assistance to anyone with a > genuine reason to make contact about a specific network, providing a > personal phone number or e-mail address is arguably unhelpful. > > Kind regards, > > Leo Vegoda > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Nov 5 18:18:13 2018 From: gert at space.net (Gert Doering) Date: Mon, 5 Nov 2018 18:18:13 +0100 Subject: [address-policy-wg] [Ext] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks In-Reply-To: References: <074c4bd8e0384415802de2ff7cde00e3@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <20181105171813.GD11393@Space.Net> Hi, On Tue, Nov 06, 2018 at 12:03:10AM +0700, T?ma Gavrichenkov wrote: > Just to make it 100% clear for me: do you mean to say that you support my > proposal No. 2? Please keep the discussion on the address-policy-wg list (reply-to: set), and please try to quote only those parts of the original e-mail that are relevant for your answer. We have a list archive and a nice threaded view, so there is no need to contain the whole discussion in every single e-mail sent. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From leo.vegoda at icann.org Mon Nov 5 18:56:05 2018 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 5 Nov 2018 17:56:05 +0000 Subject: [address-policy-wg] [Ext] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks In-Reply-To: References: <074c4bd8e0384415802de2ff7cde00e3@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: T?ma Gavrichenkov wrote: > Hi Leo, > > Just to make it 100% clear for me: do you mean to say that you > support my proposal No. 2? I believe that was: > 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. As someone currently employed by ICANN, I don't advocate for or against address policy proposals. I think I can note that Article 3 of the RIPE Database Terms and Conditions defines the database's purpose, and includes: "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" I expect that most subscribers to broadband Internet services would not be effective at coordinating with network operators as they are almost always using simple plug and play equipment. On that basis, I don't really think these subscribers really are network operators as it is not reasonable to expect them to make configuration changes more complex than powering off their home router. I read 6.2 as trying to distinguish between smaller, single-homed networks operated by organizations with some IT staff and a home network with a few public IP addresses. In the former case there might be some point in having contact details published. Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3739 bytes Desc: not available URL: From mschmidt at ripe.net Wed Nov 7 11:04:27 2018 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 07 Nov 2018 11:04:27 +0100 Subject: [address-policy-wg] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks In-Reply-To: Message-ID: Dear T?ma, Thank you for your questions. Please allow me to provide some clarification. Regarding our LIR Training Course - it's important to note that this is intended to help people fulfil their role as representatives of a member. Our training courses do not provide a different interpretation of RIPE policies ("either more strict or more relaxed") - but rather represent the shared understanding and practices of network operators in the RIPE community. That being said, we are constantly reviewing our training material and will take another look at this with your feedback in mind. Nick and Leo have already provided some clarification around the historical context of section 6.2 of the policy (ripe-708). We agree with their comments and there's not much we can add beyond this. If you feel that the wording in this section is ambiguous, we invite you to make use of the Policy Development Process to propose a change to the policy. I will be happy to follow-up with you offline to provide more details and guidance to help you create a policy proposal. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From martin.tonusoo at citictel-cpc.com Tue Nov 13 13:41:20 2018 From: martin.tonusoo at citictel-cpc.com (Martin Tonusoo) Date: Tue, 13 Nov 2018 20:41:20 +0800 (HKT) Subject: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy Message-ID: <321670132.2858973.1542112880780.JavaMail.zimbra@citictel-cpc.com> Hello, according to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"(ripe-708) document, the "status" attribute value "ASSIGNED PA" has a definition of "This address space has been assigned to an End User for use with services provided by the issuing LIR". As "ASSIGNED PA" should also be used for assignments for LIR own infrastructure, then isn't the definition of "This address space has been assigned to the issuing LIR infrastructure or End User for use with services provided by the issuing LIR." bit more accurate? Best regards, Martin Tonusoo IP Network Engineer -------------------------- CITIC Telecom CPC www.citictel-cpc.com -------------------------- Direct: +372 622 3321 NOC 24/7: +372 622 3300 NOC 24/7: +7 495 9815670 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Fri Nov 30 12:33:13 2018 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 30 Nov 2018 11:33:13 +0000 Subject: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy Message-ID: <75F20C9C-4D78-4354-9FD7-1578DA4FEAFE@a2b-internet.com> Hi Martin, If you look at the text, would the LIR who assigned IP space to their own infra-structure not also be an End-User ? In the past, the LIR would describe IP space for themselves as Infra or INFRA-AW, but still give it the status Assigned PA. Something along the lines of this example : https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=178.249.152.0%20-%20178.249.152.127&type=inetnum Regards, Erik Bais From: address-policy-wg on behalf of Martin Tonusoo Date: Tuesday 13 November 2018 at 13:42 To: "address-policy-wg at ripe.net" Subject: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy Hello, according to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"(ripe-708) document, the "status" attribute value "ASSIGNED PA" has a definition of "This address space has been assigned to an End User for use with services provided by the issuing LIR". As "ASSIGNED PA" should also be used for assignments for LIR own infrastructure, then isn't the definition of "This address space has been assigned to the issuing LIR infrastructure or End User for use with services provided by the issuing LIR." bit more accurate? Best regards, Martin Tonusoo IP Network Engineer -------------------------- CITIC Telecom CPC www.citictel-cpc.com -------------------------- Direct: +372 622 3321 NOC 24/7: +372 622 3300 NOC 24/7: +7 495 9815670 -------------- next part -------------- An HTML attachment was scrubbed... URL: