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

[David Schinazi <[e-mail]>]

We've now submitted -08 which contains the changes discussed below.

Thanks,
David

On Thu, Aug 8, 2019 at 5:44 PM David Schinazi <[e-mail]>
wrote:

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