DHCP加入者向けRADIUS CoAの代替としてのRADIUS再認証RADIUS

再認証のメリット

• CoA要求を使用せずに、加入者セッション属性とサービスプランを更新または変更します。

• 加入者主導の頻繁な変更によるサービスのアクティベーションを簡素化します。

• デュアルスタック、シングルセッション構成でファミリーごとの再認証を有効にします。

• CLI設定またはRADIUS VSAを介して再認証を制御します。

機能性

再認証は、DHCPv4とDHCPv6の両方でサポートされています。これは、DHCPローカルサーバーがDHCPクライアントから更新、再バインド、検出、または送信請求のメッセージを受信したときにトリガーできます。検出メッセージと送信メッセージは、Junos OSリリース18.1R1以降で再認証をサポートします。検出メッセージと要請メッセージのサポートとは、クライアントがバインドされたCPEが再起動し、クライアントがこれらのメッセージのいずれかを送信してセッションを復旧した場合、再認証により、Authdが加入者に対して行われた更新を取得できることを意味します。

再認証の動作は、以下のように決定されます。

• reauthenticate lease-renewalステートメントは、サポートされている4つのメッセージのいずれかを受信したときに再認証がトリガーされることを指定します。

• reauthenticate remote-id-mismatchステートメントは、受信したメッセージにDHCPクライアントのエージェントリモートIDの値の変更が含まれている場合にのみ再認証がトリガーされることを指定します。属性値には加入者サービスプランの名前が含まれているため、値の変更は加入者向けサービスの変更を意味します。

• VSA(26-206) reauthentication-on-renew ジュニパーネットワークスは、ログイン時の加入者に対してRADIUSサーバーからのAccess-Acceptメッセージに値1で返された場合、4つのメッセージのいずれかを受信すると再認証をトリガーします。値が0の場合、再認証は無効になります。VSA値は、受信するたびにセッションデータベースに保存されます。このVSAが再認証を有効にすると、再認証を試みるたびにチェックされます。値が0に変更された場合(つまり、後続のAccess-Acceptが値0のVSAを返した場合)、その加入者に対する再認証プロセスは停止します。

  CLI設定(reauthenticate ステートメント)とReauthenticate-On-Renew動作は追加的です。VSA による再認証の無効化は、 reauthenticate ステートメントが設定されていない場合にのみ有効です。 reauthenticate ステートメントにいずれかのオプションが設定されている場合、VSA値0が上書きされます。CLI設定がない場合、VSA自体で再認証を有効にすることができます。

再認証プロセスは、元の認証プロセスとほぼ同じです。再認証がトリガーされると、ローカルサーバー上のjdhcpdプロセスが認証要求をauthdに送信し、次にauthdがAccess-RequestメッセージをRADIUSサーバーに送信して2つ目の認証を要求します。

注:

再認証リクエストは、 radius または none以外の認証順序では失敗します。authdプロセスは、そのような要求に対して否定的な確認応答(NAK)を返します。

このAccess-Requestには、元のAccess-Acceptメッセージで返されたRADIUSの状態とクラス属性が含まれています。これらの属性により、RADIUSサーバーは再認証要求とログイン(認証)要求を区別できます。

RADIUSサーバーは、加入者の新しい属性を使用して、Access-Acceptメッセージをauthdに返します。authdプロセスは、jdhcpdへの変更を含む確認応答(ACK)を送信し、jdhcpdは属性が変更されたDHCPオファーをDHCPクライアントに送信します。 図 1 に示すように、DHCP ネゴシエーションは通常通りに続行され、加入者セッションは新しい属性値で続行されます。再認証にサービスプランの変更が含まれる場合、RADIUSサーバーは、 図2に示すように、要求を受け入れると、その他の変更された属性を含む新しいプランを返します。サービスプランの変更プロセス中にDHCPクライアントをホストしているCPEが再起動した場合、サービスを中断することなく、新しいプランでの再認証がサポートされます。

