Re: [manet] Warren Kumari's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS)

Lou Berger <lberger@labn.net> Thu, 11 April 2019 12:01 UTC

Return-Path: <lberger@labn.net>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300FE120131 for <manet@ietfa.amsl.com>; Thu, 11 Apr 2019 05:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 sp5RIUuRR9Xo for <manet@ietfa.amsl.com>; Thu, 11 Apr 2019 05:01:24 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A98120223 for <manet@ietf.org>; Thu, 11 Apr 2019 05:01:24 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 55E4D17670F for <manet@ietf.org>; Thu, 11 Apr 2019 05:58:04 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EYLEhP8rjVLCbEYLEhsOTo; Thu, 11 Apr 2019 05:58:04 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nPOhAwh8KuAueBPThEAr6ByIpb/fSW3SBSL8TjqYv80=; b=O30tALpYU9LRPvzjWvQs/KDvVS x+mMjzJeO/Svz3dQmKmJKjwUP/PirlFRexpxkvJu9oXhXPu4PZMKRoP8yGqAwuALGXmdzX1QMwmb9 fgr2Uh4BMIptuc4NHLfu7BcGY;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:49738 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1hEYLD-003hpZ-UR; Thu, 11 Apr 2019 05:58:04 -0600
To: Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>
Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff <sratliff@idirect.net>, aretana.ietf@gmail.com, manet-chairs@ietf.org, manet@ietf.org
References: <155474982892.30185.1930382368416788523.idtracker@ietfa.amsl.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <7465dc7c-e64b-9926-5e8d-9203e4767c7b@labn.net>
Date: Thu, 11 Apr 2019 07:58:02 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <155474982892.30185.1930382368416788523.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1hEYLD-003hpZ-UR
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:49738
X-Source-Auth: lberger@labn.net
X-Email-Count: 15
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/3ixHod1SEvbjo6_bH_Ugx4jFcfY>
Subject: Re: [manet] Warren Kumari's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Apr 2019 12:01:26 -0000

On 4/8/2019 2:57 PM, Warren Kumari via Datatracker wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-manet-dlep-pause-extension-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Please note that I'm really not a DLEP person, and so this may be completely
> incorrect -- in which case I'm (of course!) happy to clear my discuss.
>
> Hypothetical Scenario:
> My next-door neighbor keeps using up all the bandwidth, making my Internets
> slow! Stupid neighbor!
>
> Until now I didn't have much motivation to mess with DLEP (it didn't really
> gain me anything), but now I can spoof Pause Data Items to get the router to
> stop sending traffic to her, freeing up all the bandwidth for me.
>
> The security considerations section doesn't *really* cover this -- it says:
> " Note that this extension does allow a compromised or impersonating modem to
> suppress transmission by the router, but this is not a substantively different
> attack by such a compromised modem simply dropping all traffic destined to, or
> sent by a router." -- that only covers compromised modems, not impersonating
> modems.

FWIW an impersonator can shut a router completely down, by constantly 
resetting the DLEP session.  RFC8175 defines TLS protected DLEP as the 
solution.  To make this clear(er) the text has been updated to read


   Note that this extension does allow a compromised or impersonating
   modem to suppress transmission by the router.  Similar attacks are
   generally possible base DLEP, for example an impersonating modem may
   cause a session reset or a compromised modem simply can
   drop all traffic destined to, or sent by a router.  <xref
   target="RFC8175"/> defines the use of TLS to protect against the
   impersonating attacker.

suggested improvements are most welcome! (but see below addition before 
drafting ;-)

> It also says:
> "[RFC8175] defines the use of TLS to protect against the impersonating
> attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't
> require it.
>
> RFC8175 Security Considerations also say:
> " 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."
> and "Similar issues can arise if DLEP data is used as an input to policing
> algorithms -- injection of malicious data via DLEP can cause those policing
> algorithms to make incorrect decisions, degrading network throughput."
>
> It seems that this specification is specifically allowing the dataplane to be
> affected by (spoofed) DLEP messages, and in a much more direct way than
> discussed in the RFC8175 security considerations section. I think that this is
> dangerous without much more direct advice (like "MUST use TLS" or similar).

I have no objection to something.  How about, to the end of the prior 
paragraph:

   Implementations of the extension defined in this document MUST support
   configuration of TLS usage, as describe in <xref target="RFC8175"/>,
   in order to protect configurations where injection attacks are
   possible, i.e., when the link between a modem and router is not
   otherwise protected.

Lou

>
>
>
>