Re: [core] Roman Danyliw's Discuss on draft-ietf-core-sid-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Roman Danyliw via Datatracker <[e-mail]> wrote:
    > ** Section 5.
    > Conceptually, SID files could be processed by less-constrained target
    > systems such as network management systems.  Such systems need to
    > take extra care to make sure that they are only processing SID files
    > from authoritative sources, as authoritative as the YANG modules that
    > they are using.

    > Thanks for flagging this as a security consideration.  Rob Wilton also
    > mentioned it in his ballot.  I’m a puzzled by this use case.  Is this
    > suggesting that “less constrained … systems” would download SID files based on
    > some kind of real-time input?  If so, this seems highly problematic because (a)
    > it could leak information to an outside party; and (b) seems like it could
    > cause a DDoS on the distributor of the SID files or even the system itself
    > (depending on the caching strategy). Is the use case here that the SID file
    > would be distributed “offline” by the system vendor or operator through
    > configuration making it more akin to the developer use case mentioned
    > previously?  I appreciate that CBOR is intended to be self-describing, but I’m
    > not sure how a network management system would be parsing arbitrary formats.

I think that there are several things in this.

1) yeah, a network management system could download the SID files
   from a central repo (iana.org/yangcatalog if necessary) when first
   interacting with some new device for the first time using CORECONF.

2) Yes, this could leak information to the logs of yangcatalog about who
   asked for what, when.  It would be better if the NMS vendor distributed
   things in some concentrated form, like tgz or zip.
   Or rsync.

3) Yes, this could be a DDoS against the SID file hosting service.  They are
   static files though, and it's over HTTPS, so I think that this is not a
   particularly new concern.

4) The NMS system won't be parsing abitrary CBOR: yang-cbor/RFC9254 defines
   some pretty regular CBOR that encodes things.  Okay, it's CBOR maps (with
   a few arrays) all the way down, but there isn't much more than that.
   The keys are all integers with delta encoding.
   It's morally equivalent to JSON or XML.  The SID files just let the NMS
   make sense of the resulting uint63s.
   Yes, one could construct some very deeping nested CBOR which might blow up
   a stack, but that's always a problem with all of these formats.

    } ** Section 6.5.3
    } After Working Group Adoption, any modification of a ".sid" file is
    } expected to be discussed on the mailing list of the appropriate
    } Working Groups.  SPECIFIC ATTENTION SHOULD BE PAID TO IMPLEMENTERS'
    } OPINION AFTER WORKING GROUP LAST CALL IF A SID VALUE IS TO CHANGE ITS
    } MEANING.  In all cases, a ".sid" file and the SIDs associated with it
    } are subject to change before the publication of an internet draft as
    } an RFC.

    > This text is here to bring clarity to an important issue, but it isn’t clear to
    > me what it is.  The text appears to be describing what is true for any
    > significant change to a WG document.

Upper-cased the specific concern.
Since SID numbers generally are baked into target system code, any change to
them might disrupt people's "running code".  But there are a bunch of changes
that actually don't affect things.
For instance, one can change the YANG leaf name without actually affecting
the meaning or SID number :-)

One thing that a WG probably wants to do at WGLC (or just before it), is to
throw away all "unstable" allocations, and reallocate them so that they are
in a contiguous group/range.  This definitely has affects on running code, so it
should be done *once*.   The reason they might not be contiguous is because
during the WG discussion leaves have been added/removed or had their types changed.

    > ** Section 6.5.3
    > Due to the difficulty in changing SID values during IETF document
    > processing, it is expected that most documents will ask for SID
    > allocations using Early Allocations [BCP100].   The details of the
    > Early Allocation should be included in any Working Group Adoption
    > call.
    > ...
    > In all cases, a ".sid" file and the SIDs associated with it
    > are subject to change before the publication of an internet draft as
    > an RFC.

    > -- I have no experience with early allocation of an IANA code point happening
    > concurrent with a WG adoption of a document.  Is that common?

I have seen it done, although I can't exactly name it.
I know that we asked for certain numbers in ANIMA to be allocated when it
became clear that the WG was going to do this work.  We needed those numbers
to do interoperation of running code, and WG adoption was the earliest we
were allowed to ask for that.

    > -- What difficulty is expected in changing SID values?

    > -- Why is early allocation happening if the draft is not stable (which seems
    > unlikely at adoption time)?

running code.
We expect that those writing running code understand that they might have to
revise their running code *adhoc*.  But, as a WG, we do need to manage the
process or people waste time debugging mis-matches.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide