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

Carlos Martinez-Cagnazzo <> Thu, 08 December 2011 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49E7321F8B20 for <>; Thu, 8 Dec 2011 12:01:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gvuH5WjQFOkv for <>; Thu, 8 Dec 2011 12:01:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3E25D21F8B14 for <>; Thu, 8 Dec 2011 12:00:54 -0800 (PST)
Received: by laah2 with SMTP id h2so103158laa.31 for <>; Thu, 08 Dec 2011 12:00:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=lOToqplEQriSF/uMIxJ+l1L7u6rRcR+yRNnKnKhF5lM=; b=ASLvsfmTaSsiJIEzk6s+7VzbSRub4SXboOoQiuF3P4aRZqjrG5phOufMLIs5XdR86s G7iot+mkez5KwVKllvfx2+YB/kqTJfNkAQjugUlocIqF4LDem5fys8erQ465NkfGVtE2 vcX4jZx9XE3cmcbtIWju9gTQ0Nh1mXUwWQqK8=
MIME-Version: 1.0
Received: by with SMTP id gb15mr3013633lab.9.1323374453219; Thu, 08 Dec 2011 12:00:53 -0800 (PST)
Received: by with HTTP; Thu, 8 Dec 2011 12:00:53 -0800 (PST)
In-Reply-To: <Pine.WNT.4.64.1112080951080.8356@mw-PC>
References: <> <> <Pine.WNT.4.64.1112072138260.8356@mw-PC> <> <Pine.WNT.4.64.1112080951080.8356@mw-PC>
Date: Thu, 8 Dec 2011 18:00:53 -0200
Message-ID: <>
From: Carlos Martinez-Cagnazzo <>
To:, Arturo Servin <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Thu, 08 Dec 2011 20:01:04 -0000

A few numbers we gathered with Arturo. After processing yesterday's
RIPE RIS dump from the PTT Metro Sao Paulo sensor, we detected

-  ~5300 invalid prefixes
- ~2800 valid prefixes

Out of the invalid prefixes we have:

- ~ 3100 invalids due to bad maxLen
- ~ 2200 invalids due to wrong origin AS

I fully agree with Alex that maxLen is currently badly misunderstood
by the community at large. A lot of work is badly needed in order to
improve this situation.

However, surprisingly enough, many people do not know which AS should
originate their own prefixes. Out of the collected data it looks like
large companies with operations in different countries are the "worst
offenders" in this case.

We have put online a little tool to play with this data:

The database is refreshed once a day (7 am GMT-2). All feedback is of
course welcome. Beware that it is pretty crude at this point and be
warned that it can blow up in your face without warning :-)

We are working on:

- including more queries
- allowing CSV downloads of result sets
- RESTful-like interface
- WHOIS interfacing for richer display

Warm regards,


On Thu, Dec 8, 2011 at 3:10 PM, Matthias Waehlisch <> wrote:
> Hi Sriram,
> On Thu, 8 Dec 2011, Sriram, Kotikalapudi wrote:
>>  >I'm not sure if I understand your quote correctly: Do you only
>> consider the case where the super-block encloses the sub-allocations
>> (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no
>> MaxLength violation, right?.
>> KS: No. I am taking about something different.
>> If ISP A (with AS A) creates a ROA for its super-block x.y.0.0/16
>> and its Customer B (with AS B) has a sub-allocation x.y.z.0/24 and
>> has NOT created a ROA yet, then the customer's announcement will be Invalid.
>> The same effect happens whether ISP A's ROA is:
>> {ROA: x.y.0.0/16, AS A} (w/o maxLength; defaulted to maxLength = 16)
>> or, {ROA: x.y.0.0/16, AS A, maxLength = 24}
>> or, {ROA: x.y.0.0/16, AS A, maxLength = 18}.
>> With any of the above ROAs, Cust. B's announcement is Invalid
>> because it doesn't have a ROA yet for its sub-allocation.
>  definitely agree.
>> KS: The BCP I quoted from origin-ops requires that ISP A MUST
>> register its ROA only after the customer sub-allocation ROAs
>> have been created (or, register all necessary ROAs simultaneously).
>> In the above example: ISP A can create a ROA for Customer B
>> along with its own ROA as follows:
>> {ROA: x.y.0.0/16, AS A} and {ROA: x.y.z.0/24, AS B}
>> That ensures that Customer B is not in trouble.
>> This is the bottom up approach for ROA creation.
>> Question is: Do the ISP's (or super-block owners) in your
>> measurement data seem to be compliant with said BCP.
>  My point was that it is not too easy to decide if the ISPs are
> compliant with the BCP. But I think I got your point: If the origin AS
> in the Update has (somehow) a *customer* relationship with the ROA AS it
> is more likely that the ISP's ROA creation is in violation of the BCP.
>  In our last IETF presentation, we identified for the incorrect origin
> ASes that there exists a ROA Origin that is 1 hop away (ignoring
> prepending) from the announced origin AS in 90% of the cases. Coming
> back to your question: Yes, most of the announcements are invalid
> probably due to the violation of the BCP but I will try to verify in
> more detail.
> Cheers
>  matthias
> --
> Matthias Waehlisch
> .  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
> .  Takustr. 9, D-14195 Berlin, Germany
> .. ..
> :. Also: ..
> _______________________________________________
> sidr mailing list

Carlos M. Martinez-Cagnazzo