RFC 7930 - Larger Packets for RADIUS over TCP 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7930
タイトル : RFC 7930 - RADIUS over TCPの大きなパケット
翻訳編集 : 自動生成

[要約] RFC 7930は、RADIUS over TCPでの大きなパケットのサポートに関する仕様です。その目的は、RADIUSメッセージのサイズ制限を拡張し、より効率的なネットワーク通信を可能にすることです。

Internet Engineering Task Force (IETF)                        S. Hartman
Request for Comments: 7930                             Painless Security
Updates: 6613                                                August 2016
Category: Experimental
ISSN: 2070-1721

Larger Packets for RADIUS over TCP

RADIUS over TCPの大きなパケット

Abstract

概要

The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.

RFC 6614で説明されているRADIUS-over-TLS実験により、RADIUSパケットの4096オクテットの最大サイズ制限が問題となる新しい使用例にRADIUSが開かれました。この仕様は、RADIUS-over-TCP実験（RFC 6613）を拡張して、より大きなRADIUSパケットを許可します。この仕様は、RADIUS認可情報の断片化を許可するために進行中の他の作業を補完します。このドキュメントでは、新しいRADIUSコード、つまりIESGの承認が必要なアクションを登録しています。

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 7841.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc7930.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7930で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
   2.  Changes to Packet Processing  . . . . . . . . . . . . . . . .   4
     2.1.  Status-Server Considerations  . . . . . . . . . . . . . .   4
   3.  Forward and Backward Compatibility  . . . . . . . . . . . . .   5
     3.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Protocol-Error Code . . . . . . . . . . . . . . . . . . . . .   7
   5.  Too Big Response  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

1. はじめに

The experiment with Remote Authentication Dial-In User Service (RADIUS) over Transport Layer Security (TLS) [RFC6614] provides strong confidentiality and integrity for RADIUS [RFC2865]. This enhanced security has opened new opportunities for using RADIUS to convey additional authorization information. As an example, [RFC7833] describes a mechanism for using RADIUS to carry Security Assertion Markup Language (SAML) messages in RADIUS. Many attributes carried in these SAML messages will require confidentiality or integrity such as that provided by TLS.

トランスポート層セキュリティ（TLS）を介したリモート認証ダイヤルインユーザーサービス（RADIUS）の実験[RFC6614]は、RADIUS [RFC2865]に強力な機密性と整合性を提供します。この強化されたセキュリティにより、RADIUSを使用して追加の認証情報を伝達する新しい機会が開かれました。例として、[RFC7833]は、RADIUSを使用してセキュリティアサーションマークアップ言語（SAML）メッセージをRADIUSで伝送するメカニズムについて説明しています。これらのSAMLメッセージで伝達される多くの属性には、TLSによって提供されるものなどの機密性または整合性が必要です。

These new use cases involve carrying additional information in RADIUS packets. The maximum packet length of 4096 octets is proving insufficient for some SAML messages and for other structures that may be carried in RADIUS.

これらの新しい使用例には、RADIUSパケットで追加情報を運ぶことが含まれます。 4096オクテットの最大パケット長は、一部のSAMLメッセージや、RADIUSで伝送される可能性のある他の構造には不十分であることを証明しています。

One approach is to fragment a RADIUS message across multiple packets at the RADIUS layer. RADIUS fragmentation [RFC7499] provides a mechanism to split authorization information across multiple RADIUS messages. That mechanism is necessary in order to split authorization information across existing unmodified proxies.

1つのアプローチは、RADIUSレイヤーで複数のパケットにまたがってRADIUSメッセージをフラグメント化することです。 RADIUSフラグメンテーション[RFC7499]は、認証情報を複数のRADIUSメッセージに分割するメカニズムを提供します。そのメカニズムは、既存の変更されていないプロキシ間で認証情報を分割するために必要です。

However, there are some significant disadvantages to RADIUS fragmentation. First, RADIUS is a lock-step protocol, and only one fragment can be in transit at a time as part of a given request. Also, there is no current mechanism to discover the Path Maximum Transmission Unit (PMTU) across the entire path that the fragment will travel. As a result, fragmentation is likely both at the RADIUS layer and at the transport layer. When TCP is used, much better transport characteristics can be achieved by fragmentation only at the TCP layer. This specification provides a mechanism to achieve these better transport characteristics when TCP is used. As part of this specification, a new RADIUS code is registered.

