[manet] DLEP-18 Security Considerations

Stan Ratliff <ratliffstan@gmail.com> Tue, 19 January 2016 00:51 UTC

Return-Path: <ratliffstan@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 240001A702F for <manet@ietfa.amsl.com>; Mon, 18 Jan 2016 16:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7Ceqb5WFJY4o for <manet@ietfa.amsl.com>; Mon, 18 Jan 2016 16:51:07 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 E91271A702E for <manet@ietf.org>; Mon, 18 Jan 2016 16:51:06 -0800 (PST)
Received: by mail-io0-x234.google.com with SMTP id 77so533880586ioc.2 for <manet@ietf.org>; Mon, 18 Jan 2016 16:51:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tlenZMbDHT/o0/7lAwR/DGLUTTnE7MW8FK5tEXss/Gg=; b=Z6TIkJgTcKPhgRHnWLqiqVGdiFSMIlzsP9hwHMW9tY+YCH1ZuTdLbkANwXK2/QwhCL Ip8MxE7PhseybGJd5/Ue7TJSa8LvPIJn+IDnuUkHMoaAJO2zyl6GdYgGgsPYPpDoVXo+ yjohTH68ZCWNNlN5boKyKeVX7R20OFhSA9X1FAwkNbBuMP9DARGvyry9pAyujVLDNSYC GYtUfyKGNpWWSTU9uCLCoS+smsQNdduMb5t+8+kn/1W2LKZO06wJQhLHoPpwtUsRdGis 2hs+RDLvgxP9e0X5QDXPmUoK9K4HRE5c9qWyXQyCxIUFtosK6wIaEPIKaYya+v2pNSkT zIWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=tlenZMbDHT/o0/7lAwR/DGLUTTnE7MW8FK5tEXss/Gg=; b=A9LdcIiwmUnNZS6t8imr+HrF1x3Gj6oULk5IqqI8iSoPriKus4gRBzOyoXgS/tmyME zNG3fCaweKx+B2IdffGG56jpt/ZOQBHUfoR1ax5orrcu/HrZ3AALagf15mz8fMUJ4ciN DZmnf4tdpFvvkYH95gG6nZliEUupN5GVeHWVnbVlw/39t0DwVKz+II8lIS7+OsZYsLp6 5l8+hiVX0Ws7O9PNTCpdc9M7bdu/FxXp5IEZrspnzURkpLO1M/uOyrN75pXB8As0Cfug 5nDdPeYxnWrY2ycQLleqEcdRkO58dlHfV4jU0MK3t+RXAGFcKIRl0no7eQ2apDDE38a8 5f6g==
X-Gm-Message-State: ALoCoQnu8JunsfweE42gAisQqjVexp1fjitS2ufzadzhph/X56qWZWPhb0c+68WPV17LX4SAWQ1bOrSmGThtIQD8ggymG0a9rA==
MIME-Version: 1.0
X-Received: by with SMTP id 37mr27393551iod.182.1453164666353; Mon, 18 Jan 2016 16:51:06 -0800 (PST)
Received: by with HTTP; Mon, 18 Jan 2016 16:51:06 -0800 (PST)
Date: Mon, 18 Jan 2016 19:51:06 -0500
Message-ID: <CALtoyo=6zEWqj8kC=JHb1=6sKD+ktCOWmnU+rzbNGhrkAwMfzQ@mail.gmail.com>
From: Stan Ratliff <ratliffstan@gmail.com>
To: MANET IETF <manet@ietf.org>
Content-Type: multipart/alternative; boundary=001a113fb894bd08d70529a543ff
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/gBhuV4qloiwt9d9XQZB3Bw56_cI>
Subject: [manet] DLEP-18 Security Considerations
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2016 00:51:09 -0000

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?