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