RIPE 57

Comments about:

• content to the Chair of the working group.
• format to webmaster@ripe.net.

Meeting: RIPE 57, Dubai
Date: Tusday 28 October 2008
Time: 16:00 - 17:00 CET
Chair: Kurtis Lindqvist & Bijal Sanghani
Jabber:
Scribe: Laura Cobley (RIPE NCC)

WG URL:
http://www.ripe.net/ripe/wg/ncc-services/index.html
Agenda:
http://www.ripe.net/ripe/meetings/ripe-56/agendas/ncc-services.html

A. Administrative Matters

The minutes from RIPE 56 were approved.

There were no questions.

B. RIPE NCC Update, Vision and Focus 2009

Slides by Axel Pawlik, RIPE NCC:
http://www.ripe.net/ripe/meetings/ripe-57/presentations/Pawlik-Update_from_the_RIPE_NCC_at_RIPE57.An80.pdf

Ruediger Volk (Deutsche Telekom) asked if the RIPE NCC had any information about the availability of IPv6 education. He asked if a repository of information could be set up or whether the RIPE community should do something about it.

Axel answered that the RIPE NCC will make a repository of information if there is a demand and if we do not compete with others.

Rumy Kanis (Training Manager, RIPE NCC) added that research has been carried out in the RIPE NCC's service region. In certain countries, such
as the UK, Germany, France and the Netherlands, there are a lot of IPv6 courses available. This is not the case in other parts of the region,
such as eastern Europe. The RIPE NCC gets a lot of questions about IPv6 training when giving courses in these areas. She asked the community to
let the RIPE NCC know where and how they thought IPv6 courses should be given and what information they would want in those courses. Feedback
can be sent to rumy@ripe.net or training@ripe.net.

C. Certification Update - Tim Bruinzeels, RIPE NCC

Slides: http://www.ripe.net/ripe/meetings/ripe-57/presentations/Bruijnzeels-Certification_RIPE_NCC_Beta_Programme_.KB9X.pdf

Dmitry Burkov stated that if the system is deployed, he would have critical issues. He added that he would not be the only one with issues and that all Russian Local Internet Registries (LIRs) would have issues. The system will break a specific law regarding cryptographic tools. The system would need to be synchronised with the RIPE NCC's system and this would be a big problem. He continued that, as he had stated before, perhaps a National Registry is needed. He said that the details can be discussed but now that deployment is coming, he needed to say something.

Andrew de la Haye (RIPE NCC) answered that the Certification Task Force takes Dmitry's comments seriously and stated that it would like to invite Dmitry to discuss the issues mentioned.

Steve Kent (BBN Technologies) said that he had dealt with this issue before with Russian organisations. With the same cryptography, there were no problems. He said that he didn't believe that this system violates any laws but that he was prepared to discuss it.

Dmitry said that the problem will be with the repository and with automated deployment of policies in the future.

Randy Bush (IIJ) said that people should be able to run their own stuff using this protocol, which should satisfy needs.

Steve asked Tim some additional questions:

• When I generate a ROA, does it check if the prefix is in my cert? Tim responded yes.
• Will you make the cert and the ROA match? Tim responded yes.
• Can you enable default entries? Tim responded that these are based on the cert lifetime.
• Steve added that Tim may be able to use some existing software, such as software which tracks the CIDR WG specs.

Tim responded that the team has been looking at this and also at a bottom-up validation tool.

An attendee stated that their organisation has a similar mechanism and also runs an experimental service. He added that he had some feedback from users which might help:

• When users input their IPs, they don't know which IPs they own and we have to tell them.
• The CA holders forget about their certificates and what they have entered, so we notify them before it expires.

Tim stated that the RIPE NCC could automate certificate renewal. The normal user wouldn't have to deal with this and the system should take care of it.

Malcolm Hutty (LINX) said that the basic aim is to look forward to a world in which, when someone makes a route announcement, it will be treated with suspicion unless they have a signed CA. In principle, that would give the RIPE NCC the power to revoke address allocations. He added that his concerns are that this will prove attractive and will become a regular occurance. He asked how the RIPE NCC plans to deal with legal requests to revoke certificates.

Daniel Karrenberg (RIPE NCC) said that this was a valid concern. The RIPE NCC has always said it is not its business and that the Dutch legal system would need to be involved, so in this way nothing will change. The other thing is that ISPs aren't enthusiastic about the near real-time provisioning, but governments are. He added that his question is whether ISPs will actually implement this.

Randy disagreed with Daniel. He said that ISPs have the power, but if this is deployed, the RIPE NCC will have the power too. There is a basic trade off of security versus ease of use.

Daniel said that it is a trade off of security versus possibility of abuse.

Malcolm said that this is a significant change. It is not just go or no-go, but there are other options that can be explored. Especially if we want to prevent revocation impacting people in other regions. He mentioned the steps:

1. Comply
2. Appeal
3. Change location to escape jurisdiction
4. Re-engineer the database to separate sections (jurisdictions) so that each can choose to comply individually.

He added that the fourth option is the preferred one.

Steve said that he didn't think that the fourth option would help. RIRs only provide data that ISPs can choose whether they adopt it.

Malcolm said that in practical terms, these are the probable consequences.

Ruediger said that it would be useful for routing as the data is somewhat trustworthy and this is one single solution. Revocation of certificates will have an effect on routing. This will become more and more useful as resources become more scarce. He said that he could not see another reasonable way to do this in a feasible amount of time.

An attendee said that the RIPE NCC should not say that it is only responsible for creating the tool and not for what people do with it. He asked how can he generate his own key if he does not trust your generator.

Tim said that he did not envision this being allowed.

Randy said that this is just the first step and it is a good step.

Daniel said that choices had to be made to make progress and what was thought would be immediately useful to most people was chosen. If additional things will be useful to many people then they will be implemented.

• Action: RIPE NCC to fix the ROA validation screen (lower case as3333)

D. Hostcount Update - Mark Dranse, RIPE NCC

Slides: http://www.ripe.net/ripe/meetings/ripe-57/presentations/Dranse-Hostcount_Update.dXoF.pdf

There were no questions.

E. Open Microphone Session

Kurtis summed up the previous discussion and said that The CATF will
look again at the legal issues that Dmitry mentioned.

Z. A.O.B.

The session ended.