Archives

DATABASE WORKING GROUP SESSION.
14 May 2015
4:00 p.m.:

CHAIR: Hello Database Working Group. Welcome to our session. If I may ask that the people in the back, please come a little bit to the front, join us here, let's make is a cosy tight‑knit group.

Thank you very much for attending this super exciting session about one of the most fascinating pieces of software in the history of the internet, the RIPE database. Let's get on with our agenda.

Second item, select scribe, we hereby appoint Nigel as our scribe. Thank you, Nigel, much appreciated.

If we're going to do an applause, everybody should join in, Nigel, thank you.

(Applause)

We need to finalise our agenda. We published the agenda a few days ago on the site. Is there anybody in the room that disagrees with the items we'll discuss today? Is there anybody that wants to add an item to what we discuss today? Nope. Excellent. I declare two minutes left.

Nigel, I'm going to give the microphone to you because you are going to review our action list.

NIGEL TITLEY: Thank you. As usual, a quick run through the actions.

RIPE 67, these date from two meetings ago. To be quite honest, I couldn't remember where we had actually discharged this last time or not so hopefully we'll get that sorted out now. So 67.4, this is on Wilfried to take the issue of geolocation RIPE NCC Working Group as it doesn't seem to be heavily used. I think this has actually been done or rather it's been subsumed into another action point where the RIPE NCC Services ‑‑ which the RIPE NCC have picked up. So I'm suggesting that discharge this one, I don't know if anybody wants to disagree. Okay. Good.

67 .5, to check that the anti‑abuse Working Group is prop recall specified both what should be done with mail that's sent to the abuse contact and possibly it's form amount of again I think we have had a response back from the abuse Working Group... I think the responding was get the abuse contact sorted out and then you'll decide what to put in it.

BRIAN NISBET: There is obviously the ‑‑ there is some stuff about abuse, but the basic one on this at the moment is leave it with us, we'll get back to you. So you shouldn't be ‑‑ I think... yeah, we haven't done that yet, so I think it's now our action point in anti‑abuse rather than yours in database. My recollection of the agreement from London or before was, so...

NIGEL TITLEY: That's fine, so we can close it here, and ‑‑ Rudiger wants to differ.

RUDIGER VOLK: As long as someone who is supposed to supply a mail address for a function is not told what the function is supposed to be, I think that is a farce, is should not be done this way. I cannot tell my customers what they are supposed to do there. I cannot, in my large company, I cannot tell which department actually should be directed.

NIGEL TITLEY: Exactly. So turn around, point to Brian and point that at him.

BRIAN NISBET: I think there's some fairly simple answers there, but, no... that's so noted, we will raise it and we'll take it. I mean, it's a thing that's there, we know we need to do it, it just hasn't been done yet.

NIGEL TITLEY: Bring it back to us when you are finished with it. Thank you. That's two down. 67.6, bring to the attention of the Routing Working Group the fact that the Routing Group data as recorded in the database is generally very poor. This has also been subsumed into another action point which we'll see later on so I think these three are actually gone, which is nice.

68.1, on the RIPE NCC, remove the referral by attribute. We probably have a presentation on this, yes, we do, okay. So that's good.

69.1, we're back to just one meeting ago, RIPE NCC. To produce a self contained document describing the migration of the changed attribute to the last modified created attributes. Have we done that yet? We have, excellent.

And 69.2, come up with some straw man proposals for displaying history for objects where available. This was I think generating history where there is actually history in the database but it's not necessarily visible. I haven't seen anything on that, but that's possibly because the minutes were only published about three days ago. Right. Can we say that's ongoing or do you want to address that? Tim?

AUDIENCE SPEAKER: We can take that on board, that was on my radar actually. But I think that refers to objects that have been deleted, so the history isn't normally visible for them and there's a question whether those objects should be shown in history.

NIGEL TITLEY: That might well be, okay, so you'll column up with some sort of straw man proposal which will appear. Okay, that's fine. That action is ongoing.

And finally, 69.3, to examine and report on possible solutions to improving geolocation data in the RIPE database. Again that's another ongoing one I suspect. Yes, okay, right...

And I think that's it. So, I shall pass it back to Jaop.

CHAIR: Thank you very much, Nigel, for going for through the action lis. Our next speaker is the infamous at this moment.

TIM BRUIJNZEELS: Thank you. Operational update. I'll try to keep it short. Some statistics to start with. We get a lot of queries through the database, many for queries than updates, it's not really unexpected. I have some statistics here on the type of updates that we see. The majority of updates goes through the sync updates mechanism by ‑‑ using passwords. Mail updates have very common as well. We're about 75%, well, three quarters use passwords the rest abuse BGP, almost nobody uses X 509 certificates for this. And the rest interface and web updates are going through the same, well, the web updates use the interface as show up as one thing here. People use mostly passwords there as well. I'll get back to that in another slide.

Then, the release candidate environment we have had it for a while. New releases are cryptically ‑‑ well, are deployed here unless it's a bug fix. Normally we would use a period of say two weeks in RC, but we can use longer times where necessary, especially when a change is substantial.

After having received some feedback on this, for example, well the next slide has details about the plan for deprecating change. That was communicated, but it's in a labs article, it's on the mailing list, so, what we have just done is we have added to the release notes page a section where we also list upcoming releases as far as we know of them. This is of course subject to change if things come up, operationally or through policies, that cannot change, but it's good to have an idea of what's coming.

Also, I will talk a bit more about plans we have to make the user interface better. We think that the release candidate environment is also very useful for this so we would like to deploy changes there even though they are changes to the core WHOIS, it's good a public instance where people can look at the interface and before we deploy it to production.

Then, release is done, since the last RIPE meeting, 1.77 was implementing policy 2012‑07. There were changes in there store resiliency, some support for the release candidate environment and training environments, and bug fixes. We had to roll that back because of an issue with concurrent updates, that wasn't noticed in the release candidate environment. When this happened, we added better tests for this to ensure that it doesn't happen again, so now we actually do a ‑‑ we had functional tests that all the updates work, but now we also do bulk update testing. Also, some dry‑run option was added to the RIS API, it was useful for everybody but we also use it when we do updates from web interface to say verify an update is valid before ‑‑ well, for validation essentially.

Most recently, we have had deployed Phase 1 of deprecating change and referral by. Through RC, we didn't deploy this through production because in our CD we noticed a problem. RC is good for that. And that was that fixing of the leaved objects ‑‑ sorry, the deletion of objects wasn't working properly, when last modified and created were not enabled because, you know, in our implementation we actually figured out that yes, we can started adding these attributes to you all the objects but it takes quite a while before they are all there. So we had to do multi‑phase thing where we first deployed a new version of the software and after the while when the attributes had been generated we would enable them in the output. And when you delete an object you need to submit the object. So it was kind of confused about what are you trying to delete. So that was fixed.

And we had to also implement another business rule for ‑‑ that would allow publishing of sponsoring org for legacy resources. That was required by policy. Unfortunately, we still found and issue after we deployed production and that was not noticed by us, but not reported by anybody else either in RC which was that normally when you submit an object unmodified, it should be an no op, so there is nothing happens, but in this case we were not ignoring degenerated attributes properly so the last modified value would be updated and, therefore, a new object, new version of the object would be created. We fixed that. What we still have to do is look at history and find those instances where only the last modified attribute was modified because it's essentially not an interesting change. And receipt actively fix those, so that's what we plan to do. I think that's it for this part. I mean, there is more on the details of the referral by and changed deprecation in the next slide, but maybe there are other questions at this point.

AUDIENCE SPEAKER: Peter Koch. On your slide number 2 you gave the breakdown of the database statistics, and mentioned the updates. In relation to that changed last modified discussion that we had, do you have an idea or you can freely point me to the website somehow, how many of these updates are no ops or how do you count them here?

TIM BRUIJNZEELS: I think these are all the updates. They should include the no ops, yeah.

There is no jumping up and down, so I think this should also include the no ops, any kind of update.

CHAIR: Think other questions for Tim?

AUDIENCE SPEAKER: Did anyone notice that 74% there, of e‑mail updates are done with a password? Is that a bad thing?

CHAIR: You tell me.

AUDIENCE SPEAKER: Is that responsible behaviour? Should the NCC allow that?

AUDIENCE SPEAKER: That's clear text passwords is right. I just wanted to say that ‑‑ I think that's not the best way of doing it. We should actually start to try to maybe propose something and take clear text passwords away from ‑‑

CHAIR: So 74%, that means that this group of people is doing the right thing but you guys...

AUDIENCE SPEAKER: I think this is so. By the way, is there any way to do SSO other than web?

TIM BRUIJNZEELS: No, not currently.

AUDIENCE SPEAKER: I do think that clear text passwords in e‑mails are not a good idea, so, we might want to put that in an action point to discuss for ‑‑ another method of or taking it out. Let's just take it out.

TIM BRUIJNZEELS: I think the sync updates and rest updates use HTTPS so we have channel security there. But with mail, and TLS ‑‑ somebody will correct me I'm sure ‑‑ I think it's a lot more likely that it will fallback to clear text even if you have stuff set up, it's stuff can go wrong in the chain as far as I understand, that's a problem with mail and ‑‑ yeah, TLS. But... but you know I'm looking at the Working Group here as well, personally I would think it's not the best security practice, but obviously it's a large enough amount of users that cannot change it lightly.

SHANE KERR: So, I think it's important, I said this I think a few times on the mailing list, that when we're discussing passwords that we keep in mind the whole context here, right. We're not talking about mailing around bars of gold, right. We're talking about entries in a database which has a full history which can with be revoked and rolled back, right. And I think we also have to understand that security, as always, has a cost, and the cost in this case is that if we make it difficult, people are just going to say I'm not going to keep my information up to date because it's a pain in the ass, right, so, I'm not arguing necessarily against it, I just don't feel the strong tins burning desire to get rid of this method because I don't think it causes that much harm and I think if people want to maintain their data this unless we have evidence that it's really causing a problem, maybe it's not a thing. I would however think that we might want to pursue the RIPE NCC changing policies for maintenance of of data that has been allocate bid them. I'm not a RIPE NCC member, so, I can really enforce that, but I think that's a reasonable thing.

AUDIENCE SPEAKER: Peter Koch, on that very point as well, so let's please not play games with statistics here. 74% of the 20% that use mail at all, so, that's one thing. And of course, yeah, yeah, I'm against terrorism and passwords and should die and so forth, the message is clear here, but to really assess the risk, the risk for the system recollect the risk for the users, Tim already mentioned one would have to look at how many of these connections are TLS protected and in brackets, single hop, if you can determine that, but looking at the TLS part would be good. And ‑‑ because lots of the mail traffic already is TLS protected and of course it would be great if there was deign, deign for STP which might suddenly help people as well.

Just as an observation and suggestion, passwords are bad, but they are not the worst thing in the world.

CHAIR: We're closing the mike on this particular topic after the two of you are allowed to make a brief and concise statements.

AUDIENCE SPEAKER: Vasha Pollok. Just a very quick question. 95% are actually using passwords are using the sync update. That's really a lot. And I was wondering, are new maintainer objects still allowing passwords? Or is that something that we could change, at least start from now? Or the update ‑‑ but mail would not be secure. Even the 74%, are just too high I was wondering if it's something to discuss to have new maintainer up takes only with the signature?

CHAIR: I don't think that's possible at this moment. Because, there is no feature parity with the API if you do not have a password.

AUDIENCE SPEAKER: Wilfried. Just very briefly from a technology and security point of view, I would probably say passwords should go pretty soon but looking at the general user environment, what are we going to replace it with, with single click, Facebook, Twitter, whatever, log in to be accepted as an SSO ID? I'd rather stick with passwords, thank you.

CHAIR: Tim?

TIM BRUIJNZEELS: Next slide, please

So, new functionality and ongoing work. First of all, the referral by and maintainer. That should say 179.2, but referral by is now optional in maintainers and everybody's advise is to stop using it when creating new maintainers.

In the next phase, which is planned for release 180, we plan to remove referral by all together. The idea is that this will go into RC by the end of this month, it should be just about ready now, but I want to be sure before we put it out there of course.

And we proposed earlier a fairly long period for RC here which is to do with the next slide. Because, whereas the removal of referral by is probably not very controversial the project so replace changed with last modified and created has a bigger impact.

The first part of that has been deployed. So created and last modified are now added to each object.

And the next phase, which we will deploy end of this month, would mark changed as optional so you can still include it, but be prepared that it may not be there for all objects, especially when you are passing objects. And since this may cause issues for people using objects in automated tool chains, it's really advice to everybody to take a good look at the release candidate environments because we don't see a whole lot of traffic there in terms of numbers, but please be advised because once it goes completely, you'll, you might see issues in production.

The third phase for this project is planned for ‑‑ well, to be implemented immediately following the second face essentially. Technically, what we need to do on the database side isn't all that complicated for this but because of the long RC period, we want to deploy this Phase 3 where we actually remove changed all together, and disallow submitting it immediately after.

So, as soon as Phase 2 goes to RC, stays there six weeks and then we deploy it to production, then we can deploy Phase 3 in RC and six weeks later again, we can deploy it to production.

There's a question here, do we really need six weeks? I think that we actually suggested it on our own initiative, and personally, I don't have a problem with using six weeks, but the question is given that we don't really see a whole lot of traffic on RC, is it really useful to use a time that this is, you know, a period this long, because in effect, it delays things, as is shown here. Maybe you can get back to that at the end of the presentation.

Other things: This was brought up on the mailing list as well. The RIPE NCC is planning to stop enforcing the organisation name in the description line of independent resources, but we need to do some work before we're there. A little bit of background here is that, well, historically, there was no org used in these objects, so we started including the organisation name in the description line as a way for people to know who the organisation was. But, since recently ‑‑ well, the org was added and then there was still a problem because references could be changed and names could be changed. But since recently, we have actually put business rules in place to prevent that independent resources that the organisation pointer is changed and that the name of the organisation itself is changed. This can still happen in case of transfers and all that of course, but because we need to ensure that the registry is accurate, we just need to be in the loop. So there is a process for that.

We are currently still working on the clean‑up of remaining objects. We have most of them done by far, but I think we are ‑‑ so out of 10k objects, I think those were old nums, and we have 8k done of those, so, we expect that in the summer it is completely finished and when that's done we can stop enforcing this. Unfortunately, we kind of need it until then to know where we are in this clean‑up process, so we want all information available, so I'm asking, please, a little more patience but we're really working on it.

Then, this was essentially in a slide deck at the last meeting well and we have been doing some work in this regard, it's not made it to production just yet, but we're busy on the background. We believe that the usability of the database is a big issue for a lot of people, maybe not so much the people in this room, but for example, I went on a database training course as well recently, and, well, the first three hours of that course was essentially spent on getting people to set up a person, object and a maintainer, and after that time, people are really tired, and they don't even get to, you know, really understand the more advanced topics like what is this database good for and what type of information should be put in there. So, we really think there's a lot to be gained by making the interface easier for people out there who use the database incidentally.

And we have some statistics of well managing authorisations, we see a lot of clicks I have lost access to my maintainer and some of that will be due to the fact that maintaining your maintainer is actually not easy. The reverse, setting up your verse DNS, we get a ticket a day, so, that's quite a lot.

Now, another subject, business rules, also came up on the mailing list. We're actually mapping out all the business rules that we have, and we plan to publish this very clearly later when we're ready.

But essentially, business rules are things that are enforced on updates, but they are not really part of the database schema, so it's not like an attribute is mandatory or optional, it's not like that black and white in general, but there are certain conditions where something needs to be enforced. Like, for example, that those resources allocated or assigned by RIPE NCC, that the organisation name cannot be changed.

So, this is a useful way of doing that. And we are actively using them when it comes to end user resources and also legacy resources that are registered with us, the typical model is that we have shared maintenance, so we have a maintainer for the RIPE NCC that prospects certain aspects, and the remaining aspects attributes can be updated as normal by the usual maintainer on this object.

