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

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:waehlisch@ieee.org .. 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> 