Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server

Randy Bush <randy@psg.com> Fri, 08 July 2011 13:50 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 4798721F89B8 for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 06:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level:
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 TXXPCpBGIzYe for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 06:50:47 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A221F88F9 for <sidr@ietf.org>; Fri, 8 Jul 2011 06:50:47 -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 1QfBS9-000H7U-Fk; Fri, 08 Jul 2011 13:50:45 +0000
Date: Fri, 08 Jul 2011 22:50:44 +0900
Message-ID: <m2pqlklw3v.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Chris Hall <chris.hall@highwayman.com>
In-Reply-To: <014001cc3d74$319571c0$94c05540$@highwayman.com>
References: <012601cc3d54$8f07c4e0$ad174ea0$@highwayman.com> <m2y609kptw.wl%randy@psg.com> <014001cc3d74$319571c0$94c05540$@highwayman.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 wg list' <sidr@ietf.org>
Subject: Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server
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: Fri, 08 Jul 2011 13:50:48 -0000

>> i have a design that covers you.  it is based on an 'optimization'
>> and we have agreed to let optimizations sit for a bit.
> OK.  But I quibble with the notion that support for Route Servers
> should be treated as an "optimisation".

it is compressing prepends that is the optimization.  transparent route
servers are not an optimization, they're a hack.

>>   o an early optimization will be that each bgpspeaking AS adds
>>     a one byte prepend count, over which it signs.  this saves
>>     signing 92 prepends.  the count is normally one.
> 
> OK.  That clears up a confusion I had... I wasn't sure whether there
> was supposed to be one signature per ASN in the path, or one per
> *distinct* ASN in the path.  For my money, prepending is common enough
> to merit covering as a "feature.

prepending is supported in the current spec.  the problem is that there
is one signature per prepend, expensive.

>>   o a bgpsec-speaking 'transparent' route server signs over a zero
>>     prepend count.
>  
> That would be, as you suggest, less 'transparent' than it used to be.
> I don't know if "revealing" the use of the route server is a serious
> issue.  But I'm not sure how much is gained by inserting the route
> server ASN ?

maintaining bgpsec.  if A hands announcement to RS and RS hands to B and
C truely transparently, to whom does A forward sign the announcement, B
or C?  #faceplant

> It seems reasonable to me to treat the route server as an extension of
> its clients' networks -- that's pretty much what it is.  So, if the
> route server uses a different key for each client's routes, and the
> *client* is responsible for issuing the certificate (as if the route
> server were one of its routers), then that about covers it -- unless I
> am missing something ?

so, A has to know all the ASs to which RS will hand route, forward sign
announcements to each of them and hand all those to RS, and RS then
stores them all and forwards as appropriate.  that'll scale really well.

omg!  on reread it seems you are giving A's private key to RS.  not a
fracking chance in hell.  you just blew the trust model to hell.

>>   o bgpsec speakers calculate as path length by summing prepend
>>     counts.
> 
> Are you suggesting placing the prepend count in the AS Path itself ?

see slide 29 of https://archive.psg.com/110614.nanog-bgpsec.pdf

randy