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. One pending comment is this one: > > [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. 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 > -----Message d'origine----- > De : Christian Huitema [mailto:huitema@xxxxxxxxxxx] > Envoyé : lundi 5 octobre 2020 17:20 > À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@xxxxxxxxxx>; > secdir@xxxxxxxx > Cc : opsawg@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-opsawg-model- > automation-framework.all@xxxxxxxx > Objet : Re: [Last-Call] Secdir last call review of draft-ietf- > opsawg-model-automation-framework-06 > > > On 10/5/2020 1:02 AM, mohamed.boucadair@xxxxxxxxxx wrote: > > Hi Christian, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Christian Huitema via Datatracker [mailto:noreply@xxxxxxxx] > >> Envoyé : dimanche 4 octobre 2020 01:20 À : secdir@xxxxxxxx Cc : > >> opsawg@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-opsawg-model- > >> automation-framework.all@xxxxxxxx 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 > _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
