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

"Vishwas Manral" <> Thu, 28 February 2008 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0B8B28C790; Thu, 28 Feb 2008 10:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.294
X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7-qDjuMjUIJb; Thu, 28 Feb 2008 10:57:11 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id B135F3A6EEA; Thu, 28 Feb 2008 10:57:11 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4ACDE28C738 for <>; Thu, 28 Feb 2008 10:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id appqoh9bJipx for <>; Thu, 28 Feb 2008 10:57:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CCFBA3A6EC9 for <>; Thu, 28 Feb 2008 10:57:05 -0800 (PST)
Received: by with SMTP id 25so3279004wfa.31 for <>; Thu, 28 Feb 2008 10:56:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HsFtt+h6/44TEdl/CDk4g4uSdlnKISnTJpgBSfZjjp0=; b=khmex5Y6BCLWkkSsd6R3tIJDjDdWVQoFEe8x1MOvIgfniWqww/yqtYQldcLgxGfgxQ5OrZXB0MzJxAqIg1Mn54ud9zlQ4GvNGgpAPZIxeWkd+96PUIJLAG75Dx+WtOaXwbULVzRsfy6H86a6a1swMIwj87Ih0Abg1DYlFjpC/1E=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S5ER9s9/nFXDiCJ3RprIYF6ALdO/kuvxYdNPqdyOiSGbgU7yG+hnjxxGailK9J6Nr9ZsBpKuWRb0qT+5pZT+Sj4Xk4JBfMSuerO3Sqjq9n8FkMfz8fS5nNLA04j5+JcXURHEER1IWeEqjZwO9BFUnG6tNrvjZ04ndM/+ea0f6oY=
Received: by with SMTP id p20mr6509032wfj.236.1204225018500; Thu, 28 Feb 2008 10:56:58 -0800 (PST)
Received: by with HTTP; Thu, 28 Feb 2008 10:56:58 -0800 (PST)
Message-ID: <>
Date: Thu, 28 Feb 2008 10:56:58 -0800
From: Vishwas Manral <>
To: Sandra Murphy <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <p06240500c3ebd2c48236@> <> <p06240509c3ebe4459c93@> <> <p0624050cc3ebfc54fb15@> <> <> <> <>
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

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).

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).


On Thu, Feb 28, 2008 at 10:13 AM, Sandra Murphy <> wrote:
>  On Thu, 28 Feb 2008, Vishwas Manral wrote:
>  > Hi Sandra,
> >
>  > After reading a bit through what Pekka/ Danny/ Joe Abely said away in
>  > which we could update the filters between peers automatically(only
>  > relating to routes originated by the peer), from the RIR, we may
>  > achieve the very same functionality.
>  >
>  Generating filters from IRR (not RIR, a point it took me a while to learn)
>  data is indeed similar, with the following differences:
>  (a) Security (authenticity, integrity and authorization) of IRR data
>  varies widely among IRR's.  And there are quite a few IRRs.
>  (b) Even those IRRs associated with RIRs can protect authn/int/authr of
>  only that data that comes from their own members.
>  (c) RIPE uses the strongest security model among the many IRRs, but their
>  system relies on protection of the communication with the user (and the
>  protection varies from user to user) and the protection of communication
>  to the person accessing the data.  The protection is not stored with the
>  data, so the reader must rely on the IRR to get it right.  I don't think
>  the reader can tell what protection was used to put the data in there, so
>  there's no way for the reader to judge the assurance in the data.
>  (d) This is not a mechanism that could extent to protection of the other
>  BGP features that you have mentioned.  So if/when we decide to work on
>  those features, we'd have to start over with the system we are building
>  now anyway.
>  --Sandy
Sidr mailing list