RIPE 48

• content to the Chair of the working group.
• format to [email protected].

RIPE NCC Services Working Group Summary (RIPE 48)

Date: Tuesday 4 May 2004
Time: 14.00 - 15.30
Location: Grand Ballroom

Date: Thursday 6 May 2004
Time: 11.00 - 12.30
Location: Grand Ballroom

AGENDA:

A. Administrative Matters
B. Axel - RIPE NCC Update / 2005 Activity Plan
C. RIPE NCC - LIR Portal Update
E. Kurtis Lindqvist - WG input for the 2005 Activity Plan
F. Filiz Yilmaz - Authentication for Hostmaster Robot
G. Daniel Karrenberg - De-Bogonising New Address Blocks
Y. Open Microphone
Z. AOB

http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-nccserv-agenda.pdf
********************************************************************

A. Kurtis Lindqvist - Administrative Matters
**********************************
Chair: Kurtis Lindqvist - Netnod Internet Exchange
Co-Chair: Bijal Sanghani - Flag Telecom
Scribes: Eamonn McGuinness, Nathalie Dougall

Minutes from RIPE 47 approved:
http://www.ripe.net/ripe/wg/ncc-services/r47-minutes.html

B. RIPE NCC Update / 2005 Activity Plan
Presented by: Axel Pawlik - RIPE NCC Managing Director
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-nccserv-ncc-update.pdf
***********************************************************************
Axel spoke about the 2004 and 2005 Activity Plans. Members were asked
to think about their input for the 2005 Activity Plan. The agenda
point at the 2nd session of this working group (Thursday morning) is
where people can provide input and/or raise any issues of concern.
People are also encouraged to approach Axel, and/or other member of
the RIPE NCC staff, and/or any of the attending RIPE NCC Board members
to speak privately should they be hesitant to do in the public arena.

Within Registration Services (RS), the RIPE NCC Hostmasters are trying
to improve how they interact with customers. The Local Internet
Registry (LIR) Portal has many useful features such as new request
forms, wizards and so on. Reverse Delegation is in the process of
becoming more automated and straightforward.

The RIPE NCC is unhappy with IANA at the moment as it is still waiting
for a new block of IPv6 addresses. They were notified in February to
expect a large request from the RIPE NCC as requests from members are
being received. Feedback received from IANA was positive. However
when the RIPE NCC requested an additional IPv6 block at the end of
March, IANA responded that they had issues with the request and needed
to discuss it with the IAB (Internet Architecture Board) first. It was
made clear that the IAB are not at fault.

Kurtis Lindqvist (Chair) asked what exactly is the problem?

Axel (RIPE NCC Managing Director) said in the past it was decided that
IANA give /23 blocks of IPv6 to each RIR which was fine so far. But
now the RIPE NCC are receiving requests which justify larger
allocations, hence the request for a larger allocation than a /23.

Gert Doering (SpaceNet) wanted to clarify a small point, that the
community were actually not so happy that only /23s were allocated to
the RIR's. Larger blocks should have been given.

- -Back to the presentation-

Axel highlighted that the RIPE NCC are being proactive in scheduling
member training courses alongside related conferences in the RIPE
service region.

AfriNIC should become the next established RIR at the end of 2004, or
in early 2005. The 1st AfriNIC open policy meeting will be held in
Dakar in May - http://www.afrinic.net.

The Membership Liaison Officers (MLOs) are responsible for improving
co-ordination and to provide further outreach to the RIPE NCC
community. There are two more Regional Meetings planned in 2004:
Moscow and Nairobi.

The RIPE NCC Communications department are co-ordinating with the
other RIRs to report consistent and accurate data to news agencies and
media when necessary.

Axel reported that the RIPE NCC is planning another Membership Survey
in 2005 as the previous one (2002) was very useful. Many suggestions
from the previous survey were implemented as can be seen from this

year's Annual Report and Activity Plan.

