Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation

From: Terry Manderson <[email-masked]>
Date: Thu, 10 Sep 2009 07:21:15 -0700

On 10/08/09 4:42 PM, "Terry" <[email-masked]> wrote:

> 
> I don't see this an inventing problems. I think it is realizing that the
> mooted interpretation is going to go badly for some in anything but a complete
> deployment. I would prefer that we, as a working group, aren't putting forward
> something that is going to cause pain. I think there are enough hairy monsters
> surrounding this work already.
> 
> I'm currently putting together an analysis of this from the DFZ as to impact.
> I'll post again in a few days.
> 
> T.

It took me more than a few days to get back to this due to other
commitments.

I have created a origination map from my view of the BGP table (or DFZ if
that term doesn't offend you).

You will find a map from a recent bgp dump here:
http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20090909.1200.ht
ml

I have categorized prefixes I see as:
    Aggregate: the least specific prefixes seen
    Deaggregated: where the same AS that has the aggregate, originates more
specific prefixes
    Suballocated: where a different AS originates a more specific from a
aggregate or deaggregate prefix
    Sub-Suballocated: where a different AS originates a more specific from a
Suballocted prefix
    Sub-Sub-Suballocated: where a different AS originates a more specific
from a Sub-Suballocated prefix
    Sub-Sub-Sub-Suballocated: where a different AS originates a more
specific from a Sub-Sub-Suballocated prefix

the prefix tally is:
 147300 Aggregate
  92275 Deaggregated
  50125 Suballocated
   1420 Sub-Suballocated
     16 Sub-Sub-Suballocated
      1 Sub-Sub-Sub-Suballocated

If the WG maintains the idea that a ROA represents an implicit deny as
previously discussed - I believe in terms of a deployment of rpki, the
current interpretation represents a significant blocker.

Presuming what I see in BGP is a mostly accurate representation of intent,
all sub*allocated prefixes must have a valid ROA and (and obviously
certificate state) before any aggregate or deaggrgate prefix ROAs can be
issued. This is backward to the current top-down approach of resource certs
of IANA->RIRs->NIR|LIR->ISP->Multihomed-endsite. That is resource certs need
to be issued first, top-down, but ROAs (etc) need to created bottom up else
breakage will occur from routes being deemed invalid.

So a good 20% of the prefix's need to be issued ROA's before any trust
statements can be made about most of the aggregate prefixes.

To complete the analysis, the deaggregated prefixes could be covered by the
same ROA as the aggregate (except with maxLength tweaking) - but again could
not be created prior to any suballocated prefix' ROAs being created.

The alternate approach would be to create ROAs just for the 92275
deaggregates, provided they didn't have any suballocations (which many do)
or the suballocated prefix ROAs already existed.

Please SIDR-WG, consider a ROA to not have any deny interpretations or
implications to allow a soft deployment, in a sensible top down manner.

I'll come back to the WG in a few days, where "few" is in the range 1-100,
with some analysis that supports both AS0-ROA and, to larger extent, BOA due
to observations of unallocated/reserved AS numbers and prefixes.

Cheers
Terry
(the disclaimer applies that this analysis is based on what I see from just
one BGP peer)