Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)
Brian Dickson <brian.peter.dickson@gmail.com> Fri, 11 May 2012 21:27 UTC
Return-Path: <brian.peter.dickson@gmail.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 0D81321F86B3 for <sidr@ietfa.amsl.com>; Fri, 11 May 2012 14:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.523
X-Spam-Level:
X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 dlnElReZQeiR for <sidr@ietfa.amsl.com>; Fri, 11 May 2012 14:27:53 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFEB721F862F for <sidr@ietf.org>; Fri, 11 May 2012 14:27:52 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so2171582wgb.13 for <sidr@ietf.org>; Fri, 11 May 2012 14:27:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P6Unc8CzLPIQOCKlY5pUJ+z/q24hOJc4i0+hTAFIX1M=; b=trE3xV0R0afqngTrdM+cudUCG1gphjnIA8Ylt19tFZ6dqvTl5npiuNc63IVz088kvS F3pk1AiyrXa5buawwlMO+7nQ5l0SrKDyYa2ueIKU1bu/7g7O+mXpMnOExUei/gUKo3rX CIfmytqKqiro5mMTX5qEWDLAZiFqGxYRLX8nd6f8hAePRYd7R57s6DVWDYHobfURhmQw ikzkgFglYRuLN/eXQ9Z8xx9gHy699d8sew+wdCpBApe7MeOoiUIx0O8dfqzSaixOB8g7 PJvxoJWeilCDw9pCzc9wIQ6mQFBCJLzbwOfHh14Zw26/htDf5pP3yjNcWPTbkt5eS+kt tekA==
MIME-Version: 1.0
Received: by 10.180.83.196 with SMTP id s4mr4354167wiy.15.1336771672130; Fri, 11 May 2012 14:27:52 -0700 (PDT)
Received: by 10.223.93.138 with HTTP; Fri, 11 May 2012 14:27:51 -0700 (PDT)
In-Reply-To: <CAL9jLab0aSJBpQTtbNLq_qLbxwhXj7Y3-_aqZVeMPoTB5C8DTA@mail.gmail.com>
References: <CAH1iCiruThFzpef5u9NVt+3AokGnuFhq-GrbqEOkkKnVhav4zQ@mail.gmail.com> <CAL9jLab2XT-4NWr8KyHKOiQMTWqE5cTavmEr4Uw+S4zhrA=YLA@mail.gmail.com> <CAH1iCiq3so54pE9XBM5Bp13xaERbmShipmCg=ckEySiDsh5ZPQ@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B990A66A8@MBCLUSTER.xchange.nist.gov> <CAH1iCirMKm1TbtBzWSKy=vHGLdYHvbtnXcwO1G9aG00n3DXmyw@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B990A6710@MBCLUSTER.xchange.nist.gov> <D7A0423E5E193F40BE6E94126930C4930B990A6716@MBCLUSTER.xchange.nist.gov> <CABFLmSTVmEUMYZmXNkbhSac0_jb0o-2nPG2_58Si0SGmF0podA@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C4930B985DEF48@MBCLUSTER.xchange.nist.gov> <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> <CAH1iCio4_PaLFACs_cDZRV9c3iYhn93XqCrQrR5PD48bpyM3BA@mail.gmail.com> <CAL9jLab0aSJBpQTtbNLq_qLbxwhXj7Y3-_aqZVeMPoTB5C8DTA@mail.gmail.com>
Date: Fri, 11 May 2012 17:27:51 -0400
Message-ID: <CAH1iCioDW_mBWNyMy8K-jOrjdNqtnpQjdneSvWdRg0NWLNYV3w@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: multipart/alternative; boundary="f46d04428eeea9c3bf04bfc9680f"
Cc: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>
Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)
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, 11 May 2012 21:27:54 -0000
I was referring to the use of HW-based crypto (which is not cheap), not the timeframe (5-7 years), as having lack of quantitative analysis on cost/benefit, cost barrier to entry, or other supporting justification. The argument that "we can't do the crypto without HW" is circular, when the argument for crypto is "we can include the HW for crypto in the next go-around of HW". If crypto requires HW, the incremental cost needs to be considered, along with justification that shows that the market will accept and fully adopt HW crypto universally. The premise is bgpsec requires universal adoption to have end-to-end delivery of protection. The deployment scenario where anything less than the vast majority of ASNs do bgpsec, quickly devolves to negative cost-benefit. If the only parties deploying bgpsec are a closed set of peers who already trust each other and already do TCP-AO (aka MD5), the net benefit is zero. So, who is going to write up the cost benefit, deployment model (inter-as), and critical mass required document? Or the market analysis (how many routers with this will be needed), vendor survey with committed roadmap (when will this be available, on what platforms)? Or the export restrictions limitations to deployment (serious crypto hardware being deployed to the state-department listed countries?) and/or alternative vendor support? Basically, if the assumption is HW crypto, please go the extra mile and show that this assumption is based on verifiable "stuff", i.e. that this is not just fantasy. Brian On Fri, May 11, 2012 at 4:20 PM, Christopher Morrow <morrowc.lists@gmail.com > wrote: > On Fri, May 11, 2012 at 3:44 PM, Brian Dickson > <brian.peter.dickson@gmail.com> wrote: > > It has been proposed that a roadmap timeframe of 5-7 years is > acceptable, in > > order that vendors provide hardware-based implementations. No > justification > > for this has been offered, beyond "well, it is common sense". > > I believe the timeframes take into account common larger-network > depreciation rates for equipment. > core -> agg -> fastedge -> hinter-lands-edge -> gone > > takes ~4-7 years... or so network folk had said (this came out in the > RAWS WG as well, in 2006) > > -chris >
- [sidr] Keys and algorithms for Updates - feasibil… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Christopher Morrow
- Re: [sidr] Keys and algorithms for Updates - feas… Christopher Morrow
- Re: [sidr] Keys and algorithms for Updates - feas… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Sriram, Kotikalapudi
- Re: [sidr] Keys and algorithms for Updates - feas… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Ross.Anderson@cl.cam.ac.uk
- Re: [sidr] Keys and algorithms for Updates - feas… Sriram, Kotikalapudi
- Re: [sidr] Keys and algorithms for Updates - feas… Murphy, Sandra
- Re: [sidr] Keys and algorithms for Updates - feas… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Christopher Morrow
- Re: [sidr] Keys and algorithms for Updates - feas… Murphy, Sandra
- Re: [sidr] Keys and algorithms for Updates - feas… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Christopher Morrow
- Re: [sidr] Keys and algorithms for Updates - feas… Brian Dickson
- Re: [sidr] Keys and algorithms for Updates - feas… Christopher Morrow
- Re: [sidr] Keys and algorithms for Updates - feas… Ross.Anderson@cl.cam.ac.uk
- Re: [sidr] Keys and algorithms for Updates - feas… Christopher Morrow
- Re: [sidr] Keys and algorithms for Updates - feas… Montgomery, Douglas
- Re: [sidr] sidrKeys and algorithms for Updates - … Wes Hardaker