Re: [sidr] is a longer announce invalid or not found?

Randy Bush <randy@psg.com> Fri, 30 September 2011 20:37 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 E23F821F8BAD for <sidr@ietfa.amsl.com>; Fri, 30 Sep 2011 13:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level:
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWyxO3xz+jd3 for <sidr@ietfa.amsl.com>; Fri, 30 Sep 2011 13:37:59 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 76B3221F8BAA for <sidr@ietf.org>; Fri, 30 Sep 2011 13:37:59 -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 1R9jt8-00033n-0B; Fri, 30 Sep 2011 20:40:54 +0000
Date: Sat, 01 Oct 2011 05:40:53 +0900
Message-ID: <m2mxdlsqzu.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se>
References: <m2d3eilpnq.wl%randy@psg.com> <20110930101754.GB10004@juniper.net> <m2ehyytj2l.wl%randy@psg.com> <20110930122831.GA10176@juniper.net> <m2bou2t7x5.wl%randy@psg.com> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <m2sjndsrs5.wl%randy@psg.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se>
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" <sidr@ietf.org>
Subject: Re: [sidr] is a longer announce invalid or not found?
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, 30 Sep 2011 20:38:00 -0000

>> then create the subsidiary cert, ee cert, and roa for them.  you will
>> then have two certs,
>>   10.0.0.0/16-16
>>   10.0.66.0/24-24
>> 
>> i call this the lazy customer.  they probably pay me to one or more of
>> provision the circuit, configure their cpe, ...  i might as well
>> provision their certs and roa.
> 
> Will you sign his announcement too?

no, because we are talking origin validation, not bgpsec

> If he doesn't implement sidr on all his routers yet, he will not sign
> his announcements.

first, 'sidr' is highly ambiguous.  sidr is documenting three main
technologies, rpki, rpki-based origin validation, and bgpsec.  we were
discussing the first two.

second, origin validation and bgpsec can be partially deployed within an
operator.  this is one of the reasons they are blended into local
policy, and do not force policy upon the operator.

third, a (let's assume dual homed) leaf site does not have to do much
for bgpsec.  their upstreams validate, so they do not have to.  all they
have to do is sign their announcement.  we refer to this as a 'simplex'
site, they announce signed but do not accept signed data, do not hold
any key or cert other than their own, ...  cool result is that current
leaf site hardware could do this, no upgrade.  so, for my simplex lazy
customer, yes i gen the bgpsec router key for them, and they or i stuff
it in their router.

randy