[sidr] BGPSEC Threat Model ID

Danny McPherson <danny@tcb.net> Sat, 29 October 2011 20:20 UTC

Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D593521F853B for <sidr@ietfa.amsl.com>; Sat, 29 Oct 2011 13:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dccFMWZb5fIt for <sidr@ietfa.amsl.com>; Sat, 29 Oct 2011 13:20:25 -0700 (PDT)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com []) by ietfa.amsl.com (Postfix) with ESMTP id A0F5B21F8512 for <sidr@ietf.org>; Sat, 29 Oct 2011 13:20:24 -0700 (PDT)
Received: from peregrine.verisign.com ([]) (using TLSv1) by exprod6ob116.postini.com ([]) with SMTP; Sat, 29 Oct 2011 13:20:24 PDT
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com []) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p9TKK8ZL028195 for <sidr@ietf.org>; Sat, 29 Oct 2011 16:20:08 -0400
Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Oct 2011 16:20:08 -0400
From: Danny McPherson <danny@tcb.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Sat, 29 Oct 2011 16:20:07 -0400
Message-Id: <E96517DD-BAC7-4DD8-B345-562F71788C6A@tcb.net>
To: sidr wg list <sidr@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 29 Oct 2011 20:20:08.0091 (UTC) FILETIME=[26F7AEB0:01CC9678]
Subject: [sidr] BGPSEC Threat Model ID
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Oct 2011 20:20:26 -0000

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 

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

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 

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?