Babel Routing Protocol over Datagram Transport Layer Security
draft-ietf-babel-dtls-10

[Ballot comment]
[[ 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.

[Ballot comment]
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"

[Ballot comment]
This is very well written draft. Nits:

-
- Please update the DTLS-CID reference; I see that even the current draft is going to expire on 23 April.

[Ballot comment]
This is very well written draft. Nits:

- In section 2.1, could we change "nodes could use DTLS connection identifiers" to a MAY?
- Please update the DTLS-CID reference; I see that even the current draft is going to expire on 23 April.

[Ballot discuss]
I support Roman's Discuss point (1) (and basically cover the same as his
(2) below).

Let's have a discussion about (DTLS) identity.
Section 2.1 says that we use mutual authentication and that
implementations "MUST support authenticating peers against a local store
of credentials"; also that "if a node receives a new DTLS connection
from a neighbour to whom it already has a connection, the node MUST NOT
discard the older connection until it has completed the handshake of the
new one and validated the identity of the peer".  But how does this
authentication occur, and what constitutes the identity of the peer.  We
will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.)
DNS-ID or SRV-ID must match the name obtained in some fashion.  But for
Babel, we are authenticating routers -- router identity is usually in
the form of just an IP address on a loopback interface!  Are we expected
to get certificates that certify IP addresses as identity, or use some
sort of PSK or password-based TLS authentication?  (The last two are not
really compatible with the "MUST send a CertificateRequest", BTW.)  Raw
public keys?  I think we can give a more clear picture of how to build a
secure system.

Relatedly, once DTLS authenticates an identity, what level of
authorization checks are performed?  Are we still in a single
authorization domain, where any router that authenticates as being part
of a given domain is implictily authorized to be a babel peer and convey
any and all routing information?

We should also give some guidance on ciphers and algorithms where we
discuss the DTLS details (BCP 195 is probably the safest bet here, even
if it's a little in need of an update).

[Ballot comment]
Section 1.2

  The protocol described in this document protects Babel packets with
  DTLS.  As such, it inherits the features offered by DTLS, notably
  authentication, integrity, replay protection, confidentiality and
  asymmetric keying.  It is therefore expected to be applicable in a

replay protection is not an inherent feature of DTLS, so I suggest
"optional replay protection" to emphasize that an implementation of
babel may need to explicitly configure it.

  There exists another mechanism for securing Babel, namely Babel HMAC
  authentication [BABEL-HMAC].  HMAC only offers basic features, namely
  authentication, integrity and replay protection with a small number
  of symmetric keys.  A comparison of Babel security mechanisms and

Even the authentication is limited, as it is group authentication, not
true per-entity authentication.

Section 2.1

  information last longer.  If a node receives a new DTLS connection
  from a neighbour to whom it already has a connection, the node MUST
  NOT discard the older connection until it has completed the handshake
  of the new one and validated the identity of the peer.

(Does the validated identity of the peer have to match the one from the
previous handshake?)

Section 2.3

I agree with the RtgDir reviewer that unprotected (multicast) Hellos are
at risk of tampering by an attacker, who could drop them or modify the
seqno/interval, for DoS purposes.
I see the text about use of multicast Hellos for discovery and the
acknowledgment that an out-of-band neighbor discovery mechanism may be
available.  Are there any such discovery mechanism under development?
Regardless, I think we should consider mandating/suggesting (to some
strength; maybe SHOULD is enough) the use of protected unicast Hellos
instead of just stating that nodes can either rely on multicast or send
protected unicast Hellos.  When unicast (protected) Hellos are in use,
even tampering with multicast Hellos will not be enough to cause a DoS
attack, since a node must be detected as down on both unicast and
multicast to be considered gone.  (Of course, a sufficiently powerful
attacker can still just drop all traffic and cause DoS.)

Section 2.4

  Note that receiving an unprotected packet can still be used to
  discover new neighbours, even when all TLVs in that packet are
  silently ignored.

Is this going to cause a lot of spurious DTLS handshake attempts if we
ever end up with a babel-dtls implementation adjacent to a
classic-babel-only implementation?  Is there any rate limiting on that?

Section 2.5

Do we want to talk about the potential consequences of an attacker
arbitrarily delaying valid content (to justify the need for a timeout)?

Section 2.6

  A node MAY allow configuration options to allow unprotected Babel on
  some interfaces but not others; this effectively gives nodes on that
  interface the same access as authenticated nodes, and SHOULD NOT be
  done unless that interface has a mechanism to authenticate nodes at a
  lower layer (e.g., IPsec).

I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite
justify making it a Discuss-level point.

Section 3

  IP, UDP and DTLS.  Nodes MUST NOT send Babel packets larger than the
  attached interface's MTU adjusted for known lower-layer headers (at
  least UDP and IP) or 512 octets, whichever is larger, but not
  exceeding 2^16 - 1 adjusted for lower-layer headers.  Every Babel
  speaker MUST be able to receive packets that are as large as any