ただし、RADIUSフラグメンテーションにはいくつかの重大な欠点があります。まず、RADIUSはロックステッププロトコルであり、特定の要求の一部として一度に送信できるフラグメントは1つだけです。また、フラグメントが移動するパス全体のパス最大転送単位（PMTU）を検出する現在のメカニズムはありません。その結果、断片化はRADIUS層とトランスポート層の両方で発生する可能性があります。 TCPを使用すると、TCP層でのみフラグメンテーションを行うことにより、はるかに優れたトランスポート特性を実現できます。この仕様は、TCPが使用されるときにこれらのより良いトランスポート特性を実現するメカニズムを提供します。この仕様の一部として、新しいRADIUSコードが登録されます。

This specification is published as an Experimental specification because the TCP extensions to RADIUS are currently experimental. The need for this specification arises from operational experience with the TCP extensions. However, this specification introduces no new experimental evaluation criteria beyond those in the base TCP specification; this specification can be evaluated along with that one for advancement on the Standards Track.

RADIUSへのTCP拡張は現在実験的であるため、この仕様は実験的仕様として公開されています。この仕様の必要性は、TCP拡張機能の運用経験から生じます。ただし、この仕様では、基本的なTCP仕様の基準を超える新しい実験的評価基準は導入されていません。この仕様は、規格トラックでの進歩のために、それとともに評価できます。

1.1. Requirements Notation

1.1. 要件表記

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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. Changes to Packet Processing

2. パケット処理の変更

The maximum length of a RADIUS message is increased from 4096 to 65535. A RADIUS Server implementing this specification MUST be able to receive a RADIUS packet of maximum length. Servers MAY have a maximum size over which they choose to return an error, as discussed in Section 5, rather than processing a received packet; this size MUST be at least 4096 octets.

RADIUSメッセージの最大長が4096から65535に増加しました。この仕様を実装するRADIUSサーバーは、最大長のRADIUSパケットを受信できる必要があります。サーバーは、セクション5で説明したように、受信したパケットを処理するのではなく、エラーを返すことを選択する最大サイズを持つ場合があります。このサイズは少なくとも4096オクテットでなければなりません。

Clients implementing this specification MUST be able to receive a RADIUS packet of maximum length; that is, clients MUST NOT close a TCP connection simply because a large packet is sent over it. Clients MAY include the Response-Length attribute defined in Section 6 to indicate the maximum size of a packet that they can successfully process. Clients MAY silently discard a packet greater than some configured size; this size MUST be at least 4096 octets. Clients MUST NOT retransmit an unmodified request whose response is larger than the client can process, as subsequent responses will likely continue to be too large.

この仕様を実装するクライアントは、最大長のRADIUSパケットを受信できる必要があります。つまり、クライアントは、大きなパケットがTCP接続を介して送信されるという理由だけでTCP接続を閉じてはなりません（MUST NOT）。クライアントは、正常に処理できるパケットの最大サイズを示すために、セクション6で定義されたResponse-Length属性を含めることができます。クライアントは、構成されたサイズより大きいパケットを警告なく破棄する場合があります。このサイズは少なくとも4096オクテットでなければなりません。クライアントは、応答がクライアントが処理できるよりも大きい変更されていないリクエストを再送信してはなりません。

Proxies MUST be able to receive a RADIUS packet of maximum length without closing the TCP connection. Proxies SHOULD be able to process and forward packets of maximum length. When a proxy receives a request over a transport with a 4096-octet maximum length and the proxy forwards that request over a transport with a larger maximum length, the proxy MUST include the Response-Length attribute with a value of 4096.

プロキシは、TCP接続を閉じずに最大長のRADIUSパケットを受信できる必要があります。プロキシは、最大長のパケットを処理および転送できる必要があります（SHOULD）。プロキシーが最大長4096オクテットのトランスポートを介して要求を受信し、プロキシーがその最大長のトランスポートを介してその要求を転送する場合、プロキシーは値4096のResponse-Length属性を含める必要があります。

