RADIUS-Neuauthentifizierung als Alternative zu RADIUS-CoA für DHCP-Abonnenten

Vorteile der erneuten Authentifizierung

• Aktualisieren oder ändern Sie die Sitzungsattribute und Servicepläne von Abonnenten, ohne eine CoA-Anforderung zu verwenden.

• Simplifizieren Sie die Aktivierung von Services, die sich aus häufigen, vom Abonnenten initiierten Änderungen ergeben.

• Aktivieren Sie die erneute Authentifizierung pro Produktfamilie in Dual-Stack-Konfigurationen mit einer Sitzung.

• Steuern Sie die erneute Authentifizierung über eine CLI-Konfiguration oder einen RADIUS-VSA.

Funktionalität

Die erneute Authentifizierung wird sowohl für DHCPv4 als auch für DHCPv6 unterstützt. Sie kann ausgelöst werden, wenn der lokale DHCP-Server eine Nachricht zum Erneuern, erneuten Binden, Ermitteln oder Anfordern von einem DHCP-Client empfängt. Die Nachrichten zum Ermitteln und Anfordern von Nachrichten unterstützen die erneute Authentifizierung ab Junos OS Version 18.1R1. Die Unterstützung für die Discover- und Solicit-Nachrichten bedeutet, dass, wenn ein CPE mit einem gebundenen Client neu gestartet wird und der Client eine dieser Nachrichten sendet, um die Sitzung wieder hochzufahren, die erneute Authentifizierung es authd ermöglicht, alle Updates abzurufen, die für den Abonnenten vorgenommen wurden.

Das Verhalten der erneuten Authentifizierung wird wie folgt bestimmt:

• Die reauthenticate lease-renewal Anweisung gibt an, dass die erneute Authentifizierung ausgelöst wird, wenn eine der vier unterstützten Nachrichten empfangen wird.

• Die reauthenticate remote-id-mismatch Anweisung gibt an, dass die erneute Authentifizierung nur ausgelöst wird, wenn die empfangene Nachricht eine Änderung des Werts der Remote-Agenten-ID des DHCP-Clients enthält. Der Attributwert enthält den Namen des Abonnentendienstplans, sodass eine Änderung des Werts eine Änderung des Dienstes für den Abonnenten bedeutet.

• Die Juniper Networks VSA (26-206) löst eine erneute Authentifizierung aus, wenn sie mit dem Wert 1 in der Access-Accept-Nachricht vom RADIUS-Server für den Abonnenten bei der Anmeldung reauthentication-on-renew zurückgegeben wird. Der Wert 0 deaktiviert die erneute Authentifizierung. Der VSA-Wert wird in der Sitzungsdatenbank gespeichert, sobald er empfangen wird. Nachdem dieser VSA die erneute Authentifizierung aktiviert hat, wird er bei jedem erneuten Authentifizierungsversuch überprüft. Wenn sich der Wert in 0 geändert hat, d. h., wenn ein nachfolgendes Access-Accept den VSA mit dem Wert 0 zurückgegeben hat, wird der Prozess der erneuten Authentifizierung für diesen Abonnenten beendet.

  Die CLI-Konfiguration (reauthenticate Anweisung) und das Verhalten "Reauthenticate-On-Renew" sind additiv. Das Deaktivieren der erneuten Authentifizierung mit dem VSA wirkt sich nur aus, wenn die reauthenticate Anweisung nicht konfiguriert ist. Wenn die reauthenticate Anweisung mit einer der beiden Optionen konfiguriert ist, wird der VSA-Wert 0 überschrieben. Wenn die CLI-Konfiguration nicht vorhanden ist, kann der VSA die erneute Authentifizierung selbst aktivieren.

Der Prozess der erneuten Authentifizierung ist nahezu identisch mit dem ursprünglichen Authentifizierungsprozess. Wenn die erneute Authentifizierung ausgelöst wird, sendet der jdhcpd-Prozess auf dem lokalen Server eine Authentifizierungsanforderung an authd, der wiederum eine Access-Request-Nachricht an den RADIUS-Server sendet, um eine zweite Authentifizierung anzufordern.