RADIUSサーバーが再認証リクエストを拒否するか、タイムアウトした場合、authdはNAKをjdhcpdに送信し、jdhcpdは含まれているエラーコードを確認します。エラーコードがタイムアウトを示している場合、jdhcpdはDHCPクライアントにACKを送信し、加入者セッションは元の属性とサービスで維持されます。その他のエラーコードの場合、jdhcpdはDHCPv4 NAKまたはDHCPv6 REPLY(ライフタイム値を0に設定)を論理NAKとして送信し、加入者のログアウトを開始し、セッションデータベースから加入者を削除します。

表1は、同じ加入者に対して異なるリクエストタイプがすでに進行中の場合に、authdがリクエストを処理する方法を示しています。

表1:複数のリクエストタイプの処理

リクエスト処理中	同じ加入者に対して追加リクエストを受信しました	アクション
再認証	CoA	authd は NAK で CoA に応答します。
CoA	再認証	authdは、CoAが処理されるまで再認証リクエストをキューに入れ、その後再認証リクエストを処理します。
再認証	切断	authd は切断に対して NAK で応答します。
切断	再認証	authdはNAKで再認証要求に応答し、加入者をログアウトし続けます。

ベストプラクティス:

ネットワークファミリーは再認証の一環として終了または再起動されないため、加入者コンテンツは加入者のセキュアポリシーミラーリングに関して再評価されません。再認証処理中に変更される可能性のある属性をミラーリングする加入者セキュアポリシーのトリガーとして使用しないでください。

クライアントがバインドされた後、再認証の結果、DHCPv6加入者のIPアドレスまたはIPv6アドレスが変更された場合、DHCPv6サーバーはアドレス変更リクエストを評価します。サーバーは、応答PDUのIDアソシエーション(IA)内のクライアントにステータスコードを返します。Junos OS リリース 18.4R1 以降、DHCPv6 サーバーがアドレスの問題を発見すると、以前サポートされていた NoAddrsAvail と NoPrefixAvail のコードに加えて、NotOnLink のステータス コードもサポートされます。これらのステータスコードは、次のように定義されています。

• NoAddrsAvail(2)—サーバーは、クライアント要求でIAにアドレスを割り当てることができません。アドレスとNoAddrsAvailなしでIAを返します。

• NotOnLink(4)—サーバーは、クライアント要求内の任意のIAの1つ以上のアドレスのプレフィックスが、クライアントに接続するリンクに適していないと判断します。このコードは、再認証エラー(RADIUS Access-Reject)が発生した場合にも使用されます。

• NoPrefixAvail(6)—サーバーには、クライアント要求のIAに使用できるプレフィックスがありません。

クライアントが NotOnLink 状態コードを受信した場合、アドレスなしで別の要求を送信するか、ネゴシエーション プロセスを再開できます。DHCPv6ローカルサーバーが要求を送信した場合、DHCPv6ローカルserは要求を無視し、新しい再ネゴシエーションが開始されることを期待します。

デュアルスタック加入者

Junos OSリリース18.1R1より前のリリースでは、デュアルスタックDHCP加入者は独立したクライアントセッションとして扱われます。各スタックは独立して更新され、新しいサービスを取得します。

Junos OSリリース18.1R1以降、デュアルスタックのシングルセッション加入者に対して、ファミリーごとの認証と再認証がサポートされます。デュアルスタック、シングルセッション加入者とは、通常、1:1アクセスモデルで独自のVLANを持つ世帯を指します。世帯は、セッションデータベースに1つのセッションを持つ単一の加入者として表されますが、DHCPv4とDHCPv6の各ファミリーに1つずつ、2つの個別のDHCPバインディングがあります。その結果、セッション内の各ファミリーがログインするか、再認証を試みると、authdは個別のアクセス要求を送信します。

