On 8/10/12 3:40 AM, "Byron Ellacott" <[email protected]> wrote:
>Hi Doug, > >On 10/08/2012, at 3:46 PM, Montgomery, Douglas wrote: > >>> Substitute "ASm" for "AS0" in my example. >> >> You can not change a VALID route to any other state by creating >>additional >> valid ROAs. You have to delete (revoke, etc) the valid matching ROAs to >> achieve that. Creating a (covering) ROA can change an UNKNOW to an >> INVALID. > >You can change an INVALID route to a VALID route by creating a ROA for >it, though, and if C doesn't think G should be getting their traffic, >they could issue the ROA and announce the route and capture at least some >traffic. Agreed. > >> I would agree on a weaker statement, that we should discuss and come to >> some understanding about issues of consistency associated with >>overlapping >> attestations from multiple levels of the resource hierarchy and/or a >> single holder. The current syntax of our objects and validation >> algorithms allow considerable flexibility here. If, and where policies >> should curtail some of this flexibility is what we are discussing. > >I think that's a side discussion that might be interesting, but it's >orthogonal to a draft proposing certification that is for a purpose other >than authorisation of claims of current holdings. We're not talking >about attestations at multiple levels of the resource hierarchy with >grandfathering, we're talking about issuing certificates that are >intentionally not aligned with current holdings, to enable attestations >about resources to be made before the question of who the right holder is >has been resolved. > >This could possibly be resolved through section 4.9.4 of the CPS document >- a CA who wishes to allow themselves the flexibility to recognise a >claim to resources from a grandchild without immediately severing their >child could note that a grace period may be provided on revocation due to >resource holding changes on a case by case basis. This allows a >grandfathering approach where the CA updates the record of current >holding, but delays the revocation of the former holder while resolving >questions about who should be the current holder - but it does not, in my >view, solve the problem of getting packets to the right place, because >"the right place" is not known until the identity of the current holder >is known. > > Byron There seems to be a lot of assumptions in terms like "the right place". Are you suggesting that EE Certs/attestations for a given resource can only be made at the leaves of the allocation tree? What about attestations about aggregate routes at higher levels of the hierarchy? dougm _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
