Subject: Re: Last Call: <draft-ietf-sidr-bgpsec-threats-06.txt> (Threat Model for BGP Path Security) to Informational RFC

From: SM <[email-masked]>
Date: Fri, 13 Sep 2013 02:54:22 -0700

At 15:26 09-09-2013, The IESG wrote:
>The IESG has received a request from the Secure Inter-Domain Routing WG
>(sidr) to consider the following document:
>- 'Threat Model for BGP Path Security'
>   <draft-ietf-sidr-bgpsec-threats-06.txt> as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-09-23. Exceptionally, comments may be

I read this draft to find out whether we have met the enemy, and he is us [1].

The draft mentions PATHSEC in the Introduction section without 
explaining the term.  I suggest using the following (edited) which is 
already in the Abstract:

   "The term PATHSEC is used to refer to any BGP path security
    technology that makes use of the RPKI."

According to Section 2 anyone or any thing can be an adversary.  I 
would not use "threat" to determine "adversary" as motivation can 
change.  I am not sure whether the average reader will understand the 
nuance.  Please note that I am not suggesting any change.

In Section 3:

   'Hackers may be motivated by a desire for "bragging rights" or for
    profit or to express support for a cause.'

The above may be applicable for any person.

   "The staff could be motivated to do this based on political pressure
    from the nation in which the registry operates (see below)
    or due to criminal influence (see above)."

Wouldn't the profit angle also be applicable for registries?  The 
above focuses on staff instead of the registry.  Political pressure 
would apply for the organization (see definition of entity in Section 2).

   "Nations - A nation may be a threat.  A nation may control one or more
    network operators that operate in the nation, and thus can cause them
    to act as rogue network operators."

The are also network operators that operate outside the nation.  That 
can be used to get the operator to act as a dishonest network 
operator outside the nation.

  "A nation may have a technical active wiretapping capability (e.g.,
   within its territory) that enables it to effect MITM attacks on
   inter-network traffic.  (This capability may be facilitated by
   control or influence over a telecommunications provider operating
   within the nation.)"

There is an emphasis that this (the nation) threat only applies 
within the territory.  There is a sentence after the quoted text that 
the nation has the ability to take control in other countries.  Would 
a reference to NSL be appropriate in that paragraph?

In Section 4.2:

   "False (Route) Origination: A router might originate a route for a
    prefix, when the AS that the router represents is not authorized
    to originate routes for that prefix.  This is an attack, but it is
    addressed by the use of the RPKI [RFC6480]."

Wouldn't the way to address the attack open the way for other attacks 
(see Section 3)?

In Section 4.5:

   "Some adversaries might effect an attack on a CA by violating
    personnel or physical security controls as well. The distinction
    between CA as adversary vs. CA as an attack victim is important.
    Only in the latter case should one expect the CA to remedy problems
    caused by a attack once the attack has been detected.  (If a CA
    does not take such action, the effects are the same as if the
    CA is an adversary.)"

I gather that the CA would have a CPS and that CPS would take into 
consideration the possible attacks and describe the measures to 
prevent them.  The above looks at it from an after-the-fact 
perspective; i.e. once the damage is done, action is taken.

This draft is well-thought.  There's a cryptography angle to one of 
the references.  I wondered about the why for that reference.

Regards,
-sm

1. The explanation was that "each individual is wholly involved in 
the democratic process, work at it or no.  The results of the process 
fall on the head of the public and he who is recalcitrant or 
procrastinates in raising his voice can blame no one but himself".

---

From: Danny McPherson <[email-masked]>
Date: Thu, 19 Sep 2013 17:22:46 -0400

I read this draft and tried to participate in shaping into something I as an operator believe useful in SIDR WG, but to no avail -- IMO because the protocol work, and then the requirements work, were largely completed already.  I believe this approach will cause more harm than good and result in more instability than security, and it leaves some considerable holes with which I am actually concerned about related to inter-domain routing security (and autonomy) on the Internet.   As such, myself and some other operators published this document, which has since been accepted and evolved as a WG document within the Global Routing Operations WG (GROW):

http://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-help-02
 
I've given up on SIDR, I wish them well….

-danny

On Sep 9, 2013, at 6:26 PM, The IESG <[email-masked]> wrote:

> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document describes a threat model for the context in which
>   (E)BGP path security mechanisms will be developed.  The threat model
>   includes an analysis of the RPKI, and focuses on the ability of an AS
>   to verify the authenticity of the AS path info received in a BGP
>   update.  We use the term PATHSEC to refer to any BGP path security
>   technology that makes use of the RPKI.  PATHSEC will secure BGP
>   [RFC4271], consistent with the inter-AS security focus of the RPKI
>   [RFC6480].
> 
>   The document characterizes classes of potential adversaries that are
>   considered to be threats, and examines classes of attacks that might
>   be launched against PATHSEC.  It does not revisit attacks against
>   unprotected BGP, as that topic has already been addressed in
>   [RFC4271].  It concludes with brief discussion of residual
>   vulnerabilities.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
>

---

From: "Russ White" <[email-masked]>
Date: Thu, 19 Sep 2013 18:28:34 -0400

> I read this draft and tried to participate in shaping into something I as
an
> operator believe useful in SIDR WG, but to no avail -- IMO because the
> protocol work, and then the requirements work, were largely completed
> already.  I believe this approach will cause more harm than good and
result in
> more instability than security, and it leaves some considerable holes with
> which I am actually concerned about related to inter-domain routing
security
> (and autonomy) on the Internet.   As such, myself and some other operators
> published this document, which has since been accepted and evolved as a
> WG document within the Global Routing Operations WG (GROW):
> 
> I've given up on SIDR, I wish them well..

+1

Russ