Subject: [secdir] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06

From: Christian Huitema via Datatracker <[email-masked]>
Date: Sat, 03 Oct 2020 16:19:56 -0700

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?

---

From: <[email-masked]>
Date: Mon, 5 Oct 2020 08:02:13 +0000

Hi Christian, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Christian Huitema via Datatracker [mailto:[email-masked]]
> Envoyé : dimanche 4 octobre 2020 01:20
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; draft-ietf-opsawg-model-
> [email-masked]
> Objet : Secdir last call review of draft-ietf-opsawg-model-
> automation-framework-06
> 
> 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. 

 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.

> 
> 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. 

 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. 

> 
> 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.  

> 
> 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. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 5 Oct 2020 08:20:26 -0700

> [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.

>    countermeasures will be applied.

Yes, please.

> [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 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?

> [Med] This is the role of the assurance functions. See also the NEW text suggested above.
Yes, the new text is useful.
> [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

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 07:22:02 +0000

Hi Christian, 

You made good points. Thanks. 

I went with the following modifications to try to address them:

* Update the title of the layering architecture to insist the view within the same operator:  

OLD: 
 Figure 3: Layering and Representation

NEW
 Figure 3: Layering and Representation Within a Network Operator

And added this NEW text to further insist on this aspect: 

 "All these elements (i.e., Orchestrator(s),	
 Controller(s), device(s)) are under the responsibility of the same	
 operator."

* Mention how the composite service case is handled: 

NEW:
 A composite service offered by a network operator may rely on	
 services that are offered by other operators.  In such case, the	 
 network operator acts as a "Customer" to request services from other	
 networks.  The operators providing these services will then follow	
 the layering depicted in Figure 3.

* Cover service violation (including "bad" partners): 

NEW:
   A provider may rely on services offered by other providers to build
   composite services.  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 (e.g., Section 2.1 of [RFC4176]).  Misbehaving peer
   providers will thus be identified and appropriate countermeasures
   will be applied.

* Internal layer misalignment (corrupted data, manipulated data reporting, ..): 

NEW:
   To detect misalignment between layers that might be induced by
   misbehaving nodes, upper layers should continuously monitor the
   perceived service (Section 4.1.3) and should proceed with checks to
   assess that the provided service complies with the expected service
   and that the data reported by an underlying layer is matching the
   perceived service by the above layer.  Typically, such checks are the
   responsibility of the service diagnosis (Section 4.1.4).

* Misbehaving Nodes: 

NEW:
   Network operators should monitor and audit their networks to detect
   misbehaving nodes and abnormal behaviors.  For example, OAM discussed
   in Section 4.1.4 can be used for that purpose.

> development of service descriptions.

Models must anyway comply with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. These models must identify sensitive data and so on. I'm afraid that no change is needed for this one.  

Cheers,
Med

> De : Christian Huitema [mailto:[email-masked]]
> Envoyé : lundi 5 octobre 2020 17:20
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]
> Objet : Re: [Last-Call] Secdir last call review of draft-ietf-
> opsawg-model-automation-framework-06
> 
> 
> >> Envoyé : dimanche 4 octobre 2020 01:20 À : [email-masked] Cc :
> >> [email-masked]; [email-masked]; draft-ietf-opsawg-model-
> >> [email-masked] Objet : Secdir last call review
> of
> >> draft-ietf-opsawg-model-
> >> automation-framework-06
> >>
> 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.
> 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.
> 
> does
> >> not discuss what happens when some providers try to game the
> system
> > 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).
> >
> >> network and device. Creation of services will trigger
> requirements on
> >> the networks, and then configuration of devices. Performance
> but
> >> these processes only secure "point to point"
> >> 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] 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.
> 
> 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?
> 
> > [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.
> >
> 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.
> I will leave that to you and the RFC Production Center. That was
> just a side remark.
> 
> -- Christian Huitema
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Oct 2020 08:33:55 -0700

Christian, thanks for the review.
Med, thanks for the updates and discussion.
These exchanges improved the document a lot, so I had much less to cover in
my No Objection ballot.

-Ben

On Tue, Oct 06, 2020 at 07:22:02AM +0000, [email-masked] wrote:
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call