Subject: Re: the problem that needs solving vs the problem as seen by RPSL

From: Randy Bush <[email-masked]>
Date: Sun, 6 Sep 1998 10:11:03 -0700 (PDT)

I generally agree, but have to amplify and quibble as usual.

> NOTE: in the case of a multi-homed prefix, there may be more than
> one AS which is allowed to inject the prefix, even though there
> is still only ONE AS in which it naturally occurs.

Actually, the circumstance in which this arises is best described as
proxy aggregation, which may occur avec or sans multi-homing.

Given RFC 1930, why would multi-homing cause a prefix to be announced
by two different ASs?

> There may also be cases where the "Injecting AS of Record"
> wishes to delegate "right of injection" to another AS
> (possibly an internal sub-AS which needs external
> visibility for policy reasons).

I can see this.  Note that it is often a more specific prefix,
i.e. an ISP loans part of their address space to a multi-homed
customer.

> Note that it is not dynamic and changes only as the result
> of administrative actions.  This is by design and is based
> on information the Address Registries must already keep on
> hand.

Specifically, it is administratively static and may be used to
check the dynamic system, route exchange via BGP.

> a daily FTP run would also solve the problem.

A few times a week we asked "I just registered the fix in the IRR,
would you please rebuild your ACL," by someone for whom we are
actually willing to rebuild mid-day.

> HINT - The Real World grades on RESULTS, not effort.

You get an E for effort.  You get a paycheck for product.

randy

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Sun, 6 Sep 1998 10:52:48 -0700 (PDT)

Mike,

You are right that RPSL does not solve the problem you described. The
problem you described is solved in the following draft:
	draft-ietf-rps-auth-01.ps
Your email may indicate the fact that you actually missed this
draft. If so, it would be nice if you could read it and comment on
it. You seem to have a lot of insight into the problem.

Here is an excerpt form its introduction:
  . . .
  The problem since has become more difficult.  New requirements have
  emerged.

 1.  The need to represent the routing policies of many organizations,

 2.  CIDR and overlapping prefixes, the increasing complexity of routing
     policies and the needs of aggregation,

 3.  the need to assure integrity of the data and delegate authority for
     the data representing specifically allocated resources to multiple
     persons or organizations,

 4.  the need to assure integrity of the data and distribute the storage
     of data subsets to multiple repositories.

  The RIPE effort specificly focused on the first issue [2].  Its
  predecessor, the PRDB, addressed the needs of a single organization,
  while the RIPE database was initially intended to address the needs of
  the European Internet community.  The RIPE database formats as
  described in [2] are the basis of current IRR.

  Routing protocols themselves provide no assurance that the origination
  of a route is legitimate and can actually reach the stated
  destination.  The nature of CIDR allows more specific prefixes to
  override less specific prefixes [9, 19, 8].  Even with signed route
  origination, there is no way to determine if a more specific prefix is
  legitimate and should override a less specific route announcement
  without a means of determining who is authorized to announce specific
  prefixes.  Failing to do so places no assurance of integrity of global
  routing information and leaves an opportunity for a very effective
  form of denial of service attack.

  The Routing Policy System Language (RPSL) [1, 15, 14] was a fairly
  substantial evolutionary step in the data representation which was
  largely targeted at addressing the second group of needs.  The PRDB
  accommodated CIDR in 1993 [13] and the RIPE database accommodated the
  improvements including explicit support for aggregation.  Transition
  of the IRR to RPSL is expected to occur in late 1988 [12].

  This document addresses the third group of needs identified above.

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
http://www.isi.edu/~cengiz    University of Southern California

---

From: "Mike O'Dell" <[email-masked]>
Date: Sun, 06 Sep 1998 14:20:21 -0400

the complexity of RPSL is not required to solve the problem that needs solving.

whether is another problem exists which could use RPSL is irrelevant for now.

	-mo

---

From: Bill Manning <[email-masked]>
Date: Sun, 6 Sep 1998 18:04:44 -0700 (PDT)

not that this will help, but a couple of efforts have tried to
move in this direction.  

check the rdi.int zone, in particular 4555.rdi.int
and the associated prefixes referenced therein.

ASMOP can place the listed AS delegations online, then its
a question of ISPs willing to keep the data themselves.

Should I make the change?
Would anyone be willing to make use of the AS delegation heirarchy?

--bill

---

From: "Mike O'Dell" <[email-masked]>
Date: Sun, 06 Sep 1998 21:19:28 -0400

the address assignment organizations are the authoritative source
of information w.r.t. what AS can originate a particular
prefix

anything else is hearsay and should be avoided

	-mo

---

From: Bill Manning <[email-masked]>
Date: Sun, 6 Sep 1998 18:28:08 -0700 (PDT)

> anything else is hearsay and should be avoided

Too True.  Hence -IF- I were to attempt such a thing, I'd work
from published sources.  ASN delegations tend not to be real dynamic
and lists are published by the delegation registries.

--bill

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Sep 1998 18:43:40 -0700 (PDT)

>> of information w.r.t. what AS can originate a particular prefix
> from published sources. 

If it is expected that ISPs use it, we are not interested in from what
source you would work, as well-intentioned as you might be.  

We would expect the zones to be DELEGATED by the IANA to the registries to
which the relevant address space is allocated, and for them to populate the
data.  I could probably write an I-D if you are really interested in this
approach.

I would find embedding RPS in the DNS as particularly sick and broken,
combining the worst aspects of two approaches.

randy

---

From: Geoff Huston <[email-masked]>
Date: Mon, 07 Sep 1998 12:04:09 +1000

Mike,

I admire your bravery in trusting irrelevant databases. :-)

The news from the trenches is that addresses are
being traded in all kinds of inventive ways, and
the address assignment organizations, and their databases,
remain willfully ignorant of such transactions. Accordingly
there is very little that we can trust as a fair arbiter
of an assertion of prefix advertisement.

   Geoff

---

From: "Mike O'Dell" <[email-masked]>
Date: Sun, 06 Sep 1998 22:46:18 -0400

you miss my point.

anything done by anyone except the registries would be suspect
from first principles, no matter how much in a spirit of
public service it was offered.

if your goal is a "disproof of non-existance" to encourage
the address assignment authorities to pick up the ball and
run with it, then there may well be merit in your offer.

	-mo

---

From: "Mike O'Dell" <[email-masked]>
Date: Sun, 06 Sep 1998 22:49:30 -0400

OK, so they are not doing their job.

why not fix the root cause rather than invent a source
of new bugs?
	
	-mo

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Sep 1998 20:03:37 -0700 (PDT)

> RPS oozing out of Resource Records would be a true
> abomination worthy of unending suffering in the next world.

roam.psg.com:/usr/home/randy> dig +norec @ns.isi.edu. 4555.rdi.int. axfr       

; <<>> DiG 8.1 <<>> +norec @ns.isi.edu. 4555.rdi.int. axfr 
; (1 server found)
$ORIGIN 4555.rdi.int.
@                       1d12h IN SOA    dot.ep.net. hostmaster.ep.net. (
                                        1925630         ; serial
                                        3H              ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        1d12h )         ; minimum

                        1d12h IN NS     dot.ep.net.
                        1d12h IN NS     ns.isi.edu.
                        1d12h IN TXT    "RPS 0000 person:Bill Manning"
                        1d12h IN TXT    "RPS 0001 descr: LosAngelesPeering exchange"
                        1d12h IN TXT    "RPS 0002 aut-num: AS4555"
                        1d12h IN TXT    "RPS 0003 as-in: from AS226 100 AS226"
                        1d12h IN TXT    "RPS 0004 as-in: from AS226 110 AS4554"
                        1d12h IN TXT    "RPS 0005 interas-in: fron AS226 10.10.1.1/32 (pref=3) AS4554"
                        1d12h IN TXT    "RPS 0007 admin-c: WM110-NSI"
                        1d12h IN TXT    "RPS 0008 tech-c: WM110-NSI"
                        1d12h IN TXT    "RPS 0009 remarks: The first live example of this technique"
                        1d12h IN TXT    "RPS 0010 remarks: Check the SOA for mnt-by, changed data"
                        1d12h IN TXT    "RPS 0011 source: DNS"
                        1d12h IN TXT    "RPS 0012 route: 198.32.2.0/24"
                        1d12h IN TXT    "RPS 0013 route: 3ff3:0800/24"
                        1d12h IN SOA    dot.ep.net. hostmaster.ep.net. (
                                        1925630         ; serial
                                        3H              ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        1d12h )         ; minimum

;; Received 17 answers (17 records).
;; FROM: roam.psg.com to SERVER: 128.9.128.127
;; WHEN: Sun Sep  6 20:02:39 1998

---

From: "Mike O'Dell" <[email-masked]>
Date: Sun, 06 Sep 1998 22:48:23 -0400

RIGHT ON, BROTHER!!!!

	-mo

---

From: Joe Abley <[email-masked]>
Date: Mon, 7 Sep 1998 16:37:11 +1200

>                         1d12h IN TXT    "RPS 0005 interas-in: fron AS226 10.10.1.1/32 (pref=3) AS4554"

fron?

-- 
Joe Abley <[email-masked]>      Tel +64 9 912-4065, Fax +64 9 912-5008
Network Architect, CLEAR Net                      http://www.clear.net.nz/