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

["Sriram, Kotikalapudi" <[e-mail]>]

Geoff,

Thanks. Comments inline.

>Hi Sriram,

>I am espousing method B in your terminology.

Yes, I thought so. I also think method B should be preferable over method A, 
if we do go down this path. 

>Perhaps if I rephrase the validation question a little, 
>it may be a little clearer.

>The validation question is: Given a certificate X and a TA certificate, 
>for what resources is this certificate "valid"?

Suggestion:
s/Given a certificate X and a TA certificate/Given a certificate X and 
its certification path (per Section 6 of RFC5280)/ 

>You point out
>> (In terms of language and clarity, the notion of calling a certificate "valid" 
>> is misleading when in fact all that is being checked is merely 
>> whether a given INR is subsumed in it.)  

>Maybe there is a way of tightening this up. 
>How about: A resource contained in the resource extension 
>of a certificate is defined as "valid" if this resource 
>is listed in the resource extension field of all certificates 
>that are contained in a certification path, where the 
>construction of this certification path is defined in section 6 of RFC5280.

Suggestion:
s/is listed in the resource extension field of all certificates/
/is subsumed in the resource extension field of each of the certificates/

(Note: A prefix may not be listed but may be subsumed in a less specific that is listed.)

Do you need somewhat different wording for the case of ROA validation?
(Is a ROA also technically a "certificate"?)
When you say "resource contained in the resource extension",
is that well defined for a ROA as well?

>(In the WG I also considered a slightly expanded question: 
>Given a certificate X and a set of TA certificates, 
>for what resources is this certificate "valid"?, 
>but that proved to be a little more controversial for many!)

Yes, I also feel that the “join” idea is far more complicated and the benefits are not clear.

Thanks.
Sriram

________________________________________
From: Geoff Huston <[e-mail]>
Sent: Sunday, March 16, 2014 9:15 PM
To: Sriram, Kotikalapudi
Cc: George Michaelson; sidr wg list
Subject: Re: Questions about draft-huston-rpki-validation-01

Hi Sriram,

I am espousing method B in your terminology.

Perhaps if I rephrase the validation question a little, it may be a little clearer.

The validation question is: Given a certificate X and a TA certificate, for what resources is this certificate "valid"?

You point out
> (In terms of language and clarity, the notion of calling a certificate "valid"
> is misleading when in fact all that is being checked is merely
> whether a given INR is subsumed in it.)

Maybe there is a way of tightening this up. How about: A resource contained in the resource extension of a certificate is defined as "valid" if this resource is listed in the resource extension field of all certificates that are contained in a certification path, where the construction of this certification path is defined in section 6 of RFC5280.

Back you your example...So the question posted by the ROA, which is signed by certificate 3, is "Is certificate 3 valid for 10.0.0.0/24?"

As you've described here the certification path is Cert 1, Cert 2, and Cert 3, and as 10.0.0.0/24 is contained in the resource extension of all of these certificates then it can be concluded that the question posed by the ROA, namely whether certificate 3 is valid for 10.0.0.0/24, can be answered in the affirmative.

(In the WG I also considered a slightly expanded question: Given a certificate X and a set of TA certificates, for what resources is this certificate "valid"?, but that proved to be a little more controversial for many!)


regards,

   Geoff







On 13 Mar 2014, at 7:17 am, Sriram, Kotikalapudi <[e-mail]> wrote:

> Geoff,
>
> About my Question (3), let us discuss this a bit more carefully with an example.
>
> There is this ROA: {10.0.0.0/24, AS64499} that we wish to validate.
> It is signed with Certificate 3, which has the following certificate path to the TA:
> Certificate 1: It lists {10.0.0.0/12, AS64501, AS64505, AS64509}  (TA certificate)
> Certificate 2: It lists {10.0.0.0/22, AS64501, AS64505, AS64511}
> Certificate 3: It lists {10.0.0.0/20, AS64501, AS64505}
> Note: Certificate 1 is the TA certificate.
>
> It is clear that following the current (RFC 3779) method,
> Certificates 2 and 3 are invalid, and it follows that the ROA is invalid.
>
> Now, there are two methods that we may enumerate for a modified (or alternate)
> validation proposal:
>
> Method A (more conservative but less robust relative to Method B below):
>
> Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3.
>
> Step 2: Do the resources in Certificate 3 subsume the prefix in the ROA?  Answer: YES,
> because "the INR of interest" 10.0.0.0/24 in the ROA is subsumed by
> an INR 10.0.0.0/20 in Certificate 3. OK, now proceed to validate Certificate 3.
> Note that "the INR of interest" in Certificate 3 is 10.0.0.0/20.
>
> Step 3: Ask if the resources in Certificate 2 subsume "the INR of interest" in Certificate 3?
> Answer: NO, because "the INR of interest" 10.0.0.0/20 in Certificate 3 is NOT subsumed
> by an INR in the parent Certificate 2.
> (Note: The parent Certificate 2 has a more specific prefix 10.0.0.0/22.)
>
> Step 4: Since the certificate chain "validation" failed at Step 3, declare the ROA
> being considered as "Invalid" for the prefix-origin pair {10.0.0.0/24, AS64499} .
>
> Method B (less conservative but more robust relative to Method A above):
>
> Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3.
>
> Step 2: Set "the given INR" as 10.0.0.0/24. That is the INR in the ROA for which
> validation is being sought.
> [Note: "The given INR" remains a constant in the steps that follow.
> We just *stay focused on this given INR* for the rest of the validation process below.
> This is the main difference compared to method A.]
>
> Step 3: Do the resources in Certificate 3 subsume the "the given INR" 10.0.0.0/24?
> Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.0.0/20 in Certificate 3.
>
> Step 4: Do the resources in Certificate 2 subsume the "the given INR" 10.0.0.0/24?
> Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.0.0/22 in Certificate 2.
>
> Step 5: Do the resources in Certificate 1 subsume the "the given INR" 10.0.0.0/24?
> Answer: YES, because the given INR 10.0.0.0/24 is subsumed by an INR 10.0.0.0/12 in Certificate 1.
>
> Step 6: Since the certificate chain "validation" passed at each step above
> for "the given INR" 10.0.0.0/24, declare the ROA being considered
> as "Valid" for the prefix-origin pair {10.0.0.0/24, AS64499} .
>
> So Method A produces an "Invalid" result for the ROA,
> whereas Method B yields a "Valid" result.
> I hope the difference between Methods A and B is clear.
> In Method A, "the INR of interest" at level x must be subsumed by an INR at level x+1.
> But in Method B, only "the given INR" (e.g., a prefix in a ROA or an ASN in a router certificate)
> is the steady focus, and what is required is that "the given INR" must be subsumed
> by resources listed in the certificate at each level (1, 2, 3, ..., n).
>
> The description on your Slide #18 falls short of describing precisely
> either Method A or Method B. From your Slide #14, it seems evident that you are
> proposing Method B; am I right?
> (In terms of language and clarity, the notion of calling a certificate "valid"
> is misleading when in fact all that is being checked is merely
> whether a given INR is subsumed in it.)
>
> Sriram
>
>