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_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
