Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/rps/rps-minutes-97aug.txt

Text File | 1997-10-10 | 15KB | 313 lines

Minutes of the RPS session
39th IETF - Thursday, 08/14/97, 9:00am - 11:30am

Chairs: Cengiz Alaettinoglu, Daniel Karrenberg (DK58)
Reported by: Joachim Schmitz (JS395-RIPE)

* Agenda

- Updates to RPSL specification (Cengiz Alaettinoglu)
- Ideas for RPSL extensions (Cengiz Alaettinoglu)
- RPSL transition draft (David Kessens)
- RPSL application draft (David Meyer)
- Security extensions for RPSL (David Meyer)
- autnum authorization and cross notification (Carol Orange)
- BIRD - will it fly? (Cengiz Alaettinoglu)
- RAToolSet news (Cengiz Alaettinoglu)
- roe working experience (Joachim Schmitz)
- Multicast additions to RPSL (Susan Hares)

The agenda is more detailed than the one previously posted. There were no
changes to this agenda.

* Updates to RPSL specification (Cengiz Alaettinoglu)

Most changes to the RPSL specifications were editorial. They include semantic
changes in the structured policies section, and cleaning up a
misspecification
there; "mnt-by" is now a list of maintainers, route set members now contain
operators. To distinguish from newer BGP versions, the term "BGP" was
replaced
by "BGP4"; "RIPv6" is now called "RIPng". Some dictionary elements which were
easy to add include new rp-operators and new data types.
The current version is draft-ietf-rps-rpsl-03.txt and will be put forward to
IESG as proposed standard.

* Ideas for RPSL extensions (Cengiz Alaettinoglu)

The work defining RPSL extension procedures was done by Cengiz Alaettinoglu,
David Meyer, David Kessens, and Randy Bush). One major element is that
extensions will not carry version numbers. Extensions should be done
systematically on
1. extend dictionary
2. new classes
3. new attributes to existing classes
4. extend existing attributes
while taking into account that everything must stay backward compatible.
There
is no precedence on points 2 and 3 - this depends on the special case.
Finally,
extensions must be published as an IETF document.
RPSL is a powerful language. It covers to areas: configuration of routers and
description of policies. Whether these two shall be better distinguished or
even separated was not a major issue. For the time being the general feeling
was to keep it together.

* RPSL transition draft (David Kessens)

There was a new version of the transition draft available as
draft-ietf-rps-transition-01.txt. It describes three stages for the
transition
from old RIPE-181 style policy representations in routing registries to the
RPSL representation:
- testing and playing
  The database software will be installed with RPSL extensions on a test
  database for testing purposes. Actually, some of it has already happened.
- RPSL database server mirrors RIPE-181 server
  Two copies of the databases are kept in parallel. Updates will be possible
  to both servers. Small banners on the output distinguish the difference for
  the users. The RAToolSet will be ready to use with RPSL. Tutorials how to
  use RPSL will be held at NANOG, RIPE, APRICOT
- RPSL is default in the IRR
  While RIPE-181 updates will still be possible they will be automatically
  converted to RPSL, all servers apply RPSL.
The conversion tools are also separately available at
http://www.isi.edu/ra/rps/transition/ where other functionality (eg query of
old and new database) can be tested. After the Munich IETF meeting the mirror
frequency of the test database will be daily from real life registries, later
on it will be turned into a real time mirror (regarding the test database).
It was suggested to add a remark to a converted RPSL object notifying of the
fact that the object shown was converted from RIPE-181, and when the
conversion
occured.
Stage 2 of the transition process will occur in December '97, for stage 3
there
is no specific date yet because the time to educate users is unpredictable.
The question whether the converter between policy descriptions runs 100%
secure
was answered that from 120,000 objects only 15 could not be converted with
automated tools.
Changes to details of the transition plan are sure to happen, depending on
the
outcome of discussions with the routing registries. A new version will be
prepared after the Munich IETF meeting by David Kessens and Carol Orange. The
transition document will remain internal to the RPS working group and not
enter
the standards track.

* RPSL application draft (David Meyer)

