Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

From: "George, Wes" <[email-masked]>
Date: Mon, 4 Aug 2014 16:42:35 -0400

Late to the discussion because I needed to have cycles to read and think
about this draft...

On 7/31/14, 4:03 PM, "Stephen Kent" <[email-masked]> wrote:

>Terry has reminded us that, even if such accidents occur, the world does
>not end, at
>least wrt origin validation. Thus, for the current set of SIDR RFCs, the
>damage that
>would occur is not nearly so great as some have suggested; until the
>error is fixed (which
>one would presume would be fairly quickly), origin validation would
>treat the affected
>routes as no worse than they are treated today.

WG] Maybe I'm missing something, but I'm not sure I agree with this
characterization. This is probably true for routes that transition from
Valid to Unknown, but not if they are actually found to be Invalid, which
is what I understand would be the result of the problem discussed in this
draft - invalid certs = invalid routes. While policy is ultimately a local
matter, in 7115 we recommend dropping invalids due to the fact that it
isn't possible to depref any routes enough to ensure that they are never
used if they are more specific than a valid or unknown route with a
comparably higher local pref. Unless we're changing that guidance, "%
Network not in table" is worse than they'd be treated today.

Deploying SIDR OV is about risk vs reward, i.e. How much benefit do I gain
in terms of what outages (attack vectors) I'm protecting myself and my
customers against vs what risk the same parties incur for experiencing
other outages that only exist if I am deploying OV. The possibility of
routes being invalidated and dropped on account of a botched cert overlap
or migration puts this squarely on the wrong side of the risk/reward
balance.

Thanks

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 4 Aug 2014 17:47:42 -0400

speaking as a regular ol' member

> This is probably true for routes that transition from
> draft - invalid certs = invalid routes. 

Well….

invalid EE certs = invalid ROA (for the most part - there's operational consideration about not removing an EE cert if a repository is unavailable, I suppose)

An invalid ROA does not necessarily mean an invalid route.

If there is no other covering ROA, then a BGP route for that prefix becomes unknown, as Terry pointed out.

If there is another ROA which covers the same prefix, then a route may be invalid -- if no covering ROA authorizes the ASN that the invalidated ROA mentions.

--Sandy, speaking as a regular ol' member

---

From: "George, Wes" <[email-masked]>
Date: Tue, 5 Aug 2014 11:51:17 -0400

On 8/4/14, 5:47 PM, "Sandra Murphy" <[email-masked]> wrote:

>If there is another ROA which covers the same prefix, then a route may be
>invalid -- if no covering ROA authorizes the ASN that the invalidated ROA
>mentions.

WG] I'm once again bitten by an incomplete understanding of the way that
the PKI interacts with the routing side. Sigh. That makes more sense, but
since I have often volunteered to be "new guy who's not an RPKI expert"
thus serving as the canary in the coal mine for finding the hidden gotchas
like this, we have a very important detail here that may or may not be
properly covered in our existing documents.

I went poking through 6907, and it contains a useful definition for a
covering ROA that seems to imply that an invalid ROA could technically
still be considered a covering ROA, but for this:
"For all of the use cases in this document, it is assumed that RPKI
   objects (e.g., resource certificates, ROAs) validate in accordance
   with [RFC6487] and [RFC6480].  In other words, we assume that
   corrupted RPKI objects, if any, have been detected and eliminated."

So that text explicitly declares this case of invalid ROA and how to
handle it out of scope for the scenarios discussed.

Restating the combination of this text and your answer above, is it
accurate to say that invalid ROAs are removed before the RP ever gets to
the step where it checks to see if they are covering or matching, thus it
is impossible for an invalid ROA to invalidate a route? Is that required
by the standard, or simply an implementation convention that some or all
of the existing RP software follows?

I think that begs some further questions: Is there ever a case where we
*want* an invalid ROA to translate to an invalid route, or do we *always*
want to simply punt those from the system so that the routes they would
have covered are tested only against any remaining valid ROAs? Do we ever
see a need to treat an invalid ROA as a revoke? Is the behavior any
different if the ROA was previously valid and unexpired, and suddenly
becomes invalid vs if it was previously unknown and the first ROA that
shows up is invalid? I'm quite sure that diving into this will also
generate a bunch of unpleasant questions about tiebreaker behavior when
both valid and invalid ROAs match or cover prefixes, so it may be simpler
to just make it clear that this is the intended behavior, but I figured
I'd pose the questions since that's what we seem to be having a
fundamental misunderstanding about.

