Re: [sidr] A quick note from RPKI in the wild

Tim Bruijnzeels <> Fri, 09 December 2011 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C72021F854D for <>; Fri, 9 Dec 2011 02:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.383
X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB35=0.431]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F+OQHvjihvA9 for <>; Fri, 9 Dec 2011 02:08:04 -0800 (PST)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1342]) by (Postfix) with ESMTP id 03C3021F8549 for <>; Fri, 9 Dec 2011 02:08:04 -0800 (PST)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <>) id 1RYxN3-0003JN-3l; Fri, 09 Dec 2011 11:08:02 +0100
Received: from ([]) by with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <>) id 1RYxN2-0005DX-Qa; Fri, 09 Dec 2011 11:08:00 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-1--626786697"
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Fri, 09 Dec 2011 11:08:00 +0100
Message-Id: <>
References: <> <> <> <> <> <>
To: Arturo Servin <>
X-Mailer: Apple Mail (2.1084)
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points: -3.7 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.4 SARE_UNSUB35 BODY: SARE_UNSUB35 -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071900370d1da53479df3d225741317166ee
Cc: "Sriram, Kotikalapudi" <>, "" <>
Subject: Re: [sidr] A quick note from RPKI in the wild
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Dec 2011 10:08:05 -0000


On Dec 8, 2011, at 11:58 PM, Arturo Servin wrote:
> I imagine then that it just warns that the roa does not match the routing table and it is up to roa-creator to figure out what the error is (the roa or the route).

Speaking for the implementation in the RIPE NCC hosted pilot service (managed CA hosted by us, UI in member portal), and validator....

On the portal page where members can manage their ROAs we also check the announcements that we see(*) for their certified address space, against their ROAs. Yes, this is a warning only. It is up to the member to make the judgement what is right and configure things accordingly. Note that our members can not, at this time, certify their own clients for part of their address space. So if a client of a member uses a prefix then it's up the member to ensure that the ROAs for this prefix are set up correctly.

Members can also subscribe to 'roa-alerts'. If they do they get a daily email about unknown and invalid announcements that we see for them. This is not real-time alerting of course. We're actually also thinking about that, but it would require a very different technical solution and we're focusing on other stuff first... at this stage I think this is mainly useful for members to make sure that their ROAs actually keep matching their announcements. Although if some rogue announcement is happening continuously it will show up. We have also received some feedback where someone mentioned: "oh... I forgot that we were doing that announcement there.. I'd better fix it..". I am not sure if that was based on the UI or the mailing though..

All this was added fairly recently so we actually have quite a lot of ROAs that were created before this functionality was there. We are planning to do a one-time mailing soon where we alert members to announcements invalidated by their ROAs. I am not keen on spamming people, but with thousands of announcements being invalidated, presumably largely because the ROAs are wrong -- not the announcements... I don't see operators trusting this. So, data quality and fixing this is important.

We also compare validated ROAs to the announcements we see in the new version of our validator. And yes, it's showing a *lot* of invalids. This is the RP side of course, so changing those ROAs is not really an option ;) We do provide knobs in the validator though to ignore ROAs for certain prefixes and add your own ASN, prefix, maxLength entries as though ROAs existed for them, but managing this doesn't scale to thousands... 

An official release announcement is scheduled for Tuesday, but it's already available for download, and your feedback is appreciated:


*: We use the 8-hourly aggregate of routes seen by RIS Route Collectors. Published here: