IBNS 2.0: Flexibilitäts-Gewinn oder Konfigurations-Falle?

Identity-Based Networking Service

Die Funktion der gleichzeitigen Authentisierung wurde mit Cisco Identity-Based Networking Service 2.0 (IBNS 2.0) vor ca. 10 Jahren in Zusammenhang mit Cisco TrustSec eingeführt.

Im Unterschied zu IBNS 1.0 basiert IBNS 2.0 auf Templates. Dazu zählen unter anderem Policy- und Interface-Templates, welche die Konfiguration vom Interface in die globale Konfiguration verlagern. Hinzu kommt das Thema Flexibilität. So kann zum Beispiel ein Interface-Template via RADIUS-Attribut einem Interface zugeordnet werden.

Der vorher durch die Summe an Authentisierungsfunktionen (Authentisierungsreihenfolge, Default-Policy, Hostmodi, Control Direction, Timing, Reauthentisierung, Accounting, RADIUS-failed Policy, etc.)  bestimmte Authentisierungsablauf ist mit IBNS 2.0 flexibel konfigurierbar. Dies kann sowohl ein Vorteil als auch ein Nachteil sein.

Anfängliche Gründe für IBNS 2.0

Für uns und unsere Kunden stand dabei insbesondere die verkürzte Wartezeit bis zur erfolgreichen MAC-Adress-Authentisierung im Vordergrund. Bei einer klassischen sequenziellen Abarbeitung der IBNS-1.0-Konfiguration werden zunächst drei Versuche einer EAP-Authentisierung durchgeführt. Zwischen jedem Versuch gibt es eine entsprechende Wartezeit. Erst nach drei fehlgeschlagenen Versuchen wird anschließend eine MAC-Adress-Authentisierung angestoßen. Bei Verwendung der Standard-Timer kann dies zu einer Verzögerung von bis zu 90 Sekunden führen. Diese können angepasst werden. Dabei wird eine Verzögerung zwischen sechs und zehn Sekunden empfohlen.

Man kann die Reihenfolge auch umdrehen, sodass die MAC-Authentisierung vor der EAP-Authentisierung erfolgt. Dennoch bleibt das Verfahren starr und unterliegt zusätzlichen Limitierungen. Um nach einer erfolgreichen MAC-Authentisierung einem Endgerät eine EAP-Authentisierung zu ermöglichen, muss die EAP-Authentisierung in der Konfiguration priorisiert werden. Bei dieser Reihenfolge mit zusätzlicher Priorität auf EAP-Authentisierung gibt es ein Problem im Detail. Eine Reauthentisierung führt nicht zu einer erfolgreichen EAP-Sitzung, solange eine erfolgreiche MAC-Adress-Authentisierung weiterhin möglich ist. Die Priorität wird hier nicht berücksichtigt.

Sequential vs Concurrent

Bei IBNS 2.0 kann man zwischen der sequentiellen Abarbeitung (ähnlich IBNS 1.0) oder der gleichzeitigen Abarbeitung der verfügbaren Authentisierungsmethoden (EAP/MAB) wählen.

