Network Working Group J. Kempf, Ed.
Request for Comments: 3374 September 2002
Category: Informational
Problem Description: Reasons For Performing Context Transfers
Between Nodes in an IP Access Network
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service (QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". This document discusses the desirability of context transfer for facilitating seamless IP mobility.
ホストの移動性をサポートするIPアクセスネットワークでは、ホストとネットワークの間のルーティング経路が頻繁にかつ迅速に変更することができます。いくつかのケースでは、ホストは、ホスト移動置き去りにされているサブネット上の特定のコンテキスト転送候補サービスを確立することができます。そのようなサービスの例としては、認証、許可、アカウンティング（AAA）、ヘッダ圧縮、およびサービス品質（QoS）です。ホストが新しいサブネット上でそれらのサービスを取得するためには、ホストを明示的にゼロから必要なシグナリングフローを実行することにより、サービスを再確立する必要があります。いくつかのケースでは、このプロセスはかなり新しいサブネット上のモバイルホストを確立するプロセスを遅らせるだろう。代替は、新しいサブネットに、「コンテキスト転送」と呼ばれるプロセスをこれらのサービス、またはコンテキストに関連付けられた既存の状態に関する情報を転送することです。この文書では、シームレスなIPモビリティを容易にするためのコンテキスト転送の望ましさを論じています。
Table of Contents
目次
1.0 Introduction................................................2
2.0 Reference Definitions.......................................3
3.0 Scope of the Context Transfer Problem.......................3
4.0 The Need for Context Transfer...............................4
4.1 Fast Context Transfer-candidate Service Re-establishment....4
4.1.1 Authentication, Authorization, and Accounting (AAA).........4
4.1.2 Header Compression..........................................5
4.1.3 Quality of Service (QoS)....................................6
4.2 Interoperability............................................6
5.0 Limitations on Context Transfer.............................7
5.1 Router Compatibility........................................7
5.2 Requirement to Re-initialize Service from Scratch...........7
5.3 Suitability for the Particular Service......................7
5.4 Layer 2 Solutions Better....................................7
6.0 Performance Considerations..................................8
7.0 Security Considerations.....................................8
8.0 Recommendations.............................................9
9.0 Acknowledgements............................................9
10.0 References.................................................10
11.0 Complete List of Authors' Addresses........................12
12.0 Full Copyright Statement...................................14
In networks where the hosts are mobile, the routing path through the network must often be changed in order to deliver the host's IP traffic to the new point of access. Changing the basic routing path is the job of a IP mobility protocol, such as Mobile IPv4 [1] and Mobile IPv6 [2]. But the success of real time services such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of the impact of this traffic redirection. In the process of establishing the new routing path, the nodes along the new path must be prepared to provide similar routing treatment to the IP packets as was provided along the old routing path.
ホストが携帯しているネットワークでは、ネットワークを介してルーティングパスは、多くの場合、アクセスの新しいポイントにホストのIPトラフィックを配信するために変更する必要があります。基本的なルーティング経路を変更すると、そのようなモバイルIPv4 [1]及びモバイルIPv6 [2]のようなIPモビリティプロトコルのジョブです。しかし、モバイル環境でのなどのVoIP電話、ビデオ、などのリアルタイムサービスの成功は、このトラフィックのリダイレクトの影響の最小化に大きく依存します。新しいルーティングパスを確立するプロセスでは、新しいパスに沿ったノードは、古いルーティングパスに沿って提供されたように、IPパケットに類似したルーティング処理を提供するために用意されなければなりません。
In many cases, the routing treatment of IP packets within a network may be regulated by a collection of context transfer-candidate services that influence how packets for the host are treated. For example, whether a particular host has the right to obtain any routing at all out of the local subnet may depend on whether the host negotiated a successful AAA exchange with a network access server at some point in the past. Establishing these services initially results in a certain amount of related state within the network and requires a perhaps considerable amount of time for the protocol exchanges. If the host is required to re-establish those services by the same process as it uses to initially establish them, delay-sensitive real time traffic may be seriously impacted.
多くの場合、ネットワーク内のIPパケットのルーティング処理は、ホストのパケットが処理される方法に影響を与える文脈転送候補サービスの集合体によって調節することができます。たとえば、特定のホストがローカルサブネットの外に全くルーティングを取得する権利を有するかどうかをホストが、過去のある時点で、ネットワークアクセスサーバとAAA成功した交換をネゴシエートするかどうかに依存し得ます。これらのサービスを確立することは、最初に、ネットワーク内の関連する状態の一定量をもたらし、プロトコル交換のための時間の、おそらくかなりの量を必要とします。それは最初にそれらを確立するために使用するとホストが同じプロセスでそれらのサービスを再確立する必要がある場合、遅延に敏感なリアルタイムトラフィックが深刻な影響を受ける可能性があります。
An alternative is to transfer enough information on the context transfer-candidate service state, or context, to the new subnet so that the services can be re-established quickly, rather than require the mobile host to establish them from scratch. The transfer of service context may be advantageous in minimizing the impact of host mobility on, for example, AAA, header compression, QoS, policy, and possibly sub-IP protocols and services such as PPP. Context transfer at a minimum can be used to replicate the configuration information needed to establish the respective protocols and services. In addition, it may also provide the capability to replicate state information, allowing stateful protocols and services at the new node to be activated along the new path with less delay and less signaling overhead.
代替サービスが迅速に再確立することができるように、新しいサブネットに、コンテキスト転送候補サービス状態、または文脈に十分な情報を転送するのではなく、最初からそれらを確立するために、モバイルホストを必要とすることです。サービスコンテクストの転送は、例えば、上のホストの移動性の影響を最小化するのに有利であり得る、AAA、ヘッダ圧縮、PPPなどのQoSポリシー、及びおそらくはサブIPプロトコルとサービス。最低でもコンテキスト転送は、それぞれのプロトコルやサービスを確立するために必要な設定情報を複製するために使用することができます。加えて、それはまた、より少ない遅延、より少ないシグナリングオーバーヘッドと新経路に沿って活性化される新しいノードにステートフルプロトコルおよびサービスを可能にする、状態情報を複製する能力を提供することができます。
In this document, a case is made for why the Seamoby Working Group should investigate context transfer.
この文書では、ケースはSeamobyワーキンググループは、コンテキスト転送を調査する必要がある理由のために作られています。
Context
状況
The information on the current state of a service required to re-establish the service on a new subnet without having to perform the entire protocol exchange with the mobile host from scratch.
サービスの現在の状態に関する情報を最初から移動ホストとの全体のプロトコル交換を実行することなく、新しいサブネットにサービスを再確立するのに必要な。
Context Transfer
コンテキスト転送
The movement of context from one router or other network entity to another as a means of re-establishing specific services on a new subnet or collection of subnets.
サブネットの新しいサブネットまたはコレクションに特定のサービスを再確立する手段として、別のルータまたは他のネットワークエンティティからのコンテキストの動き。
Context Transfer Candidate Service
文脈転送候補サービス
A service that is a candidate for context transfer. In this document, only services that are concerned with the forwarding treatment of packets, such as QoS and security, or involve granting or denying the mobile host access to the network, such as AAA, are considered to be context transfer-candidate services.
コンテキスト転送のための候補であるサービス。例えばAAA、この文書は、このようなQoSやセキュリティなどのパケットの転送処理に関係しているサービスのみ、またはネットワークへのモバイルホストのアクセスを許可または拒否含んで、コンテキスト転送候補サービスであると考えられます。
The context transfer problem examined in this document is restricted to re-establishing services for a mobile host that are, in some sense, related to the forwarding treatment of the mobile host's packets or network access for the mobile host. It is not concerned with actually re-establishing routing information. Routing changes due to mobility are the domain of the IP mobility protocol. In addition, transfer of context related to application-level services, such as those associated with the mobile host's HTTP proxy, is also not considered in this document, although a generic context transfer protocol for transferring the context of services related to forwarding treatment or network access may also function for application-level services as well.
この文書で検討コンテキスト転送の問題は、ある意味では、モバイルホストのためのモバイルホストのパケットやネットワークアクセスの転送処理に関連しているモバイルホストの再構築のサービスに制限されています。それは実際にルーティング情報を再確立すると心配していないです。モビリティによるルーティングの変更は、IPモビリティプロトコルのドメインです。加えて、そのようなモバイルホストのHTTPプロキシに関連するものなど、アプリケーションレベルのサービスに関連するコンテキストの転送は、また、転送処理やネットワークに関連するサービスのコンテキストを転送するための一般的なコンテキスト転送プロトコルが、本書では考慮されていませんアクセスも同様に、アプリケーションレベルのサービスのために機能することができます。
An important consideration in whether a service is a candidate for context transfer is whether it is possible to obtain a "correct" context transfer for the service in a given implementation and deployment, that is, one which will result in the same context at the new access router as would have resulted had the mobile host undergone a protocol exchange with the access router from scratch. For some services, the circumstances under which context transfer may result in correctness may be very limited [11].
サービスは、コンテキスト転送のための候補であるかどうかで考慮すべき重要な点は、つまり、所与の実装と展開にサービスのための「正しい」コンテキスト転送を得ることが可能であるかどうか、新しいのと同じ状況になりますものですアクセスルータは、モバイルホストは最初からアクセスルータとのプロトコル交換を受けた結果だろう。一部のサービスでは、コンテキスト転送が正当で生じ得る状況下では、非常に制限されてもよい[11]。
There are two basic motivations for context transfer:
コンテキスト転送のための2つの基本的な動機があります。
1) The primary motivation, as mentioned in the introduction, is the need to quickly re-establish context transfer-candidate services without requiring the mobile host to explicitly perform all protocol flows for those services from scratch.
1）第一の動機は、冒頭で述べたように、明示的にすべてのプロトコルを実行するために移動ホストを必要とすることなく、必要すばやく再確立するコンテキスト転送候補サービスは、最初からそれらのサービスのために流れます。
2) An additional motivation is to provide an interoperable solution that works for any Layer 2 radio access technology.
2）追加的な動機は、任意のレイヤ2の無線アクセス技術のために働く相互運用可能なソリューションを提供することです。
These points are discussed in more detail in the following subsections.
これらの点は、以下のサブセクションで詳しく説明されています。
As mentioned in the introduction, there are a variety of context transfer-candidate services that could utilize a context transfer solution. In this section, three representative services are examined. The consequences of not having a context transfer solution are examined as a means of motivating the need for such a solution.
冒頭で述べたように、コンテキスト転送ソリューションを利用することができるコンテキスト転送候補のさまざまなサービスが存在します。このセクションでは、3つの代表的なサービスが検討されています。コンテキスト転送溶液を有さないの結果は、そのような解決策の必要性が動機の手段として検討されています。
One of the more compelling applications of context transfer is facilitating the re-authentication of the mobile host and re-establishment of the mobile host's authorization for network access in a new subnet by transferring the AAA context from the mobile host's previous AAA server to another. This would allow the mobile host to continue access in the new subnet without having to redo an AAA exchange with the new subnet's AAA server. Naturally, a security association between the AAA servers is necessary so that the mobile host's sensitive authentication information can be securely transferred.
コンテキスト転送のより魅力的なアプリケーションの一つは、他にモバイルホストの前のAAAサーバからAAAコンテキストを転送することによって、モバイルホストと新しいサブネット内のネットワークアクセスのためのモバイルホストの認証の再確立の再認証を促進されます。これは、モバイルホストが新しいサブネットのAAAサーバとAAA交換をやり直すことなく、新しいサブネット内のアクセスを継続することができるようになります。モバイルホストの敏感な認証情報を確実に転送することができるように自然に、AAAサーバとの間のセキュリティアソシエーションが必要です。
In the absence of context transfer, there are two ways that can currently be used for AAA:
コンテキスト転送の非存在下で、現在のAAAのために使用することができる2つの方法があります。
1) Layer 2 mechanisms, such as EAP [3] in PPP [4] or 802.1x [5] can be used to redo the initial protocol exchange, or possibly to update it. Currently, there is no general Layer 3 mechanism for conducting an AAA exchange between a host and an AAA server in the network.
1）このようなEAPのような2つの機構を、レイヤ[3] PPPで[4]または802.1X [5]を更新するために、おそらく最初のプロトコル交換をやり直すか、またはするために使用することができます。現在、ネットワーク内のホストとAAAサーバの間でAAA交換を行うための一般的なレイヤ3のメカニズムはありません。
2) If the mobile host is using Mobile IPv4 (but not Mobile IPv6 currently), the host can use the AAA registration keys [6] extension for Mobile IPv4 to establish a security association with the new Foreign Agent.
モバイルホストは現在、モバイルIPv4（ただし、モバイルIPv6）を使用している場合は、モバイルIPv4は、新しい外部エージェントとのセキュリティアソシエーションを確立するため2）、ホストは、AAAの登録キー[6]拡張を使用することができます。
Since 2) is piggybacked on the Mobile IPv4 signaling, the performance is less likely to be an issue, but 2) is not a general solution. The performance of 1) is likely to be considerably less than is necessary for maintaining good real time stream performance.
2）モバイルIPv4シグナリングにピギーバックされるので、性能が問題になりにくいが、2）一般的な解決策ではありません。 1のパフォーマンスは）良いリアルタイムストリームのパフォーマンスを維持するために必要であるよりもかなり少なくなる可能性があります。
In [7], protocols are described for efficient compression of IP headers to avoid sending large headers over low bandwidth radio network links. Establishing header compression generally requires from 1 to 4 exchanges between the last hop router and the mobile host with full or partially compressed headers before full compression is available. During this period, the mobile host will experience an effective reduction in the application-available bandwidth equivalent to the uncompressed header information sent over the air. Limiting the uncompressed traffic required to establish full header compression on a new last hop router facilitates maintaining adequate application-available bandwidth for real time streams, especially for IPv6 where the headers are larger.
[7]において、プロトコルは、低帯域幅の無線ネットワークリンクを介して大ヘッダを送信することを避けるために、IPヘッダの効率的な圧縮のために記載されています。完全な圧縮が使用可能になる前にヘッダ圧縮を確立することは、一般的に1から最後のホップルータと完全または部分的に圧縮ヘッダを持つモバイルホストとの間の4交換する必要があります。この期間中、モバイルホストは、空気を介して送信される非圧縮ヘッダ情報に相当するアプリケーションの利用可能な帯域幅で有効な減少を経験します。新しいラストホップルータでフルヘッダー圧縮を確立するために必要な圧縮されていないトラフィックを制限すること、特にヘッダが大きくなっているIPv6のため、リアルタイム・ストリームのための適切なアプリケーションに利用可能な帯域幅を維持することが容易。
Context transfer can help in this case by allowing the network entity performing header compression, usually the last hop router, to transfer the header compression context to the new router. The timing of context transfer must be arranged so that the header context is transferred from the old router as soon as the mobile host is no longer receiving packets through the old router, and installed on the new router before any packets are delivered to or forwarded from the mobile host.
コンテキスト転送は、新しいルータにヘッダ圧縮コンテキストを転送するために、ヘッダ圧縮、通常、最後のホップルータを実行するネットワークエンティティを可能にすることにより、この場合に役立つことができます。ヘッダコンテキストが新しいルータに移動ホストがもはや古いルータを介してパケットを受信するとすぐに古いルータから転送されず、インストールされているように、任意のパケットがに送達またはから転送される前にコンテキスト転送のタイミングは、配置されなければなりませんモバイルホスト。
Significant QoS protocol exchanges between the mobile host and routers in the network may be required in order to establish the initial QoS treatment for a mobile host's packets. The exact mechanism whereby QoS for a mobile host should be established is currently an active topic of investigation in the IETF. For existing QoS approaches (Diffsrv and Intsrv) preliminary studies have indicated that the protocol flows necessary to re-establish QoS in a new subnet from scratch can be very time consuming for Mobile IP, and other mobility protocols may suffer as well.
ネットワーク内の移動ホストとルータ間で有効なQoSプロトコル交換は、モバイルホストのパケットのための最初のQoS処理を確立するために必要な場合があります。モバイルホストのQoSが確立されなければならないとなる正確なメカニズムは、現在IETFにおける調査のアクティブな話題です。既存のQoSアプローチ（DiffsrvとIntsrv）のための予備的研究では、プロトコルは、モバイルIPのために非常に時間がかかることができ、ゼロから新しいサブネットにQoSを再確立する必要が流れていることを示している、と他のモビリティプロトコルも同様に低下することがあります。
A method of transferring the mobile host's QoS context from the old network to the new could facilitate faster re-establishment of the mobile host's QoS treatment on the new subnet. However, for QoS mechanisms that are end-to-end, transferring context at the last hop router may be insufficient to completely re-initialize the mobile host's QoS treatment, since some number of additional routers in the path between the mobile host and corresponding node may also need to be involved.
新しい古いネットワークからモバイルホストのQoSコンテキストを転送する方法は、新しいサブネット上のモバイルホストのQoS処理の高速化の再構築を容易にすることができます。しかし、QoSメカニズムのための移動ホストと対応するノードとの間の経路における追加のルータのいくつかの数ので、完全にモバイルホストのQoS処理を再初期化するのに不十分であり得る最後のホップルータにコンテキストを転送し、エンド・ツー・エンドであることまた、関与する必要があります。
A particular concern for seamless handover is that different Layer 2 radio protocols may define their own solutions for context transfer. There are ongoing efforts within 3GPP [8] and IEEE [9] to define such solutions. These solutions are primarily designed to facilitate the transfer of Layer 2-related context over a wired IP network between two radio access networks or two radio access points. However, the designs can include extensibility features that would allow Layer 3 context to be transferred. Such is the case with [10], for example.
シームレスハンドオーバのための特定の関心は、異なるレイヤ2の無線プロトコルは、コンテキスト転送のための独自のソリューションを定義することができるということです。そのようなソリューションを定義するために、3GPP [8]、[9] IEEE内の継続的な努力があります。これらのソリューションは、主に次の2つの無線アクセスネットワーク又は二無線アクセスポイントとの間の有線IPネットワークを介してレイヤ2関連のコンテキストの転送を容易にするように設計されています。しかし、デザインは、レイヤ3のコンテキストを転送することができるようになる拡張機能を含めることができます。そのような、例えば、[10]の場合です。
If Layer 2 protocols were to be widely adopted as an optimization measure for Layer 3 context transfer, seamless mobility of a mobile host having Layer 2 network interfaces that support multiple radio protocols would be difficult to achieve. Essentially, a gateway or translator between Layer 2 protocols would be required, or the mobile host would be required to perform a full re-initialization of its context transfer-candidate services on the new radio network, if no translator were available, in order to hand over a mobile host between two access technologies.
レイヤ2つのプロトコルが広くレイヤ3コンテキスト転送、複数の無線プロトコルをサポートするレイヤ2ネットワークインターフェースを有するモバイルホストのシームレスな移動性の最適化の尺度として採用されるならば達成することは困難であろう。本質的に、レイヤ2つのプロトコルとの間のゲートウェイまたはトランスレータが必要とされるであろう、または全く翻訳者が利用可能でない場合、モバイルホストはするために、新しい無線ネットワーク上のコンテキスト転送候補サービスの完全な再初期化を実行するために必要とされます2つのアクセス技術間のモバイルホストを引き渡します。
A general Layer 3 context transfer solution may also be useful for Layer 2 protocols that do not define their own context transfer protocol. Consideration of this issue is outside the scope of the Seamoby Working Group, however, since it depends on the details of the particular Layer 2 protocol.
一般的なレイヤ3コンテキスト転送ソリューションは、独自のコンテキスト転送プロトコルを定義していないレイヤ2プロトコルのために有用であり得ます。それは、特定のレイヤ2プロトコルの詳細に依存するため、この問題の検討は、しかし、Seamobyワーキンググループの範囲外です。
Context transfer may not always be the best solution for re-establishing context transfer-candidate services on a new subnet. There are certain limitations on when context transfer may be useful. These limitations are discussed in the following subsections.
コンテキスト転送は、常に新しいサブネット上で再確立文脈転送候補サービスのための最善の解決策ではないかもしれません。コンテキスト転送が有用である可能性があるときに一定の制限があります。これらの制限は以下のサブセクションで説明されています。
Context transfer between two routers is possible only if the receiving router supports the same context transfer-candidate services as the sending router. This does not mean that the two nodes are identical in their implementation, nor does it even imply that they must have identical capabilities. A router that cannot make use of received context should refuse the transfer. This results in a situation no different than a mobile host handover without context transfer, and should not be considered an error or failure situation.
2つのルータ間のコンテキスト転送は、受信ルータが送信するルータと同じ文脈転送候補サービスをサポートしている場合にのみ可能です。これは、2つのノードがその実施に同一であることを意味するものではありません、またそれも、彼らは同じ機能を持っていなければならないことを意味するものではありません。受け取ったコンテキストを利用することができないルータが転送を拒否すべきです。これは、コンテキスト転送せずにモバイルホストのハンドオーバよりも変わらない状況になり、エラーや障害状況と考えるべきではありません。
The primary motivation for context transfer assumes that quickly re-establishing the same level of context transfer-candidate service on the new subnet is desirable. And yet, there may be situations where either the device or the access network would prefer to re-establish or re-negotiate the level of service. For example, if the mobile host crosses administrative domains where the operational policies change, negotiation of a different level of service may be required.
コンテキスト転送のための主な動機は、すぐに新しいサブネット上の文脈転送候補同じレベルのサービスを再確立することが望ましいことを前提としています。そして、まだ、デバイスまたはアクセスネットワークのいずれかを再確立またはサービスのレベルを再交渉することを好むだろうな状況があるかもしれません。モバイルホストは運用ポリシーが変更管理ドメインを横断した場合、サービスの異なるレベルの交渉が必要になることがあります。
Context transfer assumes that it is faster to establish the service by context transfer rather than from scratch. This may not be true for certain types of service, for example, multicast, "push" information services.
コンテキスト転送は、コンテキスト転送ではなく、最初からサービスを確立するために高速であることを前提としています。これは、例えば、マルチキャスト、「プッシュ」情報サービスサービスの特定の種類の真実ではないかもしれません。
Context transfer is an enhancement to improve upon the performance of a handover for Layer 3 context transfer-candidate services. Many networks provide support for handover at Layer 2, within and between subnets. Layer 3 context transfer may not provide a significant improvement over Layer 2 solutions, even for Layer 3 context, if the handover is occurring between two subnets supporting the same Layer 2 radio access technology.
コンテキスト転送は、レイヤ3コンテキスト転送候補サービスのハンドオーバの性能を改善する拡張です。多くのネットワークは、サブネット内との間で、レイヤ2でのハンドオーバのためのサポートを提供しています。ハンドオーバが同じレイヤ2の無線アクセス技術をサポートする2つのサブネット間で発生している場合は、レイヤ3コンテキスト転送は、偶数層3コンテキストに対して、レイヤ2ソリューション上有意な改善を提供しないかもしれません。
The purpose of context transfer is to sustain the context transfer-candidate services being provided to a mobile host's traffic during handover. It is essentially an enhancement to IP mobility that ultimately must result in an improvement in handover performance. A context transfer solution must provide performance that is equal to or better than re-initializing the context transfer-candidate service between the mobile host and the network from scratch. Otherwise, context transfer is of no benefit.
コンテキスト転送の目的は、ハンドオーバー中のモバイルホストのトラフィックに提供されているコンテキスト転送候補サービスを維持することです。それは本質的に、最終的にハンドオーバー性能の向上につながる必要がありますIPモビリティを向上させたものです。コンテキスト転送溶液に等しい又はモバイルホストとゼロからネットワーク間のコンテキスト転送候補サービスを再初期化よりも優れている性能を提供しなければなりません。それ以外の場合は、コンテキスト転送は無い利点があります。
Any context transfer standard must provide mechanism for adequately securely the context transfer process, and a recommendation to deploy security, as is typically the case for Internet standards. Some general considerations for context transfer security include:
通常、インターネット標準の場合のように、任意のコンテキスト転送規格では、十分に安全にコンテキスト転送プロセスのためのメカニズム、およびセキュリティを展開する勧告を提供しなければなりません。コンテキスト転送セキュリティのためのいくつかの一般的な考慮事項は次のとおりです。
- Information privacy: the context may contain information which the end user or network operator would prefer to keep hidden from unauthorized viewers.
- 情報のプライバシー：コンテキストは、エンドユーザやネットワークオペレータが不正な視聴者から隠しておくことを好むだろうな情報が含まれていてもよいです。
- Transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving router, and therefore could potentially affect the operation of the access network itself. The potential threats include denial of service and theft of service attacks.
- 転送正当性：虚偽または故意に破損したコンテキスト転送は、受信ルータの動作時に深刻な影響を及ぼす可能性があり、したがって、潜在的にアクセスネットワーク自体の動作に影響を与える可能性があります。潜在的な脅威は、サービスとサービス攻撃の窃盗の否定を含んでいます。
- Security preservation: part of the context transfer may include information pertinent to a security association established between the mobile host and another entity on the network. For this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures.
- セキュリティ保全：コンテキスト転送の一部がモバイルホストとネットワーク上の別のエンティティとの間で確立されたセキュリティアソシエーションに関連する情報を含むことができます。このセキュリティアソシエーションは、ハンドオーバ中に保持するために、セキュリティコンテキストの転送は、適切なセキュリティ対策を含める必要があります。
It is expected that the measures used to secure the transport of information between peers (e.g., IPSEC [10]) in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions.
IPネットワーク内のピア（例えば、IPSEC [10]）との間の情報の転送を確保するために使用される手段は、コンテキスト転送のために十分であるべきであることが期待されます。しかし、上記の考察与えられ、利用できるIETFソリューションを超えた追加のセキュリティ対策を提供するための理由があるかもしれません。
Since context transfer requires a trust relationship between network entities, the compromise of only one of the network entities that transfer context may be sufficient to reduce the security of the whole system, if for example the context transferred includes encryption keying material. When the host moves from the compromised network entity to an uncompromised network entity in the presence of context transfer, the compromised context may be used to decrypt the communication channel. When context transfer is not used, a compromise of only one network entity only gives access to what that network entity can see. When the mobile host moves to an uncompromised network entity in the absence of context transfer, security can be re-established at the new entity. However, to the extent that context transfer happens primarily between routers, the security of context transfer will depend on the security of the routers. Any compromise of security on a router that affects context transfer may also lead to other, equally serious disruptions in network traffic.
コンテキスト転送は、ネットワークエンティティ間の信頼関係、一方のみコンテキストを転送するネットワークエンティティのの妥協を必要とするので、例えば転送コンテキストは、暗号化キーイングマテリアルが含まれている場合、システム全体のセキュリティを低下させるのに十分であり得ます。ホストは、コンテキスト転送の存在下で、妥協のないネットワークエンティティに損なわれたネットワークエンティティから移動するとき、妥協コンテキストは、通信チャネルを復号するために使用することができます。コンテキスト転送を使用しない場合は、唯一のネットワークエンティティの妥協はそのネットワークエンティティが見ることができるものへのアクセスを提供します。モバイルホストは、コンテキスト転送の不存在下で妥協のないネットワークエンティティに移動すると、セキュリティが新しいエンティティで再確立することができます。しかし、コンテキスト転送は、主にルータ間で起きる程度に、コンテキスト転送のセキュリティは、ルータのセキュリティに依存します。コンテキスト転送に影響を及ぼし、ルータのセキュリティの一切の妥協は、ネットワークトラフィックの他、均等に深刻な混乱につながる可能性があります。
The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions.
コンテキスト転送の調査は、既存または新興IETFソリューションの能力を超えるコンテキスト転送のために必要な新しいセキュリティ対策を特定しなければなりません。
The following steps are recommended for Seamoby:
次の手順はSeamobyのために推奨されます。
- Investigation into candidate router-related services for context and an analysis of the transfer requirements for each candidate;
- コンテキストと各候補に対する転送要求の分析のための候補ルータ関連サービスの調査。
- The development of a framework and protocol(s) that will support the transfer of context between the routing nodes of an IP network.
- IPネットワークのルーティングノード間のコンテキストの転送をサポートするフレームワークとプロトコル（単数または複数）の開発。
The context transfer solution must inter-work with existing and emerging IP protocols, in particular, those protocols supporting mobility in an IP network.
コンテキスト転送ソリューション特に、これらのプロトコルは、IPネットワークにおけるモビリティをサポートし、既存および新興のIPプロトコルとの相互動作しなければなりません。
The editor would like to thank the Seamoby CT design team (listed at the end of the document as co-authors), who were largely responsible for the initial content of this document, for their hard work, and especially Gary Kenward, who shepherded the document through its initial versions.
エディタは牧特にゲイリーKenwardを、彼らのハードワークのために、このドキュメントの初期の内容に大きく関与した、（共著者として文書の最後に記載されている）Seamoby CTのデザインチームに感謝し、したいと思いますその初期のバージョンを通じて文書。
[1] Perkins, C., "IP Mobility Support", RFC 3220, January 2002.
[1]パーキンス、C.、 "IPモビリティサポート"、RFC 3220、2002年1月。
[2] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[2]ジョンソン、D.とC.パーキンス、 "IPv6におけるモビリティサポート"、進行中の作業。
[3] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[3]ブルンク、L.及びVollbrecht、J.、 "PPP拡張認証プロトコル（EAP）"、RFC 2284、1998年3月。
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[4]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[5] IEEE Std. P802.1X/D11, "Standard for Port based Network Access Control", March 2001.
[5] IEEE STD。 、2001年3月P802.1X / D11、「ネットワークアクセス制御ベースのポートのための標準」。
[6] Perkins, C., and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.
[6]パーキンス、C.、およびP.カルフーン、 "モバイルIPのためのAAAの登録キー" が進行中で働いています。
[7] Borman, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren T., Le, K., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[7]ボーマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、L.、Hakenberg、R.、コレンT.、ル、K.、Martenssonから、A 。、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、 "ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、ESP、および非圧縮"、RFC 3095、2001年7月。
[8] 3GPP TR 25.936 V4.0.0, "Handovers for Real Time Services from PS Domain," 3GPP, March 2001.
[8] 3GPP TR 25.936 V4.0.0、 "PSドメインからのリアルタイムサービスのためのハンドオーバー、" 3GPP、2001年3月。
[9] IEEE Std. 802.11f/D2.0, "Draft Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," July 2001.
[9] IEEE STD。 2001年7月802.11f / D2.0、「IEEE 802.11動作をサポート流通システム、全体でインターアクセスポイントプロトコル経由でマルチベンダーアクセスポイントの相互運用性のための練習を推奨ドラフト」。
[10] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10]ケント、S.とアトキンソン、R.、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[11] Aboba, B. and M. Moore, "A Model for Context Transfer in IEEE 802", Work in Progress.
[11] Aboba、B.及びM.ムーア、 "IEEE 802におけるコンテキスト転送のためのモデル"、ProgressのWork。
O. Henrik Levkowetz A Brand New World Osterogatan 1 S-164 28 Kista SWEDEN
O.ヘンリクLevkowetz A真新しい世界Osterogatan 1つのS-164 28シスタSWEDEN
Phone: +46 8 477 9942 EMail: henrik@levkowetz.com
電話：+46 8 477 9942 Eメール：henrik@levkowetz.com
Pat R. Calhoun Black Storm Networks 110 Nortech Parkway San Jose CA 95134 USA
パットR.カルフーンブラックストームネットワーク110 NortechパークウェイサンノゼCA 95134 USA
Phone: +1 408-941-0500 EMail: pcalhoun@bstormnetworks.com
電話：+1 408-941-0500電子メール：pcalhoun@bstormnetworks.com
James Kempf NTT DoCoMo USA Laboratories 181 Metro Drive, Suite 300 San Jose, CA 95110 USA
ジェームズ・ケンプNTTドコモUSA研究所181メトロドライブ、スイート300サンノゼ、CA 95110 USA
Phone: 408-451-4711 EMail: kempf@docomolabs-usa.com
電話：408-451-4711 Eメール：kempf@docomolabs-usa.com
Gary Kenward Nortel Networks 3500 Carling Avenue Nepean, Ontario K2G 6J8 CANADA
ゲイリーKenward Nortel Networksの3500カーリングアベニューオタワ、オンタリオK2G 6J8 CANADA
Phone: +1 613-765-1437 EMail: gkenward@nortelnetworks.com
電話：+1 613-765-1437電子メール：gkenward@nortelnetworks.com
Hamid Syed Nortel Networks 100 Constellation Crescent Nepean Ontario K2G 6J8 CANADA
ハミド・サイードノーテルネットワーク100星座クレセントオタワオンタリオK2G 6J8 CANADA
Phone: +1 613 763-6553 EMail: hmsyed@nortelnetworks.com
電話：+1 613 763-6553 Eメール：hmsyed@nortelnetworks.com
Jukka Manner Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND
コンピュータサイエンス、ヘルシンキ大学、私書箱のユッカマナー教室ボックス26（インダストリアル・ストリート23）FIN-00014ヘルシンキフィンランド
Phone: +358-9-191-44210 EMail: jmanner@cs.helsinki.fi
電話：+ 358-9-191-44210 Eメール：jmanner@cs.helsinki.fi
Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 USA
マジドNakhjiriモトローラ1501西シュアードライブアーリントンハイツIL 60004 USA
Phone: +1 847-632-5030 EMail: madjid.nakhjiri@motorola.com
電話：+1 847-632-5030電子メール：madjid.nakhjiri@motorola.com
Govind Krishnamurthi Communications Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington MA 01803 USA
Govind Krishnamurthi通信システム研究所、ノキア・リサーチセンター5道端の道路バーリントンMA 01803 USA
Phone: +1 781 993 3627 EMail: govind.krishnamurthi@nokia.com
電話：+1 781 993 3627 Eメール：govind.krishnamurthi@nokia.com
Rajeev Koodli Communications Systems Lab, Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
ラジーブKoodli通信システム研究所、ノキア・リサーチセンター313フェアチャイルドドライブマウンテンビューCA 94043 USA
Phone: +1 650 625 2359 EMail: rajeev.koodli@nokia.com
電話：+1 650 625 2359 Eメール：rajeev.koodli@nokia.com
Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1P 6E2 CANADA
Kulwinder S. Atwal Zucottoワイヤレス株式会社オタワオンタリオK1P 6E2 CANADA
Phone: +1 613 789 0090 EMail: kulwinder.atwal@zucotto.com
電話：+1 613 789 0090 Eメール：kulwinder.atwal@zucotto.com
Michael Thomas Cisco Systems 375 E Tasman Rd San Jose CA 95134 USA
マイケル・トーマスシスコシステムズ375 EタスマンRdのサンノゼCA 95134 USA
Phone: +1 408 525 5386 EMail: mat@cisco.com
電話：+1 408 525 5386 Eメール：mat@cisco.com
Mat Horan COM DEV Wireless Group San Luis Obispo CA 93401 USA
マット・ホランCOM DEVワイヤレスグループサンルイスオビスポCA 93401 USA
Phone: +1 805 544 1089 EMail: mat.horan@comdev.cc
電話：+1 805 544 1089 Eメール：mat.horan@comdev.cc
Phillip Neumiller 3Com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA
フィリップNeumillerの3Com社1800 W.中央道路マウントプロスペクトIL 60056 USA
EMail: phil_neumiller@3com.com
メールアドレス：phil_neumiller@3com.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。