I think that there are probably still cases during a transfer where if you
get the order of operations wrong, in addition to the invalid ROA, you
will have a second valid covering ROA that might not match what's being
announced and thus a potentially invalid route. That's probably what needs
to be enumerated in the validation-reconsidered draft as the problem with
the biggest potential impact, even if it's secondary to the main failure
mode where a bunch of routes just go to unknown status and temporarily
lose the protection that origin validation is supposed to provide.

Thanks
Wes George

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 05 Aug 2014 14:49:06 -0300

Hello,

I think what we need to discuss is which certificate validation rules
apply to our problem domain, basically securing origin and/or securing path.

Current specs refer that RFC 3779 validation rules should be applied to
SIDR's problem domain. I couldn´t find any justification for this, other
than 'RFC 3779 was already there by the time SIDR started'. Maybe I'm
wrong and this discussion indeed took place. I'd appreciate any pointers.

Regarding our draft, maybe we can split the discussion about possible
solutions to the problem (as I understand from our last meeting there
was rough consensus that there is indeed a problem to be solved here) in
two parts:

- Unbundling: For example, a wrong ASN list currently invalidates both
IPv4 and IPv6 resources in the same cert and down below. It doesn´t seem
to make much sense to have a mistake in one resource type invalidate the
other two. Discuss #1!

- Managing mistakes within the same resource type: Should a mistake in
one IPv4 prefix invalidate the whole cert and down below for *all*
prefixes? Discuss #2!

I agree on keeping the discussion to real world problems and not
perceptions. So the 'encouraging sloppiness' argument, whether perhaps
having some merit, is not really about a threat or a specific attack or
a about a specific problem.

cheers!

-Carlos

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 5 Aug 2014 21:10:53 +0200

Hi all,

> If there is another ROA which covers the same prefix, then a route may be invalid -- if no covering ROA authorizes the ASN that the invalidated ROA mentions.

I think we are dealing with a low-risk, but high-impact scenario here.

Arguments have been made to depict this as a virtually-no-risk and low-impact problem, but I am not convinced. 

I want to reduce the impact because low-risk, low-impact is a much better place to be.. I believe this is possible without any serious adverse effects.

With regards to impact:
=======================

= Origin validation:

Indeed: routes would (almost certainly*) go from Valid to Unknown. But, what are we trying to achieve here by this whole origin validation thing? Valid is preferred over Unknown, why else would we bother with this stuff in the first place? Sure, being pushed to Invalid is much worse, but a complete failure of origin validation for a large part of the internet (e.g. a whole RIR region) still counts as a high impact event in my book.

*: If a valid ROA exist through another certificate chain then routes could become Invalid. This scenario is less likely to happen by accident, because the parent would have to issue the same resource to more than one child certificate.

= Path validation:

For path validation it was mentioned that there is no ‘unknown’ state. And I am not sure if it’s even possible to differentiate here between ‘Invalid’ vs ‘Unknown’. I expect that the difference would be: knowing that that a path has been tampered with (key known, signature invalid) vs not being able to verify (unknown key). This looks attractive, but I think it opens an easy attack to just sign with a random key and the path is suddenly ‘unknown’ and not ‘invalid’.. Maybe I am missing something, if someone has an idea about how this could work that would be great. Unknown is still a better place to be than invalid, but only if there is a real difference between the two.

So, all in all, I still believe that this *is* a high impact problem.

The solution the authors have been suggesting to this problem consists of *limiting* the impact to just the affected resources. If we had that we could turn this problem into a low-risk, and much-lower-impact problem.

With regards to risk:
=====================

Low risk does not equal no risk. And combined with high impact this is problematic.

While all RIRs and other responsible CAs are using precautions, there are many moving parts and problems can happen. Bugs in software, human error, timing issues in publishing parent and child certificates can all result in inconsistencies between the certificate issued and published by the parent at a point in time, and what the child believes they have.

Currently RIRs maintain their own TAs, and this puts them in a position where they have full control and knowledge of when changes occur, so currently the risk these inconsistencies is fairly limited (but not absent). In case this changes the risk increases. And because it’s child certificate that ends up being rejected the immediate impact is on the party that has the least control over this.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Aug 2014 17:11:07 -0400

Carlos,