There were not too many comments on the current version of the RPSL
application
draft draft-ietf-rps-appl-rpsl-01.txt, the most notable one being on the use
of
communities. Input from NANOG on RPSL was whether syntax "<AS1>" compared to
simply "AS1" is not a bit overloaded. This is more a language issue than an
application issue, and was not considered important. From the audience usage
of terminology was criticized - terms like schemes, classes, attributes,
values
and others are seemingly used without clear definition. This must be cleaned
up. Input will be provided to the authors of the application draft.
In the current state the application draft will not be submitted to IESG
because it could not yet be tested on fresh people in practice. Therefore it
will remain a working group document until spring '98 incorporating
experience
from the tutorials (as described in the transition process). Then it should
become an informational RFC.

* Security extensions for RPSL (David Meyer)

According to D.Meuer the provider community asks for better security measures
with regard to RPSL. Main objectives are
- data origin authentication
- data origin integrity
- data privacy
All of this should be supplied as simple as possible. D.Meyer suggests to add
a new field to the maintainer object, denoted "key". It contains the public
key
of this maintainer. On every object a signature field is added (including the
maintainer itself) which contains the signature for the object. The object as
a whole is signed. An issue is the initial verfication of the maintainer to
get
the process started. D.Meyer then described a possible implementation using
the
MD5/RSA algorithm, and showed how it may work in operation. Data privacy is
still an open question. Discussion in the audience showed that storing
private
data in the registries opens a can of worms
- the registries do not have any control about what is stored (implications
are
  similar to anonymous ftp)
- the database is meant to be public, storing private data there is contrary
  to the original purpose
- it should probably not be ruled out completely but then be left to the
  implementors
This falls in with the topics and discussions in the RIPE security task force
which asked D.Meyer to join in. The RPS working group decided that the
presentation by D.Meyer will become a document of the working group. It is
currently available from http://www.antc.uoregon.edu/IETF/Munich97/RPSL/

* Autnum authorization and cross notification (Carol Orange)

C.Orange presented some new developments in the RIPE database software
initiated by the RIPE Routing working group. These new developments even
though
they are not directly related to RPSL include changes or additions to
existing
objects, namely the autnum object and route objects which are also elements
of
RPSL. However, these changes are not related to routing policies but to
schemes
enhancing security for the database.
Autnum objects will carry a new "mnt-route" attribute which has a maintainer
as
value. Only those maintainers are allowed to create/delete/change route
objects
for the origin this autnum object describes.
In addition, notification is extended for route objects describing
overlapping
IP ranges. Notification occurs on creation and deletion of overlapping route
objects. The submitter of the according database changes is always notified.
Owners of existing route objects may get notified if they add a new
"crs-notify" attribute to their autnum or route objects. The cross notify
attribute takes maintainers as value.
This raised the question about a registered default route (RADB). Anyone will
be notified of overlaps because all routes overlap with the default. If there
are changes to the default route object all maintainers in the routing
registry
will be notified! This can however easily be avoided by treating the default
route separately in the database software.
People shall be referenced via NIC handles alone. Yet, person objects do not
require a mail address. In this case notification will not work. However,
users
are supposed to be intelligent enough to only reference person objects for
notification purposes if they contain a mail address. It may also be an issue
to find a person object from another database. This was referred to the RIDE
working group.
Further possible extensions with regard to RPSL may include a cross notify
attribute in route-sets and AS-sets, or route-sets may be used as parameters
for the cross notification field. Cross notification may also be extended to
hierarchical sets. This is an ongoing discussion in the RIPE working groups.

* BIRD - will it fly? (Cengiz Alaettinoglu)

BIRD is a suggestion for a distributed database system developed by Cengiz
Alaettinoglu, Ramesh Dovindan, David Kessens, and Wee San Lee. IRD stands for
Internet Registry Daemon, and the letter B was added for convenience. BIRD
consists of several parts:
- user interface: here queries (whois, RAToolSet) occur, updates are made,
etc.
  Some kind of legitimation is desirable (sign on, challenge, cookies) but
  details are yet to be discussed.
- registry interface "RPM" (reliable policy multicast): a reliable mechanism
  to distribute policy data via multicast ensures consistency among single
  registries participating in the IRR. Talkers and listeners will be hard
  coded in the BIRD software sharing the same group address.
  All participants using BIRD must trust each other, the data sent among them
  however will be authenticated. Object keys will be globally unique,
integrity
  be checked locally first, then objects will be sent out, and in case of
  clashes all conflicting objects deleted. In a whole to achieve consistency
  is a nontrivial problem, as discussion in the audience showed. Issues will
  be written up and further discussed in the mailing list.
- scheduler, syntax checker, object storage, indexer: the scheduler
distributes
  work among the different elements of BIRD. The syntax checker is not
limited
  to registry objects but distinguishes e.g. classes, attributes, privileges,
  schema and dictionary objects. The object storage keeps the data including
  caching to improve performance. With the indexer there are many open issues
  which are not yet resolved. The indexer gdbm currently used needs way too
  much time to create an index of the database. Therefore, other mechanisms
or
  improvements must be considered taking crash recovery into account.
For BIRD, security is also a major issue. This is not limited to
communication
among participants in the IRR using BIRD, but extends to the user interface
as well. Objects submitted to the IRR must be signed at least. The discussion
about the earlier presentation of D.Meyer already showed that this involves
several issues. To come to a definite solution, it should first be thought
about what is wanted and then how to accomplish it by signing or other
methods.
In addition, the participants of BIRD must somehow be selected. In principle,
anybody could become a registry. To keep data consistent and reliable some
checks must be built in. Discussion revealed that not everybody should be
able
to reveive registry data via BIRD (on the RPM interface) but anybody should
be
allowed to send data (on the user interface). However, a mechanism to select
participants in the IRR must still be found.
With all the open questions and issues it can not yet be told whether BIRD
will
ever fly but work is continuing. A very limited demo already exists today.
The
alpha release is planned for December '97.

* RAToolSet news (Cengiz Alaettinoglu)

C.Alaettinoglu intended to have RAToolSet version 4.0.0 available beyond the
current alpha release before the Munich IETF meeting. Time constraints
prohibited this early distribution. It is now considered to become available
around mid September. The most important changes include extensions to roe
(route object editor), and general RPSL support (especially import/export
attributes in RIPE-181 type registries).

* roe working experience (Joachim Schmitz)

J.Schmitz presented his working experience with roe, the route object editor,
being part of the RAToolSet. roe is a C++/Tcl/Tk program to view and
manipulate
route objects registered at any routing registry, and to compare them to real
life routes. Route objects are taken from the routing registries, real life
routes are supplied by the output of "show ip bgp <AS reg exp>" from Cisco
routers. roe is easy to install and very easy to use. It could have more
configurable parts, and should be more verbose in what it does in each phase.
Depending on the AS studied, roe might need quite some resources. Performance
of roe depends on the amount of data, availability/load of routing registry
servers, and network performance.
In a whole roe is found to be particularly useful to check for consistency of
routes and corresponding object entries in routing registries, to synchronize
route object entries in different registries, to find erroneous route
objects,
or to detect missing or superfluous routes or route objects. These tasks are
very easily performed because roe compares large sets of data in a clear
presentation, while working on registry data is simplified by easy selection
and the usage of templates.
As a final conclusion roe is considered a "must" for any ISP working with
routing registries.

* Multicast additions to RPSL (Susan Hares)

S.Hares presented a number of transparencies where she explained and
clarified
the things earlier said and discussed in the RPS working group (either on the
IETF, or in the mailing list) and the Multicast working group.
One of the major topics definitely was the question: what is a policy? She
then
distinguished between published and unpublished policies and detailed her
thoughts about what a multicast policy is, e.g. referring to RPF checks, or
to
tree building. In the end she wants to identify where the current draft fits
in, whether it is still unpublished policy, and whether it shall be
published.
In a whole this presentation has built a base for further discussions.

* Work items

The following work items exist for the RPS working group
- the RPSL definition draft is going to proposed standard
- the RPSL application document will be kept waiting until further experience
  is gained in spring '98 with the usage of RPSL. Then it will be proposed as
  informational RFC
- the transition document from RIPE-181 to RPSL will remain internal to the
  RPS working group, and will be reworked
- the security document will be treated as a working group document and will
  be discussed in the working group
- the multicast topic will be revisited next time
A separate document on a minimum set required to satisfy a policy definition
is
not needed because this is already part of the RPSL definition document.

J.Schmitz 08/20/97