RFC 3715 - IPsec-Network Address Translation (NAT) Compatibility Requirements 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3715
タイトル : RFC 3715 - IPSEC-Networkアドレス翻訳（NAT）互換性要件
翻訳編集 : 自動生成

[要約] 要約：RFC 3715は、IPsecとNATの互換性要件についてのガイドラインです。目的：IPsecとNATの組み合わせにおいて、セキュリティと通信の問題を解決するための要件を提供すること。

Network Working Group                                           B. Aboba
Request for Comments: 3715                                      W. Dixon
Category: Informational                                        Microsoft
                                                              March 2004

IPsec-Network Address Translation (NAT) Compatibility Requirements

IPSEC-Networkアドレス翻訳（NAT）互換性要件

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 describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses.

このドキュメントは、ネットワークアドレス変換（NAT）とIPSECの間の既知の非互換性について説明し、それらに対処するための要件を説明します。おそらく、IPSECの最も一般的な使用は、仮想プライベートネットワーキング機能を提供することです。仮想プライベートネットワーク（VPN）の非常に人気のある使用の1つは、企業イントラネットへの通信者アクセスを提供することです。今日、NATはホームゲートウェイやホテルなどの電気在庫が使用する可能性のある他の場所に広く展開されています。その結果、IPSEC-NATの非互換性は、主要な使用法の1つでのIPSECの展開における大きな障壁となっています。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Requirements Language. . . . . . . . . . . . . . . . . .  2
   2.  Known Incompatibilities between NA(P)T and IPsec . . . . . . .  3
       2.1.  Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . .  3
       2.2.  NA(P)T Implementation Weaknesses . . . . . . . . . . . .  7
       2.3.  Helper Incompatibilities . . . . . . . . . . . . . . . .  8
   3.  Requirements for IPsec-NAT Compatibility . . . . . . . . . . .  8
   4.  Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.  IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12
       4.2.  RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.3.  6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
       6.1.  Normative References . . . . . . . . . . . . . . . . . . 15
       6.2.  Informative References . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18

1. Introduction

1. はじめに

Perhaps the most common use of IPsec [RFC2401] is in providing virtual private networking (VPN) capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today, Network Address Translations (NATs) as described in [RFC3022] and [RFC2663], are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This document describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them.

おそらく、IPSEC [RFC2401]の最も一般的な使用は、仮想プライベートネットワーキング（VPN）機能を提供することです。VPNの非常に人気のある使用の1つは、企業イントラネットへのテレコミーターアクセスを提供することです。今日、[RFC3022]および[RFC2663]に記載されているネットワークアドレス翻訳（NAT）は、ホーム在庫やホテルなどの通信業者が使用する可能性のある他の場所に広く展開されています。その結果、IPSEC-NATの非互換性は、主要な使用法の1つでのIPSECの展開における大きな障壁となっています。このドキュメントは、NATとIPSECの間の既知の非互換性について説明し、それらに対処するための要件を説明します。

1.1. Requirements Language

1.1. 要件言語

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].

このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「は」、「はすか」、「必要はありません」は、[RFC2119]に記載されているように解釈されるべきではありません。

Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is not the same thing as requiring that all protocol traffic be encrypted.

このドキュメントで指定されている要件は、プロトコルの提出の評価に使用されることに注意してください。そのため、要件言語とは、これらのプロトコルの機能を指します。プロトコルドキュメントは、これらの機能が必要な、推奨、またはオプションであるかどうかを指定します。たとえば、プロトコルをサポートすることを要求することは、すべてのプロトコルトラフィックを暗号化することを要求するのと同じものではありません。

A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements, but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."

プロトコルの提出は、それが実装する機能の要件の1つ以上を満たすことができない場合、準拠していません。その機能の要件をすべて満たす、必要ではなく、そうでなければならない、必要ではない、そしてすべきではないプロトコルの提出は、「無条件に準拠している」と言われています。すべての要件を満たす必要があり、必要ではないものをすべて満たしているものですが、そのプロトコルの要件はすべて「条件付きで準拠」していると言われています。

2. Known Incompatibilities between NA(P)T and IPsec

2. Na（P）TとIPSECの間の既知の非互換性

The incompatibilities between NA(P)T and IPsec can be divided into three categories:

Na（P）TとIPSECの互換性は、次の3つのカテゴリに分けることができます。

1) Intrinsic NA(P)T issues. These incompatibilities derive directly from the NA(P)T functionality described in [RFC3022]. These incompatibilities will therefore be present in any NA(P)T device.

1) 固有のna（p）tの問題。これらの非互換性は、[RFC3022]で説明されているNa（P）T機能に直接派生しています。したがって、これらの互換性は、任意のNa（P）Tデバイスに存在します。

2) NA(P)T implementation weaknesses. These incompatibilities are not intrinsic to NA(P)T, but are present in many NA(P)T implementations. Included in this category are problems in handling inbound or outbound fragments. Since these issues are not intrinsic to NA(P)T, they can, in principle, be addressed in future NA(P)T implementations. However, since the implementation problems appear to be wide spread, they need to be taken into account in a NA(P)T traversal solution.

2) Na（p）T実装の弱点。これらの非互換性は、Na（P）Tに固有のものではありませんが、多くのNa（P）Tの実装に存在します。このカテゴリには、インバウンドまたはアウトバウンドフラグメントの処理に問題があります。これらの問題はNa（P）Tに固有のものではないため、原則として、将来のNa（P）Tの実装で対処できます。ただし、実装の問題は広範囲に広がっているように見えるため、Na（P）Tトラバーサル溶液で考慮する必要があります。

3) Helper issues. These incompatibilities are present in NA(P)T devices which attempt to provide for IPsec NA(P)T traversal. Ironically, this "helper" functionality creates further incompatibilities, making an already difficult problem harder to solve. While IPsec traversal "helper" functionality is not present in all NA(P)Ts, these features are becoming sufficiently popular that they also need to be taken into account in a NA(P)T traversal solution.

3) ヘルパーの問題。これらの互換性は、IPSEC NA（P）Tトラバーサルを提供しようとするNa（P）Tデバイスに存在します。皮肉なことに、この「ヘルパー」機能はさらに非互換性を生み出し、すでに困難な問題を解決するのが難しくなります。IPSECトラバーサル「ヘルパー」機能はすべてのNa（P）TSには存在しませんが、これらの機能は十分に人気になりつつあるため、Na（P）Tトラバーサル溶液でも考慮する必要があります。

2.1. Intrinsic NA(P)T Issues

2.1. 固有のna（p）tの問題

Incompatibilities that are intrinsic to NA(P)T include:

Na（p）tに固有の非互換性が含まれます。

a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check. Since IPsec ESP [RFC2406] does not incorporate the IP source and destination addresses in its keyed message integrity check, this issue does not arise for ESP.

a) IPSEC AH [RFC2402]とNATの間の非互換性。AHヘッダーには、キー付きメッセージの整合性チェックにIPソースと宛先アドレスが組み込まれているため、NATまたはReverse NATデバイスは、フィールドをアドレス指定するために変更を行うと、メッセージの整合性チェックが無効になります。IPSEC ESP [RFC2406]は、Keyed Message Integrity CheckにIPソースと宛先アドレスを組み込んでいないため、この問題はESPの場合は発生しません。

b) Incompatibility between checksums and NAT. TCP and UDP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked upon receipt, they will be invalidated by passage through a NAT or reverse NAT device.

b) チェックサムとナットの間の非互換性。TCPおよびUDPチェックサムは、計算に「擬似ヘッダー」を含めることにより、IPソースと宛先アドレスに依存します。その結果、チェックサムが計算され、受領時にチェックされる場合、NATまたは逆NATデバイスを通過することにより無効になります。

As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksums are not calculated (as is possible with IPv4 UDP). As described in [RFC793], TCP checksum calculation and verification is required in IPv4. UDP/TCP checksum calculation and verification is required in IPv6.

その結果、TCP/UDPプロトコルが関与しない場合（IPSECトンネルモードまたはIPSEC保護GREなど）、IPSECのセキュリティペイロード（ESP）がNATのみを通過します。）。[RFC793]で説明されているように、IPv4ではTCPチェックサムの計算と検証が必要です。UDP/TCPチェックサムの計算と検証がIPv6で必要です。

Stream Control Transmission Protocol (SCTP), as defined in [RFC2960] and [RFC3309], uses a CRC32C algorithm calculated only on the SCTP packet (common header + chunks), so that the IP header is not covered. As a result, NATs do not invalidate the SCTP CRC, and the problem does not arise.

[RFC2960]および[RFC3309]で定義されているストリーム制御伝送プロトコル（SCTP）は、IPヘッダーがカバーされないように、SCTPパケット（共通ヘッダーチャンク）でのみ計算されたCRC32Cアルゴリズムを使用します。その結果、NATはSCTP CRCを無効にしません。問題は発生しません。

Note that since transport mode IPsec traffic is integrity protected and authenticated using strong cryptography, modifications to the packet can be detected prior to checking UDP/TCP checksums. Thus, checksum verification only provides assurance against errors made in internal processing.

トランスポートモードIPSECトラフィックは強力な暗号化を使用して整合性保護および認証されているため、UDP/TCPチェックサムをチェックする前にパケットの変更を検出できることに注意してください。したがって、チェックサムの検証は、内部処理で行われたエラーに対する保証のみを提供します。

c) Incompatibility between IKE address identifiers and NAT. Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets.

c) IKEアドレス識別子とNATの間の非互換性。IPアドレスがインターネットキーエクスチェンジプロトコル（IKE）フェーズ1 [RFC2409]またはフェーズ2の識別子として使用されている場合、NATまたは逆NATによるIPソースまたは宛先アドレスの変更により、識別子と識別子とアドレスのアドレスの間の不一致が生じます。IPヘッダー。[RFC2409]で説明されているように、IKEの実装はそのようなパケットを破棄する必要があります。

In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 identifiers, userIDs and FQDNs can be used instead. Where user authentication is desired, an ID type of ID_USER_FQDN can be used, as described in [RFC2407]. Where machine authentication is desired, an ID type of ID_FQDN can be used. In either case, it is necessary to verify that the proposed identifier is authenticated as a result of processing an end-entity certificate, if certificates are exchanged in Phase 1. While use of USER_FQDN or FQDN identity types is possible within IKE, there are usage scenarios (e.g. Security Policy Database (SPD) entries describing subnets) that cannot be accommodated this way.

IKEフェーズ1およびフェーズ2の識別子としてのIPアドレスの使用を避けるために、代わりにユーザーIDSおよびFQDNを使用できます。ユーザー認証が必要な場合、[RFC2407]で説明されているように、ID_USER_FQDNのIDタイプを使用できます。マシン認証が必要な場合、ID_FQDNのIDタイプを使用できます。どちらの場合でも、フェーズ1で証明書が交換される場合、提案された識別子がエンドエンティティ証明書を処理した結果として認証されていることを確認する必要があります。IKE内でuser_fqdnまたはfqdnのアイデンティティタイプの使用が可能です。この方法では対応できないシナリオ（サブネットを説明するセキュリティポリシーデータベース（SPD）エントリ）。

Since the source address in the Phase 2 identifier is often used to form a full 5-tuple inbound SA selector, the destination address, protocol, source port and destination port can be used in the selector so as not to weaken inbound SA processing.

フェーズ2識別子のソースアドレスは、5タプルのインバウンドSAセレクターを完全に形成するためによく使用されるため、インバウンドSA処理を弱めないように、宛先アドレス、プロトコル、ソースポート、および宛先ポートを使用することができます。

d) Incompatibility between fixed IKE source ports and NAPT. Where multiple hosts behind the NAPT initiate IKE SAs to the same responder, a mechanism is needed to allow the NAPT to demultiplex the incoming IKE packets from the responder. This is typically accomplished by translating the IKE UDP source port on outbound packets from the initiator. Thus responders must be able to accept IKE traffic from a UDP source port other than 500, and must reply to that port. Care must be taken to avoid unpredictable behavior during re-keys. If the floated source port is not used as the destination port for the re-key, the NAT may not be able to send the re-key packets to the correct destination.

d) 固定されたIKEソースポートとNAPT間の非互換性。NAPTの背後にある複数のホストがIke SASを同じレスポンダーに開始する場合、NAPTがResponderからの入っているIKEパケットを非難するためにメカニズムが必要です。これは通常、IKE UDPソースポートをイニシエーターからのアウトバウンドパケットに翻訳することで実現されます。したがって、レスポンダーは500以外のUDPソースポートからのIKEトラフィックを受け入れることができなければならず、そのポートに返信する必要があります。再キーの間に予測不可能な行動を避けるために注意する必要があります。フロートソースポートが再キーの宛先ポートとして使用されていない場合、NATは再キーパケットを正しい宛先に送信できない場合があります。

e) Incompatibilities between overlapping SPD entries and NAT. Where initiating hosts behind a NAT use their source IP addresses in Phase 2 identifiers, they can negotiate overlapping SPD entries with the same responder IP address. The responder could then send packets down the wrong IPsec SA. This occurs because to the responder, the IPsec SAs appear to be equivalent, since they exist between the same endpoints and can be used to pass the same traffic.

e) 重複するSPDエントリとNATの間の非互換性。NATの背後にあるホストを開始する場合、フェーズ2識別子でソースIPアドレスを使用する場合、同じレスポンダーIPアドレスでオーバーラップSPDエントリを交渉できます。レスポンダーは、間違ったIPSEC SAを下にパケットを送信できます。これは、応答者にとって、同じエンドポイントの間に存在し、同じトラフィックを通過するために使用できるため、IPSEC SASが同等であるように見えるために発生します。

f) Incompatibilities between IPsec SPI selection and NAT. Since IPsec ESP traffic is encrypted and thus opaque to the NAT, the NAT must use elements of the IP and IPsec header to demultiplex incoming IPsec traffic. The combination of the destination IP address, security protocol (AH/ESP), and IPsec SPI is typically used for this purpose.

f) IPSEC SPI選択とNATの間の非互換性。IPSEC ESPトラフィックは暗号化されているため、NATに不透明であるため、NATはIPとIPSECヘッダーの要素を使用して、IPSECトラフィックをデマルチプレックスする必要があります。宛先IPアドレス、セキュリティプロトコル（AH/ESP）、およびIPSEC SPIの組み合わせは、通常、この目的に使用されます。

However, since the outgoing and incoming SPIs are chosen independently, there is no way for the NAT to determine what incoming SPI corresponds to what destination host merely by inspecting outgoing traffic. Thus, were two hosts behind the NAT to attempt to create IPsec SAs at the same destination simultaneously, it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination.

ただし、発信と着信のSPIは独立して選択されるため、NATが発信トラフィックを検査するだけでどの宛先ホストに対応するかをNATが決定する方法はありません。したがって、NATの背後にある2人のホストで、同じ宛先で同時にIPSEC SASを作成しようとしたため、NATが着信IPSECパケットを間違った宛先に配信する可能性があります。

Note that this is not an incompatibility with IPsec per se, but rather with the way it is typically implemented. With both AH and ESP, the receiving host specifies the SPI to use for a given SA, a choice which is significant only to the receiver. At present, the combination of Destination IP, SPI, and Security Protocol (AH, ESP) uniquely identifies a Security Association. Also, SPI values in the range 1-255 are reserved to IANA and may be used in the future. This means that, when negotiating with the same external host or gateway, the internal hosts behind the same NAPT can select the same SPI value, such that one host inbound SA is (SPI=470, Internal Dest IP=192.168.0.4) and a different host inbound SA is (SPI=470, Internal Dest IP=192.168.0.5). The receiving NAPT will not be able to determine which internal host an inbound IPsec packet with SPI=470 should be forwarded to.

これは、IPSec自体との非互換性ではなく、通常実装される方法との非互換性であることに注意してください。AHとESPの両方で、受信ホストは特定のSAに使用するSPIを指定します。これは、受信機のみに重要な選択です。現在、宛先IP、SPI、およびセキュリティプロトコル（AH、ESP）の組み合わせは、セキュリティ協会を一意に識別しています。また、範囲1〜255のSPI値はIANAに予約されており、将来使用される場合があります。これは、同じ外部ホストまたはゲートウェイと交渉する場合、同じNAPTの背後にある内部ホストが同じSPI値を選択できるため、1つのホストのインバウンドSAが（SPI = 470、内部DEST IP = 192.168.0.4）およびA異なるホストインバウンドSAは（SPI = 470、内部DEST IP = 192.168.0.5）です。受信NAPTは、SPI = 470を使用したインバウンドIPSECパケットを転送する内部ホストを決定することができません。

It is also possible for the receiving host to allocate a unique SPI to each unicast Security Association. In this case, the Destination IP Address need only be checked to see if it is "any valid unicast IP for this host", not checked to see if it is the specific Destination IP address used by the sending host. Using this technique, the NA(P)T can be assured of a low but non-zero chance of forwarding packets to the wrong internal host, even when two or more hosts establish SAs with the same external host.

また、受信ホストが各ユニキャストセキュリティ協会に一意のSPIを割り当てることも可能です。この場合、宛先IPアドレスは、「このホストの有効なユニキャストIP」であるかどうかを確認するためにチェックするだけで、送信ホストが使用する特定の宛先IPアドレスであるかどうかを確認する必要がありません。この手法を使用して、2人以上のホストが同じ外部ホストでSASを確立した場合でも、NA（P）Tは、間違った内部ホストにパケットを転送する低いがゼロではない可能性を保証できます。

This approach is completely backwards compatible, and only requires the particular receiving host to make a change to its SPI allocation and IPsec_esp_input() code. However, NA(P)T devices may not be able to detect this behavior without problems associated with parsing IKE payloads. And a host may still be required to use a SPI in the IANA reserved range for the assigned purpose.

このアプローチは完全に後方に互換性があり、SPI割り当てとIPSEC_ESP_INPUT（）コードを変更するために特定の受信ホストのみが必要です。ただし、NA（P）Tデバイスは、IKEペイロードの解析に関連する問題なくこの動作を検出できない場合があります。また、ホストは、割り当てられた目的のためにIANA予約範囲でSPIを使用する必要がある場合があります。

g) Incompatibilities between embedded IP addresses and NAT. Since the payload is integrity protected, any IP addresses enclosed within IPsec packets will not be translatable by a NAT. This renders ineffective Application Layer Gateways (ALGs) implemented within NATs. Protocols that utilize embedded IP addresses include FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (optionally), and many games. To address this issue, it is necessary to install ALGs on the host or security gateway that can operate on application traffic prior to IPsec encapsulation and after IPsec decapsulation.

g) 埋め込まれたIPアドレスとNATの間の互換性。ペイロードは整合性保護されているため、IPSECパケット内に囲まれたIPアドレスはすべてNATによって翻訳可能ではありません。これにより、NAT内に実装された効果のないアプリケーションレイヤーゲートウェイ（ALG）がレンダリングされます。埋め込まれたIPアドレスを利用するプロトコルには、FTP、IRC、SNMP、LDAP、H.323、SIP、SCTP（オプションで）、および多くのゲームが含まれます。この問題に対処するには、IPSECカプセル化前およびIPSECの脱カプセル化後にアプリケーショントラフィックを操作できるホストまたはセキュリティゲートウェイにALGをインストールする必要があります。

h) Implicit directionality of NA(P)T. NA(P)Ts often require an initial outbound packet to flow through them in order to create an inbound mapping state. Directionality prohibits unsolicited establishment of IPsec SAs to hosts behind the NA(P)T.

h) Na（p）tの暗黙の方向性。Na（P）TSは、多くの場合、インバウンドマッピング状態を作成するために、それらを通る最初のアウトバウンドパケットを必要とします。方向性は、NA（P）Tの背後にあるホストにIPSEC SASの未承諾の確立を禁止しています。

i) Inbound SA selector verification. Assuming IKE negotiates phase 2 selectors, inbound SA processing will drop the decapsulated packet, since [RFC2401] requires a packet's source address match the SA selector value, which NA(P)T processing of an ESP packet would change.

i) インバウンドSAセレクターの検証。IKEがフェーズ2セレクターを交渉すると仮定すると、[RFC2401]にはパケットのソースアドレスがSAセレクター値と一致するため、インバウンドSA処理は脱カプセル化パケットをドロップします。SAセレクター値は、ESPパケットのNA（P）T処理が変更されます。

2.2. NA(P)T Implementation Weaknesses

2.2. Na（p）T実装の弱点

Implementation problems present in many NA(P)Ts include:

多くのNa（P）TSに存在する実装の問題は次のとおりです。

j) Inability to handle non-UDP/TCP traffic. Some NA(P)Ts discard non-UDP/TCP traffic or perform address-only translation when only one host is behind the NAT. Such NAPTs are unable to enable SCTP, ESP (protocol 50), or AH (protocol 51) traffic.

j) 非udp/TCPトラフィックを処理できない。一部のNA（P）TSは、NATの背後にあるホストが1つだけである場合、非udp/TCPトラフィックを破棄するか、住所のみの翻訳を実行します。このようなNAPTSは、SCTP、ESP（プロトコル50）、またはAH（プロトコル51）トラフィックを有効にすることができません。

k) NAT mapping timeouts. NA(P)Ts vary in the time for which a UDP mapping will be maintained in the absence of traffic. Thus, even where IKE packets can be correctly translated, the translation state may be removed prematurely.

k) NATマッピングタイムアウト。NA（P）TSは、トラフィックがない場合にUDPマッピングが維持される時間によって異なります。したがって、IKEパケットを正しく翻訳できる場合でも、翻訳状態は時期尚早に削除される場合があります。

l) Inability to handle outgoing fragments. Most NA(P)Ts can properly fragment outgoing IP packets in the case where the IP packet size exceeds the MTU on the outgoing interface. However, proper translation of outgoing packets that are already fragmented is difficult and most NAPTs do not handle this correctly. As noted in Section 6.3 of [RFC3022], where two hosts originate fragmented packets to the same destination, the fragment identifiers can overlap. Since the destination host relies on the fragmentation identifier and fragment offset for reassembly, the result will be data corruption. Few NA(P)Ts protect against identifier collisions by supporting identifier translation. Identifier collisions are not an issue when NATs perform the fragmentation, since the fragment identifier need only be unique within a source/destination IP address pair.