Diese Zugriffsanforderung enthält RADIUS-Status- und Klassenattribute, die in der ursprünglichen Access-Accept-Nachricht zurückgegeben wurden. Diese Attribute ermöglichen es dem RADIUS-Server, die erneute Authentifizierungsanforderung von Anmeldeanforderungen (Authentifizierungsanforderungen) zu unterscheiden.

Der RADIUS-Server gibt eine Access-Accept-Nachricht mit neuen Attributen für den Abonnenten an authd zurück. Der authd-Prozess sendet eine Bestätigung (ACK) mit den Änderungen an jdhcpd, wodurch ein DHCP-Angebot mit geänderten Attributen an den DHCP-Client gesendet wird. Die DHCP-Aushandlung wird wie gewohnt fortgesetzt (siehe Abbildung 1), und die Abonnentensitzung wird mit den neuen Attributwerten fortgesetzt. Wenn die erneute Authentifizierung eine Änderung des Serviceplans umfasst, gibt der RADIUS-Server den neuen Plan mit allen anderen geänderten Attributen zurück, wenn er die Anforderung akzeptiert, wie in Abbildung 2 dargestellt. Wenn der CPE, auf dem der DHCP-Client gehostet wird, während der Änderung eines Dienstplans neu gestartet wird, wird die erneute Authentifizierung mit dem neuen Plan ohne Unterbrechung des Dienstes unterstützt.

Wenn der RADIUS-Server eine erneute Authentifizierungsanforderung ablehnt oder eine Zeitüberschreitung auftritt, sendet authd eine NAK an jdhcpd, die den enthaltenen Fehlercode überprüft. Wenn der Fehlercode auf eine Zeitüberschreitung hinweist, sendet jdhcpd eine Bestätigung an den DHCP-Client, und die Abonnentensitzung wird mit den ursprünglichen Attributen und dem ursprünglichen Dienst beibehalten. Bei jedem anderen Fehlercode sendet jdhcpd eine DHCPv4 NAK oder DHCPv6 REPLY (wobei der Gültigkeitswert auf 0 festgelegt ist) als logischen NAK, initiiert die Abmeldung des Abonnenten und löscht den Abonnenten aus der Sitzungsdatenbank.

In Tabelle 1 wird beschrieben, wie authd Anforderungen verarbeitet, wenn für denselben Abonnenten bereits ein anderer Anforderungstyp ausgeführt wird.

Wenn die erneute Authentifizierung zu einer Änderung der IP- oder IPv6-Adresse eines DHCPv6-Abonnenten führt, nachdem ein Client gebunden wurde, wertet der DHCPv6-Server die Adressänderungsanforderung aus. Der Server gibt einen Statuscode an den Client in der Identitätszuordnung (IA) der Antwort-PDU zurück. Ab Junos OS Version 18.4R1 wird ein Statuscode für NotOnLink zusätzlich zu den zuvor unterstützten Codes für NoAddrsAvail und NoPrefixAvail unterstützt, wenn der DHCPv6-Server ein Problem mit der Adresse feststellt. Diese Statuscodes sind wie folgt definiert:

• NoAddrsAvail (2): Der Server kann in der Client-Anforderung keine Adressen für die IA zuweisen. Sie gibt die IA ohne Adressen und NoAddrsAvail zurück.

• NotOnLink (4): Der Server stellt fest, dass das Präfix für eine oder mehrere Adressen in einem beliebigen IA in der Client-Anforderung nicht für die Verbindung geeignet ist, die eine Verbindung zum Client herstellt. Dieser Code wird auch im Falle eines erneuten Authentifizierungsfehlers (RADIUS Access-Reject) verwendet.

• NoPrefixAvail (6): Auf dem Server stehen keine Präfixe für die IA in der Clientanforderung zur Verfügung.

Wenn der Client den NotOnLink-Statuscode erhält, kann er eine weitere Anforderung ohne Adressen senden oder den Aushandlungsprozess neu starten. Wenn eine Anforderung gesendet wird, ignoriert der lokale DHCPv6-Serer die Anforderung und erwartet, dass eine neue Neuverhandlung beginnt.

Dual-Stack-Abonnenten

In Versionen vor Junos OS Version 18.1R1 werden Dual-Stack-DHCP-Abonnenten als unabhängige Client-Sitzungen behandelt. Jeder Stack erneuert sich und erhält neue Services unabhängig voneinander.

