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

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 11 Mar 2014 22:27:36 +0000

I went through your -01 draft and the SIDR presentation slides from last week once again, 
and have the following questions: 

(1) An update with prefix-origin pair {5.0.0.0/24, AS64511} is received. 
There is a ROA: {5.0.0.0/22, maxLength = 24; AS64511} in the RPKI. 
However, it is signed using a certificate that is “valid” only for resource {5.0.0.0/24}.  
In this case, is it the intent of your alternate validation model to ascertain that 
the above ROA is partially valid, and accordingly prefix-origin pair {5.0.0.0/24, AS64511} is “Valid”?

(2) Let us say, there is a ROA: {1.0.0.0/24, 2.0.0.0/22, 3.0.0.0/20; AS64500} in the RPKI. 
But this ROA is signed using a certificate that is “valid” only for resources {1.0.0.0/24, 3.0.0.0/20}
that is a subset of the prefixes listed in the ROA.  
In this case, is it the intent of your alternate validation model to ascertain that 
the above ROA is partially valid, and accordingly prefix-origin pairs 
{1.0.0.0/24, AS64500} and {3.0.0.0/20, AS64500} are “Valid”? 

(3) On slide #18, do you need to require “Certificates 1 through n-1 are also “valid” 
according to this same criterion”?  You are not validating them at this point. 
You are only validating Certificate ‘n’ for *a given INR*. 
Is it not enough to require that “the resources in the INR extension of 
Certificate x must subsume the given INR” for each x (individually); x=1, 2, 3, …, n? 

Thanks.
Sriram

---

From: Geoff Huston <[email-masked]>
Date: Wed, 12 Mar 2014 17:13:37 +1100

Hi Srinam,

Thanks for your questions - let me try and answer them as best I can...

> the above ROA is partially valid, and accordingly prefix-origin pair {5.0.0.0/24, AS64511} is “Valid”?

If I understand your question, you are painting the picture where:

The ROA says that AS64511 can announce 5.0.0.0/22 or any subset  up to a /24

The EE cert that signed it has a resource extension of 5.0.0.0/24 (i.e. the ROA is overclaiming)

And the CA that signed it has a resource extension set that encompasses 5.0.0.0/24

And the CA "above" it has a resources extension that encompasses 5.0.0.0/24

etc to the trust anchor

So if we said "is the UPDATE 5.0.0.0/24 valid" then given that 5.0.0.0/24 is contained
in the ROA, and the same prefix is contained in all the certs from the EE cert to a TA in an otherwise
valid validation path, then the answer would be YES

Although I note that the draft did NOT explicitly talk about the relationship
between a ROA and the EE cert that signed it. It only talked about the treatment of the
resource extensions in the pair-wise comparison of certificates in the validation path.
In your question you've extended that same approach to the relationship between the
EE cert that signed the ROA and the ROA. I think that is a consistent extension, but 
its a matter that should be further considered.

> {1.0.0.0/24, AS64500} and {3.0.0.0/20, AS64500} are “Valid”? 

In this example you are again painting a picture of a ROA that "overclaims" as compared to the resources
listed in the EE certificate that signed it.

Assuming that there are validation paths for 1.0.0.0/24 and 3.0.0.0/24 between a TA and the EE cert then yes,
by the same reasoning as the answer to the previous question I would say that a consistent answer
is that these two updates would be accepted as "valid"

(with the same caveat that this is an extension to the described approach to certificate
validation, but an extension that I personally am comfortable with)

> Certificate x must subsume the given INR” for each x (individually); x=1, 2, 3, …, n? 

I was taking the text of RFC3779 that defined the certificate validity (slide 3) and was illustrating
the difference in that text were we to use this approach. I think your formulation of the text has the same semantic
intent as the text on slide 18, but your text highlights the difference from RFC3779, while I was 
trying to illustrate what would need to change from the original validation definition.

Either that or I have not understood your question! If so, could you explain this a bit more?

regards,

    Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 12 Mar 2014 19:07:18 +0000

