Re: [sidr] IXP and Route Server and Next Hop transparency

Randy Bush <randy@psg.com> Sat, 09 July 2011 14:56 UTC

Return-Path: <randy@psg.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 4DFF621F8583 for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 07:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level:
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 K7WpErLe-7Q6 for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 07:56:48 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id ABD5D21F8582 for <sidr@ietf.org>; Sat, 9 Jul 2011 07:56:48 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <randy@psg.com>) id 1QfYxa-0002RV-07; Sat, 09 Jul 2011 14:56:46 +0000
Date: Sat, 09 Jul 2011 23:56:44 +0900
Message-ID: <m2tyavijtf.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Robert Raszuk <raszuk@cisco.com>
In-Reply-To: <4E17646A.1050600@cisco.com>
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> <4E17646A.1050600@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: sidr@ietf.org
Subject: Re: [sidr] IXP and Route Server and Next Hop transparency
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Sat, 09 Jul 2011 14:56:49 -0000

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

considering next hop likely changes at AS boundaries (and for some ops
practice, within the AS), how and why would one sign it?  e.g. at the
boundary between A and B, why bother having A sign it across what should
be a trustable boundary.

and, if A did sign it, and B changes the next hop when handing the
update on to C, A's signature just got farbled.

so bottom line, imiho, what's the need, and doing it would break things.

randy