- db-wg - mailman.ripe.net

Whois Release 1.93
by Edward Shryane 04 Mar '19

04 Mar '19

Dear Working Group, RIPE Database release 1.93 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Monday, 25th February. Release 1.93 includes the following main changes: * Improved email address validation. * Do not allow expired public keys to authenticate updates, and expire signed messages after 1 hour. * Validate bogon space in route(6) creation. * Warn the user if the resource abuse-c is identical to the organisation's abuse-c. * Allow use of elliptic curve algorithm in key-cert objects (updated cryptography library). * Fixed NRTM client parsing end of stream comment in keepalive mode. * Filter out comment in autocomplete API (used by the DB web application) * Only validate reserved words in primary key on create, so existing objects can be updated. * Database schema changes for 2017-02 Abuse-c Validation implementation. The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt The release notes will also be published shortly: https://www.ripe.net/manage-ips-and-asns/db/release-notes More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 2

Whois Release 1.92.6.2
by Edward Shryane 01 Mar '19

01 Mar '19

Dear Working Group, RIPE Database release 1.92.6.2 was deployed to production yesterday evening, with a single change from the previous 1.92.6 release. Following the Database downtime on 22 February, this change restores the Full Text Search functionality. More information on the downtime can be found on our website: https://www.ripe.net/support/service-announcements/ripe-database-full-text-… We apologise for any inconvenience caused by this incident. Regards Ed Shryane RIPE NCC

1 0

No more personal objects in the RIPE Database?
by Hans Petter Holen 23 Feb '19

23 Feb '19

Following Denis’s presentation at the last database working group meeting and Elvis’s messages to the RIPE NCC members list I think it is time to have a new discussion on the need for personal objects in the RIPE Database. https://ripe77.ripe.net/presentations/63-PERSONobjects.pdf https://ripe77.ripe.net/archives/video/2298/ https://www.ripe.net/ripe/mail/archives/members-discuss/2019-February/00329… This is not questioning previous legal assessments of GDPR compliance, but taking a step back and looking at how would we do this if we were to design the RIPE Database with today's privacy requirements in mind. The ccTLD for .NO, Norid made an update to their service last year to completely remove person objects from their database. https://www.norid.no/uploads/2017/12/Datamodell-revidert-en-v2.pdf In terms of the RIPE Database, that would mean that resources would refer to organisational objects and roles, not to personal objects. Perhaps Denis and/or Elvis would propose a policy change in this respect? Hans Petter

3 3

Re: [db-wg] Idea: magic mntner for all LIR contacts
by Tore Anderson 19 Feb '19

19 Feb '19

* Aleksi Suhonen > On 03/12/2018 10:35, Tore Anderson via db-wg wrote: >> So I was thinking: is this mandatory and error-prone duplication of work >> really necessary? Wouldn't it be possible to instead have some kind of >> magic mntner object that is is kept automatically up to date with «auth: >> SSO»-attributes for all the LIR user accounts? > > I second this idea. Perhaps this should be a different object type tho, to make it clear that editing the magic maintainer by hand will have undesired results. It should be interchangeable with normal maintainers of course, a bit like person objects and role objects are. Or maybe just expand the existing SSO attribute to accept a RegID. For example: mntner: FOOBAR-MNT auth: SSO no.foobar Which would allow maintenance by all registered user accounts in LIR no.foobar (except for accounts with the «billing» privilege level). > Do you want someone to co-author a PDP on this? I was hoping that a PDP wouldn't be necessary, to be honest. That is, if the NCC thought it was a good idea they could just go ahead and implement it. (If I recall correctly, the «auth: SSO» functionality was added without there being a community policy demanding it.) That said, if you want to write a proposal to this effect I'd be happy to put my name on it. Tore

9 44

Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects
by Christoffer Hansen (Lists) 11 Feb '19

11 Feb '19

Dear DB WG, It came to my attention the RIPE NCC Database does not do validation of signed updates. (Other than checking the key is allowed to sign updates for object(s) in question) I got the understanding from writing to DB-WG-Chairs this was a decision made years back. I think is less than optimal from a security perspective an signed update (with GPG and/or X509 certs) is not validated against (1) when the update was signed (E.g. signing was done 10 minutes ago) and (2) that the expiration date for the keys are not validated. Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database. What I have in mind. Is the RIPE NCC Database begins verifying validity (not revoked and/or expired) of GPG-key|X509-cert used to sign updates with. Christoffer

