Hi Steve, Please see inline.
Roque On Jul 18, 2012, at 5:47 PM, Stephen Kent wrote: Roque, Hi Steve, Thanks for your comments. I tried to extract the most relevant for discussion on text format. 1) Section 2: RFC 6487 limitation to multiple Repository Publication Points. Comment: "6487 says that, for AIA: In this profile, a single reference to the publication point of the immediate superior certificate MUST be present, …That RFC later says that it’s OK to have other types of accessMethods, which contradicts the earlier text. In any case, the latter text prohibits multiple instances of the same method (e.g., rynch) so …" (Roque) In summary, RFC 5280 allows multiple "accessMethod + accessLocation". However, RFC 6487 has the contradiction that you pointed out that would prevent not only multiple Repository Publication Points but also for the AIA to allow RSYNC + HTTP support (something we have commented in this list). Although we know that today the AIA has in practice little use, I think we would need to update RFC 6487 in the text to remove the reference to the "single reference". It's not a contradiction for 6487 to be more restrictive in this respect. 6487 imposes a number of restrictions relative to 5280. So, if we decide to change 6487 it should be because we decide that we need the flexibility, not because 6487 was inconsistent wrt AIA vs. SIA and CRLDP. (Roque) I believe the issue with RFC6487 is what "single" means when in Section 4.8.7 says: "single reference to the publication point of the immediate superior certificate". 2) Section 3: "In order to increase robustness, It is RECOMMENDED that a different FQDN could be resolved to IP addresses included in ROA objects from different CAs and hosted in diverse Repository Publication Points." Comment:"I can’t understand the latter part of this sentence." (Roque) The idea is that the different FQDN: rpki.operator1.org<http://rpki.operator1.org>, rpki.operator2.net<http://rpki.operator2.net> resolve respectively to IP1 and IP2 addresses. So, those two addresses are recommended to be covered by different ROAs, even administrated by different CAs. Again, the idea is to increase diversity and to avoid any sort of circular dependency. Good idea, but not well explained in the text. Also, this takes some effort, if the FQDN might resolve to multiple addresses and we have to check all of them against a set of ROAs. How would this work for an anycast address? (Roque) The idea is to foster diversity. So, you need to see the union of all IP addresses you are resolving to make sure that they do not all depends on one ROA. I am not sure about what do you meant by Anycast. This is a TCP service, so there are some load balancing technique that you can apply that are based on anycasting the DNS servers that resolve the domain name and have inconsistent zones around the globe but I am not sure that was your concern. 3) Section 3.2 "A RP can use different rules to select the URI from which to fetch the Trust Anchor certificate." Comment: "Is this a good recommendation?" (Roque) The idea here was to imitate the DNS behavior and let the RP to have their "secret sauce" to chose the operator. Normally what you want is to chose the closest one, that is why in DNS you keep track of the response time from the different servers. We already have the ability to use DNS for pub point diversity, as your text noted. I think it might be preferable to give CAs a different mechanism with more tightly-defined semantics to influence RP behavior re RPKI data retrieval when we introduce these additional mechanisms. (Roque) The problem that we were raising on depending on DNS based mechanisms for a single FQDN, is that you depend on that single FQDN resolution. With lets say two URI, you can set one operator to be one CDN and another operator to be a second CDN. Steve
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
