Re: [sidr] BGPSEC Threat Model ID

[Danny McPherson <[e-mail]>]

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.

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

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

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

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

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

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

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

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.

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?

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

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?

-danny