> wrong and this discussion indeed took place. I'd appreciate any pointers.
3779 was developed for the RPKI context (when S-BGP was the encompassing 
term);
that's why it was adopted by SIDR. The extension was developed by folks with
considerable PKI expertise, as a way to make minimal changes to standard PKI
path validation.,
> to make much sense to have a mistake in one resource type invalidate the
The original S-BGP design had 2, essentially parallel PKIs, one for ASNs
and one for address blocks. We elected to consolidate the two into
one because the CAs are the same in most cases, and it saves space,
bandwidth, etc., even though the extensions are distinct. Combining the two
trees was seen as a good engineering  decision, even though the 
resources are separate.
But, then, so are IPv4 and v6 address prefixes.  Do you propose creating 
separate PKIs
for IPv4 and IPv6 addresses?
> one IPv4 prefix invalidate the whole cert and down below for *all*
Should revocation of a cert with a set of prefixes invalidate all
the certs below? (hint, the answer is yes.) The examples cited by
you and your fellow authors focus only on errors in 3779 extensions,
but why are revocation errors not equally important to address?

A PKI based on X.509 yields a  binary validity outcome for path validation,
plus a set of ancillary info  that may be used  by an app. One might 
imagine
treating 3779 extensions as ancillary data, but that won't affect the 
revocation
error situation.

> a about a specific problem.
The sloppiness argument is very much a real world issue, based on two 
decades
of experience in the Web PKI environment. Certs used in the Web PKI 
frequently do
not adhere to PKIX specs, validation is sometimes sloppy, and the 
results have led
to real attacks. (For example, a major vendor failed to enforce the CA 
flag in the
Basic Constraints extension, and that allowed attacker to forge certs.)

Steve

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 05 Aug 2014 18:51:03 -0300

Stephen,

(snipping for brevity)

> considerable PKI expertise, as a way to make minimal changes to standard

Given that S-BGP failed to gain any traction and most people outside the
IETF have never heard of it, I don´t think it sets a particularly
encouraging precedent.

There is nothing wrong with the extension, nor with the rules per-se.
Some of us believe that 3779 rules are not a good match for this
particular problem. They may very well be for other, related, problem
domains (whole network transfers come to mind now).

> for IPv4 and IPv6 addresses?

Definitely not. Again, S-BGP is not a particularly good data point. I
propose to *unbundle* the analysis of resource types when validating
certs. I believe that is clear from my earlier email and from our draft.

On the other hand, if you believe that unbundling introduces any new
threat, please do comment on that.

> but why are revocation errors not equally important to address?

The ability of not being able to correct 1 issue out of 2 doesn´t seem
to be a good argument for leaving the 2 unfixed.

In addition, revocation errors are way less probable than transient
registry inaccuracies. I actually don´t see how we would revoke a cert
by mistake, although I´m not saying it cannot happen. If I had to put
probabilities to it, I would say 99% of problems will come from registry
inaccuracies vs 1% revocation errors.

So, if 2 weeks of work (Tim says 1 day, but given he's a particularly
gifted coder we´ll give everyone else 14 times as much) can solve 99%
(or 90%, or even 80%) of issues and remove a large roadblock for the
continuing adoption of OV and RPKI, it seems like a no brainer.

The intent of our draft is not to say that RFC 3779 is in error, it just
goes to say that the validation model it proposes will possibly create
difficult scenarios in real-world RPKI deployments, scenarios that will
undermine the trust in the overall solution.

regards

Carlos

---

From: Stephen Kent <[email-masked]>
Date: Wed, 06 Aug 2014 11:44:40 -0400

Carlos,

...
> IETF have never heard of it, I don´t think it sets a particularly
You asked why 3779. I explained. The were many reasons why S-BGP
didn't succeed, but use of 3779 is not likely one of them.
> domains (whole network transfers come to mind now).
The SIDR WG began meeting in 2006, I believe. The SIDR arch doc was 
first posted
(as an accepted WG I-D) on 2/28/07. It cited 3779 as the basis for the RPKI.
It seems curious to me that it has taken 7 years for senior RIR tech 
staff to
determine that there is a problem. You are relatively new to this 
effort, but what
is the excuse for your co-authors?
> certs. I believe that is clear from my earlier email and from our draft.
The earlier draft did not contain an algorithm for doing what
Geoff has recently suggested as a way to do this. That I-D contained
a set of text that tried to convey what the authors wanted to happen,
but it was sloppy and focused only on EE cert validation. The current
I-D tries to describe a problem space, and it should do so without
prejudice wrt a solution. Your comments suggest otherwise.
(Also, since you keep criticizing S-BGP, how extensive is your 
understanding
the system, beyond knowing the acronym. Have you read any of the papers, 
or are
your comments based on hearsay?)

> ...
Quite the contrary. If a major rationale for changing path validation is
to deal with mistakes by RPKI CAs, then let's articulate the rationale
clearly and comprehensively, so that it guides our selection of a solution.
if we adopt one fix based on an incomplete description of the problem, it
may cause us to postpone developing a more comprehensive solution. Also
a more comprehensive solution might avoid duplication of mechanisms.
> inaccuracies vs 1% revocation errors.
Your numbers seem very speculative to me. At best they are based on
the limited experience that RIRs have with managed CA services for clients.
So I am not convinced that you have a solid basis for projecting one type of
error vs. another when support for CAs run buy net operators is deployed.
> continuing adoption of OV and RPKI, it seems like a no brainer.
I agree that there is a "no brainer" here, but you would not like
my assessment of why. As Terry noted, the "end of routing as we
know it" or taking an entire country offline, claims that were made
were misleading, wrt OV. So, why do you see resolution of this issue as
a major impediment to continuing adoption of the RPKI?

Steve

---

From: Andy Newton <[email-masked]>
Date: Fri, 8 Aug 2014 15:39:01 +0000

On Aug 6, 2014, at 11:44 AM, Stephen Kent <[email-masked]> wrote:

> The SIDR WG began meeting in 2006, I believe. The SIDR arch doc was first posted

Either the question Carlos has asked is unanswered or the answer is using circular logic. I cannot tell which.

The question was about why, in this effort, we are using 3779 validation rules, and the answer appears to be because a past, failed effort used them. Is there really no technical justification?

> It seems curious to me that it has taken 7 years for senior RIR tech staff to
> determine that there is a problem. You are relatively new to this effort, but what

C’mon Steve. You're better than this.

-andy

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 8 Aug 2014 14:04:39 -0400

speaking as regular ol' member

On Aug 8, 2014, at 11:39 AM, Andy Newton <[email-masked]> wrote:

> \

and previously

On Aug 5, 2014, at 1:49 PM, Carlos M. Martinez <[email-masked]> wrote:

> than 'RFC 3779 was already there by the time SIDR started'. 

The RPKI was intended to certify the rightful holder of a prefix.  So it was designed to follow the current prefix allocation system.  In the current prefix allocation system, you can only allocate prefixes that you hold.  So the RPKI validation rules were designed to ensure that you can only certify allocations from what you are certified to hold.

RFC3779 was also intended to follow the current prefix allocation system.  No surprise, its validation rules ensure that you can only certify allocations from what you hold.  That made RFC3779 useful for the purposes of providing a RPKI certification of prefix allocation.  Reuse of existing technology that provides the features you want is generally considered wisdom.

This prefix allocation system is encapsulated in the RPSL authorization model that is used in some RIRs.  In those systems, you can only create an inetnum if you hold the rights to a parent inetnum.

That's the authorization model people have been using in some regions for decades.   I have always found the fact that the RPKI authorization model was a good match to the IRR authorization model in long use to be reassuring.  It meant the RPKI followed what people had already long accepted, and it meant that operators should find the semantics familiar.

--Sandy, speaking as regular ol' member

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Aug 2014 03:35:57 +0900

> The question was about why, in this effort, we are using 3779
> validation rules

because we understand how they work formally from considerable
experience with PKIs.  they are deployed and working today.

the wg is considering an other validation process.  it is still a bit
wobbly, and the need for it is poorly motivated.  if you remember, i
advocated looking at this as a work item, and came up with the one
rather subtle motivation for it.

the rest of the motivations seem to involve transfer, which has never
been defined or formalized, so can be molded to whatever excuse anybody
needs this week.  when the rirs are willing to help define transfer, we
can look at this from an engineering view, as opposed to emotional and
fud.

> and the answer appears to be because a past, failed effort used
> them. Is there really no technical justification?

to paraphrase, C’mon Andy. You're better than this.

randy

---

From: Andy Newton <[email-masked]>
Date: Fri, 8 Aug 2014 19:17:45 +0000

> RFC3779 was also intended to follow the current prefix allocation system.  No surprise, its validation rules ensure that you can only certify allocations from what you hold.  That made RFC3779 usef…

Since we are talking about wisdom, knowing why you are doing something is wise. Doing something just because it was done in the past is following tradition.

> That's the authorization model people have been using in some regions for decades.   I have always found the fact that the RPKI authorization model was a good match to the IRR authorization model i…

Well, not all IRRs are tied to RIR registrations. In fact, most are not.

Reverse DNS might be a better parallel. However, if a particular delegation is lame, the DNS does not consider all delegations of the network holder to be lame.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 8 Aug 2014 19:56:15 +0000

> experience with PKIs.  they are deployed and working today.

