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