Re: [manet] DLEP-18 Security Considerations

Justin Dean <bebemaster@gmail.com> Sun, 07 February 2016 12:58 UTC

Return-Path: <bebemaster@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 AB5C41B3A1E for <manet@ietfa.amsl.com>; Sun, 7 Feb 2016 04:58: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 B7Qzvwl2Sody for <manet@ietfa.amsl.com>; Sun, 7 Feb 2016 04:58:07 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 217FD1B3A1F for <manet@ietf.org>; Sun, 7 Feb 2016 04:58:07 -0800 (PST)
Received: by mail-ob0-x231.google.com with SMTP id wb13so126310721obb.1 for <manet@ietf.org>; Sun, 07 Feb 2016 04:58:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WqDurzLxhHbcFTjibFQalxxNn9OzHemaR8wMkrNmmRg=; b=0fcnaMbKf5LrkbwDskRADT7wesbtvCmBgslQonug+dL+pfI3h+uAQdQv9N6WKREFlr thWzIs/q3KZ+5FH8KZ8Ku+843p84D5hX04wFRHDEpRvzc8H+2G/276bdSEJPXtE+MsiF Pn/lxmZJz2UiWSwl3PnJaognAaa0ATZJaj+5AeyvD/rh2o9FKCiU4mq+jgaISVdNZe/0 5MtDocn1yP1A146c9tsms3nIC8odmDe5EfCppCrLm6NkaYLdU+PkMtZ5jPWtcdzOFURt NqFwU0EfirRScn408EZeV+yxb/rBEEekW0R8xCtvNa5AX/5qzjemB4MIOtErL/uaJMii tj3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WqDurzLxhHbcFTjibFQalxxNn9OzHemaR8wMkrNmmRg=; b=F8hU8OlzZQkXFW4jHL85RI89JorzlBl5puEreYT8trRQoNuH7RZRDEzbQYiDRvs6E4 yrsPF6TBQIrhaeiUfUzuYDUO4GYXfp3lj/Fo9sCTtSHjOnvZ4TjJ7Me6U0P2DsvyE2L6 hX6YTqtkeKoUXtFmUuDkUmZZCLHQzhmP5Nx4DMR05p3CJG0X9Y/4a9VjWZtvokZ/56L8 pGvz/YRjH4JawI3ETSfpsA71wUv5nvPKBJo7T0FHnjnWT6Au/EBTGmJdQp5PVvhqz2vT G/SersBYtUw4FKHccgiipz94gusdwP+SklPDbNKJ3bpZ157XSBQTV5Sqxmkdkdt14eKW ITYQ==
X-Gm-Message-State: AG10YOTnWEZ8N8kMAa0iFJLB5TWs7rYGz1M6kpryKpe/3gVUPMfIPEoDUH8/tFvJbCj2tF4Euy8aMaldxgn/ng==
MIME-Version: 1.0
X-Received: by 10.60.220.230 with SMTP id pz6mr20172016oec.49.1454849886611; Sun, 07 Feb 2016 04:58:06 -0800 (PST)
Received: by 10.76.159.234 with HTTP; Sun, 7 Feb 2016 04:58:06 -0800 (PST)
In-Reply-To: <CAGnRvur=CMe7YwudtYJmbO_fOPh2n3Vch5z1AkzawFe1gULgjQ@mail.gmail.com>
References: <CALtoyo=6zEWqj8kC=JHb1=6sKD+ktCOWmnU+rzbNGhrkAwMfzQ@mail.gmail.com> <D2DBAA65.10DB40%aretana@cisco.com> <CAGnRvur=CMe7YwudtYJmbO_fOPh2n3Vch5z1AkzawFe1gULgjQ@mail.gmail.com>
Date: Sun, 07 Feb 2016 07:58:06 -0500
Message-ID: <CA+-pDCfPghT=v=CPdNa8vNXPCiJmC1FMK3NwS-vf890irOkLJg@mail.gmail.com>
From: Justin Dean <bebemaster@gmail.com>
To: Henning Rogge <hrogge@gmail.com>
Content-Type: multipart/alternative; boundary="001a11367c2eb1722a052b2da26b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/y_P9SU-K84Qfv59-fQk7hJiRm4Y>
Cc: MANET IETF <manet@ietf.org>
Subject: Re: [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: Sun, 07 Feb 2016 12:58:09 -0000

How about the following update?  Taken from bits of Hennings' explanation
here and Ran's proposed text from quite a while back.  Please note the
difference in deployment and implement, and the resulting what actually
gets used in real deployments....

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.

   DLEP is restricted to operation over a single (possibly
   logical) hop at layer 2; Deployments other than single-hop are
   not permitted and outside the scope of this specification.
   Deployments requiring authentication and/or encryption of traffic
   MUST take steps to secure the Layer 2 link.

All DLEP Implementations either:

(a) MUST implement Transport Layer Security (TLS)' [RFC-5246]
so TLS is available for use when deployment dictate or
(b) MUST restrict the valid IP (both IPv4 and IPv6) unicast
addresses for use with DLEP to link-local addresses.

   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 effect security of the data plane;
   standard security procedures can be employed for the data plane.

On Sun, Feb 7, 2016 at 6:54 AM, Henning Rogge <hrogge@gmail.com> wrote:

> On Sat, Feb 6, 2016 at 11:22 PM, Alvaro Retana (aretana)
> <aretana@cisco.com> wrote:
> > On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff"
> > <manet-bounces@ietf.org on behalf of ratliffstan@gmail.com> wrote:
> >
> > Stan:
> >
> > Hi!
> >
> > 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?
>
> It will not work because the user traffic will not reach the
> destination. DLEP is the model of a "external radio" which acts as a
> bridge (as in "layer-2 bridge") between the connection to the router
> and the radio network.
>
> If you are more than 1 IP-hop away you will not get the user traffic.
>
> > What about confidentiality of the data?  What about exposing information
> > about users (privacy)?
>
> if you have one IP-hop between radio and router linklayer/MAC security
> takes care of this. If not you are outside the specification of the
> protocol and do something strange to the traffic anyways... so it
> should not be DLEP's problem.
>
> >  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?
>
> If you break the basic assumptions of the protocol, you should not
> expect its security considerations to be secure in your situation.
>
> > 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…
>
> http://tools.ietf.org/html/draft-ietf-manet-dlep-18#section-2.1
>
> > 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.
>
> There is no guarantee that xx/yy/zz will give you any kind of security
> in an unspecified environment.
>
> Henning Rogge
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>