Well ok. Where else are the 3779 rules used? Unfortunately, the RFC index does not list references.

> rather subtle motivation for it.

I’m not seeing the relevance of this history lesson to the question that was asked. How does this relate to the technical reasons of why we are using 3779 rules?

> to paraphrase, C’mon Andy. You're better than this.

Imitation is the sincerest form of flattery. I’m now thinking about shaving off my beard. ;)

-andy

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 08 Aug 2014 17:14:28 -0300

Thanks Sandy, yours is actually the first in this very long and
sometimes a bit... strange thread that actually provides an answer to my
original question.

>From your email I identify a subtly different use case from the one that
SIDR seems to be about.

#1 - Certify the rightful holder of a prefix
#2 - Help routers validate prefixes when deciding how to build their
routing tables

RFC 3779 validation rules are probably the best suited rules for #1. It
seems clear now that whether RFC 3779 validation rules are adequate or
well suited to #2 has not been discussed here in depth.

It seems to me that this is a good time to do so.

Have a great weekend.

-Carlos

On 8/8/14, 3:04 PM, Sandra Murphy wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 8 Aug 2014 16:23:12 -0400

> Since we are talking about wisdom, knowing why you are doing something is wise. Doing something just because it was done in the past is following tradition.

You mischaracterize the motivation.  I indicated that the desired features of the RPKI design matched the features provided by an existing technology.  That is decidedly not just following tradition.

For example, the RPKI also uses CMS, because it provides the features the RPKI needs.  That is not just following tradition.

> Well, not all IRRs are tied to RIR registrations. In fact, most are not.

I mentioned those used in some RIRs.  I did not address all IRRs.

Yes, most do not.  Those that do not are subject to unauthorized registrations.  As has happened.  

I am not sure why you are bringing up systems which provide no security in discussing the design of a secure system.  As an example of what to avoid?

> Reverse DNS might be a better parallel. However, if a particular delegation is lame, the DNS does not consider all delegations of the network holder to be lame.

I do not follow the parallel at all.

--Sandy

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 08 Aug 2014 17:25:31 -0300

Hi Steve,

> is the excuse for your co-authors?

I like reading here that there indeed you acknowledge that indeed *there
is* a problem. We have some progress then.

Sorry for being slow though, I promise to be better in the future.

> (Also, since you keep criticizing S-BGP, how extensive is your

Steve, you put words in my mouth, words that I didn't say. I don't
criticize s-BGP. For all I know, it may very well be the best technology
ever designed.

However, the fact that it failed to gain any traction is undeniable. You
might argue that the world at large is stupid and they failed to
acknowledge they had the cure for everything in S-BGP, but I think we
all know better than that.

> your comments based on hearsay?)

Mmmm I tried to find a single operator running S-BGP and failed. Sorry.

Steve, I think you're taking this too personally. I understand that 3779
is your brainchild, and no one is saying that it is 'wrong' in any sense.

The question about whether it is applicable to route and path validation
as it is is a valid one, and there is very, very little coming from the
rest of the WG explaining why we need strict 3779 or detailing what new
attack vectors would be introduced by validation-revisited.

Have a great weekend.

-Carlos

---

From: Andy Newton <[email-masked]>
Date: Fri, 8 Aug 2014 21:16:50 +0000

> You mischaracterize the motivation.  I indicated that the desired features of the RPKI design matched the features provided by an existing technology.  That is decidedly not just following traditio…

I’m fine with not characterizing motives and historical context. Just following your lead. :)

> For example, the RPKI also uses CMS, because it provides the features the RPKI needs.  That is not just following tradition.

CMS is used in many deployed systems. As has been asked but has been left unanswered, in what other deployed systems is 3779 used? The grounds for changing the 3779 rules has been described as “wobbly” but how is that accusation made if we cannot put our fingers on the reasons for the 3779 rules in the first place?

> I am not sure why you are bringing up systems which provide no security in discussing the design of a secure system.  As an example of what to avoid?

Again, I was following your lead by addressing the example you gave.

> I do not follow the parallel at all.

If you are looking for a system that follows the address allocation hierarchy, reverse DNS is one such system. However, I get the feeling you and I are talking past each other. If that was not the characteristic you were describing or I have done a poor job explaining my point, please let me know.

-andy

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 8 Aug 2014 18:17:39 -0400

> I’m fine with not characterizing motives and historical context. Just following your lead. :)

I did not mention motives, I mentioned motivations, as in the requirements that drove the design.

I did not suggest 3779 was adopted because it existed but because it had the desirable features.

