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

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 28 February 2008 19:03 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 248183A6F15; Thu, 28 Feb 2008 11:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.281
X-Spam-Level:
X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[AWL=-0.463, 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 uqwKxZzDbZUk; Thu, 28 Feb 2008 11:03:27 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39B93A6EEF; Thu, 28 Feb 2008 11:03:24 -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 5B7B83A6EF7 for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 11:03:23 -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 n+RmzDbedojB for <sidr@core3.amsl.com>; Thu, 28 Feb 2008 11:03:21 -0800 (PST)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 961E53A6EF1 for <sidr@ietf.org>; Thu, 28 Feb 2008 11:02:39 -0800 (PST)
Received: by wf-out-1314.google.com with SMTP id 25so3283433wfa.31 for <sidr@ietf.org>; Thu, 28 Feb 2008 11:02:32 -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=rz+9/Z6n3hdvng+CQR5MTZAPcxfRZxD9OgWwfWN1ZaM=; b=prG8C/X6PY6oO+qM5k+CGT/O1s0XtisBw7+d6y6yKXgu3y6at9swNeqjRYYqipzMOGbH0wmAHOQIVMkLFvuSC2yZluFxRuyqQ8gPhvTs5Y6kjAL61833LsK8l0NDE6ov7Yp+8RAyakSa9CAVaCWcZZMBZNJXpdqQ2I2GugXVy/w=
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=aeGL6qwPYtPhW9TJgqNP1YFQDxgur/xrq+AS/MopP9S+wuh0DEEJfMaYa8OPQ42JbLJ0dR6UAkjihf/qY14idvDYyXaal+1ODvXoOhax7yMNa2yfGWncR+eBtAHQmGoEKTcQEZXk44H+2CnqBo6NMkUCv+Ve2IztlfbLM8N3kSY=
Received: by 10.142.133.15 with SMTP id g15mr6528061wfd.9.1204225352404; Thu, 28 Feb 2008 11:02:32 -0800 (PST)
Received: by 10.143.164.14 with HTTP; Thu, 28 Feb 2008 11:02:31 -0800 (PST)
Message-ID: <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com>
Date: Thu, 28 Feb 2008 11:02:31 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Sandra Murphy <sandy@sparta.com>
In-Reply-To: <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <47C4E38E.1070105@bogus.com> <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> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.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,

To further clarify,
>  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).
This would mean for someone who gets the information from RIPE does
not need to necessarily use the mechanism the way it currently stands.

Thanks,
Vishwas

On Thu, Feb 28, 2008 at 10:56 AM, Vishwas Manral <vishwas.ietf@gmail.com> 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).
>
>  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