RPS WG Minutes
Minutes taken by Cengiz Alaettinoglu

Changes to draft-ietf-rps-auth
Curtis Villamizar

Curtis first gave an overview of rps-auth and then went over the
changes to the draft.

as-block class is introduced to add hierarchy to the aut-num
objects. IANA owns the whole as range, and assigns blocks to
registries they further assign them to their customers. The chain ends
in aut-num objects. When an as-block object is created, the
authorization is sought in an as-block object that includes the range
most tightly. When an aut-num is created, the authorization is sought
in an as-block object that includes the range most tightly.

inetnum chain is similar. reclaim and no-reclaim attribute is added to
inetnum class to allow address lending/ownership. The default is
no-reclaim, that is address ownership. reclaim lets you delete
routes/inetnums that are more specific of the inetnum even if you are
not a maintainer for those objects. The rps-auth does not favor
lending over ownership or vice versa. The decision is upto the parties
involved.

The maintainer objects are chained together using the referral-by
attribute. It also allows an automated way of creating maintainer
objects. Any maintainer can create another one by including itself in
the referral-by and signing the transaction. referral-by also provides
an accounting trail when maintainers become unresposive.

When authorization is sought for a route object, the aut-num of the
origin attribute and either the most specific route object that is
less specific than this if it exists, or a most tightly covering
inetnum is used (if the most specific less specific route object is
not found).  Once the object is found, the maintainers in either
mnt-routes, mnt-lower or mnt-by are checked. For objects (other than
route), mnt-lower and mnt-by is checked. That is the semantics is an
or of the maintainers.

Flat names, such as nic handles, are scoped within the object's
registry. When nick handle co19 is used in an object in ripe database,
it is scoped to the nick handles in ripe, i.e. nick handles are not
globally unique. To refer to a nick handle in another registry, one
needs to prepend the registry name with :: to the nick handle, as in
ripe::co19.

Repository class and delegated attribute provides traversal rules for
hierarchical objects. They are now moved to the draft-ietf-rps-dist
document.

Authorization rule for objects with hierarchical names (e.g. as-set,
route-set) is added. The authorization is sought from the object named
by the portion of the object's name to the left of the right most
colon. For example, for object X:Y:Z, it is sought from X:Y.

There is a related document draft-ietf-rps-dbsec-pgp-authent. It will
advance together with rps-auth.

auth-override is changed so that it is only placable if the maintainer
did not do any updates in the last 60 days. It is still only active
after 60 days.

We still need wording for the security considerations section.

The working grouped is explicitly provided consensus on:
       - dont use mnt-routes to provide authorization to inetnum objects
       - any maintainer in mnt-routes, mnt-lower and mnt-by are
         authorized for route objects. any maintainer in mnt-lower
         and mnt-by for other objects.
       - to go to the last call after ietf on rps-auth and rps-dbsec-pgp


======================================================================
Changes to draft-ietf-rps-dist
Curtis Villamizar

Curtis first provided overview of the rps-dist document and
highlighted the changes.

Distributed IRR consists of rpsl as the external data representation,
rps-auth & rps-dbsec-pgp for authorization and authentication, and
rps-dist for transfer format and protocols.

rps-dist adds to rpsl the repository class and delegated and integrity
attributes. Repository objects helps you find other repositories. The
delegated attribute is used to move subsets of the data to other
registries. The integrity attribute tells whether an object is legacy,
authorized, on unauthorized. For example, an authorized object can
only be updated by its maintainer, but a legacy object can be updated
by an authorized maintainer even if that maintainer is not listed in
the object's mnt-by.

There is little distinction between a repository and a mirror. They
run the same code and protocols. However, the mirror does not
originate/own any data, it only stores data. There is also a
"lightweight" mirror. They are not required to store the entire data
set, hence they can not forward transactions. A light weight mirror
can be a router.

There are 3 ways to distribute transactions: a snapshot which is
analogous to ftp today, a transaction sequence request which is a
poll, and flooding request which is give me everything and keep
sendign indefinitely.

The data format summaries are only an issue for the implementors, not
to the users. A lot of examples are added. In particular complete
meta-objects used in an hypotethical transaction is included.

The refresh attribute of the repository object is replaced by the
hearth-beat-rate. Each repository sends hearth-beat objects to its
flooding peers (which forward these to their flooding peers) with this
rate to ensure that they are not down or behind a network partition.