Ab Junos OS Version 18.1R1 werden die familienspezifische Authentifizierung und erneute Authentifizierung für Dual-Stack-Abonnenten mit einer Sitzung unterstützt. Ein Dual-Stack-Teilnehmer mit einer Sitzung ist in der Regel ein Haushalt mit eigenem VLAN in einem 1:1-Zugriffsmodell. Der Haushalt wird als einzelner Abonnent mit einer einzelnen Sitzung in der Sitzungsdatenbank dargestellt, verfügt jedoch über zwei separate DHCP-Bindungen, eine für jede Familie, DHCPv4 und DHCPv6. Folglich sendet authd separate Zugriffsanfragen, wenn sich jede Familie in der Sitzung anmeldet oder versucht, sich erneut zu authentifizieren:

• Die familienspezifische Authentifizierung erfolgt, wenn eine Ermittlungs- oder Anforderungsnachricht empfangen wird, während sich eine Abonnentensitzung im DHCP-Init-Status befindet.

• Die familienspezifische Neuauthentifizierung erfolgt, wenn sowohl die erneute Authentifizierung als auch die bedarfsgesteuerte Adresszuweisung konfiguriert sind und eine Nachricht zum Erneuern, erneuten Binden, Ermitteln oder Anfordern für die Familiensitzung empfangen wird, während sie sich im DHCP-gebundenen Zustand befindet.

Sowohl die Authentifizierung als auch die erneute Authentifizierung werden pro Familie verarbeitet. Die erste Familie, die den Prozess auslöst, wird betreut, bevor die andere (zweite) Familie die Authentifizierung oder erneute Authentifizierung auslöst. Nachrichten aus der zweiten Familie werden ignoriert, bis die erste Familie gebunden ist. Dann wird die zweite Familienanfrage bearbeitet.

Wenn sich nur eine Familie der Dual-Stack-Einzelsitzung anmeldet, wird nur eine Authentifizierung verarbeitet. Erneute Authentifizierungen werden nur für die eine Clientfamilie verarbeitet.

Der authd-Prozess klassifiziert Attribute als zur DHCPv4- oder DHCPv6-Familie gehörend und kennzeichnet sie entsprechend. Sowohl für die Authentifizierung als auch für die erneute Authentifizierung, je nachdem, welche Familie die Anforderung initiiert, enthält authd entweder die DHCP-Optionen VSA (26-55) oder die DHCPv6-Optionen VSA (26-65). Abhängig von seiner Konfiguration gibt der RADIUS-Server möglicherweise Informationen nur für die Familie zurück, die die Anforderung initiiert hat (die anfordernde Familie) oder für beide Familien.

Wenn authd Attribute in der Access-Accept-Nachricht empfängt, können die Familien-Tags feststellen, welche Attribute der anfordernden Familie oder der anderen (nicht anfordernden) Familie entsprechen. Nur Attribute für die anfordernde Familie werden in die Sitzungsdatenbank geschrieben.

Bei Anforderungen zur erneuten Authentifizierung vergleicht authd die zurückgegebenen Attribute mit der Sitzungsdatenbank, um festzustellen, ob Änderungen auf dem RADIUS-Server vorgenommen wurden. Auch hier werden nur Änderungen, die der anfordernden Familie entsprechen, in die Sitzungsdatenbank geschrieben, wodurch die alten Werte überschrieben werden.

Änderungen während der erneuten Authentifizierung werden wie folgt verarbeitet:

• Attribut (außer Adresse) – Wenn authd feststellt, dass sich eines oder mehrere dieser Attribute für die anfordernde Familie geändert haben, werden die neuen Werte in der Sitzungsdatenbank gespeichert. Nachdem authd jdhcpd benachrichtigt hat, sendet es eine Bestätigung mit den neuen Attributwerten an den DHCP-Client.

