Thank you Job & Nick for your comments. They pretty much do confirm what I was suspecting that the ROA may be incorrect.
I am looking at this topic from the perspective of stub enterprise AS not a transit operator. So with that being said in such cases of INVALID ASN I could potentially drop it from entering my DMZ routing. Currently just playing with lowering a bit local pref. And I am getting those prefixes like this one from multiple peers. In fact I found this one 45.227.254.0/24 and many others which drew my attention by adding an automated correlation of invalid ROAs to my TCP analyzer watching 100% of my Internet in/out traffic. Most prefixes marked as INVALID are actually turning up as covering sources of TCP attacks ! But not all. So I digged a bit more and found that those which are legitimate INVALID are INVALID LENGTH not INVALID ASN. Pretty bad that routers have no options to distinguish one vs the other state when performing origin validation. Of course as a workaround I could feed them with only INVALID ASN ROAs validated on the server, but I do not recall anyone so far recommended such practice. Those who drop INVALID would by default drop both ASN or LENGTH isn't it ? See another point here is that if I am at the DMZ and if I am seeing quite a nice correlation of attacks with INVALID ASN it is tempted to apply those prefixes as src drop ACLs shielding my servers or other DMZ infra from the attacks. Of course cluster of inline IPS are supposed to filter those just by learning traffic patterns on a /32 or /128 basis, but with Nx10G of traffic they get pretty busy anyway. Last on the part of INVALID LENGTH ... Imagine I owe /19 of IPv4 and I am allocating /24s in many of my global DMZs. If I do not sign my /19 aggregate I have no problem as it will be globally not found. But the moment I sign it I must also sign all /24s I advertise as otherwise they will become INVALID - right ? So now each time any engineering group globally injects new /24 they also must also sign it ... Can you imagine the operational burden here in a global company when the RPKI operation is usually centralized ? No wonder that RIPE Validator shows 1700+ INVALID LENGTH prefixes. And at least in IOS XE as mentioned above I do not see a way to only validate against INVALID ASN. To the point Randy shared - I am afraid if prefix is leased from some operator who is RPKI aware to the one which is not which could likely be the root cause on the example I provided I am not sure there is process in place to make sure the obsolete data is erased. If this is just up to humans it is pretty much guaranteed it is going to be wrong. Many thx all, R. On Sun, Apr 12, 2020 at 9:51 PM Job Snijders <[email protected]> wrote: > On Sun, Apr 12, 2020 at 08:39:58PM +0200, Robert Raszuk wrote: > > Would anyone be able to explain the below phenomenon? > > > > RPKI Origin validation marks net 45.227.254.0/24 as INVALID as it > expects > > it to be originated by ASN: 395978 > > If you look at https://stat.ripe.net/45.227.254.0%2F24#tabId=routing you > can see that the prefix is only seen by 72% of the RIPE RIS collectors, > this is a very low score, I'd consider this a problematic network > outage. If you'd have internet access users serviced out of the block it > probably would mean many websites don't work, or don't work well. > > In the 'Routing History' widget we can see: > > May 2018 - Jul 2018 - AS 395978 > Aug 2018 - AS 62088 > Oct 2018 - Mar 2019 - AS 42260 > Feb 2019 - Mar 2020 - AS 51852 > > I guess early someone deemed AS 395978 deemed to be the right origin ASN > and create RPKI ROAs, but subsequently didn't update these RPKI ROAs to > the new ASNs as the space moved from lessee to lessee. I suspect IP > address leasing is in play because the announcement periods don't seem > to overlap, suggesting there might have been coordination between > previous and next Origin ASN. > > Since the ROA still exists, whoever created the ROA (to authorize > 395978) still is in authority, so from an operational perspective it is > incumbent on that entity to correct the RPKI information. If the space > had been transferred from one LIR to another LIR the 'offending' ROA > would've been deleted in that transfer process. > > > But it comes from 51852 which according to ipinfo or bgpview is > > legitimate ASN: > > > > https://ipinfo.io/AS51852/45.227.254.0/24 > > https://bgpview.io/prefix/45.227.254.0/24 > > I am not sure in what way you are reading the data, the information > displayed here doesn't weigh in on legitimacy. Both websites are > frontends to public whois data, they shows the prefix is suballocated to > 'Xwin universal ltd', but the originating ASN is 'Private Layer INC'. > > > As I see similar discrepancies in many global networks I would like to > > ask who to trust ? If RPKI data is not valid then I think we have a > > real problem. > > I am not sure it is about trust. I trust the system works as designed, > which means there is potential for human error in the ROA creation > process. In this sense IRR, DNSSEC, and RPKI have some similarities - > they all potentially set a user up for failure. > > Operators deploying OV have to the balance of inconvenience for entities > who misconfigured their ROA against the consequences of accepting BGP > misconfigurations or hijacks of prefixes which could've been prevented > had ROAs been honored. > > An operator should notify its customers who are announcing RPKI invalids > before deploying Origin Validation with 'invalid == reject' policies on > the EBGP edge. This way the alert notification about the ROA > misconfiguration follows contractually established inter-organisation > communication channels. Sometimes that mechanism works well! > > Another theory is that some (a lot?) of the RPKI Invalids that exist in > the default-free zone in a steady state are not really in use, just > 'parked'. Folk wisdom suggests if you don't announce all your prefixes > in the DFZ, malicious actors tend to notice and start using the space in > your stead. Because of this (and other reasons) we can't really know > what IP address space is actually in use or not. > > Traffic studies done by some network operators in the months prior to > deploying RPKI OV commonly show very little or no traffic destined for > RPKI Invalids. In these studies it is important to separate RPKI > invalids that become 'unreachable', and traffic for IPs covered by RPKI > invalids which are covered by a less specific not-found/valid > announcement. > https://mailman.nanog.org/pipermail/nanog/2019-February/099522.html > > Back to the prefix at hand, I believe this to be the party in charge of > the RPKI ROA: > > $ whois 45.227.252.0/22 | grep @ | sort -u > e-mail: [email protected] > > One could reach out to the operator and ask them? > > Kind regards, > > Job >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