The multicast data distribution and fragmentation and reassembly is
removed from the document. The sequence-begin object is renamed to
transaction-begin object. A transfer-encoding attribute is added to
the transaction-begin object to allow gzipped data transfers.

Curtis suggested that (upon request from RIPE and ARIN) the
people and role objects should not be distributed. The main reason is
the spammers. Instead queries should be referred to the appropriate
repositories. Also for attributes with email values, a nic handle can
be used to overcome privacy issue of emails. For legacy objects, the
emails can be stripped out before forwarding.

Harald did not liked the fact that the standard specified which
classes are not distributed. WG reached a consensus on allowing
selected classes not to be distributed, but leaving the decision of
which classes are not distributed to each registry. However, the
policy objects have to be distributed. There was also a per object
field, settable by the user, to allow redistribution or not. It was
objected by the WG.



======================================================================
RPSL Transition Report
David Kessens

David said the phase II of the transition is done. Every registry is
ready to move to phase III where the rpsl is the only data
representation. However, a flag date for phase III is not set and
every registry will decide on the date on their own pace.

David also wrote an RPSL to RIPE181 converter to ease moving to phase
III. He said this tool can only convert simple objects.


======================================================================
IRR Coordination issues
Abha Ahuja

Abha is maintaining a web page http://www.merit.edu/radb/list.html of
routing registries. The page contains for each registry where to get
their data, ftp sites, whois servers, mirrors and such. She is also
planning to make the data of each registry available for ftp from
their server. She also maintains a mailing list [email protected] for
routing registry operators. Send email to [email protected] to join.


======================================================================
RPSL Implementation in RAToolSet
Cengiz Alaettinoglu
this section of the notes are taken by Curtis Villamizar

 RPSL is 100% implemented in RaToolSet

 There are a lot of new RaToolSet featues and more to be added.
 RatoolSet 3.* Ripe-181 only
           >=4 RPSL only

 review usage of the RtConfig toolset

 review new features
   full community handling
   filter set, peering set, router set

 support new cisco prefix lists

 structures policy is now supported (RPSL refine and except)

 file cache (Rtconfig -f filename) useful for testing

 new options:
   -cisco_dont_do_maps
   access_list <filter>
   aspath_access_list <filter>

 switching from v3 to v4 RaToolSet:
   read the README and README.v4 and Changes and man pages
   command lines and defaults differ


======================================================================
IRRd transition to RPSL
Jerry Winters

Merit retired the old perl based server code this February. The
transition was flawless in that hardly anyone noticed. The resaon was
mainly performance. They are also considering round robin dns for load
balancing their server. The load on their server is increasing
exponentially.

Merit's plan for phase III is to have RPSL supported in IRRd and use
it. They are currently working on this.  The irrd query interface is
already fully RPSL capable. There are also two new commands to expand
as-sets and route-sets.

As for rps auth, they have the old pgp scheme they had in place. They
have not yet converted to rps-dbsec-pgp.

IRRd also allows TCP connections for object update. This is useful for
tools like aoe/roe/irrj.

IRRd has pipelined modules. These modules dont share data structures,
and perform small task such as
       convert ripe181 to rpsl
       rpsl/ripe181 syntax checking
       pgp authentication.
Hence, he expects supporting rps-auth to be easy. Cengiz suggested to
use rpslcheck for the rpsl syntax checking.

As for rps-dist, it is not supported yet. But they will eventually
implement it. Their first priority is to convert to RPSL and then
support rps-auth which are both more important than implementing
rps-dist.

IRRd has some other cool features: It can handle very large objects
better, it tells the line number of the error and put an error pointer
(i.e. <?>) where the error is seen, interactive user interface to
reconfigure IRRd without killing and restarting the server, access
lists for queries, updates and mirrors, filter specifications for what
classes to import and export to and from other registries, to get
statistics.

IRRj is a GUI java client that can do database updates.

Performance of IRRd is impressive. Their ~30M router configuration of
the mae-east router went under 3 minutes from over 4 hours. The file
is generated using RtConfig.

A gamma version of IRRd is freely available at www.irrd.net.


======================================================================
Closing Remarks

Curtis suggested a new work item for putting public keys to the route
objects for secure BGP. He and Charlie will write a separate new draft
and make it ready for the summer IETF. Bert, the AD present, approved
the work item.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.