2.1. Status-Server Considerations

2.1. ステータスサーバーに関する考慮事項

This section extends processing of Status-Server messages as described in Sections 4.1 and 4.2 of [RFC5997].

このセクションは、[RFC5997]のセクション4.1および4.2で説明されているように、Status-Serverメッセージの処理を拡張します。

Clients implementing this specification SHOULD include the Response-Length attribute in Status-Server requests. Servers are already required to ignore unknown attributes received in this message. By including the attribute, the client indicates how large of a response it can process to its Status-Server request. It is very unlikely that a response to Status-Server is greater than 4096 octets. However, the client also indicates support for this specification, which triggers the server behavior below.

この仕様を実装するクライアントは、Status-ServerリクエストにResponse-Length属性を含める必要があります（SHOULD）。サーバーは、このメッセージで受信した不明な属性を無視する必要があります。属性を含めることにより、クライアントは、Status-Server要求に対して処理できる応答の大きさを示します。 Status-Serverへの応答が4096オクテットを超えることはほとんどありません。ただし、クライアントはこの仕様のサポートも示しているため、以下のサーバー動作がトリガーされます。

If a server implementing this specification receives a Response-Length attribute in a Status-Server request, it MUST include a Response-Length attribute indicating the maximum size request it can process in its response to the Status-Server request.

この仕様を実装するサーバーがStatus-Server要求でResponse-Length属性を受け取る場合、Status-Server要求への応答で処理できる最大サイズの要求を示すResponse-Length属性を含める必要があります。

3. Forward and Backward Compatibility

3. 前方および後方互換性

An implementation of [RFC6613] will silently discard any RADIUS packet larger than 4096 octets and will close the TCP connection. This section provides guidelines for interoperability with these implementations. These guidelines are stated at the SHOULD level. In some environments, support for large packets will be important enough that roaming or other agreements will mandate their support. In these environments, all implementations might be required to support this specification, thus removing the need for interoperability with RFC 6613. It is likely that these guidelines will be relaxed to the MAY level and support for this specification made a requirement if RADIUS over TLS and TCP are moved to the Standards Track in the future.

[RFC6613]の実装は、4096オクテットより大きいRADIUSパケットを警告なしに破棄し、TCP接続を閉じます。このセクションでは、これらの実装との相互運用性に関するガイドラインを示します。これらのガイドラインは、SHOULDレベルで述べられています。一部の環境では、大きなパケットのサポートが非常に重要であり、ローミングまたはその他の合意によりサポートが義務付けられます。これらの環境では、すべての実装がこの仕様をサポートする必要があるため、RFC 6613との相互運用性の必要性がなくなります。これらのガイドラインはMAYレベルまで緩和され、RADIUS over TLSおよびTCPは将来的に標準トラックに移行されます。

Clients SHOULD provide configuration for the maximum size of a request sent to each server. Servers SHOULD provide configuration for the maximum size of a response sent to each client. If dynamic discovery mechanisms are supported, configuration SHOULD be provided for the default maximum size of RADIUS packets sent to clients and servers. If an implementation provides more granular configuration for some classes of dynamic resources, then the implementation SHOULD also provide configuration of default maximum packet sizes at the same granularity. As an example, an implementation that provided granular configuration for resources using a particular trust anchor or belonging to a particular roaming consortium SHOULD provide default packet size configuration at the same granularity.

クライアントは、各サーバーに送信されるリクエストの最大サイズの構成を提供する必要があります（SHOULD）。サーバーは、各クライアントに送信される応答の最大サイズの構成を提供する必要があります（SHOULD）。動的検出メカニズムがサポートされている場合、クライアントとサーバーに送信されるRADIUSパケットのデフォルトの最大サイズに対して構成を提供する必要があります（SHOULD）。実装が動的リソースのいくつかのクラスに対してより細かい構成を提供する場合、実装は同じ細かさでデフォルトの最大パケットサイズの構成も提供する必要があります（SHOULD）。例として、特定のトラストアンカーを使用する、または特定のローミングコンソーシアムに属するリソースに詳細な構成を提供する実装は、同じ粒度でデフォルトのパケットサイズ構成を提供する必要があります（SHOULD）。