There was a question about the Legacy maintainer that we added for this purpose, that was resources that are registered on a contractual relationship with the RIPE NCC, so not all Legacy resources in general, it's a joint maintainer again, so we have just added our own, and the main thing it does is that it ensures that the organisation, the org ID is not changed on the object, on the resource object and the name of that organisation is not changed.

Then another thing we'd like to do, and I'm not sure, I did mention this to some people in person, but as you may know for LIRs the organisational objects and allocation objects are maintained by RIPE NCC, but we actually believe that this is joint maintainer model Legacy holder much better here as well. Because if you look at the slide is intentionally messy, the top of it, that's how an LIR updates their organisation object, so you need to log into the LIR portal, you need to change for example you can change your postal address, and that will be reflected on your organisation object. And if you want to change the list of admin contacts you need to go to the section where we have LIR contacts and Nick handles that. For other things you need to go to an object editor and choose the attribute you want to change and update the value. And well for allocations, there's also an object editor.

In general, these are the web interfaces in this case, but you can use other updates mechanisms of course for these objects. The point is, if we had a shared maintenance, people could just use these normal mechanisms to update these objects, we would have no need for all these special cases. It would be ‑‑ would have business rules to protect what needs to be protected. We would report clearly if you would submit something through, say, sync updates or e‑mail updates, that conflicts with one of those business rules, we can explain why this is. On this specific instance for example, if you wouldn't be allowed to change your organisation name here because of some restriction, we can show you and we can tell you if you want to do this, then please follow this process so you know, talk to us about changing your name for example.

So, well this is the basically it in bullet points. We think there would be a lot of gain there. Also, it would allow for some simplifications going forward, for example allocation objects, everybody now has MNT lower, MNT routes pointing to their own maintainer which is fine but the mechanism is generally should only be needed when you want to delegate to other maintainers, so if you had your own maintainer on the allocation object itself you may not need this, only if you really want to delegate to others.

Okay. That's the idea where we'd like to go, but getting there takes time obviously, we need to do stuff in the interface, and also there is a question of well which maintainer should we then add instead? Well, de facto, today, it's the LIR portal users for an LIR who have access to these objects, so it would be would make sense to let these users choose which maintainer to put as the MNT by on these objects when we are ready to go to a new mechanism.

One option there could also be to have a default maintainer for LIRs which would make it easy especially for new LIRs. As you may know, there is managed user section in the LIR portal, where you can add or remove SSO accounts. It would be fairly trivial for us technically to generate a maintainer for that as well that you may want to use, but, we don't really ‑‑ it should definitely be an opt‑in thing, so, I'm just saying that's one option.

But in general, maybe, the MNT ref for your organisation makes more sense. The thing is it's the LIR portal users that are authorized to make these changes today, so if we are going to migrate away from it it would also make sense to let those users decide which maintainer to use in the object instead.

I am stressing this because I think it will really benefit users but it the also benefit us in terms of the interfaces that we need to build, they can be a lot more generic, it doesn't really matter any more whether an LIR is accessing the database or a non‑LIR.

And that brings me to the questions slides, or comment...

CHAIR: Thank you very much for your update Tim. Elvis?

ELVIS VELEA: I used to work there as well and I remember seeing many, many people, many customers, LIRs, not knowing how to update their organisation object, because they used to update any single object by using the RIPE database tools, whatever. Now, there is a special case that the org can only update from the LIR portal and the same with the allocation, but not the PI assignments, not the root assignments objects, etc., etc., etc. With this business rules now, I think it would be a very good idea to allow the user or the LIR to maintain their own data. So, do give them the maintain by of the org object, of course you are not going to allow them to change the ‑‑ the net name in the allocation, although I don't even know why we have rich ID update. I'm forced in net name, but that's another discussion.

Allow them to change their data by using the maintainer and not the object editors, because we're only using the object editors for two types of objects, right, allocations and organisation objects.

TIM BRUIJNZEELS: Okay. Yeah, this was mainly about the general direction, because I think we need to ‑‑ when we add business rules, we need to think about exactly what is allowed and isn't allowed and that needs to be clear then. But that's another discussion. I'd like to hear first, like thank you for your feedback, that if you group agrees with the general direction, because I think that's the most important decision to take, and then we can look at okay, currently users can modify these things, there are some things in there that cannot change, and maybe you should just be allowed to. But that's a different discussion.

ELVIS VELEA: Second thing I wanted to say is, the business rules should be very clear. People should know where these business rules can be found so that they know what they're allowed to and what they are not allowed to modify. Right now this is not published anywhere. I didn't even know that you guys no longer allow the organisation object to be updated if it's reference in a resources.

TIM BRUIJNZEELS: The name ‑‑

ELVIS VELEA: The org name. What have the org name was a typo and the user wants to change, modify the typo. It will have to be to the RIPE NCC and tell them, hey, there is a typo in this org object.

TIM BRUIJNZEELS: Yes. But I mean they would have already gone through that process earlier. So, that would be a typo that wasn't caught earlier.

ELVIS VELEA: Exactly, that was not caught while the resources request was evaluated. And there is one other thing that I wanted to talk to you about and that's about Legacy, you have added the maintain in the Legacy blocks which basically no longer allows ‑‑ so let's put this hypothetical, it's not hypothetical, I have bumped into this problem, an IPv4 Legacy allocation, the user has created Legacy blocks underneath it, so assignments, although he was not allowed to create assignments, he had to create them as Legacy as well, and then he wanted to remove them and was no longer able to because he was the maintainer of the large block, and not the small block, but it was not allowed to delete them any more, right?

TIM BRUIJNZEELS: You want to say anything about this?

ANDREA CIMA: I'm not sure ‑‑ we can have a look at this case you are talking about, but as far as I know, the Legacy, RIPE NCC Legacy maintainer is added only in resources for which the Legacy holder has chosen to enter into a contractual relationship with the RIPE NCC. That maintainer is added as a co‑maintainer, meaning the resource holder is full maintainer of the object and can do whatever they want to the object. The RIPE NCC maintainer on there is there to be able to see if the legal name of the organisation, meaning the organisation object of this resources, changes. Because if you have entered into a contractual relationship with the RIPE NCC we have to ensure that we continue having a contractual relationship with that organisation. That the the only case in which this maintainer is added and the moment the Legacy holder decides to cancel the contractual relationship with the RIPE NCC, that maintainer is removed. So, that is the only case. It's not to stop people from creating more specific objects.

ELVIS VELEA: Okay. So, actually ‑‑ let's take this off line.

CHAIR: Any other questions, remarks?

AUDIENCE SPEAKER: Remarks. Ruediger Volk. Tim, in the early part of your presentation, you mentioned, and I think kind of raised a question about low use of release candidate. You have to understand that actually doing tests requires resources and potentially preparation and scheduling of resources, it would be extremely helpful if we had some advance idea about when we may need the resources.

In my current case, I really have to say the 179 thing collided with a really major changes on my side, and the intermediate surprising change of a dataset kind of increased the complications. So, that could help and offer all, I think in general, there probably is only a very limited number of parties that actually have the resources and apply the resources to testing.

TIM BRUIJNZEELS: I understand that, but I still would urge anybody to do tests and do tell us when you find issues.

Also, with regard to the planning, you also mentioned this to me in person, and yes, we do have an labs article and it went to the mailing list, but only one thing I want to say about this is we have now added a section to our release notes page where we say this is upcoming. It can still change but I hope that will help people plan.

AUDIENCE SPEAKER: My name is Raymond from RIPE NCC. Can you go back to slide number 10. My question is with the audience present here, how many of you use this interface? Can you raise your hands? Thank you.

TIM BRUIJNZEELS: Maybe I should introduce John actually, he is our now employee who is an expert in user experience, so he is working closely with us on improving the usability of these things, so, if you have concerns about usability, please talk to him.

I think then the next slide deck.

Okay. So, we have talked about this before. Let me go through this really quickly, we'll see if there is questions about it, if it's too quick.

Why do we want this? Well, we would really like to improve, make is easier to set up a personal object in a secure way and manage your credentials in one place, we also believe that there is a benefit to be had in auditing when a maintainer can refer to a person, because right now, we can see which maintainer updated an object but we don't know who it was. That is something we could show to authorise people, would be very interesting to them, because we do get questions about that.

Also, it can make for a more intuitive way of authorising people in an organisation, because more admin context and tag context we do refer to persons.

How could this work? First of all, none of the changes here would impact existing maintainers, everything there would still works. But what we would do is extend the personal object with the option to have multiple off lines for the current authentication method such as SSO, BGP, password even. We would extend this person MNT by ‑‑ that's a proposal here, one way to do it, with a key word "self" so indicate that this person can actually maintain itself by the credentials listed on this person.

Maintainer, can then be extended that the off attribute in maintainer can refer to a person in addition to the existing mechanisms. Why MNT by itself? Well, this allows for a strong one to one relationship between a person and an SSO account. For example, I mean these are in effect the same people. To establish this association, one would need to have access to both, or, you could create a new person object from an SSO account, for example. The benefit is that we can give one interface say, on access.ripe.net where you can create an SSO account and you can have a simple checkmark that says also create a personal object for me and maintain it or some way of saying, well, I have an existing person object and I can authorise against it, so please bring these two things together now.

Furthermore, if we do this, then we currently have about 2,000 maintainers I believe, it still goes up everyday because that refers to SSO contacts at the moment. Once an association is made between a person and an SSO account, and maintainers maintain themselves as they typically do, then the SSO account that was authorised for such a maintainer can also update this maintainer to refer to the person object instead. So this can be an elegant way to also clean up existing data. In my opinion, painless and it would be by an account that was already authorised for this maintainer. So, there's no special hack going on here, except that we would make the flow easy.

It has also been discussed on lists, and suggested what been persons that are maintained by others because some organisations will generate person objects for their staff. Well, we can of course discuss more, but in my opinion, we should not allow credentials on objects that are mentioned by other people, because if we say this is a person, then that person should maintain their own password, BGP etc., I don't get my password set for me by my IT department, maybe when I first joined, but after that it's up to me to change it.

So, because if we do allow this, I think that makes it a lot more difficult, and I think it makes it less useful, to be honest. But, what I would suggest instead, is that we have some kind of invitation mechanism, you can think of scenarios where you can let me set up, initiate the process, but contact a real user out there and allow them to finalise a process.

Open issues that were also discussed on the list. What about removing off lines from persons that are used in an authorisation context? I agree that we should probably prevent this by having a business rule in this case that the last off line cannot be removed from such a person object until that person is actually not used in a maintainer context any more, or as well as an authorisation in a maintainer context.

If you want to stop doing this, then first make sure that you know, you're not listed as offs ‑‑ as an authorisation ‑‑ let me rephrase that. Make sure that the person doesn't appear any more on any maintainers in an off line, then it should be safe to remove the credentials from that person as well.

And that brings me to questions...

CHAIR: Thank you Tim.

AUDIENCE SPEAKER: Pierce. Just a question, do you think it will be useful to extend that to the roll out, just to be a group of person from which at least one has authentication audit outreach. If like, could just put one row maintainer as a reference to the bunch of guys who have having their own credentials, BGPs, passwords whatever, do you think it would be useful?

TIM BRUIJNZEELS: Personally, I think that maintainers already tend to ‑‑ I'm not so sure personally that you would need an extra layer of an additional roll in there, I mean, it would be useful if you want to use that role for different maintainers. Right.

AUDIENCE SPEAKER: The point is that I want to have a single place in the database where I point my colleagues, the group of people, that is the role object, and I don't want to keep in mind that when someone leaves my team, I have to update both roll object and my timing object.

TIM BRUIJNZEELS: I'd say, technically, it's definitely possible, so, you could say allow role as well, but then we would have to do some additional checks to make sure that there is at least somebody on that roll that has, you know, authorisation, because ‑‑ and the question then is should everybody in that role have that or just one person? So technically I think it's possible, yeah, sure.

AUDIENCE SPEAKER: Thank you.

AUDIENCE SPEAKER: Ruediger Volk. Well, okay, I understand the maintainer as the object that has credentials will be usable without any restriction, okay. I'm quite certainly sceptical about adding other things, but as long as the existing mechanism still can be used, that's fine. In the early part of your presentation, you made the remarks about this is going to help answer the question who has done something. Kind of of, that's a question that has come up to me quite a number of times, but kind of actually the question that I would ‑‑ that I have, is slightly different. My question typically is: Which credentials have been used to install a certain version of an object or which credentials are used, well, okay, actually the e‑mail address would be nice to know, of the guy that triggered a database warning to me that someone has tried to fiddle with objects that are under my control and not on the other parties. Well, okay, we know often this is just fat fingering, no bad intention, but well, okay, actually helping what's going wrong would help a lot if we have it and for the database and for understanding the quality of items in the database actually recording what credentials was used for a certain version would be helpful and it could go very easily, I think, into a recorded metadata field.

TIM BRUIJNZEELS: Okay, thank you. I think that the maintainer currently is quite anonymous so it's difficult for us to ‑‑ well, we don't really want to show you which password hash was used for example.

RUDIGER VOLK: Well kind of you know which maintainer object had some matching key, so you know which credentials was used.

TIM BRUIJNZEELS: That's what we know, but we don't know which user of maintainer did it.

RUDIGER VOLK: If the user was an e‑mail coming in, you probably have an e‑mail address. If you have someone using a checked account, you also have the information, and yes, the mail that gives me the warning, tells me which strange dial in IP address is used, which of course is useless.

TIM BRUIJNZEELS: Yes, but most updates ‑‑ you do realise most updates use passwords and cannot just tell you this hash was used to try to update.

CHAIR: Come on, why not?

RUDIGER VOLK: No, no, the password matched some maintainer, as the maintainer is the credentials.

TIM BRUIJNZEELS: Yes, but if the password doesn't maintainer but another one, I don't think we should go there to be honest ‑‑

JOB SNIJDERS: I have to cut this short because of scheduling constraints. Rudiger, please raise this issue on the Database Working Group mailing list, and I will try to figure out a way ‑‑ I think you are looking for sort of activity log. Then you definitely need to e‑mail to explain what it is we need.

ELVIS VELEA: Can I also say two words on this? You have an IP address ‑‑

JOB SNIJDERS: I'm sorry, we're ten minutes behind on schedule right now so I'm going to really enforce a tighter grip on the schedule now. One question.

AUDIENCE SPEAKER: A question from the remote participants, Denis, he made the comment you must include role objects in this otherwise you are encouraging objects to be maintained by individual people who may leave a company and that has been a major problem for the last 50 years.

JOB SNIJDERS: Thank you Denis. Thank you Tim for presenting this. Can I have a round of applause.

(Applause)



PIOTR STRZYZEWSKI: Hello everybody, welcome. I will give you a short presentation about last few proposals that have been posted or sent to the mailing list as even from my point of view as a private person.

There was a few of them, first one was made by me, INET(6)NUM to the different status, then there is a proposal about clean‑up of some hacks with status values. UTF‑8 in the database. Make phone number optional in the person objects, and the last one on that list, clean‑up historical abuse mail locks attributes. There is also one more proposal, but it will be described by the proposer, so it will be the next point in the agenda.

So, the first thing, there is a kind of a problem that it's not possible to put into the database two either INET NUM 6 or INET NUM with the same space with different status, this leads to a situation where for example a small company gets the last /22 allocation, and then this company wants to put exactly under that allocation, just a /22 assignment and it's not allowed to. It has to be split to at least two objects. That's something which is problematic and because of the strange responses from the robot who is not allowing to do so, I have seen a number of comments from my friends that why I cannot do that, then I have to respond to them just two objects and so on. So I propose to deal with that.

However, there was almost no feedback except for I think it was Gert who tells me that INET NUM value, it's the key for that object, and he is against combining that with the status value. So, because there is a lack of any feedback for that proposal, I will probably forget about it as an a proposal. There is a comment from Rudiger

RUDIGER VOLK: I think the database model less impacted if you propose to actually allow multiple value status.

PIOTR STRZYZEWSKI: That's a good idea and it's very connected to the, this idea by Tim that we can, proper maintainer maintain our own allocations. We'll move that the that the database mailing list.

