[RTG-DIR] Rtgdir last call review of draft-ietf-babel-dtls-06

Min Ye via Datatracker <noreply@ietf.org> Fri, 05 July 2019 12:49 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26359120094; Fri, 5 Jul 2019 05:49:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Min Ye via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Min Ye <amy.yemin@huawei.com>
Message-ID: <156233097510.22018.7107165165922007078@ietfa.amsl.com>
Date: Fri, 05 Jul 2019 05:49:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/fuvl_TQmvfqxbtq5Qv12qB_ok4M>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-babel-dtls-06
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2019 12:49:35 -0000

Reviewer: Henning Rogge
Review result: Has Issues

//resend to RTG DIR list
Hi,

I was asked by the Routing Directorate to do a last call review of
draft-ietf-babel-dtls-06.

I like that the draft is quite short, which is a good thing for a
security draft. I have found a few question you can consider to
address in the final document.

Chapter 2.3:
I wonder if using DTLS protected unicast Hellos should be mandatory...
using unprotected multicast to determine bidirectional reachability
looks like a good way to do a cheap denial of service attack.

Chapter 2.5:
What happens when a node starts a new DTLS connection and there is
already one in the neighbor table? This could both be an attempt to
attack Babel, a reboot of a node or just a matter of misconfiguration
of two nodes.

Chapter 3:
Different pairs of nodes could select different ciphers, resulting in
different MTUs. I assume this is no problem for Babel (could be
mentioned in the chapter).

Some of the design decisions of regarding the three questions could be
mentioned in chapter 5 (Security Implications).

Henning Rogge