Last Call Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08
review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07-00

Request Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-30
Requested 2017-01-16
Draft last updated 2017-02-07
Completed reviews Opsdir Last Call review of -08 by Stefan Winter (diff)
Secdir Last Call review of -08 by Matthew Miller (diff)
Assignment Reviewer Stefan Winter
State Completed
Review review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07
Reviewed rev. 08 (document currently at 09)
Review result Has Issues
Review completed: 2017-02-07

Review
review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07

Hello,

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.

Document reviewed: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08

Review: I believe this document is "Ready with comments".

Nits and comments below.

5.1. Fields of a PDU

The PDU fields are using slightly confusing nomenclature:

An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element. -> Max Length
An 8-bit unsigned integer denoting the shortest prefix allowed for the Prefix element. -> Prefix Length

If the longest is called max, shouldn't the shortest be called min, rather than "prefix"? Also note "by" vs. "for".

5.11. Error Report

s/PDUS/PDUs/

6. Timers

If Expire is < Refresh and/or Retry, then the implementation would be
forced to go against the SHOULD.

Does it make sense to require Expire to be > max { Refresh, Retry } ?

7. Version Negotiation

All the combinations of versions will lead to a successful negotation.
There is just one thing which is implicit (and one could argue "goes
without saying), but why not make it explicit:

"Routers MUST always start the negotiation with the highest version they
support otherwise configured otherwise."

The text as it currently stands does not mandate that, and a router
which *supports* 0 and 1 could choose to start a version 0 conversation,
leading to a successful version 0 connection. If that is not desirable
by the protocol designers, they should make sure that this degree of
freedom is taken away.

8.1 and 8.2:

"See Section 6
<https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08#section-6>
for details on the required polling frequency."

Just language: section 6 does not specify a signle required frequency.
It specifies a minimum interval (SHOULD for Refresh/Retry) and a maximum
interval (MUST for Expire), and the exact frequency is free to choose by
the implementation:

The actual frequency lies in a band between 0 and Expire (if clients
choose to ignore the SHOULDs) or Refresh/Retry and Expire (if they do not).

A text like:

"See Section 6
<https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08#section-6>
for details on the lower and upper bounds for the polling frequency."

would be more explicit.

9. Transport / Authentication

So there is a (comparatively old-ish) protocol which would be a good
mandatory-to-implement transport. But then this RFC doesn't make it so
because it is not available on all platforms? The sentence:

"It is expected that, when the TCP Authentication Option (TCP-AO)
   [RFC5925 <https://tools.ietf.org/html/rfc5925>] is available on all platforms deployed by operators, it
   will become the mandatory-to-implement transport."


unnecessarily creates a chicken-and-egg situation. Considering that
there is already a version 0 which can be used by older routers not
doing RFC5925, why not establish RFC5925 requirements as the baselines
*right now in this RFC*?

If version 0 is not good enough and router vendors want the features of
version 1, they can update their code for TCP-AO transport along with
the code updates they have to do anyway to implement this RFC here.

9.2. TLS

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


The preceding text makes clear that DNS identification is done by the
client (router), so it sure needs to implement that.

However the server identifies clients by their subjectAltName:iPAddr
(NOT the DNS name). So, the server doesn't have to implement this,
right? It only needs to be able to present a certificate with that
property inside, but that's not called "implementation".

10.

"See Section 6
<https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08#section-6>
for details on what to do when the client is not able to refresh from a
particular cache."

Section 6 defines timing parameters and has no info on what to do if things don't work. You may want to reference some other text? (But actually the text in the exact section 10 here talks about that very topic?)

11.

This section contains advice on how caches should talk to RPKI. The scope of the rest of the document is about routers talking to caches. And this section in particular is about deployment scenarios between routers and caches.

IOW, the last two paragraphs look they they should in some other RPKI deployment considerations document?

12. Error code 8:

"The received PDU has a
      Protocol Version field that differs from the protocol version
      negotiated in Section 7
<https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-08#section-7>."

The router did not negotiate anything in section 7. It negotiated the protocol version during its connection setup. It was probably following the rules that this RFC gives in section 7, but the sentence still sounds weird if written like that.

Greetings,

Stefan Winter 

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66