• Adresse oder Adresspool: Wenn authd eine Änderung für die anfordernde Familie erkennt, benachrichtigt es den lokalen DHCP-Server, der wiederum eine NAK (DHCPv4) oder logische NAK (DHCPv6) an den DHCP-Client sendet.

  Wenn die anfordernde Familie die einzige Familie ist, die gebunden ist, meldet jdhcpd den Abonnenten ordnungsgemäß ab. Wenn die nicht anfordernde Familie ebenfalls gebunden ist, deaktiviert jdhcpd die anfordernde Familie, lässt die nicht anfordernde Familienbindung jedoch intakt, ohne dass der Dienst für die nicht anfordernde Familie unterbrochen wird. Die Deaktivierung der anfordernden Familie hat keine Auswirkungen auf ein anschließendes Auslösen der erneuten Authentifizierung durch die nicht anfordernde Familie.

  Wenn die deaktivierte Familie anschließend eine Discover- oder Request-Nachricht sendet, um sich wieder anzumelden, wird wie gewohnt ein Access-Request zur erneuten Authentifizierung gesendet, und die neue Adresse, die in der Access-Accept-Datei empfangen wurde, wird auf den Abonnenten angewendet.

Wenn der RADIUS-Server auf eine Authentifizierungs- oder erneute Authentifizierungsanforderung mit einer Access-Reject-Nachricht antwortet, benachrichtigt authd den lokalen DHCP-Server, der wiederum einen NAK (DHCPv4) oder einen logischen NAK (DHCPv6) an den DHCP-Client sendet. Die anfordernde Familie wird ordnungsgemäß beendet. Die Familie wird deaktiviert und der Abonnent wird abgemeldet. Dann wird die nicht anfordernde Familie deaktiviert und abgemeldet, aber der Client wird nicht über die Beendigung informiert.

Wenn die Lebenderkennung für die nicht anfordernde Familie ausgeführt wird, erkennt der Client den Verbindungsverlust, wenn die Familie beendet wird, und sendet anschließend eine Ermittlungs- oder Anforderungsnachricht an den lokalen DHCP-Server. Wenn die Lebendigkeitserkennung jedoch nicht ausgeführt wird, erkennt der Client den Verbindungsverlust erst, wenn die Zeit für die erneute Bindung (T2, Option 59) abgelaufen ist und der Dienst unterbrochen wird. Je nach Laufzeit des Mietvertrags kann dies lange dauern.

Paketfluss

In der folgenden Abbildung wird die Reihenfolge für die anfängliche Aushandlung einer Abonnentensitzung zwischen einem DHCP-Client, einem DHCP-Server und dem RADIUS-Server beschrieben. Der Serviceplan des Clients wird in der zweiten Teilzeichenfolge in der Remote-ID angegeben, die in DHCPv4-Option 82, Unteroption 2 oder DHCPv6-Option 37 enthalten ist.

• Erste Verhandlungen
• Änderung des Serviceplans

Erste Verhandlungen

Abbildung 1 veranschaulicht die Abfolge der Schritte bei der anfänglichen Aushandlung zwischen einem DHCP-Client, einem DHCP-Server und dem RADIUS-Server. In der Abbildung werden die folgenden Begriffe verwendet:

CPE – Customer Premises Equipment (fungiert als DHCP-Client oder -Abonnent).

OLT – Optischer Leitungsabschlussator, z. B. ein DSL-Zugriffsmultiplexer (DSLAM) oder ein anderes Aggregationsgerät.

Gerät der MX-Serie: Fungiert als DHCP-Server.

Abbildung 1: Erste Verhandlungen

Änderung des Serviceplans

Abbildung 2 zeigt die Abfolge der Schritte bei einem Wechsel von Dienstplänen von einem 100-Mbit/s-Plan zu einem 1-Gbit/s-Plan:

Abbildung 2: Serviceplan

Für die erneute Authentifizierung unterstützte RADIUS-Attribute

Tabelle 2 listet die RADIUS-Standardattribute und VSAs auf, die während der erneuten Authentifizierung verarbeitet werden können, wenn sie in der RADIUS-Access-Accept-Nachricht empfangen werden, und beschreibt, wie authd Änderungen an Attributen verarbeitet. Die Attributverarbeitung ist konsistent mit der Verarbeitung von CoA-Anforderungen. Die Merkmale der sich erneut authentifizierenden Abonnentensitzung ändern sich nur, wenn neue Werte oder neue Attribute in der Access-Accept-Nachricht empfangen werden.