Next thing, there is, also by me, a proposal to clean up some hacks with the status values. They are existing right now in the database to satisfy the schema. However, those hacks are commented to explain the situation, and raising more confusion for some people like me. And there is a ‑‑ this is one of the examples, which I posted also to the mailing list, that although they start to say this is allocated by RIR, the comment says this block was actually allocated by IANA. So, what the hell? There was no feedback at all, as always. And I think because that's just cleaning some hacks, I will ‑‑ if there will be no opposition from the members of the group, I will ask NCC to think about cleaning that and fixing that stuff. There is no, as far as I know, there is no policy or document not allowing us to do so, like a complete list and closed list of statuses or something like that. We can extend that catalogue and this probably will not affect any of your scripts.

So, UTF 8 in the database. This is not a new idea. It was presented by me at RIPE 61 and it was one more time presented at RIPE 66. You can blame me that I was not active enough to push that in the Working Group. There was some discussion about that. There were proposed two ways of dealing with the idea of UTF‑8. The one is putting the UTF‑8 in the present attributes and the other one is put it in the complimentary attributes with the default behaviour of the server controlled by the some attribute ‑‑ sorry some parameter.

And the possible implementation things like person dash IDN or person dash whatever, so, two ideas, to deal with that.

I could see personally that there was a positive feedback for that internationalisation of the database. There was one concern made by the Andy from ARIN that they are using mostly Latin one characters, but ARIN ‑‑ sorry, maybe I should not say that but still ‑‑ ARIN from America, they are having a limited number of characters and we are using a number of them among other 50 or 60 countries in our region. So, we have to deal with the problem.

So, still, I think it's a positive feedback on the list for that. And as always there are two points of view for such a situation, one is that it could help with getting the correct data for low law enforcement agencies because those are from my point of view, one of the biggest users of our database, they are looking who makes the abuse, so they want to know what's the correct name of the company or person, correct address, not the funny translation to a Latin one or US ASCII.

The other point of view is that it could make everything, and I encourage you to post your comments or opinion or whatever concerns on the mailing list and I see that Rudiger has something to say.

Do we have time frame for comments for Rudiger?

RUDIGER VOLK: Keep in mind and verify that whatever strange bit patterns you put into the data does not collide with essentially 7 or 8 bit clean protocols, unfortunately the protocols for accessing the databases have not been standardised and to a large degree not even documented correctly.

PIOTR STRZYZEWSKI: We can move to U, it S 7.

RUDIGER VOLK: Just keep that concern in mind. That's where it would be a path for destroying stuff.

PIOTR STRZYZEWSKI: That's a valid point. And as you can see at the very top of that slide. This is UTF in the database and the next slide is about UTF not only in the database. Do you see this, this is ‑‑ it's a badge of a friend of mine, he was wise enough to remove the Polish characters from his name, but he made how it will look like on the badge with the Polish letters in the company name, and I have no idea from which characters that this was taken from. But, apparently, RIPE NCC have, you know, some strange problems with dealing with that situation because on the attendees list, it's fully with Polish letters, both in the name and in the company name without any problems, so, I don't know what the guys are doing. Do you think it's the printer's problem?

RUDIGER VOLK: Well, okay, if IETF my name got merged with the Exel sheet ‑‑

PIOTR STRZYZEWSKI: So that was just an example. Another one was made by Shane Kerr I think, it was about making phone number optional in person objects and discussion shortly after that tends to the idea about extending that to make more attributes optional. We could do that. But there was a comment by the NCC about RFC 2622 which is about RPSL that in the RPSL on the phone number is mandatory, and I will make a short comment here, that was not ‑‑ I spoke with cafe, that was not to stop the discussion, that was just to remind us about that, we can do whatever we want with the database, we can even go to the IETF and start to change RPSL. But the funny thing is at the very same section about the person object in the RPSL, these are FC, there is also a mention that the e‑mail attribute should be mandatory in our database it's optional. So we are already inconsistent with that RFC which has been pointed during the short discussion time about that proposal.

Next. There is recently was a proposal to clean‑up the historical abuse mail locks attributes. It was made by Dennis Walker who is not here. This is most like a follow‑up to the implementation of Abuse‑C, there was a timeline for that, and I think that the anti‑abuse community declares that the clean‑up should be done, just to have one consistent way of asking the database what's the contact for abuse handling? I know that Rudiger, that you are not sure what department have to be ‑‑

RUDIGER VOLK: Clean it up when we have documentation.

PIOTR STRZYZEWSKI: Okay. So, there is a problem because RIPE NCC maintains two abuse contacts tools, one is abuse contact finder and the other is connected with RIPE stats, they are inconsistent with the way they are. The contacts one is based only the Abuse‑C, the other one is using more sophisticated, I put that in the quotes, sophisticated algorithm.

There is also a problem with Legacy resources holders that so. Community members think that we are not entitled to enforce them to implement Abuse‑C. I'm, as a private person and member of the organisation which holds the Legacy, I think that we, as the legacy holder, should implement the Abuse C because we have that obligation in the document describing the RIPE 605, describing our obligations to the this database. We should maintain correct information, correct contact information and abuse contact information is one of those informations so I'm really don't think ‑‑ however, to deal with that, I make a post on the holders mailing list to raise this issue to their attention because I think some of them probably do not follow the discussions on the database working group mailing list.

And we are waiting for more feedback on that, mostly about this Legacy issues and stuff like that.

Any questions? No. Thank you.

(Applause)

AUDIENCE SPEAKER: Yes, just one note. Robert Kislakieb. When thinking about UTF‑8 you have to keep in mind that it doesn't exist unless you specify the end coding, therefore, you can forget talking about objects outside the database unless you also specify the end coding which complicates things a bit and UTF 7 is even worse.

PIOTR STRZYZEWSKI: The same goes with Latin 1 which is currently used by the database. If ‑‑ I'm deliberately putting some Polish letters in the database, they are screwed up because you think it's Latin 1 and I think it's Latin 2. Come on. It's the valid point right now. Thank you.

AUDIENCE SPEAKER: Lars Lemar from NetNod. You also have the interesting problem of storing stuff in the database is one thing, but when you want to search for something, you have the input locale to take into consideration and it will create an entire plethora of problems, so this is just not turning something on. This is an entire set of problems that we need to look at carefully before doing anything. Thank you.

JOB SNIJDERS: Right. Next up is William Sylvester.

WILLIAM SYLVESTER: I'm here today to talk about my proposal for orphaned objects. Now, in the case that orphaned objects are not in the relational sense, I'm talking about how objects that have an existing maintainer but are basically not maintainable. We have run across several examples where we found objects that have an INET NUM maintainer where they have a routing or DNS objects that are not maintained by the same party. In many of those cases it's block the INET NUM user from updating or changing some of those records. In going through this, we have had a lot of discussion on the mailing list, especially in regards to how a lot of features already exist for non legacy holders who are under contract with the RIPE NCC. Specifically, this relates towards Legacy parties, and what we found is, it's not created equal. Why this happened I think is because for a very long time we didn't know what to do with Legacy numbers. Now that we have some policies that exist for what we can do with Legacy numbers, my proposal is to treat everybody the same. Specifically, we are talking about, you know, objects that are direct relation so I know there was some objections specifically around, I heard an example of someone using an INET NUM and then they had taken, say, a 24 and given a routing object to a third‑party, and they didn't want anything to do with that, that's really a band aid that's a fix for a problem that we can't reflect accurately in the database, the different pieces in regard to you know in that case we probably should have sub‑netted or split the blocks. Today you can't do that through web updates or through some of the other interfaces.

I mean, the net of the proposal is that we should allow the INET NUM holders to maintain their own objects, we should keep a direct one to one relationship with that and as far as the INET NUM reflecting the underlying routing objects, and the general premises is to make the database accurate. So... with that, I'd open any questions or concerns.

PIOTR STRZYZEWSKI: Can I ask a question? So, it's not a question, it's just a note that I also follow my idea about performing the URX holders and community and I post an e‑mail about that to the mailing list, there was only one comment which goes along with your idea that INET NUM should be an automate in place of control for the related objects, so, my advice is let's wait. If there will be more comments on that mailing list, I promise I will make another report, however, I was guided that I have no mandate to represent the view of Legacy holders at large. So, that will be just a report, nothing more, nothing less, that's all.

WILIFRIED WOEBER: Two comments again, first of all, I think at this point in time it is appropriate to treat the Legacy resources registration records differently than the other types. We are right now in the process of actually getting this sponsoring LIR thing going, and during this exercise, we already found a couple of interesting cases in our back yard, where we were probably need the help of the RIPE NCC registration services is get things in line again sort wifi an org object maintain there, so I think we should revisit that after maybe half a year or a year when this whole thing like working through the Legacy resources and having these relationships established when we have the feedback like what are the problems, what are the figures statistically. That's the first comment. The second comment I'd like to say is I agree with your vision or with your goal to have the INET NUM holder sort of being the king and God for the address blocks. But, in some situations, I guess the registered responsible party for this address block will not necessarily be in a position or willing or clued in good enough to do that. So I think there will be quite a few cases where another party like traditionally the maintainer or the future the sponsoring LIR could be needs to be part of the picture. Just a statements. That's my belief.

And following up on that one, I seem to be hearing between your lines on the screen or in your sentences, that that you to advocate maybe, or to imply that in the long run in the database we are going to do completely away with the dual authentication path.

WILLIAM SYLVESTER: That wasn't any of my intention.

WILIFRIED WOEBER: Then I got it wrong, because I'm feeling quite a bit worried if sort of an IP address block holder could randomly create route objects in a database without the consent ‑‑

JOB SNIJDERS: I think this is off topic.

WILIFRIED WOEBER: You think? Okay.

JOB SNIJDERS: I would like to add a remark myself. What I see in this proposal is alignments from a software perspective, anything that alliance Legacy space precisely the same way with norm will al space from a code perspective, I think it's much easier than having all these exceptions and classes and ifs and Ls statements to check what type of space it is. So, I like the approach.

SHANE KERR: I checked my, what I said on the list so I'll try to not contradict myself too much. But, I basically support this proposal. I actually think that we are possibly ignoring the cost of delaying this. We had bad data, incorrect things in the database, people can't clean it up today. By having an abundance of caution and not doing anything, we actually are doing a disservice to the users of the internet. I'd prefer to like follow the 80/20 rule, where the 80% is not good and not worry about the 20% that's not good. In the knowledge that we can make the RIPE NCC do more work if we have to clean things up again afterwards. So...

AUDIENCE SPEAKER: Hello, Andrea Cima, RIPE NCC. I think we all have the same goal in mind, better quality data. So, I think we all agree with that. Before you go ahead with this and before the Working Group decides to go ahead with this, I think you should take a step back and be really careful. Address space issued by the RIPE NCC and address space not issued by the RIPE NCC, the Legacy space that you mentioned, is different. In case of address space issued by the RIPE NCC, we do know who is the legitimate holder of the address space. There are certain rules in place, policies set by the RIPE community, so that is really clear. When it comes to Legacy space we have to think that about 20 or more years ago certain organisations received a large block of addresses, and they may have received these addresses for themselves or they may have received these addresses to be further distributed. We, today, do not know what were the agreements between those organisations, between the ones that further distributed it and the organisations that received it. Now what you're saying here is that the holder of a parent object, that over 20 years ago has given many blocks away to other organisations could, within one click of a button, remove everything below, you could remove 20 years of history. Now, you have to pay attention, because I know for sure that there are holders of more specific blocks in which certain key services are being run today route servers, are being run on some of those blocks. We wouldn't want to delete their registration in one go, so before you go ahead with this, really take a step back and think what the possible consequences may be. That's it.

WILLIAM SYLVESTER: That's good feedback.

SHANE KERR: Again, I think the answer to that is that the opposite of ‑‑ I mean, it's ‑‑ we have known bad data in there. The answer to this is not just to say we can't decide for sure, it's to try and do what we think is best. I know it's out site of the RIPE NCC's remit because they don't have contracts and thing likes that. I don't think the best thing to do is we can't know for sure so the best thing to do is nothing.

RUDIGER VOLK: Shane I think that which we are making decisions over the heads of people who are quite clearly not represented here. And kind of my take is, as the Legacy space is formally integrated into the current registry system, I suppose due diligence and all checking and so on is done, and in that process there may actually some clean up happen. But for space, where we do not have contact and direct communication with someone who is or has been responsible, I think we really should not touch it. The risk that the historically collected information about those resources actually have fake stuff in them and we follow that and having the risk of unrolling that at some point in time, yes, it may be only a few things, but I don't think we should go there.

SHANE KERR: I don't know who is not represented here. This is a RIPE meeting. Anyone is welcome to come and say thinking they want.

RUDIGER VOLK: The guys to whom I assigned addresses, I received directly from SRI Nic in 88 are not represented here. They don't ‑‑ I cannot tell whether they know they should be here. Some may have died off and not be existing any more, but...

AUDIENCE SPEAKER: Peter Timmage, I want to give real examples to put some meat on the bone here. We have actually seen dozens of Legacy holders who yes they didn't know this existed who had the block started '89, '90, '91 who in '91 they were using a frame relay system and they had a customer working with them or someone managing and they had a route object attached to it. They are now fully back in control of the block, they are fully managing it but when they reach out to try to remove it, they can't. In the end they have to be to the RIPE NCC and have to go through all these steps just to get the thing removed that was for their INET NUM. So I'm going back to the central premise here, it is their INET NUM, they should be able to control the objects that are attached to it. They don't, because many of these objects have expired or should have ‑‑ it would be great if there was a way of saying, well, if it's 20 years old, it probably isn't good but we don't because they do last that long, they are used so real real examples are dozens of companies that have this problem happen to them and they do ‑‑ so maybe it's this way, these are people who are control of their maintainer or their INET NUM. The INET NUM is fully in their company name, they are using it, they are absolutely in control, but they can't remove orphaned objects that are attached to it. That's what this proposal is about. So, these aren't people that are dead or gone. These are actually people using their block, but they can't remove things.

RUDIGER VOLK: Well, are they bringing their resources into the formal system?

AUDIENCE SPEAKER: They don't have to, there is no requirement.

RUDIGER VOLK: Yes, but kind of, if they want to have something changed in the formal system and stay outside, well ‑‑

AUDIENCE SPEAKER: So you're saying to get an ‑‑ so you are saying to get an accurate register you have to agree to be part of the system? Because that what it sounds like. I thought the goal of the Database Working Group is accuracy and a good database, correct? So, why don't we try to stick with away from policy of having to be part of the group, stick to the goal of the Database Working Group is for it to be about accurate objects, so I want to keep to that point of view

RUDIGER VOLK: But the interesting question is if no formal checks about the INET NUM object on which, to which you are relating have been done, well, okay, what can we do, and I know we have had specific cases where numbers that I assigned in '88 have been hijacked in the existing system.

AUDIENCE SPEAKER: I don't know about those cases and that's good to know. That's actually valuable for us to hear. Many of these people we do work with have to contact the RIPE NCC and have to provide lots of documentation, they provide the documentation to get the maintainer ‑‑ these are people with RIPE NCC locked maintainers ‑‑ and for them to get their maintainer for their INET NUM, they do prove and provide documentation, they are not signing an agreement but they are providing documentation for that, and they provide that to the RIPE NCC registration desk, but then they cannot remove INET NUM objects underneath it that are there, that are orphaned.

AUDIENCE SPEAKER: Lars Liman. I would ‑‑ I have a few comments. I think Andrea said just the right thing before, so plus one to that. I also think that we might want to carefully distinguish between leaf nodes and nodes higher up in the system. I see a very big difference between the different levels in the system here. So, that will have to be very carefully hashed out, and to add to that I think we should take this very carefully. About being represented here, I guess a lot of you have read the Hitchhiker's Guide to the Galaxy, do remember the first chapter of that one, about the plans hidden in the cabinet behind the door wanting for the tiger on the galaxy two miles away from here, if you don't know where to look you cannot really take part. Even if we think that we are well established and have good outreach, that's not necessarily the case for these Legacy ‑‑ old Legacy space, they are ‑‑ it's gone. So, they can still be on the net, but it's gone and it can be used internally somewhere and not necessarily directly visible, but be very careful.

JOB SNIJDERS: Thank you all for your comments. Okay, one minute.

AUDIENCE SPEAKER: Nurani, speaking only in a personal capacity and as someone who, I guess, has ‑‑ well, I was involved when we shifted a lot of Legacy space from the ARIN database into the RIPE NCC to the RIPE database, and I just, without trying to repeat comments made, I just think we need to be very careful about separating database accuracy and policy, and when trying to achieve database accuracy not actually in the process trampling all over policy. So that's just a general comment. Thanks.

JOB SNIJDERS: Thank you. Thank you Wilhelm. I have great news. We are extending this session with 20 minutes. Next up is Robert.

ROBERT KISTELEKI: Hi, this is Robert. IETF participant and I just wanted to give you a heads‑up about a draft that exists. It requires no actions on your side. So if you want to ignore this, then just by all means do it.

You have seen such a thing. This is an extract from the RIPE database, this is the RIPE NCC autnum. I omitted a couple of details, so this is nothing new. Let's assume for a moment that you all know what RPKI is. Because you do. Let's further assume that you are participating because you want to, and someone is certifying you, well, in this example that's the RIPE NCC because you have RIPE NCC resources. Then, this mechanism will allow you to use your RPKI certificate, loosely speaking, and sign your RPSL object cryptographically, so therefore by giving is some kind of protection. Basically that means that anyone who knows about the RPKI system could verify it is indeed coming ultimately from the RIPE NCC, and it basically means that I, as the holder of this particular resource, declare the following to be true.

So, this would even exist and it's very viable outside the RIPE database, which is one of the the benefits here. The approach is itself is the style looking something like this. So the red stuff is the new thing, that's the signature. The part of it here explains which of the attributes are actually signed, so you can just say, I also want to protect my org attribute but you don't have to if you don't want to. So, the ones that are listed there separated by pluses are highlighted with a different colour. And then there is a reference to the certificate that could be used to verify there is a version number, there is an algorithm, there is a signature time, there could be an expiration time if you want to, and finally there is this data which is the signature itself.

So, this, as a concept, is applicable to virtually all the object types that have number resources as primary keys in them, so INET NUM, route nums, Route‑6 and all those. You could use multiple signatures if there is a reason for that. So for example with route objects that actually would make sense, the AS holder and the prefix holder could separately sign the same object and the two signatures would appear there.

This is not meant to replace any kind of authentication mechanism in any databases, so RPSS is fine anyway it is. The authentication mechanisms would be untouched, this is just an extra attribute. It could be one of the solutions to the problem that you tried to raise on Tuesday and I think will come back to that in a minute. But, it could be independent from it.

So, this is just a heads‑up. If you are interested in this topic, then you can Google for CIDR RPSS and look at the details.

That's it.

JOB SNIJDERS: Any questions for Robert? Thank you very much.

(Applause)

JOB SNIJDERS: Database Working Group. Some of you might be familiar with the RIPE NCC RPSL maintainer. It is used to bring foreign objects into the RIPE database and authenticate them. And a very well known secret is that the password to this maintainer is RPSL. It's now out there. It's no longer a secret. But the issue, I think, is that there are tonnes and tonnes of objects with this maintainer associated with it with the password that everybody knows, and I consider that a very bad thing because it means that there currently are roughly 12,000 objects that anybody can change, literally anybody can go to the website and delete them, modify them, do crazy stuff, and that's a bad thing.

There are 300 aut‑nums in the RIPE database that the protected with the RPSL password. So I sent this to the mailing list asking for some feedback because my personal preference would be that we just delete those lines from the database, and somehow either lock them, if there is no remaining maintainer, or if there is still a maintainer, leave that one but delete the weak one. But that would be my preference to clean this up and make sure that nobody can modify those route objects just using the RPSL password. There's been very little feedback on this proposal. So, I'm just going to ambush you guys.

Is anybody in this room opposing getting rid of this weakness in the database? Wilfried, and the other 50 people are like fine?

ELVIS VELEA: Aut‑num objects with the free maintainer, you are asking if someone is opposing, but anyone can create a script by knowing the password just to delete everything, right?

JOB SNIJDERS: Yes.

WILIFRIED WOEBER: To be more specific, I'm not against getting hold of that and sort of removing the mess, but if I remember correctly, there was a good reason why this mechanism was installed, and it was to allow people to register you stuff in the RIPE database where the authoritative registration is not originally in the RIPE database, and the widest application of that was to allow people to put route objects into the database for IP address blocks which are not authoritative in the RIPE database database. So I'm with you, this is a mess. It should be cleaned up, but I don't think that simply ripping it out without a useful replacement is irresponsible.

JOB SNIJDERS: I fully agree with you and you should have clarified myself a bit. Using the maintainer to create an object, there is certainly a valid role for that currently. What I'm proposing is that the maintainer cannot stay associated with the object. So, the objects will stay there as they are today, you can still use the maintainer to create a route object for which there's like a foreign aut‑num but a RIPE‑based INET NUM, nothing changes in that regard, but after it has been created, like a millisecond later, this maintainer should be removed from the objects. So, I agree with your assessment, it's there for a reason, I am just saying that after you created object, you should no longer be able to use the weak password.

RUDIGER VOLK: Yes, I agree creating the business rule that no user‑created object should have this maintainer makes a lot of sense, and the pure ‑‑ the poor guys who had the idea of creating stuff this way, well, okay, need some help. Looking at the numbers, of course, my question would be, well, okay, have you counted the kind of top‑level elements that the RIPE NCC actually created in here? Those obviously should not be changed or actually the mechanisms used for introducing foreign resources obviously need some kind of overhaul. Kind of the thing started out because there are administrators of the database decided that they should actually represent all the resources ‑‑

JOB SNIJDERS: But those objects are not protected by this particular maintainer.

RUDIGER VOLK: Okay. Then... send ‑‑ well, okay, just ‑‑ not creating ‑‑

JOB SNIJDERS: We're only talking about this maintainer.

RUDIGER VOLK: That's fine on new objects and the old ones, well, okay, give them the courtesy of giving them some notice.

JOB SNIJDERS: Yeah, of course.

ELVIS VELEA: Have you ever done a WHOISed this object, the RPSL maintainer? When you WHOIS the RIPE NCC RPSL maintainer, it says there with bold capital letters, "Do not use this maintainer as maintained by. The password of this maintainer is RPSL, it gets reset every single day. It will always be a public password." So, no one should use this maintainer as maintained by, and as Rudiger said there should be a business rule saying do not use this ‑‑ not allowing people to actually use this maintainer as maintained by. If you want to create an object for an research that is outside the region, you use your own maintainer as maintained by and you use this password to just help you double authenticate. But all of those objects should be deleted because anyone ‑‑

JOB SNIJDERS: No, no, not not objects, only the maintainer by line ‑‑

ELVIS VELEA: All the objects that are maintained by this maintainer can be modified by anyone because the password is public, everyone knows it.

TIM BRUIJNZEELS: For new objects, yes, we can easily change the software to make sure that you also supply another maintainer and actually don't use this one. Just let us know. We are just waiting what comes out of this discussion, but technically we can easily facilitate this. We could even ask yourself though, that ‑‑ yeah, do we really need this maintainer, if everybody knows the password ‑‑

JOB SNIJDERS: That's a separate discussion.

TIM BRUIJNZEELS: Then you might not force people to figure out don't type in RPSL, you might as well say just use your own maintainer and go for it.

AUDIENCE SPEAKER: A comment from the chat room by Denis. You are confusing the user test in maintainer in "maintained by" with use as hierarchical authorisation, these are two different issues, see my recent labs article for explanation, consequences and suggested fixes.

JOB SNIJDERS: Thank you, Denis.

