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

["STARK, BARBARA H" <[e-mail]>]

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... 😊
> 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").
> 
> 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".
> 
> > 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.
> 
> > ----------------------------------------------------------------------
> > 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.
> 
> >    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.
> 
> > 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.
> 
> >    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.
> 
> > 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.
> 
> >       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.
> 
> >    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
> it easy to change keys/certs to Security Considerations. Ensuring usability
> of key/cert change is, I think, a valid security consideration.
> 
> > 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).
> 
> > 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.
> 
> > 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.
> 
> >    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."
> 
> >    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)
>