Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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). 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. 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. 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.) 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.)
Section 1.1 Please use the specific RFC 8174 boilerplate (in particular, it includes "NOT RECOMMENDED"). 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. 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. 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'... 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. o Interface: MAC algorithm What node in the tree does this correspond to? 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.) 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? 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? 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 (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 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. 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. 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.) babel-dtls-cached-info: Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension Please reference RFC 7924 here. 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. 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. 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? Section 3.4 Shouldn't these all be 'counter's, not 'uint's? 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? Also, should we say anything about truncating the bitstring at some arbitrary point? (Similarly for the unicast case, on both counts.) 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.) 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"? 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? 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.) 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. 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.] 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/ 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. 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. 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. Also, it's somewhat unusual to talk about "(D)TLS certificates" as opposed to X.509 certificate, raw public key, etc.. 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. 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. 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). 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. Section 8.2 Per https://www.ietf.org/iesg/statement/normative-informative.html even optional features like DTLS, MAC, RFC 3339 timestasmps, etc., should be listed as normative references.
Thank you for the SECDIR review from Valery Smyslov. Please review and respond to the remaining items. In particular, I concur with the recommendations about precise language around the names of the parameters. Section 3.1. babel-implementation-version. Is there any guidance on the format of this string (or is it free form like a Server: in HTTP)? Section 3.1. babel-metric-comp-algorithms, babel-mac-algorithms, babel-dtls-cert-types. Is there any guidance to provide on the delimiter between a list of values, or is that explicitly a data model issue? Section 3.1. babel-security-supported, babel-mac-algorithms, babel-dtls-cert-types. Consider providing citations on “MAC” and “DTLS”; and “HMAC-SHA256” and “BLAKE2s”; and “X.509” and “RawPublicKey” (just like was done for babel-metric-comp-algorithms). Section 3.8. babel-mac-key-value. 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]. I was under the impression that this was an information model to encode generic Babel protocol parameter and that the underlying protocol documents fully specified the normative behavior. However, this guidance appears to be introducing more restrictive configuration guidance not found in draft-ietf-babel-hmac making this document an information model + profile. Was this intentional? Section 3.8 and 3.9. babel-mac-key-test and babel-cert-test. It would be useful to explain the use case for this testing API. Section 5. Note that operations are also exposed in the information model. OLD This document defines a set of information model objects and parameters that may be exposed to be visible from other devices NEW This document defines a set of information model objects, parameters, and operations that may be exposed to be visible from other devices Section 5. Per: MAC keys are allowed to be as short as zero-length. This is useful for testing. Network operators are advised to follow current best practices for key length and generation of keys related to the MAC 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. Add clarifying text that the information model explicitly enables this brute force attack where most of the workload is pushed onto the server (since it computes the hash). Also add a mitigation. Perhaps something like “This information model provides an oracle via the babel-mac-key-test operation that would enable such a brute force attack. Operators SHOULD rate limit access to this operation.”
[[ nits ]] [ section 3.1 ] * s/running and operational/running any operational/?
The shepherd writeup is more than a year old. I wonder if we should get into the habit of asking that these be refreshed before they're scheduled on telechats. Please fix the boilerplate text from BCP 14 (your Section 1.1). Lastly, +1 to Barry's comments.
Just a couple of minor comments here: — Section 1.1 — Please use the exact BCP 14 boilerplate from RFC 8174. — Section 1.2 — For “datetime”, I suggest adding “Section 5.6” to the reference to RFC 3339, to make the specific format easier to find. And I think the use of 3339 in the definition of the type makes it a normative reference. Similarly, the use of ISO.10646 to define “string” makes it normative.
I want to revisit the question about including support for source-specific routing in the Information model. This topic came up already, but the discussion focused only on whether source-specific routing needed to be enabled or not, with one implementor mentioning that their implementation required it . In addition to enabling the functionality, and because "most of the information model is focused on reporting Babel protocol operational state" (§1), I am interested in the reporting side. It seems to me that the incremental cost to add this support is trivial (as described in §3/draft-ietf-babel-source-specific: "Data Structures"). Why is source-specific routing not supported? I find it to be a significant omission, especially considering that the source-specific routing spec is in IESG Evaluation at the same time.  https://mailarchive.ietf.org/arch/msg/babel/F7tlCQk8IeTaHN_rKHbsoKF3urE/
Thank you for the work put into this document. Please find below some non-blocking COMMENT points, and some nits. I also second Alvaro's question about the source-routing component. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I have a slight concern that draft-ietf-babel-yang-model is not reviewed at the same time as the information model but, at least, they will be reviewed in the right order ;-) -- Section 3 -- For an informational document, I wonder whether the use of normative "MAY" is required. -- Section 3.2 -- About the UDP port, should the Babel default be part of the information model description ? I would prefer to leave it to the protocol specifications. Same remark applies to other objects/properties when the Babel default value is repeated in the information model. What is the usefulness of repeating it ? == NITS == -- Section 2 -- It is probably a matter of taste ;-) but I do not like too much the fact that all the objects names start with "babel-" as it is implicit.
Thank you for this document. I support Ben's discuss regarding reusing the terminology from NMDA. I think that the document should have a normative reference to RFC 8342, and probably explain that in some places the information model is using the same concepts of configuration and operational data separation described in NMDA. I also support Alvaro's question about whether the source-routing component should be included. This is just a comment, and I'm not proposing that you change tack, but I have to confess that I question how beneficial publishing an Information Model really is. I understand that the goal here is to be able to publish two different data models, one based on YANG and other based on BBF's [TR-181]. But what we end up with is an information model defined in a custom ad hoc language, which will naturally necessitate for the YANG and TR-181 models to be generated by hand, and for all three models to be kept up to date and consistent with each other. Hence, I wonder whether retrospectively it would have been better to just define the YANG model in IETF and ask BBF to use that as source reference to construct the TR-181 model from, ideally as a programmatic conversion, or failing that by hand. At least that way there are only two things to keep in sync rather than three. Regards, Rob