• Sequential Authentication / klassische Reihenfolge
  
  Code

  event session-started match-all
  10 class always do-until-failure
  10 authenticate using dot1x retries 2 retry-time 0 priority 10
  event authentication-failure match-first
  5 class DOT1X_FAILED do-until-failure
  10 terminate dot1x
  20 authenticate using mab priority 20
  […##93###
  event agent-found match-all
  10 class always do-until-failure
  10 terminate mab
  20 authenticate using dot1x retries 2 retry-time 0 priority 10

In der klassischen Reihenfolge wird erst versucht, eine EAP-Authentisierung durchzuführen. Schlägt dies nach konfigurierten Wiederholungen und Wartezeiten fehl, kommt es zu einer MAC-Adress-Authentisierung. Sendet ein Endgerät während einer etablierten MAC-Authentisierungssitzung ein EAPoL-Start (agent-found), wird die priorisierte EAP-Sitzung etabliert und die MAC-Authentisierungssitzung terminiert.

• Concurrent Authentication / gleichzeitige Authentisierung
  
  Code

  event session-started match-all
  10 class always do-until-failure
  10 authenticate using dot1x priority 10
  20 authenticate using mab priority 20

Bei gleichzeitiger Authentisierung werden beide Authentisierungsverfahren parallel gestartet. Aufgrund der Endgerätepakete (EAPoLtart oder beliebiges anderes Paket) wird das jeweilige Verfahren verwendet. Sind 2 Verfahren erfolgreich, muss das Verfahren mit der niedrigeren Priorität beendet werden.

Probleme mit IBNS 2.0

IBNS 2.0 bietet mit „Concurrent Authentication” die oben beschriebene Möglichkeit einer gleichzeitigen Verwendung von EAP- und MAC-Adress-Authentisierung. Diese Option wird jedoch weder in der aktuellen Dokumentation [1]  noch innerhalb von Authentication Templates in Cisco Software Defined Access (SD-Access) (siehe [2] und Abbildung 1) erwähnt oder angeboten.

Insgesamt ist das IBNS-2.0-Regelwerk unter Verwendung aller Funktionen und dem damit verbundenen Einsatz von „events“ sehr flexibel, jedoch auch komplex. Zudem existieren wenige fertige Beispiele, die alle Funktionen beinhalten.

In bestimmten Kombinationen kann es zu ungewollten Effekten kommen. Eine Konfiguration aus dem IBNS 2.0 Deployment Guide [3] führt zum Beispiel zu ständigen Neuauthentisierungen aller Endgeräte. Dies passiert bei „Concurrent Authentication“, wenn zwar eine erfolgreiche EAP-Authentisierung erfolgt, die MAC-Adress-Authentisierung jedoch aufgrund einer nicht registrierten MAC-Adresse fehlschlägt. Hierbei wird auch die erfolgreiche EAP-Authentisierung terminiert, und der gesamte Prozess beginnt von vorne.

Hierbei muss das Event authentication-failure so angepasst werden, dass bei einer fehlgeschlagenen MAC-Authentisierung eine erneute EAP-Authentisierung angestoßen wird, um das ungewünschte Verhalten zu stoppen.

Bei individuellen Änderungen an IBNS 2.0 Policy Maps sollte daher immer geprüft werden, ob das konfigurierte Regelwerk wie gewünscht arbeitet. Je nach Softwarestand kann dies mit dem Befehl „debug pre all“ erfolgen. In den entsprechenden Logs lässt sich die Abarbeitung des Regelwerks im Detail nachvollziehen.

Wahre Vorteile

Die wahren Vorteile von IBNS 2.0 liegen weniger in der Funktion „Concurrent Authentication“ als vielmehr in der Verwendung von Templates.

Momentane Situation

Viele unserer Kunden setzen weiterhin IBNS 1.0 ein. IBNS 2.0 wird nur von wenigen genutzt, häufig aufgrund der Funktion „Concurrent Authentication“. Diese sollte nur unter Berücksichtigung der oben beschriebenen Aspekte verwendet werden (siehe Probleme mit IBNS 2.0). Sollten jedoch Templates zum Einsatz kommen oder Cisco SD-Access genutzt werden, ist der Einsatz von IBNS 2.0 notwendig.

Migration

Wenn IBNS 1.0 verwendet wird und die aktuelle Konfiguration in IBNS 2.0 dargestellt werden soll, kann der Befehl „authentication display new-style“ genutzt werden. Wird die Konfiguration nicht gespeichert und werden keine Änderungen durchgeführt, lässt sich mit „authentication display legacy“ wieder zur IBNS-1.0-Ansicht zurückkehren.

Verweise

[1] Understanding Identity Based Network Services IBNS 2.0 Cisco Live, Juni 2025
https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2025/pdf/BRKCRT-3002.pdf

[2] Cisco SD-Access Deployment Using Cisco Catalyst Center, Dezember 2025
https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/catalyst-center/cisco-validated-solution-profiles/validated-profile-sda-deployment.html

[3] IBNS 2.0 Deployment Guide, November 2014
https://community.cisco.com/kxiwq67737/attachments/kxiwq67737/discussions-network-access-control/593066/1/whitepaper_C11-729965.pdf&ved=2ahUKEwjPwabzqKmTAxUiRv4FHWkVJTAQFnoECAUQAQ&usg=AOvVaw2qJ7qj_HsLUekLXFe0Igwp