Hi all, Support adoption. I am willing to contribute ‘RPKI Signed Object’ and ASN.1 text - when the time comes and if desired.
In relation to Sriram’s remark: > On 25 May 2018, at 16:56, Sriram, Kotikalapudi (Fed) > <[email protected]> wrote: > > 2. I would prefer that the proposed new RPKI objects contain only a list of > immediate customers. >> From that (assuming mature state of deployment), the entire customer AS cone >> for > any AS can be constructed (recursively). > I see a major down side to including more than the list of immediate > customers. > The downside is that there could be too much churn in the RPKI. > If a customer drops or changes a transit provider, then there should not be > any ripple effects > in the RPKI propagating through all higher tiers. I think this rippling > effect is inherent > with the current proposal in the draft (as I understand it). Quick grepping in the RIPE Database IRR shows that about 15% of “members:” attributes in AS-SET objects references other AS-SET objects. This could be other people’s customers, or it could be shorthands (allowing easy re-use of a set of ASNs in different places). When it’s other people’s customers then it’s not clear to me whether the ASN that makes this reference would still appear in the PATH. In other words, could one not just stick to referencing ASNs only and recursively find the published ‘rpki-as-cone' for those ASNs? If only ASNs are used, I do believe that the object can be simplified and it would be much easier to reason about who signs what. There could be a single object per AS: Policy for AS-A To-upsteam: AS-X, send customers: AS1,2,3 To-upsteam: AS-Y, send customers: AS 4, 5 To-upsteam: AS-Z, send customers: none Signed AS-A (must appear on EE certificate in the RPKI Signed Object that contains this) And AS 1,2,3,4,5 would each have their own rpki-as-cone object. Unless I am missing something here (and please enlighten me if so), I think this would allow for building recursive lists of ASNs that may be seen on a session with a downstream AS, and ROAs and/or IRR objects could be used then to get the filterlists. At least that’s how I understand AS-SET objects to be used today (again, enlighten me if not.. still learning about hands-on operations). These objects could also be leveraged through a future rkpi-rtr extension and allow for: valid/invalid/unknown upstream|downstream hooks in router config. Meaning: 1) if a given AS-A did not publish an rpki-as-cone object, then both upstream and downstream ASNs would be UNKNOWN relative to this AS-A. 2) if a given AS-A published an rpki-as-cone object with AS X,Y, and Z as upstreams then AS-A->ASX/Y/Z in a path would be VALID, while AS-A->any other AS would be INVALID upstream 3) if a given AS-A published an rpki-as-cone object with AS 1,2,3 as customers to AS-X, then AS1/2/3->AS-A would be VALID where (AS-A->AS-X), and any other AS->AS-A here would be INVALID (undeclared customer for upstream) This would allow for semantics like: If (path contains INVALID upstream) or (path contains undeclared customer) or (origin invalid [ROA origin validation) then drop It would also allow for incremental uptake. Any AS can protect themselves a bit better by publishing a signed policy, but if you don’t then there is no difference from today. RPKI Validators can do the leg work for the crypto, so implementation in routers would require some memory and CPU, but nothing too drastic - similar to rpki-rtr and ROAs today. Tim _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
