RFC3539 日本語訳
3539 Authentication, Authorization and Accounting (AAA) TransportProfile. B. Aboba, J. Wood. June 2003. (Format: TXT=93110 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 3539 Microsoft
Category: Standards Track J. Wood
Sun Microsystems, Inc.
June 2003
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3539年のマイクロソフトカテゴリ: 木製の標準化過程J.サン・マイクロシステムズ・インク2003年6月
Authentication, Authorization and Accounting (AAA) Transport Profile
認証、承認、および会計(AAA)輸送プロフィール
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals.
このドキュメントはAuthentication、Authorization、およびAccounting(AAA)のためにプロトコルの中に起こる輸送問題について議論します。 また、それは輸送の使用のときにAAAプロトコルで推薦を提供します。 これは実験的な提案と同様に標準化過程RFCsの使用法を含んでいます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 2
2. Issues in Transport Usage. . . . . . . . . . . . . . . . . . . 5
2.1. Application-driven Versus Network-driven . . . . . . . . 5
2.2. Slow Failover. . . . . . . . . . . . . . . . . . . . . . 6
2.3. Use of Nagle Algorithm . . . . . . . . . . . . . . . . . 7
2.4. Multiple Connections . . . . . . . . . . . . . . . . . . 7
2.5. Duplicate Detection. . . . . . . . . . . . . . . . . . . 8
2.6. Invalidation of Transport Parameter Estimates. . . . . . 8
2.7. Inability to use Fast Re-Transmit. . . . . . . . . . . . 9
2.8. Congestion Avoidance . . . . . . . . . . . . . . . . . . 9
2.9. Delayed Acknowledgments. . . . . . . . . . . . . . . . . 11
2.10. Premature Failover . . . . . . . . . . . . . . . . . . . 11
2.11. Head of Line Blocking. . . . . . . . . . . . . . . . . . 11
2.12. Connection Load Balancing. . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 要件言語。 . . . . . . . . . . . . . . . . . 2 1.2. 用語。 . . . . . . . . . . . . . . . . . . . . . . 2 2. 輸送用法による問題。 . . . . . . . . . . . . . . . . . . 5 2.1. アプリケーションで、ネットワーク駆動の.52.2に対して駆動です。 遅いフェイルオーバー…………………6 2.3。 ネーグルAlgorithm. . . . . . . . . . . . . . . . . 7 2.4の使用。 複数のコネクションズ. . . . . . . . . . . . . . . . . . 7 2.5 検出をコピーしてください。 . . . . . . . . . . . . . . . . . . 8 2.6. 無効にする輸送パラメータ推計について。 . . . . . 8 2.7. 使用にFast Re伝わっている無能。 . . . . . . . . . . . 9 2.8. 輻輳回避. . . . . . . . . . . . . . . . . . 9 2.9。 承認を遅らせました。 . . . . . . . . . . . . . . . . 11 2.10. 時期尚早なフェイルオーバー. . . . . . . . . . . . . . . . . . . 11 2.11。 線ブロッキングのヘッド。 . . . . . . . . . . . . . . . . . 11 2.12. 接続ロードバランシング。 . . . . . . . . . . . . . . . 12
Aboba & Wood Standards Track [Page 1] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[1ページ]。
3. AAA Transport Profile. . . . . . . . . . . . . . . . . . . . . 12
3.1. Transport Mappings . . . . . . . . . . . . . . . . . . . 12
3.2. Use of Nagle Algorithm . . . . . . . . . . . . . . . . . 12
3.3. Multiple Connections . . . . . . . . . . . . . . . . . . 13
3.4. Application Layer Watchdog . . . . . . . . . . . . . . . 13
3.5. Duplicate Detection. . . . . . . . . . . . . . . . . . . 19
3.6. Invalidation of Transport Parameter Estimates. . . . . . 20
3.7. Inability to use Fast Re-Transmit. . . . . . . . . . . . 21
3.8. Head of Line Blocking. . . . . . . . . . . . . . . . . . 22
3.9. Congestion Avoidance . . . . . . . . . . . . . . . . . . 23
3.10. Premature Failover . . . . . . . . . . . . . . . . . . . 24
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 25
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Normative References . . . . . . . . . . . . . . . . . . 25
6.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A - Detailed Watchdog Algorithm Description . . . . . . . 28
Appendix B - AAA Agents. . . . . . . . . . . . . . . . . . . . . . 33
B.1. Relays and Proxies . . . . . . . . . . . . . . . . . . . 33
B.2. Re-directs . . . . . . . . . . . . . . . . . . . . . . . 35
B.3. Store and Forward Proxies. . . . . . . . . . . . . . . . 36
B.4. Transport Layer Proxies. . . . . . . . . . . . . . . . . 38
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 39
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 39
Author Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
3. AAA輸送プロフィール。 . . . . . . . . . . . . . . . . . . . . 12 3.1. マッピング. . . . . . . . . . . . . . . . . . . 12 3.2を輸送してください。 ネーグルAlgorithm. . . . . . . . . . . . . . . . . 12 3.3の使用。 複数のコネクションズ. . . . . . . . . . . . . . . . . . 13 3.4 応用層番犬. . . . . . . . . . . . . . . 13 3.5。 検出をコピーしてください。 . . . . . . . . . . . . . . . . . . 19 3.6. 無効にする輸送パラメータ推計について。 . . . . . 20 3.7. 使用にFast Re伝わっている無能。 . . . . . . . . . . . 21 3.8. 線ブロッキングのヘッド。 . . . . . . . . . . . . . . . . . 22 3.9. 輻輳回避. . . . . . . . . . . . . . . . . . 23 3.10。 時期尚早なフェイルオーバー. . . . . . . . . . . . . . . . . . . 24 4。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 24 5. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 25 6. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1。 引用規格. . . . . . . . . . . . . . . . . . 25 6.2。 有益な参照. . . . . . . . . . . . . . . . . 26付録A--詳細な番犬アルゴリズム記述. . . . . . . 28付録B--AAAのエージェント。 . . . . . . . . . . . . . . . . . . . . . 33 B.1。 リレーとプロキシ. . . . . . . . . . . . . . . . . . . 33B.2。 .35B.3を向け直します。 プロキシを保存して、進めてください。 . . . . . . . . . . . . . . . 36 B.4。 層のプロキシを輸送してください。 . . . . . . . . . . . . . . . . 38 知的所有権声明。 . . . . . . . . . . . . . . . . . 39の承認。 . . . . . . . . . . . . . . . . . . . . . . . . . 39作者は、.40の完全な著作権が声明. . . . . . . . . . . . . . . . . . . . . 41であると扱います。
1. Introduction
1. 序論
This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals.
このドキュメントはAuthentication、Authorization、およびAccounting(AAA)のためにプロトコルの中に起こる輸送問題について議論します。 また、それは輸送の使用のときにAAAプロトコルで推薦を提供します。 これは実験的な提案と同様に標準化過程RFCsの使用法を含んでいます。
1.1. Requirements Language
1.1. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[RFC2119]で説明されるように解釈されることになっていてください、」であるべきです
1.2. Terminology
1.2. 用語
Accounting
The act of collecting information on resource usage for the
purpose of trend analysis, auditing, billing, or cost
allocation.
傾向変動分析、監査、支払い、または費用配分の目的のためにリソース用法における情報集めの行為を説明します。
Aboba & Wood Standards Track [Page 2] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[2ページ]。
Administrative Domain
An internet, or a collection of networks, computers, and
databases under a common administration.
管理Domain Anインターネット、または一般的な管理の下におけるネットワーク、コンピュータ、およびデータベースの収集。
Agent A AAA agent is an intermediary that communicates with AAA
clients and servers. Several types of AAA agents exist,
including Relays, Re-directs, and Proxies.
エージェントのA AAAのエージェントはAAAのクライアントとサーバとコミュニケートする仲介者です。 Relaysを含んでいて、いくつかのタイプのAAAのエージェントが存在する、Re指示、そして、Proxies。
Application-driven transport
Transport behavior is said to be "application-driven" when
the rate at which messages are sent is limited by the rate
at which the application generates data, rather than by the
size of the congestion window. In the most extreme case,
the time between transactions exceeds the round-trip time
between sender and receiver, implying that the application
operates with an effective congestion window of one. AAA
transport is typically application driven.
アプリケーション駆動の輸送Transportの振舞いはメッセージが送られるレートが混雑ウィンドウのサイズに従ってというよりむしろアプリケーションがデータを生成するレートによって制限されるとき、「アプリケーションで、駆動である」と言われています。 最も極端な場合では、トランザクションの間の時間は送付者と受信機の間で往復の時間を超えています、アプリケーションが1の有効な混雑ウィンドウで作動するのを含意して。 通常、AAA輸送は動かされたアプリケーションです。
Attribute Value Pair (AVP)
The variable length concatenation of a unique Attribute
(represented by an integer) and a Value containing the
actual value identified by the attribute.
Value Pair(AVP)を結果と考えてください。ユニークなAttribute(整数で、表される)と属性によって特定された実価を含むValueの可変長連結。
Authentication
The act of verifying a claimed identity, in the form of a
pre-existing label from a mutually known name space, as the
originator of a message (message authentication) or as the
end-point of a channel (entity authentication).
認証はアイデンティティであると主張されたaについて確かめる行為(互いに知られている名前からの先在のラベルのフォームがメッセージの創始者(通報認証)として、または、チャンネルのエンドポイント(実体認証)として区切るコネ)です。
Authorization
The act of determining if a particular right, such as
access to some resource, can be granted to the presenter of
a particular credential.
決定するのにもかかわらずの、a特定の行為が何らかのリソースへのアクセスなどのように正す承認を特定の資格証明書のプレゼンターに与えることができます。
Billing The act of preparing an invoice.
準備の行為にインボイスを請求します。
Network Access Identifier
The Network Access Identifier (NAI) is the userID submitted
by the host during network access authentication. In
roaming, the purpose of the NAI is to identify the user as
well as to assist in the routing of the authentication
request. The NAI may not necessarily be the same as the
user's e-mail address or the user-ID submitted in an
application layer authentication.
ネットワークAccess Identifier Network Access Identifier(NAI)はネットワークアクセス認証の間にホストによって提出されたuserIDです。 ローミングでは、NAIの目的は、ユーザを特定して、認証要求のルーティングを助けることです。 NAIは必ずユーザのEメールアドレスかユーザIDが応用層認証で提出したのと同じであるかもしれないというわけではありません。
Aboba & Wood Standards Track [Page 3] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[3ページ]。
Network Access Server (NAS)
A Network Access Server (NAS) is a device that hosts
connect to in order to get access to the network.
ネットワークAccess Server(NAS)A Network Access Server(NAS)はホストがネットワークに近づく手段を得るために接続するデバイスです。
Proxy In addition to forwarding requests and responses, proxies
enforce policies relating to resource usage and
provisioning. This is typically accomplished by tracking
the state of NAS devices. While proxies typically do not
respond to client Requests prior to receiving a Response
from the server, they may originate Reject messages in
cases where policies are violated. As a result, proxies
need to understand the semantics of the messages passing
through them, and may not support all extensions.
推進要求へのプロキシIn追加と応答、プロキシはリソース用法と食糧を供給することに関連する方針を実施します。 これは、NASデバイスの状態を追跡することによって、通常達成されます。 サーバからResponseを受ける前にプロキシはクライアントRequestsに通常応じませんが、彼らは方針が違反されるケースの中のRejectメッセージを溯源するかもしれません。 その結果、プロキシは、メッセージの意味論がそれらを通り抜けるのを理解するのが必要であり、すべての拡大をサポートするかもしれないというわけではありません。
Local Proxy
A Local Proxy is a proxy that exists within the same
administrative domain as the network device (e.g. NAS) that
issued the AAA request. Typically a local proxy is used to
multiplex AAA messages to and from a large number of
network devices, and may implement policy.
地方のProxy A Local ProxyはAAA要求を出したネットワークデバイス(例えば、NAS)と同じ管理ドメインの中に存在するプロキシです。 地元のプロキシは、通常、デバイスと多くのネットワークデバイスからAAAメッセージを多重送信するのに使用されて、政策を実施するかもしれません。
Store and forward proxy
Store and forward proxies distinguish themselves from other
proxy species by sending a reply to the NAS prior to
proxying the request to the server. As a result, store and
forward proxies need to implement AAA client and server
functionality for the messages that they handle. Store and
Forward proxies also typically keep state on conversations
in progress in order to assure delivery of proxied Requests
and Responses. While store and forward proxies are most
frequently deployed for accounting, they also can be used
to implement authentication/authorization policy.
ストア、前進のプロキシストア、および前進のプロキシは、他のプロキシ種とサーバに要求をproxyingする前にNASに返信することによって、自分たちを区別します。その結果、店と前進のプロキシは、AAAのクライアントとサーバがそれらが扱うメッセージのための機能性であると実装する必要があります。 また、ストアとForwardプロキシは、proxied RequestsとResponsesを配送に保証するために会話の状態を進行中に通常維持します。 また、店と前進のプロキシが会計で最も頻繁に配布されている間、認証/承認が方針であると実装するのに彼らを使用できます。
Network-driven transport
Transport behavior is said to be "network driven" when the
rate at which messages are sent is limited by the
congestion window, not by the rate at which the application
can generate data. File transfer is an example of an
application where transport is network driven.
メッセージが送られるレートがアプリケーションがデータを生成することができるレートによって制限されるのではなく、混雑ウィンドウによって制限されるとき、ネットワーク駆動の輸送Transportの振舞いは「運転されたネットワーク」であると言われます。 ファイル転送は輸送が運転されたネットワークであるアプリケーションに関する例です。
Re-direct Rather than forwarding Requests and Responses between
clients and servers, Re-directs refer clients to servers
and allow them to communicate directly. Since Re-directs
do not sit in the forwarding path, they do not alter any
AVPs transitting between client and server. Re-directs do
not originate messages and are capable of handling any
message type. A Re-direct may be configured only to re-
direct messages of certain types, while acting as a Relay
クライアントとサーバの間にRequestsとResponsesを送るよりラザーを向け直してください、Re指示、クライアントをサーバに差し向けてください、そして、それらを直接伝達させてください。 以来Re指示する、推進経路に座るな、そうしないて、また彼らがクライアントとサーバの間を通過する少しのAVPsも変更しない、向け直す、メッセージを溯源しないで、どんなメッセージタイプも扱うことができます。 ダイレクトにReはRelayとして機能している間構成されるかもしれませんが、あるタイプに関するメッセージを再指示します。
Aboba & Wood Standards Track [Page 4] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[4ページ]。
or Proxy for other types. As with Relays, re-directs do
not keep state with respect to conversations or NAS
resources.
または、他のタイプのためのProxy。 Relaysのように向け直す、会話かNASリソースに関して状態を維持しないでください。
Relay Relays forward requests and responses based on routing-
related AVPs and domain forwarding table entries. Since
relays do not enforce policies, they do not examine or
alter non-routing AVPs. As a result, relays never
originate messages, do not need to understand the semantics
of messages or non-routing AVPs, and are capable of
handling any extension or message type. Since relays make
decisions based on information in routing AVPs and domain
forwarding tables they do not keep state on NAS resource
usage or conversations in progress.
前進の要求と応答がルーティングに基礎づけたリレーRelaysはAVPsとドメイン推進テーブルエントリーを関係づけました。 リレーが方針を実施しないので、それらは、非ルーティングAVPsを調べもしませんし、変更もしません。 その結果、リレーは、メッセージを決して溯源しないで、メッセージか非ルーティングAVPsの意味論を理解する必要はなくて、どんな拡大やメッセージタイプも扱うことができます。 それらは、NASリソース用法か進行中の会話の状態を維持しませんリレーでAVPsとドメイン推進ルーティングによる情報に基づいた決定をテーブルの上に置くので。
2. Issues in AAA Transport Usage
2. AAA輸送用法による問題
Issues that arise in AAA transport usage include:
AAA輸送用法で起こる問題は:
Application-driven versus network-driven
Slow failover
Use of Nagle Algorithm
Multiple connections
Duplicate detection
Invalidation of transport parameter estimates
Inability to use fast re-transmit
Congestion avoidance
Delayed acknowledgments
Premature Failover
Head of line blocking
Connection load balancing
使用への輸送パラメータ推計のネーグルのAlgorithm Multiple接続Duplicate検出Invalidationのネットワーク駆動のSlowフェイルオーバーUseに対してアプリケーション駆動のInabilityは速く系列ブロッキングConnectionロードバランシングのCongestion回避Delayed承認Premature Failover Headを再送します。
We discuss each of these issues in turn.
私たちは順番にそれぞれのこれらの問題について議論します。
2.1. Application-driven versus Network-driven
2.1. アプリケーションによる駆動、ネットワークによる駆動
AAA transport behavior is typically application rather than network driven. This means that the rate at which messages are sent is typically limited by how quickly they are generated by the application, rather than by the size of the congestion window.
通常、AAA輸送の振舞いは運転されたネットワークよりむしろアプリケーションです。 これは、それらが混雑ウィンドウのサイズに従ってというよりむしろアプリケーションでどれくらいすぐに生成されるかによってメッセージが送られるレートが通常制限されることを意味します。
For example, let us assume a 48-port NAS with an average session time of 20 minutes. This device will, on average, send only 144 authentication/authorization requests/hour, and an equivalent number of accounting requests. This represents an average inter-packet spacing of 25 seconds, which is much larger than the Round Trip Time (RTT) in most networks.
例えば、48ポートが20分の平均したセッション時間があるNASであると仮定しましょう。 このデバイスは144認証/承認要求/時間、および同等な数の会計要求だけを平均的に送るでしょう。 これは25秒の平均した相互パケットスペースを表します。(秒はRound Trip Time(RTT)よりはるかにほとんどのネットワークで大きいです)。
Aboba & Wood Standards Track [Page 5] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[5ページ]。
Even on much larger NAS devices, the inter-packet spacing is often larger than the RTT. For example, consider a 2048-port NAS with an average session time of 10 minutes. It will on average send 3.4 authentication/authorization requests/second, and an equivalent number of accounting requests. This translates to an average inter- packet spacing of 293 ms.
はるかに大きいNASデバイスでさえ、相互パケットスペースはRTTよりしばしば大きいです。 例えば、2048ポートが10分の平均したセッション時間があるNASであると考えてください。 それは要求/秒、および同等な数の会計要求を3.4認証/承認に平均的に送るでしょう。 これは293の平均した相互パケットスペースに原稿を翻訳します。
However, even where transport behavior is largely application-driven, periods of network-driven behavior can occur. For example, after a NAS reboot, previously stored accounting records may be sent to the accounting server in rapid succession. Similarly, after recovery from a power failure, users may respond with a large number of simultaneous logins. In both cases, AAA messages may be generated more quickly than the network will allow them to be sent, and a queue will build up.
しかしながら、輸送の振舞いがアプリケーションによる主に駆動でさえあるところに、ネットワーク駆動の振舞いの一区切りは起こることができます。 例えば、NASがリブートした後に以前に保存された会計帳簿を矢つぎばやな会計サーバに送るかもしれません。 同様に、停電からの回復の後に、ユーザは多くの同時のログインで応じるかもしれません。 どちらの場合も、AAAメッセージはネットワークが、それらが送られるのを許容するよりはやく生成されるかもしれません、そして、待ち行列は増すでしょう。
Network congestion can occur when transport behavior is network- driven or application-driven. For example, while a single NAS may not send substantial AAA traffic, many NASes may communicate with a single AAA proxy or server. As a result, routers close to a heavily loaded proxy or server may experience congestion, even though traffic from each individual NAS is light. Such "convergent congestion" can result in dropped packets in routers near the AAA server, or even within the AAA server itself.
輸送の振舞いがネットワーク駆動である、またはアプリケーションによる駆動であるときに、ネットワークの混雑は起こることができます。 例えば、独身のNASがかなりのAAAトラフィックを送らないかもしれない間、多くのNASesが独身のAAAプロキシかサーバとコミュニケートするかもしれません。その結果、大いに積み込まれたプロキシかサーバの近くのルータは混雑になるかもしれません、それぞれの個々のNASからのトラフィックが軽いのですが。 「集中的な混雑」がもたらすことができるそのようなものはAAAサーバの近く、または、AAAサーバ自体の中でさえルータでパケットを下げました。
Let us consider what happens when 10,000 48-ports NASes, each with an average session time of 20 minutes, are configured with the same AAA agent or server. The unfortunate proxy or server would receive 400 authentication/authorization requests/second and an equivalent number of accounting requests. For 1000 octet requests, this would generate 6.4 Mbps of incoming traffic at the AAA agent or server.
10,000 48ポートのNASes(20分の平均したセッション時間があるそれぞれ)が同じAAAのエージェントかサーバで構成されるとき、何が起こるか考えましょう。不幸なプロキシかサーバが要求/秒と会計の同等な数が要求する400認証/承認を受けるでしょう。 1000の八重奏要求のために、これはAAAのエージェントかサーバで入って来るトラフィックの6.4Mbpsを生成するでしょう。
While this transaction load is within the capabilities of the fastest AAA agents and servers, implementations exist that cannot handle such a high load. Thus high queuing delays and/or dropped packets may be experienced at the agent or server, even if routers on the path are not congested. Thus, a well designed AAA protocol needs to be able to handle congestion occurring at the AAA server, as well as congestion experienced within the network.
最も速いAAAのエージェントとサーバの能力の中にこのトランザクション負荷がある間、そのような高い負荷を扱うことができない実装が存在しています。 したがって、高い列を作りは延着します、そして、下げられたパケットはエージェントかサーバで経験されるかもしれません、経路のルータが混雑していなくても。 したがって、よく設計されたAAAプロトコルは、AAAサーバで起こる混雑を扱うことができる必要があります、ネットワークの中で経験された混雑と同様に。
2.2. Slow Failover
2.2. 遅いフェイルオーバー
Where TCP [RFC793] is used as the transport, AAA implementations will experience very slow fail over times if they wait until a TCP connection times out before resending on another connection. This is not an issue for SCTP [RFC2960], which supports endpoint and path failure detection. As described in section 8 of [RFC2960], when the number of retransmissions exceeds the maximum
TCP[RFC793]が輸送として使用されるところでは、別の接続の再送のTCP接続回数前まで待っているなら、AAA実装は非常に遅いフェイルオーバー時勢になるでしょう。 これはSCTP[RFC2960]のための問題ではありません。(SCTPは終点と経路失敗が検出であるとサポートします)。 セクションで説明されるように、8は[RFC2960]「再-トランスミッション」の数であるときに時最大を超えています。
Aboba & Wood Standards Track [Page 6] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[6ページ]。
("Association.Max.Retrans"), the peer endpoint is considered
unreachable, the association enters the CLOSED state, and the failure
is reported to the application. This enables more rapid failure
detection.
(「Association.Max.Retrans」)、同輩終点は手が届かないと考えられます、そして、協会はCLOSED状態に入ります、そして、失敗はアプリケーションに報告されます。 これは、より急速な失敗検出を可能にします。
2.3. Use of Nagle Algorithm
2.3. ネーグルAlgorithmの使用
AAA protocol messages are often smaller than the maximum segment size (MSS). While exceptions occur when certificate-based authentication messages are issued or where a low path MTU is found, typically AAA protocol messages are less than 1000 octets. Therefore, when using TCP [RFC793], the total packet count and associated network overhead can be reduced by combining multiple AAA messages within a single packet.
AAAプロトコルメッセージは最大のセグメントサイズ(MSS)よりしばしば小さいです。 例外は証明書ベースの認証メッセージを発行するか、または低い経路MTUを見つけるところに起こりますが、AAAプロトコルメッセージは通常、1000未満の八重奏です。 したがって、TCP[RFC793]を使用するとき、単一のパケットの中の複数のAAAメッセージを結合することによって、総パケットカウントと関連ネットワークオーバーヘッドを抑えることができます。
Where AAA runs over TCP and transport behavior is network-driven, such as after a reboot when many users login simultaneously, or many stored accounting records need to be sent, the Nagle algorithm will result in "transport layer batching" of AAA messages. While this does not reduce the work required by the application in parsing packets and responding to the messages, it does reduce the number of packets processed by routers along the path. The Nagle algorithm is not used with SCTP.
AAAがTCPと輸送の振舞いをどこにひくかが、送られるべき多くのユーザが同時に、ログインするか、または多くが会計帳簿を保存したときのリブートなどのような後ネットワーク駆動の必要性である、ネーグルアルゴリズムはAAAメッセージの「トランスポート層バッチング」をもたらすでしょう。 これはパケットを分析して、メッセージに応じながら、アプリケーションで必要である仕事を下げませんが、それは経路に沿ったルータで処理されたパケットの数を減少させます。 ネーグルアルゴリズムはSCTPと共に使用されません。
Where AAA transport is application-driven, the NAS will typically receive a reply from the home server prior to having another request to send. This implies, for example, that accounting requests will typically be sent individually rather than being batched by the transport layer. As a result, within the application-driven regime, the Nagle algorithm [RFC896] is ineffective.
AAA輸送がアプリケーションによる駆動であるところでは、発信するという別の要求を持つ前に、NASはホームサーバから回答を通常受け取るでしょう。 例えば、これは、会計要求がトランスポート層によってbatchedされるより個別にむしろ通常送られるのを含意します。 その結果、アプリケーション駆動の政権の中では、ネーグルアルゴリズム[RFC896]は効力がありません。
2.4. Multiple Connections
2.4. 複数のコネクションズ
Since the RADIUS [RFC2865] Identifier field is a single octet, a maximum of 256 requests can be in progress between two endpoints described by a 5-tuple: (Client IP address, Client port, UDP, Server IP address, Server port). In order to get around this limitation, RADIUS clients have utilized more than one sending port, sometimes even going to the extreme of using a different UDP source port for each NAS port.
RADIUS[RFC2865]識別子分野がただ一つの八重奏であるので、最大256の要求が5-tupleによって説明された2つの終点で進行できます: (クライアントIPアドレス、Clientポート、UDP、Serverが移植するServer IPアドレス。) この制限を逃れるために、RADIUSクライアントは1つ以上の送付ポートを利用しました、時々それぞれのNASポートに異なったUDPソースポートを使用する極端に行きさえして。
Were this behavior to be extended to AAA protocols operating over reliable transport, the result would be multiplication of the effective slow-start ramp-up by the number of connections. For example, if a AAA client had ten connections open to a AAA agent, and used a per-connection initial window [RFC3390] of 2, then the
この振舞いが信頼できる輸送の上で作動するAAAプロトコルに広げられることになっているなら、結果はポートの数に従った有効な遅れた出発立ち上げの乗法でしょうに。 例えば、その時AAAのクライアントがAAAのエージェントにとって、オープンな10の接続があって、2の1接続あたり1つの初期の窓[RFC3390]を使用したなら
Aboba & Wood Standards Track [Page 7] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[7ページ]。
effective initial window would be 20. This is inappropriate, since it would permit the AAA client to send a large burst of packets into the network.
有効な初期の窓は20でしょう。 AAAのクライアントがパケットの大きい炸裂をネットワークに送ることを許可するでしょう、したがって、これは不適当です。
2.5. Duplicate Detection
2.5. 検出をコピーしてください。
Where a AAA client maintains connections to multiple AAA agents or servers, and where failover/failback or connection load balancing is supported, it is possible for multiple agents or servers to receive duplicate copies of the same transaction. A transaction may be sent on another connection before expiration of the "time wait" interval necessary to guarantee that all packets sent on the original connection have left the network. Therefore it is conceivable that transactions sent on the alternate connection will arrive before those sent on the failed connection. As a result, AAA agents and servers MUST be prepared to handle duplicates, and MUST assume that duplicates can arrive on any connection.
AAAのクライアントが複数のAAAのエージェントかサーバに接続を維持して、フェイルオーバー/failbackか接続ロードバランシングがサポートされるところでは、複数のエージェントかサーバが同じトランザクションの写本を受け取るのは、可能です。 オリジナルの接続に送られたすべてのパケットがネットワークを出たのを保証するのに必要な「時間待ち」間隔の満了の前に別の接続にトランザクションを送るかもしれません。 したがって、トランザクションが、ものが失敗した接続を転送する前に代替の接続が到着するのを転送したのが想像できます。 その結果、AAAのエージェントとサーバは、写しを扱うように準備しなければならなくて、写しがどんな接続のときにも到着できると仮定しなければなりません。
For example, in billing, it is necessary to be able to weed out duplicate accounting records, based on the accounting session-id, event-timestamp and NAS identification information. Where authentication requests are always idempotent, the resultant duplicate responses from multiple servers will presumably be identical, so that little harm will result.
例えば、支払いでは、写し会計帳簿を取り外すことができるのが必要です、会計セッションイド、イベントタイムスタンプ、およびNAS識別情報に基づいて。 いつも認証要求がベキ等元であるところでは、おそらく、複数のサーバからの結果の写し応答は同じになるでしょう、害がほとんど結果として生じないように。
However, there are situations where the response to an authentication request will depend on a previously established state, such as when simultaneous usage restrictions are being enforced. In such cases, authentication requests will not be idempotent. For example, while an initial request might elicit an Accept response, a duplicate request might elicit a Reject response from another server, if the user were already presumed to be logged in, and only one simultaneous session were permitted. In these situations, the AAA client might receive both Accept and Reject responses to the same duplicate request, and the outcome will depend on which response arrives first.
しかしながら、状況が認証要求への応答を以前に設立された状態に依存するところにあります、同時の使用制限が励行されている時のように。 そのような場合、認証要求はベキ等元にならないでしょう。 例えば、初期の要求はAccept応答を引き出すかもしれませんが、写し要求は別のサーバ、ユーザが既にあえてログインされたか、そして、および同時のセッションが受入れられたものだけからReject応答を引き出すかもしれません。 これらの状況で、AAAのクライアントはAcceptと同じ写しへのReject応答が要求する両方を受けるかもしれません、そして、結果はどの応答が先着するかに依存するでしょう。
2.6. Invalidation of Transport Parameter Estimates
2.6. 無効にする輸送パラメータ推計について
Congestion control principles [Congest],[RFC2914] require the ability of a transport protocol to respond effectively to congestion, as sensed via increasing delays, packet loss, or explicit congestion notification.
輻輳制御原則[充血する]、[RFC2914]はトランスポート・プロトコルが有効に混雑に応じる能力を必要とします、遅れ、パケット損失、または明白な混雑通知を増強することを通して感じられるように。
With network-driven applications, it is possible to respond to congestion on a timescale comparable to the round-trip time (RTT).
ネットワーク駆動のアプリケーションでは、往復の時間(RTT)に匹敵するスケールで混雑に応じるのは可能です。
However, with AAA protocols, the time between sends may be longer than the RTT, so that the network conditions can not be assumed to
間のAAAプロトコルによる時間がどのように発信しても、RTTより長いかもしれません、ネットワーク状態を想定できないように
Aboba & Wood Standards Track [Page 8] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[8ページ]。
persist between sends. For example, the congestion window may grow during a period in which congestion is being experienced because few packets are sent, limiting the opportunity for feedback. Similarly, after congestion is detected, the congestion window may remain small, even though the network conditions that existed at the time of congestion no longer apply by the time when the next packets are sent. In addition, due to the low sampling interval, estimates of RTT and RTO made via the procedure described in [RFC2988] may become invalid.
間に固執してください。発信します。 例えば、混雑ウィンドウはわずかなパケットしか送らないので、混雑が経験される予定である期間、成長するかもしれません、フィードバックの機会を制限して。 同様に、混雑が検出された後に混雑ウィンドウは小さいままで残るかもしれません、混雑時点で存在したネットワーク状態がもう次のパケットが送られる時までに適用されませんが。 さらに、低い標本抽出間隔のため[RFC2988]で説明された手順で作られたRTTとRTOの見積りは無効になるかもしれません。
2.7. Inability to Use Fast Re-transmit
2.7. 速く使用する無能は再送されます。
When congestion window validation [RFC2861] is implemented, the result is that AAA protocols operate much of the time in slow-start with an initial congestion window set to 1 or 2, depending on the implementation [RFC3390]. This implies that AAA protocols gain little benefit from the windowing features of reliable transport.
混雑窓の合法化[RFC2861]が実装されるとき、結果はプロトコルが初期の混雑ウィンドウによる遅れた出発でよく経営するAAAが1か2にセットしたということです、実装[RFC3390]によって。 これは、AAAプロトコルが信頼できる輸送のウインドーの特徴から利益をほとんど獲得しないのを含意します。
Since the congestion window is so small, it is generally not possible to receive enough duplicate ACKs (3) to trigger fast re-transmit. In addition, since AAA traffic is two-way, ACKs including data will not count as part of the duplicate ACKs necessary to trigger fast re- transmit. As a result, dropped packets will require a retransmission timeout (RTO).
混雑ウィンドウが非常に小さいので速く引き金となることができるくらいの写しACKs(3)を受け取るのが一般に可能でないので、再送してください。 さらに、AAAトラフィックが両用であるので、データを含むACKsが速く引き金となるのに必要なACKsが再伝える写しの一部にみなさないでしょう。 その結果、下げられたパケットは再送タイムアウト(RTO)を必要とするでしょう。
2.8. Congestion Avoidance
2.8. 輻輳回避
The law of conservation of packets [Congest] suggests that a client should not send another packet into the network until it can be reasonably sure that a packet has exited the network on the same path. In the case of a AAA client, the law suggests that it should not retransmit to the same server or choose another server until it can be reasonably sure that a packet has exited the network on the same path. If the client advances the window as responses arrive, then the client will "self clock", adjusting its transmission rate to the available bandwidth.
パケット[充血する]の保護の法は、パケットが同じ経路でネットワークを出たのが、合理的に確かになる場合があるまでクライアントが別のパケットをネットワークに送るべきでないと示唆します。 AAAのクライアントの場合では、法は、パケットが同じ経路でネットワークを出たのが、合理的に確かになる場合があるまで、同じサーバに再送するべきでないか、別のサーバを選ぶべきでないと示唆します。 応答が到着するのに応じてクライアントが窓を進めると、クライアントは利用可能な帯域幅に通信速度を調整する「自己は時間を計ること」がそうするでしょう。
While a AAA client using a reliable transport such as TCP [RFC793] or SCTP [RFC2960] will self-clock when communicating directly with a AAA-server, end-to-end self-clocking is not assured when AAA agents are present.
AAAのエージェントが出席しているとき、AAAサーバと共に直接伝達するとき、TCP[RFC793]かSCTP[RFC2960]などの信頼できる輸送を使用しているAAAのクライアントが自己に時間を計る間、終わりから終わりへの自己時計は保証されません。
As described in the Appendix, AAA agents include Relays, Proxies, Re-directs, Store and Forward proxies, and Transport proxies. Of these agents, only Transport proxies and Re-directs provide a direct transport connection between the AAA client and server, allowing end-to-end self-clocking to occur.
Appendix、インクルードRelays(Proxies)がRe指示するAAAのエージェント、ストア、Forwardプロキシ、およびTransportプロキシで説明されるように。 そして、これらのエージェント、Transportプロキシだけ、起こるようAAAのクライアントとサーバとのa直航運送関係を提供して、終わりから終わりへの自己時計を許すのにRe指示します。
Aboba & Wood Standards Track [Page 9] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[9ページ]。
With Relays, Proxies or Store and Forward proxies, two separate and de-coupled transport connections are used. One connection operates between the AAA client and agent, and another between the agent and server. Since the two transport connections are de-coupled, transport layer ACKs do not flow end-to-end, and self-clocking does not occur.
RelaysかProxiesかストアとForwardプロキシと共に、2人の別々の、そして、衝撃を吸収された輸送の接続が使用されています。 接続がAAAのクライアントとエージェントの間で手術する1つ、およびエージェントとサーバの間の別のもの. 2人の輸送の接続が衝撃を吸収されるので、トランスポート層ACKsは終わるために終わった状態で流れないで、また自己時計は起こりません。
For example, consider what happens when the bottleneck exists between a AAA Relay and a AAA server. Self-clocking will occur between the AAA client and AAA Relay, causing the AAA client to adjust its sending rate to the rate at which transport ACKs flow back from the AAA Relay. However, since this rate is higher than the bottleneck bandwidth, the overall system will not self-clock.
例えば、ボトルネックがAAA RelayとAAAサーバの間に存在していると何が起こるか考えてください。自己時計はAAAのクライアントとAAA Relayの間に起こるでしょう、AAAのクライアントがAAA Relayからのどの輸送ACKs流動に送付レートをレートに調整するかを引き起こして。 しかしながら、このレートがボトルネック帯域幅より高いので、総合体系は自己に時間を計らないでしょう。
Since there is no direct transport connection between the AAA client and AAA server, the AAA client does not have the ability to estimate end-to-end transport parameters and adjust its sending rate to the bottleneck bandwidth between the Relay and server. As a result, the incoming rate at the AAA Relay can be higher than the rate at which packets can be sent to the AAA server.
AAAのクライアントとAAAサーバとの直航運送関係が全くないので、AAAのクライアントには、終わりから終わりへの輸送がパラメタであると見積もって、Relayとサーバの間のボトルネック帯域幅に送付レートを調整する能力がありません。その結果、AAA Relayの入って来るレートはAAAサーバにパケットを送ることができるレートより高い場合があります。
In this case, the end-to-end performance will be determined by details of the agent implementation. In general, the end-to-end transport performance in the presence of Relays, Proxies or Store and Forward proxies will always be worse in terms of delay and packet loss than if the AAA client and server were communicating directly.
In this case, the end-to-end performance will be determined by details of the agent implementation. In general, the end-to-end transport performance in the presence of Relays, Proxies or Store and Forward proxies will always be worse in terms of delay and packet loss than if the AAA client and server were communicating directly.
For example, if the agent operates with a large receive buffer, it is possible that a large queue will develop on the receiving side, since the AAA client is able to send packets to the AAA agent more rapidly than the agent can send them to the AAA server. Eventually, the buffer will overflow, causing wholesale packet loss as well as high delay.
For example, if the agent operates with a large receive buffer, it is possible that a large queue will develop on the receiving side, since the AAA client is able to send packets to the AAA agent more rapidly than the agent can send them to the AAA server. Eventually, the buffer will overflow, causing wholesale packet loss as well as high delay.
Methods to induce fine-grained coupling between the two transport connections are difficult to implement. One possible solution is for the AAA agent to operate with a receive buffer that is no larger than its send buffer. If this is done, "back pressure" (closing of the receive window) will cause the agent to reduce the AAA client sending rate when the agent send buffer fills. However, unless multiple connections exist between the AAA client and AAA agent, closing of the receive window will affect all traffic sent by the AAA client, even traffic destined to AAA servers where no bottleneck exists. Since multiple connections between a AAA client and agent result in multiplication of the effective slow-start ramp rate, this is not recommended. As a result, use of "back pressure" cannot enable individual AAA client-server conversations to self-clock, and this technique appears impractical for use in AAA.
Methods to induce fine-grained coupling between the two transport connections are difficult to implement. One possible solution is for the AAA agent to operate with a receive buffer that is no larger than its send buffer. If this is done, "back pressure" (closing of the receive window) will cause the agent to reduce the AAA client sending rate when the agent send buffer fills. However, unless multiple connections exist between the AAA client and AAA agent, closing of the receive window will affect all traffic sent by the AAA client, even traffic destined to AAA servers where no bottleneck exists. Since multiple connections between a AAA client and agent result in multiplication of the effective slow-start ramp rate, this is not recommended. As a result, use of "back pressure" cannot enable individual AAA client-server conversations to self-clock, and this technique appears impractical for use in AAA.
Aboba & Wood Standards Track [Page 10] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 10] RFC 3539 AAA Transport Profile June 2003
2.9. Delayed Acknowledgments
2.9. Delayed Acknowledgments
As described in Appendix B, ACKs may comprise as much as half of the traffic generated in a AAA exchange. This occurs because AAA conversations are typically application-driven, and therefore there is frequently not enough traffic to enable ACK piggybacking. As a result, AAA protocols running over TCP or SCTP transport may experience a doubling of traffic as compared with implementations utilizing UDP transport.
As described in Appendix B, ACKs may comprise as much as half of the traffic generated in a AAA exchange. This occurs because AAA conversations are typically application-driven, and therefore there is frequently not enough traffic to enable ACK piggybacking. As a result, AAA protocols running over TCP or SCTP transport may experience a doubling of traffic as compared with implementations utilizing UDP transport.
It is typically not possible to address this issue via the sockets API. ACK parameters (such as the value of the delayed ACK timer) are typically fixed by TCP and SCTP implementations and are therefore not tunable by the application.
It is typically not possible to address this issue via the sockets API. ACK parameters (such as the value of the delayed ACK timer) are typically fixed by TCP and SCTP implementations and are therefore not tunable by the application.
2.10. Premature Failover
2.10. Premature Failover
RADIUS failover implementations are typically based on the concept of primary and secondary servers, in which all traffic flows to the primary server unless it is unavailable. However, the failover algorithm was not specified in [RFC2865] or [RFC2866]. As a result, RADIUS failover implementations vary in quality, with some failing over prematurely, violating the law of "conservation of packets".
RADIUS failover implementations are typically based on the concept of primary and secondary servers, in which all traffic flows to the primary server unless it is unavailable. However, the failover algorithm was not specified in [RFC2865] or [RFC2866]. As a result, RADIUS failover implementations vary in quality, with some failing over prematurely, violating the law of "conservation of packets".
Where a Relay, Proxy or Store and Forward proxy is present, the AAA client has no direct connection to a AAA server, and is unable to estimate the end-to-end transport parameters. As a result, a AAA client awaiting an application-layer response from the server has no transport-based mechanism for determining an appropriate failover timer.
Where a Relay, Proxy or Store and Forward proxy is present, the AAA client has no direct connection to a AAA server, and is unable to estimate the end-to-end transport parameters. As a result, a AAA client awaiting an application-layer response from the server has no transport-based mechanism for determining an appropriate failover timer.
For example, if the path between the AAA agent and server includes a high delay link, or if the AAA server is very heavily loaded, it is possible that the NAS will failover to another agent while packets are still in flight. This violates the principle of "conservation of packets", since the AAA client will inject additional packets into the network before having evidence that a previously sent packet has left the network. Such behavior can result in a worse situation on an already congested link, resulting in congestive collapse [Congest].
For example, if the path between the AAA agent and server includes a high delay link, or if the AAA server is very heavily loaded, it is possible that the NAS will failover to another agent while packets are still in flight. This violates the principle of "conservation of packets", since the AAA client will inject additional packets into the network before having evidence that a previously sent packet has left the network. Such behavior can result in a worse situation on an already congested link, resulting in congestive collapse [Congest].
2.11. Head of Line Blocking
2.11. Head of Line Blocking
Head of line blocking occurs during periods of packet loss where the time between sends is shorter than the re-transmission timeout value (RTO). In such situations, packets back up in the send queue until
Head of line blocking occurs during periods of packet loss where the time between sends is shorter than the re-transmission timeout value (RTO). In such situations, packets back up in the send queue until
Aboba & Wood Standards Track [Page 11] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 11] RFC 3539 AAA Transport Profile June 2003
the lost packet can be successfully re-transmitted. This can be an issue for SCTP when using ordered delivery over a single stream, and for TCP.
the lost packet can be successfully re-transmitted. This can be an issue for SCTP when using ordered delivery over a single stream, and for TCP.
Head of line blocking is typically an issue only on larger NASes. For example, a 48-port NAS with an average inter-packet spacing of 25 seconds is unlikely to have an RTO greater than this, unless severe packet loss has been experienced. However, a 2048-port NAS with an average inter-packet spacing of 293 ms may experience head-of-line blocking since the inter-packet spacing is less than the minimum RTO value of 1 second [RFC2988].
Head of line blocking is typically an issue only on larger NASes. For example, a 48-port NAS with an average inter-packet spacing of 25 seconds is unlikely to have an RTO greater than this, unless severe packet loss has been experienced. However, a 2048-port NAS with an average inter-packet spacing of 293 ms may experience head-of-line blocking since the inter-packet spacing is less than the minimum RTO value of 1 second [RFC2988].
2.12. Connection Load Balancing
2.12. Connection Load Balancing
In order to lessen queuing delays and address head of line blocking, a AAA implementation may wish to load balance between connections to multiple destinations. While it is possible to employ dynamic load balancing techniques, this level of sophistication may not be required. In many situations, adequate reliability and load balancing can be achieved via static load balancing, where traffic is distributed between destinations based on static "weights".
In order to lessen queuing delays and address head of line blocking, a AAA implementation may wish to load balance between connections to multiple destinations. While it is possible to employ dynamic load balancing techniques, this level of sophistication may not be required. In many situations, adequate reliability and load balancing can be achieved via static load balancing, where traffic is distributed between destinations based on static "weights".
3. AAA Transport Profile
3. AAA Transport Profile
In order to address AAA transport issues, it is recommended that AAA protocols make use of standards track as well as experimental techniques. More details are provided in the sections that follow.
In order to address AAA transport issues, it is recommended that AAA protocols make use of standards track as well as experimental techniques. More details are provided in the sections that follow.
3.1. Transport Mappings
3.1. Transport Mappings
AAA Servers MUST support TCP and SCTP. AAA clients SHOULD support SCTP, but MUST support TCP if SCTP is not available. As support for SCTP improves, it is possible that SCTP support will be required on clients at some point in the future. AAA agents inherit all the obligations of Servers with respect to transport support.
AAA Servers MUST support TCP and SCTP. AAA clients SHOULD support SCTP, but MUST support TCP if SCTP is not available. As support for SCTP improves, it is possible that SCTP support will be required on clients at some point in the future. AAA agents inherit all the obligations of Servers with respect to transport support.
3.2. Use of Nagle Algorithm
3.2. Use of Nagle Algorithm
While AAA protocols typically operate in the application-driven regime, there are circumstances in which they are network driven. For example, where an NAS reboots, or where connectivity is restored between an NAS and a AAA agent, it is possible that multiple packets will be available for sending.
While AAA protocols typically operate in the application-driven regime, there are circumstances in which they are network driven. For example, where an NAS reboots, or where connectivity is restored between an NAS and a AAA agent, it is possible that multiple packets will be available for sending.
As a result, there are circumstances where the transport-layer batching provided by the Nagle Algorithm (12) is useful, and as a result, AAA implementations running over TCP MUST enable the Nagle algorithm, [RFC896]. The Nagle algorithm is not used with SCTP.
As a result, there are circumstances where the transport-layer batching provided by the Nagle Algorithm (12) is useful, and as a result, AAA implementations running over TCP MUST enable the Nagle algorithm, [RFC896]. The Nagle algorithm is not used with SCTP.
Aboba & Wood Standards Track [Page 12] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 12] RFC 3539 AAA Transport Profile June 2003
3.3. Multiple Connections
3.3. Multiple Connections
AAA protocols SHOULD use only a single persistent connection between a AAA client and a AAA agent or server. They SHOULD provide for pipelining of requests, so that more than one request can be in progress at a time. In order to minimize use of inactive connections in roaming situations, a AAA client or agent MAY bring down a connection to a AAA agent or server if the connection has been unutilized (discounting the watchdog) for a certain period of time, which MUST NOT be less than BRINGDOWN_INTERVAL (5 minutes).
AAA protocols SHOULD use only a single persistent connection between a AAA client and a AAA agent or server. They SHOULD provide for pipelining of requests, so that more than one request can be in progress at a time. In order to minimize use of inactive connections in roaming situations, a AAA client or agent MAY bring down a connection to a AAA agent or server if the connection has been unutilized (discounting the watchdog) for a certain period of time, which MUST NOT be less than BRINGDOWN_INTERVAL (5 minutes).
While a AAA client/agent SHOULD only use a single persistent connection to a given AAA agent or server, it MAY have connections to multiple AAA agents or servers. A AAA client/agent connected to multiple agents/servers can treat them as primary/secondary or balance load between them.
While a AAA client/agent SHOULD only use a single persistent connection to a given AAA agent or server, it MAY have connections to multiple AAA agents or servers. A AAA client/agent connected to multiple agents/servers can treat them as primary/secondary or balance load between them.
3.4. Application Layer Watchdog
3.4. Application Layer Watchdog
In order to enable AAA implementations to more quickly detect transport and application-layer failures, AAA protocols MUST support an application layer watchdog message.
In order to enable AAA implementations to more quickly detect transport and application-layer failures, AAA protocols MUST support an application layer watchdog message.
The application layer watchdog message enables failover from a peer that has failed, either because it is unreachable or because its applications functions have failed. This is distinct from the purpose of the SCTP heartbeat, which is to enable failover between interfaces. The SCTP heartbeat may enable a failover to another path to reach the same server, but does not address the situation where the server system or the application service has failed. Therefore both mechanisms MAY be used together.
The application layer watchdog message enables failover from a peer that has failed, either because it is unreachable or because its applications functions have failed. This is distinct from the purpose of the SCTP heartbeat, which is to enable failover between interfaces. The SCTP heartbeat may enable a failover to another path to reach the same server, but does not address the situation where the server system or the application service has failed. Therefore both mechanisms MAY be used together.
The watchdog is used in order to enable a AAA client or agent to determine when to resend on another connection. It operates on all open connections and is used to suspend and eventually close connections that are experiencing difficulties. The watchdog is also used to re-open and validate connections that have returned to health. The watchdog may be utilized either within primary/secondary or load balancing configurations. However, it is not intended as a cluster heartbeat mechanism.
The watchdog is used in order to enable a AAA client or agent to determine when to resend on another connection. It operates on all open connections and is used to suspend and eventually close connections that are experiencing difficulties. The watchdog is also used to re-open and validate connections that have returned to health. The watchdog may be utilized either within primary/secondary or load balancing configurations. However, it is not intended as a cluster heartbeat mechanism.
The application layer watchdog is designed to detect failures of the immediate peer, and not to be affected by failures of downstream proxies or servers. This prevents instability in downstream AAA components from propagating upstream. While the receipt of any AAA Response from a peer is taken as evidence that the peer is up, lack of a Response is insufficient to conclude that the peer is down. Since the lack of Response may be the result of problems with a
The application layer watchdog is designed to detect failures of the immediate peer, and not to be affected by failures of downstream proxies or servers. This prevents instability in downstream AAA components from propagating upstream. While the receipt of any AAA Response from a peer is taken as evidence that the peer is up, lack of a Response is insufficient to conclude that the peer is down. Since the lack of Response may be the result of problems with a
Aboba & Wood Standards Track [Page 13] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 13] RFC 3539 AAA Transport Profile June 2003
downstream proxy or server, only after failure to respond to the watchdog message can it be determined that the peer is down.
downstream proxy or server, only after failure to respond to the watchdog message can it be determined that the peer is down.
Since the watchdog algorithm takes any AAA Response into account in determining peer liveness, decreases in the watchdog timer interval do not significantly increase the level of watchdog traffic on heavily loaded networks. This is because watchdog messages do not need to be sent where other AAA Response traffic serves as a constant reminder of peer liveness. Watchdog traffic only increases when AAA traffic is light, and therefore a AAA Response "signal" is not present. Nevertheless, decreasing the timer interval TWINIT does increase the probability of false failover significantly, and so this decision should be made with care.
Since the watchdog algorithm takes any AAA Response into account in determining peer liveness, decreases in the watchdog timer interval do not significantly increase the level of watchdog traffic on heavily loaded networks. This is because watchdog messages do not need to be sent where other AAA Response traffic serves as a constant reminder of peer liveness. Watchdog traffic only increases when AAA traffic is light, and therefore a AAA Response "signal" is not present. Nevertheless, decreasing the timer interval TWINIT does increase the probability of false failover significantly, and so this decision should be made with care.
3.4.1. Algorithm Overview
3.4.1. Algorithm Overview
The watchdog behavior is controlled by an algorithm defined in this section. This algorithm is appropriate for use either within primary/secondary or load balancing configurations. Implementations SHOULD implement this algorithm, which operates as follows:
The watchdog behavior is controlled by an algorithm defined in this section. This algorithm is appropriate for use either within primary/secondary or load balancing configurations. Implementations SHOULD implement this algorithm, which operates as follows:
[1] Watchdog behavior is controlled by a single timer (Tw). The
initial value of Tw, prior to jittering is Twinit. The default
value of Twinit is 30 seconds. This value was selected because
it minimizes the probability that failover will be initiated due
to a routing flap, as noted in [Paxson].
[1] Watchdog behavior is controlled by a single timer (Tw). The initial value of Tw, prior to jittering is Twinit. The default value of Twinit is 30 seconds. This value was selected because it minimizes the probability that failover will be initiated due to a routing flap, as noted in [Paxson].
While Twinit MAY be set as low as 6 seconds (not including
jitter), it MUST NOT be set lower than this. Note that setting
such a low value for Twinit is likely to result in an increased
probability of duplicates, as well as an increase in spurious
failover and failback attempts.
While Twinit MAY be set as low as 6 seconds (not including jitter), it MUST NOT be set lower than this. Note that setting such a low value for Twinit is likely to result in an increased probability of duplicates, as well as an increase in spurious failover and failback attempts.
In order to avoid synchronization behaviors that can occur with
fixed timers among distributed systems, each time the watchdog
interval is calculated with a jitter by using the Twinit value
and randomly adding a value drawn between -2 and 2 seconds.
Alternative calculations to create jitter MAY be used. These
MUST be pseudo-random, generated by a PRNG seeded as per
[RFC1750].
In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, each time the watchdog interval is calculated with a jitter by using the Twinit value and randomly adding a value drawn between -2 and 2 seconds. Alternative calculations to create jitter MAY be used. These MUST be pseudo-random, generated by a PRNG seeded as per [RFC1750].
[2] When any AAA message is received, Tw is reset. This need not be
a response to a watchdog request. Receiving a watchdog response
from a peer constitutes activity, and Tw should be reset. If the
watchdog timer expires and no watchdog response is pending, then
a watchdog message is sent. On sending a watchdog request, Tw is
reset.
[2] When any AAA message is received, Tw is reset. This need not be a response to a watchdog request. Receiving a watchdog response from a peer constitutes activity, and Tw should be reset. If the watchdog timer expires and no watchdog response is pending, then a watchdog message is sent. On sending a watchdog request, Tw is reset.
Aboba & Wood Standards Track [Page 14] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 14] RFC 3539 AAA Transport Profile June 2003
Watchdog packets are not retransmitted by the AAA protocol, since
AAA protocols run over reliable transports that will handle all
retransmissions internally. As a result, a watchdog request is
only sent when there is no watchdog response pending.
Watchdog packets are not retransmitted by the AAA protocol, since AAA protocols run over reliable transports that will handle all retransmissions internally. As a result, a watchdog request is only sent when there is no watchdog response pending.
[3] If the watchdog timer expires and a watchdog response is pending,
then failover is initiated. In order for a AAA client or agent
to perform failover procedures, it is necessary to maintain a
pending message queue for a given peer. When an answer message
is received, the corresponding request is removed from the queue.
The Hop-by-Hop Identifier field MAY be used to match the answer
with the queued request.
[3] If the watchdog timer expires and a watchdog response is pending, then failover is initiated. In order for a AAA client or agent to perform failover procedures, it is necessary to maintain a pending message queue for a given peer. When an answer message is received, the corresponding request is removed from the queue. The Hop-by-Hop Identifier field MAY be used to match the answer with the queued request.
When failover is initiated, all messages in the queue are sent to
an alternate agent, if available. Multiple identical requests or
answers may be received as a result of a failover. The
combination of an end-to-end identifier and the origin host MUST
be used to identify duplicate messages.
When failover is initiated, all messages in the queue are sent to an alternate agent, if available. Multiple identical requests or answers may be received as a result of a failover. The combination of an end-to-end identifier and the origin host MUST be used to identify duplicate messages.
Note that where traffic is heavy, the application layer watchdog
can take as long as 2Tw to determine that a peer has gone down.
For peers receiving a high volume of AAA Requests, AAA Responses
will continually reset the timer, so that after a failure it will
take Tw for the lack of traffic to be noticed, and for the
watchdog message to be sent. Another Tw will elapse before
failover is initiated.
Note that where traffic is heavy, the application layer watchdog can take as long as 2Tw to determine that a peer has gone down. For peers receiving a high volume of AAA Requests, AAA Responses will continually reset the timer, so that after a failure it will take Tw for the lack of traffic to be noticed, and for the watchdog message to be sent. Another Tw will elapse before failover is initiated.
On a lightly loaded network without much AAA Response traffic,
the watchdog timer will typically expire without being reset, so
that a watchdog response will be outstanding and failover will be
initiated after only a single timer interval has expired.
On a lightly loaded network without much AAA Response traffic, the watchdog timer will typically expire without being reset, so that a watchdog response will be outstanding and failover will be initiated after only a single timer interval has expired.
[4] The client MUST NOT close the primary connection until the
primary's watchdog timer has expired at least twice without a
response (note that the watchdog is not sent a second time,
however). Once this has occurred, the client SHOULD cause a
transport reset or close to be done on the connection.
[4] The client MUST NOT close the primary connection until the primary's watchdog timer has expired at least twice without a response (note that the watchdog is not sent a second time, however). Once this has occurred, the client SHOULD cause a transport reset or close to be done on the connection.
Once the primary connection has failed, subsequent requests are
sent to the alternate server until the watchdog timer on the
primary connection is reset.
Once the primary connection has failed, subsequent requests are sent to the alternate server until the watchdog timer on the primary connection is reset.
Suspension of the primary connection prevents flapping between
primary and alternate connections, and ensures that failover
behavior remains consistent. The application may not receive a
response to the watchdog request message due to a connectivity
problem, in which case a transport layer ACK will not have been
received, or the lack of response may be due to an application
Suspension of the primary connection prevents flapping between primary and alternate connections, and ensures that failover behavior remains consistent. The application may not receive a response to the watchdog request message due to a connectivity problem, in which case a transport layer ACK will not have been received, or the lack of response may be due to an application
Aboba & Wood Standards Track [Page 15] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 15] RFC 3539 AAA Transport Profile June 2003
problem. Without transport layer visibility, the application is
unable to tell the difference, and must behave conservatively.
problem. Without transport layer visibility, the application is unable to tell the difference, and must behave conservatively.
In situations where no transport layer ACK is received on the
primary connection after multiple re-transmissions, the RTO will
be exponentially backed off as described in [RFC2988]. Due to
Karn's algorithm as implemented in SCTP and TCP, the RTO
estimator will not be reset until another ACK is received in
response to a non-re-transmitted request. Thus, in cases where
the problem occurs at the transport layer, after the client fails
over to the alternate server, the RTO of the primary will remain
at a high value unless an ACK is received on the primary
connection.
In situations where no transport layer ACK is received on the primary connection after multiple re-transmissions, the RTO will be exponentially backed off as described in [RFC2988]. Due to Karn's algorithm as implemented in SCTP and TCP, the RTO estimator will not be reset until another ACK is received in response to a non-re-transmitted request. Thus, in cases where the problem occurs at the transport layer, after the client fails over to the alternate server, the RTO of the primary will remain at a high value unless an ACK is received on the primary connection.
In the case where the problem occurs at the transport layer,
subsequent requests sent on the primary connection will not
receive the same service as was originally provided. For
example, instead of failover occurring after 3 retransmissions,
failover might occur without even a single retransmission if RTO
has been sufficiently backed off. Of course, if the lack of a
watchdog response was due to an application layer problem, then
RTO will not have been backed off. However, without transport
layer visibility, there is no way for the application to know
this.
In the case where the problem occurs at the transport layer, subsequent requests sent on the primary connection will not receive the same service as was originally provided. For example, instead of failover occurring after 3 retransmissions, failover might occur without even a single retransmission if RTO has been sufficiently backed off. Of course, if the lack of a watchdog response was due to an application layer problem, then RTO will not have been backed off. However, without transport layer visibility, there is no way for the application to know this.
Suspending use of the primary connection until a response to a
watchdog message is received guarantees that the RTO timer will
have been reset before the primary connection is reused. If no
response is received after the second watchdog timer expiration,
then the primary connection is closed and the suspension becomes
permanent.
Suspending use of the primary connection until a response to a watchdog message is received guarantees that the RTO timer will have been reset before the primary connection is reused. If no response is received after the second watchdog timer expiration, then the primary connection is closed and the suspension becomes permanent.
[5] While the connection is in the closed state, the AAA client MUST
NOT attempt to send further watchdog messages on the connection.
However, after the connection is closed, the AAA client continues
to periodically attempt to reopen the connection.
[5] While the connection is in the closed state, the AAA client MUST NOT attempt to send further watchdog messages on the connection. However, after the connection is closed, the AAA client continues to periodically attempt to reopen the connection.
The AAA client SHOULD wait for the transport layer to report
connection failure before attempting again, but MAY choose to
bound this wait time by the watchdog interval, Tw. If the
connection is successfully opened, then the watchdog message is
sent. Once three watchdog messages have been sent and responded
to, the connection is returned to service, and transactions are
once again sent over it. Connection validation via receipt of
multiple watchdogs is not required when a connection is initially
brought up -- in this case, the connection can immediately be put
into service.
The AAA client SHOULD wait for the transport layer to report connection failure before attempting again, but MAY choose to bound this wait time by the watchdog interval, Tw. If the connection is successfully opened, then the watchdog message is sent. Once three watchdog messages have been sent and responded to, the connection is returned to service, and transactions are once again sent over it. Connection validation via receipt of multiple watchdogs is not required when a connection is initially brought up -- in this case, the connection can immediately be put into service.
Aboba & Wood Standards Track [Page 16] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 16] RFC 3539 AAA Transport Profile June 2003
[6] When using SCTP as a transport, it is not necessary to disable
SCTP's transport-layer heartbeats. However, if AAA
implementations have access to SCTP's heartbeat parameters, they
MAY chose to ensure that SCTP's heartbeat interval is longer than
the AAA watchdog interval, Tw. This will ensure that alternate
paths are still probed by SCTP, while the primary path has a
minimum of heartbeat redundancy.
[6] When using SCTP as a transport, it is not necessary to disable SCTP's transport-layer heartbeats. However, if AAA implementations have access to SCTP's heartbeat parameters, they MAY chose to ensure that SCTP's heartbeat interval is longer than the AAA watchdog interval, Tw. This will ensure that alternate paths are still probed by SCTP, while the primary path has a minimum of heartbeat redundancy.
3.4.2. Primary/Secondary Failover Support
3.4.2. Primary/Secondary Failover Support
The watchdog timer MAY be integrated with primary/secondary style failover so as to provide improved reliability and basic load balancing. In order to balance load among multiple AAA servers, each AAA server is designated the primary for a portion of the clients, and designated as secondaries of varying priority for the remainder. In this way, load can be balanced among the AAA servers.
The watchdog timer MAY be integrated with primary/secondary style failover so as to provide improved reliability and basic load balancing. In order to balance load among multiple AAA servers, each AAA server is designated the primary for a portion of the clients, and designated as secondaries of varying priority for the remainder. In this way, load can be balanced among the AAA servers.
Within primary/secondary configurations, the watchdog timer operates as follows:
Within primary/secondary configurations, the watchdog timer operates as follows:
[1] Assume that each client or agent is initially configured with a
single primary agent or server, and one or more secondary
connections.
[1] Assume that each client or agent is initially configured with a single primary agent or server, and one or more secondary connections.
[2] The watchdog mechanism is used to suspend and eventually close
primary connections that are experiencing difficulties. It is
also used to re-open and validate connections that have returned
to health.
[2] The watchdog mechanism is used to suspend and eventually close primary connections that are experiencing difficulties. It is also used to re-open and validate connections that have returned to health.
[3] Once a secondary is promoted to primary status, either on a
temporary or permanent basis, the next server on the list of
secondaries is promoted to fill the open secondary slot.
[3] Once a secondary is promoted to primary status, either on a temporary or permanent basis, the next server on the list of secondaries is promoted to fill the open secondary slot.
[4] The client or agent periodically attempts to re-open closed
connections, so that it is possible that a previously closed
connection can be returned to service and become eligible for use
again. Implementations will typically retain a limit on the
number of connections open at a time, so that once a previously
closed connection is brought online again, the lowest priority
secondary connection will be closed. In order to prevent
periodic closing and re-opening of secondary connections, it is
recommended that functioning connections remain open for a
minimum of 5 minutes.
[4] The client or agent periodically attempts to re-open closed connections, so that it is possible that a previously closed connection can be returned to service and become eligible for use again. Implementations will typically retain a limit on the number of connections open at a time, so that once a previously closed connection is brought online again, the lowest priority secondary connection will be closed. In order to prevent periodic closing and re-opening of secondary connections, it is recommended that functioning connections remain open for a minimum of 5 minutes.
[5] In order to enable diagnosis of failover behavior, it is
recommended that a table of failover events be kept within the
MIB. These failover events SHOULD include appropriate
transaction identifiers so that client and server data can be
[5] In order to enable diagnosis of failover behavior, it is recommended that a table of failover events be kept within the MIB. These failover events SHOULD include appropriate transaction identifiers so that client and server data can be
Aboba & Wood Standards Track [Page 17] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 17] RFC 3539 AAA Transport Profile June 2003
compared, providing insight into the cause of the problem
(transport or application layer).
compared, providing insight into the cause of the problem (transport or application layer).
3.4.3. Connection Load Balancing
3.4.3. Connection Load Balancing
Primary/secondary failover is capable of providing improved resilience and basic load balancing. However, it does not address TCP head of line blocking, since only a single connection is in use at a time.
Primary/secondary failover is capable of providing improved resilience and basic load balancing. However, it does not address TCP head of line blocking, since only a single connection is in use at a time.
A AAA client or agent maintaining connections to multiple agents or servers MAY load balance between them. Establishing connections to multiple agents or servers reduces, but does not eliminate, head of line blocking issues experienced on TCP connections. This issue does not exist with SCTP connections utilizing multiple streams.
A AAA client or agent maintaining connections to multiple agents or servers MAY load balance between them. Establishing connections to multiple agents or servers reduces, but does not eliminate, head of line blocking issues experienced on TCP connections. This issue does not exist with SCTP connections utilizing multiple streams.
In connection load balancing configurations, the application watchdog operates as follows:
In connection load balancing configurations, the application watchdog operates as follows:
[1] Assume that each client or agent is initially configured with
connections to multiple AAA agents or servers, with one
connection between a given client/agent and an agent/server.
[1] Assume that each client or agent is initially configured with connections to multiple AAA agents or servers, with one connection between a given client/agent and an agent/server.
[2] In static load balancing, transactions are apportioned among the
connections based on the total number of connections and a
"weight" assigned to each connection. Pearson's hash [RFC3074]
applied to the NAI [RFC2486] can be used to determine which
connection will handle a given transaction. Hashing on the NAI
provides highly granular load balancing, while ensuring that all
traffic for a given conversation will be sent to the same agent
or server. In dynamic load balancing, the value of the "weight"
can vary based on conditions such as AAA server load. Such
techniques, while sophisticated, are beyond the scope of this
document.
[2] In static load balancing, transactions are apportioned among the connections based on the total number of connections and a "weight" assigned to each connection. Pearson's hash [RFC3074] applied to the NAI [RFC2486] can be used to determine which connection will handle a given transaction. Hashing on the NAI provides highly granular load balancing, while ensuring that all traffic for a given conversation will be sent to the same agent or server. In dynamic load balancing, the value of the "weight" can vary based on conditions such as AAA server load. Such techniques, while sophisticated, are beyond the scope of this document.
[3] Transactions are distributed to connections based on the total
number of available connections and their weights. A change in
the number of available connections forces recomputation of the
hash table. In order not to cause conversations in progress to
be switched to new destinations, on recomputation, a transitional
period is required in which both old and new hash tables are
needed in order to permit aging out of conversations in progress.
Note that this requires a way to easily determine whether a
Request represents a new conversation or the continuation of an
existing conversation. As a result, removing and adding of
connections is an expensive operation, and it is recommended that
the hash table only be recomputed once a connection is closed or
returned to service.
[3] Transactions are distributed to connections based on the total number of available connections and their weights. A change in the number of available connections forces recomputation of the hash table. In order not to cause conversations in progress to be switched to new destinations, on recomputation, a transitional period is required in which both old and new hash tables are needed in order to permit aging out of conversations in progress. Note that this requires a way to easily determine whether a Request represents a new conversation or the continuation of an existing conversation. As a result, removing and adding of connections is an expensive operation, and it is recommended that the hash table only be recomputed once a connection is closed or returned to service.
Aboba & Wood Standards Track [Page 18] RFC 3539 AAA Transport Profile June 2003
Aboba & Wood Standards Track [Page 18] RFC 3539 AAA Transport Profile June 2003
Suspended connections, although they are not used, do not force
hash table reconfiguration until they are closed. Similarly,
re-opened connections not accumulating sufficient watchdog
responses do not force a reconfiguration until they are returned
to service.
Suspended connections, although they are not used, do not force hash table reconfiguration until they are closed. Similarly, re-opened connections not accumulating sufficient watchdog responses do not force a reconfiguration until they are returned to service.
While a connection is suspended, transactions that were to have
been assigned to it are instead assigned to the next available
server. While this results in a momentary imbalance, it is felt
that this is a relatively small price to pay in order to reduce
hash table thrashing.
While a connection is suspended, transactions that were to have been assigned to it are instead assigned to the next available server. While this results in a momentary imbalance, it is felt that this is a relatively small price to pay in order to reduce hash table thrashing.
[4] In order to enable diagnosis of load balancing behavior, it is
recommended that in addition to a table of failover events, a
table of statistics be kept on each client, indexed by a AAA
server. That way, the effectiveness of the load balancing
algorithm can be evaluated.
[4] In order to enable diagnosis of load balancing behavior, it is recommended that in addition to a table of failover events, a table of statistics be kept on each client, indexed by a AAA server. That way, the effectiveness of the load balancing algorithm can be evaluated.
3.5. Duplicate Detection
3.5. Duplicate Detection
Multiple facilities are required to enable duplicate detection. These include session identifiers as well as hop-by-hop and end-to- end message identifiers. Hop-by-hop identifiers whose value may change at each hop are not sufficient, since a AAA server may receive the same message from multiple agents. For example, a AAA client can send a request to Agent1, then failover and resend the request to Agent2; both agents forward the request to the home AAA server, with different hop-by-hop identifiers. A Session Identifier is insufficient as it does not distinguish different messages for the the same session.
複数の施設が、写し検出を可能にするのに必要です。 これらは終わりからホップごとの終わりへのメッセージ識別子と同様にセッション識別子を含んでいます。 ホップごとの値が各ホップで変化するかもしれない識別子は十分ではありません、AAAサーバが複数のエージェントから同じメッセージを受け取るかもしれないので。 例えば、AAAのクライアントは、Agent1、当時のフェイルオーバーに要求を送って、Agent2に要求を再送できます。 両方のエージェントはホップごとの異なった識別子と共にホームAAAサーバに要求を転送します。 同じセッションへの異なったメッセージを区別しないとき、Session Identifierは不十分です。
Proper treatment of the end-to-end message identifier ensures that AAA operations are idempotent. For example, without an end-to-end identifier, a AAA server keeping track of simultaneous logins might send an Accept in response to an initial Request, and then a Reject in response to a duplicate Request (where the user was allowed only one simultaneous login). Depending on which Response arrived first, the user might be allowed access or not.
終わりから終わりへのメッセージ識別子の適切な治療は、AAA操作がベキ等元であることを確実にします。 例えば、終わりから終わりへの識別子がなければ、同時のログインの動向をおさえるAAAサーバは初期のRequest、および次に、Rejectに対応して写しRequestに対応してAcceptを送るかもしれません(1つの同時のログインだけがユーザに許されたところ)。 どのResponseが先着したかによって、ユーザはアクセスを許されるかもしれません。
However, if the server were to store the end-to-end message identifier along with the simultaneous login information, then the duplicate Request (which utilizes the same end-to-end message identifier) could be identified and the correct response could be returned.
しかしながら、サーバが同時のログイン情報に伴う終わりから終わりへのメッセージ識別子を保存することであるなら、写しRequest(終わりから終わりへのメッセージ同じ識別子を利用する)を特定できます、そして、正しい応答を返すことができました。
Aboba & Wood Standards Track [Page 19] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[19ページ]。
3.6. Invalidation of Transport Parameter Estimates
3.6. 無効にする輸送パラメータ推計について
In order to address invalidation of transport parameter estimates, AAA protocol implementations MAY utilize Congestion Window Validation [RFC2861] and RTO validation when using TCP. This specification also recommends a procedure for RTO validation.
TCPを使用するとき、輸送パラメータ推計について無効にするのを扱うために、AAAプロトコル実装はCongestion Window Validation[RFC2861]とRTO合法化を利用するかもしれません。 また、この仕様はRTO合法化のための手順を推薦します。
[RFC2581] and [RFC2861] both recommend that a connection go into slow-start after a period where no traffic has been sent within the RTO interval. [RFC2861] recommends only increasing the congestion window if it was full when the ACK arrived. The congestion window is reduced by half once every RTO interval if no traffic is received.
[RFC2581]と[RFC2861]は、接続が期間の後にトラフィックが全くRTO間隔中に送られないところに遅れた出発に入ることをともに勧めます。 [RFC2861]は、ACKが到着したとき、それが完全であった場合にだけ混雑ウィンドウを増強することを勧めます。 いったんあらゆるRTO間隔であり、どんなトラフィックも受け取られているというわけではないなら、混雑ウィンドウは半減します。
When Congestion Window Validation is used, the congestion window will not build during application-driven periods, and instead will be decayed. As a result, AAA applications operating within the application-driven regime will typically run with a congestion window equal to the initial window much of the time, operating in "perpetual slowstart".
Congestion Window Validationが使用されているとき、混雑ウィンドウは、アプリケーションでやる気満々の期間、建てないで、代わりに腐食されるでしょう。 その結果、アプリケーション駆動の政権の中で作動するAAAアプリケーションは初期の窓と等しい混雑ウィンドウと共によく通常稼働するでしょう、「永久のslowstart」で作動して。
During periods in which AAA behavior is application-driven this will have no effect. Since the time between packets will be larger than RTT, AAA will operate with an effective congestion window equal to the initial window. However, during network-driven periods, the effect will be to space out sending of AAA packets. Thus instead of being able to send a large burst of packets into the network, a client will need to wait several RTTs as the congestion window builds during slow-start.
AAAの振舞いがアプリケーションによる駆動である期間、これは効き目がないでしょう。 パケットの間の時間がRTTよりさらに大きくなるので、AAAは初期の窓と等しい有効な混雑ウィンドウで作動するでしょう。 しかしながら、ネットワーク駆動の期間、外でAAAパケットを発信させるスペースには効果があるでしょう。 したがって、パケットの大きい炸裂をネットワークに送ることができます、クライアントが待つ必要があるということであることの代わりに混雑ウィンドウとしての数個のRTTsが遅れた出発の間、建てます。
For example, a client operating over TCP with an initial window of 2, with 35 AAA requests to send would take approximately 6 RTTs to send them, as the congestion window builds during slow start: 2, 3, 3, 6, 9, 12. After the backlog is cleared, the implementation will once again be application-driven and the congestion window size will decay. If the client were using SCTP, the number of RTTs needed to transmit all requests would usually be less, and would depend on the size of the requests, since SCTP tracks the progress for the opening of the congestion window by bytes, not segments.
例えば、2の初期の窓があるTCPの上のクライアント操作、35で、発信するというAAA要求は彼らを送るためにおよそ6RTTsを取るでしょう、遅れた出発の間の混雑窓の体格として: 2, 3, 3, 6, 9, 12. 予備がきれいにされた後に、実装はもう一度アプリケーションで駆動になるでしょう、そして、混雑ウィンドウサイズは腐食するでしょう。 クライアントがSCTPを使用しているなら、すべての要求を伝えるのが必要であるRTTsの数を、通常、より少ないだろう、要求のサイズに依存するでしょうに、SCTPが混雑ウィンドウの始まりに進歩をセグメントではなく、何バイトも追跡するので。
Note that [RFC2861] and [RFC2988] do not address the issue of RTO validation. This is also a problem, particularly when the Congestion Manager [RFC3124] is implemented. During periods of high packet loss, the RTO may be repeatedly increased via exponential back-off, and may attain a high value. Due to lack of timely feedback on RTT and RTO during application-driven periods, the high RTO estimate may persist long after the conditions that generated it have dissipated.
[RFC2861]と[RFC2988]がRTO合法化の問題を扱わないことに注意してください。 特にCongestionマネージャ[RFC3124]が実装されるとき、また、これは問題です。 高いパケット損失の期間、RTOは下に指数の後部を通って繰り返して増強されて、高い値を得るかもしれません。 アプリケーションでやる気満々の期間のRTTとRTOのタイムリーなフィードバックの不足のため、それを生成した状態が消散したずっと後に、高いRTO見積りは持続するかもしれません。
Aboba & Wood Standards Track [Page 20] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[20ページ]。
RTO validation MAY be used to address this issue for TCP, via the following procedure:
RTO合法化はTCPのために以下の手順でこの問題を扱うのに使用されるかもしれません:
After the congestion window is decayed according to [RFC2861],
reset the estimated RTO to 3 seconds. After the next packet comes
in, re-calculate RTTavg, RTTdev, and RTO according to the method
described in [RFC2581].
[RFC2861]に従って混雑ウィンドウが腐食された後に、3秒までおよそRTOをリセットしてください。 次のパケットが入った後に、[RFC2581]で説明されたメソッドに従って、RTTavg、RTTdev、およびRTOについて再計算してください。
To address this issue for SCTP, AAA implementations SHOULD use SCTP heartbeats. [RFC2960] states that heartbeats should be enabled by default, with an interval of 30 seconds. If this interval proves to be too long to resolve this issue, AAA implementations MAY reduce the heartbeat interval.
SCTPのためにこの問題を扱うために、AAA実装SHOULDはSCTP鼓動を使用します。 [RFC2960]は、鼓動がデフォルトで30秒の間隔で可能にされるべきであると述べます。 この間隔がこの問題を解決できないくらい長いと判明するなら、AAA実装は鼓動間隔を短縮するかもしれません。
3.7. Inability to Use Fast Re-Transmit
3.7. 速く使用する無能は再送されます。
When Congestion Window Validation [RFC2861] is used, AAA implementations will operate with a congestion window equal to the initial window much of the time. As a result, the window size will often not be large enough to enable use of fast re-transmit for TCP. In addition, since AAA traffic is two-way, ACKs carrying data will not count towards triggering fast re-transmit. SCTP is less likely to encounter this issue, so the measures described below apply to TCP.
Congestion Window Validation[RFC2861]が使用されているとき、AAA実装はよく初期の窓と等しい混雑ウィンドウで作動するでしょう。 結果、ウィンドウサイズがしばしば大きくなるというわけではないとき、TCPのために速く使用を可能にすることができるくらい再送します。 さらに、AAAトラフィックが両用であるので、データを運ぶのが引き金となることに向かって数えないACKsは速く再送します。 SCTPがこの問題により遭遇しそうにないので、以下で説明された測定はTCPに適用されます。
To address this issue, AAA implementations SHOULD support selective acknowledgement as described in [RFC2018] and [RFC2883]. AAA implementations SHOULD also implement Limited Transmit for TCP, as described in [RFC3042]. Rather than reducing the number of duplicate ACKs required for triggering fast recovery, which would increase the number of inappropriate re-transmissions, Limited Transmit enables the window size be increased, thus enabling the sending of additional packets which in turn may trigger fast re-transmit without a change to the algorithm.
この問題を扱うために、AAA実装SHOULDは[RFC2018]と[RFC2883]で説明されるように選択している承認をサポートします。 また、AAA実装SHOULDはTCPのために[RFC3042]で説明されるように株式会社Transmitを実装します。 増強されて、その結果追加パケットの発信を可能にする不適当な再トランスミッションの数を増強するだろう速い回復の引き金となって、株式会社Transmitがウィンドウサイズを可能にするので必要である写しACKsについて数を減らすよりむしろ、引き金はアルゴリズムへの変化なしでどれを順番に速く再送するかもしれないか。
However, if congestion window validation [RFC2861] is implemented, this proposal will only have an effect in situations where the time between packets is less than the estimated retransmission timeout (RTO). If the time between packets is greater than RTO, additional packets will typically not be available for sending so as to take advantage of the increased window size. As a result, AAA protocols will typically operate with the lowest possible congestion window size, resulting in a re-transmission timeout for every lost packet.
しかしながら、混雑窓の合法化[RFC2861]が実装される場合にだけ、この提案には、パケットの間の時間がおよそ再送タイムアウト以下である状況(RTO)における効果があるでしょう。 パケットの間の時間がRTOより大きいなら、追加パケットは増強されたウィンドウサイズを利用するために発信するのに通常利用可能にならないでしょう。 その結果、AAAプロトコルは可能な限り低い混雑ウィンドウサイズで通常作動するでしょう、あらゆる無くなっているパケットのための再トランスミッションタイムアウトをもたらして。
Aboba & Wood Standards Track [Page 21] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[21ページ]。
3.8. Head of Line Blocking
3.8. 線ブロッキングのヘッド
TCP inherently does not provide a solution to the head-of-line blocking problem, although its effects can be lessened by implementation of Limited Transmit [RFC3042], and connection load balancing.
TCPは本来系列のヘッドブロッキング問題に解決法を提供しません、株式会社Transmit[RFC3042]、および接続ロードバランシングの実装で効果を少なくすることができますが。
3.8.1. Using SCTP Streams to Prevent Head of Line Blocking
3.8.1. 線ブロッキングのヘッドを防ぐのにSCTPストリームを使用します。
Each AAA node SHOULD distribute its messages evenly across the range of SCTP streams that it and its peer have agreed upon. (A lost message in one stream will not cause any other streams to block.) A trivial and effective implementation of this simply increments a counter for the stream ID to send on. When the counter reaches the maximum number of streams for the association, it resets to 0.
それぞれのAAAノードSHOULDは均等にそれとその同輩が同意したSCTPストリームの範囲の向こう側にメッセージを分配します。 (1つのストリームにおける無くなっているメッセージはいかなる他のストリームもブロックに引き起こさないでしょう。) この些細で有効な実装は単にストリームIDが転送するカウンタを増加します。 カウンタがいつで最大数に達するかは協会のために流れて、それは0へのリセットです。
AAA peers MUST be able to accept messages on any stream. Note that streams are used *solely* to prevent head-of-the-line blocking. All identifying information is carried within the Diameter payload. Messages distributed across multiple streams may not be received in the order they are sent.
AAAの同輩はどんなストリームに関するメッセージも受け入れることができなければなりません。 ストリームが*唯一使用されて、防ぐ*が、立ち塞がるのを系列を向かわせるということであることに注意してください。 すべての身元が分かる情報がDiameterペイロードの中に運ばれます。 複数の小川の向こう側に分配されたメッセージはそれらが送られるオーダーに受け取られないかもしれません。
SCTP peers can allocate up to 65535 streams for an association. The cost for idle streams may or may not be zero, depending on the implementation, and the cost for non-idle streams is always greater than 0. So administrators may wish to limit the number of possible streams on their diameter nodes according to the resources (i.e. memory, CPU power, etc.) of a particular node.
SCTP同輩は協会のために最大65535のストリームを割り当てることができます。 実装によって、活動していないストリームのための費用はゼロであるかもしれません、そして、いつも非活動していないストリームのための費用は0以上です。 それで、特定のノードに関するリソース(すなわち、メモリ、CPUパワーなど)によると、管理者は彼らの直径ノードの上で可能なストリームの数を制限したがっているかもしれません。
On a Diameter client, the number of streams may be determined by the maximum number of peak users on the NAS. If a stream is available per user, then this should be sufficient to prevent head-of-line blocking. On a Diameter proxy, the number of streams may be determined by the maximum number of peak sessions in progress from that proxy to each downstream AAA server.
Diameterクライアントでは、ピークユーザの最大数に従って、ストリームの数はNASで決定しているかもしれません。 ストリームがユーザ単位で利用可能であるなら、これは、系列のヘッドブロッキングを防ぐために十分であるべきです。 Diameterプロキシでは、そのプロキシから川下のそれぞれのAAAサーバまでの進行中のピークセッションの最大数に従って、ストリームの数は決定しているかもしれません。
Stream IDs do not need to be preserved by relay agents. This simplifies implementation, as agents can easily handle forwarding between two associations with different numbers of streams. For example, consider the following case, where a relay server DRL forwards messages between a NAS and a home server, HMS. The NAS and DRL have agreed upon 1000 streams for their association, and DRL and HMS have agreed upon 2000 streams for their association. The following figure shows the message flow from NAS to HMS via DRL, and the stream ID assignments for each message:
中継エージェントによってストリームIDは保存される必要はありません。 これは実装を簡素化します、エージェントが容易に異なった数のストリームとの2つの関係の間の推進を扱うことができるとき。例えば、以下のケースを考えてください。そこでは、HMS DRLがNASの間のメッセージを転送するリレーサーバ、ホームサーバ、NAS、およびDRLがそれらの協会のために1000のストリームに同意して、DRLとHMSはそれらの協会のために2000のストリームに同意しました。 以下の図はDRLを通したNASからHMSまでのメッセージ流動、および各メッセージのためのストリームID課題を示しています:
Aboba & Wood Standards Track [Page 22] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[22ページ]。
+------+ +------+ +------+ | | | | | | | NAS | ---------> | DRL | ---------> | HMS | | | | | | | +------+ 1000 streams +------+ 2000 streams +------+
+------+ +------+ +------+ | | | | | | | NAS| --------->| DRL| --------->| HMS| | | | | | | +------+ 1000のストリーム+------+ 2000のストリーム+------+
msg 1: str id 0 msg 1: str id 0
msg 2: str id 1 msg 2: str id 1
...
msg 1000: str id 999 msg 1000: str id 999
msg 1001: str id 0 msg 1001: str id 1000
msg1: strイド0msg1: strイド0msg2: strイド1msg2: strイド1…msg1000: strイド999msg1000: strイド999msg1001: strイド0msg1001: strイド1000
DRL can forward messages 1 through 1000 to HMS using the same stream ID that NAS used to send to DRL. However, since the NAS / DRL association has only 1000 streams, NAS wraps around to stream ID 0 when sending message 1001. The DRL / HMS association, on the other hand, has 2000 streams, so DRL can reassign message 1001 to stream ID 1000 when forwarding it on to HMS.
DRLは、NASが以前はよくDRLに送ったのと同じストリームIDを使用することでメッセージを1〜1000にHMSに転送できます。 しかしながら、NAS / DRL協会には1000のストリームしかないので、NASはメッセージ1001を送るとき、ID0を流すために巻きつけます。 DRL / HMS協会には2000のストリームが他方ではあるので、それをHMSに送るとき、DRLはメッセージ1001からストリームID1000を再選任できます。
This distribution scheme acts like a hash table. It is possible, yet unlikely, that two messages will end up in the same stream, and even less likely that there will be message loss resulting in blocking when this happens. If it does turn out to be a problem, local administrators can increase the number of streams on their nodes to improve performance.
この分配体系はハッシュ表のように行動します。 それは可能です、まだありそうもない、これであるときにブロッキングをもたらすメッセージの損失よりありさえしそうにない状態で2つのメッセージが終わるのが起こります。 問題であると判明するなら、地元の管理者は、性能を向上させるために彼らのノードでストリームの数を増強できます。
3.9. Congestion Avoidance
3.9. 輻輳回避
In order to improve upon default timer estimates, AAA implementations MAY implement the Congestion Manager (CM) [RFC3124]. CM is an end- system module that:
デフォルトタイマ見積りを改良するために、AAA実装は、Congestionがマネージャ(CM)である[RFC3124]と実装するかもしれません。 CMが終わりのシステム・モジュールである、それ:
(i) Enables an ensemble of multiple concurrent streams from a
sender destined to the same receiver and sharing the same
congestion properties to perform proper congestion avoidance
and control, and
そして(i)が、同じ受信機に運命づけられていて、同じ混雑の特性を共有しているa送付者からの複数の同時発生のストリームのアンサンブルが適切な輻輳回避とコントロールを実行するのを可能にする。
(ii) Allows applications to easily adapt to network congestion.
(ii)で、アプリケーションは容易にネットワークの混雑に順応できます。
The CM helps integrate congestion management across all applications and transport protocols. The CM maintains congestion parameters (available aggregate and per-stream bandwidth, per-receiver round- trip times, etc.) and exports an API that enables applications to learn about network characteristics, pass information to the CM, share congestion information with each other, and schedule data transmissions.
CMは、すべてのアプリケーションとトランスポート・プロトコルの向こう側にふくそう管理を統合するのを助けます。 CMは、混雑パラメタ(利用可能な集合と1ストリームあたりの帯域幅、1受信機あたりの丸い旅行時間など)を維持して、アプリケーションがネットワークの特性に関して学んで、情報をCMに通過して、混雑情報を互いと共有して、データ伝送の計画をするのを可能にするAPIをエクスポートします。
Aboba & Wood Standards Track [Page 23] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[23ページ]。
The CM enables the AAA application to access transport parameters (RTTavg, RTTdev) via callbacks. RTO estimates are currently not available via the callback interface, though they probably should be. Where available, transport parameters SHOULD be used to improve upon default timer values.
CMは、コールバックでAAAアプリケーションが輸送パラメタ(RTTavg、RTTdev)にアクセスするのを可能にします。 それらはたぶん有効であるべきですが、RTO見積りは現在、コールバックインタフェースを通して有効ではありません。 入手できるところに、パラメタSHOULDを輸送してください。使用されて、デフォルトタイマ値を改良してください。
3.10. Premature Failover
3.10. 時期尚早なフェイルオーバー
Premature failover is prevented by the watchdog functionality described above. If the next hop does not return a reply, the AAA client will send a watchdog message to it to verify liveness. If a watchdog reply is received, then the AAA client will know that the next hop server is functioning at the application layer. As a result, it is only necessary to provide terminal error messages, such as the following:
時期尚早なフェイルオーバーは上で説明された番犬の機能性によって防がれます。 次のホップが回答を返さないと、AAAのクライアントは、活性について確かめるために番犬メッセージをそれに送るでしょう。 番犬回答が受け取られていると、AAAのクライアントは、次のホップサーバが応用層で機能しているのを知るでしょう。 その結果、単に以下などの端末のエラーメッセージを提供するのが必要です:
"Busy": agent/Server too busy to handle additional requests, NAS
should failover all requests to another agent/server.
「忙しくします」: 追加要求、NASを扱うことができないくらい忙しいエージェント/サーバはすべてが別のエージェント/サーバに要求するフェイルオーバーがそうするべきです。
"Can't Locate": agent can't locate the AAA server for the
indicated realm; NAS should failover that request to another
proxy.
「場所を見つけることができません」: エージェントは示された分野へのAAAサーバの場所を見つけることができません。 NASはそれが別のプロキシに要求するフェイルオーバーがそうするべきです。
"Can't Forward": agent has tried both primary and secondary AAA
servers with no response; NAS should failover the request to
another agent.
「前方にそうすることができません」: エージェントは応答なしでプライマリの、そして、セカンダリの両方のAAAサーバを試みました。 NASがそうするべきである、フェイルオーバー、別のエージェントへの要求。
Note that these messages differ in their scope. The "Busy" message tells the NAS that the agent/server is too busy for ANY request. The "Can't Locate" and "Can't Forward" messages indicate that the ultimate destination cannot be reached or isn't responding, implying per-request failover.
これらのメッセージがそれらの範囲で異なることに注意してください。 「忙しい」メッセージは、どんな要求にも、エージェント/サーバが忙し過ぎるとNASに言います。 「場所を見つけることができない」で、「前方にそうすることができません」というメッセージは、最終仕向地が達することができませんし、応じてもいないのを示します、1要求あたりのフェイルオーバーを含意して。
4. Security Considerations
4. セキュリティ問題
Since AAA clients, agents and servers serve as network access gatekeepers, they are tempting targets for attackers. General security considerations concerning TCP congestion control are discussed in [RFC2581]. However, there are some additional considerations that apply to this specification.
AAAのクライアント、エージェント、およびサーバがネットワークアクセス門番として勤めるので、彼らは攻撃者のための目標を誘惑しています。 [RFC2581]でTCP輻輳制御に関する総合証券問題について議論します。 しかしながら、この仕様に適用されるいくつかの追加問題があります。
By enabling failover between AAA agents, this specification improves the resilience of AAA applications. However, it may also open avenues for denial of service attacks.
AAAのエージェントの間のフェイルオーバーを可能にすることによって、この仕様はAAAアプリケーションの弾力を改良します。 しかしながら、また、それはサービス不能攻撃のために大通りを開くかもしれません。
The failover algorithm is driven by lack of response to AAA requests and watchdog packets. On a lightly loaded network where AAA responses would not be received prior to expiration of the watchdog
フェイルオーバーアルゴリズムはAAA要求に無反応を通り過ぎて、パケットを監視することです。 AAA応答が番犬の満了の前に受けられない軽くロードされたネットワークに関して
Aboba & Wood Standards Track [Page 24] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[24ページ]。
timer, an attacker can swamp the network, causing watchdog packets to be dropped. This will cause the AAA client to switch to another AAA agent, where the attack can be repeated. By causing the AAA client to cycle between AAA agents, service can be denied to users desiring network access.
タイマ、攻撃者はネットワークに殺到できて、引き起こすのは下げられるべき番犬パケットです。 これで、AAAのクライアントは攻撃を繰り返すことができるところで別のAAAのエージェントに切り替わるでしょう。 AAAのクライアントがAAAのエージェントの間で自転車で行くことを引き起こすことによって、サービスはネットワークアクセサリーを望んでいるユーザに対して否定される場合があります。
Where TLS [RFC2246] is being used to provide AAA security, there will be a vulnerability to spoofed reset packets, as well as other transport layer denial of service attacks (e.g. SYN flooding). Since SCTP offers improved denial of service resilience compared with TCP, where AAA applications run over SCTP, this can be mitigated to some extent.
TLS[RFC2246]がAAAセキュリティを提供するのに使用されているところに、偽造しているリセットパケットへの脆弱性があるでしょう、他のトランスポート層サービス不能攻撃(例えば、SYN氾濫)と同様に。 SCTP申し出がTCPと比べてサービス弾力の否定を改良したので、これをある程度緩和できます。そこでは、AAAアプリケーションがSCTPをひきます。
Where IPsec [RFC2401] is used to provide security, it is important that IPsec policy require IPsec on incoming packets. In order to enable a AAA client to determine what security mechanisms are in use on an agent or server without prior knowledge, it may be tempting to initiate a connection in the clear, and then to have the AAA agent respond with IKE [RFC2409]. While this approach minimizes required client configuration, it increases the vulnerability to denial of service attack, since a connection request can now not only tie up transport resources, but also resources within the IKE implementation.
IPsec[RFC2401]がセキュリティを提供するのに使用されるところでは、IPsec方針が入って来るパケットの上でIPsecを必要とするのは、重要です。 AAAのクライアントが、どんなセキュリティー対策がエージェントかサーバで予備知識なしに使用中であるかを決心しているのを可能にするために、それは明確で接続を開始して、そして、AAAのエージェントをIKE[RFC2409]と共に応じさせるのに誘惑しているかもしれません。 このアプローチは必要なクライアント構成を最小にしますが、サービス不能攻撃に脆弱性を増強します、接続要求が現在IKE実装の中で輸送リソースだけではなく、リソースもタイアップできるので。
5. IANA Considerations
5. IANA問題
This document does not create any new number spaces for IANA administration.
このドキュメントはIANA管理のために少しの新しい数の空間も作成しません。
References
参照
6.1. Normative References
6.1. 引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC896] Nagle, J., "Congestion Control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC896] 1984年1月のネーグル、J.、「IP/TCPインターネットワークにおける混雑Control」RFC896。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1750] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Aboba & Wood Standards Track [Page 25] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[25ページ]。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC2486] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A.
Romanow, "An Extension to the Selective Acknowledgment
(SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883] フロイドとS.とMahdaviとJ.とマシスとM.とポドルスキーとM.とA.Romanow、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883、2000年7月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
L. and V. Paxson, "Stream Control Transmission Protocol",
RFC 2960, October 2000.
[RFC2960]スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC3042] Allman, M., Balakrishnan H. and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", RFC 3042, January
2001.
[RFC3042] オールマンとM.とBalakrishnan H.とS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、2001年1月。
[RFC3074] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load
Balancing Algorithm", RFC 3074, February 2001.
[RFC3074] フォルツとB.とGoncziとS.とレモンとT.とR.スティーブンス、「DHCロードバランシングアルゴリズム」、RFC3074、2001年2月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[RFC3124]BalakrishnanとH.とS.Seshan、「混雑マネージャ」(RFC3124)2001年6月。
6.2. Informative References
6.2. 有益な参照
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] アトキンソンとR.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC2861] ハンドレーとM.とPadhyeとJ.とS.フロイド、「TCP混雑窓の合法化」、RFC2861、2000年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[RFC2865]RigneyとC.とウィレンスとS.とルーベン、A.とW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
Aboba & Wood Standards Track [Page 26] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[26ページ]。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、「半径会計」、RFC2866、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, June 2000.
[RFC2975] AbobaとB.とArkkoとJ.とD.ハリントン、「会計管理への紹介」、RFC2975、2000年6月。
[RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC3390] オールマンとM.とフロイドとS.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC3390、2002年10月。
[Congest] Jacobson, V., "Congestion Avoidance and Control", Computer
Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[充血します] ジェーコブソンと、V.と、「輻輳回避とコントロール」、コンピュータCommunication Review、vol.18、No.4、ページ 314-329 8月1988日の ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[Paxson] Paxson, V., "Measurement and Analysis of End-to-End
Internet Dynamics", Ph.D. Thesis, Computer Science
Division, University of California, Berkeley, April 1997.
[パクソン]パクソンと、V.と、「終わりから終わりへのインターネット力学の測定と分析」、博士Thesis、コンピュータ学術課(カリフォルニア大学バークレイ校1997年4月)
Aboba & Wood Standards Track [Page 27] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[27ページ]。
Appendix A - Detailed Watchdog Algorithm
付録A--詳細な番犬アルゴリズム
In this Appendix, the memory control structure that contains all information regarding a specific peer is referred to as a Peer Control Block, or PCB. The PCB contains the following fields:
このAppendixでは、特定の同輩のすべての情報を含むメモリ制御構造はPeer Control Block、またはPCBと呼ばれます。 PCBは以下の分野を含んでいます:
Status:
OKAY: The connection is up
SUSPECT: Failover has been initiated on the connection.
DOWN: Connection has been closed.
REOPEN: Attempting to reopen a closed connection
INITIAL: The initial state of the pcb when it is first created.
The pcb has never been opened.
状態: 以下を承認してください。 SUSPECTの上に接続があります: フェイルオーバーは接続のときに開始されました。 以下より倒してください。 接続は閉店しました。 再開します: 閉じている接続INITIALを再開させるのを試みます: それであるときに、pcbの初期状態は最初に、創設されます。 pcbは一度も開かれたことがありません。
Variables:
Pending: Set to TRUE if there is an outstanding unanswered
watchdog request
Tw: Watchdog timer value
NumDWA: Number of DWAs received during REOPEN
変数: 未定: 傑出している答えのない番犬要求Twがあれば、TRUEにセットしてください: タイマ値がNumDWAであると監視してください: REOPENの間に受け取られたDWAsの数
Tw is the watchdog timer, measured in seconds. Every second, Tw is decremented. When it reaches 0, the OnTimerElapsed event (see below) is invoked. Pseudo-code for the algorithm is included on the following pages.
Twは秒に測定されたウオッチドッグタイマーです。 毎秒、Twは減少します。 0に達するとき、OnTimerElapsedイベント(以下を見る)は呼び出されます。 アルゴリズムのための中間コードは以下のページに含まれています。
SetWatchdog()
{
/*
SetWatchdog() is called whenever it is necessary
to reset the watchdog timer Tw. The value of the
watchdog timer is calculated based on the default
initial value TWINIT and a jitter ranging from
-2 to 2 seconds. The default for TWINIT is 30 seconds,
and MUST NOT be set lower than 6 seconds.
*/
Tw=TWINIT -2.0 + 4.0 * random() ;
SetTimer(Tw) ;
return ;
}
SetWatchdog(){ /*SetWatchdog() ウオッチドッグタイマーをリセットするのが必要であるときはいつも、呼ばれて、Twウオッチドッグタイマーの値がデフォルトの初期の値のTWINITに基づいて計算されて、-2〜2秒TWINITのためのデフォルトから変化するジターが30秒であり、6秒*/Tw=TWINIT-2.0+4.0より低い*無作為の状態で設定されてはいけないということです。() ; SetTimer(Tw)(リターン)
/*
OnReceive() is called whenever a message
is received from the peer. This message MAY
be a request or an answer, and can include
DWR and DWA messages. Pending is assumed to
be a global variable.
*/
OnReceive(pcb, msgType)
同輩からメッセージを受け取るときはいつも、/*OnReceive()は呼ばれます。 このメッセージは、要求か答えであるかもしれなく、DWRとDWAメッセージを含むことができます。 未定である、大域変数であると思われます。 */OnReceive(pcb、msgType)
Aboba & Wood Standards Track [Page 28] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[28ページ]。
{
if (msgType == DWA) {
Pending = FALSE;
}
switch (pcb->Status){
case OKAY:
SetWatchdog();
break;
case SUSPECT:
pcb->Status = OKAY;
Failback(pcb);
SetWatchdog();
break;
case REOPEN:
if (msgType == DWA) {
NumDWA++;
if (NumDWA == 3) {
pcb->status = OKAY;
Failback();
}
} else {
Throwaway(received packet);
}
break;
case INITIAL:
case DOWN:
Throwaway(received packet);
break;
default:
Error("Shouldn't be here!");
break;
}
}
未定..切り換える..ケース..中断..ケース..壊す..ケースに入れる..状態..等しい..ほか..ビラ..受ける..パケット..中断..ケース..ケース..ビラ..受ける..パケット..壊す..デフォルトとする..誤り..ここ..壊す
/*
OnTimerElapsed() is called whenever Tw reaches zero (0).
*/
OnTimerElapsed(pcb)
{
switch (pcb->status){
case OKAY:
if (!Pending) {
SendWatchdog(pcb);
SetWatchdog();
Pending = TRUE;
break;
}
pcb->status = SUSPECT;
Tw範囲が(0)のゼロに合っているときはいつも、/*OnTimerElapsed()は呼ばれます。 */OnTimerElapsed(pcbする)、(pcb>の状態)を切り換えてください、ケースOKAY: SetWatchdog()(未定の=TRUE)が壊れるという(Pending)SendWatchdog(pcb)であるなら、pcb>の状態はSUSPECTと等しいです。
Aboba & Wood Standards Track [Page 29] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[29ページ]。
FailOver(pcb);
SetWatchdog();
break ;
case SUSPECT:
pcb->status = DOWN;
CloseConnection(pcb);
SetWatchdog();
break;
case INITIAL:
case DOWN:
AttemptOpen(pcb);
SetWatchdog();
break;
case REOPEN:
if (!Pending) {
SendWatchdog(pbc);
SetWatchdog();
Pending = TRUE;
break;
}
if (NumDWA < 0) {
pcb->status = DOWN;
CloseConnection(pcb);
} else {
NumDWA = -1;
}
SetWatchdog();
break;
default:
error("Shouldn't be here!);
break;
}
}
フェイルオーバー(pcb)。 SetWatchdog()。 壊れてください。 SUSPECTをケースに入れてください: pcb>の状態はDOWNと等しいです。 CloseConnection(pcb)。 SetWatchdog()。 壊れてください。 INITIALをケースに入れてください: DOWNをケースに入れてください: AttemptOpen(pcb)。 SetWatchdog()。 壊れてください。 REOPENをケースに入れてください: pcb>の状態はDOWNと等しいです; CloseConnection(pcb)、(NumDWA<0)であるならSetWatchdog()(未定の=TRUE)が壊れるという(Pending)SendWatchdog(pbc)であるならほか、NumDWA=-1;、SetWatchdog()。 壊れてください。 デフォルト: 誤り、(「ここにあるべきでない、!)、」、。 壊れてください。 } }
/*
OnConnectionUp() is called whenever a connection comes up
*/
OnConnectionUp(pcb)
{
switch (pcb->status){
case INITIAL:
pcb->status = OKAY;
SetWatchdog();
break;
case DOWN:
pcb->status = REOPEN;
NumDWA = 0;
SendWatchdog(pcb);
接続が*/OnConnectionUp(pcbする)を来るときはいつも、/*OnConnectionUp()が呼ばれる、(pcb>の状態)を切り換えてください、ケースINITIAL: pcb>の状態=OKAY; SetWatchdog(); 壊れてください; DOWNをケースに入れてください: pcb>の状態はREOPEN; NumDWA=0; SendWatchdog(pcb)と等しいです。
Aboba & Wood Standards Track [Page 30] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[30ページ]。
SetWatchdog();
Pending = TRUE;
break;
default:
error("Shouldn't be here!);
break;
}
}
SetWatchdog()。 未定である、= 本当に。 壊れてください。 デフォルト: 誤り、(「ここにあるべきでない、!)、」、。 壊れてください。 } }
/*
OnConnectionDown() is called whenever a connection goes down
*/
OnConnectionDown(pcb)
{
pcb->status = DOWN;
CloseConnection();
switch (pcb->status){
case OKAY:
Failover(pcb);
SetWatchdog();
break;
case SUSPECT:
case REOPEN:
SetWatchdog();
break;
default:
error("Shouldn't be here!);
break;
}
}
接続が*/OnConnectionDown(pcb)を下るときはいつも、/*OnConnectionDown()は呼ばれます。pcb>の状態=DOWN; CloseConnection();が(pcb>の状態)を切り換える、OKAYをケースに入れてください: フェイルオーバー(pcb); SetWatchdog();は壊れます; SUSPECTをケースに入れてください: REOPEN: SetWatchdog(); 中断; デフォルト: 誤りをケースに入れてください、(「ここにあるべきでない、!)、; 壊れてください;、」
/* Here is the state machine equivalent to the above code:
*ここの/は上のコードに同等な州のマシンです:
STATE Event Actions New State
===== ------ ------- ----------
OKAY Receive DWA Pending = FALSE
SetWatchdog() OKAY
OKAY Receive non-DWA SetWatchdog() OKAY
SUSPECT Receive DWA Pending = FALSE
Failback()
SetWatchdog() OKAY
SUSPECT Receive non-DWA Failback()
SetWatchdog() OKAY
REOPEN Receive DWA & Pending = FALSE
NumDWA == 2 NumDWA++
Failback() OKAY
REOPEN Receive DWA & Pending = FALSE
NumDWA < 2 NumDWA++ REOPEN
州のイベント動作の新しい州===== ------ ------- ---------- 承認が受信される、誤ったSetWatchdog()オーケーの承認が受ける=までDWAがDWAを受ける、非DWA SetWatchdog()承認が、疑う偽のFailback() SetWatchdog()オーケーの容疑者が受ける=まで、承認が再開させる非DWA Failback() SetWatchdog()はDWAを受けて、2NumDWA++Failback()偽のNumDWA=承認が再開させる=までDWAと2NumDWA++が再開させる未定の=偽のNumDWA<を受けます。
Aboba & Wood Standards Track [Page 31] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[31ページ]。
STATE Event Actions New State
===== ------ ------- ----------
REOPEN Receive non-DWA Throwaway() REOPEN
INITIAL Receive DWA Pending = FALSE
Throwaway() INITIAL
INITIAL Receive non-DWA Throwaway() INITIAL
DOWN Receive DWA Pending = FALSE
Throwaway() DOWN
DOWN Receive non-DWA Throwaway() DOWN
OKAY Timer expires & SendWatchdog()
!Pending SetWatchdog()
Pending = TRUE OKAY
OKAY Timer expires & Failover()
Pending SetWatchdog() SUSPECT
SUSPECT Timer expires CloseConnection()
SetWatchdog() DOWN
INITIAL Timer expires AttemptOpen()
SetWatchdog() INITIAL
DOWN Timer expires AttemptOpen()
SetWatchdog() DOWN
REOPEN Timer expires & SendWatchdog()
!Pending SetWatchdog()
Pending = TRUE REOPEN
REOPEN Timer expires & CloseConnection()
Pending & SetWatchdog()
NumDWA < 0 DOWN
REOPEN Timer expires & NumDWA = -1
Pending & SetWatchdog()
NumDWA >= 0 REOPEN
INITIAL Connection up SetWatchdog() OKAY
DOWN Connection up NumDWA = 0
SendWatchdog()
SetWatchdog()
Pending = TRUE REOPEN
OKAY Connection down CloseConnection()
Failover()
SetWatchdog() DOWN
SUSPECT Connection down CloseConnection()
SetWatchdog() DOWN
REOPEN Connection down CloseConnection()
SetWatchdog() DOWN
*/
州のイベント動作の新しい州===== ------ ------- ---------- REOPEN Receive非DWA Throwaway() REOPEN INITIAL Receive DWA PendingはFALSE Throwaway() DOWN DOWN Receive非DWA Throwaway() DOWN OKAY Timerが吐き出すFALSE Throwaway() INITIAL INITIAL Receive非DWA Throwaway() INITIAL DOWN Receive DWA Pending=とSendWatchdog()と等しいです; Pending SetWatchdog()、TRUE OKAY OKAY Timerが吐き出して、SetWatchdog() SUSPECT SUSPECT TimerまでFailover()が吐き出す=までCloseConnection() SetWatchdog() DOWN INITIAL TimerがAttemptOpen() SetWatchdog() INITIAL DOWN Timerを吐き出す、AttemptOpen()を吐き出します; SetWatchdog() DOWN REOPEN Timerは期限が切れます、そして、0DOWN REOPEN Timerが吐き出すTRUE REOPEN REOPEN Timerが吐き出す=、未定のCloseConnection()、およびSetWatchdog() NumDWA<までSendWatchdog()!Pending SetWatchdog()とNumDWAは-1Pending&SetWatchdog() NumDWAと等しいです; 0が= 本当にSetWatchdog()のオーケーの下に接続との初期の接続をNumDWA=0SendWatchdog() SetWatchdog()未定の状態で再開させる>=はCloseConnection() SetWatchdの下で接続のオーケーの下にCloseConnection()フェイルオーバー()SetWatchdog()を怪しい接続の下側に再開させます。CloseConnection() SetWatchdog() DOWN*/へのog() DOWN REOPEN Connection
Aboba & Wood Standards Track [Page 32] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[32ページ]。
Appendix B - AAA Agents
付録B--AAAのエージェント
As described in [RFC2865] and [RFC2607], AAA agents have become popular in order to support services such as roaming and shared use networks. Such agents are used both for authentication/authorization, as well as accounting [RFC2975].
[RFC2865]と[RFC2607]で説明されるように、AAAのエージェントはローミングと共有された使用がネットワークでつなぐサービスを支持するためにポピュラーになりました。 そのようなエージェントは認証/認可、および会計[RFC2975]に使用されます。
AAA agents include:
AAAのエージェントは:
Relays
Proxies
Re-directs
Store and Forward proxies
Transport layer proxies
リレーはストアとForwardプロキシTransport層のプロキシをProxies Re指示します。
The transport layer behavior of each of these agents is described below.
これらのエージェントの各人のトランスポート層の振舞いは以下で説明されます。
B.1 Relays and Proxies
B.1リレーとプロキシ
While the application-layer behavior of relays and proxies are different, at the transport layer the behavior is similar. In both cases, two connections are established: one from the AAA client (NAS) to the relay/proxy, and another from the relay/proxy to the AAA server. The relay/proxy does not respond to a client request until it receives a response from the server. Since the two connections are de-coupled, the end-to-end conversation between the client and server may not self clock.
リレーとプロキシの応用層の振舞いは異なっていますが、トランスポート層では、振舞いは同様です。 どちらの場合も、2つの接続が確立されます: AAAクライアント(NAS)からリレー/プロキシと、別のリレー/プロキシから. リレー/プロキシが反応させないAAAサーバまでのものからそれまでのクライアント要求までの1つはサーバから応答を受けます。以来2つの接続が衝撃を吸収されて、クライアントとサーバとの会話がそうしない終わりから終わりへの自己は時計です。
Since AAA transport is typically application-driven, there is frequently not enough traffic to enable ACK piggybacking. As a result, the Nagle algorithm is rarely triggered, and delayed ACKs may comprise nearly half the traffic. Thus AAA protocols running over reliable transport will see packet traffic nearly double that experienced with UDP transport. Since ACK parameters (such as the value of the delayed ACK timer) are typically fixed by the TCP implementation and are not tunable by the application, there is little that can be done about this.
AAA輸送がアプリケーションによる通常駆動であるので、頻繁にACK便乗を可能にすることができないくらいの交通があります。 その結果、ネーグルアルゴリズムはめったに引き起こされません、そして、遅れたACKsは交通のおよそ半分を包括するかもしれません。 したがって、信頼できる輸送をひくAAAプロトコルは、パケット交通がUDP輸送で経験されたそれをほとんど倍にするのを見るでしょう。 ACKパラメタ(遅れているACKタイマの値などの)がTCP実現で通常修理されていて、アプリケーションで調整可能でないので、少ししかこれに関してできるありません。
Aboba & Wood Standards Track [Page 33] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[33ページ]。
A typical trace of a conversation between a NAS, proxy and server is shown below:
NASと、プロキシとサーバとの会話の典型的な跡は以下に示されます:
Time NAS Relay/Proxy Server ------ --- ----------- ------
時間NASリレー/Proxyサーバ------ --- ----------- ------
0 Request
------->
OTTnp + Tpr Request
------->
0要求-------OTTnp+Tprが要求する>。------->。
OTTnp + TdA Delayed ACK
<-------
OTTnp+TdAはACK<を遅らせました。-------
OTTnp + OTTps + Reply/ACK Tpr + Tsr <-------
OTTnp+OTTps+回答/ACK Tpr+Tsr<。-------
OTTnp + OTTps + Tpr + Tsr + Reply OTTsp + TpR <-------
OTTnp+OTTps+Tpr+Tsr+回答OTTsp+TpR<。-------
OTTnp + OTTps + Tpr + Tsr + Delayed ACK OTTsp + TdA ------->
OTTnp+OTTps+Tpr+Tsr+遅れたACK OTTsp+TdA------->。
OTTnp + OTTps + OTTsp + OTTpn + Tpr + Tsr + Delayed ACK TpR + TdA ------->
OTTnp+OTTps+OTTsp+OTTpn+Tpr+Tsr+遅れたACK TpR+TdA------->。
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Relay/Proxy) OTTpn = One-way trip time (Relay/Proxy to NAS) OTTps = One-way trip time (Relay/Proxy to Server) OTTsp = One-way trip time (Server to Relay/Proxy) TdA = Delayed ACK timer Tpr = Relay/Proxy request processing time TpR = Relay/Proxy reply processing time Tsr = Server request processing time
キー--- 片道旅行時間(Relay/プロキシへのサーバ)片道旅行時間(Serverのリレー/プロキシ)片道旅行時間(NASのリレー/プロキシ)片道旅行時間(Relay/プロキシへのNAS)片道OTT=Trip Time OTTnp=OTTpn=OTTps=OTTsp=TdA=はACKタイマTpr=リレー/プロキシ要求処理時間TpR=リレー/プロキシ回答処理時間Tsr=サーバ要求処理時間を遅らせました。
At time 0, the NAS sends a request to the relay/proxy. Ignoring the serialization time, the request arrives at the relay/proxy at time OTTnp, and the relay/proxy takes an additional Tpr in order to forward the request toward the home server. At time TdA after
時0に、NASはリレー/プロキシに要求を送ります。 連載時間を無視して、要求が時間OTTnpのリレー/プロキシに到着して、リレー/プロキシがホームサーバに向かって要求を転送するために追加Tprを取る、後の時間TdA
Aboba & Wood Standards Track [Page 34] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[34ページ]。
receiving the request, the relay/proxy sends a delayed ACK. The delayed ACK is sent, rather than being piggybacked on the reply, as long as TdA < OTTps + OTTsp + Tpr + Tsr + TpR.
要求を受け取って、リレー/プロキシは遅れたACKを送ります。 回答のときに背負われるよりむしろ遅れたACKを送ります、TdA<OTTps+OTTsp+Tpr+Tsr+TpRと同じくらい長いです。
Typically Tpr < TdA, so that the delayed ACK is sent after the relay/proxy forwards the request toward the server, but before the relay/proxy receives the reply from the server. However, depending on the TCP implementation on the relay/proxy and when the request is received, it is also possible for the delayed ACK to be sent prior to forwarding the request.
リレー/プロキシがサーバに向かって要求を転送した後にもかかわらず、リレー/プロキシの前に遅れたACKを送るのは通常Tpr<TdAによってサーバから回答を受け取ります。しかしながら、要求が受信されているとき、リレー/プロキシにおけるTCP実現によって、また、要求を転送する前に遅れたACKを送るのも可能です。
At time OTTnp + OTTps + Tpr, the server receives the request, and Tsr later, it generates the reply. Where Tsr < TdA, the reply will contain a piggybacked ACK. However, depending on the server responsiveness and TCP implementation, the ACK and reply may be sent separately. This can occur, for example, where a slow database or storage system must be accessed prior to sending the reply.
時間OTTnp+OTTps+Tprのときに、サーバは後で要求、およびTsrを受け取って、それは回答を発生させます。 Tsr<TdA、回答が便乗しているACKを含むところ。 しかしながら、別々にサーバの反応性とTCP実現による、ACK、および回答を送るかもしれません。 例えば、これは回答を送る前に遅いデータベースか格納システムにアクセスしなければならないところに起こることができます。
At time OTTnp + OTTps + OTTsp + Tpr + Tsr the reply/ACK reaches the relay/proxy, which then takes TpR additional time to forward the reply to the NAS. At TdA after receiving the reply, the relay/proxy generates a delayed ACK. Typically TpR < TdA so that the delayed ACK is sent to the server after the relay/proxy forwards the reply to the NAS. However, depending on the circumstances and the relay/proxy TCP implementation, the delayed ACK may be sent first.
回答をNASに送るTpRの追加時間がその時かかる回答/ACKがリレー/プロキシに届く時間OTTnp+OTTps+OTTsp+Tpr+Tsrのときに。 回答を受け取った後のTdAでは、リレー/プロキシは遅れたACKを発生させます。 通常TpR<TdA、それで、リレー/プロキシの後に遅れたACKをサーバに送るのは回答をNASに送ります。 しかしながら、事情とリレー/プロキシTCP実現によって、最初に、遅れたACKを送るかもしれません。
As with a delayed ACK sent in response to a request, which may be piggybacked if the reply can be received quickly enough, piggybacking of the ACK sent in response to a reply from the server is only possible if additional request traffic is available. However, due to the high inter-packet spacings in typical AAA scenarios, this is unlikely unless the AAA protocol supports a reply ACK.
単に要求に対応して送る遅れたACKのように、追加要求交通が利用可能であるなら、ACKの便乗が十分すぐに回答を受け取ることができるのでサーバからの回答に対応して発信したならどれが背負われるかは、可能です。 しかしながら、典型的なAAAシナリオの高い相互パケットスペースのために、AAAプロトコルが回答ACKを支持しない場合、これはありそうもないです。
At time OTTnp + OTTps + OTTsp + OTTpn + Tpr + Tsr + TpR the NAS receives the reply. TdA later, a delayed ACK is generated.
時間OTTnp+OTTps+OTTsp+OTTpn+Tpr+Tsr+TpRのときに、NASは回答を受け取ります。 後でのTdA、遅れたACKは発生します。
B.2 Re-directs
B.2は向け直します。
Re-directs operate by referring a NAS to the AAA server, enabling the NAS to talk to the AAA server directly. Since a direct transport connection is established, the end-to-end connection will self-clock.
AAAサーバをNASを参照することによって作動して、NASが直接AAAサーバと話すのを可能にしながら、向け直します。 直航運送接続が確立されるので、終わりから終わりとの接続は自己に時間を計るでしょう。
With re-directs, delayed ACKs are less frequent than with application-layer proxies since the Re-direct and Server will typically piggyback replies with ACKs.
向け直す、ダイレクトにReとServerがACKsとの回答を通常背負うので、遅れたACKsは応用層プロキシほど頻繁ではありません。
Aboba & Wood Standards Track [Page 35] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[35ページ]。
The sequence of events is as follows:
出来事の系列は以下の通りです:
Time NAS Re-direct Server ------ --- --------- ------
時間のNASの再直接のサーバ------ --- --------- ------
0 Request
------->
OTTnp + Tpr Redirect/ACK
<-------
0要求------->OTTnp+Tprの再直接の/ACK<。-------
OTTnp + Tpr + Request OTTpn + Tnr ------->
OTTnp+Tpr+要求OTTpn+Tnr------->。
OTTnp + OTTpn + Tpr + Tsr + Reply/ACK OTTns <-------
OTTnp+OTTpn+Tpr+Tsr+回答/ACK OTTns<。-------
OTTnp + OTTpn + OTTns + OTTsn + Tpr + Tsr + Delayed ACK TdA ------->
OTTnp+OTTpn+OTTns+OTTsn+Tpr+Tsr+遅れたACK TdA------->。
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Re-direct) OTTpn = One-way trip time (Re-direct to NAS) OTTns = One-way trip time (NAS to Server) OTTsn = One-way trip time (Server to NAS) TdA = Delayed ACK timer Tpr = Re-direct processing time Tnr = NAS re-direct processing time Tsr = Server request processing time
キー--- 片道旅行時間(NASへのサーバ)片道旅行時間(ServerへのNAS)片道旅行時間(NASに向け直す)片道旅行時間(ダイレクトにReへのNAS)片道OTT=Trip Time OTTnp=OTTpn=OTTns=OTTsn=TdA=は再直接のNAS処理時間Tsr=サーバ要求ACKタイマTpr=再直接の処理時間Tnr=処理時間を遅らせました。
B.3 Store and Forward Proxies
B.3はプロキシを格納して、進めます。
With a store and forward proxy, the proxy may send a reply to the NAS prior to forwarding the request to the server. While store and forward proxies are most frequently deployed for accounting [RFC2975], they also can be used to implement authentication/authorization policy, as described in [RFC2607].
要求をサーバに転送する前に、店と前進のプロキシと共に、プロキシはNASに返信するかもしれません。また、店と前進のプロキシが会計[RFC2975]で最も頻繁に配備されている間、認証/認可政策を実施するのに彼らを使用できます、[RFC2607]で説明されるように。
As noted in [RFC2975], store and forward proxies can have a negative effect on accounting reliability. By sending a reply to the NAS without receiving one from the accounting server, store and forward proxies fool the NAS into thinking that the accounting request had been accepted by the accounting server when this is not the case. As a result, the NAS can delete the accounting packet from non-volatile
[RFC2975]に述べられるように、店と前進のプロキシは会計の信頼性でマイナスの影響があることができます。 会計サーバからの1を受け取らないでNASに返信することによって、店と前進のプロキシはこれがそうでないときに、受け入れられた会計が会計サーバから要求する考えにNASをだまします。 その結果、NASは非揮発性から会計パケットを削除できます。
Aboba & Wood Standards Track [Page 36] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[36ページ]。
storage before it has been accepted by the accounting server. That leaves the proxy responsible for delivering accounting packets. If the proxy involves moving parts (e.g. a disk drive) while the NAS does not, overall system reliability can be reduced. As a result, store and forward proxies SHOULD NOT be used.
会計サーバはそれの前の格納を受け入れました。それはプロキシを会計パケットを届けるのに責任があった状態でおきます。 NASがかかわりませんが、プロキシが可動部(例えば、ディスクドライブ)にかかわるなら、総合体系の信頼性は減少できます。 結果、店、およびフォワードプロキシSHOULD NOTとして、使用されてください。
The sequence of events is as follows:
出来事の系列は以下の通りです:
Time NAS Proxy Server ------ --- ----- ------
時間NAS Proxyサーバ------ --- ----- ------
0 Request
------->
OTTnp + TpR Reply/ACK
<-------
0要求------->OTTnp+TpR回答/ACK<。-------
OTTnp + Tpr Request
------->
OTTnp+Tpr要求------->。
OTTnp + OTTph + Reply/ACK Tpr + Tsr <-------
OTTnp+OTTph+回答/ACK Tpr+Tsr<。-------
OTTnp + OTTph + Tpr + Tsr + Reply OTThp + TpR <-------
OTTnp+OTTph+Tpr+Tsr+回答OTThp+TpR<。-------
OTTnp + OTTph + Tpr + Tsr + Delayed ACK OTThp + TdA ------->
OTTnp+OTTph+Tpr+Tsr+遅れたACK OTThp+TdA------->。
OTTnp + OTTph + OTThp + OTTpn + Tpr + Tsr + Delayed ACK TpR + TdA ------->
OTTnp+OTTph+OTThp+OTTpn+Tpr+Tsr+遅れたACK TpR+TdA------->。
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Proxy) OTTpn = One-way trip time (Proxy to NAS) OTTph = One-way trip time (Proxy to Home server) OTThp = One-way trip time (Home Server to Proxy) TdA = Delayed ACK timer Tpr = Proxy request processing time TpR = Proxy reply processing time Tsr = Server request processing time
キー--- 片道旅行時間(ProxyへのホームServer)片道旅行時間(ホームサーバへのプロキシ)片道旅行時間(NASのプロキシ)片道旅行時間(ProxyへのNAS)片道OTT=Trip Time OTTnp=OTTpn=OTTph=OTThp=TdA=はACKタイマTpr=プロキシ要求処理時間TpR=プロキシ回答処理時間Tsr=サーバ要求処理時間を遅らせました。
Aboba & Wood Standards Track [Page 37] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[37ページ]。
B.4 Transport Layer Proxies
B.4トランスポート層プロキシ
In addition to acting as proxies at the application layer, transport layer proxies forward transport ACKs between the AAA client and server. This splices together the client-proxy and proxy-server connections into a single connection that behaves as though it operates end-to-end, exhibiting self-clocking. However, since transport proxies operate at the transport layer, they cannot be implemented purely as applications and they are rarely deployed.
アプリケーションにおけるプロキシが層にしながら行動することに加えて、トランスポート層プロキシはAAAのクライアントとサーバの間に輸送ACKsを送ります。まるで終わらせる端を操作するかのようにこれはクライアントプロキシとプロキシサーバ接続をそれが振る舞わせる単独結合に継ぎ合わせします、自己時計を示して。 しかしながら、輸送プロキシがトランスポート層で働いているので、アプリケーションとして純粋に彼らを実行できません、そして、それらはめったに配備されません。
With a transport proxy, the sequence of events is as follows:
輸送プロキシと共に、出来事の系列は以下の通りです:
Time NAS Proxy Home Server ------ --- ----- -----------
時間NASプロキシホームサーバ------ --- ----- -----------
0 Request
------->
OTTnp + Tpr Request
------->
0要求-------OTTnp+Tprが要求する>。------->。
OTTnp + OTTph + Reply/ACK Tpr + Tsr <-------
OTTnp+OTTph+回答/ACK Tpr+Tsr<。-------
OTTnp + OTTph + Tpr + Tsr + Reply/ACK OTThp + TpR <-------
OTTnp+OTTph+Tpr+Tsr+回答/ACK OTThp+TpR<。-------
OTTnp + OTTph + OTThp + OTTpn + Tpr + Tsr + Delayed ACK TpR + TdA ------->
OTTnp+OTTph+OTThp+OTTpn+Tpr+Tsr+遅れたACK TpR+TdA------->。
OTTnp + OTTph + OTThp + OTTpn + Tpr + Tsr + Delayed ACK TpR + TpD ------->
OTTnp+OTTph+OTThp+OTTpn+Tpr+Tsr+遅れたACK TpR+TpD------->。
Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Proxy) OTTpn = One-way trip time (Proxy to NAS) OTTph = One-way trip time (Proxy to Home server) OTThp = One-way trip time (Home Server to Proxy) TdA = Delayed ACK timer Tpr = Proxy request processing time TpR = Proxy reply processing time
キー--- 片道旅行時間(ProxyへのホームServer)片道旅行時間(ホームサーバへのプロキシ)片道旅行時間(NASのプロキシ)片道旅行時間(ProxyへのNAS)片道OTT=Trip Time OTTnp=OTTpn=OTTph=OTThp=TdA=はACKタイマTpr=プロキシ要求処理時間TpR=プロキシ回答処理時間を遅らせました。
Aboba & Wood Standards Track [Page 38] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[38ページ]。
Tsr = Server request processing time TpD = Proxy delayed ack processing time
Tsr=サーバ要求処理時間TpD=プロキシはack処理時間を遅らせました。
Intellectual Property Statement
知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
Acknowledgments
承認
Thanks to Allison Mankin of AT&T, Barney Wolff of Databus, Steve Rich of Cisco, Randy Bush of AT&T, Bo Landarv of IP Unplugged, Jari Arkko of Ericsson, and Pat Calhoun of Blackstorm Networks for fruitful discussions relating to AAA transport.
AAA輸送に関連する有意義な論議をAT&Tのアリソン・マンキン、Databusのバーニー・ヴォルフ、シスコのスティーブ・リッシュ、AT&Tのランディ・ブッシュ、IP UnpluggedのボーLandarv、エリクソンのヤリArkko、およびBlackstorm NetworksのパットCalhounをありがとうございます。
Aboba & Wood Standards Track [Page 39] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[39ページ]。
Authors' Addresses
作者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 425 706、6605Fax: +1 7329年の425 936メール: bernarda@microsoft.com
Jonathan Wood Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
ジョナサン・木製のサン・マイクロシステムズ・インク901サンアントニオRoadパロアルト、カリフォルニア 94303
EMail: jonwood@speakeasy.net
メール: jonwood@speakeasy.net
Aboba & Wood Standards Track [Page 40] RFC 3539 AAA Transport Profile June 2003
Abobaと木製の規格はAAA輸送プロフィール2003年6月にRFC3539を追跡します[40ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aboba & Wood Standards Track [Page 41]
Abobaと木製の標準化過程[41ページ]
一覧
スポンサーリンク