• ファミリーごとの認証は、加入者セッションがDHCP初期化状態のときに検出メッセージまたは要請メッセージを受信した場合に行われます。

• ファミリーごとの再認証は、再認証とオンデマンドアドレス割り当ての両方が設定されており、DHCPバインド状態のときにファミリーセッションの更新、再バインド、検出、または要求メッセージが受信された場合に発生します。

注:

オンデマンドアドレス割り当てでは、ログイン時に各ファミリーに個別にアドレスが割り当てられます。デュアルスタック、シングルセッション加入者に対してオンデマンドアドレス割り当てを設定するか、ファミリーごとの認証を行う必要があり、再認証を有効にすることはできません。再認証の場合、これは CLI で設定されているか、Reauthenticate-On-Renew VSA(26-206)で設定されているかに関わらず当てはまります。

認証と再認証はどちらもファミリーごとに処理されます。プロセスをトリガーした最初のファミリーは、もう一方(2番目の)ファミリーが認証または再認証をトリガーする前に処理されます。2番目のファミリーからのメッセージは、最初のファミリーがバインドされるまで無視されます。その後、2 番目のファミリー要求が処理されます。

デュアルスタックシングルセッションのファミリーが1つだけログインした場合、1つの認証のみが処理されます。再認証は、1つのクライアントファミリーに対してのみ処理されます。

authdプロセスは、属性をDHCPv4またはDHCPv6ファミリーに属するものとして分類し、それに応じてタグ付けします。認証と再認証の両方で、リクエストを開始するファミリに応じて、authdにはDHCP-Options VSA(26-55)またはDHCPv6-Options VSA(26-65)のいずれかが含まれます。設定によっては、RADIUSサーバーがリクエストを開始したファミリー( リクエスト側ファミリー)のみの情報を返すか、両方のファミリーの情報を返す場合があります。

authdがAccess-Acceptメッセージで属性を受信すると、ファミリータグを使用して、authdがどの属性がリクエスト側ファミリーまたは他の(非リクエスト側)ファミリーに対応するかを判断できます。要求元ファミリーの属性のみがセッション・データベースに書き込まれます。

再認証リクエストの場合、authdは返された属性をセッションデータベースと比較し、RADIUSサーバーに変更が加えられたかどうかを判断します。ここでも、要求元のファミリに対応する変更のみがセッションデータベースに書き込まれ、古い値が上書きされます。

再認証中の変更は、以下のように処理されます。

• 属性(アドレス以外)—リクエスト元ファミリーに対してこれらの属性の1つ以上が変更されたとauthdが判断すると、新しい値をセッションデータベースに保存します。authdがjdhcpdに通知した後、新しい属性値を含むACKをDHCPクライアントに送信します。

• アドレスまたはアドレスプール—authdがリクエスト元ファミリーの変更を検出すると、DHCPローカルサーバーに通知し、次にNAK(DHCPv4)または論理NAK(DHCPv6)をDHCPクライアントに送信します。

  リクエスト元のファミリーがバインドされている唯一のファミリーである場合、jdhcpd は加入者を正常にログアウトします。非要求ファミリーもバインドされている場合、jdhcpd は要求ファミリーを非アクティブ化しますが、非要求ファミリーへのサービスが中断されることなく、非要求ファミリーのバインディングはそのまま残されます。要求側ファミリーの非アクティブ化は、その後の非要求側ファミリーによる再認証のトリガーには影響しません。

  非アクティブ化されたファミリーがその後、再びログインするための検出メッセージまたは要請メッセージを送信すると、通常通り再認証のためにアクセスリクエストが送信され、アクセスアクセプトで受信した新しいアドレスが加入者に適用されます。

