Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)

[David Schinazi <[e-mail]>]

Thanks for your review Roman! We've made changes on our git repository
<https://github.com/jech/babel-drafts> and will submit a revised draft
shortly.

Detailed responses inline.

Thanks,
David

On Wed, Aug 7, 2019 at 12:26 PM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> ----------------------------------------------------------------------
> 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.
>

We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the
reference
in draft-ietf-babel-dtls.

(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?
>

I'll respond to this point on Ben's DISCUSS since I think you're both asking
for the same thing.


> ----------------------------------------------------------------------
> 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)
>

Agreed, fixed.


> (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.
>

We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the
reference
in draft-ietf-babel-dtls.


> (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?
>

This was an oversight. The text now also discusses IPv4.


> (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.
>

Done.

(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./
>

Agreed. We added your new sentence but also kept the old one since both are
true.


> (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.
>

Agreed. We've reworked that paragraph.


> (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?
>

Fair enough, We've removed that sentence.

(10) Editorial
> -- Section 2.1.  Expand “IHU” on first use
>

Done

-- Section 3.  Nit. s/ciphers/ciphersuites/


Done