Re: [sidr] BGPSEC Threat Model ID

[Danny McPherson <[e-mail]>]

On Nov 3, 2011, at 7:09 AM, Stephen Kent wrote:

> Having been motived to reread the SIDR charter by Brian's message, there is a simple answer to the in/out of scope question, but it's one you will not like :-). The charter for SIDR states that the secruity goals for the WG are to address two vulnerabilities: authorization for prefix origination and path validation.  Relative to the charter, route leaks are out of scope.  I will add text to the intro for the threat model to state that the scope of the model is defined by the charter, and include the relevant charter text. I hope you'll forgive me for taking the easy path here.

I do not...

The charter is temporal and the product of the WG in the form of RFCs 
will be much more persistent, I'm concerned by a line of reasoning that 
says "Let's ignore and not even enumerate or concern ourselves with 
these obvious threats because the current charter [deliberately] says 
all we have to do is provide semantic validation of the AS_PATH" [and 
doing anything more would quite possibly NOT be conducive to 
expedited publication of BGPSEC].  

> I agree that the integrity that would result from including this attribute under the sig applied by the first AS would provide the secruity you cited. That may make it worthwhile to protect via the sig. However, the accuracy of the assertion being made by this attribute is unverifiable by any of the ASes along the path, and that was what worried me.  But, again, the charter makes this out of scope, i.e., it is not relevant to the origin authorization or path accuracy vulnerabilities cited there.

NIce, another threat that shouldn't be listed because it's not in the charter 
as written or addressed via BGPSEC as is.  If that's the case, then all the 
drafts should include the current revision of the charter and explicit text about 
ignoring all other threats under these auspices.

> That sig provides integrity, which is valuable, but it does not provide a way to verify the accuracy of the assertion by the origin AS. Your concern is that an AS along the route can change the value of the attribute. One might also be concerned that the origin set the value incorrectly. Ultimately, I think this is a bad example for us to argue about, as it is a vestigial part of BGP, from EGP days, that is the penultimate basis for route decisions.

No, it is used today and opens up traffic attraction attacks, please don't 
brush it aside because it's 'penultimate' in the decision process - it is 
there and it impacts traffic today.

> It is up to each RP to decide whether to rely on assertions made by an expired cert, or to act as though the cert does not exist. In the routing context, there appears to be some agreement that relying on expired certs is more desirable
> than treating the resources as not certified. But, this is a per-RP decision.

There is only room for two states, right?  Valid and not valid.  Stale == not valid.

> Many folks do. This is probably because an expired cert often indicates that
> the cert holder was sloppy, and failed to renew the cert, i.e., pay the CA. Expiration is not as negative an indication as revocation.

Or because a CA was compromised - we've seen this in the real world with
increased frequency, as you well know.

> There is a subtly here, and thanks for pointing it out. The idea is that if an RP has a cert, and it was not revoked, then the RP can continue to rely on it, after the cert expires, if the RP is unable to acquire fresh data from the pub point for that cert. If the cert had been revoked, it should not be un-revoked because it expired.

And therefore we MUST NOT rely on expired certificates, period.

> I think the phrase "undermines the entire system" is melodramatic. How about "you actual assurance may vary?" :-)

"house of cards", "village of cards"...

> I would prefer more centralization of RPKI data. My original model called for each RIR to aggregate the data for every member, and act as a mirror for the data for every other RIR. But other folks wanted greater distribution. One can argue that wider distribution may offer potentially greater resilience, so ...

Yeah, I get it -- until you get to the point where you have to use expired 
certificates in a PKI and they may have been revoked or may no longer 
be valid or intended for use but because you can't pick certificates up 
from some remote portion of the Internet then you relay on stale (i.e., 
NOT valid) data.  Even if "more distributed", I'm not sure that's added 
resilience, particularly when PKI is employed.

> OCSP is an optimization of the CRL mechanism, designed to efficiently answer a revocation status query for a single cert. Since every RP needs to know the revocation  status of everycert, OCSP (or an analogous mechanism) does not seem to be a good match.  For many years folks have thought that very fast dissemination of revocation status data was important for PKIs.  In reality, revocation is an administrative procedure for which the major delays will be
> created by people deciding whether to revoke a cert, vs. the time it takes to disseminate the CRL.

And I'm saying that if we're going to employ a PKI solution on a distributed 
loosely coherent resource certification infrastructure that's going to be employed 
by RPs in a non-determinsitc manner and result in "periodic updates" in the 
routing system in order to minimize exposure windows, then we ought to look 
at what architectural approaches can be considered or what new elements 
invented to minimize unneeded state and churn in the network and maximize 
resiliency without introducing the possibly for any array of new attacks.

We've already seen issues where such an approach has been problematic with 
DNSSEC in the wake of portions of the Internet being fragmented and causing 
issues and inability to update certificates in the system at root, TLD and SLD 
levels, and what you're proposing here is far far more troubling.

> There are two types of certs: CA certs and EE certs.
> 
> Because revoking a CA cert has major implications, so such a decision will not be taken lightly. Thus I expect relatively few revocations of CA certs and the principle delay will be procedural.

Yes, just as with SSL certificates today - but when they do happen, the more
quickly you can become aware of that revocation the better off you;re going to 
be -- and it's all still inherently reactive from a controls perspective.

> All of the EE certs defined so far (not counting router certs for BGPSEC, which have yet to be agreed upon) are embedded in RPKI objects: manifests, ROAs, and GB records.
> 
> A new manifest MUST be published whenever any file at a pub point changes. The CPS template recommends daily CRL issuance, and that seems to be what the RIRs are doing for the pub points that they maintain . Thus it is likely that a new manifest will be issued every day. So, I doubt that many manifest cert will be revoked.

But when they are, you better get'm fast...

If you're intended to play the "charter says .." card then we're wasting our time.
At least I've got my concerns on record for broader reference..  This is unfortunate.

-danny