RFC5338 日本語訳

Network Working Group                                       T. Henderson
Request for Comments: 5338                            The Boeing Company
Category: Informational                                      P. Nikander
                                            Ericsson Research NomadicLab
                                                                 M. Komu
                           Helsinki Institute for Information Technology
                                                          September 2008

コメントを求めるワーキンググループT.ヘンダーソン要求をネットワークでつないでください: 5338 ボーイング社カテゴリ: 情報技術2008年9月の情報のP.の研究NomadicLab M.KomuヘルシンキNikanderエリクソン研究所

       Using the Host Identity Protocol with Legacy Applications

レガシーアプリケーションがあるホストアイデンティティプロトコルを使用します。

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.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document is an informative overview of how legacy applications
   can be made to work with the Host Identity Protocol (HIP).  HIP
   proposes to add a cryptographic name space for network stack names.
   From an application viewpoint, HIP-enabled systems support a new
   address family of host identifiers, but it may be a long time until
   such HIP-aware applications are widely deployed even if host systems
   are upgraded.  This informational document discusses implementation
   and Application Programming Interface (API) issues relating to using
   HIP in situations in which the system is HIP-aware but the
   applications are not, and is intended to aid implementors and early
   adopters in thinking about and locally solving systems issues
   regarding the incremental deployment of HIP.

このドキュメントはHost Identityプロトコル(HIP)で働くのをどうレガシーアプリケーションをすることができるかに関する有益な概要です。 HIPは、ネットワークスタック名のために暗号の名前スペースを加えるよう提案します。 アプリケーション観点から、HIPによって可能にされたシステムはホスト識別子の新しいアドレスファミリーを養いますが、ホストシステムがアップグレードしてもそのようなHIP意識しているアプリケーションが広く配布されるまで、長い時間であるかもしれません。 この情報のドキュメントは、システムがHIP意識していますが、アプリケーションが意識しているというわけではない状況でHIPを使用するのに関係する実装とApplication Programming Interface(API)問題について議論して、HIPの増加の展開に関するシステム問題について考えて、局所的に解決する際に作成者と初期採用者を支援することを意図します。

Henderson, et al.            Informational                      [Page 1]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[1ページ]のRFC5338

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Enabling HIP Transparently within the System ....................4
      3.1. Applying HIP to Cases in Which IP Addresses Are Used .......4
      3.2. Interposing a HIP-Aware Agent in the DNS Resolution ........6
      3.3. Discussion .................................................7
   4. Users Invoking HIP with a Legacy Application ....................8
      4.1. Connecting to a HIT or LSI .................................8
      4.2. Using a Modified DNS Name ..................................9
      4.3. Other Techniques ...........................................9
   5. Local Address Management ........................................9
   6. Security Considerations ........................................11
   7. Acknowledgments ................................................12
   8. Informative References .........................................12

1. 序論…2 2. 用語…3 3. 透過的にシステムの中でヒップを可能にします…4 3.1. どのIPにヒップをケースに適用して、アドレスは使用されています…4 3.2. DNS解決でクールに意識しているエージェントを挿入します…6 3.3. 議論…7 4. レガシーアプリケーションでヒップを呼び出しているユーザ…8 4.1. ヒットかLSIに接続します…8 4.2. 変更されたDNS名を使用します…9 4.3. 他のテクニック…9 5. ローカルアドレス管理…9 6. セキュリティ問題…11 7. 承認…12 8. 有益な参照…12

1.  Introduction

1. 序論

   The Host Identity Protocol (HIP) [RFC5201] is an experimental effort
   in the IETF and IRTF to study a new public-key-based name space for
   use as host identifiers in Internet protocols.  Fully deployed, the
   HIP architecture would permit applications and users to explicitly
   request the system to send packets to another host by expressing a
   location-independent unique name of a peer host when the system call
   to connect or send packets is performed.  However, there will be a
   transition period during which systems become HIP-enabled but
   applications are not.  This informational document does not propose
   normative specification or even suggest that different HIP
   implementations use more uniform methods for legacy application
   support, but is intended instead to aid implementors and early
   adopters in thinking about and solving systems issues regarding the
   incremental deployment of HIP.

Host Identityプロトコル(HIP)[RFC5201]は使用のためにインターネットプロトコルのホスト識別子として新しい公開鍵ベースの名前スペースを研究するIETFとIRTFの実験的な取り組みです。 完全に配布されます、HIPアーキテクチャはアプリケーションとユーザが、パケットを接続するか、または送るシステムコールが実行されるとき同輩ホストの位置から独立しているユニークな名前を表すことによって別のホストにパケットを送るよう明らかにシステムに要求することを許可するでしょう。 しかしながら、システムがHIPによって可能にされるようになる過渡期があるでしょうが、しかし、利用はありません。 この情報のドキュメントは、標準の仕様を提案もしませんし、異なったHIP実装がレガシーアプリケーションサポートにより一定のメソッドを使用するのを示してさえいてもいませんが、HIPの増加の展開に関するシステム問題について考えて、解決する際に作成者と初期採用者を支援することを代わりに意図します。

   When applications and systems are both HIP-aware, the coordination
   between the application and the system can be straightforward.  For
   example, using the terminology of the widely used sockets Application
   Programming Interface (API), the application can issue a system call
   to send packets to another host by naming it explicitly, and the
   system can perform the necessary name-to-address mapping to assign
   appropriate routable addresses to the packets.  To enable this, a new
   address family for hosts could be defined, and additional API
   extensions could be defined (such as allowing IP addresses to be
   passed in the system call, along with the host name, as hints of
   where to initially try to reach the host).

アプリケーションとシステムがHIPともに意識しているとき、アプリケーションとシステムの間のコーディネートは簡単である場合があります。 例えば、広く使用されたソケットApplication Programming Interface(API)の用語を使用して、アプリケーションは明らかにそれを命名する別のホストにパケットを送るためにシステムコールを発行できます、そして、システムは適切な発送可能アドレスをパケットに割り当てるために必要な名前からアドレス・マッピングを実行できます。 これを可能にするために、ホストのための新しいアドレスファミリーを定義できました、そして、追加API拡大は定義された(IPアドレスが初めはどこでホストに届こうとするかに関するヒントとしてホスト名に伴うシステムコールで通過されるのを許容するとしてのそのようなもの)であるかもしれません。

Henderson, et al.            Informational                      [Page 2]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[2ページ]のRFC5338

   This document does not define a native HIP API such as described
   above.  Rather, this document is concerned with the scenario in which
   the application is not HIP-aware and a traditional IP-address-based
   API is used by the application.

このドキュメントは上で説明されるようにネイティブのHIP APIを定義しません。 むしろ、このドキュメントはアプリケーションがHIP意識していないシナリオに関係があります、そして、伝統的なIPアドレスベースのAPIはアプリケーションで使用されます。

   The discussion so far assumes that applications are written directly
   to a sockets API.  However, many applications are built on top of
   middleware that exports a higher-level API to the application.  In
   this case, for the purpose of this document, we refer to the
   combination of the middleware and the middleware-based application as
   an overall application, or client of the sockets API.

