Thanks for comments. My interest was to continue the discussion that Job hosted at RIPE70, and to get to some guidelines for those that need to exploit temporary redirection with BGP; whether customers or providers of services. Job, thanks for your observation that "the RIPE database supports this, you can create multiple route-objects covering the same prefix but with different "origin:" values.". Randy states agreement. However, this does conflict with some other Internet documents, like BCP-6. That can only be confusing and may inhibit global consensus. If IETF BCP documents are inaccurate then the RIPE community has some responsibility to point it out. The dual authorisation that RIPE requires on a ROUTE object seems an unnecessary hurdle, and gives rise to the cross-border concern that Job raised in the BoF. The consensus from RPKI seems to be that the inetnum maintainer has the authority to grant ROA. I do not know the history of why RIPE asks for AS maintainer also. Is there still some good reason? (If so, I am puzzled that it does not apply to RPKI, but that is a separate discussion). Removing the AS maintainer from the route object Creation authorisation seems to solve the cross-region problem. Are there reasons not to do this? Job mentioned that RaDB seems to have neither authorisation requirement, so creating a global view of the IRR is challenging without policy agreement leading to trust on these things. Summary: 1/ ask IETF to update BCP-6. Is this something RIPE NCC should do? 2/ discuss why AS maintainer authorisation is required for RIPE ROUTE object Creation. I subsequently read the article by Den Is May 2015, which comments that there is no written policy for IRR. Steve
Hi all, On Wed, Jun 24, 2015 at 10:59:45AM +0000, snash wrote:
Thanks for comments. My interest was to continue the discussion that Job hosted at RIPE70, and to get to some guidelines for those that need to exploit temporary redirection with BGP; whether customers or providers of services.
Welcome! :-) Just a note (applicable to all db-wg participants): please send emails in PLAIN TEXT, rather then HTML. This will make it easier for others to digest your information and respond. For instance I do not see colored text in my terminal based mail client. The mailing-list archive also works better with just plain text messages. Also use in-line replies rather then top quoting.
Job, thanks for your observation that "the RIPE database supports this, you can create multiple route-objects covering the same prefix but with different "origin:" values.". Randy states agreement. However, this does conflict with some other Internet documents, like BCP-6. That can only be confusing and may inhibit global consensus. If IETF BCP documents are inaccurate then the RIPE community has some responsibility to point it out.
I don't see how this is confusing. The BCP states "Generally, a prefix can should belong to only one AS", and generally, this is true.
The dual authorisation that RIPE requires on a ROUTE object seems an unnecessary hurdle, and gives rise to the cross-border concern that Job raised in the BoF.
For historical perspective and discussion you could review these two threads: https://www.ripe.net/ripe/mail/archives/routing-wg/2006-September/000719.htm... https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004597.html
The consensus from RPKI seems to be that the inetnum maintainer has the authority to grant ROA. I do not know the history of why RIPE asks for AS maintainer also. Is there still some good reason? (If so, I am puzzled that it does not apply to RPKI, but that is a separate discussion). Removing the AS maintainer from the route object Creation authorisation seems to solve the cross-region problem. Are there reasons not to do this?
All of the above are valid questions.
Job mentioned that RaDB seems to have neither authorisation requirement, so creating a global view of the IRR is challenging without policy agreement leading to trust on these things.
I have trouble understanding what you mean with the above paragraph. Can you rephrase or provide examples?
Summary: 1/ ask IETF to update BCP-6. Is this something RIPE NCC should do?
Anybody can propose a change. But this proces might be long and challenging. Please review https://www.ietf.org/newcomers.html
2/ discuss why AS maintainer authorisation is required for RIPE ROUTE object Creation.
I encourage discussion on this subject. Kind regards, Job
this does conflict with some other Internet documents, like BCP-6. That can only be confusing and may inhibit global consensus. If IETF BCP documents are inaccurate then the RIPE community has some responsibility to point it out.
the routing folk at ietf have been well aware of this for many years.
The dual authorisation that RIPE requires on a ROUTE object seems an unnecessary hurdle
and semantically incorrect
The consensus from RPKI seems to be that the inetnum maintainer has the authority to grant ROA.
[ sorry to be pedantic about terminology. but this is a complex area and rigor is needed to keep out of the weeds. ] the rpki is a database, it has no ability to consent. it also has no idea what an inetnum: is. i think you mean that the design of the rpki is that an address resource holder is the sole authority over what ASs may announce that resource. that any CA covering the address resource may authorize ROAs for that resource.
I do not know the history of why RIPE asks for AS maintainer also. Is there still some good reason? (If so, I am puzzled that it does not apply to RPKI, but that is a separate discussion).
the discussion when the rpki was designed was that the AS asserts its consent through bgp.
1/ ask IETF to update BCP-6.
i am sure you have better ways to spend your time. randy
participants (3)
-
Job Snijders -
Randy Bush -
snash