Re: [sidr] BGPSEC Threat Model ID

[Stephen Kent <[e-mail]>]

At 10:29 PM -0400 11/2/11, Danny McPherson wrote:
>On Nov 2, 2011, at 10:52 AM, Stephen Kent wrote:
>
>>I interpret the task at hand as trying to secure BGP, not a new 
>>EGP. Since BGP semantics (and syntax) do not provide a basis for 
>>deciding when an advertisement constitutes a route leak, I think it 
>>reasonable that the BGPSEC threat model view this as out of scope. 
>>If BGP were modified to express semantics we're discussing, then it 
>>would be in scope, and I would expect BGPSEC to address it.
>>
>
>Duly noted, and my disagreement stands:
>
>To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or
>benign, that is not an authorized transit for a given prefix is out of scope
>because it is not a "semantics violation" does not mitigate what I perceive
>as  a very significant risk to my operations.
>
>Absent a companion set of mechanisms and controls under cover of "BGPSEC"
>to mitigate that risk, I'm opposed to the publication of this 
>document under the
>auspices  of  "Threat Model for BGP Path Security".  I.e., it is not 
>an acceptable
>residual risk.

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.

>>yes, one can use RPSL to express more info, but these are just assertions
>>
>>by the maintainers of RPSL objects.
>>
>
>But if these maintainers are the resource holders that are authorized via the
>RPKI, then they are no more assertions than an RIR's RPKI testimony about
>their resource holdings is an assertion.

I'm not sure I understand the sentence above.  RPKI CAs issue certs 
based on authoritative databases about Internet resources.  The 
authorized holder of a resource can make lots of assertions, and the 
RPKI allows us to attribute these assertions to that entity. RPSL 
allows lots of assertions to be made, and many of them cannot be 
validated relative to the RPKI. Relying on such assertions, just 
because their sigs can be validated under the RPKI is a new sort of 
vulnerability that we ought not enable.

>>  For some of this data, there is no basis for validating it via 
>>external, authoritative
>>
>>sources. That makes such data a poor basis for security controls.
>>
>
>Ahh, and the crux - then perhaps this needs to be corrected, rather than
>accepting this residual risk?

see comment above. 

>
>>We disagree about the advisability of relying on some types of IRR 
>>data, e.g., an assertion that AS X will advertise (not originate) 
>>routes for prefix Z.
>>
>
>"Some types" is relative, and I understand and agree with that.  Tell me
>how to get there?

Get where?

>
>>Sorry, I misunderstood your question. Now I know the data item to 
>>which you were referring. I checked with a network operator here at 
>>the RIPE meetings, to understand how/why it is used.  I now believe 
>>that the ORIGIN attribute is a poster boy for an attribute that 
>>is unsuitable for inter-AS protection. This attribute can be set to 
>>one of 3 values by an AS sending an Update. (One of these values 
>>cites EGP as the source of the data, so unless the Update has been 
>>terribly delayed, this is not a credible value :-).)  The other two 
>>values are IGP and INCOMPLETE (i.e., mystery). How would an AS that 
>>sees this value externally verify that the value is accurate? I am 
>>unable to imagine how this would work.
>>
>
>If it were cryptographically protected by the origin AS then it couldn't be
>manipulated by intermediate ASes for the purpose of traffic attraction
>attacks - as it commonly is today.  As discussed above, ORIGIN code was
>simply an example of why the laser focus only on the AS_PATH Path
>Attributes may be problematic in practice.

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.

>>Let me try again. If we can't identify a suitable, authoritative 
>>source of data that could be used to verify an assertion about an 
>>attribute in an Update, that attribute is not a candidate for 
>>inter-AS security mechanisms.
>>
>
>If an origin AS for which a ROA is associated in the current system signs
>those transitive attributes then what more do you need?

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.

>>  How does BGP indicate (i.e., where are the bits that say) that the 
>>Update sent to E is not to be propagated to another ISP?  I've been 
>>told that the NO_EXPORT community does not have the right 
>>semantics, and that network operators do not pay attention to this 
>>anyway.
>>
>
>I agree NO_EXPORT is not the right answer, I never even considered it.
>
>I'm saying policy is a big part of the problem, at least as considerable as
>"integrity" of the AS_PATH, IMO, and if we don't take a systemic approach
>and consider the gaps that exist, then it's hard for me to justify the
>investment.

I'm not sure what you're trying to say about policy here. Can you elaborate.

>
>>>But it "may" be externally detectable, which was my point that
>>>
>>>you've reinforced :-)
>>>
>>
>>"May" is not a suitable basis for a secruity protocol :-).
>>
>
>The possibly exists that it many cases it can be detected, therefore, "cannot"
>is false.

OK, "cannot" was too strong. But, I still feel that "may" is a bad 
basis for a security protocol.

>>I can add text to note that use of cached data enables some types 
>>of attacks resulting from use of stale data.
>>
>
>I think the text we need here, if you truly believe this is the right course,
>is to clearly state that expired digital certificate data is acceptable.  As a
>basis for a security architecture, this assumption seems a residual risk I
>would prefer to mitigate.

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.

>For example, do you consider it acceptable to use expired certs when
>you connect to a web site via SSL or VPN to some remote location?  I
>don't.

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.

>Furthermore, besides the obvious attacks you're accepting by recommending
>use of expired certificates, aren't revoked certificates 
>only supposed to remain
>in the CRL until their validity period has expired?  How in the 
>heck can we justify
>use of expired certificates in the absence of current data, when some of those
>expired certificates may have even been revoked?

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.

>>In PKIs it is always the case that, in the absence of the current 
>>CRL, use the old one. This is because, with one ugly exception, 
>>once you are revoked, you are revoked, you stay revoked. So, 
>>expired and stale are meaningful differences to us PKI experts. 
>>But, I agree that more text can be added to note the 
>>vulnerabilities associated with using stale or expired PKI data.
>>
>
>And that is exactly my point, I don't know the difference between them
>and therefore using them opens me up to attack and undermines the entire
>system.

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

>Also, if RPKI weren't so distributed, or if we could develop a 
>model, perhaps some
>OSCP-esque near realtime function would be of benefit here, in the 
>general case,
>and perhaps even some notify function from publication points/CAs 
>for RPs to identify
>revoked certificates, such that a RP, or even BGPSEC speakers, could 
>be notified of
>an incident with a particular resource, rather than periodically 
>telling everyone
>everything via a periodic update/refresh mechanism?
>
>What are your thoughts on this?

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

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 every cert, 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.

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.

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.

The GB record is likely to be very stable, as it provides contact 
info for the pub point maintainer. I don't see freshness attacks on 
these records as a big deal.

A ROA expresses a binding between a prefix and an ASN. I would expect 
most of these to be fairly stable, and that operators would follow a 
make-before-break policy. That suggests that ROA cert revocation will 
be relatively infrequent, and will not require immediate 
dissemination.

So, I am not convinced that there is a need for a different approach 
to disseminating revocation status.

Steve