Babel Routing Protocol over Datagram Transport Layer Security
draft-ietf-babel-dtls-10
Yes
(Martin Vigoureux)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Suresh Krishnan)
Note: This ballot was opened for revision 07 and is now closed.
Erik Kline
No Objection
Comment
(2020-08-16)
Sent
[[ comments ]] [ section 5 ] * The first sentence of the 3rd paragraphs reads to me like "while DTLS provides protection against replay attacks an attacker can still mount a replay attack". I don't have any constructive proposal to change this, but if it tickles something in your mind that might be more clear to those not super knowledgeable about DTLS, I'm sure that'll be great.
Murray Kucherawy
No Objection
Comment
(2020-06-27 for -09)
Sent
Reading the shorter document before the longer one, so I may be missing some important context here. This was pretty easy to read, so nice work. A number of editorial comments and suggestions follow: Section 2: * "... sent over to both unicast ..." -- s/over to both/over both/, right? Section 2.1: * "... intervals, to avoid ..." -- remove the comma * "Nodes SHOULD drop packets that have been reordered ..." -- Why would an implementer not do this? (i.e., why is it only a SHOULD?) Section 2.2: * "... from the Magic byte ..." -- s/Magic/magic/ Section 2.3: * Please expand/explain "TLV" on first use. * Just an aesthetic suggestion: In this sentence... Since Babel over DTLS only protects unicast packets, implementors may implement Babel over DTLS by modifying an implementation of Babel without DTLS support, and replacing any TLV previously sent over multicast with a separate TLV sent over unicast for each neighbour. ...you use "implementors", "implement", and "implementation". Maybe this? Since Babel over DTLS only protects unicast packets, implementors may provide Babel over DTLS by using a variant of Babel without DTLS support, and replacing any TLV previously sent over multicast with a separate TLV sent over unicast for each neighbour. Section 2.5: * Why is the stuff in the first paragraph only SHOULD/RECOMMENDED? (The answer may lie in the second paragraph, but I'm uncertain.) * I suggest that Section 5 should make a backward reference to this section since it talks about mitigation of an attack. Section 2.6: * "A node MAY allow configuration options to allow ..." -- change one of those "allow"s to "permit"
Roman Danyliw
(was Discuss)
No Objection
Comment
(2019-08-27 for -09)
Sent for earlier
Thank you for addressing my DISCUSSes and COMMENTs.
Éric Vyncke
No Objection
Comment
(2019-08-05 for -07)
Sent
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.
Martin Vigoureux Former IESG member
Yes
Yes
(for -07)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -07)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -07)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(2019-08-06 for -07)
Sent
Please reply to the rtg-dir review: https://mailarchive.ietf.org/arch/msg/rtg-dir/fuvl_TQmvfqxbtq5Qv12qB_ok4M
Barry Leiba Former IESG member
No Objection
No Objection
(for -07)
Not sent
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2019-08-14 for -09)
Sent
Thank you for resolving my Discuss points!
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2020-04-15 for -09)
Sent
This is very well written draft. Nits: - <striking the request to change DTLS-CID to a 2119 word, as this would create a Normative downref, which is not worth it> - Please update the DTLS-CID reference; I see that even the current draft is going to expire on 23 April.
Mirja Kühlewind Former IESG member
(was Discuss)
No Objection
No Objection
(2019-08-14 for -09)
Sent
Thanks for discussing the port assignment (again)!
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -07)
Not sent