7 10

Certain sponsored? ASNs without sponsoring-org
by Cynthia Revström 08 Jan '19

08 Jan '19

So I have now run across several ASNs in which the org is of type "OTHER" yet there is no sponsoring-org, could this please be clarified? Example ASNs: AS200358, AS204842 If it is like I think it is, it must be that they have lost their sponsors but if that is the case, I would like to see a remark that is an "RIPE NCC managed value" saying something like "This ASN does not have any sponsor since YYYY-MM-DD". I am not entirely sure on this but something to clarify what is going on. Kind regards, Cynthia Revström

5 9

usage of LIR-PARTITIONED status
by Marco Schmidt 20 Dec '18

20 Dec '18

Hello Alex, Allow me to provide some additional clarification. As Gert has already correctly explained, the status LIR-PARTITIONED is used to partition allocations. For inetnum objects with the status ALLOCATED PA, you can create more specific objects with the status LIR-PARTITIONED PA. The same applies for PI. However there are no inetnums with the status ALLOCATED PI in the RIPE Database, and such ranges are no longer provided by the RIPE NCC. Recently, consensus was reached on a policy change to remove the status ALLOCATED PI and LIR-PARTITIONED PI from the RIPE IPv4 Policy document. https://www.ripe.net/participate/policies/proposals/2018-03 Following this policy change, we will also remove this status from the RIPE Database code and documentation shortly. I hope this clarifies things. Kind regards, Marco Schmidt Policy Officer RIPE NCC

1 0

usage of LIR-PARTITIONED status
by Alexander Stranzky 19 Dec '18

19 Dec '18

Hello, recently I stumbled upon some less-used status of the INETNUM object, namely LIR-PARTITIONED PA & LIR-PARTITIONED PI. Since there is no difference in the docs (https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data…), can anyone tell me when to use PA and when PI? Cheers, Alex -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * 63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net

2 1

Idea: magic mntner for all LIR contacts
by Tore Anderson 03 Dec '18

03 Dec '18

Hi, I'm starting to lose count of how many times I've made changes to the User Accounts list on the LIR Portal, but forgot to update our mntner object to add/remove the corresponding «auth: SSO foo@bar»-attributes. So I was thinking: is this mandatory and error-prone duplication of work really necessary? Wouldn't it be possible to instead have some kind of magic mntner object that is is kept automatically up to date with «auth: SSO»-attributes for all the LIR user accounts? Tore

1 0

Re: [db-wg] IRR and Hurricane Electric and RIPE
by Peter Courtney 13 Nov '18

13 Nov '18

thank you for the advice, much appreciated but all sorted now by Net Solutions Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Re: [db-wg] IRR and Hurricane Electric and RIPE
by Peter Courtney 13 Nov '18

13 Nov '18

thank you Christoffer, I am now well on my way to sorting this out with Net Solutions Europe, we will see what tomorrow brings, thank you for the advice Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

IRR and Hurricane Electric and RIPE
by Peter Courtney 13 Nov '18

13 Nov '18

First Message on here, please go easy as I am learning every day, just recently a number of our customers have been complaining that they cannot get on to various web sites, so I sent an email to HE, and got this reply back Hello Teledesign AS41614 and your BGP Query Looks like you do not have valid IRR entries for some entries. http://irrexplorer.nlnog.net/search/91.204.244.0/24 says "Prefix is in DFZ, but NOT registered in any IRR You are NOT getting routed to the whole Internet. From BGP.HE.NET https://bgp.he.net/AS41614#_prefixes You should have GREEN check mark next to the prefixes. From route-views.oregon-ix.net: route-views>sh ip b 91.204.244.0/24 l | i 1299 route-views> Please ensure all of your prefixes have valid IRR entries. It seems these may be getting filtered by remote networks. Documentation is available here, but you essentially need to create a route object with your ASN as the origin http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html =================================================== could anyone help me find a simple "How To Document" that I can follow and do what HE are asking me to do, or is it something I can ask RIPE to do on my behalf thanks in advance to all Peter ( newbie sysadmin ) Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 2

