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

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 28 February 2008 18:57 UTC

Return-Path: <sidr-bounces@ietf.org>
X-Original-To: ietfarch-sidr-archive@core3.amsl.com
Delivered-To: ietfarch-sidr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B8B28C790; Thu, 28 Feb 2008 10:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.294
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-qDjuMjUIJb; Thu, 28 Feb 2008 10:57:11 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B135F3A6EEA; Thu, 28 Feb 2008 10:57:11 -0800 (PST)
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACDE28C738 for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 10:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id appqoh9bJipx for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 10:57:05 -0800 (PST)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id CCFBA3A6EC9 for <sidr@ietf.org>; Thu, 28 Feb 2008 10:57:05 -0800 (PST)
Received: by wf-out-1314.google.com with SMTP id 25so3279004wfa.31 for <sidr@ietf.org>; Thu, 28 Feb 2008 10:56:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.143.37.20 with SMTP id p20mr6509032wfj.236.1204225018500; Thu, 28 Feb 2008 10:56:58 -0800 (PST)
Received: by 10.143.164.14 with HTTP; Thu, 28 Feb 2008 10:56:58 -0800 (PST)
Message-ID: <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com>
Date: Thu, 28 Feb 2008 10:56:58 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Sandra Murphy <sandy@sparta.com>
In-Reply-To: <Pine.WNT.4.64.0802281259530.2416@SANDYM-LT.columbia.ads.sparta.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <47C4E38E.1070105@bogus.com> <p06240500c3ebd2c48236@192.168.101.9> <77ead0ec0802271913u2c032ec2y2d03b73cb36de37f@mail.gmail.com> <p06240509c3ebe4459c93@169.223.13.71> <77ead0ec0802272031j6d958279tf3028c4096093020@mail.gmail.com> <p0624050cc3ebfc54fb15@169.223.13.71> <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com> <Pine.WNT.4.64.0802281109260.2416@SANDYM-LT.columbia.ads.sparta.com> <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com> <Pine.WNT.4.64.0802281259530.2416@SANDYM-LT.columbia.ads.sparta.com>
Cc: Roland Dobbins <rdobbins@cisco.com>, opsec wg mailing list <opsec@ietf.org>, sidr@ietf.org
Subject: Re: [Sidr] [OPSEC] pccw as17557 leak...
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

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

Thanks,
Vishwas

On Thu, Feb 28, 2008 at 10:13 AM, Sandra Murphy <sandy@sparta.com> 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
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr