Re: [manet] DLEP-18 Security Considerations

"Alvaro Retana (aretana)" <> Sat, 06 February 2016 22:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1DDF41B3485 for <>; Sat, 6 Feb 2016 14:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MXqLH3BtTfWZ for <>; Sat, 6 Feb 2016 14:22:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B1211B345D for <>; Sat, 6 Feb 2016 14:22:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8744; q=dns/txt; s=iport; t=1454797352; x=1456006952; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qi/uv3Pg7vUri7v+0Cvn3+8FiKZHuDxqjXZEjtIAfQI=; b=YYqjZ9WjT+ByxDLQkeL4/3zJclbS4SGZLZlrm6LXKgYBswCTBcEDQsxl +PWm/HibgpXiQ6yrpG1vw08BqnNIr7dikqFDnKeH15YB6+PXEgYq/C7kF jhKcZWh87zl4kT+AliqhFDmkhw2ccklh+3NaW0UxJrBla6JMZemGRyIGP k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCmcbZW/40NJK1egm5MgT8GiFWud?= =?us-ascii?q?4ITAQ2BZoYNAoElOBQBAQEBAQEBgQqEQgEBBIEJAgEIPwchERQRAgQBEogGAxK?= =?us-ascii?q?5Rw2ETwEBAQEBAQEDAQEBAQEbhhIBhDaCN4FLEQGEWAWNX4UPhAcBi1yBc45zh?= =?us-ascii?q?n2HQAEeAQFCg2RqhyM0fAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,407,1449532800"; d="scan'208,217";a="235863537"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Feb 2016 22:22:31 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u16MMVAO029598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 6 Feb 2016 22:22:31 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 6 Feb 2016 16:22:30 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Sat, 6 Feb 2016 16:22:30 -0600
From: "Alvaro Retana (aretana)" <>
To: Stan Ratliff <>, MANET IETF <>
Thread-Topic: [manet] DLEP-18 Security Considerations
Thread-Index: AQHRUlOAoKZlMQke1UG/MiPH4VQjRZ8fk4WA
Date: Sat, 6 Feb 2016 22:22:30 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D2DBAA6510DB40aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [manet] DLEP-18 Security Considerations
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Feb 2016 22:22:36 -0000

On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <<> on behalf of<>> wrote:



You'll need references for L2 security.

The main problem I see with the text below is that it is based on assumptions - even though you do say that "DLEP is restricted to...a single (possibly logical) hop at layer 2", it is based on the deployment assumptions.  What happens if it isn't deployed that way?

What about confidentiality of the data?  What about exposing information about users (privacy)?  I know that the assumed deployment model makes it very hard to look at the data in flight between and the physical and L2 security may well be enough.  However, what if DLEP is not used as expected?

IMO, you should describe the expected operating environment (or point to the assumptions) and any security mechanisms that should be included there (L2, physical assumptions), and explain why confidentiality and privacy are not a concern...but then you should also say something like: "if DLEP is used in an environment other then the expected one, then xx, yy and zz MUST/SHOULD be implemented".   I think that this way we would be covering the normal case, but also providing an answer to what if without making mandatory mechanisms that may be superfluous.

My 2c.


Hello WG,

As requested in the email thread earlier today, here's a snapshot of what we currently have in the upcoming DLEP-18 draft wrt security. We've put an additional paragraph in the Assumptions section (Sec. 2.1) that says:

   The reliance on MAC addresses by DLEP forces the assumption that
   participating DLEP peers are on a single segment (either physical or
   logically, via tunneling protocols) at Layer 2.  DLEP further assumes
   that security of the implementations (e.g., authentication of
   stations, encryption of traffic, or both) is dealt with by by
   utilizing Layer 2 security techniques.

Additionally, here is the text in the "Security Considerations":

12.  Security Considerations

   The potential security concerns when using DLEP are:

   1.  An attacker might pretend to be a DLEP peer, either at DLEP
       session initialization, or by injection of messages once a
       session has been established, and/or

   2.  DLEP data items could be altered by an attacker, causing the
       receiving implementation to inappropriately alter its information
       base concerning network status.

   Since DLEP is restricted to operation over a single (possibly
   logical) hop at layer 2, implementations requiring authentication
   and/or encryption of traffic MUST take steps to secure the Layer 2

   To avoid potential denial of service attack, it is RECOMMENDED that
   implementations using the Peer Discovery mechanism maintain an
   information base of hosts that persistently fail Session
   Initialization having provided an acceptable Discovery signal, and
   ignore Peer Discovery signals from such hosts.

   This specification does not address security of the data plane, as it
   (the data plane) is not affected, and standard security procedures
   can be employed.

Thoughts? Suggestions?