- A. Preliminaries
- Joachim Schmitz opened the working group, passed the attenders' list
around and asked for a volunteer scribe. Joao Luis Silva Damas volunteered as
scribe. There were 46 participants in the session.
The working group agreed
upon the minutes of the previous meeting, and accepted the draft agenda earlier
circulated on the mailing list.
Review of actions RIPE 28
- Action 27.R1: Carol Orange, RIPE NCC
- To implement cross notification in the RR with modifications as agreed at
the meeting of the 27th RIPE Routing WG.
- Action 27.R2: Carol Orange, RIPE NCC
- To implement aut-num authorisation in the RR
Both actions were still open. The reason for this are the project of rewriting
the whole database software, and preparation for the transistion to RPSL. Due
to shortage of staff these two actions could not be dealt with.
- Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and
Christian Panigl).
- To write up the results on route flap damping in a RIPE document
The final draft of the paper was circulated on the mailing list (see below).
This action was therefore closed.
- Action 28.R1: Carol Orange, RIPE NCC
- Contact other RR on the topic of distributed authorization
Carol Orange met with representatives from other RR (see below). This action
was therefore closed.
- B. Current Developments
- RIPE Document on Route Flap Damping (Christian Panigl)
Input has been
gathered from the community, and a report on bugs in the Cisco IOS has been
added (regarding improper counting of flaps and early onset of damping). The
final draft of the paper was circulated on the mailing list shortly before this
RIPE meeting, with a last call for comments. If there are no further additions
from the community this final draft will be published as a RIPE document after
the meeting (now available as RIPE-178 from the RIPE ftp/web servers).
Most of RIPE considerations on route flap damping have been taken into
account and put in the internet draft currently being written by Curtis
Villamizar, Ravi Chandra, and Ramesh Govindan. However, the scope of their
draft goes beyond the RIPE document. Their paper is available from
http://engr.ans.net/route-damp/
RPSL Update and Report from IETF 40 (Carol Orange)
Unfortunately, there is a delay in implementation of RPSL due to
unforeseable circumstances. Nonetheless, implementation will continue, just as
other work around RPSL does:
- There is a new version of the RAToolset at ISI with partial support for
RPSL and there will soon be a new one with full RPSL support.
- The RPSL draft has moved to proposed standard.
- A draft from David Meyer regarding extension of RPSL was accepted.
- A new routing class has been defined providing alternate ways of
specifying policy.
Another major topic at the IETF was security for the IRR. This arises from the
fact that if IRR information is going to be used for configurations on routers,
e.g. for filters. The IRR information must be trusted and a clear authorization
scheme must exist. The main issues seem to be data integrity, prevention of
accidental or malicious misconfiguration and prevention of improper use of
adress space. In order to base the BGP filtering scheme on the data in the
routing registry, the data must be properly tied to the IP assignment data
maintained by the IP registries. In the RPS WG of the IETF where this was
discussed, it was noted that this will be more diffucult in the ARIN and APNIC
regions where the routing and IP registries are separate.
With these requirementes the need arises for communication between IP
registries and routing registries. The European internet community has an
advantage here.
- C. IRR Authorization (Carol Orange)
(swapped in order with Gerald Winters' presentation due to problems with the
overhead projector)
- The goal of IRR authorization is to make BGP routing in the Internet more
secure which depends on proper registry data. This is meant to prevent
accidental or malicious misconfigurations. Under this prerequisite it is
mandatory to define a scheme which allows an ISP to decide which routes they
may trust.
This calls for a definition of the IRR: A proposal is: "The
IRR is a place that reflects what is announced in the Internet and what is
permitted to be announced."
With AS numbers the path of authority is clear.
IANA -> Regional registries -> ISPs
This works in Europe but not elsewhere. Actually, it is possible to look
for free AS numbers, just use them and register them in the IRR. The authority
of AS numbers is not checked by the other routing registries. There have been
several occasions when this lead to routing problems.
The distribution of IP numbers works similarly. There seems to be agreement
in that nonallocated IP numbers should not be routed. However, there is not yet
an accpeted mechanism for providing this.
One solution could be to delegate authority for a block of IP numbers in
the routing registry at the time of IP allocation by creating an object for the
full block that can then be subdivided by the ISP. However, this would tie IP
allocation to routing entries.
Joachim Schmitz noted that people should be aware that this imposes
restrictions on what can be registered and is a big change from current
practice. Comments on this paradigm shift are welcome.
- D. Using Internet Routing Announcements to Identify Incorrect IRR Data
(Gerald Winters)
- Most of the results presented here are based upon PAIR. PAIR is the
Policy Analyzer of Internet Routing.
One goal is to compare policies stored on IRRs versus real BGP information in
real time. Several tools have been developed for looking at announcements
- route search tool
- route collation tool
- AS path analyzer
among others. These tools and a few others provide opportunities to identify
inconsistencies, and to clean up the routing registries from obsolete or wrong
data. The next question arises as to how easy it would be to do this clean
up. First it must be known which information should be stored on the IRR.
However, this depends on the definition of the IRR. Several have been proposed:
- a repository of current internet policy
- a repository also for private routing information
- a place to experiment
In the following, a series of examples of actual objects stored on RADB were
shown:
- objects with very short prefixes, e.g. 0.0.0.0/1
- private/non routable space, e.g. 10.0.0.0/24
- withdrawn routes several years old
- non aggregated (but aggregatable) routes
- holes in "non owned" aggregates (either reasonable or
mailicious)
- registration of all subblocks of an aggregate to prevent the above
- extremely old objects
- empty policy AS objects (39% of those on RADB)
Some of this may look inadequate to some and actually be perfectly reasonable.
The question is: What to do with these objects?
As a first step a definition for the IRR is required. Any further action
can then be based upon this definition. However, to come to this definition
consensus must be found that cleaning is needed, and we must define what can be
done. The IRR will probably need some power over object removal to clean up
data. Yet, the IRR can not decide on its own - community approval is needed.
The presentation triggered some discussion. Miguel Angel Sanz asked whether
any coordination or contact exists between the different Routing Registries
regarding this topic. Gerald Winters replied that RIPE, RADB, and ANS are
coordinating, but MCI and CANET are not. Carol Orange added that closer
coordination has started recently and is being promoted. There have been
discussiones about the authorization scheme. However, we need to take into
account that different registries serve different purposes: RIPE and RADB are
publicly available but MCI runs a RR for their own purposes.
There were remarks regarding the fact that the importance of the
correctness of data in IRRs depends on them being used for router configuration
and for that to happen better tools are needed. Joachim Schmitz replied that
large ISPs currently tend do so and request their peers to do so as well.
There were questions regarding the licensing of RADB code and Gated code.
Gerald Winters and Jake Kuhon from Merit replied that the funding scheme for
Merit is changing right now. Work on Gated has been resumed at Merit. The
details on licensing will depend on the final scheme for Merit. Information
will be available from Merit soon.
Richard Almeida made remarks on the differences in registering procedures
between Europe and the US and a general comment on the situation being better
in Europe.
Questions about followup on aggregation work from previous meeting met the
reply there has been no progress recently.
- E. Reports from other WGs
- There was no current input from other WGs.
- F. AOB
- Since there was no AOB the meeting was closed.
you are here: RIPE -> RIPE Working Groups -> Routing
