[Sidrops] Publication Server Checks (was: Re: [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021)

[Tim Bruijnzeels <[e-mail]>]

[trimming recipient list for this side-discussion]

> On 30 Mar 2021, at 14:21, Ties de Kock <[e-mail]> wrote:
> 
> Hi Tim, all,
> 
>> On 30 Mar 2021, at 13:24, Tim Bruijnzeels <[e-mail]> wrote:
>> 
>> Hi Job, all,
>> 
>>> On 30 Mar 2021, at 12:00, Job Snijders <job=[e-mail]> wrote:
>>> 
>>> Hi Tim, working group,
>>> 
>>> first things first: I support adoption of this draft.
>>> 
>>> On Mon, Mar 29, 2021 at 04:06:56PM +0200, Tim Bruijnzeels wrote:
>>>> = revocation?
>>>> 
>>>>  A large number of experiments for the process of ROA issuance have
>>>>  been made on our RPKI testbed, it is found that the misconfigurations
>>>>  during the issuance may cause the ROAs which have been issued to be
>>>>  revoked.
>>>> 
>>>> I don't see how the ROAs would be revoked in this context.
>>> 
>>> Perhaps 'revoked' is the wrong word, maybe 'withdrawn' or 'unpublished'?
>>> 
>>> I took the third suggestion in 'Section 3' to mean that if the ROA
>>> issuer does not confirm the End-Entity certificate signing the ROA
>>> eContent checks that it is allowed to sign the resources listed in the
>>> eContent, it might end up submitting an invalid object to the
>>> Repository.
>>> 
>>> The Repository deferences any previous ROA with the same filename,
>>> performs validation on the newly submitted ROA, concludes it is invalid
>>> (because the resources in the eContent overclaim compared to the
>>> resources listed as subordinate on the EE cert) and ends up publishing a
>>> CA Repository without the intended ROA.
>> 
>> No, the publication server does not validate content. See RFC 8181:
>> 
>> 5.  Security Considerations
>> 
>>   The RPKI publication protocol and the data it publishes use entirely
>>   separate PKIs for authentication.  The published data is
>>   authenticated within the RPKI, and this protocol has nothing to do
>>   with that authentication, nor does it require that the published
>>   objects be valid in the RPKI.
>> 
>> 
>> That being said.. as yet another aside..
>> 
>> I have been thinking of proposing extensions to the publication protocol (RFC 8181) to make Publication Servers somewhat more responsible. For example they could enforce quota both in terms of number of files, and size. They could also verify objects, e.g. only allow known types, and only allow objects which at least parse. But there is a potential issue then with bugs in verification code. Also, if this is done for security then it may not matter because malicious CAs could 'just' run their own publication server, until they might be revoked by an angry parent CA. Still... I think this is worth a (separate) discussion. Raising the barrier to abuse and mistakes seems like a good idea.
> 
> I would be hesitant to add too much validation to the publication protocol. In
> my opinion the BPKI relationship ensures that the content of the messages is
> what the client intends to publish.
> 
> However, I would welcome the removal of some foot cannons. For example,
> updating an object [and thus changing the hash of] on a manifest that currently
> has entries with matching names and hashes, without also updating the manifest,
> likely is a sign of a bug - not of the intention of the client.

First off, I don't think there is a huge and immediate operational issue with RFC 8181 right now, but it's good to keep an open mind to improvements.

My first take on this would be quota. And when it comes to objects I would not validate them, but just sanity check that they are of a known type and maybe that they can be parsed. I.e. add error codes as Job suggested.

We may want to extend the protocol so that quota information can be communicated. Not sure.. protocol changes are not trivial, even error codes might break things. There may be a way to do this without breaking existing relations if we include capability communication on HTTP headers for example - to help version negotiation. But it's not easy, and we should see if it's really worth it.

For consistency checks I would leave it to the CA to make sure they send all their updates as a single RFC 8181 delta.

On the other end of the possible spectrum a Publication Server could actively validate everything, and even remove things. I think that goes way too far and is dangerous, error prone and harmful. Just saying for the sake of discussion.

But.. perhaps it would be good to draft some text and have structured discussion? And yes, if we are going to discuss extending the publication protocol, then there is of course the risk, or feature, that people will want other changes too.


Tim



> 
> Ties
> 
>> 
>>> I would suggest:
>>> 
>>> """
>>> 3) A safeguard scheme is essential to protect the process of ROA
>>>  issuance. Before committing to the issuance of a ROA object, the
>>>  signer software should confirm the ipAddrBlocks in the To-Be-Signed
>>>  eContent are fully contained by the RFC 3779 extensions listed on the
>>>  End-Entity certificate used to generate the signature. 
>>> """
>>> 
>>> In other words, a signing pipeline would help the operator by performing
>>> RFC 6482 Section 4 validation *before* constructing the ROA, to prevent
>>> constructing ROAs the Repository operator would consider invalid.
>> 
>> 
>> All RPKI CA implementations that I know of already take care to issue objects which do not overclaim. The problem is that a delegated CA may not find out that a parent has shrunk their resources until whenever it happens to send them a "Resource Class List Request" as defined in RFC 6492.
>> 
>> It would be much nicer practice if parent CAs can hold off shrinking resources until a child has had a chance to clean up. I will suggest some text to the ROV timing draft.. not sure that this belongs there, but it may be a start.
>> 
>> Tim
>> 
>> 
>> 
>>> 
>>> Kind regards,
>>> 
>>> Job
>>> 
>>> _______________________________________________
>>> Sidrops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops