Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Barbara,

Thanks for the extra reminder, and sorry for needing it.

I think the -12 addresses most of my concerns, but we may need to talk a
bit more about the HMAC key length topic -- I'm having a hard time matching
the stated justification with my understanding of the facts.

More inline...

On Wed, Feb 03, 2021 at 10:31:12PM +0000, STARK, BARBARA H wrote:
> Hi Ben (and IESG),
> I just wanted to mention that I did publish a -12 draft that I think resolves all comments (in the manner I said I would in my various responses). 
> https://tools.ietf.org/html/draft-ietf-babel-information-model-12
> Looking forward to getting these Discusses cleared... 😊
> Thx,
> Barbara
> 
> > Hi Ben,
> > Thanks a bunch for your comments. I'm sorry it's taken me a few weeks to
> > provide a response. But, well, NomCom... 😊

Thank you (and NomCom) for your service!

> > And I wanted to give these comments the full attention they deserved.
> > Barbara
> > 
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > Section 2 says that the "DTLS certificate values" are required to return
> > > no value when read, but this property seems to be intended for private
> > > data such as DTLS private key values, not the certificates themselves
> > > (which are public).
> > 
> > Thanks. I agree and suggest in Section 2, changing "DTLS certificate values" to
> > "DTLS private keys" (which are required to return no value when read).
> > 
> > > While I appreciate that IPv6 is the current version of the internet
> > > protocol, I do see that 6126bis allows for Babel to run over both IPv6
> > > and IPv4, yet this document in multiple places implicitly assumes that
> > > Babel runs over IPv6, to the exclusion of IPv4.  Such a restriction from
> > > the core protocol spec should only be undertaken by an information model
> > > with clear reasoning and loud disclaimer.
> > 
> > The WG did discuss this and expressed the view that they were only interested
> > in defining configuration for Babel over IPv6. Note that use of Babel to
> > configure
> > IPv4 routing tables can be done over IPv6.
> > 
> > Perhaps if we added to the Abstract <Juliusz: please look at this and provide
> > suggested changes>:
> > "This information model only includes parameters and parameter values
> > useful for managing Babel over IPv6.
> > This model has no parameters or values specific to operating Babel
> > over IPv4, although Babel can be operated over IPv4.
> > Note that Babel over IPv6 can be used for configuration of both
> > IPv4 and IPv6 routes."
> > 
> > and then expand on this in the Introduction with
> > "This information model only includes parameters and parameter values
> > useful for managing Babel over IPv6.
> > This model has no parameters or values specific to operating Babel
> > over IPv4, even though [ID.ietf-babel-rfc6126bis] does define a multicast
> > group for sending and listening to multicast announcements on IPv4.
> > There is less likelihood of breakage due to
> > inconsistent configuration and increased implementation simplicity
> > if Babel is operated always and only over IPv6. Running Babel over IPv6
> > requires IPv6 at the link layer and does not need advertised prefixes, router
> > advertisements or DHCPv6 to be present in the network. Link-local IPv6 is widely
> > supported among devices where Babel is expected to be used.
> > Note that Babel over IPv6 can be used for configuration of both
> > IPv4 and IPv6 routes."
> > 
> > > Similarly (as Roman notes), we are putting requirements on the key
> > > length for MAC keys (relative to the block size of the underlying hash
> > > function) that have were once present in draft-ietf-babel-hmac but have
> > > been removed as of draft-ietf-babel-hmac-10.  I assume that the intent
> > > is not to impose additional restrictions compared to the protocol spec,
> > > thus we need to catch up to those changes.
> > 
> > How humans interact with configuration parameters presented through
> > a data model instantiation of this information model is a concern. Having
> > experienced the horrors of the days of configuring WEP keys (which were
> > either ASCII or hex and caused most people not to use WEP with Wi-Fi)
> > and witnessed (and been party to) the discussions in
> > Babel where we wanted to ensure that whatever string was inputted for
> > the key would yield consistent MAC computation across all implementations
> > (i.e.,
> > would yield consistent "actual key"), I believe
> > it is imperative for the information model to constrain the input. As I explained
> > in my response to Roman and Valery, we saw considerable variability in
> > how existing libraries for allowing users to supply a key value treated
> > values that could not be directly used as what RFC 2104 calls "the actual key".
> > To ensure human users are successful in supplying the same "actual key" value
> > to various
> > implementations, it's necessary for user interfaces to restrict what is
> > supplied to be "the actual key" so no extraneous hashing and processing
> > is needed to generate "the actual key" (other than adding zeroes if the input
> > key is shorter than an "actual key").

These are all important considerations, and I am glad that you are keeping
them in mind (while simultaneously being sad that they are necessary).
But they seem to mostly be concers with the translation layer between the
input layer and the cryptographic API, and the restrictions that I am
concerned about are ones that relate to processing done within the
cryptographic API boundary.

> > The restrictions provided for the length of an input key are consistent with
> > what the HMAC and BLAKE RFCs indicate for "actual key" length.
> > 
> > This allows implementations of draft-ietf-babel-hmac to use existing HMAC
> > and BLAKE2s libraries without worrying about what inconsistent manipulations
> > the libraries or associated libraries for inputting keys do to strings that are
> > too long to be directly used as "actual keys".

In particular, the procedures for using an HMAC key longer than the block
length of the underlying hash function (hash the key first) are
longstanding and well-implemented.  Are you saying that you have
experiences with buggy HMAC implementations that don't do this?  (If so,
that would be a great tidbit to mention in the document as motivation.)

The situation for Blake2s-128 (which is being used directly and not via
HMAC) is not quite so clear to me since it's a more recent innovation, and
RFC 7693 seems rather unclear about what to do if the input key is larger
than 64 bytes (it talks only of padding the key and setting as d[0], where
d[0] is a 16-word block, and for Blake2s words are 32 bits).  So while
limiting the length of the Blake2s key may be justified in fact, (1) that
justification should probably be in the document, and (2) I don't see a
factual basis for limiting HMAC keys to the block length.

(For what it's worth I did do a bit of math, and even if the "actual key"
is limited to uppercase letters plus digits, a 64-character string can
still contain some 330 bits of entropy, which is stronger than a 32-byte
random string.  You'd have to be really limited in what characters can be
used, e.g., to only digits, in order to have the maximum theoretical
entropy of the 64-character string fall below 256 bits.)

