[要約] RFC 7499は、RADIUSパケットのフラグメンテーションのサポートに関する規格です。その目的は、大きなRADIUSパケットを複数の小さなパケットに分割して送信することで、ネットワークの効率性と信頼性を向上させることです。
Internet Engineering Task Force (IETF) A. Perez-Mendez, Ed.
Request for Comments: 7499 R. Marin-Lopez
Category: Experimental F. Pereniguez-Garcia
ISSN: 2070-1721 G. Lopez-Millan
University of Murcia
D. Lopez
Telefonica I+D
A. DeKok
Network RADIUS
April 2015
Support of Fragmentation of RADIUS Packets
RADIUSパケットのフラグメンテーションのサポート
Abstract
概要
The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.
リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルは、パケットサイズの合計が4096バイトに制限されています。 Access-Challengeパケットを介して、複数のパケットにわたって大量の認証データをフラグメント化するための規定が存在します。大量の承認データを断片化するための同様の規定はありません。このドキュメントでは、既存のRADIUSメカニズムを利用してその機能を提供する方法を説明します。これらのメカニズムは既存の実装とほぼ互換性があり、プロキシからは見えないように設計されており、レガシーRADIUSクライアントおよびサーバーに対しては「フェイルセーフ」です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7499.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7499で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Language ......................................6
2. Status of This Document .........................................6
3. Scope of This Document ..........................................7
4. Overview .......................................................10
5. Fragmentation of Packets .......................................13
5.1. Pre-Authorization .........................................14
5.2. Post-Authorization ........................................18
6. Chunk Size .....................................................21
7. Allowed Large Packet Size ......................................22
8. Handling Special Attributes ....................................23
8.1. Proxy-State Attribute .....................................23
8.2. State Attribute ...........................................24
8.3. Service-Type Attribute ....................................25
8.4. Rebuilding the Original Large Packet ......................25
9. New T Flag for the Long Extended Type Attribute Definition .....26
10. New Attribute Definition ......................................26
10.1. Frag-Status Attribute ....................................27
10.2. Proxy-State-Length Attribute .............................28
10.3. Table of Attributes ......................................29
11. Operation with Proxies ........................................29
11.1. Legacy Proxies ...........................................29
11.2. Updated Proxies ..........................................29
12. General Considerations ........................................31
12.1. T Flag ...................................................31
12.2. Violation of RFC 2865 ....................................32
12.3. Proxying Based on User-Name ..............................32
12.4. Transport Behavior .......................................33
13. Security Considerations .......................................33
14. IANA Considerations ...........................................34
15. References ....................................................35
15.1. Normative References .....................................35
15.2. Informative References ...................................35
Acknowledgements ..................................................37
Authors' Addresses ................................................37
The RADIUS [RFC2865] protocol carries authentication, authorization, and accounting information between a RADIUS Client and a RADIUS Server. Information is exchanged between them through RADIUS packets. Each RADIUS packet is composed of a header, and zero or more attributes, up to a maximum packet size of 4096 bytes. The protocol is a request/response protocol, as described in the operational model ([RFC6158], Section 3.1).
RADIUS [RFC2865]プロトコルは、RADIUSクライアントとRADIUSサーバーの間で認証、承認、およびアカウンティング情報を伝送します。情報は、RADIUSパケットを介してそれらの間で交換されます。各RADIUSパケットは、ヘッダーと0個以上の属性で構成され、最大パケットサイズは4096バイトです。運用モデル（[RFC6158]、セクション3.1）で説明されているように、プロトコルは要求/応答プロトコルです。
The intention of the above packet size limitation was to avoid UDP fragmentation as much as possible. Back then, a size of 4096 bytes seemed large enough for any purpose. Now, new scenarios are emerging that require the exchange of authorization information exceeding this 4096-byte limit. For instance, the Application Bridging for Federated Access Beyond web (ABFAB) IETF working group defines the transport of Security Assertion Markup Language (SAML) statements from the RADIUS Server to the RADIUS Client [SAML-RADIUS]. This assertion is likely to be larger than 4096 bytes.
上記のパケットサイズ制限の目的は、UDPフラグメンテーションをできるだけ回避することでした。当時、4096バイトのサイズは、どんな目的にも十分な大きさでした。現在、この4096バイトの制限を超える認証情報の交換を必要とする新しいシナリオが出現しています。たとえば、Webを超えるフェデレーションアクセスのアプリケーションブリッジング（ABFAB）IETFワーキンググループは、RADIUSサーバーからRADIUSクライアントへのセキュリティアサーションマークアップ言語（SAML）ステートメントのトランスポートを定義します[SAML-RADIUS]。このアサーションは、4096バイトを超える可能性があります。
This means that peers desiring to send large amounts of data must fragment it across multiple packets. For example, RADIUS-EAP [RFC3579] defines how an Extensible Authentication Protocol (EAP) exchange occurs across multiple Access-Request / Access-Challenge sequences. No such exchange is possible for accounting or authorization data. [RFC6158], Section 3.1 suggests that exchanging large amounts of authorization data is unnecessary in RADIUS. Instead, the data should be referenced by name. This requirement allows large policies to be pre-provisioned and then referenced in an Access-Accept. In some cases, however, the authorization data sent by the RADIUS Server is large and highly dynamic. In other cases, the RADIUS Client needs to send large amounts of authorization data to the RADIUS Server. Neither of these cases is met by the requirements in [RFC6158]. As noted in that document, the practical limit on RADIUS packet sizes is governed by the Path MTU (PMTU), which may be significantly smaller than 4096 bytes. The combination of the two limitations means that there is a pressing need for a method to send large amounts of authorization data between RADIUS Client and Server, with no accompanying solution.
つまり、大量のデータを送信したいピアは、複数のパケットにまたがってデータをフラグメント化する必要があります。たとえば、RADIUS-EAP [RFC3579]は、複数のAccess-Request / Access-Challengeシーケンス間で拡張認証プロトコル（EAP）交換がどのように行われるかを定義します。このような交換は、アカウンティングまたは許可データに対しては不可能です。 [RFC6158]、セクション3.1は、RADIUSでは大量の認証データを交換する必要がないことを示唆しています。代わりに、データは名前で参照する必要があります。この要件により、大規模なポリシーを事前にプロビジョニングして、Access-Acceptで参照できます。ただし、場合によっては、RADIUSサーバーから送信される認証データが大きく、非常に動的です。それ以外の場合、RADIUSクライアントは大量の認証データをRADIUSサーバーに送信する必要があります。これらのケースはどちらも[RFC6158]の要件を満たしていません。そのドキュメントに記載されているように、RADIUSパケットサイズの実際的な制限は、4096バイトより大幅に小さいパスMTU（PMTU）によって制御されます。 2つの制限の組み合わせにより、RADIUSクライアントとサーバー間で大量の承認データを送信する方法が緊急に必要になり、付随するソリューションはありません。
[RFC6158], Section 3.1 recommends three approaches for the transmission of large amounts of data within RADIUS. However, they are not applicable to the problem statement of this document for the following reasons:
[RFC6158]、セクション3.1では、RADIUS内で大量のデータを送信するための3つのアプローチを推奨しています。ただし、次の理由により、これらはこのドキュメントの問題ステートメントには適用されません。
o The first approach (utilization of a sequence of packets) does not talk about large amounts of data sent from the RADIUS Client to a RADIUS Server. Leveraging EAP (request/challenge) to send the data is not feasible, as EAP already fills packets to PMTU, and not all authentications use EAP. Moreover, as noted for the NAS-Filter-Rule attribute ([RFC4849]), this approach does not entirely solve the problem of sending large amounts of data from a RADIUS Server to a RADIUS Client, as many current RADIUS attributes are not permitted in Access-Challenge packets.
o 最初のアプローチ（一連のパケットの利用）では、RADIUSクライアントからRADIUSサーバーに送信される大量のデータについては触れていません。 EAP（要求/チャレンジ）を利用してデータを送信することはできません。EAPはすでにPMTUにパケットを満たしているため、すべての認証でEAPが使用されるわけではないためです。さらに、NAS-Filter-Rule属性（[RFC4849]）で述べたように、このアプローチでは、RADIUSサーバーからRADIUSクライアントに大量のデータを送信する問題が完全には解決されません。 Access-Challengeパケット。
o The second approach (utilization of names rather than values) is not usable either, as using names rather than values is difficult when the nature of the data to be sent is highly dynamic (e.g., a SAML statement or NAS-Filter-Rule attributes). URLs could be used as a pointer to the location of the actual data, but their use would require them to be (a) dynamically created and modified, (b) securely accessed, and (c) accessible from remote systems. Satisfying these constraints would require the modification of several networking systems (e.g., firewalls and web servers). Furthermore, the setup of an additional trust infrastructure (e.g., Public Key Infrastructure (PKI)) would be required to allow secure retrieval of the information from the web server.
o 送信されるデータの性質が非常に動的な場合（SAMLステートメントまたはNAS-Filter-Rule属性など）、値ではなく名前を使用することが難しいため、2番目のアプローチ（値ではなく名前の使用）も使用できません。 。 URLは、実際のデータの場所へのポインターとして使用できますが、その使用には、（a）動的に作成および変更され、（b）安全にアクセスされ、（c）リモートシステムからアクセスできる必要があります。これらの制約を満たすには、いくつかのネットワークシステム（ファイアウォールやWebサーバーなど）の変更が必要になります。さらに、Webサーバーから情報を安全に取得するには、追加の信頼インフラストラクチャ（Public Key Infrastructure（PKI）など）のセットアップが必要になります。
o PMTU discovery does not solve the problem, as it does not allow the sending of data larger than the minimum of (PMTU or 4096) bytes.
o PMTUディスカバリーは、最小（PMTUまたは4096）バイトより大きいデータの送信を許可しないため、問題を解決しません。
This document provides a mechanism to allow RADIUS peers to exchange large amounts of authorization data exceeding the 4096-byte limit by fragmenting it across several exchanges. The proposed solution does not impose any additional requirements to the RADIUS system administrators (e.g., need to modify firewall rules, set up web servers, configure routers, or modify any application server). It maintains compatibility with intra-packet fragmentation mechanisms (like those defined in [RFC3579] or [RFC6929]). It is also transparent to existing RADIUS proxies, which do not implement this specification. The only systems needing to implement this RFC are the ones that either generate or consume the fragmented data being transmitted. Intermediate proxies just pass the packets without changes. Nevertheless, if a proxy supports this specification, it may reassemble the data in order to examine and/or modify it.
このドキュメントは、RADIUSピアが、4096バイトの制限を超える大量の許可データを、複数の交換でフラグメント化することで交換できるようにするメカニズムを提供します。提案されたソリューションは、RADIUSシステム管理者に追加の要件を課しません（たとえば、ファイアウォールルールの変更、Webサーバーの設定、ルーターの構成、またはアプリケーションサーバーの変更が必要です）。パケット内のフラグメンテーションメカニズム（[RFC3579]または[RFC6929]で定義されているような）との互換性を維持します。また、この仕様を実装していない既存のRADIUSプロキシに対して透過的です。このRFCを実装する必要がある唯一のシステムは、送信される断片化されたデータを生成または消費するシステムです。中間プロキシは、変更なしでパケットを渡すだけです。それにもかかわらず、プロキシがこの仕様をサポートしている場合、それを調べたり修正したりするためにデータを再構成することがあります。
A different approach to deal with RADIUS packets above the 4096-byte limit is described in [RADIUS-Larger-Pkts], which proposes to extend RADIUS over TCP by allowing the Length field in the RADIUS header to take values up to 65535 bytes. This provides a simpler operation, but it has the drawback of requiring every RADIUS proxy in the path between the RADIUS Client and the RADIUS Server to implement the extension as well.
4096バイトの制限を超えるRADIUSパケットを処理する別のアプローチは、[RADIUS-Larger-Pkts]で説明されています。これは、RADIUSヘッダーのLengthフィールドが最大65535バイトの値をとることを許可することにより、RADIUS over TCPを拡張することを提案しています。これはより簡単な操作を提供しますが、RADIUSクライアントとRADIUSサーバー間のパスにあるすべてのRADIUSプロキシにも拡張機能を実装する必要があるという欠点があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. When these words appear in lower case, they have their natural language meaning.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。これらの単語が小文字で表示される場合、それらは自然言語の意味を持っています。
This document is an Experimental RFC. It defines a proposal to allow the sending and receiving of data exceeding the 4096-byte limit in RADIUS packets imposed by [RFC2865], without requiring the modification of intermediary proxies.
このドキュメントは試験的なRFCです。 [RFC2865]によって課されたRADIUSパケットの4096バイトの制限を超えるデータの送受信を、中間プロキシの変更を必要とせずに許可するという提案を定義しています。
The experiment consists of verifying whether the approach is usable in a large-scale environment, by observing the uptake, usability, and operational behavior it shows in large-scale, real-life deployments. In that sense, so far the main use case for this specification is the transportation of large SAML statements defined within the ABFAB architecture [ABFAB-Arch]. Hence, it can be tested wherever an ABFAB deployment is being piloted.
実験は、大規模な実際の展開で示される取り込み、使いやすさ、および動作の動作を観察することにより、アプローチが大規模環境で使用可能かどうかを検証することで構成されています。その意味で、これまでのところ、この仕様の主なユースケースは、ABFABアーキテクチャ[ABFAB-Arch]内で定義された大きなSAMLステートメントの転送です。したがって、ABFABの展開がパイロットされる場所であればどこでもテストできます。
Besides, this proposal defines some experimental features that will need to be tested and verified before the document can be considered for the Standards Track. The first one of them is the requirement of updating [RFC2865] in order to relax the sentence defined in Section 4.1 of that document that states that "An Access-Request MUST contain either a User-Password or a CHAP-Password or a State." This specification might generate Access-Request packets without any of these attributes. Although all known implementations have chosen the philosophy of "be liberal in what you accept," we need to gain more operational experience to verify that unmodified proxies do not drop these types of packets. More details on this aspect can be found in Section 12.2.
さらに、この提案は、ドキュメントを標準化トラックで検討する前にテストおよび検証する必要があるいくつかの実験的機能を定義しています。それらの最初の1つは、「アクセス要求にはユーザーパスワードまたはCHAPパスワードまたは状態のいずれかが含まれていなければならない（MUST）」と述べているそのドキュメントのセクション4.1で定義された文を緩和するために[RFC2865]を更新する要件です。 」この仕様では、これらの属性のないAccess-Requestパケットが生成される場合があります。すべての既知の実装では「受け入れる内容を自由にする」という理念を選択していますが、変更されていないプロキシがこれらのタイプのパケットをドロップしないことを確認するには、より多くの運用経験を得る必要があります。この側面の詳細については、セクション12.2を参照してください。
Another experimental feature of this specification is that it requires proxies to base their routing decisions on the value of the RADIUS User-Name attribute. Our experience is that this is the common behavior; thus, no issues are expected. However, it needs to be confirmed after using different implementations of intermediate proxies. More details on this aspect can be found in Section 12.3.
この仕様の別の実験的機能は、RADIUS User-Name属性の値に基づいてルーティング決定を行うためにプロキシが必要になることです。私たちの経験では、これは一般的な動作です。したがって、問題は予想されません。ただし、中間プロキシの異なる実装を使用した後に確認する必要があります。この側面の詳細については、セクション12.3を参照してください。
Moreover, this document requires two minor updates to Standards Track documents. First, it modifies the definition of the Reserved field of the Long Extended Type attribute [RFC6929] by allocating an additional flag called the T (Truncation) flag. No issues are expected with this update, although some proxies might drop packets that do not have the Reserved field set to 0. More details on this aspect can be found in Section 12.1.
さらに、このドキュメントでは、Standards Trackドキュメントに2つのマイナーアップデートが必要です。まず、T（切り捨て）フラグと呼ばれる追加のフラグを割り当てることにより、Long Extended Type属性[RFC6929]のReservedフィールドの定義を変更します。このアップデートでは問題は予想されませんが、一部のプロキシは、Reservedフィールドが0に設定されていないパケットをドロップする可能性があります。この側面の詳細は、セクション12.1を参照してください。
The other Standards Track document that requires a minor update is [RFC6158]. It states that "attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 bytes," something no longer true if this document advances.
マイナーアップデートを必要とする他の標準トラックドキュメントは[RFC6158]です。これは、「属性の設計者は、RADIUS実装が4096バイトを超えるRADIUSパケットを正常に処理できることを想定してはならない」と述べており、このドキュメントが進んだ場合は真実ではなくなります。
A proper "Updates" clause will be included for these modifications when/if the experiment is successful and this document is reissued as a Standards Track document.
実験が成功し、このドキュメントがスタンダードトラックドキュメントとして再発行された場合、または変更された場合、これらの変更には適切な「更新」句が含まれます。
This specification describes how a RADIUS Client and a RADIUS Server can exchange data exceeding the 4096-byte limit imposed by one packet. However, the mechanism described in this specification SHOULD NOT be used to exchange more than 100 kilobytes of data. Any more than this may turn RADIUS into a generic transport protocol, such as TCP or the Stream Control Transmission Protocol (SCTP), which is undesirable. Experience shows that attempts to transport bulk data across the Internet with UDP will inevitably fail, unless these transport attempts reimplement all of the behavior of TCP. The underlying design of RADIUS lacks the proper retransmission policies or congestion control mechanisms that would make it a competitor of TCP.
この仕様は、RADIUSクライアントとRADIUSサーバーが1つのパケットによって課される4096バイトの制限を超えるデータを交換する方法を説明します。ただし、この仕様で説明されているメカニズムは、100キロバイトを超えるデータの交換には使用しないでください。これを超えると、RADIUSがTCPやストリーム制御伝送プロトコル（SCTP）などの一般的なトランスポートプロトコルに変わる可能性がありますが、これは望ましくありません。経験上、UDPを使用してインターネット経由でバルクデータを転送しようとすると、TCPのすべての動作を再実装しない限り、必然的に失敗することが示されています。 RADIUSの基礎となる設計には、TCPの競合相手となる適切な再送信ポリシーまたは輻輳制御メカニズムがありません。
Therefore, RADIUS/UDP transport is by design unable to transport bulk data. It is both undesirable and impossible to change the protocol at this point in time. This specification is intended to allow the transport of more than 4096 bytes of data through existing RADIUS/UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a "green field" deployment requires the transport of bulk data.
したがって、RADIUS / UDPトランスポートは、バルクデータをトランスポートできないように設計されています。この時点でプロトコルを変更することは望ましくなく、不可能です。この仕様は、既存のRADIUS / UDPプロキシを介して4096バイトを超えるデータを転送できるようにすることを目的としています。 RADIUS / TCPなどの他のソリューションは、「グリーンフィールド」の展開でバルクデータの転送が必要な場合に使用する必要があります。
Section 7, below, describes in further detail what is considered to be a reasonable amount of data and recommends that administrators adjust limitations on data transfer according to the specific capabilities of their existing systems in terms of memory and processing power.
以下のセクション7では、妥当な量のデータと見なされるものをさらに詳しく説明し、管理者がメモリと処理能力の観点から既存のシステムの特定の機能に従ってデータ転送の制限を調整することを推奨しています。
Moreover, its scope is limited to the exchange of authorization data, as other exchanges do not require such a mechanism. In particular, authentication exchanges have already been defined to overcome this limitation (e.g., RADIUS-EAP). Moreover, as they represent the most critical part of a RADIUS conversation, it is preferable to not introduce into their operation any modification that may affect existing equipment.
さらに、他の交換はそのようなメカニズムを必要としないため、その範囲は許可データの交換に限定されます。特に、認証交換はこの制限を克服するためにすでに定義されています（RADIUS-EAPなど）。さらに、これらはRADIUS会話の最も重要な部分を表すため、既存の機器に影響を与える可能性のある変更を操作に導入しないことが望ましいです。
There is no need to fragment accounting packets either. While the accounting process can send large amounts of data, that data is typically composed of many small updates. That is, there is no demonstrated need to send indivisible blocks of more than 4 kilobytes of data. The need to send large amounts of data per user session often originates from the need for flow-based accounting. In this use case, the RADIUS Client may send accounting data for many thousands of flows, where all those flows are tied to one user session. The existing Acct-Multi-Session-Id attribute defined in [RFC2866], Section 5.11 has been proven to work here.
アカウンティングパケットをフラグメント化する必要もありません。アカウンティングプロセスは大量のデータを送信できますが、そのデータは通常、多数の小さな更新で構成されています。つまり、4キロバイトを超えるデータの分割不可能なブロックを送信する必要性が実証されていません。多くの場合、ユーザーセッションごとに大量のデータを送信する必要性は、フローベースのアカウンティングの必要性から生じます。この使用例では、RADIUSクライアントが数千のフローのアカウンティングデータを送信する場合があり、これらのフローはすべて1つのユーザーセッションに関連付けられています。 [RFC2866]のセクション5.11で定義されている既存のAcct-Multi-Session-Id属性は、ここで機能することが証明されています。
Similarly, there is no need to fragment Change-of-Authorization (CoA) [RFC5176] packets. Instead, according to [RFC5176], the CoA client will send a CoA-Request packet containing session identification attributes, along with Service-Type = Additional-Authorization, and a State attribute. Implementations not supporting fragmentation will respond with a CoA-NAK and an Error-Cause of Unsupported-Service.
同様に、許可変更（CoA）[RFC5176]パケットをフラグメント化する必要はありません。代わりに、[RFC5176]によれば、CoAクライアントは、Service-Type = Additional-Authorization、およびState属性とともに、セッション識別属性を含むCoA-Requestパケットを送信します。断片化をサポートしない実装は、CoA-NAKおよびUnsupported-ServiceのError-Causeで応答します。
The above requirement does not assume that the CoA client and the RADIUS Server are co-located. They may, in fact, be run on separate parts of the infrastructure, or even by separate administrators. There is, however, a requirement that the two communicate. We can see that the CoA client needs to send session identification attributes in order to send CoA packets. These attributes cannot be known a priori by the CoA client and can only come from the RADIUS Server. Therefore, even when the two systems are not co-located, they must be able to communicate in order to operate in unison. The alternative is for the two systems to have differing views of the users' authorization parameters; such a scenario would be a security disaster.
上記の要件は、CoAクライアントとRADIUSサーバーが同じ場所にあることを想定していません。実際には、インフラストラクチャの別々の部分で実行されたり、別々の管理者によって実行されたりすることもあります。ただし、両者が通信する必要があります。 CoAクライアントは、CoAパケットを送信するためにセッション識別属性を送信する必要があることがわかります。これらの属性は、CoAクライアントからアプリオリに知ることができず、RADIUSサーバーからのみ取得できます。したがって、2つのシステムが同じ場所に配置されていない場合でも、協調して動作するためには、それらが通信できる必要があります。もう1つの方法は、2つのシステムがユーザーの承認パラメーターの異なるビューを持つことです。このようなシナリオは、セキュリティ上の災害になります。
This specification does not allow for fragmentation of CoA packets. Allowing for fragmented CoA packets would involve changing multiple parts of the RADIUS protocol; such changes introduce the risk of implementation issues, mistakes, etc.
この仕様では、CoAパケットのフラグメンテーションは許可されていません。断片化されたCoAパケットを許可するには、RADIUSプロトコルの複数の部分を変更する必要があります。このような変更は、実装の問題、ミスなどのリスクをもたらします。
Where CoA clients (i.e., RADIUS Servers) need to send large amounts of authorization data to a CoA server (i.e., RADIUS Client), they need only send a minimal CoA-Request packet containing a Service-Type of Authorize Only, as per [RFC5176], along with session identification attributes. This CoA packet serves as a signal to the RADIUS Client that the users' session requires re-authorization. When the RADIUS Client re-authorizes the user via Access-Request, the RADIUS Server can perform fragmentation and send large amounts of authorization data to the RADIUS Client.
CoAクライアント（つまり、RADIUSサーバー）が大量の承認データをCoAサーバー（つまり、RADIUSクライアント）に送信する必要がある場合、[だけ]のように、サービスタイプが[承認のみ]を含む最小限のCoA要求パケットを送信するだけで済みますRFC5176]、セッション識別属性とともに。このCoAパケットは、ユーザーのセッションで再認証が必要であることをRADIUSクライアントに通知する信号として機能します。 RADIUSクライアントがAccess-Requestを介してユーザーを再承認すると、RADIUSサーバーは断片化を実行し、大量の承認データをRADIUSクライアントに送信できます。
The assumption in the above scenario is that the CoA client and RADIUS Server are co-located, or at least strongly coupled. That is, the path from CoA client to CoA server SHOULD be the exact reverse of the path from RADIUS Client to RADIUS Server. The following diagram will hopefully clarify the roles:
上記のシナリオの前提は、CoAクライアントとRADIUSサーバーが同じ場所に配置されているか、少なくとも強く結合されていることです。つまり、CoAクライアントからCoAサーバーへのパスは、RADIUSクライアントからRADIUSサーバーへのパスの正確な逆になる必要があります。次の図は、役割を明確に示しています。
+----------------+
| RADIUS CoA |
| Client Server |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Server Client |
+----------------+
Where there is a proxy involved:
プロキシが含まれている場合：
+----------------+
| RADIUS CoA |
| Client Server |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Proxy Proxy |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Server Client |
+----------------+
That is, the RADIUS and CoA subsystems at each hop are strongly connected. Where they are not strongly connected, it will be impossible to use CoA-Request packets to transport large amounts of authorization data.
つまり、各ホップのRADIUSおよびCoAサブシステムは強く接続されています。それらが強く接続されていない場合、CoA-Requestパケットを使用して大量の認証データを転送することは不可能です。
This design is more complicated than allowing for fragmented CoA packets. However, the CoA client and the RADIUS Server must communicate even when not using this specification. We believe that standardizing that communication and using one method for exchange of large data are preferred to unspecified communication methods and multiple ways of achieving the same result. If we were to allow fragmentation of data over CoA packets, the size and complexity of this specification would increase significantly.
この設計は、フラグメント化されたCoAパケットを許可するよりも複雑です。ただし、CoAクライアントとRADIUSサーバーは、この仕様を使用していない場合でも通信する必要があります。私たちは、その通信を標準化し、大きなデータの交換に1つの方法を使用することは、不特定の通信方法や同じ結果を達成する複数の方法よりも好ましいと考えています。 CoAパケットを介したデータの断片化を許可すると、この仕様のサイズと複雑さが大幅に増加します。
The above requirement solves a number of issues. It clearly separates session identification from authorization. Without this separation, it is difficult to both identify a session and change its authorization using the same attribute. It also ensures that the authorization process is the same for initial authentication and for CoA.
上記の要件により、多くの問題が解決されます。セッションの識別と承認を明確に区別します。この分離がなければ、セッションを識別し、同じ属性を使用してその許可を変更することは困難です。また、許可プロセスが初期認証とCoAで同じであることも保証します。
Authorization exchanges can occur either before or after end-user authentication has been completed. An authorization exchange before authentication allows a RADIUS Client to provide the RADIUS Server with information that MAY modify how the authentication process will be performed (e.g., it may affect the selection of the EAP method). An authorization exchange after authentication allows the RADIUS Server to provide the RADIUS Client with information about the end user, the results of the authentication process, and/or obligations to be enforced. In this specification, we refer to "pre-authorization" as the exchange of authorization information before the end-user authentication has started (from the RADIUS Client to the RADIUS Server), whereas the term "post-authorization" is used to refer to an authorization exchange happening after this authentication process (from the RADIUS Server to the RADIUS Client).
承認の交換は、エンドユーザー認証が完了する前でも後でも行うことができます。認証前の承認交換により、RADIUSクライアントは、認証プロセスの実行方法を変更する可能性がある情報をRADIUSサーバーに提供できます（たとえば、EAP方式の選択に影響する場合があります）。認証後の承認交換により、RADIUSサーバーは、RADIUSクライアントにエンドユーザー、認証プロセスの結果、および/または実施する義務に関する情報を提供できます。この仕様では、「事前承認」をエンドユーザー認証が開始する前の（RADIUSクライアントからRADIUSサーバーへの）承認情報の交換と呼びますが、「事後承認」という用語はこの認証プロセスの後に発生する許可交換（RADIUSサーバーからRADIUSクライアントへ）。
In this specification, we refer to the "size limit" as the practical limit on RADIUS packet sizes. This limit is the minimum between 4096 bytes and the current PMTU. We define below a method that uses Access-Request and Access-Accept in order to exchange fragmented data. The RADIUS Client and Server exchange a series of Access-Request / Access-Accept packets, until such time as all of the fragmented data has been transported. Each packet contains a Frag-Status attribute, which lets the other party know if fragmentation is desired, ongoing, or finished. Each packet may also contain the fragmented data or may instead be an "ACK" to a previous fragment from the other party. Each Access-Request contains a User-Name attribute, allowing the packet to be proxied if necessary (see Section 11.1). Each Access-Request may also contain a State attribute, which serves to tie it to a previous Access-Accept. Each Access-Accept contains a State attribute, for use by the RADIUS Client in a later Access-Request. Each Access-Accept contains a Service-Type attribute with the "Additional-Authorization" value. This indicates that the service being provided is part of a fragmented exchange and that the Access-Accept should not be interpreted as providing network access to the end user.
この仕様では、「サイズ制限」をRADIUSパケットサイズの実際的な制限と呼びます。この制限は、4096バイトと現在のPMTUの間の最小値です。フラグメント化されたデータを交換するために、Access-RequestおよびAccess-Acceptを使用するメソッドを以下に定義します。 RADIUSクライアントとサーバーは、フラグメント化されたすべてのデータが転送されるまで、一連のAccess-Request / Access-Acceptパケットを交換します。各パケットにはFrag-Status属性が含まれています。これにより、断片化が必要か、進行中か、終了したかを相手に知らせることができます。各パケットには、フラグメント化されたデータが含まれる場合もあれば、代わりに、相手からの以前のフラグメントに対する「ACK」である場合もあります。各Access-RequestにはUser-Name属性が含まれており、必要に応じてパケットをプロキシできます（セクション11.1を参照）。各Access-Requestには、以前のAccess-Acceptに関連付けるために役立つState属性も含まれる場合があります。各Access-Acceptには、RADIUSクライアントが後のAccess-Requestで使用するためのState属性が含まれています。各Access-Acceptには、「Additional-Authorization」値を持つService-Type属性が含まれています。これは、提供されているサービスが断片化された交換の一部であり、Access-Acceptがエンドユーザーにネットワークアクセスを提供するものとして解釈されるべきではないことを示しています。
When a RADIUS Client or RADIUS Server needs to send data that exceeds the size limit, the mechanism proposed in this document is used. Instead of encoding one large RADIUS packet, a series of smaller RADIUS packets of the same type are encoded. Each smaller packet is called a "chunk" in this specification, in order to distinguish it from traditional RADIUS packets. The encoding process is a simple linear walk over the attributes to be encoded. This walk preserves the order of the attributes of the same type, as required by [RFC2865]. The number of attributes encoded in a particular chunk depends on the size limit, the size of each attribute, the number of proxies between the RADIUS Client and RADIUS Server, and the overhead for fragmentation-signaling attributes. Specific details are given in Section 6. A new attribute called Frag-Status (Section 10.1) signals the fragmentation status.
RADIUSクライアントまたはRADIUSサーバーがサイズ制限を超えるデータを送信する必要がある場合、このドキュメントで提案されているメカニズムが使用されます。 1つの大きなRADIUSパケットをエンコードする代わりに、同じタイプの一連の小さなRADIUSパケットがエンコードされます。この仕様では、小さいパケットを「チャンク」と呼び、従来のRADIUSパケットと区別します。エンコードプロセスは、エンコードされる属性を単純に直線的にたどります。このウォークでは、[RFC2865]で要求されているように、同じタイプの属性の順序が保持されます。特定のチャンクにエンコードされた属性の数は、サイズ制限、各属性のサイズ、RADIUSクライアントとRADIUSサーバー間のプロキシの数、およびフラグメンテーションシグナリング属性のオーバーヘッドによって異なります。具体的な詳細については、セクション6を参照してください。Frag-Status（セクション10.1）と呼ばれる新しい属性は、フラグメンテーションステータスを示します。
After the first chunk is encoded, it is sent to the other party. The packet is identified as a chunk via the Frag-Status attribute. The other party then requests additional chunks, again using the Frag-Status attribute. This process is repeated until all the attributes have been sent from one party to the other. When all the chunks have been received, the original list of attributes is reconstructed and processed as if it had been received in one packet.
最初のチャンクはエンコードされた後、相手に送信されます。パケットは、Frag-Status属性によってチャンクとして識別されます。次に、もう一方のパーティは、Frag-Status属性を使用して、追加のチャンクを要求します。このプロセスは、すべての属性が一方の当事者から他方の当事者に送信されるまで繰り返されます。すべてのチャンクが受信されると、属性の元のリストが再構成され、1つのパケットで受信されたかのように処理されます。
The reconstruction process is performed by simply appending all of the chunks together. Unlike IPv4 fragmentation, there is no Fragment Offset field. The chunks in this specification are explicitly ordered, as RADIUS is a lock-step protocol, as noted in Section 12.4. That is, chunk N+1 cannot be sent until all of the chunks up to and including N have been received and acknowledged.
再構築プロセスは、すべてのチャンクを一緒に追加するだけで実行されます。 IPv4フラグメンテーションとは異なり、フラグメントオフセットフィールドはありません。セクション12.4に記載されているように、RADIUSはロックステッププロトコルであるため、この仕様のチャンクは明示的に順序付けされています。つまり、Nまでのすべてのチャンクが受信されて確認応答されるまで、チャンクN + 1を送信できません。
When multiple chunks are sent, a special situation may occur for Long Extended Type attributes as defined in [RFC6929]. The fragmentation process may split a fragmented attribute across two or more chunks, which is not permitted by that specification. We address this issue by using the newly defined T flag in the Reserved field of the Long Extended Type attribute format (see Section 9 for further details on this flag).
複数のチャンクが送信されると、[RFC6929]で定義されているように、Long Extended Type属性に対して特別な状況が発生する可能性があります。断片化プロセスは、断片化された属性を2つ以上のチャンクに分割する場合がありますが、その仕様では許可されていません。この問題は、Long Extended Type属性形式のReservedフィールドで新しく定義されたTフラグを使用することで解決されています（このフラグの詳細については、セクション9を参照してください）。
This last situation is expected to be the most common occurrence in chunks. Typically, packet fragmentation will occur as a consequence of a desire to send one or more large (and therefore fragmented) attributes. The large attribute will likely be split into two or more pieces. Where chunking does not split a fragmented attribute, no special treatment is necessary.
この最後の状況は、チャンクで最も一般的に発生することが予想されます。通常、パケットの断片化は、1つ以上の大きな（したがって断片化された）属性を送信したい結果として発生します。大きな属性は、おそらく2つ以上の部分に分割されます。チャンクによって断片化された属性が分割されない場合、特別な処理は必要ありません。
The setting of the T flag is the only case where the chunking process affects the content of an attribute. Even then, the Value fields of all attributes remain unchanged. Any per-packet security attributes, such as Message-Authenticator, are calculated for each chunk independently. Neither integrity checks nor security checks are performed on the "original" packet.
Tフラグの設定は、チャンク処理が属性の内容に影響を与える唯一のケースです。それでも、すべての属性の値フィールドは変更されません。 Message-Authenticatorなどのパケットごとのセキュリティ属性は、チャンクごとに個別に計算されます。整合性チェックもセキュリティチェックも「元の」パケットでは実行されません。
Each RADIUS packet sent or received as part of the chunking process MUST be a valid packet, subject to all format and security requirements. This requirement ensures that a "transparent" proxy not implementing this specification can receive and send compliant packets. That is, a proxy that simply forwards packets without detailed examination or any modification will be able to proxy "chunks".
チャンキングプロセスの一部として送信または受信された各RADIUSパケットは、すべての形式とセキュリティ要件に従って、有効なパケットである必要があります。この要件により、この仕様を実装していない「透過」プロキシが準拠パケットを送受信できることが保証されます。つまり、詳細な検査や変更を行わずに単にパケットを転送するプロキシは、「チャンク」をプロキシすることができます。
When the RADIUS Client or the RADIUS Server desires to send a packet that exceeds the size limit, it is split into chunks and sent via multiple client/server exchanges. The exchange is indicated via the Frag-Status attribute, which has value More-Data-Pending for all but the last chunk of the series. The chunks are tied together via the State attribute.
RADIUSクライアントまたはRADIUSサーバーがサイズ制限を超えるパケットを送信する場合は、チャンクに分割され、複数のクライアント/サーバー交換を介して送信されます。交換はFrag-Status属性を介して示されます。この属性には、シリーズの最後のチャンクを除くすべてについて値More-Data-Pendingがあります。チャンクはState属性を介して結合されます。
The delivery of a large fragmented RADIUS packet with authorization data can happen before or after the end user has been authenticated by the RADIUS Server. We can distinguish two phases, which can be omitted if there is no authorization data to be sent:
許可データを含む断片化された大きなRADIUSパケットの配信は、エンドユーザーがRADIUSサーバーによって認証される前または後に発生する可能性があります。送信する認証データがない場合は省略できる2つのフェーズを区別できます。
1. Pre-authorization. In this phase, the RADIUS Client MAY send a large packet with authorization information to the RADIUS Server before the end user is authenticated. Only the RADIUS Client is allowed to send authorization data during this phase.
1. 事前承認。このフェーズでは、RADIUSクライアントは、エンドユーザーが認証される前に、承認情報を含む大きなパケットをRADIUSサーバーに送信する場合があります。このフェーズでは、RADIUSクライアントのみが認証データを送信できます。
2. Post-authorization. In this phase, the RADIUS Server MAY send a large packet with authorization data to the RADIUS Client after the end user has been authenticated. Only the RADIUS Server is allowed to send authorization data during this phase.
2. 許可後。このフェーズでは、RADIUSサーバーは、エンドユーザーが認証された後、承認データを含む大きなパケットをRADIUSクライアントに送信する場合があります。このフェーズでは、RADIUSサーバーのみが認証データを送信できます。
The following subsections describe how to perform fragmentation for packets for these two phases. We give the packet type, along with a RADIUS Identifier, to indicate that requests and responses are connected. We then give a list of attributes. We do not give values for most attributes, as we wish to concentrate on the fragmentation behavior rather than packet contents. Attribute values are given for attributes relevant to the fragmentation process. Where "long extended" attributes are used, we indicate the M (More) and T (Truncation) flags as optional square brackets after the attribute name. As no "long extended" attributes have yet been defined, we use example attributes, named as "Example-Long-1", etc. For the sake of simplicity, the maximum chunk size is established in terms of the number of attributes (11).
次のサブセクションでは、これらの2つのフェーズでパケットのフラグメンテーションを実行する方法について説明します。要求と応答が接続されていることを示すために、RADIUS IDとともにパケットタイプを指定します。次に、属性のリストを指定します。パケットの内容ではなく断片化の動作に集中するため、ほとんどの属性には値を指定していません。属性値は、断片化プロセスに関連する属性に指定されます。 「長い拡張」属性が使用される場合、属性名の後にオプションの角括弧としてM（詳細）およびT（切り捨て）フラグを示します。 「長い拡張」属性はまだ定義されていないため、「Example-Long-1」などの名前のサンプル属性を使用します。簡単にするために、最大チャンクサイズは属性の数（11 ）。
When the RADIUS Client needs to send a large amount of data to the RADIUS Server, the data to be sent is split into chunks and sent to the RADIUS Server via multiple Access-Request / Access-Accept exchanges. The example below shows this exchange.
RADIUSクライアントが大量のデータをRADIUSサーバーに送信する必要がある場合、送信されるデータはチャンクに分割され、複数のAccess-Request / Access-Accept交換を介してRADIUSサーバーに送信されます。次の例は、この交換を示しています。
The following is an Access-Request that the RADIUS Client intends to send to a RADIUS Server. However, due to a combination of issues (PMTU, large attributes, etc.), the content does not fit into one Access-Request packet.
以下は、RADIUSクライアントがRADIUSサーバーに送信する予定のアクセス要求です。ただし、問題の組み合わせ（PMTU、大きな属性など）により、コンテンツは1つのAccess-Requestパケットに収まりません。
Access-Request
User-Name
NAS-Identifier
Calling-Station-Id
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
Figure 1: Desired Access-Request
図1：必要なアクセス要求
The RADIUS Client therefore must send the attributes listed above in a series of chunks. The first chunk contains eight (8) attributes from the original Access-Request, and a Frag-Status attribute. Since the last attribute is "Example-Long-1" with the M flag set, the chunking process also sets the T flag in that attribute. The Access-Request is sent with a RADIUS Identifier field having value 23. The Frag-Status attribute has value More-Data-Pending, to indicate that the RADIUS Client wishes to send more data in a subsequent Access-Request. The RADIUS Client also adds a Service-Type attribute, which indicates that it is part of the chunking process. The packet is signed with the Message-Authenticator attribute, completing the maximum number of attributes (11).
したがって、RADIUSクライアントは、上記の属性を一連のチャンクで送信する必要があります。最初のチャンクには、元のAccess-Requestからの8つの属性とFrag-Status属性が含まれています。最後の属性はMフラグが設定された「Example-Long-1」であるため、チャンクプロセスはその属性にTフラグも設定します。 Access-Requestは、値23のRADIUS Identifierフィールドと共に送信されます。Frag-Status属性の値はMore-Data-Pendingで、RADIUSクライアントが後続のAccess-Requestでさらにデータを送信したいことを示します。 RADIUSクライアントは、チャンクプロセスの一部であることを示すService-Type属性も追加します。パケットはMessage-Authenticator属性で署名され、属性の最大数（11）を完成させます。
Access-Request (ID = 23)
User-Name
NAS-Identifier
Calling-Station-Id
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
Message-Authenticator
Figure 2: Access-Request (Chunk 1)
図2：アクセス要求（チャンク1）
Compliant RADIUS Servers (i.e., servers implementing fragmentation) receiving this packet will see the Frag-Status attribute and will postpone all authorization and authentication handling until all of the chunks have been received. This postponement also applies to the verification that the Access-Request packet contains some kind of authentication attribute (e.g., User-Password, CHAP-Password, State, or other future attribute), as required by [RFC2865] (see Section 12.2 for more information on this).
このパケットを受信する準拠RADIUSサーバー（つまり、フラグメンテーションを実装するサーバー）はFrag-Status属性を参照し、すべてのチャンクが受信されるまで、すべての承認と認証の処理を延期します。この延期は、[RFC2865]で要求されているように、Access-Requestパケットにある種の認証属性（User-Password、CHAP-Password、State、またはその他の将来の属性）が含まれていることの検証にも適用されます（詳細については、セクション12.2を参照）これに関する情報）。
Non-compliant RADIUS Servers (i.e., servers not implementing fragmentation) should also see the Service-Type requesting provisioning for an unknown service and return Access-Reject. Other non-compliant RADIUS Servers may return an Access-Reject or Access-Challenge, or they may return an Access-Accept with a particular Service-Type other than Additional-Authorization. Compliant RADIUS Client implementations MUST treat these responses as if they had received Access-Reject instead.
非準拠のRADIUSサーバー（つまり、断片化を実装していないサーバー）も、不明なサービスのプロビジョニングを要求するService-Typeを確認し、Access-Rejectを返す必要があります。その他の非準拠のRADIUSサーバーは、Access-RejectまたはAccess-Challengeを返す場合や、Additional-Authorization以外の特定のサービスタイプでAccess-Acceptを返す場合があります。準拠するRADIUSクライアントの実装では、これらの応答を、代わりにAccess-Rejectを受信した場合と同様に処理する必要があります。
Compliant RADIUS Servers who wish to receive all of the chunks will respond with the following packet. The value of the State here is arbitrary and serves only as a unique token for example purposes. We only note that it MUST be temporally unique to the RADIUS Server.
すべてのチャンクを受信したい準拠RADIUSサーバーは、次のパケットで応答します。ここでのStateの値は任意であり、例の目的で一意のトークンとしてのみ機能します。 RADIUSサーバーに対して一時的に一意である必要があることに注意してください。
Access-Accept (ID = 23) Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xabc00001 Message-Authenticator
Access-Accept（ID = 23）Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xabc00001 Message-Authenticator
Figure 3: Access-Accept (Chunk 1)
図3：Access-Accept（チャンク1）
The RADIUS Client will see this response and use the RADIUS Identifier field to associate it with an ongoing chunking session. Compliant RADIUS Clients will then continue the chunking process. Non-compliant RADIUS Clients will never see a response such as this, as they will never send a Frag-Status attribute. The Service-Type attribute is included in the Access-Accept in order to signal that the response is part of the chunking process. This packet therefore does not provision any network service for the end user.
RADIUSクライアントはこの応答を確認し、RADIUS IDフィールドを使用して、進行中のチャンクセッションに関連付けます。準拠するRADIUSクライアントは、チャンク処理を続行します。非準拠のRADIUSクライアントは、Frag-Status属性を送信しないため、このような応答は表示されません。応答がチャンクプロセスの一部であることを通知するために、Service-Type属性はAccess-Acceptに含まれています。したがって、このパケットはエンドユーザーにネットワークサービスをプロビジョニングしません。
The RADIUS Client continues the process by sending the next chunk, which includes an additional six (6) attributes from the original packet. It again includes the User-Name attribute, so that non-compliant proxies can process the packet (see Section 11.1). It sets the Frag-Status attribute to More-Data-Pending, as more data is pending. It includes a Service-Type, for the reasons described above. It includes the State attribute from the previous Access-Accept. It signs the packet with Message-Authenticator, as there are no authentication attributes in the packet. It uses a new RADIUS Identifier field.
RADIUSクライアントは、次のチャンクを送信することでプロセスを続行します。これには、元のパケットからの追加の6つの属性が含まれます。ここにもUser-Name属性が含まれているため、非準拠プロキシはパケットを処理できます（セクション11.1を参照）。保留中のデータが多いため、Frag-Status属性をMore-Data-Pendingに設定します。上記の理由により、Service-Typeが含まれています。以前のAccess-AcceptのState属性が含まれています。パケットには認証属性がないため、Message-Authenticatorでパケットに署名します。新しいRADIUS IDフィールドを使用します。
Access-Request (ID = 181)
User-Name
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
State = 0xabc000001
Message-Authenticator
Figure 4: Access-Request (Chunk 2)
図4：アクセス要求（チャンク2）
Compliant RADIUS Servers receiving this packet will see the Frag-Status attribute and look for a State attribute. Since one exists and it matches a State sent in an Access-Accept, this packet is part of a chunking process. The RADIUS Server will associate the attributes with the previous chunk. Since the Frag-Status attribute has value More-Data-Request, the RADIUS Server will respond with an Access-Accept as before. It MUST include a State attribute, with a value different from the previous Access-Accept. This State MUST again be globally and temporally unique.
このパケットを受信する準拠RADIUSサーバーは、Frag-Status属性を確認し、State属性を探します。 1つが存在し、Access-Acceptで送信された状態と一致するため、このパケットはチャンキングプロセスの一部です。 RADIUSサーバーは、属性を以前のチャンクに関連付けます。 Frag-Status属性の値はMore-Data-Requestであるため、RADIUSサーバーは以前と同様にAccess-Acceptで応答します。以前のAccess-Acceptとは異なる値を持つState属性を含める必要があります。この状態は、グローバルかつ一時的に一意である必要があります。
Access-Accept (ID = 181) Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xdef00002 Message-Authenticator
Access-Accept（ID = 181）Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xdef00002 Message-Authenticator
Figure 5: Access-Accept (Chunk 2)
図5：Access-Accept（チャンク2）
The RADIUS Client will see this response and use the RADIUS Identifier field to associate it with an ongoing chunking session. The RADIUS Client continues the chunking process by sending the next chunk, with the final attribute(s) from the original packet, and again includes the original User-Name attribute. The Frag-Status attribute is not included in the next Access-Request, as no more chunks are available for sending. The RADIUS Client includes the State attribute from the previous Access-Accept. It signs the packet with Message-Authenticator, as there are no authentication attributes in the packet. It again uses a new RADIUS Identifier field.
RADIUSクライアントはこの応答を確認し、RADIUS IDフィールドを使用して、進行中のチャンクセッションに関連付けます。 RADIUSクライアントは、元のパケットからの最終的な属性を使用して次のチャンクを送信し、再び元のUser-Name属性を含めて、チャンキングプロセスを続行します。 Frag-Status属性は、送信に使用できるチャンクがなくなるため、次のAccess-Requestには含まれません。 RADIUSクライアントには、以前のAccess-AcceptのState属性が含まれています。パケットには認証属性がないため、Message-Authenticatorでパケットに署名します。ここでも、新しいRADIUS IDフィールドが使用されます。
Access-Request (ID = 241) User-Name Example-Long-2 State = 0xdef00002 Message-Authenticator
Access-Request（ID = 241）User-Name Example-Long-2 State = 0xdef00002 Message-Authenticator
Figure 6: Access-Request (Chunk 3)
図6：アクセス要求（チャンク3）
On reception of this last chunk, the RADIUS Server matches it with an ongoing session via the State attribute and sees that there is no Frag-Status attribute present. It then processes the received attributes as if they had been sent in one RADIUS packet. See Section 8.4 for further details on this process. It generates the appropriate response, which can be either Access-Accept or Access-Reject. In this example, we show an Access-Accept. The RADIUS Server MUST send a State attribute, which allows linking the received data with the authentication process.
この最後のチャンクを受信すると、RADIUSサーバーはState属性を介して進行中のセッションと照合し、Frag-Status属性が存在しないことを確認します。次に、受信した属性が1つのRADIUSパケットで送信されたかのように処理します。このプロセスの詳細については、セクション8.4を参照してください。 Access-AcceptまたはAccess-Rejectのいずれかである適切な応答を生成します。この例では、Access-Acceptを示しています。 RADIUSサーバーはState属性を送信する必要があります。これにより、受信したデータを認証プロセスにリンクできます。
Access-Accept (ID = 241) State = 0x98700003 Message-Authenticator
Access-Accept（ID = 241）State = 0x98700003 Message-Authenticator
Figure 7: Access-Accept (Chunk 3)
図7：Access-Accept（チャンク3）
The above example shows in practice how the chunking process works. We reiterate the implementation and security requirements here.
上記の例は、実際にチャンキングプロセスがどのように機能するかを示しています。ここでは、実装とセキュリティの要件を繰り返し説明します。
Each chunk is a valid RADIUS packet (see Section 12.2 for some considerations about this), and all RADIUS format and security requirements MUST be followed before any chunking process is applied.
各チャンクは有効なRADIUSパケットであり（これに関するいくつかの考慮事項についてはセクション12.2を参照）、チャンクプロセスを適用する前にすべてのRADIUS形式とセキュリティ要件に従う必要があります。
Every chunk except for the last one from a RADIUS Client MUST include a Frag-Status attribute, with value More-Data-Pending. The last chunk MUST NOT contain a Frag-Status attribute. Each chunk except for the last one from a RADIUS Client MUST include a Service-Type attribute, with value Additional-Authorization. Each chunk MUST include a User-Name attribute, which MUST be identical in all chunks. Each chunk except for the first one from a RADIUS Client MUST include a State attribute, which MUST be copied from a previous Access-Accept.
RADIUSクライアントからの最後のチャンクを除くすべてのチャンクには、値More-Data-PendingのFrag-Status属性が含まれている必要があります。最後のチャンクはFrag-Status属性を含んではいけません（MUST NOT）。 RADIUSクライアントからの最後のチャンクを除く各チャンクには、追加の承認の値を持つService-Type属性を含める必要があります。各チャンクには、すべてのチャンクで同一である必要があるUser-Name属性を含める必要があります。 RADIUSクライアントからの最初のチャンクを除く各チャンクには、以前のAccess-Acceptからコピーする必要があるState属性を含める必要があります。
Each Access-Accept MUST include a State attribute. The value for this attribute MUST change in every new Access-Accept and MUST be globally and temporally unique.
各Access-Acceptには、State属性を含める必要があります。この属性の値は、すべての新しいAccess-Acceptで変更する必要があり、グローバルかつ一時的に一意である必要があります。
When the RADIUS Server wants to send a large amount of authorization data to the RADIUS Client after authentication, the operation is very similar to the pre-authorization process. The presence of a Service-Type = Additional-Authorization attribute ensures that a RADIUS Client not supporting this specification will treat that unrecognized Service-Type as though an Access-Reject had been received instead ([RFC2865], Section 5.6). If the original large Access-Accept packet contained a Service-Type attribute, it will be included with its original value in the last transmitted chunk, to avoid confusion with the one used for fragmentation signaling. It is RECOMMENDED that RADIUS Servers include a State attribute in their original Access-Accept packets, even if fragmentation is not taking place, to allow the RADIUS Client to send additional authorization data in subsequent exchanges. This State attribute would be included in the last transmitted chunk, to avoid confusion with the ones used for fragmentation signaling.
認証後にRADIUSサーバーがRADIUSクライアントに大量の承認データを送信する場合の操作は、承認前のプロセスとよく似ています。 Service-Type = Additional-Authorization属性の存在により、この仕様をサポートしていないRADIUSクライアントは、認識されないService-Typeを、代わりにAccess-Rejectが受信されたかのように扱うことが保証されます（[RFC2865]、セクション5.6）。元の大きなAccess-AcceptパケットにService-Type属性が含まれていた場合、フラグメンテーションシグナリングに使用されたものとの混同を避けるため、最後に送信されたチャンクに元の値が含まれます。 RADIUSサーバーは、フラグメンテーションが行われていない場合でも、RADIUSクライアントが後続の交換で追加の承認データを送信できるように、元のAccess-AcceptパケットにState属性を含めることをお勧めします。このState属性は、フラグメンテーションシグナリングに使用されるチャンクとの混乱を避けるために、最後に送信されたチャンクに含まれます。
Clients supporting this specification MUST include a Frag-Status = Fragmentation-Supported attribute in the first Access-Request sent to the RADIUS Server, in order to indicate that they would accept fragmented data from the server. This is not required if the pre-authorization process was carried out, as it is implicit.
この仕様をサポートするクライアントは、サーバーからフラグメント化されたデータを受け入れることを示すために、RADIUSサーバーに送信される最初のAccess-RequestにFrag-Status = Fragmentation-Supported属性を含める必要があります。事前承認プロセスが実行された場合、これは暗黙的であるため、必要ありません。
The following is an Access-Accept that the RADIUS Server intends to send to a RADIUS Client. However, due to a combination of issues (PMTU, large attributes, etc.), the content does not fit into one Access-Accept packet.
以下は、RADIUSサーバーがRADIUSクライアントに送信する予定のAccess-Acceptです。ただし、問題の組み合わせ（PMTU、大きな属性など）により、コンテンツは1つのAccess-Acceptパケットに収まりません。
Access-Accept
User-Name
EAP-Message
Service-Type = Login
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
State = 0xcba00003
Figure 8: Desired Access-Accept
図8：必要なアクセス-受け入れ
The RADIUS Server therefore must send the attributes listed above in a series of chunks. The first chunk contains seven (7) attributes from the original Access-Accept, and a Frag-Status attribute. Since the last attribute is "Example-Long-1" with the M flag set, the chunking process also sets the T flag in that attribute. The Access-Accept is sent with a RADIUS Identifier field having value 30, corresponding to a previous Access-Request not depicted. The Frag-Status attribute has value More-Data-Pending, to indicate that the RADIUS Server wishes to send more data in a subsequent Access-Accept. The RADIUS Server also adds a Service-Type attribute with value Additional-Authorization, which indicates that it is part of the chunking process. Note that the original Service-Type is not included in this chunk. Finally, a State attribute is included to allow matching subsequent requests with this conversation, and the packet is signed with the Message-Authenticator attribute, completing the maximum number of attributes (11).
したがって、RADIUSサーバーは、上記の属性を一連のチャンクで送信する必要があります。最初のチャンクには、元のAccess-Acceptの7つの属性とFrag-Status属性が含まれています。最後の属性はMフラグが設定された「Example-Long-1」であるため、チャンクプロセスはその属性にTフラグも設定します。 Access-Acceptは、図示されていない以前のAccess-Requestに対応する値30のRADIUS IDフィールドとともに送信されます。 Frag-Status属性の値はMore-Data-Pendingであり、RADIUSサーバーが後続のAccess-Acceptでさらにデータを送信することを希望していることを示します。 RADIUSサーバーは、値が追加の承認であるService-Type属性も追加します。これは、チャンクプロセスの一部であることを示します。元のService-Typeはこのチャンクに含まれていないことに注意してください。最後に、後続の要求をこの会話と照合できるようにState属性が含まれ、パケットはMessage-Authenticator属性で署名され、属性の最大数を完成させます（11）。
Access-Accept (ID = 30)
User-Name
EAP-Message
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
State = 0xcba00004
Message-Authenticator
Figure 9: Access-Accept (Chunk 1)
図9：Access-Accept（チャンク1）
Compliant RADIUS Clients receiving this packet will see the Frag-Status attribute and suspend all authorization handling until all of the chunks have been received. Non-compliant RADIUS Clients should also see the Service-Type indicating the provisioning for an unknown service and will treat it as an Access-Reject.
このパケットを受信する準拠するRADIUSクライアントは、Frag-Status属性を確認し、すべてのチャンクが受信されるまで、すべての認証処理を一時停止します。非準拠のRADIUSクライアントも、不明なサービスのプロビジョニングを示すService-Typeを確認し、それをAccess-Rejectとして扱います。
RADIUS Clients who wish to receive all of the chunks will respond with the following packet, where the value of the State attribute is taken from the received Access-Accept. They will also include the User-Name attribute so that non-compliant proxies can process the packet (Section 11.1).
すべてのチャンクを受信するRADIUSクライアントは、次のパケットで応答します。State属性の値は、受信したAccess-Acceptから取得されます。非準拠のプロキシーがパケットを処理できるように、ユーザー名属性も含まれます（セクション11.1）。
Access-Request (ID = 131) User-Name Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xcba00004 Message-Authenticator
Access-Request（ID = 131）User-Name Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xcba00004 Message-Authenticator
Figure 10: Access-Request (Chunk 1)
図10：アクセス要求（チャンク1）
The RADIUS Server receives this request and uses the State attribute to associate it with an ongoing chunking session. Compliant RADIUS Servers will then continue the chunking process. Non-compliant RADIUS Servers will never see a response such as this, as they will never send a Frag-Status attribute.
RADIUSサーバーはこの要求を受信し、State属性を使用して、進行中のチャンクセッションに関連付けます。準拠するRADIUSサーバーは、チャンク処理を続行します。非準拠のRADIUSサーバーはFrag-Status属性を送信しないため、このような応答は表示されません。
The RADIUS Server continues the chunking process by sending the next chunk, with the final attribute(s) from the original packet. The value of the Identifier field is taken from the received Access-Request. A Frag-Status attribute is not included in the next Access-Accept, as no more chunks are available for sending. The RADIUS Server includes the original State attribute to allow the RADIUS Client to send additional authorization data. The original Service-Type attribute is included as well.
RADIUSサーバーは、次のチャンクを元のパケットの最終的な属性とともに送信することにより、チャンキングプロセスを続行します。 Identifierフィールドの値は、受信したAccess-Requestから取得されます。送信に使用できるチャンクがなくなるため、Frag-Status属性は次のAccess-Acceptに含まれません。 RADIUSサーバーには、RADIUSクライアントが追加の認証データを送信できるようにする元の状態属性が含まれています。元のService-Type属性も含まれています。
Access-Accept (ID = 131)
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
Service-Type = Login
State = 0xfda000003
Message-Authenticator
Figure 11: Access-Accept (Chunk 2)
図11：Access-Accept（チャンク2）
On reception of this last chunk, the RADIUS Client matches it with an ongoing session via the Identifier field and sees that there is no Frag-Status attribute present. It then processes the received attributes as if they had been sent in one RADIUS packet. See Section 8.4 for further details on this process.
この最後のチャンクを受信すると、RADIUSクライアントは、IDフィールドを介して進行中のセッションと照合し、Frag-Status属性が存在しないことを確認します。次に、受信した属性が1つのRADIUSパケットで送信されたかのように処理します。このプロセスの詳細については、セクション8.4を参照してください。
In an ideal scenario, each intermediate chunk would be exactly the size limit in length. In this way, the number of round trips required to send a large packet would be optimal. However, this is not possible for several reasons.
理想的なシナリオでは、各中間チャンクは正確に長さのサイズ制限になります。このようにして、大きなパケットを送信するために必要なラウンドトリップの数が最適になります。ただし、これはいくつかの理由で不可能です。
1. RADIUS attributes have a variable length and must be included completely in a chunk. Thus, it is possible that, even if there is some free space in the chunk, it is not enough to include the next attribute. This can generate up to 254 bytes of spare space in every chunk.
1. RADIUS属性は可変長であり、チャンクに完全に含まれている必要があります。したがって、チャンクに空き領域があっても、次の属性を含めるだけでは不十分である可能性があります。これにより、チャンクごとに最大254バイトのスペアスペースが生成されます。
2. RADIUS fragmentation requires the introduction of some extra attributes for signaling. Specifically, a Frag-Status attribute (7 bytes) is included in every chunk of a packet, except the last one. A RADIUS State attribute (from 3 to 255 bytes) is also included in most chunks, to allow the RADIUS Server to bind an Access-Request with a previous Access-Challenge. User-Name attributes (from 3 to 255 bytes) are included in every chunk the RADIUS Client sends, as they are required by the proxies to route the packet to its destination. Together, these attributes can generate from up to 13 to 517 bytes of signaling data, reducing the amount of payload information that can be sent in each chunk.
2. RADIUSフラグメンテーションでは、シグナリング用にいくつかの追加属性を導入する必要があります。具体的には、Frag-Status属性（7バイト）は、最後のものを除いて、パケットのすべてのチャンクに含まれています。 RADIUS状態属性（3〜255バイト）もほとんどのチャンクに含まれ、RADIUSサーバーがAccess-Requestを以前のAccess-Challengeにバインドできるようにします。プロキシがパケットを宛先にルーティングするために必要なため、ユーザー名属性（3〜255バイト）は、RADIUSクライアントが送信するすべてのチャンクに含まれています。これらの属性を合わせて、最大13〜517バイトのシグナリングデータを生成できるため、各チャンクで送信できるペイロード情報の量が削減されます。
3. RADIUS packets SHOULD be adjusted to avoid exceeding the network MTU. Otherwise, IP fragmentation may occur, with undesirable consequences. Hence, maximum chunk size would be decreased from 4096 to the actual MTU of the network.
3. RADIUSパケットは、ネットワークMTUを超えないように調整する必要があります（SHOULD）。そうしないと、IPフラグメンテーションが発生し、望ましくない結果が生じる可能性があります。したがって、最大チャンクサイズは4096からネットワークの実際のMTUに減少します。
4. The inclusion of Proxy-State attributes by intermediary proxies can decrease the availability of usable space in the chunk. This is described in further detail in Section 8.1.
4. 中間プロキシによってProxy-State属性を含めると、チャンク内の使用可能なスペースの可用性が低下する可能性があります。これについては、8.1節で詳しく説明します。
There are no provisions for signaling how much data is to be sent via the fragmentation process as a whole. It is difficult to define what is meant by the "length" of any fragmented data. That data can be multiple attributes and can include RADIUS attribute header fields, or it can be one or more "large" attributes (more than 256 bytes in length). Proxies can also filter these attributes, to modify, add, or delete them and their contents. These proxies act on a "packet by packet" basis and cannot know what kind of filtering actions they will take on future packets. As a result, it is impossible to signal any meaningful value for the total amount of additional data.
全体としてフラグメンテーションプロセスを介して送信されるデータの量をシグナリングするための規定はありません。断片化されたデータの「長さ」が何を意味するかを定義することは困難です。そのデータは、複数の属性であり、RADIUS属性ヘッダーフィールドを含むことができます。または、1つ以上の「大きな」属性（長さが256バイトを超える）である場合があります。プロキシは、これらの属性をフィルタリングして、それらとその内容を変更、追加、または削除することもできます。これらのプロキシは「パケットごと」に基づいて動作し、将来のパケットに対してどのようなフィルタリングアクションを実行するかを認識できません。その結果、追加データの合計量に意味のある値を通知することはできません。
Unauthenticated end users are permitted to trigger the exchange of large amounts of fragmented data between the RADIUS Client and the RADIUS Server, having the potential to allow denial-of-service (DoS) attacks. An attacker could initiate a large number of connections, each of which requests the RADIUS Server to store a large amount of data. This data could cause memory exhaustion on the RADIUS Server and result in authentic users being denied access. It is worth noting that authentication mechanisms are already designed to avoid exceeding the size limit.
認証されていないエンドユーザーは、RADIUSクライアントとRADIUSサーバーの間で断片化された大量のデータの交換をトリガーでき、サービス拒否（DoS）攻撃を許可する可能性があります。攻撃者は多数の接続を開始する可能性があり、それぞれがRADIUSサーバーに大量のデータを保存するよう要求します。このデータにより、RADIUSサーバーでメモリが使い果たされ、正規のユーザーがアクセスを拒否される可能性があります。サイズ制限を超えないように認証メカニズムがすでに設計されていることは注目に値します。
Hence, implementations of this specification MUST limit the total amount of data they send and/or receive via this specification. Its default value SHOULD be 100 kilobytes. Any more than this may turn RADIUS into a generic transport protocol, which is undesirable. This limit SHOULD be configurable, so that it can be changed if necessary.
したがって、この仕様の実装は、この仕様を介して送受信するデータの総量を制限する必要があります。デフォルト値は100キロバイトにする必要があります。これを超えると、RADIUSが一般的なトランスポートプロトコルに変わる可能性がありますが、これは望ましくありません。この制限は構成可能である必要があり（SHOULD）、必要に応じて変更できます。
Implementations of this specification MUST limit the total number of round trips used during the fragmentation process. Its default value SHOULD be 25. Any more than this may indicate an implementation error, misconfiguration, or DoS attack. This limit SHOULD be configurable, so that it can be changed if necessary.
この仕様の実装は、フラグメンテーションプロセス中に使用されるラウンドトリップの総数を制限する必要があります。デフォルト値は25である必要があります。これを超えると、実装エラー、設定ミス、またはDoS攻撃を示している可能性があります。この制限は構成可能である必要があり（SHOULD）、必要に応じて変更できます。
For instance, let's imagine that the RADIUS Server wants to transport a SAML assertion that is 15000 bytes long to the RADIUS Client. In this hypothetical scenario, we assume that there are three intermediate proxies, each one inserting a Proxy-State attribute of 20 bytes. Also, we assume that the State attributes generated by the RADIUS Server have a size of 6 bytes and the User-Name attribute takes 50 bytes. Therefore, the amount of free space in a chunk for the transport of the SAML assertion attributes is as follows: Total (4096 bytes) - RADIUS header (20 bytes) - User-Name (50 bytes) - Frag-Status (7 bytes) - Service-Type (6 bytes) - State (6 bytes) - Proxy-State (20 bytes) - Proxy-State (20 bytes) - Proxy-State (20 bytes) - Message-Authenticator (18 bytes), resulting in a total of 3929 bytes. This amount of free space allows the transmission of up to 15 attributes of 255 bytes each.
たとえば、RADIUSサーバーが長さが15000バイトのSAMLアサーションをRADIUSクライアントに転送したいとします。この架空のシナリオでは、3つの中間プロキシがあり、それぞれに20バイトのProxy-State属性が挿入されていると想定しています。また、RADIUSサーバーによって生成された状態属性のサイズは6バイトで、ユーザー名属性のサイズは50バイトであると想定しています。したがって、SAMLアサーション属性を転送するためのチャンクの空き容量は次のとおりです。合計（4096バイト）-RADIUSヘッダー（20バイト）-ユーザー名（50バイト）-フラグステータス（7バイト） -Service-Type（6バイト）-State（6バイト）-Proxy-State（20バイト）-Proxy-State（20バイト）-Proxy-State（20バイト）-Message-Authenticator（18バイト）合計3929バイト。この空き容量により、最大255個の属性をそれぞれ255バイトで送信できます。
According to [RFC6929], a Long-Extended-Type provides a payload of 251 bytes. Therefore, the SAML assertion described above would result in 60 attributes, requiring four round trips to be completely transmitted.
[RFC6929]によれば、Long-Extended-Typeは251バイトのペイロードを提供します。したがって、上記のSAMLアサーションでは60個の属性が発生し、4回のラウンドトリップを完全に送信する必要があります。
RADIUS proxies may introduce Proxy-State attributes into any Access-Request packet they forward. If they are unable to add this information to the packet, they may silently discard it rather than forward it to its destination; this would lead to DoS situations. Moreover, any Proxy-State attribute received by a RADIUS Server in an Access-Request packet MUST be copied into the corresponding reply packet. For these reasons, Proxy-State attributes require special treatment within the packet fragmentation mechanism.
RADIUSプロキシは、転送するAccess-RequestパケットにProxy-State属性を導入する場合があります。この情報をパケットに追加できない場合、宛先に転送するのではなく、メッセージを表示せずに破棄する可能性があります。これはDoSの状況につながります。さらに、RADIUSサーバーがAccess-Requestパケットで受信したProxy-State属性は、対応する応答パケットにコピーする必要があります。これらの理由により、Proxy-State属性には、パケットフラグメンテーションメカニズム内での特別な処理が必要です。
When the RADIUS Server replies to an Access-Request packet as part of a conversation involving a fragmentation (either a chunk or a request for chunks), it MUST include every Proxy-State attribute received in the reply packet. This means that the RADIUS Server MUST take into account the size of these Proxy-State attributes in order to calculate the size of the next chunk to be sent.
RADIUSサーバーが断片化（チャンクまたはチャンクの要求のいずれか）を含む会話の一部としてAccess-Requestパケットに応答する場合、RADIUSサーバーは応答パケットで受信したすべてのProxy-State属性を含める必要があります。これは、送信される次のチャンクのサイズを計算するために、RADIUSサーバーがこれらのProxy-State属性のサイズを考慮しなければならないことを意味します。
However, while a RADIUS Server will always know how much space MUST be left in each reply packet for Proxy-State attributes (as they are directly included by the RADIUS Server), a RADIUS Client cannot know this information, as Proxy-State attributes are removed from the reply packet by their respective proxies before forwarding them back. Hence, RADIUS Clients need a mechanism to discover the amount of space required by proxies to introduce their Proxy-State attributes. In the following paragraphs, we describe a new mechanism to perform such a discovery:
ただし、RADIUSサーバーは常に、プロキシ状態属性（RADIUSサーバーによって直接含まれているため）の各応答パケットにどれだけのスペースが残っている必要があるかを常に知っていますが、RADIUSクライアントはこの情報を知ることができません。それらを戻す前に、それぞれのプロキシによって応答パケットから削除されます。したがって、RADIUSクライアントには、プロキシがProxy-State属性を導入するために必要なスペースの量を検出するメカニズムが必要です。次の段落では、そのような発見を実行するための新しいメカニズムについて説明します。
1. When a RADIUS Client does not know how much space will be required by intermediate proxies for including their Proxy-State attributes, it SHOULD start using a conservative value (e.g., 1024 bytes) as the chunk size.
1. RADIUSクライアントが、プロキシ状態属性を含めるために中間プロキシが必要とするスペースがわからない場合は、チャンクサイズとして控えめな値（1024バイトなど）を使用する必要があります。
2. When the RADIUS Server receives a chunk from the RADIUS Client, it can calculate the total size of the Proxy-State attributes that have been introduced by intermediary proxies along the path. This information MUST be returned to the RADIUS Client in the next reply packet, encoded into a new attribute called Proxy-State-Length. The RADIUS Server MAY artificially increase this quantity in order to handle situations where proxies behave inconsistently (e.g., they generate Proxy-State attributes with a different size for each packet) or where intermediary proxies remove Proxy-State attributes generated by other proxies. Increasing this value would make the RADIUS Client leave some free space for these situations.
2. RADIUSサーバーは、RADIUSクライアントからチャンクを受信すると、パスに沿って中間プロキシによって導入されたProxy-State属性の合計サイズを計算できます。この情報は、次の応答パケットでRADIUSクライアントに返され、Proxy-State-Lengthと呼ばれる新しい属性にエンコードされる必要があります。 RADIUSサーバーは、プロキシの動作に一貫性がない場合（たとえば、パケットごとに異なるサイズのProxy-State属性を生成する場合）や、中間プロキシが他のプロキシによって生成されたProxy-State属性を削除する場合に、この量を人為的に増やしてもよい（MAY）。この値を大きくすると、RADIUSクライアントはこれらの状況のためにいくらかの空き領域を残します。
3. The RADIUS Client SHOULD respond to the reception of this attribute by adjusting the maximum size for the next chunk accordingly. However, as the Proxy-State-Length offers just an estimation of the space required by the proxies, the RADIUS Client MAY select a smaller amount in environments known to be problematic.
3. RADIUSクライアントは、次のチャンクの最大サイズを適宜調整することにより、この属性の受信に応答する必要があります（SHOULD）。ただし、Proxy-State-Lengthはプロキシが必要とするスペースの概算を提供するだけなので、RADIUSクライアントは、問題があることがわかっている環境ではより少ない量を選択する場合があります。
This RADIUS fragmentation mechanism makes use of the State attribute to link all the chunks belonging to the same fragmented packet. However, some considerations are required when the RADIUS Server is fragmenting a packet that already contains a State attribute for other purposes not related to the fragmentation. If the procedure described in Section 5 is followed, two different State attributes could be included in a single chunk. This is something explicitly forbidden in [RFC2865].
このRADIUSフラグメント化メカニズムは、State属性を使用して、同じフラグメント化されたパケットに属するすべてのチャンクをリンクします。ただし、RADIUSサーバーが、フラグメンテーションに関連しない他の目的のためにすでにState属性を含むパケットをフラグメント化する場合、いくつかの考慮事項が必要です。セクション5で説明されている手順に従う場合、2つの異なる状態属性を1つのチャンクに含めることができます。これは[RFC2865]で明示的に禁止されているものです。
A straightforward solution consists of making the RADIUS Server send the original State attribute in the last chunk of the sequence (attributes can be reordered as specified in [RFC2865]). As the last chunk (when generated by the RADIUS Server) does not contain any State attribute due to the fragmentation mechanism, both situations described above are avoided.
簡単な解決策は、RADIUSサーバーにシーケンスの最後のチャンクで元の状態属性を送信させることです（属性は[RFC2865]で指定されているように並べ替えることができます）。最後のチャンク（RADIUSサーバーによって生成された場合）には、断片化メカニズムが原因で状態属性が含まれていないため、上記の両方の状況が回避されます。
Something similar happens when the RADIUS Client has to send a fragmented packet that contains a State attribute in it. The RADIUS Client MUST ensure that this original State is included in the first chunk sent to the RADIUS Server (as this one never contains any State attribute due to fragmentation).
RADIUSクライアントが状態属性を含む断片化されたパケットを送信する必要がある場合も、同様のことが起こります。 RADIUSクライアントは、この元の状態がRADIUSサーバーに送信される最初のチャンクに含まれていることを確認する必要があります（フラグメント化のため、この属性には状態属性が含まれないため）。
This RADIUS fragmentation mechanism makes use of the Service-Type attribute to indicate that an Access-Accept packet is not granting access to the service yet, since an additional authorization exchange needs to be performed. Similarly to the State attribute, the RADIUS Server has to send the original Service-Type attribute in the last Access-Accept of the RADIUS conversation to avoid ambiguity.
このRADIUSフラグメンテーションメカニズムは、Service-Type属性を使用して、追加の承認交換を実行する必要があるため、Access-Acceptパケットがまだサービスへのアクセスを許可していないことを示します。状態属性と同様に、RADIUSサーバーは、あいまいさを避けるために、RADIUS会話の最後のAccess-Acceptで元のService-Type属性を送信する必要があります。
The RADIUS Client stores the RADIUS attributes received in each chunk in a list, in order to be able to rebuild the original large packet after receiving the last chunk. However, some of these received attributes MUST NOT be stored in that list, as they have been introduced as part of the fragmentation signaling and hence are not part of the original packet.
RADIUSクライアントは、各チャンクで受信したRADIUS属性をリストに格納し、最後のチャンクを受信した後に元の大きなパケットを再構築できるようにします。ただし、これらの受信された属性の一部は、フラグメンテーションシグナリングの一部として導入されたため、元のパケットの一部ではないため、そのリストに格納してはなりません（MUST NOT）。
o State (except the one in the last chunk, if present)
o 状態（存在する場合、最後のチャンクにあるものを除く）
o Service-Type = Additional-Authorization
o サービスタイプ=追加認証
o Frag-Status
o フラグステータス
o Proxy-State-Length
o プロキシ状態長
Similarly, the RADIUS Server MUST NOT store the following attributes as part of the original large packet:
同様に、RADIUSサーバーは、次の属性を元の大きなパケットの一部として格納してはなりません（MUST NOT）。
o State (except the one in the first chunk, if present)
o 状態（存在する場合、最初のチャンクにあるものを除く）
o Service-Type = Additional-Authorization
o サービスタイプ=追加認証
o Frag-Status
o フラグステータス
o Proxy-State (except the ones in the last chunk)
o Proxy-State（最後のチャンクにあるものを除く）
o User-Name (except the one in the first chunk)
o ユーザー名（最初のチャンクにあるものを除く）
This document defines a new field in the Long Extended Type attribute format. This field is one bit in size and is called "T" for Truncation. It indicates that the attribute is intentionally truncated in this chunk and is to be continued in the next chunk of the sequence. The combination of the M flag and the T flag indicates that the attribute is fragmented (M flag) but that all the fragments are not available in this chunk (T flag). Proxies implementing [RFC6929] will see these attributes as invalid (they will not be able to reconstruct them), but they will still forward them, as Section 5.2 of [RFC6929] indicates that they SHOULD forward unknown attributes anyway.
このドキュメントでは、Long Extended Type属性形式で新しいフィールドを定義しています。このフィールドのサイズは1ビットで、切り捨ての場合は「T」と呼ばれます。これは、属性がこのチャンクで意図的に切り捨てられ、シーケンスの次のチャンクで継続されることを示しています。 MフラグとTフラグの組み合わせは、属性がフラグメント化されている（Mフラグ）が、このチャンクではすべてのフラグメントが使用可能ではない（Tフラグ）ことを示します。 [RFC6929]を実装するプロキシはこれらの属性を無効と見なします（再構築できません）が、[RFC6929]のセクション5.2は未知の属性を転送する必要があることを示しているため、引き続き転送します。
As a consequence of this addition, the Reserved field is now 6 bits long (see Section 12.1 for some considerations). The following figure represents the new attribute format:
この追加の結果として、予約フィールドは6ビット長になりました（いくつかの考慮事項については、セクション12.1を参照してください）。次の図は、新しい属性フォーマットを表しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Updated Long Extended Type Attribute Format
図12：更新されたLong Extended Type Attribute Format
This document proposes the definition of two new extended type attributes, called Frag-Status and Proxy-State-Length. The format of these attributes follows the indications for an Extended Type attribute defined in [RFC6929].
このドキュメントでは、Frag-StatusとProxy-State-Lengthと呼ばれる2つの新しい拡張型属性の定義を提案しています。これらの属性の形式は、[RFC6929]で定義されている拡張タイプ属性の指示に従います。
This attribute is used for fragmentation signaling, and its meaning depends on the code value transported within it. The following figure represents the format of the Frag-Status attribute:
この属性はフラグメンテーションシグナリングに使用され、その意味は、その中で転送されるコード値によって異なります。次の図は、Frag-Status属性のフォーマットを表しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Frag-Status Format
図13：Frag-Statusのフォーマット
Type
タイプ
241
２４１
Length
長さ
7
７
Extended-Type
拡張タイプ
1
１
Code
コード
4 bytes. Integer indicating the code. The values defined in this specification are:
4バイト。コードを示す整数。この仕様で定義されている値は次のとおりです。
0 - Reserved
0-予約済み
1 - Fragmentation-Supported
1-フラグメンテーションサポート
2 - More-Data-Pending
2-データ保留中
3 - More-Data-Request
3-More-Data-Request
This attribute MAY be present in Access-Request, Access-Challenge, and Access-Accept packets. It MUST NOT be included in Access-Reject packets. RADIUS Clients supporting this specification MUST include a Frag-Status = Fragmentation-Supported attribute in the first Access-Request sent to the RADIUS Server, in order to indicate that they would accept fragmented data from the server.
この属性は、Access-Request、Access-Challenge、およびAccess-Acceptパケットに存在する場合があります。 Access-Rejectパケットに含めることはできません。この仕様をサポートするRADIUSクライアントは、サーバーからフラグメント化されたデータを受け入れることを示すために、RADIUSサーバーに送信される最初のAccess-RequestにFrag-Status = Fragmentation-Supported属性を含める必要があります。
This attribute indicates to the RADIUS Client the length of the Proxy-State attributes received by the RADIUS Server. This information is useful for adjusting the length of the chunks sent by the RADIUS Client. The format of this Proxy-State-Length attribute is as follows:
この属性は、RADIUSサーバーが受信したProxy-State属性の長さをRADIUSクライアントに示します。この情報は、RADIUSクライアントが送信するチャンクの長さを調整するのに役立ちます。このProxy-State-Length属性の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Proxy-State-Length Format
図14：プロキシ状態長の形式
Type
タイプ
241
２４１
Length
長さ
7
７
Extended-Type
拡張タイプ
2
２
Value
値
4 bytes. Total length (in bytes) of received Proxy-State attributes (including headers). As the RADIUS Length field cannot take values over 4096 bytes, values of Proxy-State-Length MUST be less than that maximum length.
4バイト。受信したProxy-State属性（ヘッダーを含む）の全長（バイト単位）。 RADIUSの長さフィールドは4096バイトを超える値をとることができないため、Proxy-State-Lengthの値はその最大長よりも小さい必要があります。
This attribute MAY be present in Access-Challenge and Access-Accept packets. It MUST NOT be included in Access-Request or Access-Reject packets.
この属性は、Access-ChallengeおよびAccess-Acceptパケットに存在する場合があります。 Access-RequestまたはAccess-Rejectパケットに含めることはできません。
The following table shows the different attributes defined in this document, along with the types of RADIUS packets in which they can be present.
次の表は、このドキュメントで定義されているさまざまな属性と、それらが存在できるRADIUSパケットのタイプを示しています。
| Type of Packet |
+-----+-----+-----+-----+
Attribute Name | Req | Acc | Rej | Cha |
----------------------+-----+-----+-----+-----+
Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
Proxy-State-Length | 0 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
The fragmentation mechanism defined above is designed to be transparent to legacy proxies, as long as they do not want to modify any fragmented attribute. Nevertheless, updated proxies supporting this specification can even modify fragmented attributes.
上で定義された断片化メカニズムは、断片化された属性を変更したくない限り、レガシープロキシに対して透過的になるように設計されています。それでも、この仕様をサポートする更新されたプロキシは、断片化された属性を変更することさえできます。
As every chunk is indeed a RADIUS packet, legacy proxies treat them as they would the rest of the packets, routing them to their destination. Proxies can introduce Proxy-State attributes into Access-Request packets, even if they are indeed chunks. This will not affect how fragmentation is managed. The RADIUS Server will include all the received Proxy-State attributes in the generated response, as described in [RFC2865]. Hence, proxies do not distinguish between a regular RADIUS packet and a chunk.
すべてのチャンクは確かにRADIUSパケットであるため、レガシープロキシはそれらを残りのパケットと同様に扱い、宛先にルーティングします。プロキシは、チャンクであってもAccess-RequestパケットにProxy-State属性を導入できます。これは、断片化の管理方法には影響しません。 [RFC2865]で説明されているように、RADIUSサーバーは、生成された応答に受信したすべてのProxy-State属性を含めます。したがって、プロキシは通常のRADIUSパケットとチャンクを区別しません。
Updated proxies can interact with RADIUS Clients and Servers in order to obtain the complete large packet before starting to forward it. In this way, proxies can manipulate (modify and/or remove) any attribute of the packet or introduce new attributes, without worrying about crossing the boundaries of the chunk size. Once the manipulated packet is ready, it is sent to the original destination using the fragmentation mechanism (if required). The example in Figure 15 shows how an updated proxy interacts with the RADIUS Client to (1) obtain a large Access-Request packet and (2) modify an attribute, resulting in an even larger packet. The proxy then interacts with the RADIUS Server to complete the transmission of the modified packet, as shown in Figure 16.
更新されたプロキシは、RADIUSクライアントおよびサーバーと対話して、転送を開始する前に完全な大きなパケットを取得できます。このようにして、プロキシは、チャンクサイズの境界を越えることを心配することなく、パケットの任意の属性を操作（変更および/または削除）したり、新しい属性を導入したりできます。操作されたパケットの準備ができると、（必要に応じて）フラグメンテーションメカニズムを使用して元の宛先に送信されます。図15の例は、更新されたプロキシがRADIUSクライアントと対話して、（1）大きなAccess-Requestパケットを取得し、（2）属性を変更して、さらに大きなパケットを生成する方法を示しています。次に、プロキシーはRADIUSサーバーと対話して、変更されたパケットの送信を完了します（図16を参照）。
+-+-+-+-+-+ +-+-+-+-+-+
| RADIUS | | RADIUS |
| Client | | Proxy |
+-+-+-+-+-+ +-+-+-+-+-+
| |
| Access-Request(1){User-Name,Calling-Station-Id, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State1} |
|<---------------------------------------------------|
| |
| Access-Request(2){User-Name,State1, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1} |
|--------------------------------------------------->|
Proxy Modifies Attribute Data, Increasing Its Size from 9 Fragments to 11 Fragments
プロキシは属性データを変更し、そのサイズを9フラグメントから11フラグメントに増やします
Figure 15: Updated Proxy Interacts with RADIUS Client
図15：更新されたプロキシはRADIUSクライアントと相互作用します
+-+-+-+-+-+ +-+-+-+-+-+
| RADIUS | | RADIUS |
| Proxy | | Server |
+-+-+-+-+-+ +-+-+-+-+-+
| |
| Access-Request(3){User-Name,Calling-Station-Id, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State2} |
|<---------------------------------------------------|
| |
| Access-Request(4){User-Name,State2, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State3} |
|<---------------------------------------------------|
| |
| Access-Request(5){User-Name,State3,Example-Long-1} |
|--------------------------------------------------->|
Figure 16: Updated Proxy Interacts with RADIUS Server
図16：更新されたプロキシはRADIUSサーバーと相互作用します
As described in Section 9, this document modifies the definition of the Reserved field of the Long Extended Type attribute [RFC6929] by allocating an additional flag called the T flag. The meaning and position of this flag are defined in this document, and nowhere else. This might cause an issue if subsequent specifications want to allocate a new flag as well, as there would be no direct way for them to know which parts of the Reserved field have already been defined.
セクション9で説明したように、このドキュメントは、Tフラグと呼ばれる追加のフラグを割り当てることにより、Long Extended Type属性[RFC6929]のReservedフィールドの定義を変更します。このフラグの意味と位置はこのドキュメントで定義されており、他の場所では定義されていません。予約済みフィールドのどの部分がすでに定義されているかを直接確認する方法がないため、後続の仕様でも新しいフラグを割り当てる必要がある場合、これにより問題が発生する可能性があります。
An immediate and reasonable solution for this issue would be declaring that this RFC updates [RFC6929]. In this way, [RFC6929] would include an "Updated by" clause that will point readers to this document. Another alternative would be creating an IANA registry for the Reserved field. However, the RADIUS Extensions (RADEXT) working group thinks that would be overkill, as a large number of specifications extending that field are not expected.
この問題の即時かつ合理的な解決策は、このRFCが更新されることを宣言することです[RFC6929]。このようにして、[RFC6929]は、このドキュメントを読者に示す「更新者」節を含みます。もう1つの方法は、予約済みフィールド用のIANAレジストリを作成することです。ただし、RADIUS拡張（RADEXT）ワーキンググループは、そのフィールドを拡張する多数の仕様が想定されていないため、これはやり過ぎであると考えています。
In the end, the proposed solution is that this experimental RFC should not update RFC 6929. Instead, we rely on the collective mind of the working group to remember that this T flag is being used as specified by this Experimental document. If the experiment is successful, the T flag will be properly assigned.
結局、提案された解決策は、この実験的なRFCがRFC 6929を更新すべきではないということです。代わりに、この実験的なドキュメントで指定されているようにこのTフラグが使用されていることを覚えておくために、ワーキンググループの集合的な考え方に依存します。実験が成功すると、Tフラグが適切に割り当てられます。
Section 5.1 indicates that all authorization and authentication handling will be postponed until all the chunks have been received. This postponement also applies to the verification that the Access-Request packet contains some kind of authentication attribute (e.g., User-Password, CHAP-Password, State, or other future attribute), as required by [RFC2865]. This checking will therefore be delayed until the original large packet has been rebuilt, as some of the chunks may not contain any of them.
セクション5.1は、すべてのチャンクが受信されるまで、すべての承認と認証の処理が延期されることを示しています。この延期は、[RFC2865]で要求されているように、Access-Requestパケットにある種の認証属性（User-Password、CHAP-Password、State、またはその他の将来の属性）が含まれていることの検証にも適用されます。したがって、このチェックは、チャンクの一部に含まれていない可能性があるため、元の大きなパケットが再構築されるまで遅延されます。
The authors acknowledge that this specification violates the "MUST" requirement of [RFC2865], Section 4.1 that states that "An Access-Request MUST contain either a User-Password or a CHAP-Password or a State." We note that a proxy that enforces that requirement would be unable to support future RADIUS authentication extensions. Extensions to the protocol would therefore be impossible to deploy. All known implementations have chosen the philosophy of "be liberal in what you accept." That is, they accept traffic that violates the requirement of [RFC2865], Section 4.1. We therefore expect to see no operational issues with this specification. After we gain more operational experience with this specification, it can be reissued as a Standards Track document and can update [RFC2865].
著者は、この仕様が[RFC2865]の「必須」の要件に違反していることを認めており、「アクセス要求には、ユーザーパスワードまたはCHAPパスワードまたは状態のいずれかが含まれている必要がある」と述べています。その要件を適用するプロキシは、将来のRADIUS認証拡張をサポートできなくなることに注意してください。したがって、プロトコルの拡張機能を展開することはできません。すべての既知の実装は、「受け入れるものを自由にする」という哲学を選択しています。つまり、[RFC2865]、セクション4.1の要件に違反するトラフィックを受け入れます。したがって、この仕様では運用上の問題は発生しないと予想されます。この仕様でより多くの運用経験を得た後、それを標準化トラックドキュメントとして再発行し、[RFC2865]を更新できます。
This proposal assumes that legacy proxies base their routing decisions on the value of the User-Name attribute. For this reason, every packet sent from the RADIUS Client to the RADIUS Server (either chunks or requests for more chunks) MUST contain a User-Name attribute.
この提案は、レガシープロキシがルーティングの決定をUser-Name属性の値に基づいていることを前提としています。このため、RADIUSクライアントからRADIUSサーバーに送信されるすべてのパケット（チャンクまたは追加のチャンクの要求）には、User-Name属性が含まれている必要があります。
This proposal does not modify the way RADIUS interacts with the underlying transport (UDP). That is, RADIUS keeps following a lock-step behavior that requires receiving an explicit acknowledgement for each chunk sent. Hence, bursts of traffic that could congest links between peers are not an issue.
この提案は、RADIUSが基になるトランスポート（UDP）と対話する方法を変更しません。つまり、RADIUSは、送信されたチャンクごとに明示的な確認応答を受信する必要があるロックステップ動作を続けます。したがって、ピア間のリンクを混雑させる可能性のあるトラフィックのバーストは問題になりません。
Another benefit of the lock-step nature of RADIUS is that there are no security issues with overlapping fragments. Each chunk simply has a length, with no Fragment Offset field as with IPv4. The order of the fragments is determined by the order in which they are received. There is no ambiguity about the size or placement of each chunk, and therefore no security issues associated with overlapping chunks.
RADIUSのロックステップの性質のもう1つの利点は、フラグメントの重複によるセキュリティの問題がないことです。各チャンクの長さは単純で、IPv4の場合のようにフラグメントオフセットフィールドはありません。フラグメントの順序は、フラグメントが受信された順序によって決まります。各チャンクのサイズや配置に曖昧さはなく、したがって、チャンクの重複に関連するセキュリティの問題はありません。
As noted in many earlier specifications ([RFC5080], [RFC6158], etc.), RADIUS security is problematic. This specification changes nothing related to the security of the RADIUS protocol. It requires that all Access-Request packets associated with fragmentation are authenticated using the existing Message-Authenticator attribute. This signature prevents forging and replay, to the limits of the existing security.
以前の多くの仕様（[RFC5080]、[RFC6158]など）で述べたように、RADIUSのセキュリティには問題があります。この仕様は、RADIUSプロトコルのセキュリティに関連するものは何も変更しません。フラグメンテーションに関連付けられているすべてのAccess-Requestパケットは、既存のMessage-Authenticator属性を使用して認証される必要があります。このシグネチャは、既存のセキュリティの限界まで、偽造と再生を防ぎます。
The ability to send bulk data from one party to another creates new security considerations. RADIUS Clients and Servers may have to store large amounts of data per session. The amount of this data can be significant, leading to the potential for resource exhaustion. We therefore suggest that implementations limit the amount of bulk data stored per session. The exact method for this limitation is implementation-specific. Section 7 gives some indications of what could be reasonable limits.
あるパーティから別のパーティにバルクデータを送信する機能により、セキュリティに関する新しい考慮事項が生まれます。 RADIUSクライアントとサーバーは、セッションごとに大量のデータを保存する必要がある場合があります。このデータの量は膨大になり、リソースが枯渇する可能性があります。したがって、実装により、セッションごとに保存されるバルクデータの量を制限することをお勧めします。この制限の正確な方法は、実装によって異なります。セクション7は、合理的な制限となる可能性のあるものを示しています。
The bulk data can often be pushed off to storage methods other than the memory of the RADIUS implementation. For example, it can be stored in an external database or in files. This approach mitigates the resource exhaustion issue, as RADIUS Servers today already store large amounts of accounting data.
バルクデータは、RADIUS実装のメモリ以外のストレージメソッドにプッシュされることがよくあります。たとえば、外部データベースやファイルに保存できます。現在、RADIUSサーバーはすでに大量のアカウンティングデータを格納しているため、このアプローチはリソースの枯渇の問題を軽減します。
The Internet Assigned Numbers Authority (IANA) has registered the Attribute Types and Attribute Values defined in this document in the RADIUS namespaces as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes, and registries created by this document, IANA has updated <http://www.iana.org/assignments/radius-types> accordingly.
Internet Assigned Numbers Authority（IANA）は、このドキュメントで定義されている属性タイプと属性値を、BCP 26 [RFC5226]に従って[RFC3575]の「IANAに関する考慮事項」セクションで説明されているように、RADIUS名前空間に登録しました。このドキュメントで作成されたRADIUSパケット、属性、およびレジストリについては、IANAはそれに応じて<http://www.iana.org/assignments/radius-types>を更新しました。
In particular, this document defines two new RADIUS attributes, entitled "Frag-Status" (value 241.1) and "Proxy-State-Length" (value 241.2), which have been allocated from the short extended space as described in [RFC6929]:
特に、このドキュメントは、[RFC6929]で説明されているように、短い拡張スペースから割り当てられた「Frag-Status」（値241.1）および「Proxy-State-Length」（値241.2）という2つの新しいRADIUS属性を定義します。
Type Name Length Meaning
---- ---- ------ -------
241.1 Frag-Status 7 Signals fragmentation
241.2 Proxy-State-Length 7 Indicates the length of the
received Proxy-State attributes
The Frag-Status attribute also defines an 8-bit "Code" field, for which IANA has created and now maintains a new sub-registry entitled "Code Values for RADIUS Attribute 241.1, Frag-Status". Initial values for the RADIUS Frag-Status "Code" registry are given below; future assignments are to be made through "RFC Required" [RFC5226]. Assignments consist of a Frag-Status "Code" name and its associated value.
Frag-Status属性は、8ビットの「コード」フィールドも定義します。IANAはこのフィールドを作成し、「RADIUS属性241.1のコード値、Frag-Status」というタイトルの新しいサブレジストリを維持しています。 RADIUS Frag-Status "Code"レジストリの初期値を以下に示します。将来の割り当ては、「RFCが必要」[RFC5226]を通じて行われます。割り当ては、Frag-Statusの「コード」名とそれに関連付けられた値で構成されます。
Value Frag-Status Code Name Definition
---- ------------------------ ----------
0 Reserved See Section 10.1
1 Fragmentation-Supported See Section 10.1
2 More-Data-Pending See Section 10.1
3 More-Data-Request See Section 10.1
4-255 Unassigned
Additionally, IANA has allocated a new Service-Type value for "Additional-Authorization".
さらに、IANAは「追加の許可」に新しいService-Type値を割り当てました。
Value Service Type Value Definition
---- ------------------------ ----------
19 Additional-Authorization See Section 5.1
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000, <http://www.rfc-editor.org/ info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月、<http：//www.rfc- editor.org/ info / rfc2865>。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>.
[RFC3575] Aboba、B。、「RADIUS（Remote Authentication Dial In User Service）に関するIANAの考慮事項」、RFC 3575、2003年7月、<http://www.rfc-editor.org/info/rfc3575>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011, <http://www.rfc-editor.org/info/rfc6158>.
[RFC6158] DeKok、A.、Ed。、およびG. Weber、「RADIUS Design Guidelines」、BCP 158、RFC 6158、2011年3月、<http://www.rfc-editor.org/info/rfc6158>。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013, <http://www.rfc-editor.org/info/rfc6929>.
[RFC6929] DeKok、A。およびA. Lior、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、RFC 6929、2013年4月、<http://www.rfc-editor.org/info/rfc6929>。
[ABFAB-Arch] Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, draft-ietf-abfab-arch-13, July 2014.
[ABFAB-Arch] Howlett、J.、Hartman、S.、Tschofenig、H.、Lear、E。、およびJ. Schaad、「Webを超えたフェデレーテッドアクセスのアプリケーションブリッジング（ABFAB）アーキテクチャ」、作業中、ドラフト- ietf-abfab-arch-13、2014年7月。
[RADIUS-Larger-Pkts] Hartman, S., "Larger Packets for RADIUS over TCP", Work in Progress, draft-ietf-radext-bigger-packets-03, March 2015.
[RADIUS-Larger-Pkts] Hartman、S。、「RADIUS over TCPのより大きなパケット」、作業中、draft-ietf-radext-bigger-packets-03、2015年3月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, <http://www.rfc-editor.org/info/rfc2866>.
[RFC2866] Rigney、C。、「RADIUS Accounting」、RFC 2866、2000年6月、<http://www.rfc-editor.org/info/rfc2866>。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003, <http://www.rfc-editor.org/info/rfc3579>.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（Remote Authentication Dial In User Service）Support For Extensible Authentication Protocol（EAP）」、RFC 3579、2003年9月、<http://www.rfc-editor.org / info / rfc3579>。
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007, <http://www.rfc-editor.org/info/rfc4849>.
[RFC4849] Congdon、P.、Sanchez、M。、およびB. Aboba、「RADIUS Filter Rule Attribute」、RFC 4849、2007年4月、<http://www.rfc-editor.org/info/rfc4849>。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007, <http://www.rfc-editor.org/info/rfc5080>.
[RFC5080] Nelson、D。およびA. DeKok、「Common Remote Authentication Dial In User Service（RADIUS）Implementation Issues and Suggested Fixes」、RFC 5080、2007年12月、<http://www.rfc-editor.org/info / rfc5080>。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008, <http://www.rfc-editor.org/info/rfc5176>.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008、 <http://www.rfc-editor.org/info/rfc5176>。
[SAML-RADIUS] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML", Work in Progress, draft-ietf-abfab-aaa-saml-10, February 2015.
[SAML-RADIUS]ハウレット、J。、ハートマン、S。、およびA.ペレス-メンデス、編、「SAMLのRADIUS属性、バインディング、プロファイル、名前識別子形式、および確認方法」、進行中の作業、ドラフト-ietf-abfab-aaa-saml-10、2015年2月。
Acknowledgements
謝辞
The authors would like to thank the members of the RADEXT working group who have contributed to the development of this specification by either participating in the discussions on the mailing lists or sending comments about our RFC.
著者は、メーリングリストでの議論に参加するか、RFCに関するコメントを送信することにより、この仕様の開発に貢献してきたRADEXTワーキンググループのメンバーに感謝します。
The authors also thank David Cuenca (University of Murcia) for implementing a proof-of-concept implementation of this RFC that has been useful to improve the quality of the specification.
著者はまた、仕様の品質を向上させるのに役立つこのRFCの概念実証実装を実装してくれたDavid Cuenca（ムルシア大学）に感謝します。
This work has been partly funded by the GEANT GN3+ SA5 and CLASSe (<http://www.um.es/classe/>) projects.
この作品は、GEANT GN3 + SA5およびCLASSe（<http://www.um.es/classe/>）プロジェクトから一部資金提供を受けています。
Authors' Addresses
著者のアドレス
Alejandro Perez-Mendez (editor) University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
Alejandro Perez-Mendez（編集者）ムルシア大学Campus de Espinardo S / N、Faculty of Computer Science Murcia 30100 Spain
Phone: +34 868 88 46 44
EMail: alex@um.es
Rafa Marin-Lopez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
ラファマリンロペスムルシア大学キャンパスデエスピナルドS / N、コンピュータサイエンス学部ムルシア30100スペイン
Phone: +34 868 88 85 01
EMail: rafa@um.es
Fernando Pereniguez-Garcia University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
フェルナンドペレニゲスガルシアムルシア大学キャンパスデエスピナルドS / N、コンピュータサイエンス学部ムルシア30100スペイン
Phone: +34 868 88 78 82 EMail: pereniguez@um.es Gabriel Lopez-Millan University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
電話：+34 868 88 78 82メール：pereniguez@um.esガブリエルロペスミランムルシア大学キャンパスデエスピナルドS / N、コンピュータサイエンス学部ムルシア30100スペイン
Phone: +34 868 88 85 04
EMail: gabilm@um.es
Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 84 Madrid 28006 Spain
Diego R. Lopez Telefonica I + D Don Ramon de la Cruz、84 Madrid 28006 Spain
Phone: +34 913 129 041
EMail: diego@tid.es
Alan DeKok Network RADIUS SARL 57bis Boulevard des Alpes Meylan 38240 France
Alan DeKok Network RADIUS SARL 57bis Boulevard des Alpes Meylan 38240 France
EMail: aland@networkradius.com
URI: http://networkradius.com