RADIUS Reauthentication als Alternative zu RADIUS CoA für DHCP-Anwender

Vorteile der erneuten Authentifizierung

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

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

• Ermöglichen Sie die erneute Authentifizierung pro Familie 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 Erkennungs- und Anforderungsnachrichten unterstützen die erneute Authentifizierung ab Junos OS Version 18.1R1. Die Unterstützung für die Erkennungs- und Abrufmeldungen 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 authd ermöglicht, alle Aktualisierungen abzurufen, die für den Anwender vorgenommen wurden.

Das Verhalten bei 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 eine erneute Authentifizierung nur ausgelöst wird, wenn die empfangene Nachricht eine Änderung des Werts der Remote-ID des DHCP-Clients enthält. Der Attributwert enthält den Namen des Anwender-Serviceplans, sodass eine Wertänderung eine Änderung des Dienstes für den Anwender bedeutet.

• Wenn der VSA von Juniper Networks reauthentication-on-renew (26-206) mit dem Wert 1 in der Access-Accept-Nachricht vom RADIUS-Server für den Anwender bei der Anmeldung zurückgegeben wird, löst er eine erneute Authentifizierung nach Erhalt einer der vier Nachrichten aus. Der Wert 0 deaktiviert die erneute Authentifizierung. Der VSA-Wert wird bei jedem Empfang in der Sitzungsdatenbank gespeichert. 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 erneute Authentifizierungsprozess für diesen Anwender beendet.

  Die CLI-Konfiguration (reauthenticate Anweisung) und das Verhalten von Reauthenticate-On-Renew sind additiv. Das Deaktivieren der erneuten Authentifizierung mit dem VSA hat nur Auswirkungen, wenn die reauthenticate Anweisung nicht konfiguriert ist. Wenn die Anweisung mit einer der reauthenticate beiden Optionen konfiguriert ist, überschreibt sie den VSA-Wert 0. Wenn die CLI-Konfiguration fehlt, kann der VSA die erneute Authentifizierung selbst aktivieren.

Der Prozess der erneuten Authentifizierung ist nahezu identisch mit dem ursprünglichen Prozess der Authentifizierung. Wenn eine erneute Authentifizierung ausgelöst wird, sendet der jdhcpd-Prozess auf dem lokalen Server eine Authentifizierung an authd, das 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 Anforderung zur erneuten Authentifizierung von Anmeldeanforderungen (Authentifizierung) zu unterscheiden.

Der RADIUS-Server gibt eine Access-Accept-Nachricht mit neuen Attributen für den Anwender 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, wie in Abbildung 1 dargestellt, und die Sitzung des Anwenders 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 das CPE, auf dem der DHCP-Client gehostet wird, während der Änderung eines Serviceplans 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 einen NAK an jdhcpd, der den enthaltenen Fehlercode überprüft. Wenn der Fehlercode auf eine Zeitüberschreitung hinweist, sendet jdhcpd eine Bestätigung an den DHCP-Client, und die Anwendersitzung wird mit den ursprünglichen Attributen und dem ursprünglichen Service beibehalten. Bei jedem anderen Fehlercode sendet jdhcpd eine DHCPv4-NAK- oder DHCPv6-ANTWORT (mit dem Lifetime-Wert auf 0) als logisches NAK, initiiert die Abmeldung des Anwenders und löscht den Anwender aus der Sitzungsdatenbank.

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

Wenn die erneute Authentifizierung zu einer Änderung der IP- oder IPv6-Adresse eines DHCPv6-Anwenders 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 zusätzlich zu den zuvor unterstützten Codes für NoAddrsAvail und NoPrefixAvail ein Statuscode für NotOnLink unterstützt, wenn der DHCPv6-Server ein Problem mit der Adresse erkennt. Diese Statuscodes sind wie folgt definiert:

• NoAddrsAvail (2): Der Server kann in der Clientanforderung keine Adressen für die IA zuweisen. Es 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 einer IA in der Clientanforderung für die Verbindung, die eine Verbindung zum Client herstellt, nicht geeignet ist. Dieser Code wird auch im Falle eines Fehlers bei der erneuten Authentifizierung (RADIUS Access-Reject) verwendet.

• NoPrefixAvail (6): Der Server verfügt über keine Präfixe für die IA in der Clientanforderung.

Wenn der Client den NotOnLink-Statuscode empfängt, kann er eine weitere Anfrage ohne Adressen senden oder den Aushandlungsprozess neu starten. Wenn er eine Anforderung sendet, 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 Clientsitzungen behandelt. Jeder Stack erneuert sich und erhält unabhängig neue Services.

Ab Junos OS Version 18.1R1 werden die Authentifizierung und erneute Authentifizierung pro Familie für Dual-Stack-Abonnenten mit einer Sitzung unterstützt. Ein Dual-Stack-Single-Session-Anwender ist in der Regel ein Haushalt mit eigenem VLAN in einem 1:1-Zugriffsmodell. Der Haushalt wird als einzelner Anwender 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 familienübergreifende Authentifizierung erfolgt, wenn eine Ermittlungs- oder Abrufnachricht empfangen wird, während sich eine Anwendersitzung im DHCP-Init-Status befindet.

• Eine erneute Authentifizierung pro Familie erfolgt, wenn sowohl die erneute Authentifizierung als auch die Adresszuweisung nach Bedarf 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 behandelt, 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 enthält authd je nachdem, welche Familie die Anforderung initiiert, entweder die DHCP-Optionen VSA (26-55) oder die DHCPv6-Optionen VSA (26-65). Je nach Konfiguration gibt der RADIUS-Server möglicherweise nur Informationen 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 von authd bestimmen, 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 am 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 address) – Wenn authd feststellt, dass sich eines oder mehrere dieser Attribute für die anfordernde Familie geändert haben, speichert es die neuen Werte in der Sitzungsdatenbank. 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 einen NAK (DHCPv4) oder einen logischen NAK (DHCPv6) an den DHCP-Client sendet.

  Wenn die anfordernde Familie die einzige Familie ist, die gebunden ist, meldet jdhcpd den Anwender ordnungsgemäß ab. Wenn die nicht anfordernde Familie ebenfalls gebunden ist, deaktiviert jdhcpd die anfragende Familie, lässt aber die nicht anfordernde Familienbindung intakt, ohne dass der Dienst an der nicht anfragenden Familie unterbrochen wird. Die Deaktivierung der anfordernden Familie hat keine Auswirkungen auf ein nachträgliches Auslösen der erneuten Authentifizierung durch die nicht anfordernde Familie.

  Wenn die deaktivierte Familie anschließend eine Discover- oder Request-Nachricht zur erneuten Anmeldung sendet, wird wie üblich eine Access-Anfrage zur erneuten Authentifizierung gesendet, und die neue Adresse, die im Access-Accept empfangen wird, wird auf den Anwender 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 antragstellende Familie wird würdevoll beendet; Die Familie ist deaktiviert und der Anwender ist abgemeldet. Dann wird die nicht anfordernde Familie deaktiviert und abgemeldet, aber der Client wird nicht über die Kündigung informiert.

Wenn die Lebendigkeitserkennung 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 Abrufnachricht an den lokalen DHCP-Server. Wenn die Gefahrenerkennung jedoch nicht ausgeführt wird, erkennt der Client den Verbindungsverlust erst, wenn die erneute Bindung (T2, Option 59) abläuft und der Dienst verloren geht. Je nach Dauer des Mietvertrags kann dies lange dauern.

Paket-Flow

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

• Erste Verhandlung
• Änderung des Serviceplans

Erste Verhandlung

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

CPE – Gerät am Kundenstandort (fungiert als DHCP-Client oder -Anwender).

OLT – Optical Line Terminator – z. B. ein DSL-Zugriffsmultiplexer (DSLAM) oder ein anderes Aggregationsgerät.

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

Abbildung 1: Erste Verhandlung

Änderung des Serviceplans

Abbildung 2 veranschaulicht die Abfolge der Schritte bei einem Wechsel der Servicepläne, 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 behandelt. Die Attributverarbeitung ist konsistent mit der Verarbeitung von CoA-Anforderungen. Die Merkmale der erneut authentifizierenden Anwendersitzung ändern sich nur, wenn neue Werte oder neue Attribute in der Access-Accept-Nachricht empfangen werden.