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

[Stephen Kent <[e-mail]>]

Danny, here are replies to the issues you raised wrt the threats doc.

Steve
--------

I am surprised that external systems (e.g., NTP) are not mentioned at 
all in this document?

*I will add some text to note that the use of certificates, CRLs, and 
other RPKI signed products requires access to a reliable (though not 
highly precise) time source by the devices that process them. For the 
RPKI, the current deployment model calls for such processing to be 
performed by servers, not routers. For BGPSEC, the need for a reliable 
time source may extend to routers, if BGPSEC path signatures carry an 
expiration time. *

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 will add text noting that the focus of the doc is eBGP, not iBGP.*

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.

*Agree. Fixed.*

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/

*fixed.*

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.

*This text is taken from the charter (including the "AS-PATH" typo). A 
discussion of whether the BGPSEC design addresses this charter goal may 
be appropriate for the BGPSEC architecture document, but not here. *

**

=====

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.

*Your comment caused me to realize that I ought not be addressing BGPSEC 
in this document. BGPSEC is a proposed solution and thus not the focus 
of a threat analysis which, in turn, is intended to be an input to a 
requirements document. I'll remove all BGPSEC references. *

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.

*As noted above, I'm removing all references to BGPSEC. *

5) "i.e., for the links that connect BGP routers." By "links" here I 
assume you mean "transport connections"?

*I meant the telecom links that connect eBGP speakers, but talking in 
terms of BGP/TCP sessions seems OK. I'll edit the text accordingly.*

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.

*I have changed the text use the phrasing you suggested, and have 
included the relevant cite. *

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."

*I disagree. It is common in academic literature to use an oracle as the 
basis against which the security of a protocol is measured. That's an 
appropriate model for protocol security in many contexts, e.g., for a 
point-to-point connection where a wiretapper would be able to see all of 
the traffic. It is overkill in this context, and thus I have chosen to 
explicitly reject it. But, I have removed the reference to any specific 
solution approach.*

=====

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.

*You're missing a ")" above **J. I don't know which SIDR (vs. IETF) RFCs 
you have in mind. Please be specific. Restating definitions in a 
terminology section is common; unless the WG chairs believe this is a 
bad idea for this document, I'll retain them. If you feel that specific 
terms have been redefined in a fashion that is inaccurate, please note 
which ones, and indicate the preferred definitions, and we can revisit 
them as needed.*

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."

*I looked at several of the RPKI RFCs and didn't see a definition for 
this term. I believe we added it in response to a request from Sriram. 
If you have an appropriate cite I can add it. *

Also, you're missing closing ")" there..

*Fixed.*

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.").

*You seem to have omitted some words above, so the result is not a 
sentence. I also don't know what "pay-for-for" means, ...*

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.

*When the adversary acquires the capabilities to carry out an attack, 
the adversary becomes a threat. If you believe that the adversary has a 
good chance of acquiring a specific capability (in a time frame of 
interest), then it is appropriate to treat the adversary as a threat, 
otherwise not. This characterization of "threat" has been used in 
defense and diplomatic contexts for decades.*

" 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."

*I've removed all references to BGPSEC.*

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?

*I've changed the text to avoid suggesting that a path security solution 
requires certificates to be per router vs. per-AS.*

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?

*I've reworded this to avoid the offending language.*

14) Is the phrase "Hackers" even necessary here, or should you not 
employ "Adversary" as defined in previous sections?

*First, it's not clear where "here" is, since you didn't include any 
quoted text. If you are referring to the discussion of hackers as a 
class of adversary, then yes, it's necessary to explicitly describe the 
class of adversary. *

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?

*Not in general. An MITM attack against a link implies an on-path 
presence, which is not usually a capability of a hacker, e.g., an 
ability to insert a packet processing device on a link between two 
(e)BGP speakers. The underlying notion is that such links (in the layer 
1, not layer 4 sense) are not accessible to this class of adversaries.*

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.

*In this context, a subscriber is a customer of a network operator, and 
who is not another network operator.*

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?

*No. The traditional term here is a "false flag" operation, if effected 
via a nation state. We're not talking about installing malware as a way 
to make use of the privileges of a legitimate network operator.*

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.

*The intent here is to give examples that distinguish motivations of 
different classes of adversaries, so using the generic term is not 
appropriate.*

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.

*The text describing criminal motivations and capabilities is different.*

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.

*I agree that some folks use the term "threat" more generally, to 
encompass non-malicious behavior, referring to threats as accidental vs. 
malicious. I have chosen to focus on malicious behavior here. I'll note 
that explicitly, e.g., by augmenting the definition of "threat."*

21) The "adversary" comments about apply equally to "Nations" as well, 
methinks, if these represent threats to users of the system.

*I disagree, for the same reasons cited in my responses above. The text 
describing capabilities is distinct for different classes of adversaries 
and this argues against using the more generic term.*

=====

ATTACKS ON A BGP ROUTER

22) A stable reference for "route leaks" would be useful in the 
document, given the recurring references

*If we had one that the WG agreed upon, I'd be happy to insert it. 
Otherwise, maybe we should just delete the phrase from the document.*

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.

*I have reworded this to not be BGPSEC-specific.*

24) s/if such a time is mandates,/if such a time is mandated,/

*fixed.*

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... "

*The intent was an eBGP neighbor, which is also a BGPSEC neighbor. But, *

26) s/in injected/injected/

*More likely s/in 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?)?

*I've removed the redundant comment about re-announcing.*

=====

ATTACKS ON NETWORK OPERATOR MANAGEMENT COMPUTERS

28) define "RP Tools"

**

*Software used by an RP to process RPKI signed products, consistent with 
RFCs 6486, 6487, 6488, 6490, and 6491.*

29) Here and in elsewhere first use of acronyms should be expanded 
(e.g., CRL, etc.)

*Agreed, we'll revisit the text to verify that first uses of acronyms 
are expanded.*

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."

*I agree that we should keep separate attacks that apply to vanilla BGP, 
the RPKI context, and to the BGPSEC context. However, the example you 
gave is not one that crosses this boundary. This attack is describing 
replacement of router certificates, so it applies only to a network that 
is BGPSEC-enabled, and thus would publish router certificates. The text 
has been changed to reflect removal of all BGPSEC references.*

=====

ATTACKS ON A REPOSITORY PUBLICATION POINT

31) s/ inside or an external threat/ insider or an external threat/ ?

*Fixed.*

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."

*What do you mean by local vs. remote systems? Are you referring to RPKI 
pub points vs. RP caches? The repository RFC says nothing about a 
repository removing data because the data is stale, There is no 
assumption that an entity operating a repository will scan its contents 
and delete expire certificates or stale CRLs.*

**

*While it is always preferable to use current, validated data from the 
RPKI repository system, it is not unreasonable to use stale data in the 
absence of current, validated data. Ultimately this decision is up to 
each RP, but discarding stale data just because it's stale is not 
usually a great strategy. Consider my driver's license (which ought not 
be used to identify me except in the context of driving or renting a 
car). It is probably just as valid an ID the day after it expires as it 
was the day before.*

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?

*I disagree. I think it is good advice and it is not inconsistent with 
how many systems operate today when RPs lack access to the freshest PKI 
data. *

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.

*If there is no older (valid) object instance in the RP's cache, then 
the RP cannot make use of it, and it is as though the object did not 
exist. Yes, an adversary can exploit this RP behavior, but is that worse 
that having an RP ignore the old (valid) data? Consider a generic PKI, 
that uses CRLs (not OCSP). If an adversary suppresses publication of the 
next CRL (as specified by the next Update field), what should RPs do? 
All of the previously revoked certificates are still revoked (ignoring 
the PKIX-deprecated CRL entry extension that can undo revocation). So, 
it makes sense to keep using the old CRL until a current one can be 
acquired, CRLs do not expire; they become stale. Yes, RPs ought to 
engage in some OOB action to try to cause a current CRL to be posted, 
but in the meantime ... *

35) Regarding the above, what should an RP do when they detect such an 
attack?

*The Ghostbusters record was developed to provide a means for alerting 
pub point maintainers of this sort of problem. It was specified after we 
generated this text, so we can add a pointer to it now.*

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 "

*This is not a requirements document, so the question, in that form, in 
not applicable.*

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).

*See comment above re Ghostbusters.*

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."

*Again, I disagree, for the reasons noted earlier.*

39) s/be un aware/be unaware/

*Fixed.*

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."

*No. This text refers to "...certificates or ROAs that are not present."*

41) Hope?

"Here too the hope is that the CA will be notified of the problem (by 
RPs) and will remedy the error."

*Gee, I didn't mean to sound like an Obama supporter. s/hope/goal/*

=====

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:

*Section 3 defined 5 classes of threats. Since a threat is a motivated 
capable adversary, ...*

"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.

*See response above.*

43) "(as first noted by Pogo)" -- Reference/

*fixed.*

=====

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."

*I've already address the question of whether it makes sense for an RP 
to use validated but stale 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. "

**

*addressed as part of removing all BGPSEC references.*

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.

*See comment above. *

46) s/AS_path/AS_PATH/

*fixed.*