Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07

["Alvaro Retana (aretana)" <[e-mail]>]

On 4/26/16, 6:58 PM, "Rob Austein" <[e-mail]> 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.