Tech Trends and Predictions That Will Shape 2023

There are thousands of stories of invention, innovation, and discovery playing out across the technology industry at this exact moment. They are real but largely unseen until an event – a data breach, a cloud outage, a social movement – brings them to our attention.

The cloud and AI are no longer frontiers. The digital economy is the new tech green space. Nearly 8 out of every ten companies have experienced at least one cloud data breach. The transition to net-zero will be as disruptive as the industrial revolution.

Businesses need to separate the trends from the hype to capture competitive value. That’s what drives my annual ritual of making tech predictions for our next orbit around the sun. The future is beginning to take shape, and here are my predictions for tech trends coming in the year ahead.

Trend #1

An Accelerating Attack Surface Will Demand More and Future-Proof Security Innovations

In the billion-dollar race to protect, detect, and respond to an expanding attack surface, we will see risk management melding with business innovation capabilities. Compromised credentials, misconfigurations, and malicious and inadvertent misuse of resources have been at the center of security discussions.

We see the conversation broadening to applications and their dependencies, as well as shadow IT which goes far beyond mismanaged devices. Exposure for businesses could exponentially increase due to unvetted development projects and as organizations innovate to meet the demand for always-on, digital access to products and services.

◉ Application and API Security (CNAPP)

As modern cloud-native applications are becoming drivers of business, protecting the underlying application environment is critical. In 2023, developers will get more and more support from various tools that help speed up development cycles and allow them to better manage and secure distributed application architectures with an emphasis on delivering exceptional, secure digital experiences. We will also see continued movement toward tools that allow developers, site reliability engineers and security experts to collaborate more seamlessly on these outcomes.

◉ Quantum Cryptography

Transmitting keys poses a fundamental risk to security, as keys can be harvested and decrypted later. While Post Quantum Cryptography (PQC) is a potential stop-gap solution, it’s unclear if PQC schemes could be broken in the future. Quantum Key Distribution (QKD) is poised to be particularly impactful because it avoids distribution of the keys over an insecure channel. In 2023, in preparation for a post-quantum world, we will see a macrotrend emerge with adoption of QKD in datacenters, IoT, autonomous systems, and 6G.

Trend #2

Experience Economy Solutions Will Deliver Actionable Business Insights and Performance

The digital experience of customers and end users is now a primary driver of business success, and “experience” will emerge as a key new KPI in the months ahead. This will change the playing field dramatically.

To survive and thrive, companies need to be able to tie data insights derived from normal IT operations directly to business outcomes or risk being overtaken by more innovative competitors. Distributed tracing will soon become a currency of business performance, and every technology investment will need to be set against observability standards and practices – from cloud, to core, to edge.

◉ Full-Stack Observability Tied to Business Outcomes

A significant problem with monitoring has always been too much data with too little context and business correlation. The evolution of application monitoring toward full stack observability will increasingly provide a view relative to business context. When applied systematically, this can dramatically speed up response and optimize business operations in real time. In 2023, business context will become widely recognized as an integral part of monitoring and visibility outcomes.

◉ Traces and OpenTelemetry

In the year ahead, there will be a significant shift toward the open-source ability to grab information from multiple domains that were previously siloed and then develop modern applications that rely on distributed tracing embedded in the actual experience. OpenTelemetry will become the leading open-source standard behind how IT teams consume data to enable observability over the IT stack from the network and infrastructure to applications and the internet.

◉ Edge Native Application Development Frameworks

As edge devices become smarter, and process, manage, and drive insights closer to the user, there is growing need for edge-native application ecosystems. In 2023, we will see growing adoption of application development frameworks for the edge replete with new data management, compliance and security APIs coupled with novel AI/ML toolchains. This is the beginning of a world where the edge will be operated by horizontal software platforms – groups of small, generic computers scaled to deployment needs and consumed as a service.

Trend #3

The New Phase of Digital Transformation Will Be Led by Smart Connectivity and Networks

Resilient and agile supply chains can be a weak link or great competitive advantage. Predictive technologies move us away from using isolated data analysis to real-time decision making. Multicloud models are designed to be elastic and scalable to complex regulatory and service-level requirements.

Smart connectivity and networks are at the center of it all. They’re not just about optimizing resources – they can potentially help organizations anticipate and respond to global trade issues, workforce changes, and other unexpected events. Next year, 2023, will be a turning point in the deployment of game-changing networking and connectivity solutions on which future engineering marvels will be built.

◉ IoT/Supply Chain Resiliency

Enterprises and logistics providers will increasingly utilize IoT to bring greater visibility into their supply chains in 2023. IoT and other technologies will not only play a larger role in bringing better resiliency and efficiency into supply chains but can also help to improve IT/OT network management. As a result, organizations will start to reconfigure supply chains around predictive and prescriptive models including smart contracts and distributed ledgers. This is a major transition toward more sustainable business practices and circular supply chains.

◉ Predictive Networks

In the year ahead, the network will become more experience-centric with increasing capabilities to predict end user experience issues and provide problem-solving options. Companies will increasingly access predictive technologies in integrated, easy-to-use SaaS offers. This represents an important step toward a future where connectivity is powered by self-healing networks that can learn, predict, and plan. Predictive networks will be powered by the same predictive analytics that are gathered from myriad telemetry sources.

◉ Multicloud Realignment

As deglobalization and issues around data sovereignty accelerate, in the year ahead we will see a discernible shift in how companies leverage multicloud architectures. While 89% of enterprises are adopting a multicloud strategy for a variety of reasons (geopolitical, technical, provider diversification), the benefits also come with additional complexity in connecting, securing, and observing a multicloud environment. We will see continued movement toward new multicloud frameworks such as Sovereign Clouds, Local Zone Clouds, Zero-Carbon Clouds, and other novel cloud offerings. This will create a path toward more private and edge cloud applications and services ushering in a new multicloud operating model.

Trend #4

Responsible Innovation Will Move Fast Toward Building a Better, More Inclusive Future for All

Organizations are expected to put their good intentions into action – being purpose-driven is now a corporate requirement. Trust in our institutions and in companies has been tested over the last few years. This has brought us to an inflection point, and we are on the edge of generational change that will become evident through technology in 2023.

Ultimately, organizations will have to define a purpose that goes beyond profitability. While there have arguably been benefactors of the collapse of trust, the new scope of innovation is bending fast toward public good – with responsibility, sustainability, equity and inclusion as guiding themes.

◉ Hybrid Work Equity and Inclusion

Fostering a culture of accessibility-first thinking and embedding universal design principles with assistive technologies will emerge in 2023 as defining principles for development of collaboration products and features. This is the next phase of hybrid work where prioritizing equitable, inclusive experiences can help drive happier and more productive workforces. In 2023, we will also see the use of natural language processing (NLP) and AI/ML in new and innovative ways to deliver these solutions.

◉ Sustainability and the Journey to Net Zero

Net zero will drive common standards to meet sustainability goals with advancements in Power Over Ethernet (PoE) design and hardware to transform data centers for a more sustainable future. Networking and APIs will become more advanced within data center platform management to monitor, track, and change the use of energy. IT vendors and equipment partners will be more transparent in their reuse of hardware (circularity) to move the needle with the sustainability processes.

◉ Responsible AI

In 2023, the ability of rogue individuals and organizations to use artificial intelligence for unethical or socially destructive objectives will continue to grow. Industry, governments, academia, and NGOs will come together to begin hammering out a framework for governing AI in an ethical and responsible manner to mitigate potential harm. This framework will be based on principles such as transparency, fairness, accountability, privacy, security, and reliability and will be applied in contexts such as model creation and the selection of training data for AI systems.

As we look to the year ahead, we see a transformation in how applications, connectivity, and security are delivered and consumed. We see an immersive future that is “sustainable by default,” requiring new technologies built with new processes and in service to new business models. We see exceptional, reliable digital experiences as the gold standard of business success.

No matter how extensive or complex the advances, there’s no greater risk than standing still. The winners in 2023 will be those armed with the right tools – and the courage – to break down organizational silos across domains and disciplines and work together without limits to affect real and lasting change.

Source: cisco.com

Continue reading

Cisco Secure Cloud Analytics – What’s New

Nowadays, “cybersecurity” is the buzzword du jour, infiltrating every organization, invited or not. Furthermore, this is the case around the world, where an increasing proportion of all services now have an online presence, prompting businesses to reconsider the security of their systems. This, however, is not news to Cisco, as we anticipated it and were prepared to serve and assist clients worldwide.

Secure Cloud Analytics, part of the Cisco Threat, Detection, and Response (TD&R) portfolio, is an industry-leading tool for tackling core Network Detection and Response (NDR) use cases. These workflows focus primarily on threat detection and how security teams may recognize the most critical issues around hunting and forensic investigations to improve their mean-time-to-respond.

Over the last year, the product team worked tirelessly to strengthen the NDR offering. New telemetry sources, more advanced detections, and observations supplement the context of essential infrastructure aspects as well as usability and interoperability improvements. Additionally, the long-awaited solution Cisco Telemetry Broker is now available, providing a richer SecOps experience across the product.

MITRE ATT&CK framework alerting capabilities

As part of our innovation story on alerting capabilities, Secure Cloud Analytics now features new detections tied to the MITRE ATT&CK framework such as Worm Propagation, Suspicious User Agent, and Azure OAuth Bypass.

Additionally, various new roles and observations were added to the Secure Cloud Analytics to improve and change user alerts, that are foundational pieces of our detections. Alerts now include a direct link to AWS’ assets and their VPC, as well as direct access to Azure Security Groups, enabling further investigation capabilities through simplified workflows. In addition, the Public Cloud Providers are now included in coverage reports that provide a gap analysis to determine which accounts are covered. Alert Details offers new device information, such as host names, subnets, and role metrics that emphasize detection techniques. To better configure alerts, we are adding telemetry to gain contextual reference on their priority. Furthermore, the ingest process has grown more robust due to data from the Talos intelligence feed and ISE.

NDR: A Force Multiplier to Cisco XDR Strategy

The highly anticipated SecureX integration is now available in a single click, with no API credentials required and smooth interaction between the two platforms. Most importantly, Secure Cloud Analytics alerts may now be configured to automatically publish as incidents to the SecureX Incident Manager. The Talos Intelligence Watchlist Hits Alert is on by default due to its prominence among the many alert types.

Among other enhancements to graphs and visualizations, the Encrypted Traffic widget allows for an hourly breakdown of data. Simultaneously, the Device Report contains traffic data for a specific timestamp, which may be downloaded as a CSV. Furthermore, the Event Viewer now displays bi-directional session traffic to provide even more context to Secure Cloud Analytics flows, as well as additional columns to help with telemetry log comprehension: Cloud Account, Cloud Region, Cloud VPC, Sensor and Exporter.

New Sensor Data to Quickly Detect and Hunt Threats

On-premises sensors now provide additional telemetry on the overview page and a dedicated page where users can look further into the telemetry flowing through them in Sensor Health. To optimize the Secure Cloud Analytics deployment and improve the user experience, sensors may now be deleted from the interface.

Regarding telemetry, Cisco Telemetry Broker can now serve as a sensor in Secure Cloud Analytics, so users can identify and respond to threats faster with additional context sent to Secure Cloud Analytics. In addition, there will soon be support for other telemetry types besides IPFIX and NetFlow.

As we can see from the vast number of new additions to Secure Cloud Analytics, the product team has been working hard to understand the latest market trends, listen to the customers’ requests, and build one of the finest SaaS products in the NDR industry segment. The efforts strongly underline how Secure Cloud Analytics can solve some of the most important challenges in the NDR space around visibility, fidelity of alerts and deployment complexity by providing a cloud hosted platform that can offer insights on-premise and on cloud environments simultaneously from the same dashboard.

Source: cisco.com

Continue reading

Making private 5G interconnect easy to configure, simple to operate, and widely adopted

1. Introduction

This is the follow up blog to an earlier post titled “scaling the adoption of private cellular networks” where the challenges of how to scale interconnect between private 3GPP networks are described. Compared to the current inter-network signaling that serves around 800 public cellular operators, there are forecasts of a 1000 fold increase in the number of private cellular networks. Critically, each private network may experience perhaps a thousandth of the signaling load of a conventional public carrier network.