So you may think you are following my lead, but I think you are not on the same path I'm on.

> CMS is used in many deployed systems. As has been asked but has been left unanswered, in what other deployed systems is 3779 used? The grounds for changing the 3779 rules has been described as “wob…

I think I answered that. The RPKI was designed for the prefix allocation system. In the prefix allocation system, one can allocate only from the allocation one holds.  3779 also was designed to follow the prefix allocation system and its rules enforce that allocation behavior.  It provided the features a certification of the prefix allocation system needed, so it was adopted.

I suppose we could have invented an entirely new crypto based system, but the prefix allocation system's behavior would have been part of what we built anyway. 3779 did not invent the encompassing rules, those rules are derived from the behavior of the existing system.

> Again, I was following your lead by addressing the example you gave.

I was talking about IRR/RPSL systems that follow the authorization model.  You pointed out examples of those that do not.  That's not following my lead.

I was attempting to point out that the only other existing system with an authorization model also follows the same encompassing rule.  Again, the encompassing rule is derived from the behavior of the prefix allocation system.

> If you are looking for a system that follows the address allocation hierarchy, reverse DNS is one such system. However, I get the feeling you and I are talking past each other. If that was not the…

The parallel to DNS delegation that is bad would be one RPKI certificate that is bad.

The parallel to "all delegations of the network holder" would be "all RPKI certificates of a resource holder".

So the parallel is: if a particular RPKI certificate is bad, the system does not consider all RPKI certificates of the resource holder to be bad.  True.

So I don't follow why you think this parallel is better.  But I'm not sure that it helps the discussion to explore it.  If you think it would, maybe we better take it off list?

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Aug 2014 10:55:56 +0900

> well suited to #2 has not been discussed here in depth.

i think you are a bit confused here.

what geoff proposed changes nothing about 1 and 2.  it's about how one
validates the correctness of the external data, irrespective of how it
is used.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Aug 2014 11:42:23 +0900

> Well ok. Where else are the 3779 rules used?

the validation for 3779 is essentially the same as for X.509, a rigid
hierarchy.  some do not like different aspects of that rigidity, i am
among them, but for different aspects than this one.

> I’m not seeing the relevance of this history lesson to the question
> that was asked. How does this relate to the technical reasons of why
> we are using 3779 rules?

because they are working.  you are proposing a change to a deployed
rfc.  what is the motivation for the change?  be technically explicit.

the point of the history lesson of the rirs blocking the definition and
documentation of transfer is that it seems to be the only serious reason
for the change those very same rirs are proposing.  so, if you want your
proposal to change rfced running code to be taken seriously, you had
best document it technically, not just throw perjoratives and hyperbole.

once again, i was the first (non author) to advocate the wg working on
this, and did put up one very subtle possible motivation.  unlike the
rir mafia, i am not threatening to hold my breath until i am blue if it
gets consensus (or not); my youngest grandchild has grown past that
phase.  i just want clear and well-understood technical reasons for a
change to deployed running documented code that seems to be working.

> Imitation is the sincerest form of flattery. I’m now thinking about

not likely.  the last time i was beardless jack kennedy was president.
i do not change running beard without a sound technical reason.  otoh,
if you can document how i can transfer to a 27 year old body, we would
likely have a deal.

randy

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 11 Aug 2014 08:10:29 -0300

Hi,

> experience with PKIs.  they are deployed and working today.

Where? Can you provide examples? I seem to be having a really hard time
finding real, widespread world uses of RFC 3779, outside RPKI that is.

As a another data point, most people attending LACNIC conferences had
never heard of RFC 3779 validation before Arturo and myself brought RPKI
into their radars. And among those you can count engineering depts of
ISPs counting their user base in tens of millions.

regards

-Carlos

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 11 Aug 2014 08:13:41 -0300

I'm not defending the draft per se here. Maybe I should start a new thread.

I think we, as SIDR, need to revisit some basics and some 'axioms' that
have been taken for granted, in particular, why are we using RFC 3779
rules here.

So far we got:

1- because they were used in s-BGP
2- because they ware already there
3- because we understand them

So far, this looks quite 'wobbly' too.

This actually doesn't mean that the proposal of the draft is the 'right'
one, but I think we need to re-discuss this before the RPKI gets more
traction and people get burn scars.

Wes's email is pretty clear, risk vs reward.

cheers!

-Carlos

---

From: "George, Wes" <[email-masked]>
Date: Mon, 11 Aug 2014 08:58:24 -0400

>3- because we understand them

For small values of "we" and "understand"

;-)

