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

From: Christopher Morrow <[email-masked]>
Date: Mon, 19 May 2014 14:38:48 -0400

On Thu, Apr 17, 2014 at 11:35 AM, Tim Bruijnzeels <[email-masked]> wrote:
> 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}

It's unclear to me what would happen if you split this into a
prefix/asn per cert and just carried more certs in your purse. Why
would I not just add more certs to my purse? is there a particular
reason to conglomerate these under the minimal number of certs? are we
trying to minimize space in my purse? if so the purse is large, and
the certs very small... I could 10x or 100x the number of certs here
and be ok still.

-chris

---

From: Geoff Huston <[email-masked]>
Date: Tue, 20 May 2014 22:10:03 +1000

> the certs very small... I could 10x or 100x the number of certs here

For AS numbers thats an interesting approach, if you carry a single ASN per cert then yes, there would be a whole lot more certs around (-ve), but any discrepancy in AS registry records between parent and child would be limited to just those ASns where there are such discrepancies (+ve)

However I'm unsure how you could or would apply this principle to IPv4 addresses. And I'm even more unclear about IPv6. 

However, in principle, the validation algorithm proposed in this draft performs a validation function which is semantically equivalent to breaking down each certificate into a collection of certificates, each describing one element of the original number set, but this approach does not require one to define the minimal unit of addresses in IPv6, nor try to generate an enumeration of individual /128s (or even /64s!) in IPv6, which I guess is a Good Thing.

Geoff

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 20 May 2014 17:35:23 -0400

> For AS numbers thats an interesting approach, if you carry a single ASN per cert then yes, there would be a whole lot more certs around (-ve), but any discrepancy in AS registry records between par…

ok, in tim's/your(someone's) original note:
--------------------- snip ------------------------

Currently we reject certificate 2 and everything under it..
--------------------- end snip ------------------------

it looks to me like making this 8 ROA instead of 3 would make sense.
The 'isp'/resource-owner (I think - AS64501) would be able to announce
the /12, /22 and /20. The customer/other prefix-users:
   64505 - /12 and /22
   64509 - /12 and /20
   64511 - /22

which seems to catch the intent of the 3 certs at least. This way if
you were to break out a new /X from the /12 for AS65534  no one is
broken and no shuffling has to happen (yet).

If the RIR would break the /12 up into 2x /13, for instance, and
transfer the top/higher /13 off to RIR#2, only the /12 needs to change
and you could do make-before-break over some period of time acceptable
to the 3+ parties involved.

Additionally, if the RIR has an oopsy on the /12 the other prefixes by
the users are ok... hopefully.

It's not clear to me that 'oopsy' will happen on only a single prefix
either? if it can happen to 1, it can happen to 20000. (maybe that's a
chat for another day in the thread though).

> However I'm unsure how you could or would apply this principle to IPv4 addresses. And I'm even more unclear about IPv6.

to /32's? or something else? I suppose TODAY we only really care about
'minimum size prefix (max length) which is globally accepted'. We also
should have data on how quickly the RPKI system converges across it's
whole (perhaps to some level of 'converge') given number of objects in
the global system. (this metric discussion came up several times over
the last M meetings... sriram and tim have some data, but it's not
clear how applicable any of the study work has been)

> However, in principle, the validation algorithm proposed in this draft performs a validation function which is semantically equivalent to breaking down each certificate into a collection of certifi…

sure, but I don't know that we need to go to host-level data do we?
you can't get a host-route routed in the internet today, at least not
beyond your local ISP (save leaks/mistakes), and I think the ROA
format allows you to specify:
  128.2.0.0/16-32 AS5050

right? so in v6:
  2001:4860::/32-128 AS15169

Any case of splitting a prefix (2001:4860::/32  becomes 2001:4860::/33
&& 2001:4860:8000::/33) for the purposes of transfer/change-in-Origin
is going to require /make before break. I don't think that's changed
by the validation algorithm is it?

I do think that being explicit with the roa content and not cute by
chunking as much as possible into the bag is a good thing. It seems,
to me, like it makes the decision process for each ROA less complex,
and thus any further actions on that ROA (splits, joins, deletion,
etc) simpler.

-chris

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 May 2014 14:06:47 -0400

Folks,

I realize I am very late in commenting on this doc, but I was on 
vacation for
a month, and upon return I am working through 2300+ new messages, so ...

I have three concerns with the document:

1- the doc presumes that the solution to the principle problem cited is 
to change
the validation alg. That may be the right outcome, but I think it might 
be more
appropriate to focus on the primary, cited concern, i.e., that a error 
in the
3779 extension(s) of cert for a CA with many children might cause 
problems for many of the
children. Geoff specifically raised this issue for RIRs, and because 
they are acting
as TAs, they have the ability to issue a new self-signed cert that 
adversely impacts
many of their children. NIRs and very large ISPs don't acts as TAs, so 
errors by them
affect certs issued by them to individual children.

One could begin by describing what we believe to be best practices for 
RPKI CAs
with regard to 3779 extension checks. For example, for a CA that is also 
a TA,
it makes sense to run RP validation for every cert issued by the CA 
prior to
publishing a new self-signed cert. That simple process would detect any 
child certs
that would be rendered invalid by an error if the sort cited by Geoff. 
This RP check
can be automated trivially, since the CA/TA has direct access to all of 
the currently-
valid certs that it has issued.

For a CA that is not a TA, the impact of a 3779 change is limited to the 
subtree for
the affected cert. Here too, it makes sense for the CA to run an RP 
check whenever
it is reducing the scope of the 3779 extensions. So, the automated check 
to run here
would entail two parts: first see if a cert that is being re-issued 
represents a reduction
in scope for the 3779 extension(s); second, fetch the certs issued by 
the CA whose cert
is being reissued, and see if any of them will be invalidated by the 
change.

If those with experience operating RPKI CAs have other suggestions for 
good practice wrt
avoiding the problem Geoff cited, they too should be part of a doc 
addressing this issue.
(I'd also like to verify that the RIRs are, or are not, performing the 
first set of checks
today, for their ss-certs.)

Geoff has argued that other benefits accrue from relaxing the 3779 part 
of the path
validation procedure. There is not agreement on his other examples. For 
example, we
have an I-D describing how to automate more of the resource transfer 
process (draft-barnes-sidr-tao-00). The mechanism described there would 
benefit a little from a relaxed
3779 validation check, but only in very limited circumstances. So, that 
use case does
not seem especially compelling.

2- A separate concern is that the candidate doc contains two separable 
cases: one relaxes
path validation by not mandating that every subordinate cert contain 
only a subset
of the resources in the parent cert. The other case introduces the 
notion of a join
into the RPKI tree structure. This latter case was extensively 
criticized during the
SIDR WG meeting, by a number of folks. I suggest that case not be part 
of a new WG
doc at this time.

3- My final concern/observation, is that the text in the doc that 
describes how to
relax the 3779 aspects of path validation is not, as stated, viable. 
Specifically,
it appears to assume that path validation is performed only for EE 
certs. In the RPKI,
we effect path discovery top down, based on our model for discovering 
CAs and
their children. (In PKIs in general, path discovery may be top down or 
bottom up, or
both toward the middle, but the RPKI is not a generic PKI.) Because of 
the top-
down approach, it makes sense for RP software to validate each newly 
discovered
CA. This is not only an efficiency issue, but also an anti-DOS feature. 
Thus the
description of how to modify the current 3779 path validation alg is not 
adequate.
I believe it can be fixed, and I have indicated how it might be fixed in 
(private)
message excahnges with Geoff. Thus this concern is not a reason to 
reject work on this
topic, but it does suggest that a viable algorithmic description might 
be a prerequisite
for adopting a version of this doc.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 22 May 2014 05:04:55 +1000

Hi Steve,

I appreciate the backlog of mail you are working from, as you note in your mail, but
I always think it useful to have carefully read a document before performing a critique. I'm sure
you would agree with that sentiment. I was therefore quite surprised to find you had said the
following:

