The RPKI Repository Delta Protocol (RRDP)
draft-ietf-sidr-delta-protocol-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-06-23
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-05-22
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-05-10
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2017-05-05
|
08 | (System) | RFC Editor state changed to REF from EDIT |
2017-03-30
|
08 | (System) | RFC Editor state changed to EDIT from MISSREF |
2017-03-16
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-03-16
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-03-15
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-03-14
|
08 | (System) | IANA Action state changed to In Progress |
2017-03-14
|
08 | (System) | RFC Editor state changed to MISSREF |
2017-03-14
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-03-14
|
08 | (System) | Announcement was received by RFC Editor |
2017-03-14
|
08 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-03-14
|
08 | Cindy Morgan | IESG has approved the document |
2017-03-14
|
08 | Cindy Morgan | Closed "Approve" ballot |
2017-03-14
|
08 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2017-03-14
|
08 | Alvaro Retana | Ballot approval text was generated |
2017-03-14
|
08 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS. |
2017-03-14
|
08 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss |
2017-03-13
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-03-13
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-03-13
|
08 | Oleg Muravskiy | New version available: draft-ietf-sidr-delta-protocol-08.txt |
2017-03-13
|
08 | (System) | New version approved |
2017-03-13
|
08 | (System) | Request for posting confirmation emailed to previous authors: Rob Austein , Tim Bruijnzeels , Bryan Weber , Oleg Muravskiy |
2017-03-13
|
08 | Oleg Muravskiy | Uploaded new revision |
2017-03-08
|
07 | Alvaro Retana | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation - Defer::AD Followup |
2017-03-02
|
07 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Orit Levin. |
2017-03-02
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer |
2017-03-02
|
07 | Chris Morrow | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a delta protocol which provides relying parties with a mechanism to query a repository for incremental updates, thus enabling the RP to keep its state in sync with the repository." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The WG process was as most SIDR process goes... long, but generally good in the end. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are 2 different protocol implementations to date. One from RipeLabs, one from Dragon Research Group. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: morrowc@ops-netman.net - Chris Morrow (me) AD: Alvaro Retana - aretana@cisco.com (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. the shepherd read the document during it's lifecycle, it has lived up to expectations. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Quite possibly the XML bits: https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-04#section-3.5.4 should be reviewed again, I believe the authors already undertook some expert review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. no concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. yes, no issues. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no IPR claims. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? solid consensus (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) no appeal/etc threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No substantive nits, all issues will be dealt with before RFC Editor time. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews required. (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No other documents changed due to this document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There is one item for IANA to accomplish, an update to a PKIX registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. no new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. YES! xmllint and trang were used to validate the XML schema. |
2017-03-02
|
07 | Alexey Melnikov | [Ballot discuss] I would be happy to ballot Yes on this document, as it is well written and is a useful piece of work. However … [Ballot discuss] I would be happy to ballot Yes on this document, as it is well written and is a useful piece of work. However I have one issue (and a few minor comments) that I would like to DISCUSS before doing so: In Section 5.3 the document says: It is RECOMMENDED that Relying Parties and Publication Servers follow the Best Current Practices outlined in [RFC7525] on the use of HTTP over TLS (HTTPS) [RFC2818]. RFC 7525 is referencing RFC 6125 for server hostname validation. Unfortunately this is not detailed enough to perform hostname validation, because reference to RFC 6125 requires specifying answers to every question in section 3 of RFC 6125. (And there is no generic RFC that specifies how this is done for protocols using HTTP.) One example of how this might look like is in Section 9.2 of . For your convenience the relevant text is pasted below: Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates. DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*". rpki-rtr implementations which use TLS MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [RFC6125]. The only thing missing from the above is explicit mentioning that SRV-ID and URI-ID are not used. (I think the same should apply to your document.) |
2017-03-02
|
07 | Alexey Melnikov | [Ballot comment] In 3.2: HTTPS reference is out-of-date. SHA-256 needs a reference. The shepherding write up says that the schema was not validated. Why not? |
2017-03-02
|
07 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from No Record |
2017-03-01
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-02-26
|
07 | Alexey Melnikov | [Ballot comment] In 3.2: HTTPS reference is out-of-date. SHA-256 needs a reference. <> The shepherding write up says that the schema was not validated. Why … [Ballot comment] In 3.2: HTTPS reference is out-of-date. SHA-256 needs a reference. <> The shepherding write up says that the schema was not validated. Why not? |
2017-02-26
|
07 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2017-02-16
|
07 | Alexey Melnikov | Telechat date has been changed to 2017-03-02 from 2017-02-16 |
2017-02-16
|
07 | Alexey Melnikov | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2017-02-16
|
07 | Stephen Farrell | [Ballot comment] 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 … [Ballot comment] 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. |
2017-02-16
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2017-02-16
|
07 | Benoît Claise | [Ballot comment] Sue Harres' OPS DIR review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents … [Ballot comment] 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.. “ |
2017-02-16
|
07 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2017-02-16
|
07 | Benoît Claise | [Ballot comment] I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. … [Ballot comment] 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.. “ |
2017-02-16
|
07 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-02-16
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2017-02-16
|
07 | Alexey Melnikov | [Ballot comment] I am very likely to defer this document, as it needs review from HTTP experts. |
2017-02-16
|
07 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2017-02-16
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-02-16
|
07 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2017-02-15
|
07 | Spencer Dawkins | [Ballot comment] 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. … [Ballot comment] 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. |
2017-02-15
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-02-15
|
07 | Ben Campbell | [Ballot 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 … [Ballot 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. |
2017-02-15
|
07 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-02-15
|
07 | Terry Manderson | [Ballot comment] Thank you for this work, it is clear and well written. While I have never (ever) been enamoured by RSYNC, and I much … [Ballot comment] 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.. |
2017-02-15
|
07 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-02-15
|
07 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-02-15
|
07 | Susan Hares | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Susan Hares. Sent review to list. |
2017-02-14
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-02-14
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-02-14
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-02-14
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-02-10
|
07 | Oleg Muravskiy | New version available: draft-ietf-sidr-delta-protocol-07.txt |
2017-02-10
|
07 | (System) | New version approved |
2017-02-10
|
07 | (System) | Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein" |
2017-02-10
|
07 | Oleg Muravskiy | Uploaded new revision |
2017-02-10
|
06 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2017-02-10
|
06 | Alvaro Retana | Ballot has been issued |
2017-02-10
|
06 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2017-02-10
|
06 | Alvaro Retana | Created "Approve" ballot |
2017-02-10
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-02-10
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-02-10
|
06 | Oleg Muravskiy | New version available: draft-ietf-sidr-delta-protocol-06.txt |
2017-02-10
|
06 | (System) | New version approved |
2017-02-10
|
06 | (System) | Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein" |
2017-02-10
|
06 | Oleg Muravskiy | Uploaded new revision |
2017-02-02
|
05 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg. |
2017-02-01
|
05 | Alvaro Retana | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup |
2017-02-01
|
05 | Alvaro Retana | Ballot writeup was changed |
2017-01-31
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-01-30
|
05 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-01-30
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-sidr-delta-protocol-05.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-sidr-delta-protocol-05.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete. In the SMI Security for PKIX Access Descriptor subregistry of the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry located at: http://www.iana.org/assignments/smi-numbers/ a new entry will be registered as follows: Decimal: [ TBD-at-registration ] Description: id-ad-rpkiNotify Reference: [ RFC-to-be ] Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-01-25
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2017-01-25
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2017-01-19
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Orit Levin |
2017-01-19
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Orit Levin |
2017-01-19
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2017-01-19
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2017-01-17
|
05 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-01-17
|
05 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org, … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org, aretana@cisco.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (RPKI Repository Delta Protocol) to Proposed Standard The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI Repository Delta Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a protocol which provides relying parties with a mechanism to query a repository for incremental updates using the HTTP Over TLS (HTTPS) [RFC2818] protocol, thus enabling the RP to keep its state in sync with the repository using a secure transport channel. This document updates [RFC6480], [RFC6481], and [RFC7730]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5781: The rsync URI Scheme (Informational - IETF stream) rfc2818: HTTP Over TLS (Informational - IETF stream) rfc6480: An Infrastructure to Support Secure Internet Routing (Informational - IETF stream) All 3 references have been considered by the community before and are already listed in the acceptable Downref Registry: https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry |
2017-01-17
|
05 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-01-17
|
05 | Alvaro Retana | Placed on agenda for telechat - 2017-02-16 |
2017-01-17
|
05 | Alvaro Retana | Changed consensus to Yes from Unknown |
2017-01-17
|
05 | Alvaro Retana | Last call was requested |
2017-01-17
|
05 | Alvaro Retana | Ballot approval text was generated |
2017-01-17
|
05 | Alvaro Retana | Ballot writeup was generated |
2017-01-17
|
05 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2017-01-17
|
05 | Alvaro Retana | Last call announcement was changed |
2017-01-17
|
05 | Alvaro Retana | Last call announcement was generated |
2017-01-16
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-01-16
|
05 | Oleg Muravskiy | New version available: draft-ietf-sidr-delta-protocol-05.txt |
2017-01-16
|
05 | (System) | New version approved |
2017-01-16
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein" |
2017-01-16
|
05 | Oleg Muravskiy | Uploaded new revision |
2016-12-20
|
04 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2016-12-20
|
04 | Alvaro Retana | === AD Review of draft-ietf-sidr-delta-protocol-04 === I have several comments (please see below); I marked many of them as “Major”, some because of the use … === AD Review of draft-ietf-sidr-delta-protocol-04 === I have several comments (please see below); I marked many of them as “Major”, some because of the use of Normative language, but my main concern is that I think error conditions in the protocol are underspecified (see M7, M8, M10, below). Along the same lines, I think that an Operations Considerations section would be of benefit (see M8 below); you might also want to take a look at RFC5706 (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions). I would like to see the error conditions comments addressed before moving this document forward to IETF Last Call. Thanks!! Alvaro. Major: M1. I assume that the id-ad-rpkiNotify value was assigned through the early allocation process. Instead of pointing at the registry in Section 3.2, point at the IANA Consideration Section --- and there, please remind IANA of the early allocation and request the update. M2. Section 3.2. (Certificate Authority Use): “Relying Parties that do not support this delta protocol MUST NOT reject a CA certificate merely because it has an SIA extension containing this new kind of AccessDescription.” By definition, an RP that has never even considered this document will not support the delta protocol – IOW, trying to specify the behavior of RPs that may have never even seen this document makes no sense to me, and can’t be enforced. What is the current behavior when an RP receives the extra SIA extension? M3. Section 3.3.2. (Publishing Updates): “Whenever the repository server receives updates from a CA it SHOULD generate new snapshot and delta files. However, if a publication server services a large number of CAs it MAY choose to combine updates from multiple CAs. If a publication server combines updates in this way, it MUST NOT postpone publishing for longer than one minute.” The “MUST NOT” at the end (making it mandatory to publish) doesn’t work with the “SHOULD” at the beginning, which has no time constraint and opens to the door to a situation where no publishing is done. Suggestion: NEW> Whenever the repository server receives updates from a CA it MUST generate new snapshot and delta. If a publication server services a large number of CAs it MAY choose to combine updates from multiple CAs, but it MUST NOT postpone publishing for longer than one minute. M4. From 3.3.2. (Publishing Updates): “The update notification file SHOULD be kept small…older delta files that…will result in total size of deltas exceeding the size of the snapshot, MUST be excluded.” Here the “SHOULD” and the “MUST” are in contradiction: you either do it always (MUST) or there may be cases when you don’t (SHOULD). s/SHOULD/should M5. Section 3.4.1. (Processing the Update Notification File) says that “a Relying Party (RP)…SHOULD prefer to use this protocol as follows.” I think you really want to be explicit: s/SHOULD prefer to use/SHOULD use M6. 3.4.1. (Processing the Update Notification File): “The RP SHOULD download the update notification file, unless an update notification file was already downloaded and processed from the same location in this validation run.” Is there any other reason for the file not to be downloaded? Why would the RP decide not to (“SHOULD”)? If there are no other reasons, then why isn’t the “SHOULD” a “MUST”? M7. 3.4.1. (Processing the Update Notification File): “MUST issue an operator error” What is an “operator error” and how do you issue one? I didn’t see an error definition in the schema. M8. 3.4.1. (Processing the Update Notification File): “If neither update notification file and one snapshot file or delta files could be processed…SHOULD use an alternate repository retrieval mechanism if it is available.” This “SHOULD” doesn’t define anything normative with respect to the Delta Protocol. I think that this document would benefit from a short Operation Considerations section; a place to indicate expectations of the operators, potential issues, the fact (as expressed in this piece of text) that an alternate mechanism should be enabled (or at least considered), other considerations related to logging errors for the operator (see above), etc. M9. There are some places where non-normative and normative (RFC2119) language is used that may cause confusion. For example, in 3.4.2: “should perform the following actions”, the actions contain a set of “MUSTs” and “SHOULDs”. Please find an alternate way to write the lead-in header to avoid confusion. Suggestion: s/it should perform the following actions/it performs the following actions. [Note that the same construct if used in several different places…] M10. In several places (related to verification, but in other places as well), “the file MUST be rejected” is used. What does this mean exactly? Are there actions that should be taken as a result? An example of why I’m asking: an RP will download and process delta files based on information in a notification file – if a delta file is not well-formed (for example), then the validation will fail and the RP MUST reject it – there are multiple reasons why the file may not be well-formed, but the bottom line is that whatever information was there that the repository pointed to in the notification message is lost (?) – does this mean that the RP is now out of sync? Should the RP now try and re-sync using the snapshot file? What if that is also rejected? Maybe the notification file was somehow corrupted and pointed at the wrong file(s)…should the relationship with the repository be reset/restarted? It is not clear at all what should be done, or what the implications are of these error conditions; it just looks like we reject and go on. [See comment M8 above: it looks like only when “neither update notification file and one snapshot file or delta files could be processed” that we would abandon using RRDP.] M11. From 3.4.3. (Processing Delta Files): “it is RECOMMENDED that a RP uses additional strategies to determine if an object is still relevant for validation before removing it from its local storage”. Ok, like what? M12. 3.5.1.2. (Update Notification File): “…the repository server MUST ensure that this file is not cached for longer than 1 minute. An exception to this rule…” Using “MUST” implies no exceptions. s/MUST/SHOULD s/then no/than no M13. Why isn’t an IETF namespace [RFC3688] used in the XML schema? I would strongly suggest that you use one and request it in the IANA Considerations Section. Unlike the publication protocol, this document specifies version 1 – which of course doesn’t mean there isn’t a longer history behind it, so I’m open to keeping a non-IETF namespace if that is the case. M14. 3.5.2.3: “Note that the publish element is defined in the publication protocol [I-D.ietf-sidr-publication]” But the example doesn’t correspond to the definition in I-D.ietf-sidr-publication, even if it does comply with the schema in this document. Should the publish element behave the same way as specified in I-D.ietf-sidr-publication? It is good that the RRDP design goes back to the Publication Protocol, but if it doesn’t use the exact definition from there (including the schema), then the differences should be highlighted here. M15. 3.5.3.3: “Note that the publish and withdraw elements are defined in the publication protocol [I-D.ietf-sidr-publication]” Same comment as above. M16. Section 5. (Security Considerations): “RRDP replaces the use of rsync by HTTPS…”. Given the statement in 3.4.1 about using “an alternate repository retrieval mechanism” and the rest of the text in this section, I would assume that the intent is not really to “replace the use of rsync” (with an update to RFC6480). Maybe I’m reading too much into the phrase above, but please clarify. Minor: P1. In 3.3.1. (Initialisation): “Note that this snapshot file MAY contain zero publish elements at this point if no objects have been submitted for publication yet.” This text is not describing an option: s/MAY/may P2. Please expand RRDP in first use. P3. Section 3.4.4. (Polling the Update Notification File) says: “A detailed description of the validation process itself is out of scope of this document.” Isn’t that what is described in 3.4.1 and 3.5.1.3?? P4. “version 4 UUID” Please provide a reference. P5. 3.5.1.3: “The serial attribute must be…” This is the only place where RFC2119 language is not used in this section. Any special reason? P6. 3.5.1.3: “If delta elements are included they MUST form a contiguous sequence of serial numbers…up to the serial number mentioned in the notification element.” The example in this section lists the serial numbers in “reverse order” (3, 2) – is there an order requirement? The text seems to imply it, but it could go either way. P7. The following references should be Informative: IANA-AD-NUMBERS, RFC6481, RFC6486, RFC6488 should be made Informative. Nits: N1. In both 3.3.1/3.3.2, the notes about “format and caching concerns” would work better if they are part of the previous paragraph. N2. s/are no no longer/are no longer |
2016-12-19
|
04 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2016-12-19
|
04 | Alvaro Retana | Notification list changed to "Chris Morrow" <morrowc@ops-netman.net>, aretana@cisco.com from "Chris Morrow" <morrowc@ops-netman.net> |
2016-10-26
|
04 | Chris Morrow | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, Certificate Revocation Lists (CRL), and RPKI signed objects to repositories. Relying Parties (RP) retrieve the published information from those repositories. This document specifies a delta protocol which provides relying parties with a mechanism to query a repository for incremental updates, thus enabling the RP to keep its state in sync with the repository." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The WG process was as most SIDR process goes... long, but generally good in the end. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are 2 different protocol implementations to date. One from RipeLabs, one from Dragon Research Group. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: morrowc@ops-netman.net - Chris Morrow (me) AD: Alvaro Retana - aretana@cisco.com (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. the shepherd read the document during it's lifecycle, it has lived up to expectations. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Quite possibly the XML bits: https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-04#section-3.5.4 should be reviewed again, I believe the authors already undertook some expert review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. no concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. yes, no issues. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no IPR claims. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? solid consensus (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) no appeal/etc threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No substantive nits, all issues will be dealt with before RFC Editor time. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews required. (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No other documents changed due to this document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There is one item for IANA to accomplish, an update to a PKIX registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. no new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No automated checks made. |
2016-10-26
|
04 | Chris Morrow | Responsible AD changed to Alvaro Retana |
2016-10-26
|
04 | Chris Morrow | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2016-10-26
|
04 | Chris Morrow | IESG state changed to Publication Requested |
2016-10-26
|
04 | Chris Morrow | IESG process started in state Publication Requested |
2016-10-26
|
04 | Chris Morrow | Changed document writeup |
2016-10-26
|
04 | Chris Morrow | Notification list changed to "Chris Morrow" <morrowc@ops-netman.net> |
2016-10-26
|
04 | Chris Morrow | Document shepherd changed to Chris Morrow |
2016-09-29
|
04 | Tim Bruijnzeels | New version available: draft-ietf-sidr-delta-protocol-04.txt |
2016-09-29
|
04 | Tim Bruijnzeels | New version approved |
2016-09-29
|
04 | Tim Bruijnzeels | Request for posting confirmation emailed to previous authors: "Tim Bruijnzeels" , "Oleg Muravskiy" , "Bryan Weber" , "Rob Austein" |
2016-09-29
|
04 | (System) | Uploaded new revision |
2016-07-14
|
03 | Sandra Murphy | Added to session: IETF-96: sidr Thu-1000 |
2016-07-07
|
03 | Tim Bruijnzeels | New version available: draft-ietf-sidr-delta-protocol-03.txt |
2016-03-21
|
02 | Tim Bruijnzeels | New version available: draft-ietf-sidr-delta-protocol-02.txt |
2015-10-19
|
01 | Tim Bruijnzeels | New version available: draft-ietf-sidr-delta-protocol-01.txt |
2015-03-21
|
00 | Sandra Murphy | Intended Status changed to Proposed Standard from None |
2015-02-16
|
00 | Tim Bruijnzeels | New version available: draft-ietf-sidr-delta-protocol-00.txt |