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", 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'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.
More comments below....
---
s/to determine of/to determine if/
---
In terminology section include "(AS)" after "Authonomous System"
per subsequent use of acronym.
---
s/AS Number (ANS)/AS Number (ASN)/
---
"False Origination" should probably be "network operator", not
ISP, in particular given the subsequent definition of ISP.
---
s/Local Internet registries/Local Internet Registries/
---
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.
---
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".
---
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?
---
"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"?
---
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?
---
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.
---
s/act as a rogue capacity/act in a rogue capacity/ ?
---
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"
---
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?
---
This discusses TCP-AO or IPSec, whereas the rquirements draft avoids
TCP-AO and talks about TLS?
---
S 4.3:
"This type of behavior cannot be externally detected as an attack."
/cannot/may not/
---
"PA allocation" - Define PA here.
---
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.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:
"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."
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?
---
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?
---
S 5.
s/were been discussed in the/were discussed in the/
---
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.
---
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?
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
