[sidr] ROA management recommendations for users

Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> Thu, 15 September 2011 22:03 UTC

Return-Path: <carlosm3011@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 6EBA521F869E for <sidr@ietfa.amsl.com>; Thu, 15 Sep 2011 15:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZCSXY3PM90jU for <sidr@ietfa.amsl.com>; Thu, 15 Sep 2011 15:03:10 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20E21F85B9 for <sidr@ietf.org>; Thu, 15 Sep 2011 15:03:10 -0700 (PDT)
Received: by fxd18 with SMTP id 18so1186902fxd.31 for <sidr@ietf.org>; Thu, 15 Sep 2011 15:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=hej0Gy3eBPSiWkUyzygL2ibZp/997QpnGFWl5Gddt50=; b=Z5TPN/yElSfEduutHaYnyG9o1F/K1TLdMDkM8ulvMK++HDSwEQDT8wMYIGPPkO7r/I EZ2p18hAzechrPIP8YtIToe8xU1RLaxcMLH6bFC1WP60p9hgI/E3zfEpoqUgOFlDYMCU SD2iRoFAg3BWSCgfFdBk//BgU3/bul7dP3tLg=
MIME-Version: 1.0
Received: by 10.223.33.145 with SMTP id h17mr1240160fad.130.1316124322608; Thu, 15 Sep 2011 15:05:22 -0700 (PDT)
Received: by 10.152.14.2 with HTTP; Thu, 15 Sep 2011 15:05:22 -0700 (PDT)
Date: Thu, 15 Sep 2011 19:05:22 -0300
Message-ID: <CA+z-_EViJv72KMbZNhAodftYBhJWdWXLBFZvD8uGB+Avh-Ae1A@mail.gmail.com>
From: Carlos Martinez-Cagnazzo <carlosm3011@gmail.com>
To: sidr@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [sidr] ROA management recommendations for users
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: carlos@lacnic.net
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: Thu, 15 Sep 2011 22:03:11 -0000

Hello,

I am working on a presentation giving some recommendations for RPKI
early adopters. I want to provide some guidelines on how they should
go about creating their ROAs, and I would love to receive some input
from this list.

Broadly speaking, and looking at what people have created in the
repositories so far, there seem to be two different views on the
matter:

- ROAs that mirror BGP announcements and/or block de-aggregation within networks
For example, an organization with as 100  holding 10.1/16 and having
sub-allocated 10.1.128/18 to as 200 creates something like this:

ROA #1: 10.1.0/17-18, 10.1.192/18-18 origin-as 100
ROA #2: 10.1.128/18-18 origin-as 200

- ROAs that protect all the way to /32 (in IPv4)

Using the same example as above, they would have:
ROA #1: 10.1/16-32 origin-as 100
ROA #2: 10.1.128/18-32 origin-as 200

Your input and thoughts are much appreciated!

Warm regards,

Carlos

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================