l) 発信断片を処理できない。ほとんどのNA（P）TSは、IPパケットサイズが発信インターフェイスのMTUを超える場合に、発信IPパケットを適切に断片化できます。ただし、すでに断片化されている発信パケットの適切な翻訳は困難であり、ほとんどのNAPTはこれを正しく処理しません。[RFC3022]のセクション6.3で述べたように、2つのホストが断片化されたパケットを同じ宛先に発信するように、フラグメント識別子が重複する可能性があります。宛先ホストは、再組み立てのためにフラグメンテーション識別子とフラグメントオフセットに依存しているため、結果はデータ腐敗になります。識別子翻訳をサポートすることにより、識別子衝突から保護するNa（P）TSはほとんどありません。識別子の衝突は、NATがフラグメンテーションを実行する場合の問題ではありません。フラグメント識別子は、ソース/宛先IPアドレスペア内でのみ一意である必要があるためです。

Since a fragment can be as small as 68 octets [RFC791], there is no guarantee that the first fragment will contain a complete TCP header. Thus, a NA(P)T looking to recalculate the TCP checksum may need to modify a subsequent fragment. Since fragments can be reordered, and IP addresses can be embedded and possibly even split between fragments, the NA(P)T will need to perform reassembly prior to completing the translation. Few NA(P)Ts support this.

フラグメントは68オクテット[RFC791]と同じくらい小さいため、最初のフラグメントに完全なTCPヘッダーが含まれるという保証はありません。したがって、TCPチェックサムの再計算を検討しているNa（p）tは、後続のフラグメントを変更する必要がある場合があります。フラグメントを並べ替えることができ、IPアドレスを埋め込み、場合によってはフラグメント間で分割できるため、翻訳を完了する前にNA（P）Tは再組み立てを実行する必要があります。これをサポートするNa（P）TSはほとんどありません。

m) Inability to handle incoming fragments. Since only the first fragment will typically contain a complete IP/UDP/SCTP/TCP header, NAPTs need to be able to perform the translation based on the source/dest IP address and fragment identifier alone. Since fragments can be reordered, the headers to a given fragment identifier may not be known if a subsequent fragment arrives prior to the initial one, and the headers may be split between fragments. As a result, the NAPT may need to perform reassembly prior to completing the translation. Few NAPTs support this. Note that with NAT, the source/dest IP address is enough to determine the translation so that this does not arise. However, it is possible for the IPsec or IKE headers to be split between fragments, so that reassembly may still be required.

m) 入ってくる断片を処理できない。最初のフラグメントのみが通常、完全なIP/UDP/SCTP/TCPヘッダーを含むため、NAPTSはソース/DEST IPアドレスとフラグメント識別子のみに基づいて翻訳を実行できる必要があります。フラグメントを並べ替えることができるため、特定のフラグメント識別子へのヘッダーは、最初のフラグメントの前に後続のフラグメントが到着し、ヘッダーがフラグメント間で分割される場合がわからない場合があります。その結果、NAPTは翻訳を完了する前に再組み立てを実行する必要がある場合があります。これをサポートするナップはほとんどありません。NATを使用すると、ソース/DEST IPアドレスは翻訳を決定するのに十分であり、これが発生しないことに注意してください。ただし、IPSECまたはIKEヘッダーがフラグメント間で分割される可能性があるため、再組み立てが必要になる場合があります。

2.3. Helper Incompatibilities

2.3. ヘルパーの非互換性

Incompatibilities between IPsec and NAT "helper" functionality include:

IPSECとNATの「ヘルパー」機能の互換性は次のとおりです。

n) Internet Security Association and Key Management Protocol (ISAKMP) header inspection. Today some NAT implementations attempt to use IKE cookies to de-multiplex incoming IKE traffic. As with source-port de-multiplexing, IKE cookie de-multiplexing results in problems with re-keying, since Phase 1 re-keys typically will not use the same cookies as the earlier traffic.

n) インターネットセキュリティ協会と主要な管理プロトコル（ISAKMP）ヘッダー検査。今日、いくつかのNAT実装は、IKE Cookieを使用してIKEトラフィックを脱マルグに使用しようとしています。Source-Port De Multiplexingと同様に、Ike Cookie DeMultiplexingは、フェーズ1の再キーは通常、以前のトラフィックと同じCookieを使用しないため、再キーイングの問題になります。

o) Special treatment of port 500. Since some IKE implementations are unable to handle non-500 UDP source ports, some NATs do not translate packets with a UDP source port of 500. This means that these NATs are limited to one IPsec client per destination gateway, unless they inspect details of the ISAKMP header to examine cookies which creates the problem noted above.

o) ポート500の特別な処理。一部のIKE実装では500 UDP以外のソースポートを処理できないため、一部のNATは500のUDPソースポートでパケットを翻訳しません。ISAKMPヘッダーの詳細を検査して、上記の問題を作成するCookieを調べない限り。

p) ISAKMP payload inspection. NA(P)T implementations that attempt to parse ISAKMP payloads may not handle all payload ordering combinations, or support vendor_id payloads for IKE option negotiation.

p) ISAKMPペイロード検査。ISAKMPペイロードを解析しようとするNA（P）Tの実装は、すべてのペイロード順序付けの組み合わせを処理したり、IKEオプション交渉のベンダー_IDペイロードをサポートしたりすることはできません。

3. Requirements for IPsec-NAT Compatibility

3. IPSEC-NAT互換性の要件

The goal of an IPsec-NAT compatibility solution is to expand the range of usable IPsec functionality beyond that available in the NAT-compatible IPsec tunnel mode solution described in Section 2.3.

IPSEC-NAT互換性ソリューションの目標は、セクション2.3で説明するNAT互換IPSECトンネルモードソリューションで利用可能なものを超えて、使用可能なIPSEC機能の範囲を拡張することです。

In evaluating a solution to IPsec-NAT incompatibility, the following criteria should be kept in mind:

IPSEC-NATの非互換性の解決策を評価する際、次の基準に留意する必要があります。

Deployment

展開

Since IPv6 will address the address scarcity issues that frequently lead to use of NA(P)Ts with IPv4, the IPsec-NAT compatibility issue is a transitional problem that needs to be solved in the time frame prior to widespread deployment of IPv6. Therefore, to be useful, an IPsec-NAT compatibility solution MUST be deployable on a shorter time scale than IPv6.

IPv6は、IPv4を使用してNa（P）TSの使用に頻繁につながる住所の希少性の問題に対処するため、IPSEC-NAT互換性の問題は、IPv6の展開前に時間枠で解決する必要がある移行問題です。したがって、有用であるために、IPSEC-NAT互換性ソリューションは、IPv6よりも短い時間スケールで展開できる必要があります。

Since IPv6 deployment requires changes to routers as well as hosts, a potential IPsec-NAT compatibility solution, which requires changes to both routers and hosts, will be deployable on approximately the same time scale as IPv6. Thus, an IPsec-NAT compatibility solution SHOULD require changes only to hosts, and not to routers.

IPv6の展開にはルーターとホストの変更が必要なため、ルーターとホストの両方の変更を必要とする潜在的なIPSEC-NAT互換性ソリューションは、IPv6とほぼ同じ時間スケールで展開できます。したがって、IPSEC-NAT互換性ソリューションは、ルーターではなく、ホストのみに変更を必要とする必要があります。

Among other things, this implies that communication between the host and the NA(P)T SHOULD NOT be required by an IPsec-NAT compatibility solution, since that would require changes to the NA(P)Ts, and interoperability testing between the host and NA(P)T implementations. In order to enable deployment in the short term, it is necessary for the solution to work with existing router and NA(P)T products within the deployed infrastructure.

とりわけ、これは、ホストとNa（P）T間の通信がIPSEC-NAT互換性ソリューションでは必要ないことを意味します。これには、NA（P）TSの変更が必要であり、ホストとホストとの間の相互運用性テストが必要であることを意味します。Na（P）T実装。短期的に展開を有効にするためには、ソリューションが展開されたインフラストラクチャ内の既存のルーターおよびNA（P）T製品と連携する必要があります。

Protocol Compatibility

プロトコル互換性

An IPsec NAT traversal solution is not expected to resolve issues with protocols that cannot traverse NA(P)T when unsecured with IPsec. Therefore, ALGs may still be needed for some protocols, even when an IPsec NAT traversal solution is available.

IPSEC NATトラバーサルソリューションは、IPSECを使用していない場合、Na（p）tを通過できないプロトコルの問題を解決することは期待されていません。したがって、IPSEC NATトラバーサルソリューションが利用可能な場合でも、一部のプロトコルにはALGSが必要になる場合があります。

Security

安全

Since NA(P)T directionality serves a security function, IPsec NA(P)T traversal solutions should not allow arbitrary incoming IPsec or IKE traffic from any IP address to be received by a host behind the NA(P)T, although mapping state should be maintained once bidirectional IKE and IPsec communication is established.

Na（P）Tの方向性はセキュリティ機能に役立つため、IPSEC NA（P）Tトラバースソリューションは、IPアドレスからの任意の着信IPSECまたはIKEトラフィックを、NA（P）Tの背後にあるホストが受信できるようにしてはなりません。双方向IKEとIPSEC通信が確立されたら、維持する必要があります。

Telecommuter Scenario

テレコミーターシナリオ

Since one of the primary uses of IPsec is remote access to corporate Intranets, a NA(P)T traversal solution MUST support NA(P)T traversal, via either IPsec tunnel mode or L2TP over IPsec transport mode [RFC3193]. This includes support for traversal of more than one NA(P)T between the remote client and the VPN gateway.

IPSECの主要な用途の1つは企業イントラネットへのリモートアクセスであるため、Na（P）Tトラバーサルソリューションは、IPSECトンネルモードまたはIPSEC輸送モードを介したL2TPを介してNa（P）Tトラバーサルをサポートする必要があります[RFC3193]。これには、リモートクライアントとVPNゲートウェイの間の複数のNa（P）Tのトラバーサルのサポートが含まれます。

The client may have a routable address and the VPN gateway may be behind at least one NA(P)T, or alternatively, both the client and the VPN gateway may be behind one or more NA(P)Ts. Telecommuters may use the same private IP address, each behind their own NA(P)T, or many telecommuters may reside on a private network behind the same NA(P)T, each with their own unique private address, connecting to the same VPN gateway. Since IKE uses UDP port 500 as the destination, it is not necessary to enable multiple VPN gateways operating behind the same external IP address.

クライアントにはルーティング可能なアドレスがあり、VPNゲートウェイは少なくとも1つのNa（P）Tの背後にある場合があります。または、クライアントとVPNゲートウェイの両方が1つ以上のNa（P）TSの背後にある場合があります。テレコミーターは同じプライベートIPアドレスを使用する場合があり、それぞれが独自のNA（P）Tの背後にあるか、多くの電気在庫が同じNA（P）Tの背後にあるプライベートネットワークに居住し、それぞれが独自のプライベートアドレスを備えており、同じVPNに接続することができます。ゲートウェイ。IKEは宛先としてUDPポート500を使用するため、同じ外部IPアドレスの背後で動作する複数のVPNゲートウェイを有効にする必要はありません。

Gateway-to-Gateway Scenario

ゲートウェイからゲートウェイへのシナリオ

In a gateway-gateway scenario, a privately addressed network (DMZ) may be inserted between the corporate network and the Internet. In this design, IPsec security gateways connecting portions of the corporate network may be resident in the DMZ and have private addresses on their external (DMZ) interfaces. A NA(P)T connects the DMZ network to the Internet.

ゲートウェイゲートウェイのシナリオでは、企業ネットワークとインターネットの間に個人的にアドレス指定されたネットワーク（DMZ）が挿入される場合があります。この設計では、コーポレートネットワークの一部を接続するIPSECセキュリティゲートウェイは、DMZに居住し、外部（DMZ）インターフェイスにプライベートアドレスを持っている場合があります。A NA（P）Tは、DMZネットワークをインターネットに接続します。

End-to-End Scenario

エンドツーエンドのシナリオ

A NAT-IPsec solution MUST enable secure host-host TCP/IP communication via IPsec, as well as host-gateway communications. A host on a private network MUST be able to bring up one or multiple IPsec-protected TCP connections or UDP sessions to another host with one or more NA(P)Ts between them. For example, NA(P)Ts may be deployed within branch offices connecting to the corporate network, with an additional NA(P)T connecting the corporate network to the Internet. Likewise, NA(P)Ts may be deployed within a corporate network LAN or WAN to connect wireless or remote location clients to the corporate network. This may require special processing of TCP and UDP traffic on the host.

NAT-IPSECソリューションでは、IPSECを介した安全なホストホストTCP/IP通信、およびホストゲートウェイ通信を可能にする必要があります。プライベートネットワーク上のホストは、1つまたは複数のIPSECで保護されたTCP接続またはUDPセッションを、1つ以上のNA（P）TSを持つ別のホストに持ち上げることができなければなりません。たとえば、NA（P）TSは、コーポレートネットワークに接続するブランチオフィス内に展開され、企業ネットワークをインターネットに接続する追加のNA（P）Tがあります。同様に、NA（P）TSは、企業ネットワークLANまたはWAN内に展開され、ワイヤレスまたはリモートロケーションのクライアントをコーポレートネットワークに接続できます。これには、ホストのTCPおよびUDPトラフィックの特別な処理が必要になる場合があります。

Bringing up SCTP connections to another host with one or more NA(P)Ts between them may present special challenges. SCTP supports multi-homing. If more than one IP address is used, these addresses are transported as part of the SCTP packet during the association setup (in the INIT and INIT-ACK chunks). If only single homed SCTP end-points are used, [RFC2960] section 3.3.2.1 states:

1つ以上のNa（P）TSを使用して別のホストにSCTP接続を持ち上げると、特別な課題が発生する可能性があります。SCTPはマルチホミングをサポートしています。複数のIPアドレスが使用される場合、これらのアドレスは、Associationセットアップ中（initおよびinit-ackチャンク）中にSCTPパケットの一部として輸送されます。単一の家庭用SCTPエンドポイントのみが使用されている場合、[RFC2960]セクション3.3.2.1の状態：

Note that not using any IP address parameters in the INIT and INIT-ACK is an alternative to make an association more likely to work across a NAT box.

initとinit-ackでIPアドレスパラメーターを使用しないことは、AssociationがNATボックスで動作する可能性が高くなるための代替手段であることに注意してください。

This implies that IP addresses should not be put into the SCTP packet unless necessary. If NATs are present and IP addresses are included, then association setup will fail. Recently [AddIP] has been proposed which allows the modification of the IP address once an association is established. The modification messages have also IP addresses in the SCTP packet, and so will be adversely affected by NATs.

これは、必要でない限り、IPアドレスをSCTPパケットに入れないでください。NATが存在し、IPアドレスが含まれている場合、アソシエーションのセットアップは失敗します。最近[ADDIP]が提案されており、関連付けが確立されるとIPアドレスの変更が可能になります。変更メッセージには、SCTPパケットにもIPアドレスがあるため、NATの影響を受けます。

Firewall Compatibility

ファイアウォールの互換性

Since firewalls are widely deployed, a NAT-IPsec compatibility solution MUST enable a firewall administrator to create simple, static access rule(s) to permit or deny IKE and IPsec NA(P)T traversal traffic. This implies, for example, that dynamic allocation of IKE or IPsec destination ports is to be avoided.

ファイアウォールは広く展開されているため、NAT-PIPSEC互換性のソリューションにより、ファイアウォール管理者がIKEおよびIPSEC NA（P）Tトラバーストラフィックを許可または拒否するためのシンプルで静的アクセスルールを作成できるようにする必要があります。これは、たとえば、IKEまたはIPSEC宛先ポートの動的割り当てが避けることを意味します。

Scaling

スケーリング

An IPsec-NAT compatibility solution should be capable of being deployed within an installation consisting of thousands of telecommuters. In this situation, it is not possible to assume that only a single host is communicating with a given destination at a time. Thus, an IPsec-NAT compatibility solution MUST address the issue of overlapping SPD entries and de-multiplexing of incoming packets.

IPSEC-NAT互換性のソリューションは、数千人の電気在庫で構成されるインストール内に展開できる必要があります。この状況では、一度に特定の目的地と通信しているのは、1人のホストだけが想定することはできません。したがって、IPSEC-NAT互換性のソリューションは、SPDエントリの重複と着信パケットの崩壊の問題に対処する必要があります。

Mode Support

モードサポート

At a minimum, an IPsec-NAT compatibility solution MUST support traversal of the IKE and IPsec modes required for support within [RFC2409] and [RFC2401]. For example, an IPsec gateway MUST support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec transport mode NA(P)T traversal. The purpose of AH is to protect immutable fields within the IP header (including addresses), and NA(P)T translates addresses, invalidating the AH integrity check. As a result, NA(P)T and AH are fundamentally incompatible and there is no requirement that an IPsec-NAT compatibility solution support AH transport or tunnel mode.

少なくとも、IPSEC-NAT互換性ソリューションは、[RFC2409]および[RFC2401]内でのサポートに必要なIKEおよびIPSECモードのトラバーサルをサポートする必要があります。たとえば、IPSECゲートウェイはESPトンネルモードNA（P）Tトラバーサルをサポートする必要があり、IPSECホストはIPSECトランスポートモードNA（P）Tトラバーサルをサポートする必要があります。AHの目的は、IPヘッダー内の不変のフィールド（アドレスを含む）を保護することであり、Na（p）tはアドレスを翻訳し、AHの整合性チェックを無効にします。その結果、Na（P）TとAHは根本的に互換性があり、IPSEC-NAT互換性ソリューションがAH輸送またはトンネルモードをサポートすることを要求していません。

Backward Compatibility and Interoperability

後方互換性と相互運用性

An IPsec-NAT compatibility solution MUST be interoperable with existing IKE/IPsec implementations, so that they can communicate where no NA(P)T is present. This implies that an IPsec-NAT compatibility solution MUST be backwards-compatible with IPsec as defined in [RFC2401] and IKE as defined in [RFC2409]. In addition, it SHOULD be able to detect the presence of a NA(P)T, so that NA(P)T traversal support is only used when necessary. This implies that it MUST be possible to determine that an existing IKE implementation does not support NA(P)T traversal, so that a standard IKE conversation can occur, as described in [RFC2407], [RFC2408], and [RFC2409]. Note that while this implies initiation of IKE to port 500, there is no requirement for a specific source port, so that UDP source port 500 may or may not be used.

IPSEC-NAT互換性ソリューションは、既存のIKE/IPSEC実装と相互運用可能でなければならないため、NA（P）Tが存在しない場合に通信できるようにします。これは、[RFC2401]で定義されているIPSECと[RFC2409]で定義されているIPSECと、IPSEC-NAT互換ソリューションが後方互換でなければならないことを意味します。さらに、Na（P）Tの存在を検出できるようにするため、Na（P）Tトラバーサルサポートが必要な場合にのみ使用されるようにする必要があります。これは、[RFC2407]、[RFC2408]、および[RFC2409]で説明されているように、既存のIKE実装がNa（P）Tトラバーサルをサポートしないことを判断することが可能であることを意味します。これは、IKEのポート500への開始を意味しますが、特定のソースポートには要件がないため、UDPソースポート500が使用される場合と使用されない場合があることに注意してください。

Security

安全

An IPsec-NAT compatibility solution MUST NOT introduce additional IKE or IPsec security vulnerabilities. For example, an acceptable solution must demonstrate that it introduces no new denial of service or spoofing vulnerabilities. IKE MUST be allowed to re-key in a bi-directional manner as described in [RFC2408].

IPSEC-NAT互換性ソリューションは、追加のIKEまたはIPSECセキュリティの脆弱性を導入してはなりません。たとえば、許容可能なソリューションは、サービスの新しい拒否やスプーフィングの脆弱性を導入しないことを実証する必要があります。IKEは、[RFC2408]に記載されているように、双方向の方法で再キーをすることを許可されなければなりません。

4. Existing Solutions

4. 既存のソリューション

4.1. IPsec Tunnel Mode

4.1. IPSECトンネルモード

In a limited set of circumstances, it is possible for an IPsec tunnel mode implementation, such as that described in [DHCP], to traverse NA(P)T successfully. However, the requirements for successful traversal are sufficiently limited so that a more general solution is needed:

限られた一連の状況では、[DHCP]で説明されているようなIPSECトンネルモードの実装がNa（P）Tを正常に通過する可能性があります。ただし、トラバーサルを成功させるための要件は十分に制限されているため、より一般的なソリューションが必要です。

1) IPsec ESP. IPsec ESP tunnels do not cover the outer IP header within the message integrity check, and so will not suffer Authentication Data invalidation due to address translation. IPsec tunnels also need not be concerned about checksum invalidation.

1) Ipsec esp。IPSEC ESPトンネルは、メッセージの整合性チェック内で外側のIPヘッダーをカバーしていないため、住所の翻訳により認証データの無効化に苦しむことはありません。Ipsecトンネルは、チェックサムの無効化についても心配する必要はありません。

2) No address validation. Most current IPsec tunnel mode implementations do not perform source address validation so that incompatibilities between IKE identifiers and source addresses will not be detected. This introduces security vulnerabilities as described in Section 5.

2) アドレスの検証なし。現在のIPSecトンネルモードの実装のほとんどは、IKE識別子とソースアドレス間の非互換性が検出されないように、ソースアドレスの検証を実行しません。これにより、セクション5で説明されているセキュリティの脆弱性が導入されます。

3) "Any to Any" SPD entries. IPsec tunnel mode clients can negotiate "any to any" SPDs, which are not invalidated by address translation. This effectively precludes use of SPDs for the filtering of allowed tunnel traffic.

3) 「任意の任意の」SPDエントリ。IPSECトンネルモードのクライアントは、「任意の」SPDをネゴシエートできます。これにより、許可されたトンネルトラフィックのフィルタリングのためのSPDの使用は事実上除外されます。

4) Single client operation. With only a single client behind a NAT, there is no risk of overlapping SPDs. Since the NAT will not need to arbitrate between competing clients, there is also no risk of re-key mis-translation, or improper incoming SPI or cookie de-multiplexing.

