[OPSAWG] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06

Christian Huitema via Datatracker <noreply@ietf.org> Sat, 03 October 2020 23:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B984F3A0983; Sat, 3 Oct 2020 16:19:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: opsawg@ietf.org, last-call@ietf.org, draft-ietf-opsawg-model-automation-framework.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160176719670.27275.17469866976212039001@ietfa.amsl.com>
Reply-To: Christian Huitema <huitema@huitema.net>
Date: Sat, 03 Oct 2020 16:19:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Kbjrdjufu9pJAyT2Oc_oupNOMSY>
Subject: [OPSAWG] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2020 23:19:57 -0000

Reviewer: Christian Huitema
Review result: Has Issues

The document proposes an architecture for describing and provisioning services
such as L3VPN or L2VPN. This is an ambitious architecture, aiming at providing
end-to-end services over concatenations of network services provided by
independent providers. I am concerned that the model does not expose trust
boundaries during these providers, and that the security section does not
discuss what happens when some providers try to game the system or otherwise
fail to cooperate.

The architecture organizes functions in three levels, service, network and
device. Creation of services will trigger requirements on the networks, and
then configuration of devices. Performance monitoring at the device level will
inform service assurance and service optimizatio at the network level, and
service assurance, optimization and diagnostic at the service level. The
configurations and the performance measurements are described using Yang models.

The Yang modules are designed to be accessed through secrure protocols, such as
NETCONF over SSH or RESTCONF over HTTPS. This provides authentication of the
servers and protection of the data, and allows implementation of access
control. That's a good basis, but these processes only secure "point to point"
interfaces between functions in the system. This presupposes honest cooperation
between all actors, despite the fact that those actors often are in competition.

The security considerations consider misconfiguration attacks such as the
creation of forwarding loops, leakage of sensitive information, and traffic
isolation issues. These are all interesting issues, but they are only mentioned
in the architecture document as guidelines for the future development of actual
services. I think issues such as the protection of sensitive information should
be developed in the model itself, because they are generic. The document
articulates a hierarchy of Yang modules. Why does it not articulate the trust
boundaries between the different actors?

In addition to three classes of issues listed in the security considerations, I
am also concerned with possibilities of retaining or falsifying data. What if
an actor hides or fakes performance monitoring data, either out of malice or
due to faulty equipement? Will that disrupt the provision of the services? What
tools are available to detect such behavior? What if a network provide
overpromises, in order to attract contracts? I understand that the ultimate
remedies lies in contract obligations and contract enforcement, but that
enforcement has to be based on data. How is the architectur organizing the
collection of the data?

On a side note, I find that this architecture cites a large number of other
drafts such as evpn, l2vpn, l3vpn, etc. These drafts in turn presumably cite
the architecture, thus forcing the RFC production to organize all of them in a
large publication cluster. Is it really required for the architecture document
to cite all the documents that will later use it?