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

"Sriram, Kotikalapudi" <> Wed, 07 December 2011 22:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13D1C11E808B for <>; Wed, 7 Dec 2011 14:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tj8K6zl0Df5f for <>; Wed, 7 Dec 2011 14:28:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6588D11E8073 for <>; Wed, 7 Dec 2011 14:28:49 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 7 Dec 2011 17:28:41 -0500
Received: from ([fe80::41df:f63f:c718:e08]) by ([]) with mapi; Wed, 7 Dec 2011 17:28:06 -0500
From: "Sriram, Kotikalapudi" <>
To: Alex Band <>, "" <>
Date: Wed, 7 Dec 2011 17:28:46 -0500
Thread-Topic: [sidr] A quick note from RPKI in the wild
Thread-Index: AcyzmYVobC6J6eNTRdORolgc0x0dDgBe9UnA
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
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: Wed, 07 Dec 2011 22:28:50 -0000

>By the latter group, 416 Route Origin Authorization (ROA) objects have been created, covering the equivalent of 230,000 /24 prefixes and 8,600 /32 IPv6 prefixes. 
>MaxLength in ROAs is sorely misunderstood, lots of education is needed there. Most leave the field blank, causing more specific announcements to be invalid.


Can you comment if (a) the more specifics are announced from the same AS as seen 
in the ROA, or (b) they are announced from a different AS (e.g., customer AS)?
If it is the latter, then even the ROA creation (for the less specific)
is possibly in violation of: 
"Before issuing a ROA for a super-block, an operator MUST ensure that
   any sub-allocations from that block which are announced by other ASs,
   e.g. customers, have correct ROAs in the RPKI." from the origin-ops doc. 

As for education, the origin-ops document as well as the use-cases
document (Sections 3, 7) 
can be referred.