[secdir] Secdir last call review of draft-ietf-bess-datacenter-gateway-10

Daniel Migault via Datatracker <noreply@ietf.org> Tue, 27 April 2021 16:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2FD3A15B6; Tue, 27 Apr 2021 09:24:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Daniel Migault via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: bess@ietf.org, draft-ietf-bess-datacenter-gateway.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161954068804.26944.17229787113752757407@ietfa.amsl.com>
Reply-To: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 27 Apr 2021 09:24:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pkR7ha1N2UYrCSRYH2f1QSx_Eo8>
Subject: [secdir] Secdir last call review of draft-ietf-bess-datacenter-gateway-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2021 16:24:48 -0000

Reviewer: Daniel Migault
Review result: Ready

Hi,

Review result: Ready

I reviewed this document as part of the Security Directorate's ongoing effort
to review all IETF documents being processed by the IESG.  These comments were
written primarily for the benefit of the Security Area Directors.  However, in
this case these comments mostly reflect some question to clarify my own
understanding. Document authors, document editors, and WG chairs should treat
these comments just like any other IETF Last Call comments.

Yours,
Daniel

Just to clarify my understanding of Fig 1. BGP usually selects the best route,
so if AS1-AS2 is the best, none of the traffic will go through AS3. However
even in this configuration AS2 will select one of the GW and all traffic will
go only to one of the GW1 or GW2. The Add-Path might be able to distinguishes
between AS1-AS2 and AS3 but AS1-AS2 cannot be subdivided between two paths one
that would terminates in GW1 and another that would terminates at GW2.

I am not sure following acronyms may be expanded as well as AFI/SAFI being
described with text as opposed to their values. I let you decide whether that
is needed or not.

OLD:
 An IPv4 or IPv6 NLRI containing one of the GW's loopback addresses
      (that is, with an AFI/SAFI pair that is one of 1/1, 2/1, 1/4, or
      2/4).

NEW
 An IPv4 or IPv6 Network Layer Reachability Information (NLRI) [RFC4760]
 containing one of the GW's loopback addresses (that is, with an Address Family
 Number (AFI)/ Subsequent Address Family (SAFI) pair that is one of IPv4/NLRI
 used for unicast forwarding (1/1), IPv6/NLRI used for unicast forwarding
 (2/1), IPv4/NLRI with MPLS Labels (1/4), or IPv6/NLRI with MPLS Labels (2/4)).


Security consideration:

When the information is shared between the domains, I am wondering if the
information is encrypted or if the communication appears in clear text. If no
encryption is used, that information is actually not limited to the two domains
but to anyone on path can read it. If that is the case, information provided by
the Egress SR domain to the Ingress SR Domain seems to me transiting through
the backbone which makes the information pretty much public. I am wondering if
I am missing something.