[Sidrops] Roman Danyliw's Discuss on draft-ietf-sidrops-8210bis-08: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-sidrops-8210bis-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 5.11

   The diagnostic text is optional; if not present, the Length of Error
   Text field MUST be zero.  If error text is present, it MUST be a
   string in UTF-8 encoding (see [RFC3629]).

How does the protocol convey the language the diagnostic text?  Per Section 4.2
of BCP 18, “[p]rotocols that transfer text MUST provide for carrying
information about the language of that text.”

I appreciate that this behavior in v2 comes from v1 and v0.  How was it handled
previously?

** Section 7.  The guidance on error reporting seems inconsistent.

(a) Section 5.11 says “If error text is present, it MUST be a string in UTF-8
encoding”

(b) Section 7 says “in which case the Arbitrary Text field of the ERROR Report
PDU MUST be a list of one octet binary integers indicating the version numbers
the cache supports.”

The text in (b) seems to be describing an encoding inconsistent with the
guidance in (a).

** Section 9.  Use of TCP MD5.

   It is expected that, when the TCP Authentication Option (TCP-AO)
   [RFC5925] is available on all platforms deployed by operators, it
   will become the mandatory-to-implement transport.
         …
   *  Caches and routers MAY use TCP MD5 transport [RFC5925] using the
      rpki-rtr port.  Note that TCP MD5 has been obsoleted by TCP-AO
      [RFC5925].

The above text comes from RFC6810 (2013), repeated again in RFC8210 (2017) and
stated here (2022).  Why isn’t it appropriate 9 years later to drop support for
TCP MD5 in v2?  Can the operational considerations preventing older platforms
from staying with v1 be explained?

If there was a compelling operational reason, could the text be rewritten to
the effect of “TCP MD5 SHOULD NOT be used unless TLS, IPSec and SSH are NOT
supported.”

** Section 9.  Per the TLS guidance, is there a reason why conformance to
RFC7525 or draft-ietf-uta-rfc7525bis-07 cannot be required to ensure modern
version of TLS and secure ciphersuites.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Relationship with RFC8210.  I support Martin Duke's DISCUSS.

-- The abstracts says “This document updates and replaces RFC 8210.”  When I
read “replaces”, I took that to mean that RFC8210 is obsoleted by this document.

-- Section 1 says “This document updates [RFC8210].”  I found that confusing
because I don’t see how I need to read this document to implement v1 of the
protocol.  I was under the impression this was v2, something stand-alone.

** Section 4.  Per “It is configured with a semi-ordered list of caches …”,
what kind of data structure is “semi-ordered”?  Is this a priority list?

** Section 4.
   ... servers'
   clocks MUST be correct to a tolerance of approximately an hour.

How does an implementer reconcile the strict “MUST” guidance of “approximately
an hour” and still ensure interoperability?  What is the “tolerance” on
“approximately” -- 60 minutes and 1 second, 70 minutes, etc.  I recommend
s/approximately an hour/an hour/.

** Section 5.1.  Why do some fields have a data-type and others just text
description.  For example, “Protocol Version” is explicitly described as being
an 8-bit unsigned integer, but the text doesn’t say that a Serial number is
32-bits.

** Section 5.1.
      A cache increments its Serial Number when
      completing a rigorously validated update from a parent cache or
      the Global RPKI.

Is there are update which is not “rigorously validated”?  I’m trying to
understand if there are updates which don’t bump the serial number.

** Section 5.1.  With a 16-bit Session ID, how concerning or likely is a
collision?  Rob Wilton asked a similar question.  A few birthday paradox
approximations says 50% chance of a collision with 256 caches or 1% chance of
collision with 36 caches assuming they are randomly selected.

** Section 5.1
      A
      seconds-since-epoch timestamp value such as the POSIX time()
      function makes a good Session ID value.

What is the recommended approach to convert the POSIX time() result into the
smaller 16-bit value?

** Section 5.1.  Per the definition of a Provider AS Number, what is a
“spacified AFI”?

