As we've noticed, almost every time a table with data inside is displayed within Kentik Portal, it invariably takes no time before our users ask for it to be downloadable in a CSV format.
Additionally, AI Advisor very often displays results in a table format, because it is one of the most legible ways for our users to efficiently parse that data.

Hence, we've taught AI Advisor to display a Download CSV action button with any and every data table it displays.
This could be the end of the product announcement, but read on, it gets even more interesting.

Spreadsheets, day in to day out

If you work in the computer or networking industry, you can certainly confirm first hand that one of the most routine tasks we all end up performing every day is some variant of this sequence of actions:

1. Get some data from a SaaS tool
2. Download said data
   1. If you're lucky and the tool has the capability, export to CSV/XLSX
   2. If you're not copy it from the browser into a spreadsheet (comes with the customary prayer that it will format fine through pasting)
3. Massage the data to make it presentable to an audience

Rinse and repeat, all day every day including weekends.

Enter AI Advisor

As we are all making more and more room for AI Advisor to boost productivity, the aforementioned loop gets less taxing, thanks to this new Download CSV button mentioned earlier. Just take a look at the example below where I'm asking AI Advisor to give me a list of the top inbound ASN to my network by traffic:

We could call it a day and close the product announcement here, but I really wanted to make it worth your read here, so bear with for another paragraph, will you?

Cranking it up a notch

As mentioned earlier, there's always some amount of massaging you'll want to do on tabular data before presenting it to someone else.
The previous example is no exception. Right now I'm getting a table with the following columns 1) rank 2) AS Name, 3) Avg Traffic.

What if I wanted to:

• display the ASN registration country in its own column for further filtering, and in a way that's human readable
• add a link on each row to the peeringDB record for each network (arcane knowledge, you can reach the PeeringDB page of any ASN via this URL format: https://peeringdb.com/asn/ )

Let's go.

I know, you're welcome 😉

Not so long ago, we released an update to Kentik Portal's Search Engine that gave it AI Superpowers. Since then, the Search Engine has been able to point users to any screen in Kentik Portal based on any question pertaining to a task they want to perform, such as "Where can I track my IP Transit spend?" or "How can I monitor my backbone link capacity?". In order to deliver this feature we've built an AI module that feeds off a complete SiteMap of the Portal and knows what each module on any URL does, and what its entry pointer in the Knowledge Base is.

We've extended this feature to our beloved AI Advisor for it to gain new abilities, read on.

"AI Advisor, please help!"

Given our ever-increasing product surface, we wanted to make it easier for new users to hit the ground running. Often, someone will make a note of certain portal functionalities during a trial period that they will want to implement later in their deployment of the product, but forget where in the Kentik Portal it exists or how to implement them. This usually results in getting to the outcomes you want slower.

Sometimes, a user will need to dig into how a certain computation is made, or why Kentik Portal is making specific determinations.

This is where this feature shines: on any screen in Kentik Portal, you can now ask AI Advisor to explain to you how a certain screen works, just as how you would ask your Customer Success advisor.
AI Advisor will then fetch the relevant data from the SiteMap, link it to relevant Knowledge Base article and give you a crash course on how the screen you're currently looking at works. Basically, you can ask Kentik to explain how it works. We believe that this will significantly help with the timeliness to answer to our user's question about the product, and more durably unblock them in the pursuit of operating their infrastructure with our platform.

As you will discover in the examples that follow, contrary to a lot of AI Assistants, AI Advisor just does not dump help links on the user. It answers in precise, summarized terms to questions related to functionality and how it works under the hood.

A simple example with Connectivity Costs

As you can see in the screenshot below, AI Advisor now includes the additional step in its reasoning to summon the SiteMap tool

Landing on a screen and asking what it does and how it works is now a trivial operation, for instance on the Connectivity Costs workflow screen:

...leading to a follow-up conversation of how it works:

Another example, this time with Kentik Market Intelligence

Another example, directly taken from the Kentik Market Intelligence page, as it is one of our more niche products - expectedly not all users are fully aware of what marvels it performs

... where a follow-up interaction would most likely be around "How do we establish a score to rank networks against each others", again successfully clarified by AI Advisor

...which begs the follow-up question around the different Retail, Wholesale and Backbone types of scores, for which AI Advisor will even compose an explanatory diagram on the fly:

AI Advisor gets smarter every day, so don't be shy, ask it anything !

These examples are all but a tiny fraction of how AI Advisor can supercharge your life of managing infrastructure -- and we're adding new capabilities to it every day.
This is the simplest, most straightforward way for you to start on the journey to faster results and outcomes from Kentik: next time, right before you contact our amazing Customer Success team of advisors, give AI Advisor a prompt and see what it answers, you may be surprised ;)

To create a more seamless Kentik experience and more tightly integrate Kentik into your network operations workflows, we are pleased to announce Kentik's AI Advisor REST API is now available. This provides programmatic access to AI Advisor investigations, allowing you to integrate AI Advisor directly into your enterprise AI Agents, chatbots, and other automation workflows.

The AI Advisor REST API provides programmatic access to the same advanced network analysis capabilities available in the Kentik portal, allowing you to ask natural language questions and receive AI Advisor's insights through a simple, asynchronous REST interface

What is AI Advisor REST API?

AI Advisor REST API gives you programmatic access to Kentik's network intelligence agent, enabling you to:

• Ask questions in natural language about your network operations, device health, traffic patterns, and performance
• Maintain conversational context across multi-turn chat sessions for deeper analysis
• Receive markdown-formatted responses with transparent reasoning and actionable insights

Common Use Cases

• ITSM Integration: Connect AI Advisor to ServiceNow, Jira, or other ticketing systems for automated network analysis
• Automated Workflows: Trigger network analysis from alerting systems or scheduled jobs for reporting
• Chatbot Integration: Interact with AI Advisor in your favorite chat application
• AI Agents Integration: Extend your enterprise AI agent with AI Advisor's capabilities

API Endpoints

• POST /ai_advisor/v202511/chat - Create new session with initial prompt
• GET /ai_advisor/v202511/chat/{id} - Retrieve session status and results
• PUT /ai_advisor/v202511/chat - Add follow-up questions to existing session

Authentication & Access

The AI Advisor REST API uses standard Kentik API authentication with email and API token headers. All Admin and Member users with AI Advisor access can use the API.

Get Started Today

Ready to integrate AI-powered network intelligence into your workflows? Check out our comprehensive documentation:

• AI Advisor REST API Documentation - Complete API guide with examples
• OpenAPI Specification - Full API schema
• AI Advisor Overview - Learn about AI Advisor capabilities

Have questions? Contact your Kentik account team or reach out to support@kentik.com.

CDN Analytics is one of the most valued features in our platform, and for good reason. With 75% to 85% of a broadband ISP’s inbound traffic routinely being carried by just five major CDNs, understanding CDN-originated traffic is critical for managing subscriber performance and network capacity.

However, CDNs vary widely in how they operate. They range from massive commercial entities to single-purpose networks built exclusively for content providers (like Netflix’s Open Connect, Facebook's Network Appliances, or Google Global Caches). Because of this complexity, automatically enriching traffic data based on its true CDN origin is both an art and a science. It requires a smart detection engine – the core of our True Origin technology – that keeps evolving.

Additionally, the relationship between a broadband ISP and a CDN often extends beyond standard interconnection agreements, particularly when CDNs offer Cache Embedding programs. When caching appliances are co-located in the ISP's last mile, the ISP needs to verify the ROI: measuring the efficiency of that last-mile caching against the real-world costs of hosting, cooling, and powering the hardware.

Today, our detection engine grows again to help support these use cases. We are adding detection for Edgevana and Valve to our CDN Analytics, bringing our list of detected commercial and purpose-built CDNs to 65!

Let’s double-click into what this means for your network.

How does Kentik's True Origin CDN detection engine work?

The theoretical bits are somewhat trivial: flow telemetry comes in with source and destination IPs, which we map in real time to source or destination CDNs to enrich flow records we ingest. For this to be possible, our CDN Detection Engine constantly maintains a list of CDN-to-IP mappings behind the scenes. This list leverages a number of datasets:

• Multiple passive DNS datasets
• Our customer's real-time DNS data feeds 
• Routing registry data for prefixes originated by CDN ASNs
• Interface classification-based detection of 'Embedded Cache' type interfaces
• Configuration inputs from our customers declaratively adding Embedded Caches

This data is parsed every day using a set of heuristics, and allows Kentik to generate a unique and very accurate data set of IP-to-CDN mappings that include 1) IPs for servers in each CDN's infrastructure, and 2) last-mile-embedded servers in the broadband ISPs of both customers and non-customers. 

