Subject: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sat, 23 Apr 2016 00:09:07 +0000

Hi!

I have a couple of Major comments related to the existence/co-existence of two versions of the protocol.  I would like to see the comments discussed/addressed before starting the IETF Last Call.

Thanks!!

Alvaro.

Major:

  1.  RFC6810.
     *   Section 1.2. (Changes from RFC 6810):  "The protocol described in this document is largely compatible with [RFC6810]."  What does "largely compatible" mean?  It either is compatible or it isn't.  From Section 7. (Protocol Version Negotiation), it looks like there's no way for a router that only supports version 0 to talk a cache that only supports version 1, and viceversa.  Even though the PDUs are mostly the same, that doesn't seem to matter...in the end it looks like the versions are not compatible and in reality version 1 is simply an update to version 0.
     *   This document is marked as obsoleting rfc6810, but it mandates its use in section 7 ("...the cache MUST downgrade to protocol version 0 [RFC6810]...").  There are a couple of paths forward:
        *   It seems to me that this document should simply be called "RPKI to Router Protocol version 1" and not change the status of rfc6810 - we can always declare version 0 historic later.
        *   If you really want to obsolete version 0, then an alternative is to eliminate the normative language when it refers to it...  For example,
           *   OLD> "If a cache which supports version 1 receives a query from a router which specifies version 0, the cache MUST downgrade to protocol version 0 [RFC6810] or send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection."
           *   NEW> "If a cache which supports version 1 receives a query from a router which specifies version 0, the cache SHOULD send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection."
  2.  Section 7. (Protocol Version Negotiation)  Related to the points above...  Are other versions of this protocol expected?  I know the answer may come from a crystal ball at this point...but can the process defined here be generalized?

Minor:

  1.  Implementation
     *   In Section 1. (Introduction) you reference rfc7128 for an implementation report, but that RFC reports on the implementation of rfc6810, and not this new version.
     *   It would be nice to include a section according to rfc6982 about implementations of this version.
  2.  Section 9. (Transport)  I think this sentence is superfluous: "Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPSec transport.", because a couple of paragraphs later the text also says "...caches and routers MUST use one of the following more protected protocols" (and the same protocols are revisited).

---

From: Rob Austein <[email-masked]>
Date: Tue, 26 Apr 2016 21:58:28 -0400

At Sat, 23 Apr 2016 00:09:07 +0000, Alvaro Retana (aretana) wrote:
>
>      *   Section 1.2. (Changes from RFC 6810):  "The protocol
>          described in this document is largely compatible with
>          [RFC6810]."  What does "largely compatible" mean?  It
>          either is compatible or it isn't.

It means that most of the code one needs to deal with version one is
the same as the code one needs to deal with version zero.  Feel free
to suggest better text.

>          From Section 7. (Protocol Version Negotiation), it looks
>          like there's no way for a router that only supports version
>          0 to talk a cache that only supports version 1, and
>          viceversa.

Correct.  This is implicit in the original PDU design in RFC 6810, the
current draft doesn't change anything in that part of the design.

>          Even though the PDUs are mostly the same, that doesn't seem
>          to matter...in the end it looks like the versions are not
>          compatible and in reality version 1 is simply an update to
>          version 0.

I don't know how to parse that last sentence.  If there's a change you
want made here, please send text.

>      *   This document is marked as obsoleting rfc6810, but it
>          mandates its use in section 7 ("...the cache MUST downgrade
>          to protocol version 0 [RFC6810]...").  There are a couple
>          of paths forward:
>
>         *   It seems to me that this document should simply be
>             called "RPKI to Router Protocol version 1" and not
>             change the status of rfc6810 - we can always declare
>             version 0 historic later.
>
>         *   If you really want to obsolete version 0, then an
>             alternative is to eliminate the normative language when
>             it refers to it...  For example,
>
>            *   OLD> "If a cache which supports version 1 receives a
>                query from a router which specifies version 0, the
>                cache MUST downgrade to protocol version 0 [RFC6810]
>                or send a version 1 Error Report PDU with Error Code
>                4 ("Unsupported Protocol Version") and terminate the
>                connection."
>
>            *   NEW> "If a cache which supports version 1 receives a
>                query from a router which specifies version 0, the
>                cache SHOULD send a version 1 Error Report PDU with
>                Error Code 4 ("Unsupported Protocol Version") and
>                terminate the connection."

The intent is to deprecate version zero, because it lacks features we
think are important.  But version zero is already in the field and we
have no control over how long it will take to upgrade all existing
copies.  So we have to specify how versions zero and one are intended
to interoperate.  I don't know how to specify that without normative
references to the older version.

>   2.  Section 7. (Protocol Version Negotiation)  Related to the
>       points above...  Are other versions of this protocol expected?

No way of knowing, but the users aren't all dead yet, so assume yes.

>       I know the answer may come from a crystal ball at this
>       point...but can the process defined here be generalized?

The omission was deliberate.  We don't know what changes might occur
in the future, and while we'd like to think that the version mechanism
is sufficiently flexible to handle any likely changes, there is no way
to know what backwards compatibility rules might be needed before we
know what the associated changes will be.  So we deliberately
refrained from specifying behavior for any version other than the ones
currently assigned, in order to avoid unnecessarily constraining our
options in hypothetical future transitions.

I expect that any future updates will follow this pattern (saying
nothing about future versions, but specifying what to do with all know
versions, even if it's just drop or reject stuff older than version N.

>   1.  Implementation
>      *   In Section 1. (Introduction) you reference rfc7128 for an
>          implementation report, but that RFC reports on the
>          implementation of rfc6810, and not this new version.

Seems safe to remove that.

>          about implementations of this version.

Seems a bit late, given that the WG thinks it's done with this already
and that section would need to be removed before RFC publication?

Don't feel strongly about this, just not sure I see much value.

>   2.  Section 9. (Transport)  I think this sentence is superfluous:
>       "Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or
>       IPSec transport.", because a couple of paragraphs later the
>       text also says "...caches and routers MUST use one of the
>       following more protected protocols" (and the same protocols
>       are revisited).

Seems safe to remove that.

Thanks for the review!