Subject: Re: [Sidrops] 6486bis: referenced object validation

From: Job Snijders <[email-masked]>
Date: Mon, 4 Jan 2021 02:58:43 +0000

On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote:
> > The December 1st, 2020 case is definitely one I'd add to the testbed
> > archive.
> 
> It would be. I think this is an effort in itself. Do you have a
> proposal in mind?

At this URL http://rpkiviews.org/ i am trying to re-publish data I
collected after having made some attempt with OpenBSD's 'rpki-client' to
validate the RPKI data.

one view:

    http://www.rpkiviews.org/adrian.sobornost.net/rpkidata/2020/12/01/

and a bit later I added a second instance with a different view:

    http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2021/01/01/

Kind regards,

Job

---

From: Tony Tauber <[email-masked]>
Date: Mon, 4 Jan 2021 12:10:54 -0500

> http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2021/01/01/

Nice work.
When you say "different view", what does that mean?
The structure of the data is different or the location in the internet
where the collection was performed from ("vantage point"?) was different?
(The latter perhaps being interesting should reachability of any TALs or
Publication Points be different.)

Tony

---

From: Job Snijders <[email-masked]>
Date: Mon, 4 Jan 2021 19:40:09 +0000

> where the collection was performed from ("vantage point"?) was different?

You are spot on, its just the location that is different. It'll be
important to keep an eye on 'the RPKI' from multiple angles in the
default-free zone.

I imagine we have to include in the risk model how cache instances
Relying Parties might see different objects coming out of publication
servers depending on where they are connected to the Internet. 

Citing RFC 7115 Section 6:

    """
    Like the DNS, the global RPKI presents only a loosely consistent
    view, depending on timing, updating, fetching, etc.  Thus, one cache
    or router may have different data about a particular prefix than
    another cache or router.  There is no 'fix' for this, it is the
    nature of distributed data with distributed caches.
    """

As we can't 'fix' it, at least we can monitor and record it (just like
the weather! :-).

Adrian.sobornost.net is generously hosted by NTT in their Dallas, TX,
USA facility. Josephine.sobornost.net is generously hosted by XS4ALL in
their Amsterdam, NL facility. I've updated the page to provide more
detail.

> Publication Points be different.)

yup!

*** REQUEST TO THE GROUP ***

If others are willing to set up similarly structured data collection
efforts, I can help in two ways:

    1) add links towards such initiatives from the www.rpkiviews.org
       page.
    2) I myself can configure your data collection server through SSH,
       all that is required is a POSIX compliant system with... LOTS of
       disk space.

It would be incredible valuable to have public viewpoints located in the
African, Asian, and South American segments of the Internet. 

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 5 Jan 2021 09:53:57 +0100

Hi Job, all,

> On 4 Jan 2021, at 20:40, Job Snijders <[email-masked]> wrote:
> 

I think geographically diverse vantage points are indeed valuable.

However, a lot (most) publication points only have a single point of presence, so I suspect that a significant part of the variation in data seen is due to timing differences rather than geography / net topology.

Not a criticism.. just saying it would be good to keep this in mind when analysing differences.

Tim

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Tue, 5 Jan 2021 11:52:25 +0000

Hi Tim,

On Tue, Jan 05, 2021 at 09:53:57AM +0100, Tim Bruijnzeels wrote:
> However, a lot (most) publication points only have a single point of
> presence, so I suspect that a significant part of the variation in
> data seen is due to timing differences rather than geography / net
> topology.

Yes, timing also plays a big role in it all.

> when analysing differences.

Yeah, analysing differences is a tedious chore, there is an infinite
number of 'pathways' from signer to validator. Just looking at the 5 TAs
I observed the following:

    ARIN: 3 x A & 3 x AAAA DNS records for rpki.arin.net and also
          rrdp.arin.net, making for (at least) 12 points of presence.

    LACNIC: similar to ARIN

    RIPE: 1 x A + 1 x AAAA record for rpki.ripe.net, RRDP is distributed
          through a CDN with a 100+ points of presence.

    APNIC: one IPv4 address and separately one IPv6 address

    AFRINIC: similar to APNIC.

The above description of course is just the 'expected steady state',
Separately, there might be situations in which a publication point's IP
prefixes are hijacked in some way (be it via BGP or DNS trickery),
temporarily creating a 'multiple POP' situation.

In really complex cases one might even have to correlate routeviews with
rpkiviews, all the while keeping in mind that the two planes can
influence each other to some degree. Debugging the RPKI is hard work.

Kind regards,

Job