Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)
On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard wrote: > Please don't. > > You're not doing the routing security ecosystem any favours by doing > this. The routing security ecosystem is less of a concern to me than the lone network engineer at some water district or county who were about to have a really bad / confusing few days while they tried to figure out why their Internet is somewhere between slightly and completely broken due to no action of their own. > Couple of reasons why: 1. this isn't your data and this is an > unexpected action on the part of the registrants, The registrants had a year to fix this themselves, and they didn't, which implies to me that they are unaware of the issue. How can something be unexpected to those who are unaware? > 2. this is a sure-fire > way of accumulating even more cruft in ALTDB in a way which is > troublesome to clean up afterwards, Is it? What is terrible about cruft sitting in IRR databases? It doesn't cause conflict with anyone else announcing their new address space from any other ASN. Cleaning it up is easy too. Publish an RPKI ROA for your space. We will automatically delete any route objects which disagree with an RPKI ROA. The routing security ecosystem should be doing that anyways. > 3. there are several thousand > objects in there which are already marked as proxy registrations, and > are already likely to be inaccurate, And there's lots of non-proxy registrations which are inaccurate too. The fact that RPSL was so contrived and routing security has been so sidecar for decades that carriers have found it easier to create proxy registrations vs getting their customers to go spend money on an RADB account or figure out this IRR thing in general means that proxy registrations are a reality we live in. IRR objects lacking any kind of expiration date was a failing of the original design. Proxy registration or not, when a company shuts down operations, there is kind of by definition no one left around to care about cleaning up their IRR records. If RIRs published RPKI ROAs for unallocated space to AS0 to give us an authoritative way to know that the address space is defunct, clean up could happen automatically. I looked into using the RIR registration databases to try and find objects which predate the current allocation, but even that data isn't clean enough to trace which objects are actually "stale" in some definition of the term. > 4. you're losing authentication > information for people to self-manage their registrations Anyone on that list who would like to self-manage your IRR objects, PLEASE email me saying so. Bonus points if you include a reason why you waited until T-0 to change your mind on managing them. -- Kenneth Finnegan http://blog.thelifeofkenneth.com/ On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard wrote: > > Kenneth Finnegan wrote on 04/04/2022 21:05: > > I've taken it upon myself to create > > proxy registrations for all of these prefixes in ALTDB. > > Please don't. > > You're not doing the routing security ecosystem any favours by doing > this. Couple of reasons why: 1. this isn't your data and this is an > unexpected action on the part of the registrants, 2. this is a sure-fire > way of accumulating even more cruft in ALTDB in a way which is > troublesome to clean up afterwards, 3. there are several thousand > objects in there which are already marked as proxy registrations, and > are already likely to be inaccurate, 4. you're losing authentication > information for people to self-manage their registrations, and 5. you > have likely not cross-checked this data against RIR transfers / > de-registrations - it's not really possible to do with with the > arin-nonauth db because that db doesn't include the last-modified > timestamp, and the changed: attribute is unreliable. > > Nick
Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)
Howdy All, While I agree that it might be politically entertaining to let this one blow up as a demonstration of how ARIN conducts business, this list of networks includes too many small networks who likely don't have a savy networking engineering team. In my opinion, they are not acceptable collateral damage to demonstrate ARIN's lack of regard for the community in shutting this down without a transition plan for the RPSL objects, so as one of the admins for the ALTDB IRR database, I've taken it upon myself to create proxy registrations for all of these prefixes in ALTDB. Like any proxy registration, asset owners are welcome to contact the maint POC, and if no response from them, db-ad...@altdb.net, requesting that stale records be deleted, but please also note that ALTDB automatically deletes any route objects which conflict with a publishes RPKI ROA, so the most effective way to clean up stale IRR records is to publish RPKI ROAs for your address space. -- Kenneth Finnegan ALTDB Admin http://blog.thelifeofkenneth.com/ On Mon, Apr 4, 2022 at 8:59 AM Job Snijders via NANOG wrote: > > Dear all, > > On Sat, Apr 02, 2022 at 09:09:58PM +, John Curran wrote: > > As previously reported here, ARIN will be shutting down the > > ARIN-NONAUTH IRR database on Monday, 4 April 2022 at 12:00 PM ET. > > > > It is quite likely that some network operators will see different > > route processing as a result of this change, as validation against the > > ARIN-NONAUTH IRR database will not longer be possible. > > > > Please be aware of this upcoming event and make alternative > > arrangements if you are presently relying on upon routing objects in > > the ARIN-NONAUTH IRR database. > > I ran an analysis just now in which I created an intersection between > prefixes observed in the BGP default-free zone and exactly matching > route:/route6: objects in ARIN-NONAUTH. I then substracted exact > matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and > APNIC IRR sources. The result is a list of routes which might > experience service disruptions due to missing IRR objects. > > The below 2,749 Prefix + Origin AS pairings are at risk as a result of > ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects > are likely to manifest themselves in the coming 24 - 32 hours. Prior to > this announcement, ARIN consulted with its community on the future of > its IRR service. > > I voiced objection and raised concerns about (what appeared to be) > limited visibility into what exactly the effects of such a database > shutdown would mean for the Internet: > https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html > Other community members also shared concerns: > https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html > A number of graceful alternative mechanisms were proposed, but not > acted upon: > https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html > > One might argue "well, folks had more than a year to move their > objects!", but on the other hand, it is entirely possible not all the > right people were reached, or in cases where affected parties did > receive a communication from ARIN, they perhaps were unable to > understand the message. > > Please check if any of your prefixes are on the below list, and if so, > double check whether your IRR administration is able to overcome the > disappearance of ARIN-NONAUTH. Godspeed! > > This tool might be useful: https://irrexplorer.nlnog.net/ > > Kind regards, > > Job >
Re: Amazon now controls 3.0.0.0/8
On Thu, Nov 8, 2018 at 3:58 PM Job Snijders wrote: > Seems ALTDB should delete the old AS 80 / GE IRR proxy route registration: > http://irrexplorer.nlnog.net/search/3.0.0.0 Done. For anyone else who is suffering from their prefixes malingering in ALTDB from previous users and has ultimately failed to resolve the issue with the maintainer of the object, you can escalate the matter to the db-ad...@altdb.net alias. We have recently started a cleanup effort of the ALTDB database to improve the quality of the routing information present in it. -- Kenneth Finnegan ALTDB Admin
Re: Quickstart Guide to IRR/RPSL
On Thu, Jul 19, 2018 at 9:19 AM, Job Snijders wrote: > Excellent, have you also considered using ARIN-WHOIS and RPKI as data > sources for your route servers? An excellent tool to generate route > server configurations is 'arouteserver' http://arouteserver.readthedocs.io/ After the volume of time and level of frustration it took just to get a handle on IRR, RPKI has been placed very low on our priority list. It's still on our list, but we've got plenty of other work to do before I figure out the implications of turning on RPKI, and I'm not willing to turn on a prefix authentication that I'm not able to walk my members through a way to correct. As for ARIN-WHOIS, I think I had gotten confused whether it was additive or exclusive of IRR objects for allowing prefixes. We have a lot of members running prefixes off of letters of authorization, so rejecting routes based on ARIN-WHOIS wasn't attractive, but that documentation you linked to reads more like it'll accept prefixes in addition to what gets accepted based on IRR alone. We will experiment with it. And yes, arouteserver is an excellent tool; we're currently using it, so enabling RPKI and ARIN-WHOIS will be relatively easy once we're willing to qualify it and roll it out. > 1/ About the "Selecting an IRR Database" section, the best current > practise is to use the IRR that your RIR provides you. In other words: > register ARIN managed prefixes in the ARIN IRR, and RIPE managed > prefixes in the RIPE IRR. Only the RIRs are in a position to attest that > it was the owner of a prefix that created the route(6): object. This is true. I wanted to write a more evergreen guide than walking through the current implementation of a single region's RIR, since there's several of them with their own unique work-flows and I get the sense that several of them are currently in flux. If we could ultimately replace this whitepaper with links to five equivalent documents from the RIRs, so be it. > Databases such as RADB, NTTCOM, ALTDB are so-called "third party" > databases and at this moment in time have no way to validate anything. > I've highlighted the differences between the various sources of data in > this talk at RIPE76 https://ripe76.ripe.net/archives/video/22 I did eventually find that talk useful once I had climbed high enough on the learning curve to really understand what you were talking about. Thanks. > 2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing > Policy" step, nobody uses this. Is the expectation that the only source of a network's as-set is PeeringDB then? I have reason to believe there are IRR consumers who do parse export/mp-export statements. I think at least documenting an mp-export to AS-ANY policy is reasonable, but I'll reconsider that. > 4/ Step 4 can be extended to promote creating RPKI ROAs (in addition to) > the route objects. Anyone can create a route: object in ALTDB, but only > the owner of a prefix can create a RPKI ROA. As such the RPKI ROAs are a > far more valuable source of data to filter generators. Yes. Someone should write a "zero to RPKI" tutorial. After this whitepaper literally took sitting down and reading the RFCs for something that people bemoan isn't used by every network, I'm not excited to try and get the same handle on RPKI to be able to speak with authority on how to set it up. > Can I update http://peering.exposed/ and add FCIX with a 'yes' to both > secure route servers & BCP 214? :-) Please do. :-) $0 for 10G, N/A for 100G. The next IRR puzzle for us is converting a CSV of member ASNs to their as-sets to generate the requested AS33495:AS-MEMBERS as-set so our members can also generate filters against the route servers. It seems like there's probably a tool like bgpq3 that can turn a list of ASNs into an as-set of their exports, but I'm not seeing it. Anyone have something at hand, or am I breaking out the python soon? -- Kenneth Finnegan http://blog.thelifeofkenneth.com/
Quickstart Guide to IRR/RPSL
Greetings, As part of setting up a new Internet Exchange in Fremont, California, we've been investigating prefix filtering on the route servers based on IRR. Unfortunately, we were not satisfied with any of the existing documentation available online as far as taking a network engineer from "zero" to "just enough IRR to post our prefixes for filtering". Lacking this documentation, it was rather unreasonable for us to turn on filtering and drop most of our peer's prefixes without a relevant whitepaper to point them to to get started. So, we wrote our own guide: http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html I thought others on this list would find our whitepaper interesting, and/or have valuable feedback based on their experience applying IRR themselves. -- Kenneth Finnegan Technical Director Fremont Cabal Internet Exchange http://fcix.net/
Re: IPv6 Default Allocation - What size allocation are you giving out
What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). What happens when the resident pulls their car into their garage and their car requests a unique /64 so the various computers on the CAN can start syncing with the Internet? Car's media center starts downloading new music, engine controller uploads diagnostics, GPS navigator starts downloading new maps, etc. Different example: people like Jim Gettys and Dave Taht are pushing for consumer routers to start routing between WiFi and Ethernet instead of bridging the two out of the box, since WiFi tends to fall over so hard on multicast/broadcast traffic. Suddenly their router needs two subnets, and either one of them doesn't work, or they have to live with reduced WiFi performance. -- Kenneth Finnegan http://blog.thelifeofkenneth.com/
Re: update
My original proposition still holds perfectly: (1) The vulnerability profile of a system is fixed at system commissioning. (2) Vulnerabilities do not get created nor destroyed except through implementation of change. (3) If there is no change to a system, then there can be no change in its vulnerabilities. Your original proposition is pointlessly academic. Yes, given absolutely no changes to the system, it's vulnerability profile does not change. Does your correct system boundary include the file system? So you're definition of an unchanging system only uses read-only file systems. Does it include the system's load average? Can't ever change the number of clients connected to it... Does it include the system's uptime? Etc. So yes, you're right. The number of existing vulnerabilities in a system never changes. It's just that you've also ruled out every system I can imagine being even remotely useful in life, so your argument seems to apply to _nothing_. What does change for a system is the threat profile as exploits become better known. Arguing that it is better to blissful march onward with what is *known* to be a vulnerable system instead of rolling out stable branch security updates that *generally* contain less bugs demonstrates a lack of pragmatism. I'm sorry that someone on the Internet hasn't precisely used your made-up distinction between a vulnerability profile and the actual threat level given the current state of the rest of the universe. We really don't need to be splitting hairs about this on the NANOG list... -- Kenneth Finnegan http://blog.thelifeofkenneth.com/
