Hi, thanks for the response. Please see comments inline.
Thanks!
Ben.
On 16 Feb 2017, at 8:31, Tim Bruijnzeels wrote:
Dear Ben, all,
On 16 Feb 2017, at 04:31, Ben Campbell <[email protected]> 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.
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.
- 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.
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.
- 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.
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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
