[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: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- DISCUSS -> NoObj. 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 modems. 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). -------
- [manet] Warren Kumari's No Objection on draft-iet… Warren Kumari via Datatracker