Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07
"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 25 May 2016 04:09 UTC
Return-Path: <aretana@cisco.com>
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 5451B12D5D8; Tue, 24 May 2016 21:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td5U3heDv0NP; Tue, 24 May 2016 21:09:57 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF0A12D5C3; Tue, 24 May 2016 21:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10317; q=dns/txt; s=iport; t=1464149396; x=1465358996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zTSFduqyn6KUa2jPppgVE59A46qxQl35COjBF5XrucA=; b=S+2siMHzEcjhb6l1uXK+K0U6GOCJq/nABHtq6t2o5ozk6YxGTZcGPtJX MhYEitLj0s6+fILPw8lrLl1cVofH/Auim+tJJN5TtVLm5E52NhTOlQf0f VgbdZB9IMC+kkEeRscwceke5v7ypTvbVyynfBIKZ53E4AuUg+YCqdv70C 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AxAgBmJEVX/5NdJa1bgzeBUwa5fgENgXaGEQKBODgUAQEBAQEBAWUnhEMBAQQ6Mg0QAgEIDgoeEDIlAgQOBRkCiBTESQEBAQEBAQEBAQEBAQEBAQEBAQEehAmCHoRMihkBBIgGizGFAAGOH4FpjTOGM4kYAR4BAUKDbW6JCH8BAQE
X-IronPort-AV: E=Sophos;i="5.26,362,1459814400"; d="scan'208";a="277404124"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 04:09:55 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4P49sMf005119 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 04:09:55 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 May 2016 23:09:54 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 24 May 2016 23:09:55 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Rob Austein <sra@hactrn.net>
Thread-Topic: AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07
Thread-Index: AQHRnPRan3y40yRdEkS30+qNsvqUUg==
Date: Wed, 25 May 2016 04:09:54 +0000
Message-ID: <D36A105A.1277CC%aretana@cisco.com>
References: <D321EEDD.11B911%aretana@cisco.com> <20160427015828.9591B3EEED13@minas-ithil.hactrn.net>
In-Reply-To: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B8730323F4598D408B063CA049F68F14@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/DwKmWVz6zLoDMUvXMcNuWFfTmk0>
Cc: "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" <draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org>, "sidr@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, 25 May 2016 04:09:59 -0000
On 4/26/16, 6:58 PM, "Rob Austein" <sra@hactrn.net> wrote: Rob: Hi! >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. When I think about protocol compatibility I think about on-the-wire behavior and packets, not about the implementation internals. NEW> The protocol described in this document should allow an implementation to largely reuse the code developed for version zero. However, I would prefer if the sentence was taken out completely. ... > >> * 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. If you want to deprecate version zero, then Obsoleting rfc6810 is ok. What is not ok is mandating its use at the same time. I'm thinking that we could get away with removing Section 7 completely, and leaving the downgrade behavior as a "local implementation detail" -- see below: I'm including comments on Section 7, and an optional new subsection. Notes_On_7 (my comments with [A]> 7. Protocol Version Negotiation A router MUST start each transport connection by issuing either a Reset Query or a Serial Query. This query will tell the cache which version of this protocol the router implements. [A] This text (above) is in conflict with Section 8.1. (Start or Restart) which reads: "When a transport connection is first established, the router MAY send a Reset Query...Alternatively...it MAY start with a Serial Query..." To match the behavior in Section 7, here's a suggestion for alternate text (for 8.1). OLD> When a transport connection is first established, the router MAY send a Reset Query and the cache responds with a data sequence of all data it contains. Alternatively, if the router has significant unexpired data from a broken session with the same cache, it MAY start with a Serial Query containing the Session ID from the previous session to ensure the Serial Numbers are commensurate. NEW> When a transport connection is first established, the router MUST send a Reset Query and the cache responds with a data sequence of all data it contains, or a Serial Query. The Serial Query can be used if the router has significant unexpired data from a broken session with the same cache; in this case the Serial Query containing the Session ID from the previous session to ensure the Serial Numbers are commensurate. [A] BTW, a couple of paragraphs later the text goes back to saying that "The router MUST send either a Reset Query or a Serial Query..." I think this text would now be redundant and can be deleted. 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. [A] The behavior of sending the Error PDU is expected if the cache doesn't support anything else. In the case of the cache supporting both, it can just directly downgrade (as a local decision) -- see some suggested text below. If a router which supports version 1 sends a query to a cache which only supports version 0, one of two things will happen. 1. The cache may terminate the connection, perhaps with a version 0 Error Report PDU. In this case the router MAY retry the connection using protocol version 0. 2. The cache may reply with a version 0 response. In this case the router MUST either downgrade to version 0 or terminate the connection. [A] In this case again, the behavior of the router can be a local decision: if a version 0 response (including an Error PDU) is received, then downgrade -- again, see suggested text below. In any of the downgraded combinations above, the new features of version 1 will not be available. If either party receives a PDU containing an unrecognized Protocol Version (neither 0 nor 1) during this negotiation, it MUST either downgrade to a known version or terminate the connection, with an Error Report PDU unless the received PDU is itself an Error Report PDU. [A] Both versions react the same way to an unrecognized version...so no need to repeat. The router MUST ignore any Serial Notify PDUs it might receive from the cache during this initial start-up period, regardless of the Protocol Version field in the Serial Notify PDU. Since Session ID and Serial Number values are specific to a particular protocol version, the values in the notification are not useful to the router. Even if these values were meaningful, the only effect that processing the notification would have would be to trigger exactly the same Reset Query or Serial Query that the router has already sent as part of the not-yet-complete version negotiation process, so there is nothing to be gained by processing notifications until version negotiation completes. [A] This text (above) is in conflict with Section 5.2. (Serial Notify), which reads: "If the router receives a Serial Notify PDU during the initial start-up period...the router SHOULD simply ignore the Serial Notify PDU..." Solution: update 5.2 with a "MUST" -- according to the explanation above, there's no real value in listening (which would not make it a "SHOULD"). [A] Section 5.2 also says: "See Section 7 for details." Instead of that reference, you can include the additional text above (after the first sentence). Caches SHOULD NOT send Serial Notify PDUs before version negotiation completes. Note, however, that routers MUST handle such notifications (by ignoring them) for backwards compatibility with caches serving protocol version 0. [A] The text above is the corollary of the "MUST ignore" text before it (you can include it in 5.2)...and the second sentence is really redundant. Once the cache and router have agreed upon a Protocol Version via the negotiation process above, that version is stable for the life of the session. See Section 5.1 for a discussion of the interaction between Protocol Version and Session ID. If either party receives a PDU for a different Protocol Version once the above negotiation completes, that party MUST drop the session; unless the PDU containing the unexpected Protocol Version was itself an Error Report PDU, the party dropping the session SHOULD send an Error Report with an error code of 8 ("Unexpected Protocol Version"). [A] Add the exception (receiving an Error PDU) to the definition of error code 8 in Section 12. Given that it is in fact possible to find older versions in the field, you might want to include a Section calling that out. My suggestion is to create a new Section called "Deployment Considerations", include in it the current Section 11. (Deployment Scenarios) as a sub-section, and add a new sub-section called "Transition Considerations". Suggestion> 11.2 Transition Considerations This document Obsoletes version zero of this protocol [RFC6810]. The intent is to deprecate its use. However, version zero is already in the field and it is possible that deployments will encounter mixed scenarios, where a router or cache may only support version zero. It is also expected that during the transition period a cache or router that supports version one will also support version zero. The determination that a peer (cache or router) only supports version zero is straight forward: a version zero PDU is received from them. In these cases, it is up to the local implementation, and policy, whether it might prefer to use version zero to establish the session, with the understanding that the new features of version one will not be available. One new comment: Section 12. (Error Codes) says that "Errors which are considered fatal SHOULD cause the session to be dropped." When is it ok not to drop the session? IOW, why not use a "MUST"? Thanks! Alvaro.
- Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-… Alvaro Retana (aretana)
- Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-… Alvaro Retana (aretana)
- [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6… Alvaro Retana (aretana)
- Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-… Rob Austein
- Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-… Alvaro Retana (aretana)
- Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-… Stephen Kent