Geoff,

Thanks for the reply.
Quoting from your responses,

> I think that is a
>consistent extension, but its a matter that should be further considered.

>validation, but an extension that I personally am comfortable with)

Yes, that is right. I think we are in sync on my questions (1) and (2), 
except that as you've said all this needs further consideration by the WG.

For my question (3), we need to delve deeper. Please see my next email.

Sriram 

>-----Original Message-----
>From: Geoff Huston [mailto:[email-masked]]
>Sent: Wednesday, March 12, 2014 2:14 AM
>To: Sriram, Kotikalapudi
>Cc: George Michaelson; sidr wg list
>Subject: Re: Questions about draft-huston-rpki-validation-01
>
>Hi Srinam,
>
>> I went through your -01 draft and the SIDR presentation slides from
>> last week once again, and have the following questions:
>>
>> However, it is signed using a certificate that is "valid" only for resource
>{5.0.0.0/24}.
>> In this case, is it the intent of your alternate validation model to
>> ascertain that the above ROA is partially valid, and accordingly prefix-origin
>pair {5.0.0.0/24, AS64511} is "Valid"?
>
>So if we said "is the UPDATE 5.0.0.0/24 valid" then given that 5.0.0.0/24 is
>contained in the ROA, and the same prefix is contained in all the certs from the
>EE cert to a TA in an otherwise valid validation path, then the answer would be
>YES
>
>between a ROA and the EE cert that signed it. It only talked about the treatment
>of the resource extensions in the pair-wise comparison of certificates in the
>validation path.
>In your question you've extended that same approach to the relationship
>between the EE cert that signed the ROA and the ROA. I think that is a
>consistent extension, but its a matter that should be further considered.
>
>
>>
>> But this ROA is signed using a certificate that is "valid" only for resources
>{1.0.0.0/24, 3.0.0.0/20}
>> {1.0.0.0/24, AS64500} and {3.0.0.0/20, AS64500} are "Valid"?
>
>
>> (3) On slide #18, do you need to require "Certificates 1 through n-1 are also
>"valid"
>> according to this same criterion"?  You are not validating them at this point.
>> You are only validating Certificate 'n' for *a given INR*.
>> Is it not enough to require that "the resources in the INR extension of
>> Certificate x must subsume the given INR" for each x (individually); x=1, 2, 3,
>..., n?
>
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 12 Mar 2014 20:17:11 +0000

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

---

From: Geoff Huston <[email-masked]>
Date: Mon, 17 Mar 2014 12:15:03 +1100

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
> 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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 17 Mar 2014 23:21:30 +0000

Geoff,

Thanks. Comments inline.

>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. 

>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)/ 

>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 <[email-masked]>
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,

You point out

regards,

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 18 Mar 2014 10:46:49 +1100

Hi Sriram,

> its certification path (per Section 6 of RFC5280)/ 

agreed, this is a little cleared

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

agreed

> is that well defined for a ROA as well?

RFC6482 need not be altered at all.

Section 4 of RFC64582 states:

      The IP address delegation extension [RFC3779 is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.

which still holds in this slightly altered certificated validation framework.

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

I am working on clarity here in terms of explaining the benefits of this approach.

thanks,

   Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 18 Mar 2014 12:22:27 +0000

Geoff,

>which still holds in this slightly altered certificated validation framework.

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)? 
Such as:
A ROA is "valid" for a given IP address prefix specified in the ROA, 
if the given IP address prefix is subsumed in the resource extension field 
of the end-entity (EE) certificate (contained within the ROA),
and also subsumed in the resource extension field of all other certificates 
that are contained in a certification path, where the 
construction of this certification path is defined in Section 6 of RFC5280.

Sriram

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Mar 2014 06:10:20 +1100

> (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.

regards,

  Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 18 Mar 2014 20:09:26 +0000

>> the alternate validation algorithm for a ROA need slightly different
>> wording (as compared to that for certificates)?
>
>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 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.

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.

Thanks.
Sriram