A long time ago, I can still remember it, it was November 2014, Nick Hilliard sent an e‑mail to the Database Working Group stating that he had some concerns regarding the source fields on objects. And what was asked for is that we would differentiate in the database where objects that are managed by RIPE NCC, so the objects that fall within the 35/8s that the RIPE NCC hangs and objects from foreign RIRs that we would differentiate in the source fields where they actually come from.

So, a concrete example would be the first prefix is managed by RIPE NCC, so the source should be RIPE. The second object, however, I believe belongs to APNIC, and but there is a route object in the RIPE database covering that prefix, but given that the prefix falls within space managed by APNIC, we should maybe put in RIPE non‑authoritative as a source.

So, today, for every object, we stipulate that the source is RIPE, even though RIPE is not authoritative for those prefixes. But my ‑‑ I like that idea personally, but I do see a few drawbacks.

For instance, the moment we change the source on objects, it might be that prefix filter generation software, which is only looking for source RIPE when it queries the RIPE database, it might start ignoring RIPE non‑authoritative. So there could be unintended side effects if we would just change the source. And one RIR in particular stands out. There are roughly 40,000 objects, route objects, in the RIPE database that cover AfriNIC space, so at this moment, I would advise the Working Group to have a little bit of patience before we proceed and change the source field for foreign objects, we first need to do some cleaning up I believe.

So the proposal, I think, should be put on hold until we first finish some other action items. Rudiger

RUDIGER VOLK: Well, okay, first of all, I can confirm if you just change the source field in the existing objects, indeed service for certain customers will terminate. What I'm seeing is, yes, it's a good idea to put this on hold and actually I think a little bit of refinements is needed, and well, okay, if we are not rushing ahead, well, okay, we can take our time to do the refinements but we need, I think, to do the refinements.

For me, the thing is, our operational practice is when someone brings in foreign address space to be route originated from my network, we ask them to create an INET NUM object that can be used, well, okay, where they have to put in the maintainer of our routing registry and then we create the route object and, of course we know the INET NUM object is kind of insecure, but it's documented at least. And I have, overall, a somewhat clean thing. Other people use other operational procedures, and for stuff that you would push on the basis of, well, okay, it's outside of what you recognise as RIPE address space which also needs to be actually figured out in the fine detail, well, okay, what rules would be applied on the RIPE none of IRR? What kind of RPSS or some other authorisation can be done there if we just say well, okay, this is like an IRR that just has the rule any paying party can inject junk and only the party that injected the junk can clean it up and the database operator has overriding rules, well, okay, that's not going to improve what we have actually.

JOB SNIJDERS: I agree with 95% of what you said. Thank you for your comments.

Next slide deck please.

Related to the previous presentation, I'm launching now a new project, I call it IRR homing project. Because I firmly believe that information like a route object belongs in the same database as where the INET NUM is hosted, and that for instance, APNIC space should go in the APNIC IRR. RIPE space has to go in the RIPE IRR.

And there are 40,000 AfriNIC objects in the RIPE database, there are like 7,000 APNIC objects in the RIPE database, there is a whole bunch of ARIN stuff in our database, and I think it's time to send those objects home.

The way to do that will be not ‑‑ it won't be overnight. There are operational concerns, similar to if we would change the source attribute value to RIPE non authoritative, moving these objects might also have unintended side effects.

So, that the process I envision roughly is two RIRs meet with each other, possibly over lunch, they discuss that a bulk migration has to happen to get the objects to the proper RIR, and after that bulk migration has happened, the RIPE continues to mirror this data for at least 12 months, possibly longer. During this period, we monitor carefully by doing some BGP announcements from various places with and without the proper route objects in the proper database, to measure the effect of moving these objects and then after a period of time, we should be able to assess whether removing the mirroring capability for that particular space in the RIPE database would lead to operational issues or not.

Comments? Questions?

AUDIENCE SPEAKER: Lars Liman from NetNod. We have run into situations and an initial allocation policy not going to say that's still the case because this is a couple of years back and things may have changed but I have run into problems with, for instance, trying for instance trying to announce APNIC address space from Anton must say system number announced by the RIPE NCC. So, you were at that time not able to register the right combination of things even if you used the two databases and tried to do the right thing, so, that's a situation that we need to keep in mind if we're going to go this path. Apart from that, I don't have any objections, but just making sure that we can combine resources from several registries into a working operational situation, that's ‑‑

JOB SNIJDERS: I happen to have some slides on that after this.

ELVIS VELEA: I agree that route objects should be, or routing data should be in the RIR database that holds the authoritative INET NUM object. I also think, and as far as I remember, the RIPE database mirrors the databases of the other registries, I don't know if it mirrors the data from the IRRs of those registries.

JOB SNIJDERS: Today ‑‑

ELVIS VELEA: But some registries don't have an IRR.

JOB SNIJDERS: Correct.

ELVIS VELEA: However, for those that do have an IRR, I think the relevant thing that we should do is instead of using minus A to actually see that data, we should actually ‑‑ the RIPE database should actually show the data from the authoritative IRR and if there is authoritative data there, they should not allow creation in the RIPE database. That's one of the things, because you would want to create data that overlaps with maybe authoritative data in another registries.

Second thing is I have been saying this for a few years now: Why don't we, the Database Working Group try to start a project with the other database groups in the other, in the five RIRs, and try to actually find a way to create a unique place for data, a unique database. Another database, but that third database, the one database, which has data from all of the RIRs.

ROBERT KISTELEKI: I have to inform all of you that in five minutes there is a workshop going to start here and we have one more presentations, sorry I'm stopping you from this very interesting point. But Wilfried ‑‑ you have ‑‑ Rudiger, sorry, Ruddy, five minutes they are going to start something here.

WILIFRIED WOEBER: Elvis took 80% of what I was about to bring to the table. The second ten seconds is, I like the idea. But this smells like we have to go back to RPSL and try to find out whether we need a new take on RPSL DIST or something like that. Because there is a good reason why some of the registries actually do offer the service of a route registry and some others don't. There is a reason for that.

JOB SNIJDERS: Thank you for your comments. We will pursue further discussion on our mailing list.

The last item I would like to report on is last Tuesday, at 6 p.m., we had a birds of a feather session where audience, there were I think 40, 50 people in the room, 70% of them were operators, 15% were RIR employees, there were some left then. And the purpose of that BoF session is like, the fake idea of how to do cross registry authorisation, because today, everybody recognises that it is an issue if you have RIPE space but a foreign aut‑num that comes from for instance APNIC, it's quite complicated to get anything done in the RIPE database at this moment in time.

So, the idea was to explore that space and see what would be possible to either do cross registry authorisation or remove requirements to do so.

Four ideas were presented in the birds of a feather session, and a fifth one was added on the mailing list. The first idea to flatten the maintainer space, I thought it was a good idea, but I'm kind of withdrawing that idea because I don't think it's such a good idea after the BoF any more. Tim gave a very nice presentation on using RPKI instead of a federated system. Andy from ARIN presented an idea to use RDAP, which is a sort of federated system to get queries to the correct source of truth. We could do something maybe where, instead of querying the RDAP system you post to the RD P system and the request is routed to the appropriate place. We could relax our route object authorisation requirements or we could modify our route object creation requirements. You will see proposals being posted to the mailing list in the next few days that cover these directions, and your feedback is much appreciated at the mailing list.

The BoF did not really provide us with a clear consensus or a clear sense of this is the perfect direction. Everybody agrees. Therefore, this is to be continued on the mailing list. You are standing ready to comment it appears.

AUDIENCE SPEAKER: It is more what happened in the BoF. There was one aspect that was discussed and I knew we had a solution but I haven't actually remembered it but I looked at afterwards. There was an intention to write a maintainer at the registry MNT job at RIPE or something like that. I think this came up in the discussion and the right way to do that is to use the colon syntax and that is used to do structures, and the document 2725 actually uses as double colon to reference the foreign object, you can just totally legitimate in a RPSL right RIPE: MNT X, I just wanted to say that.

JOB SNIJDERS: I learn something everyday. Thank you.

We have come to the end of our session. I apologise for the poor job we did at scheduling this and allowing, allocating the time to the various presentations. I promise you in Bucharest it will be...

Thank you all for attending. Thank you.

(Applause)

LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE