[sidr] IXP and Route Server and Next Hop transparency
Robert Raszuk <raszuk@cisco.com> Fri, 08 July 2011 20:11 UTC
Return-Path: <raszuk@cisco.com>
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 41B0621F8CED for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 13:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52ys+vIQy6u3 for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 13:11:18 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 39FC921F8C82 for <sidr@ietf.org>; Fri, 8 Jul 2011 13:11:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1036; q=dns/txt; s=iport; t=1310155878; x=1311365478; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=RE83Flvq/RhV8+Cr6PPP/itXI+cfx+16/w3536opY9A=; b=fUIy0hDbKvstVHdLr+maBHpDq4AYJPijdewAeYYsBYcUssqK0aUNHF2H zvKEmk+sMd0IkDHvTZvuPa4HsLeBebDnhyUdu0/bf1bJj0aY43uqqgzc8 CoPj9s84j7jHWLpWm39FTHDSobkXfQGngumRt8rQnVtVE8JdNyeYWP41n M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIHADNkF06rRDoJ/2dsb2JhbABUmFyOdXesCoMVDwGaM4Y4BJJMhH2LSQ
X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="1173767"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jul 2011 20:11:17 +0000
Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p68KBGIr009364 for <sidr@ietf.org>; Fri, 8 Jul 2011 20:11:16 GMT
Message-ID: <4E17646A.1050600@cisco.com>
Date: Fri, 08 Jul 2011 22:11:22 +0200
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: sidr@ietf.org
References: <012601cc3d54$8f07c4e0$ad174ea0$@highwayman.com> <m2y609kptw.wl%randy@psg.com> <014001cc3d74$319571c0$94c05540$@highwayman.com> <m2pqlklw3v.wl%randy@psg.com> <014a01cc3d7f$6312f730$2938e590$@highwayman.com> <m2oc14ljh7.wl%randy@psg.com> <017d01cc3da0$9f8cd390$dea67ab0$@highwayman.com>
In-Reply-To: <017d01cc3da0$9f8cd390$dea67ab0$@highwayman.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [sidr] IXP and Route Server and Next Hop transparency
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: raszuk@cisco.com
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: Fri, 08 Jul 2011 20:11:19 -0000
On the previous post I just wanted to limit such bgpsec less exchange to stub customers only. But I agree and stand corrected that if we solve it for all - transit included - then there is no need to make any special treatment for stubs. Question withdrawn. --- However I would like to ask for some clarification on why bgpsec is all about securing advertised nets and does not (at least to the best of my knowledge) certify that such prefixes have been advertised with legitimate next hops (the one which the prefix owner really owns). I browsed the respective drafts and did not find a trace of such. If we talk about RS in particular such RS is not in the data path hence it is not modifying next hops as received from his clients. How are we going to protect the paths from compromised RS where the prefixes are advertised correctly but next hops are bogus ? What's worse client's customers connected via such RS may have chosen such paths as best even if they have alternatives ... Thx, R.
- [sidr] draft-sriram-bgpsec-design-choices-00 -- I… Chris Hall
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Randy Bush
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Chris Hall
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Randy Bush
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Robert Raszuk
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Chris Hall
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Randy Bush
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Chris Hall
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Randy Bush
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Randy Bush
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Sandra Murphy
- [sidr] IXP and Route Server and Next Hop transpar… Robert Raszuk
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Sriram, Kotikalapudi
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Chris Hall
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Sriram, Kotikalapudi
- Re: [sidr] IXP and Route Server and Next Hop tran… Randy Bush
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Roque Gagliano
- Re: [sidr] IXP and Route Server and Next Hop tran… Sandra Murphy
- Re: [sidr] IXP and Route Server and Next Hop tran… Robert Raszuk
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Chris Hall
- Re: [sidr] draft-sriram-bgpsec-design-choices-00 … Chris Hall