Subject: Re: signing rpls, etc....

From: Sandy Murphy <[email-masked]>
Date: Wed, 9 Sep 1998 08:27:08 -0400 (EDT)

I've been trying to madly get caught up on the email from over the weekend,
mostly to try to glean what each person's objection is, starting with mo's
"signing rpsl,.... let's not reinvent the same flat tires" comment.
But I can't let this one pass unanswered:

>We are losing sight of what is required by an ISP today. Two issues I see:
>- origin authentication - how do I know that what I'm hearing is what someone is e
>ntitled to send me.

THIS IS NOT ORIGIN AUTHENTICATION!!!!!!

THIS IS ORIGIN AUTHORIZATION!!!! 

The two are very different problems and you use very different
techniques to solve them.  For origin authorization, you need some
noted authority who can attest to the authorization of the apparent
source of the information you receive.  For origin authentication, you
use a digital signature transmitted with the data you receive.
Verification of the digitial signature gives assurance as to both
source authenticity and integrity of the data.

[Now of course to verify the digital signature you usually need some
assurance of an entity's binding to the public key used in the
verification (i.e., the entity's authorization to use the public key,
attested to by some authority) and then we get into the whole PKI
problem.]

But if you're not worried about bad guys or bad routers injecting
valid (authorized) origins at invalid points or times, then maybe you
don't need the digital signatures/verifications.  (Maybe.  Personally,
it sounds like an big red "DO NOT PUSH" button waiting for the right
malicious person or unlucky coincidence.)  Right now, it seems this
isn't the threat people are worried about.

Authentication is assurance that you know to whom you speak -- with no
assurance that the speaker is allowed to do what they request.

Authorization is assurance that a request is allowable -- with no
assurance that the requestor is who they say they are.

--Sandy

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Sep 1998 13:50:43 -0400

In message <[email-masked]>, Randy Bush writes:
> 
> >   3.  Even if you choose not to publish you policy, and you decide
> >       that some other representation of policy is more suitable to
> >       your needs, if others find RPSL policy capabilities useful and
> >       find the exchange of RPSL policy information useful, should you
> >       interfere the progress of RPSL policy and aggregation
> >       capabilities just because you chose not to use them?
> > 
> > Regardless of the answers to the first two questions, the answer to
> > the third is clearly "no".
> 
> wrong.  because it obscures with a massive mess what should be a simple
> thing for us all to use.
> 
> would you feel it reasonable for this email to have an additional 800%
> overhead in TeX, html, smgl, and 30 other pounds of syntax?
> 
> randy

Randy,

The aut-num is a completely separate RPSL object and no one is forcing
you to read other peoples aut-num objects.  If you are not interested,
don't read them.  It won't change what is in the route objects,
inetnums, and as-blocks (AS assignment and policy specification are
separated in rps-auth into as-block and aut-num).

Defining an aut-num and a means to represent policy in the aut-num and
RPSL obscures nothing in the database.  Perhaps you are arguing that
the RPSL spec should be split in two with a separate document defining
only the aut-num and policy so as not to obscure what is in the route
object, inetnum, and other objects that you want to use.  That's all
fine and well, but route, inetnum, are mainly defined in RIPE-181 and
except for a few refinements such as aggregation fields in routes are
unchanged in RPSL.

Removing the obscurity that you speak of may be a task for an
informational RFC describing the use of the registry minus anything
related to the aut-num policy.  Is this a good idea in your opinion?

Curtis