Hi Sriram, 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?.
If the super-block does not enclose the announced prefix but there is an incorrect origin AS, you cannot easily decide about the primary reason for the invalidation (i.e., whether the ROA has been created without considering sub-allocations or the origin AS has been announced by mistake). 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. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:[email protected] .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Wed, 7 Dec 2011, Sriram, Kotikalapudi wrote: > >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. > > Alex, > > 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. > http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-13#section-3 > > As for education, the origin-ops document as well as the use-cases > document (Sections 3, 7) > http://tools.ietf.org/html/draft-ietf-sidr-usecases-03 > can be referred. > > Sriram > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
