[GROW] 答复: Playing with origin validation

draft-ietf-sidrops-ov-egress-02 could be a good solution to the case that Robert raised. The egress OV provides the export filtering for routes with invalid ROA validation result. With this capability supported, the origin AS/AS operator is in fact able to identify that its own ROA entry is out of date and needs to be updated. However, currently there's no further action/suggestion specified other than filtering in the draft-ietf-sidrops-ov-egress-02. So, a small suggestion to the authors that maybe some specifications can be added to the draft regarding how the origin AS could/should react upon this case. 

BR,

Yunan

-----邮件原件-----
发件人: GROW [mailto:grow-bounces@ietf.org] 代表 Job Snijders
发送时间: 2020年4月13日 3:51
收件人: Robert Raszuk <robert@raszuk.net>
抄送: grow@ietf.org grow@ietf.org <grow@ietf.org>
主题: Re: [GROW] Playing with origin validation

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:      noc@FLYSERVERS.COM

One could reach out to the operator and ask them?

Kind regards,

Job

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow