[sidr] BGPSEC Threat Model ID

[Danny McPherson <[e-mail]>]

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?