Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 15 Feb 2017 19:31:06 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-delta-protocol-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.4.1, 3rd paragraph: In a number of other protocols, a "User-Agent"
header can be used for implementation fingerprinting, so that an attacker
can guess what vulnerabilities might exist in that instance. Is that a
concern here?

- 3.5.3.2, 2nd paragraph: The MAY sounds more like a statement of fact
than permission.

- 5.2, 2nd paragraph: The RECOMMENDED sounds like a statement of fact as
worded.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 16 Feb 2017 15:31:03 +0100

Dear Ben, all,

> On 16 Feb 2017, at 04:31, Ben Campbell <[email-masked]> wrote:
> 

TL;DR:

This is not strictly required by the delta protocol and can be taken out if big concerns exist. But I believe that this will help with operational planning of changes in RPKI standards. I do not see big security concerns - obviously if I did I would not have insisted to my co-authors that we should have this :)

Longer:

The "User-Agent" was introduced here solely to help capability tracking that may help in operations of *other* changes in the RPKI standards.

For example: validation-reconsidered introduces new OIDs that when present will lead to current RPs rejecting objects that use them. If this happens at the trust anchor level that can be problematic. Because of this, the reconsidered document includes an intended timeline where RP software MUST be updated with this capability before CAs MAY use this. A timeline is one way to do this, but being able to also actually track if updated RP software is really deployed is useful.

Similarly capability tracking can help with other (currently unplanned) changes in the RPKI: new object types, or changes to existing ones. And it can help if we ever need to do an algorithm roll-over, e.g. to elliptic-curve instead of RSA - then again knowing which proportion of RPs supports the new algorithm can help.

On the other hand I do not see a huge security concern with this because even though Repository Servers would know which version of RP software is deployed where, they would not be able to attack them easily because RPs can normally be contacted only inside the trusted network where they are operated: e.g. routers using rpki-rtr.

> - 3.5.3.2, 2nd paragraph: The MAY sounds more like a statement of fact

yes, but whether the files *are* cached is a choice, so I thought a normative MAY was in order. I don't particularly mind changing this though, because I don't think it will lead to ambiguity.

> - 5.2, 2nd paragraph: The RECOMMENDED sounds like a statement of fact as

I am not sure that I understand your comment.

We RECOMMEND that RP software polls the Update Notification File for changes. We believe that is useful to mention here because new implementations may find it useful and it sends a message to Repository Servers that they should be prepared to deal with this.

However, another strategy can also be used. For example the current RIPE NCC RPKI Validator will actually re-trigger a complete validation process every X (configurable) minutes and then try to fetch updates. This works, but is somewhat resource intensive for the RP.

Would it be better if we did not RECOMMEND, but rather said something like this?

RPs MAY poll the Update Notification File for changes, so that a potentially resource intense RPKI validation process can be avoided if there is no new content available.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 16 Feb 2017 16:50:36 -0600

Hi, thanks for the response. Please see comments inline.

Thanks!

Ben.

On 16 Feb 2017, at 8:31, Tim Bruijnzeels wrote:

>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> This is not strictly required by the delta protocol and can be taken 
> out if big concerns exist. But I believe that this will help with 
> operational planning of changes in RPKI standards. I do not see big 
> security concerns - obviously if I did I would not have insisted to my 
> co-authors that we should have this :)
>
> Longer:
>
> The "User-Agent" was introduced here solely to help capability 
> tracking that may help in operations of *other* changes in the RPKI 
> standards.
>
> For example: validation-reconsidered introduces new OIDs that when 
> present will lead to current RPs rejecting objects that use them. If 
> this happens at the trust anchor level that can be problematic. 
> Because of this, the reconsidered document includes an intended 
> timeline where RP software MUST be updated with this capability before 
> CAs MAY use this. A timeline is one way to do this, but being able to 
> also actually track if updated RP software is really deployed is 
> useful.
>
> Similarly capability tracking can help with other (currently 
> unplanned) changes in the RPKI: new object types, or changes to 
> existing ones. And it can help if we ever need to do an algorithm 
> roll-over, e.g. to elliptic-curve instead of RSA - then again knowing 
> which proportion of RPs supports the new algorithm can help.
>
> On the other hand I do not see a huge security concern with this 
> because even though Repository Servers would know which version of RP 
> software is deployed where, they would not be able to attack them 
> easily because RPs can normally be contacted only inside the trusted 
> network where they are operated: e.g. routers using rpki-rtr.

There is a mention in the security considerations that the repository is 
not trusted.

I recognize the risk is not high. Making User-Agent a SHOULD is not my 
favorite thing, but I'm not going to push the point. Do I understand 
correctly that RRDP is only defined for use with TLS? (Did I miss a MUST 
NOT use without TLS requirement)? If there's any chance of using this 
without TLS, then it might be worth a security consideration mention.

> yes, but whether the files *are* cached is a choice, so I thought a 
> normative MAY was in order. I don't particularly mind changing this 
> though, because I don't think it will lead to ambiguity.

My point is the fact people can do that is natural outcome of the fact 
the files do not change. You aren't offering permission so much as 
noting the possibility. But I will leave the choice to you.

> We RECOMMEND that RP software polls the Update Notification File for 
> changes. We believe that is useful to mention here because new 
> implementations may find it useful and it sends a message to 
> Repository Servers that they should be prepared to deal with this.
>
> However, another strategy can also be used. For example the current 
> RIPE NCC RPKI Validator will actually re-trigger a complete validation 
> process every X (configurable) minutes and then try to fetch updates. 
> This works, but is somewhat resource intensive for the RP.
>
> RPs MAY poll the Update Notification File for changes, so that a 
> potentially resource intense RPKI validation process can be avoided if 
> there is no new content available.

So this is was just a very pedantic NIT about the use of 2119 keywords, 
where the sentence makes it sound like the fact of the recommendation 
comes from some authority other than the sentence itself. But on 
re-reading it, I don't think it creates ambiguity. It's probably not 
worrying about.