Re: [sidr] Master thesis - RPKI

Demian Rosenkranz <drosen2s@smail.inf.h-brs.de> Fri, 17 January 2014 12:30 UTC

Return-Path: <drosen2s@smail.inf.h-brs.de>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C731AE093 for <sidr@ietfa.amsl.com>; Fri, 17 Jan 2014 04:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level:
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQc4DpF52lZ9 for <sidr@ietfa.amsl.com>; Fri, 17 Jan 2014 04:30:12 -0800 (PST)
Received: from ux-2s11.inf.fh-bonn-rhein-sieg.de (ux-2s11.inf.fh-bonn-rhein-sieg.de [194.95.66.8]) by ietfa.amsl.com (Postfix) with ESMTP id 298F41AE097 for <sidr@ietf.org>; Fri, 17 Jan 2014 04:30:12 -0800 (PST)
Received: from [192.168.14.106] ([62.153.176.78]) (authenticated bits=0) by ux-2s11.inf.fh-bonn-rhein-sieg.de (8.14.4/8.14.4/Debian-4ska0) with ESMTP id s0HCTvSj003205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <sidr@ietf.org>; Fri, 17 Jan 2014 13:29:58 +0100
Message-ID: <52D92241.9070401@smail.inf.h-brs.de>
Date: Fri, 17 Jan 2014 13:29:53 +0100
From: Demian Rosenkranz <drosen2s@smail.inf.h-brs.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "sidr@ietf.org" <sidr@ietf.org>
References: <52D3FE0B.1080808@smail.inf.h-brs.de> <24B20D14B2CD29478C8D5D6E9CBB29F678F1DE97@HSV-MB002.huntsville.ads.sparta.com> <5d0fd135e7b94f38836297f58bca92fd@BLUPR09MB053.namprd09.prod.outlook.com> <52D562AA.3090309@smail.inf.h-brs.de> <117b37a9b60e4417b41381ebdde53414@BLUPR09MB053.namprd09.prod.outlook.com>
In-Reply-To: <117b37a9b60e4417b41381ebdde53414@BLUPR09MB053.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Auth: by SMTP AUTH @ ux-2s11
X-MIMEDefang-Info-ge: Gescannt in Inf@FH-BRS, Regeln s. MiniFAQ E-Mail/Mailscanner
X-Scanned-By: MIMEDefang 2.73
Subject: Re: [sidr] Master thesis - RPKI
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Jan 2014 12:30:15 -0000

Comments below.

Am 15.01.2014 18:22, schrieb Sriram, Kotikalapudi:
>> From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Demian Rosenkranz
>>
>> Correct, Im talking about really short lifetimes for ROAs (EE certificates). The
>> RP software would be forced to cryptographically checks the objects again
>> and again over short intervals.
>> But long lifetimes for ROAs (EE certificates) mean at least bigger CRLs.
>> This would be one benefit of short lifetimes.
>>
>
> Even if about a few hundred origination-change events occur in a year that require
> ROA-EE-certificate rollover, you are dealing with an increase of merely just that many
> additional entries in the CRL (with the long-lifetime ROAs and revocation approach).
> If instead short lifetimes are used, then 500,000 certs and ROAs would be propagated
> in the RPKI system periodically in each of those short intervals.
> The latter seems to be a much bigger price to pay.
OK, thats right!

> But if you can provide further analysis and insight in your thesis,
> it would be very welcome.
Unfortunately, I'm writing my thesis in German but I would be happy to 
get feedback from the users of this mailing-list. So, I try to keep you 
updated with the most significant results!

>
> We discussed and quantified these types choices and trade-offs earlier
> not in the context of ROA (EE cert) lifetimes, but in the context
> of AS or router key rollover mechanisms to mitigate BGPSEC update replay attacks.
> Please see:
> http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-02
> http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-02
Thank you for this information!

>
> Sriram
>
>
>