Aren't these requirements just duplicating what's in 6126bis?  We
probably don't need to repeat the normative language, at least, even if
there's a desire to repeat the content.

  Note that distinct DTLS connections can use different ciphers, which
  can have different amounts of overhead per packet.  Therefore, the

nit: I think the intention here was "per-packet overhead", though the
statement is true as currently written (due to variable length padding
for block ciphers).

Section 5

The RFC 7525 ref is probably better spelled as BCP 195, and arguably
moved earlier in the text (i.e., where I mentioned it previously).

  A malicious client might attempt to perform a high number of DTLS
  handshakes with a server.  As the clients are not uniquely identified
  by the protocol and can be obfuscated with IPv6 temporary addresses,
  a server needs to mitigate the impact of such an attack.  Such

nit: they're not uniquely identified by the protocol *until the
handshake completes* -- our requirement for mutual authentication will
cause all valid clients to be identified.  However, the DoS risk does
not require the client to let the handshake complete, so the core
statement here remains valid.  It may also be worth mentioning
"Slowloris"-style attacks that keep handshake state active for as long
as possible to increase resource consumption.

Section 6.2

DTLS-CID needs to be normative if it is a MAY-level feature.  (See
https://www6.ietf.org/iesg/statement/normative-informative.html .)

RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a
MUST-level requirement!

[Ballot discuss]
(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?

[Ballot comment]
(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/

[Ballot discuss]
Unfortunately I need to discuss the port request again.

First of all I would like to comment on the shepherd write-up which says:
"The document requires only the allocation of a port number for Babel
over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section."
This is not correct. Having a second port for the secured version of a protocol WAS common practice. However RFC6335 say now
"The use of separate
  service name or port number assignments for secure and insecure
  variants of the same service is to be avoided in order to discourage
  the deployment of insecure services."

Anyway, in this case I understand that a different port is desired because unencrypted HELLO messages are still received over the default babel port. However, it is not clear to me why a fixed/default port is needed. The neighbour needs to be discovered in some why, no matter what, before a DTLS connection can be established and this discovery procedure could indicate a dynamic port number that the peer is listening on for babel over DTLS. E.g. the multicast HELLO could have a new TLV with this port information. Please clarify why this option is not suitable! Thanks!

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-babel-dtls-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about the IANA Considerations section of this document.

We understand that, upon approval of this document, there is a single action which we must complete.

In the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers

the following port number will be registered as follows:

Service Name: babel-dtls
Port Number: TBD
Description: Babel Routing Protocol over DTLS
Assignee: David Schinazi
Contact: David Schinazi
Reference: [RFC to be]

IANA notes the authors have suggested port 6699 for this registration.

IANA Question: Should the assignee be the IESG  and the contact be the IETF Chair ? Please see RFC 6335, Section 8.1.1

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-07-04):

From: The IESG
To: IETF-Announce
CC: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com, draft-ietf-babel-dtls@ietf.org, martin.vigoureux@nokia.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Babel Routing Protocol over Datagram Transport Layer Security) to Proposed Standard


The IESG has received a request from the Babel routing protocol WG (babel) to
consider the following document: - 'Babel Routing Protocol over Datagram
Transport Layer Security'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Babel Routing Protocol does not contain any means to authenticate
  neighbours or protect messages sent between them.  This document
  specifies a mechanism to ensure these properties, using Datagram
  Transport Layer Security (DTLS).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO for draft-ietf-babel-dtls-07.txt
--------------------------------------

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard. Title page indicates Standards Track. This document
standardizes the securing of Babel with DTLS.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

  Technical Summary:

The Babel Routing Protocol does not contain any means to authenticate
neighbours or protect messages sent between them.  This documents
specifies a mechanism to ensure these properties, using Datagram
Transport Layer Security (DTLS).

  Working Group Summary:

There was a clear consensus in favor of the document. There was no
opposition except for one participant who changed to support.

  Document Quality:

The document is of good quality and has had a reasonable variety of
reviews with comments resolved to the satisfaction of the reviewers.

  Personnel:
    Document Shepherd: Donald Eastlake
    Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

The document Shepherd's review is here:
https://mailarchive.ietf.org/arch/msg/babel/AzjslHG1bVLksmXMs62gLDqeN_M

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

An early security review took place. See
https://mailarchive.ietf.org/arch/msg/babel/1i3PTpCYZ5uXgNxIsWR8Ken3Tnw
An early routing review took place. See
https://mailarchive.ietf.org/arch/msg/babel/cKA2BYaRP08UPgPSeIWp7K-ci6A

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of?

No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

Yes, see:
https://mailarchive.ietf.org/arch/msg/babel/CcIbTcuyYI7GdJfGvYg7S3CxddQ
https://mailarchive.ietf.org/arch/msg/babel/XacfODvwa5WHp7VG5tTCgV3AL28
https://mailarchive.ietf.org/arch/msg/babel/071D6tjivX4agtaUzFGlmxL0DT8

(8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the
    IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

There is a good consensus of active participants in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

No such formal review required.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

There is a normative reference to draft-ietf-babel-rfc6126bis but that
draft is in WG Last Call and expected to advance shortly.

(15) Are there downward normative references (see RFC 3967)?

There are no down-refs.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction?

The front page indicates that this document Updates rfc6126bis. This
is an arguable point.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified.

The document requires only the allocation of a port number for Babel
over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section.

(18) List any new IANA registries that require Expert Review for
    future allocations.

No new registries created.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

No automated checks required.

PROTO for draft-ietf-babel-dtls-07.txt
--------------------------------------

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard. Title page indicates Standards Track. This document
standardizes the securing of Babel with DTLS.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

  Technical Summary:

The Babel Routing Protocol does not contain any means to authenticate
neighbours or protect messages sent between them.  This documents
specifies a mechanism to ensure these properties, using Datagram
Transport Layer Security (DTLS).

  Working Group Summary:

There was a clear consensus in favor of the document. There was no
opposition except for one participant who changed to support.

  Document Quality:

The document is of good quality and has had a reasonable variety of
reviews with comments resolved to the satisfaction of the reviewers.

  Personnel:
    Document Shepherd: Donald Eastlake
    Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

The document Shepherd's review is here:
https://mailarchive.ietf.org/arch/msg/babel/AzjslHG1bVLksmXMs62gLDqeN_M

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

An early security review took place. See
https://mailarchive.ietf.org/arch/msg/babel/1i3PTpCYZ5uXgNxIsWR8Ken3Tnw
An early routing review took place. See
https://mailarchive.ietf.org/arch/msg/babel/cKA2BYaRP08UPgPSeIWp7K-ci6A

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of?

No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

Yes, see:
https://mailarchive.ietf.org/arch/msg/babel/CcIbTcuyYI7GdJfGvYg7S3CxddQ
https://mailarchive.ietf.org/arch/msg/babel/XacfODvwa5WHp7VG5tTCgV3AL28
https://mailarchive.ietf.org/arch/msg/babel/071D6tjivX4agtaUzFGlmxL0DT8

(8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the
    IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

There is a good consensus of active participants in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

No such formal review required.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

There is a normative reference to draft-ietf-babel-rfc6126bis but that
draft is in WG Last Call and expected to advance shortly.

(15) Are there downward normative references (see RFC 3967)?

There are no down-refs.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction?

The front page indicates that this document Updates rfc6126bis. This
is an arguable point.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified.

The document requires only the allocation of a port number for Babel
over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section.

(18) List any new IANA registries that require Expert Review for
    future allocations.

No new registries created.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

No automated checks required.