Wes

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 11 Aug 2014 13:01:55 +0000

Hi Wes,

Thanks for your message, I think it is always great to have a fresh view when we are looking at new problems.

I have some comments inline.

Cheers!
Roque

On Aug 5, 2014, at 5:51 PM, "George, Wes" <[email-masked]<mailto:[email-masked]>> wrote:

On 8/4/14, 5:47 PM, "Sandra Murphy" <[email-masked]<mailto:[email-masked]>> wrote:

If there is no other covering ROA, then a BGP route for that prefix
becomes unknown, as Terry pointed out.

(Roque)
The answer resides in the definitions of VRPs-Validated ROA payloads which is the information received by the BGP speakers. As its name states, the validator server only sends VRPs that correspond to valid ROAs. So, you are right that in the transition from ROAs to VRPs, the router has not knowledge that there were some signed objects (not just ROAs) that failed the validation process. This behaviour is document on RFC 6811:

"The BGP speaker loads validated objects from the cache into local

   storage.  The objects loaded have the content (IP address, prefix
   length, maximum length, origin AS number).  We refer to such a
   locally stored object as a "Validated ROA Payload" or "VRP"."

Terry's point is that as VRPs always correspond to valid ROAs, the problem under discussion will, in the worse case, take you to a "not-found" state.

I think that begs some further questions: Is there ever a case where we
*want* an invalid ROA to translate to an invalid route, or do we *always*
want to simply punt those from the system so that the routes they would
have covered are tested only against any remaining valid ROAs?

