Re: [sidr] BGPSEC Threat Model ID

Russ White <russw@riw.us> Wed, 02 November 2011 17:41 UTC

Return-Path: <russw@riw.us>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1046B11E814D for <sidr@ietfa.amsl.com>; Wed, 2 Nov 2011 10:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level:
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, SARE_UNSUB22=0.948]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+t5EiS9mLyb for <sidr@ietfa.amsl.com>; Wed, 2 Nov 2011 10:41:52 -0700 (PDT)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8622A11E8149 for <sidr@ietf.org>; Wed, 2 Nov 2011 10:41:52 -0700 (PDT)
Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:50908 helo=rtp-russwh-8913.cisco.com) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RLeox-0002DX-1T; Wed, 02 Nov 2011 13:41:51 -0400
Message-ID: <4EB180DD.5010401@riw.us>
Date: Wed, 02 Nov 2011 13:41:49 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Brian Dickson <brian.peter.dickson@gmail.com>
References: <E96517DD-BAC7-4DD8-B345-562F71788C6A@tcb.net> <p06240807cad42f85eb7d@193.0.26.186> <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <p06240801cad6ab773279@193.0.26.186> <CAH1iCir-UoT+BMOD53oxQ9fdMiGirvaTL0eZDS3A5wVEDuw2LA@mail.gmail.com> <4EB170AD.1030302@riw.us> <CAH1iCiqTST7V=jdHe8R04nfP-0c33NSo9m4gZ_majpx7wUCciw@mail.gmail.com>
In-Reply-To: <CAH1iCiqTST7V=jdHe8R04nfP-0c33NSo9m4gZ_majpx7wUCciw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
Cc: sidr@ietf.org
Subject: Re: [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: Wed, 02 Nov 2011 17:41:53 -0000

> Signed.

I wonder --if I sign my door knob, does that make it secure?

Cryptographic signatures are not security. In fact, for all our wailing
about "obscurity is not security," cryptography is just a more
sophisticated form of obscurity. Somewhere along the way we've lost
sight of the original meaning of that phrase, and the original goals of
security.

>> The failure to define and separate policy from routing has caused a
>> great deal of confusion within the BGP security space over the years.
> 
> Correct. And given that there exist malicious use cases for violating implicit
> policy, it makes sense that it be addressed in conjunction with BGPSEC.

There are several problems here.

1. Most providers apparently want to enforce policy without telling
anyone what their policy actually is. That this is a logical
contradiction doesn't seem to disturb anyone.

2. You can't "enforce" your policy --all you can do is signal to someone
else what that policy is, and ask them nicely to enforce it for you.

2a. If you have a business relationship with this other party, then you
already have an enforcement mechanism at hand --signatures and other
sorts of things won't provide anything additional.

2b. If you don't have a business relationship with this other party,
then there's no point in asking, because they're going to do what's best
for them, not for you.

There's some sort of dream world where you can not tell anyone what your
policies are, and people you don't have a business relationship with
will somehow enforce those policies (that they don't know about, because
you refuse to tell them) for you. It's a nice dream, but I don't see how
it has any bearing on reality.

Until we can get past this little dream world, I don't see how SIDR is
going to make any real progress towards actually securing BGP. Either
policies --all policies-- must be off limits, even ones masquerading as
"man in the middle attacks," or all policies must be within bounds, and
we must enumerate and deal with them honestly.

:-)

Russ