Re: [sidr] BGPSEC Threat Model ID

[Stephen Kent <[e-mail]>]

At 3:27 PM -0400 11/1/11, Danny McPherson wrote:
>  > Route leaks represent a violation of an ISPs local policy, i.e., the ISP
>>  is propagating routes that it, locally, did not intend to propagate.
>
>Perhaps the network operator DID fully intend to propagate ("leak") those
>routes in order to hijack and MITM traffic?  Any multi-homed customer can
>launch such an attack today of this sort, and as a matter of fact, it
>happens all the time, for benign or malicious purposes.
>
>To say that this is not a "semantics violation" and therefore in scope
>does not mitigate the risk.  How that risk can be considered as a
>"Residual Risk" in a "Threat Model for BGP Path Security" document totally
>escapes me?

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.

>
>>  BGPSEC (or any analogous technology) can provide protection for BGP
>>  relative to two constraints:
>>	- the semantics of BGP have to align with the protection
>>	- the underlying PKI has to align with the protection
>>
>>  Thus, for example, other attributes carried by BGP and for which the
>>  resource allocation system has no reference, cannot be protected.
>>  Similarly, route leaks, because they are a violation of a local policy,
>>  which is not expressed in BGP Update messages, cannot be addressed.
>
>But they are certainly still risks, whether the proposals at
>hand can mitigate them or not is orthogonal.

The threat model is based on using the RPKI as the starting point.
I will add text that clearly articulates that.

>And even policy
>expressed in IRRs and via RPSL can result in controls that can
>be put in place to mitigate various aspects of those risk.

yes, one can use RPSL to express more info, but these are just 
assertions by the
maintainers of RPSL objects. 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.

>   I
>don't understand how we can ignore this as an objective here,
>and we certainly cannot discard it so casually as a trivial
>residual threat.  If some non-obvious or undisclosed roadmap
>exists to solve this piece then I'm truly anxious to see it -
>else it would seem to me secure IRRs bootstrapped by resource
>certification data and perhaps even deployed to routers via some
>rpki-rtr-esque protocol would provide a lot better protection
>with a lot less overhead.

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.

>  >>"False Origination" should probably be "network operator", not
>  >>ISP, in particular given the subsequent definition of ISP.
>>
>>  please explain.
>
>You use ISP in this draft as if they're the only ones who
>may be multi-homed or trigger leaks or other functions, "network
>operator" is much more broadly applicable and well beyond "ISP"
>in the traditional sense.

OK; I have changed all instances of ISP to network operator.

>  >>---
>>>The definition of "Route" seems to be missing the full set of
>>>path attributes associated with the NLRI, it currently only
>>>focuses on the AS_PATH attribute, and even omits the ORIGIN
>>>code of the path.
>>
>>  I think the definition does not omit the origin AS, but I will
>>  clarify the text.
>
>I'm not talking about Origin AS, I'm talking about "ORIGIN Type
>Code" Path Attribute (i.e., i, e, or ?).

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.

>  > Our context assumes use of the RPKI, and the RPKI attests to only
>>  prefix and ASN holdings of entities, hence the focus on these
>>  attributes. For example, MPLS attributes are not supported in the
>>  RPKI, so they are out of scope here.
>
>I think the "Threat Model" document should give consideration
>to Path Attributes beyond just AS_PATH, particularly because most
>are used in path selection.  If we think we don't need to protect
>these because they are not in RPKI, then we should consider what
>that means rather than assume RPKI contains the information for
>all that we need to protect.

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.

>  > The definition I used here has been widely used for many years
>>  in contexts where folks understand the importance of
>>  distinguishing among attacks,  adversaries, and motivations.
>>  Unlike the RPKI focus on config errors, BGPSEC focuses on attacks.
>>  As noted in above, route leaks are out of scope, because they
>  > do not represent violations of BGP semantics, as expressed
>>  externally.
>
>If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a
>transit customer of both, and then decides (or is compromised
>and used to decide) that he wants to hijack traffic from ISP_1
>towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2
>Prefix_P to ISP_1 through Enterprise_E's local interconnect,
>and "policy" makes it a more preferred path, how is this not
>an attack?

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.

>And it's most certainly a threat and one that some consider
>out of scope at that?

I presume that you mean in scope, right?

>...
>  >
>>  I said "cannot" here because of the modifier "externally." To external
>>  observers, such behavior by an ISP may be viewed as odd behavior, but
>>  enough ISPs behave oddly enough to make this indistinguishable from
>>  an attack.
>
>But it "may" be externally detectable, which was my point that
>you've reinforced :-)

"May" is not a suitable basis for a secruity protocol :-).

>  >>Such guidance and implementation may be precisely what an attacker
>>>was hoping to instigate, no?  Further:
>>
>>  The RPKI and BGPSEC designs place a high priority on maintaining
>>  the ability of ISPs to continue routing in the face of outages. Using
>>  cached, previously validated RPKI data is a good way to support this
>>  goal, in the face of outages, benign or malicious. So, I think we are
>>  making an appropriate decision here. An attacker can always try to
>>  effect DoS on targeted RPs, and has has fewer attack options when RPs
>>  can revert to cached data.
>
>While I agree, this can enable downgrade or other attacks, no?
>Just like clicking on that self-signed or expired intermediate
>CA certificate warning in a web browser, right?  If so, the threat
>model should indicate as such.

I can add text to note that use of cached data enables some types of 
attacks resulting from use of stale data.


>  >>---
>>>I'm surprised I don't see anything here about timing dependencies
>>>between RPKI and BGPSEC routers, and variances across a BGPSEC system
>>>having considerable potential impacts.  I think some discussion of
>>>this is in order in a threats draft.
>>
>>  There is no requirement that a BGPSEC router interact directly with
>>  the RPKI repository system. However, your question is still relevant
>>  if we substitute
>>  "local RPKI server" for "BGPSEC router." S 4.4 already deals with
>>  attacks against publication points, many of which are relevant to the
>>  timing concerns you cite above. The RPKI, is a distributed repository
>>  system with many maintainers. RPs ought not assume that they always
>>  have the very latest data from the system, and maintainers ought not
>>  assume that all RPs have the latest data.  This issue is addressed in
>  > detail in the RPKI key rollover doc.
>
>But it's a threat and this is the threat document, right?  If
>we're not going to include it here we should at least reference
>those sections.

I can add text that notes the implications for RPs of using any distributed
repository system with data supplied by object owners.

>  > Section 5 already addresses this, at a high level, see bold text:
>  >
>>	- the RPKI repository system may be attacked in ways that make
>>           its contents unavailable, or not current. It is anticipated that
>>           RPs will cope with this vulnerability through local caching of
>>           repository data, and through local settings that tolerate
>>           expired or stale repository data.
>>
>>  I have changed this to say
>>
>>	contents unavailable, not current current, or inconsistent.
>
>Not current == expired.  I'll defer to crypto types here, but as
>a first order function, I would like to see explicit text and reach
>agreement that expired data should be used in the absence of current
>data, and what the attack surface implications of using expired data
>are.

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.

Steve