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）によって搬送される場合にはLocationオブジェクト（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のプロセスに従って処理標準トラック文書であろう。この文書では、このトピックに関するGEOPRIVワーキンググループの合意の声明でSIPワーキンググループを提供するために主に意図されます。これは、二次的、一般的なリーダーのための問題空間のチュートリアル情報を提供しています。
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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]）のプレゼンス情報データフォーマットは、位置情報（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-搬送]で指定されています。 SIP内のLIを提供するための一般的な動機は、位置は、SIPメッセージをルーティングする際に考慮されるようにすることです。一例として、ユースケースは、場所が応答を指示するためにディスパッチャによって使用されるで緊急サービス、だろう。別のユースケースは、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の<再送許容>要素は、位置情報（LI）は（場所受信者にロケーションサーバ（LS）を介してロケーション・ジェネレータから伝播する、RFC 3693のセクション4のような環境で使用するために設計されましたLR）。このアーキテクチャでは、今度は、ルールメーカーによって設定されているLIへのアクセス制御を管理する規則（ポリシー）に作用するロケーションサーバの責任です。これらの責任の最も重要なのは、許可の場所受信者にLIを提供し、他の人にそれを否定しています。 [RFC4119]準拠位置オブジェクト（LOS）の内部には、位置受信者を拘束することを意図している追加のプライバシールールです。これらは、<再送許可>要素が含まれます。この要素は、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>.
<再送許可>は、盗聴などの手段を通じて場所を学習から権限のない者を防ぐために、任意のプロトコルレベルでのメカニズムを提供することを意図していないこと、しかし、覚えておいてください。それは単にLRにルールメーカーの好みを表現する方法です。 LRは、例えば、法的ルールメーカーで表現プライバシー設定を追跡するためにバインドされた場合、彼らは<再送信許可>パラメータを無視して、彼らは責任を負う可能性があります。これ以上のプライバシー保護は、<再送許可>によって提供されていると想定されていません。
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.
潜在的ユーザエージェントサーバ（UAS）に到達する前に複数のSIP仲介を横断するSIP要求の中に埋め込むことを含むLIためのユースケースがあります。このユースケースでは、一つ以上の仲介者は、SIPルーティングの決定を行うためにLIを検査するかもしれません。我々は、以下のロケーションベースのルーティングとしてこれを参照します。一般的な例としては、緊急サービスおよびSIP要求の発信元は、近くのピザ店を接触させて、特定の地理的位置に近接してサービスに到達したいと考え、他の多くの世俗的な例を含めることができます。このような場合の両方で、UACは、LIへのアクセスを有するように選択仲介とUASを意図してもよいです。ピザの場合、例えば、ユーザエージェントクライアント（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はありません。複数（LRSとしてそれらを修飾すると思われる）LIを検査する必要があるかたくなるそのうちのいくつかは、UACとUAS間の仲介、およびそれらのいくつかではないでしょうがあるかもしれません。 SIPプロキシサーバは、一般的に、[RFC4119] -awareではなく、その機能を実行するために、SIPリクエストのボディを検査する必要はありませんが、何もLIを含む任意のSIPメッセージボディを検査するか、ログインするプロキシサーバを、排除しません。 UACは、SIPリクエストが届く可能性がある仲介業者及び最終的UAS予測するためにさらに、それは非常に困難です。
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.
このアーキテクチャはさらに、即ち、により基準位置情報を送信するLI代わりに（一般値でPIDF-LOなどと呼ばれる）PIDF-LO体を用いたSIPリクエストで取得することができる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?
LIに縛ら読み取る任意のエンティティである<再送が許容しますか>？もしそうなら、それは<再送信許可>場合は、ロケーションベースのルーティングは、要求を転送し、SIPコールを完了することができません行いプロキシを意味する「ノー」ですか？また、彼らは、コールを完了するために、メッセージからロケーション体を除去しなければなりませんか？
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?
プロキシはRFC 4119を理解していない場合は、<再送許可>設定「なし」にポリシーステートメントを含む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があるようにすることを意図していることはできますか？そう、1つがLRは別のLRに再送信することが許可された場合、どのようにまた、他の第三者（すなわち、どのようにシリアルのLRは、それらが再送信を許可されているために誰を知っているだろう）にLIを送信するために許可されていない知っているのだろうか？どのようにこのすべてを指定することができましたか？
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コンテキストの両方で広範な議論の後に、この問題に対する解決策は、<再送許容>フラグが「NO」に設定されている場合でも動作するようにロケーションベースのルーティングを有効にする必要があることにコンセンサスがあるように思われます。溶液はまた、ルールメーカーに位置ベースのルーティング及びエンドポイントの消費のための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エレメントは、それが含まれているLOが<再送許容>「NO」に設定した場合であっても別のLIを渡すことができます。これは、許可された受信者への配信の一部としてではなく、再送としてSIPメッセージの通過を見ます。それは<再送許容>を制御することを意味する第三者に合格であるように、<再送許容>は、「no」に設定されている場合、SIPエンティティは、依然として外部のエンティティに通常のルーティング外これらのメッセージを通過する差し止めれます。
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.
このアーキテクチャは、認可された受信者が他の許可の受信者に上のLOを渡すには、RFC 3963の推測とは大きく異なっているが、最も賢明なメカニズムは、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と一つの分布を制限するために使用されてもよいです。これらは、以下で議論されています。
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へのアクセスを制限する一つの方法は、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要素（例えば、「自宅」や第一ホッププロキシ）との信頼関係を有する場合、それはまた、限られた環境において有用であってもよく、それはLIのみその要素に明らかにすることを望んでいます。
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を暗号化しようとする場合には、メッセージの最終的な終点を予測することは非常に困難であり得ることに留意されたいです。これらの暗号化されるLIは、オリジネーターの期待感が満たされていないどのような場合に有用ではないだろう。
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.
別の、より多くの可能なアプローチは、参照によって場所を活用します。 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のために頼むかもしれない千人の当事者のホワイトリストを管理し、LIの千異なり、暗号化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).
1認可決定を行う任意のシステムでは、認証中に一定のコストを支払わなければならない - 大きい保証大きなコストを。当然の正確なコストの意志は参照のURIスキームに依存します。 SIPの場合、ダイジェストは、低計算コストを持っていますが、適用可能性を制限する、事前に確立されたキーが必要です。 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から周知の方法で搬送アーキテクチャをキャスト。これは、<再送許可>の元の意味の保存を可能にします。
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を使用する許可を示しています。 「ロケーション・ルーティング・可」が「いいえ」に設定されている場合、発信者はこの使用が許可されていないことを示しています。 「ロケーション・ルーティング・可」を「いいえ」に設定されている、この動作の施行のためのプロトコルレベルのメカニズムを持っていません。 PIDF-LOのような<再送許容>は「NO」に設定され、それは、LI受信者であるSIP要素に優先度を表現するルールメーカーのための方法です。それは、しかし、重要な最適化を提示することができます。場所ごとの参照は、「ロケーション・ルーティング・可」を「いいえ」に設定して含まれる場合、パスに沿ったSIP要素は、彼らが位置情報を参照解除しようとし必要がないことを知っています。これは間接参照を試みると認証段階で拒否されているよりもかなり高速です。
We recommend that "Location-Routing-Allowed" be made mandatory-to-implement for elements complying with [LOC-CONVEY].
私たちは、「ロケーション・ルーティング・可」[LOC-伝え]実装に必須の要素に準拠するために行われることをお勧めします。
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「ロケーションルーティング許容」ヘッダを含む任意のSIPメッセージが「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.
我々は、UAは、それが他のSIP要素によって挿入された任意の場所のポリシーを設定するために、場所を含んでいない場合でも、「ロケーションルーティング許容」ヘッダを挿入させることをお勧めします。
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交換を発信した後、UAは、SIPメッセージの中に位置現在挿入されている場合でも、ネットワークアーキテクチャ、場所のルールメーカーであることを主張することを可能にします。
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.
我々は1つが存在しない場合、「ロケーションルーティング許容」ヘッダを挿入し、参照することにより、または値によってかどうか、任意の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のほとんどの用途では、彼らは名目上の起点と公称終端の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は、エンドポイントとして機能しない、実際には（セッションを終了し、別のセッションを発信する）場合は、<再送許可>は、それに適用され、<再送許可>「ノー」であるならば、それは場所をコピーしてはいけません。それは、発信レッグのルートを選択した場合、任意の新しいルーティング-許可メカニズムは、それに適用されます。
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節で提案しました。型B2BUA上のテキストのためのブライアン・ローゼンに感謝します。
[LOC-CONVEY] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", Work in Progress, March 2009.
[LOC-伝え]ポーク、J.とB.ローゼン、「セッション開始プロトコルのための場所搬送」、進歩、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc.
ジョンピーターソンNeuStar株式会社
EMail: jon.peterson@neustar.biz
メールアドレス：jon.peterson@neustar.biz
Ted Hardie Qualcomm
テッドハーディークアルコム
EMail: hardie@qualcomm.com
メールアドレス：hardie@qualcomm.com
John Morris Center for Democracy & Technology
民主主義と技術のためのジョン・モリスセンター
EMail: jmorris@cdt.org
メールアドレス：jmorris@cdt.org