RADIUSサーバーが認証または再認証要求にAccess-Rejectメッセージで応答すると、authdはDHCPローカルサーバーに通知し、DHCPローカルサーバーがNAK(DHCPv4)または論理NAK(DHCPv6)をDHCPクライアントに送信します。リクエスト元のファミリーは正常に終了します。ファミリーは非アクティブ化され、加入者はログアウトされます。その後、非要求ファミリーは非アクティブ化され、ログアウトされますが、クライアントには終了について通知されません。

非要求ファミリでライブネス検出が実行されている場合、クライアントはファミリーが終了したときに接続の喪失を検出し、その後、DHCPローカルサーバーに検出メッセージまたは送信請求メッセージを送信します。ただし、ライブネス検出が実行されていない場合、クライアントは、リバインド時間(T2、オプション59)が終了し、サービスが失われるまで、接続の喪失を検出しません。リースの期間によっては、これに時間がかかる場合があります。

ベストプラクティス:

両方のアドレスファミリーのライブネス検出を設定して、接続損失を検出する時間を短縮します。ライブネス検出の設定については、 DHCPライブネス検出の概要 を参照してください。

パケットフロー

次の図は、DHCP クライアント、DHCP サーバー、および RADIUS サーバー間の加入者セッションの初期ネゴシエーションのシーケンスを示しています。クライアントのサービスプランは、DHCPv4オプション82、サブオプション2、またはDHCPv6オプション37に含まれるリモートIDの2番目の部分文字列で指定されます。

• 最初のネゴシエーション
• サービスプランの変更

再認証でサポートされるRADIUS属性

表2は、RADIUS Access-Acceptメッセージで受信した場合に再認証中に処理できるRADIUS標準属性とVSAを示し、属性の変更をauthdがどのように処理するかを示しています。属性処理は、CoA リクエスト処理と一致しています。再認証加入者セッションの特性は、Access-Acceptメッセージで新しい値または新しい属性を受信した場合にのみ変更されます。

表2:再認証でサポートされているRADIUS属性

属性番号	属性名	処理の結果
8	フレーム化されたIPアドレス	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
22	フレームルート	新しい値が加入者セッションデータベースに保存されます。古いデータが追加されます。
24	状態	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
25	クラス	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
26-4	プライマリDNS	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
26-5	セカンダリDNS	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
26-6	プライマリWINS	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
26-7	セカンダリWINS	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
26-55	DHCP オプション	加入者のDHCP設定への変更を処理するために、値がDHCPローカルサーバーに送信されます。
26-65	サービスアクティベーション	認証プロセスは、VSA内のサービスのリストを、その加入者セッションですでにアクティブなサービスと比較します。 VSAのリストにまだアクティブでないサービスが含まれている場合、authdは加入者のためにそれらのサービスを有効にします。 加入者セッションですでにアクティブなサービスがVSAにリストされていない場合、authdはそのサービスを非アクティブ化します。 例えば、サービスAとBがセッションでアクティブであるが、VSAにはサービスBとCしか含まれていないとします。サービスAはVSAリストにないため、非アクティブ化されています。サービスCはリストにありますが、現在はアクティブではないため、authdはCをアクティブにします。サービスBはすでにアクティブでリストに載っているため、アクティブなままです。
26-161	IPv6-Delegated-Pool-Name	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
26-206	更新時の再認証	値が1(有効)の場合、authdは、値がまだ存在しない場合、加入者セッションデータベースに追加します。 値が 0(無効)で、値 1 がデータベースにすでに存在する場合、authd はデータベース値を 0 に設定します。 メッセージ内の値が欠落しているか無効で、値がデータベースにすでに存在する場合、authd はデータベースから値を削除します。
26-207	DHCPv6-オプション	値は、加入者のDHCP設定への変更を処理するためにDHCPv6ローカルサーバーに送信されます。
88	フレームプール	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
97	Framed-IPv6-Prefix	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
100	フレームIPv6プール	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
123	Delegated-IPv6-Prefix	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。
168	フレーム化されたIPv6アドレス	新しい値が加入者セッションデータベースに保存されます。古いデータは上書きされます。