Re: [manet] DLEP-18 Security Considerations

Lou Berger <lberger@labn.net> Sun, 07 February 2016 14:53 UTC

Return-Path: <lberger@labn.net>
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 462CC1B3B87 for <manet@ietfa.amsl.com>; Sun, 7 Feb 2016 06:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 m7diEzcGZejh for <manet@ietfa.amsl.com>; Sun, 7 Feb 2016 06:53:45 -0800 (PST)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id CE6C81B3B7F for <manet@ietf.org>; Sun, 7 Feb 2016 06:53:44 -0800 (PST)
Received: (qmail 14953 invoked by uid 0); 7 Feb 2016 14:53:41 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 7 Feb 2016 14:53:41 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id FZtZ1s0082SSUrH01ZtcRe; Sun, 07 Feb 2016 14:53:39 -0700
X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=-NfooI8aBGcA:10 a=kGVakC0ZM5EA:10 a=jFJIQSaiL_oA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=NhSHSWgtGNU5mE0hXpEA:9 a=X4XThmf0Jqt3l_an:21 a=AszAkRxmpE5IgAeX:21 a=QEXdDO2ut3YA:10 a=RhyRCO8XQdqBenyPb78A:9 a=hCvYrBm9cIVzcBop:21 a=A0gmN-fm6FXWsJnl:21 a=GZUm7VqxDOwP0BT3:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=BQG5YBZYbnvkJ/HQJDRAV8o0Cbk5GQEZrDDdBwDkd7k=; b=PvfvT1cdh9IEvQmTtSmV1fB05ytsH2jcXczTOg12dV97n+GjI6WCUCL35mdclsu/H4pE4o0kSyDSLHUGDaAw95lpgOvz73i55EPMJe2yrnU1gi3Dh6Hcmv/gcpcoN0A5;
Received: from [172.58.233.18] (port=62008 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from <lberger@labn.net>) id 1aSQiV-0001EU-EF; Sun, 07 Feb 2016 07:53:35 -0700
From: Lou Berger <lberger@labn.net>
To: Justin Dean <bebemaster@gmail.com>, Henning Rogge <hrogge@gmail.com>
Date: Sun, 07 Feb 2016 09:53:30 -0500
Message-ID: <152bc392e10.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <CA+-pDCfPghT=v=CPdNa8vNXPCiJmC1FMK3NwS-vf890irOkLJg@mail.gmail.com>
References: <CALtoyo=6zEWqj8kC=JHb1=6sKD+ktCOWmnU+rzbNGhrkAwMfzQ@mail.gmail.com> <D2DBAA65.10DB40%aretana@cisco.com> <CAGnRvur=CMe7YwudtYJmbO_fOPh2n3Vch5z1AkzawFe1gULgjQ@mail.gmail.com> <CA+-pDCfPghT=v=CPdNa8vNXPCiJmC1FMK3NwS-vf890irOkLJg@mail.gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.10 (build: 24000016)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------152bc3931d01b97281843141d68"
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.58.233.18 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/Rote4PVDZap7_3zanEeSRcHpbSc>
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 14:53:47 -0000

Justin,

Two minor suggestions:

s/ link-local addresses/a directly attached IP sub-subnet/

And at then end of  b

Such implementations MAY [or SHOULD] support MACsec, IEEE 802.1AE and 802.1X.

Lou





On February 7, 2016 7:58:37 AM Justin Dean <bebemaster@gmail.com>; wrote:

> 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
>>
>
>
>
> ----------
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>