Level 3's IRR Database
Hi All, I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3. So, I have two queries A.) Are only customers of Level 3 allowed to use this database B.) Can someone from Level 3 please clarify if there are any plans to lock this down slightly At this point, it would seem that if you are a customer of level 3's, you can register any space you feel like in there, and announce anything you feel like once the filters propagate, which in my opinion completely nullifies the point of IRR in the first place. Though I think this also raises the question about IRR databases in general. Would it not be far more sane to have each RIR run a single instance each which talk to each other, which can be verified against IP address assignments, and scrap the distributed IRR systems that allow for issues like this to occur? (In the mean time I've emailed the relevant people to try and get the entries falsely registered in that database removed, and will wait and see if I get a response). Andrew Alston TENET - Chief Technology Officer Phone: +27 21 763 7181
On Sun, Jan 30, 2011 at 3:23 AM, Andrew Alston <aa@tenet.ac.za> wrote:
I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3.
This is not unique to Level3 -- it is the industry standard practice and has been since the dawn of time. You must be a Level3 customer to have a mntner: for publishing to their IRR database (in theory.) Since there isn't an automatic mechanism for verifying that a given ISP is really allowed to originate a route (or provide transit for an AS, etc.) there is simply no practical way to change this at this time, without processing updates manually (and introducing human error into that yes/no authorization check.) IRR is a convenience that many networks rely on. When done correctly, this is not a bad idea by any means. In theory, RPKI will fix the real problem you are addressing -- that it is really difficult to verify whether or not a neighboring AS is allowed to carry a given route. In practice, vendors need to support it on routers, networks need to upgrade, ARIN (and other RIRs) need to do their part, and thousands of auto-pilot networks will need to be hand-held by their ISPs in order to make this happen. How soon theory can become reality is not easy to predict. How many networks have ubiquitous support for 32 bit ASN? IPv6? RPKI is a bastard thing created out of a perceived (perhaps correctly) need for real security, when in fact basically all of the events that have led to its creation (except for some scare-tactic papers and presentations) were not deliberate. This brings me to my point, which is that IRR is very good for preventing accidents and automating some common tasks. It should be "secure" to a point, but just because a route: object exists does not mean that mntner: really has authority over that address space. You can pretty much rely on the fact that the given origin AS is intentionally announcing the route, as opposed to leaking it by accident. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 30/01/2011 09:08, Jeff Wheeler wrote:
This brings me to my point, which is that IRR is very good for preventing accidents and automating some common tasks. It should be "secure" to a point, but just because a route: object exists does not mean that mntner: really has authority over that address space.
Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and AfriNIC implement hierarchical object ownership, which means that if you're registering their address space, you can only do so if that address space legitimately belongs to you. This isn't the case on third party IRRDBs like RADB, L3 and AltDB. Nick
On 1/30/2011 11:15 AM, Nick Hilliard wrote:
Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and AfriNIC implement hierarchical object ownership, which means that if you're registering their address space, you can only do so if that address space legitimately belongs to you. This isn't the case on third party IRRDBs like RADB, L3 and AltDB.
Which is nice. I just duplicated an ARIN entry in raddb using my maintainer with all other information the same. Since Level 3 pulls based on my as-set + my maintainer list, my entry automatically updates their acl list. Does this mean I can't lie? No. However, IRR's aren't designed to top lying. they are designed to help in management and tracking issues. Jack
On 2011-01-30, at 12:15, Nick Hilliard wrote:
On 30/01/2011 09:08, Jeff Wheeler wrote:
This brings me to my point, which is that IRR is very good for preventing accidents and automating some common tasks. It should be "secure" to a point, but just because a route: object exists does not mean that mntner: really has authority over that address space.
Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and AfriNIC implement hierarchical object ownership, which means that if you're registering their address space, you can only do so if that address space legitimately belongs to you.
Note that in the case of the RIPE db (and perhaps the others, I don't know) this is only the case for resources that can be traced back to a RIPE NCC-assigned netblock. I routinely register objects in the RIPE db which were assigned from other regions (e.g. ARIN). Since many European networks have procedures and automation that requires things to be in the RIPE db, using that db as your primary publication mechanism avoids the need to duplicate later. The parent object in the RIPE db for such foreign resources is inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space country: EU # Country is really world wide org: ORG-IANA1-RIPE admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED remarks: The country is really worldwide. remarks: This address space is assigned at various other places in remarks: the world and might therefore not be in the RIPE database. mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-RPSL-MNT source: RIPE # Filtered and the maintainer object for routes is mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE auth: MD5-PW $1$ScJSM7nN$Xw3aAduCRZx4QUEq8QjR5/ remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT source: RIPE # Filtered This means that anybody can assert pretty much anything they like, so long as the resources are not NCC-assigned. Joe
On 31/01/2011 14:16, Joe Abley wrote:
On 2011-01-30, at 12:15, Nick Hilliard wrote:
Depends on which IRR you use. The IRRDBs run by RIPE, APNIC and AfriNIC implement hierarchical object ownership, which means that if you're registering their address space, you can only do so if that address space legitimately belongs to you.
This means that anybody can assert pretty much anything they like, so long as the resources are not NCC-assigned.
yes, indeed. I did mention "which means that if you're registering their address space...", although maybe that wasn't clear enough. Will use capital letters next time :-) Nick
The solution to this problem (theoretical at least) already exist in the form of RPKI. On Sun, Jan 30, 2011 at 6:23 AM, Andrew Alston <aa@tenet.ac.za> wrote:
Hi All,
I've just noticed that Level 3 is allowing people to register space in its IRR database that A.) is not assigned to the people registering it and B.) is not assigned via/to Level 3.
So, I have two queries
A.) Are only customers of Level 3 allowed to use this database B.) Can someone from Level 3 please clarify if there are any plans to lock this down slightly
At this point, it would seem that if you are a customer of level 3's, you can register any space you feel like in there, and announce anything you feel like once the filters propagate, which in my opinion completely nullifies the point of IRR in the first place.
Though I think this also raises the question about IRR databases in general. Would it not be far more sane to have each RIR run a single instance each which talk to each other, which can be verified against IP address assignments, and scrap the distributed IRR systems that allow for issues like this to occur?
(In the mean time I've emailed the relevant people to try and get the entries falsely registered in that database removed, and will wait and see if I get a response).
Andrew Alston TENET - Chief Technology Officer Phone: +27 21 763 7181
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
On 30/01/2011 17:39, Carlos Martinez-Cagnazzo wrote:
The solution to this problem (theoretical at least) already exist in the form of RPKI.
So, what are peoples' routing policies on RPKI going to be? Are people going to drop prefixes with no RPKI record? Or drop prefixes with an incorrect RPKI record? Or drop prefixes with a revoked status? I'm concerned that if we're trying to avoid another Youtube affair, the RPKI policy acceptability criteria will have to be so strict that this may have a serious effect on overall reachability via the internet. Nick
I think we just don't know (yet) how people are going to apply RPKI. If I were operating a large network today, I would try to run RPKI in a sort of warning-only mode, i.e. getting some sort of alert if an invalid route was detected. While this wouldn't have prevented YouTube's incident, it would probably have shortened the recovery period. I think it is too early in the deployment process to start dropping routes based on RPKI alone. We'll get there at some point, I guess. cheers Carlos On 1/30/11 6:47 PM, Nick Hilliard wrote:
On 30/01/2011 17:39, Carlos Martinez-Cagnazzo wrote:
The solution to this problem (theoretical at least) already exist in the form of RPKI.
So, what are peoples' routing policies on RPKI going to be? Are people going to drop prefixes with no RPKI record? Or drop prefixes with an incorrect RPKI record? Or drop prefixes with a revoked status?
I'm concerned that if we're trying to avoid another Youtube affair, the RPKI policy acceptability criteria will have to be so strict that this may have a serious effect on overall reachability via the internet.
Nick
.-- My secret spy satellite informs me that at 11-01-30 1:22 PM Randy Bush wrote:
So, what are peoples' routing policies on RPKI going to be? Are people going to drop prefixes with no RPKI record? Or drop prefixes with an incorrect RPKI record? Or drop prefixes with a revoked status?
draft-ietf-sidr-rpki-origin-ops-04.txt
Question, Based on this draft the recommended preference order is: 1) Validation ok 2) not found 3) Validation nok Suppose an operator would use local-pref to achieve this. This intention (preferring validated routes) will break, when there's a more specific announcement that doesn't validate. For example the youtube incident would not have been stopped by doing this. Are there any suggestions or recommendations for how to handle these cases? Cheers, Andree
On 1/30/2011 2:47 PM, Nick Hilliard wrote:
I'm concerned that if we're trying to avoid another Youtube affair, the RPKI policy acceptability criteria will have to be so strict that this may have a serious effect on overall reachability via the internet.
Not really. Just a simple, if route invalidly signed, drop it. If route validly signed, prefer it over unsigned. That allows people to choose to protect their routes, while the vast majority of routes don't need protecting. I haven't seen the proper mechanism, though it may exist, to say (hey, I already have a route which while not as specific was signed, so bye bye). Jack
On Sun, Jan 30, 2011 at 5:08 PM, Jack Bates <jbates@brightok.net> wrote:
Just a simple, if route invalidly signed, drop it.
What constitutes a invalidly signed route more exactly? Would a signed route by a signer (ISP) who's status has been revoked by an entity in the RPKI-hierarchy-of-trust above (for whatever reason), be considered invalid? For example, if the Egyptian government orders an entity situated somewhere in the verification trust-chain to revoke the trust-chain for some prefixes below, because it prefers these prefixes to not be reachable by anyone, that wouldn't be very good, would it? Not seeing the upside of that model at all. Why would anyone want that? Cheers, Martin
participants (11)
-
Andree Toonk -
Andrew Alston -
Carlos M. Martinez -
Carlos Martinez-Cagnazzo
-
Jack Bates -
Jeff Wheeler -
Joe Abley -
Martin Millnert -
Nick Hilliard -
Randy Bush -
Valdis.Kletnieks＠vt.edu