Re: [sidr] A quick note from RPKI in the wild

A few numbers we gathered with Arturo. After processing yesterday's
RIPE RIS dump from the PTT Metro Sao Paulo sensor, we detected

-  ~5300 invalid prefixes
- ~2800 valid prefixes

Out of the invalid prefixes we have:

- ~ 3100 invalids due to bad maxLen
- ~ 2200 invalids due to wrong origin AS

I fully agree with Alex that maxLen is currently badly misunderstood
by the community at large. A lot of work is badly needed in order to
improve this situation.

However, surprisingly enough, many people do not know which AS should
originate their own prefixes. Out of the collected data it looks like
large companies with operations in different countries are the "worst
offenders" in this case.

We have put online a little tool to play with this data:
http://www.labs.lacnic.net/rpkitools/looking_glass/

The database is refreshed once a day (7 am GMT-2). All feedback is of
course welcome. Beware that it is pretty crude at this point and be
warned that it can blow up in your face without warning :-)

We are working on:

- including more queries
- allowing CSV downloads of result sets
- RESTful-like interface
- WHOIS interfacing for richer display

Warm regards,

Carlos

On Thu, Dec 8, 2011 at 3:10 PM, Matthias Waehlisch <waehlisch@ieee.org> wrote:
> Hi Sriram,
>
> On Thu, 8 Dec 2011, Sriram, Kotikalapudi wrote:
>
>>  >I'm not sure if I understand your quote correctly: Do you only
>> consider the case where the super-block encloses the sub-allocations
>> (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no
>> MaxLength violation, right?.
>>
>> KS: No. I am taking about something different.
>> If ISP A (with AS A) creates a ROA for its super-block x.y.0.0/16
>> and its Customer B (with AS B) has a sub-allocation x.y.z.0/24 and
>> has NOT created a ROA yet, then the customer's announcement will be Invalid.
>> The same effect happens whether ISP A's ROA is:
>> {ROA: x.y.0.0/16, AS A} (w/o maxLength; defaulted to maxLength = 16)
>> or, {ROA: x.y.0.0/16, AS A, maxLength = 24}
>> or, {ROA: x.y.0.0/16, AS A, maxLength = 18}.
>> With any of the above ROAs, Cust. B's announcement is Invalid
>> because it doesn't have a ROA yet for its sub-allocation.
>>
>  definitely agree.
>
>> KS: The BCP I quoted from origin-ops requires that ISP A MUST
>> register its ROA only after the customer sub-allocation ROAs
>> have been created (or, register all necessary ROAs simultaneously).
>> In the above example: ISP A can create a ROA for Customer B
>> along with its own ROA as follows:
>> {ROA: x.y.0.0/16, AS A} and {ROA: x.y.z.0/24, AS B}
>> That ensures that Customer B is not in trouble.
>>
>> This is the bottom up approach for ROA creation.
>> Question is: Do the ISP's (or super-block owners) in your
>> measurement data seem to be compliant with said BCP.
>>
>  My point was that it is not too easy to decide if the ISPs are
> compliant with the BCP. But I think I got your point: If the origin AS
> in the Update has (somehow) a *customer* relationship with the ROA AS it
> is more likely that the ISP's ROA creation is in violation of the BCP.
>
>  In our last IETF presentation, we identified for the incorrect origin
> ASes that there exists a ROA Origin that is 1 hop away (ignoring
> prepending) from the announced origin AS in 90% of the cases. Coming
> back to your question: Yes, most of the announcements are invalid
> probably due to the violation of the BCP but I will try to verify in
> more detail.
>
>
> Cheers
>  matthias
>
> --
> Matthias Waehlisch
> .  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
> .  Takustr. 9, D-14195 Berlin, Germany
> .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
> :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://cagnazzo.name
=========================