Skip to main content

You're viewing an archived page. It is no longer being updated.


RIPE Meeting:


Working Group:



1st Draft

Revision Number:


Please mail comments/suggestions on:

RIPE 43 - Tools Working Group

Chair: Manuel Valente [email protected]
Scribe: Filiz Yilmaz Bican [email protected]

* Administrative Matters
* Ongoing Tool Projects
* Secure Web Portal Presentation
* Whois DB Synchronous Updates
* Audience Input

Administrative Matters

From the last meeting there are no minutes since in RIPE 42 there
had been no Tools WG so confirmation/comments for the minutes of
Tools WG which was held in RIPE 41 is asked. There were no
objections to them.

Ongoing Tool Projects
By Manuel Valente

There are 3 ongoing projects:

-PGP For Hostmasters

This project was in beta for few months and now it is all in production.
The e-mails that LIRs receive from are being signed
by the RIPE NCC PGP master key:

Next step is to make hostmasters recognise mails signed by LIRs. This will
lead a better and secure RIPE NCC-LIR communication.

-IPMT: IP Allocations Management Tool

This tool is to ease the management of allocations for LIRs.
Storing different allocations and making different assignments from them is
a hard job and this tool is intended to make this process easier.

-WhoisDB RPSL Parsing Library

This library has been released by RIPE Database Department. It allows syntax
parsing on whois objects. It uses the same tool as whois demon so
anything that is parsed with this, whois demon will parse it too. So
one will be able to check database templates with this tool before
sending the real updates to the database. It is implemented in C, which can
be gathered via ftp:

We also we have a Perl module for it.

(Q)uestions/(S)uggestions & (A)nswers regarding above: None

Secure Web Portal Presentation: By Manuel Valente & Kevin Baker

General Overview by Manuel Valente:

This is an extranet for LIRs which is secure, providing access and
modification LIR information, supporting multi-users and
regroup services currently split across

40% of the requests sent to are to access and
modify the general LIR information like phone, address, etc... and
to change the registered contact information for the LIR. This drew
the motive for such a tool so that LIRs could do such changes on
their own without sending requests.

The tool is provided in its Beta release in RIPE 43.

The tool is in multiuser model in which there is one admin user and
password for a registry. This admin user can create, delete and
customise the other user accounts in terms of their access to
different services of the registry information.

Services within the Portal already available are:
- Read-write access to
o General LIR information like Address, Country
o Contact Information like Nic-Handles, E-mail, Phones, Fax, Mailing lists

- Read-only access to
o Billing information like Address, Contacts, Invoices, Payments
and Balance

Other highlights for the Secure Web Portal are that
- it has security through authentication and encryption
- it is designed modular
- at the current time of this presentation, 40 accounts are created
and 70 updates are realized

Short term plans for the portal (until the end of 2002) are;
- to have IP addresses and AS Numbers information of the LIRs added to the
portal by means of listings of IP allocations and AS Numbers,
allocation pools and online submissions of allocations and AS
Number Requests.

- to integrate with current RIPE NCC Tools which will provide
comparison with WhoisDB data (asused), submission
of Whois objects updates and invoice payment.

- to integrate with RIPE NCC Ticketing System which will allow LIRs to
check the status and messages of their ongoing tickets.

Longterm plans for the portal (within 1-2 years from now) are;
- to enable complete interaction between LIRs and RIPE NCC through web
interface - mail communication will still be on which is very important.

- to increase automation so that it will be easier to submit forms trough web

- to reduce load of RIPE NCC Hostmasters so that less they will have
to do, more they will be able to deal with ongoings

Finally, thanks to participants. Accessibility for all members is
coming soon but for the time being, for the participants of this meeting
please visit the Hostmaster Center for your registry's admin

All feedback can be sent to [email protected].

And LIRs who have an admin user can login at:

(Q)uestions/(S)uggestions & (A)nswers:

Q: Is there a specific reason for having billing information read only?
A: For the moment it is like that since billing information is
sensitive. Most of the information there will be read write soon.


Technical Overview by Kevin Baker

Requirements for the portal was to have it;
- web based
- secure
- allowing LIRs to administrate their own users
- initially simple

Backend architecture of the portal consists of (which
contains ssl and httpd with Perl and Mason), an ssh tunnel through a
firewall, which enables communication with a daemon accessing
registry data and authorisation data.

Web server connects to a server behind the firewall for data.
Storage daemon authorises access in accordance to the credentials
passed from web server and then it returns data. LDAP is used for
nice hierarchy to store authorisation and access credentials.

Web server is HTTPD which is apache built with ssh and perl.

CGI and templating is done via HTML::Mason which is PHP like, making
coding up screens easy.

Storage daemon is used as a solution to keep the internal database
secure. It basicly chokes access at one point, only talks to the web server,
returns a subset of registry data to limit exposure, uses LDAP to
maintain authorisation data, could become a speed bottleneck.

To authorise clients, to maintain authorisation over a login session
and to secure the transmission of the data, login credentials are
validated against access list and browser gets a cookie holding a
session id. Session is only valid until log out or time out due to
inactivity. SSL limits session keys leaking and encrypts the data.

The building blocks of the portal can be listed as perl, mysql,
ldap, apache and ssh.

The portal has been alive almost for a week now and we are watching
it. There are few bugs. Your feedback will make us able to stabilise
it within few months time.

(Q)uestions/(S)uggestions & (A)nswers:

Q: Is it possible to put an e-mail message which will tell us that this
user changed this? Something like a notification message?
A: OK.

S: What about the usage of certificates instead of passwords?
A: It might be hard for some users to maintain their certificates,
but we will look into this.

Synchronous Updates in RIPE Database in RIPE Database: By Can Bican

Related URLs to visit are:

Current way to update the database is only sending updates by
e-mails. This is not convenient for automated or controlled updates
since it is hard to match the update and the corresponding
acknowledgement and there is delay between the submission and the

It may also be annoying for a beginner; sending the update, waiting
for the acknowledgement, identifying errors, fixing them and sending
the update again affects user's performance.

Matching the object contents, the help texts and the update message
and its results all require different tools.

And using an e-mail interface to for a database is an unfamiliar
idea for most users.

Solution to these is to provide an infrastructure to enable
Synchronous updates (which is called syncupdates) and to
provide a web based graphical interface on top of this
infrastructure (which is called webupdates).

Synchronous Updates can be seen as a method to update the
database by connecting to a TCP port where the main requirements are
having it extensible, maintainable, compliant with current update
schemes and regulations, in same functionality with mail updates and
easy to use protocol.

The architecture of the system consists of a http server which
provides a well known input method, frontends which do the filtering
and grouping, backends which do the scheduling, server frontend
which provides acknowledgement and mail notification and the core

Minimal client for the system is any web agent/client/robot so if you
have a language and it understands http you can use the tool. The input
format is well defined and output can be parsed easily.

Notifications are not synchronous, they are sent via e-mail.

Web Updates is a prototype of a web based graphical user interface to
syncupdates where adding, editing and deleting objects are possible.
Authentication is password based.

References are:

Project page is at:

Project mailbox is [email protected]

(Q)uestions/(S)uggestions & (A)nswers:

Q: Will it be possible to send PGP signed updates?
A: It is possible at the moment through syncupdates, but it is not possible
for webupdates since PGP is not really meant for web browsers, we are looking
for other alternatives.

Q: Referenced URL does not work.
A: It was working in the morning, I'll check.

Q: Are there ready object templates for web updates that we can use?
A: For creation we provide the empty fields for you to fill in, but
according to your suggestions we can develop.

Q: Is it possible to send multiple updates?
A: In syncupdates, it is possible, but in web interface it is not
possible at the moment but in the next release we will probably do this
as well.

S: It would be nice, if you can define which auth to use in mail
updates and which auth to use in webupdates.
A: I am not sure if we can change it, but we can think about it in the future.

Audience Input

Manuel Valente's e-mail address is [email protected]. You can write
your questions/suggestions/comments about tools.