- content to the Chair of the working group.
- format to webmaster _at_ ripe _dot_ net.
Friday, 9 May 2008 09:00 - 10:30
Chair: Joao Damas, Rob Evans, Joachim Schmitz.
Minutes: Franz Schwarzinger (RIPE NCC)
Jabber Scribe: Sandra Bras (RIPE NCC)
A. Administrative Matters
There were no open action points that required attention. There was no input on the minutes from the last meeting on the mailing list.
B. LISP - State of the Art -
Vince Fuller (Cisco Systems)
Wilfried Woeber (Vienna University) asked how the debugging environment would look like compared to traditional tools.
Vince answered that on the overlay network, debugging should work as it works now. Only when running traceroutes the packet might run a very different path the first time it is run.
Jari Arkko (Ericsson) commented on the address rewriting and the required host changes. He pointed out that this might not be true in all cases and that there is ongoing discussion about this on the Routing Research group at the IRTF
Vince agreed and mentioned the IRTF website at http://www.irtf.org and their mailing list for more information.
Jari also commented that he really likes the idea and they are building prototypes. The next step should be to design experiments to answer questions about deployment mechanisms and mapping system.
Vince pointed out the LISP interest mailing list and asked for further discussion to take place there.
Jari noted that some of these questions might be of interest for the RRG as well.
Joao Damas (ISC) commented that the main reason for this talk is for people to get hands on experience.
Vince said that the RIPE NCC is volunteering as a test site and this working group needs a time commitment from them.
C. Internet-Scale BGP Simulation
Maciek Wojciechowski (NLNetLabs)
There were no questions.
D. MyASN Development
Erik Romijn (RIPE NCC)
Joao Damas (ISC) commented that he is happy that the RIPE NCC is looking at SMS as a notification mechanism because, in the case of prefixes being hijacked, emails might not arrive at all.
Erik agreed on this and wants to gather statistics on how many subscribers would actually be affected by this problem.
Joao asked if they could use route collectors to send out notifications.
Erik answered that this is not possible.
E. Discussion - Building an IRR Based on the RPKI Infrastructure
Kurt Erik Lindqvist (Netnod) stated that he had no slides for this since it should only be a discussion and pointed to his presentation on Monday. He asked how to move on with this proposal and suggested to move implementation-specific discussion to the Database Working Group.
Joao Damas (ISC) asked if Kurt could give a quick overview on what his proposal is about.
Kurt stated that the idea is to build a new IRR registry that contains route objects generated from the ROA in the RPKI.
Joao clarified this and pointed out that data in this registry should be more reliable.
Kurt added that the RIPE NCC should build a tool that enables people to add data by themselves. He also noted that Ruediger Volk (Deutsche Telekom) had the initial idea for this proposal.
Ruediger mentioned that RPKI was initially done to reach long-term goals in the area of secure routing. The RIRs have used RPKI to create new data structures in order to secure allocations. He noted that the data in the RIPE region is usually of good quality but this is not the case in other parts of the world. He compared the RPSL based IRR databases to the data that is available in RPKI and what tools are used to query this data. RPKI has the Route Origin Authorisation object that actually contains routing information which matches the RPSL information very precisely. The idea is to use the secure RPKI information to create RPSL representations so that it can be accessed by currently available tools. In order to differentiate between normal RPSL information and the secure RPKI information he suggested using the source attribute in RPSL. Only minor changes would be needed in the existing databases and tools to use this efficiently.
Wilfired Woeber (Vienna University/ZID/ACOnet/RIPe Database Working Group Chair) stated that he likes the idea but wants to know whether this is a completely new database or just a new mechanism integrated in the existing databases.
Ruediger said that they are not intending to make changes to the objects or add additional attributes. The data will be exactly the same but the trustworthy data will be tagged with a special source tag.
George Michaelson (APNIC, speaking in a personal capacity) stated that he is pleased that this will have a limited lifetime and a limited scope. He mentioned the fundamental issue regarding the trustworthiness of a data source. He also stated that there is a similar proposal at APNIC and that they would be able to implement this. However, assuming that unverifiable data can be trusted just because it is retrieved from a certain source is inherently weak. The work that the RIPE NCC is doing in regards to providing embedded signatures is not harmful to this proposal and should be done.
Daniel Karrenberg (RIPE NCC) stated that the RIPE NCC is already working on getting this into their prototype and it is not very difficult to do that. He was surprised that this was turned into a PDP proposal. He did not want to criticise the proposal but thought that it was a bit unnecessary for something that is already being done.
Joao asked if it is already being done.
Daniel answered that the RIPE NCC was discussing this with Ruediger and has put it in the process for the prototype. However he was not sure where it was in the planning.
Andrei Robachevsky (RIPE NCC) stated that there are a few implementation details but it should be fairly simple to implement this. He also commented that there are components in the routing registry that could be used to improve routing security in the future. There are already some thoughts on how authorisation schemes can be improved in order to improve data quality. This might include signing the data in the routing registry.
Wilfried pointed out that not all routing registries use a unified RPSL representation.
Ruedierg stated that they should keep this simple.
Wilfried answered that he wants to find out whether there is a way to improve the system.
Joao stated that this is not relevant to the discussion right now and asked to finish this first.
Jos Boumans (RIPE NCC) agreed with Daniel on the simple implementation but the proposal goes into more depth, having five points covering things like how Internet Service Providers and Internet Exchanges should be able to use the same software independently on their side. This is much more than "low hanging fruit" and simple implementations. It is already in motion but only a simple subset of the full proposal.
Joao asked if there are any more opinions on this subject and suggested instead of having a policy proposal, to put an action item on the RIPE NCC to implement this.
Kurt stated that the reason for the policy proposal is to give the same text to the other RIRs as well.
Joao suggested an action item on the RIPE NCC first to find out what can be implemented easily and provide the working group with an estimate of when that first part can be done. Following that, the RIPE NCC should provide an assessment of what work would need to be done and give a report at the next RIPE Meeting.
Kurt also asked for a demo of a first implementation at the next RIPE Meeting.
Joao agreed and added that only the hard work should be assessed at the next RIPE Meeting.
Wilfried stated that he would have liked this to be mentioned in the RIPE Database Working Group under "I/O With Other Working Groups".
Joao noted that suggestion.
Joao Damas (ISC) noted that they were approached by JPNIC, from Japan, wanting to report on the status of ASN 32 implementations in different routers. They stated their intention to present on the mailing list.
Mirroring Other Routing Registries - Jos Boumans (RIPE NCC)
Jos asked if this is being used for operational decisions.
Ruediger Volk (Deutsche Telekom) stated that he used it.
Jos asked if he was aware of these limitations.
Ruediger answered that he was not aware of it.
Jos asked if he would still be using this considering the limitations.
Ruediger responded that, while knowing the limitations, he would prefer to run the query against the appropriate database.
Jos stated that this is very prudent.
Ruediger mentioned that sometimes they were using the RIPE Database for APNIC data because the APNIC server would create syntax errors that would then break their tools. Therefore, having the RIPE Database filtering out irregularities is of value. Sometimes they have to run the same query at different databases because the references are crossing the registry boundaries and for that they would need a database server that actually does mirroring.
Jos asked if he would need a database server that was able to give him the answer.
Ruediger answered that keeping all the tools in sync with all the irregularities is difficult and it would be nice to have a central service that does this for you. However, filtering out irregularities might also remove data and it would be nice to know when that actually
Jos asked if Ruediger meant that he has to query multiple databases anyway and whether it would be convenient to have someone do the conversion for them.
Ruediger stated that this was what he meant.
Jos said that this is exactly their problem. They have been trying very hard to do this but unfortunately it led into operational problems. He asked if this was really what they want them to do.
Ruediger answered that he did not remember any errors that led him into a feedback loop with his customers and he would be comfortable with being able to send regular reports to his customers based on a service provided by the RIPE NCC even if some information is missing.
Jos asked if anybody else has so much faith in them that they build their routing policies base on the answers of mirrors.
An attendee stated that they trust them.
Jos states that they must trust them in case they are using this.
Joao mentioned that he thought there was a lack of detail in the presentation and asked about how the RIRs implement the RPSL and the changes that have been made to it. He also stated that APNIC is using the RIPE Database software with only a few local modifications. He asked for data on this and said that the RIPE NCC was welcome to restate the proposal when a better set of data can be presented to the RIPE community.
Jos answered that no one fully implements RPSL specification and all the changes that are made to it at least twice a year. He also stated that he has the data and is happy to discuss this on the mailing list.
Joao apologised for being so late, asked if anyone had to add anything.
No one wanted to add anything.
There were no action points open at the beginning of the meeting.
A new action point regarding a new IRR based on RPKI infrastructure was created. The RIPE NCC will investigate the work involved in building an IRR based on the RPKI infrastructure and give a report at the next RIPE Meeting.
Everyone was thanked for their participation.