Caution - this draft represents MEF work in progress and is subject to change.
This draft document represents MEF work in progress; it has not achieved full MEF standardization and is subject to change. Changes are likely before this becomes a fully endorsed MEF Standard. The reader is strongly encouraged to keep this in mind and review the Release Notes (if applicable) when making a decision on adoption. Additionally, because this document has not been adopted as a Final Specification in accordance with MEF’s Bylaws, Members are not obligated to license patent claims that are essential to implementation of this document under MEF’s Bylaws.
The information in this publication is freely available for reproduction and use by any recipient and is believed to be accurate as of its publication date. Such information is subject to change without notice and MEF Forum (MEF) is not responsible for any errors. MEF does not assume responsibility to update or correct any information in this publication. No representation or warranty, expressed or implied, is made by MEF concerning the completeness, accuracy, or applicability of any information contained herein and no liability of any kind shall be assumed by MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or user of this document. MEF is not responsible or liable for any modifications to this document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication or otherwise:
a) any express or implied license or right to or under any patent, copyright, trademark or trade secret rights held or claimed by any MEF member which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor
b) any warranty or representation that any MEF members will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor
c) any form of relationship between any MEF member and the recipient or user of this document.
This draft document represents MEF work in progress, has not achieved full MEF standardization and is subject to change. There are known unresolved issues that are likely to result in changes before this becomes a fully endorsed MEF Standard. The reader is strongly encouraged to review the Release Notes when making a decision on adoption. Additionally, because this document has not been adopted as a Final Specification in accordance with MEF’s Bylaws, Members are not obligated to license patent claims that are essential to implementation of this document under MEF’s Bylaws.
Implementation or use of specific MEF standards, specifications, or recommendations will be voluntary. This document is provided “as is” with no warranties whatsoever, express of implied, including without limitation, any warranties of merchantability, non-infringement, accuracy, completeness or fitness for any particular purpose. MEF and its members disclaim all liability, including liability for infringement of any proprietary rights, relating to use of information in this document.
Table of Contents 1 List of Contributing Members .................................................................................................... 1
Figure 20 - Example of a Clean File ............................................................................................................. 57
Figure 21 - Example of Malware Detected and File Removed, using a Signature Scan .............................. 58
Figure 22 - Example of Malware Detected and File Removed, using a Sandbox ........................................ 58
Figure 23 - Example of Malware Detected and File Reconstructed ........................................................... 59
List of Tables Table 1 - Terminology and Abbreviations ..................................................................................................... 7
Table 2 - Security Action List Usage Policy .................................................................................................. 22
Table 3 - Items to be included in a SEN....................................................................................................... 25
Table 4 - Summary of Security Functions ................................................................................................. 41
Table 5 - Mapping of threats or vulnerabilities to predominant security functions .................................. 60
The following members of the MEF participated in the development of this Standard and have requested to be included in this list.
Editor Note 1: This list will be finalized before Letter Ballot. Any member that comments in at least one CfC Ballot is eligible to be included by opting in before the Letter Ballot is initiated. Note that it is the MEF member that is listed here (typically a company or organization), not their individual representatives.
This document specifies the Policy Criteria needed to add Application Security to SD-WAN Services. As such, it is based on the framework specified in MEF 70.1 [2].
Specifically, security functions and related actions are defined, each of which can be applied per Application Flow. These security functions include:
• Middle-Box Function, which when enabled, supports the decryption and re-encryption of a TLS-encrypted Application Flow (e.g., HTTPS). While this breaks the end-to-end guarantee of TLS, as a result the following security functions are made available.
• IP, Port and Protocol Filtering, which, when enabled, can block a list of IP addresses, protocols and/or port numbers.
• DNS Protocol Filtering, which when enabled, can block access to a list of prescribed DNS Servers operating using the DNS protocol over 53/TCP and 53/UDP.
• Domain Name Filtering, which when enabled, can block access to a list of domains. • URL Filtering, which when enabled, can block access to a list of URLs. • Malware Detection and Removal, which when enabled, scans objects for malware and can
remove the malware.
In addition, key concepts include:
• Allow List, a list of match criteria entries (IP addresses, domain names, URLs or other IDs) that are allowed
• Block List, a list of match criteria entries (IP addresses, domain names, URLs or other IDs) that are blocked
• Quarantine List, a list of match criteria entries (IP addresses, domain names, URLs or other IDs) that are blocked, but can be managed by the Subscriber to move match criteria entries to an Allow List or a Block List
• Security Event Notification (SEN), which is used to notify the Subscriber and Service Provider personnel, e.g., Security Operations Center (SOC) personnel, of security related events
This section defines the terms used in this document. In many cases, the normative definitions to terms are found in other documents. In these cases, the third column is used to provide the reference that is controlling, in other MEF or external documents.
In addition, terms defined in MEF 61.1 [1] and MEF 70.1 [2] are included in this document by reference and are not repeated in the table below. Terms marked with * are adapted from terms in MEF 70.1 [2].
Term Definition Reference
Allow An action taken by a security function, where an Application Flow or a subset of an Application Flow is permitted.
This document
Allow List A list of match criteria entries (IP addresses, domain names, URLs or other IDs) that are allowed.
This document
Block An action taken by a security function, where an Application Flow, or a subset of an Application Flow, is denied.
This document
Block List A list of match criteria entries (IP addresses, domain names, URLs or other IDs) that are blocked.
This document
CA Certification Authority RFC 4210 [13]
Certification Authority
A third-party organization, trusted both by the certificate owner and by the party relying upon the certificate, that issues digital certificates.
This document
Common Vulnerabilities and Exposures
CVE® is a list of entries - each containing an identification number, a description, and at least one public reference - for publicly known cybersecurity vulnerabilities. CVE Entries are used in numerous cybersecurity products and services from around the world, including the U.S. National Vulnerability Database (NVD).
MITRE
Computer Virus A computer program that, when executed, replicates itself by modifying other computer programs and inserting its own code.
This document
Computer Worm A computer program that replicates itself in order to spread to other computers.
This document
Coordinated Universal Time
The primary time standard by which the world regulates clocks and time. It is within about 1 second of mean solar time at 0° longitude, and is not adjusted for daylight saving time. In some countries, the term Greenwich Mean Time is used.
The act of monitoring, identifying, and blocking sensitive or important data from being stolen while in use, in motion across a network, and at rest (in storage).
This document
Digital Certificate A digital file that certifies the ownership of a public key by the owner of the certificate as specified in the ITU-T X.509 standard.
This document
DNS Domain Name System RFC 6895 [19]
DNS Protocol Filtering
Action taken by the Service Provider to check whether Domain Name System (DNS) messages on ingress or egress at an SD-WAN UNI are to be Allowed,
This document
Domain Name Filtering
Action taken by the Service Provider to check whether access to a domain name is to be allowed or blocked on ingress at an SD-WAN UNI based on whether the domain name is on a Block List or a Quarantine list.
This document
Domain Name System
It provides replicated distributed secure hierarchical databases that store "resource records" (RRs) under domain names.
RFC 6895 [19]
FQDN Fully Qualified Domain Name RFC 4703 [14]
Fully Qualified Domain Name
The full name of a system, rather than just its hostname. For example, "venera" is a hostname, and "venera.isi.edu" is an FQDN.
RFC 4703 [14]
HSTS HTTP Strict Transport Security RFC 6797 [18]
HTTP Hypertext Transfer Protocol RFC 7230 [21]
HTTP Strict Transport Security
The overall name for the combined User Agent and server-side security policy defined by RFC 6797. It provides a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.
RFC 6797 [18]
HTTPS Hypertext Transfer Protocol Secure RFC 2818 [8]
Hypertext Transfer Protocol
The Hypertext Transfer Protocol (HTTP) is a stateless application level protocol for distributed, collaborative, hypertext information systems. HTTP/1.1
Indicators of compromise (IOC) are forensic artifacts from intrusions that are identified on organizational information systems (at the host or network level). IOCs provide organizations with valuable information on objects or information systems that have been compromised.
NIST 800-53 [31]
Information Security Operations Center
An Information Security Operations Center (ISOC) is a dedicated site where enterprise information systems (web sites, applications, databases, data centers and servers, networks, desktops and other endpoints) are monitored, assessed, and defended.
Wikipedia
IOC Indicator of Compromise NIST 800-53 [31]
Malware Malware is defined as any malicious program or code that is harmful to systems or users of the systems.
This document
MBF Middle Box Function This document
Middle Box Function
A function used to decrypt and re-encrypt the Subscriber's encrypted TLS session in order to scan the Application Flow to perform security policy actions.
Adapted from ETSI
National Vulnerabilities Database
This NIST SP 800-53 database represents the security controls and associated assessment procedures defined in NIST SP 800-53 Revision 4 Recommended Security Controls for Federal Information Systems and Organizations.
NIST 800-53 [31]
NVD National Vulnerabilities Database NIST 800-53 [31]
Partially Qualified Domain Name
A domain name that does not include the full path of labels up to the DNS root. It is a relative name that has meaning only within a particular context. The partial name must be interpreted within that context to fully identify the node.
This document
IP, Port and Protocol Filtering
Action taken by the Service Provider to check whether an Application Flow includes source or destination IP addresses, destination port numbers and/or protocols that are to be allowed or blocked.
This document
PQDN Partially Qualified Domain Name This document
Quarantine List A list of match criteria entries (IP addresses, domain names, URLs or other IDs) that are blocked, but can be managed by the Subscriber to move a match criteria entry to an Allow List or Block List.
This document
Ransomware A computer program that threatens to publish the victim's data or perpetually block access to it unless a ransom is paid.
This document
Scareware A computer program which uses social engineering to cause shock, anxiety, or the perception of a threat in order to manipulate the user into buying unwanted software.
This document
Security Event Notification
A method to communicate a security event to the SD-WAN Subscriber and Service Provider personnel, e.g., SOC personnel.
This document
Security Operations Center
Facility that houses an information and network security team responsible for monitoring, analyzing and addressing an organization's security posture on an ongoing basis.
This document
SEN Security Event Notification This document
Security Service Provider
The Service Provider that provides the security functions for the SD-WAN service and coordinates with the SD-WAN Service Provider.
This document
Service Provider The SD-WAN Service Provider or a Security Service Provider. This document*
SOC Security Operations Center This document
Social Engineering In an information security context, the psychological manipulation of people into performing actions or divulging confidential information.
This document
String An alpha-numeric character set using Base 64 encoding, RFC 4648 [14]
TLS Transport Layer Security RFC 5246 [16]
Transport Layer Security
A cryptographic protocol designed to provide communications security over a computer network
RFC 5246 [16]
Uniform Resource Identifier
A URI is an identifier consisting of a sequence of characters matching the syntax rule named in Section 3 of RFC 3986. It enables uniform identification of resources via a separately defined extensible set of naming schemes. A URI can be classified as a locator, a name or both.
The subset of URIs that, in addition to identifying a resource, provides a means of locating the resource by describing its primary access mechanism (e.g., its network "location").
RFC 3986 [11]
Universally Unique IDentifier
A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs. Since a UUID is a fixed size and contains a time field, it is possible for values to rollover (around A.D. 3400, depending on the specific algorithm used). A UUID can be used for multiple purposes, from tagging objects with an extremely short lifetime, to reliably identifying very persistent objects across a network.
RFC 4122 [12]
URI Uniform Resource Identifier RFC 3986 [11]
URL Uniform Resource Locator RFC 3986 [11]
URL Filtering Action taken by the Service Provider to check whether access to a URL is to be allowed or blocked on ingress at an SD-WAN UNI.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC 2119 [5], RFC 8174 [26]) when, and only when, they appear in all capitals, as shown here. All key words must be in bold text.
Items that are REQUIRED (contain the words MUST or MUST NOT) are labeled as [Rx] for required. Items that are RECOMMENDED (contain the words SHOULD or SHOULD NOT) are labeled as [Dx] for desirable. Items that are OPTIONAL (contain the words MAY or OPTIONAL) are labeled as [Ox] for optional.
Security is a top requirement of most customers considering SD-WAN services. Enterprises are investing more and more in cyber security due to the increasing number and types of threats, the security and data protection requirements imposed by regulations, the costs of fixing damaged systems caused by cybercrime and the related customer impact costs (e.g., loss of customers) after a serious data breach. The Service Provider that supports security functions can offload the increasingly complex set of functions required to maintain and improve a Subscriber's IT security posture over time.
This document considers the following cyber threats that could be mitigated in an SD-WAN service:
• Computer Virus: A computer program that, when executed, replicates itself by modifying other computer programs and inserting its own code.
• Computer Worm: A computer program that replicates itself in order to spread to other computers.
• Trojan Horse: Any computer program which misleads users of its true, malicious intent and is generally spread by some form of social engineering.
• Ransomware: A computer program that threatens to publish the victim's data or perpetually block access to it unless a ransom is paid.
• Scareware: A computer program which uses social engineering to cause shock, anxiety, or the perception of a threat in order to manipulate the user into buying unwanted software.
• Social Engineering: In an information security context, the psychological manipulation of people into performing actions or divulging confidential information.
MEF 70.1 [2] describes a reserved policy name called ‘block’ that can apply to an Application Flow, i.e., an Application Flow can be blocked at an SWVC End Point. MEF 70.1 [2] also defines two policy criteria for Application Flow Security (AF-SECURITY-INGRESS and AF-SECURITY-EGRESS) that can apply to an Application Flow (ingress or egress), based on agreement with the Subscriber, and points to this document for the list of specific security functions and possible values. This document defines the security functions that fit within the AF-SECURITY-INGRESS and AF-SECURITY-EGRESS policy criteria, and specifies requirements on the Service Provider to adequately implement those security functions. Note that a given security function could block a subset of an Application Flow, depending on whether there is a perceived security threat. Block in this document is more granular than the block specified in MEF W70.1.
The security functions are listed here, and further detailed in Section 7.
• Middle-box Function (MBF): when enabled for a given Application Flow, decrypts the Subscriber's Transport Layer Security (TLS) encrypted traffic to allow for scanning and then re-encrypts. In this document, use of the term 'TLS' refers to TLS 1.2, as specified in IETF 5246 [16], unless another version is specified.
• DNS Protocol Filtering: when enabled for a given Application Flow, can block access to a list of DNS Servers.
• Domain Name Filtering: when enabled for a given Application Flow, can block access to a list of domains.
• URL Filtering: when enabled for a given Application Flow, can block access to a list of URLs (more granular than domains).
• Malware Detection and Removal: when enabled for a given Application Flow, scans objects for malware and can remove or modify the malware.
• Security Event Notification (SEN): is used to notify the Subscriber and Service Provider personnel when security actions are taken.
This document further describes security actions and security action policies that can be used to simplify the configuration of the security functions.
Figure 1 below depicts an example of two Application Flows that are identified on ingress at the SD-WAN UNI, one of which has security functions applied.
Figure 1 - Example of Application Security for Ingress Application Flows
In this example, Application Flow 1 carries traffic that does not require additional security functions defined in this document. Application Flow 2 carries traffic that requires a set of security functions to be applied to the traffic.
This document does not impose any explicit constraints on where in the SD-WAN network security functions can be applied - it allows for flexibility in various deployment options. It is assumed that when a security function is provided on an Application Flow, all possible paths have the same security scanning.
A Service Provider may distribute security functions in a cloud, edge computing node or Customer Premises Equipment (CPE), depending on the functionality and where it can be optimally placed.
This document does not address requirements to secure the SD-WAN network itself, or the encrypted Tunnel Virtual Connections (TVCs) - the SD-WAN Service Provider is responsible for securing its own network.
The remainder of the document is organized as follows:
• Key Concepts and Definitions are described and specified in Section 6. • Application Flow security functions are specified in Section 7. • References are listed in Section 8. • Use cases relating Application Flows and security functions are described in Appendix A. • A description of Transport Layer Security (TLS) 1.3 is provided in Appendix B. • Examples of Malware Detection and Removal are described in Appendix C. • A mapping of security threats to security functions is described in Appendix D. • A brief description of a detailed threat modeling report is provided in Appendix E, together
with a link to the threat modeling tool output, for interactive capability.
This section describes key concepts that are needed to properly define the security functions that are specified in Section 7.
Note that when the term support is used in a normative context in this document, it means that the Service Provider is capable of enabling the functionality upon agreement with the Subscriber.
6.1 Security Functions for Application Flows
Figure 2 below depicts a high-level perspective on the positioning of security functions in the context of traditional SD-WAN Application Flow classification and forwarding. Security functions can include any combination of IP, Port and Protocol Filtering, DNS Protocol Filtering, Domain Name Filtering, URL Filtering, Malware Detection and Removal and more, as appropriate to the endpoints, protocols and content that is being sent and received (Application Flows are typically HTTPS/TLS based).
Figure 2 - Relationship of security functions and Application Flows
In Figure 2 above, security functions are shown as sitting between classification (identifying the Application Flow) and the application of the forwarding policy. It should be noted that this represents a functional
relationship, and that there can be different implementation choices as to where these functions physically sit.
For an Application Flow that is encrypted by the Subscriber, the Service Provider may be asked to decrypt the Subscriber's encrypted (HTTPS/TLS) traffic, apply the security functions to the unencrypted traffic and then to re-encrypt the traffic for transport across the SD-WAN network. This is described in more detail in Section 7.1.
Non-HTTPS/TLS traffic is not deemed to be within the scope of inspection, except with respect to the DNS hostnames, URLs, IP addresses, port numbers and malware scanning that are used to access it.
It is suggested that any TLS based interception being performed by a middle-box as part of a managed service should use a PKI hierarchy that is rooted in a Certificate Authority that is operated in line the CA/Browser Forum baseline requirements [36] where certificates are securely created, used, revoked and destroyed.
The security functions specified in this section fit within the AF-SECURITY-INGRESS and AF-SECURITY-EGRESS Policy Criteria of MEF 70.1 [2]. These security functions can be applied to an Application Flow (Ingress or Egress) or Application Flow Group (Ingress or Egress) at a given SWVC End Point, and consist of:
• Middle-box Function (MBF) - detailed specification in Section 7.1 • Security Event Notification (SEN) - detailed specification in Section 7.4 • IP, Port and Protocol Filtering - detailed specification in Section 7.5 • DNS Protocol Filtering - detailed specification in Section 7.6 • Domain Name Filtering - detailed specification in Section 7.7 • URL Filtering - detailed specification in Section 7.8 • Malware Detection and Removal - detailed specification in Section 7.9
In this document, the words Allow and Block are used when describing the possible action of a security function, and when used in this context, the terms are always capitalized. Allow is defined as an action taken by a security function, where an Application Flow or a subset of an Application Flow is permitted. Block is defined as an action taken by a security function, where an Application Flow, or a subset of an Application Flow, is denied. Note that these terms apply to each security function independently, i.e., for a given Application Flow, one security function might Allow, while another security function might Block. In this case, the overall effect is Block. See Appendix A for use case examples of how these security functions interact with different Application Flows.
7.1 Middle-Box Function (MBF)
Many security functions can only work when the Application Flows are unencrypted. Therefore, encrypted Application Flows must be decrypted for the security functions to inspect the packets, and then re-encrypted after the security function actions are taken. This section describes an approach for providing security functions for Application Flows carrying encrypted traffic, specifically, Transport Layer Security (TLS) sessions. This section does not cover the encryption of TVCs, since that is covered in MEF 70.1 [2].
In the context of this document, the term Middle-Box Function (MBF) refers to a function used to decrypt and re-encrypt TLS sessions in an Application Flow. This may be required by specific security functions that need to see unencrypted traffic in order to detect, remove, filter, etc., and so it is defined as a generic capability.
For a given Application Flow, MBF can be either Enabled or Disabled.
• When Disabled for a given Application Flow, the MBF does not apply decryption / re-encryption of TLS sessions.
• When Enabled for a given Application Flow, and where the client trusts the MBF’s proposed certificate chain, for each TLS session, the MBF decrypts TLS-encrypted packets, and enables other security functions to apply to the unencrypted packets, and then re-encrypts the packets that are Allowed by the other security functions.
Editor Note 2: The following text through [R8] has been added recently to the working draft. Please do a careful review of these requirements.
Requirements [R1] through [R6] relate to the capability of the MBF.
[R1] The Service Provider MUST provide to the Subscriber a list of all TLS versions supported by the MBF.
[R2] The MBF MUST meet the mandatory requirements of TLS 1.2, per RFC 5246 [16].
[R3] The MBF MUST meet the mandatory requirements of section 9.3 of RFC 8446 [27] (Protocol Invariants).
[R4] The MBF MUST be capable of disabling each TLS version, as listed in [R1].
For example, to support a stronger security posture, a Subscriber might want to disable TLS 1.1 and below.
[R5] The Service Provider MUST provide to the Subscriber a list of all of the cipher suites per TLS version that are supported by the MBF.
In general, a cipher suite includes the protocol name (e.g., TLS), the Key Exchange algorithm (e.g., DHE_DSS), WITH the encryption algorithm (AES_128_CBC) and the Message Authentication algorithm (SHA256). The following is an example of a cipher suite for TLS 1.2: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x00, 0x40).
[R6] The Service Provider MUST indicate to the Subscriber which of the cipher suites listed in [R5] can be disabled.
Editor Note 3: [R6] was initially proposed more strongly - mandating MBF support for disabling each of the cipher suites in the list. A counter proposal was to make it a recommendation - SHOULD support disabling each. Instead, we opted for transparency. Please look at the wording and provide your thoughts.
For example, to support a stronger security posture, a Subscriber might want to disable the use of weaker cipher suites.
[R7] When MBF is Enabled for a given Application Flow, the MBF MUST NOT change the TLS protocol version for a TLS session as compared to the client request.
[R8] When MBF is Enabled for a given Application Flow, the MBF MUST NOT choose a weaker cipher suite in the negotiation for a TLS session as compared to the TLS session without the MBF.
NIST 800-52 [32] is a useful reference that provides a comprehensive set of guidelines for the selection, configuration, and use of Transport Layer Security (TLS) Implementations for US federal systems.
The term "man in the middle" refers to an encrypted connection with possible oversight. Many attacks use this technique to have an un-authorized view of all the unencrypted traffic by exploiting a flaw in the encryption chain. The term MBF is used in this document to refer to a function agreed with the Subscriber and Service Provider and used by a security team to help provide advanced protection for the Subscriber for encrypted Application Flows. A Service Provider typically distributes these functions for better efficiency and usage. It is noted that there may be a divergence in behavior between the wishes and needs of the Subscriber and the end user, however these are necessarily outside of the scope of this document.
Figure 3 below depicts an MBF used between a Subscriber's client and a server - the server can be either a public Internet host or an internal private host in the Subscriber's network. For simplicity, the SD-WAN network is not shown here.
Figure 3 - Example of an MBF used between a Subscriber's client and a Server
Once a given Application Flow is decrypted by the MBF, then security functions can be applied. Figure 4 below depicts an example of an implementation that applies security functions to an Ingress Application Flow that is encrypted. A similar approach could be used for an Egress Application Flow.
Figure 4 - Example of using Middle-box and Security Functions for an Application Flow
Note: It is desirable that decryption and encryption should happen within the same MBF appliance to avoid further compromising the security of Subscriber’s traffic during the application of security functions.
[R9] An encrypted Application Flow MUST not be exposed outside the Service Provider's security functions in an unencrypted fashion or in an encrypted form that offers a lower level of confidentiality and integrity to the Subscriber.
[R10] Ancillary traffic relating to service operation of an encrypted Application Flow that is being sent to a third party for processing MUST be encrypted and trust validated, such that it does not provide a lower level of confidentiality and integrity to the Subscriber.
Ancillary traffic in [R10] is meant to include Security Event Notification (SEN) traffic, as specified in Section 7.4.
7.1.1 Certificate Authority and Validation
This subsection refers to the following standards related to public key certificates: ITU-T X.509 [4], IETF RFC 4210 [13], IETF RFC 5280 [17] and IETF RFC 6960 [20].
The Certificate Authority (CA) and certificate validation is agreed between the Subscriber and the Service Provider to account for both public and private certificate usage.
[R11] The MBF MUST be capable of issuing a valid, signed certificate for each TLS session with the client's trusted CA.
Note that the certificate can be self-signed, and has to be installed as a trusted root authority by the client.
While this document does not prescribe the exact hierarchy of trust that should be leveraged when replacing complex certificate chains in-line, the following requirements have been deemed necessary.
[R12] Server certificates MUST be generated and regenerated with fresh, suitably random material per the requirements in FIPS-140-2 [31] for each distinct endpoint that the MBF performs interception of.
[R13] All certificates MUST be created with properties that offer at least equivalent functional security to those they replace with respect to properties, such as, alternative server names, validity periods, choices of hash, etc.
[D1] Certificate Authorities SHOULD clearly announce themselves within the properties of the certificates they operate for reasons of transparency, so that the Subscriber can identify where MBF is in operation versus where they are connecting directly to the originating server.
[R14] All use of fraudulent textual certificate properties to spoof existing public Certificate Authorities is EXPRESSLY forbidden. Certificate trust by Subscribers MUST be rooted in their trust of the Certificate Authority rather than successful deception.
[D2] It is strongly recommended that any TLS based interception being performed by a middle-box as part of a managed service SHOULD use a PKI hierarchy that is rooted in a Certificate Authority that is operated in line the CA/Browser Forum baseline requirements [36] where certificates are securely created, used, revoked and destroyed.
[R15] The MBF MUST be capable of accepting a valid signed Subscriber certificate for each TLS session between the MBF and the Subscriber’s server.
[R16] When an MBF is Enabled for a given Application Flow, the MBF MUST verify the validity of the targeted server certificate of the TLS session, as illustrated in Figure 3.
[R17] When an invalid server certificate is detected, an MBF MUST be capable of Blocking the TLS session, and notifying the client in the Subscriber's network of the invalid certificate.
Recommendations for key management can be found in NIST 800-57 [34].
The method for notifying the client in the Subscriber's network is beyond the scope of this document.
Note that this document does not impose any requirements on validating the client certificate. Work on such requirements are for further study.
7.1.2 Transport Layer Security (TLS) Protocol version 1.3
IETF has recently approved RFC 8446 [27], The Transport Layer Security (TLS) Protocol Version 1.3 [27]. TLS 1.3 [27] allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. Appendix A provides a more detailed description of TLS 1.3 [27].
For Subscribers using TLS 1.3 [27], the expectation is that the SD-WAN service would not negatively affect its use.
7.1.3 Application Flow Consisting of Multiple Protocols
An MBF, when Enabled for an Application Flow, decrypts the encrypted payload, allowing for security functions to be applied to the unencrypted payload, and then re-encrypts the payload for transport in the Application Flow. In this document, for convenience, when we say that the Application Flow is decrypted using an MBF, it means that both decryption and re-encryption are performed on the Application Flow.
When the Application Flow is carrying multiple protocols, it is possible that a subset of the Application Flow cannot be decrypted by the MBF, e.g., a subset of the Application Flow may be unencrypted, or encrypted with an encryption protocol not supported by the MBF. Furthermore, in some cases, the MBF may not be able to re-encrypt an encryption protocol even if the MBF CA is trusted. This could be the case when the CA of the MBF is trusted by the Subscriber's client, and the MBF is able to successfully decrypt the encryption protocol from the Subscriber's client in the decryption phase of the MBF process, however, the target server CA may have pinned the client certificate to the Subscriber's client, prohibiting the use of a client certificate by the MBF for the re-encryption phase of the MBF process.
The following requirement addresses the case of multiple subsets of an Application Flow, at least one of which cannot be decrypted by the MBF.
[R18] The MBF MUST support both of the following possible actions:
Decrypt the subset of the Application Flow that can be decrypted and Block the subset that cannot be decrypted, and
Decrypt the subset of the Application Flow that can be decrypted and Allow the subset that cannot be decrypted.
[R19] When MBF is Enabled for a given Application Flow, the MBF MUST perform one of the following actions, based upon Subscriber policy:
Decrypt the subset of the Application Flow that can be decrypted and Block the subset that cannot be decrypted, or
Decrypt the subset of the Application Flow that can be decrypted and Allow the subset that cannot be decrypted.
The cases in which all or none of the Application Flow can be decrypted are covered by the concept of a subset that may be the entire Application Flow or none of the Application Flow. For example, the subset that can be decrypted may be null, in which case the entire Application Flow is either Blocked or Allowed.
Some protocols present challenges for an MBF to support. For example, the HTTP Strict Transport Security (HSTS) protocol, as specified in IETF RFC 6797 [17], is a mechanism implemented at the server to expressly prevent an MBF. Another example is QUIC, as specified in [29], which 'incorporates TLS 1.3 at the transport layer'.
If the Subscriber needs to use a protocol in the Application Flow that cannot be decrypted by the MBF, there are two possibilities:
• Disable MBF for that Application Flow, or
• Enable MBF, and agree on the second option listed in [R19].
7.2 Security Action List Types
In this document, the term "match criteria entry" is used to indicate an entry in a list. Depending on the security function to which it applies, a match criteria entry could be a specific port number, protocol ID, URL, domain name, or IP address or some other identifier within the context of an Application Flow. A given security function can have three types of lists in which different match criteria entries are placed, based on user preferences, the match criteria entry's reputation or other factors. Such lists are used for different filtering purposes defined in subsequent sections.
Below describes the three types of lists and their behaviors.
A Block List is a list of match criteria entries that result in an Application Flow or subset of an Application Flow to be Blocked. The Service Provider is responsible for enforcing the Block List. The list of match criteria entries in the Block List include:
• Match criteria entries that are deemed a security threat by the Service Provider and the Subscriber.
• Match criteria entries that conform to the Subscriber’s corporate policy or regulatory requirements.
Maintenance of Match criteria entries that are added to or removed from the Block List are based on agreement between the Subscriber and the Service Provider.
[R20] For a given Application Flow, the Application Flow or a subset of the Application Flow that contains a match criteria entry on a Block List MUST be Blocked.
An Allow List is a list of match criteria entries that result in an Application Flow or subset of an Application Flow to be Allowed. The Service Provider is responsible for enforcing the match criteria entries on the Allow List. The match criteria entries in the Allow List include:
• Match criteria entries that are explicitly identified by the Subscriber. Note that a given Subscriber might not identify any match criteria entry for the Allow List.
• Match criteria entries that are implicitly identified by the Service Provider. For example, all match criteria entries that are not on the Block List might be considered as match criteria entries for the Allow List.
Maintenance of match criteria entries added to or removed from the Allow List are based on agreement between the Subscriber and the Service Provider.
[R21] For a given Application Flow, the Application Flow or a subset of the Application Flow that contains a match criteria entry included on an Allow List MUST be Allowed.
A Quarantine List is a list of match criteria entries in an Application Flow that are not on the Block List and that are deemed suspicious. All match criteria entries on the Quarantine List are Blocked. A match criteria entry that has been implicitly added to the Allow List and that has been deemed suspicious could be moved to the Quarantine List. The Service Provider is responsible to maintain the match criteria entries on the Quarantine List. The Service Provider cannot move a match criteria entry currently on the Block List or explicitly added to the Allow List to the Quarantine List. The Quarantine List enables the Subscriber to take an action, e.g.,
• Move the match criteria entry from the Quarantine List to the Block List to permanently Block, or
• Explicitly move the match criteria entry to the Allow List to Allow, or • Ignore the match criteria entry and leave it in the Quarantine List where it will continue to
Block
[R22] A match criteria entry that has been implicitly added to the Allow List and that is deemed suspicious MUST be placed on the Quarantine List.
[R23] For a given Application Flow, the Application Flow or a subset of the Application Flow that contains a match criteria entry on the Quarantine List MUST be Blocked.
[R24] An Application Flow or subset of an Application Flow that does not contain a match criteria entry on the Block List, Allow List or Quarantine List MUST be Allowed.
To avoid conflict, a match criteria entry cannot be on different lists.
[R25] Each match criteria entry MUST be on at most one list.
[R25] means that a match criteria entry on one of these lists cannot also be on another list, e.g., a match criteria entry on a Block List cannot also appear on the Allow List.
In some cases, a match criteria entry on one list could be generalized, e.g., *.xyz.com might be a match criteria entry on an Allow List than means to Allow all access to xyz.com. There could also be a more specific match criteria entry on the Block List, e.g., badpage.xyz.com. In such a scenario, the more specific match criteria entry would normally overrule the more general match criteria entry, i.e., all access to xyz.com would be Allowed except for badpage.xyz.com, which would be Blocked. It is the responsibility of the Service Provider to implement these lists in such a way as to match the intent of the Subscriber.
The Service Provider typically maintains a threat database for each security function, and uses it to populate and dynamically modify (add or subtract) match criteria entries on each of the lists. It is expected that the
Subscriber can modify the lists to reflect its own threat intelligence. Specifications on the threat database, the method for maintaining each of the lists, and the method for providing this interaction for the Subscriber's use (e.g., APIs) are beyond the scope of this document.
7.3 Security Action List Usage Policy
A security action list usage policy can be explicit or implicit.
When the policy is explicit, the Subscriber can add specific match criteria entries into either their Block List or their Allow List, as well as use pre-defined Block Listed match criteria entries from their Service Provider. When the policy is implicit, the Subscriber and Service Provider agree on a set of match criteria entries for only one list, either the Block List or the Allow List. Any match criteria entry not on the agreed list is deemed to be on the other list.
The implicit policy can be understood by the following examples.
Example 1: A bank wants to define their domain name filtering policy based on what they want to Allow. They specify domain names, which Application Flows they want to be Allowed (not blocked), in an Allow List. The bank wants any other domain names not listed in the Allow List to be Blocked. In this example, the bank need not capture every domain name they want Blocked in a Block List. Any Application Flows, for domain names not on the Allow List, are implicitly on the Block List and thus Blocked.
Example 2: A retailer wants to define their domain name filtering policy based on what they want to Block. The retailer also wants to specify these domain names for a particular category, e.g., Adult, Games, and Gambling, rather than list them individually. They specify the categories, whose Application Flows they want to be Blocked, in a Block List. The retailer wants Application Flows for any other categories not listed in the Block List to be Allowed. In this example, the retailer need not capture every domain name or category they want to be Allowed in an Allow List. Any domain names not on the Block List are implicitly on the Allow List and thus Allowed. The domain names within a category are provided by the Service Provider and the Subscriber can review them to determine if they are sufficiently comprehensive. If not, they can add additional domain names to the Block List.
Security Action Policy
Description Values
Security Action List Usage Policy
Determines the behavior of how Allow Lists and Block Lists are populated and the resultant actions. When set to Implicit, the Subscriber need only enter match criteria entries in either an Allow List or a Block List. Anything not in the list that is populated is deemed to be in the other list. When set to Explicit, the Subscriber adds specific match criteria entries to their Block List and Allow List, as well as using pre-defined Block Listed match criteria entries from their Service Provider.
If Security Action List Usage Policy = Implicit, then the Subscriber need only enter match criteria entries in either the Allow List or the Block List and the other list implicitly includes all match criteria entries not in the populated list. This method is convenient when the Subscriber knows exactly what they want to Block (Block List) or Allow (Allow List). When only entering match criteria entries in an Allow List, the Subscriber enters at least one match criteria entry (otherwise, everything would be Blocked). When specifying only Block List match criteria entries, like in Example 2 above, any suspected match criteria entries, identified by security scanners, would get placed in the Quarantine List so the Subscriber can determine if they want to add them to the Block List or not. When specifying only Allow List match criteria entries, like in Example 1 above, any of the Allow List match criteria entries that becomes suspected would be placed in the Quarantine List, e.g., a legitimate domain name has a URL that has been hijacked and thus would be Quarantined.
[D3] When one of the following security functions is Enabled (IP, Port and Protocol Filtering, DNS Protocol Filtering, Domain Name Filtering or URL Filtering) for an Application Flow, the Service Provider SHOULD support an Implicit Security Action List Usage Policy.
If Security Action List Usage Policy = Explicit, then the Subscriber can enter match criteria entries in either the Allow List and/or the Block List. This method enables the Subscriber to explicitly list Allow List and Block List match criteria entries plus use the standard library of Block Listed match criteria entries provided by their Service Provider. This method would also allow Security scanners to identify suspected match criteria entries which would be placed in the Quarantine List where the Subscriber can determine if they are legitimate or not and take action to place them in either the Allow List or Block List.
[R26] When one of the following security functions is Enabled (IP, Port and Protocol Filtering, DNS Protocol Filtering, Domain Name Filtering or URL Filtering) for an Application Flow, the Service Provider MUST support an Explicit Security Action List Usage Policy.
[R27] When one of the following security functions is Enabled (IP, Port and Protocol Filtering, DNS Protocol Filtering, Domain Name Filtering or URL Filtering) for an Application Flow, the Service Provider MUST provide a Security Action List Usage Policy to the Subscriber.
[R28] When one of the following security functions is Enabled (IP, Port and Protocol Filtering, DNS Protocol Filtering, Domain Name Filtering or URL Filtering) for an Application Flow, the Service Provider MUST indicate to the Subscriber whether the Security Action List Usage Policy is Implicit or Explicit.
7.4 Security Event Notification (SEN)
A Security Event Notification (SEN) is defined as a method to communicate a security event, e.g., a match criteria entry (IP address, domain name, URL or other ID) that is Blocked or quarantined, to the SD-WAN Subscriber and Service Provider personnel, e.g., SOC personnel.
The SEN includes an Indicator of Compromise (IOC). Typical IOCs are virus signatures, IP addresses, hashes of malware files, or URLs or domain names of botnet command and control servers.
Per NIST 800-53 [31], "Indicators of compromise (IOC) are forensic artifacts from intrusions that are identified on organizational information systems (at the host or network level). IOCs provide organizations with valuable information on objects or information systems that have been compromised. IOCs for the discovery of compromised hosts can include, for example, the creation of registry key values. IOCs for network traffic include, for example, Universal Resource Locator (URL) or protocol elements that indicate malware command and control servers. The rapid distribution and adoption of IOCs can improve information security by reducing the time that information systems and organizations are vulnerable to the same exploit or attack."
[R29] A SEN MUST be issued whenever an Application Flow or subset of the Application Flow or Object associated with the Application Flow, is Blocked, quarantined or modified.
An example of a modified Application Flow is the removal of an infected file attachment in an e-mail, and typically the removed file attachment would be replaced with a message stating that the file was infected and removed.
[R30] A SEN MUST include the items listed in Table 3:
Issuer String Base 64 [14] Examples: Security Service Provider Name, SD-WAN Service Provider Name, Security Vendor Name, etc.
Timestamp of IOC date-time RFC 3339 [9] Example: UTC
SEN ID UUID RFC 4122 [12] Universal Unique ID
Zone ID String Base 64 [14] MEF 70.1 [2]
Source IP address received from Internet breakout UCS
IPv4 or IPv6 format
only populate if threat is from Internet Breakout UCS.
SD-WAN UNI ID String Base 64 [14] MEF 70.1 [2]
IOC Type String of the IOC Base 64 [14] Examples: CVE1, STIX2, CWE3, CAPEC4, ATT&CK5, RFC 7970 [25].
IOC Information ID String Base 64 [14] Identifies the IOC based on type
IOC Source URL for the IOC type
Example: If CVE, then cve.mitre.org
Type of Compromise String Base 64 [14] Examples: known vulnerability, breach, data leakage, abuse of resources, jacking, where to find more information on the breach.
Compromise details String Base 64 [14] Examples: Username, Source/Destination IP address, Source MAC address, neutralized* URL, neutralized* domain, malware, Source/Destination port number, anomalous behavior.
Action Taken String Base 64 [14] Examples: informational, quarantined or blocked, malware removed
Table 3 - Items to be included in a SEN
1 Common Vulnerabilities and Exposures - MITRE - cve.mitre.org
2 Structured Threat Information Expression - https://oasis-open.github.io/cti-documentation/
3 Common Weakness Enumeration - NIST NVD - https://nvd.nist.gov/vuln/categories
*Note that this document mandates the use of square brackets, which are reserved characters in RFC 3986 [11], to neutralize a domain or URL in a SEN. For example, if the compromised detail includes www.domain.tld, the SEN would send it as www[.]domain[.]tld.
[D4] Any domain name or URL in an IOC SHOULD be neutralized by using square brackets around each period.
Other items could also be included in the SEN, if agreed, e.g., Host name, User Name, owner of public IP address, place, contact, etc.
[R31] The Service Provider MUST support UTC for the timestamp format.
[R31] means that the Service Provider needs to be able to use UTC format for the timestamp if the Subscriber wants that, although for a particular service or a particular Subscriber, a different time format could be agreed.
A SEN is used to notify Subscribers of a security event.
[R32] A SEN MUST have a recipient list, which is agreed between the Service Provider and the Subscriber.
For example, the recipient list could include a Security Operations Center (SOC), a Network Operations Center (NOC) and/or an individual.
7.5 IP, Port and Protocol Filtering
IP, Port and Protocol Filtering is defined as action taken by the Service Provider to check whether an Application Flow includes a list of source or destination IP addresses, source or destination port numbers and/or associated protocols that are to be allowed or blocked. Certain IP addresses, port numbers and associated protocols are commonly used by the Subscriber for use in their internal network, and these are generally not allowed on an Application Flow that uses Internet Breakout. A Subscriber's security policy might also disallow specific IP addresses, port numbers and associated protocols that are not used by the Subscriber, to mitigate possible attack channels used by hackers.
A Block List consists of a list of match criteria entries each of which needs to be blocked. An Allow List consists of a list of match criteria entries each of which needs to be allowed. A Quarantine List is used by the Service Provider to block suspicious match criteria entries that have not been identified on either the Block List or the Allow List.
IP, Port and Protocol Filtering has the value of Enabled or Disabled.
When Disabled, there is no filtering based on IP address, port number or protocol.
4 Common Attack Pattern Enumeration and Classification) - MITRE - https://capec.mitre.org
When IP, Port and Protocol Filtering is Enabled for a given Application Flow, the Ingress Application Flow and/or the Egress Application Flow is checked against a list of specific source or destination IP addresses, protocols and/or port numbers and associated transport protocols and a determination is made to either Allow or Block. There could be more than one protocol that uses a given port number.
An IP, Port and Protocol Filtering Block List and an IP, Port and Protocol Filtering Allow List are maintained by the Service Provider, with each match criteria entry on a list using an 8-tuple of the form <DAV4, SAV4, DAV6, SAV6, transport protocol, DPORT, SPORT, list of protocols>.
• DAV4, the list of destination IPv4 addresses, and consists of one or a range of IPv4 addresses. All could be used to indicate that all destination IPv4 addresses are on the list.
• SAV4, the list of source IPv4 addresses, and consists of one or a range of IPv4 addresses. All could be used to indicate that all source IPv4 addresses are on the list.
• DAV6, the list of destination IPv6 addresses, and consists of one or a range of IPv6 addresses. All could be used to indicate that all destination IPv6 addresses are on the list.
• SAV6, the list of source IPv6 addresses, and consists of one or a range of IPv6 addresses. All could be used to indicate that all source IPv6 addresses are on the list.
• transport protocol, one of the following four entries: TCP, UDP, TCP/UDP, Other. Other allows for other transport protocols to be included, e.g., RTP.
• DPORT, the list of destination port numbers. All could be used to indicate that all destination port numbers are on the list.
• SPORT, the list of source port numbers. All could be used to indicate that all source port numbers are on the list.
• list of protocols, a list of one or more application protocols. All could be used to indicate that all application protocols are on the list.
Editor Note 4: The team discussed adding state to the IP, Port & Protocol filtering security function, but could not provide normative requirements. An example discussed was ICMP Ping. When destined to the Internet, an ICMP echo request from an SD-WAN Subscriber's client might be allowed on an ingress Application Flow, and the following ICMP echo response would need to be allowed on the egress Application Flow. But, an ICMP echo request from the Internet towards the Subscriber's client might need to be blocked on the egress Application Flow (the Subscriber doesn't want anyone out there pinging the Subscriber's network. This implies that state needs to be kept on these types of protocols. Another example could involve SNMP. Please comment as to how to describe this in terms of requirements or behavior of this security function.
The following are some examples of an entry on the Block List:
• A match criteria entry in the Block List of <All, All, All, All, TCP, 53, All, Protocol X> means that the subset of the Application Flow that uses Protocol X over TCP using destination port 53 would be blocked, regardless of IP address and source port number.
• A match criteria entry in the Block List of < All, All, All, All, TCP/UDP, All, All, Protocol X> means that the subset of the Application Flow that uses Protocol X would be blocked regardless of IP address and port number.
• A match criteria entry in the Block List of <Range 1, All, Range2, All, UDP, All, All, Protocol X> means that the subset of the Application Flow that uses Protocol X, would be blocked for all port numbers using UDP transport with an IPv4 destination address in Range1 and IPv6 destination address in Range2.
As an example use case, the Subscriber might provide the following list to be Blocked on all Application Flows that use Internet Breakout (these should only be allowed for internal use of the Subscriber):
Any match criteria entry that is not included on the Block List is assumed to be on the Allow List. If a Block List is not used, an Allow List could be agreed between the Subscriber and Service Provider to allow specific match criteria entries, and any match criteria entry that is not included on the Allow List is assumed to be on the Block List. If the Service Provider detects any suspicious activity associated with IP addresses, port number(s) and/or protocol(s) that would ordinarily be allowed, that IP address, port number(s) and/or protocol(s) are added to the Quarantine List for further investigation by the Subscriber. All three lists (Block List, Allow List and Quarantine List) are maintained by the Service Provider.
[R33] When IP, Port and Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of match criteria entries in the Block List.
Once the service is turned up, the match criteria entries on the Block List can be modified at the request of the Subscriber. This is normally a dynamic process. This could be via a web portal or API to a Subscriber application. Such implementation methods are beyond the scope of this document.
[R34] When IP, Port and Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the match criteria entries in the Block List.
The Allow List consists of a list of match criteria entries that are to be ALLOWED. A Subscriber could also move a specific match criteria entry that was on the Block List or in the Quarantine List to the Allow List. Note that there could be a single match criteria entry in the Allow List, i.e., 'all match criteria entries not on the Block List or Quarantine List'.
[R35] When IP, Port and Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of match criteria entries in the Allow List.
[R36] When IP, Port and Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of match criteria entries in the Allow List.
Initially, when the service is activated, the Quarantine List could be empty. If the Service Provider determines a port and associated protocol to be suspect, it could be placed on the Quarantine List.
[R37] When IP, Port and Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of match criteria entries in the Quarantine List.
[R38] When IP, Port and Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to move a match criteria entry from the Quarantine List to either the Block List or the Allow List.
[R39] When IP, Port and Protocol Filtering is Enabled for a given Application Flow, one of the following three actions MUST be performed:
Allow the Application Flow or subset of the Application Flow that contains a match criteria entry that is explicitly on the Allow List or not on any other list.
Block the Application Flow or subset of the Application Flow that contains a match criteria entry that is on the Block List.
Block the Application Flow or subset of the Application Flow that contains a match criteria entry that is not on either the Allow List or the Block List, or is implicitly on the Allow List, but is considered suspect, and place the match criteria entry on the Quarantine List.
7.6 DNS Protocol Filtering
DNS Protocol Filtering is defined as action taken by the Service Provider to check whether Domain Name System (DNS) [19] messages, as specified in RFC 1035 [5] and RFC 1996 [6], on ingress and egress at an SD-WAN UNI, are to be Allowed or Blocked based on the IP address of the DNS Server associated with the DNS message.
An example of DNS Protocol Filtering is shown in Figure 5 below.
In Figure 5, DNS Server Z is on the Allow List and DNS Server X is on the Block List. When a DNS message is sent to DNS Server X, it is blocked. A notification may be sent to the client when it is blocked, depending on prior agreement of the Service Provider and SD-WAN Subscriber.
DNS Protocol Filtering is a security function that applies to the DNS protocol operating over 53/TCP and 53/UDP for a given Application Flow or Application Flow Group, and has the value of Enabled or Disabled.
• When DNS Protocol Filtering is Disabled for a given Application Flow, there is no inspection of DNS messages on that Application Flow.
• When DNS Protocol Filtering is Enabled for a given Application Flow, DNS Protocol Filtering inspects DNS messages on ingress and egress at an SD-WAN UNI, and checks the IP address against entries in the DNS Protocol Filtering Allow List and DNS Protocol Filtering Block List, and decides whether to Allow or Block the DNS message.
A DNS Protocol Filtering Block List is a list of match criteria entries that are associated with a DNS Server that is to be blocked. A DNS Protocol Filtering Allow List is a list of match criteria entries that are associated with a DNS Server that is to be allowed. The lists are maintained by the Service Provider, with each match criteria entry on a list using a 4-tuple of the form <DAV4, SAV4, DAV6, SAV6>.
• DAV4, the list of destination IPv4 addresses, and consists of one or a range of IPv4 addresses. All could be used to indicate that all destination IPv4 addresses are on the list.
• SAV4, the list of source IPv4 addresses, and consists of one or a range of IPv4 addresses. All could be used to indicate that all source IPv4 addresses are on the list.
• DAV6, the list of destination IPv6 addresses, and consists of one or a range of IPv6 addresses. All could be used to indicate that all destination IPv6 addresses are on the list.
• SAV6, the list of source IPv6 addresses, and consists of one or a range of IPv6 addresses. All could be used to indicate that all source IPv6 addresses are on the list.
Editor Note 5: There was some discussion about adding a tuple to cover the type and/or content of the DNS messages to allow for a stronger function that includes inspection of the DNS messages. A contribution or detailed comments would welcome.
One of the lists is explicitly agreed between the Subscriber and the Service Provider, and the other is implicitly derived by the Service Provider.
The Service Provider has a list of match criteria entries that represent DNS servers that could have security threats (e.g., those known to cause security threats or have illicit content) for the Block List. This Block List is maintained and dynamically modified over time as additional match criteria entries to be blocked are identified. The Subscriber may also provide a list of match criteria entries to the Service Provider to populate the Block List.
[R40] When DNS Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of match criteria entries in a DNS Protocol Filtering Block List.
Once the service is turned up, the list of DNS servers on the Block List can be modified at the request of the Subscriber. This is normally a dynamic process. This could be via a web portal or API to a Subscriber application. Such implementation methods are beyond the scope of this document.
[R41] When DNS Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of match criteria entries in the DNS Protocol Filtering Block List.
Typically, the Allow List consists of match criteria entries that represent DNS servers that are to be Allowed. A Subscriber could also move a match criteria entry that was on the Block List or in the Quarantine List to the Allow List so that the specific match criteria entry is Allowed. Note that there could be a single match criteria entry in the Allow List, i.e., 'all match criteria entries not on the Block List or Quarantine List'.
[R42] When DNS Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of match criteria entries in a DNS Protocol Filtering Allow List.
[R43] When DNS Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of match criteria entries in the DNS Protocol Filtering Allow List.
[D5] When DNS Protocol Filtering is Enabled for a given Application Flow, the match criteria entries for the DNS Protocol Filtering Allow List SHOULD be explicitly specified.
Typically, the Allow List is explicitly specified and the Block List is implicitly derived (anything not on the Allow List). The Service Provider and Subscriber can agree to other mechanisms.
Initially, when the service is activated, the Quarantine List could be empty. If the Service Provider determines an IP address to be suspect, it could be placed on the Quarantine List.
[R44] When DNS Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of match criteria entries in the DNS Protocol Filtering Quarantine List.
[R45] When DNS Protocol Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of match criteria entries on the DNS Protocol Filtering Quarantine List.
[R45] means that the match criteria entry will stay on the Quarantine List unless the Subscriber either deletes the match criteria entry from the Quarantine List or moves the match criteria entry to either the Allow List or the Block List.
[R46] When DNS Protocol Filtering is Enabled for a given Application Flow, one of the following two actions MUST be performed:
• Allow the DNS message if the match criteria entry of the DNS Server is on the DNS Protocol Filtering Allow List.
• Block the DNS message if the match criteria entry of the DNS Server is not on the DNS Protocol Filtering Allow List.
[R47] The DNS Protocol Filtering security function MUST be capable of informing the client in the Subscriber's network immediately of any DNS Message failure.
[D6] When a DNS message is Blocked, the client in the Subscriber's network SHOULD be immediately informed of the DNS message failure.
This document does not specify the method for informing the client. One example could be that a DNS query is re-directed by the Service Provider to a web page that gives the reason(s) why the DNS query is Blocked. The method used is based on agreement of the Service Provider and Subscriber.
There are two scenarios that can be used by the Service Provider to support DNS Protocol Filtering.
Scenario A: The Service Provider hosts a DNS Server and the Subscriber uses that DNS Server for queries. This Server is included in the Allow List. In this case, when DNS Protocol Filtering is Enabled, encrypted (e.g., DNS over HTTPS and/or DNS over TLS) and unencrypted DNS queries are checked and either Allowed or Blocked, per the previous description.
Scenario B: The Service Provider does not host a DNS Server: In this case, when DNS Protocol Filtering is Enabled, only unencrypted DNS messages can be checked. Encrypted DNS messages are handled as any other packets in the Application Flow.
There are special cases involving DNS that are not in scope for this document. Specifically,
• DNS over HTTPS (DoH), as specified in RFC 8484 [28]. DoH shares port 443 with all other HTTPS traffic. If a Subscriber wants to use DoH, it is better to have MBF Disabled for the Application Flow.
• DNS over TLS (DoT), as specified in RFC 7858 [24]. DoT uses dedicated port 853. It is possible to use the IP, Port and Protocol Filtering security function to either Allow/Block the Application Flow, or subset of the Application Flow, carrying DoT.
• DNSSEC, based on a suite of IETF RFCs, provides security extensions for DNS. • TOR, as specified in RFC 7686 [23], is a special case that does not use the DNS
infrastructure for resolving domains associated with the .onion TLD.
7.7 Domain Name Filtering
Domain Name Filtering is defined as action taken by the Service Provider to check whether access to a domain name is to be Allowed or Blocked based on Domain Name Filtering Allow List / Block List. Domain Name Filtering provides a level of protection from attempting to visit a malicious host.
There are four basic methods for identifying and blocking a domain name that is on the Block List:
• Inspect the DNS message, which is normally unencrypted, and block the resolution.
• If the DNS message is encrypted or not used by the client, and if the Application Flow is unencrypted, inspect the Application Flow and block the session.
• If the DNS message is encrypted or not used by the client, if the Application Flow is encrypted with TLS 1.2, then inspect the SNI extension (unencrypted for TLS 1.2) of the handshake message for the host (domain) name, and block the TLS session.
• If the DNS message is encrypted or not used by the client, and if SNI cannot be used, then enable MBF for the Application Flow, and inspect the unencrypted packets for the domain name, and block the TLS session.
There are three types of domain names under consideration:
• a Fully Qualified Domain Name (FQDN), is the full name of a system and uses the following format: Hostname.DomainName.TopLevelDomain. An example of this would be www.mef.net where the Hostname is 'www', the domain name is 'mef' and the TopLevelDomain is '.net'.
• a Partially Qualified Domain Name (PQDN), is not an FQDN, e.g., the top level domain might be missing, and a local resolver can generally supply the missing part.
• An Unqualified Domain Name is a domain name that does not exist - it could have a full structure like the FQDN, but it can't be resolved to an IP address.
An example of the three types of domain names is shown in Figure 6 below.
Figure 6 - Example of the three types of domain names
As can be seen in Figure 6 above, users A, B and C send a mix of DNS messages to DNS Server Z (Allow List). All DNS messages are forwarded to the DNS Server, but only the FQDN message requests are resolved and sent back to the requester.
Domain Name Filtering is a security function that applies for a given Application Flow or Application Flow Group, and has the value of Enabled or Disabled.
• When Disabled for a given Application Flow, access to all domain names in that Application Flow are Allowed, except for the subset of the Application Flow that may be filtered by another security function.
• When Enabled for a given Application Flow, Domain Name Filtering inspects the Application Flow (both Ingress and Egress) for domain names and decides whether to Allow or Block access to one or more of those domain names.
The Service Provider has a list of disreputable or undesirable domain names (e.g., those known to cause security threats or have illicit content) for the Domain Name Filtering Block List. This Domain Name Filtering Block List is maintained and dynamically modified over time as additional domains to be blocked are identified. The Subscriber may also provide a list of domain name categories and/or specific domain names to the Service Provider to populate the Domain Name Filtering Block List.
An example Domain Name Filtering using DNS Messages is shown in Figure 7 below.
Figure 7 - Example of Domain Name Filtering using DNS Messages
As shown in Figure 7 above, users A and B send unencrypted FQDN request messages to DNS Server Z, which is on the Allow List. Domain Name Filtering is enabled, and *.badguy.hac is on the Block List, and so it is blocked. Only the appropriate DNS messages and domain names get forwarded to the DNS Server.
[R48] When Domain Name Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of domain names in a Domain Name Filtering Block List.
Once the service is turned up, the list of domain names on the Block List can be modified at the request of the Subscriber. This is normally a dynamic process. This could be via a web portal or API to a Subscriber application. Such implementation methods are beyond the scope of this document.
[R49] When Domain Name Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of domain names in the Domain Name Filtering Block List.
Typically, the Allow List consists of domain names that are to be Allowed. A Subscriber could also move a domain name that was on the Block List or in the Quarantine List to the Allow List so that the specific domain name is ALLOWED. Note that there could be a single entry in the Allow List, i.e., 'all match criteria entries not on the Block List or Quarantine List'.
[R50] When Domain Name Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of domain names in a Domain Name Filtering Allow List.
[R51] When Domain Name Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of domain names in the Domain Name Filtering Allow List.
Initially, when the service is activated, the Quarantine List could be empty. If the Service Provider determines a domain name to be suspect, it could be placed on the Quarantine List.
[R52] When Domain Name Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of domain names in the Domain Name Filtering Quarantine List.
[R53] When Domain Name Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of domain names on the Domain Name Filtering Quarantine List.
[R53] means that the domain name will stay on the Quarantine List unless the Subscriber either deletes the domain name from the Quarantine List or moves the domain name to either the Allow List or the Block List.
[R54] When Domain Name Filtering is Enabled for a given Application Flow, the SD-WAN Service MUST be able to filter FQDNs.
Editor Note 6: We may want to either: a) delete [R55] (it's ambiguous); or b) mandate blocking it (possible security issue to allow it?). The example in Figure 6 shows that a PQDN would not be resolved. Comments on what to do with[R55].
[R55] When Domain Name Filtering is Enabled for a given Application Flow, the SD-WAN Service MUST be able to filter PQDNs using the DomainName.TopLevelDomain format.
[R56] Domain Name Filtering MUST use the Security List requirements described in Section 7.2.
[R57] When Domain Name Filtering is Enabled for a given Application Flow, one of the following three actions MUST be performed:
• Allow access to the domain if the domain name is explicitly on the Domain Name Filtering Allow List or not on any other list.
• Block access to the domain if the domain name is on the Domain Name Filtering Block List.
• Block access to the domain if the domain name is determined to be on the Domain Name Filtering Quarantine List or considered suspect and placed on the Domain Name Filtering Quarantine List.
[R58] The Domain Name Filtering security function MUST be capable of informing the client in the Subscriber's network immediately when access to a domain is Blocked.
[D7] When access to a domain is Blocked, the client in the Subscriber's network SHOULD be immediately informed.
This document does not specify the method for informing the client. The method used is based on agreement of the Service Provider and Subscriber.
7.8 URL Filtering
URL Filtering is defined as action taken by the Service Provider to check whether access to a URL, as specified in IETF RFC 3986 [11], is to be Allowed or Blocked based on the URL Filtering Allow List / Block List. URL Filtering applies to cases where the domain name is on the Domain Name Filtering Allow List, but one or more URLs associated with that domain have a security issue, and need to be blocked.
There are two basic methods for identifying and blocking a URL that is on the URL Filtering Block List:
• If the Application Flow is unencrypted, inspect the Application Flow and block the session.
• If the Application Flow is encrypted, enable MBF for the Application Flow, and inspect the unencrypted packets for the URL, and block the TLS session.
URL Filtering is a security function that applies for a given Application Flow or Application Flow Group, and has the allowed value of Enabled or Disabled.
• When Disabled, access to all URLs is Allowed, unless blocked by another security function.
• When Enabled, URL Filtering inspects the Application Flow (both Ingress and Egress) for access to URLs and decides whether to Allow or Block access to one or more of those URLs.
If an Application Flow uses a URL that is on the URL Filtering Allow List, access to that URL is Allowed. If an Application Flow uses a URL that is on the URL Filtering Block List, access to that URL
is Blocked. When Blocked, the client can be notified that access to that URL has been Blocked and with the reasons why.
If an Application Flow uses a URL or domain name that is on neither the Allow List nor the Block List, then it is considered to be on the Quarantine List. Access to a URL on the Quarantine List is Blocked (quarantined) until further security checks can be done. The client can be notified of the Block with the reasons why. At some point, the Service Provider and the Subscriber can agree whether a URL on the Quarantine List is to be moved to the Allow List or the Block List. The details of how this is done is beyond the scope of this document.
An example of URL Filtering applied to a TLS session is shown in Figure 8 below.
Figure 8 - Example of URL Filtering applied to TLS session
In the example shown in Figure 8, Server Q hosts several domains. URL Filtering is enabled for the Application Flow and since the Application Flow is encrypted, an MBF is also enabled. User A tries to connect to Server Q for a URL that is on the URL Filtering Block List, and that connection attempt is blocked. User B connects to Server Q for a URL that is on the URL Filtering Allow List, and that connection on is allowed. Only appropriate URLs get connected.
Similar to Domain Name Filtering, the Service Provider may have a list of disreputable or undesirable URLs associated with good domains (e.g., those URLs known to cause security threats or have illicit content) for the Block List. This Block List is maintained and dynamically modified over time as additional URLs to be blocked are identified. The Subscriber may also provide a list of URLs to the Service Provider to populate the Block List.
[R59] When URL Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of URLs in a URL Filtering Block List.
Once the service is turned up, the list of URLs on the Block List can be modified at the request of the Subscriber. This is normally a dynamic process. This could be via a web portal or API to a Subscriber application. Such implementation methods are beyond the scope of this document.
[R60] When URL Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of URLs in the URL Filtering Block List.
Typically, the Allow List consists of URLs that are to be ALLOWED. A Subscriber could also move a URL that was on the Block List or in the Quarantine List to the Allow List so that the specific URL is ALLOWED. Note that there could be a single entry in the Allow List, i.e., 'all match criteria entries not on the Block List or Quarantine List'.
[R61] When URL Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of URLs in the URL Filtering Allow List.
[R62] When URL Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of URLs in the URL Filtering Allow List.
Initially, when the service is activated, the Quarantine List could be empty. If the Service Provider determines a URL to be suspect, it could be placed on the Quarantine List.
[R63] When URL Filtering is Enabled for a given Application Flow, the Service Provider MUST maintain a list of URLs in the URL Filtering Quarantine List.
[R64] When URL Filtering is Enabled for a given Application Flow, the Service Provider MUST allow the Subscriber to modify the list of URLs on the URL Filtering Quarantine List.
[R64] means that the URL will stay on the Quarantine List unless the Subscriber either deletes the URL from the Quarantine List or moves the URL to either the Allow List or the Block List.
[R65] When URL Filtering is Enabled for a given Application Flow, one of the following three actions MUST be performed:
• Allow access if the URL is explicitly on the URL Filtering Allow List or not on any other list.
• Block access if the URL is on the URL Filtering Block List. • Block access if the URL is on the URL Filtering Quarantine List or considered
suspect and placed on the Quarantine List. [R66] The URL Filtering security function MUST be capable of informing the client in the
Subscriber's network immediately when access to a URL is Blocked.
[D8] When access to a URL is Blocked, the client in the Subscriber's network SHOULD be immediately informed.
This document does not specify the method for informing the client. The method used is based on agreement of the Service Provider and Subscriber.
Malware is defined as malicious software, and refers to any malicious program or code that is harmful to systems or users of the systems.
Malware Detection and Removal is a security function that applies to all Application Flows or Application Flow Groups associated with a given zone, and has the allowed values of Enabled or Disabled A typical use case is where a Subscriber wants all web e-mails and downloads to be checked, and, when malware is detected, it would be removed.
• When Malware Detection and Removal is Disabled for a given zone, malware detection is not done on any of the Application Flows.
• When Malware Detection and Removal is Enabled for a given zone, all Application Flows associated with the zone (both Ingress and Egress) are scanned to detect malware, and if detected, appropriate action taken. This means that the Malware Detection and Removal security function is always bi-directional in nature).
If a given Application Flow is encrypted, Malware Detection and Removal can only be Enabled if an MBF is also Enabled.
In the following text, the term Object is used to denote a part of an Application Flow that is scanned when Malware Detection and Removal is Enabled. Examples of an Object are: a file attached to an e-mail or downloaded from a web server; a link on a web page with embedded malware; etc. An alternative term is artifact.
Malware Detection:
All objects are scanned, using known signatures, to detect malware hidden in the objects (e.g., antivirus scan on an e-mail). Objects without detected malware are forwarded. Objects with detected malware have an action applied. Decision is made to Block the object (Subscriber wants all such objects Blocked) or to quarantine the object (Subscriber wants ability to inspect the quarantined objects and decide whether to Allow them. In this case, the Subscriber takes the risk).
For a limited set of objects determined by the Service Provider as potentially suspicious, behavioral analysis may be done. This consists of a simulated but monitored environment where the objects are statically scanned, "used" (open, execute for binaries) and monitored for suspicious activities. Behavioral analysis can detect many of the yet unknown attacks, but it can be very compute intensive and is usually done on objects for which no known signature exists. If a dangerous file is detected, a signature is created.
[R67] The Malware Detection and Removal security function MUST be Enabled on a per zone basis.
This implies that the Service Provider and the Subscriber need to agree on which zones require the Malware Detection and Removal security function to be enabled.
[R68] When a given zone has the Malware Detection and Removal security function Enabled, all Application Flows associated with that zone MUST have the Malware Detection and Removal security function Enabled.
In the event that a given Application Flow, or subset of the Application Flow, cannot be decrypted, then Malware Detection and Removal cannot be done for that Application Flow, or subset of the Application Flow. The Service Provider and the Subscriber need to agree on the action to be taken when these kinds of events occur. Such action could involve blocking or allowing the subset of the Application Flow that cannot be decrypted.
[R69] When Malware Detection and Removal is Enabled for a given Application Flow, the Service Provider MUST describe which kind of detection (e.g., signature scan, behavioral analysis or both) is performed.
File base detection retains the data during analysis and is released once analysis is performed. This has consequences on the performance metrics for the service, e.g., latency. For this reason, when an Application Flow has Malware Detection and Removal Enabled, any performance objectives for the Application Flow cannot apply.
[R70] When Malware Detection and Removal is Enabled for a given Application Flow, and when an object in the Application Flow is determined to either have malware or look suspicious that it may have malware, the SD-WAN Service MUST apply one of the following actions:
• Block Object and Block the associated Application Flow or subset of the Application Flow, or
• Block Object and Allow the associated Application Flow or subset of the Application Flow, or
• Quarantine Object and Block the associated Application Flow or subset of the Application Flow, or
• Quarantine Object and Allow the associated Application Flow or subset of the Application Flow, or
• Remove malware from the Object and Allow the associated Application Flow or subset of the Application Flow.
Note that if removing malware from the Object is attempted and fails, then one of the other actions applies.
[R71] The Service Provider MUST report which action is taken for detected malware, and make it available to the Subscriber via a SEN (see Section 7.4).
Appendix C describes four examples of Malware Detection and Removal.
[2] MEF 70.1, SD-WAN Service Attributes and Services, December 2020
Editor Note 7: The above reference assumes MEF 70.1 goes to Letter Ballot before, or at the same time as, this document. At that time, the date will be updated.
[30] ETSI TS 103 523-3 V1.2.1, Technical Specification, CYBER; Middlebox Security Protocol; Part 3: Enterprise Transport Security, March 2019
[31] FIPS PUB 140-2, SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES, May 2001, https://csrc.nist.gov/publications/detail/fips/140/2/final
[32] NIST 800-52, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, Rev. 2, August 2019
[33] NIST Special Publication 800-53 (Rev. 4), Security and Privacy Controls for Federal Information Systems and Organizations, Information System Monitoring. NIST 800-53/Rev4/control/SI-4
[34] NIST SP 800-57 (Part 1, Rev. 5), Recommendation for Key Management: Part 1 – General, May 2020 https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
[35] NIST Special Publication 800-94, Guide to Intrusion Detection and prevention Systems (IDPS), February 2007
[36] CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, version 1.7.0, May 2020. https://cabforum.org/baseline-requirements/
Appendix A Application Flows and Security Functions
This appendix describes several use cases of Application Flows, with one or more security functions enabled. The use cases involve unencrypted Application Flows, encrypted Application Flows and an Application Flow with a mix of traffic.
It describes the security function behavior expected at the SD-WAN Edge by describing a hypothetical architecture. It does not imply that any implementation be architected or implemented based on this model.
The following acronyms are used throughout this appendix and are briefly described here.
• MBF – Middle-box Function
• IPPF – IP, Port and Protocol Filtering
• DPF – DNS Protocol Filtering
• DNF – Domain Name Filtering
• URLF – URL Filtering
• MDR – Malware Detection and Removal
• A – Allowed
• B – Blocked
The security functions are depicted with hexagons and labelled appropriately. These functions can be thought to be processed in parallel or serially, as shown in Figure 9 below.
This document does not constrain how these security functions are processed. A brief explanation of both is given below.
Parallel processing of security functions can provide the following benefits: all security functions processed in one location; single packet lookup across multiple functions; and reduced latency. It requires a single security Service Provider providing all of the functions. A challenge of this approach is a possibly higher compute power needed at the location.
Serial processing of security functions can provide the following benefits: lower compute power at a given location; allows for a multi-security Service Provider solution. It requires multiple security applications. A challenge of this approach multiple security Service Provider integration.
This document recognizes that both serial and parallel processing are valid implementations. Each has its benefits and challenges. This document does not take a position as to which should be utilized when applying security functions to an SD-WAN service.
For the sake of this appendix, serial processing has been utilized in all of the use cases, as it is easier to graphically represent the content of the use cases. This should not be construed as an endorsement of one option over another and is provided as exemplary only.
The Subscriber is running Office 365 applications over a TLS 1.2 encrypted session. All security functions are enabled.
Figure 10 - Use Case 1: Office 365, TLS 1.2 Application Flow
In Use Case 1, MBF decrypts and re-encrypts the Application Flow and the individual security functions check the Application Flow. All checks are good, and the Application Flow is Allowed.
A.2 Use Case 2: Office 365, TLS 1.2 Application Flow, Malware is Detected
The Subscriber is running Office 365 applications over a TLS 1.2 encrypted session. All security functions are enabled. Outlook Messages are subject to Malware Detection. Malware is detected and removed from a subset of the Application Flow.
Figure 11 - Use Case 2: TLS 1.2 Application Flow, Malware is Detected
In Use Case 2, MBF decrypts and re-encrypts the Application Flow and the individual security functions check the Application Flow. The Malware Detection and Removal security function detects malware in a message. The malware is removed and the rest of the Application Flow is Allowed.
A.3 Use Case 3: Google Drive, QUIC Application Flow
In Use Case 3, the Subscriber is running a Google Drive application over a QUIC encrypted session. The IP, Port and Protocol Filtering (IPPF) and DNS Protocol Filtering (DPF) security functions are enabled; the other security functions are disabled.
Figure 12 - Use Case 3: Google Drive, QUIC Application Flow
The Application Flow is defined as QUIC, using UDP port 443 and an Allowed list of IP addresses of QUIC servers. IPPF and DPF checks are good. The Application Flow is Allowed.
In Use Case 4, the Subscriber has an Application Flow supporting the Guest Wifi zone providing access to the Internet via Internet Breakout. The IP, Port and Protocol Filtering (IPPF), DNS Protocol Filtering (DPF) and Domain Name Filtering (DNF) security functions are enabled; the other security functions are disabled. On this Application Flow, clients are trying to access two different domains. Subset 1 of the Application Flow is trying to connect to site.abc.com web server. Subset 2 of the Application Flow is trying to connect to badresource.badcompany.org web server.
Figure 13 - Use Case 4: Web Traffic to a Public Resource
In this case, for subset 1, all security function checks are good, and subset 1 is allowed. For subset 2, the IPPF and DPF checks are good, but since the badresource.badcompany.org domain name is on the Block List, subset 2 is blocked.
In Use Case 5, the Subscriber is using the Application Flow for file transfer. File uploads consist of SSH and FTP. By policy, FTP is not allowed (on the Block List). The IP, Port and Protocol Filtering (IPPF) and DNS Protocol Filtering (DPF) security functions are enabled; the other security functions are disabled. Subset 1 of the Application Flow uses SSH, while subset 2 of the Application Flow uses FTP.
Figure 14 - Use Case 5: File Transfer, Application Flow is a mix of encrypted and unencrypted
In this case, DPF checks are good, but IPPF checks identify a file upload using FTP, which is on the Block List, and is therefore blocked. The SSH file uploads are allowed.
A.6 Use Case 6: Web Traffic to a Weather Site, unencrypted Application Flow
In Use Case 6, the Subscriber is accessing a website to check weather. The IP, Port and Protocol Filtering (IPPF) and DNS Protocol Filtering (DPF) security functions are enabled; the other security functions are disabled.
Figure 15 - Use Case 6: Web Traffic to a Weather Site, unencrypted Application Flow
In this case, IPPF and DPF checks are good. The Application Flow is allowed.
A.7 Use Case 7: Web Traffic to Public Resource, unencrypted Application Flow
In Use Case 7, the Subscriber has an Application Flow supporting the Guest Wifi zone providing access to the Internet via Internet Breakout. The IP, Port and Protocol Filtering (IPPF) and DNS Protocol Filtering (DPF) security functions are enabled; the other security functions are disabled. The Application Flow consists of DNS messages to two different DNS servers. Subset 1 of the Application Flow is sending DNS messages to DNS Server 1, which is on the Allow List. Subset 2 of the Application Flow is sending DNS messages to DNS Server 2, which is on the Block List.
Figure 16 - Use Case 7: Web Traffic to Public Resource, unencrypted Application Flow
In this case, DPF detects DNS messages to DNS Server 2 on the Block List, and blocks those messages. The DNS messages to the other DNS Server 1 are allowed.
In Use Case 8, the Subscriber is running applications to a Commerce website. The Application Flow consists of a mix of unencrypted and encrypted traffic. All security functions are enabled. By policy, unencrypted traffic is not allowed to this commerce website.
Figure 17 - Use Case 8: Commerce Website, mix of unencrypted and encrypted traffic
In this case, all security functions are enabled. Subset 1 of the Application Flow is encrypted, and all security function checks are good. Subset 1 is allowed. Subset 2 of the Application Flow is unencrypted. MBF is configured to block unencrypted traffic and so subset 2 is blocked.
A.9 Use Case 9: Internet Website, Unencrypted Traffic
In Use Case 9, the Subscriber is running unencrypted application to an Internet website. All security functions are enabled. By policy, unencrypted traffic is allowed on this Application Flow.
Figure 18 - Use Case 9: Internet Website, unencrypted traffic
MBF is configured to allow the unencrypted traffic, and all other security function checks are good. The Application Flow is allowed.
A.10 Use Case 10: Social Media Website, URL Filtering
In Use Case 10, the Subscriber is running applications to a social media website. All security functions are enabled. Subset 1 of the Application Flow consists of requests to site.abc.com/user-site, while subset 2 of the Application Flow consists of requests to site.abc.com/advertisement/adultcontent. By policy, access to URLs containing adult content are blocked.
Figure 19 - Use Case 10: Internet Website, unencrypted traffic
All security function checks for subset 1 are good, and that subset is allowed. The URLF security function detects that subset 2 has a URL that is on the Block List, and therefore subset 2 is blocked.
Appendix B Description of Transport Layer Security, TLS 1.3
Why is TLS 1.3 [27] more than an update of ciphers?
First and most important, it does a much better job of addressing weak security. Of course, many of the previous improvements to SSL and TLS made over the years have also been to improve security, but in order to maintain compatibility with previous versions, a lot of legacy stuff was also left in. And it was these items that provided an attack vector that allowed cybercriminals to bypass newer security in favor of older attacks - which is exactly how Logjam, FREAK, Lucky13, BEAST, and POODLE managed to succeed. TLS 1.3 does not allow to switch back to less secure protocols.
Some of the ciphers in previous versions were also weak cryptographically, making them vulnerable to a variety of exploits (RC4, CBC, SHA1, MD5, etc.). In fact, some of those ciphers were so weak that they also couldn’t prevent recorded traffic from being decrypted later if someone had access to the private key (RSA static key).
Of course, TLS 1.2 enabled you to prioritize your cipher preferences to make sure the newer ciphers were preferred over the older ones, but not many people did that. And the default ordering of ciphers left many people unknowingly vulnerable. TLS 1.3 has finally resolved this issue by replacing those less secure ciphers with more modern and secure solutions. By not allowing you to even enable these ciphers, TLS 1.3 makes you more secure.
The second big change involves speeding up the TLS handshake. TLS encryption and decryption traditionally takes a while to perform (especially when compared to not encrypting anything at all) because it requires extra CPU time and additional latency to perform TLS operations. Even a normal TLS 1.2 handshake consists of around 5-7 packets sent back and forth between the client and server, which creates a lot of unnecessary overhead. Even worse, each one of those packets moving back and forth also includes a certain amount of latency. TLS 1.3 reduces the number of packets needed for a handshake to 0-3. By doing this, connections can be established and start working sooner, and as a result, feel more responsive. And in some cases, a TLS session can even be resumed with no packets exchanged at all.
One caveat is that in TLS 1.2 the certificate exchanged between the client and server is unencrypted, while in TLS 1.3, the certificate is encrypted. This creates an issue for the middlebox relying on a passive decryption explaining some of the push back of the industries for TLS1.3. With active middlebox as described in this standard, the inspection is still allowed with TLS1.3.
The following examples describe different possible outcomes when Malware Detection and Removal is Enabled for a given Application Flow. In these examples, it is assumed that the Application Flow is using TLS 1.2 and that an MBF has been Enabled to see unencrypted traffic. Other security functions would have already been applied to the Application Flow, e.g., URL Filtering or Intrusion Detection, before checking for malware.
Figure 20 below shows an example of a clean file going through the malware detection and removal process.
Figure 20 - Example of a Clean File
In the example shown in Figure 20, the file is identified and scanned to detect a possible malware. The scan result is normal, and there is no need for further checking in the sandbox and so the Application Flow is re-encrypted and forwarded.
Figure 21 below shows an example of a file containing malware that is detected with a signature scan. In this figure, the red rectangle represents a part of a file that contains malware.
Figure 21 - Example of Malware Detected and File Removed, using a Signature Scan
In the example shown in Figure 21, the file is identified and scanned to detect a possible malware and malware is detected. A decision is made to remove the file and replace it with a URL re-direction that explains that a file containing malware has been detected and removed.
Figure 22 below shows an example of a file containing malware that is detected in the sandbox. As previously noted, the red rectangle represents a part of a file that contains malware. In this example, the Internet Content Adaptation Protocol (ICAP), as specified in RFC 3507 [8], is used for transferring data into and back from the sandbox.
Figure 22 - Example of Malware Detected and File Removed, using a Sandbox
In the example shown in Figure 22, the file is identified and the signature scan is normal, but the file looks suspicious, and a decision is made to sandbox the file for further analysis. Malware is detected in the sandbox and a new signature is created for the unknown malware. The file is removed and replaced with a URL re-direction that explains that a file containing malware has been detected and removed.
Figure 23 below shows an example of a file containing malware that is detected by a signature scan. As previously noted, the red rectangle represents a part of a file that contains malware.
Figure 23 - Example of Malware Detected and File Reconstructed
In example shown in Figure 23, the file is identified and scanned to detect a possible malware and malware is detected. A decision is made to remove the part of the file that has the malware and reconstruct the clean part of the file for forwarding. A message could be added explaining that a file containing malware has been detected and the malware removed from the file.
Threat modelling is the process by which threats, whether vulnerabilities or the absence of appropriate controls, can be described and mitigations or remediations planned. The purpose of the process is to provide those responsible for designing, developing, implementing, operating or using the system with a systematic understanding of what controls have been included and any gaps that may exist, given the nature of the system. In practice, this should consider the likely attacker’s profile, the tools, tactics and procedures they use to compromise such system and the assets which are most at risk. For this document, threat modelling was used to answer questions such as “Where would an SD-WAN solution be most vulnerable to attack?” and “What security controls do we need to design into the standard to protect against these attacks?”.
For the purposes of this document, the working group took the following approach:
• Created an application diagram using Microsoft’s Threat Modelling Tool
• Annotated the diagram with the properties as understood for each asset and functional flow
• Reviewed the working drafts to identify coverage of the threats identified by the previous two steps
• Annotated the threat with related references from this document
• Discussed and made changes to the overall document based on any gaps identified
For threats that the document proposes to mitigate or remediate, the threat model provided attempts to reference the appropriate sections of this document in justifying their state as “Mitigation Implemented”. Whilst a number of items within the threat model were also deemed to be “Out of scope”, their inclusion in the references in the supplied threat model should be instructive as to some of the responsibilities of individual implementations which will need consideration by software engineering, implementation and/or operational teams.
Editor Note 8: The following links work just for MEF members, for now. When going to Letter Ballot later this year, it is planned to add a sentence or two in this document with a link to a github server where the raw/tool file will be available for the industry at large.
An HTML version of the threat model is available on the following link: threat model - html, and a raw/tool file version is available on this link: threat model - raw/tool.
To view this tool’s output in the original source form, please use the freely available tool from Microsoft: https://aka.ms/threatmodelingtool. An overview of the tool and usage can also be found here: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool.
