[要約] 要約：RFC 5606は、SIPの場所伝達における「再送信許可」の影響について説明しています。 目的：このRFCの目的は、再送信許可の機能がSIPの場所伝達に与える影響を明確にすることです。
Network Working Group J. Peterson
Request for Comments: 5606 NeuStar, Inc.
Category: Informational T. Hardie
Qualcomm
J. Morris
CDT
August 2009
Implications of 'retransmission-allowed' for SIP Location Conveyance
SIPロケーションキャベサンスに対する「再送信」の意味
Abstract
概要
This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.
このドキュメントでは、PIDF-LOがセッション開始プロトコル（SIP）によって伝達される場合の位置オブジェクト（PIDF-LO）の存在情報データ形式の<再送信を許可された>要素の解釈の曖昧さを調査します。SIPの位置輸送メカニズムがこのあいまいさにどのように適応するかについての推奨事項を提供します。
Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader.
SIPロケーションキャンベーションメカニズムを標準化するドキュメントは、通常のSIPプロセスに従って処理される標準トラックドキュメントです。このドキュメントは、主にSIPワーキンググループに、このトピックに関するGEOPRIVワーキンググループのコンセンサスの声明を提供することを目的としています。次に、一般読者の問題スペースに関するチュートリアル情報を提供します。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Recommendation ..................................................5
3.1. Goals ......................................................5
3.2. Core Semantics .............................................5
3.3. Limiting Access ............................................6
3.3.1. Limiting Access Using Public Key Encryption .........6
3.3.2. Limiting Access Using Location-by-Reference .........7
3.3.3. Refraining from Including Location Information ......8
3.4. Choosing among the Available Mechanisms ....................8
3.5. Indicating Permission to Use Location-Based Routing
in SIP .....................................................8
3.6. Behavior of Back-to-Back User Agents ......................10
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. Informative References .........................................11
The Presence Information Data Format for Location Objects (PIDF-LO [RFC4119]) carries both location information (LI) and policy information set by the Rule Maker, as is stipulated in [RFC3693]. The policy carried along with LI allows the Rule Maker to restrict, among other things, the duration for which LI will be retained by recipients and the redistribution of LI by recipients.
[RFC3693]で規定されているように、ロケーションオブジェクト（PIDF-LO [RFC4119]）の存在情報データ形式（PIDF-LO [RFC4119]）の両方の位置情報（LI）とポリシー情報の両方がルールメーカーによって設定されています。LIと一緒に運ばれたポリシーにより、ルールメーカーは、とりわけ、LIが受信者によって保持される期間と受信者によるLIの再分配を制限することができます。
The Session Initiation Protocol [RFC3261] is one proposed Using Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is specified in [LOC-CONVEY]. The common motivation for providing LI in SIP is to allow location to be considered in routing the SIP message. One example use case would be emergency services, in which the location will be used by dispatchers to direct the response. Another use case might be providing location to be used by services associated with the SIP session; a location associated with a call to a taxi service, for example, might be used to route to a local franchisee of a national service and also to route the taxi to pick up the caller.
セッション開始プロトコル[RFC3261]は、PIDF-LOのプロトコルを使用して提案されているものです。SIP内のPIDF-LOの伝達は、[Loc Convey]で指定されています。SIPでLiを提供する一般的な動機は、SIPメッセージをルーティングする際に場所を考慮することです。ユースケースの1つは緊急サービスです。このサービスでは、その場所は、応答を指示するためにディスパッチャがその場所を使用します。別のユースケースは、SIPセッションに関連するサービスで使用する場所を提供することです。たとえば、タクシーサービスへの呼び出しに関連する場所を使用して、国内サービスの地元のフランチャイジーにルーティングし、タクシーをルーティングして発信者を迎えに行くこともできます。
Some ambiguities have arisen in the interpretation of Rule Maker policy when PIDF-LO is conveyed by SIP. The following sections explore the problem and provide a recommendation.
PIDF-LOがSIPによって伝えられた場合、ルールメーカーポリシーの解釈にいくつかのあいまいさが生じました。次のセクションでは、問題を調査し、推奨事項を提供します。
The <retransmission-allowed> element of RFC 4119 was designed for use in an environment like that of Section 4 of RFC 3693, in which Location Information (LI) propagates from a Location Generator through a Location Server (LS) to a Location Recipient (LR). In this architecture, it is the responsibility of the Location Server to act on the rules (policy) governing access control to LI, which are in turn set by the Rule Maker. The most important of these responsibilities is delivering LI to authorized Location Recipients and denying it to others. Internal to [RFC4119]-compliant location objects (LOs) are additional privacy rules which are intended to constrain Location Recipients. These include the <retransmission-allowed> element. This element is intended to prevent a compromise of privacy when an authorized recipient of LI shares that LI with third-party entities, principally those who are not authorized by the Rule Maker to receive LI. For example, a user might be willing to share their LI with a pizza shop, but they might not want that pizza shop to sell their LI to a targeted advertising company that will contact the user with coupons for a nearby hair salon.
RFC 4119の<再送信による承認>要素は、RFC 3693のセクション4のような環境で使用するように設計されています。この環境では、位置情報（LI）がロケーションサーバー（LS）を介してロケーションレシピエント（LR）。このアーキテクチャでは、Liへのアクセス制御を管理するルール（ポリシー）に基づいて行動することはロケーションサーバーの責任であり、これはルールメーカーによって設定されます。これらの責任の中で最も重要なのは、承認された場所の受信者にLiを提供し、他の人にそれを否定することです。[RFC4119]の内部に並ぶロケーションオブジェクト（LOS）は、ロケーション受信者を制約することを目的とした追加のプライバシールールです。これらには、<再送信を許可された>要素が含まれます。この要素は、LIの承認されたレシピエントが、主にルールメーカーがLIを受け取ることを許可されていないliの承認されたレシピエントが、Liを共有する場合にプライバシーの妥協を防ぐことを目的としています。たとえば、ユーザーはLIをピザショップと喜んで共有したいかもしれませんが、そのピザショップが近くのヘアサロンのクーポンでユーザーに連絡するターゲット広告会社にLIを販売することを望まないかもしれません。
Bear in mind, however, that <retransmission-allowed> is not intended to provide any protocol-level mechanism to prevent unauthorized parties from learning location through means like eavesdropping. It is merely a way to express the preferences of the Rule Maker to the LR. If the LR were, for example, legally bound to follow the privacy preferences expressed by Rule Makers, then they might incur liability if they ignored the <retransmission-allowed> parameter. No further privacy protection is assumed to be provided by <retransmission-allowed>.
ただし、<Transmission-Alowed>は、不正な当事者が盗聴などの手段を通じて場所を学習するのを防ぐためのプロトコルレベルのメカニズムを提供することを意図していないことに留意してください。これは、ルールメーカーの好みをLRに表現するための単なる方法です。たとえば、LRがルールメーカーによって表明されたプライバシー設定に合法的に拘束されていた場合、<再送信-Allowed>パラメーターを無視した場合、責任を負う可能性があります。<Transmission-Allowed>によってそれ以上のプライバシー保護が提供されるとは想定されていません。
There is a use case for LI that involves embedding it in a SIP request that will potentially traverse multiple SIP intermediaries before arriving at a user agent server (UAS). In this use case, one or more intermediaries might inspect the LI in order to make a SIP routing decision; we will hereafter refer to this as location-based routing. Common examples could include emergency services and other more mundane cases where the originator of a SIP request wants to reach a service in proximity to a particular geographic location, such as contacting a nearby pizza shop. In both such cases, the UAC may intend for selected intermediaries and the UAS to have access to the LI. In the pizza case, for instance, the user agent client (UAC) shares an address both for location-based routing and additionally so that the pizza shop reached by that routing has the address to which a pizza should be sent.
Liには、ユーザーエージェントサーバー（UAS）に到着する前に複数のSIP仲介者を潜在的に通過する可能性のあるSIPリクエストに埋め込むことを伴うユースケースがあります。このユースケースでは、SIPルーティングの決定を下すために、1人以上の仲介者がLIを検査する場合があります。これを今後、これをロケーションベースのルーティングと呼びます。一般的な例には、SIPリクエストの発信者が近くのピザショップに連絡するなど、特定の地理的場所に近接してサービスに到達することを望んでいる緊急サービスやその他の平凡なケースが含まれます。どちらの場合も、UACは選択した仲介者とUASがLIにアクセスできるようにすることを意図する場合があります。たとえば、ピザの場合、ユーザーエージェントクライアント（UAC）は、ロケーションベースのルーティングとさらに、そのルーティングに到達したピザショップの両方の住所を共有しています。
This location-based routing use case for LI has a number of important disconnects from the RFC 3693 model. Unlike the RFC 3693 model, there is no LS designating to which specific entities LI will be sent. There may be multiple intermediaries between the UAC and UAS, some of which will need or want to inspect LI (which would seem to qualify them as LRs) and some of them will not. While SIP proxy servers generally are not [RFC4119]-aware and do not need to inspect SIP request bodies in order to perform their function, nothing precludes proxy servers inspecting or logging any SIP message bodies, including LI. Furthermore, it is very difficult for the UAC to anticipate which intermediaries and which eventual UAS a SIP request might reach.
Liのこの位置ベースのルーティングユースケースには、RFC 3693モデルから多くの重要な切断があります。RFC 3693モデルとは異なり、特定のエンティティLIが送信されるLSを指定することはありません。UACとUASの間には複数の仲介者が存在する場合がありますが、その一部はLI（LRSとして適格と思われる）を必要とするか、検査したいと考えています。SIPプロキシサーバーは一般に[RFC4119]ではなく、機能を実行するためにSIP要求ボディを検査する必要はありませんが、LIを含むSIPメッセージ本文を検査または記録するプロキシサーバーを排除するものはありません。さらに、UACがどの仲介業者と、どのようなSIPリクエストが到達するかを予測することは非常に困難です。
This architecture is further complicated by the possibility of sending location information by-reference, that is, placing a URL where LI can be retrieved in SIP requests instead of using a PIDF-LO body (commonly called including the PIDF-LO by value). Depending on the qualities of a reference, further authorization checks may be performed before LI is retrieved, LI may be customized depending on who is asking, and so forth. As will be discussed in greater detail below, the conveyance of a reference may have very different privacy properties than conveying a PIDF-LO body by-value in a SIP request.
このアーキテクチャは、PIDF-LOボディを使用する代わりに、SIPリクエストでLIを取得できるURLを配置する可能性により、さらに複雑になります。参照の品質に応じて、LIが取得される前にさらなる許可チェックが実行される場合があります。LIは、誰が尋ねているなどに応じてカスタマイズされる場合があります。以下で詳しく説明するように、リファレンスの伝達は、SIPリクエストでPIDF-LOボディバリューを伝えるのとは大きく異なるプライバシープロパティを持っている可能性があります。
In this architecture, the question of who is an "authorized recipient" from the point of view of the Rule Maker has been muddy.
このアーキテクチャでは、ルールメーカーの観点から誰が「承認された受信者」であるかという問題は濁っています。
The SIP elements along the path are authorized to receive and forward the SIP message; does that make them automatically authorized recipients of the LI it contains? The final target of the SIP message will receive the LI along with other information, but it may be different than the initial target in a variety of scenarios; is it authorized to read the LI?
パスに沿ったSIP要素は、SIPメッセージを受信して転送することが許可されています。それにより、それらに含まれるLIの自動的に認可された受信者になりますか？SIPメッセージの最終ターゲットは、他の情報とともにLIを受信しますが、さまざまなシナリオの初期ターゲットとは異なる場合があります。Liを読むことが許可されていますか？
These questions and concerns are particularly problematic when <retransmission-allowed> is set to "no" (the default case). This core concern might be put as "to whom does <retransmission-allowed> apply in location-based routing?" More specifically:
これらの質問と懸念は、<再送信を許可>が「いいえ」に設定されている場合、特に問題があります（デフォルトのケース）。この核となる懸念は、「<再送信を許可している>には、ロケーションベースのルーティングに適用されるのは誰ですか？」すなわち：
Is any entity that reads LI bound by <retransmission-allowed>? If so, does that mean a proxy that performs location-based routing is unable to forward a request and complete a SIP call if <retransmission-allowed> is "no"? Alternatively, must they strip the location body from the message in order to complete the call? If the proxy does not understand RFC 4119, it may forward a SIP message containing a policy statement <retransmission-allowed> set to "no". Is any proxy that does understand RFC 4119 required to parse the LI for this statement, even if it would not do so in order to route the message?
Liを読み取るエンティティは、<Recransmission-Allowed>にバインドされていますか？もしそうなら、それはロケーションベースのルーティングを実行するプロキシがリクエストを転送し、<Transmission-Allowed>が「いいえ」である場合、SIPコールを完了することができないことを意味しますか？または、通話を完了するために、メッセージからロケーション本体を剥奪する必要がありますか？プロキシがRFC 4119を理解していない場合、<No」に設定されたポリシーステートメント<Transmiss-Allowed>を含むSIPメッセージを転送する場合があります。メッセージをルーティングするためにそうしない場合でも、このステートメントのLIを解析するために必要なRFC 4119を理解しているプロキシはありますか？
Is there a need for SIP-level indications regarding retransmission for the benefit of entities that do not understand RFC 4119?
RFC 4119を理解していないエンティティの利益のために、再送信に関するSIPレベルの兆候が必要ですか？
Since the UAC cannot anticipate who may receive a SIP request, how do we understand who the intended LR is in the location-based routing case? Can a UAC have intended for there to be multiple serial LRs in a transmission? If so, if one LR is authorized to retransmit to another LR, how will it know it is not also authorized to transmit LI to other third parties (i.e., how will the serial LRs know to whom they are authorized to retransmit)? How could all of this be designated?
UACは、誰がSIPリクエストを受信できるかを予測できないため、意図したLRがロケーションベースのルーティングケースに誰がいるかをどのように理解しますか？UACは、トランスミッションに複数のシリアルLRを存在することを意図していますか？もしそうなら、あるLRが別のLRに再送信することを許可されている場合、他の第三者にLIを送信することは許可されていないことをどのようにして知っていますか（つまり、シリアルLRが誰に再送信を許可されているかをどのように知っていますか）。これらすべてをどのように指定できますか？
The following sections provide a recommendation for how the <retransmission-allowed> flag should be understood in a SIP environment. The core semantics of this recommendation represent the consensus of the GEOPRIV working group. While Section 3.5 proposes a syntax that might be adopted by the SIP WG to implement these semantics in its protocol, the actual syntax of SIP is the responsibility of the SIP WG.
次のセクションでは、SIP環境で<再送信を許可された>フラグをどのように理解するかについての推奨事項を示します。この推奨事項の中核的なセマンティクスは、Geoprivワーキンググループのコンセンサスを表しています。セクション3.5では、SIP WGがプロトコルにこれらのセマンティクスを実装するために採用される可能性のある構文を提案していますが、SIPの実際の構文はSIP WGの責任です。
After extensive discussion in both GEOPRIV and SIP contexts, there seems to be consensus that a solution for this problem must enable location-based routing to work even when the <retransmission-allowed> flag is set to "no". A solution should also give the Rule Maker the ability to allow or forbid the use of LI for location-based routing and the ability to allow or forbid the use of LI for the consumption of the endpoint.
GeoprivとSIPの両方のコンテキストで広範な議論の後、この問題の解決策は、<Recransmission-Allowed>フラグが「いいえ」に設定されている場合でも、位置ベースのルーティングを機能させる必要があるというコンセンサスがあるようです。また、ソリューションは、ルールメーカーに、ロケーションベースのルーティングにLIの使用を許可または禁止し、エンドポイントの消費にLIの使用を許可または禁止する機能を提供する必要があります。
Consensus has emerged that any SIP entity that receives a SIP message containing LI through the operation of SIP's normal routing procedures or as a result of location-based routing should be considered an authorized recipient of that LI. Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has <retransmission-allowed> set to "no"; this sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if <retransmission-allowed> is set to "no", as it is the passing to third parties that <retransmission-allowed> is meant to control.
SIPの通常のルーティング手順の操作を通じて、またはロケーションベースのルーティングの結果として、LIを含むSIPメッセージを受信するSIPエンティティは、そのLIの承認された受信者と見なされるべきであるというコンセンサスが明らかになりました。この推定のため、1つのSIP要素が含まれている場合でも、あるSIP要素を別のSIP要素に渡すことができます。これにより、SIPメッセージの通過は、再送信としてではなく、許可された受信者への配信の一部として見られます。SIPエンティティは、<Transmission-Allowed>が「いいえ」に設定されている場合、通常のルーティングの外部外部エンティティへのこれらのメッセージを渡すことを依然として禁じられています。
This architecture is considerably different from the presumptions of RFC 3963, in that authorized recipients pass the LO on to other authorized recipients, but it seems to be the most sensible mechanism given SIP's operation.
このアーキテクチャは、RFC 3963の推定とはかなり異なります。これは、認定された受信者が他の認定受信者にLOを渡すという点で、SIPの操作を考えると最も賢明なメカニズムのようです。
To maintain the Rule Maker's ability to affect the consumption of this information, two different mechanisms may be used to limit the distribution of LI and one may used to limit the sphere in which it may be used; these are discussed below.
この情報の消費に影響を与えるルールメーカーの能力を維持するために、Liの分布を制限するために2つの異なるメカニズムを使用し、使用する球体を制限するために使用される場合があります。これらについては、以下で説明します。
One way of limiting access to LI is to encrypt the PIDF-LO object in a SIP request. If the originator knows which specific entity on the path needs to inspect the LI, and knows a public key for that entity, this is a straightforward matter. It is even possible to encrypt multiple instance of PIDF-LO, containing different policies or levels of location granularity, in the same SIP request if multiple entities along the path need to inspect the location.
LIへのアクセスを制限する1つの方法は、SIPリクエストでPIDF-LOオブジェクトを暗号化することです。オリジネーターが、パス上のどの特定のエンティティがLIを検査する必要があるかを知っており、そのエンティティの公開鍵を知っている場合、これは簡単な問題です。パスに沿って複数のエンティティが場所を検査する必要がある場合、同じSIP要求で、異なるポリシーまたは場所の粒度のレベルを含むPIDF-LOの複数のインスタンスを暗号化することも可能です。
This is most likely to be effective in cases where the originator does not wish the LI to be inspected by intermediate entities and has the public key for the target of the SIP message, as it is very difficult for the originator to anticipate the intermediaries through which a SIP message will pass. It may also be useful in limited environments where the originator has a trust relationship with a specific SIP element (e.g., a "home" or first-hop proxy) and it wants to reveal that LI only to that element.
これは、オリジネーターが中間エンティティによってLIが検査されることを望まない場合に効果的である可能性が最も高く、SIPメッセージのターゲットの公開鍵を持っている可能性があります。SIPメッセージが渡されます。また、オリジネーターが特定のSIP要素（例えば、「ホーム」または最初のホッププロキシ）と信頼関係を持っている限られた環境でも役立つかもしれません。
Note that even in the case where the originator intends to encrypt LI for the benefit only of the target of the message, it may be quite difficult to anticipate the eventual endpoint of the message. These encrypted LIs will not be useful in any case where the anticipation of the originators is not met.
オリジネーターがメッセージのターゲットのみの利益のためにLiを暗号化するつもりの場合でも、メッセージの最終的なエンドポイントを予測することは非常に難しいかもしれないことに注意してください。これらの暗号化されたLISは、創始者の予想が満たされていない場合には役に立ちません。
An additional problem posed by this approach is that it requires some sort of public key discovery system, which compounds the operational complexity significantly. While this method is included for completeness, it is the consensus of the working group that the deployment scenarios in which this is appropriate will be relatively few; we do not believe it is an appropriate baseline approach.
このアプローチによってもたらされる追加の問題は、運用上の複雑さを大幅に悪化させる何らかの公開キー発見システムが必要であることです。この方法は完全性のために含まれていますが、これが適切である展開シナリオが比較的少ないのはワーキンググループのコンセンサスです。適切なベースラインアプローチであるとは思いません。
Another, more feasible approach is leveraging location by reference. When a SIP request conveys a reference, it cannot be properly said to be conveying location; location is conveyed upon dereferencing the URI in the question, and the meaning of <retransmission-allowed> must be understood in the context of that conveyance, not the forwarding of the SIP request.
もう1つのより実行可能なアプローチは、参照により場所を活用することです。SIPリクエストがリファレンスを伝える場合、場所を伝達していると適切に言われることはできません。場所は、質問でURIを繰り返すと伝達され、<再送信に許可された>の意味は、SIPリクエストの転送ではなく、その伝達の文脈で理解されなければなりません。
The properties of references, especially the security properties, vary significantly depending on the nature and disposition of the resource indicated. Clearly, if the referenced PIDF-LO is available, in the same form, to any entity along the SIP signaling path that requests it, then inserting a reference has no advantages over inserting LI by value (and introduces wasteful complexity). However, if the Rule Maker influences the results of the dereferencing process, including determining who can receive LI at what degree of granularity and what policies are bound with the LI, the security properties are different.
参照の特性、特にセキュリティプロパティは、示されている資源の性質と処分によって大きく異なります。明らかに、参照されたPIDF-LOが同じ形式で、それを要求するSIPシグナルパスに沿った任意のエンティティに利用可能である場合、参照を挿入することは、価値によってLIの挿入よりも利点はありません（そして無駄な複雑さを導入します）。ただし、ルールメーカーが、どの程度の粒度性でLIを受け取ることができるか、LIにどのようなポリシーが拘束されるかを判断するなど、控えめなプロセスの結果に影響を与える場合、セキュリティプロパティは異なります。
It might superficially appear that this suffers from the same problems as the encryption approach, since the Rule Maker must anticipate a set of entities who are authorized to receive location information. The difference is that this set does not need to be communicated in the SIP request in order for authorization decisions to be made. There is a world of difference between managing a whitelist of a thousand parties that might ask for LI and sending a SIP request containing a thousand differently encrypted adumbrations on LI -- the former is commonplace and the latter is impossible. Additionally, some Rule Maker policies might not even require the establishment of an exhaustive whitelist. For example, it may be that there exists a finite set of commercial requestors that the Rule Maker would like to block, in a manner similar to the way ad-blockers operate in modern web browsers.
ルールメーカーは位置情報を受け取ることを許可されているエンティティのセットを予測する必要があるため、これは暗号化アプローチと同じ問題に苦しんでいるように見えるかもしれません。違いは、許可決定を下すために、このセットをSIPリクエストで伝える必要がないことです。Liを要求するかもしれない1000の政党のホワイトリストを管理することと、Liに異なる暗号化された1000の暗号化されたadumbrationsを含むSIPリクエストを送信することとの間には、違いの世界があります。前者は一般的であり、後者は不可能です。さらに、一部のルールメーカーポリシーは、徹底的なホワイトリストの設立を必要としない場合があります。たとえば、最新のWebブラウザでの広告ブロッカーの動作方法と同様に、ルールメーカーがブロックしたいという有限の商業要求者セットが存在する可能性があります。
In any system where one makes an authorization decision, a certain cost in authentication must be paid -- the greater the assurance the greater the cost. The precise cost will of course depend on the URI scheme of the reference. For SIP, Digest has a low computational cost but requires pre-established keys, which limits applicability. RFC 4474 Identity does not require any pre-association, but it does make signaling more heavyweight and requires the deployment of additional features in the network, including a web-like public key infrastructure (PKI).
許可決定を下すシステムでは、認証の特定のコストを支払う必要があります。保証が大きいほどコストが大きくなります。もちろん、正確なコストは、参照のURIスキームに依存します。SIPの場合、Digestの計算コストは低いですが、事前に確立されたキーが必要であり、適用性が制限されます。RFC 4474アイデンティティは事前関連付けを必要としませんが、シグナリングをよりヘビー級にし、ウェブのような公開キーインフラストラクチャ（PKI）を含むネットワーク内の追加機能の展開を必要とします。
But even if no authentication takes place, in the Location-by-Reference (LbyR) case the meaning of <retransmission-allowed> is unambiguous -- each entity to which LI is conveyed in the dereference process is bound by the retransmission policy. The cost of the reference itself is of course the server that maintains the resource. While not every SIP client has access to an appropriate server for this purpose, the fact that PIDF-LO builds on the typical SIP presence service makes this less implausible than it might be. Moreover, the LbyR approach casts the conveyance architecture in a manner familiar from RFC 3693, with a Location Server receiving requests from Location Recipients, which may be accepted or denied. This allows the preservation of the original semantics of <retransmission-allowed>.
しかし、認証が行われない場合でも、場所ごと（LBYR）の場合、<再送信による禁止>の意味は明確です。これは、控除プロセスでLIが伝えられる各エンティティが再送信ポリシーに拘束されます。リファレンス自体のコストは、もちろんリソースを維持するサーバーです。すべてのSIPクライアントがこの目的のために適切なサーバーにアクセスできるわけではありませんが、PIDF-LOが典型的なSIPプレゼンスサービスに基づいて構築されているという事実により、これはそれよりも信じがたいものではありません。さらに、LBYRアプローチは、RFC 3693から馴染みのある方法でキャンベニアアーキテクチャをキャストし、ロケーションサーバーがロケーション受信者からリクエストを受信し、受け入れられたり拒否されたりします。これにより、<retransmission-allowed>の元のセマンティクスを保存できます。
The most fundamental mechanism for limiting access to location information is simply not including it. While location-based routing might conceivably occur in almost any SIP message in the future, there is no requirement that location be included in the general case to support it. If it is not included and is required, an appropriate error indicating the lack may be returned and the choice made to continue communication with the information included. This challenge and response will slow the establishment of communication when it is required, but it is the most basic way to ensure that location distribution is limited to the times when it is required for communication to proceed.
位置情報へのアクセスを制限するための最も基本的なメカニズムは、単にそれを含めないことです。将来、ほぼすべてのSIPメッセージでロケーションベースのルーティングが発生する可能性がありますが、それをサポートするために場所を一般的なケースに含める必要はありません。それが含まれておらず、必要である場合、欠如が返され、含まれている情報との通信を継続するための選択が行われる可能性があることを示す適切なエラーがあります。この課題と対応は、必要なときにコミュニケーションの確立が遅くなりますが、コミュニケーションが進むために必要な時期に限定されることを保証するための最も基本的な方法です。
Refraining from including location is the most appropriate choice for systems that do not wish to reveal location to any party in the SIP path.
場所を含めることを控えることは、SIPパスのどのパーティーにも場所を明らかにしたくないシステムにとって最も適切な選択です。
Location-by-Reference is generally recommended as the most deployable mechanism for limiting access to LI which is passed via a SIP message. It is significantly easier to deploy than public key discovery systems, allows for both whitelists and blacklists, and can scale in ways that the inclusion of multiple encrypted bodies cannot. Encryption may be used in a limited set of circumstance where location-by-value must be used.
一般に、SIPメッセージを介して渡されるLiへのアクセスを制限するための最も展開可能なメカニズムとして、一般に推奨されます。公開キーディスカバリーシステムよりも展開が非常に簡単で、ホワイトリストとブラックリストの両方が可能になり、複数の暗号化されたボディを含めることができない方法でスケーリングできます。暗号化は、価値ごとに使用する必要がある限られた一連の状況で使用される場合があります。
The discussion in Section 3.3.2 describes 3 mechanisms for limiting the distribution of LI to specific entities. There remains the problem of limiting the use to which LI included by value or by reference may be put. In order to meet the need to limit that use, this document recommends the creation of a syntactical element in SIP to carry this information. As an exemplary concrete proposal, we recommend a "Location-Routing-Allowed" header as described below.
セクション3.3.2の議論では、LIの分布を特定のエンティティに制限するための3つのメカニズムについて説明します。価値または参照に含まれるLIを使用する使用を制限するという問題が残っています。その使用を制限する必要性を満たすために、このドキュメントでは、この情報を携帯するためにSIPで構文要素を作成することを推奨しています。模範的な具体的な提案として、以下に説明するように「ロケーションルーティングが許可された」ヘッダーをお勧めします。
When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is indicating permission to use the included LI for location-based routing. When "Location-Routing-Allowed" is set to "No", the originator is indicating that this use is not permitted. "Location-Routing-Allowed" being set to "No" has no protocol-level mechanism for enforcement of this behavior; like the PIDF-LO <retransmission-allowed> being set to "no", it is a way for the Rule Maker to express a preference to the SIP elements, which are LI recipients. It may, however, present a significant optimization. Where a location-by-reference is included with "Location-Routing-Allowed" set to "No", the SIP elements along the path know that they do not need to attempt to dereference the location information; this is significantly faster than attempting the dereference and being denied at the authentication stage.
「ロケーションルーティングアロー」が「はい」に設定されている場合、ルールメーカーは、ロケーションベースのルーティングに含まれるLIを使用する許可を示しています。「ロケーションルーティング」が「いいえ」に設定されている場合、オリジネーターはこの使用が許可されていないことを示しています。「no」に設定される「ロケーションルーティング」が設定されていることには、この動作を実施するためのプロトコルレベルのメカニズムがありません。pidf-lo <retransmission-allowed>が「いいえ」に設定されているように、これはルールメーカーがLIの受信者であるSIP要素よりも好みを表現する方法です。ただし、重要な最適化を提示する場合があります。「no」に設定された「ロケーションルーティングが許可されている」に位置ごとに含まれている場合、パスに沿ったSIP要素は、位置情報を繰り返しようとする必要がないことを知っています。これは、繰り返しを試み、認証段階で拒否されるよりもはるかに高速です。
We recommend that "Location-Routing-Allowed" be made mandatory-to-implement for elements complying with [LOC-CONVEY].
[Loc Convey]に準拠した要素に「位置ルーティングが許可されている」を確定することをお勧めします。
We recommend that it appear in any SIP message that contains a location, whether by reference or by value.
参照によるものであろうと価値であろうと、場所を含む任意のSIPメッセージに表示することをお勧めします。
We recommend that any SIP message containing a location but no "Location-Routing-Allowed" header should be treated as containing a "Location-Routing-Allowed" header set to "no".
場所を含むが、「ロケーションルーティングに許可された」ヘッダーは、「no」にセットされた「ロケーションルーティングが許可された」ヘッダーを含むものとして扱う必要があることをお勧めします。
We recommend that a UA be allowed to insert a "Location-Routing-Allowed" header even when it has not included a location, in order to set the policy for any locations inserted by other SIP elements.
他のSIP要素によって挿入された場所のポリシーを設定するために、場所が含まれていない場合でも、UAを「ロケーションルーティングに許可する」ヘッダーを挿入することをお勧めします。
This allows the UA to assert that it is a Rule Maker for locations, even when the network architecture in which the UA is present inserts the location into SIP messages after the UA has originated the SIP exchange.
これにより、UAが存在するネットワークアーキテクチャがUAがSIP Exchangeを発信した後にSIPメッセージに場所を挿入する場合でも、UAはロケーションのルールメーカーであると主張することができます。
We recommend that any SIP element inserting a location, whether by reference or by value, insert a "Location-Routing-Allowed" header if one is not already present. If one is present, it should not be overridden by the SIP element inserting the location.
参照によるものであろうと価値のいずれであろうと、場所を挿入するSIP要素は、まだ存在していない場合は「ロケーションルーティングが許可されている」ヘッダーを挿入することをお勧めします。存在する場合は、場所を挿入するSIP要素によってオーバーライドされるべきではありません。
We recommend that any SIP element not the originator of a message and not inserting a location be enjoined from inserting a "Location-Routing-Allowed" header.
メッセージの発信元ではなく、「ロケーションルーティングが許可された」ヘッダーを挿入することから場所を挿入しないSIP要素をお勧めします。
Back-to-back user agent (B2BUA) behavior is often difficult to proscribe. There are many uses of B2BUAs, and the rules that apply to location would depend on the actual use case. This section suggests what any SIP mechanism arising from this document might wish to consider with regard to B2BUA behavior.
バックツーバックユーザーエージェント（B2BUA）の動作は、しばしば禁止するのが困難です。B2BUAには多くの用途があり、場所に適用されるルールは実際のユースケースに依存します。このセクションでは、このドキュメントから生じるSIPメカニズムがB2BUAの動作に関して考慮したいと思うものを示唆しています。
In most uses of B2BUAs, they act as a simple intermediary between the nominal originating and nominal terminating UAs, that is, a proxy that does something proxies aren't allowed to do. In such cases, the B2BUA must conform to any new routing-allowed mechanism if it chooses an outgoing route. As this document advises proxies, <retransmission-allowed> does not apply to the B2BUA in this case, and the B2BUA must copy the LI, the new routing-allowed, and existing <retransmission-allowed> values.
B2BUAのほとんどの用途では、公称起源のUASと公称終端UAの間の単純な仲介者、つまりプロキシが許可されていないプロキシとして機能します。そのような場合、B2BUAは、発信ルートを選択した場合、新しいルーティングが許可されたメカニズムに準拠する必要があります。このドキュメントがプロキシに助言するように、この場合は<再送信による禁止>はB2BUAには適用されず、B2BUAはLI、新しいルーティングを許可し、既存の<再受信>値をコピーする必要があります。
Where the B2BUA in fact does act as an endpoint (terminating the session and originating a different session), <retransmission-allowed> applies to it, and it must not copy location if <retransmission-allowed> is "no". If it chooses a route for the outgoing leg, any new routing-allowed mechanism applies to it.
実際、B2BUAがエンドポイントとして機能し（セッションを終了し、別のセッションを発信します）、<Transmission-Allowed>が適用されます。発信脚のルートを選択した場合、新しいルーティングが許可されたメカニズムがそれに適用されます。
Encryption lets the originator control who, including B2BUAs, is allowed to see location. On the other hand, using encryption with LI, which is needed for routing, is problematic, in that it is often difficult to know in advance which elements do location-based routing. Similarly, using Location-by-Reference instead of location-by-value provides additional control to the originator over B2BUA behavior by controlling who can dereference. See Section 3.4 for more guidance on this trade off.
暗号化により、B2BUAを含む誰が場所を見ることができる人を制御できます。一方、ルーティングに必要なLIで暗号化を使用することは問題があります。これは、どの要素が位置ベースのルーティングを行うかを事前に知ることが困難なことが多いという点でしばしば困難です。同様に、価値ごとの場所ではなくロケーションごとの使用を使用すると、誰が拒否できるかを制御することにより、B2BUAの動作に対するオリジネーターに追加の制御が提供されます。このトレードオフに関する詳細については、セクション3.4を参照してください。
The privacy and security implications of distributing location information are the fundamental subject of this document.
場所情報を配布することのプライバシーとセキュリティの意味は、このドキュメントの基本的な主題です。
James Polk provided a series of questions regarding the specifics of the Location-Routing-Allowed mechanism, and this resulted in the recommendations in Section 3.4. Thanks to Brian Rosen for the text on B2BUAs.
ジェームズ・ポークは、ロケーションルーティングが許可されたメカニズムの詳細に関する一連の質問を提供し、これによりセクション3.4の推奨が行われました。B2Buasのテキストについては、Brian Rosenに感謝します。
[LOC-CONVEY] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", Work in Progress, March 2009.
[Loc Convey] Polk、J.およびB. Rosen、「セッション開始プロトコルの位置運搬」、2009年3月、進行中の作業。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J.、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc.
Jon Peterson Neustar、Inc。
EMail: jon.peterson@neustar.biz
Ted Hardie Qualcomm
テッドハーディクアルコム
EMail: hardie@qualcomm.com
John Morris Center for Democracy & Technology
ジョン・モリス民主主義と技術センター
EMail: jmorris@cdt.org