(Roque) There is the case of AS 0 (section 7.1.6<http://tools.ietf.org/html/rfc6907#section-7.1.6> in RFC6907 and also in RFC 6483 BUT  both Informational documents).

AS0 was thought as a solution to bogon prefixes or networks that are not meant to be public (military, banks, etc.)

Do we ever
see a need to treat an invalid ROA as a revoke?

(Roque) I believe the current process of allowing to take the union of valid ROAs for a given prefix is the right strategy. It is consistent with the "make before break" principle.
Some examples are:
- changing network ASes
- networks with multiple origin ASes
- ROA's EE certification roll-overs

Is the behavior any
shows up is invalid?

(Roque) You only send VRPs to the routers, which correspond to valid ROAs. You notify the router of changes, including removals

I'm quite sure that diving into this will also

(Roque) VRPs are always referring to valid ROAs. There is not "matching" with invalid ROAs. The problem under discussion, IMO, is that in some specific "corner cases" where ROAs may be invalidated due to some issues up in the allocation hierarchy.

I think that there are probably still cases during a transfer where if you
get the order of operations wrong, in addition to the invalid ROA, you
will have a second valid covering ROA that might not match what's being
announced and thus a potentially invalid route.
That's probably what needs
to be enumerated in the validation-reconsidered draft as the problem with
the biggest potential impact, even if it's secondary to the main failure
mode where a bunch of routes just go to unknown status and temporarily
lose the protection that origin validation is supposed to provide.

(Roque) Agree to add to the document a "before" and "after" process for transfer as example.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 11 Aug 2014 17:58:57 +0200

On 09 Aug 2014, at 04:42, Randy Bush <[email-masked]> wrote:

> hierarchy.  

Personally I am not challenging this general approach.

The *one* thing I (and I believe we..) challenge is whether the an overclaimed resource should invalidate a complete certificate, instead of invalidating just the resources at hand, but allowing the remainder.

> rfc.  what is the motivation for the change?  be technically explicit.

Resource certificates are always evaluated in context. Under RFC3779 we accept the resources listed for the trust anchor as-is, but for everything down the chain we insist that *everything* is also held by the parent. I.e. we know exactly which resources we are willing to accept. So we do not believe the listed resources at face value.

I understand that conceptually this is an attractive simple model. However I believe that are reasons why certificates can end up overclaiming, and *importantly* this is not always something that a CA has full control over.

Essentially I see two causes, that can be caused by various reasons:
1 = the parent certificate is shrunk and published before the, now overclaiming, certificate is shrunk and re-published
2 = the certificate is grown and republished, before the grown parent certificate is republished, so it looks overclaiming

Some possible causes, there may be more:

The following two we may be able to mitigate technically, because we are dealing with co-operating parties:
  @1 There is a mis-timing in certificate shrinking in a transfer between co-operating parties.
  @2 There is a mis-timing in the parent publishing a cert with extended resource, and issuing it to the child, and the child using those resources in turn.

But this is the one that has me scared. It is not the issuing CA being sloppy, it’s a problem between them and *their* parent:
@1 The *grand*-parent shrinks the *parent* certificate without the parent knowing about this, and some of these resources appear on the, now overclaiming, child certificate. The grand-parent and parent are not involved in an active transfer process. They may not agree that the resource in question should be removed, or the grand-parent may have shrunk these resources in error.

By rejecting the overclaiming child certificate completely I think we are being too harsh, or pedantic even. We know better, so we are just not going to trust this one. But.. there is a very real possibility that we actually *do* know better than the issuing CA at this point. So, what exactly is the problem with accepting the remaining resources? i.e. the intersection between the parent certificate’s resources and this certificate. We know the context, this evaluation is very easy and well-defined. If the CA really intended that the remaining resources should not be tied to the certificate, they would have revoked. If the grand-parent really intended that those resources should not be certified anymore, they would have removed them as well.

> best document it technically, not just throw perjoratives and hyperbole.

I think a formal specification for transfers can mitigate the problem of transfers between co-operative CAs, but this can not mitigate errors.

But, more importantly our transfer policies are set in the address policy working group, and our implementation is based on the directives that we get from our community there. Other RIRs have similar, but slightly different policies. The ‘rules’ regarding these transfers can be changed at any time. As an RIR employee I feel a lot of reluctance against engaging in a technical definition of a transfer, as it can be perceived to compete with our community process. 

> i just want clear and well-understood technical reasons for a

I hope that the third case above (CA unaware that its own certificate has shrunk) made my motivations more clear.

I understand that changing running code is a pain, but I don’t think it’s impossible. We have running code that warns about overclaiming, but accepts remaining.

Tim

---

From: Andy Newton <[email-masked]>
Date: Mon, 11 Aug 2014 17:41:39 +0000

> among them, but for different aspects than this one.

Ah. I think I see the disconnect. The validity of a certificate with 3779 extensions is covered by section 2.3 and 3.3 of 3779. Those are the rules for answering “Is this certificate valid?” However, what use is that question by itself? Isn’t a better question, “Can this IP address be validated with this certificate?” It is a matter of context, and the current validation rules lack context.

If a certificate covers 192.0.2.0/24 and 198.51.100.0/24 yet its parent only covers 192.0.2.0/24, that certificate is invalid even though 192.0.2.0/24 has a path of validity. Why? In the context of “Is 192.0.2.0/24 valid with this certificate?”, why can’t we say yes?

> if you can document how i can transfer to a 27 year old body, we would

Can we compromise with a zombie-JFK?

-andy

---

From: Andy Newton <[email-masked]>
Date: Mon, 11 Aug 2014 18:02:29 +0000

> I did not mention motives, I mentioned motivations, as in the requirements that drove the design.

That sounds like splitting hairs.

> I think I answered that. The RPKI was designed for the prefix allocation system. In the prefix allocation system, one can allocate only from the allocation one holds.  3779 also was designed to fol…

Except 3779 goes further, in that if a certificate ever claims more than what has been allocated then NONE of its allocations are valid.

> I was attempting to point out that the only other existing system with an authorization model also follows the same encompassing rule.  Again, the encompassing rule is derived from the behavior of…

Which seems to be an answer far afield from “where else is 3779 used?”

-andy

---

From: Byron Ellacott <[email-masked]>
Date: Thu, 14 Aug 2014 14:11:40 +0000

Randy,

> best document it technically, not just throw perjoratives and hyperbole.

Transfer for APNIC is defined and documented:

    http://www.apnic.net/policy/transfer-policy

… which you are no doubt familiar with, having contributed actively to its development.  The point is resource transfer is documented as a number registry policy process, not as a technical process.  Of course, the RPKI very conveniently requires that CA certification actions follow registry actions, so when one uses an RIR's policy for transfer to enact a transfer, certificates are updated without any extra technical process needed.

The RPKI, as Sandy has indirectly suggested, is a view of the resource allocation hierarchy.  Defining technical processes for changing the contents of the RPKI does not make sense, as the RPKI does not change, the resource allocation hierarchy does.

If 'make before break' semantics are important when a certificate is revoked and reissued following a registry action, the WG could certainly produce something there - perhaps 4.5.9 of the CPS draft is a possible place to do this?  As a bonus, addressing the consequences of "partial revocation" (RFC6484 4.9.1 requires revoke+reissue to remove some INRs from a certificate, which is a hack around the all-or-nothing nature of 3779 validation) also deals with returns, exchanges, and plain old human or software error.

Assuming, of course, that transient certificate errors are a problem that we should avoid :-)

-- 
bje, speaking as an individual