4) 単一のクライアント操作。NATの後ろに1人のクライアントのみがいる場合、SPDが重複するリスクはありません。NATは、競合するクライアント間で仲裁する必要がないため、誤った翻訳を再翻訳するリスクも、SPIまたはCookieの不適切な溶解のリスクもありません。

5) No fragmentation. When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even when exchanging a single certificate if the key size, or the size of other certificate fields (such as the distinguished name and other extensions), is large enough. However, when pre-shared keys are used for authentication, fragmentation is less likely.

5) 断片化はありません。証明書認証が使用されると、IKEの断片化に遭遇する可能性があります。これは、証明書チェーンが使用されている場合、またはキーサイズ、または他の証明書フィールドのサイズ（識別名やその他の拡張機能など）のサイズが十分に大きい場合でも、単一の証明書を交換する場合でも発生する可能性があります。ただし、認証に事前に共有キーが使用される場合、断片化の可能性は低くなります。

6) Active sessions. Most VPN sessions typically maintain ongoing traffic flow during their lifetime so that UDP port mappings are less likely be removed due to inactivity.

6) アクティブセッション。ほとんどのVPNセッションは通常、寿命の間に継続的な交通流を維持するため、UDPポートマッピングが不活動のために除去される可能性が低くなります。

4.2. RSIP

4.2. rsip

RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for IPsec traversal, as described in [RSIPsec]. By enabling host-NA(P)T communication, RSIP addresses issues of IPsec SPI de-multiplexing, as well as SPD overlap. It is thus suitable for use in enterprises, as well as home networking scenarios. By enabling hosts behind a NAT to share the external IP address of the NA(P)T (the RSIP gateway), this approach is compatible with protocols including embedded IP addresses.

[rsip]および[rsipframe]に記載されているrsipには、[rsipsec]で説明されているように、ipsecトラバーサルのメカニズムが含まれています。host-na（p）tコミュニケーションを有効にすることにより、RSIPはIPSEC SPI脱マルチプレックスの問題とSPDオーバーラップに対処します。したがって、企業での使用やホームネットワーキングシナリオでの使用に適しています。NATの背後にあるホストがNA（P）T（RSIPゲートウェイ）の外部IPアドレスを共有できるようにすることにより、このアプローチは埋め込まれたIPアドレスを含むプロトコルと互換性があります。

By tunneling IKE and IPsec packets, RSIP avoids changes to the IKE and IPsec protocols, although major changes are required to host IKE and IPsec implementations to retrofit them for RSIP-compatibility. It is thus compatible with all existing protocols (AH/ESP) and modes (transport and tunnel).

IKEとIPSECパケットのトンネルにより、RSIPはIKEおよびIPSECプロトコルの変更を回避しますが、IKEとIPSECの実装をホストするにはRSIP適合性を改装するために大きな変更が必要です。したがって、既存のすべてのプロトコル（AH/ESP）およびモード（輸送およびトンネル）と互換性があります。

In order to handle de-multiplexing of IKE re-keys, RSIP requires floating of the IKE source port, as well as re-keying to the floated port. As a result, interoperability with existing IPsec implementations is not assured.

IKE Recyysの脱調和を処理するために、RSIPはIKEソースポートのフローティングとフローティングポートへの再キーを必要とします。その結果、既存のIPSEC実装との相互運用性は保証されません。

RSIP does not satisfy the deployment requirements for an IPsec-NAT compatibility solution because an RSIP-enabled host requires a corresponding RSIP-enabled gateway in order to establish an IPsec SA with another host. Since RSIP requires changes only to clients and routers and not to servers, it is less difficult to deploy than IPv6. However, for vendors, implementation of RSIP requires a substantial fraction of the resources required for IPv6 support. Thus, RSIP solves a "transitional" problem on a long-term time scale, which is not useful.

RSIPは、RSIP対応のホストには、別のホストとIPSEC SAを確立するために対応するRSIP対応ゲートウェイを必要とするため、IPSEC-NAT互換性ソリューションの展開要件を満たしていません。RSIPは、クライアントとルーターのみに変更を必要とし、サーバーには変更しないため、IPv6よりも展開することはそれほど難しくありません。ただし、ベンダーの場合、RSIPの実装には、IPv6サポートに必要なリソースのかなりの部分が必要です。したがって、RSIPは長期的な時間尺度で「移行」問題を解決しますが、これは役に立ちません。

4.3. 6to4

6to4, as described in [RFC3056] can form the basis for an IPsec-NAT traversal solution. In this approach, the NAT provides IPv6 hosts with an IPv6 prefix derived from the NAT external IPv4 address, and encapsulates IPv6 packets in IPv4 for transmission to other 6to4 hosts or 6to4 relays. This enables an IPv6 host using IPsec to communicate freely to other hosts within the IPv6 or 6to4 clouds.

[RFC3056]で説明されているように、6TO4は、IPSEC-NATトラバーサル溶液の基礎を形成できます。このアプローチでは、NATはIPv6ホストにNAT外部IPv4アドレスから派生したIPv6プレフィックスを提供し、他の6to4ホストまたは6to4リレーに送信するためにIPv4のIPv6パケットをカプセル化します。これにより、IPSECを使用してIPv6ホストがIPv6または6to4クラウド内の他のホストと自由に通信できるようになります。

While 6to4 is an elegant and robust solution where a single NA(P)T separates a client and VPN gateway, it is not universally applicable. Since 6to4 requires the assignment of a routable IPv4 address to the NA(P)T in order to allow formation of an IPv6 prefix, it is not usable where multiple NA(P)Ts exist between the client and VPN gateway. For example, an NA(P)T with a private address on its external interface cannot be used by clients behind it to obtain an IPv6 prefix via 6to4.

6to4は、単一のNa（p）tがクライアントとVPNゲートウェイを分離するエレガントで堅牢なソリューションですが、普遍的に適用可能ではありません。6to4は、IPv6プレフィックスの形成を許可するために、routable IPv4アドレスをNa（p）tに割り当てる必要があるため、クライアントとVPNゲートウェイの間に複数のNa（P）TSが存在する場合は使用できません。たとえば、外部インターフェイスにプライベートアドレスを備えたNA（P）Tは、その背後にあるクライアントが6TO4を介してIPv6プレフィックスを取得するために使用することはできません。

While 6to4 requires little additional support from hosts that already support IPv6, it does require changes to NATs, which need to be upgraded to support 6to4. As a result, 6to4 may not be suitable for deployment in the short term.

6to4には、すでにIPv6をサポートするホストからの追加のサポートはほとんど必要ありませんが、6TO4をサポートするためにアップグレードする必要があるNATの変更が必要です。その結果、6to4は短期的には展開に適していない場合があります。

5. Security Considerations

5. セキュリティに関する考慮事項

By definition, IPsec-NAT compatibility requires that hosts and routers implementing IPsec be capable of securely processing packets whose IP headers are not cryptographically protected. A number of issues arise from this that are worth discussing.

定義上、IPSEC-NAT互換性では、IPSECを実装するホストとルーターを、IPヘッダーが暗号化されていないパケットを安全に処理できることが必要です。これから議論する価値がある多くの問題が発生します。

Since IPsec AH cannot pass through a NAT, one of the side effects of providing an IPsec-NAT compatibility solution may be for IPsec ESP with null encryption to be used in place of AH where a NAT exists between the source and destination. However, it should be noted that ESP with null encryption does not provide the same security properties as AH. For example, there are security risks relating to IPv6 source routing that are precluded by AH, but not by ESP with null encryption.