Re: [db-wg] [Ext] [address-policy-wg] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks
by Töma Gavrichenkov 05 Nov '18

05 Nov '18

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 <leo.vegoda(a)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 >

2 1

Re: [db-wg] Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects
by Christoffer Hansen 05 Nov '18

05 Nov '18

On Mon, 5 Nov 2018 at 15:33, Gunnar Guðvarðarson <gunnar.gudvardarson(a)advania.is> wrote: > That's amazing(ly bad), thank you! True.

1 0

Re: [db-wg] Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects
by Christoffer Hansen (Lists) 05 Nov '18

05 Nov '18

Hi Gunnar, On Thu, 1 Nov 2018 at 15:51, Gunnar Guðvarðarson <gunnar.gudvardarson(a)advania.is> wrote: > What happens if you send signed update A, then signed update B, and then re-send signed update A. > > Does the re-sent signed update overwrite the object? Yes! If you re-send an older (signed) version (A) of an object in the RIPE database. A newer update (B) can be overwritten with the older one (A). The current implementation in the DB does not validate anything apart if the key as allowed or not. Expiration date or if an object has been update since an incoming update message is not taken into account. If the update message is signed with a valid key. It is accepted. (Currently I have only tested this with my own objects in the DB) Christoffer

1 0

Policies and Guidelines for Assignments for Network Infrastructure and End User Networks
by Töma Gavrichenkov 05 Nov '18

05 Nov '18

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

2 2

RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects
by Marco Schmidt 16 Oct '18

16 Oct '18

Dear colleagues, We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", to the Routing Working Group mailing list. The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA. As the RIPE IRR is part of the RIPE Database, we want to notify the Database Working Group. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06 We encourage you to review this proposal and send your comments to <routing-wg(a)ripe.net> before 9 November 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

8 16

Re: [db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects
by Alexander Azimov 16 Oct '18

16 Oct '18

2Robert How does it help to get rid of commercial IRRs? It's only RIPE policy, it doesn't work like GPDR. :) 2Job There is only one good thing about mistakes - if you can fix it. Here if one fails to properly configure ROAs it may lead to ongoing operational problems, that can't be fixed even after fixing ROAs, since RIPE-NONAUTH database is locked. I think, that it's ok to delete route objects that conflict with ROAs only if you are able to create new. Otherwise, the only winning party will be commercial IRRs. пн, 15 окт. 2018 г. в 17:29, Alexander Azimov <aa(a)qrator.net>: > 2Robert > How does it help to get rid of commercial IRRs? It's only RIPE policy, it > doesn't work like GPDR. :) > > 2Job > There is only one good thing about mistakes - you can fix it. > Here if one fails to properly configure ROAs it may lead to ongoing > operational problems, that can't be fixed even after fixing ROAs, since > RIPE-NONAUTH database is locked. > I think, that it's ok to delete route objects that conflict with ROAs only > if you are able to create new. Otherwise, the only winning party will be > commercial IRRs. > > пн, 15 окт. 2018 г. в 17:06, Robert Heuvel via db-wg <db-wg(a)ripe.net>: > >> Hi, >> >> Where can we express our support for this RIPE Policy proposal? >> We think it is a great idea and gets rid of commercial IIRs where you can >> register just about anything which is or is not yours... >> >> Robert Heuvel >> atom86 (AS8455) >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> >> > > -- > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | visit: radar.qrator.net > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | visit: radar.qrator.net

3 6

Re: [db-wg] Agenda RIPE77 - Database Working Group
by William Sylvester 13 Oct '18

13 Oct '18

Dear Working Group Members, Below is the agenda for the Database Working Group for RIPE77. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 20 mins Edward Shryane, RIPE NCC C. RIPE-NONAUTH Cleanup – 20mins Job Snijders, NTT D. Country Code Use in RIPE DB and Extended Delegated Statistics – 20 mins Ingrid Wijte, RIPE NCC E. Discussion: PERSON objects in the RIPE Database – 15 mins Denis Walker F. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Re: [db-wg] PERSON objects in the RIPE Database
by Maria Stafyla 12 Oct '18

12 Oct '18

