Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
(1) Section 1. These are different than the ones listed in Section 6 of draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls. As DTLS and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, they really should be harmonized. (2) Section 2.1. Per “Implementations MUST support authenticating peers against a local store of credentials”, what does that credentialing look like? Is it certificates, PSK, etc? What validation procedure is being used for this authentication?
(3) Abstract. Per “Babel does not contain any means … [to] protect messages”, be more precise in the definition of protect (i.e., integrity and confidentiality) (4) Section 1.2. Per “A comparison of Babel security mechanisms and their applicability can be found in [RFC6126bis]”, where in draft-ietf-babel-rfc6126bis does this comparison occur. The references to HMAC and TLS are in a single paragraph in in Section 6/Security Considerations which roughly reiterate the one sentence statements written here. (5) Section 2.1. Per “When a node receives a new DTLS connection, it MUST verify that the source IP address is an IPv6 link-local address …”, what happens if IPv4 is in use? (6) Section 2.1. Per “Nodes MUST only negotiate DTLS version 1.2 or higher”, this is stricter than RFC7525 cited in the Security Consideration later in the draft. That’s fine, but please reiterate that in Section 5. (7) Section 2.6 Suggest being clearer that this is a deployment not an implementation issue. s/Implementations MAY implement both Babel over DTLS and unprotected Babel./ /A node MAY run both Babel over DTLS and unprotected Babel./ (8) Section 2.6, Per “However, accepting unprotected Babel packets … loses the security properties of Babel over DTLS”. This seems misleading. The security properties of “Babel over DTLS” as a protocol are stated in Section 1.2. In this section there is discussion of the security properties of the node (and the resulting neighbor table). These are different. The issue seems to be that a node is building a neighbor table with updates from sources which need to be trusted to different degrees. (9) Section 5. Per “Confidential interaction between two Babel peers requires Datagram Transport Layer Security (DTLS) with a cipher suite offering confidentiality protection. The guidance given in [RFC7525] MUST be followed to avoid attacks on DTLS.”, the first sentence is true, but incomplete, in that we’d also want cipher suites with a strong key exchange algorithm, etc. Section 4.2 of RFC7525, which is cited as a MUST, provides a list of recommended ciphers suites. Do we need this first sentence? (10) Editorial -- Section 2.1. Expand “IHU” on first use -- Section 3. Nit. s/ciphers/ciphersuites/
Thank you for resolving my Discuss points!
Thanks for discussing the port assignment (again)!
Please reply to the rtg-dir review: https://mailarchive.ietf.org/arch/msg/rtg-dir/fuvl_TQmvfqxbtq5Qv12qB_ok4M
Thank you for the work put into this document. I have only two COMMENTs. Regards, -éric == COMMENTS == -- Section 1.2 -- The text refers to the security consideration of RFC6121bis for an extended comparison of HMAC & DTLS except that there is no additional information in RFC 6121bis. -- Section 2.1 -- It is a little unclear to me whether a mix of DTLS and non-DTLS Babel nodes can exist on the same layer-2 network. I guess no (as implied later) but a clear sentence would help.