[要約] RFC 4058は、PANA（ネットワークアクセスの認証を運ぶためのプロトコル）の要件に関するプロトコルです。その目的は、ネットワークアクセスの認証に関する要件を定義し、PANAプロトコルの開発と実装を促進することです。
Network Working Group A. Yegin, Ed.
Request for Comments: 4058 Samsung AIT
Category: Informational Y. Ohba
Toshiba
R. Penno
Juniper Networks
G. Tsirtsis
Flarion
C. Wang
ARO/NCSU
May 2005
Protocol for Carrying Authentication for Network Access (PANA) Requirements
ネットワークアクセス（PANA）要件のための認証を運ぶためのプロトコル
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure.
将来のIPデバイスには、ネットワーク接続を獲得するためのさまざまなアクセステクノロジーがあります。現在、認証と承認の目的でクライアント情報をネットワークに提供するためのアクセス固有のメカニズムがあります。特定のアクセスメディア（IEEE 802リンクの場合は802.1xなど）に制限されていることに加えて、これらのプロトコルの一部は特定のネットワークトポロジ（ポイントツーポイントリンクなどのPPPなど）に限定されています。このドキュメントの目標は、ホストとネットワークがネットワークアクセスのために互いに認証できるようにするリンク層の不可知論的プロトコルの要件を特定することです。このプロトコルは、クライアントのデバイスと、エージェントがAAAインフラストラクチャのクライアントになる可能性のあるネットワーク内のエージェントの間で実行されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Terminology .....................................................4
4. Requirements ....................................................4
4.1. Authentication .............................................4
4.1.1. Authentication of Client ............................4
4.1.2. Authorization, Accounting, and Access Control .......6
4.1.3. Authentication Backend ..............................7
4.1.4. Identifiers .........................................7
4.2. IP Address Assignment ......................................7
4.3. EAP Lower Layer Requirements ...............................7
4.4. PAA-to-EP Protocol .........................................8
4.5. Network ....................................................8
4.5.1. Multi-access ........................................8
4.5.2. Disconnect Indication ...............................8
4.5.3. Location of PAA .....................................9
4.5.4. Secure Channel ......................................9
4.6. Interaction with Other Protocols ..........................10
4.7. Performance ...............................................10
4.8. Congestion Control ........................................10
4.9. IP Version Independence ...................................10
4.10. Denial of Service Attacks ................................10
4.11. Client Identity Privacy ..................................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
A. Problem Statement ..............................................12
B. Usage Scenarios ................................................13
References ........................................................16
Normative References ...........................................16
Informative References .........................................16
Secure network access service requires access control based on the authentication and authorization of the clients and the access networks. Initial and subsequent client-to-network authentication provides parameters that are needed to police the traffic flow through the enforcement points. A protocol is needed to carry authentication parameters between the client and the access network. See Appendix A for the associated problem statement.
セキュアネットワークアクセスサービスには、クライアントとアクセスネットワークの認証と承認に基づいてアクセス制御が必要です。初期およびその後のクライアントからネットワークへの認証は、執行ポイントを通るトラフィックの流れを警察するために必要なパラメーターを提供します。クライアントとアクセスネットワークの間に認証パラメーターを運ぶには、プロトコルが必要です。関連する問題ステートメントについては、付録Aを参照してください。
The protocol design will be limited to defining a messaging protocol (i.e., a carrier) that will allow authentication payload to be carried between the host/client and an agent/server in the access network for authentication and authorization purposes regardless of the AAA infrastructure that may (or may not) reside on the network. As a network-layer protocol, it will be independent of the underlying access technologies and applicable to any network topology.
プロトコル設計は、AAAインフラストラクチャに関係なく、認証と承認の目的でアクセスネットワークで、ホスト/クライアントとエージェント/サーバーの間で認証ペイロードを運ぶことができるメッセージングプロトコル（つまり、キャリア）を定義することに限定されます。ネットワーク上に存在する可能性があります（またはそうでない場合があります）。ネットワーク層プロトコルとして、それは基礎となるアクセステクノロジーとは独立しており、あらゆるネットワークトポロジに適用されます。
The intent is not to invent new security protocols and mechanisms but to reuse existing mechanisms such as EAP [RFC3748]. In particular, the requirements do not mandate the need to define new authentication protocols (e.g., EAP-TLS [RFC2716]), key distribution or key agreement protocols, or key derivation methods. The desired protocol can be viewed as the front-end of the AAA protocol or any other protocol/mechanisms the network is running at the background to authenticate its clients. It will act as a carrier for an already defined security protocol or mechanism.
意図は、新しいセキュリティプロトコルとメカニズムを発明することではなく、EAP [RFC3748]などの既存のメカニズムを再利用することです。特に、要件は、新しい認証プロトコル（例：EAP-TLS [RFC2716]）、キーディストリビューションまたはキー契約プロトコル、またはキー派生方法を定義する必要性を義務付けていません。目的のプロトコルは、AAAプロトコルのフロントエンドまたはその他のプロトコル/メカニズムのフロントエンドとして見ることができます。すでに定義されているセキュリティプロトコルまたはメカニズムのキャリアとして機能します。
An example of a protocol being extended for use in authenticating a host for network access is Mobile IPv4. A Mobile IPv4 registration request message is used as a carrier for authentication extensions (MN-FA [RFC3344] or MN-AAA [RFC3012]) that allows a foreign agent to authenticate mobile nodes before providing forwarding service. The goal of PANA is similar in that it aims to define a network-layer transport for authentication information. However, PANA will be decoupled from mobility management and will rely on other specifications for the definition of authentication payloads.
ネットワークアクセスのホストを認証するために使用するために拡張されているプロトコルの例は、モバイルIPv4です。モバイルIPv4登録要求メッセージは、認証拡張機能（MN-FA [RFC3344]またはMN-AAA [RFC3012]）のキャリアとして使用されます。パナの目標は、認証情報のネットワーク層輸送を定義することを目的とするという点で似ています。ただし、パナはモビリティ管理から切り離され、認証ペイロードの定義のために他の仕様に依存します。
This document defines common terminology and identifies requirements of a protocol for PANA that will be used to define and limit the scope of the work to be done in this group.
このドキュメントは、一般的な用語を定義し、このグループで行われる作業の範囲を定義および制限するために使用されるパナのプロトコルの要件を特定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
PANA Client (PaC)
パナクライアント（PAC）
The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization.
ネットワークアクセス認証のためのアイデンティティを証明する資格情報を提供する責任があるホストデバイスにあるプロトコルのクライアント側。
PANA Client Identifier (PaCI)
パナクライアント識別子（PACI）
The identifier that is presented by the PaC to the PAA for network access authentication. A simple username and NAI [RFC2794] are examples of PANA client identifiers.
ネットワークアクセス認証のためにPACによってPAAに提示される識別子。単純なユーザー名とNAI [RFC2794]は、PANAクライアント識別子の例です。
Device Identifier (DI)
デバイス識別子（di）
The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, this identifier might contain an IP address, a link-layer address, or a switch port number, etc. of a connected device.
ネットワークで使用される識別子は、クライアントのネットワークアクセスを制御および警察するためのハンドルとして使用します。アクセステクノロジーに応じて、この識別子には、接続されたデバイスのIPアドレス、リンク層アドレス、またはスイッチポート番号などが含まれる場合があります。
PANA Authentication Agent (PAA)
パナ認証エージェント（PAA）
The access network side entity of the protocol whose responsibility is to verify the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI.
PANAクライアントが提供する資格情報を検証し、クライアントに関連付けられ、DIによって識別されたデバイスにネットワークアクセスサービスを付与する責任があるプロトコルのアクセスネットワーク側のエンティティ。
Enforcement Point (EP)
執行ポイント（EP）
A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of client devices. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP.
パケットごとの施行ポリシー（つまり、フィルター）がクライアントデバイスのインバウンドトラフィックとアウトバウンドトラフィックに適用されるアクセスネットワーク上のノード。DIや（オプションで）暗号化キーなどの情報は、EPにフィルターを構築するためにクライアントごとにPAAによって提供されます。
PANA MUST enable authentication of PaCs for network access. A PaC's identity can be authenticated by verifying the credentials (e.g., identifier, authenticator) supplied by one of the users of the device or the device itself. PANA MUST only grant network access service to the device identified by the DI, rather than separate access to multiple simultaneous users of the device. Once network access is granted to the device, methods used by the device on arbitrating which user can access the network is outside the scope of PANA.
パナは、ネットワークアクセスのためにPACの認証を有効にする必要があります。PACのIDは、デバイスのユーザーの1人またはデバイス自体が提供する資格情報（識別子、認証機など）を確認することにより、認証できます。PANAは、デバイスの複数の同時ユーザーへの個別のアクセスではなく、DIによって識別されたデバイスにネットワークアクセスサービスを付与する必要があります。ネットワークアクセスがデバイスに付与されると、どのユーザーがネットワークにアクセスできるかを仲裁する際にデバイスが使用する方法は、パナの範囲外にあります。
PANA MUST NOT define new security protocols or mechanisms. Instead, it MUST be defined as a "carrier" for such protocols. PANA MUST identify which specific security protocol(s) or mechanism(s) it can carry (the "payload"). EAP is a candidate protocol that satisfies many requirements for authentication. PANA would be a carrier protocol for EAP. If the PANA Working Group decides that extensions to EAP are needed, it will define requirements for the EAP WG instead of designing such extensions.
パナは、新しいセキュリティプロトコルまたはメカニズムを定義してはなりません。代わりに、そのようなプロトコルの「キャリア」として定義する必要があります。PANAは、どの特定のセキュリティプロトコルまたはそれが運ぶことができるか（「ペイロード」）を特定する必要があります。EAPは、認証のための多くの要件を満たす候補プロトコルです。パナは、EAPのキャリアプロトコルになります。PanaワーキンググループがEAPへの拡張機能が必要であると判断した場合、このような拡張機能を設計する代わりにEAP WGの要件を定義します。
Providing authentication, integrity and replay protection for data traffic after a successful PANA exchange is outside the scope of this protocol. In networks where physical layer security is not present, link-layer or network-layer ciphering (e.g., IPsec) can be used to provide such security. These mechanisms require the presence of cryptographic keying material at PaC and EP. Although PANA does not deal with key derivation or distribution, it enables this by carrying EAP and allowing appropriate EAP method selection. Various EAP methods are capable of generating basic keying material that cannot be directly used with IPsec because it lacks the properties of an IPsec SA (security association) including secure cipher suite negotiation, mutual proof of possession of keying material, freshness of transient session keys, key naming, etc. These basic (initial) EAP keys can be used with an IPsec key management protocol, like IKE, to generate the required security associations. A separate protocol, called secure association protocol, is required to generate IPsec SAs based on the basic EAP keys. This protocol MUST be capable of enabling IPsec-based access control on the EPs. IPsec SAs MUST enable authentication, integrity and replay protection of data packets as they are sent between the EP and PaC.
パナ交換が成功した後、データトラフィックの認証、整合性、リプレイ保護を提供することは、このプロトコルの範囲外です。物理層のセキュリティが存在しないネットワークでは、リンク層またはネットワーク層の暗号化（IPSECなど）を使用して、そのようなセキュリティを提供できます。これらのメカニズムには、PACおよびEPに暗号化キーイング材料が存在する必要があります。Panaは重要な派生または分布を扱っていませんが、EAPを運び、適切なEAPメソッド選択を許可することでこれを有効にします。さまざまなEAPメソッドは、安全な暗号スイートの交渉、キーイング素材の相互証明、一時的なセッションキーの新鮮さの相互証明を含むIPSEC SA（セキュリティ協会）の特性を欠いているため、IPSECで直接使用できない基本的なキーイン材料を生成できます。キーネーミングなど。これらの基本的な（初期）EAPキーは、IKESのIKEなどのIPSECキー管理プロトコルで使用して、必要なセキュリティ関連を生成できます。Secure Associationプロトコルと呼ばれる別のプロトコルは、基本的なEAPキーに基づいてIPSEC SASを生成するために必要です。このプロトコルは、EPSでのIPSECベースのアクセス制御を有効にすることができなければなりません。IPSEC SASは、EPとPACの間に送信されるデータパケットの認証、整合性、およびリプレイ保護を有効にする必要があります。
Providing a complete secure network access solution by securing router discovery [RFC1256], neighbor discovery [RFC2461], and address resolution protocols [RFC826] is outside the scope as well.
ルーター発見[RFC1256]、隣接発見[RFC2461]、およびアドレス解像度プロトコル[RFC826]を保護することにより、完全なセキュアネットワークアクセスソリューションを提供することも、範囲外です。
Some access networks might require or allow their clients to get authenticated and authorized by the network access provider (NAP) and ISP before the clients gain network access. NAP is the owner of the access network who provides physical and link-layer connectivity to the clients. PANA MUST be capable of enabling two independent authentication operations (i.e., execution of two separate EAP methods) for the same client. Determining the authorization parameters as a result of two separate authentications is an operational issue and therefore outside the scope of PANA.
一部のアクセスネットワークでは、クライアントがネットワークアクセスを取得する前に、クライアントがネットワークアクセスプロバイダー（NAP）とISPによって認証および承認を受けることを要求または許可する場合があります。NAPは、クライアントに物理的およびリンク層の接続性を提供するアクセスネットワークの所有者です。PANAは、同じクライアントに対して2つの独立した認証操作（つまり、2つの個別のEAPメソッドの実行）を有効にすることができなければなりません。2つの個別の認証の結果としての認証パラメーターを決定することは、運用上の問題であり、したがってパナの範囲外です。
Both the PaC and the PAA MUST be able to perform mutual authentication for network access. Providing only the capability of a PAA authenticating the PaC is not sufficient. Mutual authentication capability is required in some environments but not in all of them. For example, clients might not need to authenticate the access network when physical security is available (e.g., dial-up networks).
PACとPAAの両方が、ネットワークアクセスのために相互認証を実行できる必要があります。PACを認証するPAAの機能のみを提供するだけでは十分ではありません。一部の環境では相互認証機能が必要ですが、すべての環境では必要ありません。たとえば、クライアントは物理セキュリティが利用可能になったときにアクセスネットワークを認証する必要がない場合があります（たとえば、ダイヤルアップネットワークなど）。
PANA MUST be capable of carrying out both periodic and on-demand re-authentication. Both the PaC and the PAA MUST be able to initiate both the initial authentication and the re-authentication process.
パナは、周期的およびオンデマンドの両方の再認証を実行できる必要があります。PACとPAAの両方が、初期認証と再認証プロセスの両方を開始できる必要があります。
Certain types of service theft are possible when the DI is not protected during or after the PANA exchange [RFC4016]. PANA MUST have the capability to exchange DI securely between the PaC and PAA where the network is vulnerable to man-in-the-middle attacks. While PANA MUST provide such a capability, its utility relies on the use of an authentication method that can generate keys for cryptographic computations on PaC and PAA.
特定の種類のサービス盗難は、PANA交換中または後にDIが保護されていない場合に可能です[RFC4016]。パナには、ネットワークが中間の攻撃に対して脆弱なPACとPAAの間で安全にDIを交換する能力が必要です。PANAはそのような機能を提供する必要がありますが、そのユーティリティは、PACおよびPAAで暗号化計算のキーを生成できる認証方法の使用に依存しています。
After a device is authenticated by using PANA, it MUST be authorized for "network access." That is, the core requirement of PANA is to verify the authorization of a PaC so that PaC's device may send and receive any IP packets. It may also be possible to provide finer granularity authorization, such as authorization for QoS or individual services (e.g., http vs. ssh). However, while a backend authorization infrastructure (e.g., RADIUS or Diameter based AAA infra) might provide such indications to the PAA, explicit support for them is outside the scope of PANA. For instance, PANA is not required to carry any indication of the services authorized for the authenticated device.
パナを使用してデバイスが認証された後、「ネットワークアクセス」を許可する必要があります。つまり、PANAのコア要件は、PACのデバイスがIPパケットを送信および受信できるように、PACの承認を検証することです。また、QoSや個々のサービスの承認（HTTP対SSHなど）など、より細かい粒度認証を提供することも可能かもしれません。ただし、バックエンド認証インフラストラクチャ（たとえば、半径または直径ベースのAAAインフラ）はPAAにそのような兆候を提供する可能性がありますが、それらの明示的なサポートはパナの範囲外です。たとえば、PANAは、認証されたデバイスに対して許可されたサービスの兆候を把握する必要はありません。
Providing access control functionality in the network is outside the scope of PANA. Client access authentication SHOULD be followed by access control to make sure only authenticated and authorized clients can send and receive IP packets via the access network. Access control can involve setting access control lists on the EPs. PANA protocol exchange identifies clients that are authorized to access the network. If IPsec-based access control is deployed in an access network, PaC and EPs should have the required IPsec SA in place. Generating the IPsec SAs based on EAP keys is outside the scope of PANA protocol. This transformation MUST be handled by a separate secure association protocol (see section 4.1.1).
ネットワーク内のアクセス制御機能を提供することは、パナの範囲外です。クライアントアクセス認証の後にアクセス制御が続いて、アクセスネットワークを介してIPパケットを送信および受信できることを確認し、認証されたクライアントのみを確認する必要があります。アクセス制御には、EPSにアクセス制御リストの設定が含まれます。Pana Protocol Exchangeは、ネットワークへのアクセスを許可されたクライアントを識別します。IPSECベースのアクセス制御がアクセスネットワークに展開されている場合、PACとEPSには必要なIPSEC SAが配置されている必要があります。EAPキーに基づいてIPSEC SASを生成することは、パナプロトコルの範囲外です。この変換は、個別の安全な関連プロトコルによって処理する必要があります（セクション4.1.1を参照）。
Carrying accounting data is outside the scope of PANA.
会計データのキャリングは、パナの範囲外です。
PANA protocol MUST NOT make any assumptions on the backend authentication protocol or mechanisms. A PAA MAY interact with backend AAA infrastructures such as RADIUS or Diameter, but it is not a requirement. When the access network does not rely on an IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use a proprietary backend system, or rely on the information locally stored on the authentication agents.
Panaプロトコルは、バックエンド認証プロトコルまたはメカニズムについて仮定を立ててはなりません。PAAは、半径や直径などのバックエンドAAAインフラストラクチャと相互作用する場合がありますが、要件ではありません。AccessネットワークがIETF定義のAAAプロトコル（半径、直径など）に依存していない場合でも、独自のバックエンドシステムを使用するか、認証エージェントにローカルに保存されている情報に依存します。
The interaction between the PAA and the backend authentication entities is outside the scope of PANA.
PAAとバックエンド認証エンティティ間の相互作用は、パナの範囲外です。
PANA SHOULD allow various types of identifiers to be used as the PaCI (e.g., username, Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), etc.). This requirement generally relies on the client identifiers supported by various EAP methods.
PANAは、さまざまなタイプの識別子をPACI（例：ユーザー名、ネットワークアクセス識別子（NAI）、完全資格のドメイン名（FQDN）など）として使用できるようにする必要があります。この要件は、一般に、さまざまなEAPメソッドでサポートされているクライアント識別子に依存しています。
PANA SHOULD allow various types of identifiers to be used as the DI (e.g., IP address, link-layer address, port number of a switch, etc.).
パナは、さまざまなタイプの識別子をDI（例：IPアドレス、リンク層アドレス、スイッチのポート番号など）として使用できるようにする必要があります。
A PAA MUST be able to create a binding between the PaCI and the associated DI upon successful PANA exchange. This can be achieved by PANA communicating the PaCI and DI to the PAA during the protocol exchange. The DI can be carried either explicitly as part of the PANA payload, or implicitly as the source of the PANA message, or both. Multi-access networks also require use of a cryptographic protection along with DI filtering to prevent unauthorized access [RFC4016]. The keying material required by the cryptographic methods needs to be indexed by the DI. As described in section 4.1.2, the binding between DI and PaCI is used for access control and accounting in the network.
PAAは、成功したパナ交換時にパシと関連するDIの間に結合を作成できる必要があります。これは、プロトコル交換中にPACIとDIをPAAに伝えるパナによって実現できます。DIは、パナペイロードの一部として明示的に、またはパナメッセージのソースとして暗黙的に運ぶことができます。マルチアクセスネットワークは、不正アクセスを防ぐために、DIフィルターとともに暗号化保護を使用する必要があります[RFC4016]。暗号化方法に必要なキーイング材料は、DIによってインデックス作成する必要があります。セクション4.1.2で説明されているように、DIとPACIの間のバインディングは、ネットワーク内のアクセス制御と会計に使用されます。
Assigning an IP address to the client is outside the scope of PANA. PaC MUST configure an IP address before running PANA.
クライアントにIPアドレスを割り当てることは、パナの範囲外です。PACは、パナを実行する前にIPアドレスを構成する必要があります。
The EAP protocol imposes various requirements on its transport protocols that are based on the nature of the EAP protocol, and need to be satisfied for correct operation. Please see [RFC3748] for the generic transport requirements that MUST be satisfied by PANA.
EAPプロトコルは、EAPプロトコルの性質に基づいた輸送プロトコルにさまざまな要件を課し、正しい動作のために満たす必要があります。パナが満たさなければならない一般的な輸送要件については、[RFC3748]を参照してください。
PANA does not assume that the PAA is always co-located with the EP(s). Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., gateway to the Internet, depending on the network architecture). When the PAA and the EP(s) are separated, another transport for client provisioning is necessary. This transport is needed to create access control lists in order to allow authenticated and authorized clients' traffic through the EPs. PANA Working Group will preferably identify an existing protocol solution that allows the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. Possible candidates include, but are not limited to COPS, SNMP, Diameter, etc.
Panaは、PAAが常にEP（S）と共同で協力されているとは想定していません。ネットワークアクセスの施行は、クライアントと同じIPサブネット（複数のルーターなど）と同じIPサブネット、またはアクセスドメインの別のサブネット（たとえば、ネットワークアーキテクチャに応じてインターネットへのゲートウェイ）で提供できます。PAAとEPが分離されている場合、クライアントプロビジョニング用の別のトランスポートが必要です。このトランスポートは、EPSを介した認証され、認定されたクライアントのトラフィックを許可するために、アクセス制御リストを作成するために必要です。PANAワーキンググループは、PAAがPAAがEPSから分離されている場合、PAAが1つ以上のEPSに承認情報を配信できるようにする既存のプロトコルソリューションを識別することが好ましいでしょう。可能な候補者には、警官、SNMP、直径などが含まれますが、これらに限定されません。
The communication between PAA and EP(s) MUST be secure. The objective of using a PAA-to-EP protocol is to provide filtering rules to EP(s) for allowing network access of a recently authenticated and authorized PaC. The chosen protocol MUST be capable of carrying DI and cryptographic keys for a given PaC from PAA to EP. Depending on the PANA protocol design, support for either of the pull model (i.e., EP initiating the PAA-to-EP protocol exchange per PaC) or the push model (i.e., PAA initiating the PAA-to-EP protocol exchange per PaC), or both may be required. For example, if the design is such that the EP allows the PANA traffic to pass through even for unauthenticated PaCs, the EP should also allow and expect the PAA to send the filtering information at the end of a successful PANA exchange without the EP ever sending a request.
PAAとEPの間の通信は安全でなければなりません。PAA-to-EPプロトコルを使用する目的は、最近認証された認証されたPACのネットワークアクセスを許可するために、EPにフィルタリングルールを提供することです。選択したプロトコルは、PAAからEPまでの特定のPACのDIおよび暗号キーを運ぶことができなければなりません。PANAプロトコルの設計に応じて、プルモデルのいずれか（つまり、PACあたりのPAAからEPプロトコル交換を開始するEP）またはプッシュモデル（つまり、PACごとのPAAからEPプロトコル交換を開始するPAA）のサポート）、または両方が必要になる場合があります。たとえば、EPがPANAトラフィックが認知度のないPACでも通過できるように設計がある場合、EPはEPがEPが送信せずにパナエクスチェンジの成功した最後にフィルタリング情報を送信できるようにする必要があり、期待する必要があります。リクエスト。
PANA MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links. In other words, PANA MUST NOT assume that the PaC has only one network interface, that the access network has only one first hop router, or that the PaC is using a point-to-point link.
PANAは、複数のインターフェイスを備えたPACをサポートする必要があり、マルチアクセスリンク上の複数のルーターを備えたネットワークが必要です。言い換えれば、PANAは、PACに1つのネットワークインターフェイスしかないこと、アクセスネットワークに最初のホップルーターが1つしかないこと、またはPACがポイントツーポイントリンクを使用していると想定してはなりません。
PANA MUST NOT assume that the link is connection-oriented. Links may or may not provide disconnect indication. Such notification is desirable in order for the PAA to clean up resources when a client moves away from the network (e.g., inform the enforcement points that the client is no longer connected). PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST be capable of securing disconnect messages in order to prevent malicious nodes from leveraging this extension for DoS attacks.
パナは、リンクが接続指向であると想定してはなりません。リンクは、切断された兆候を提供する場合と提供しない場合があります。このような通知は、クライアントがネットワークから離れたときにPAAがリソースをクリーンアップするために望ましいです（たとえば、クライアントが接続されなくなったことを執行ポイントに通知します）。パナには、切断された兆候を提供するメカニズムが必要です。PANAは、悪意のあるノードがDOS攻撃のこの拡張機能を活用するのを防ぐために、メッセージを切断することを保護できる必要があります。
This mechanism MUST allow the PAA to be notified about the departure of a PaC from the network. This mechanism MUST also allow a PaC to be notified about the discontinuation of the network access service. Access discontinuation can occur due to various reasons such as network systems going down or a change in the access policy.
このメカニズムは、ネットワークからのPACの出発についてPAAに通知できるようにする必要があります。このメカニズムは、ネットワークアクセスサービスの中止についてPACに通知することもできなければなりません。アクセスの中止は、ネットワークシステムがダウンしたり、アクセスポリシーの変更などのさまざまな理由により発生する可能性があります。
In case the clients cannot send explicit disconnect messages to the PAA, it can still detect their departure by relying on periodic authentication requests.
クライアントが明示的な切断メッセージをPAAに送信できない場合、定期的な認証要求に依存して出発を検出できます。
The PAA and PaC MUST be exactly one IP hop away from each other. That is, there must be no IP routers between the two. Note that this does not mean they are on the same physical link. Bridging and tunneling (e.g., IP-in-IP, GRE, L2TP, etc.) techniques can place two nodes just exactly one IP hop away from each other although they might be connected to separate physical links. A PAA can be on the network access server (NAS) or WLAN access point or first hop router. The use of PANA when the PAA is multiple IP hops away from the PaC is outside the scope of PANA.
PAAとPACは、ちょうど1つのIPホップである必要があります。つまり、2つの間にIPルーターがないはずです。これは、それらが同じ物理的リンクにいるという意味ではないことに注意してください。ブリッジングとトンネリング（例：IP-in-IP、GRE、L2TPなど）テクニックは、個別の物理リンクに接続されている可能性がありますが、2つのIPホップを互いに1つずつ離すことができます。PAAは、ネットワークアクセスサーバー（NAS）またはWLANアクセスポイントまたはファーストホップルーターにあります。PAAがPACから離れた複数のIPホップであるときのパナの使用は、パナの範囲外です。
A PaC may or may not be pre-configured with the IP address of PAA. Therefore the PANA protocol MUST define a dynamic discovery method. Given that the PAA is one hop away from the PaC, there are a number of discovery techniques that could be used (e.g., multicast or anycast) by the PaC to find out the address of the PAA.
PACは、PAAのIPアドレスと事前に構成されている場合とそうでない場合があります。したがって、PANAプロトコルは動的発見方法を定義する必要があります。PAAがPACから1ホップ離れていることを考えると、PACがPACが使用するために使用できる多くの発見技術（マルチキャストやaycastなど）があります。
PANA MUST NOT assume the presence of a secure channel between the PaC and the PAA. PANA MUST be able to provide authentication especially in networks which are not protected against eavesdropping and spoofing. PANA MUST enable protection against replay attacks on both PaCs and PAAs.
パナは、PACとPAAの間に安全なチャネルの存在を想定してはなりません。パナは、特に盗聴やスプーフィングから保護されていないネットワークで認証を提供できる必要があります。パナは、PACとPAASの両方でのリプレイ攻撃に対する保護を可能にする必要があります。
This requirement partially relies on the EAP protocol and the EAP methods carried over PANA. Use of EAP methods that provide mutual authentication and key derivation/distribution is essential for satisfying this requirement. EAP does not make a secure channel assumption, and supports various authentication methods that can be used in such environments. Additionally, PANA MUST ensure that its design does not contain vulnerabilities that can be exploited when it is used over insecure channels. PANA MAY provide a secure channel by deploying a two-phase authentication. The first phase can be used for creation of the secure channel, and the second phase for client and network authentication.
この要件は、部分的にEAPプロトコルに依存しており、EAPメソッドはパナを介して伝達されます。この要件を満たすためには、相互認証と主要な派生/分布を提供するEAPメソッドの使用が不可欠です。EAPは、安全なチャネルの仮定を行うことはなく、そのような環境で使用できるさまざまな認証方法をサポートしています。さらに、Panaは、その設計に、安全でないチャネルよりも使用されているときに悪用される可能性のある脆弱性を備えていないことを確認する必要があります。Panaは、2フェーズ認証を展開することにより、安全なチャネルを提供する場合があります。第1フェーズは、安全なチャネルの作成に使用でき、クライアントとネットワーク認証の第2フェーズを使用できます。
Mobility management is outside the scope of PANA. However, PANA MUST be able to co-exist and MUST NOT unintentionally interfere with various mobility management protocols, such as Mobile IPv4 [RFC3344], Mobile IPv6 [RFC3775], fast handover protocols [FMIPv6] [FMIPv4], and other standard protocols like IPv6 stateless address auto-configuration [RFC2461] (including privacy extensions [RFC3041]), and DHCP [RFC2131] [RFC3315]. PANA MUST NOT make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC.
モビリティ管理は、パナの範囲外です。ただし、PANAは共存できる必要があり、モバイルIPv4 [RFC3344]、モバイルIPv6 [RFC3775]、高速ハンドオーバープロトコル[FMIPV6] [FMIPV4]、およびその他の標準プロトコルなど、さまざまなモビリティ管理プロトコルを意図せずに干渉してはなりません。IPv6ステートレスアドレスAuto-configuration [RFC2461]（プライバシー拡張[RFC3041]を含む）、およびDHCP [RFC2131] [RFC3315]。PANAは、PACのIPアドレス構成に使用されるプロトコルまたはメカニズムについて仮定を立ててはなりません。
PANA design SHOULD efficiently handle the authentication process in order to gain network access with minimum latency. For example, it may minimize the protocol signaling by creating local security associations.
パナの設計では、最小レイテンシでネットワークアクセスを獲得するために、認証プロセスを効率的に処理する必要があります。たとえば、ローカルセキュリティ協会を作成することにより、プロトコルシグナル伝達を最小限に抑えることができます。
PANA MUST provide congestion control for the protocol messaging. Under certain conditions PaCs might unintentionally get synchronized when sending their requests to the PAA (e.g., upon recovering from a power outage on the access network). The network congestion generated from such events can be avoided by using techniques like delayed initialization and exponential back off.
パナは、プロトコルメッセージングに渋滞制御を提供する必要があります。特定の条件下では、PACはPAAにリクエストを送信するときに意図せずに同期する可能性があります（たとえば、アクセスネットワークの停電から回復したとき）。このようなイベントから生成されたネットワークのうっ血は、遅延した初期化や指数のバックオフなどの手法を使用することで回避できます。
PANA MUST work with both IPv4 and IPv6.
PANAは、IPv4とIPv6の両方で動作する必要があります。
PANA MUST be robust against a class of DoS attacks such as blind masquerade attacks through IP spoofing. These attacks would swamp the PAA, causing it to spend resources and prevent network access by legitimate clients.
パナは、IPスプーフィングによるブラインドマスカレード攻撃などのDOS攻撃のクラスに対して堅牢でなければなりません。これらの攻撃はPAAを圧倒し、リソースを費やし、合法的なクライアントによるネットワークアクセスを防ぎます。
Some clients might prefer hiding their identity from visited access networks for privacy reasons. Providing identity protection for clients is outside the scope of PANA. Note that some authentication methods may already have this capability. Where necessary, identity protection can be achieved by letting PANA carry such authentication methods.
一部のクライアントは、プライバシー上の理由で訪問されたアクセスネットワークから身元を隠すことを好む場合があります。クライアントにID保護を提供することは、パナの範囲外です。一部の認証方法にはすでにこの機能がある場合があることに注意してください。必要に応じて、パナにそのような認証方法を伝えることにより、アイデンティティ保護を実現できます。
This document identifies requirements for the PANA protocol design. Due to the nature of this protocol, most of the requirements are security related. The actual protocol design is not specified in this document. A thorough discussion on PANA security threats can be found in PANA Threat Analysis and Security Requirements [RFC4016]. Security threats identified in that document are already included in this general PANA requirements document.
このドキュメントは、パナプロトコル設計の要件を識別します。このプロトコルの性質により、要件のほとんどはセキュリティに関連しています。実際のプロトコル設計は、このドキュメントでは指定されていません。パナのセキュリティの脅威に関する徹底的な議論は、パナの脅威分析とセキュリティ要件に記載されています[RFC4016]。その文書で特定されたセキュリティの脅威は、この一般的なPANA要件文書に既に含まれています。
Authors would like to thank Bernard Aboba, Derek Atkins, Steven Bellovin, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy, Basavaraj Patil, Hesham Soliman, and the PANA Working Group members for their valuable contributions to the discussions and preparation of this document.
著者は、バーナード・アボバ、デレク・アトキンス、スティーブン・ベロヴィン、ジュリエン・ボーンレル、サブ・ダス、フランシス・デュポン、ダン・フォースバーグ、ピート・マッキャン、ライオネル・モランド、トーマス・ナルテン、モハン・パルタサラシー、バサヴァラジ・パティル、ヘシャム・ソリマン・ワーキング・メンバーに感謝します。この文書の議論と準備への貴重な貢献のため。
Access networks in most cases require some form of authentication in order to prevent unauthorized usage. In the absence of physical security (and sometimes in addition to it) a higher layer (L2+) access authentication mechanism is needed. Depending on the deployment scenarios, a number of features are expected from the authentication mechanism. For example, support for various authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming, network service provider discovery and selection, separate authentication for access (L1+L2) service provider and ISP (L3), etc. In the absence of a link-layer authentication mechanism that can satisfy these needs, operators are forced to either use non-standard ad-hoc solutions at layers above the link, insert additional shim layers for authentication, or misuse some of the existing protocols in ways that were not intended by design. PANA will be developed to fill this gap by defining a standard network-layer access authentication protocol. As a network-layer access authentication protocol, PANA can be used over any link-layer that supports IP.
ほとんどの場合、アクセスネットワークは、不正使用を防ぐために何らかの形の認証を必要とします。物理的なセキュリティがない場合（およびそれに加えて）、より高い層（L2）アクセス認証メカニズムが必要です。展開シナリオに応じて、認証メカニズムから多くの機能が予想されます。たとえば、さまざまな認証方法（MD5、TLS、SIMなど）、ネットワークローミング、ネットワークサービスプロバイダーの発見と選択、アクセス用の個別認証（L1 L2）サービスプロバイダーとISP（L3）などのサポート。これらのニーズを満たすことができるリンク層認証メカニズムの欠如、オペレーターは、リンクの上のレイヤーで非標準アドホックソリューションを使用するか、認証のために追加のシム層を挿入するか、既存のプロトコルの一部を方法で誤用することを余儀なくされます。それは設計によって意図されていませんでした。パナは、標準のネットワーク層アクセス認証プロトコルを定義することにより、このギャップを埋めるために開発されます。ネットワーク層アクセス認証プロトコルとして、PANAはIPをサポートする任意のリンク層で使用できます。
DSL networks are a specific example where PANA has the potential for addressing some of the deployment scenarios. Some DSL deployments do not use PPP [RFC1661] as the access link-layer (IP is carried over ATM and the subscriber device is either statically or DHCP-configured). The operators of these networks are left either using an application-layer web-based login (captive portal) scheme for subscriber authentication, or providing a best-effort service only as they cannot perform subscriber authentication required for the differentiated services. The captive portal scheme is a non-standard solution that has various limitations and security flaws.
DSLネットワークは、パナが展開シナリオの一部に対処する可能性がある特定の例です。一部のDSL展開では、アクセスリンクレイヤー（IPがATMに携帯され、サブスクライバーデバイスが静的またはDHCP構成のいずれかであるため、PPP [RFC1661]を使用しません。これらのネットワークのオペレーターは、サブスクライバー認証のためのアプリケーションレイヤーWebベースのログイン（Captive Portal）スキームを使用して、または差別化されたサービスに必要なサブスクライバー認証を実行できないためにのみ最高のエフォルトサービスを提供するかのいずれかです。キャプティブポータルスキームは、さまざまな制限とセキュリティの欠陥を持つ非標準ソリューションです。
PPP-based authentication can provide some of the required functionality. But using PPP only for authentication is not a good choice, as it incurs additional messaging during the connection setup and extra per-packet processing. It also forces the network topology to a point-to-point model. Aside from resistance to incorporating PPP into an architecture unless it is absolutely necessary, there is even interest in the community in removing PPP from some of the existing architectures and deployments (e.g., 3GPP2, DSL).
PPPベースの認証は、必要な機能の一部を提供できます。ただし、PPPを使用するためにのみPPPを使用することは、接続セットアップ中および追加のパケットごとの処理中に追加のメッセージングが発生するため、適切な選択ではありません。また、ネットワークトポロジをポイントツーポイントモデルに強制します。絶対に必要でない限り、PPPをアーキテクチャに組み込むことに対する抵抗は別として、既存のアーキテクチャと展開（3GPP2、DSLなど）からPPPを削除することにコミュニティに興味さえあります。
Using Mobile IPv4 authentication with a foreign agent instead of proper network access authentication is an example of protocol misuse. The Registration Required flag allows a foreign agent to force authentication even when the agent is not involved in any Mobile IPv4 signalling (co-located care-of address case). This enables the use of a mobility-specific protocol for an unrelated functionality.
適切なネットワークアクセス認証の代わりに、外国エージェントでモバイルIPv4認証を使用することは、プロトコルの誤用の例です。登録に必要なフラグにより、外国人エージェントは、エージェントがモバイルIPv4シグナル伝達（共同配置された住所ケース）に関与していない場合でも、認証を強制できます。これにより、無関係な機能にモビリティ固有のプロトコルを使用できます。
PANA will carry EAP above IP in order to enable any authentication method on any link-layer. EAP can already be carried by [IEEE-802.1X] and PPP. IEEE 802.1X can only be used on unbridged IEEE 802 links, hence it only applies to limited link types. Inserting PPP between IP and a link-layer can be perceived as a way to enable EAP over that particular link-layer, but using PPP for this reason has the aforementioned drawbacks and is not a good choice. While IEEE 802.1X and PPP can continue to be used in their own domains, they do not take away the need to have a protocol like PANA.
PANAは、リンク層の認証方法を有効にするために、EAP上記のIPを運びます。EAPは、[IEEE-802.1x]およびPPPによって既に運ばれます。IEEE 802.1xは、架橋IEEE 802リンクでのみ使用できます。したがって、限られたリンクタイプにのみ適用されます。IPとリンク層の間にPPPを挿入することは、その特定のリンク層上でEAPを有効にする方法として認識できますが、この理由でPPPを使用することは前述の欠点を持ち、良い選択ではありません。IEEE 802.1xとPPPは引き続き独自のドメインで使用できますが、Panaのようなプロトコルを持つ必要性を奪いません。
PANA will be applicable to various types of networks. Based on the presence of lower-layer security prior to running PANA, the following types cover all possibilities:
パナは、さまざまな種類のネットワークに適用できます。パナを実行する前の低層セキュリティの存在に基づいて、次のタイプはすべての可能性をカバーしています。
a) Physically secured networks (e.g., DSL networks). Although data traffic is always carried over a physically secured link, the client might need to be authenticated and authorized when accessing the IP services.
a) 物理的に保護されたネットワーク（例：DSLネットワーク）。データトラフィックは常に物理的にセキュリティで保護されているリンクを継続していますが、IPサービスにアクセスするときにクライアントを認証および承認する必要がある場合があります。
b) Networks where L1-L2 is already cryptographically secured before enabling IP (e.g., cdma2000 networks). Although the client is authenticated on the radio link before enabling ciphering, it additionally needs to get authenticated and authorized for accessing the IP services.
b) IP（CDMA2000ネットワークなど）を有効にする前に、L1-L2がすでに暗号化されているネットワーク。クライアントは、暗号化を有効にする前にラジオリンクで認証されていますが、さらにIPサービスにアクセスするために認証および許可される必要があります。
c) No lower-layer security present before enabling IP. PANA is run in an insecure network. PANA-based access authentication is used to bootstrap cryptographic per-packet authentication and integrity protection.
c) IPを有効にする前に、低層セキュリティは存在しません。パナは、安全でないネットワークで実行されます。パナベースのアクセス認証は、パケットごとの認証と整合性保護をブートストラップするために使用されます。
PANA is applicable to not only large-scale operator deployments with full AAA infrastructure, but also to small disconnected deployments like home networks and personal area networks.
PANAは、完全なAAAインフラストラクチャを備えた大規模なオペレーターの展開だけでなく、ホームネットワークや個人エリアネットワークなどの小さな切断された展開にも適用できます。
Since PANA enables decoupling AAA from the link-layer procedures, network access authentication does not have to take place during the link establishment. This allows deferring client authentication until the client attempts to access differentiated services (e.g., high bandwidth, unlimited access, etc.) in some deployments. Additionally, multiple simultaneous network access sessions over the same link-layer connection can occur as well.
PANAは、リンク層手順からAAAを分離することを可能にするため、リンクの確立中にネットワークアクセス認証を行う必要はありません。これにより、クライアントがいくつかの展開で差別化されたサービス（たとえば、帯域幅、無制限のアクセスなど）にアクセスしようとするまで、クライアント認証を延期できます。さらに、同じリンク層接続を介した複数の同時ネットワークアクセスセッションも同様に発生する可能性があります。
The following five scenarios capture the PANA usage model in different network architectures with reference to its placement of logical elements such as the PANA Client (PaC) and the PANA Authentication Agent (PAA) with respect to the Enforcement Point (EP) and the Access Router (AR). Note that PAA may or may not use AAA infrastructure to verify the credentials of PaC in order to authorize network access.
次の5つのシナリオは、パナクライアント（PAC）やPANA認証エージェント（PAA）などの論理要素の配置を参照して、執行ポイント（EP）とアクセスルーターに関して、さまざまなネットワークアーキテクチャでパナの使用モデルをキャプチャします。（AR）。PAAは、ネットワークアクセスを承認するために、AAAインフラストラクチャを使用する場合とPACの資格情報を検証する場合があることに注意してください。
Scenario 1: PAA co-located with EP but separated from AR
シナリオ1：PAAはEPと共同住宅されましたが、ARから分離されています
In this scenario (Figure 1), PAA is co-located with the enforcement point on which access control is performed. This might be the case where PAA is co-located with the L2 access device (e.g., an IP-capable switch).
このシナリオ（図1）では、PAAはアクセス制御が実行される施行ポイントと共同で配置されています。これは、PAAがL2アクセスデバイス（IP利用可能なスイッチなど）と共同住宅されている場合があります。
PaC -----EP/PAA--+
|
+------ AR ----- (AAA)
|
PaC -----EP/PAA--+
Figure 1: PAA co-located with EP but separated from AR.
図1：PAAはEPと共同で配置されましたが、ARから分離されています。
Scenario 2: PAA co-located with AR but separated from EP
シナリオ2：PAAはARと共同住宅しますが、EPから分離されています
In this scenario, PAA is not co-located with EPs but is placed on the AR. Although we have shown only one AR here, there could be multiple ARs, one of which is co-located with the PAA. Access control parameters have to be distributed to the respective enforcement points so that the corresponding device on which PaC is authenticated can access the network. A separate protocol is needed between PAA and EP to carry access control parameters.
このシナリオでは、PAAはEPSと共同で配置されていませんが、ARに配置されています。ここでは1つのARのみを示しましたが、複数のARが存在する可能性があります。アクセス制御パラメーターは、PACが認証されている対応するデバイスがネットワークにアクセスできるように、それぞれの施行ポイントに配布する必要があります。Access Controlパラメーターを搭載するには、PAAとEPの間で個別のプロトコルが必要です。
PaC ----- EP --+
|
+------ AR/PAA --- (AAA)
|
PaC ----- EP --+
Figure 2: PAA co-located with AR but separated from EP
図2：PAAはARと共同住宅しますが、EPから分離されています
Scenario 3: PAA co-located with EP and AR
シナリオ3：PAAはEPとARと共同住宅されています
In this scenario (Figure 3), PAA is co-located with the EP and AR on which access control and routing are performed.
このシナリオ（図3）では、PAAは、アクセス制御とルーティングが実行されるEPおよびARと共同で配置されています。
PaC ----- EP/PAA/AR--+
|
+-------(AAA)
|
PaC ----- EP/PAA/AR--+
Figure 3: PAA co-located with EP and AR.
図3：EPとARと共同住宅。
Scenario 4: Separated PAA, EP, and AR
シナリオ4：分離PAA、EP、およびAR
In this scenario, PAA is neither co-located with EPs nor with ARs. It still resides on the same IP link as ARs. After successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this.
このシナリオでは、PAAはEPSと同時にARSと共同で開催されていません。それはまだARSと同じIPリンクに存在します。認証が成功した後、アクセス制御パラメーターは個別のプロトコルを介してそれぞれの執行ポイントに配布され、PANAはこれで明示的な役割を果たしません。
PaC ----- EP -----+--- AR ---+
| |
PaC ----- EP --- -+ |
| |
PaC ----- EP -----+--- AR -- + ----(AAA)
|
+--- PAA
Figure 4: PAA, EP and AR separated.
図4：PAA、EP、およびAR分離。
Scenario 5: PAA separated from co-located EP and AR
シナリオ5：PAAが共同住宅EPおよびARから分離
In this scenario, EP and AR are co-located with each other but separated from PAA. PAA still resides on the same IP link as ARs. After successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this.
このシナリオでは、EPとARは互いに共同住宅されていますが、PAAから分離されています。PAAは、ARSと同じIPリンクにまだ住んでいます。認証が成功した後、アクセス制御パラメーターは個別のプロトコルを介してそれぞれの執行ポイントに配布され、PANAはこれで明示的な役割を果たしません。
PaC --------------+--- AR/EP ---+
| |
PaC --------------+ |
| |
PaC --------------+--- AR/EP -- + ----(AAA)
|
+--- PAA
Figure 5: PAA separated from EP and AR.
図5：PAAはEPおよびARから分離されています。
References
参考文献
Normative References
引用文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005.
[RFC4016] Parthasarathy、M。、「認証とネットワークアクセス（PANA）脅威分析とセキュリティ要件を伝達するためのプロトコル」、RFC 4016、2005年3月。
Informative References
参考引用
[FMIPv4] Malki, K., "Low Latency Handoffs in Mobile IPv4", Work in Progress, June 2004.
[FMIPV4] Malki、K。、「モバイルIPv4での低レイテンシハンドオフ」、2004年6月、進行中の作業。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
[IEEE-802.1X]電気および電子機器エンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワーク：ポートベースのネットワークアクセス制御」、IEEE Standard 802.1x、2001年9月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、S。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716] Aboba、B。およびD. Simon、「PPP EAP TLS認証プロトコル」、RFC 2716、1999年10月。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794] Calhoun、P。およびC. Perkins、「IPv4のモバイルIPネットワークアクセス識別子拡張機能」、RFC 2794、2000年3月。
[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ Response Extensions", RFC 3012, November 2000.
[RFC3012] Perkins、C。およびP. Calhoun、「モバイルIPv4チャレンジ/応答拡張機能」、RFC 3012、2000年11月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", Work in Progress.
[fmipv6] Koodli、R.、ed。、「モバイルIPv6用の高速ハンドオーバー」、進行中の作業。
Authors' Addresses
著者のアドレス
Alper E. Yegin (editor) Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA
Alper E. Yegin（編集者）Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose、CA 95134 USA
Phone: +1 408 544 5656 EMail: alper.yegin@samsung.com Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
電話：1 408 544 5656メール：alper.yegin@samsung.com
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Reinaldo Penno Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146 USA
Reinaldo Penno Juniper Networks 10 Technology Park Drive Westford、MA 01886-3146 USA
EMail: rpenno@juniper.net
George Tsirtsis Flarion Bedminster One 135 Route 202/206 South Bedminster, NJ 07921 USA
George Tsirtsis Flarion Bedminster One 135 Route 202/206 South Bedminster、NJ 07921 USA
Phone: +44 20 88260073
EMail: G.Tsirtsis@Flarion.com
Cliff Wang ARO/NCSU 316 Riggsbee Farm Morrisville, NC 27560 USA
クリフワンアロ/NCSU 316リグスビーファームモリスビル、ノースカロライナ州27560 USA
Phone: +1 919 548 4207
EMail: cliffwangmail@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。