Hi Denis, all According to Article 3 of the RIPE Database Terms and Conditions, one of the defined purposes for the use of the RIPE Database is "Facilitating coordination between network operators". A PERSON object is meant to contain the (business) contact information of people who are responsible for the networks the Internet number resources correspond to and/or for maintaining the related information in the RIPE Database and the DNS zone contacts. If someone creates a PERSON object that is not meant for one of the defined purposes, this would constitute a violation of the RIPE Database Terms and Conditions (See Article 4.1.). It's also worth noting that PERSON objects that are not referenced in any other object (and thus do not serve any operational purpose) are automatically deleted after 90 days. In general, personal data may only be processed in accordance with the relevant principles. If personal data is no longer required in relation to the defined purpose it was supplied/collected for, then its processing will not be justified any more. However, depending on the information that is inserted when a ROLE object is created, it might contain personal data - this is something the RIPE NCC has no control over. Kind regards, Maria Stafyla Legal Counsel RIPE NCC > Hi Nick, Athina > > Perhaps the RIPE NCC legal team can give us some advice on this issue. > In your presentation at RIPE 76 you said the justification for > personal data in the RIPE Database was for contacting people about > operational issues. If many of these 2 million people whose personal > data is held in the RIPE Database are not contacts, is there any legal > justification for having this amount of personal data in the database? > > Also if 'contacts' can be roles rather than identifiable people, can > we justify holding this personal data simply because, historically, > PERSON objects were used instead of ROLE objects? > > cheers > denis > co-chair DB-WG > > > ------------------------------------------------------------------------ > *From:* Nick Hilliard <nick(a)foobar.org> > *To:* denis walker <ripedenis(a)yahoo.co.uk> > *Cc:* DB-WG <db-wg(a)ripe.net> > *Sent:* Sunday, 7 October 2018, 14:56 > *Subject:* Re: [db-wg] PERSON objects in the RIPE Database > > denis walker wrote on 25/09/2018 23:55: > > So really the only question that must be answered is "Can we justify > > holding this amount of personal data on the basis of contacts for > > administrative and technical issues relating to internet resources and > > network operations?" If the answer is 'no' then change MUST happen, > long > > before the universe dies. > > I.e. "is what we have [...] legal"? > > DBWG probably needs to get a legal opinion on this. > > > Nick > > > >

1 0

remove bogon prefixes in the RIPE IRR NON-AUTH DB?
by Job Snijders 09 Oct '18

09 Oct '18

Dear WG, I'd like to raise the issue of bogon prefixes in the RIPE IRR, and ask RIPE NCC to remove all "bogon" route object registrations from the "RIPE-NONAUTH" IRR database. Today I was made aware of this example: $ whois -h whois.ripe.net -- "-Troute6 2001:db8::/32" | egrep -v "%|^$" route6: 2001:db8::/32 origin: AS25375 descr: AS25375 mnt-by: ch-stafag-1-mnt mnt-by: LEUNET-SECURITY-MNT created: 2018-08-25T15:27:50Z last-modified: 2018-08-25T15:27:50Z source: RIPE I'd consider the following prefixes, and any more-specifics of these to be bogons prefixes: 0.0.0.0/8 # RFC 1122 'this' network 10.0.0.0/8 # RFC 1918 private space 100.64.0.0/10 # RFC 6598 Carrier grade nat space 127.0.0.0/8 # RFC 1122 localhost 169.254.0.0/16 # RFC 3927 link local 172.16.0.0/12 # RFC 1918 private space 192.0.2.0/24 # RFC 5737 TEST-NET-1 192.168.0.0/16 # RFC 1918 private space 198.18.0.0/15 # RFC 2544 benchmarking 198.51.100.0/24 # RFC 5737 TEST-NET-2 203.0.113.0/24 # RFC 5737 TEST-NET-3 224.0.0.0/4 # Multicast 240.0.0.0/4 # Reserved ::/8 # RFC 4291 IPv4-compatible, loopback, et al 0100::/64 # RFC 6666 Discard-Only 2001:2::/48 # RFC 5180 BMWG 2001:10::/28 # RFC 4843 ORCHID 2001:db8::/32 # RFC 3849 documentation 3ffe::/16 # RFC 3701 old 6bone fc00::/7 # RFC 4193 unique local unicast fe80::/10 # RFC 4291 link local unicast fec0::/10 # RFC 3879 old site local unicast ff00::/8 # RFC 4291 multicast Any route/route6 objects covered by the above prefixes should be deleted from the database, and the software should be extended in such a way that nobody can register new route/route6 objects covered by the above list. Kind regards, Job