If a client sends a request larger than 4096 octets and the TCP connection is closed without a response, the client SHOULD treat the request as if a "Request Too Big" error (Section 5) specifying a maximum size of 4096 is received. Clients or proxies sending multiple requests over a single TCP connection without waiting for responses SHOULD implement capability discovery as discussed in Section 3.2.

クライアントが4096オクテットを超えるリクエストを送信し、TCP接続が応答なしで閉じられた場合、クライアントは、4096の最大サイズを指定する "Request Too Big"エラー（セクション5）が受信されたかのようにリクエストを処理する必要があります（SHOULD）。応答を待たずに単一のTCP接続を介して複数の要求を送信するクライアントまたはプロキシは、セクション3.2で説明するように、機能検出を実装する必要があります（SHOULD）。

By default, a server SHOULD NOT generate a response larger than 4096 octets. The Response-Length attribute MAY be included in a request to indicate that larger responses are acceptable. Other attributes or configurations MAY be used as an indicator that large responses are likely to be acceptable.

デフォルトでは、サーバーは4096オクテットを超える応答を生成してはなりません（SHOULD NOT）。より大きな応答が受け入れられることを示すために、Response-Length属性をリクエストに含めることができます。他の属性または構成は、大きな応答が許容される可能性が高いことを示す指標として使用される場合があります。

A proxy that implements both this specification and RADIUS fragmentation [RFC7499] SHOULD use RADIUS fragmentation when the following conditions are met:

この仕様とRADIUSフラグメンテーションの両方を実装するプロキシは[RFC7499]次の条件が満たされたときにRADIUSフラグメンテーションを使用する必要があります（SHOULD）。

1. A RADIUS packet is being forwarded towards a next hop whose configuration does not support a packet that large.

1. RADIUSパケットは、その大きなパケットをサポートしない構成のネクストホップに転送されています。

2. RADIUS fragmentation can be used for the packet in question.

2. 問題のパケットにRADIUSフラグメンテーションを使用できます。

3.1. Rationale

3.1. 根拠

The interoperability challenge appears at first significant. This specification proposes to introduce behavior where new implementations will fail to function with existing implementations.

相互運用性の課題は、最初は重要です。この仕様は、新しい実装が既存の実装では機能しない場合の動作を導入することを提案しています。

However, these capabilities are introduced to support new use cases. If an implementation has 10000 octets of attributes to send, it cannot, in general, trim down the response to something that can be sent. Under this specification, a large packet would be generated that will be silently discarded by an existing implementation. Without this specification, no packet is generated because the required attributes cannot be sent.

ただし、これらの機能は、新しい使用例をサポートするために導入されています。実装が送信する属性の10000オクテットを持っている場合、一般に、送信可能なものへの応答を削減することはできません。この仕様の下では、既存の実装によって静かに破棄される大きなパケットが生成されます。この指定がないと、必要な属性を送信できないため、パケットは生成されません。

The biggest risk to interoperability would be if requests and responses are expanded to include additional information that is not strictly necessary. So, avoiding creating situations where large packets are sent to existing implementations is mostly an operational matter. Interoperability is most impacted when the size of packets in existing use cases is significantly increased and least impacted when large packets are used for new use cases where the deployment is likely to require updated RADIUS implementations.

相互運用性に対する最大のリスクは、厳密に必要ではない追加情報を含めるように要求と応答が拡張される場合です。したがって、大きなパケットが既存の実装に送信される状況を回避することは、ほとんどの場合運用上の問題です。相互運用性は、既存のユースケースでパケットのサイズが大幅に増加したときに最も影響を受け、展開で更新されたRADIUS実装が必要になる可能性が高い新しいユースケースで大きなパケットが使用されたときに影響が最も少なくなります。

There is a special challenge for proxies or clients with a high request volume. When an implementation of RFC 6613 receives a packet that is too large, it closes the connection and does not respond to any requests in process. Such a client would lose requests and might find it difficult to distinguish "Request Too Big" situations from other failures. In these cases, the discovery mechanism described in Section 3.2 can be used.

リクエスト数が多いプロキシまたはクライアントには、特別な課題があります。 RFC 6613の実装が大きすぎるパケットを受信すると、接続を閉じ、処理中の要求に応答しません。このようなクライアントはリクエストを失い、「リクエストが大きすぎる」状況を他の失敗と区別するのが難しい場合があります。これらの場合、セクション3.2で説明した検出メカニズムを使用できます。

Also, RFC 6613 is an experiment. Part of running that experiment is to evaluate whether additional changes are required to RADIUS. A lower bar for interoperability should apply to changes to Experimental protocols than Standard protocols.

また、RFC 6613は実験です。その実験の実行の一部は、RADIUSに追加の変更が必要かどうかを評価することです。相互運用性の低いバーは、標準プロトコルよりも実験プロトコルへの変更に適用する必要があります。

This specification provides good facilities to enable implementations to understand packet size when proxying to/from Standards Track UDP RADIUS.

この仕様は、Standards Track UDP RADIUSとの間でプロキシを行うときに、実装がパケットサイズを理解できるようにする優れた機能を提供します。

3.2. Discovery

3.2. 発見

As discussed in Section 2.1, a client MAY send a Status-Server message to discover whether an authentication or accounting server supports this specification. The client includes a Response-Length attribute; this signals the server to include a Response-Length attribute indicating the maximum packet size the server can process. In this one instance, Response-Length indicates the size of a request that can be processed rather than a response.

セクション2.1で説明したように、クライアントはStatus-Serverメッセージを送信して、認証サーバーまたはアカウンティングサーバーがこの仕様をサポートしているかどうかを検出できます（MAY）。クライアントにはResponse-Length属性が含まれています。これは、サーバーが処理できる最大パケットサイズを示すResponse-Length属性を含めるようにサーバーに通知します。この1つの例では、Response-Lengthは、応答ではなく処理できる要求のサイズを示します。

4. Protocol-Error Code

4. プロトコルエラーコード

This document defines a new RADIUS code, 52, called Protocol-Error. This packet code may be used in response to any request packet, such as Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. It is a response packet sent by a server to a client. The packet indicates to the client that the server is unable to process the request for some reason.

このドキュメントでは、プロトコルエラーと呼ばれる新しいRADIUSコード52を定義しています。このパケットコードは、Access-Request、Accounting-Request、CoA-Request、Disconnect-Requestなどの要求パケットに応答して使用できます。これは、サーバーからクライアントに送信される応答パケットです。パケットは、サーバーが何らかの理由で要求を処理できないことをクライアントに示します。

A Protocol-Error packet MUST contain an Original-Packet-Code attribute, along with an Error-Cause attribute. Other attributes MAY be included if desired. The Original-Packet-Code contains the code from the request that generated the protocol error so that clients can disambiguate requests with different codes and the same ID. Regardless of the original packet code, the RADIUS Server calculates the Message-Authenticator attribute as if the original packet were an Access-Request packet. The identifier is copied from the original request.

Protocol-Errorパケットには、Error-Cause属性とともにOriginal-Packet-Code属性が含まれている必要があります。必要に応じて、他の属性を含めることができます。 Original-Packet-Codeには、プロトコルエラーを生成したリクエストのコードが含まれているため、クライアントは、異なるコードと同じIDのリクエストを明確化できます。元のパケットコードに関係なく、RADIUSサーバーは、元のパケットがAccess-RequestパケットであるかのようにMessage-Authenticator属性を計算します。識別子は元のリクエストからコピーされます。

Clients processing Protocol-Error MUST ignore unknown or unexpected attributes.

Protocol-Errorを処理するクライアントは、不明または予期しない属性を無視する必要があります。

This RADIUS code is hop by hop. Proxies MUST NOT forward a Protocol-Error packet they receive.

このRADIUSコードはホップバイホップです。プロキシは、受信したプロトコルエラーパケットを転送してはなりません。

5. Too Big Response

5. 大きすぎる応答

