Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07
"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 29 June 2016 17:46 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 0ECF812D599; Wed, 29 Jun 2016 10:46:01 -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 0OeZYrZHlSZ5; Wed, 29 Jun 2016 10:45:50 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754A212D5A1; Wed, 29 Jun 2016 10:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10814; q=dns/txt; s=iport; t=1467222347; x=1468431947; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xAnFqUFVWqgTq2eCtMCjKDTx3KZ13qJgYHzrqIjBnzs=; b=hv8zrn9r82B/uSx2LQ8RpyCkhTugD6kAsIZaida4lLajBL8avY7niR5B we8L8EHL7femNASVtr9+M0GA1VLb/oi2kNGtho13BMyU6f6q3uSX9kgvQ 8pyif7T04MJ+QRE6N/TU7lSBal9JF3YvubHa8WnWXV4ulALP2grrTNQ/2 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYAgAACHRX/4wNJK1agz6BUwa5Q4F7hhgCgTI4FAEBAQEBAQFlJ4RNAQEEOjINEAIBCA4KHhAyJQIEDgUZAogVxBQBAQEBAQEBAQEBAQEBAQEBAQEBHoQKgh6ETYobAQSIGIs4hTUBjj2BaY08hlSJLgEeNoIIHIFMbog/fwEBAQ
X-IronPort-AV: E=Sophos;i="5.26,547,1459814400"; d="scan'208";a="290920067"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2016 17:45:46 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5THjkcb006452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 17:45:46 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 12:45:45 -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.1210.000; Wed, 29 Jun 2016 12:45:45 -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+qNsvqUUqABMvIA
Date: Wed, 29 Jun 2016 17:45:45 +0000
Message-ID: <D3998132.1319FD%aretana@cisco.com>
References: <D321EEDD.11B911%aretana@cisco.com> <20160427015828.9591B3EEED13@minas-ithil.hactrn.net> <D36A105A.1277CC%aretana@cisco.com>
In-Reply-To: <D36A105A.1277CC%aretana@cisco.com>
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: <6D5510C51FC97F4ABA0EFCE3BFE3198D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/v5PlKaFlKCa6E2OlW1W78Uak6DI>
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, 29 Jun 2016 17:46:01 -0000
Rob: Hi! Did you have comments on this? I'm assuming that we're expecting an updated document at some point, but if we need to discuss more... Thanks! Alvaro. On 5/25/16, 12:09 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote: >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