[secdir] SecDir review of draft-ietf-manet-dlep

"Paul Hoffman" <paul.hoffman@vpnc.org> Wed, 16 November 2016 07:02 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896C312968A; Tue, 15 Nov 2016 23:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 AtVJ29pa4fFI; Tue, 15 Nov 2016 23:02:25 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E94129695; Tue, 15 Nov 2016 23:02:22 -0800 (PST)
Received: from [10.32.60.66] (dhcp-8990.meeting.ietf.org [31.133.139.144] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id uAG728Gv039091 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Nov 2016 00:02:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host dhcp-8990.meeting.ietf.org [31.133.139.144] (may be forged) claimed to be [10.32.60.66]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: draft-ietf-manet-dlep.all@ietf.org, secdir <secdir@ietf.org>
Date: Wed, 16 Nov 2016 16:02:18 +0900
Message-ID: <C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/vMcrKgp2dPfpLd_9s1WcP7k61Es>
Subject: [secdir] SecDir review of draft-ietf-manet-dlep
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 07:02:26 -0000

Greetings. This is a review of draft-ietf-manet-dlep-15 for the Security 
Directorate. Please treat these comments as you would any IETF Last Call 
comments you get.

As I understand it, Dynamic Link Exchange Protocol (DLEP) is a protocol 
for a router and wireless modem to inform each other about 
characteristics of the link in order to make better routing decisions. 
It runs over UDP and TCP, and is explicitly meant to be only valid on a 
single L2 hop directly between the modem and router. (Please let me know 
if I have this wrong!)

There is no security in DLEP. At the end of Section 3, it says:
    DLEP further requires that security of the implementations (e.g.,
    authentication of stations, encryption of traffic, or both) is dealt
    with by utilizing Layer 2 security techniques.  This reliance on
    Layer 2 mechanisms secures all DLEP Messages - both the UDP 
discovery
    Signals and the TCP control Messages.
Further, there is no mandatory-to-implement L2 security protocol; 802.1X 
and 802.1AE are mentioned as possibly being used, but neither is 
required to be implemented.

This, the specified security is pretty weak. It is not clear what 
advantage an attacker would get by snooping on the DLEP traffic: the 
values exchanged are pretty easy to determine just by watching the link. 
It is also not clear what advantage an attacker would get by 
impersonating either party or mounting an MITM attack other than 
degrading the link, which an MITM could do anyways.

This feels like a classic IETF "we don't deal with security and leave it 
to the layer below us" protocol, which might be acceptable in this case 
because of the nature of the data being exchanged.

--Paul Hoffman