[multipathtcp] Roman Danyliw's No Objection on draft-ietf-mptcp-rfc6824bis-15: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 15 May 2019 19:31 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: multipathtcp@ietf.org
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7CB1200F1; Wed, 15 May 2019 12:31:03 -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-mptcp-rfc6824bis@ietf.org, Philip Eardley <philip.eardley@bt.com>, mptcp-chairs@ietf.org, philip.eardley@bt.com, multipathtcp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <155794866343.30707.4998411980016390930.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 12:31:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/-dL1QPbg_MDNx4EqPQa9hsfBf24>
Subject: [multipathtcp] Roman Danyliw's No Objection on draft-ietf-mptcp-rfc6824bis-15: (with COMMENT)
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 19:31:04 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-mptcp-rfc6824bis-15: 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-mptcp-rfc6824bis/



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

(1) Section 2.3.  Editorial.  s/successful reception/successful receipt/

(2) Section 5.  Thanks for mentioning the possibility of a downgrade attack in
both the protocol version and algorithm negotiation.  Since [RFC7430] spells
out a clear attacker taxonomy, I’d recommend using it here too (just like it
was used in the new text added for the downgrade attack on the version
negotiation).

Old:
Note that this would be susceptible to bid-down attacks only if the attacker
was on-path (and thus would be able to modify the data anyway).

Proposed New:
Note that this negotiation would be susceptible to a bid-down attack by an
on-path active attacker who could modify the crypto capability bits response
from the receiver to use a less secure crypto mechanism.

(3) Section 6.
> Intrusion Detection Systems look out for traffic patterns and
>     content that could threaten a network.  Multipath will mean that
>     such data is potentially spread, so it is more difficult for an
>      IDS to analyze the whole traffic, and potentially increases the
>      risk of false positives.

I’d recommend being a bit clearer on the impact to NIDS.  Perhaps something
like the following:

Intrusion Detection/Prevention Systems (IDS/IPS) observe packet streams for
patterns and content that could threaten a network.  Multipath may require the
instrumentation of additional paths and correlation of data from these paths to
maintain comparable visibility into all of the traffic between end-points. 
Without such changes, an IDS would get an incomplete view of the traffic where
by increasing the risk of missing traffic of interest and producing false
positive alerts.  MPTCP-aware IDS/IPS would need to read tokens to correlate
multiple subflows and reassemble them for analysis.