When a RADIUS Server receives a request that is larger than can be processed, it generates a Protocol-Error response as follows:

RADIUSサーバーは、処理可能なサイズを超える要求を受信すると、次のようにプロトコルエラー応答を生成します。

The code is Protocol-Error.

コードはProtocol-Errorです。

The Response-Length attribute MUST be included and its value is the maximum size of request that will be processed.

Response-Length属性が含まれている必要があり、その値は処理されるリクエストの最大サイズです。

The Error-Cause attribute is included with a value of 601.

Error-Cause属性には、値601が含まれています。

The Original-Packet-Code attribute is copied from the request.

Original-Packet-Code属性がリクエストからコピーされます。

Clients will not typically be able to adjust and resend requests when this error is received. In some cases, the client can fall back to RADIUS fragmentation. In other cases, this code will provide for better client error reporting and will avoid retransmitting requests guaranteed to fail.

通常、クライアントは、このエラーを受け取ったときに要求を調整して再送信できません。場合によっては、クライアントはRADIUSフラグメンテーションにフォールバックできます。他の場合では、このコードはクライアントのエラー報告を改善し、失敗することが保証されたリクエストの再送信を回避します。

6. IANA Considerations

6. IANAに関する考慮事項

A new RADIUS Packet Type Code is registered in the "RADIUS Packet Type Codes" registry discussed in Section 2.1 of RFC 3575 [RFC3575]. The name is "Protocol-Error" and the code is 52.

新しいRADIUSパケットタイプコードは、RFC 3575 [RFC3575]のセクション2.1で説明されている「RADIUSパケットタイプコード」レジストリに登録されています。名前は「Protocol-Error」で、コードは52です。

The following RADIUS attribute Type values [RFC3575] are assigned. The assignment rules in Section 10.3 of [RFC6929] are used.

次のRADIUS属性タイプ値[RFC3575]が割り当てられています。 [RFC6929]のセクション10.3の割り当てルールが使用されます。

   +----------------------+-----------+--------------------------------+
   | Name                 | Attribute | Description                    |
   +----------------------+-----------+--------------------------------+
   | Response-Length      | 241.3     | An attribute of type "integer" |
   |                      |           | per Section 5 of RFC 2865      |
   |                      |           | containing maximum response    |
   |                      |           | length.                        |
   |                      |           |                                |
   | Original-Packet-Code | 241.4     | An integer attribute           |
   |                      |           | containing the code from a     |
   |                      |           | packet resulting in a          |
   |                      |           | Protocol-Error response.       |
   +----------------------+-----------+--------------------------------+

The Response-Length attribute MAY be included in any RADIUS request. In this context, it indicates the maximum length of a response the client is prepared to receive. Values are between 4096 and 65535. The attribute MAY also be included in a response to a Status-Server message. In this case, the attribute indicates the maximum size RADIUS request that is permitted.

Response-Length属性は、すべてのRADIUS要求に含めることができます。このコンテキストでは、クライアントが受信する準備ができている応答の最大長を示します。値は4096〜65535です。属性は、Status-Serverメッセージへの応答に含めることもできます（MAY）。この場合、この属性は、許可されるRADIUS要求の最大サイズを示します。

A new Error-Cause value is registered in the "Values for RADIUS Attribute 101, Error-Cause Attribute" registry at <http://www.iana.org/assignments/radius-types> for "Response Too Big" with value 601. The range of valid values for the Error-Cause attribute in the "Values for RADIUS Attribute 101, Error-Cause Attribute" registry originally defined in RFC 5176 are extended. Two new ranges are defined:

<Response Too Big "の<http://www.iana.org/assignments/radius-types>にある" RADIUS Attribute 101、Error-Cause Attributes "レジストリに値601の新しいError-Cause値が登録されています。RFC 5176で最初に定義された「RADIUS属性101の値、エラー原因属性」レジストリのエラー原因属性の有効な値の範囲が拡張されました。 2つの新しい範囲が定義されています。

6xx fatal errors committed by a RADIUS server

RADIUSサーバーによってコミットされた6xxの致命的なエラー

7xx fatal errors committed by a RADIUS client

