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

"Taylor, Rick (External)" <rick.taylor.external@airbus.com> Tue, 22 November 2016 11:34 UTC

Return-Path: <rick.taylor.external@airbus.com>
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 4EF911295AA; Tue, 22 Nov 2016 03:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 8x_iiiriBGwB; Tue, 22 Nov 2016 03:34:50 -0800 (PST)
Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE94C129AEE; Tue, 22 Nov 2016 03:34:46 -0800 (PST)
Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 22 Nov 2016 12:34:44 +0100
Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 22 Nov 2016 12:34:21 +0100
Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2016 12:34:20 +0100
Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2016 12:34:20 +0100
Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.03.0279.002; Tue, 22 Nov 2016 11:34:20 +0000
From: "Taylor, Rick (External)" <rick.taylor.external@airbus.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, "draft-ietf-manet-dlep.all@ietf.org" <draft-ietf-manet-dlep.all@ietf.org>, secdir <secdir@ietf.org>
Thread-Topic: SecDir review of draft-ietf-manet-dlep
Thread-Index: AQHSP9dxooq1deGLb0CN9D0fTSXK8KDk5l2g
Date: Tue, 22 Nov 2016 11:34:19 +0000
Message-ID: <B177F831FB91F242972D0C35F6A0733163AD92C3@SUCNPTEXM01.com.ad.uk.ds.corp>
References: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org>
In-Reply-To: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.80.22.46]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 22 Nov 2016 11:34:20.0356 (UTC) FILETIME=[5DAC9840:01D244B4]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-22714.006
X-TM-AS-Result: No--17.696500-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Vw-a5ZsDZh_84sBd9eI6I1BJWiQ>
X-Mailman-Approved-At: Tue, 22 Nov 2016 03:35:55 -0800
Subject: Re: [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: Tue, 22 Nov 2016 11:34:53 -0000

Hi Paul,

Thank you for the review.  A couple of quick comments:

Did you review draft-ietf-manet-dlep-15 or draft-ietf-manet-dlep-25 (the latest)?  As we have attempted to address the security comments raised by the WG and AD review.

One area we have worked hard on addressing is mandating use of RFC5082 (Generalized TTL Security) on the link between router and modem (See Section 3.1).  As you correctly state, DLEP does not have any inherent security mechanisms, and recommends link-layer security, such as 802.1X/AE, but we do mandate mechanisms to restrict the protocol to run over a single hop.  As you point out, DLEP is a control-plane protocol and does not carry any user data.

We have updated the security considerations (section 12) since draft-15, please can you see if the new verbiage addresses your valid comments?

Many thanks,

Rick Taylor

-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
Sent: 16 November 2016 07:02
To: draft-ietf-manet-dlep.all@ietf.org; secdir
Subject: SecDir review of draft-ietf-manet-dlep

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

This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.




--
Airbus Defence and Space has taken all possible efforts to ensure this email is free from malicious code; however, never open suspicious emails or attachments or follow unknown hyperlinks.

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure.

If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system.

Emails to Airbus Defence and Space Limited may be processed, recorded and monitored anywhere in the European Community.


Airbus Defence and Space Limited

Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS.
Registered in England and Wales under company number 02449259.