The RPKI Repository Delta Protocol (RRDP)
draft-ietf-sidr-delta-protocol-08
Yes
(Alvaro Retana)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 06 and is now closed.
Alexey Melnikov Former IESG member
(was Discuss)
Yes
Yes
(2017-03-14)
Unknown
Thank you for addressing my DISCUSS.
Alvaro Retana Former IESG member
Yes
Yes
(for -06)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -07)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2017-02-15 for -07)
Unknown
- 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.
Benoît Claise Former IESG member
No Objection
No Objection
(2017-02-16 for -07)
Unknown
Sue Harres' OPS DIR review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Status: Ready with NITS – Overall comment: Thank you for creating this draft that helps the SIDR RPKI repositories better. What I’ve checked (for OPS-AD/NM-ADs): Check texted, updates to other protocols The details are belowl Sue Hares ------------------------ Editorial NITS list: Overall –comment: Each of these nits has a sub-status a) Really needed – confusing – the document suffers from being confusing unless you fix it b) Style – your choice, but the style of the text made it a bit confusing c) Go Check – security section that is out of my depth as reviewer #1 comment, 3.3.2 Publishing Updates, p. 6 Status: really needed – confusing Why: You are describing the delta files and then the handling of the file is a different bullet. Please make it one format. Old:/ o This delta file MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely. o The format and caching concerns for delta files are explained in more detail in Section 3.5.3. / New: / o This delta file MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely. The format and caching concerns for delta files are explained in more detail in Section 3.5.3. / #2, comment, 3.3.2, Publishing updates, p. 6 #2 Status; really needed – confusing Why: you are describing the snapshot and then the file handling. It should be one bullet. Old:/ o The snapshot file MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely. o The format and caching concerns for snapshot files are explained in more detail in Section 3.5.2. / New/ o The snapshot file MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely. The format and caching concerns for snapshot files are explained in more detail in Section 3.5.2. / #3, comment, 3.3.2, Publishing updates, p. 6 Status: really needed – confusing Why: You are describing the notification files and then the file format. Old:/ o A new notification file MUST now be created by the repository server. This new notification file MUST include a reference to the new snapshot file, and all delta files selected in the previous steps. o The format and caching concerns for update notification files are explained in more detail in Section 3.5.1. / New: / o A new notification file MUST now be created by the repository server. This new notification file MUST include a reference to the new snapshot file, and all delta files selected in the previous steps. The format and caching concerns for update notification files are explained in more detail in Section 3.5.1. / #4 section 3.4.1:entire section Status: style/confusing Comment: The first paragraph is the description of how Relying Party (RP) when it learns about a valid certificate with a SIA entry for the RRDP protocol. The section does not make it clear. Easy fix: Old/this protocol as follows/ New/this protocol as follows:/ + indent each paragraph as part of list #5 page 8 section 3.4.2 –general comment Status: really-needed The last paragraph “RP SHOUD NOT Remove objects”, the sentences as follows: The RP could use additional strategies to determine if an object is still relevant for validation before removing it from its local storage. In particular objects should not be removed if they are included in a current validated manifest. If you suggest this, I suspect that all of you know what your implementations are doing. However, the specification is for other people who want to also implement this protocol or checks to this protocol. An example or a pointer to an example would be very useful. It does not break the protocol, so this did not rise to the level of “minor”. However it is piece of the specification you could tie down operationally. #6 page 14, section 3.5.3.3 – file format and validation Status: style/nice to have – makes it easier for reader. Old:/ Note that a formal RELAX NG specification of this file format is included later in this document. A RP MUST NOT process any delta file that is incomplete or not well-formed./ New:/ Note that a formal RELAX NG specification of this file format is included in section 3.5.4 in this document. A RP MUST NOT process any delta file that is incomplete or not well-formed. / #7 section 6, paragraph 3 status: Status: Please check with security person Paragraph: / Supporting both RRDP and rsync necessarily increases the number of opportunities for a malicious RPKI CA to perform denial of service attacks on relying parties, by expanding the number of URIs which the RP may need to contact in order to complete a validation run. However, other than the relative cost of HTTPS versus rsync, adding RRDP to the mix does not change this picture significantly: with either RRDP or rsync a malicious CA can supply an effectively infinite series of URIs for the RP to follow. The only real solution to this is for the RP to apply some kind of bound to the amount of work it is willing to do. Note also that the attacker in this scenario must be an RPKI CA, since otherwise the normal RPKI object security checks would reject the malicious URIs./ I’m really out of my depth to state how this works as security expert or As operational expert. It just raised questions of “oh really.. “
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -07)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2017-02-15 for -07)
Unknown
I’m not skilled in the art of RPKI, so perhaps I lack imagination, but I'm not understanding why these two SHOULDs aren't MUSTs. I'm not asking for a change, but if the document included explanations of why an implementation might not do the SHOULDs, some readers might thank you. The RP SHOULD add all publish elements to a local storage and update its last processed serial number to the serial number of this delta file. The RP SHOULD NOT remove objects from its local storage solely because it encounters a "withdraw" element, because this would enable a publication server to withdraw any object without the signing Certificate Authority consent. The RP could use additional strategies to determine if an object is still relevant for validation before removing it from its local storage. In particular objects should not be removed if they are included in a current validated manifest.
Stephen Farrell Former IESG member
No Objection
No Objection
(2017-02-16 for -07)
Unknown
3.5.1.3: hard-coding a hash algorithm again? Why is that a good idea? sha256 is the right hash to choose today, but having to rev the rrdp version to move to some other hash alg seems like a bad plan. I suggest you either add a "hashalg" attribute to the xml or else use a ni schemed URI for the value of the uri attribute (or something along those lines). Same thing in 3.5.3.3.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -07)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(2017-02-15 for -07)
Unknown
Thank you for this work, it is clear and well written. While I have never (ever) been enamoured by RSYNC, and I much prefer this direction on a personal level, the updates to the existing RFCs regarding RSYNC does two things. The first is it demotes RSYNC to 'just another access mechanism', and the second is it appears to remove the quality of a mandatory to implement retrieval mechanism. Am I reading that correctly? If this is intentional and has workgroup consensus so be it and onwards we move..