[bess] Roman Danyliw's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 19 May 2021 20:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD823A1D5A; Wed, 19 May 2021 13:02:50 -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-bess-datacenter-gateway@ietf.org, bess-chairs@ietf.org, bess@ietf.org, Matthew Bocci <matthew.bocci@nokia.com>, matthew.bocci@nokia.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <162145456955.28529.8072971663484949985@ietfa.amsl.com>
Date: Wed, 19 May 2021 13:02:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/XGqZ_OB7RhKeE5nTxBRWszhBF6A>
Subject: [bess] Roman Danyliw's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2021 20:03:00 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: 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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/



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

RFC8402 tells us:

(a)“Segment Routing domain (SR domain): the set of nodes participating in the
source-based routing model …

(a.1) “These nodes may be connected to the same physical infrastructure (e.g.,
a Service Provider's network).”

(a.2) “They may as well be remotely connected to each other (e.g., an 
enterprise VPN or an overlay).”

(b) “By default, SR operates within a trusted domain.  Traffic MUST be filtered
at the domain boundaries.” My understanding of this document is that it is an
enabling capability to help establish SR domains of the like described in
(a.2).  What I see missing is text that provides the confidence suggested by
the language of “trusted domain” in (b).

-- Section 1 hints at various VPN technologies perhaps being used  “The various
ASes that provide connectivity between the Ingress and Egress   Domains could
each be constructed differently and use different technologies such as IP, MPLS
with global table routing native BGP to the edge, MPLS IP VPN, SR-MPLS IP VPN,
or SRv6 IP VPN.”  However, the security properties of all of those aren’t clear
to a degree that would seem consistent with being a “trusted domain”.  For
example, saying “IP” might suggest that naked IP packets with SR headers (with
no additional security primitives) could be dropped onto the open Internet, or
at least through networks not under the control the “data centers” use case
suggested by the name of the document.

-- The discussion at
https://mailarchive.ietf.org/arch/msg/bess/zY783PgnXSCp6GNSRF4kY0diLYs/ around
the forwarding plane trust model is also informative.   It is noted that that
the “transit nodes of the AS are not part of the domain.”  I could agree, but
only to the degree that the SR packets are tunneled in such as way that
suggested a trusted domain at least of equal security as (a.1).

I think language is needed to describe the normative security requirements of
the tunnels that will be created on top of the routes enables by this work to
substantiate the claim that at a “trusted domain” is being maintained.  This
has some overlap with John’s text about clarify the proposed trust model.


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

Thank you to Daniel Migault for the SECDIR review.

I support John DISCUSS positions.