Wilfried Woeber (UniVie / ACOnet asked why these regional meetings are
free of charge and why they weren't self-sufficient, like the RIPE
Meetings.

Axel explained that the Regional Meetings are RIPE NCC meetings, not
RIPE meetings. The difference is that the RIPE NCC goes out into a
specific region, meeting directly with the membership, according to
needs of that region. This is a different focus than the open process
of RIPE meetings.

The 2002 Membership Survey and other sources expressed the opinion
that some parts of the RIPE region were unaware or unfamiliar with the
RIPE NCC and with general policies and procedures. Regional desks were
suggested, thus the MLO role was created within the RIPE NCC. The
first obvious region to meet was the Middle East, followed by Russia.
The goals of these meetings are to educate, increase knowledge and
allow the RIPE NCC to be more accessible to members in remote regions.
These meetings also afford us the opportunity to speak with
government agencies and so forth.

C. RIPE NCC / LIR Portal Update
Presented by: Vesna Manojlovic - RIPE NCC Advanced Courses Trainer
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-nccserv-lirportal.pdf
********************************************************************
Vesna began by asking how many of the present audience uses the LIR
Portal. Nearly everyone put their hand up.

During the presentation Wilfried Woeber (UniVie / ACOnet) asked what
'RSS' stands for?

Vesna explained that RSS stands for 'Really Simple Syndication'. It is
a web syndication protocol used primarily by news websites and web
logs.

Vesna reported how the tools on the LIR Portal are helping the RIPE
NCC's members acquire IP address resources quickly. This in turn
allows the RIPE NCC to concentrate more time assisting new and
inexperienced LIRs. Vesna concluded by saying that all feedback and
input from the membership is welcome and does make a difference.

Andre Koopal (MCI) would like to be able to have access to the
messages in the Hostmaster tickets his LIR has with the RIPE NCC.

Kurtis Lindqvist (Chair) ended the discussion reiterating the fact
that the original intention was for an LIR to give this presentation
but there were no volunteers. He would like to get a volunteer for the
next RIPE meeting in Manchester in September 2004.

E. Kurtis Lindqvist (Chair) - WG input for the 2005 Activity Plan
***************************************************
Kurtis reminded everyone why this working group was set up - to
provide input and dialogue to the Activity Plan of the RIPE NCC. The
work the RIPE NCC does should reflect the wishes and needs of the
community.

When there was no response from the audience when asked if anyone gave
any feedback to the RIPE NCC about the Activity Plan for 2005, Kurtis
asked if everyone were happy for the RIPE NCC to take care of
compiling the Activity Plan on their own. Again there was no response.

Axel Pawlik (RIPE NCC Managing Director) was not surprised, but still
a little disappointed at not receiving any feedback on this topic. He
will give a similar presentation (Agenda item B.) on Friday afternoon
during the RIPE NCC General Meeting (GM) where members will be
present. This therefore presents another formal opportunity for RIPE
NCC members to give input and thoughts on the AP. If Axel or the RIPE
NCC Board do not receive any feedback they will take this as approval
to go ahead with the plan. Axel reminded everyone that the Activity
Plan would be published to the RIPE NCC membership in August 2004, a
few weeks before the General Meeting at RIPE 49 in Manchester in
September 2004.

Kurtis pleaded to the community to give input and feedback with
respect to the Activity Plan. If it is difficult to speak up at the
meeting, then emails to Axel and/or the RIPE NCC Board Members are
also an option. It is worrying that there appears to be silence on
this issue.

F. Authentication for Hostmaster Robot
Presented by: Filiz Yilmaz - RIPE NCC Senior Hostmaster
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-nccserv-hm-robot.pdf
**********************************************************************
After Filiz gave her presentation, Gert Doering (SpaceNet) said that
in his opinion the problem with PGP is the key management (user keys,
Hostmaster key etc.) and the RIPE NCC have solved this now. He
suggested a script could be added to the LIR Portal for users who can
choose to have their e-mails encrypted or not. Then the RIPE NCC
Hostmasters can accept the e-mails as encrypted or not.

Shane Kerr (RIPE NCC Software Manager) was more cautious as this
change would not come without complications. He explained how many LIR
Portal users lose their keys but the RIPE NCC cannot suddenly stop
communicating with LIRs in those cases. Signing is easier, as the
e-mail is visible and the user knows what the RIPE NCC is trying to
send them and vice versa. The RIPE NCC can look at their mail logs and
see what is going on there. There is already an infrastructure for key
management and recovery in place.

Another problem Shane reported is that some communication is not only
"one-to-one", but also sometimes "one-to-many". This complicates the
picture quite a bit. All of the recipients have to read the e-mail and
if some do not have a PGP key or X.509 there is simply no way to
encrypt it for them. It was decided not to pursue the effort of going
into this issue in great detail before the last RIPE Meeting, because
of the complications it poses, therefore the RIPE NCC decided to focus
on verifying the correctness of the e-mail before starting to encrypt
it.

Once this is done, the RIPE community will have to be asked if it is
worth the effort for the RIPE NCC to go over all of these issues and
put together a plan.

Randy Bush (IIJ) asked, regarding automated software signing of
messages with PGP and X.509, how those keys are maintained and revoked
and so on. This is in light of the fact that if this process is being
done automatically, are there keys on a hard disk which may pose a
security risk?

Shane (RIPE NCC Software Manager) responded by saying it is RIPE NCC's
policy to have extra secure hosts. These include CA and the RIPE NCC's
PGP signing box. There are two or three hosts, which have a limited
access and are connected directly to a single box, which is not on the
fabric of the RIPE NCC's network. The Operations Department of the
RIPE NCC can access most of the machines in the RIPE NCC. These boxes
have a smaller set of Administrators with access. The hosts are secure
so the keys are not generally available.

The RIPE NCC takes security seriously. For PGP there is a key-signing
box and a set of procedures where the keys are changed regularly. Even
so, Shane admits the RIPE NCC has not published their old keys
recently and he promises to get that fixed shortly.

Randy Bush (IIJ) asserted that presuming hosts are secure is a rather
weak assumption.

Kurtis Lindqvist (Chair) asked Shane if there has there been any more
co-ordination work done with the other RIR's regarding X.509?

Shane (RIPE NCC Software Manager) said the RIPE NCC is willing to make
a more detailed presentation on the underlining issues of PGP
encryption if the community wishes. The RIPE NCC put together this
presentation because they would like to start building it. Shane asked
the audience if the community were supportive of the proposal. There
were no objections to the proposal.

ACTIONS
********
48.1 RIPE NCC - To make a more detailed presentation on PGP encryption.
48.2 RIPE NCC - To start implementing the key-signing proposal.

G. De-Bogonising New Address Blocks
Presented by: Daniel Karrenberg - RIPE NCC Chief Scientist
http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-nccserv-debogon.pdf
*********************************************************************
This presentation highlights the connectivity problems of LIR's who
receive address space out of very new /8's the RIPE NCC receive from
the IANA. The problem is that it takes too much time for all operators
to update their bogon filters.

Geoff Huston (TELSTRA) pointed out that the address prefixes stated in
the presentation are taken from the RIPE whois database and not from
the delegated zone files of the RIPE NCC. The address prefixes stored
in the RIPE NCC's delegated files are more reliable as (a) handed out
officially by the RIPE NCC, (b) are in use and (c) can be routed.

Geoff expressed his opinion regarding the necessity of using the
delegated files as authority if the community wants to be serious
about using correct bogon information. The Whois Databases should not
be relied upon, as they are problematic for all kinds of reasons. He
would not advise anyone doing real-live packet filtering to rely on a
Whois Database.

Daniel Karrenberg (RIPE NCC Chief Scientist) agreed and said the RIPE
NCC will amend this procedure.

The final slide of the presentation called for input from the audience
about this pilot. Would people like to see this make into a RIPE
document with the intention of becoming a regular RIPE NCC service?

Geoff Huston (TELSTRA) asked for more granularity when producing
information on bogons. Addresses that have been allocated or assigned
but are in an "active" /8 make ideal bogons for miscreants. The RIPE
NCC should publish this information.

Ruediger Volk (Deutsche Telecom) was next to say he would like the
RIRs to clarify what address space each has given out so far. This
would allow an understanding of what address space is in use and what
is not.

Ruediger believes only the RIRs and IANA can and should do this.

Andre Koopal (MCI) thinks the RIPE NCC should take the responsibility
of clarifying what they have allocated and what shouldn't be in the
bogon list. Additionally, he thinks that IANA should define the list
of where the real bogons are, not the RIPE NCC.

Daniel Karrenberg (RIPE NCC Chief Scientist) reminded the audience
that the RIPE NCC started this de-bogonising pilot because of the many
complaints they received from LIRs. There was pressure for the RIPE
NCC to provide some relief, to be seen to do something to tackle the
problem. There have been mostly positive reactions to the pilot
although at this stage it is more ad hoc relief than an actual
solution.

Andre Koopal (MCI) wishes to see the pilot become a permanent RIPE NCC
service.

Randy Bush (IIJ) would like an effort made to look at the problems
from the front rather than using ad hoc relief. He agrees with Geoff
Huston that the underlying data is weak, not well defined and lacks
proper signed distribution.

Geoff Huston (TELSTRA) specifies there are approximately 2,000 entries
(out of approximately 210,000) whose data are unclear, most of which
are /24 networks. It is not clear if those records have been allocated
or not. This kind of data needs to be accurate in order to have a
trustful bogon filter.

Kurtis Lindqvist (Chair) asked if something is being done to prevent
similar problems happening in IPv6?

According to Daniel Karrenberg (RIPE NCC Chief Scientist) and Gert
Doering (SpaceNet), these issues with IPv6 have not risen yet. It was
not specified as a requirement for this pilot. Gert stated people are
filtering far too loosely with IPv6 and the problem is not the
prefixes not propagating, but garbage propagating everywhere. There
does not appear to be a problem with non-reachability due to bogon
filters. He asserts the problems discussed here are not evident in
IPv6. IPv6 has other problems.

Gert thinks there may be scientific interest to measure propagation,
especially to counter mistakes made in the past with IPv4.

Kurtis Lindqvist (Chair) posed the question to the audience: Would
there be interest to give the RIPE NCC a task to go to IANA to try to
clean up the data?

Daniel Karrenberg answered that all the RIR's have this task already.

Geoff Huston (TELSTRA) spoke that as a customer of RIR data and as an
operator he needs to rely on accurate data. The IANA and the RIR's
need to fixed the current inconsistencies. Currently within the RIR
communities information is published about address space in a number
of different formats; delegated files, Whois, RIPE NCC documents. They
are not all drawn from the same underlining database, they cannot be
because there is inconsistency, he said.

Geoff believes it is worth the RIR's effort to have an accurate and
consistent listing of what address space is in use and what is not, on
at least a 24-hour cycle. Then people will know what to expect in
their routers. IPv6 or IPv4 makes no difference.

Shane Kerr (RIPE NCC Software Manager) addressed the WG to say the
RIPE NCC are aware and have foundation plans to improve consistency of
registration data across the RIR's and IANA. However the current plan
is to wait until the ERX (Early Registration Transfer Project:
http://www.ripe.net/ripencc/pub-services/db/erx.html) is finished.
This would allow the RIPE NCC to clean up the data it currently holds
first before addressing the inconsistency problem.

Nevertheless the RIPE NCC wanted to use this pilot to gauge from this
working group about how much effort should be spend on this because it
will be expensive in terms of cost and time to pursue it further. It
will take time away from answering requests for new IP resources for
example and Shane does not have a good feeling yet how much time the
community wishes the RIPE NCC spend on addressing this data
consistency issue.

Kurtis Lindqvist (Chair) asked Shane if the RIPE NCC is waiting for
the ERX to finish, and if anything was being done right now to clean
the data?

Shane Kerr (RIPE NCC Software Manager) explained how historically it
used to be the case that anyone could register anything in the RIPE
Whois Database at any time. There was never an effort to clean up or
make the data consistent in the past in a systematic way. Right now,
as the ERX proceeds the RIPE NCC are cleaning up the data within each
/8 systematically and once the ERX is complete the RIPE NCC will be
able to know that at least the data from those /8 blocks is good.
Shane confirmed that most of the garbage left resides in the 192/8
block. Historically this block is quite a mess.

When the ERX project finishes the RIPE NCC would like to go back and
start looking at the data in the oldest blocks, 193/8, 194/8 & 195/8.
These are of the vintage 1993 - 1995 era. In order to do this however
it will take human beings going through old mail logs and files and so
forth.

Geoff Huston (TELSTRA) felt it was worth the effort if the community
wants a secure routing system that is robust against determined and
professional attempts to abuse it. Filtering will not help. The data
must be trusted from the beginning. The people who can clarify what
address blocks have been allocated are the RIR's.

Geoff went on to say the price of a secure routing system is
ultimately cleaning up the data first so reliable and trusted
attestations can be made about address space.

Kurtis Lindqvist (Chair) agrees and sees this task as important as
making new delegations. The Bogon issue is important. It already
causes a lot of havoc, which amounts to cost to the LIRs. Kurtis
suggested it might be cheaper to clean the data up in the long run
than to leave it as it is at the moment.

Leo Vegoda (RIPE NCC Registration Services Manager) explained that
some old last resort registries had passed their allocations to the
RIPE NCC. However, not all of them had passed the documentation for
the assignments they had made. This means that the RIPE NCC cannot
easily validate database entries. Cleaning things up will take
considerable input from the operator community as well as the RIPE
NCC.

Daniel Karrenberg (RIPE NCC Chief Scientist) agrees with Leo and
although he is RIPE NCC staff he also agrees with Geoff Huston that
this is the RIR's core business and time should be spent on this task.

Ruediger Volk (Deutsche Telecom) agrees the data needs to be cleaned
and recommended to quickly setup RS set names or something similar
without delay.

Kurtis Lindqvist (Chair) asked the audience if they do NOT think the
RIPE NCC should spend time and effort to try to clean up the bogus
data?

- -Silence from the audience-

As there were no comments, Kurtis said that this is clear consensus.
The message (apparently) is that the community wants the RIPE NCC to
spend time and effort pursuing the goal to clean up the registration
data. He acknowledges it is probably going to cost some money so he
suggested to possibly making a standard reporting item on the RIPE NCC
to report on the progress of this task and then cost and plans can
come from there.

48.3 Chair - Add standard agenda item to report on progress of data
quality.

Y. Open Microphone

- -There were no Open Microphone discussions-

Z. AOB