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

Christian Huitema <> Mon, 05 October 2020 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 357333A0B5B for <>; Mon, 5 Oct 2020 08:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QpCmX7AN6cZU for <>; Mon, 5 Oct 2020 08:33:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 761F63A0B5E for <>; Mon, 5 Oct 2020 08:33:28 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kPSUK-0000tP-BH for; Mon, 05 Oct 2020 17:33:23 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4C4kn80lTcz1V3K for <>; Mon, 5 Oct 2020 08:20:28 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kPSHr-0003CF-VL for; Mon, 05 Oct 2020 08:20:27 -0700
Received: (qmail 22627 invoked from network); 5 Oct 2020 15:20:27 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 5 Oct 2020 15:20:27 -0000
To:, "" <>
Cc: "" <>, "" <>, "" <>
References: <> <6471_1601884933_5F7AD305_6471_296_1_787AE7BB302AE849A7480A190F8B93303154CFFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Christian Huitema <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <>
Date: Mon, 5 Oct 2020 08:20:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <6471_1601884933_5F7AD305_6471_296_1_787AE7BB302AE849A7480A190F8B93303154CFFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDnxl3lEv+D2ifmeO1jOKM+cRX qYbtEQV1z/L435ZRxFQ9JRr01hVIlwpzB50G+oyR+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxph9w6EwXICYy0ePXtGEMhqrwBb733ZN4jAbrTI5wHo5JWU6UgOqKJ9sMwhVoOBGSAIboXtx P9OF0EfNs5TqNq2Yhy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8bHkXi9GLeWp7+HXTQ99TbN4nuZrRf7bMi0WRR6pZ+nWcMukJUdRW8DYus2N8h3mJpX 0SU68ek9wyYNR7nSKrZbQsAM8hGlAkv+YXlQiOyIRazNjLvclnGzlTC8ZgkR3laIWqvAxiBHuIuS y5fCAlEkHWdEoOAn+pyn1FCAnUcslFACVO3tx78u0bG7If2TCVS6MJc3NAuQuOQNu034Xbk0eoDY +s9WKCp7noRNuLzm0znzSXChKWk/itcbicJsIPcXdWV5hJvxxhlt4adIoo6yfqb5R4VemuUI6bcE ARsm0De6PaZO6/JToEyx4tmc5OljkPSpPXAVjl2oMr8a1xm0wfXUFMjTH2DyD8i5kO5bZlYFvf25 LVONYbYifH5OzZCwIgD/xDehea09OpnwSuobZrrGExMR7eTbBjMGDKI3ijhhJn7Muv/NHXl0o++8 3wM=
Archived-At: <>
Subject: Re: [OPSAWG] [Last-Call] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Oct 2020 15:33:30 -0000

On 10/5/2020 1:02 AM, wrote:
> Hi Christian, 
> Thank you for the review. 
> Please see inline.
> Cheers,
> Med
>> -----Message d'origine-----
>> De : Christian Huitema via Datatracker []
>> Envoyé : dimanche 4 octobre 2020 01:20
>> À :
>> Cc :;; draft-ietf-opsawg-model-
>> Objet : Secdir last call review of draft-ietf-opsawg-model-
>> automation-framework-06
>> 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.
> [Med] There is no such assumption in the draft but we can accommodate that case. 

It seems I was led to the wrong conclusion by the exposition of the
layering between services, networks and devices. If you in fact assume
that all the "networks" involved in the provision of the service are
under the same management, by a single operator, then you should say
that loudly and clearly in the draft.

>  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.
> [Med] The various blocks discussed in the document are within the scope of the ** same provider **. 
> That's said, if a provider relies upon other providers to deliver a given service, the model will apply in a recursive manner: That is, a network can act as a "customer" and request services from other networks. The peer network will then follow the various levels depicted in the architecture to deliver the service.
> Any failure of a peer provider to deliver an agreed service is a violation of the service level agreement. Such violation is detected by means of the service fulfilment/assurance and appropriate counter-measures will be followed. These counter-measures may be technical (switch to another provider) and/or contractual (penalties). 
> We can add the following: 
>    A provider may rely upon services offered by other providers.
>    Appropriate mechanisms should be enabled by the provider to monitor
>    and detect a service disruption from these providers.  The
>    characterization of a service disruption (including, mean time
>    between failures, mean time to repair), the escalation procedure, and
>    penalties are usually documented in contractual agreements.
>    Misbehaving peer providers will thus be identified and appropriate
>    countermeasures will be applied.

Yes, please.

>> 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.
> [Med] It is up to each individual model to call out those, not this document. 

I am concerned about that. If that's the approach, then it should be
stated very forcefully, as in some kind of MUST requirement for the
development of service descriptions.

>  The
>> document articulates a hierarchy of Yang modules. Why does it not
>> articulate the trust boundaries between the different actors?
> [Med] Because the focus is on what happens within  ** a single provider **. The interaction with other providers is no more than a provider acting as a "customer" for a service offered by another provider. 
> The customer-facing interface is out of scope. We think this this now clarified with the review from Brian. 

I already asked that you state the single provider focus more clearly in
introduction. I would appreciate if it was also called out in the
security considerations. You assume that the various elements are under
a single management authority, and thus are cooperating in good faith.
Applying the model without that assumption opens the possibility of a
range of attacks, in which competing actors might be dissimulating or
manipulating information. You consider that out of scope, but then that
also mean that the model should not be applied to orchestration of
services across multiple operators.

On the other end, there is the particular issue of the untrusted device.
Consider the now classic scenario in which attackers manage to obtain
the credential of some employees of the operator, maybe through a
phishing attack. The attackers then use those credentials to gain access
to a couple of network devices. Have you considered how they might
leverage that access through the service architecture? Or, conversely,
have you considered whether the architecture provides functions for the
operator to detect and isolate such attacks?

>> 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?
> [Med] All the levels are under the responsibility of the same provider. An underlying level can report performance data but the above level can also proceed with OAM checks as per Section 4.1.4. Anomalies can thus be detected locally.   
>> 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?
> [Med] This is the role of the assurance functions. See also the NEW text suggested above.
Yes, the new text is useful.
>> 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?
> [Med] None of these drafts is normative. There is not risk to create a publication cluster. 

I will leave that to you and the RFC Production Center. That was just a
side remark.

-- Christian Huitema