議論は、今までのところ、アプリケーションが直接ソケットAPIに書かれていると仮定します。 しかしながら、多くのアプリケーションが、よりハイレベルのAPIをアプリケーションにエクスポートするミドルウェアの上で組立てられます。 この場合、このドキュメントの目的について、私たちはミドルウェアの組み合わせと全面散布としてのミドルウェアベースのアプリケーションか、ソケットAPIのクライアントについて言及します。

   When HIP is enabled on a system, but the applications are not HIP-
   aware, there are a few basic possibilities to use HIP, each of which
   may or may not be supported by a given HIP implementation.  We report
   here on techniques that have been used or considered by experimental
   HIP implementations.  We organize the discussion around the policy
   chosen to use or expose HIP to the applications.  The first option is
   that users are completely unaware of HIP, or are unable to control
   whether or not HIP is invoked, but rather the system chooses to
   enable HIP for some or all sessions based on policy.  The second
   option is that the user makes a decision to try to use HIP by
   conveying this information somehow within the constraints of the
   unmodified application.  We discuss both of these use cases in detail
   below.

HIPがシステムの上で有効にされますが、アプリケーションがHIP意識していないとき、HIPを使用するいくつかの基本的な可能性があります。それは与えられたHIP実装によってそれぞれサポートされるかもしれません。 私たちはここ、実験的なHIP実装によって使用されるか、または考えられたテクニックに関して報告します。 私たちは使用か露出HIPに選ばれた方針の周りでアプリケーションに議論を計画します。 第1の選択はユーザが、HIPに完全に気づかないか、またはHIPが呼び出されるかどうかを制御できませんが、むしろシステムが、方針に基づくいくつかかすべてのセッションのためにHIPを有効にするのを選ぶということです。 2番目のオプションはユーザが変更されていないアプリケーションの規制の中でどうにかこの情報を伝えることによってHIPを使用しようとするという決定をするということです。 私たちは使用が詳細に以下にケースに入れるこれらの両方について議論します。

   HIP was designed to work with unmodified applications, to ease
   incremental deployment.  For instance, the HIT is the same size as
   the IPv6 address, and the design thinking was that, during initial
   experiments and transition periods, the HITs could substitute in data
   structures where IPv6 addresses were expected.  However, to a varying
   degree depending on the mechanism employed, such use of HIP can alter
   the semantics of what is considered to be an IP address by
   applications.  Applications use IP addresses as short-lived local
   handles, long-lived application associations, callbacks, referrals,
   and identity comparisons [APP-REF].  The transition techniques
   described below have implications on these different uses of IP
   addresses by legacy applications, and we will try to clarify these
   implications in the below discussions.

HIPは変更されていないアプリケーションで仕事に設計されていて、増加の展開を緩和しました。 例えば、HITはIPv6アドレスと同じサイズです、そして、デザイン考えは初期の実験と過渡期の間、HITsがIPv6アドレスが予想されたデータ構造で代理をするかもしれないということでした。 しかしながら、使われたメカニズムに依存する異なった度合いにHIPのそのような使用はアプリケーションで何がIPアドレスであると考えられるかに関する意味論を変更できます。 アプリケーションは短命な地方のハンドル、長命の応用アソシエーション、コールバック、紹介、およびアイデンティティ比較[APP-REF]としてIPアドレスを使用します。 以下で説明された変遷のテクニックはレガシーアプリケーションによるIPアドレスのこれらの異なった用途に意味を持っています、そして、私たちは以下の議論におけるこれらの含意をはっきりさせようとするでしょう。

2.  Terminology

2. 用語

   Callback:   The application at one end retrieves the IP address of
      the peer and uses that to later communicate "back" to the peer.
      An example is the FTP PORT command.

コールバック: 片端のアプリケーションは、同輩のIPアドレスを検索して、後で同輩に伝えるのにそれを使用します。 例はFTP PORTコマンドです。

   Host Identity:  An abstract concept applied to a computing platform.

アイデンティティを接待してください: 抽象概念はコンピューティングプラットホームに適用されました。

Henderson, et al.            Informational                      [Page 3]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[3ページ]のRFC5338

   Host Identifier (HI):  A public key of an asymmetric key pair used as
      a name for a Host Identity.  More details are available in
      [RFC5201].

識別子(HI)をホスティングしてください: Host Identityに名前として使用される非対称の主要な組の公開鍵。 その他の詳細は[RFC5201]で利用可能です。

   Host Identity Tag (HIT):  A 128-bit quantity composed with the hash
      of a Host Identity.  More details are available in [RFC4843] and
      [RFC5201].

アイデンティティタグ(ヒット)を接待してください: 128ビットの量はHost Identityのハッシュで構成されました。 その他の詳細は[RFC4843]と[RFC5201]で利用可能です。

   Local Scope Identifier (LSI):  A 32- or 128-bit quantity locally
      representing the Host Identity at the IPv4 or IPv6 API.

ローカルの範囲識別子(LSI): IPv4かIPv6APIに局所的にHost Identityを表す32か128ビットの量。

   Long-lived application associations:  The IP address is retained by
      the application for several instances of communication.

長命の応用アソシエーション: IPアドレスはコミュニケーションのいくつかのインスタンスのアプリケーションで保有されます。

   Referral:   In an application with more than two parties, party B
      takes the IP address of party A and passes that to party C.  After
      this, party C uses the IP address to communicate with A.

紹介: パーティーBは、2回以上のパーティーに伴うアプリケーションでは、パーティーAのアドレスをIPに取って、パーティーC.Afterにそれを通過します。これ、パーティーCはAで交信するのにIPアドレスを使用します。

   Resolver:  The system function used by applications to resolve domain
      names to IP addresses.

レゾルバ: IPアドレスにドメイン名を決議するのにアプリケーションで使用されるシステム機能。

   Short-lived local handle:  The IP addresses is never retained by the
      application.  The only usage is for the application to pass it
      from the DNS APIs (e.g., getaddrinfo()) and the API to the
      protocol stack (e.g., connect() or sendto()).

短命な地方のハンドル: IPアドレスはアプリケーションで決して保有されません。 プロトコルへの例えば、getaddrinfo())とAPIを積み重ねます。唯一の用法がアプリケーションがDNS APIからそれを通過することである、((例えば、()かsendto())を接続してください。

3.  Enabling HIP Transparently within the System

3. 透過的にシステムの中でヒップを可能にします。

   When both users and applications are unaware of HIP, but the host
   administrator chooses to use HIP between hosts, a few options are
   possible.  The first basic option is to perform a mapping of the
   application-provided IP address to a host identifier within the
   stack.  The second option, if DNS is used, is to interpose a local
   agent in the DNS resolution process and to return to the application
   a HIT or a locally scoped handle, formatted like an IP address.

ユーザとアプリケーションの両方がHIPに気づかないのですが、ホスト管理者が、ホストの間でHIPを使用するのを選ぶとき、いくつかのオプションが可能です。 最初の基本的なオプションはスタックの中でアプリケーションで提供されたIPアドレスに関するマッピングをホスト識別子に実行することです。 2番目のオプションは、DNSが使用されているなら、DNS解決プロセスで地元のエージェントを挿入して、IPアドレスのようにフォーマットされたHITか局所的に見られたハンドルをアプリケーションに返すことです。

3.1.  Applying HIP to Cases in Which IP Addresses Are Used

3.1. IPアドレスが使用されている場合にヒップを適用します。

   Consider the case in which an application issues a "connect(ip)"
   system call to set the default destination to a system named by
   address "ip", but for which the host administrator would like to
   enable HIP to protect the communications.  The user or application
   intends for the system to communicate with the host reachable at that
   IP address.  The decision to invoke HIP must be done on the basis of
   host policy.  For example, when an IPsec-based implementation of HIP
   is being used, a policy may be entered into the security policy
   database that mandates to use or to try HIP based on a match on the
   source or destination IP address, port numbers, or other factors.

アプリケーションが「(ip)を接続してください」というシステムコールを発行する場合がアドレス"ip"によってホスト管理者が、HIPがコミュニケーションを保護するのを可能にしたがっている、指定されたシステムにデフォルトの目的地を設定すると考えてください。 システムはユーザかアプリケーションがそのIPアドレスで届いているホストとコミュニケートするつもりです。 ホスト方針に基づいてHIPを呼び出すという決定をしなければなりません。 例えば、HIPのIPsecベースの実装が使用されていたか、方針がそれが使用に強制する安全保障政策データベースに入れられたかもしれないか、またはHIPを試みるのがソースか送付先IPアドレスのマッチを基礎づけたときには、数、または他の要素を移植してください。

Henderson, et al.            Informational                      [Page 4]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[4ページ]のRFC5338

   The mapping of IP address to host identifier may be implemented by
   modifying the host operating system or by wrapping the existing
   sockets API, such as in the TESLA approach [TESLA].

ホスト識別子へのIPアドレスに関するマッピングはホスト・オペレーティング・システムを変更するか、または既存のソケットAPIを包装することによって、実装されるかもしれません、テスラのアプローチ[テスラ]などのように。

   There are a number of ways that HIP could be configured by the host
   administrator in such a scenario.

ホスト管理者がそのようなシナリオでHIPを構成できるだろう多くの方法があります。

   Manual configuration:

手動の構成:

      Pre-existing Security Associations (SAs) may be available due to
      previous administrative action, or a binding between an IP address
      and a HIT could be stored in a configuration file or database.

Security Associations(SAs)を先在させるのが前の管理動作のために利用可能であるかもしれませんか、または構成ファイルかデータベースにIPアドレスとHITの間の結合は保存できました。

   Opportunistically:

便宜主義的に:

      The system could send an I1 to the Responder with an empty value
      for Responder HIT.

システムはResponder HITのために空の値があるResponderにI1を送るかもしれません。

   Using DNS to map IP addresses to HIs:

IPを写像するのにDNSを使用すると、以下はHIsに扱われます。

      If the Responder has host identifiers registered in the forward
      DNS zone and has a PTR record in the reverse zone, the Initiator
      could perform a reverse+forward lookup to learn the HIT associated
      with the address.  Although the approach should work under normal
      circumstances, it has not been tested to verify that there are no
      recursion or bootstrapping issues, particularly if HIP is used to
      secure the connection to the DNS servers.  Discussion of the
      security implications of the use or absence of DNS Security
      (DNSSEC) is deferred to the Security Considerations section.

Responderが前進のDNSゾーンにホスト識別子を登録させて、PTRに逆のゾーンに記録させるなら、Initiatorは、アドレスに関連しているHITを学ぶために逆の、または、前進のルックアップを実行するかもしれません。 アプローチは平常な時の下で働くべきですが、それはどんな再帰もブートストラップ法問題もないことを確かめるためにテストされていません、特にHIPがDNSサーバに接続を保証するのに使用されるなら。 使用のセキュリティ含意の議論かDNS Security(DNSSEC)の不在がSecurity Considerations部に延期されます。

   Using HIP in the above fashion can cause additional setup delays
   compared to using plain IP.  For opportunistic mode, a host must wait
   to learn whether the peer is HIP-capable, although the delays may be
   mitigated in some implementations by sending initial packets (e.g.,
   TCP SYN) in parallel to the HIP I1 packet and waiting some time to
   receive a HIP R1 before processing a TCP SYN/ACK.  Note that there
   presently does not exist specification for how to invoke such
   connections in parallel.  Resolution latencies may also be incurred
   when using DNS in the above fashion.

上のファッションでHIPを使用すると、明瞭なIPを使用すると比べて、追加セットアップ遅れは引き起こされる場合があります。 便宜主義的なモードを、ホストは、同輩がHIPできるかどうか学ぶのを待たなければなりません、HIP I1パケットに平行な初期のパケット(例えば、TCP SYN)を送って、いつかTCP SYN/ACKを処理する前にHIP R1を受け取るのを待つことによって、遅れはいくつかの実装で緩和されるかもしれませんが。 どう平行なそのような接続を呼び出すかためには仕様が現在存在しないことに注意してください。 また、上のファッションでDNSを使用するとき、解決潜在は被られるかもしれません。

   A possible way to reduce the above-noted latencies, in the case that
   the application uses DNS, would be for the system to
   opportunistically query for HIP records in parallel to other DNS
   resource records, and to temporarily cache the HITs returned with a
   DNS lookup, indexed by the IP addresses returned in the same entry,
   and pass the IP addresses up to the application as usual.  If an
   application connects to one of those IP addresses within a short time
   after the lookup, the host should initiate a base exchange using the

アプリケーションがDNSを使用して、上で有名な潜在を減少させる可能な方法は、システムがHIPのために便宜主義的に他のDNSリソース記録に平行な記録について質問して、一時同じエントリーで返されたIPアドレスによって索引をつけられたDNSルックアップと共に返されたHITsをキャッシュして、IPアドレスを通常通りのアプリケーションまで通過するだろうことです。 アプリケーションがルックアップの後に短い間以内にそれらのIPアドレスの1つに接続するなら、ホストは塩基置換使用を開始するべきです。

Henderson, et al.            Informational                      [Page 5]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[5ページ]のRFC5338

   cached HITs.  The benefit is that this removes the uncertainty/delay
   associated with opportunistic HIP, because the DNS record suggests
   that the peer is HIP-capable.

HITsをキャッシュしました。 利益はこれが便宜主義的なHIPに関連している不確実性/遅れを取り除くということです、DNS記録が、同輩がHIPできると示唆するので。

3.2.  Interposing a HIP-Aware Agent in the DNS Resolution

3.2. DNS解決でクールに意識しているエージェントを挿入します。

   In the previous section, it was noted that a HIP-unaware application
   might typically use the DNS to fetch IP addresses prior to invoking
   socket calls.  A HIP-enabled system might make use of DNS to
   transparently fetch host identifiers for such domain names prior to
   the onset of communication.

前項で、HIP気づかないアプリケーションがソケット呼び出しを呼び出す前にIPアドレスをとって来るのにDNSを通常使用するかもしれないことに注意されました。 HIPによって可能にされたシステムは、コミュニケーションの開始の前に透過的にそのようなドメイン名のためのホスト識別子をとって来るのにDNSを利用するかもしれません。

   A system with a local DNS agent could alternately return a Local
   Scope Identifier (LSI) or HIT rather than an IP address, if HIP
   information is available in the DNS or other directory that binds a
   particular domain name to a host identifier, and otherwise to return
   an IP address as usual.  The system can then maintain a mapping
   between LSI and host identifier and perform the appropriate
   conversion at the system call interface or below.  The application
   uses the LSI or HIT as it would an IP address.  This technique has
   been used in overlay networking experiments such as the Internet
   Indirection Infrastructure (i3) and by at least one HIP
   implementation.

地元のDNSエージェントとのシステムは交互にIPアドレスよりむしろLocal Scope Identifier(LSI)かHITを返すかもしれません、HIP情報がDNSか特定のドメイン名をホスト識別子に縛る他のディレクトリで利用可能であって、いつものようにIPアドレスを返すためにそうでないなら。 システムは、次に、LSIとホスト識別子の間のマッピングを維持して、システムコールインタフェースにおける以下での適切な変換を実行できます。 アプリケーションがLSIを使用するか、またはそれとしてのHITは使用するでしょう。IPアドレス。 このテクニックはインターネットIndirection Infrastructure(i3)などのオーバレイネットワーク実験と少なくとも1つのHIP実装によって使用されました。

   In the case when resolvers can return multiple destination
   identifiers for an application, it may be configured that some of the
   identifiers can be HIP-based identifiers, and the rest can be IPv4 or
   IPv6 addresses.  The system resolver may return HIP-based identifiers
   in front of the list of identifiers when the underlying system and
   policies support HIP.  An application processing the identifiers
   sequentially will then first try a HIP-based connection and only then
   other non-HIP based connections.  However, certain applications may
   launch the connections in parallel.  In such a case, the non-HIP
   connections may succeed before HIP connections.  Based on local
   system policies, a system may disallow such behavior and return only
   HIP-based identifiers when they are found from DNS.

レゾルバがアプリケーションのための複数の目的地識別子を返すことができるときの場合では、残りが識別子のいくつかがHIPベースの識別子であるかもしれなく、IPv4かIPv6アドレスであるかもしれないことが構成されるかもしれません。 基本的なシステムと方針がHIPをサポートすると、システムレゾルバはHIPベースの識別子を識別子のリストの正面に返すかもしれません。 次に、識別子を連続して処理するアプリケーションは最初にHIPベースの接続を裁くでしょう、そして、次にだけ、他の非HIPは接続を基礎づけました。 しかしながら、あるアプリケーションは平行な接続を送り出すかもしれません。 このような場合には、非HIP接続はHIP接続の前に成功するかもしれません。 ローカルシステム方針に基づいて、それらがDNSから見つけられるとき、システムは、そのような振舞いを禁じて、HIPベースの識別子だけを返すかもしれません。

   If the application obtains LSIs or HITs that it treats as IP
   addresses, a few potential hazards arise.  First, applications that
   perform referrals may pass the LSI to another system that has no
   system context to resolve the LSI back to a host identifier or an IP
   address.  Note that these are the same type of applications that will
   likely break if used over certain types of network address
   translators (NATs).  Second, applications may cache the results of
   DNS queries for a long time, and it may be hard for a HIP system to
   determine when to perform garbage collection on the LSI bindings.
   However, when using HITs, the security of using the HITs for identity
   comparison may be stronger than in the case of using IP addresses.

アプリケーションがそれがIPアドレスを扱うLSIかHITsを入手するなら、いくつかの潜在的な危険が起こります。 まず最初に、紹介を実行するアプリケーションは、ホスト識別子かIPアドレスにLSIを決議して戻すためにシステムの背景を全く持っていない別のシステムへのLSIを通過するかもしれません。 これらが、あるタイプのネットワークアドレス変換機構(NATs)の上で使用されるならおそらく壊れる同じタイプのアプリケーションであることに注意してください。 2番目に、アプリケーションは長い間、DNS質問の結果をキャッシュするかもしれません、そして、HIPシステムが、いつLSI結合にガーベージコレクションを実行するかを決定するのは、困難であるかもしれません。 しかしながら、HITsを使用するとき、アイデンティティ比較にHITsを使用するセキュリティはIPアドレスを使用するケースより強いかもしれません。

Henderson, et al.            Informational                      [Page 6]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[6ページ]のRFC5338

   Finally, applications may generate log files, and administrators or
   other consumers of these log files may become confused to find LSIs
   or HITs instead of IP addresses.  Therefore, it is recommended that
   the HIP software logs the HITs, LSIs (if applicable), corresponding
   IP addresses, and Fully Qualified Domain Name (FQDN)-related
   information so that administrators can correlate other logs with HIP
   identifiers.

最終的に、アプリケーションはログファイルを生成するかもしれません、そして、これらのログファイルの管理者か他の消費者がIPアドレスの代わりにLSIかHITsを見つけるために混乱するようになるかもしれません。 したがって、HIPソフトウェアがHITs、LSI(適切であるなら)、対応するIPアドレス、およびFully Qualified Domain Nameの(FQDN)関連の情報を登録するのは、管理者がHIP識別子で他のログを関連させることができるように、お勧めです。

   It may be possible for an LSI or HIT to be routable or resolvable,
   either directly or through an overlay, in which case it would be
   preferable for applications to handle such names instead of IP
   addresses.  However, such networks are out of scope of this document.

LSIかHITが直接かオーバレイを通して発送可能であるか、または溶解性であることが、可能であるかもしれない、その場合、アプリケーションがIPアドレスの代わりにそのような名前を処理するのは、望ましいでしょう。 しかしながら、このドキュメントの範囲の外にそのようなネットワークがあります。

3.3.  Discussion

3.3. 議論

   Solutions preserving the use of IP addresses in the applications have
   the benefit of better support for applications that use IP addresses
   for long-lived application associations, callbacks, and referrals,
   although it should be noted that applications are discouraged from
   using IP addresses in this manner due to the frequent presence of
   NATs [RFC1958].  However, they have weaker security properties than
   the approaches outlined in Section 3.2 and Section 4, because the
   binding between host identifier and address is weak and not visible
   to the application or user.  In fact, the semantics of the
   application's "connect(ip)" call may be interpreted as "connect me to
   the system reachable at IP address ip" but perhaps no stronger
   semantics than that.  HIP can be used in this case to provide perfect
   forward secrecy and authentication, but not to strongly authenticate
   the peer at the onset of communications.

アプリケーションにおけるIPアドレスの使用を保存するソリューションが長命の応用アソシエーションにIPアドレスを使用するアプリケーション、コールバック、および紹介の、より良いサポートの恩恵を持っています、アプリケーションがNATs[RFC1958]の頻繁な存在のためこの様にIPアドレスを使用するのでお勧めできないことに注意されるべきですが。 しかしながら、彼らには、セクション3.2とセクション4に概説されたアプローチより弱いセキュリティの特性があります、アプリケーションかユーザにとって、ホスト識別子とアドレスの間の結合が弱くて、目に見えないので。 事実上、アプリケーションの「(ip)を接続してください」呼び出しの意味論は「IPアドレスipで届いているシステムに私を接続してください」にもかかわらず、恐らくそれより強いどんな意味論としても解釈されないかもしれません。 この場合コミュニケーションの開始のときに強く同輩を認証するのではなく、完全な前進の秘密保持と認証を提供するのにHIPを使用できます。

   Using IP addresses at the application layer may not provide the full
   potential benefits of HIP mobility support.  It allows for mobility
   if the system is able to readdress long-lived, connected sockets upon
   a HIP readdress event.  However, as in current systems, mobility will
   break in the connectionless case, when an application caches the IP
   address and repeatedly calls sendto(), or in the case of TCP when the
   system later opens additional sockets to the same destination.

応用層でIPアドレスを使用するのはHIP移動性サポートの完全な潜在的利益を提供しないかもしれません。 システムが長命の、そして、接続されたソケットにあて名を書き直させることができるなら、それは移動性を考慮します。HIPでは、イベントにあて名を書き直させてください。 しかしながら、現在のシステムのように、移動性はコネクションレスなケースを使いならすでしょう、アプリケーションがIPアドレスをキャッシュして、繰り返してsendto()と呼ぶか、または後でシステムであることのTCPの場合で同じ目的地に追加ソケットを開けると。

   Section 4.1.6 of the base HIP protocol specification [RFC5201] states
   that implementations that learn of HIT-to-IP address bindings through
   the use of HIP opportunistic mode must not enforce those bindings on
   later communications sessions.  This implies that when IP addresses
   are used by the applications, systems that attempt to
   opportunistically set up HIP must not assume that later sessions to
   the same address will communicate with the same host.

.6のセクション4.1ベースHIPプロトコル仕様[RFC5201]が、HIPの便宜主義的なモードの使用でHITからIPへのアドレス結合を知っている実装が後のコミュニケーションセッションのときにそれらの結合を実施してはいけないと述べます。 これは、IPアドレスがアプリケーションで使用されるとき、便宜主義的にHIPをセットアップするのを試みるシステムが、同じアドレスへの後のセッションが同じホストとコミュニケートすると仮定してはいけないのを含意します。

Henderson, et al.            Informational                      [Page 7]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[7ページ]のRFC5338

   The legacy application is unaware of HIP and therefore cannot notify
   the user when the application uses HIP.  However, the operating
   system can notify the user of the usage of HIP through a user agent.
   Further, it is possible for the user agent to name the network
   application that caused a HIP-related event.  This way, the user is
   aware when he or she is using HIP even though the legacy network
   application is not.  Based on usability tests from initial
   deployments, displaying the HITs and LSIs should be avoided in user
   interfaces.  Instead, traditional security measures (lock pictures,
   colored address bars) should be used where possible.

アプリケーションがHIPを使用する場合、レガシーアプリケーションは、HIPに気づかなく、したがって、ユーザに通知できません。 しかしながら、オペレーティングシステムはユーザエージェントを通してHIPの使用法についてユーザに通知できます。 さらに、ユーザエージェントがHIP関連のイベントを引き起こしたネットワーク応用を命名するのは、可能です。 この道、レガシーネットワーク応用は意識していませんが、その人がHIPを使用しているとき、ユーザは意識しています。 初期の展開からの有用性能試験に基づいて、HITsとLSIを表示するのはユーザインタフェースで避けられるべきです。 代わりに、伝統的な安全策(アドレスバーに着色されたロック画像)は可能であるところで使用されるべきです。

   One drawback to spoofing the DNS resolution is that some
   applications, or selected instances of an application, actually may
   want to fetch IP addresses (e.g., diagnostic applications such as
   ping).  One way to provide finer granularity on whether the resolver
   returns an IP address or an LSI is to have the user form a modified
   domain name when he or she wants to invoke HIP.  This leads us to
   consider, in the next section, use cases for which the end user
   explicitly and selectively chooses to enable HIP.

DNS解決を偽造することへの1つの欠点はいくつかのアプリケーション、またはアプリケーションの選択されたインスタンスが実際に、IPアドレス(例えば、ピングなどの診断アプリケーション)をとって来たがっているかもしれないということです。 レゾルバがIPアドレスかLSIを返すかどうかに関して、よりすばらしい粒状を提供する1つの方法はその人がHIPを呼び出したがっているとき、ユーザに変更されたドメイン名を形成させることです。 これは、私たちが、次のセクションで使用がエンドユーザがHIPを有効にするのを明らかに選択的に選ぶケースであると考えるように導きます。

4.  Users Invoking HIP with a Legacy Application

4. レガシーアプリケーションでヒップを呼び出しているユーザ

   The previous section described approaches for configuring HIP for
   legacy applications that did not necessarily involve the user.
   However, there may be cases in which a legacy application user wants
   to use HIP for a given application instance by signaling to the HIP-
   enabled system in some way.  If the application user interface or
   configuration file accepts IP addresses, there may be an opportunity
   to provide a HIT or an LSI in its place.  Furthermore, if the
   application uses DNS, a user may provide a specially crafted domain
   name to signal to the resolver to fetch HIP records and to signal to
   the system to use HIP.  We describe both of these approaches below.

前項は必ずユーザにかかわったというわけではないレガシーアプリケーションのためにHIPを構成するためのアプローチについて説明しました。 しかしながら、レガシーアプリケーションユーザが与えられたアプリケーションインスタンスに何らかの方法でHIPの可能にされたシステムに合図することによってHIPを使用したがっている場合があるかもしれません。 アプリケーションユーザーインタフェースか構成ファイルがIPアドレスを受け入れるなら、HITかLSIを場所に提供する機会があるかもしれません。 その上、アプリケーションがDNSを使用するなら、ユーザは、HIPに記録をとって来て、HIPを使用するためにシステムに合図するためにレゾルバに合図するために特に、作られたドメイン名を提供するかもしれません。 私たちは以下のこれらのアプローチの両方について説明します。

4.1.  Connecting to a HIT or LSI

4.1. ヒットかLSIに接続すること。

   Section 3.2 above describes the use of HITs or LSIs as spoofed return
   values of the DNS resolution process.  A similar approach that is
   more explicit is to configure the application to connect directly to
   a HIT (e.g., "connect(HIT)" as a socket call).  This scenario has
   stronger security semantics, because the application is asking the
   system to send packets specifically to the named peer system.  HITs
   have been defined as Overlay Routable Cryptographic Hash Identifiers
   (ORCHIDs) such that they cannot be confused with routable IP
   addresses; see [RFC4843].

DNS解決プロセスのリターン値であると偽造されるように上のセクション3.2はHITsかLSIの使用について説明します。 より明白な同様のアプローチは直接HIT(例えば、ソケット呼び出しとしての「接続してください(当たる)」)に接続するためにアプリケーションを構成することです。 このシナリオには、より強いセキュリティ意味論があります、アプリケーションが、特に命名された同輩システムにパケットを送るようにシステムに頼んでいるので。 HITsは彼らが発送可能IPアドレスに混乱できないように、Overlay Routable Cryptographic Hash Identifiers(ORCHIDs)と定義されました。 [RFC4843]を見てください。

   This approach also has a few challenges.  Using HITs can be more
   cumbersome for human users (due to the flat HIT name space) than
   using either IPv6 addresses or domain names.  Another challenge with

また、このアプローチには、いくつかの挑戦があります。 人間のユーザには、HITsを使用するのはIPv6アドレスかドメイン名のどちらかを使用するより厄介である場合があります(スペースという平坦なHIT名による)。 別のものは挑戦します。

Henderson, et al.            Informational                      [Page 8]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[8ページ]のRFC5338

   this approach is in actually finding the IP addresses to use, based
   on the HIT.  Some type of HIT resolution service would be needed in
   this case.  A third challenge of this approach is in supporting
   callbacks and referrals to possibly non-HIP-aware hosts.  However,
   since most communications in this case would likely be to other HIP-
   aware hosts (else the initial HIP associations would fail to
   establish), the resulting referral problem may be that the peer host
   supports HIP but is not able to perform HIT resolution for some
   reason.

実際にHITに基づいて使用するIPアドレスを見つけるのにおいてこのアプローチがあります。 タイプのHIT解決サービスがこの場合必要でしょう。 コールバックと紹介をサポートするのにおいてこのアプローチの3番目の挑戦がことによるとある、非HIP意識する、ホスト。 しかしながら、大部分以来、他のHIPの意識しているホストにはこの場合、コミュニケーションがおそらくあるだろう、(ほか、協会が設立しない初期のHIP)、同輩ホストがHIPをサポートするということであるかもしれませんが、結果として起こる紹介問題は、ある理由でHIT解決を実行できません。

4.2.  Using a Modified DNS Name

4.2. 変更されたDNS名を使用します。

   Specifically, if the application requests to resolve "HIP-
   www.example.com" (or some similar prefix string), then the system
   returns an LSI, while if the application requests to resolve
   "www.example.com", IP address(es) are returned as usual.  The use of
   a prefix rather than suffix is recommended, and the use of a string
   delimiter that is not a dot (".") is also recommended, to reduce the
   likelihood that such modified DNS names are mistakenly treated as
   names rooted at a new top-level domain.  Limits of domain name length
   or label length (255 or 63, respectively) should be considered when
   prepending any prefixes.

明確に、システムは"HIP- www.example.com"(または、何らかの同様の接頭語ストリング)を決議するというアプリケーション要求であるならLSIを返します、"www.example.com"を決議するというアプリケーション要求であるなら、いつものようにIPアドレス(es)を返しますが。 接尾語よりむしろ接頭語の使用がお勧めであってドットでないストリングデリミタの使用である、(「」、)、また、そのような変更されたDNS名が新しい最上位のドメインで根づいている名前として誤って扱われるという見込みを減少させることが勧められます。 どんな接頭語もprependingするとき、ドメイン名の長さかラベルの長さ(それぞれ255か63)の限界は考えられるべきです。

4.3.  Other Techniques

4.3. 他のテクニック

   Alternatives to using a modified DNS name that have been experimented
   with include the following.  Command-line tools or tools with a
   graphical user interface (GUI) can be provided by the system to allow
   a user to set the policy on which applications use HIP.  Another
   common technique, for dynamically linked applications, is to
   dynamically link the application to a modified library that wraps the
   system calls and interposes HIP layer communications on them; this
   can be invoked by the user by running commands through a special
   shell, for example.

変更されたDNS名を使用することへの実験された代替手段は以下を含んでいます。 システムでグラフィカルユーザーインターフェース(GUI)があるコマンドラインツールかツールを提供して、ユーザがアプリケーションがHIPを使用する方針を設定するのを許容できます。 別の一般的なテクニックはダイナミックにリンクされたアプリケーションのためにダイナミックにシステムコールを包装して、HIP層のコミュニケーションをそれらに挿入する変更されたライブラリにアプリケーションをリンクすることです。 ユーザは、例えば、特別なシェルを通してコマンドを実行することによって、これを呼び出すことができます。

5.  Local Address Management

5. ローカルアドレス管理

   The previous two sections focused mainly on controlling client
   behavior (HIP initiator).  We must also consider the behavior for
   servers.  Typically, a server binds to a wildcard IP address and
   well-known port.  In the case of HIP use with legacy server
   implementations, there are again a few options.  The system may be
   configured manually to always, optionally (depending on the client
   behavior), or never use HIP with a particular service, as a matter of
   policy, when the server specifies a wildcard (IP) address.

前の2つのセクションが、主に、クライアントの振舞い(HIP創始者)を制御するのは焦点を合わせました。 また、私たちはサーバのための振舞いを考えなければなりません。 通常、サーバはワイルドカードIPアドレスとウェルノウンポートに付きます。 レガシーサーバ実装があるHIP使用の場合には、いくつかのオプションが再びあります。 システムは特定のサービスがあるHIPを決して使用しないように手動で構成されるかもしれません、政策の問題として、サーバがワイルドカード(IP)アドレスを指定するとき。

Henderson, et al.            Informational                      [Page 9]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[9ページ]のRFC5338

   When a system API call such as getaddrinfo [RFC3493] is used for
   resolving local addresses, it may also return HITs or LSIs, if the
   system has assigned HITs or LSIs to internal virtual interfaces
   (common in many HIP implementations).  The application may use such
   identifiers as addresses in subsequent socket calls.

また、getaddrinfo[RFC3493]などのシステムAPI呼び出しがローカルのアドレスを決議するのに使用されるとき、HITsかLSIを返すかもしれません、システムが内部の仮想インターフェース(多くのHIP実装で一般的な)にHITsかLSIを割り当てたなら。 アプリケーションはその後のソケット呼び出しにアドレスのような識別子を使用するかもしれません。

   Some applications may try to bind a socket to a specific local
   address, or may implement server-side access control lists based on
   socket calls such as getsockname() and getpeername() in the C-based
   socket APIs.  If the local address specified is an IP address, again,
   the underlying system may be configured to still use HIP.  If the
   local address specified is a HIT (Section 4), the system should
   enforce that connections to the local application can only arrive to
   the specified HIT.  If a system has many HIs, an application that
   binds to a single HIT cannot accept connections to the other HIs but
   the one corresponding to the specified HIT.

いくつかのアプリケーションが、特定のローカルアドレスにソケットを縛ろうとするか、またはCベースのソケットAPIでgetsockname()やgetpeername()などのソケット呼び出しに基づくサーバサイドアクセスコントロールリストを実装するかもしれません。 指定されたローカルアドレスがIPアドレスであるなら、一方、基本的なシステムは、まだHIPを使用しているために構成されるかもしれません。 システムは指定されたローカルアドレスがHIT(セクション4)であるなら、実施されるはずです。局所塗布との接続は指定されたHITに到着できるだけです。 システムに多くのHIsがあるなら、独身のHITに付くアプリケーションは他のHIsに接続を受け入れることができるのではなく、指定されたHITに対応するものを受け入れます。

   When a host has multiple HIs and the socket behavior does not
   prescribe the use of any particular HI as a local identifier, it is a
   matter of local policy as to how to select a HI to serve as a local
   identifier.  However, systems that bind to a wildcard may face
   problems when multiple HITs or LSIs are defined.  These problems are
   not specific to HIP per se, but are also encountered in non-HIP
   multihoming scenarios with applications not designed for multihoming.

ホストが複数のHIsを持って、ソケットの振舞いがローカルの識別子としてどんな特定のHIの使用も定めないとき、ローカルの識別子として機能するのは、どうHIを選択するかに関するローカルの方針の問題です。 しかしながら、複数のHITsかLSIが定義されるとき、ワイルドカードに固まるシステムは問題に直面するかもしれません。 これらの問題は、そういうもののHIPに特定ではありませんが、また、アプリケーションがマルチホーミングのために設計されていなく、非HIPマルチホーミングシナリオで行きあたられます。

   As an example, consider a client application that sends a UDP
   datagram to a server that is bound to a wildcard.  The server
   application receives the packet using recvfrom() and sends a response
   using sendto().  The problem here is that sendto() may actually use a
   different server HIT than the client assumes.  The client will drop
   the response packet when the client implements access control on the
   UDP socket (e.g., using connect()).

例と、ワイルドカードに縛られるサーバにUDPデータグラムを送るクライアントアプリケーションを考えてください。 サーバ・アプリケーションは、recvfrom()を使用することでパケットを受けて、sendto()を使用することで応答を送ります。 sendto()が実際にクライアントが仮定するより異なったサーバHITを使用するかもしれないという問題がここにあります。 クライアントはクライアントがUDPソケットの上にアクセスがコントロールであると実装する応答パケットを下げるでしょう。(例えば、使用は())を接続します。

   Reimplementing the server application using the sendmsg() and
   recvmsg() to support multihoming (particularly considering the
   ancillary data) would be the ultimate solution to this problem, but
   with legacy applications is not an option.  As a workaround, we make
   suggestion for servers providing UDP-based services with non-
   multihoming-capable services.  Such servers should announce only the
   HIT or public key that matches to the default outgoing HIT of the
   host to avoid such problems.

マルチホーミングをサポートするのにsendmsg()とrecvmsg()を使用することで(特に補助データを考える場合)サーバ・アプリケーションをReimplementingするのは、この問題の根本的な解決でしょうが、レガシーアプリケーションで、オプションがありません。 回避策として、私たちは、マルチホーミングできる非サービスをUDPベースのサービスに提供しながら、サーバのための提案をします。 そのようなサーバはそのような問題を避けるためにホストの出発しているHITをデフォルトに合わせるHITか公開鍵だけを発表するべきです。

   Finally, some applications may create a connection to a local HIT.
   In such a case, the local system may use NULL encryption to avoid
   unnecessary encryption overhead, and may be otherwise more permissive
   than usual such as excluding authentication, Diffie-Hellman exchange,
   and puzzle.

最終的に、いくつかのアプリケーションが地方のHITに接続を創造するかもしれません。 不要な暗号化オーバーヘッドを避けるのにNULL暗号化を使用するかもしれません。そうでなければ、このような場合には、ローカルシステムは、認証、ディフィー-ヘルマンの交換、およびパズルを除くのなどようにいつもより寛大であるかもしれません。

Henderson, et al.            Informational                     [Page 10]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[10ページ]のRFC5338

6.  Security Considerations

6. セキュリティ問題

   In this section, we discuss the security of the system in general
   terms, outlining some of the security properties.  However, this
   section is not intended to provide a complete risk analysis.  Such an
   analysis would, in any case, be dependent on the actual application
   using HIP, and is therefore considered out of scope.

このセクションで、いくつかのセキュリティの特性について概説して、私たちはあいまいな言葉でシステムのセキュリティについて議論します。 しかしながら、このセクションが完全な危険分析を提供することを意図しません。 そのような分析は、どのような場合でも、HIPを使用することで本番適用に依存していて、したがって、範囲から考えられます。

   The scenarios outlined above differ considerably in their security
   properties.  When the DNS is used, there are further differences
   related to whether or not DNSSEC [RFC4033] is used, and whether the
   DNS zones are considered trustworthy enough.  Here we mean that there
   should exist a delegation chain to whatever trust anchors are
   available in the respective trees, and the DNS zone administrators in
   charge of the netblock should be trusted to put in the right
   information.

上に概説されたシナリオは彼らのセキュリティ所有地でかなり異なります。 DNSが使用されているとき、さらに、DNSSEC[RFC4033]が使用されていて、DNSゾーンが十分信頼できると考えられるか否かに関係なく、関連する違いがあります。 ここで、私たちは、いかなるそれぞれの木に手があいている信頼アンカーへの委譲チェーンも存在するべきであり、netblock担当のDNSゾーンの管理者が正しい情報を入れると信じられるべきであると言っています。

   When IP addresses are used by applications to name the peer system,
   the security properties depend on the configuration method.  With
   manual configuration, the security of the system is comparable to a
   non-HIP system with similar IPsec policies.  The security semantics
   of an initial opportunistic key exchange are roughly equal to non-
   secured IP; the exchange is vulnerable to man-in-the-middle attacks.
   However, the system is less vulnerable to connection hijacking
   attacks.  If the DNS is used, if both zones are secured (or the HITs
   are stored in the reverse DNS record) and the client trusts the
   DNSSEC signatures, the system may provide a fairly high security
   level.  However, much depends on the details of the implementation,
   the security and administrative practices used when signing the DNS
   zones, and other factors.

IPアドレスが同輩システムを命名するのにアプリケーションで使用されるとき、セキュリティの特性は構成メソッドに依存します。 手動の構成で、システムのセキュリティは同様のIPsec方針で非HIPシステムに匹敵しています。 初期の便宜主義的な主要な交換のセキュリティ意味論はおよそ非機密保護しているIPと等しいです。 交換は介入者攻撃に被害を受け易いです。 しかしながら、システムはそれほど接続ハイジャック攻撃に害を被りやすくはありません。 両方のゾーンを保証するなら(HITsは逆のDNS記録に保存されます)DNSが使用されていて、クライアントがDNSSEC署名を信じるなら、システムはかなり高いセキュリティー・レベルを提供するかもしれません。 しかしながら、多くがDNSがゾーンと、他の要素であると署名するとき使用される実装の詳細、セキュリティ、および管理習慣に依存します。

   Using the forward DNS to map a domain name into an LSI is a case that
   is closest to the most typical use scenarios today.  If DNSSEC is
   used, the result is fairly similar to the current use of certificates
   with Transport Layer Security (TLS).  If DNSSEC is not used, the
   result is fairly similar to the current use of plain IP, with the
   additional protection of data integrity, confidentiality, and
   prevention of connection hijacking that opportunistic HIP provides.
   If DNSSEC is used, data integrity and data origin authentication
   services are added to the normal DNS query protocol, thereby
   providing more certainty that the desired host is being contacted, if
   the DNS records themselves are trustworthy.

ドメイン名をLSIに写像するのに前進のDNSを使用して、今日、最も典型的な使用の最も近くにあるケースはシナリオですか? DNSSECが使用されているなら、結果はTransport Layer Security(TLS)との証明書の現在の使用とかなり同様です。 DNSSECが使用されていないなら、便宜主義的なHIPが提供するという結果は接続ハイジャックのデータ保全、秘密性、および防止の追加保護による明瞭なIPの現在の使用とかなり同様です。 DNSSECが使用されているなら、データ保全とデータ発生源認証サービスは正常なDNS質問プロトコルに追加されます、その結果、必要なホストが連絡されているというより多くの確実性を提供します、DNS記録自体が信頼できるなら。

Henderson, et al.            Informational                     [Page 11]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[11ページ]のRFC5338

   If the application is basing its operations on HITs, the connections
   become automatically secured due to the implicit channel bindings in
   HIP.  That is, when the application makes a connect(HIT) system call,
   either the resulting packets will be sent to a node possessing the
   corresponding private key or the security association will fail to be
   established.

アプリケーションが操作をHITsに基礎づけているなら、接続はHIPで暗黙のチャンネル結合のため自動的に機密保護されるようになります。 すなわち、aがアプリケーションで(HIT)システムコールを接続すると、対応する秘密鍵を持っているノードに結果として起こるパケットを送るだろうか、またはセキュリティ協会は設立しないでしょう。

   When the system provides (spoofs) LSIs or HITs instead of IP
   addresses as the result of name resolution, the resultant fields may
   inadvertently show up in user interfaces and system logs, which may
   cause operational concerns for some network administrators.
   Therefore, it is recommended that the HIP software logs the HITs,
   LSIs (if applicable), corresponding IP addresses, and FQDN-related
   information so that administrators can correlate other logs with HIP
   identifiers.

システムがIPの代わりにLSIかHITsが名前解決の結果として扱う(パロディー)を提供するとき、結果の野原はユーザインタフェースとシステムログにうっかり現れるかもしれません。(システムログは何人かのネットワーク管理者に関する操作上の心配をかけるかもしれません)。 したがって、HIPソフトウェアがHITs、LSI(適切であるなら)、対応するIPアドレス、およびFQDN関連の情報を登録するのは、管理者がHIP識別子で他のログを関連させることができるように、お勧めです。

7.  Acknowledgments

7. 承認

   Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen,
   Julien Laganier, and Jukka Ylitalo have provided comments on
   different versions of this document.  The document received
   substantial and useful comments during the review phase from David
   Black, Lars Eggert, Peter Koch, Thomas Narten, and Pekka Savola.

ジェフAhrenholz、ゴンサロ・キャマリロ、アルベルト・ガルシア、テームKoponen、ジュリアンLaganier、およびユッカYlitaloはこのドキュメントの異なった見解のコメントを提供しました。 ドキュメントはレビュー段階の間、デヴィッドBlack、ラース・エッゲルト、ピーター・コッホ、トーマスNarten、およびペッカSavolaから実質的で役に立つコメントを受けました。

8.  Informative References

8. 有益な参照

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
              Henderson, "Host Identity Protocol", RFC 5201, April 2008.

[RFC5201]マスコウィッツ、R.、Nikander、P.、Jokela、P.、エド、T.ヘンダーソン、「ホストアイデンティティプロトコル」、RFC5201、4月2008日

   [RFC4843]   Nikander, P., Laganier, J., and F. Dupont, "An IPv6
              Prefix for Overlay Routable Cryptographic Hash Identifiers
              (ORCHID)", RFC 4843, April 2007.

[RFC4843] Nikander、P.、Laganier、J.、およびF.デュポン、「オーバレイのRoutableの暗号のハッシュ識別子(ラン)のためのIPv6接頭語」、RFC4843(2007年4月)。

   [TESLA]     Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA:  A
              Transparent, Extensible Session-Layer Architecture for
              End-to-end Network Services",  Proceedings of USENIX
              Symposium on Internet Technologies and Systems (USITS),
              pages 211-224, March 2003.

[テスラ]ザルツ、J.、Balakrishnan、H.、およびA.Snoeren、「テスラ:」 「Transparent、Endから終わりへのNetwork ServicesのためのExtensible Session-層のArchitecture」とインターネットTechnologiesの上のUSENIX SymposiumのProceedingsとSystems(USITS)、211-224ページ、2003年3月。

   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
              Internet", RFC 1958, June 1996.

[RFC1958] 大工、B.、エド、「インターネットの建築プリンシプルズ」、RFC1958、6月1996日

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。

Henderson, et al.            Informational                     [Page 12]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[12ページ]のRFC5338

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6", RFC
              3493, February 2003.

[RFC3493] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャン、J.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」

   [APP_REF]  Nordmark, E., "Shim6 Application Referral Issues", Work in
              Progress, July 2005.

E.、「Shim6アプリケーション紹介問題」という[装置_審判]Nordmarkは進歩、2005年7月に働いています。

Authors' Addresses

作者のアドレス

   Thomas Henderson
   The Boeing Company
   P.O. Box 3707
   Seattle, WA
   USA

トーマス・ヘンダーソンボーイング社P.O. Box3707ワシントンシアトル(米国)

   EMail: thomas.r.henderson@boeing.com

メール: thomas.r.henderson@boeing.com

   Pekka Nikander
   Ericsson Research NomadicLab
   JORVAS  FIN-02420
   FINLAND

ペッカ・Nikanderエリクソン研究NomadicLab JORVASフィン-02420フィンランド

   Phone: +358 9 299 1
   EMail: pekka.nikander@nomadiclab.com

以下に電話をしてください。 +358 9 299 1 メール: pekka.nikander@nomadiclab.com

   Miika Komu
   Helsinki Institute for Information Technology
   Metsaenneidonkuja 4
   Helsinki  FIN-02420
   FINLAND

情報技術Metsaenneidonkuja4ヘルシンキフィン-02420フィンランドのミカKomuヘルシンキ研究所

   Phone: +358503841531
   EMail: miika@iki.fi

以下に電話をしてください。 +358503841531 メールしてください: miika@iki.fi

Henderson, et al.            Informational                     [Page 13]

RFC 5338           Using HIP with Legacy Applications     September 2008

ヘンダーソン、他 2008年9月にレガシーアプリケーションがあるヒップを使用する情報[13ページ]のRFC5338

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Henderson, et al.            Informational                     [Page 14]

ヘンダーソン、他 情報[14ページ]