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: =?us-ascii?q?A0AYAgAACHRX/4wNJK1agz6BUwa5Q4F7h?= =?us-ascii?q?hgCgTI4FAEBAQEBAQFlJ4RNAQEEOjINEAIBCA4KHhAyJQIEDgUZAogVxBQBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBHoQKgh6ETYobAQSIGIs4hTUBjj2BaY08hlSJLgEeN?= =?us-ascii?q?oIIHIFMbog/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.
>