Re: plea for comcast/sprint handoff debug help

[Tim Bruijnzeels]

Hi Chris, list,

> On 10 Nov 2020, at 05:22, Christopher Morrow  wrote:
> 
> sure... it's just made one set of decisions. I was hoping with some
> discussion we'd get to:
> Welp, sure we can fallback and try rsync if we don't see success in  
> time.

We will implement fallback in the next release of routinator.

We still believe that there are concerns why one may not want to fall back, but 
we also believe that it will be more constructive to have the technical 
discussion on this as part of the ongoing deprecate rsync effort in the sidrops 
working group in the IETF.

Regards,

Tim

Re: plea for comcast/sprint handoff debug help

[Tim Bruijnzeels]

Hi Randy, all,

> On 31 Oct 2020, at 04:55, Randy Bush  wrote:
> 
>> If there is a covering less specific ROA issued by a parent, this will
>> then result in RPKI invalid routes.
> 
> i.e. the upstream kills the customer.  not a wise business model.

I did not say it was. But this is the problematic case.

For the vast majority of ROAs the sustained loss of the repository would lead 
to invalid ROA *objects*, which will not be used in Route Origin Validation 
anymore leading to the state 'Not Found' for the associated announcements.

This is not the case if there are other ROAs for the same prefixes published by 
others (most likely the parent). Quick back of the envelope analysis: this 
affects about 0.05% of ROA prefixes.

>> The fall-back may help in cases where there is an accidental outage of
>> the RRDP server (for as long as the rsync servers can deal with the
>> load)
> 
> folk try different software, try different configurations, realize that
> having their CA gooey exposed because they wanted to serve rrdp and
> block, ...

We are talking here about the HTTPS server being unavailable, while rsync *is*.

So this means, your HTTPS server is down, unreachable, or has an issue with its 
HTTPS certificate. Your repository could use a CDN if they don't want to do all 
this themselves. They could monitor, and fix things.. there is time.

Thing is even if HTTPs becomes unavailable this still leaves hours (8 by 
default for the Krill CA, configurable) to fix things. Routinator (and the RIPE 
NCC Validator, and others) will use cached data if they cannot retrieve new 
data. It's only when manifests and CRLs start to expire that the objects would 
become invalid.

So the fallback helps in case of incidents with HTTPS that were not fixed 
within 8 hours for 0.05% of prefixes.

On the other hand, the fallback exposes a Malicious-in-the-Middle replay attack 
surface for 100% of the prefixes published using RRDP, 100% of the time. This 
allows attackers to prevent changes in ROAs to be seen.

This is a tradeoff. I think that protecting against replay should be considered 
more important here, given the numbers and time to fix HTTPS issue.


> randy, finding the fort rp to be pretty solid!

Unrelated, but sure I like Fort too.

Tim

Re: plea for comcast/sprint handoff debug help

[Tim Bruijnzeels]

Hi Job, all,

> On 30 Oct 2020, at 11:06, Job Snijders  wrote:
> 
> On Thu, Oct 29, 2020 at 09:14:16PM +0100, Alex Band wrote:
>> In fact, we argue that it's actually a bad idea to do so:
>> 
>> https://blog.nlnetlabs.nl/why-routinator-doesnt-fall-back-to-rsync/
>> 
>> We're interested to hear views on this from both an operational and
>> security perspective.
> 
> I don't see a compelling reason to not use rsync when RRDP is
> unavailable.
> 
> Quoting from the blog post:
> 
>"While this isn’t threatening the integrity of the RPKI – all data
>is cryptographically signed making it really difficult to forge data
>– it is possible to withhold information or replay old data."
> 
> RRDP does not solve the issue of withholding data or replaying old data.
> The RRDP protocol /also/ is unauthenticated, just like rsync. The RRDP
> protocol basically is rsync wrapped in XML over HTTPS.
> 
> Withholding of information is detected through verification of RPKI
> manifests (something Routinator didn't verify up until last week!),
> and replaying of old data is addressed by checking validity dates and
> CRLs (something Routinator also didn't do until last week!).
> 
> Of course I see advantages to this industry mainly using RRDP, but those
> are not security advantages. The big migration towards RRDP can happen
> somewhere in the next few years.


Routinator does TLS verification when it encounters an RRDP repository. If the 
repository cannot be reached, or its HTTPS certificate is somehow invalid, it 
will use rsync instead. It's only after it found a *valid* HTTPS connection, 
that it refuses to fall back.

There is a security angle here.

Malicious-in-the-middle attacks can lead an RP to a bogus HTTPS server and 
force the software to downgrade to rsync, which has no channel security. The 
software can then be given old data (new ROAs can be withheld), or the attacker 
can simply withhold a single object. With the stricter publication point 
completeness validation introduced by RFC6486-bis this will lead to the 
rejecting of all ROAs published there.

The result is the exact same problem that Randy et al.'s research pointed at. 
If there is a covering less specific ROA issued by a parent, this will then 
result in RPKI invalid routes.

The fall-back may help in cases where there is an accidental outage of the RRDP 
server (for as long as the rsync servers can deal with the load), but it 
increases the attack surface for repositories that keep their RRDP server 
available.

Regards,
Tim



> 
> The arguments brought forward in the blog post don't make sense to me.
> The '150,000' number in the blog post seems a number pulled from thin
> air.
> 
> Regards,
> 
> Job

Re: Has Anyone managed to get Delegated RPKI working with ARIN

[Tim Bruijnzeels]

Hi,

Everyone is welcome to read that list of course, but the TL;DR is:

ARIN currently uses a pre RFC 8183 format for the identity exchange. It would 
be good if this were updated. New versions of rpkid as well as Krill have 
issues with the old format.

In the meantime this XSL provided by rpki.net can be of help:
https://raw.githubusercontent.com/dragonresearch/rpki.net/master/potpourri/oob-translate.xsl
 


Note: if you are planning to give Krill a try we recommend that you wait for 
version 0.5. We expect to have this version ready in 1-2 weeks. It will include 
usability improvements, better monitoring and a UI.

Kind regards,

Tim



> On 5 Feb 2020, at 16:03, Christopher Munz-Michielin  
> wrote:
> 
> Brilliant! Thanks for the write up Cynthia, I'll have a read through!
> 
> Chris
> 
> On 2020-02-05 1:56 a.m., Cynthia Revström wrote:
>> (Re-sent as I forgot to include the ML the first time, oops)
>> Hi Chris,
>> 
>> I recently figured it out and posted it on the NLNetLabs RPKI mailing list. 
>> https://lists.nlnetlabs.nl/pipermail/rpki/2020-February/000124.html 
>> 
>> I hope it helps :)
>> 
>> - Cynthia
>> 
>> On Wed, Jan 29, 2020 at 6:31 PM Christopher Munz-Michielin 
>> mailto:christop...@ve7alb.ca>> wrote:
>> 
>>Hi Nanog,
>> 
>>Posting here since my Google-fu is coming up short.  I'm trying to setup 
>> delegated RPKI in ARIN using rpki.net 's rpkid Python 
>> daemon and am running into an issue submitting the identity file to ARIN's 
>> control panel. The same file submitted to RIPE's  test environment at 
>> https://localcert.ripe.net/#/rpki works without issue, while submitting to 
>> ARIN results in "Invalid Identity.xml file."
>> 
>>The guide I'm following is this one: 
>> https://github.com/dragonresearch/rpki.net/blob/master/doc/quickstart/xenial-ca.md
>>  and I'm able to get as far as generating the identity file.
>> 
>>Wondering if anyone has gone down this road before and has any helpful 
>> hints to make this work?
>> 
>>Cheers,
>>Chris
>>