Leveraging Passive DNS data feeds and Interface Classification, setup for our customers is kept minimal as most of the embedded caches in their network will be automatically detected. In case they are not (one example is when these servers are behind a 3rd party router that's not registered with Kentik), a config interface allows them to statically declare them. 

What happens when we add a new CDN to our detection engine?

Train the detection engine on CNAMEs

This basically means that we feed it with patterns to look for in terms of unique CNAMEs to be crawled in our set of passive DNS data-feeds. We're talking about the *.akamaized.net or `*.fastly.net` well-known CNAME patterns that CDN customers use to link their own domain names in order for these CDNs to serve.
This data is further fed to the engine via our OTT DNS Taps, since it taps the DNS queries upstream of your subscribers.

Wire the ASN-to-CDN mappings using Routing Registries

The other trivial source of data is the ASNs that a given CDN uses to run their infrastructure on: all prefixes originated by these ASNs is turned in to CDN-to-IP mappings. For instance Akamai is well known to operate AS20940, but they have successively acquired other companies such as Prolexic, Instart Logic, Linode ...and not all of their associated ASNs are used to deliver CDN traffic to users. In the same vein, Netflix is publicly known to operate the Open Connect cache network both at IXes on their own servers via AS2906, but also via embedded caches on AS40027. This updated list gets parsed every day and adds to the IP-to-CDN mappings from the day before.

We also add metadata to all CDN entries in the engine's directory service, so that we can present users with added context for a given CDN – such as:

• The public logo of the CDN to embellish the CDN's detail page
• CDN type – are they a Commercial CDN, a purpose-build content CDN, or a Cloud Provider
• What their associated ASNs are and PeeringDB entries are
• Do they run an Embedded Cache Program (such as Netflix's OCA, Facebook's FNA, Google's GGC, Akamai's AANP, Apple's AEC...) and store the link to these individual initiatives web pages

Here's what the /service-provider/cdn/Valve details page looks like:

Wire the detection engine to Interface Classification

For the CDNs running an Embedded Cache Program, we built our engine to be able to detect as many of the IPs corresponding to these cache servers, even when they are in your own last-mile network and not directly hosted in the CDNs ASNs.

One of the ways our engine detects this is it looks at SNMP interface data from your Network Devices and inspects those with an Embedded Cache Connectivity Type. For those, the engine takes the IP subnet the interface is on, and if able to match a CDN from the interface description or the Provider Interface Classification field, assigns an additional IP-to-CDN Mapping.

In the CDN Analytics > Config section of the portal, you can see which ones are automatically detected (updates once a day) as depicted below:

Add means for users to self-declare IP CIDRs to CDN Mappings

Some Content CDNs (aka purpose-built) that run a last-mile Cache Embedding program have been known to provide a router to the broadband ISP in addition to the caches. The CDN in this case retains admin control over this router, which in turn cannot be registered with Kentik.

The consequence is that Embedded Cache interfaces cannot be auto detected since they're located on a device not registered in Kentik. In this case, users from the ISP will want to declare the CIDR space used to number the caches manually, which they can do in the Additional Embedded Caches tab of the CDN configuration workflow.

When adding a new CDN with a last-mile Embedded Cache program, we ensure that it is added to the manual addition config screen for users to start entering their static mappings.  

The following Cache Embedding CDNs are currently covered: Akamai, Amazon, Apple, Azion (Brazil), Baishan Cloud, ByteDance (tiktok), CDN77, Cloudflare, Edgevana, Facebook, G-Core, Globo, Google, i3D, Izzi, Limelight, Lumen/Level(3), Azure, Netflix, Netskrt, Quantil/China NetCenter, Qwilt, Valve.

As a result, the IP-to-CDN mappings resulting from this configuration form will be added to the daily mechanism that generates the global CDN-to-IP mappings.

Adding a CDN Offload widget to the landing page

While last-mile Cache Embedding provides many benefits to the broadband ISP, they also come with an operational cost around rack space, power, and cooling. Because of this, the embedding broadband ISP will often want to be able to measure the benefits for each embedding CDN to continuously justify the decision to embed.

The key metric for the main benefit is called offload: offload is a ratio between how much traffic is delivered to the subscribers from the cache vs. how much traffic is delivered to the subscribers in total – from a cache or from outside of the network. This Offload Ratio is commonly measured as a percentage. Traditionally, CDNs that transport a constantly growing long tail of user-generated content tend to have lower Offload Ratios (as popular content is competing for the discreet storage space offered by the embedded appliances). Conversely, CDNs with a fixed catalog (Netflix being a prime example, as the size of their catalog being somewhat fixed at all times) can achieve very high offload for a little cache footprint.

Note: there are subtleties between CDNs as to how we compute the Offload ratio. While we usually run these computations at peak time, because offload makes the most sense when traffic is at its highest, cases like Netflix Open Connect are different because the peak for inbound traffic happens when the caches fill themselves at night instead of during the delivery peak.

Users can enable/disable any Embedding CDN widget on the CDN Analytics landing page via the config screen, here's what it looks like:

And here's what a fully furnished landing page with offload widgets can look like:

Even better, all those independent widgets lead to a dashboard that will precisely let users figure out what the traffic patterns are for the caches when it comes to offload and will display all the following types of cache traffic:

• OffNet to Subscribers (aka longtail)
• OnNet to Subscribers (aka last-mile delivery)
• Cache to Cache Fill Traffic
• OffNet Cache Fill traffic

We hope you enjoyed this walk through on the internals of our CDN detection system. If you have any questions about it, please let Kentik's Product Team know, as we heavily count on your inputs to add new CDNs or new capabilities to the workflow as our CDN detection engine gets smarter and smarter!

For several years, kprobe has served as a flexible bridge for our community, providing deep host-level visibility and DNS insights. However, the requirements for modern network observability are changing. To ensure our customers are equipped with our latest innovations and highest-performance capabilities, we have officially sunset kprobe as we consolidate our engineering focus onto the Kentik Universal Agent.

This transition is about more than just a tool change; it is about providing you with a unified, high-performance foundation for the next decade of networking. We recommend all users begin transitioning to these supported alternatives to stay aligned with Kentik’s innovation roadmap.

Unlocking the Next Generation of Innovation

Maintaining disparate legacy agents limits the speed at which we can deliver value. By centralizing our development on the Universal Agent, we are creating a streamlined control plane that enables us to roll out new capabilities from advanced metadata enrichment to UI-driven orchestration, at a much faster cadence. This move ensures you are always running on our most secure, platform-agnostic, and performant code base.

The Path to Modern Observability

1. High-Performance DNS & OTT Insights

For those utilizing kprobe for DNS performance or OTT traffic mapping, the Kentik Universal Agent is your direct path forward. Our recently released DNS Tap capability is now live, purpose-built to replace kprobe’s DNS-tapping functions with higher throughput. By mapping DNS queries directly to hostnames, it provides the deep service context required for modern OTT visibility without the CPU overhead of legacy packet processing.

2. Standardized Host Flow & System Visibility

For general host-flow export and system-mode visibility, we recommend the industry-standard hsflowd. As a mature, widely adopted open-source project, hsflowd provides excellent cross-platform support and is the ideal choice for users who prioritize open-source consistency for general host metrics.

A Strategic Shift in Application Visibility
As the industry moves toward pervasive encryption (TLS 1.3), traditional application-layer packet decoding such as kprobe’s legacy HTTP decodes has become less effective for modern, secure environments. Kentik’s strategy is evolving to focus on high-scale transport-layer visibility and cloud-native insights. For specialized use cases requiring deep, unencrypted HTTP packet analysis, we recommend leveraging dedicated APM or specialized DPI tools that complement Kentik’s network-wide observability.

Timeline & Support

• Status: kprobe is officially deprecated as of today.
• Repositories: The GitHub repository has been moved to an "Archived" state.
• Support: While traffic processing and query results will remain working without any intended interruption standalone agents deprecated such as kprobe will receive limited to no new software updates. Plan your migration today. 

Ready to access the latest Kentik innovations?
Contact your Kentik account team or visit our Knowledge Base for detailed migration guides.

We are incredibly grateful to the developers and customers who helped kprobe grow, and we look forward to building the future of network observability together.

The Kentik Product Team

Our users and readers probably noticed a few months back that we added the ingestion of SNMP Syslogs and Traps to our platform via NMS.
Today we are bringing new enhancements to that Syslog functionality. But before we dig into those, let's do a quick recap of what was already available.

Setting up Syslog on a Network Device

First order of business when you want to add Syslog observability to your Kentik setup is to deploy our Universal Agent and enable the syslog capability on it. Deploying Universal Agent is trivial and all that's needed is to enable the Syslog Server capability during the final steps of the deployment process, as pictured below:

For an already deployed agent, the capability can be installed/enabled on the fly as depicted below from the Settings > Universal Agent agent list.

Once this is done, all you need to do is configure your network devices to send Syslog records to this agent. If necessary, you can also configure the listening IP and ports on the syslog capability.
Provided your device is NMS enabled, the Kentik cluster will ingest Syslog records from the device via the Universal Agent's syslog capability.

How can I access Syslog data for analysis? (part 1)

All ingested syslog data is enriched with a sum of attributes and immediately stored in our universal telemetry datastore, making it ready for analysis.
Syslogs (as well as SNMP Traps) correspond to a new broad type of Telemetry available in our platform called Events. We intend to add additional event types in the near future, so stay tuned!

Once ingested, new Metrics and Dimensions choices (both Group By and Filter) will be available in Data Explorer, as depicted below - allowing for very granular event type queries.

Here's an example of a Data Explorer query displaying syslog volumes per device and per severity over time.

Additionally, the new Events View tab on the data table will appear for users to display a complete list (unaggregated) of all the Syslog messages captured in this time window for filter defined in the query.

Of course, all of these visualizations are available to a bunch of extra useful capabilities such as

• Saved Views
• Dashboards
• Filter Based Dimensions
• Generate One Chart per Series

So what's new with Syslog? (part 2)

As of today, we're adding a few niceties, this is where it all becomes interesting. The keen eye will have noticed that the Infrastructure > Devices inventory screen includes a new filter in the NMS Status section - this filter now allows users to narrow the device list down to those that we are seeing Syslog entries for.

...but the real deal is that starting today a new Syslogs tab appears on the Infrastructure > Device > device details screen: let's say you are doing your rounds on a device, eyeballing it's metrics in the overview tab - you see a spike on CPU on the overview spark line and want to check if error reported by syslog has happened that may explain it, here's what it looks like when you click on the Syslog tab. Now users can easily search for specific syslog entries on this device of any Severity within any Time Range.

What does the future hold?

As mentioned earlier, we are just getting started on Events. They will soon play an important role in our unified observability stack, being additionally available to our recently released AI Advisor: when clicking on the top right Ask button on a Device Details page to summon the agent, it will already have the recently Syslogs for the device as part of its context.

As a fast follow-up, we will be soon adding SNMP Traps as a similar additional tab in the Device Details screen.

Later this year, we will be opening up amazing possibilities to query together Traffic (Flow), NMS (SNMP/ST), Events (syslogs, traps & more) and Performance (Synthetics) together in a cohesive set of visualizations - so stay tuned as things are just about to become interesting!

Low Resolution login screen

More often than not, our users may have to access Kentik Portal from a web browser running via Terminal Server or some equivalent VNC variant.
Some of our users have reported that the animated gradient on the new Login Screen resulted in a very laggy experience in such remote setups.

To solve this issue, we have introduced a QueryArg in the login URL that these users can now bookmark, which instead of an animated gradient displays a static one, therefore solving this issue:

https://portal.kentik.com/login?lowres=true if you are a US Platform user, or https://portal.kentik.eu/login?lowres=true if you are an EU Platform user.

Kentik Next for SSO users

https://next.kentik.com (alternatively https://next.kentik.eu to our EU users) is a public version of Kentik Portal which is always ahead of our production systems - it is the equivalent of OSes' Nightly Builds, a public pendant to our portal.kentik.com main instance. "Next" as we call it, exists for our customers to experience the next features to hit our production systems. (Disclaimer: as paint may constantly be wet on it, we advise users to stick to the product systems to perform production work). 

Up until now Next was not available to our SSO users - but it is now, so give it a try !

In our everlasting quest to strengthen security around the Kentik Platform, we're happy to introduce WebAuthN today – a growing web browser native Web Authentication standard with many benefits over prior ones.
Until today, we offered Multi-Factor Authentication (MFA) to our users via these 2-Factor (2FA) methods: Time-based One-Time Password (TOTP, also known as Authenticator App-based Tokens) and hardware keys such as YubiKeys from the FIDO Alliance.
While these methods offer a better security level than plain user/password authentication and we strongly encourage our users to adopt 2FA, the standards have evolved to new, more secure methods that we are now proud to offer to our user base.

Let's see what this is all about!

Authentication security concepts

Let’s take a look at modern improvements recently achieved in the domain of Web Authentication.

"Something you are"

In authentication, there are three categories of credentials (or factors) used to verify a user's identity. They are: something you know (like a password), something you have (such as a security token), and something you are (like a fingerprint). Using a combination of two or more of these factors is known as multi-factor authentication (MFA). 

Modern Authentication favors something you are with the use of Biometric Methods: Fingerprint Recognition (known as Touch ID for Apple users, or Hello for Microsoft users), or camera-based Face Recognition (known as Face ID for Apple users, Face Unlock for Android users). While a malevolent actor can phish something you know, steal something you own, it is much harder to spoof something you are when it is based on your unique biometric markers.

Public/Private keys

Another recent security improvement on the web is the adoption of browser-based Public-key credentials extensions (WebAuthN, which we’ll talk about in a minute, uses this scheme).

In a public-key based Authentication model, a pair of keys (public key and private key) are used in authentication. The remote authenticating system stores a user's public key (visible to anyone) and a credential ID, not a password. The private key, which is the secret half of the key pair, is stored securely on the user's device, not on the server. 

This design offers significant security benefits compared to traditional passwords: 

• Security by design: The server has no shared secret with the user that could be compromised. The public key is useless to an attacker on its own.
• Phishing resistance: The private key is cryptographically bound to a specific website domain, so it cannot be used on a fake phishing site to trick the user.
• Data breach protection: If a server's database is breached, the attacker can only steal public keys and credential IDs, which cannot be used to impersonate a user.

What is WebAuthN ?

WebAuthN is the latest version of the FIDO Alliance’s open authentication standard (FIDO2). It is an effort to bring strong 2FA to the web and is based on the W3C’s Web Authentication API, which is supported by many, if not most, common web browsers.
In a nutshell, WebAuthN brings these attractive improvements to prior 2FA technologies:

• it is the leading open authentication standard on the web: it is widely adopted, can be audited, and comes natively in most recent browsers
• it adds public-key cryptography to most existing 2FA methods, securing them further (with the exception of TOTP, which becomes the least secure 2FA method)
• because most recent browsers are tightly integrated with the hardware and OS they run on, it brings Biometrics (aka "something you are") to web authentication, alleviating the need to procure physical keys

What does it look like in Kentik Portal ? 

To enable WebAuthN we've made changes to the User Profile section's Authentication tab, surfacing these new 2-Factor capabilities now offered to users - 

but before we dive into these changes, let's summarize the levels of security now offered by Kentik Portal per Authentication method and outline their respective security levels:

Multiple 2-Factor Methods per user

Kentik still offers each user to configure multiple 2-Factor Authentication methods in their User Profile – this allows users to configure backups or configure alternatives between when they're at home and on the go. A user can configure and name as many of these as they desire.

These Authentication methods are now split in 3 separate tables (click the button on the top right of each table to add one):

• (1) Legacy Methods: 
  Least secure 2-Factor - will include your Legacy Hardware Keys such as YubiKeys, and your TOTP.
  You can re-create a new entry for your YubiKey in the Security Keys table, which will make them WebAuthN compliant (more secure): we strongly encourage you to do so !
  Because Time-Based One-Time Passwords aren't compatible with the WebAuthN standard, they will stay in this "Legacy Methods" section, we advise to move away from them.
  That being said, they're still a better alternative than no 2-Factor.
  
  
• (2) Device Authenticators:
  These are Hardware/OS level biometrics such as Apple's Touch ID and Microsoft Hello - they are considered to currently be the most secure methods, because they correspond to the "Something you are" principle.
  Registration of these via the Enroll Device button is natively supported by most recent browsers using a common UI.
  
  
• (3) Security Keys:
  These authentication factors include both Hardware USB Security Keys (such as Yubikey, or Google's Titan- both FIDO and FIDO2), both natively WebAuthN compliant -with FIDO2, they come with a PIN code.
  In addition to these keys, you can also configure a mobile based (both iPhone or Android) WebAuthN compliant methods in this section. In this clever method, a QR code is presented to the user at login time, triggering the device's biometric native UI to proceed with a Face ID / Face Unlock verification.

When multiple methods are available, authentication will always prioritize the Device Authenticators first, via a native browser prompt. If other WebAuthN methods have been configured by the user such as a YubiKey or an iPhone/Android Mobile Authentication - these will be available as part of the same prompt by choosing Other Methods. (see screengrab below)

As a user, what should I do ?

This choice depends a lot on the Security policy dictated by your company, which you should always conform to.
With that said, as outlined by the previous diagram in this article comparing the security level of the various available methods, Kentik highly suggests that you always opt for the most secure one possible, which is encompassed in the following recommendations:

• Always use 2-Factor – plain password authentication is unsafe.
• If your current 2-Factor is TOTP, you should consider adding a WebAuthN compatible one now – in this case HW based biometrics are your best choice since they’re available on any recent laptop or mobile device.

• If your current 2-Factor is a YubiKey, you should consider

  • re-registering it in the Security Keys section to add WebAuthN to it
  • adding a biometrics-based Device Authenticator if your computer allows it, it will be prioritized over the YubiKey
• Try to have at least two methods configured, in case you lose one of them or if it happens to get compromised – so that you won't lose access to Kentik portal.

As someone who is responsible for Kentik App Security, what should I do ?

As a security focused Kentik Administrator,  you want to increase Authentication Security for all your SaaS Applications, Kentik being no exception. To make your job easier of migrating users from a weaker 2FA to a stronger, WebAuthN 2FA, we added a filter in the Company Settings > Users screen to identify users based on their 2FA settings:

Additionally, a new Custom button appeared at the top right of the Users table, which will let you add two new columns in - to help Kentik admins track 2 Factor adoption within their company:

• Strong Authenticators: number of WebAuthN 2Factor Authenticators configured
• Weak Authenticators: number of non-WebAuthN 2Factor Authenticators configured

What's next for Kentik Portal Authentication ?

Making 2-Factor authentication mandatory

At this juncture, we're seriously considering this further step as the next one. There are a couple ways we could go about doing so: 

• In a first step, we could expose a company-wide setting where your security staff could set it as mandatory for your tenant to respect your company's security stance, with a disabled default to make for a smooth and easy transition.
• In a second step, we could make it mandatory by default and bake it in the user registration/onboarding process.

One of the reasons we haven't made a call about it yet is that a lot of customers have a centralized AAA strategy to access their SaaS apps that goes through centrally managing it via SSO, with the implication that the underlying SSO should take care of the multi-factor strategy.

Do let us know what your preference would be on the matter!

Do let us know what your preference would be on the matter !

A note on Password-less authentication

One of the eventual benefits of WebAuthN is password-less authentication such as PassKeys: this standard converges towards allowing users to register to a web application without providing the proverbial insecure password and exclusively replace it in our user profiles data store with the generated Public Key from the initial WebAuthN challenge.
While this is one of our long term goals, password-less is not part of this release, as it requires us to completely overhaul the user registration process.

Still, do let us know if password-less authentication is something you'd like to see in the product in the future.

One of Kentik's core missions has always been to help our users make sense of their infrastructure, taking the front seat in the Network Intelligence space by constantly enriching the Telemetry our users send us to ingest.
This release adds new BGP dimensions and filters for you and the AI Advisor to leverage as you are trying to make sense of the Infrastructure at the edge of your network.

Let's dive into it!

How do BGP enrichments work ?

When registering devices in Kentik, you have the option of establishing a BGP session with our SaaS or OnPrem cluster. These sessions, v4 and v6 are configured as iBGP Route Reflector Clients.
As we ingest your Netflow/Sflow/IPFIX telemetry, we map the SRC_IP and DST_IP from the flow fields with the Routing Data gathered from these iBGP sessions and enrich flows with such useful dimensions as

• Source or Destination ASN (Autonomous System)
• AS Path for the outgoing traffic
• Next-Hop, 2nd Hop, 3rd Hop ASN from the AS Path
• BGP Communities
• A variety of VRF related dimensions
• ...

If you don't peer directly with our clusters for a Kentik-registered device, you can choose to adopt the routing table of another device, or use a Generic Routing Table to access part of that information.

Alternate enrichment of Source or Destination ASN with a Generic Table

If your device is iBGP-peered with Kentik's SaaS cluster, the Source and Destination ASN enriched in your Netflow/Sflow/IPFIX records will be in priority based off your own routing data, but will fall back to a Generic Routing table if your own routing information has no entry for a given Source or Destination IP. This Generic Routing table is built on MTR Route Dumps from the RouteViews Project (courtesy of University of Oregon).

Two things are worth noting

• you should never send default routes (0.0.0.0/0) in your iBGP Route Reflector Client sessions to Kentik, as it will attract all source or destinations that you do not have a route for
• if your device does not have an iBGP session established with Kentik, we'll use this Generic Routing table for your entire traffic

In some cases, using your BGP tables to enrich your traffic may hide an issue: if these are intermittent, you may see Source or Destination ASN flapping around for the same prefix, which can result in a long and often sterile investigation.

We are now solving that problem by adding two Source ASN (Generic Table) and Destination (Generic Table) to the default BGP available dimensions. These are additions and do not replace the original Source ASN and Destination ASN dimensions: they can be used together within the same Data Explorer query to more rapidly track down such situations. You'll find them in the Dimensions selector as depicted in the screenshot below:

Collapsed AS Path

Every prefix learned by a BGP peer contains an AS Path, which indicates the series of Networks (identified by their Autonomous System Number, aka ASN) - this path is used heavily in the BGP decision mechanism to determine which route is best when multiple are received, and the length of the AS Path is a key decision factor: the BGP route election process will select the one with the fewer hops (ASN Hops) in the AS Path attribute of the prefix received.

Most BGP-speaking Networks are homed Multi-Homed: this means they have at least two upstream providers to receive the Full Internet Routing table from. While it is trivial BGP-wise to influence which of the two upstream providers you want to select for any destination prefix, it is much more complicated (if not impossible) to influence which one of the two upstreams you want to receive traffic from in priority.
To achieve that, BGP offers a mechanism named AS Path Prepending which basically allows any ASN along the path to insert their ASN in the AS Path attribute of the prefix as a last-ditch effort have their upstreams prefer another route for this prefix (Last ditch because this is far from being an efficient method).

In the following example, AS62775 which originates two /48 IPv6 prefixes and announces them to AS396955 who in turns announces them to AS1299. AS396955 prepends their ASN one more time when announcing to AS1299, signaling that they want to prevent AS1299 to use them to reach these AS62775 prefixes.

As a way to de-noise the above picture, we've come up with a bunch of additional of AS Path related dimensions that contract the AS Path when it sees duplicate hops in it - these dimensions come in addition to the existing AS Path related ones, as can be seen on the screenshot below

Using AS Path (Collapsed) instead of AS Path as a Group By dimension will yield the following sankey for the same prefixes

IPv6 Flow Labels

IPv6 flow labels are a 20-bit field in the IPv6 header used to identify packets belonging to the same traffic flow, allowing routers to provide special handling for them. A flow is a sequence of packets from a specific source to a destination. The label is used to efficiently handle and prioritize these flows, such as for real-time voice or video, without inspecting the entire packet payload.

As this relatively new standard gets adopted more broadly (it allows routers along the path to perform special handling of a Flow between a Source and a Destination marked with these labels), a number of our customers have asked us to include this additional dimension to our flow enrichment process. This has now been done as part of the below highlighted dimension.

Unfortunately, as any new networking standard tends to be vendor specific, our initial support for IPv6 Flow Labels is currently limited to Juniper Networks devices.
Please do let us know if your current use warrants to extend this support to other vendors by raising a feature request with your Customer Success specialist and we'll add it to our list of future work to consider for future roadmaps.

Interface Classification is one of the key components of Kentik Portal. It makes interface-based enrichments possible. 

• Network Boundary gives users an easy way to limit queries to traffic entering or exiting the network without the risk of double-counting.
• Connectivity Type adds both technical and business context to traffic moving into or out of these interfaces, making it easier to identify, for example, which interfaces are used for peering or transit at the network's edge.
• Provider (or Customer) automatically enriches any traffic on these interfaces with the name of the connected customer.

As Interface Classification is a load-bearing feature used throughout many of the portal workflows, including our AI Advisor (which relies on it to understand the tasks an interface performs), we have always kept the list of available values for Connectivity Types locked in.

Today we're adding three more values to Connectivity Types that our users have requested over the past years.

Management

Management Interfaces are quite self-explanatory. This Connectivity Type describes the port on a device that is connected to the Management network, which is the common network used to administer devices. It comes with the default Connectivity Type of “Internal” but can be set to “External” in the case of externally based OOB monitoring.

DDoS Mitigation: Cloud or Appliance

DDoS Mitigation Cloud or Appliance Connectivity Types are intended to classify interfaces that sit in front of a DDoS mitigation platform, whether it is an appliance-based internal solution (A10, Radware, Corero, etc.) or an external scrubbing DDoS Mitigation Cloud provider.

In one case, the default Network Boundary will be “Internal,” and in the latter, it will be “External.” The DDoS Mitigation: Cloud Connectivity Type pairs well with the Provider/Customer Interface Classification attribute, and users can programmatically set it using capture groups if a consistent Interface Description policy permits them to do so.

What's next ?

As we mentioned earlier, Interface Classification is tightly controlled, as it needs to provide consistent behavior across all areas of the Kentik Portal where it is utilized. This doesn't mean we are not open to suggestions from you regarding any additional required values, especially for Connectivity Types, that help better describe the taxonomy of your network.

Do let us know if you would like us to add more of these in the future.