Chris, I have read the document and feel that the work is worth pursuing in the WG. Support adoption. Willing to contribute and review going forward. For now, I have some comments for the authors below.
Dear authors: Some of my questions/suggestions may be better handled with a face-to-face conversation possibly in Montreal. 1. FWIW, there is precedence regarding the idea of generating prefix filters based on RPKI/ROA information; see Appendix C in https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-08 . There, we also speculated on different ways of obtaining the AS cone. A somewhat related idea of an extended ROA was discussed during BGPsec design; see list item #3 in Section 6.5.2 of RFC 8374 - https://tools.ietf.org/html/rfc8374 . The idea was that the stub AS's (who is also owner of prefix(es)) upstream AS is also included in the extended ROA in addition to the stub AS. It was not pursued because at that time there was reluctance to add more RPKI objects. I feel it is worth exploring freshly the idea of a signed object that includes P2C peering info so customer AS cones can be constructed. 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). 3. The draft currently does not mention anywhere (based on my one read through) that AS cert is used to sign the AS cone object. I think an EE cert will be created from the AS cert and the EE cert will be used to sign the new RPKI object in question (similar to how ROAs are signed). 4. Consideration needs to be given to special cases, e.g., what happens if a neighbor AS is a customer in one region and a peer in another region (hybrid relations). 5. The draft seems to say "network" in some places where "AS" is meant. Prefixes are normally referred to as "networks" or subnets. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