The full potential of 5G will only be harnessed if the scalable deployment of private 5G solutions can be simplified. The 5G DRIVE (Diversified oRAN Integration & Vendor Evaluation) project led by Virgin Media O2 and part-funded by the UK Government’s Department for Culture Media and Sport (DCMS), Cisco and co-partners is targeted at defining the use of the new 5G Security Edge Protection Proxy (SEPP) roaming interface to connect public and private 5G networks. How best to integrate private 3GPP Non-Public Networks with established public cellular networks, affordably, securely and at scale is a problem that Cisco is invested in solving.

In this post we share details of a recent demonstration Cisco gave to UK DCMS and other 5G DRIVE partners. The demonstration highlights an approach that may facilitate the simplification of 5G roaming interconnect with private wireless networks.

2. Evolution of inter-carrier signaling

The first cellular networks were interconnected using the same SS7 based signaling used on the public switched telephone network. The 2G cellular standard defines enhancements to SS7 messages. These enhancements support concepts of mobility as well as the newly introduced short message service. The introduction of 4G/LTE saw the introduction of IP based Diameter signaling between carrier networks. However, the structure of the SS7-defined exchanges was preserved to facilitate the interworking with earlier systems. Importantly, these Diameter-based systems are responsible for transporting the inter-carrier roaming signaling and not the roaming data used by the end-users. This roaming data can either be tunneled back to the home network or routed locally by the visited access network.

Now, 5G sees the most significant change in how to carry signaling between networks since the inception of cellular. 5G defines a “service based architecture” (SBA) that avoids strict signaling hierarchies. Instead, SBA allows signaling consumers to communicate with different signaling producers. SBA defines the use of RESTful APIs transported using HTTP2 defined methods like GET, POST and PATCH. These APIs are more familiar to web developers compared to the telco-focused SS7 and Diameter.

As described in the earlier post, the GSM Association is responsible for the services and solutions that underpin public roaming systems. This enables subscribers to experience seamless roaming across the world. As expected, GSMA is currently enhancing these services and solutions to be able to interconnect 5G Systems and enable users to seamlessly roam onto 5G public cellular systems using SBA-defined interfaces.

Just like in earlier Gs, the roaming signaling defined in 5G architecture is bidirectional. HTTP2 Request messages originate from both the visited network and the home network. These are then responded to by the other party, as illustrated below. The signaling transits the IPX network which is a private IP backbone used between public cellular operators. The IPX is isolated from the public Internet with security rules defined to prevent unauthorized access to/from it.

The figure above illustrates that each operator is responsible for their own perimeter security including configuration of firewalls and border gateways. GSMA defines procedures for exchanging IP address information for all operator nodes that connect to the IPX in its permanent reference document (PRD) IR.21. Operators configure firewall rules using this information to ensure that only signaling connections originating from registered IP addresses are permitted. The figure below illustrates how this firewall configuration is essential for the visited access network to permit inbound signaling flows from the home network.

3. Securing 5G roaming signaling

The 5G System introduces the Security Edge Protection Proxy (SEPP). The SEPP sits at the perimeter of the 5G public cellular network and is the focus of the 5G DRIVE project.

The N32 interface is defined by 3GPP for use between two SEPPs to ensure the HTTP2 messages can be securely exchanged. First, N32 control signaling is exchanged to establish N32 forwarding. The N32 forwarding operates by taking the HTTP2 Request or Response messages that need to be exchanged between operators and encoding the HTTP2 header frames and data frames in JSON. This JSON is transported in another set of HTTP2 messages which are exchanged between the two SEPPS. 3GPP defines two options for securing signaling between SEPPs. Either TLS protects the communication of these HTTP2 messages using the transport layer, or JSON Web Encryption (JWE) protects the communication at the application layer.

4. Private network challenges

Unlike GSMA, which defines the operation of roaming signaling and the IP backbone between public cellular operators, there is no equivalent system between private 5G networks. This is one of the reasons why 3GPP has defined two separate approaches to deploying private networks, a standalone approach that simply interconnects credential holders with access networks and a public network integrated approach that integrates the private network with the systems of a public cellular operator.

Interestingly, credential holders and private Wi-Fi access networks are increasingly using OpenRoaming (www.openroaming.org) to interconnect. OpenRoaming is a federation of identity providers and access providers targeted at lowering the barriers to adoption of roaming between Wi-Fi credential holders and Wi-Fi hotspot providers. Cisco was responsible for incubating the OpenRoaming system before transferring the operation of the federation to the Wireless Broadband Alliance (www.wballiance.com).

Prior to OpenRoaming, using Wi-Fi while on the go was a hassle. Most of the time, the Wi-Fi operator requires users to accept specific end-user terms and conditions using an intrusive browser pop-up. There were some deployments that delivered a more seamless experience using SIM-based authentication by interconnecting with mobile operators, but the access network configuration was complicated and agreements time consuming. The private enterprise’s InfoSec policies typically prohibit inbound sockets from unknown hosts on the Internet. This means each inbound roaming relationship requires a specific firewall configuration to permit signaling to transition across the enterprise’s perimeter. Without such configuration, the inbound signaling originated by the credential holder will be dropped by the firewall, as illustrated below.

Instead of sharing IP addresses, the OpenRoaming federation makes extensive use of DNS to enable the visited access providers to dynamically discover signaling systems operated by different credential holders. WBA’s Public Key Infrastructure (PKI) issues certificates to OpenRoaming providers. The roaming signaling endpoints authenticate and authorize each other using these certificates. The visited access network establishes a single TLS-secured outbound socket towards the credential holder. All signaling between the providers uses this single socket.

OpenRoaming’s use of DNS and a single secure outbound socket means that the enterprise can configure a single firewall rule for all OpenRoaming signaling originating from their own systems. This significantly simplifies and streamlines the procedures required to enable roaming onto the enterprise’s wireless network.

5. Scaling signaling on the internet

As part of our 5G DRIVE participation, Cisco revisited how “server-initiated signaling” is supported on today’s Internet. The aim was to understand whether future roaming systems can be enhanced with similar capabilities.

The challenge of how to support server push based signaling is well understood. The Internet has seen the deployment of a number of different solutions. 5G signaling is based on HTTP2 and this includes a capability termed Server Sent Events (SSE). SSE is used to send web server initiated events to the client over an already established socket. SSE is designed to reduce the number of client requests and deliver faster web page load times. However, SSE is unsuitable for supporting the reverse direction 5G roaming signaling as this necessitates full bidirectional signaling.