RADIUSクライアントによってコミットされた7xxの致命的なエラー

7. Security Considerations

7. セキュリティに関する考慮事項

This specification updates [RFC6613] and will be used with [RFC6614]. When used over plain TCP, this specification creates new opportunities for an on-path attacker to impact availability. These attacks can be entirely mitigated by using TLS. If these attacks are acceptable, then this specification can be used over TCP without TLS.

この仕様は[RFC6613]を更新し、[RFC6614]で使用されます。この仕様をプレーンTCPで使用すると、パス上の攻撃者が可用性に影響を与える新たな機会が生まれます。これらの攻撃は、TLSを使用することで完全に軽減できます。これらの攻撃が許容できる場合、この仕様はTLSなしのTCPで使用できます。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、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, DOI 10.17487/RFC2865, 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、DOI 10.17487 / RFC2865、2000年6月、<http：/ /www.rfc-editor.org/info/rfc2865>。

[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, DOI 10.17487/RFC3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>.

[RFC3575] Aboba、B。、「RADIUS（リモート認証ダイヤルインユーザーサービス）に関するIANAの考慮事項」、RFC 3575、DOI 10.17487 / RFC3575、2003年7月、<http://www.rfc-editor.org/info/rfc3575 >。

[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, DOI 10.17487/RFC5997, August 2010, <http://www.rfc-editor.org/info/rfc5997>.

[RFC5997] DeKok、A。、「リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルでのステータスサーバーパケットの使用」、RFC 5997、DOI 10.17487 / RFC5997、2010年8月、<http：//www.rfc-editor .org / info / rfc5997>。

[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, DOI 10.17487/RFC6613, May 2012, <http://www.rfc-editor.org/info/rfc6613>.

[RFC6613] DeKok、A。、「RADIUS over TCP」、RFC 6613、DOI 10.17487 / RFC6613、2012年5月、<http://www.rfc-editor.org/info/rfc6613>。

[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <http://www.rfc-editor.org/info/rfc6614>.

[RFC6614] Winter、S.、McCauley、M.、Venaas、S.、and K. Wierenga、 "Transport Layer Security（TLS）Encryption for RADIUS"、RFC 6614、DOI 10.17487 / RFC6614、May 2012、<http：/ /www.rfc-editor.org/info/rfc6614>。

[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, 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、DOI 10.17487 / RFC6929、2013年4月、<http://www.rfc-editor.org/ info / rfc6929>。

8.2. Informative References

8.2. 参考引用

[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/RFC7499, April 2015, <http://www.rfc-editor.org/info/rfc7499>.

[RFC7499] Perez-Mendez、A.、Ed。、Marin-Lopez、R.、Pereniguez-Garcia、F.、Lopez-Millan、G.、Lopez、D。、およびA. DeKok、「RADIUSのフラグメンテーションのサポートパケット」、RFC 7499、DOI 10.17487 / RFC7499、2015年4月、<http://www.rfc-editor.org/info/rfc7499>。

[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, <http://www.rfc-editor.org/info/rfc7833>.

[RFC7833] Howlett、J.、Hartman、S。、およびA. Perez-Mendez、編、「セキュリティアサーションマークアップ言語（SAML）のRADIUS属性、バインディング、プロファイル、名前識別子形式、および確認方法」、 RFC 7833、DOI 10.17487 / RFC7833、2016年5月、<http://www.rfc-editor.org/info/rfc7833>。

Acknowledgements

謝辞

Sam Hartman's time on this document was funded by JANET as part of Project Moonshot.

このドキュメントに関するSam Hartmanの時間は、Project Moonshotの一部としてJANETによって資金提供されました。

Alan DeKok provided valuable review and text for the Protocol-Error packet code.

Alan DeKokは、プロトコルエラーパケットコードに関する貴重なレビューとテキストを提供しました。

Alejandro Perez Mendez provided valuable review comments.

Alejandro Perez Mendezが貴重なレビューコメントを提供しました。

Author's Address

著者のアドレス

Sam Hartman Painless Security

サムハートマンの痛みのないセキュリティ

   Email: hartmans-ietf@mit.edu