Re: [sidr] Burstiness of BGP updates

Russ White <russw@riw.us> Thu, 17 November 2011 00:48 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 F335C21F8CF3 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 16:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.543
X-Spam-Level:
X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599]
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 PYcnDn2nspJk for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 16:48:57 -0800 (PST)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75D21F8CE3 for <sidr@ietf.org>; Wed, 16 Nov 2011 16:48:57 -0800 (PST)
Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:49570 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RQq9u-0008Ku-9Z; Wed, 16 Nov 2011 19:48:54 -0500
Message-ID: <4EC459F0.9070200@riw.us>
Date: Wed, 16 Nov 2011 19:48:48 -0500
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Jakob Heitz <jakob.heitz@ericsson.com>
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <m2fwhqeq5i.wl%randy@psg.com> <CCE759E6-BEA6-433B-957A-6559C67BAD52@ericsson.com> <DCC302FAA9FE5F4BBA4DCAD4656937791452387941@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <DCC302FAA9FE5F4BBA4DCAD4656937791452387978@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <E2D346C7800D704DB41ED19D90434DA6320C15DF93@ESESSCMS0358.eemea.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se>
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" <sidr@ietf.org>
Subject: Re: [sidr] Burstiness of BGP updates
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: Thu, 17 Nov 2011 00:48:58 -0000

> Does this now allow me to send passwords in the clear on the internet?

1. Protection means to know that the site you intend to get to is
actually the site you reach.
2. Part of this protection requires protecting the routing system.
3. If you don't protect the routing system, then people are vulnerable
to various attacks against their accounts on web sites they believe they
can trust.

Is it really that complex?

What I see so far is:

1. SIDR has ruled out "knowing intentions." Without knowing intentions,
you can't very well compare what you know to what you think you should know.

2. SIDR has ruled knowing what the actual state of the system currently
is (well, at least we know what the system might have looked like a week
or two ago, and maybe a new route has come along that isn't signed but
that I should prefer over an already existing signed route, or
perhaps...) If you don't know what the system is supposed to look like,
then you don't know whether or not what you see is valid.

Can you tell me what it is SIDR is actually securing?

:-)

Russ