Prior to HTTP2 SSE, other solutions for server initiated signaling focused on polling-based solutions. With short polling, the client continuously sends HTTP requests to enable any server-initiated signaling to be returned to the client. As a consequence, short polling solutions place a significant load on the server which limits their scalability. To reduce this impact, alternative long-polling solutions have been developed. Using long polling, the client opens an HTTP request which then remains open until a server initiated message needs to be returned. As soon as the client receives the server initiated message in the HTTP response, it immediately opens another HTTP request. As with HTTP2 SSE, polling solutions are useful for sending individual events back to the client but are poorly suited when the server sent information is expected to be responded to by the client.

Some perceive the use of polling solutions by web applications as an abuse of the HTTP protocol. Consequently, the WebSockets protocol was specified to enable full two-way communications between clients and servers. The WebSocket connection starts off as an HTTP connection. The client includes an HTTP Upgrade header in the request to change the protocol from HTTP to WebSocket. The HTTP request header also includes a subprotocol field. This is used to indicate the upper layer application intended to be exchanged using the WebSocket.

6. Adapting N32 transport for adoption by private networks

As described above, the existing HTTP2-based SEPP solution takes the HTTP2 Request and Response messages that need to be exchanged between operators and encodes the HTTP2 header frames and data frames in JSON. This approach is adapted to enable a WebSocket-based SEPP to transport the same JSON encoded information. Because WebSocket transport is designed to support bi-directional communications, a single WebSocket is used to transport signaling generated from the visited network and that generated from the home network.

The 3GPP-defined N32 interface between SEPPs is split into a setup phase using control signaling and a forwarding phase. However, the current HTTP2-based system assumes fully decoupled signaling between those exchanges when the SEPP-initiator is in the visited access network and those when the SEPP-initiator is in the home network. This means that bidirectional forwarding requires separate N32 control exchanges. The HTTP2-SEPP uses a HTTP2 POST to a specific “/exchange-capability” path as part of the N32 control exchange.

In contrast, WebSockets enable bi-directional communications over a single socket. This means the visited access network is able to trigger the establishment of bidirectional forwarding. The WebSocket-SEPP signals a specific sub-protocol indicating that N32 service is being requested. In the demonstration, “n32proxy.openroaming.org” was used as an example sub-protocol. Following setup of the WebSocket, the WebSocket SEPP in the visited network sends a JSON object over the WebSocket requesting to establish the N32 forwarding service. The information exchanged in this setup message closely matches that defined in 3GPP N32c messages, including identities, public land mobile network (PLMN) information and security parameters.

After forwarding is established, the conventional HTTP2 SEPP maps the headers and data fields from received HTTP requests and responses into JSON objects that are then transported using HTTP2. The WebSocket SEPP maps the headers and data fields from received HTTP requests and responses into JSON objects that are transported using the WebSocket message syntax.

The WebSocket solution enables private networks to configure simplified firewall rules. All outbound and inbound signaling exchanges between the private 5G access network and the remote credential holder are transported on a single socket. The credential holder’s WebSocket SEPP rewrites the authority of any callBackUris it receives from the visited access network using a SEPP fully qualified domain name (FQDN) suffix. For example, a 5G Access Management Function (AMF) located in a visited network may signal a deregistration callback URI to the home network of:

http://24.208.229.196:7777/namf-callback/v1/imsi-234600000055531/dereg-notify

The WebSocket SEPP located in the home network rewrites the URI to a value that will always resolve to the IP address of the SEPP in the home network, e.g.,

http://24.208.229.196.sepp.operator.com:7777/namf-callback/v1/imsi-234600000055531/dereg-notify

This means that any HTTP requests originating in the credential holder’s network will use the rewritten URI in their HTTP2 Request messages. This ensures that all messages will be routed via the SEPP and the bidirectional N32 forwarding service towards the visited access network.

7. Demonstration of 3GPP roaming interfaces transported over WebSocket

Cisco has built a proof of concept based on the WebSocket approach described above and demonstrated the system to UK DCMS and other 5G DRIVE partners. We adopted a similar approach to how OpenRoaming enables scale by using a cloud federation as the authority to connect access network providers with identity providers. Private 5G systems can then benefit from the same simplification and streamlining of procedures that have accelerated interconnection between private Wi-Fi networks and different credential holders.

A fictitious cellular carrier is assumed to have joined a roaming federation, has been issued a certificate by the federation to use in securing signaling with other federation members and has configured their DNS records to enable their signaling systems to be discoverable from the public Internet. In the demonstration, the signaling systems of this fictitious cellular network are hosted by a cloud provider. A SIM card was provisioned in the 5G User Data Repository (UDR) of the fictitious cellular carrier, identified with a corresponding Mobile Country Code of 234 and a Mobile Network Code of 60. The demonstration focuses on the use case of a subscriber from the fictitious cellular carrier roaming onto the private 5G network operated by “Acme-Industrial” who has similarly joined the roaming federation. Acme-Industrial has configured its local private 5G network to support N32 signaling over WebSockets and operates a firewall that only permits outbound sockets to the Internet.

A UE with the SIM card attempts to register on the local private 5G network. There are a number of ways that the registration can be triggered. In one approach, the federation specifies the use of a Group Identity for Network Selection (GIN) that is broadcast from the private network. As part of the registration, the UE provides its identity to the network. The private 5G network performs a dynamic discovery to identify the home network using the 5G UE identifier.

The private 5G network contacts the UE’s home network through an API-Gateway, establishing a websocket connection.  Then, to keep things efficient and simple, we automated the implementation of logic for the WebSocket-based N32 forwarding using the cloud provider’s function-as-a-service. Finally, the 5G Core Services for the Authentication Server Function (AUSF), Unified Data Management (UDM) and User Data Repository (UDR) are hosted on cloud service’s compute platform.

The proof of concept demonstrates signaling associated with a typical roaming scenario. The different phases are described together with signaling logs from the demo.

◉ A private 5G access network is setup and awaits inbound roamers.

◉ The firewall rules in the private 5G network permit outbound signaling originating from the WebSocket-based SEPP function.

◉ An inbound roaming UE attempts to register with the private network.

◉ The private network recovers the home PLMN from the UE identifier and uses DNS to discover the WebSocket signaling peer.

