[manet] Roman Danyliw's Discuss on draft-ietf-manet-dlep-multi-hop-extension-06: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 01 May 2019 20:40 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 12647120094; Wed, 1 May 2019 13:40:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-manet-dlep-multi-hop-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.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <155674321306.791.1391699664410908649.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 13:40:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/IwR8tJL5HhTMmxiauEmllYyRE5g>
Subject: [manet] Roman Danyliw's Discuss on draft-ietf-manet-dlep-multi-hop-extension-06: (with DISCUSS and 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: Wed, 01 May 2019 20:40:13 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-manet-dlep-multi-hop-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-multi-hop-extension/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This extension (much like draft-ietf-manet-dlep-pause-extension) seems to
provide a mechanism to direct a modem to drop traffic in an unauthenticated
fashion -- for directly connected networks via the terminate action; and for
multi-hop networks via the suppress action.

For example, per the mobile scenario in Section 4 of RFC8175, a compromised
laptop in the switch could use this extension instruct the modem to drop
packets without authentication.

I saw in Warren’s comment ballet on draft-ietf-manet-dlep-pause-extension
(https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ballot/)
that

“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.”

I believe the same caveat is needed in this draft as they are enabling similar
behavior.  Please correct me if I’m conflating the capabilities of this
extension with the pause extension.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few questions and an editorial nit.

(1) Section 1.  Editorial.  There is a sentence fragment “example using.” which
likely needs to be removed.

(2) Section 2.  Per “The use of the Multi-Hop Forwarding Extension SHOULD be
configurable”, what is meant by configurable?

(3) Section 3.2.2 and 3.2.3.  The Terminate and Direct Connection messages are
not supposed to be (MUST NO) be sent in a Session Update Message.  How should
the modem behave if it receives one anyway?