Re: [Sidrops] version negotiation
Claudio Jeker <cjeker@diehard.n-r-g.com> Thu, 11 January 2024 10:34 UTC
Return-Path: <cjeker@diehard.n-r-g.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4E2C1519A4 for <sidrops@ietfa.amsl.com>; Thu, 11 Jan 2024 02:34:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGzFpI0JlAQO for <sidrops@ietfa.amsl.com>; Thu, 11 Jan 2024 02:34:05 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC92C151545 for <sidrops@ietf.org>; Thu, 11 Jan 2024 02:34:04 -0800 (PST)
Received: (qmail 93707 invoked by uid 1000); 11 Jan 2024 10:34:02 -0000
Date: Thu, 11 Jan 2024 11:34:02 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Cc: Randy Bush <randy@psg.com>, sidrops <sidrops@ietf.org>
Message-ID: <ZZ/EGo0udZFD+Ejd@diehard.n-r-g.com>
References: <C6809556-2957-4E50-93FF-E392B69EE19C@vigilsec.com> <43e9a8461d05470190ee7d3a7bb46cf4@huawei.com> <ZYFq8we3BMBji6jb@diehard.n-r-g.com> <ZYM9bEdeZOdidSU1@dwc-desktop.local> <CAMFGGcD-hAprxBBoz2dL7wzoq1j187B6XNHQURtRN85GgpgjqA@mail.gmail.com> <ZYQNxzeMl2uhweBu@diehard.n-r-g.com> <m2ttnv5kbh.wl-randy@psg.com> <ZZ1hwM7qCDsjSmU8@diehard.n-r-g.com> <m2cyu86gi6.wl-randy@psg.com> <CAMFGGcA9Mpw_o-+BCzEAJX=tHiJYG1ZDf35-MWr=j7Z=gKSLTA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMFGGcA9Mpw_o-+BCzEAJX=tHiJYG1ZDf35-MWr=j7Z=gKSLTA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/W_IP8mRHy60e3Z8-eQR1sL6Dd7c>
Subject: Re: [Sidrops] version negotiation
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jan 2024 10:34:07 -0000
On Wed, Jan 10, 2024 at 10:22:02PM +0100, Job Snijders wrote: > Randy, > > Related to RTR being “trinary”, and it being desirable for the protocol > negotiation to be generalized - would it make sense to add a text that in > order to facilitate protocol upgrades, the cache should start a new > session, or perhaps introduce a new non-fatal Error Code “Upgrade > Available”? Or some other signal? See my other mail but I think in one of the sections (either 10 or 12) this should be documented using "the cache should start a new session" option. Introducing complex upgrade logic is out of scope for RTR especially since this can be avoided by using more then one RTR cache. > Some router implementations doing ISSU (potentially making for extremely > long-lived RTR sessions), I imagine it’s valuable if there is explicit > guidance on how protocol upgrades work. > > It would be suboptimal if both cache and router support newer versions of > RTR, but because of a past negotiation, neither uses the newer version. > > Kind regards, > > Job > > On Wed, 10 Jan 2024 at 22:11, Randy Bush <randy@psg.com> wrote: > > > >> If the router query has version Q> N, the cache MUST send an Error > > >> Report (Section 5.11) with Protocol Version N and Error Code 4 > > >> ("Unsupported Protocol Version"), and the router SHOULD send another > > >> query with a Protocol Version Q of the version N in the Error Report, > > >> unless it has already failed at that version. This MAY repeat with > > >> the router attempting to negotiate lower and lower versions until > > >> they agree. > > > > > > Coming back to session downgrades (router query Q> N). RFC8210 has this: > > > > > > 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. > > > > the 8210 text is > > > > 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. > > > > > This is in direct conflict with the above. It is also in > > > draft-ietf-sidrops-8210bis-11. Also the rtr caches I checked use this > > > implicit downgrade for sessions. So I don't think this method can be > > > removed. > > > > agree that this is problematic in a number of ways. > > > > i think we would want /terminate the connection/terminate the session/ > > > > but further, 8210 is a one or zero negotiation. and we're now trinary, > > and next year we'll be quaternary :( so hard coding the 1 to 0 downgrade > > seems ill advised and should be generalized. > > > > so 'implicit' downgrade to zero or terminate should probably be phrased > > as a N-ary process, which the proposed text attempts to do. > > > > for ref, our current working text is as follows: > > > > If a cache which supports version C receives a query with Protocol > > Version Q < C, and the cache does not support versions <= Q, the > > cache MUST send an Error Report (Section 5.11) with Protocol Version > > C and Error Code 4 ("Unsupported Protocol Version") and disconnect > > the transport, as negotiation is hopeless. > > > > If a cache which supports version C receives a query with Protocol > > Version Q < C, and the ache can support version Q, the cache MUST > > downgrade to protocol version Q, [RFC6810] or [RFC8210], and respond > > with a Cache Response (Section 5.5) of that Protocol Version, Q, and > > the RPKI-Rtr session is considered open. > > > > If the the cache which supports C as its highest verion receives a > > query of version Q > C, the cache MUST send an Error Report with > > Protocol Version C and Error Code 4. The router SHOULD send another > > query with a Protocol Version Q with Q == the version C in the Error > > Report; unless it has already failed at that version, which indicates > > a fatal error in programming of the cache which SHOULD result in > > transport termination. > > > > If the router requests Q == 0 and it still fails with the cache > > responding with an Error Report with Error Code 4, then the router > > MUST abort the transport connection, as negotiation is hopeless. > > > > we think this should interop with v0 and v1 devices. but we would > > definitely appreciate specific text where it could be improved. > > > > randy > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops -- :wq Claudio
- [Sidrops] Format of ASPA RTR PDU Maria Matejka
- Re: [Sidrops] Format of ASPA RTR PDU Claudio Jeker
- Re: [Sidrops] Format of ASPA RTR PDU Martin Hoffmann
- Re: [Sidrops] Format of ASPA RTR PDU Claudio Jeker
- Re: [Sidrops] Format of ASPA RTR PDU Martin Hoffmann
- Re: [Sidrops] Format of ASPA RTR PDU Borchert, Oliver (Fed)
- Re: [Sidrops] Format of ASPA RTR PDU Claudio Jeker
- Re: [Sidrops] Format of ASPA RTR PDU Borchert, Oliver (Fed)
- Re: [Sidrops] Format of ASPA RTR PDU Maria Matejka
- Re: [Sidrops] Format of ASPA RTR PDU Claudio Jeker
- Re: [Sidrops] Format of ASPA RTR PDU Martin Hoffmann
- Re: [Sidrops] Format of ASPA RTR PDU Christopher Morrow
- Re: [Sidrops] Format of ASPA RTR PDU Job Snijders
- Re: [Sidrops] Format of ASPA RTR PDU Martin Hoffmann
- Re: [Sidrops] Format of ASPA RTR PDU Christopher Morrow
- Re: [Sidrops] Format of ASPA RTR PDU Job Snijders
- Re: [Sidrops] Format of ASPA RTR PDU Tim Bruijnzeels
- Re: [Sidrops] Format of ASPA RTR PDU Martin Hoffmann
- Re: [Sidrops] Format of ASPA RTR PDU Russ Housley
- Re: [Sidrops] Format of ASPA RTR PDU gengnan
- Re: [Sidrops] Format of ASPA RTR PDU Randy Bush
- Re: [Sidrops] Format of ASPA RTR PDU Claudio Jeker
- Re: [Sidrops] Format of ASPA RTR PDU Randy Bush
- Re: [Sidrops] Format of ASPA RTR PDU Job Snijders
- Re: [Sidrops] Format of ASPA RTR PDU Tim Bruijnzeels
- Re: [Sidrops] Format of ASPA RTR PDU Maria Matejka
- Re: [Sidrops] Format of ASPA RTR PDU Randy Bush
- Re: [Sidrops] Format of ASPA RTR PDU Dale W. Carder
- Re: [Sidrops] Format of ASPA RTR PDU Job Snijders
- Re: [Sidrops] Format of ASPA RTR PDU Claudio Jeker
- Re: [Sidrops] Format of ASPA RTR PDU Borchert, Oliver (Fed)
- Re: [Sidrops] version negotiation Randy Bush
- Re: [Sidrops] Format of ASPA RTR PDU Ties de Kock
- Re: [Sidrops] Format of ASPA RTR PDU Job Snijders
- Re: [Sidrops] Format of ASPA RTR PDU Warren Kumari
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Randy Bush
- Re: [Sidrops] Format of ASPA RTR PDU Martin Hoffmann
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Job Snijders
- Re: [Sidrops] version negotiation Randy Bush
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Randy Bush
- Re: [Sidrops] version negotiation Job Snijders
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Claudio Jeker
- Re: [Sidrops] version negotiation Randy Bush
- Re: [Sidrops] version negotiation Job Snijders
- Re: [Sidrops] version negotiation Randy Bush
- Re: [Sidrops] version negotiation Job Snijders
- Re: [Sidrops] version negotiation Job Snijders
- Re: [Sidrops] version negotiation Randy Bush
- Re: [Sidrops] version negotiation Randy Bush