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

"Alvaro Retana (aretana)" <aretana@cisco.com> Sat, 23 April 2016 00:09 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DA84012D0FE; Fri, 22 Apr 2016 17:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QtBIetDYThbv; Fri, 22 Apr 2016 17:09:13 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40CF12D1C0; Fri, 22 Apr 2016 17:09:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8907; q=dns/txt; s=iport; t=1461370153; x=1462579753; h=from:to:cc:subject:date:message-id:mime-version; bh=vO93JJ2KQC/46jk7nlRGi0dZ6M7ZRUhwRPikCrixYGw=; b=l2AjEZU+UvmGKCwcG/xYuHAt67UQueIUMTKLHvf5n6FCJQ0Bv6VXdl6S KvUVzxJHT5G05XhZDfNq9SGhV+nyRyyHTYYjLjbGd4YXDLyUS4yXzvJ6a jscRh670jLSPhK91Y+IMQkDaiXtSEtKYm2p3SYRZ5p3gd3W3mSO8uQKVA A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AgCyvBpX/5FdJa1egmxMgVa1DIRzA?= =?us-ascii?q?Q2BdYYOgSY4FAEBAQEBAQFlHAuERAR5EgGBACcEDogvv0cBAQEBAQEEAQEBAQE?= =?us-ascii?q?BARmGIY5gBY4LhROEcQGOE4FmjSqGI4kLAR4BAUKCBhqBS4hofwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,519,1454976000"; d="scan'208,217";a="263176162"
Received: from rcdn-core-9.cisco.com ([]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2016 00:09:08 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com []) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3N098qW007872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Apr 2016 00:09:08 GMT
Received: from xch-aln-002.cisco.com ( by XCH-RCD-003.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 19:09:07 -0500
Received: from xch-aln-002.cisco.com ([]) by XCH-ALN-002.cisco.com ([]) with mapi id 15.00.1104.009; Fri, 22 Apr 2016 19:09:07 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" <draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org>
Thread-Topic: AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07
Thread-Index: AQHRnPRan3y40yRdEkS30+qNsvqUUg==
Date: Sat, 23 Apr 2016 00:09:07 +0000
Message-ID: <D321EEDD.11B911%aretana@cisco.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D321EEDD11B911aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/O01C9uuVD5SB3_vHE9Vm8zk0wGg>
Cc: Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: [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: Sat, 23 Apr 2016 00:09:15 -0000


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.




  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?


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