[sidr] Some comments on draft-ietf-sidr-bgpsec-threats-02

[Danny McPherson <[e-mail]>]

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 motivations 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/