** Section 5.6, 5.7, and 5.10.  Editorial. In the PDU descriptions prior to
these, the section text opened with some notional description of who sends the
PDU and why.  Here, the section opens with a diagram and only covers a field
level description.

** Section 5.7.

Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.

What is mean by “… and no magic?”

** Section 5.10.  What is the Length of the PDU?  The figure suggests that the
Subject Key Info is a fixed 4 bytes which doesn’t seem right.

** Section 5.11.  The section doesn’t explicitly define the contents of the
“Encapsulated PDU” field.

** Section 9.1.  Per the SSH authentication information:
   User authentication MUST be supported; host
   authentication MAY be supported.  Implementations MAY support
   password authentication.

-- What is “user authentication”?    Per the authentication method names in
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-10,
there isn’t one called that.  Do you mean “publickey”?  Maybe:

NEW
User authentication (“publickey”) MUST be supported; host    authentication
(“hostbased”) MAY be supported.  Implementations MAY support password
authentication (“password”).

-- Since this text appears to be profiling SSH, and the this here comes from
Section 5 of RFC4252, should it be explicitly said that “none” MUST NOT be used.

** Section 9.2.

      The client router MUST set its "reference identifier" to the DNS
      name of the rpki-rtr cache.

What is a “reference identifier”?

** Section 9.3.

If TCP MD5 is used, implementations MUST support key lengths of at
   least 80 printable ASCII bytes, per Section 4.5 of [RFC5925].

RFC5925 doesn’t have a Section 4.5, or provide guidance about using printable
ASCII bytes

** Section 10.
This preference merely denotes proximity, not
   trust, preferred belief, et cetera.

“Proximity” to what?  I though this list was rank order list per the preference
value.

** Section 11.
When a cache is sending ROA PDUs to a router ...

I missed something.  What are ROA PDUs in this context?  Why are they not
defined in Section 5.

** Section 12.

   To keep load on Global RPKI services from unnecessary peaks, it is
   recommended that primary caches which load from the distributed
   Global RPKI not do so all at the same times, e.g., on the hour.

I’m trying to tie this recommendation for “primary caches” back to the three
deployment scenarios.  Is the ISP backbone the only one that operates a
“primary cache?”

** Section 13.  This error code text appears to be verbatim from RFC8210.  The
text also suggests that [iana-err] is the registry for these error code points.
 [iana-err] says the reference for these errors is RFC6810 for 0-7, and RFC8210
for 8.

If [iana-err] isn’t being updated to point to this text as the canonical
definition, then why repeat it here?  Couldn’t it just cite RFC8210?  What new
information is being added?

** Section 14.

      ... they need to be
      given consistent trust anchors to use in their internal validation
      process.  Distribution of a consistent trust anchor is assumed to
      be out of band.

-- Distributed to who?  Is it the routers?

-- What makes a trust anchor “consistent?”  Is the intent of this text to say
that in order to access a variety of caches, routers need the corresponding
trust anchors of these caches?

** Section 14.

      Hence, the last link, from cache to
      router, is secured by server authentication and transport-level
      security.

Please be clear that this is not always the case.  Section 9 allows for TCP.

** Section 14.

      The identity of the cache server SHOULD be verified and
      authenticated by the router client, and vice versa, before any
      data are exchanged.

(Excluding normal TCP) Are these verification and authentication practices
something different than specified by the protocol behavior in Section 9?  If
not, why the “SHOULD” as conformance to these protocols is a MUST.

** Section 14.  The text doesn't explicitly describe the risks of using an
unprotected TCP connection.

** Section 15.
   The policy for adding to the registry is RFC Required per [RFC8126];
   the document must be either Standards Track or Experimental.

Is this text needed?  The registry already says this is the policy.

** Section 15.

Protocol version 1 added one
   new error code:

              Error
              Code    Description
              -----   ---------------------------
                  8   Unexpected Protocol Version

Why is a change made by v1 germane to the IANA considerations of v2?  I don’t
think this text is needed.