On Tue, Sep 4, 2012 at 3:08 PM, Brian Dickson <[email protected] > wrote:
> > > On Tue, Sep 4, 2012 at 1:55 PM, Stephen Kent <[email protected]> wrote: > >> >> >>> Make-before-break is fully possible with exclusivity. >>> >> In the general case, the resources are transferred between two CAs, and >> these CAs need not be >> ISPs, e.g., they might be RIRs. So, before an ISP can issue ROAs for the >> newly-received INRs, >> the ISP has to have these INRs added to it's CA cert. If the parent of >> that CA was not the parent >> for the ISP that previously held the resources, then it too has to have >> the INRs in question added >> to its cert, and so on. Thus means that, in general, there will be more >> that one CA, at corresponding >> tiers of the RPKI, that will have the same INRs in their 3779 extensions. >> Equivalently, this means >> that some CA will have issued certs to two of its children, where the >> certs overlap (wrt the INrs >> being transferred). > > > > > Re-replying to focus on one specific, MAJOR deficiency: INR transfers (in the real world) vs limitations of RPKI (inherited from its use of 3779) cannot be reconciled with the scalability and security requirements for origin validation (and consequently BGPsec which presumes origin validation). > However, if there *is* a need for the old parents to cover the INR, then > the semantics are missing explicit hole-punching. > > Hole-punching is needed to disambiguate overlapping certs, so as to assure > RPs the uniqueness of INRs. > > A "hole" is the positively-asserted proven non-existence of permitted > matching INRs, and need to be "glued" to matching (covering) INRs wherever > INRs are delegated. > > Let me know if I need to go into more detail on "hole" semantics. > > (Holes are less common today than they were 15 years ago, but they are > still critical to any kind of resource validation methodology, to avoid the > entire hijacking issue.) > > Brian > Let us consider what 3779 is able to represent in terms of INR values. (As co-author, you should be familiar with this -- I'm just explicitly re-stating for everyone else.) It allows IPv4 or IPv6 (and/or v4/v6 representations within other AFI/SAFI types). For those types, it allows one or more prefixes and/or ranges. A prefix is X/N (where X is an IPv4 or IPv6 network, and N is the number of bits in the network portion of the address). A range is A-B where A and B are both addresses, and B>=A. RFC 3779 can only express positive assertions. This is the big problem, in the context of RPKI, when handling INR transfers. There is no way to correctly express INR transfers of subordinate address blocks, without drastic implications on either security, or on the ability to efficiently announce prefixes. Current IANA and IRR policies allow for the transfer (e.g. sale) of INRs between parties which are constituents of different IRRs, or between parties which are constituents of a single IRR. These policies allow for the transfer of INRs of flexible size, including subordinate blocks. The policies (rightly so) discourage unnecessary fragmentation of INRs. So, to make this issue easier to follow, lets take a fictional example (using RFC1918 space per standard practice a la example.com) and show the problem that results. Let's say someone had a right-to-use on 10.0.0.0/8. Now suppose they want to transfer (sell) a /24 out of this space, to an unrelated party. (Since binary trees don't have any particular affinity, the choice of /24 is both arbitrary and irrelevant for this example.) For illustrative purposes, suppose that it is 10.20.30.0/24. Regardless of how long the transfer takes to process, and how long it takes RP caches to sync up, at some point in the future, the RPKI needs to represent the "new world order". So, what ways does 3779 support encoding of both the original block (minus the /24), and the new block? The new block is easy - it is 10.20.30.0/24. The new owner could be in the same IRR, or a different IRR. The new owner would announce, in BGP (and BGPSEC), 10.20.30.0/24. What about the old block? It must be encoded in one of 4 ways: 1. 10.0.0.0/8 2. two ranges (10.0.0.0-10.20.29.255 and 10.20.31.0-10.255.255.255) 3. a bunch of prefixes (16 in total) of lengths 9 through 24 1. 10.0.0.0/12 2. 10.16.0.0/14 1. 10.20.0.0/20 2. 10.20.16.0/21 3. 10.20.24.0/22 4. 10.20.28.0/23 5. 10.20.31.0/24 6. 10.20.32.0/19 7. 10.20.64.0/18 8. 10.20.128.0/17 3. 10.21.0.0/16 4. 10.22.0.0/15 5. 10.24.0.0/13 6. 10.32.0.0/11 7. 10.64.0.0/10 8. 10.128.0.0/9 4. even larger number of prefixes that form any sort of binary decomposition of the above 16 prefixes However, the RP/RPKI rules mean that it is not possible to have the original owner advertise 10.0.0.0/8, if methods 2, 3, or 4 are used. On the other hand, restricting INR transfers to methods 2, 3, or 4, result in each INR causing the need for an additional (N-M) prefixes, if the original prefix length is M and the transfered prefix length is N. And lastly, if method 1 is used, it is impossible to prevent the original owner from producing an ROA that would validate, which covers the "transfered" INR. This creates a Hobson's choice: either accept the inability to protect against subsequent (accidental or malicious) hijacking of transfered INRs, or accept the need for routing table bloat. ===== ALTERNATIVES ===== There is an alternative - replace 3779, and the rules of inheritance in the RPKI, with something that supports "holes". What is a hole? The definitive assertion of the non-routeability (or non-ownership) of longer prefixes within a block. This would need to be "glued" onto a parent block, and remain attached to any delegation of a block containing the "hole". Prefixes shorter than the "hole" would be valid (e.g. an ROA with maximum prefix length < prefix length of enclosed hole(s)). Prefixes the same size or longer than the "hole" would be invalid. Neither a CA (delegation) nor an ROA would be permissible if it covered the range of a "hole" without including the explicit hole, or made permissible a routing announcement anywhere inside the "hole". Examples of "new world order" allowable ROAs of a hypothetical 3779-bis would be: 10.0.0.0/8 le 23 => would allow covering prefix 10.20.30.0/23 (which is shorter than 10.20.30.0/24) but not allow conflicting prefix 10.20.30.0/24 10.128.0.0/9 le 32 => has no overlap with the "hole" at 10.20.30.0/24 10.20.32.0/19 le 32 => has no overlap with the "hole" 10.20.31.0/24 le 32 => adjacent to, but no overlap with, the "hole" 10.20.29.0/24 le 32 => adjacent to, but no overlap with, the "hole" 10.20.0.0/16 le 23 => covers "hole", but only permits prefixes shorter than (covering) the "hole" In this alternate representation scheme, any necessary prefixes by either party could be registered (in RPKI) via ROAs, and announced, without presenting either a security risk to either party (of hijacking) or placing a burden on the global BGP table (of prefixes dictated by RPKI fragmentation of parent blocks of transfered INRs). The old owner could (continue to) announce 10.0.0.0/8. The new owner could announce 10.20.30.0/24. Nobody would have to worry about conflicting announcements of 10.20.30.0/24(or longer). The current RPKI scheme cannot represent this, because RFC 3779 cannot represent this. And as a consequence, it is impossible to encode in origin validation logic, so RPs are not able to enjoy the benefits. Until such a fix is implemented (in 3779, all the RPKI documents that incorporate 3779, and all the RP-related docs), the only reasonable conclusion is that these are fatal flaws (from the perspective of operators). Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
