Re: [Sidr] [OPSEC] pccw as17557 leak...

Sandra Murphy <> Thu, 28 February 2008 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A53FD28C73D; Thu, 28 Feb 2008 12:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.78
X-Spam-Status: No, score=-0.78 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 03drDDwUh4vb; Thu, 28 Feb 2008 12:07:03 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 27D1628C1BC; Thu, 28 Feb 2008 12:06:39 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BD6728C12C; Thu, 28 Feb 2008 12:06:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oNQ30Wu4Y-SL; Thu, 28 Feb 2008 12:06:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E0C6828C9B8; Thu, 28 Feb 2008 12:03:32 -0800 (PST)
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id m1SK3FbM009828; Thu, 28 Feb 2008 14:03:16 -0600
Received: from ( []) by (8.12.11/8.13.1) with ESMTP id m1SK3Do8027336; Thu, 28 Feb 2008 14:03:13 -0600
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Feb 2008 15:03:13 -0500
Date: Thu, 28 Feb 2008 15:03:12 -0500
From: Sandra Murphy <>
To: Vishwas Manral <>
In-Reply-To: <>
Message-ID: <>
References: <> <p06240500c3ebd2c48236@> <> <p06240509c3ebe4459c93@> <> <p0624050cc3ebfc54fb15@> <> <> <> <> <>
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Feb 2008 20:03:13.0697 (UTC) FILETIME=[F3383110:01C87A44]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 ( []); Thu, 28 Feb 2008 14:03:16 -0600 (CST)
Cc: Roland Dobbins <>, opsec wg mailing list <>,
Subject: Re: [Sidr] [OPSEC] pccw as17557 leak...
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Thu, 28 Feb 2008, Vishwas Manral wrote:

> Hi Sandra,
> Thanks again for the information in both the mails. I got to read the
> differences between the RIR and the IRR. I also agree to the fact that
> in case we have some mechanism which can verify all the attributes of
> a route, then such a certificate which does this would be helpful, and
> then the infrastructure you talk about would be helpful too.
> I understand the fact that we are talking about a NLRI and the AS
> element in the AS_PATH. I still look very interestingly at differences
> we have between AS_SEQUENCE and AS_SET (if we are to verify an update
> more than one hop away which element in the AS-SET to verify it
> against - not much difference though if we have only one AS number in
> the AS_PATH).

You are right that we have not considered how you validate an AS_PATH 
where the origination is an AS_SET.  That has been looked at before, and 
it is complicated and the possibilities of providing some protection 
aren't good, even on the theoretical level.  Keep in mind that the number 
of BGP Updates that contain AS_SET anywhere in the AS_PATH are a tiny, 
tiny, percentage (one figure I saw recently was 10K out of a base of 91M 
updates - .01%).  As a wg, we decided not to work on this right now.

> The only point I want to add to the discussion is because we have to
> verify the Origin only in the first hop peer, we do not need a global
> database (as I mentioned we are not saving against malicious attacks
> in any case).

As long as *every* first hop peer does the appropriate strong 
verification, you would be good.

But this system allows ASs beyond the first hop to verify the origination 
of the route.  So, for example, UUNET could have verified the 
announcements it saw from PCCW even if PCCW did no check and propogated 
the bogus announcement.

(As "Origin" is a BGP attribute with a different semantics, perhaps we 
should avoid using that term in this context to avoid confusion.)

And, finally, yes we *are* protecting against malicious attacks (as well 
as accidental attacks) on those features we *are* intending to protect. 
No, we are not protecting against malicious attacks (or accidental 
attacks) on features we are *not* intending to protect.  The difference is 
not malicious vs accidental, the difference is scope of protection.

You think we haven't gone far enough, I'm saying what we're building is 
the basis for any further protection.

Sidr mailing list