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

["Sriram, Kotikalapudi" <[e-mail]>]

Hi Matthias:

Thanks. My responses inline.

Sriram
________________________________________
>From: Matthias Waehlisch [[e-mail]]
>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