Re: [manet] DLEP-18 Security Considerations

"Alvaro Retana (aretana)" <aretana@cisco.com> Sun, 07 February 2016 00:28 UTC

Return-Path: <aretana@cisco.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 D047F1A885D for <manet@ietfa.amsl.com>; Sat, 6 Feb 2016 16:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKlNfC3w96GW for <manet@ietfa.amsl.com>; Sat, 6 Feb 2016 16:28:17 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CDB1A885F for <manet@ietf.org>; Sat, 6 Feb 2016 16:28:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15647; q=dns/txt; s=iport; t=1454804897; x=1456014497; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9+lWkEiqSCm3kbWoqPbf6HX4vyBi9L97YRdlQwv9rVI=; b=F9KPErgMP0yTY6l5tolBAKCC1nY4fpMVdcsxs2WpMLdO9N/3LanxOfQ7 e8Vxg8xqy2ChtXexEFIsAYCblEWbR0X7P6NWtoEwJ+mR2U/Nc2OTAtboq XFNjx67yMvw1hEUuptS6vQAY63BZUUgVARH51Dt1ij1i1AN1i+QhMo1Hp g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWBQBIj7ZW/4cNJK1egm5MgT8GiFWud?= =?us-ascii?q?YIhgWaGDQKBIjkTAQEBAQEBAYEKhEIBAQR5EAIBCD8HIREUEQIEDgWIBgMSuTA?= =?us-ascii?q?NhE8BAQEBAQEBAwEBAQEBAQEBAReGEgGENoI3gUsRAYRYBZJuhAcBi1yBc4Fbj?= =?us-ascii?q?RiGfYNvg1EBIgI+ggMZgUhqhyM0fAEBAQ?=
X-IronPort-AV: E=Sophos; i="5.22,407,1449532800"; d="scan'208,217"; a="70791272"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Feb 2016 00:28:16 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u170SGdn025871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 7 Feb 2016 00:28:16 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 6 Feb 2016 18:28:15 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Sat, 6 Feb 2016 18:28:15 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Stan Ratliff <ratliffstan@gmail.com>
Thread-Topic: [manet] DLEP-18 Security Considerations
Thread-Index: AQHRUlOAoKZlMQke1UG/MiPH4VQjRZ8fk4WAgACV3QD//41EgA==
Date: Sun, 7 Feb 2016 00:28:15 +0000
Message-ID: <D2DBCB3E.10DD58%aretana@cisco.com>
References: <CALtoyo=6zEWqj8kC=JHb1=6sKD+ktCOWmnU+rzbNGhrkAwMfzQ@mail.gmail.com> <D2DBAA65.10DB40%aretana@cisco.com> <CALtoyonxRb64odA5NAvdUfgCteqn4_s4GRoJZHaU55_4iLvTyQ@mail.gmail.com>
In-Reply-To: <CALtoyonxRb64odA5NAvdUfgCteqn4_s4GRoJZHaU55_4iLvTyQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.21.127]
Content-Type: multipart/alternative; boundary="_000_D2DBCB3E10DD58aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/G_dN302K812Sa2_-DFfFnwmPZjA>
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 00:28:20 -0000

On 2/6/16, 3:18 PM, "Stan Ratliff" <ratliffstan@gmail.com<mailto:ratliffstan@gmail.com>> wrote:

Stan:

Hi!

I'm mostly acting as the Devil's Advocate..

Alvaro,


On Sat, Feb 6, 2016 at 5:22 PM, Alvaro Retana (aretana) <aretana@cisco.com<mailto:aretana@cisco.com>> wrote:
On 1/18/16, 7:51 PM, "manet on behalf of Stan Ratliff" <manet-bounces@ietf.org<mailto:manet-bounces@ietf.org> on behalf of ratliffstan@gmail.com<mailto:ratliffstan@gmail.com>> wrote:

Stan:

Hi!

You'll need references for L2 security.

OK. Do you have any in mind?

No, you're the ones writing the spec. ;-)

Seriously…  If you write "MUST take steps to secure the Layer 2", then I really hope you (authors, WG, etc.) have specifics in mind. That question will come up.





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?

I'm confused. We tried to state the DLEP only works over 1 hop. Reliance on MAC addresses forces that. If DLEP isn't used as expected, why would anyone think it would work as expected? Or be secure? A requirement to document use cases outside the document seems to me like a never-ending task - after all, "we don't know what we don't know". We could sit & think about "perverse implementations" almost forever. At the end of the day, if DLEP is not used as expected, all bets are off.

Having said that, would the addition of text stating "Using DLEP with multiple network hops between router and modem is out of scope of this document, and results are unpredictable" serve to address your comment?

That would make me happy, but it wouldn't address my comment.  Note that the reliance on MAC addresses is explained as an assumption (not a requirement)…

I think we all understand when/how DLEP is intended to be used, but it is the SecDir/SEC ADs job to ask those "what if" questions.  No one can guarantee that DLEP won't be used unexpectedly — my real intent it to prevent the impulse of identifying anything as mandatory if it is not required.

I see that the document does include the optional use of TLS — I'm assuming most deployments would set the bit to 0.  It is not discussed anywhere when it might be set to 1, if at all.  If the provision for additional security is already there, the door is then open for all kinds of scrutiny.

Alvaro.




Regards,
Stan





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.

Alvaro.



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