An attacker could announce 10.0.0.0/17 and 10.0.128.0/17. This is equivalent to announcing 10.0.0.0/16, so it must be INVALID.
10.0.0.0/16-16 means I can announce 10.0.0.0/16, but not 10.0.66.0/24. I would do this if I have sub-allocated 10.0.66.0/24 to my customer. My customer MUST publish an ROA for 10.0.66.0/24. If my customer does not support SIDR, then I MUST revoke my ROA for 10.0.0.0/16-16 and replace it with ROAs for 10.0.0.0/18-18 10.0.64.0/23-23 10.0.67.0/24-24 10.0.68.0/22-22 10.0.72.0/21-21 10.0.80.0/20-20 10.0.96.0/19-19 10.0.128.0/17-17 As I sub-allocate more, I must split it more. However, I could sub-allocate 10.0.666.0/24 to Randy and need split nothing :) -- Jakob Heitz. On Sep 30, 2011, at 7:35 AM, "Randy Bush" <[email protected]> wrote: >>>> my read of 10.0.0.0/16-16 is an exact match >>>> and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy >>>> terms ;-)) >>> yes. >> so why is it (per your previous example) 'invalid' then - >> since a exact match was requested and no exact match could be found >> it should be 'not found'. > > because we call it an attack. see all the specs. > >> if one wanted to match against the whole subtree then 10.0.0.0/16-32 >> shall be advertised and signed; > > almost the opposite. > >>> fwiw, i do not remember junos as having a policy term to express >>> 10.0.0.0/16-14 :) >> e.g. route-filter 10.0.0.0/14 prefix-length-range /14-/16 > > cool > > randy > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
