Some comments on this document inline below..
I am surprised that external systems (e.g., NTP) are not mentioned at all in
this document?
Also, this document makes no distinction between eBGP and iBGP speakers, yet
there are certainly places where text and context would suggest it is certainly
necessary. Some hints of this below.
I believe this document needs a major overhaul before publication as a WG
document. More comments below..
-danny
=====
ABSTRACT
---
1) Regarding "Intended Status: Standards Track", I'd expect any standalone
Threat Model draft would be should be Informational.
---
2) " Enabling an AS to verify that the AS-PATH represented in a route matches
the path travelled by the NLRI for the route"
2.1): s/AS-PATH/AS_PATH/
2.2): I do not believe that even BGPSEC does this. Instead, in introduces a
new attribute which BGPSEC secures, and it forces no parity between the new
attribute and the old attribute. See 3) below, but absent some clarification
of this I am not comfortable with this text as written.
=====
INTRODUCTION
---
3) I'm not comfortable with the document as written, per it suggests that the
term "BGPSEC" == BGP Path Security, yet even the proposals received for BGPSEC
in the WG only introduce new attributes, they do not secure the BGP AS_PATH
attribute, nor do they force parity between the globally deployed BGP AS_PATH
attribute and the new attributes they propose.
---
4) "This model also takes into consideration classes of attacks that are
enabled by the use of BGPSEC (based on the current BGPSEC design.)" A stable
reference for "current BGPSEC design" is in order here.
---
5) "i.e., for the links that connect BGP routers." By "links" here I assume
you mean "transport connections"?
---
6) Can you explain what this means, I'm not sure how RPKI by itself provides
this: "secure route origination foundation offered by use of the RPKI." The
operative word "secure" appears to be used rather loosely there, particularly
when talking about BGP. Perhaps "route origin validation" and a reference to
RPKI-RTR would be more appropriate - i.e., if it's not effectuated in BGP
speaking routers through some mechanism it doesn't matter whether it's in the
RPKI or not. Conflating the two tends to cause confusion in the operations
community, methinks.
---
7) This text seems to muddy things, as it talks about the design of BGPSEC
rather than the Threat Model primitives which informed it's design:
" The security model adopted for BGPSEC does not assume an "oracle"
that can see all of the BGP inputs and outputs associated with every
AS or every BGP router. Instead, the model is based on a local
notion of what constitutes legitimate, authorized behavior by the BGP
routers associated with an AS. This is an AS-centric model of secure
operation, consistent with the AS-centric model that BGP employs for
routing. This model forms the basis for the discussion that follows."
=====
TERMINOLOGY
---
8) While I appreciate the attempt to restate and/or redefine these terms in
order to make this a standalone document, references to a large body of
previous IETF and SIDR WG documents (much of which at least one of the authors
is intimately familiar with :-) for these terms would seem to be far more
appropriate.
---
9) A reference to one of your previous (or new) citations may well be in order
here:
"False (Route) Origination - If a network operator originates a route
for a prefix that the network operator does not hold (and that it has
not been authorized to originate by the prefix holder, this is termed
false route origination."
Also, you're missing closing ")" there..
---
10) I'm not sure I agree with this definition, can you explain? E.g., given
that motivatiors are complex in a world of hacktivists and nation-state actors
alike, or pay-for-for financially motivated actors, this all seems a bit
fuzzing to me. By it's very definition above, if I've classified an entity as
malicious ("Adversary - An adversary is an entity (e.g., a person or an
organization) perceived as malicious, relative to the security policy of a
system. The decision to characterize an entity as an adversary is made by
those responsible for the security of a system. Often one describes classes of
adversaries with similar capabilities or motivations, rather than specific
individuals or organizations."). Furthermore, if I have an adversary that's
attempting to procure or develop capabilities to exploit a vulnerability for
which they do not have current capabilities, that would seem to render it a
threat to me - unless of course, I have complete visibility to their moti
vations and capabilities, which is highly improbable.
" 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."
=====
THREAT CHARACTERIZATION
---
11) Regarding this text, a reference to the BGPSEC document to which this This
Threat Model subscribes would seem to be appropriate:
" If it implements BGPSEC, it will have the ability to issue
certificates for its routers, and to sign updates in a fashion that
will be recognized by BGPSEC-enabled neighbors."
---
12) Also, the above seems to be implying that per router certificates would be
required here: "certificates for its routers", can you clarify the intent of
this text?
---
13) "sign updates" seems to be ambiguous, is your intention to suggest that
updates are signed, or that new BGP attributes would be introduced that would
be contained with existing BGP Update messaging that could be "recognized" by
BGPSEC-enabled neighbors?
---
14) Is the phrase "Hackers" even necessary here, or should you not employ
"Adversary" as defined in previous sections?
---
15) Regarding "It is assumed that hackers generally do not have the capability
to effect MITM attacks on most links between networks (links used to transmit
BGP and subscriber traffic)." given the preceding two sentences, they'd
certainly be able to, no?
---
16) Also, can you define what "subscriber" means in this context, it seems to
focus on a particularly type of connection but if I'm reading this correctly,
the threat is more ubiquitous.
---
17) Regarding "A hacker might be recruited, without his/her knowledge, by
criminals or by nations, to act on their behalf." This seems to describe a
victim or compromised system more than a "hacker", by nearly all conventional
definitions, no?
---
18) Regarding "Hackers may be motivated by a desire for "bragging rights" or
for profit." -- again, I think expanding adversary as appropriate, and leaving
it at that, might be the simplest solution here.
---
19) All of the above about "Hackers' applies to the "Criminals" section as
well. Again, refining adversaries terminology and applying would perhaps be in
order.
---
20) The "Network Operators" section might be more useful if it makes a
distinction between benign and malicious activity, although both represent
threats, the current text seems to imply malice in all cases -- when it may not
have been intentional at all.
---
21) The "adversary" comments about apply equally to "Nations" as well,
methinks, if these represent threats to users of the system.
=====
ATTACKS ON A BGP ROUTER
---
22) A stable reference for "route leaks" would be useful in the document, given
the recurring references :-)
---
23) Regarding: " Stale Path Announcement: An announcement may be propagated
with an
origination signature segment that has expired. This behavior
violates the BGPSEC spec and is considered a possible replay
attack." -- This and other references to "BGPSEC spec" need a stable
reference.
---
24) s/if such a time is mandates,/if such a time is mandated,/
---
25) Can you define "Immediate neighbor" here: "Thus only an immediate neighbor
of a route originator could be expected to detect this type of attack." Do
you mean EBGP neighbor? BGPSEC EBGP neighbor? Or... "
---
26) s/in injected/injected/
---
27) Regarding your definition of "Replay Attack", as written unless I'm
confused because BGP is stateful no new announcement is required at all (simply
suppress withdrawal, no need to re-announce - no?)?
=====
ATTACKS ON NETWORK OPERATOR MANAGEMENT COMPUTERS
---
28) define "RP Tools"
---
29) Here and in elsewhere first use of acronyms should be expanded (e.g., CRL,
etc.)
---
30) Section 4.3 and throughout the document seems to conflate RPKI use by
operators and BGPSEC-enabled routers, while an attempt (intro of S.4) was made
to define 3 classes of attacks that decouple these elements. Honoring these
three classes and cleanly delineating would make the document much clearer.
For example, this _could happen even if the local network were not
BGPSEC-enabled, no?:
"If the network operator is BGPSEC-enabled, and the adversary invoked
a tool used to request certificates, it could replace valid
certificates for routers with ones that might be rejected by BGPSEC-
enabled neighbors."
=====
ATTACKS ON A REPOSITORY PUBLICATION POINT
---
31) s/ inside or an external threat/ insider or an external threat/ ?
---
32) This seems to entirely gloss over the fact that the local systems and
remote systems will likely in practice handle expired data in very different
ways, and it seems to suggest that data should not be purged until replaced
(what if it's replaced with something compromised), and that that information
should ever be used anyway (using expired data can causes other systems to need
to purge it in BGPSEC, no?):
"If repository publication points are unavailable or the retrieved data is
corrupted, an RP can
revert to using the cached data This behavior helps insulate RPs from the
immediate effects of DoS attacks on publication points."
---
33) This seems like bad advice to me and should be removed: "Each RP will
decide, locally, whether to continue to make use of or ignore cached RPKI
objects that are stale or expired." We're suggesting we build and employ this
whole system and yet the threat model says we should use expired data in a PKI?
---
34) Regarding this text, what if there is no "older object", or if this is
precisely the behavior the adversary aimed to trigger:
"If an adversary deletes one or more CA certificates, ROAs or the CRL
for a publication point, the manifest for that publication point will
allow an RP to detect this attack. (The RP would be very unhappy if
there is no CRL for the CA instance anyway.) 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.
---
35) Regarding the above, what should an RP do when they detect such an attack?
---
36) Is this feedback loop a requirement of the system;
"Such behavior should result in the CA (or publication point maintainer) being
notified of the problem. An RP can continue to use the last valid instance of
the deleted "
---
37) How does this happen?:
" This alerts an RP that there may be a problem, and,
hopefully, the entity responsible for the publication point will be
asked to remedy the problem (e.g., republish the missing CA
certificates and/or ROAs).
---
38) Is this an actual recommendation you're making? This seems like a really
bad idea to me,
"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."
---
39) s/be un aware/be unaware/
---
40) This seems to contradict your previous recommendation where you suggest
that if stale or expired data exists that an RP should use it:
"INRs associated with these objects will be treated as unauthenticated."
---
41) Hope?
"Here too the hope is that the CA will be notified of the problem (by RPs) and
will remedy the error."
=====
ATTACKS ON AN RPKI CA
---
42) Section 2 only loosely defines "Adversary", unless I missed something it
doesn't define various types of adversaries as this text suggests:
"All of adversaries listed in Section 2 are presumed to be capable of launching
attacks against the computers used to perform CA functions."
As noted previously, collapsing the rather ambiguous terms you introduce in
section 3 into section 2's "Adversary" set might make sense.
---
43) "(as first noted by Pogo)" -- Reference/
=====
RESIDUAL VULNERABILITIES
---
44) The difference here is that if that information is used to sign updates in
the routing system which are propagated to BGPSEC-enabled routers then using
stale data can cause considerable churn or non-deterministic behaviors
(including forwarding loops_ in the routing system. Unless I'm missing
something, this is an incredibly bad idea:
" 1. The RP may choose to make use of its local cache, employing
local configuration settings that tolerate expired or stale
objects. (Such behavior is, nominally, always within the
purview of an RP in PKI.) Using cached, expired or stale data
subjects the RP to attacks that take advantage of the RP's
ignorance of changes to this data."
---
45) Here are you suggesting that BGPSEC should (will) protect the BGP AS_PATH,
or introduce a new attribute?
"BGPSEC signatures do not protect all attributes associated with an AS_path. "
Either way, some text about divergence between a BGPSEC path and a brand new
attribute would seem to be in order -- although in a previous section and
certainly not in a residual threats section.
---
46) s/AS_path/AS_PATH/
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
