Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)
David Schinazi <dschinazi.ietf@gmail.com> Fri, 09 August 2019 23:40 UTC
Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED53120253; Fri, 9 Aug 2019 16:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkUZZsKPrQjW; Fri, 9 Aug 2019 16:40:16 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1307120168; Fri, 9 Aug 2019 16:40:15 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id h28so70599363lfj.5; Fri, 09 Aug 2019 16:40:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pH3vDHyTZt4Uyv3AEAhpM36ibWFdjZdaxuDvSKALTVg=; b=C6UYgodTjPW0qJOjZK0dbXoTVTjal1PU5cRHwaym4KwY3EqcxsWza5j6r1c6Wn3A6k 4lUO2L/3Q0rRCpzHh+oM+gIa3n9m9T5MNTe5IP2pSNh+p4iu9Chq9UVt9P1A0q95+WgE yrEIrZciIIKMxdOSMJ9vGCr5L3VKC5UHoqN/4uU/Jp+uyjUzqZHd3mdv4QqgWL1ccGg1 r1wuRGfP5ox1ddhsi9EYEwJSFiupDD0g2w4bwA3bPck3aPAUjHe5N3MynwEP1Fpwvlhj Qb29TBMK5yiDcYnnF/sTXw3GRLLjXy0ooPkC/M8ppy6bfO3HmkiR7O8IrcJQWjFtRKlZ errg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pH3vDHyTZt4Uyv3AEAhpM36ibWFdjZdaxuDvSKALTVg=; b=jQZHN9x2OIpgKrbwMwK6RvGxJPkO6Rd3EshCo4gNRu8S4p6BipHJqmhZiDr/ehehVd SpbQJV5/2BjrmdV3y+/Is58R2mpKMVo+xDxAFUwha2cokxR4TJHQhRnHFST4S6TgHQkF DFwY7IwjJGt1NitSegWXCAX4wVVzBiVVMyhNCxnOwdg0MP+dp+qK5hA7fEPH/Zg62gnJ nZOO9Y+07K+kf2ZxP0G28CgIXht60yN6YGhSsCg0WctAzMYEYqDh5dNGZJlmMlBBlNoT LqamaJq/bTKkPwhrMHRhGgFjLwh/9y6/L4bjXum992NDyB5o9T9bS2x+8v6r4z9lEe97 hLEQ==
X-Gm-Message-State: APjAAAXj+K09tAyOJPYAXuy3eNSyzee2foDihipPLFmrHbBVIiYPa736 f3snqKsbEahhxp/N8Pmm3r/tIi7YYaw1KJTLs/k=
X-Google-Smtp-Source: APXvYqydqoV9ehgPifYTgIUBxNdTXvMp8ZJb0n7/LRF67+Ysf0yU+enCBqFML7A5TVKqO0Rm4z13Cm/fEGAQtElqzy0=
X-Received: by 2002:a19:428c:: with SMTP id p134mr12869862lfa.166.1565394013962; Fri, 09 Aug 2019 16:40:13 -0700 (PDT)
MIME-Version: 1.0
References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> <CAPDSy+5fTinvfPeLMkMOx31SwCL6_Wuzkqif0xGR=BTCPLvBYA@mail.gmail.com>
In-Reply-To: <CAPDSy+5fTinvfPeLMkMOx31SwCL6_Wuzkqif0xGR=BTCPLvBYA@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Fri, 09 Aug 2019 16:40:02 -0700
Message-ID: <CAPDSy+5h0-pOTJTiaR7cvr0w1Qc7_mrk20jxaVSW-eG-cirmEg@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-babel-dtls@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel-chairs <babel-chairs@ietf.org>, Babel at IETF <babel@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000022c79f058fb7b2d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/I_HhYOIIlTYbRo8FUzXex1xe_LI>
Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2019 23:40:24 -0000
We've now submitted -08 which contains the changes discussed below. Thanks, David On Thu, Aug 8, 2019 at 5:44 PM David Schinazi <dschinazi.ietf@gmail.com> 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 < > noreply@ietf.org> 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 >
- [babel] Roman Danyliw's Discuss on draft-ietf-bab… Roman Danyliw via Datatracker
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… David Schinazi
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… David Schinazi
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… David Schinazi
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… David Schinazi
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… David Schinazi
- Re: [babel] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw