Last Call Review of draft-ietf-sidr-delta-protocol-05
review-ietf-sidr-delta-protocol-05-opsdir-lc-hares-2017-02-15-00

Request Review of draft-ietf-sidr-delta-protocol
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-31
Requested 2017-01-17
Other Reviews Secdir Last Call review of -05 by David Mandelberg (diff)
Genart Last Call review of -06 by Orit Levin (diff)
Review State Completed
Reviewer Susan Hares
Review review-ietf-sidr-delta-protocol-05-opsdir-lc-hares-2017-02-15
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/VWXp3TYNjOWCyAXLz-BIdROJcus
Reviewed rev. 05 (document currently at 08)
Review result Has Nits
Draft last updated 2017-02-15
Review completed: 2017-02-15

Review
review-ietf-sidr-delta-protocol-05-opsdir-lc-hares-2017-02-15

Rob, Tim, Oleg, Bryan:

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