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

[Tim Bruijnzeels <[e-mail]>]

Dear Ben, all,


> On 16 Feb 2017, at 04:31, Ben Campbell <[e-mail]> wrote:
> 
> 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?

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
> than permission.

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

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.