[manet] Warren Kumari's No Objection on draft-ietf-manet-dlep-pause-extension-06: (with COMMENT)

Warren Kumari via Datatracker <noreply@ietf.org> Thu, 11 April 2019 13:29 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: manet@ietf.org
Delivered-To: manet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5DC12021F; Thu, 11 Apr 2019 06:29:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: "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, sratliff@idirect.net, manet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <155498939209.25091.12221953944223860700.idtracker@ietfa.amsl.com>
Date: Thu, 11 Apr 2019 06:29:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/CzuNzqsMcp_Lb6BEn-_5deKyctA>
Subject: [manet] Warren Kumari's No Objection on draft-ietf-manet-dlep-pause-extension-06: (with COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
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 13:29:52 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-manet-dlep-pause-extension-06: No Objection

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:



Lou will add:
  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.

to address my DISCUSS.

--- Archived DISCUSS position for hysterical raisins ---

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

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).