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

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

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