[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sig-policy] Comments on prop-059-v001: Using the Resource Public Key Infrastructure to construct validated IRR data
Geoff Huston wrote:
Firstly, the semantics of the two objects differ. A ROA is an
"authority" granted by a prefix holder that nominates an AS as a
potential originating AS. The key observation here is that the AS
holder is not necessarily aware of this ROA, or even necessarily aware
that such an authority has been granted or published, let alone be
prepared to announce the prefix as originating from this AS. The AS
holder cannot cause such an authority to be removed or revoked. In
contrast, a Route Object is a statement by an AS holder to the effect
that the AS is currently, or may in the future, announce a
particular prefix as originating from this AS.
Randy Bush wrote:
this is completely false. a route: object is a statement by the prefix
owner of what as may announce, just like a roa; surprise surprise.
I disagree that my characterization of a Route Object is "completely
false."
A route object is not simply a statement by the prefix holder of what
an AS may announce, but includes the explicit authorization of the AS
holder.
The basis for this interpretation of the authority model of a route
object is based on:
1 - my interpretation of the text in RFC2725, Section 6, page 8, para
3, which states:
"The addition of a route object must be validated against the
authorization criteria for both the AS and the address prefix."
2 - Section 2.5.5 of the RIPE Database Update Reference Manual
(http://www.ripe.net/db/support/update-reference-manual.pdf) is
consistent with the RFC in requiring that route object creation
must satisfy several authentication criteria, including that:
"It must match the authentication specified in the aut-num object
referenced by the "origin:" attribute of the route object
submission."
3 - The RIPE IRR code at ripedb/src/modules/au/au_rpsl.c, in the
routine called route_rpsl_create() where aut-num authentication is
explicitly checked.
If I were to edit my original posting commenting on this proposal to
clarify the argument I was making, I would change the last sentence
quoted above to read:
"In contrast, a Route Object is a statement by an AS holder,
corroborated by the prefix holder, to the effect that the AS is
currently, or may in the future, announce a particular prefix as
originating from this AS."
In reviewing the remainder of my original comment I do not believe
that this edit alters the overall argument put forward, namely that in
my view there are disadvantages to this proposal, arising from the
observation that the explicit authorization of the AS holder is
missing in the creation of the synthetic RPSL Route Object from a ROA
(as the AS holder is not required to sign a ROA), and that this
differs significantly from the authentication criteria used in the IRR
context for route object creation. This difference causes consequent
issues with the appropriate interpretation and use of these synthetic
route objects, particularly in the case of filter construction, in the
manner described in my original comment on this topic.
Geoff
Disclaimer:
To be perfectly clear, yet again, to those who may otherwise
misconstrue the context of these comments, the above is a personal
comment, and in no way is intended to reflect any position of the
APNIC Secretariat, now or in the future.
