Re: [sidr] Questions about draft-huston-rpki-validation-01

[Tim Bruijnzeels <[e-mail]>]

Hi,

Sorry for the late reply, I have been very busy with other work.

On Mar 18, 2014, at 9:09 PM, "Sriram, Kotikalapudi" <[e-mail]> wrote:

>>> 
>>> That is good. But what I meant was (in your I-D under discussion) does
>>> the alternate validation algorithm for a ROA need slightly different
>>> wording (as compared to that for certificates)?
>> 
>> I think not.  RFC6482 did not define how the EE certificate is to be validated.
>> It simply states that the IP addresses listed in the ROA must also be found in the
>> resource extensions of the signing EE cert. This still holds.
>> 
>> i.e. no change is required there.
>> 
> 
> I think you are saying that a ROA is "valid" for all prefixes listed in it, if the signing EE cert is 
> "valid" for each of those prefixes (in accordance with the alternate validation method).
> I.e., there is no such thing as 'the ROA is (partially) valid for some of the listed prefixes'.
> Does not harm to include some statement this effect in your I-D.

I agree with the original observation made by Geoff and George about brittleness wrt ROA validation and resources in the chain that are irrelevant.

If I could paraphrase the method B how I see it from a top-down perspective, using a modified example where 'Certificate 2' has a mixup of an AS resource:
Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509}  (TA certificate)
Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511}
Certificate 3: {10.0.0.0/20, AS64501, AS64509}

Currently we reject certificate 2 and everything under it.. 

But, the way I see it in the RPKI world is that these CA certificates just tie a bunch of resources to a key pair. They don't actually try to make any other authoritative statements over these resources. So in other words I would be perfectly happy to take change the semantics and *warn* about any over-claiming resources, and accept only the *union* of resources between a certificate and its parent. In this case that would result in:

Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509}  (TA certificate)
Certificate 2: {10.0.0.0/22, AS64501, AS64505}  (discard: AS64511)
Certificate 3: {10.0.0.0/20, AS64501} (discard: AS64509)

In the RPKI the more meaningful statements about resources are all done with EE certificates. Signed objects like ROAs and Ghostbusters have a corresponding EE certificate, and BGPSec certificates are also EE certificates. These are the things that actually make the interesting statements like "valid holder of resource X proclaims that.. etc".

So, summarising I think the simplest approach here could be just accept the union of resources for CA certificates, but insist that EE certificates are not over-claiming.

So this would then be perfectly valid:
EE Certificate: {10.0.0.0/20} 
For ROA: listing prefix 10.0.0.0/20 only

Others can speak for themselves (Rob?, David?), but my impression was that they were actually also open to this general idea although it needs maturing. (as opposed to the joins below)

> We discussed the possibility of ROA over-claiming earlier. 
> The above is not accommodative of that. And I think that is also OK for now.
> We can revisit if robustness to ROA over-claiming is something 
> that interests anyone else on this list.

We are currently fate sharing authorisations for different prefixes and the same ASN on ROAs. We have an average of about 3 prefixes per ROA, so this allows us to reduce the number of ROAs we publish to about 1/3rd of what we would need otherwise.

There is a lot of complexity and controversy in partially accepting ROAs, or even having splits and joins and accepting part here, part there, or (more complicated) having to join validation paths. It becomes difficult to troubleshoot issues and report meaningfully about errors. I see some possibilities here, but I am not convinced. I think it would mainly save in the number of certificates and objects needed, but in the end this is all handled by tools. I don't think they (should) care too much about these numbers (a factor of 3 or something) relative to the other costs.

So all in all, I think we're probably better off keeping things simpler and in our case create more ROAs: i.e. one for each prefix.

Tim




> Thanks.
> Sriram  
> 
> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr