Subject: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 14 Aug 2012 16:19:37 +0000

The authors have indicated that they believe the draft

Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-02
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02

is ready for a working group last call.

This starts the two week working group last call.  It will end on Aug 28.  Please review the draft and send comments to the list.

--Sandy

---

From: Brian Dickson <[email-masked]>
Date: Tue, 14 Aug 2012 17:20:41 -0400

I have reviewed the draft.

It remains vague and incomplete, in the Residual Threats section. This,
despite extensive discussion (since the -00 version) on the list regarding
very specific, very real, residual threats.

It not only fails to discuss them, it fails to enumerate them.

The extensive discussion is in the archives, and contains substantive
comments from at least 1/4 active participants in SIDR, including those
with the greatest degree of operational and/or implementation experience.

I would request that the WGLC be retracted until the authors decide to
address those previous comments.

Chairs: There should not be a need to re-raise the particulars - if the
authors got shot down before, and fail to include text or address the
complaints, I fail to see why they are submitting this, or the chair(s) are
doing a WGLC.

The objective of a threats model should be to model the threats, and
identify known weaknesses. If it is substantially incomplete, it is not
ready to go. It fails to accomplish its _only_ goal.

Excluding threats from this doc, because the solution does not address
them, is beyond ridiculous. It is laughable.

Sorry if this offends the authors. The authors' work is at issue, not the
authors themselves. They are fine and upstanding individuals. This ID, in
its current form, however, is, IMHO, junk.

Brian

On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra
<[email-masked]>wrote:

> This starts the two week working group last call.  It will end on Aug 28.
>  Please review the draft and send comments to the list.
>
> --Sandy
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 15 Aug 2012 17:56:09 +0000

Brian, I can see that you think that some people brought up some issues some time ago on some previous version(s) that have not been addressed.

Unfortunately, that's not clear enough for the chairs or authors to take action.

It would help if you could provide more specifics.

--Sandy, speaking as wg co-chair

________________________________
From: Brian Dickson [[email-masked]]
Sent: Tuesday, August 14, 2012 5:20 PM
To: Murphy, Sandra
Cc: [email-masked]
Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02

It remains vague and incomplete, in the Residual Threats section. This, despite extensive discussion (since the -00 version) on the list regarding very specific, very real, residual threats.

The extensive discussion is in the archives, and contains substantive comments from at least 1/4 active participants in SIDR, including those with the greatest degree of operational and/or implementation experience.

I would request that the WGLC be retracted until the authors decide to address those previous comments.

Chairs: There should not be a need to re-raise the particulars - if the authors got shot down before, and fail to include text or address the complaints, I fail to see why they are submitting this, or the chair(s) are doing a WGLC.

The objective of a threats model should be to model the threats, and identify known weaknesses. If it is substantially incomplete, it is not ready to go. It fails to accomplish its _only_ goal.

Excluding threats from this doc, because the solution does not address them, is beyond ridiculous. It is laughable.

Sorry if this offends the authors. The authors' work is at issue, not the authors themselves. They are fine and upstanding individuals. This ID, in its current form, however, is, IMHO, junk.

Brian

On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra <[email-masked]<mailto:[email-masked]>> wrote:
The authors have indicated that they believe the draft

--Sandy
_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Aug 2012 16:25:59 -0400

I'll try to be more clear:

I do not believe comments regarding _any_ version of the draft in question,
have been adequately addressed (on the mailing list, or in person, or in
the document).

There are a number of topics of contention, and I believe it is the duty of
the chairs, not my responsibility, to track the specific items in question.

To quote from RFC 2414, section 3.3:

   It is occasionally appropriate to revisit a topic, to re-evaluate
   alternatives or to improve the group's understanding of a relevant
   decision.  However, unnecessary repeated discussions on issues can be
   avoided if the Chair makes sure that the main arguments in the
   discussion (and the outcome) are summarized and archived after a
   discussion has come to conclusion.

I would respectfully point out the dates of the discussion, and a few
of the subject lines, as follows:

"BGP Thread Model ID" (between 10/29/2011 and 11/14/2011, covering a
number of intertwined issues, where the author effectively states that
he will only change the text at the direction of the Chair(s), and
where there are a significant number of participants who express a
desire to have the text changed.)

"Route Leaks message to IDR" (3/21/2012 onward)

Also, given that draft-dickson-sidr-route-leak-solns exists and has
not expired, and that IDR has been asked to review the route-leaks
issue, and have themselves asked GROW to take a look at it, it would
be more appropriate to have the -threats- doc refer to this draft, and
to the ongoing IETF process of codifying route-leaks, rather than
disingenuously continuing to state that nothing codifies route-leaks
in the IETF.

(Technically, discussions in the mailing list archive are IETF
materials, at the very least, as are current unexpired I-D docs.)

Even without going into whether or not it is codified officially, the
codification can easily be incorporated into the -threats- doc, in the
residual threats.

The importance of this is that in considering the body of work of the
WG, and in particular potentially deploying BGPSEC (in whatever form
it emerges), operators _must_ be given all the necessary information,
including whether BGPSEC protects against threats that actually exist.
Pretending the threats do not exist, by not detailing them in the
"Residual Threats" section, is really not what I would consider
IETF-worthy.

So, in summary:

- if the chairs cannot find a volunteer to summarize and track the
major issues related to WG discussion (on-list and in-person) that
affect the -threats- doc, their duty is to do it themselves.

- I would like to see an assertion on each major issue, the following:

--- has it been discussed to death?

--- has consensus been reached (either way) about whether it should be
included in the -threats- doc?

--- has the threats doc adequately addressed the issue (and if so, in
which section)?

What I am contending is, that one or more issues have either reached
an impasse (and thus the -threats- doc, as such, does not have rough
consensus), or have a consensus which the doc does not incorporate
adequately.

Is that enough to act on?

Oh, and in case it isn't abundantly clear:

I do not support moving the document forward in its current state.

Brian

On Wed, Aug 15, 2012 at 1:56 PM, Murphy, Sandra <[email-masked]>wrote:

>  Brian, I can see that you think that some people brought up some issues
> some time ago on some previous version(s) that have not been addressed.
>
>  ------------------------------
> *From:* Brian Dickson [[email-masked]]
> *Sent:* Tuesday, August 14, 2012 5:20 PM
> *To:* Murphy, Sandra
> *Cc:* [email-masked]
> *Subject:* Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02
>
>  Sorry if this offends the authors. The authors' work is at issue, not
> the authors themselves. They are fine and upstanding individuals. This ID,
> in its current form, however, is, IMHO, junk.
>
>  Brian
>
> On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra <[email-masked]
> > wrote:
>

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Aug 2012 16:28:10 -0400

s/2414/2418/ - my bad.

On Wed, Aug 15, 2012 at 4:25 PM, Brian Dickson <
[email-masked]> wrote:

> I do not believe comments regarding _any_ version of the draft in
> question, have been adequately addressed (on the mailing list, or in
> person, or in the document).
>
> There are a number of topics of contention, and I believe it is the duty
> of the chairs, not my responsibility, to track the specific items in
> question.
>
> I would respectfully point out the dates of the discussion, and a few of the subject lines, as follows:
>
> "BGP Thread Model ID" (between 10/29/2011 and 11/14/2011, covering a number of intertwined issues, where the author effectively states that he will only change the text at the direction of the Chair(s), and where there are a significant number of participants who express a desire to have the text changed.)
>
> Also, given that draft-dickson-sidr-route-leak-solns exists and has not expired, and that IDR has been asked to review the route-leaks issue, and have themselves asked GROW to take a look at it, it would be more appropriate to have the -threats- doc refer to this draft, and to the ongoing IETF process of codifying route-leaks, rather than disingenuously continuing to state that nothing codifies route-leaks in the IETF.
>
> (Technically, discussions in the mailing list archive are IETF materials, at the very least, as are current unexpired I-D docs.)
>
> Even without going into whether or not it is codified officially, the codification can easily be incorporated into the -threats- doc, in the residual threats.
>
> The importance of this is that in considering the body of work of the WG, and in particular potentially deploying BGPSEC (in whatever form it emerges), operators _must_ be given all the necessary information, including whether BGPSEC protects against threats that actually exist. Pretending the threats do not exist, by not detailing them in the "Residual Threats" section, is really not what I would consider IETF-worthy.
>
> So, in summary:
>
> - if the chairs cannot find a volunteer to summarize and track the major issues related to WG discussion (on-list and in-person) that affect the -threats- doc, their duty is to do it themselves.
>
> --- has consensus been reached (either way) about whether it should be included in the -threats- doc?
>
> --- has the threats doc adequately addressed the issue (and if so, in which section)?
>
> What I am contending is, that one or more issues have either reached an impasse (and thus the -threats- doc, as such, does not have rough consensus), or have a consensus which the doc does not incorporate adequately.
>
>> On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra <
>> [email-masked]> wrote:
>>
>>> This starts the two week working group last call.  It will end on Aug
>>> 28.  Please review the draft and send comments to the list.
>>>
>>> --Sandy

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 20 Aug 2012 00:14:41 -0400

On Wed, Aug 15, 2012 at 4:28 PM, Brian Dickson
<[email-masked]> wrote:
> On Wed, Aug 15, 2012 at 4:25 PM, Brian Dickson
> <[email-masked]> wrote:
>>
>> question, have been adequately addressed (on the mailing list, or in person,
>> or in the document).
>>
<snip>
>> the subject lines, as follows:
<snip>
>> "Route Leaks message to IDR" (3/21/2012 onward)

I think there is text in the draft now about residual threats and route-leaks.
I believe the status on the 'do something in grow so something happens
in idr so something can happen in sidr' is 'waiting on author to get
unstuck and proceed'. which is fine, but shouldn't hold up this doc
which can be fixed/altered/etc once/if there is output from grow/idr
that sidr can do something about.

>> Also, given that draft-dickson-sidr-route-leak-solns exists and has not
>> expired, and that IDR has been asked to review the route-leaks issue, and
>> have themselves asked GROW to take a look at it, it would be more
>> appropriate to have the -threats- doc refer to this draft, and to the
>> ongoing IETF process of codifying route-leaks, rather than disingenuously
>> continuing to state that nothing codifies route-leaks in the IETF.

I don't think it's disingenuous... the threats doc says:
     ""Route leaks" are viewed as a routing security problem by many
      network operators, even though there is no IETF-codified
      definition of a route leak.  BGP itself does not include semantics
      that preclude what many perceive as route leaks.  Moreover, route
      leaks are outside the scope of BGPSEC, at this time, based on the
      SIDR charter.  Thus route leaks are not addressed in this threat
      model."

currently there isn't a completed definition, that's not to say that
eventually there may be, and the doc can be updated then. Hopefully
when there is a definition we can also have some 'method to fix them'
from idr.

<snip>

>> The importance of this is that in considering the body of work of the WG,
>> and in particular potentially deploying BGPSEC (in whatever form it
>> emerges), operators _must_ be given all the necessary information, including
>> whether BGPSEC protects against threats that actually exist. Pretending the
>> threats do not exist, by not detailing them in the "Residual Threats"
>> section, is really not what I would consider IETF-worthy.

no one is pretending anything (I think), we are awaiting some results
from the aforementioned groups/authors. I believe the other folk who
were interested in this topic are satisfied with the direction.

I think it's time to move the document along.

-chris

---

From: Danny McPherson <[email-masked]>
Date: Tue, 21 Aug 2012 23:24:54 -0400

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/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Aug 2012 05:33:03 -0400

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:

*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:

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

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

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

attack." -- This and other references to "BGPSEC spec" need a stable 
reference.

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

*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, *

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

=====

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?:

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

=====

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

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

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

*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:

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

*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:

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

---

From: Danny McPherson <[email-masked]>
Date: Tue, 28 Aug 2012 11:19:41 -0400

On Aug 28, 2012, at 5:33 AM, Stephen Kent wrote:

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

Hahh, that's pretty funny :-)

Thanks for the thoughtful reply Steve, I'll get back to you in short order on these responses - but if an updated I-D appears in the interim I'll try to apply comments only to the revision.

-danny