[要約] RFC 3374は、IPアクセスネットワーク内のノード間でコンテキスト転送を行う理由について説明しています。このRFCの目的は、コンテキスト転送の必要性と利点を明確にすることです。
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
問題の説明：IPアクセスネットワーク内のノード間のコンテキスト転送を実行する理由
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.
Copyright（c）The Internet Society（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、ヘッダー圧縮、QOS、ポリシー、およびPPPなどのサブIPプロトコルや場合によってはサブ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.
コンテキスト転送の候補者であるサービス。このドキュメントでは、QoSやセキュリティなどのパケットの転送処理に関係するサービスのみ、またはAAAなどのネットワークへのモバイルホストアクセスを許可または拒否することは、コンテキスト転送サービスサービスと見なされます。
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.
コンテキスト転送のより魅力的なアプリケーションの1つは、モバイルホストの再認証を促進し、モバイルホストの以前のAAAサーバーから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) PPP [4]または802.1x [5]のEAP [3]などのレイヤー2メカニズムを使用して、初期プロトコル交換をやり直すか、または更新することができます。現在、ネットワーク内のホストと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.
2) モバイルホストがモバイルIPv4を使用している場合（現在はモバイルIPv6ではなく）、ホストはモバイルIPv4の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）の予備調査は、新しいサブネットでQOSをゼロから再確立するために必要なプロトコルフローがモバイルIPで非常に時間がかかる可能性があることを示しており、他のモビリティプロトコルも同様に苦しむ可能性があります。
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]およびIEEE [9]内で継続的な取り組みがあります。これらのソリューションは、主に、2つの無線アクセスネットワークまたは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でのハンドオーバーのサポートを提供します。レイヤー3コンテキスト転送は、レイヤー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.
コンテキスト転送にはネットワークエンティティ間の信頼関係が必要であるため、たとえばコンテキストに転送されたコンテキストには、暗号化キーイン素材が含まれている場合、コンテキストを転送するネットワークエンティティの1つのみがシステム全体のセキュリティを減らすのに十分な場合があります。ホストが侵害されたネットワークエンティティから、コンテキスト転送の存在下で妥協のないネットワークエンティティに移動すると、妥協したコンテキストを使用して通信チャネルを復号化できます。コンテキスト転送が使用されない場合、1つのネットワークエンティティのみの妥協は、そのネットワークエンティティが表示できるものにのみアクセスできるようにします。モバイルホストがコンテキスト転送がない場合に妥協のないネットワークエンティティに移動すると、新しいエンティティでセキュリティを再確立できます。ただし、コンテキスト転送が主にルーター間で発生する限り、コンテキスト転送のセキュリティはルーターのセキュリティに依存します。コンテキストの転送に影響を与えるルーターのセキュリティの妥協は、ネットワークトラフィックの他の、同様に深刻な混乱につながる可能性があります。
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.
編集者は、このドキュメントの最初の内容を主に担当したSeamoby CT Design Team（文書の最後に記載されている）に感謝したいと思います。最初のバージョンを介してドキュメント。
[1] Perkins, C., "IP Mobility Support", RFC 3220, January 2002.
[1] Perkins、C。、「IP Mobility Support」、RFC 3220、2002年1月。
[2] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[2] Johnson、D。およびC. Perkins、「IPv6のモビリティサポート」、進行中の作業。
[3] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[3] Blunk、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。P802.1x/D11、「ポートベースのネットワークアクセス制御の標準」、2001年3月。
[6] Perkins, C., and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.
[6] Perkins、C。、およびP. Calhoun、「モバイル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] 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.、H。Zheng、「堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、およびRFC 3095、7月2001年。
[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 Domainからのリアルタイムサービス用のハンドオーバー」、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。802.11f/d2.0、「IEEE 802.11操作をサポートする配電システム全体のアクセス間ポイントプロトコルを介したマルチベンダーアクセスポイントの相互運用性の推奨プラクティスドラフト」、2001年7月。
[10] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10] Kent、S。and Atkinson、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. Moore、「IEEE 802でのコンテキスト転送のモデル」が進行中です。
O. Henrik Levkowetz A Brand New World Osterogatan 1 S-164 28 Kista SWEDEN
O. Henrik Levkowetzブランドの新しい世界Osterogatan 1 S-164 28 Kista Sweden
Phone: +46 8 477 9942
EMail: henrik@levkowetz.com
Pat R. Calhoun Black Storm Networks 110 Nortech Parkway San Jose CA 95134 USA
パットR.カルホーンブラックストームネットワーク110 Nortech Parkway San Jose CA 95134 USA
Phone: +1 408-941-0500
EMail: pcalhoun@bstormnetworks.com
James Kempf NTT DoCoMo USA Laboratories 181 Metro Drive, Suite 300 San Jose, CA 95110 USA
James Kempf NTT Docomo USA Laboratories 181 Metro Drive、Suite 300 San Jose、CA 95110 USA
Phone: 408-451-4711 EMail: kempf@docomolabs-usa.com
電話：408-451-4711メール：kempf@docomolabs-usa.com
Gary Kenward Nortel Networks 3500 Carling Avenue Nepean, Ontario K2G 6J8 CANADA
Gary Kenward Nortel Networks 3500 Carling Avenue Nepean、オンタリオK2G 6J8カナダ
Phone: +1 613-765-1437 EMail: gkenward@nortelnetworks.com Hamid Syed Nortel Networks 100 Constellation Crescent Nepean Ontario K2G 6J8 CANADA
電話：1 613-765-1437メール：gkenward@nortelnetworks.com Hamid Syed Nortel Networks 100 Constellation Crescent Nepean Ontario K2G 6J8 Canada
Phone: +1 613 763-6553
EMail: hmsyed@nortelnetworks.com
Jukka Manner Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND
ジュッカマナーコンピュータサイエンス大学ヘルシンキP.O.Box 26（Teollisuuskatu 23）Fin-00014 Helsinki Finland
Phone: +358-9-191-44210
EMail: jmanner@cs.helsinki.fi
Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 USA
Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 USA
Phone: +1 847-632-5030
EMail: madjid.nakhjiri@motorola.com
Govind Krishnamurthi Communications Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington MA 01803 USA
Govind Krishnamurthi Communications Systems Laboratory、Nokia Research Center 5 Wayside Road Burlington MA 01803 USA
Phone: +1 781 993 3627 EMail: govind.krishnamurthi@nokia.com Rajeev Koodli Communications Systems Lab, Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
電話：1 781 993 3627メール：govind.krishnamurthi@nokia.com Rajeev Koodli Communications Systems Lab、Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
Phone: +1 650 625 2359
EMail: rajeev.koodli@nokia.com
Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1P 6E2 CANADA
Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1p 6E2カナダ
Phone: +1 613 789 0090
EMail: kulwinder.atwal@zucotto.com
Michael Thomas Cisco Systems 375 E Tasman Rd San Jose CA 95134 USA
マイケルトーマスシスコシステム375 E Tasman Rd San Jose CA 95134 USA
Phone: +1 408 525 5386
EMail: mat@cisco.com
Mat Horan COM DEV Wireless Group San Luis Obispo CA 93401 USA
Mat Horan Com Dev Wireless Group San Luis Obispo CA 93401 USA
Phone: +1 805 544 1089
EMail: mat.horan@comdev.cc
Phillip Neumiller 3Com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA
Phillip Neumiller 3com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA
EMail: phil_neumiller@3com.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。