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
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.
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
The solution to this problem (theoretical at least) already exist in
the form of RPKI.
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
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
Do we really *want* to get to that point?
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
randy
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
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
.-- 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
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.
i do not understand your logic.
let's try to show the case
666.42.0.0/16 has a roa for as 777
666.42.1.0/24 has a roa for as 888
an announcement comes for 666.42.1.0/24 originating from as 999. are
you implying that it should be marked valid? i sure don't want it to.
an announcement for 666.42.0.0/16 from as 777 would still be valid.
so i am not sure what your point is. please clarify with a concrete
example.
randy
Andree was saying,
666.42.0.0/16 has a roa for as 777
you start receiving
666.42.0.0/24 and 666.42.1.0/24, both unsigned. Changing preference isn't enough to stop routing, as it's a more specific route and automatically wins if it gets into the table.
Jack
666.42.0.0/16 has a roa for as 777
you start receiving
666.42.0.0/24 and 666.42.1.0/24, both unsigned. Changing preference
isn't enough to stop routing, as it's a more specific route and
automatically wins if it gets into the table.
nope
when there is no roa for the arriving prefix, a roa for the covering
prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt.
randy
when there is no roa for the arriving prefix, a roa for the covering
prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt.
which, btw, is why draft-ietf-sidr-rpki-origin-ops-04.txt warns
Before issuing a ROA for a block, an operator MUST ensure that any
sub-allocations from that block which are announced by others (e.g.
customers) have ROAs in play. Otherwise, issuing a ROA for the
super-block will cause the announcements of sub-allocations with no
ROAs to be Invalid.
randy
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
Ahh, very good. I think that was the only concern. Presumably that would invalidate the route and it would be discarded vs deprefed.
Jack
when there is no roa for the arriving prefix, a roa for the covering
prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt.
Ahh, very good. I think that was the only concern. Presumably that
would invalidate the route and it would be discarded vs deprefed.
well, i am not sure you want to discard it. this is where the op has to
make a decision. in a world of partial deployment and ops and customers
still learning how to deal with this stuff, should it be discarded?
again from draft-ietf-sidr-rpki-origin-ops-04.txt
Local policy using relative preference is suggested to manage the
uncertainty associated with a system in flux, applying local policy
to eliminate the threat of unroutability of prefixes due to ill-
advised certification policies and/or incorrect certification data.
E.g. until the community feels comfortable relying on RPKI data,
routing on Invalid origin validity, though at a low preference, will
likely be prevalent for a long time.
but you configure your routers as you think best.
randy
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