> 2- A separate concern is that the candidate doc contains two separable cases: one relaxes
> path validation by not mandating that every subordinate cert contain only a subset
> of the resources in the parent cert. The other case introduces the notion of a join
> into the RPKI tree structure. This latter case was extensively criticized during the
> SIDR WG meeting, by a number of folks. I suggest that case not be part of a new WG
> doc at this time.

I would be grateful for the precise reference in the "candidate doc" you talk about
to the concept of a "join". I looked though draft-huston-rpki-validation-01.txt, and 
maybe I missed something incredibly obtuse and well buried in the whitespace, but I
couldn't find any such reference in this document. Are you perhaps performing a critique
of some other draft in this rather lengthy message and not in fact referring to 
draft-huston-rpki-validation-01.txt at all?

The description of the first case is also inappropriately informal - the alternative view
described in the draft is that a relying party can consider a certificate to be valid
with respect to only those resources that are contained in all certificates that form
the validation path. Perhaps the subtle difference in your description might be the
cause of your evident discomfort with what you believe is contained in this document.

I think a careful read of section 2 of this draft adequately addresses why your proposal for 
additional operational procedures in point 1 of your note seems to be well wide of addressing the issues
described in the draft. 

The assertion in point 3 that this is "not viable" I interpret as one opinion, most likely one held
by yourself. Obviously there are other opinions and perspectives on this matter, and this draft
describes such a different perspective and also includes the motivation behind it. I would recommend
that perhaps this conversation would benefit from such a careful reading of the draft in question.

regards,

Geoff

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 May 2014 14:39:18 -0400

Geoff,
>> SIDR WG meeting, by a number of folks. I suggest that case not be part of a new WG

I did read the doc carefully, and we exchanged a few very detailed 
messages in mid-February,
prior to the SIDR meeting in London. But, that was a few months ago, and 
I conflated your
briefing at that meeting (specifically slide 15) with the text of the 
document.
My bad.
> draft-huston-rpki-validation-01.txt at all?
you're right; As noted above, I was referring to slide 15 in your 
briefing at
the SIDR meeting (a briefing on the doc in question, hence my confusion).
> cause of your evident discomfort with what you believe is contained in this document.
The "algorithm" in the I-D, Section 3.2, describes validity in terms of a
"specific resource". The definition of the phrase specific resource is 
vague,
at best. It made sense if one assumed that the specific resource was 
contained in
an EE or CA) since that would avoid declaring a superior CA cert as 
invalid if an
RP did not try to evaluate such a cert. But, for the incremental, top 
down CA
cert eval process, there is no indication of how one should determine a 
specific
resource. Your slides were better ion this point, suggesting that one 
construct
the set of valid resources as part of the cert path evaluation process. 
But, you
noted that my criticism of the "join" aspect of you design was 
inaccurate, because
it is not in the doc in question, so, equivalently, the improved 
description of
the proposed path validation alg in youyr slides ought not be in scope 
either :-).
> additional operational procedures in point 1 of your note seems to be well wide of addressing the issues
I agree that my suggested CA practices represent a deviation from the 
mechanism you
are tryign to describe. But, if the WG is to consider revising path 
validation
based on the concerns you cite, then it makes sense to ask whether RIR 
CAs, in particular,
are doing what could already be done to avoid the problems in question. 
If not, then it
seems somewhat premature to impose significant changes on all RPs when 
CAs are not
doing what they could to address this potential problem. I'm not saying 
that we
ought not consider your proposal, but let's try to avoid the problem 
with easy,
prudent behavior by CAs, first.
> that perhaps this conversation would benefit from such a careful reading of the draft in question.
As I noted, and as you well know, I read the draft carefully and sent a 
couple of long messages to
you, cc'd to the WG chairs, on 2/13 and 14. The perspective of the I-D 
is not the issue; the issue is that it is imprecise on a number of 
important points. It is not a rigorous description of a proposal. Of 
course there are other opinions; there always are in the IETF.

Steve