[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.107.3.37 with SMTP id 37mr27393551iod.182.1453164666353; Mon, 18 Jan 2016 16:51:06 -0800 (PST)
Received: by 10.79.96.1 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 link. 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? Regards, Stan
- Re: [manet] DLEP-18 Security Considerations Henning Rogge
- Re: [manet] DLEP-18 Security Considerations Stan Ratliff
- Re: [manet] DLEP-18 Security Considerations Lou Berger
- Re: [manet] DLEP-18 Security Considerations Justin Dean
- Re: [manet] DLEP-18 Security Considerations Henning Rogge
- Re: [manet] DLEP-18 Security Considerations Alvaro Retana (aretana)
- Re: [manet] DLEP-18 Security Considerations Stan Ratliff
- Re: [manet] DLEP-18 Security Considerations Alvaro Retana (aretana)
- [manet] DLEP-18 Security Considerations Stan Ratliff
- Re: [manet] DLEP-18 Security Considerations Henning Rogge