Deploying an NGINX App across Kubernetes Multi-clusters with F5 BIG-IP Container Ingress Services
This tutorial simulates orchestrating multiple clusters using a single Kubernetes control plane with separate kubeconfig contexts, the same F5 CIS configuration patterns apply to genuinely separate Kubernetes clusters across different networks, cloud regions, or data centers. The simulation approach allows configuration testing without requiring multiple physical or cloud infrastructure environments.Introduction to BIG-IP SSL Orchestrator
Introduction SSL Orchestrator enables you to maximize infrastructure and security investments with dynamic, policy-based decryption, encryption, and traffic steering through security inspection devices. SSL Orchestrator is a key component of the F5 Application Delivery and Security Platform (ADSP). Demo Video What is SSL Orchestrator? F5 BIG-IP SSL Orchestrator is designed and purpose-built to enhance SSL/TLS infrastructure, provide security solutions with visibility into SSL/TLS encrypted traffic, and optimize and maximize your existing security investments. BIG-IP SSL Orchestrator delivers dynamic service chaining and policy-based traffic steering, applying context-based intelligence to encrypted traffic handling to allow you to intelligently manage the flow of encrypted traffic across your entire security stack, ensuring optimal availability. Designed to easily integrate with existing architectures and to centrally manage the SSL/TLS decrypt/re-encrypt function, BIG-IP SSL Orchestrator delivers the latest SSL/ TLS encryption technologies across your entire security infrastructure. With BIG-IP SSL Orchestrator’s high-performance encryption and decryption capabilities, your organization can quickly discover hidden threats and prevent attacks at multiple stages, leveraging your existing security solutions. BIG-IP SSL Orchestrator ensures encrypted traffic can be decrypted, inspected by security controls, then re-encrypted—delivering enhanced visibility to mitigate threats traversing the network. As a result, you can maximize your security services investment for malware, data loss prevention (DLP), ransomware, and NGFWs, thereby preventing inbound and outbound threats, including exploitation, callback, and data exfiltration. Why is this important? Offload your SSL decryption compute resources to F5. Let F5 handle all the decrypt/encrypt functions so your security tools don’t have to. This will increase the performance capabilities of your existing security solutions. Easily create policy to bypass decryption of sensitive traffic like Banking, Finance and Healthcare related websites. Improve high availability by leveraging SSL Orchestrator to distribute load among a group of security devices, like Next Generation Firewalls. A comprehensive SSL decryption solution gives you much-needed visibility into encrypted traffic, which enables you to block encrypted threats. SSL Orchestrator integrates with your existing infrastructure An SSL Orchestrator “Service” is defined as a device that SSL Orchestrator passes decrypted traffic to. A Service can be Layer 2 or 3. It can be unidirectional (TAP). It can be an ICAP server. It can be an Explicit or Transparent HTTP proxy. A Layer 2 device (bridging/bump-in-wire) refers to connectivity without IP Address configuration. Layer 2 devices pass all traffic from one interface to another interface. A Layer 3 device (typical NAT) refers to IP Address to IP Address connectivity. Layer 3 devices must be specifically configured to work on a network. An Explicit Proxy device also utilizes IP Address to IP Address connectivity. However, in this case, web applications have to be specifically configured to use an Explicit Proxy. A Transparent Proxy device also utilizes IP Address to IP Address connectivity. In this case, web applications DO NOT need to be configured to use a Proxy. Other type of devices are supported, like an ICAP server or TAP device. An ICAP server is often used for Data Loss Prevention (DLP). A TAP device is often used for passive visibility as it receives an exact copy of decrypted traffic. Service Chains Service Chains are user-defined groupings of one or more Services. Multiple Service Chains are supported by Policy (see next section). There are no restrictions on the type of Services that can be in a Service Chain. For example: a Service Chain can consist of one or more Layer 2 devices, and one or more Layer 3 devices, and so on. Policy SSL Orchestrator supports a flexible policy editor that is used to determines what type of traffic to send or not to send to a Service Chain. For example: in the case of an Outbound (see next section) configuration, certain content can bypass SSL Decryption based on URL Categories like Banking, Finance and Healthcare. Topologies A Topology defines how SSL Orchestrator will be interested into your traffic flow. It is defined as either Incoming or Outgoing. High-level parameters for how/what to intercept are defined here. In an Inbound Topology, traffic comes from users on the internet to access an application like mobile banking or shopping. This may also be referred to as a reverse proxy. In an Outbound Topology, traffic comes from users on your network to access sites/applications on the internet. For example: a person who works at Apple HQ who is accessing the internet using the company’s network. This may also be referred to as a forward proxy. Conclusion F5 BIG-IP SSL Orchestrator simplifies and accelerates the deployment of SSL visibility and orchestration services. Whether for modern, custom, or classic apps, and regardless of their location—be it on premises, in the cloud, or at the edge—BIG-IP SSL Orchestrator is built to handle today’s dynamic app landscape. Related Articles Integrating Security Solutions with F5 BIG-IP SSL Orchestrator
Automating F5 Application Delivery and Security Platform Deployments
The F5 ADSP Architecture Automation Project The F5 Application Delivery and Security Platform (ADSP) reduces the complexity of modern applications by integrating operations, traffic management, performance optimization, and security controls into a single platform with multiple deployment options. This series outlines practical steps anyone can take to put these ideas into practice using the F5 ADSP Architectures GitHub repo and related projects. Each article in the series highlights a different deployment example. The examples can be run locally or integrated into CI/CD pipelines following DevSecOps practices. The repositories are community-supported and intended as reference code for demos, workshops, or as a stepping stone for your own F5 ADSP deployments. If you find any bugs or have any enhancement requests, open an issue, or better yet, contribute. The F5 Application Delivery and Security Platform (F5 ADSP) F5 ADSP addresses four core areas: how you operate day-to-day, how you deploy at scale, how you secure against evolving threats, and how you deliver reliably across environments. Each comes with its own challenges, but together they define the foundation for keeping systems fast, stable, and safe. xOps — day-to-day operations, observability, and lifecycle management Deployment — getting workloads where they need to go, at the scale they need Delivery — traffic management across hybrid and multi-cloud environments Security — protecting applications and APIs from current threats Each architecture deployment example in this series is designed to cover at least three of the four core areas. This ensures the examples demonstrate how multiple components of the platform work together in practice, rather than showcasing any single feature in isolation. DevSecOps: Integrating security into the software delivery lifecycle is a necessary part of building and maintaining secure applications. This project incorporates DevSecOps practices by using supported APIs and tooling, with each use case including a GitHub repository containing IaC code, CI/CD integration examples, and telemetry options. In practice across the series, that means Terraform for infrastructure and F5 configuration, GitHub Actions as the pipeline runner, federated cloud identity instead of long lived keys, secrets handled through the platform rather than committed, and vulnerable target applications so the security controls can be exercised end-to-end. Contribute The repos are community-supported. Open an issue, send a PR, or port a use case to another cloud. Resources: F5 Application Delivery and Security Platform GitHub Repo and Automation Guide ADSP Architecture Article Series: Automating F5 ADSP Deployments (Intro) Automating F5 ADSP Deployments (Part 1 - F5 XC WAF and BIG-IP Adv. WAF) Automating F5 ADSP Deployments (Part 2 - F5 XC WAF and NGINX App Protect) Automating F5 ADSP Deployments (Part 3 - F5 XC API Protection and NGINX Ingress) Automating F5 ADSP Deployments (Part 4 - F5 XC BOT Defense and BIG-IP AdvWAF) Automating F5 ADSP Deployments (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress) Minimizing Security Complexity: Managing Distributed WAF PoliciesSSL Orchestrator Advanced Use Cases: Client Certificate Constrained Delegation (C3D) Support
Introduction F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases. If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility. SSL Orchestrator Use Case: Client Certificate Constrained Delegation (C3D) Using certificates to authenticate is one of the oldest and most reliable forms of authentication. While not every application supports modern federated access or multi-factor schemes, you'll be hard-pressed to find something that doesn't minimally support authentication over TLS with certificates. And coupled with hardware tokens like smart cards, certificates can enable one of the most secure multi-factor methods available. But certificate-based authentication has always presented a unique challenge to security architectures. Certificate "mutual TLS" authentication requires an end-to-end TLS handshake. When a server indicates a requirement for the client to submit its certificate, the client must send both its certificate, and a digitally-signed hash value. This hash value is signed (i.e. encrypted) with the client's private key. Should a device between the client and server attempt to decrypt and re-encrypt, it would be unable to satisfy the server's authentication request by virtue of not having access to the client's private key (to create the signed hash). This makes encrypted malware inspection complicated, often requiring a total bypass of inspection to sites that require mutual TLS authentication. Fortunately, F5 has an elegant solution to this challenge in the form of Client Certificate Constrained Delegation, affectionally referred to as "C3D". The concept is reasonably straightforward. In very much the same way that SSL forward proxy re-issues a remote server certificate to local clients, C3D can re-issue a remote client certificate to local servers. A local server can continue to enforce secure mutual TLS authentication, while allowing the BIG-IP to explicitly decrypt and re-encrypt in the middle. This presents an immediate advantage in basic load balancing, where access to the unencrypted data allows the BIG-IP greater control over persistence. In the absence of this, persistence would typically be limited to IP address affinity. But of course, access to the unencrypted data also allows the content to be scanned for malicious malware. C3D actually takes this concept of certificate re-signing to a higher level though. The "constrained delegation" portion of the name implies a characteristic much like Kerberos constrained delegation, where (arbitrary) attributes can be inserted into the re-signed token, like the PAC attributes in a Kerberos ticket, to inform the server about the client. Servers for their part can then simply filter on client certificates issued by the BIG-IP (to prevent direct access), and consume any additional attributes in the certificate to understand how better to handle the client. With C3D you can maintain strong mutual TLS authentication all the way through to your servers, while allowing the BIG-IP to more effectively manage availability. And combined with SSL Orchestrator, C3D can enable decryption and inspection of content for malware inspection. This article describes how to configure SSL Orchestrator to enable C3D for inbound decrypted inspection. Arguably, most of what follows is the C3D configuration itself, as the integration with SSL Orchestrator is pretty simple. Note that Client Certificate Constrained Delegation (C3D) is included with Local Traffic Manager (LTM) 13.0 and beyond, but for integration with SSL Orchestrator you should be running 14.1 or later.To learn more about C3D, please see the following resources: K14065425: Configuring Client Certificate Constrained Delegation (C3D): https://support.f5.com/csp/article/K14065425 Manual Chapter: SSL Traffic Management: https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-system-ssl-administration/ssl-traffic-management.html#GUID-B4D2529E-D1B0-4FE2-8C7F-C3774ADE1ED2 SSL::c3d iRule reference - not required to use C3D, but adds powerful functionality https://clouddocs.f5.com/api/irules/SSL__c3d.html The integration of C3D with SSL Orchestrator involves effectively replacing the client and server SSL profiles that the SSL Orchestrator topology creates, with C3D SSL profiles. This is done programmatically with an iRule, so no "non-strict" customization is required at the topology. Also note that an inbound (reverse proxy) SSL Orchestrator topology will take the form of a "gateway mode" deployment (a routed path to multiple applications), or "application mode" deployment (a single application instance hosted at the BIG-IP). See section 2.5 of the SSL Orchestrator deployment guide for a deeper examination of gateway and application modes: https://clouddocs.f5.com/sslo-deployment-guide/ The C3D integration is only applicable to application mode deployments. Configuration C3D itself involves the creation of client and server SSL profiles: Create a new Client SSL profile: Configuration Certificate Key Chain: public-facing server certificate and private key. This will be the certificate and key presented to the client on inbound request. It will likely be the same certificate and key defined in the SSL Orchestrator inbound topology. Client Authentication Client Certificate: require Trusted Certificate Authorities: bundle that can validate client certificate. This is a certificate bundle used to verify the client's certificate, and will contain all of the client certificate issuer CAs. Advertised Certificate Authorities: optional CA hints bundle. Not expressly required, but this certificate bundle is forwarded to the client during the TLS handshake to "hint" at the correct certificate, based on issuer. Client Certificate Constrained Delegation Client Certificate Constrained Delegation: Enabled Client Fallback Certificate (new in 15.1): option to select a default client certificate if client does not send one. This option was introduced in 15.1 and provides the means to select an alternate (local) certificate if the client does not present one. The primary use case here might be to select a "template" certificate, and use an iRule function to insert arbitrary attributes. OCSP: optional client certificate revocation control. This option defines an OCSP revocation provider for the client certificate. Unknown OCSP Response Control (new in 15.1): determines what happens when OCSP returns Unknown. If an OCSP revocation provider is selected, this option defines what to do if the response to the OCSP query is "unknown". Create a new Server SSL profile: Configuration Certificate: default.crt. The certificate and key here are used as "templates" for the re-signed client certificate. Key: default.key Client Certificate Configuration Delegation Client Certificate Constrained Delegation: Enabled CA Certificate: local forging CA cert. This is the CA certificate used to re-sign the client certificate. This CA must be trusted by the local servers. CA Key: local forging CA key CA Passphrase: optional CA passphrase Certificate Extensions: extensions from the real client cert to be included in the forged cert. This is the list of certificate extensions to be copied from the original certificate to the re-issued certificate. Custom Extension: additional extensions to copy to forged cert from real cert (OID). This option allows you to insert additional extensions to be copied, as OID values. Additional considerations: Under normal conditions, the F5 and backend server attempt to resume existing SSL sessions, whereby the server doesn’t send a Certificate Request message. The effect is that all connections to the backend server use the same forged client cert. There are two ways to get around this: Set a zero-length cache value in the server SSL profile, or Set server authentication frequency to ‘always’ in the server SSL profile CA certificate considerations: A valid signing CA certificate should possess the following attributes. While it can work in some limited scenarios, a self-signed server certificate is generally not an adequate option for the signing CA. keyUsage: certificate extension containing "keyCertSign" and "digitalSignature" attributes basicConstraints: certificate extension containing "CA = true" (for Yes), marked as "Critical" With the client and server SSL profiles built, the C3D configuration is basically done. To integrate with an inbound SSL Orchestrator topology, create a simple iRule and add it to the topology's Interception Rule configuration. Modify the SSL profile paths below to reflect the profiles you created earlier. ### Modify the SSL profile paths below to match real C3D SSL profiles when CLIENT_ACCEPTED priority 250 { ## set clientssl set cmd1 "SSL::profile /Common/c3d-clientssl" ; eval $cmd1 } when SERVER_CONNECTED priority 250 { ## set serverssl SSL::profile "/Common/c3d-serverssl" } In the SSL Orchestrator UI, either from topology workflow, or directly from the corresponding Interception Rule configuration, add the above iRule and deploy. The above iRule programmatically overrides the SSL profiles applied to the Interception Rule (virtual server), effectively enabling C3D support. At this point, the virtual server will request a client certificate, perform revocation checks if defined, and then mint a local copy of the client certificate to pass to the backend server. Optionally, you can insert additional certificate attributes via the server SSL profile configuration, or more dynamically through additional iRule logic: ### Added in 15.1 - allows you to send a forged cert to the server ### irrespective of the client side authentication (ex. APM SSO), ### and insert arbitrary values when SERVERSSL_SERVERCERT { ### The following options allow you to override/replace a submitted ### client cert. For example, a minted client certificate can be sent ### to the server irrespective of the client side authentication method. ### This certificate "template" could be defined locally in the iRule ### (Base64-encoded), pulled from an iFile, or some other certificate source. # set cert1 [b64decode "LS0tLS1a67f7e226f..."] # set cert1 [ifile get template-cert] ### In order to use a template cert, it must first be converted to DER format # SSL::c3d cert [X509::pem2der $cert1] ### Insert arbitrary attributes (OID:value) SSL::c3d extension 1.3.6.1.4.1.3375.3.1 "TEST" } If you've configured the above, a server behind SSL Orchestrator that requires mutual TLS authentication can receive minted client certificates from external users, and SSL Orchestrator can explicitly decrypt and pass traffic to the set of malware inspection tools. You can look at the certificate sent to the server by injecting a tcpdump packet between the BIG-IP and server, then open in Wireshark. tcpdump -lnni [VLAN] -Xs0 -w capture.pcap [additional filters] Finally, you might be asking what to do with certificate attributes injected by C3D, and really it depends on what the server can support. The below is a basic example in an Apache config file to block a client certificate that doesn't contain your defined attribute. <Directory /> SSLRequire "HTTP/%h" in PeerExtList("1.3.6.1.4.1.3375.3.1") RewriteEngine on RewriteCond %{SSL::SSL_CLIENT_VERIFY} !=SUCCESS RewriteRule .? - [F] ErrorDocument 403 "Delegation to SPN HTTP/%h failed. Please pass a valid client certificate" </Directory> And there you have it. In just a few steps you've configured your SSL Orchestrator to integrate with Client Certificate Constrained Delegation to support mutual TLS authentication, and along the way you have hopefully recognized the immense flexibility at your command. Updates As of F5 BIG-IP 16.1.3, there are some new C3D capabilities: C3D has been updated to encode and return the commonName (CN) found in the client certificate subject field in printableString format if possible, otherwise the value will be encoded as UTF8. C3D has been updated to support inserting a subject commonName (CN) via 'SSL::c3d subject commonName' command: when CLIENTSSL_HANDSHAKE { if {[SSL::cert count] > 0} { SSL::c3d subject commonName [X509::subject [SSL::cert 0] commonName] } } C3D has been updated to support inserting a Subject Alternative Name (SAN) and Authority Info Access (AIA) via 'SSL::c3d extension' commands: when CLIENTSSL_HANDSHAKE { ## Insert Subject Alternative Name (SAN) value SSL::c3d extension SAN "DNS:*.test-client.com, IP:1.1.1.1" ### Insert Authority Info Access (AIA) value SSL::c3d extension AIA "ocsp,https://ocsp.entrust.net.com; caIssuer, https://aia.entrust.net/l1m-chain256.cer" } C3D has been updated to add the Authority Key Identifier (AKI) extension to the client certificate if the CA certificate has a Subject Key Identifier (SKI) extension. Another interesting use case is copying the real client certificate Subject Key Identifier (SKI) to the minted client certificate. By default, the minted client certificate will not contain an SKI value, but it's easy to configure C3D to copy the origin cert's SKI by modifying the C3D server SSL profile. In the "Custom extension" field of the C3D section, add 2.5.29.14 as an available extension. __________________________________________ As of F5 BIG-IP 17.1.0 (SSL Orchestrator 11.0), C3D has been integrated natively. Now, for a deployed Inbound topology, the C3D SSL profiles are listed in the Protocol Settings section of the Interception Rules tab. You can replace the client and server SSL profiles created by SSL Orchestrator, with C3D SSL profiles in the Interception Rules tab to support C3D. The C3D support is now extended to both Gateway and Application modes. __________________________________________ As of F5 BIG-IP 21.1, there are some new C3D capabilities: C3D adds a new option in the server SSL profile to enable overriding the certificate start date. This overrides the notBefore (valid-from) attribute of forged certificates to dynamically set the certificate's start time to align with the exact time of certificate forging. C3D adds a new option in the server SSL profile to enable caching of forged certificates. This reduces the need to repeatedly generate them for similar transactions, thereby improving efficiency during high-traffic scenarios, and reducing computational overhead in TLS proxy flows. C3D adds a new iRule command to keep or override the notBefore date in the forged certificate. when CLIENTSSL_HANDSHAKE { ## Update forged certificate lifespan SSL::c3d cert_lifespan [1-8760] } C3D adds a new iRule command to override the forged certificate lifespan. when CLIENTSSL_HANDSHAKE { ## Override the forged certificate notBefore date SSL::c3d cert_start_date [ override | original ] } C3D adds a new iRule command to inject X.509 keyUsage attributes into the forged certificate. when CLIENTSSL_HANDSHAKE { ## Injects KeyUsage constraints into the forged certificate SSL::c3d extension KU "digitalSignature, keyEncipherment" } C3D adds a new iRule command to inject X.509 extendedKeyUsage attributes into the forged certificate. when CLIENTSSL_HANDSHAKE { ## Injects extendedKeyUsage constraints into the forged certificate SSL::c3d extension EKU "serverAuth, clientAuth" } C3D adds a new iRule command to inject X.509 subjectDirectoryAttributes into the forged certificate. when CLIENTSSL_HANDSHAKE { ## Injects subjectDirectoryAttributes constraints into the forged certificate SSL::c3d extension SDA "dateOfBirth:20000101000000Z, countryOfCitizenship:US" } Note that certificate extensions enabled in the C3D server SSL profile configuration are copy operations. When enabled they copy the selected attributes from the origin certificate. The iRule commands are write operations. They allow you to specify new attribute values.How to use F5 Distributed Cloud to block (OFAC) Sanctioned Countries
Over the last several days, the climate has changed significantly in Eastern Europe, and I have been getting asked a lot about the possibility of blocking Office of Foreign Assets Control - Sanctioned Countries (OFAC) with F5 Distributed Cloud, and how to do it. The answer is quite simple; yes we can do it and its a pretty simple configuration. I think its also important to point out that this same process can be used to configure any other required GeoFencing policies as well. Do we also have ways to block DDOS and provide WAAP services? Also yes, but outside the scope of this article. In this article, I will focus on how to deploy & create: [Namespace] Service Policies Origin Pool(s) to send traffic to Distributed listener / load balancer with the security policy assigned View Security Events. Level Set Most of this article will be based around ClickOps deployment of this use-case. That said, the F5 Distributed Cloud is an API first platform, so everything can be done with your tools of choice for interaction with declarative APIs. I will include JSON manifests of the configured items as well to provide examples of what delcarations will resemble, as well as support direct import into the distributed cloud. It would be possible to say, set the policy configuration JSON into github as a source of truth, and have webhooks set up to push to the platform any time a change is made to ensure configurations stay within proper alignment. Who do we block? Before we can start blocking things, we need to know what exactly to block, so we need to acquire a list of OFAC Sanctioned Countries. There are a couple of options here as well. CSV straight from the source: https://home.treasury.gov/policy-issues/office-of-foreign-assets-control-sanctions-programs-and-information Dig through available data sources on Data.Gov: https://catalog.data.gov/dataset/consolidated-non-sdn-sanctions-list Third Party ACL Sites like Country Block List: https://www.countryipblocks.net/ofac.php (I cannot personally vouch for the accuracy of this content.) For the sake of brevity here, I will focus on just some top level country sanctions based on country code versus IP Subnet, but thats up to preference. Configuration Log in to your F5 Distributed Cloud Console. (If you do not have a tenant today, you should reach out to your F5 Account Team immediately and rectify the situation!) Service Policies for everyone! There are a couple of options for service policies in the platform. Shared Policies: Policies created in the Shared namespace, can be shared globally within your tenant. Benefit: Globally set policy baseline for all applications in your tenant. Namespace Policies: Policies created in a Namespace can only be shared within that namespace. Benefit: Namespace service policies applied by default to all listeners / load balancers. For this example, we will create the policy in a namespace. From the tiles, select Load Balancers, and then we need to ensure that we are in the proper namespace. (As with everyting on the platform, there are multiple ways to get places, and multple ways to configure things, so this will only cover 1 example of how.) Now we need to expand Security, hover over Service Policies, Click Service Policies, and in the new window click Add service policy. Populate the Name under metadata, leave attachment as Any Server, and set Select Policy Rules to Denied Sources. Now, we could use IP blocks, but for this example we will just use the Country List configuration parameter and enter country codes. This will pull from GeoIP validation. UPDATE: I have been getting a lot of notes on this article based on Ukraine versus Crimea, and how to specify since its not seperated out as a country code. Can we Allow Ukraine and block Crimea? Absolutely! For Crimea, we need to pull from another database, so for this example I am going to pull from https://bgpview.io/search/Crimea and we are going to block by ASN. So within our service policy, click Add item under BGP ASN Set. And on this screen we enter in all the ASN's that we discovered from the previous link. Then click Apply. (Making sure to now remove Ukraine from our Block List.) Then we need to determine Default Action. This is where you can cause some pain for yourself, so pay special attention when selecting Default action (“Default Action for requests from sources that do not belong to this list”), if you are using Next Policy, ensure the next policy allows traffic, or set the Default action to Allow, or the application will not receive any traffic. In this example I will only be using one policy, so I will set the Default Action to Allow (as noted in the JSON). Save and Exit. UPDATE 2: OK, you guys are killing me! Can we go to City Level or target regions outside of ASN? Yes! Here is how you do that. (I should plan better in the future for less edits!) Just to keep things clean, lets add a new Service Policy. This time, under Select Policy Rules, we are going to select Custom Rule List from the drop down. Then from here, we want to click Configure under Rules, then Add Item. Give our new rule a name, and click Configure under Rule Specification. From here, we are going to change the dropdown under Clients - Client Selection from Any Client to Group of Clients by Label Selector. Then under Selector Expression, Add Label. In the available selections you will find geoip.ves.io/city, country, and region (as well as some really cool IP Intelligence options but those are out of scope for this article.). Lets do a Region first to see how that works. Selct geoip.ves.io/region, then =, then start typing a region, for example Crimea. Once we have it set, scroll down and click Apply. Now, lets add another rule, but this time we are going to select city. We are already blocking Russia in our earlier policy, but just for an example lets add = Moscow. Now scroll down and click Apply. Thats it! Now we have policies to block based on GeoIP Country, Region, and City, as well as BGP ASN. We can apply all of them to our application at the same time. Now, lets say you just want to cheat, and copy and paste some JSON in, or you want to build it into a pipeline. You can go and check out the API specifications for Service Policy here: https://docs.cloud.f5.com/docs/api/service-policy The JSON would resemble the following for our first policy: { "metadata": { "name": "coleman-ofac-deny", "namespace": "m-coleman", "labels": {}, "annotations": {}, "description": "", "disable": false }, "spec": { "algo": "FIRST_MATCH", "any_server": {}, "rules": [ { "kind": "service_policy_rule", "uid": "c12f8c5d-44c2-495c-83e8-30842e9e0a7f", "tenant": "f5-sa-rnxeudss", "namespace": "m-coleman", "name": "ves-io-service-policy-coleman-ofac-deny-asn-list" }, { "kind": "service_policy_rule", "uid": "5d24d0d0-6c6b-4c7b-b5b3-4bec67c2ffed", "tenant": "f5-sa-rnxeudss", "namespace": "m-coleman", "name": "ves-io-service-policy-coleman-ofac-deny-country-list" }, { "kind": "service_policy_rule", "uid": "f9df0b83-21de-4c13-aebf-4e27fc580ed0", "tenant": "f5-sa-rnxeudss", "namespace": "m-coleman", "name": "ves-io-service-policy-coleman-ofac-deny-default-action" } ], "deny_list": { "ip_prefix_set": [], "asn_list": { "as_numbers": [ 204791, 205515, 208090, 28761, 41269, 43222, 43564, 49617, 59744, 8654 ] }, "asn_set": [], "country_list": [ "COUNTRY_BY", "COUNTRY_BA", "COUNTRY_BI", "COUNTRY_CF", "COUNTRY_CU", "COUNTRY_IR", "COUNTRY_IQ", "COUNTRY_KP", "COUNTRY_XK", "COUNTRY_LY", "COUNTRY_MK", "COUNTRY_SO", "COUNTRY_SD", "COUNTRY_SY", "COUNTRY_ZW", "COUNTRY_CD", "COUNTRY_LB", "COUNTRY_NI", "COUNTRY_RU", "COUNTRY_SS", "COUNTRY_VE", "COUNTRY_YE" ], "tls_fingerprint_classes": [], "tls_fingerprint_values": [], "default_action_allow": {} }, "simple_rules": [] } } And our second policy JSON puts us over the limit for the article, but all JSON from these configs are in the attached file. Origin Pools Origin Pools are where we send traffic to, so if you are familiar with BIG-IP its just the Pool, and if you are familiar with NGINX its our Upstream. All of the settings and nerd knobs that are part of origin pools are out of scope of this article, so we are just going to point our origin at a single public IP and move on. To create an Origin Pool, Expand the Manage Block, hover over Load Balancers, click Origin Pools, and then Add Origin Pool. Give the Origin Pool a Name under Metadata. Then under Origin Servers click Add Item so we can add an upstream server. For this example I am going to use a Public DNS Name of Origin Server, but you should use whichever applies best to your situation. Click Add Item once done, which will return us to the Origin Pool Config. Make sure to select the correct port, and any TLS settings for your environment. Click Save and Exit. Load Balancer / Listener Now that we have somewhere to send traffic, we need a way to receive traffic and assign security policies. We will be staying within scope for this use-case as well and not highlighting all of the details within the load balancer configuration. To create a Load Balancer, Expand the Manage Block, hover over Load Balancers, click HTTP Load Balancers, and then Add HTTP load balancer. Set a Name under Metadata. Under Basic Configuration, Domains, add a domain for the application. If you have delegated a DNS zone to the platform, we can automate DNS (and make certificate management super easy, but not required). Under Default Origin Servers, click Add Item, and in the Origin Pool drop down, select the pool that was created previously, then click Add Item. For VIP configuration we will leave as Advertise on Internet. You will notice under Security Configuration, Service Policies are already set to Apply Namespace Service Policies. Since I have a few policies in my namespace already, and I want to demonstrate OFAC policies, I am going to change this to Apply Specified Service Policies, and under Apply Specified Service Policies click Configure and select the previously created policy, then click Apply. From here click Save and Exit. Testing Using a VPN we can make sure that our policy is up and running. Since we did not configure a custom response page of any sort we should just get a 403 - Forbidden page. While users accessing from non OFAC countries will be able to access the application. Reporting We should be able to access the security events now as well, Expand Virtual Hosts, HTTP Load Balancers, and then over the load balancer we created earlier a hyperlink for Security Monitoring will show up, click it. We can see in the dashboard a L7 security event, and if we select Security Events, we will see that our VPN based request was flagged (l7_policy_sec_event, Rule to match CountryList). If its not totally legible, I VPN'd to Belarus and tried to access the page. Hint: Being able to use the JSON to copy policies is really great, I have used this in action with several customers to show how quickly we can backup and copy policies between environments in a few seconds. Thats it, now your web application is blocking traffic from OFAC sanctioned countries, and anyone else you want to keep out.
F5 Distributed Cloud AI-Powered WAF: From Signature Tuning to Outcomes
AI-Powered WAF for F5 Distributed Cloud WAF is now GA. The goal is to help teams move from configuration-heavy, signature-by-signature tuning to outcome-based enforcement—so you can run WAF in blocking mode sooner, reduce operational friction, and improve detection while keeping false positives low. This article is implementation-focused and centers on the Custom policy path, where customers must make the most consequential choices: Signature Accuracy selection and how to enforce Risk Levels (High/Medium/Low) via risk-based actions.
AI-Enabled Risk Scoring Helps Reduce Risks
Risk Categories AI-enabled Risk Scoring for F5 Distributed Cloud WAF reduces key risk categories: Security, Business/availability, and Operational. Security risk (missed attacks / false negatives): F5 Distributed Cloud's AI-Powered WAF Risk Scoring improves detection by combining multiple signals per request so you don't miss attacks that traditional WAFs may not catch: High-confidence signatures Curated signature combinations (with LLM labeling to improve precision) Attack indicators (e.g., SQLi signals, libinjection, multiple signatures) A real-time ML model—to catch attacks that traditional WAFs may miss Business/availability risk (false positives blocking real users) By assigning High/Medium/Low risk outcomes using layered analysis, teams can enforce blocking with more confidence and keep false positives low, reducing accidental customer impact such as blocking legitimate users. Staged workflows are enabled, such as: Block High Review Medium (implicitly allow Low while continuing to observe) Operational risk (slow time-to-protection and heavy tuning burden) F5 Distributed Cloud's AI-Powered WAF Risk Scoring reduces manual exceptions and case-by-case policy tuning, enabling teams to deploy the WAF in blocking mode sooner, with less ongoing friction across SecOps, dev, and platform teams. Outcome-based scoring enables: Improved consistency of enforcement across distributed apps/APIs Standardization of protection by reducing bespoke tuning per app How the system makes a risk decision Risk level is computed from layering multiple complementary analyses: High Risk or High Accuracy Signature matches Heuristics – such as injection attacks, multiple attack signatures detected, predictable resource exploitation, other risk indicators Neural network - Signatures can sometimes lead to false positives. To address that, a neural network acts as a secondary classifier to determine whether attack fragments flagged by signatures signal an attack, improving accuracy while maintaining real-time performance. Key system scope The ML model analyzes behavioral patterns to refine risk assessment, ensuring accurate classification and enabling effective threat prioritization. Calling the ML model will adhere to the following scope: The ML model is called only if at least one enabled (not excluded/disabled) signature triggers in these categories: Server-Side Code Injection, SQL Injection, XSS, Command Execution, Path Traversal, LDAP Injection, XPath Injection The model analyzes only HTTP request fragments that trigger signatures (not full raw requests). If signatures are excluded or disabled, they are not considered for invoking the model. Model output: 1 = malicious → request risk level set to High 0 = benign → request risk level set to False Positive A primer on Signature Accuracy vs Signature Risk Accuracy Indicates the ability of the attack signature to identify the attack including susceptibility to false-positive alarms: Low: Indicates a high likelihood of false positives. Medium: Indicates some likelihood of false positives. High: Indicates a low likelihood of false positives. Risk Indicates the level of potential damage this attack might cause if it is successful: Low: Indicates the attack does not cause direct damage or reveal highly sensitive data. Medium: Indicates the attack may reveal sensitive data or cause moderate damage. High: Indicates the attack may cause a full system compromise. Does AI-enabled Risk Scoring add latency? AI-enabled Risk Scoring works in line with F5 Distributed Cloud WAF, inspecting real-time traffic without adding noticeable latency in our tests.F5 BIG-IP PEM telling the Service Provider's traffic story
A fundamental issue with Service Provider networks isn’t too much traffic. It’s that the network has no idea who is generating that traffic, what they’re doing, or what service plan they’re on. Without that context, every policy decision is blunt. F5 BIG-IP Policy Enforcement Manager (PEM) answers that problem for service providers. This article walks through how it works, and then gets into the specific use cases where it changes what’s operationally possible. How BIG-IP PEM builds subscriber context BIG-IP PEM sits inline between your subscribers and the network, between the GGSN/PGW and the internet or IMS core. Its first job is identity: before applying any policy, it needs to know who the subscriber is. It does this by intercepting RADIUS authentication and accounting packets when a subscriber logs onto the network, pulling the IMSI, IP address, username, and device type from those packets. That session binding (subscriber identity mapped to an IP address) is what makes every downstream decision context-aware. Once identity is established, BIG-IP PEM talks to the PCRF over a Gx interface to pull that subscriber’s policy. What plan are they on? Do they have any active add-ons or QoS entitlements? What usage thresholds apply? The PCRF answers, and BIG-IP PEM stores that configuration for the duration of the session. On top of identity, BIG-IP PEM classifies traffic at layers 4–7, using a combination of deep packet inspection and machine learning to identify over 4,000 applications, including encrypted OTT video that classic DPI tools can’t classify. The combination of who (subscriber) + what (application) + what plan (PCRF policy) is what makes fine-grained enforcement possible. Use case 1: Tiered service plans In practice, a subscriber on a premium plan gets priority queuing and higher guaranteed throughput. A basic plan subscriber hits a rate limiter when the network is congested. A business subscriber might get DSCP marking that carries their traffic with higher priority through downstream QoS domains. None of this is visible to the subscriber as a degraded experience it's just the service they signed up for, behaving as advertised. Bandwidth control in BIG-IP PEM operates at three levels: per subscriber, per-subscriber-group, and per application-type. That last one is particularly useful as you can rate-limit peer-to-peer traffic globally without touching the video or web browsing experience for anyone. The upside here isn’t just enforcing what subscribers already pay for. It’s giving your team the confidence to design genuinely differentiated tiers, knowing the network will actually enforce the difference. Use case 2: ABR video optimization Video traffic is now the majority of mobile network load, and most of it is encrypted adaptive bitrate (ABR), the same protocol that makes Netflix or YouTube automatically adjust quality based on available bandwidth. The challenge for operators is that encrypting video traffic means traditional inspections can’t see it clearly enough to manage it intelligently. BIG-IP PEM uses machine learning to detect and classify encrypted ABR flows, including QUIC-based streams without needing to decrypt them. Once identified, protocol-agnostic bandwidth controls are applied per flow. The practical use here is protecting RAN capacity. A single 4K stream can consume spectrum that would otherwise serve several standard-definition subscribers. BIG-IP PEM lets you cap 4K delivery during congestion periods, or apply it only to subscribers on plans that include HD streaming, without the subscriber experiencing a hard cutoff just a graceful step down in resolution. Preserving RAN capacity during peak hours has a direct effect on network investment cycles and subscriber satisfaction scores. Use case 3: Value-added service steering and service chaining Most SPs run a range of value-added services (VAS) ( video optimization servers, security inspection platforms, parental controls, web caching, anti-spam), but the traditional approach to using them is blunt: route all traffic through all services, or build a static linear chain. Both approaches waste resources and add latency where it isn’t needed. BIG-IP PEM enables selective steering: only send traffic to a VAS platform when it’s relevant, based on the combination of subscriber identity and traffic classification. A subscriber on a basic plan doesn’t need to hit the video optimization server. A business subscriber who hasn’t opted into the security bundle doesn’t need an anti-virus inspection. Service chaining goes a step further, allowing you to construct ordered service graphs that vary by subscriber type. For example: a subscriber requesting video content goes first to URL filtering (to check parental control settings), then to the video optimization server, then out to the network. Another subscriber browsing web content skips both. The chain is dynamic. It’s assembled based on what BIG-IP PEM learns from the PCRF. The infrastructure efficiency gain here is real: VAS platforms are expensive to run at scale, and right-sizing them to the traffic that actually needs them reduces both cost and latency. Use case 4: Tethering detection and policy Unauthorized tethering, where a subscriber shares their mobile data plan with other devices via a personal hotspot. This is a consistent headache for mobile operators. It puts additional load on the network under a plan that wasn’t priced for it, and it creates asymmetric capacity consumption that impacts other users in the same cell. BIG-IP PEM can detect tethering behavior through a combination of TTL analysis, user-agent inspection, and traffic pattern recognition. Once detected, it can enforce whatever policy you’ve defined: a hard cap on tethered traffic, a redirect to a tethering add-on purchase page, or an automatic upgrade to a multi-device plan. Use case 5: Parental controls as a managed service This one tends to get underestimated. URL filtering inside BIG-IP PEM lets service providers offer parental controls as a managed, network-level service that works regardless of which device or browser the subscriber uses, because the filtering happens on the network itself, not on the endpoint. Subscribers opt in (or you offer it as a default for certain plan types), and the SP maintains category lists that are enforced per subscriber. The commercial framing is straightforward: it’s a value-add that reduces churn among family plan subscribers and creates a natural differentiation from OTT competitors who can’t offer network-level enforcement. From an operational standpoint, category updates and custom block lists are managed centrally through BIG-IP PEM and pushed across the subscriber base with no endpoint agent deployment, and no device compatibility issues. Conclusion Putting it all together: BIG-IP PEM lives at the policy enforcement function (PEF) layer in 3GPP architecture. It’s inline on the Gi/SGi or N6 interface, sees all subscriber traffic, and acts as the enforcement point for whatever your PCRF has decided. The PCRF handles policy decisions; BIG-IP PEM handles policy execution. A few things worth calling out for anyone architecting this: BIG-IP PEM integrates with BIG-IP AFM for inline DDoS and network firewall, which means you can consolidate subscriber-facing security and policy enforcement on the same platform rather than running separate appliances for each. For operators running moving to 5G or 6G, BIG-IP PEM’s CNF deployment option means you don’t have to maintain two separate PEF architectures during the transition. Related Content BIG-IP Policy Enforcement Manager: Implementations F5BigPemPolicy Reference PEM: Subscriber-Aware Policy and Why Every Large Network Needs One | DevCentral PEM: Key Component of the Next Generation University Network | DevCentralBIG-IP Cloud-Native Network Functions 2.3: What’s New in CNF and BNK
Introduction F5 BIG-IP continues to advance BIG-IP Next for Kubernetes (BNK) and Cloud-Native Network Functions (CNFs) to meet the growing demands of service providers and modern application environments. F5 provides the full stack required to make cloud-native networking work in a service provider environment. CNFs alone are not enough; you need functions, control, infrastructure, and observability, working together as one system. What is new in BIG-IP Cloud-Native Network functions 2.3 for BNK and CNF? Release 2.3 adds MPLS provider edge support (early access), native UDP/TCP load balancing, DPU-accelerated data plane offload on NVIDIA BlueField, and subscriber-aware Policy Enforcement Manager (PEM) with Gx interface integration. It also introduces VRF-aware AFM policies, GSLB with Sync Groups for multi-region deployments, BBRv2 congestion control, and crash diagnostics that operate without host-level Kubernetes access. This release targets service providers and telecom operators who need cloud-native networking without sacrificing the protocol support and policy control of traditional infrastructure. Cloud-Native Network Functions (CNFs): What Changed in 2.3? In release 2.3, CNF capabilities focus on strengthening the underlying network functions required for service provider deployments. How does BIG-IP CNF 2.3 handle crash diagnostics in restricted Kubernetes clusters? Operating CNFs in production environments requires strong observability, even in restricted clusters. Release 2.3 introduces improvements to the crash agent that allow core files to be collected directly from pods without requiring host-level access. This enables deployments in more secure Kubernetes environments and simplifies troubleshooting when issues occur. How does BIG-IP CNF 2.3 operate in multi-tenant and multi-VRF environments? Multi-tenant environments demand precise control over traffic behavior. Release 2.3, Advanced Firewall Manager (AFM), introduces VRF-aware ACL and NAT policies, allowing operators to apply firewall and translation rules within specific routing contexts. This enables better segmentation and supports overlapping address spaces while maintaining consistent policy enforcement. It aligns CNFs more closely with how service provider networks are designed and operated. Can BIG-IP CNF 2.3 operate at edge? One of the most significant additions to this release is MPLS support within CNFs. This is currently an early-access feature and is expected to reach general availability in a future release. CNFs can now operate as provider edge nodes, supporting label-based forwarding and applying policies based on MPLS labels. This allows service providers to extend existing MPLS architectures into Kubernetes environments without requiring major redesigns. It also provides a path for replacing legacy systems with cloud-native alternatives while maintaining familiar networking constructs. UDP and TCP Application Load Balancing Release 2.3 expanded BNK support for high-performance UDP and TCP application load balancing, endtending traffic management capabilities beyond HTTP-based workloads. This enhancement enables support for a broader range of cloud-native applications, AI infrastructure traffic and telco protocols that rely on Layer 4 traffic patterns. Traffic can be intelligently balanced across services both inside and outside the Kubernetes cluster, which is critical for hybrid deployments and incremental modernization efforts. BNK deployed on NVIDIA DPUs has supported hardware offload capabilities since the Limited Availability (LA) release. With Release 2.3, advanced AI traffic optimization capabilities are now brought to General Availability (GA), including Intelligent AI Load Balancing, LLM Routing integration, Semantic Caching, and Token Governance. These capabilities help optimize AI inference traffic, improve GPU utilization, reduce latency, and enable more intelligent traffic steering across modern AI infrastructure environments. This enhancement is especially important for service providers and large enterprises operating mixed environments where traditional applications, AI workloads, and new cloud-native services must coexist. Organizations can modernize incrementally by introducing cloud-native components without requiring immediate architectural redesigns or disrupting existing applications. Subscriber-Aware Policy Enforcement Subscriber awareness remains a core requirement for service providers. Release 2.3 enhances Policy Enforcement Manager (PEM) with GX interface integration, enabling real-time policy enforcement based on subscriber data. This allows traffic to be classified and controlled dynamically, supporting use cases such as QoS enforcement, traffic shaping, and content filtering. It also enables compliance with regulatory requirements and opens new opportunities for service differentiation. Improved Observability and Aggregated Insights As CNFs scale, visibility becomes more complex. Earlier approaches relied on per-pod metrics, which made it difficult to build a unified view of the system. Release 2.3 enhances PEM by introducing aggregation through TODA, allowing statistics and session data to be collected and presented as a single entity. Enhancements to MRFDB and PEM reporting further improve visibility into subscriber sessions and traffic behavior, giving operators a more complete and centralized view of network activity. Building on this foundation, release 2.3 expands PEM capabilities with subscriber-aware policy enforcement. By integrating external policy systems and classification services, CNFs can now correlate traffic with subscriber identity and apply policies dynamically. This provides deeper insight into how individual subscribers and applications behave on the network, enabling more precise control and improved operational awareness. Additional DNS visibility enhancements, such as adding dig support into netkvest, further strengthen troubleshooting capabilities. By enabling more detailed DNS query inspection and response analysis, operators can quickly diagnose resolution issues and better understand traffic patterns tied to application behavior. Together, these enhancements move CNFs beyond basic monitoring. They provide a richer, more contextual understanding of traffic, subscribers, and services, which simplifies operations and enables faster troubleshooting in large-scale environments. DNS and Traffic Behavior Enhancements Release 2.3 includes improvements that address real-world network behavior, particularly in how DNS and transport protocols operate at scale. One example is the handling of DNS requests during certain scenarios. Instead of silently dropping traffic, CNFs can now return NXDOMAIN responses, preventing upstream systems from interpreting the lack of response as a service failure. This improves reliability and ensures better interoperability with external DNS resolvers in distributed environments. In addition, support for BBRv2 congestion control improves TCP performance in challenging conditions. It provides better fairness across flows and adapts more effectively to latency and packet loss, improving overall user experience in mobile and distributed networks. Extending to Multi-Region Traffic Management Release 2.3 continues to expand DNS capabilities with early access support for Global Server Load Balancing, enabling traffic distribution across multiple locations such as data centers and cloud environments. This represents an important step toward multi-region and hybrid architectures, where applications are no longer tied to a single cluster or deployment location. Building on this, the introduction of GSLB Sync Groups improves how configurations are managed across distributed deployments. Within a sync group, one instance is designated as the sync agent and is responsible for propagating configuration changes to other members. This approach ensures consistency across environments while preventing conflicting updates and reducing the risk of synchronization issues. Release 2.3 also begins to introduce more intelligent traffic steering with topology-based load balancing. This capability allows traffic to be directed based on user-defined parameters such as location or network proximity. As a result, operators can optimize application delivery by sending users to the most appropriate endpoint, improving latency and overall service quality. Together, these enhancements move CNFs closer to providing a fully cloud-native, globally distributed traffic management solution that aligns with modern application deployment patterns. What is new in BNK 2.3 for AI use cases? BNK 2.3.0 hardens and productizes key AI traffic optimization capabilities previously delivered through Early Access or iRules-based implementations, bringing them into native code for production-scale AI deployments while further expanding support for next-generation accelerated AI infrastructure. AI Traffic Optimization: Semantic AI Model Caching (GA) Reduces redundant GPU compute for similar or repeated prompts, improving token economics while lowering latency and increasing GPU efficiency for inference workloads. Intelligent AI Load Balancing (GA) Dynamically distributes AI inference traffic using real-time telemetry and infrastructure awareness to optimize GPU utilization, reduce queue bottlenecks, and improve response times. LLM Routing Integration (GA) Enables intelligent routing of requests across different LLMs and AI services based on policies such as cost, performance, model specialization, or operational requirements. Token Governance (GA) Provides visibility and control over token consumption with capabilities such as token monitoring, accounting, and rate limiting to help customers better manage AI infrastructure costs and tenant usage policies. AI Hardware Support Expansion: ConnectX-8 SuperNIC Support at x86 systems (GA) Expands BNK’s accelerated infrastructure support to next-generation NVIDIA networking platforms, enabling customers who are not yet ready to adopt DPUs to further optimize CPU efficiency and AI traffic processing performance. Beside CX-8, BNK 2.3.0 also supports CX-7s and BlueField-3 running in SuperNIC mode. BNK for Telco and Modern Applications Modern environments rarely consist of purely cloud-native applications. Most organizations are running a mix of legacy protocols, telco workloads, and newer microservices. Release 2.3 addresses this reality directly. One of the most important additions to this release is TCP and UDP load balancing. This extends BNK beyond HTTP-based traffic management and enables support for telco protocols and other non-HTTP workloads. It also allows traffic to be balanced both inside and outside the Kubernetes cluster, which is critical for hybrid architectures and phased migrations This capability reflects a broader shift in BNK. It is no longer just an ingress layer. It is evolving into a unified traffic management platform that can handle diverse protocols and application types without forcing architectural changes. For service providers, this means they can modernize incrementally. Existing applications can continue to operate while new components are introduced in Kubernetes. For enterprise environments, it provides a consistent way to manage traffic across distributed services without introducing additional tools or complexity. What’s new in BNK 2.3 for modern apps & telcos? Multi-Tenant Debugging (RBAC-secured Debug API) We added a new Debug-API that uses the Kubernetes RBAC (Role-Based Access Control) to allow running debug commands according to defined permissions. The administrator can assign rules (Administrator, Operator, Tenant) to users. This allow or deny users to run debug commands according to their rule and creates separation between Namespace Tenants to limit the user access to their Namespace only. Grafana Sample Dashboard Template We created a detailed instruction document that describes the setup of Prometheus and Grafana for Multi Tenancy support. With that the customer can configure his own Dashboards to display the tenant stats and separate the display so each tenant can view its own. The customer can create its own Dashboards based on the samples. Each Namespace Tenant can view its own statistics only. Gateway API Conformance Improvements BNK’s development has largely been more focused on adding functionality to expand the Gateway API than on conformance with existing use cases. Gateway API Security Enhancement (Namespace-based FW) When working in Kubernetes, serving to isolate tenancy using namespace it is valuable to be able to create namespace-based firewall rules. With our isolation of tenancy, customers do not want to have separate tools for east-west (Kubernetes network policies) and north-south (firewall); we unify their security controls. Gateway API: Load Balancing External Resources BNK’s Gateway API routes are being extended to specifically cover load balancing to external endpoints. This can either leverage the Kubernetes concept of an “endpoint slice” or using the F5 “F5pool” CRD. Because external endpoints aren’t probed by Kubernetes, BIG-IP monitors are enabled for these Gateway routes. TMOS Integration: DNS (aka GTM/GSLB) Coordinate external DNS (GTM/GSLB) BIG-IP with BNK; publish/remove ingress VIPs as BIG-IP TMOS DNS Service WideIP pool members with automatic WideIP pool member enable/disable based on K8s service availability. This feature allows multi-tiered deployments with global service availability. BNK Integration with Openshift Platform Previously, the only Openshift-specific functionality in BNK was support for the OVN CNI (via Multiple External Gateways (MEG) feature). With this new work, FLO will support being used via an Openshift operator hub (initially private instance, until business/partner items worked out) and Openshift routes are translated to BNK Gateway objects. Gateway API: IPAM Support (Infoblox) Previously, we integrated the F5 IPAM controller with BNK for Gateway API. That IPAM now can leverage Infoblox, which is used by BNPP (and was a feature of the original IPAM controller, as leveraged by CIS). Proxy Protocol Support Our customer uses proxy protocol with BIG-IP to serve their applications. To migrate to BNK, they required similar support. Under the covers, this is enabled with an iRule, but that iRule is hidden from the customer. Active-Standby Interface Bonding Currently, having the node use LACP and applications like BNK use DPDK separately causes problems. This method is meant to allow the Linux host to control active links, leveraging a “floating MAC address”. Limited Availability/EA: IBM Cloud ROKS Support This initiative prioritizes support in IBM cloud. The feature is LA in this release and Future releases will GA the use of IBM Cloud with ROKS. Early Access: BNK Support for AWS/EKS Early access support for AWS/EKS – this should be used for F5-led demonstration, not for direct-to-customer deployment. First step toward Public Cloud support in AWS/EKS. Frequently asked questions These questions represent the most common queries architects and operators ask when evaluating BIG-IP Cloud-Native Network Functions 2.3. Q: What is new in BIG-IP Cloud-Native Network Functions 2.3? A: BIG-IP CNF 2.3 adds MPLS provider edge support (early access), native UDP/TCP load balancing, DPU-accelerated data plane offload on NVIDIA BlueField, subscriber-aware PEM with Gx integration, VRF-aware AFM policies, GSLB with Sync Groups, congestion control, and crash diagnostics that operate without host-level Kubernetes access. Q: What CPU savings does BNK on NVIDIA BlueField DPU deliver? A: Validated testing (Tolly Report #226104, February 2026) showed approximately 80% host CPU reduction, 40% more output tokens per second versus HAProxy on Llama 70B, and 61% faster time to first token (TTFT). These results reflect BNK offloading data plane processing from the host CPU to the BlueField DPU, freeing the host compute for application workloads. Q: Does BIG-IP CNF 2.3 support protocols beyond HTTP and HTTPS? A: Yes. Release 2.3 adds native UDP and TCP load balancing to both CNFs and BNK, extending traffic management beyond HTTP. This supports telco protocols such as GTP-U, Diameter, and RADIUS, with the ability to balance traffic across services inside and outside the Kubernetes cluster.APIs First: Why AI Systems Are Still API Systems
AI and APIs Over the past several years, the industry has seen an explosion of interest in large language models and AI driven applications. Much of the discussion has focused on the models themselves: their size, their capabilities, and their apparent ability to reason, summarize, and generate content. In the process, it is easy to overlook a more fundamental reality. Modern AI systems are still API systems. Despite new abstractions and new terminology, the underlying mechanics of AI applications remain familiar. Requests are sent, responses are returned. Identities are authenticated, authorization decisions are made, data is retrieved, and actions are executed. These interactions happen over APIs, and the reliability, security, and scalability of AI systems are constrained by the same architectural principles that have always governed distributed systems. What is new is not the presence of APIs, but the nature of the consumer calling them. In traditional systems, API consumers are deterministic. They are code written by engineers who read the documentation and invoke endpoints in predictable ways. In AI systems, the consumer is increasingly a model, a probabilistic component that infers behavior from schemas, chains calls dynamically, and produces traffic patterns that were not explicitly programmed. That single shift is what makes every downstream concern in this series, including MCP design, token budgets, authorization, and operations, behave differently than in traditional API platforms. Understanding this relationship is critical, not only for building AI systems, but for operating and securing them in production. AI Applications as API Orchestration Platforms At a high level, an AI application is best understood not as a single model invocation, but as an orchestration layer that coordinates multiple API interactions. A typical request may involve: A client calling an application API Authentication and authorization checks Retrieval of contextual data from internal or external services One or more calls to a model inference endpoint Follow-on tool or service calls triggered by the model’s output Aggregation and formatting of the final response From an architectural perspective, this is not fundamentally different from any other multi-service application. Routing, observability, traffic management, and trust boundaries remain as relevant here as in any traditional platform. What has changed is that the decision logic, meaning when to call which service and with what parameters, is increasingly driven by model output rather than static application code. That shift does not eliminate APIs. It increases their importance. AI Application as an Orchestration Platform Models as API Endpoints, Not Black Boxes In production environments, models are consumed almost exclusively through APIs. Whether hosted by a third party or deployed internally, a model is exposed as an endpoint that accepts structured input and returns structured output. Treating models as API endpoints clarifies several important points. A model does not "see" your system. It receives a request payload, processes it, and returns a response. Everything the model knows about your environment arrives through an API boundary. What distinguishes model endpoints from conventional APIs is not their interface, but their operational profile. Responses are frequently streamed rather than returned as a single payload, which changes how load balancers, proxies, and timeouts behave. Payload sizes are highly variable, with both requests and responses ranging from a few hundred bytes to many megabytes depending on context and output length. Rate limits are often expressed in tokens per minute rather than requests per second, which complicates capacity planning and quota enforcement. Self-hosted models introduce additional concerns around GPU scheduling, cold start latency, and memory pressure that do not exist for traditional stateless services. These characteristics do not change the fundamental nature of a model as an API endpoint. They do mean that the operational assumptions built into the existing API infrastructure may not hold without adjustment. Tools, Retrieval, and Data Access Are Still APIs As AI systems evolve beyond simple prompt-and-response interactions, they increasingly rely on tools: databases, search systems, ticketing platforms, code repositories, and internal business services. These tools are almost always accessed through APIs. Retrieval-augmented generation, for example, is often described as a novel AI pattern. In practice, it is a sequence of API calls: An embedding service is called to encode a query A vector database is queried for relevant results A document store is accessed to retrieve source material The retrieved data is passed to the model as context Each step carries the usual concerns: latency, authorization, data exposure, and error handling. The model may influence when these calls occur, but it does not change their fundamental nature. Why API Design Matters More in AI Systems If AI systems are built on APIs, why do they feel harder to manage? The answer lies in amplification. Model-driven systems tend to: Chain API calls dynamically Surface data in ways developers did not explicitly anticipate Expand the blast radius of a misconfigured authorization Increase sensitivity to payload size and response shape A poorly designed API that returns excessive data may be tolerable in a traditional application. In an AI system, that same response can overflow context limits, leak sensitive information into prompts, or cascade into additional unintended tool calls. This amplification rarely stays within a single domain. A schema decision that looks like an application concern becomes a traffic and routing concern when responses grow unpredictably, and an authorization concern when a model uses that response to drive the next call. Design choices that were once contained within one team’s scope now propagate across the stack. In this sense, AI does not introduce entirely new architectural risks. It magnifies existing ones. Introducing MCP as an API Coordination Layer As models gain the ability to invoke tools directly, the need for consistent, structured access to APIs becomes more pressing. This is where Model Context Protocol (MCP) enters the picture. At a conceptual level, MCP does not replace APIs. It standardizes how AI systems discover, describe, and invoke API-backed tools. MCP servers typically sit in front of existing services, exposing them in a model-friendly way while relying on the same underlying API infrastructure. Seen through this lens, MCP is not a departure from established architecture patterns. It is an adaptation, one that acknowledges models as active participants in API-driven systems rather than passive consumers of text. But it is also the introduction of a new coordination layer, a tool plane, with its own operational, network, and security properties that do not map cleanly onto the API layer beneath it. The rest of this series examines what that means for the systems you build, run, and secure. Looking Ahead If AI systems are still API systems, then the familiar disciplines of API architecture, security, and operations remain essential. What changes is where decisions are made, how data flows, and how quickly small design flaws can propagate. The next article looks more closely at MCP itself, examining how it standardizes tool access on top of APIs and why treating it as a tool plane helps clarify both its power and its risks. From there, the series turns to tokens as a first-class design constraint that shapes tool schemas, response shaping, and traffic behavior. The fourth article addresses authorization and the security implications of letting models invoke tools directly, including identity, delegation, and the expanded blast radius MCP introduces. The series closes with a look at operating MCP-enabled systems in production, where reliability, cost, and safety have to be enforced rather than assumed. Resources: Article Series: MCP, APIs, and Tokens: Building and Securing the Tool Plane of AI Systems (Intro) MCP, APIs, and Tokens (Part 1 - APIs First: Why AI Systems Are Still API Systems) MCP, APIs, and Tokens (Part 2 - MCP as the Tool Plane: Standardizing Access Across APIs) MCP, APIs, and Tokens (Part 3 - Tokens as a Design Constraint for MCP and APIs) MCP, APIs, and Tokens (Part 4 - Securing the Tool Plane: MCP, APIs, and Authorization) MCP, APIs, and Tokens (Part 5 - Designing for the Inference Track: Safe, Scalable MCP Systems)
