[要約] RFC 3521は、メディア認証を伴うセッション設定のためのフレームワークを提供しています。このRFCの目的は、セッションのセットアップとメディアの認証を効果的に行うためのガイドラインを提供することです。
Network Working Group L-N. Hamer
Request for Comments: 3521 B. Gage
Category: Informational Nortel Networks
H. Shieh
AT&T Wireless
April 2003
Framework for Session Set-up with Media Authorization
メディア認可によるセッションのセットアップのフレームワーク
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host.
マルチメディアストリームの確立は、エンドツーエンドのQOの要件、ネットワークリソースの使用の許可、および使用されるリソースの正確な会計を考慮する必要があります。セッションのセットアップ中、要求されているメディアストリームが要求ホストのために確立されたサービスプロファイルの境界内にあることを保証するために、ポリシーが強制される場合があります。同様に、ホストがパケットフローに特定のQoSを提供するリソースを要求する場合、必要なリソースがリクエストホストのために確立されたリソースプロファイルの境界内にあることを保証するためにポリシーを施行することができます。
To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session.
詐欺を防ぎ、正確な請求を確保するために、このドキュメントでは、要求されたQoSを提供するために使用されているリソースがセッションで要求された（および承認された）メディアストリームとインラインであることを確認するために必要なリンクを提供するさまざまなシナリオとメカニズムについて説明します。
Table of Contents
目次
1. Introduction....................................................2
2. Conventions used in this document...............................3
3. Definition of terms.............................................4
4. The Coupled Model...............................................5
4.1 Coupled Model Message Flows...............................6
4.2 Coupled Model Authorization Token.........................8
4.3 Coupled Model Protocol Impacts............................8
5. The Associated Model <<using One Policy Server>>................8
5.1 Associated Model Message Flows
<<using One Policy Server>>...............................9
5.2 Associated Model Authorization Token
<<using One Policy Server>>..............................11
5.3 Associated Model Protocol Impacts
<<using One Policy Server>>..............................11
5.4 Associated Model Network Impacts
<<using One Policy Server>>..............................12
6. The Associated Model <<using Two Policy Servers>>..............12
6.1 Associated Model Message Flows
<<using Two Policy Servers>>.............................13
6.2 Associated Model Authorization Token
<<using Two Policy Servers>>.............................15
6.3 Associated Model Protocol Impacts
<<using Two Policy Servers>>.............................16
7. The Non-Associated Model........................................16
7.1 Non-Associated Model Message Flow........................17
7.2 Non-Associated Model Authorization Token.................19
7.3 Non-Associated Model Protocol Impacts....................19
8. Conclusions....................................................20
9. Security Considerations........................................21
10. Normative References...........................................22
11. Informative References.........................................23
12. Acknowledgments................................................23
13. Authors' Addresses.............................................24
14. Full Copyright Statement.......................................25
Various mechanisms have been defined through which end hosts can use a session management protocol (e.g., SIP [6]) to indicate that QoS requirements must be met in order to successfully set up a session. However, a separate protocol (e.g., RSVP [7]) is used to request the resources required to meet the end-to-end QoS of the media stream. To prevent fraud and to ensure accurate billing, some linkage is required to verify that the resources being used to provide the requested QoS are in-line with the media streams requested (and authorized) for the session.
エンドホストがセッション管理プロトコル（SIP [6]など）を使用して、セッションを正常にセットアップするためにQOS要件を満たす必要があることを示すさまざまなメカニズムが定義されています。ただし、別のプロトコル（RSVP [7]など）を使用して、メディアストリームのエンドツーエンドQOを満たすために必要なリソースを要求します。詐欺を防ぎ、正確な請求を確保するために、要求されたQoSを提供するために使用されているリソースがセッションで要求された（および承認された）メディアストリームとインラインであることを確認するために、ある程度のリンクが必要です。
This document describes such a linkage through use of a "token" that provides capabilities similar to that of a gate in [12] and of a ticket in the push model of [10]. The token is generated by a policy server (or a session management server) and is transparently relayed through the end host to the edge router where it is used as part of the policy-controlled flow admission process.
このドキュメントでは、[12]のゲートと同様の機能と[10]のプッシュモデルのチケットの機能と同様の機能を提供する「トークン」を使用することにより、このようなリンクを説明しています。トークンはポリシーサーバー（またはセッション管理サーバー）によって生成され、エンドホストを介してエッジルーターに透過的に中継され、ポリシー制御フロー入学プロセスの一部として使用されます。
In some environments, authorization of media streams can exploit the fact that pre-established relationships exist between elements of the network (e.g., session management servers, edge routers, policy servers and end hosts). Pre-established relationships assume that the different network elements are configured with the identities of the other network elements and, if necessary, are configured with security keys, etc. required to establish a trust relationship. In other environments, however, such pre-established relationships may not exist either due to the complexity of creating these associations a priori (e.g., in a network with many elements), or due to the different business entities involved (e.g., service provider and access provider), or due to the dynamic nature of these associations (e.g., in a mobile environment).
一部の環境では、メディアストリームの承認は、ネットワークの要素（セッション管理サーバー、エッジルーター、ポリシーサーバー、エンドホストなど）間に事前に確立された関係が存在するという事実を活用できます。事前に確立された関係は、異なるネットワーク要素が他のネットワーク要素のアイデンティティで構成され、必要に応じて信頼関係を確立するために必要なセキュリティキーなどで構成されていると仮定します。ただし、他の環境では、このような事前に確立された関係は、これらの関連付けを先験的に作成する複雑さ（たとえば、多くの要素を持つネットワーク）、または関係するさまざまなビジネスエンティティ（たとえば、サービスプロバイダーやサービスプロバイダーやアクセスプロバイダー）、またはこれらの関連付けの動的な性質のため（モバイル環境など）。
In this document, we describe these various scenarios and the mechanisms used for exchanging information between network elements in order to authorize the use of resources for a service and to coordinate actions between the session and resource management entities. Specific extensions to session management protocols (e.g., SIP [6], H.323), to resource reservation protocols (e.g., RSVP [4], YESSIR) and to policy management protocols (e.g., COPS-PR [9], COPS-RSVP [3]) required to realize these scenarios and mechanisms are beyond the scope of this document.
このドキュメントでは、これらのさまざまなシナリオと、サービスへのリソースの使用を承認し、セッションとリソース管理エンティティ間のアクションを調整するために、ネットワーク要素間で情報を交換するために使用されるメカニズムについて説明します。セッション管理プロトコル（SIP [6]、H.323など）、リソース予約プロトコル（例：RSVP [4]、Yessir）およびポリシー管理プロトコル（COPS-PR [9]、COPS-RSVP [3]）これらのシナリオとメカニズムを実現するために必要なのは、このドキュメントの範囲を超えています。
For clarity, this document will illustrate the media authorization concepts using SIP for session signalling, RSVP for resource reservation and COPS for interaction with the policy servers. Note, however, that the framework could be applied to a multimedia services scenario using different signalling protocols.
明確にするために、このドキュメントでは、セッションシグナルのSIP、リソース予約のRSVP、ポリシーサーバーとの対話のためのCOPを使用して、メディア認証の概念を説明します。ただし、フレームワークは、異なるシグナリングプロトコルを使用してマルチメディアサービスシナリオに適用できることに注意してください。
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 BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
Figure 1 introduces a generic model for session establishment, QoS and policy enforcement.
図1では、セッションの確立、QoS、およびポリシー施行のための一般的なモデルを紹介します。
+-------------------------------------+ +---+
| SCD - Service Control Domain | | |
| +-----------------------+ +--------+| | I |
| |Session management | |Policy || | n |
| |server | |Server || | t |
| | +---------+ +------+ | | +----+||<->| e |
| | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r |
| | +---------+ +------+ | | +----+|| | - |
| +-----------------------+ +--------+| | c |
| | | o |
+-------------------------------------+ | n |
| n |
+-------------------------------------+ | e |
| RCD - Resource Control Domain | | c |
| | | t |
| | | i |
| +------------+ +-------------+ | | n |
+----------+ | |Edge Router | |Policy Server| | | g |
| End | | | | | | | | |
| Host | | |+----------+| |+----------+ | | | N |
|+--------+| | ||RSVP Agent|| ||PDP | | | | e |
||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t |
||Client || | |+----------+| | | | | w |
|+--------+| | || PEP || | | | | o |
||SIP User|| | |+----------+| | | | | r |
||Agent || | +------------+ +-------------+ | | k |
|+--------+| | | | |
+----------+ +-------------------------------------+ +---+
Figure 1: Generic media authorization network model
図1：ジェネリックメディア認証ネットワークモデル
EH - End Host: The End Host is a device used by a subscriber to access network services. The End Host includes a client for requesting network services (e.g., through SIP) and a client for requesting network resources (e.g., through RSVP).
EH-エンドホスト：エンドホストは、ネットワークサービスにアクセスするためにサブスクライバーが使用するデバイスです。エンドホストには、ネットワークサービス（SIPなど）を要求するためのクライアントと、ネットワークリソースを要求するためのクライアント（RSVPなど）が含まれています。
ER - Edge Router: The Edge Router is a network element connecting the end host to the rest of the Resource Control Domain. The Edge Router contains a PEP to enforce policies related to resource usage in the Resource Control Domain by the End Host. It also contains a signalling agent (e.g., for RSVP) for handling resource reservation requests from the End Host.
ER-エッジルーター：エッジルーターは、エンドホストを残りのリソースコントロールドメインに接続するネットワーク要素です。エッジルーターには、エンドホストによるリソース制御ドメインのリソース使用に関連するポリシーを実施するためのPEPが含まれています。また、エンドホストからのリソース予約リクエストを処理するためのシグナル伝達剤（RSVPなど）も含まれています。
PDP - Policy Decision Point: The PDP is a logical entity located in the Policy Server that is responsible for authorizing or denying access to services and/or resources.
PDP-ポリシー決定ポイント：PDPは、サービスおよび/またはリソースへのアクセスを承認または拒否する責任を負うポリシーサーバーにある論理エンティティです。
PEP - Policy Enforcement Point: The PEP is a logical entity that enforces policy decisions made by the PDP. Note that other PEPs may reside in other network elements not shown in the model of Figure 1, however they will not be discussed in this document.
PEP-ポリシーの執行ポイント：PEPは、PDPによって行われた政策決定を実施する論理的エンティティです。他のPEPは、図1のモデルには示されていない他のネットワーク要素に存在する場合がありますが、このドキュメントでは説明しません。
PS - Policy Server: The Policy Server is a network element that includes a PDP. Note that there may be a PS in the Service Control Domain to control use of services and there may be a separate PS in the Resource Control Domain to control use of resources along the packet forwarding path. Note also that network topology may require multiple Policy Servers within either Domain, however they provide consistent policy decisions to offer the appearance of a single PDP in each Domain.
PS-ポリシーサーバー：ポリシーサーバーは、PDPを含むネットワーク要素です。サービスの使用を制御するためのサービスコントロールドメインにPSがある可能性があり、リソースコントロールドメインに別のPSがあり、パケット転送パスに沿ってリソースの使用を制御することができることに注意してください。また、ネットワークトポロジはどちらのドメイン内で複数のポリシーサーバーを必要とする場合もありますが、各ドメインに単一のPDPの外観を提供するための一貫したポリシー決定を提供することに注意してください。
RCD - Resource Control Domain: The Resource Control Domain is a logical grouping of elements that provide connectivity along the packet forwarding paths to and from an End Host. The RCD contains ER and PS entities whose responsibilities include management of resources along the packet forwarding paths. Note that there may be one or more RCDs within an autonomous domain.
RCD-リソース制御ドメイン：リソース制御ドメインは、エンドホストとの間でパケット転送パスに沿って接続を提供する要素の論理的なグループ化です。RCDには、責任がパケット転送パスに沿ったリソースの管理が含まれるERおよびPSエンティティが含まれています。自律ドメイン内に1つ以上のRCDがある可能性があることに注意してください。
SCD - Service Control Domain: The Service Control Domain is a logical grouping of elements that offer applications and content to subscribers of their services. The Session Management Server resides in the SCD along with a PS. Note that there may be one or more SCDs within an autonomous domain.
SCD-サービスコントロールドメイン：サービスコントロールドメインは、サービスのサブスクライバーにアプリケーションとコンテンツを提供する要素の論理的なグループ化です。セッション管理サーバーは、PSとともにSCDにあります。自律ドメイン内に1つ以上のSCDがある可能性があることに注意してください。
SMS - Session Management Server: The Session Management Server is a network element providing session management services (e.g., telephony call control). The Session Management Server contains a PEP to enforce policies related to use of services by the End Host. It also contains a signalling agent or proxy (e.g., for SIP) for handling service requests from the End Host.
SMS-セッション管理サーバー：セッション管理サーバーは、セッション管理サービス（テレフォニーコールコントロールなど）を提供するネットワーク要素です。セッション管理サーバーには、エンドホストによるサービスの使用に関連するポリシーを実施するためのPEPが含まれています。また、エンドホストからのサービスリクエストを処理するためのシグナリングエージェントまたはプロキシ（SIPなど）も含まれています。
In some environments, a pre-established trust relationship exists between elements of the network (e.g., session management servers, edge routers, policy servers and end hosts). We refer to this as the "coupled model", indicating the tight relationship between entities that is presumed. The key aspects of this scenario are the following:
一部の環境では、ネットワークの要素（セッション管理サーバー、エッジルーター、ポリシーサーバー、エンドホストなど）の間に事前に確立された信頼関係が存在します。これを「結合モデル」と呼び、推定されているエンティティ間の厳しい関係を示しています。このシナリオの重要な側面は次のとおりです。
- Policy decisions, including media authorization, are made by a single Policy Server.
- メディア認可を含む政策決定は、単一のポリシーサーバーによって行われます。
- The Edge Router, Session Management Servers and Policy Server involved in establishing the session are known a priori. For example, the End Host may be configured to use a Session Management Server associated with the Edge Router to which the EH is connected.
- セッションの確立に関与するエッジルーター、セッション管理サーバー、およびポリシーサーバーは、先験的に知られています。たとえば、ENDホストは、EHが接続されているエッジルーターに関連付けられたセッション管理サーバーを使用するように構成できます。
- There are pre-defined trust relationships between the SMS and the PS and between the ER and the PS.
- SMSとPSとERとPSの間には、事前に定義された信頼関係があります。
+--------+
+------+ | |
| | 1 +--------------------+ 2 | |
| |-------->| Session Management |----->| |
| |<--------| Server |<-----| |
| | 4 +--------------------+ 3 | |
| End | | Policy |
| Host | | Server |
| | | |
| | 5 +--------------------+ 6 | |
| |-------->| Edge |----->| |
| |<--------| Router |<-----| |
| | 8 +--------------------+ 7 | |
+------+ | |
+--------+
Figure 2: The Coupled Model
図2：結合モデル
In this model, it is assumed that there is one Policy Server serving both the Service Control and Resource Control Domains and that there are pre-defined trust relationships between the PS and SMS and between the PS and ER. Communications between these entities are then possible as described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルでは、サービス制御ドメインとリソース制御ドメインの両方にサービスを提供するポリシーサーバーが1つあり、PSとSMSの間に、PSとERの間に事前に定義された信頼関係があると想定されています。以下に説明するように、これらのエンティティ間の通信が可能です。シンプルさのために、発生する側面の流れのみが説明されています。同じ概念が終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1. エンドホストは、セッションで使用されるメディアストリームを示すセッション管理サーバーにセッションセットアップリクエスト（SIP Inviteなど）を発行します。このステップの一部として、エンドホストはセッション管理サーバーに認証する場合があります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the Policy Server in order to determine if the session set-up request should be allowed to proceed.
2. セッション管理サーバーは、おそらくメディアストリームの交渉が完了するのを待った後、セッションのセットアップリクエストを続行できるかどうかを判断するために、ポリシー決定要求（例：COPS REQ）をポリシーサーバーに送信します。
3. The Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the Policy Server to identify the session and the media it has authorized.
3. ポリシーサーバーは、使用するメディアのパラメーターを変更した後、おそらくセッション管理サーバーに決定（例：COPS DEC）を送信します。この応答には、その後、ポリシーサーバーがセッションとメディアを識別するために使用できる「トークン」が含まれています。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the Policy Server.
4. セッション管理サーバーは、セッションのセットアップが完了しているか、進行していることを示す、エンドホスト（例：SIP 200または183）への応答を送信します。この応答には、ポリシーサーバーからのトークンとともに、ネゴシエートされたメディアの説明が含まれています。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the Policy Server provided via the Session Management Server.
5. エンドホストは、メディアストリームに必要なQoSを提供するために必要なリソースを予約するために、リクエスト（RSVPパスなど）を発行します。このリクエストには、セッション管理サーバーを介して提供されるポリシーサーバーからのトークンが含まれています。
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the Policy Server provided by the End Host. The Policy Server uses this token to correlate the request for resources with the media authorization previously provided to the Session Management Server.
6. Edgeルーターは予約要求を傍受し、リソース予約要求を続行する必要があるかどうかを判断するために、ポリシー決定要求（COPS REQなど）をポリシーサーバーに送信します。このリクエストには、エンドホストが提供するポリシーサーバーからのトークンが含まれています。ポリシーサーバーは、このトークンを使用して、リソースのリクエストを以前にセッション管理サーバーに提供されていたメディア許可と相関させます。
7. The Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
7. ポリシーサーバーは、予約するリソースのパラメーターを変更した後、決定（例：COPS DEC）をEdgeルーターに送信します。
8. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing.
8. エッジルーターは、おそらくリソースを完了するためのエンドツーエンドの交渉を待った後、エンドホスト（例：RSVP RESV）への応答を送信して、リソースの予約が完了しているか、進行していることを示します。
In the Coupled Model, the Policy Server is the only network entity that needs to interpret the contents of the token. Therefore, in this model, the contents of the token are implementation dependent. Since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to ensure that the integrity of the token is preserved in transit; the exact mechanisms to be used are also implementation dependent.
結合モデルでは、ポリシーサーバーは、トークンの内容を解釈する必要がある唯一のネットワークエンティティです。したがって、このモデルでは、トークンの内容は実装依存です。エンドホストは信頼されていないと想定されるため、ポリシーサーバーはトークンの完全性が輸送中に保存されるようにするための措置を講じる必要があります。使用する正確なメカニズムも実装に依存します。
The use of a media authorization token in the Coupled Model requires the addition of new fields to several protocols:
結合モデルでメディア認証トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure (if any) of this object SHOULD be opaque to the resource reservation protocol. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトをリソース予約プロトコルに追加して、エンドホストからエッジルーターにトークンを透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造（もしあれば）は、リソース予約プロトコルに不透明でなければなりません。たとえば、これは[8]で定義されているポリシーデータオブジェクトを備えたRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transparently transport the token from the Policy Server to the Session Management Server and from the Edge Router to the Policy Server. The content and internal structure (if any) of this object SHOULD be opaque to the policy management protocol. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。新しいプロトコルフィールドまたはオブジェクトをポリシー管理プロトコルに追加して、ポリシーサーバーからセッション管理サーバー、およびエッジルーターからポリシーサーバーにトークンを透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造（もしあれば）は、ポリシー管理プロトコルに不透明でなければなりません。たとえば、これは[8]で定義されているポリシーデータオブジェクトを使用して、COPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure (if any) of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。セッション管理プロトコルに新しいプロトコルフィールドまたはオブジェクトを追加して、メディア認証トークンをセッション管理サーバーからエンドホストに透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造（もしあれば）は、セッション管理プロトコル（SIP [6]など）に不透明でなければなりません。
In this scenario, there are multiple instances of the Session Management Servers, Edge Routers and Policy Servers. This leads to a network of sufficient complexity that it precludes distributing knowledge of network topology to all network entities. The key aspects of this scenario are the following:
このシナリオでは、セッション管理サーバー、エッジルーター、ポリシーサーバーには複数のインスタンスがあります。これは、ネットワークトポロジの知識をすべてのネットワークエンティティに分配することを妨げる十分な複雑さのネットワークにつながります。このシナリオの重要な側面は次のとおりです。
- Policy decisions, including media authorization, are made by the same Policy Server for both the Session Management Server and the Edge Router. However, the Policy Server may change on a per-transaction basis, i.e., on a per policy request basis.
- メディア認可を含むポリシーの決定は、セッション管理サーバーとエッジルーターの両方に対して同じポリシーサーバーによって行われます。ただし、ポリシーサーバーは、トランザクションごと、つまりポリシーリクエストごとに変更される場合があります。
- The Edge Router, Session Management Server and Policy Server involved in establishing the session are not known a priori. For example, the End Host may be dynamically configured to use one of a pool of Session Management Servers and each of the Session Management Servers may be statically configured to use one of a pool of Policy Servers.
- セッションの確立に関与するエッジルーター、セッション管理サーバー、およびポリシーサーバーは、先験的に不明です。たとえば、エンドホストは、セッション管理サーバーのプールの1つを使用するように動的に構成されている場合があり、各セッション管理サーバーは、ポリシーサーバーのプールの1つを使用するように静的に構成されてもよいです。
In another example, the End Host may be mobile and continually changing the Edge Router that its point of attachment uses to communicate with the rest of the network.
別の例では、エンドホストはモバイルであり、アタッチメントがネットワークの残りの部分と通信するために使用するエッジルーターを継続的に変更することができます。
- There are pre-defined trust relationships between the SMS and the PS and between the ER and the PS.
- SMSとPSとERとPSの間には、事前に定義された信頼関係があります。
+---------------------+ +---------+
| SMS 'n' |<-->| PS 'm' |
+---------------------+ +--------+ |
+------+ : : : | | |
| | 1 +--------------------+ 2 | | |
| |-------->| Session Management |----->| | |
| |<--------| Server 1 |<-----| | |
| | 4 +--------------------+ 3 | | |
| End | | Policy | |
| Host | +--------------------+ | Server | |
| | | ER 'n' | | 1 | |
| | 5 +-+------------------+ | | | |
| |-------->| Edge |-+ 6 | | |
| |<--------| Router |----->| | |
| | 8 +--------------------+ 7 | | |
+------+ <-----| |-+
+--------+
Figure 3: The Associated Model using One Policy Server
図3：1つのポリシーサーバーを使用した関連モデル
In this model, it is assumed that a Policy Server can make decisions for both the Service Control and Resource Control Domains and that there are pre-defined trust relationships between the PS and SMS and between the PS and ER. Communications between these entities are then possible as described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルでは、ポリシーサーバーは、サービス制御ドメインとリソース制御ドメインの両方に決定を下すことができ、PSとSMSの間に事前に定義された信頼関係があると想定されています。以下に説明するように、これらのエンティティ間の通信が可能です。シンプルさのために、発生する側面の流れのみが説明されています。同じ概念が終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1. エンドホストは、セッションで使用されるメディアストリームを示すセッション管理サーバーにセッションセットアップリクエスト（SIP Inviteなど）を発行します。このステップの一部として、エンドホストはセッション管理サーバーに認証する場合があります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the Policy Server in order to determine if the session set-up request should be allowed to proceed.
2. セッション管理サーバーは、おそらくメディアストリームの交渉が完了するのを待った後、セッションのセットアップリクエストを続行できるかどうかを判断するために、ポリシー決定要求（例：COPS REQ）をポリシーサーバーに送信します。
3. The Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the Policy Server to identify the session and the media it has authorized.
3. ポリシーサーバーは、使用するメディアのパラメーターを変更した後、おそらくセッション管理サーバーに決定（例：COPS DEC）を送信します。この応答には、その後、ポリシーサーバーがセッションとメディアを識別するために使用できる「トークン」が含まれています。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the Policy Server.
4. セッション管理サーバーは、セッションのセットアップが完了しているか、進行していることを示す、エンドホスト（例：SIP 200または183）への応答を送信します。この応答には、ポリシーサーバーからのトークンとともに、ネゴシエートされたメディアの説明が含まれています。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the Policy Server provided via the Session Management Server.
5. エンドホストは、メディアストリームに必要なQoSを提供するために必要なリソースを予約するために、リクエスト（RSVPパスなど）を発行します。このリクエストには、セッション管理サーバーを介して提供されるポリシーサーバーからのトークンが含まれています。
6. The Edge Router intercepts the reservation request and inspects the token to learn which Policy Server authorized the media. It then sends a policy decision request to that Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the Policy Server provided by the End Host. The Policy Server uses this token to correlate the request for resources with the media authorization previously provided to the Session Management Server.
6. Edgeルーターは予約要求をインターセプトし、トークンを検査して、どのポリシーサーバーがメディアを承認したかを確認します。次に、リソース予約要求を続行する必要があるかどうかを判断するために、そのポリシーサーバーにポリシー決定要求を送信します。このリクエストには、エンドホストが提供するポリシーサーバーからのトークンが含まれています。ポリシーサーバーは、このトークンを使用して、リソースのリクエストを以前にセッション管理サーバーに提供されていたメディア許可と相関させます。
7. The Policy Server sends a decision to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
7. ポリシーサーバーは、予約するリソースのパラメーターを変更した後、おそらくエッジルーターに決定を送信します。
8. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing.
8. エッジルーターは、おそらくリソースを完了するためのエンドツーエンドの交渉を待った後、エンドホスト（例：RSVP RESV）への応答を送信して、リソースの予約が完了しているか、進行していることを示します。
Since the ER does not know which SMS and PS are involved in session establishment, the token MUST include:
ERはセッションの確立にどのSMSとPSが関与しているかを知らないため、トークンには以下を含める必要があります。
- A correlation identifier. This is information that the Policy Server can use to correlate the resource reservation request with the media authorized during session set up. The Policy Server is the only network entity that needs to interpret the contents of the correlation identifier therefore, in this model, the contents of the correlation identifier are implementation dependent. Since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to ensure that the integrity of the correlation identifier is preserved in transit; the exact mechanisms to be used are also implementation dependent.
- 相関識別子。これは、ポリシーサーバーがセッションのセットアップ中に許可されたメディアとリソース予約要求を相関させるために使用できる情報です。ポリシーサーバーは、相関識別子の内容を解釈する必要がある唯一のネットワークエンティティです。したがって、このモデルでは、相関識別子の内容が実装依存です。エンドホストは信頼されていないと想定されているため、ポリシーサーバーは、相関識別子の完全性が輸送中に保持されることを保証するための措置を講じる必要があります。使用する正確なメカニズムも実装に依存します。
- The identity of the authorizing entity. This information is used by the Edge Router to determine which Policy Server should be used to solicit resource policy decisions.
- 認可エンティティのアイデンティティ。この情報は、エッジルーターによって使用され、リソースポリシーの決定を求めるために使用するポリシーサーバーを決定します。
In some environments, an Edge Router may have no means for determining if the identity refers to a legitimate Policy Server within its domain. In order to protect against redirection of authorization requests to a bogus authorizing entity, the token SHOULD also include:
一部の環境では、エッジルーターは、アイデンティティがドメイン内の正当なポリシーサーバーを指すかどうかを判断する手段がない場合があります。偽の認可エンティティへの認可要求のリダイレクトから保護するために、トークンには以下も含まれなければなりません。
- Authentication data. This authentication data is calculated over all other fields of the token using an agreed mechanism. The mechanism used by the Edge Router is beyond the scope of this document.
- 認証データ。この認証データは、合意されたメカニズムを使用して、トークンの他のすべてのフィールドで計算されます。エッジルーターが使用するメカニズムは、このドキュメントの範囲を超えています。
The detailed semantics of an authorization token are defined in [4].
承認トークンの詳細なセマンティクスは[4]で定義されています。
The use of a media authorization token in this version of the Associated Model requires the addition of new fields to several protocols:
関連するモデルのこのバージョンでメディア認証トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure of this object MUST be specified so that the Edge Router can distinguish between the elements of the token described in Section 5.2. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトをリソース予約プロトコルに追加して、エンドホストからエッジルーターにトークンを透過的に輸送する必要があります。このオブジェクトの内容と内部構造は、エッジルーターがセクション5.2で説明されているトークンの要素を区別できるように指定する必要があります。たとえば、これは[8]で定義されているポリシーデータオブジェクトを備えたRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transparently transport the token -- or at least the correlation identifier -- from the Edge Router to the Policy Server. The content and internal structure of this object SHOULD be opaque to the policy management protocol. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。新しいプロトコルフィールドまたはオブジェクトをポリシー管理プロトコルに追加して、エッジルーターからポリシーサーバーにトークン（少なくとも相関識別子）を透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造は、ポリシー管理プロトコルに不透明である必要があります。たとえば、これは[8]で定義されているポリシーデータオブジェクトを使用して、COPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。セッション管理プロトコルに新しいプロトコルフィールドまたはオブジェクトを追加して、メディア認証トークンをセッション管理サーバーからエンドホストに透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造は、セッション管理プロトコル（SIP [6]など）に不透明でなければなりません。
The use of a media authorization token in this version of the Associated Model requires that the Edge Router inspect the token to learn which Policy Server authorized the media. In some environments, it may not be possible for the Edge Router to perform this function; in these cases, an Associated Model using Two Policy Servers (section 6) is required.
関連するモデルのこのバージョンでメディア認証トークンを使用するには、エッジルーターがトークンを検査して、どのポリシーサーバーがメディアを承認したかを学習する必要があります。環境によっては、エッジルーターがこの機能を実行することは不可能かもしれません。これらの場合、2つのポリシーサーバー（セクション6）を使用した関連モデルが必要です。
This version of the Associated Model also requires that the Edge Router interact with multiple Policy Servers. Policy decisions are made by the same Policy Server for both the Session Management Server and the Edge Router, however the Policy Server may change on per-transaction basis. Note that the COPS framework does not currently allow PEPs to change PDP on a per-transaction basis. To use this model, a new framework must be defined for policy decision outsourcing. This model also implies that the Policy Servers are able to interact and/or make decisions for the Edge Router in a consistent manner (e.g., as though there is only a single RCD Policy Server). How this is accomplished is beyond the scope of this document.
関連するモデルのこのバージョンでは、エッジルーターが複数のポリシーサーバーと対話する必要があります。ポリシーの決定は、セッション管理サーバーとEdgeルーターの両方に対して同じポリシーサーバーによって行われますが、ポリシーサーバーは輸送ごとに変更される場合があります。COPSフレームワークでは、現在、PEPがトランザクションごとにPDPを変更することを許可していないことに注意してください。このモデルを使用するには、政策決定のアウトソーシングのために新しいフレームワークを定義する必要があります。また、このモデルは、ポリシーサーバーが一貫した方法でエッジルーターの意思決定を相互作用または/または決定できることを意味します（たとえば、単一のRCDポリシーサーバーしかないかのように）。これがどのように達成されるかは、このドキュメントの範囲を超えています。
In this scenario, there are multiple instances of the Session Management Servers, Edge Routers and Policy Servers. This leads to a network of sufficient complexity that it precludes distributing knowledge of network topology to all network entities. The key aspects of this scenario are the following:
このシナリオでは、セッション管理サーバー、エッジルーター、ポリシーサーバーには複数のインスタンスがあります。これは、ネットワークトポロジの知識をすべてのネットワークエンティティに分配することを妨げる十分な複雑さのネットワークにつながります。このシナリオの重要な側面は次のとおりです。
- Policy decisions, including media authorization, are made by Policy Servers.
- メディア認可を含む政策決定は、ポリシーサーバーによって行われます。
- There is a PS in the Resource Control Domain that is separate from the PS in the Service Control Domain.
- リソース制御ドメインには、サービスコントロールドメインのPSとは別のPSがあります。
- The Edge Router, Session Management Server and Policy Servers involved in establishing the session are not known a priori. For example, the End Host may be dynamically configured to use one of a pool of Session Management Servers or the End Host may be mobile and continually changing the Edge Router that it uses to communicate with the rest of the network.
- セッションの確立に関与するエッジルーター、セッション管理サーバー、およびポリシーサーバーは、先験的に不明です。たとえば、エンドホストは、セッション管理サーバーのプールの1つを使用するように動的に構成されている場合があります。または、エンドホストはモバイルであり、ネットワークの残りの部分と通信するために使用するエッジルーターを継続的に変更する場合があります。
- There is a pre-defined trust relationship between the SMS and the SCD PS.
- SMSとSCD PSの間には、事前に定義された信頼関係があります。
- There is a pre-defined trust relationship between the ER and the RCD PS.
- ERとRCD PSの間には、事前に定義された信頼関係があります。
- There is a pre-defined trust relationship between the RCD and SCD Policy Servers.
- RCDとSCDポリシーサーバーの間には、事前に定義された信頼関係があります。
+--------------------+ +--------+
+------+ | SMS `n' | | |
| | 1 +-+------------------+ | | SCD |
| |-------->| Session Management |-+ 2 | Policy |
| |<--------| Server |----->| Server |
| | 4 +--------------------+<-----| |
| End | 3 +--------+
| | 7 ^ |
| Host | +--------------------+ | v 8
| | | ER 'n' | +--------+
| | 5 +-+------------------+ | | |
| |-------->| Edge |-+ 6 | RCD |
| |<--------| Router |----->| Policy |
| | 10 +--------------------+<--- -| Server |
+------+ 9 | |
+--------+
Figure 4: The Associated Model using Two Policy Servers
図4：2つのポリシーサーバーを使用した関連モデル
In this model, it is assumed that there is one Policy Server for the Service Control Domain and a different Policy Server for the Resource Control Domain. There are pre-defined trust relationships between the SCD PS and SMS, between the RCD PS and ER and between the RCD and SCD Policy Servers. Communications between these entities are then possible as described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルでは、サービス制御ドメインには1つのポリシーサーバーがあり、リソース制御ドメインには異なるポリシーサーバーがあると想定されています。SCD PSとSMS、RCD PSとERの間、およびRCDとSCDポリシーサーバーの間には、事前に定義された信頼関係があります。以下に説明するように、これらのエンティティ間の通信が可能です。シンプルさのために、発生する側面の流れのみが説明されています。同じ概念が終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1. エンドホストは、セッションで使用されるメディアストリームを示すセッション管理サーバーにセッションセットアップリクエスト（SIP Inviteなど）を発行します。このステップの一部として、エンドホストはセッション管理サーバーに認証する場合があります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the SCD Policy Server in order to determine if the session set-up request should be allowed to proceed.
2. セッション管理サーバーは、おそらくメディアストリームの交渉が完了するのを待った後、セッションのセットアップリクエストを続行できるかどうかを判断するために、ポリシー決定要求（例：COPS REQ）をSCDポリシーサーバーに送信します。
3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the SCD Policy Server to identify the session and the media it has authorized.
3. SCDポリシーサーバーは、使用するメディアのパラメーターを変更した後、おそらくセッション管理サーバーに決定（COPS DECなど）を送信します。この応答には、SCDポリシーサーバーがその後使用してセッションとメディアが承認したメディアを特定できる「トークン」が含まれています。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the SCD Policy Server.
4. セッション管理サーバーは、セッションのセットアップが完了しているか、進行していることを示す、エンドホスト（例：SIP 200または183）への応答を送信します。この応答には、SCDポリシーサーバーからのトークンとともに、ネゴシエートされたメディアの説明が含まれています。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the SCD Policy Server provided via the Session Management Server.
5. エンドホストは、メディアストリームに必要なQoSを提供するために必要なリソースを予約するために、リクエスト（RSVPパスなど）を発行します。このリクエストには、セッション管理サーバーを介して提供されるSCDポリシーサーバーからのトークンが含まれています。
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the RCD Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the SCD Policy Server provided by the End Host.
6. Edgeルーターは予約要求を傍受し、リソース予約要求を続行する必要があるかどうかを判断するために、ポリシー決定要求（COPS REQなど）をRCDポリシーサーバーに送信します。このリクエストには、エンドホストが提供するSCDポリシーサーバーからのトークンが含まれています。
7. The RCD Policy Server uses this token to learn which SCD Policy Server authorized the media. It then sends an authorization request [11] to that SCD Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the SCD Policy Server provided by the End Host.
7. RCDポリシーサーバーは、このトークンを使用して、どのSCDポリシーサーバーがメディアを承認したかを学習します。次に、リソース予約要求を続行する必要があるかどうかを判断するために、そのSCDポリシーサーバーに承認要求[11]を送信します。このリクエストには、エンドホストが提供するSCDポリシーサーバーからのトークンが含まれています。
8. The SCD Policy Server uses this token to correlate the request for resources with the media authorization previously provided to the Session Management Server. The SCD Policy Server sends a decision [11] to the RCD Policy Server on whether the requested resources are within the bounds authorized by the SCD Policy Server.
8. SCDポリシーサーバーは、このトークンを使用して、リソースのリクエストを以前にセッション管理サーバーに提供されていたメディア許可と相関させます。SCDポリシーサーバーは、要求されたリソースがSCDポリシーサーバーによって承認された範囲内であるかどうかについて、RCDポリシーサーバーに決定[11]を送信します。
9. The RCD Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
9. RCDポリシーサーバーは、おそらくリソースのパラメーターを予約するパラメーターを変更した後、決定（例：COPS DEC）をエッジルーターに送信します。
10. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing
10. エッジルーターは、おそらくリソースを完了するためのエンドツーエンドの交渉を待った後、エンドホスト（例：RSVP RESV）への応答を送信して、リソースの予約が完了しているか、進行中であることを示しています
Since the RCD Policy Server does not know which SMS and SCD PS are involved in session establishment, the token MUST include:
RCDポリシーサーバーは、どのSMSとSCD PSがセッションの確立に関与しているかを知らないため、トークンには以下を含める必要があります。
- A correlation identifier. This is information that the SCD Policy Server can use to correlate the resource reservation request with the media authorized during session set up. The SCD Policy Server is the only network entity that needs to interpret the contents of the correlation identifier therefore, in this model, the contents of the correlation identifier are implementation dependent. Since the End Host is assumed to be untrusted, the SCD Policy Server SHOULD take measures to ensure that the integrity of the correlation identifier is preserved in transit; the exact mechanisms to be used are also implementation dependent.
- 相関識別子。これは、SCDポリシーサーバーがセッションのセットアップ中に許可されたメディアとリソース予約要求を相関させるために使用できる情報です。SCDポリシーサーバーは、相関識別子の内容を解釈する必要がある唯一のネットワークエンティティです。したがって、このモデルでは、相関識別子の内容は実装依存です。エンドホストは信頼されていないと想定されるため、SCDポリシーサーバーは、相関識別子の完全性が輸送中に保存されるように措置を講じる必要があります。使用する正確なメカニズムも実装に依存します。
- The identity of the authorizing entity. This information is used by the RCD Policy Server to determine which SCD Policy Server should be used to verify the contents of the resource reservation request.
- 認可エンティティのアイデンティティ。この情報は、RCDポリシーサーバーによって使用され、リソース予約要求の内容を確認するために使用するSCDポリシーサーバーを決定します。
In some environments, an RCD Policy Server may have no means for determining if the identity refers to a legitimate SCD Policy Server. In order to protect against redirection of authorization requests to a bogus authorizing entity, the token SHOULD include:
一部の環境では、RCDポリシーサーバーは、IDが正当なSCDポリシーサーバーを指すかどうかを判断する手段がない場合があります。偽の認可エンティティへの認可要求のリダイレクトを防ぐために、トークンには以下を含める必要があります。
- Authentication data. This authentication data is calculated over all other fields of the token using an agreed mechanism. The mechanism used by the RCD Policy Server is beyond the scope of this document.
- 認証データ。この認証データは、合意されたメカニズムを使用して、トークンの他のすべてのフィールドで計算されます。RCDポリシーサーバーが使用するメカニズムは、このドキュメントの範囲を超えています。
Note that the information in this token is the same as that in Section 5.2 for the "One Policy Server" scenario.
このトークンの情報は、「1つのポリシーサーバー」シナリオのセクション5.2の情報と同じであることに注意してください。
The detailed semantics of an authorization token are defined in [4].
承認トークンの詳細なセマンティクスは[4]で定義されています。
The use of a media authorization token in this version of the Associated Model requires the addition of new fields to several protocols:
関連するモデルのこのバージョンでメディア認証トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure of this object SHOULD be opaque to the resource reservation protocol. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトをリソース予約プロトコルに追加して、エンドホストからエッジルーターにトークンを透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造は、リソース予約プロトコルに不透明でなければなりません。たとえば、これは[8]で定義されているポリシーデータオブジェクトを備えたRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transport the token from the SCD Policy Server to the Session Management Server and from the Edge Router to the RCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can distinguish between the elements of the token described in Section 6.2. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。新しいプロトコルフィールドまたはオブジェクトをポリシー管理プロトコルに追加して、SCDポリシーサーバーからセッション管理サーバー、およびエッジルーターからRCDポリシーサーバーにトークンを輸送する必要があります。このオブジェクトのコンテンツと内部構造は、ポリシーサーバーがセクション6.2で説明されているトークンの要素を区別できるように指定する必要があります。たとえば、これは[8]で定義されているポリシーデータオブジェクトを使用して、COPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。セッション管理プロトコルに新しいプロトコルフィールドまたはオブジェクトを追加して、メディア認証トークンをセッション管理サーバーからエンドホストに透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造は、セッション管理プロトコル（SIP [6]など）に不透明でなければなりません。
Note that these impacts are the same as those discussed in Section 5.3 for the "One Policy Server" scenario. However the use of two Policy Servers has one additional impact:
これらの影響は、「1つのポリシーサーバー」シナリオについてセクション5.3で説明した影響と同じであることに注意してください。ただし、2つのポリシーサーバーの使用には、1つの追加の影響があります。
- Authorization protocol. A new protocol field or object MUST be added to the authorization protocol to transport the token from the RCD Policy Server to the SCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can distinguish between the elements of the token described in Section 6.2.
- 承認プロトコル。新しいプロトコルフィールドまたはオブジェクトを認証プロトコルに追加して、トークンをRCDポリシーサーバーからSCDポリシーサーバーに輸送する必要があります。このオブジェクトのコンテンツと内部構造は、ポリシーサーバーがセクション6.2で説明されているトークンの要素を区別できるように指定する必要があります。
In this scenario, the Session Management Servers and Edge Routers are associated with different Policy Servers, the network entities do not have a priori knowledge of the topology of the network and there are no pre-established trust relationships between entities in the Resource Control Domain and entities in the Service Control Domain. The key aspects of this scenario are the following:
このシナリオでは、セッション管理サーバーとエッジルーターはさまざまなポリシーサーバーに関連付けられています。ネットワークエンティティは、ネットワークのトポロジに関する先験的な知識を持っていません。サービス制御ドメインのエンティティ。このシナリオの重要な側面は次のとおりです。
- Policy decisions, including media authorization, are made by Policy Servers.
- メディア認可を含む政策決定は、ポリシーサーバーによって行われます。
- The PS in the Resource Control Domain is separate from the PS in the Service Control Domain.
- リソースコントロールドメインのPSは、サービスコントロールドメインのPSとは別のものです。
- There is a pre-defined trust relationship between the SMS and the SCD PS.
- SMSとSCD PSの間には、事前に定義された信頼関係があります。
- There is a pre-defined trust relationship between the ER and the RCD PS.
- ERとRCD PSの間には、事前に定義された信頼関係があります。
- There are no pre-defined trust relationships between the ER and SMS or between the RCD and SCD Policy Servers.
- ERとSMSの間、またはRCDとSCDポリシーサーバーの間に事前に定義された信頼関係はありません。
+--------+
+------+ | |
| | 1 +--------------------+ 2 | SCD |
| |-------->| Session Management |----->| Policy |
| |<--------| Server |<-----| Server |
| | 4 +--------------------+ 3 | |
| End | +--------+
| Host |
| | +--------+
| | 5 +--------------------+ 6 | |
| |-------->| Edge |----->| RCD |
| |<--------| Router |<-----| Policy |
| | 8 +--------------------+ 7 | Server |
+------+ | |
+--------+
Figure 5: The Non-Associated Model
図5：関連しないモデル
In this model it is assumed that the policy servers make independent decisions for their respective domains, obviating the need for information exchange between policy servers. This model also enables session authorization when communication between policy servers is not possible for various reasons. It may also be used as a means to speed up session setup and still ensure proper authorization is performed.
このモデルでは、ポリシーサーバーがそれぞれのドメインに対して独立した決定を下し、ポリシーサーバー間の情報交換の必要性を明らかにしていると想定されています。また、このモデルは、さまざまな理由でポリシーサーバー間の通信が不可能な場合にセッション許可を可能にします。また、セッションのセットアップをスピードアップし、適切な承認が実行されるようにする手段として使用することもできます。
This model does not preclude the possibility that the policy servers may communicate at other times for other purposes (e.g., exchange of accounting information).
このモデルは、ポリシーサーバーが他の目的のために他の時間に通信する可能性を排除しません（例：会計情報の交換）。
Communications between network entities in this model is described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルのネットワークエンティティ間の通信については、以下に説明します。シンプルさのために、発生する側面の流れのみが説明されています。同じ概念が終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1. エンドホストは、セッションで使用されるメディアストリームを示すセッション管理サーバーにセッションセットアップリクエスト（SIP Inviteなど）を発行します。このステップの一部として、エンドホストはセッション管理サーバーに認証する場合があります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the SCD Policy Server in order to determine if the session set-up request should be allowed to proceed.
2. セッション管理サーバーは、おそらくメディアストリームの交渉が完了するのを待った後、セッションのセットアップリクエストを続行できるかどうかを判断するために、ポリシー決定要求（例：COPS REQ）をSCDポリシーサーバーに送信します。
3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the RCD Policy Server to determine what media has been authorized.
3. SCDポリシーサーバーは、使用するメディアのパラメーターを変更した後、おそらくセッション管理サーバーに決定（COPS DECなど）を送信します。この応答には、その後、RCDポリシーサーバーが使用してメディアが承認されたものを決定できる「トークン」が含まれています。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the SCD Policy Server.
4. セッション管理サーバーは、セッションのセットアップが完了しているか、進行していることを示す、エンドホスト（例：SIP 200または183）への応答を送信します。この応答には、SCDポリシーサーバーからのトークンとともに、ネゴシエートされたメディアの説明が含まれています。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the SCD Policy Server provided via the Session Management Server.
5. エンドホストは、メディアストリームに必要なQoSを提供するために必要なリソースを予約するために、リクエスト（RSVPパスなど）を発行します。このリクエストには、セッション管理サーバーを介して提供されるSCDポリシーサーバーからのトークンが含まれています。
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the RCD Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the SCD Policy Server provided by the End Host.
6. Edgeルーターは予約要求を傍受し、リソース予約要求を続行する必要があるかどうかを判断するために、ポリシー決定要求（COPS REQなど）をRCDポリシーサーバーに送信します。このリクエストには、エンドホストが提供するSCDポリシーサーバーからのトークンが含まれています。
7. The RCD Policy Server uses this token to extract information about the media that was authorized by the SCD Policy Server. The RCD Policy Server uses this information in making its decision on whether the resource reservation should be allowed to proceed.
7. RCDポリシーサーバーは、このトークンを使用して、SCDポリシーサーバーによって承認されたメディアに関する情報を抽出します。RCDポリシーサーバーは、この情報を使用して、リソースの予約を続行する必要があるかどうかを決定します。
The Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
ポリシーサーバーは、予約するリソースのパラメーターを変更した後、決定（例：COPS DEC）をEdgeルーターに送信します。
8. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing
8. エッジルーターは、おそらくリソースを完了するためのエンドツーエンドの交渉を待った後、エンドホスト（例：RSVP RESV）への応答を送信して、リソースの予約が完了しているか、進行中であることを示しています
In this model, the token MUST contain sufficient information to allow the RCD Policy Server to make resource policy decisions autonomously from the SCD Policy Server. The token is created using information about the session received by the SMS. The information in the token MUST include:
このモデルでは、トークンには、RCDポリシーサーバーがSCDポリシーサーバーからリソースポリシーの決定を自律的に行えるようにするための十分な情報を含める必要があります。トークンは、SMSが受け取ったセッションに関する情報を使用して作成されます。トークン内の情報には以下を含める必要があります。
- Calling party name or IP address (e.g., from SDP "c=" parameter).
- パーティー名またはIPアドレスを呼び出します（例：SDP "c ="パラメーターから）。
- Called party name or IP address (e.g., from SDP "c=" parameter).
- パーティー名またはIPアドレスと呼ばれます（例：SDP "c ="パラメーターから）。
- The characteristics of (each of) the media stream(s) authorized for this session (e.g., codecs, maximum bandwidth from SDP "m=" and/or "b=" parameters).
- このセッションで許可されたメディアストリームの（それぞれ）の特性（例：コーデック、SDP "M ="の最大帯域幅、および/または「b =」パラメーター）。
- The authorization lifetime. To protect against replay attacks, the token should be valid for only a few seconds after the start time of the session.
- 承認寿命。リプレイ攻撃から保護するには、トークンはセッションの開始時間からわずか数秒間有効である必要があります。
- The identity of the authorizing entity to allow for validation of the token.
- トークンの検証を可能にする認可エンティティのアイデンティティ。
- Authentication data used to prevent tampering with the token. This authentication data is calculated over all other fields of the token using an agreed mechanism. The mechanism used by the RCD Policy Server is beyond the scope of this document.
- トークンの改ざんを防ぐために使用される認証データ。この認証データは、合意されたメカニズムを使用して、トークンの他のすべてのフィールドで計算されます。RCDポリシーサーバーが使用するメカニズムは、このドキュメントの範囲を超えています。
Furthermore, the token MAY include:
さらに、トークンには次のものが含まれます。
- The lifetime of (each of) the media stream(s) (e.g., from SDP "t=" parameter). This field may be useful in pre-paid scenarios in order to limit the lifetime of the session.
- （それぞれ）の寿命（それぞれ）のストリーム（たとえば、SDP "t ="パラメーターから）。このフィールドは、セッションの寿命を制限するために、プリペイドシナリオで役立つ場合があります。
- The Calling and called party port numbers (e.g., from the "m=" parameter).
- 呼び出しおよび呼び出された党ポート番号（たとえば、「m =」パラメーターから）。
The detailed semantics of an authorization token are defined in [4].
承認トークンの詳細なセマンティクスは[4]で定義されています。
The use of a media authorization token in the Non-Associated Model requires the addition of new fields to several protocols:
非関連モデルでメディア認証トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure of this object SHOULD be opaque to the resource reservation protocol. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトをリソース予約プロトコルに追加して、エンドホストからエッジルーターにトークンを透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造は、リソース予約プロトコルに不透明でなければなりません。たとえば、これは[8]で定義されているポリシーデータオブジェクトを備えたRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transport the token from the SCD Policy Server to the Session Management Server and from the Edge Router to the RCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can distinguish between the elements of the token described in Section 7.2. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。新しいプロトコルフィールドまたはオブジェクトをポリシー管理プロトコルに追加して、SCDポリシーサーバーからセッション管理サーバー、およびエッジルーターからRCDポリシーサーバーにトークンを輸送する必要があります。このオブジェクトのコンテンツと内部構造は、ポリシーサーバーがセクション7.2で説明されているトークンの要素を区別できるように指定する必要があります。たとえば、これは[8]で定義されているポリシーデータオブジェクトを使用して、COPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。セッション管理プロトコルに新しいプロトコルフィールドまたはオブジェクトを追加して、メディア認証トークンをセッション管理サーバーからエンドホストに透過的に輸送する必要があります。このオブジェクトのコンテンツと内部構造は、セッション管理プロトコル（SIP [6]など）に不透明でなければなりません。
This document defines three models for session set-up with media authorization:
このドキュメントでは、メディア認可を使用してセッションのセットアップの3つのモデルを定義します。
- The Coupled Model which assumes a priori knowledge of network topology and where pre-established trust relationships exist between network entities.
- ネットワークトポロジの先験的な知識と、ネットワークエンティティ間に事前に確立された信頼関係が存在する場所を想定する結合モデル。
- The Associated Model where there are common or trusted policy servers but knowledge of the network topology is not known a priori.
- 一般的なポリシーサーバーまたは信頼できるポリシーサーバーがあるが、ネットワークトポロジの知識は先験的に不明です。
- The Non-Associated Model where knowledge of the network topology is not known a priori, where there are different policy servers involved and where a trust relationship does not exist between the policy servers.
- ネットワークトポロジの知識が不明であり、さまざまなポリシーサーバーが関与し、ポリシーサーバー間に信頼関係が存在しないアプリオリで知られていない非関連モデル。
The Associated Model is applicable to environments where the network elements involved in establishing a session have a pre-determined trust relationship but where their identities must be determined dynamically during session set up. The Non-Associated Model is applicable to environments where there is a complex network topology and/or where trust relationships between domains do not exist (e.g., when they are different business entities).
関連するモデルは、セッションの確立に関与するネットワーク要素が事前に決定された信頼関係を持っているが、セッションのセットアップ中にそのアイデンティティを動的に決定する必要がある環境に適用できます。非関連モデルは、複雑なネットワークトポロジがある環境やドメイン間の信頼関係が存在しない環境に適用できます（例えば、それらが異なるビジネスエンティティである場合）。
In any given network, one or more of these models may be applicable. Indeed, the model to be used may be chosen dynamically during session establishment based on knowledge of the end points involved in the call. In all cases, however, there is no need for the End Host or the Session Management Server to understand or interpret the authorization token - to them it is an opaque protocol element that is simply copied from one container protocol to another.
特定のネットワークでは、これらのモデルの1つ以上が適用される場合があります。実際、使用するモデルは、セッションの確立中にコールに関与するエンドポイントの知識に基づいて動的に選択できます。ただし、すべての場合において、エンドホストまたはセッション管理サーバーが認証トークンを理解または解釈する必要はありません。それらには、あるコンテナプロトコルから別のコンテナプロトコルにコピーされる不透明なプロトコル要素です。
Finally, the framework defined in this document is extensible to any kind of session management protocol coupled to any one of a number of resource reservation and/or policy management protocols.
最後に、このドキュメントで定義されているフレームワークは、多数のリソース予約および/またはポリシー管理プロトコルのいずれかに組み合わされたあらゆる種類のセッション管理プロトコルに拡張可能です。
The purpose of this document is to describe a mechanism for media authorization to prevent theft of service.
このドキュメントの目的は、サービスの盗難を防ぐためのメディア許可のメカニズムを説明することです。
For the authorization token to be effective, its integrity MUST be guaranteed as it passes through untrusted network entities such as the End Host. This can be achieved by using authentication data. There is no requirement for encryption of the token since it does not contain confidential information that may be used by malicious users.
承認トークンが効果的であるためには、エンドホストなどの信頼されていないネットワークエンティティを通過するため、その完全性を保証する必要があります。これは、認証データを使用することで実現できます。悪意のあるユーザーが使用できる機密情報が含まれていないため、トークンの暗号化には要件はありません。
This document assumes that trust relationships exist between various network entities, as described in each of the models. The means for establishing these relationships are beyond the scope of this document.
このドキュメントは、各モデルで説明されているように、さまざまなネットワークエンティティ間に信頼関係が存在することを前提としています。これらの関係を確立するための手段は、このドキュメントの範囲を超えています。
The different interfaces between the network entities described in this document have different natures requiring different security characteristics:
このドキュメントで説明されているネットワークエンティティ間の異なるインターフェイスには、異なるセキュリティ特性を必要とする異なる性質があります。
- The edge router and RCD policy server MUST have a trust relationship. If necessary, this relationship can be enforced through a formal security association [14].
- エッジルーターとRCDポリシーサーバーには、信頼関係が必要です。必要に応じて、この関係は正式なセキュリティ協会を通じて実施することができます[14]。
- The network policies exchanged over the interface between edge router and RCD policy server SHOULD be integrity protected. This can be accomplished using integrity mechanisms built into the policy control protocol (e.g., the Integrity object in COPS [2]) or through generic IP security mechanisms [14].
- エッジルーターとRCDポリシーサーバーの間のインターフェイスを介して交換されたネットワークポリシーは、整合性保護されている必要があります。これは、ポリシー制御プロトコルに組み込まれた整合性メカニズム（たとえば、COPS [2]の整合性オブジェクト）または一般的なIPセキュリティメカニズム[14]を使用して達成できます。
- The SCD and RCD policy servers MUST have a trust relationship in the associated model. If necessary, this relationship can be enforced through a formal security association [14].
- SCDおよびRCDポリシーサーバーは、関連するモデルに信頼関係を持つ必要があります。必要に応じて、この関係は正式なセキュリティ協会を通じて実施することができます[14]。
- The information exchanged over the interface between policy servers SHOULD be integrity protected. This can be accomplished using integrity mechanisms built into the policy exchange protocol [2] or through generic IP security mechanisms [14].
- ポリシーサーバー間のインターフェイスを介して交換される情報は、整合性保護されている必要があります。これは、ポリシー交換プロトコル[2]に組み込まれた整合性メカニズムを使用して、または一般的なIPセキュリティメカニズム[14]を使用して達成できます。
- The end host SHOULD be authenticated by the RCD to protect against identity theft. The network resource request/responses should be protected against corruption and spoofing. Thus, the interface between host and edge router SHOULD provide integrity and authentication of messages. For example, [13] provides integrity and authentication of RSVP messages.
- エンドホストは、個人情報の盗難から保護するためにRCDによって認証される必要があります。ネットワークリソースのリクエスト/応答は、腐敗とスプーフィングから保護する必要があります。したがって、ホストルーターとエッジルーターの間のインターフェイスは、メッセージの整合性と認証を提供する必要があります。たとえば、[13]は、RSVPメッセージの整合性と認証を提供します。
- The end host SHOULD be authenticated by the SCD to protect against identity theft. The session setup request/response should be protected against corruption and spoofing. Thus, the interface between host and SMS SHOULD provide integrity and authentication of messages.
- エンドホストは、個人情報の盗難から保護するためにSCDによって認証される必要があります。セッションのセットアップリクエスト/応答は、腐敗とスプーフィングから保護する必要があります。したがって、ホストとSMSの間のインターフェイスは、メッセージの整合性と認証を提供する必要があります。
- The SMS and the SCD policy server MUST have a a trust relationship. If necessary, this relationship can be enforced through a formal security association [14].
- SMSとSCDポリシーサーバーには、信頼関係が必要です。必要に応じて、この関係は正式なセキュリティ協会を通じて実施することができます[14]。
- The network policies exchanged over the interface between the SMS and SCD policy server SHOULD be integrity protected. This can be accomplished using integrity mechanisms built into the policy control protocol (e.g., the Integrity object in COPS [2]) or through generic IP security mechanisms [14].
- SMSとSCDポリシーサーバーの間のインターフェイスを介して交換されたネットワークポリシーは、整合性保護されている必要があります。これは、ポリシー制御プロトコルに組み込まれた整合性メカニズム（たとえば、COPS [2]の整合性オブジェクト）または一般的なIPセキュリティメカニズム[14]を使用して達成できます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[2] Durham、D.、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R.、A。Sastry、「The Cops（Common Open Policy Service）Protocol」、RFC 2748、2000年1月。
[3] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[3] Herzog、S.、Boyle、J.、Cohen、R.、Durham、D.、Rajan、R.、A。Sastry、「RSVPのCOPS使用」、RFC 2749、2000年1月。
[4] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[4] Hamer、L-N。、Gage、B.、Kosinski、B。and H. Shieh、「セッション認証政策要素」、RFC 3520、2003年4月。
[5] Handley, M. and V. Jacobson, "SDP: session description protocol," RFC 2327, April 1998.
[5] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[6] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC 2205, September 1997.
[7] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[8] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[8] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[9] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[9] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。、およびA. Smith、「ポリシープロビジョニングのためのCopsの使用（COPS-PR） "、RFC 3084、2001年3月。
[10] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and P. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[10] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and P. Spence、 "AAA Authorization Framework"、RFC 2904、2000年8月。
[11] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[11] De Laat、C.、Gross、G.、Gommans、L.、Vollbrecht、J。and D. Spence、「Generic AAA Architecture」、RFC 2903、2000年8月。
[12] "PacketCable Dynamic Quality of Service Specification", CableLabs, December 1999.
[12] 「Packetcable Dynamic Quality of Service Specification」、CableLabs、1999年12月。
[13] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[13] Baker、F.、Lindell、B。and M. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[14] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[14] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
The authors would like to thank to following people for their useful comments and suggestions related to this document: Kwok Ho Chan, Doug Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois Audet, Bill Marshall, Diana Rawlins and many others.
著者は、この文書に関連する有用なコメントや提案に感謝します：Kwok Ho Chan、Doug Reeves、Sam Christie、Matt Broda、Yajun Liu、Brett Kosinski、Francois Oudet、Bill Marshall、Diana Rawlinsなど。
Louis-Nicolas Hamer Nortel Networks PO Box 3511 Station C Ottawa, ON CANADA K1Y 4H7
Louis-Nicolas Hamer Nortel Networks PO Box 3511 Station C Ottawa、カナダK1Y 4H7
Phone: +1 613.768.3409
EMail: nhamer@nortelnetworks.com
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa, ON CANADA K1Y 4H7
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa、カナダK1Y 4H7
Phone: +1 613.763.4400
EMail: gageb@nortelnetworks.com
Hugh Shieh AT&T Wireless 7277 164th Avenue NE Redmond, WA USA 98073-9761
Hugh Shieh AT＆Tワイヤレス7277 164th Avenue Ne Redmond、WA USA 98073-9761
Phone: +1 425.580.6898
EMail: hugh.shieh@attws.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。