8 10

PERSON objects in the RIPE Database
by denis walker 07 Oct '18

07 Oct '18

Colleagues, I will start with a blunt question, then give some arguments for my concern. In May the RIPE NCC told me there are more than 2 million PERSON objects in the RIPE Database. That is almost 25% of the objects in the database. Who are these people and why do we hold so much personal data? At RIPE 76 the RIPE NCC legal team gave a presentation on GDPR and the RIPE Database. The basis of that presentation seemed to be that Article 3 of the RIPE Database Terms and Conditions defined one of the purposes of the database as: Facilitating coordination between network operators (network problem resolution, outage notification etc.) It was argued that this justifies the inclusion of personal data in the RIPE Database so that these people can be contacted in the event of network operational issues, even by people who have no business relationship with these contacts. But this Article makes no mention of 'personal' contact information. It was also mentioned that some personal data is included for policy reasons. The IPv4 Address Allocation and Assignment Policy makes a couple of references to contact data. In 4.0 Registration Requirements it says: All assignments and allocations must be registered in the RIPE Database....Registration data (range, contact information, status etc.) must be correct at all times This clearly associates contact information with the necessary registration. But this does not specify that it has to be 'personal' contact information. In 6.2 Network Infrastructure and End User Networks it says: 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. This clearly has the intent of avoiding the need to enter 'personal' data as contact information. In the IPv6 Address Allocation and Assignment Policy it is even more vague saying in 3.3 Registration: Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws. 'Reference' information and concerns about privacy again clearly indicate that the intent is to avoid using 'personal' data for the contacts. This does raise a number of questions: -Should I believe that we really do have more than 2 million individual people in this region who can seriously address technical or administrative questions on Internet resources or network operational issues? -Why is it considered necessary for contacts to be identifiable people rather than roles? -Abuse-c was intentionally designed to reference a ROLE object, which no longer needs to have any referenced PERSON objects, to avoid the need to enter personal data, why can't technical matters be addressed in the same way? The purpose in the Terms and Conditions may define a reason for holding contact information, but it doesn't justify this level of personal data being held in the database. Perhaps it's time to review what is meant by 'contact information'. What is really needed to satisfy this purpose? For example, why do we need an address for a technical contact who may need to be contacted in the event of an operational issue? No one is going to go to that address or post a letter. As always your thoughts and opinions are welcome... cheers denis co-chair DB WG

4 7

Re: [db-wg] WG Chair Selection - Call for Discussion
by William Sylvester 05 Oct '18

05 Oct '18

WG Members, Congratulations to everyone on the success of NWI-5! With the deployment behind us and everyone back from holiday in August we are moving to the next step in our chair selection process. This email opens the two (2) weeks of chair selection discussion. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. The candidates are as follows and have either made their interest known on this mailing list, or directly to the chair(s). I encourage each candidate to reiterate their qualifications to the mailing list. Piotr Strzyzewski Sean Stuart As members of this working group please discuss your approval or otherwise of each candidate. Best regards, Denis & William DB-WG Chairs

4 3

"key-cert" objects - emails listed as "owner" even thou id has been revoked
by netravnen＠gmail.com 03 Oct '18

03 Oct '18

Hi db-wg, Was updating my key-cert object in the database. And was wondering if it is by design revoked key id's is listed as owner of the key? (I would normally expect revoked id's not being listed inside key-cert objects.) The Explanation =============== I have several gpg id's as part of the key. Half is active. Half is revoked id's. All id's; even the revoked ones; is being listed as "owner:" when viewing the key-cert object in the database. -Netravnen

2 1

alloclist.txt
by nusenu 01 Oct '18

01 Oct '18

Hi, before I start parsing the alloclist.txt [1] file (with multiline context) I was wondering if there is a more parse-friendly version of that? (one record per line?) thanks, nusenu [1] https://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2