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

Rob Austein <sra@hactrn.net> Wed, 27 April 2016 01:57 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1812D5C4; Tue, 26 Apr 2016 18:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlXxbopiKbPi; Tue, 26 Apr 2016 18:57:26 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF3E12D5B4; Tue, 26 Apr 2016 18:57:23 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 1006117046; Wed, 27 Apr 2016 01:57:23 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 9591B3EEED13; Tue, 26 Apr 2016 21:58:28 -0400 (EDT)
Date: Tue, 26 Apr 2016 21:58:28 -0400
From: Rob Austein <sra@hactrn.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
References: <D321EEDD.11B911%aretana@cisco.com>
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/N5BFeGx-Gp-AM0LtWgqVjYmVwkw>
Cc: sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2016 01:57:28 -0000

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.

>      *   It would be nice to include a section according to rfc6982
>          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!