Re: [sidr] BGPSEC Threat Model ID

[Stephen Kent <[e-mail]>]

At 4:20 PM -0400 10/29/11, Danny McPherson wrote:
>Some comments on sidr-bgpsec-threats-00 below..
>
>Most substantial of my concerns is Section 5's "Residual
>Vulnerabilities", specifically:
>
>  "BGPSEC has a separate set of residual vulnerabilities:
>
>   - BGPSEC is not able to prevent what is usually referred to as
>     route leaks, because BGP itself does not distinguish between
>     transit and non-transit ASes- BGPSEC signatures do not protect
>     all attributes associated with an AS_path. Some of these
>     attributes are employed as inputs to routing decisions. Thus
>     attacks that modify (or strip) these other attributes are not
>     detected by BGPSEC."
>
>Do we really consider it acceptable that the solution and machinery
>we're recommending will NOT prevent "route leaks",

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. 
There is no semantic in BGP that captures this aspect of local 
policy. (The "NO EXPORT" community is not relevant here. An upstream 
or peer ISP may not know that the "leaking" ISP does not intend to 
export the routes in question. Also, the "leaking" ISP may 
legitimately plan to announce these routes to downstream ISPs.) So, 
since a route leak is an error only relative to the policy of the
offending ISP  BGPSEC cannot be expected to detect and reject this behavior.


>and also does
>NOT protect the integrity of the very path attributes that are used
>to apply preferences (i.e., policy derived from business logic that
>dictates most routing decisions on the Internet today)?

I don't understand the text immediately above. Can you rephrase?

>I'm having a really hard time subscribing to this as being an
>acceptable residual threat after we reach full deployment,
>particularly without a clear path outlining the development of
>controls that mitigate that risk.

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.

>
>More comments below....
>
>---
>s/to determine of/to determine if/

fixed

>---
>In terminology section include "(AS)" after "Authonomous System"
>per subsequent use of acronym.

fixed

>---
>s/AS Number (ANS)/AS Number (ASN)/

fixed.

>---
>"False Origination" should probably be "network operator", not
>ISP, in particular given the subsequent definition of ISP.

please explain.

>---
>s/Local Internet registries/Local Internet Registries/

fixed.

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

>---
>Regarding your definition of "Threat":
>
>    Threat - A threat is a motivated, capable adversary. An adversary
>    that is not motivated to launch an attack is not a threat. An
>    adversary that is motivated but not capable of launching an attack
>    also is not a threat.
>
>With many "route leaks" and similar incidents, the network operator
>may not have been motivated to launch an attack, but the impact of a
>leak is the same and it is certainly still a "threat".

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.

>---
>In "Threat Characterization" it would seem that for simplicity we
>should refer to BGP speakers as "network operators", not just ISPs
>as the current text suggests, particuarly in the case where an
>attacker may well be a subscriber that intentionally interconnects
>between two ISPs (in order to exploit business logic and derived
>preferences), or leaks routes unintentionally as is commonly the
>case today?

I have made the suggested change.

>---
>"Hackers might be recruited, without their knowledge, by criminals
>or by nations, to act on their behalf." are you referring to social
>engineering or other attacks here that would be employed to gain
>access to a network operator's systems?  If so, that doesn't make
>the victim a "hacker"?

I am referring to the adversaries, not to types of attacks. The target
of a social engineering attack is not an adversary; he/she is an instrument
used by an adversary.

>---
>Wouldn't "attacker" be a better term here, "hacker" is fairly
>ambiguous.  Also, from a threat model perspective here I see little
>difference between "criminals" and "nations", can you explain the
>difference and why it's called out expressly anywhere beyond the
>discussion of jurisdictional issues dictating network operator or
>CA/INR functions?

I think the motivation and capabilities discussion justifies the 
distinctions between these classes of adversaries. The term 
"attacker" is generic and not
useful as an adversary characterization.

>---
>Regarding "Registries", an attack on a registry in this case (e.g.,
>social engineering) could have the same or broader impacts as an
>attack on an ISP (network operator), I think you capture this in
>later sections but this text does not adequately represents this.

I'll revisit this text.

>---
>s/act as a rogue capacity/act in a rogue capacity/ ?

fixed

>---
>The end of Section 3 seems to be incomplete, i.e.:
>
>"A manifest associated with a CA's repository publication point
>  contains a list of:
>
>4. Attacks"


yep. that was a whoops at my end. the manifest text should not have
appeared there.


>---
>Regarding Section 4.1, passive attacks, and "confidentiality" from
>MITM as a non-goal, shouldn't protections there be an objective in
>order to minimize the exposure of data that could lead to replay and
>other similar attacks -- in order to further minimize that exposure
>window we're trying to address with periodic updates?

The mechanisms used to protect against replay attacks assume a MITM and
knowledge of the plaintext. This is consistent with general IETF security
analyses.

>---
>This discusses TCP-AO or IPSec, whereas the rquirements draft avoids
>TCP-AO and talks about TLS?

I'm sure my text does not mention "IPSec" (vs. IPsec) :-). I will add
TLS to the list.


>---
>S 4.3:
>
>"This type of behavior cannot be externally detected as an attack."
>
>/cannot/may not/

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.

>---
>"PA allocation" - Define PA here.

I removed the "PA" qualifier.

>---
>My read of most of the attacks in S 4.3 is about DoS-esque functions,
>not certificate issuance that might be employed at a later time.
>Perhaps we should capture this more clearly in this section, as it's
>certainly one of the more obvious issues we're seeing with the CA
>sieve today...?

S 4.3 is titled "Attacks on ISP management computers (non-CA 
computers)" so CA-specific attacks do not belong in that section. S 
4.5 addresses attacks focused on CAs.

Not sure what you mean by "CA sieve."

>---
>S 4.4
>
>Regarding this text:
>
>   "An RP can continue to use the last valid instance of the
>    deleted object as a local policy option), thus minimizing
>    the impact of such an attack."
>
>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.


>   "An RP cannot know the content of the new certificates or ROAs
>    that are not present, but it can continue to use what it has
>    cached."

yes.

>and S 5's Residual Vulnerabilities:
>
>    - 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 think we should be clear that expired information should not be
>used?

I disagree. First, note that certs expire, but CRLs are defined as 
stale when the next issue date passes.  Manifests are defined as 
stale when the bundled EE cert is expired. Other signed objects that 
have bundled EE certs expire with their certs. In the absence of 
current, valid objects,

>---
>In the cases where notifying a CA of the error in order to remedy
>the problem is the recommended action, what threats arise if the
>CA cannot be reached or authenticated?  Should those be enumerated
>here?

I assume this comment refers to the discussion in S 4.5, right?  If 
the CA does not
take action to remedy the attack effects, then the situation is equivalent to
a CA as adversary (vs. attack victim). I will add a sentence to note this.

>---
>S 5.
>
>s/were been discussed in the/were discussed in the/

fixed.

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

>---
>Shouldn't there also be some discussion of coherency the RPKI
>repository system?  I.e., timing dependencies can result in some
>amount of considerable exposure if a manifest or CRL regarding a
>particular certificate have not been refreshed yet?


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.

Steve