Subject: [sidr] comments on draft-rogaglia-sidr-multiple-publication-points-00

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jul 2012 14:16:04 -0400

I'm in favor of a doc that describes ways for CAs to take advantage of 
multiple publication points for RPKI data, but I have a number of 
comments on the specific proposals in this doc.  See the attached file for
edits and comments.

Steve

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 18 Jul 2012 08:29:24 +0000

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".

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, 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.

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.

Regards,
Roque

On Jul 17, 2012, at 8:16 PM, Stephen Kent wrote:

> I'm in favor of a doc that describes ways for CAs to take advantage of multiple publication points for RPKI data, but I have a number of comments on the specific proposals in this doc.  See the attached file for
> edits and comments.
> 
> Steve
> <draft-rogaglia-sidr-multiple-publication-points-00.pdf>_______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jul 2012 11:47:10 -0400

Roque,

> (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 Publicatio…
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) The idea is that the different FQDN: rpki.operator1.org, rpki.operator2.net resolve respectively to IP1 and IP2 addresses. So, those two addresses are recommended to be covered by different…
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 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 k…
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.

Steve

---

From: Terry Manderson <[email-masked]>
Date: Wed, 18 Jul 2012 17:51:22 -0700

Roque and Steve,

Firstly I think that the ability to specify multiple repositories for the
TAL is warranted. 

I spent some time 6 months ago thinking this through and circulated a rough
format that was:

3 ; rsync://rrs.me.org/TA/root.cer ; rsync://rrs.friend.net/TA/root.cer ;
rsync://rrs.them.com/TA/root.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB

So very similar to what you propose, the only semantic difference is that
the number of locations is provided. That has varying degrees of mileage
depending on your point of view.

I see the multiple locations in the TAL as the 'avoidance' on any circular
or even single dependencies of protocol, DNS name->IPvX address, and routing
domain. (irrespective of how the service provision is constructed those are
the three basic building blocks)

In looking at the TAL contents, should more URIs be added the premise must
be that they are all equal in the eyes of the publisher. The relying party
then may make their own decision. But I would suggest that only one URI
selection REOMMENDATION be provided, ie 1) by the closest (RTT) location, 2)
protocol preferece (if HTTP makes it there), 3) order of the TAL. or
whatever the WG decides if this item is adopted.

I also see that you seem to be (section 4) updating the SIA interpretation
in RFC6487, the SIA ordering suggests:

"The ordering of URIs in this accessDescription sequence reflect the CA's
relative preferences for access methods to be used by RPs, with the first
element of the sequence being the most preferred by the CA."

I don't mind if you update it, but the ruleset changes from the ordered
preference by the SIA publisher, to one enacted by the relying party.

While I think that its nice to say that IP addresses are covered by ROAs - I
don't see that as something that is a must as it might be a hindrance down
the road and wouldn't that in itself be a circular dependency?

At the time I thought over this I promised to write some text about it after
publication of the RFC (RFC6490), I didn't - so I am supremely glad you
have! :-)

One of the reasons that I didn't make any exerted efforts to put pen to
paper is that I kept coming back to this paragraph in 6490

   The TAL is analogous to the TrustAnchorInfo data structure [RFC5914]
   adopted as a PKIX standard.  That standard could be used to represent
   the TAL, if one defined an rsync URI extension for that data
   structure.  However, the TAL format was adopted by RPKI implementors
   prior to the PKIX trust anchor work, and the RPKI implementer
   community has elected to utilize the TAL format, rather than define
   the requisite extension.  The community also prefers the simplicity
   of the ASCII encoding of the TAL versus the binary (ASN.1) encoding
   for TrustAnchorInfo.

Should we revisit this and form the appropriate PKIX extensions? If not, why
not?

Cheers
Terry

On 19/07/12 1:47 AM, "Stephen Kent" <[email-masked]> wrote:

>> 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".
>> "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,
>> 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.
>> (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.
> _______________________________________________
> sidr mailing list
> [email-masked]

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 19 Jul 2012 08:20:00 +0000

Hi Steve,

Please see inline.

Roque

On Jul 18, 2012, at 5:47 PM, Stephen Kent wrote:

Roque,

Hi Steve,

(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:

(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

(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

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 19 Jul 2012 08:48:52 +0000

Terry,

Please see inline.

Roque

> Firstly I think that the ability to specify multiple repositories for the

(Roque) ok.

> I spent some time 6 months ago thinking this through and circulated a rough

(Roque) Good, I was not aware.

> depending on your point of view.

(Roque) We can discuss the particular semantic. 

> whatever the WG decides if this item is adopted.

(Roque)That is what we are proposing in section 3.2 

> preference by the SIA publisher, to one enacted by the relying party.

(Roque) As you mentioned, I am in favor on moving the decision to the RP. This may mean updating RFC 6487 if the WG decides.

> So, probably we need to do somethingAt the time I thought over this I promised to write some text about it after

(Roque) I do not think so. The WG analyzed and dropped the CMS proposal already.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2012 10:17:52 -0400

Terry,
> aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB
I recall.
> be that they are all equal in the eyes of the publisher.
why do you say that? it seems like an arbitrary assertion. Why not allow
a TA to assert preference through ordering?
>   The relying party
> then may make their own decision.
RPs are always allow to do that :-) .
>   But I would suggest that only one URI
I'm in favor of making a recommendation, and noting other options
available to RPs.
> preference by the SIA publisher, to one enacted by the relying party.
I'm in favor of retaining the current interpretation.
> publication of the RFC (RFC6490), I didn't - so I am supremely glad you
Thanks go to Roque.
> Should we revisit this and form the appropriate PKIX extensions? If not, why
I think the simple answer is that developers of RP software, and 
putative TAs, seem
to like the very simple TAL format. However, if we make changes that 
cause that format
to become more complex, we might want to revisit the question. If so, 
then I would
recommend using one of the formats in 5914.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2012 10:55:36 -0400

Roque,

> (Roque) I believe the issue with RFC6487 is what "single" means when 
> in Section 4.8.7 says: "single reference to thepublication point of 
> the immediate superior certificate".
>
I agree that 6487 is ambiguous re the cited text. My point, however, is 
that it is not appropriate to say that 6487 did something wrong when it 
imposed further restrictions on what 5280 says. That's what a profile 
often does.

> (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.
Anycast is not intrinsically a TCP service; it is an IP layer service. 
My question is whether a CA might use an anycast address for access to 
publication points, and if so, how would this relate to you proposal to 
check that all pub point addresses were not covered by a set of ROAs 
associated with the CA. But, I'm willing to defer that question for now.
> (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.
yes, you could do that, but is it necessary? In what other contexts, 
where high availability is required, do we define this many ways to 
ensure user access to published data?

Steve

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Jul 2012 17:29:50 +0100

> Firstly I think that the ability to specify multiple repositories for the

could you explain a bit why?  [not implying i have a strong opinion, but
am curious]

thanks.

randy

---

From: Terry Manderson <[email-masked]>
Date: Sun, 22 Jul 2012 18:25:02 -0700

> could you explain a bit why?  [not implying i have a strong opinion, but

My feeling is that when the RPKI reaches a level of use driven by BGPSEC
adoption (ubiquity?) the frequency of fetching the TA listed by the TAL (or
TALs) from the volume of relying parties will be of a level that suggests
more than just a little ad-hoc engineering. I think it is sensible to then
have just enough (but not too much) flexibility in the shape of the cogs to
allow engineering options, which may include heterogeneity of repository
construction and location. It would be nice (I think) to have this available
before it's needed.

Cheers
Terry