2022.09.06 18:32:48: [INFO] Waiting for SUPI or SUCI from in-bound roaming UE 

2022.09.06 18:33:41: [INFO] In-bound SUPIorSUCI detected: suci-0-234-60-0000-0-0-0000055531

◉ The WebSocket SEPP establishes a bi-directional N32forwarding service for the home PLMN.

2022.09.06 18:33:41: >>>> {"n32Service": "subscribeRequest", "accessProvider": "ACME-INDUSTRIAL.CISCO:US", "plmnIdList": ["23460"], "3GppSbiTargetRootApiRootSupported": "False", "jwsCipherSuiteList": ["ES256", "none"]} 

2022.09.06 18:33:41: <<<< {"n32Service": "subscribeAccept", "identityProvider": "MNC60MCC234.3GPPBROKER.GB", "3GppSbiTargetRootApiRootSupported": "False", "plmnIdList": ["23460"], "jwsCipherSuite": "none"} 

2022.09.06 18:33:41: [INFO] WebSocket forwarding established and serving suci-0-234-60-0000-0-0-0000055531

◉ The UE registers onto the private network using standard 5G service-based architecture and signalling. The WebSocket transports bi-directional signalling exchanges between the private access network and the home network.

2022.09.06 18:33:43: >>>> {"n32Service": "http2Message", "messageId": "2785087321A", "n32MessageSigned": {"payload": {"reformattedReq": {"requestLine": {":method": "POST", ":path": "/nausf-auth/v1/ue-authentications", ":scheme": "http", ":authority": "172.31.14.141:7777"}, "headers": {"accept": "application/3gppHal+json:application/problem+json", "content-type": "application/json"}, "payload": {"supiOrSuci": "suci-0-234-60-0000-0-0-0000055531", "servingNetworkName": "5G:mnc060.mcc234.3gppnetwork.org"}}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}} 

2022.09.06 18:33:43: <<<< {"n32Service": "http2Message", "messageId": "2785087321A", "n32MessageSigned": {"payload": {"reformattedRsp": {"statusLine": {":status": "201"}, "headers": {"server": "Open5GS v2.4.9", "date": "Tue, 06 Sep 2022 17:33:43 GMT", "content-length": "318", "location": "http://172.31.14.141:7777/nausf-auth/v1/ue-authentications/1", "content-type": "application/3gppHal+json"}, "payload": "{\n\t\"authType\":\t\"5G_AKA\",\n\t\"5gAuthData\":\t{\n\t\t\"rand\":\t\"50d05393a459af7786bb96b38f4ebf12\",\n\t\t\"hxresStar\":\t\"4d332c90989aa127a9c86a96a8978379\",\n\t\t\"autn\":\t\"7ee4c1f4ee8f8000c459a0a203065874\"\n\t},\n\t\"_links\":\t{\n\t\t\"5g-aka\":\t{\n\t\t\t\"href\":\t\"http://172.31.14.141:7777/nausf-auth/v1/ue-authentications/1/5g-aka-confirmation\"\n\t\t}\n\t}\n}"}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}}

◉ The UE uses the resources of the private 5G network.

◉ The home network triggers a de-registration of the UE. This will typically be due to the UE registering on another network, which could be when it returns to coverage of its home network or registers on another federated private 5G network. As we didn’t have a second access network in the demonstration, we triggered a deregistration by withdrawing the subscription of the UE in the UDR. The WebSocket SEPP in the home network translates the network initiated HTTP2 Request to de-register the UE into JSON. The JSON is transported to the private network using the already established WebSocket.

2022.09.06 18:37:53: <<<< {"n32Service": "http2Message", "messageId": "4043366907D", "n32MessageSigned": {"payload": {"reformattedReq": {"requestLine": {":method": "POST", ":path": "/namf-callback/v1/imsi-234600000055531/dereg-notify", ":scheme": "http"}, "headers": {"content-type": "application/json","accept": "application/json,application/problem+json", "host": "192.168.128.145:7777"}, "payload": {"deregReason": "SUBSCRIPTION_WITHDRAWN", "accessType": "3GPP_ACCESS"}}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}}

◉ The WebSocket SEPP in the private 5G network recovers the JSON and re-creates the HTTP2 Request to de-registers the UE. The HTTP2 message is forwarded on to the private 5G Network’s Access and Mobility Management Function (AMF) which processes the message and deregisters the UE. The AMF then signals back to the UDR that the UE has been successfully deregistered.

2022.09.06 18:37:53: >>>> {"n32Service": "http2Message", "messageId": "4043366907D", "n32MessageSigned": {"payload": {"reformattedRsp": {"statusLine": {":status": "204"}, "headers": {"server": "Open5GS v2.4.9", "date": "Tue, 06 Sep 2022 17:37:53 GMT"}, "payload": ""}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}} 

2022.09.06 18:37:53: [INFO] suci-0-234-60-0000-0-0-0000055531 successfully deregistered

◉ The home PLMN no longer serves any UEs in the visited network. The private network automatically triggers the deactivation of the WebSocket-based N32forwarding service towards the home PLMN.

2022.09.06 18:37:53: [INFO] terminating WebSocket forwarding for mnc60.mcc234 

2022.09.06 18:37:53: >>>> {"n32Service": "terminateRequest", "accessProvider": "ACME-INDUSTRIAL.CISCO:US"} 

2022.09.06 18:37:53: <<<< {"n32Service": "terminateAccept", "identityProvider": "MNC60MCC234.3GPPBROKER.GB"}

8. Reducing complexity and increasing scale

Cisco is investing in taking the complexity out of private 5G with its 5G-as-a-service offer. With WBA already reporting that over 1 million private wireless hotspots have embraced OpenRoaming, it is clear that simplifying roaming systems can lead to the transformation of roaming, from serving 100s of public cellular operators towards supporting millions of private 5G networks. Importantly, the WBA Board has committed to expanding the use of OpenRoaming to address alternative wireless technologies used in private networks. As part of this expansion, WBA has exchanged liaison statements with 3GPP regarding facilitating the adoption of roaming onto 3GPP Non Public Networks.

Re-using the newly introduced SEPP functionality to enable new deployments of roaming between public and private networks is a focus of the 5G Drive project. The proof of concept demonstrated by Cisco points to how established public cellular roaming interfaces can be adapted to facilitate adoption between private 5G networks and credential holders.

Cisco looks forward to working with others in WBA and 3GPP to help specify new capabilities that ensure that roaming between private and public cellular networks becomes as easy to configure, as simple to operate, and as widely adopted as traditional Wi-Fi-based OpenRoaming.

Source: cisco.com

Continue reading

Delivering Energy Savings and Sustainability with Cisco and HCL

Deploying sustainable manufacturing practices is tremendously important to most manufacturers in response to a variety of drivers, including stakeholder demands, regulatory mandates, climate concerns, and cost reduction. To make progress, action must take place on the factory floor to address concerns like these:

◉ Is a piece of heavy equipment running inefficiently because it has been run past its recommended hours and needs servicing?

◉ Has a piece of equipment been left running while unattended or not in use?

◉ What is the energy consumption across various industrial control systems, HVAC, and lighting on the plant floor?

Identifying potential areas of energy waste on the factory floor in a timely manner requires access to the underlying data, data analytics that derive insights from that data, and a dashboard that provides a single view of notifications and status on KPIs. After all, as the saying goes, “You can’t manage what you can’t measure.”

In response, Cisco — a leader in industrial, IOT networking — and HCLTech (HCL) — a leader in energy management solutions — have joined forces to develop an end-to-end digital sustainability solution leveraging existing products, including HCL’s Net-Zero Intelligent Operations platform (NIO), Cisco IOT gateways powered by the Cisco IOx application hosting environment, and IOx-enabled Cisco network devices. That solution won the 2022 Cisco Global Digital Sustainability Award.

HCL Net Zero Intelligent Operations (NIO) Platform

NIO is a Greenhouse Gas (GHG) emission management solution that helps companies become more sustainable and cost and energy efficient to reduce their carbon emissions and contribute to their net zero goals. NIO presents real-time energy consumption insights and analytics using baselined parameters from all critical energy consumption points originating, for example, in workspaces and on factory floors. This includes calculating, reporting, and identifying emission optimization potential for devices drawing power in a factory or building.

Of course, to provide these insights requires real time access to data from various sources. NIO is a vendor agnostic platform that tightly integrates with the edge data management layer through APIs.

Figure 1: Data Management Layer

Data management layer with the HCL ZIP application and Cisco IoT gateways

As shown in Figure 1, the edge data management portion of the Cisco and HCL solution includes the HCL ZIP application hosting environment–running on Cisco IOT gateways that run the Cisco IOx application hosting environment–which communicates with the NIO platform running either in the cloud or on-premises servers.

The HCL ZIP application collects data from different power meters and directly from energy consuming devices like robots and various Computer Numerical Control (CNC) machines such as lathes, routers, grinders and laser cutters or PLC’s. That data is pushed to the NIO platform, which applies analytics and provides insight to the business to help it achieve its sustainability goals.

The HCL ZIP application gains access to this data by running in the Cisco IOx application environment, which combines Cisco IOS and the Linux OS for highly secure networking. IoT applications such as HCL ZIP gain secure connectivity and reliable integration with third-party devices and sensors. In turn, the IOx application environment runs on Cisco all-in-one IoT gateways that provide simple, essential connectivity to various third-party edge devices.

The IoT Gateways are managed centrally through a simple, easy-to-use cloud management tool–the Cisco IoT Operations Dashboard. Using this dashboard, customers can remotely deploy, monitor, and troubleshoot the gateways and applications running on them. The dashboard provides customer insights into network usage and carries out updates remotely without sending anyone onsite. For example, customers can receive automatic alerts when a device on the network goes down so that immediate action can be taken. All of this is done remotely and at scale.

Example use cases

Condition-based maintenance

Many factories have energy meters installed but no power budget management or real time view of how the machines and robots are consuming power. As a simple example, feed motor load can be identified from current monitoring, which can tell if a machine is malfunctioning in either of the following ways:

◉ Consuming power but not producing product (underloading)

◉ Consuming more power than required (overloading)

This information can help inform sustainability goals around energy wasting and carbon emissions.

Improved operational efficiency

In another example, a manufacturer can compare energy consumption across multiple assembly lines or machine usage over a period of time. This practice can help identify optimal working conditions by regulating environmental conditions in systems like HVAC, air ventilators, furnaces, and chillers. This use case can improve plant operational efficiency and save on energy and carbon emission, once again helping a business inform and meet its sustainability goals.

Source: cisco.com

Continue reading

EVPN Myth Buster Series – To lead or follow, where does Cisco stand?

Innovation is one of many characteristics defining industry leadership. Becoming an industry leader requires a company to innovate and find new ways to solve customer problems. Industry leadership is not something that can be created overnight. It takes more than a software release or a list of supported features to cement yourself as a technology thought leader in the networking industry. Over the past several decades, Cisco has demonstrated its leadership in networking by leading technology innovations that meet and exceed customers’ needs and then enabling the adoption of these technologies across organizations driving standardization. This has also led to robust collaborations and interoperability among different vendors for the benefit of the industry as a whole – please refer to Figure 1 Number of RFCs authors per affiliation for the top 30 companies at IETF over the past three decades.

Some examples of such technologies are L3VPN, MPLS, and EVPN. Cisco innovators such as Eric Rosen, Yakov Rekhter, and George Swallow incubated MPLS and L3VPN technologies and then led the standardization effort at the IETF. Furthermore, Cisco innovator, Ali Sajassi incubated EVPN technology and then led the standardization effort at the IETF. A well-adopted standard is like a team sport, and it requires not only participation but also contributions from every member of the team – i.e., from every vendor and provider involved.

Figure 1. Number of RFC authors per affiliation for the top 30 companies at IETF over the past three decades

In the past decade, Cisco has introduced EVPN technology to the networking industry at large and has led the standardization efforts for all the initial RFCs for this technology with the help of several vendors and service providers. Although there are vendors who are true partners and contributors to this technology and its standardization, there are “others” who are neither participants nor contributors but just users of it. One can easily find out who is who by looking at the IETF statistics for EVPN.

These “other” vendors have made claims to be pioneers of cloud networking fabrics driving a standards-based approach, even though they are openly adopting and implementing Cisco-authored RFCs and drafts into their software. These “other” vendors attempt to create the perception of open standards as their core pillar. Cisco has been a long-time innovator with a proven track record of developing IETF drafts to facilitate the implementation of new technologies that are widely adopted by these other vendors (“others”) in the networking industry. Being an industry leader requires Cisco to continue evolving and driving standards to make networks work better – please refer to Figure 2. Chart showing the number of EVPN RFC Primary Authorship, EVPN RFC Authorship, and Working-Group Authorship Affiliation:

Figure 2. Number of EVPN RFC Primary Authorship, EVPN RFC Authorship, and Working-Group Authorship Affiliation

IETF

For most of us, it is widely known the IETF is the premier Internet standards organization. Citing the IETF Standards page:

“Improving existing standards and creating, implementing, and deploying new standards is an ongoing effort. The IETF’s mission is to produce high-quality, relevant technical documents that describe these voluntary standards. IETF working groups are the primary mechanism for the development of IETF specifications and guidelines.”

As EVPN-VXLAN becomes the de facto standard for IP fabrics, Cisco continues to enhance and publish IETF drafts based on the protocols and architectures addressing new requirements and use cases. When Cisco develops the standards and drafts, there is an implementation in mind for the system and its parts, while “others” will choose to follow and implement the RFCs and the drafts without a full understanding of the use cases.

These other vendors will create and leverage feature matrices to fill their gaps and respond to RFPs, citing our documents and acting as if they would know better. Cisco can confidently claim to lead while “others” only follow, while Cisco invents and “others” only adopt.

Figure 3. VXLAN EVPN Industry Contribution

Cisco continues to extend its leadership in promoting open standards, interoperability, and multi-vendor solutions for Cloud Networking technologies.

This series of blogs aimed to provide a deeper understanding of EVPN VXLAN and additions to the IETF drafts implemented for today’s customer deployments.

History of Ethernet VPN (EVPN)

For many years, the need for extending Layer-2 efficiently was a burdensome task. Before the availability of Layer-2 VPNs, sorts of LANE (LAN Emulation) were used to transport Ethernet across distances, or we just plugged two Ethernet domains together via CWDM or DWDM. All these approaches had their pros and cons, but some common challenges remained, the virtualization of the Layer-2 service across a common infrastructure. When MPLS-based Layer-2 VPN rose to prominence, the presence of true Layer-2 VPNs became available, and with this the better use of the underlying transport infrastructure. With VPLS (Virtual Private LAN Service) multipoint-to-multipoint Layer-2 VPNs became affordable and addressed many new use cases. Even though VPLS brought many advantages, the pseudo-wire maintenance, transport dependency, and lack of comprehensive embedded access node redundancy still made it challenging to deploy. While all of this was the truth over a decade ago, around 2012 we embarked on a new chapter of Layer-2 VPNs with the advent of Ethernet VPN in short EVPN. In its essence, EVPN addressed the challenges the more traditional L2VPNs incurred and innovated new schemes in layer-2 address learning to become one of the most successful VPN technologies.

The journey of EVPN as a standard started back in 2010 when Ali Sajassi introduced and presented the very first draft of EVPN (initially called Routed VPLS, draft-sajassi-l2vpn-rvpls-bgp-00.txt, to IETF (Internet Engineering Task Force) in March of 2010. This draft was later merged with another draft by Rahul Aggarwal (from Juniper), draft-raggarwa-mac-vpn-00.txt, because of their synergy, and a new draft was born in October 2010 –  draft-raggarwa-sajassi-l2vpn-evpn-00.txt. This draft became a working group document in February 2012 and became a standard RFC 7432 in February 2015. This is the defacto base RFC for the basic EVPN behavior and its modes and subsequent EVPN RFC builds on top of the groundwork of this RFC.

Around the same time as the main EVPN draft introduction, Cisco introduced other EVPN related drafts such as draft-sajassi-raggarwa-l2vpn-evpn-req-00.txt and draft-sajassi-l2vpn-pbb-evpn-00.txt in October 2010 and March 2011 respectively which became standard in February 2014 and September 2015 respectively.

After the publications of initial EVPN drafts that later became RFCs 7432, 7209, and 7623, in 2013, Cisco published another set of EVPN drafts for Virtualization/VxLAN and for inter-subnet forwarding (L2 and L3 forwarding) that gave EVPN its versatility as it stands today. These drafts later became the standard RFCs 8365 and 9135.

Figure 4. IETF EVPN Timeline

With the based EVPN using MPLS encapsulation celebrated its success in the Service Provider market, for the Data Center an IP-based encapsulation was more suitable. With this, in 2013 the EVPN draft for “overlays” (draft-sd-l2vpn-evpn-overlay) was published, which included the encapsulation of VXLAN and became RFC 8365 in 2018. In order to address the various use cases for the Data Center, a couple of related drafts were filed around the same time. The definition of how to do inter-subnet routing (draft-sajassi-l2vpn-evpn-inter-subnet-forwarding), how we advertise a IP Prefix route in EVPN (draft-rabadan-l2vpn-evpn-prefix-advertisement) or how to interconnect multiple EVPN “overlay” domains with a Data Center Interconnect (draft-rabadan-l2vpn-dci-evpn-overlay). All these drafts from 2013 now being RFCs and define the standard in how EVPN is being used within and between Data Centers.

Figure 5. EVPN RFC for VXLAN and DCI

The realms of standards are often a cabala. Opening this up and sharing some of the histories with the most significant milestones is as important as defining the standards themselves. For more than a decade, Cisco has actively driven the standardization of EVPN and shared this innovation with the networking industry. With over 50 publications to the IETF, Cisco leads the EVPN standardization and is proud of the collaboration with its partnering authors. With the proliferation of EVPN across all of Cisco’s Operating Systems (IOS-XE, IOS-XR, NX-OS) being fully interoperable, the flexibility of the right operational model across deployments in Campus, WAN, Data Center, or Service Provider domains is unmatched.

Source: cisco.com

Continue reading

Simplify the Adoption of Sustainable Technologies in the Workplace with Cisco DNA Center

Supporting sustainable technologies on a campus network is great for the planet and can substantially lower the cost of workplace operations. But adding hundreds of new IoT devices to a campus network can be a heavy lift for IT teams. Let’s take a look at the many innovations that Cisco has made to address sustainable technology, so that supporting a cleaner planet does not become a burden on IT teams.

For organizations, environmental sustainability is the practice of operating without producing a negative impact on the environment. Certainly, you’ve been hearing a lot about environmental sustainability and how IT can help to reduce your organization’s carbon footprint. When it comes to reducing the environmental impact of offices, factories, and warehouses, IT has a very big role to play. Gartner estimates that “By 2025, 75% of CIOs will be responsible for sustainable technology outcomes and 25% of CIOs will have compensation linked to their sustainable technology impact.” (Gartner Top Strategic Technology Trends for 2023: Sustainable Technology, ID G00774132)

Most IT departments will begin their sustainability work by verifying that IT technologies are being sourced from companies with “Net Zero” policies and programs. Cisco has documented all the steps we’ve taken to create a more sustainable solution for your network. Your next step will be to lower your environmental footprint by deploying new sensor technologies within your campus networks for initiatives such as energy efficiency, water usage, recycling, and site optimization. These technologies will be helpful in your sustainability objectives, but they can become a major source of complexity and time drain for IT teams. So, let’s look at some of the more popular technologies and the recent innovations in Cisco networking solutions that can make deploying them much easier.

Sustainable Technology is Coming to your Campus

The reason I can guarantee that you will soon be deploying sustainable technology is that there are substantial financial rewards for lowering your usage of electricity and material goods. Investments in sustainability are good for the planet and good for your bottom line. Sustainable technology, which is a category of smart building technologies, is a framework of networking solutions that enable businesses to achieve their sustainability goals. These goals usually include a reduction in environmental impact (power, water, recycling, and waste disposal), and optimization of office space and physical assets. Typical devices are automatic window shades that close in direct sunlight, water usage sensors, and of course UPoE+ LED lighting powered by Cisco Catalyst 9000 PoE ports and monitored by Cisco DNA Center. These are popular choices because PoE LED lighting can yield large savings quickly without a complex electrical installation, and water usage sensors are an easy way to detect water leaks – which is the most common and most expensive of office accidents.  The industry for smart building technology is diverse, and you will certainly find an IoT device or sensor for just about any project.

Figure 1: Architectures for smart buildings

The diagram in Figure 1 above, shows the many categories of smart building technologies, as well as the infrastructure and applications that manage and operate the solution. Cisco has a great webpage on our portfolio for smart buildings where you read more about the solution. Many of these technologies are complements or expansions to projects that your team already supports, but the impact of sustainable technology on your network will be substantial. There will surely be hundreds of new sensors, meters, and control devices on your campus network. Most of these will require PoE and many will require local application servers. There are three categories of Cisco DNA Center innovations that facilitate supporting these devices: (1) connecting and securing, (2) powering, and (3) software management.

Connecting and Securing New IoT Devices 

I’m sure you’ve heard about Cisco DNA Center AI-Endpoint Analytics. This feature is in the Policy section of Cisco DNA Center, and it automatically identifies all new endpoints that connect to the network using a cloud-based device manufacturers database. Endpoints are then added to the inventory dashboard and checks and authentications are made using deep packet inspection (DPI) and machine learning to authenticate that the device is what it says it is. Each device is given a “Trust Score” between 1 (suspicious) and 10 (trustworthy) and you can view a list of the verifications that each device has passed. During the lifecycle of devices, Cisco DNA Center will continue to monitor device behavior and any anomalies (such as sudden changes in communication protocols) will be flagged for attention. Additionally, Cisco DNA Center can be configured to automatically isolate devices that demonstrate behavior anomalies.

Besides security and posture information, endpoint inventory includes the manufacturer, model, OS type, software version, and other management information. You can even register the device with the manufacturer within Cisco DNA Center, and if a software upgrade is available, you will be advised right inside the dashboard. The comprehensive dashboard gives you everything you need to connect, secure, and manage the many new IoT devices on your network.

Figure 2: AI endpoint analytics aggregates network data to identify endpoints.

Powering IoT Devices and Managing PoE Capacity

As more PoE devices connect to your network, understanding power usage and availability per branch office and per switch will become critical. The PoE Analytics dashboard in Cisco DNA Center gives you quick and easy visibility of your PoE usage everywhere. You can see the status of PoE consumption across your organization: by branch, building, individual switch, or even by type of device. You can view the total power budget available in any switch, as well as what is allocated, remaining, and load. You can verify the actual amount of power being drawn from each device—this is critical since many IoT devices pull more power than their manual indicates. During the lifecycle of these devices, PoE Analytics monitors spikes in power and pushes alerts for any anomaly to the main Cisco DNA Center Assurance dashboard. Any Cisco DNA Center alert can be exported to your ServiceNow (ITSM) or PagerDuty, and PoE alerts are good candidates for immediate attention. The PoE Analytics dashboard in Cisco DNA Center enables you to plan and manage the power of your IoT devices anywhere in your network.

Figure 3: PoE Analytics facilitates managing power for IoT devices

Edge Compute for Device Software

Another challenge you will likely encounter is the performance of the server software that controls these IoT devices. In many cases, this software is located in the cloud, and the time spent managing it will be minimal. However, some of the more complex sensors may recommend that the server software be installed on-premises for improved performance. This requires either a server in your wiring closet or small Raspberry Pi devices distributed around the campus.

Instead of deploying additional hardware on-site, Cisco DNA Center can help you run these IoT applications on your Catalyst 9000 switches. Cisco Application Hosting on Catalyst 9000 series of switches extend the cloud application to the edge of the network enabling data processing closer to the source for much-improved performance of low-power IoT devices. The app hosting framework inside Catalyst 9000 switches enables off-the-shelf Docker apps, running as separate Linux processes, so they do not affect the switch’s IOS XE performance or security. Installing the application has been streamlined with Cisco DNA Center’s App Hosting Automation dashboard. Simply drag and drop the application into the dashboard and it loads into the Cisco DNA Center’s app hosting library. Then choose the switches where you want the application installed and push them out.

Figure 4: Using Cisco DNA Center to install apps on your Catalyst 9000 switches

Deploying smart building technology to meet your company goals for sustainability and cost optimization will be a big trend in 2023. Training your staff on Cisco DNA Center will enable you to manage this new technology while maximizing your IT staff’s productivity.

Source: cisco.com

Continue reading