> > > The description of the babel-mac-key-test and babel-cert-test operations
> > > need to be tightened up, as the secdir reviewer noted.  (See COMMENT.)
> > 
> > I think the secdir comments from Valery have been resolved.
> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/V_SK
> > LuCuLdwvCDhABW-
> > G2kkgRHM/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP7LOUxbeJ9rcLXe
> > V-GmWLYZzG81V3Sb0x$
> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/_FX7
> > GJpGDhMxBN1Ps0_opo2mn68/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1X
> > fAP7LOUxbeJ9rcLXeV-GmWLYZzG84l2CSUL$
> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/eSC-
> > 7ApMvv0CulyawvA0AILB59w/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfA
> > P7LOUxbeJ9rcLXeV-GmWLYZzG8y_rmrGw$
> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/90Yc
> > yVcS90Ya449tT0Zibc6Fb9o/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP7
> > LOUxbeJ9rcLXeV-GmWLYZzG8-863vKO$
> > 
> > Summary: Remove babel-cert-test; use "MAC" instead of "hash" in
> > babel-mac-key-test description.
> > Please let me know if you disagree with this resolution.
> > 
> > > We seem to be using terminology from the Network Management Datastore
> > > Architecture without reference or otherwise introducing the concepts.
> > > This is a Discuss point because the only candidate reference I know of,
> > > RFC 8342, is specific to YANG and data models, so it's applicability for
> > > use in an information model may be subject to discussion.  (Hopefully
> > > this only reflects my ignorance and not a fundamental lack of datastore
> > > architecture for information models.)
> > 
> > I'm still a YANG novice. My experience is with BBF TR-181 data models.
> > I do have a TR-181 data model of this info model that will be published
> > after the info model is published. I also considered the UIs created by the
> > Babel protocol implementers to effectively be implementations of the info
> > model. But of these, YANG does appear to be unique in maintaining distinct
> > representation of operational and running configuration datastores.
> > In researching the terminology
> > (see
> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/babel/Ze2E
> > tZEidcE7t2WMF2EqblBJN7I/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP
> > 7LOUxbeJ9rcLXeV-GmWLYZzG89hknV3y$
> > reply to Robert Wilton),
> > it appears to me that "operational datastore" and "datastore" are terms of art
> > defined
> > in techopedia.com without reference to YANG. The dates on those definitions is
> > 2013,
> > which predates RFC8342. "Running datastore" was used in RFC6241, which also
> > predates RFC8342. As I mentioned in my reply to Robert Wilton,
> > I don't think a normative reference to RFC 8342 is appropriate for what appear
> > to be
> > terms of art. There is no terminology section in the babel-information-model
> > draft, and I'm not keen on adding a terminology
> > section to the draft just for these 2 terms of art.
> > But I would do that (and maybe find a few other terms of art to include
> > so they don't seem out of place), if people really felt it necessary to define
> > these.

Thank you for the education, and apologies for not having looked harder!

> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > Section 1.1
> > >
> > > Please use the specific RFC 8174 boilerplate (in particular, it includes
> > > "NOT RECOMMENDED").
> > 
> > Thanks. I'll make that change. (This was also a comment from Barry.)
> > 
> > > Section 2
> > >
> > > We have separate MAC/DTLS-enablement nodes at a per-interface
> > > level, so not having them at the global level is perhaps suprising.
> > 
> > This was discussed, IIRC, and the WG wanted it at the per-interface
> > level only. In addition to the YANG and TR-181 data models, I
> > considered the implementation user interfaces to also be instantiations
> > of this information model. So many decisions were made based on what
> > they found reasonable when implementing their UIs.
> > 
> > > I'm happy to see babel-dtls-cert-types, given that the babel/DTLS spec
> > > leaves much open as to how to authenticate peers.  Even more specificity
> > > could be useful.
> > >
> > >    Most parameters are read-only.  Following is a descriptive list of
> > >    the parameters that are not required to be read-only:
> > >
> > > It's suprising to not see router-id on this list; 6126bis says only that
> > > "every Babel speaker is assigned a router-id" without saying how.  In
> > > the absence of a "how", it seems reasonable to assume "assigned by the
> > > administrator" as a valid option.
> > 
> > The WG discussed this. There are two points here. First is that the self-router-id
> > is useful as a unique key in YANG. But in that case, the value needs to exist and
> > be
> > immutable when the Babel object is created in the system. Second is that
> > Babel users do not care about the value of the router-id; therefore it's
> > easiest simply to auto-generate it.
> > 
> > > How do I configure which prefixes to advertise as originated from this
> > > router?  Do I just add something to the babel-routes list with NULL
> > > received metric?  But if that's how I do it, then the babel-route-obj
> > > can't be 'ro'...
> > 
> > Section 3.7 of draft-ietf-babel-rfc6126bis indicates that a Babel
> > implementation has the ability to advertise and provide updates
> > for routes injected into the Babel domain by the local node. I
> > believe the Babel implementation interacts with the device's
> > "real" routing table to identify these routes (and to update
> > that routing table). Since this is all handled by the implementation
> > without user interaction, perhaps Juliusz could better explain,
> > if necessary.

Ah, so this would be managed by the "real" routing configuration, not
something babel-specific; that's good enough for me.

> > >    o  Interface: Metric algorithm
> > >
> > >    o  Interface: Split horizon
> > >
> > >    o  Interface: enable/disable Babel on this interface
> > >    [...]
> > >
> > > It might be useful to list these in the same order as they appear in the
> > > tree diagram.
> > 
> > Thanks. I will put them in the same order as in the object definition
> > (which is the same as the tree diagram, but the object definition is
> > normative if there were to be a difference).
> > 
> > >    o  Interface: MAC algorithm
> > >
> > > What node in the tree does this correspond to?
> > 
> > Thanks. I'll delete "  o  Interface: MAC algorithm".
> > It's an unfortunate vestige of earlier revisions.

(For your amusement, I noted that this was gone when looking at the diff,
but forgot that it was done at my behest!)

> > > Section 3.1
> > >
> > >    babel-enable:  When written, it configures whether the protocol
> > >       should be enabled (true) or disabled (false).  A read from the
> > >       running or intended datastore indicates the configured
> > >       administrative value of whether the protocol is enabled (true) or
> > >       not (false).  A read from the operational datastore indicates
> > >
> > > Perhaps it's just me, but running/intended/operational datastores feels
> > > like a YANG/NMDA thing and is surprising to see in a nominally generic
> > > information model, absent further reference.
> > > (Similarly for subsequent usage of the terms.)
> > 
> > This was language we added as a comment from Mahesh to make his
> > creation of the YANG model straightforward. It's not inconsistent with TR-181
> > concepts. But this is an area where TR-181 and YANG do things a little
> > differently. Language compromise was necessary. I will rely on Mahesh
> > to take a first stab at proposing any changes, and will simply make sure
> > what I need for TR-181 is still there. I do recommend against a NMDA
> > reference, since my research suggests these are terms of art.
> > 
> > >    babel-self-router-id:  The router-id used by this instance of the
> > >       Babel protocol to identify itself.  [I-D.ietf-babel-rfc6126bis]
> > >       describes this as an arbitrary string of 8 octets.  The router-id
> > >       value MUST NOT consist of all zeroes or all ones.
> > >
> > > Why is the MUST NOT a requirement of the information model rather than
> > > the protocol?
> > 
> > Because it isn't an issue for a Babel implementation that doesn't implement
> > this information model. It only became an issue when the YANG model
> > needed to use this as a unique key and needed the object to exist whether
> > or not Babel was enabled. In the absence of YANG, a disabled implementation
> > is happy for its router-id to be all zeroes.

I'd consider adding a parenthetical to explain why the requirement exists,
but that's editorial and up to your judgment.

> > >    babel-metric-comp-algorithms:  List of supported cost computation
> > >       algorithms.  Possible values include "2-out-of-3", and "ETX". "2-
> > >       out-of-3" is described in [I-D.ietf-babel-rfc6126bis], section
> > >       A.2.1.  "ETX" is described in [I-D.ietf-babel-rfc6126bis], section
> > >       A.2.2.
> > >
> > > Perhaps this is just me, but the way this is written implies that the
> > > specific string values are to be used, which may be overly prescriptive
> > > for an information model.  Also, is there a registry for these
> > > algorithms that could be referenced?
> > 
> > There is not a registry. The algorithms an implementation supports
> > do not impact interoperability of Babel. Therefore, there is no need
> > for a Babel implementation to only use algorithms from some registered
> > list. Which makes a registry unnecessary. If an implementation supports
> > these algorithms loosely described in
> > ietf-babel-rfc6126bis, then using these strings to identify them
> > will make that clear to a user (which is good for usability). It's not
> > required for a data model to use these exact strings (a human is unlikely
> > to be confused by an implementation that uses "2 out of 3" instead of
> > "2-out-of-3", but, not surprisingly,
> > both the YANG and TR-181 data models are using these exact strings.
> > 
> > >    babel-security-supported:  List of supported security mechanisms.
> > >       Possible values include "MAC" and "DTLS".
> > >
> > >    babel-mac-algorithms:  List of supported MAC computation algorithms.
> > >       Possible values include "HMAC-SHA256", "BLAKE2s".
> > >
> > >    babel-dtls-cert-types:  List of supported DTLS certificate types.
> > >       Possible values include "X.509" and "RawPublicKey".
> > >
> > > Likewise, are there registries for these?  (D)TLS does have an existing
> > > certificate types registry
> > > (<url munged by email system>
> > > is the one to use), but for the MAC algorithms that's pretty inherently
> > > a very flexible extension point so it's easy to add a new algorithm with
> > > no or a very minimal written spec.
> > 
> > Per other commenters, I will be adding references to these to
> > draft-ietf-babel-hmac and draft-ietf-babel-dtls.
> > The babel hmac draft has normative language for the two mentioned.
> > The babel-dtls draft inherits from DTLS, which inherits from TLS
> > "The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated
> > otherwise"
> > -- so there's an expectation that X.509(v3) certs will be commonly supported.
> > babel-dtls also explicitly mentions that raw public keys "can" be supported.
> > The MAC algorithms and types of certificates supported are determined by
> > by the implementations of babel-hmac and babel-dtls. Those implementations
> > will need to expose to the data model (by some sort of API, most likely) which
> > are supported. The values used may be the values exposed, or they may be
> > mapped
> > from exposed values to values used by the data model. The information model
> > cannot constrain values exposed to it by APIs.
> > The problem with using the TLS Certificate Types registry names is several of the
> > names
> > have spaces, which makes them unusable in TR-181. It's not required for
> > an instantiation of this info model to use these "possible" values; but, again,
> > both the
> > YANG and TR-181 do. By listing them this way (as possible values, not using
> > normative language), we achieve consistency where
> > it makes sense and is useful without preventing deviation in some case where
> > it may not be useful or make sense.

Thanks; this makes sense to me and the references to the respective drafts
are helpful.

> > > Section 3.2
> > >
> > >    babel-mcast-group:  Multicast group for sending and listening to
> > >       multicast announcements on IPv6.  Default is ff02::1:6.  An
> > >
> > > IIRC the core protocol only has it as RECOMMENDED for control traffic to
> > > be over IPv6; the "on IPv6" here seems unnecessarily limiting.
> > 
> > This was what the WG wanted but is related to your 2nd DISCUSS item (and
> > my proposed resolution to that).
> > 
> > > Section 3.3
> > >
> > >    babel-interface-reference:  Reference to an interface object that can
> > >       be used to send and receive IPv6 packets, as defined by the data
> > >
> > > [again the implicit IPv6 requirement]
> > >
> > >    babel-mcast-hello-interval:  The current interval in use for
> > >       multicast Hellos sent on this interface.  Units are centiseconds.
> > >       This is a 16-bit unsigned integer.
> > >
> > > Perhaps it is better to discuss that the units need to have sufficient
> > > precision to represent centisecond granularity rather than to enforce a
> > > specific unit and constrain data models/implementations.
> > > (Similarly for other mentions of units.)
> > 
> > This value is the exact value sent via the protocol. The centisecond unit
> > of the sent value is specified in draft-ietf-babel-rfc6126bis. I believe it
> > would be a bad idea to manipulate the sent value so it is presented to users
> > with a unit different from the unit of the sent value. Having the info
> > model provide flexibility that does not exist in the Babel protocol would
> > add unnecessary complexity and cause potential confusion.
> > 
> > >    babel-dtls-cached-info:  Indicates whether the cached_info extension
> > >       is included in ClientHello and ServerHello packets.  The extension
> > >
> > > Please reference RFC 7924 here.
> > 
> > I would prefer to reference draft-ietf-babel-dtls, which in turn references
> > RFC7924, because draft-ietf-babel-dtls describes allowed use of this extension.

I'm not seeing a whole lot of additional discussion in RFC 8968 with the
RFC 7924 reference (and definitely not normative restrictions on what 7924
allows) ... but your opinion prevails.

> > >       is included if the value is "true".  An implementation MAY choose
> > >       to expose this parameter as read-only ("ro").
> > >
> > > I wonder if we can/should give a bit more guidance on what to include in
> > > the extension, as currently it would be compliant with this spec (but
> > > not very useful) to emit a cached_information extension that is highly
> > > unlikely to result in any packet size savings.
> > 
> > Possible use of this extension is described in draft-ietf-babel-dtls Appendix A.
> > I don't think the information model is the appropriate place to provide
> > implementation guidance for this extension. draft-ietf-babel-dtls would
> > be the correct place for any additional implementation guidance. I think
> > draft-ietf-babel-dtls is currently in the RFC Editor's queue.
> > 
> > >    babel-dtls-cert-prefer:  List of supported certificate types, in
> > >       order of preference.  The values MUST be among those listed in the
> > >       babel-dtls-cert-types parameter.  This list is used to populate
> > >       the server_certificate_type extension in a Client Hello.  Values
> > >
> > > An RFC 7250 reference is probably in order.
> > 
> > I would prefer to have a reference to draft-ietf-babel-dtls. That is
> > where the certificate types for a Babel DTLS implementation are
> > discussed. draft-ietf-babel-dtls does reference RFC7250. An
> > understanding of RFC7250 is not necessary for implementing
> > this information model or any data model derived from it.

(ditto)

> > >    babel-packet-log:  A reference or url link to a file that contains a
> > >       timestamped log of packets received and sent on babel-udp-port on
> > >       this interface.  The [libpcap] file format with .pcap file
> > >       extension SHOULD be supported for packet log files.  Logging is
> > >
> > > Does there need to be a mechanism for content-type
> > > negotiation/indication?
> > 
> > The format for this optional log was discussed by the WG. After
> > considering a variety of ways to proceed, this was the agreed outcome.
> > Adding content type negotiation would add unnecessary complexity,
> > since it's unlikely that an implementation would support more than one
> > content type.
> > 
> > > Section 3.4
> > >
> > > Shouldn't these all be 'counter's, not 'uint's?
> > 
> > Hmm. Interesting.
> > It looks like I introduced "counter" as a (potential) base type in the -01
> > draft (when I was sole author and there were no statistics yet defined). I
> > just took all the data types in RFC8193 that looked like they might prove
> > useful at some point.
> > It appears to be a vestige of that early draft stage that never got used.
> > uint is perfectly suitable from an info model perspective. Of course,
> > a data model can use a more specific datatype derived from uint, that
> > is specially designed for counted statistics.
> > I suggest deleting the "counter" data type, but will check with Mahesh
> > just to be safe.
> > 
> > > Section 3.5
> > >
> > >    babel-hello-mcast-history:  The multicast Hello history of whether or
> > >       not the multicast Hello packets prior to babel-exp-mcast-hello-
> > >       seqno were received.  A binary sequence where the most recently
> > >       received Hello is expressed as a "1" placed in the left-most bit,
> > >
> > > This seems to indicate that the leftmost bit is always '1', and thus
> > > that we cannot be in a situation where we missed one expected multicast
> > > hello and are already expecting "the one after it".  Is that correct?
> > 
> > Yes. An implementation won't know it has missed one until it receives a Hello
> > with a non-sequential sequence number. The number of missed packets
> > is derived from the difference between the sequence numbers of 2 received
> > packets. One of the implementations provided the history in this manner and
> > found it to be a very simple way to present this information. It proved useful
> > as a diagnostics tool. So the WG agreed to put it in the info model as an
> > optional element.
> > 
> > > Also, should we say anything about truncating the bitstring at some
> > > arbitrary point?
> > >
> > > (Similarly for the unicast case, on both counts.)
> > 
> > This was discussed by the WG. The implementation that provided the
> > history in this manner used 16 bits. But it was decided not to constrain
> > a data model or implementation that might want to allow more bits to be
> > stored. So the maximum number of history bits stored is left up to the
> > data model and the implementation.
> > 
> > >    babel-exp-ucast-hello-seqno:  Expected unicast Hello sequence number
> > >       of next Hello to be received from this neighbor.  If unicast Hello
> > >       packets are not expected, or processing of unicast packets is not
> > >       enabled, this MUST be NULL.  This is a 16-bit unsigned integer; if
> > >
> > > (We haven't defined "NULL" semantics yet.)
> > 
> > I'm unclear as to what sort of semantics are needed? In discussing this
> > verbiage in the context of terminology that would work for TR-181 and
> > YANG, we figured out we needed to ensure there was a distinction between
> > seqno of all zeroes (an allowed value) and no reception/expectation of
> > unicast packets. How this is done in YANG and TR-181 is very different.
> > So it's important not to over-define the semantics of "NULL".
> > 
> > > Section 3.6
> > >
> > >    babel-route-neighbor:  Reference to the babel-neighbors entry for the
> > >       neighbor that advertised this route.
> > >
> > > Wouldn't that make this a "reference" type rather than "string"?
> > 
> > Yes. I'll make that change. Thx.
> > 
> > >    babel-route-seqno:  The sequence number with which this route was
> > >       advertised.  This is a 16-bit unsigned integer.
> > >
> > > Is this text correct for locally originated routes?
> > 
> > Yes. The babel-route-obj allows read-only access to useful parts of the Babel
> > "Routing Table" described in draft-ietf-babel-rfc6126bis. Parameters that an
> > implementation includes in the Babel "Routing Table" are defined there. This
> > Babel "Routing Table" must not be confused with a device's routing table
> > that would be maintained external to a Babel implementation.
> > 
> > > Section 3.7
> > >
> > > I don't wish to revisit the decision, but it might have been interesting
> > > to record some of the reasoning for having an additional abstraction for
> > > "key set" and having a list of key-sets, vs just having a list of keys
> > > directly.  (Similarly for the DTLS cert sets.)
> > 
> > There were requirements that it be possible to use different keys for
> > different interfaces, the same keys for a set of interfaces, the same
> > keys for all interfaces, and have a default set of keys in case a new
> > interface were instantiated (e.g., a tunneled interface). Also, there
> > was a requirement that it be easy to change the current key by first
> > adding the new key and then removing the old key. By having key sets,
> > it was easy to do a key change without explicitly adding the new
> > key to and deleting the old key from each impacted interface. Only
> > the key set needed to be updated. Ditto for certs. If this explanation is
> > useful, I could add a paragraph explaining the sets as useful in making

I found it useful, at least -- thank you!

> > it easy to change keys/certs to Security Considerations. Ensuring usability
> > of key/cert change is, I think, a valid security consideration.

I agree; this is covered (somewhat) in BCP 107.

> > > Section 3.8
> > >
> > >    babel-mac-key-use-sign:  Indicates whether this key value is used to
> > >       sign sent Babel packets.  Sent packets are signed using this key
> > >       if the value is "true".  If the value is "false", this key is not
> > >
> > > I agree with the secdir reviewer that the "sign" terminology is
> > > problematic here, and would prefer something like
> > > "babel-mac-key-use-generate" and a similar wording in the prose.
> > 
> > In email exchange with Valery, it was agreed to rename this to
> > babel-mac-key-use-send.
> > 
> > >    babel-mac-key-value:  The value of the MAC key.  An implementation
> > >       MUST NOT allow this parameter to be read.  This can be done by
> > >       always providing an empty string when read, or through
> > >       permissions, or other means.  This value MUST be provided when
> > >       this instance is created, and is not subsequently writable.  This
> > >       value is of a length suitable for the associated babel-mac-key-
> > >       algorithm.  If the algorithm is based on the HMAC construction
> > >       [RFC2104], the length MUST be between 0 and the block size of the
> > >       underlying hash inclusive (where "HMAC-SHA256" block size is 64
> > >       bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s",
> > >       the length MUST be between 0 and 32 bytes inclusive, as described
> > >       in [RFC7693].
> > >
> > > [Per the Discuss, this key-length guidance is not aligned with
> > > draft-ietf-babel-hmac.]
> > 
> > I defer to my explanation above (under the DISCUSS).
> > 
> > >    babel-mac-key-test:  An operation that allows the MAC key and hash
> > >       algorithm to be tested to see if they produce an expected outcome.
> > >       Input to this operation is a binary string.  The implementation is
> > >       expected to create a hash of this string using the babel-mac-key-
> > >       value and the babel-mac-key-algorithm.  The output of this
> > >       operation is the resulting hash, as a binary string.
> > >
> > > s/create a hash of/create a MAC over/
> > > s/resulting hash/resulting MAC value/
> > 
> > Thx. Will do.
> > 
> > > Given that the intent is to test the MAC operation, it seems like we
> > > might want to say that the input string is treated as a babel packet,
> > > getting the pseudo-header added per draft-ietf-babel-hmac §4.1, etc.
> > > It would be in keeping with cryptographic best practice to continue to
> > > use the same pseudo-header (and possibly even include a disambiguating
> > > context string) to avoid the risk of being an oracle for generating the
> > > MAC of arbitrary text that could then be used to forge other packets
> > > elsewhere.
> > 
> > Since the entity that can use the test can also directly set the key, I'm not
> > sure of the use case for an entity with management permissions to
> > perform such an attack. But I agree that the test could easily be made
> > more secure, so it's a good idea to do so. I've thought about your suggestion
> > of treating the input string as a babel packet; but I think that gets very
> > complicated because of the behaviors around packet counters and index and
> > generation of pseudo headers (the management interface IP addresses and
> > ports may be unknown to a Babel implementation and including IP headers in
> > this test string makes it even more complicated). So the same code couldn't
> > really be used).
> > What if we had 2 inputs: the binary string and the expected MAC?
> > Then the output would just be success (input expected
> > MAC = calculated MAC) or failure. Would something like this be better?
> > Alternately (though I would prefer it less), we could have the input string
> > just be the expected MAC, where the binary string to generate a MAC for
> > would be defined here. The string could be something simple like
> > the concatenation of the registered Babel multicast group (ff02::1:6)
> > and UDP port (6696).

What you put in the -12 (provide both input and expected MAC; get back
success/failure) has much improved security properties in this regard;
thank you!

> > > As the secdir review noted, the MAC output length is not necessarily
> > > fixed by the algorithm, so some indicatino of the output length is also
> > > in order.
> > 
> > The WG has discussed making 128 bits recommended for BLAKE2s
> > (change will be made in AUTH48 to draft-ietf-babel-hmac) and
> > the corresponding possible configuration value in this model will be
> > "BLAKE2s-128".
> > 
> > > Section 3.10
> > >
> > >    babel-cert-name:  A unique name for this DTLS certificate that can be
> > >       used to identify the certificate in this object instance, since
> > >       the value is too long to be useful for identification.  This value
> > >
> > > Some guidance on whether or not it is expected to be useful to draw
> > > naming information from the certificate's Subject information, vs an
> > > arbitrary or fingerprint-based naming scheme, might be in order.
> > 
> > All constraints from an info model perspective are provided in the
> > description: unique and not empty. An implementation that supports
> > auto-generation of the name can use whatever rules it wants.
> > My TR-181 data model will allow the user to provide any unique and
> > non-empty string they want. If the user provides none, the
> > auto-generation scheme is implementation-specific and common
> > across the entire TR-181 data model (and not just Babel). I think it
> > would be odd to explicitly call out the absence of additional requirements
> > or expectations. Unless pressed, I will make no change here.

I don't have any specific text that I want to press for, but I will
reiterate that when names are used for making authentication and
authorization decisions, it is critically important that everyone involved
agrees on what name maps to what entity!  I presume that the TR-181 scheme
is not susceptible to collisions on the auto-generated names...

> > > Also, it's somewhat unusual to talk about "(D)TLS certificates" as
> > > opposed to X.509 certificate, raw public key, etc..
> > 
> > The TLS RFCs refer to these things as "certificates" in all cases, and
> > the IANA registry that lists defined types of these things is titled
> > "TLS Certificate Types". This info model table is defined so it should be
> > possible for other certificate types to be supported (if desired or
> > implemented) with no change to this table structure -- so long as
> > the certificate can be expressed in PEM format. If "DTLS certificate"
> > is not acceptable, I could change to just "certificate". I don't want
> > to constrain what type of certificate this table can support, beyond
> > PEM format and for use with an implementation of draft-ietf-babel-dtls.

I would (mildly) prefer just "certificate" -- in my mind, certificates are
things that (D)TLS consumes, but other than having a list of preexisting
certificate types for which the mapping into TLS codepoints, there is
nothing (*) TLS-specific about those certificates.

(*) okay, X.509 certificates  might have an extendedKeyUsage extension that
indicates they are intended for TLS connections, but they are still X.509
certificates.

> > >    babel-cert-test:  An operation that allows a hash of the provided
> > >       input string to be created using the certificate public key and
> > >       the SHA-256 hash algorithm.  Input to this operation is a binary
> > >       string.  The output of this operation is the resulting hash, as a
> > >       binary string.
> > >
> > > This is problematic in several ways, as noted by the secdir reviewer.
> > > For one, if we want to test a certificate, we usually would do that by
> > > producing a signature, not a hash over the public key and some other
> > > input.  Furthermore, not all the signatures produced by X.509 certificates
> > > compatible with DTLS require a hash at all or are allowed to use SHA-256
> > > within the signature operation.  It may be possible to require SHA-256
> > > always by having the input to the signature operation be the SHA-256
> > > output, which would then be hashed again during the process of computing
> > > an (e.g., RSA) signature, but that is also a bit weird.
> > > The purpose of the operation needs to be made more clear (is it to
> > > verify the public key?  The private key?) as well as how the input is
> > > structured; if the certificate private key is used to generate a
> > > signature we must take care to avoid producing a signing oracle that can
> > > be used to produce signatures valid in other contexts.
> > 
> > It was agreed (with Valery) to delete this operation.
> > 
> > > Section 5
> > >
> > > We do expose an operation to get a packet dump, but it's not clear that
> > > there are particularly noteworthy security considerations regarding that
> > > -- the dump would appear to be the ciphertext based on the language
> > > used, so it would not be a way to bypass DTLS encryption, for example.
> > >
> > >    This information model defines objects that can allow credentials
> > >    (for this device, for trusted devices, and for trusted certificate
> > >    authorities) to be added and deleted.  Public keys may be exposed
> > >    through this model.  This model requires that private keys never be
> > >
> > > It might be worth another sentence indicating the scale of the
> > > consequences of erroneously/maliciously setting such credentials.
> > 
> > I'm not quite sure what to say? "Incorrect configuration of credentials
> > (whether in error or in malice) will cause the Babel packets between
> > the incorrectly configured router(s) and other routers in the network
> > not to be trusted by each other. It will not be possible to effectively
> > use Babel to determine and react to routing changes in the network,
> > in this case."

Or just "incorrect provision of credentials (whether due to error or
malice) will cause a denial of service condition for the Babel routing
protocol on the node in question".  It may seem obvious to you and I, but I
find that it can be useful to have it stated explicitly.

> > >    exposed.  The Babel security mechanisms that make use of these
> > >    credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac])
> > >    identify what credentials can be used with those mechanisms.
> > >
> > > The DTLS one really doesn't, though -- it says only something like
> > > "details of identity management are left to deployment profiles", and
> > > there's a wide variety of DTLS credentials that are possible.
> > > The MAC mechanism has a much clearer picture about what is allowed by
> > > virtue of using the raw crypto primitive (though the allowed MAC
> > > algorithms are negotiated out-of-band there as well).
> > 
> > Perhaps: "The keys used by a [ID:ietf-babel-hmac] implementation are
> > modeled as private keys. Certificates used by a [I-D.ietf-babel-dtls]
> > implementations use separate parameters to model the public parts
> > (including the public key) and the private key."
> > 
> > >    algorithm associated with the key.  Short (and zero-length) keys and
> > >    keys that make use of only alphanumeric characters are highly
> > >    susceptible to brute force attacks.
> > >
> > > I don't think it's true to say that "keys that make use of only
> > > alphanumeric characters are highly susceptible to brute force attacks".
> > > Even if I stick to a 32-byte key, `dd if=/dev/random bs=1
> > > count=24|openssl base64` is giving me 192 bits of randomness, which is
> > > plenty for a modern security protocol.  I think you mean to say that
> > > short keys are especially susceptible to brute-force when they only use
> > > alphanumeric characters.
> > 
> > Perhaps simplify this to: "Short (and zero-length) keys are highly
> >    susceptible to brute force attacks."
> > 
> > > Section 8.2
> > >
> > > Per
> > >
> > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/stateme
> > nts/normative-informative-
> > references/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP7LOUxbeJ9rcLXe
> > V-GmWLYZzG80lrR5aI$  even
> > > optional features like DTLS, MAC, RFC 3339 timestasmps, etc., should be
> > > listed as normative references.
> > 
> > Thx. I'll be moving the following references from informative to normative:
> > [I-D.ietf-babel-dtls]
> > [I-D.ietf-babel-hmac]
> > [ISO.10646] (Unicode character definition)
> > [RFC2104] (HMAC)
> > [RFC3339] (Timestamps)
> > [RFC4868] (HMAC-SHA-256)
> > [RFC7693] (BLAKE2s)

Thanks for all of the updates throughout -- there are many good changes
and clarifications that I did not comment on specifically, but are much
appreciated!

-Ben