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

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Thu, 08 December 2011 13:26 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 53ED821F893C for <sidr@ietfa.amsl.com>; Thu, 8 Dec 2011 05:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 HNkBzIq8lfXW for <sidr@ietfa.amsl.com>; Thu, 8 Dec 2011 05:26:54 -0800 (PST)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 937D521F8A62 for <sidr@ietf.org>; Thu, 8 Dec 2011 05:26:54 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 8 Dec 2011 08:26:36 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 8 Dec 2011 08:26:42 -0500
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Matthias Waehlisch <waehlisch@ieee.org>
Date: Thu, 8 Dec 2011 08:26:00 -0500
Thread-Topic: [sidr] A quick note from RPKI in the wild
Thread-Index: Acy1Ytl/0kYQangnQEOQqSlPD7aJVAAQQWik
Message-ID: <D7A0423E5E193F40BE6E94126930C49308EE1E84C1@MBCLUSTER.xchange.nist.gov>
References: <F88C726A-DB3E-452D-9906-67B84F9B19C8@ripe.net> <D7A0423E5E193F40BE6E94126930C49308EEE3BB2A@MBCLUSTER.xchange.nist.gov>, <Pine.WNT.4.64.1112072138260.8356@mw-PC>
In-Reply-To: <Pine.WNT.4.64.1112072138260.8356@mw-PC>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] A quick note from RPKI in the wild
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 08 Dec 2011 13:26:55 -0000

Hi Matthias:

Thanks. My responses inline.

Sriram
________________________________________
>From: Matthias Waehlisch [waehlisch@ieee.org]
>Sent: Wednesday, December 07, 2011 11:36 PM

 >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.

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. 

>Anyhow, for the measurements we presented last IETF, 80% of the
invalid announcements are due to invalid origin ASes. The remaining 20%
are due to obvious MaxLength violation (i.e., same origin AS in BGP
update and ROA, but longer prefix length in BGP update). Regarding the
announcements with incorrect origin AS, for approx. 85% of these BGP
updates there exists at least one ROA with a longer MaxLength value
compared to the prefix length announced (i.e., the ROA encloses the
incorrectly announced prefix). ... Maybe it makes sense to investigate
this case in more detail. For example, looking if there is a direct
peering between the ROA origin AS and the origin AS within the BGP
update.

KS: Exactly. That is the info I was requesting. Well, it may not be
just the directly peering ASs that you look for. 
There can be customer's customers, etc.
That is, children, grand children, great grand children kind of sub-allocations
each with its own AS. Please see Slide 8 of this presentation 
http://www.ietf.org/proceedings/82/slides/sidr-2.pdf  
for measurements on customer cone structure
(i.e., # prefixes originated vs. their depth in AS path length) 
for several real ISPs.

Sriram