IPSEC AHはNATを通過できないため、IPSEC-NAT互換性ソリューションを提供する副作用の1つは、ソースと宛先の間にNATが存在するAHの代わりに使用されるIPSEC ESPの場合です。ただし、null暗号化を備えたESPは、AHと同じセキュリティプロパティを提供しないことに注意する必要があります。たとえば、IPv6ソースルーティングに関連するセキュリティリスクがあり、AHによって排除されますが、null暗号化の場合はESPではありません。

In addition, since ESP with any transform does not protect against source address spoofing, some sort of source IP address sanity checking needs to be performed. The importance of the anti-spoofing check is not widely understood. There is normally an anti-spoofing check on the Source IP Address as part of IPsec_{esp,ah}_input(). This ensures that the packet originates from the same address as that claimed within the original IKE Phase 1 and Phase 2 security associations. When a receiving host is behind a NAT, this check might not strictly be meaningful for unicast sessions, whereas in the Global Internet this check is important for tunnel-mode unicast sessions to prevent a spoofing attack described in [AuthSource], which can occur when access controls on the receiver depend upon the source IP address of verified ESP packets after decapsulation. IPsec-NAT compatibility schemes should provide anti-spoofing protection if it uses source addresses for access controls.

さらに、任意の変換でESPがソースアドレスのスプーフィングから保護しないため、ソースIPアドレスの正気チェックを実行する必要があります。スプーフィング防止チェックの重要性は広く理解されていません。通常、IPSEC_ {esp、ah} _input（）の一部として、ソースIPアドレスにスプーフィング防止チェックがあります。これにより、パケットは、元のIKEフェーズ1およびフェーズ2セキュリティ協会内で主張されたアドレスと同じアドレスから発生することが保証されます。受信ホストがNATの背後にある場合、このチェックはユニキャストセッションにとって厳密に意味がない場合がありますが、グローバルなインターネットでは、[AuthSource]に記載されているスプーフィング攻撃を防ぐためにトンネルモードユニキャストセッションではこのチェックは重要です。受信機のアクセスコントロールは、脱カプセル化後の検証されたESPパケットのソースIPアドレスによって異なります。IPSEC-NAT互換性スキームは、アクセスコントロールにソースアドレスを使用する場合、アンチスプーフィング保護を提供する必要があります。

Let us consider two hosts, A and C, both behind (different) NATs, who negotiate IPsec tunnel mode SAs to router B. Hosts A and C may have different privileges; for example, host A might belong to an employee trusted to access much of the corporate Intranet, while C might be a contractor only authorized to access a specific web site.

IPSECトンネルモードSASをルーターBに交渉する（異なる）NATの2つのホスト、AとCの両方を考えてみましょう。ホストは異なる特権を持っている可能性があります。たとえば、ホストAは、企業のイントラネットの多くにアクセスすると信頼されている従業員に属し、Cは特定のWebサイトへのアクセスのみを許可された請負業者である可能性があります。

If host C sends a tunnel mode packet spoofing A's IP address as the source, it is important that this packet not be accorded the privileges corresponding to A. If authentication and integrity checking is performed, but no anti-spoofing check (verifying that the originating IP address corresponds to the SPI) then host C may be allowed to reach parts of the network that are off limits. As a result, an IPsec-NAT compatibility scheme MUST provide some degree of anti-spoofing protection.

ホストCがAのIPアドレスをソースとしてスプーフィングするトンネルモードパケットを送信する場合、このパケットにAに対応する特権を与えられないことが重要です。IPアドレスはSPI）に対応します。ホストCは、制限外のネットワークの一部に到達することができます。その結果、IPSEC-NAT互換性スキームは、ある程度のスプーフィング防止保護を提供する必要があります。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[RFC2401] Atkinson、R。およびS. Kent、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。

[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[RFC2402]ケント、S。およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。

[RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[RFC2406]ケント、s。およびR.アトキンソン、「セキュリティペイロード（ESP）をカプセル化するIP」、RFC 2406、1998年11月。

[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。

[RFC2663] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.

[RFC2663] Srisuresh、P。およびM. Holdredge、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。

[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

[RFC3022] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。

6.2. Informative References

6.2. 参考引用

[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.

[RFC2408] Maughan、D.、Schertler、M.、Schneider、M.およびJ. Turner、「インターネットセキュリティ協会および主要管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, M. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.

[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、M.、V。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.

[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。

[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.

[RFC3193] Patel、B.、Aboba、B.、Dixon、W.、Zorn、G。、およびS. Booth、「IPSECを使用したL2TPの保護」、RFC 3193、2001年11月。

[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.

[RFC3309] Stone、J.、Stewart、R。and D. Otis、「Stream Control Transmission Protocol（SCTP）チェックサムの変更」、RFC 3309、2002年9月。

[RSIPFrame] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.

[Rsipframe] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm固有のIP：フレームワーク」、RFC 3102、2001年10月。

[RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.

[RSIP] Borella、M.、Grabelsky、D.、Lo、J。、およびK. Taniguchi、「Realm固有のIP：プロトコル仕様」、RFC 3103、2001年10月。

[RSIPsec] Montenegro, G. and M. Borella, "RSIP Support for End-to-End IPsec", RFC 3104, October 2001.

[RSIPSEC]モンテネグロ、G。およびM.ボレラ、「エンドツーエンドIPSECのRSIPサポート」、RFC 3104、2001年10月。

[DHCP] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.

[DHCP] Patel、B.、Aboba、B.、Kelly、S。、およびV. Gupta、「Ipsecトンネルモードのダイナミックホスト構成プロトコル（DHCPV4）構成」、RFC 3456、2003年1月。

[AuthSource] Kent, S., "Authenticated Source Addresses", IPsec WG Archive (ftp://ftp.ans.net/pub/archive/IPsec), Message-Id: <v02130517ad121773c8ed@[128.89.0.110]>, January 5, 1996.

[AuthSource] Kent、S。、「認証されたソースアドレス」、IPSEC WG Archive（ftp://ftp.ans.net/pub/archive/ipsec）、message-id：<V02130517AD173C8ED@[128.89.0.110]>、1月5、1996。

[AddIP] Stewart, R., et al., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Work in Progress.

[Addip] Stewart、R.、et al。、「Stream Control Transmission Protocol（SCTP）動的アドレス再構成」、進行中の作業。

7. Acknowledgments

7. 謝辞

Thanks to Steve Bellovin of AT&T Research, Michael Tuexen of Siemens, Peter Ford of Microsoft, Ran Atkinson of Extreme Networks, and Daniel Senie for useful discussions of this problem space.

AT＆T ResearchのSteve Bellovinのおかげで、SiemensのMichael Tuexen、MicrosoftのPeter Ford、Extreme NetworksのAtkinson、およびDaniel Senieがこの問題スペースの有用な議論をしてくれました。

8. Authors' Addresses

8. 著者のアドレス

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052

   Phone: +1 425 706 6605
   Fax:   +1 425 936 7329
   EMail: bernarda@microsoft.com

William Dixon V6 Security, Inc. 601 Union Square, Suite #4200-300 Seattle, WA 98101

William Dixon V6 Security、Inc。601ユニオンスクエア、スイート＃4200-300シアトル、ワシントン州98101

   EMail: ietf-wd@v6security.com

9. Full Copyright Statement

9. 完全な著作権声明

Copyright (C) The Internet Society (2004). 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.

著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。

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 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

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への情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。