Re: [Sidrops] version negotiation

[Claudio Jeker <[e-mail]>]

On Tue, Jan 02, 2024 at 04:31:30PM -0800, Randy Bush wrote:
> ( subject changed to protect the innocent :)
> 
> claudio:
> 
> point taken
> 
> i think much of the problem here is unintended lack of clarity between
> session and transport connection.  but the negotiation can be improved
> as well.
> 
> how about this as a first cut?
> 
>    7.  Protocol Version Negotiation
> 
>    Once a router has established a transport connection to a cache, it
>    MUST attempt to open a RPKI-Router 'session' by issuing either a
>    Reset Query Section 5.4) or a Serial Query (Section 5.3) with the
>    highest version of this protocol the router implements in the
>    Protocol Version field.  If the cache supports that version, it
>    responds with a Cache Response (Section 5.5) of that version and the
>    session is considered open.
> 
>    If a cache which supports version N receives a query with Protocol
>    Version Q < N, and the cache does not support versions <= Q, the
>    cache MUST send an Error Report (Section 5.11) with Protocol Version
>    N and Error Code 4 ("Unsupported Protocol Version") and disconnect
>    the transport session.
> 
>    If a cache which supports version N receives a query with Protocol
>    Version Q < N, the cache MUST downgrade to protocol version Q,
>    [RFC6810] or [RFC8210], and respond with a Cache Response
>    (Section 5.5) of that Protocol Version and the session is considered
>    open.
> 
>    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.
> 
>    If the router requests Q == 0 and it still fails with the cache
>    sending an Error Report (Section 5.11) with Error Code 4
>    ("Unsupported Protocol Version"), then the router MUST abort the
>    transport connection.
> 
>    ...
> 
> i suspect it can be improved further, and of course i would like it
> smaller/simpler.  but first is this addressing your issue(s)?

Yes, this is much better.

I think paragraph 2 and 3 (both about Q < N) should be merged.
Current paragraph 4 makes the negotiation much clearer (but 'with a
Protocol Version Q of the version N in the Error Report' is a mouth full).
What is unclear what should happen when "unless it has already failed at
that version" comes into play? Should it abort like in the last paragraph?

Now this changes the sematics of Error Code 4. So Section 13 needs to be
adjusted. Error code 4 should not be fatal but have special handling as
described in Section 7. This is required because:
   Errors which are considered fatal MUST cause the session to be dropped,
   and the router MUST flush all data learned from that cache.

-- 
:wq Claudio