On Thu, Aug 30, 2012 at 1:17 PM, Christopher Morrow <[email protected] > wrote:
> On Thu, Aug 30, 2012 at 10:59 AM, Eric Osterweil > <[email protected]> wrote: > > > > On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote: > > > >> Eric, > >> > >> Perhaps what you are looking for is some text in an operations doc, > suggesting what > >> an RP can expect, depending on how it elects to interact with the > repository system, > >> maintain its local cache, etc. > > > > Actually, I was looking for some intuition/guidance for people in a > position to take a systematic look at how to implement the design. I'm not > sure which draft, or which section, etc. Basically, I'm trying to get > things worked out, but I keep having issues w/ ensuring that ingestion of > data by a process at (say) one router has something/anything to do with the > ingestion of the same thing at (say) another router. Consistency models > tell me what properties I can rely on at time t_0 at location r_0 vs time > t_1 at r_1, etc. Right now, I'm having a lot of trouble ensuring that > anything agrees with anything else in the Interwebz and I don't know if I > should just let that be the case, or there is some sort of consistency I > need to adhere to... > > > > right, for the whole system you want to know: > 'how long between ROA create and ROA-foo on router' > > I think what you really want (because across the whole of the realm > it's a 'simple' model, where inside islands there is potentially lots > more fudgery) is: > 1) 'how long from roa-create -> roa-at-all-ASNs' > 2) 'what model of timing makes sense for 'once a ROA is at a remote > ASN, how long before that data is available on 1 routing-device, then > all routing-devices in that realm' > 3) should this set of numbers apply to ALL objects in the RPKI > equally? or should some object types have different timing > requirements? > > -chris > > (using ROA as the unit, you could use CRL update, EE-cert, etc... 'one > item in the RPKI') > I think this extends out to the several kinds of "consistency" questions I have, as well. For example: There are a whole bunch of documents that detail bits and pieces of the RPKI, some of which have some ASCII-art showing parts of the system. However, there is a severe lack of detail on the things it is about, specifically IP prefixes (INRs) that are protected via the whole system. In fact, in the one document that I think should be most critical, on validating ROAs, there are almost no references to IP blocks, and what few there are get referred to either indirectly (via another RFC reference) or using inconsistent terminology. After reviewing the whole mess of docs, and following the mutual implicit or explicit cross-references, I have some questions that don't seem to have been answered by the docs (both the published RFCs and current I-Ds). (1) What is the presumed model for INRs themselves? Are INRs presumed to be exclusive, and allocations hierarchical (with the occasional instance of an entire allocation being handed off without being divided)? That is to say, is a given piece of address space (contiguous power-of-2 block) always under the exclusive control of one party, based on longest-match rules of IP routing? (I'm pretty sure that the existing assignment methods starting at IANA->RIRs is built entirely on exclusivity, modulo RFC1918 space.) (2) If INRs are meant to be exclusive, why does the RPKI not enforce that exclusivity? It appears, having looked at the docs in the context of grandparenting, that despite the assertion that validation is a top-down activity, it is fundamentally a bottom-up process (looking for an eventual match against a trust anchor). And, in essence, there is no requirement that INR "delegations" that occur at any given CA, need to be unique, which presumably contradicts the nature of INRs. (Note here - the presumption is not uniqueness by ASN, but uniqueness by organization controlling ROA assignment, where that single org could/would issue ROAs for multiple ASNs.) I believe that enforcing exclusivity of INR blocks within each CA's set of signed objects, is all that is needed to achieve global uniqueness. A CA's ROA(s) could be matched against delegations, requiring a zero-overlap, or alternatively modifying the ROA validation process to somehow disambiguate things. (3) If an ROA is issued by CA_1 for A.B.C.D/X (max length X+Y, Y>=1), and the same CA_1 also signs a delegation on A.B.C.D/(X+1) to CA_2, who issues an ROA for A.B.C.D/(X+1) (max length (X+1)+Y, Y>=0), that two parties are then legitimately able to originate (conflicting) BGP routes for A.B.C.D/X+1 - something that I doubt CA_2 would be happy about (even as a possibility, let alone an actuality). (4) ROAs appear to be "containers" for (possibly) multiple prefixes. Is it strictly necessary for every prefix in a ROA to validate properly, for a ROA to validate? Or, if not, how does that work for partial validity, prefix-by-prefix? (5) Everything in the validation and RPKI seems to be forward-lookup oriented from an ASN perspective. What about trying to look up information on a given prefix, if you don't have the ASN(s)? It seems like it would require an exhaustive search of every pub point under any published CA that contained a covering address for the prefix in question. Is that correct, and did anyone look at this originally when designing the RPKI? What if you have one ASN that you know is announcing a given prefix, but want to find out if any other ASN has a valid ROA which includes the same prefix (or covering prefix, or child prefix)? (6) What about an informational RFC to tie all the relevant bits together, e.g. with big ASCII-art diagrams, high-level text describing relationships, and pointers to detailed technical RFCs? Without this, trying to understand any of this, let along trying to implement, is rather unwieldy. (7) This also points towards the number of places the docs "punt" on critical issues. E.g. the question of INR->RPKI timing ("...is a side-effect...") is pretty vague. I also think the issue of "bogon" space could/should be addressed, so that unused space can not only _not_ be part of any ROA, but that unused space can authoritatively be excluded from routing tables via BGPSEC mechanisms. (There is no reason to wait for everyone to deploy BGPSEC to achieve this piece of low hanging fruit.) Since INRs are allocated top-down, Reserved space can trivially be authenticated and placed into a "black list" dynamically. Any comments, from anyone, on any of these, are welcome. Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
