RFC3715 日本語訳
3715 IPsec-Network Address Translation (NAT) CompatibilityRequirements. B. Aboba, W. Dixon. March 2004. (Format: TXT=43476 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 3715 W. Dixon
Category: Informational Microsoft
March 2004
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3715年のW.ディクソンカテゴリ: 2004年の情報のマイクロソフト行進
IPsec-Network Address Translation (NAT) Compatibility Requirements
IPsec-ネットワーク・アドレス翻訳(NAT)互換性要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントは、Network Address Translation(NAT)とIPsecの間で知られている非互換性について説明して、それらを扱うために要件について説明します。 バーチャルプライベートネットワーキング能力を提供するのにおいて恐らくIPsecの最も一般の使用があります。 Virtual兵士のNetworks(VPNs)の1つの非常にポピュラーな使用は法人のイントラネットへの在宅勤務者アクセスを提供することです。 今日、NATsはホームゲートウェイ、および在宅勤務者によって使用されそうな他の位置で広く配布されます、ホテルなどのように。 結果はIPsec-NAT非互換性が主要な用途の1つにおける、IPsecの展開で主要なバリアになったということです。
Aboba & Dixon Informational [Page 1] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[1ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 要件言語。 . . . . . . . . . . . . . . . . . 2 2. NA(P)TとIPsec. . . . . . . 3 2.1の間の非互換性を知っています。 本質的なNA(P)T問題。 . . . . . . . . . . . . . . . . 3 2.2. NA(P)T実装弱点. . . . . . . . . . . . 7 2.3。 アシスタント非互換性. . . . . . . . . . . . . . . . 8 3。 IPsec-NATの互換性. . . . . . . . . . . 8 4のための要件。 既存のソリューション. . . . . . . . . . . . . . . . . . . . . . 12 4.1。 IPsecはモードにトンネルを堀ります。 . . . . . . . . . . . . . . . . . . . 12 4.2. RSIP. . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3。 6to4. . . . . . . . . . . . . . . . . . . . . . . . . . 13 5。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 14 6. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1。 引用規格. . . . . . . . . . . . . . . . . . 15 6.2。 有益な参照. . . . . . . . . . . . . . . . . 16 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 17 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 17 9の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 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.
バーチャルプライベートネットワーキング(VPN)に能力を提供するのにおいて恐らくIPsec[RFC2401]の最も一般の使用があります。 VPNsの1つの非常にポピュラーな使用は法人のイントラネットへのアクセスを在宅勤務者に提供することです。 今日、[RFC3022]で説明されるNetwork Address Translations(NATs)、および[RFC2663]はホームゲートウェイ、および在宅勤務者によって使用されそうな他の位置で広く配布されます、ホテルなどのように。 結果は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].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[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.
本書では指定された要件はプロトコル差出を評価する際に使用されることです。 そういうものとして、要件言語はこれらのプロトコルの能力について言及します。 プロトコルドキュメントは、これらの特徴が必要であるか、お勧め、または任意であるかを指定するでしょう。 例えば、プロトコルサポート秘密性がすべてがトラフィックについて議定書の中で述べるのが必要であるのと同じものでないことは必要であることで、暗号化されてください。
Aboba & Dixon Informational [Page 2] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[2ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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つか以上を満たさないならプロトコル提案が対応でない、それが実装する能力のためのNOT要件はそうしなければなりません。 すべてを満たすプロトコル提案、NOT、SHOULD、および能力のためのSHOULD NOT要件は「無条件に言いなりになる」と言われています;でなければならない そして、すべてを満たすもの、プロトコルのための要件が言われているすべてのSHOULDかSHOULD NOTではなく、NOT要件が「条件付きに言いなりになっていなければなりませんか?」
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)tで存在していない間、これらの特徴は十分ポピュラーにまた彼らが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の間の不一致、ああ、[RFC2402]とNAT。 AHヘッダーがIPソースを取り入れて、合わせられたメッセージの保全における送付先アドレスがチェックするので、NATか分野を扱うために変更を行う逆のNATデバイスがメッセージの保全チェックを無効にするでしょう。 超能力[RFC2406]がするIPsecがIPソースを取り入れないで、合わせられたメッセージの保全における送付先アドレスがチェックするので、この問題は超能力のために起こりません。
Aboba & Dixon Informational [Page 3] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[3ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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) チェックサムとNATの間の不一致。 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 Encapsulating Security有効搭載量(超能力)がNATを通して妨害がない状態で終わる、(IPv4 UDPで可能である、) [RFC793]で説明されるように、TCPチェックサム計算と検証がIPv4で必要です。 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]で定義されるストリームControl Transmissionプロトコル(SCTP)はSCTPパケット(一般的なヘッダー+塊)だけの上で計算されたCRC32Cアルゴリズムを使用します、IPヘッダーがカバーされていないように。 その結果、NATsは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.
UDP/TCPチェックサムをチェックする前に交通機関IPsecトラフィックが強い暗号を使用することで保護されて、認証された保全であるのでパケットへの変更を検出できることに注意してください。その結果、チェックサム検証は内部の処理に関する誤りに対して保証を前提とするだけです。
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)に使用されるところ NATsか逆のNATsによるIPソースか送付先アドレスのフェーズ1[RFC2409]かPhase2、変更が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 Phase1とPhase2つの識別子としてIPアドレスの使用を避けるために、代わりにuserIDsとFQDNsを使用できます。 ユーザー認証が望まれているところでは、[RFC2407]で説明されるように_ID USER_FQDNのIDタイプを使用できます。 マシン認証が望まれているところでは、ID_FQDNのIDタイプを使用できます。 どちらかの場合では、終わり実体証明書を処理することの結果、提案された識別子が認証されることを確かめるのが必要です、Phase1で証明書を交換するなら。 USER_FQDNかFQDNアイデンティティタイプの使用はIKEの中で可能ですが、この道に対応できない用法シナリオ(例えば、サブネットについて説明するSecurity Policy Database(SPD)エントリー)があります。
Aboba & Dixon Informational [Page 4] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[4ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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.
Phase2識別子のソースアドレスが完全な5-tuple本国行きの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に「反-マルチプレックス」への入って来る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を重ね合わせることの間の非互換性。 それらのソースIPがPhaseで2つの識別子を扱うNAT使用の後ろでホストを開始するところでは、それらは、同じ応答者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超能力トラフィックが暗号化されていてその結果、NATに不透明であるので、NATは「反-マルチプレックス」の入って来るIPsecトラフィックにIPとIPsecヘッダーの要素を使用しなければなりません。 送付先IPアドレス、セキュリティプロトコル(AH/超能力)、および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.
しかしながら、送受信のSPIsが独自に選ばれているので、NATが、入って来るSPIが何で単にどんなあて先ホストに文通するかを決定する外向的なトラフィックを点検する方法が全くありません。 したがって、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
これがそういうもののIPsecにもかかわらず、それが通常実装されるむしろ方法がある不一致でないことに注意してください。 AHと超能力の両方で、受信ホストは与えられたSAの使用にSPIを指定します、受信機だけに重要な選択。現在のところ、Destination IP、SPI、およびSecurityプロトコル(AH、超能力)の組み合わせは唯一Security Associationを特定します。 また、範囲1-255のSPI値は、IANAに予約されて、中で使用されるかもしれません。
Aboba & Dixon Informational [Page 5] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[5ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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.
将来。 これは、同じ外部のホストかゲートウェイと交渉するとき、同じNAPTの後ろの内部のホストが同じSPI値を選択できることを意味して、1ホストの本国行きのSAが(SPI=470、Internal Dest IP=192.168.0.4)であり、異なったホストが本国行きのSAであるようにものは(SPI=470、Internal 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.
また、受信ホストが各ユニキャストSecurity AssociationにユニークなSPIを割り当てるのも、可能です。 この場合、Destination IP Addressはそれが「このホストのための何か有効なユニキャストIP」であるかどうか確認するためにはチェックされるだけでよいです、と送付ホストによって使用されたIPアドレスはそれが特定のDestinationであるかどうか確認するためにチェックしませんでした。 このテクニックを使用して、間違った内部のホストにパケットを送るという安値にもかかわらず、非ゼロ機会をNA(P)Tを保証できます、2人以上のホストが同じ外部のホストと共にSAsを設立すると。
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_入力()コードへ変更を加えるのが必要です。 しかしながら、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で翻訳できないでしょう。 これは、NATsの中で効果がないApplication Layer Gateways(ALGs)を実装するようにレンダリングします。 埋め込まれたIPアドレスを利用するプロトコルがFTP、IRC、SNMP、LDAP、H.323、SIP、SCTP(任意に)、および多くのゲームを含んでいます。 この問題を扱うために、IPsecカプセル化の前とIPsec被膜剥離術の後にアプリケーショントラフィックを作動させることができるホストかセキュリティゲートウェイにALGsを設置するのが必要です。
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)tは、本国行きのマッピング状態を創設するためにしばしば初期の外国行きのパケットがそれらを通して流れるのを必要とします。 方向性はIPsec SAsの求められていない設立をNA(P)Tの後ろのホストに禁止します。
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個のセレクタ、本国行きのSA処理が交渉するフェーズを交渉すると仮定して、decapsulatedパケットを下げてください、そして、[RFC2401]がパケットのソースを必要とするので、マッチがSAセレクタ価値であると扱ってください。(超能力パケットのNA(P)T処理はそれを変えるでしょう)。
Aboba & Dixon Informational [Page 6] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[6ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
2.2. NA(P)T Implementation Weaknesses
2.2. NA(P)T実装弱点
Implementation problems present in many NA(P)Ts include:
多くのNA(P)tにおける現在の実装問題は:
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トラフィックを扱うことができないこと。 1人のホストしかNATの後ろにいないとき、いくつかのNA(P)tが、非UDP/TCPトラフィックを捨てるか、またはアドレスだけ翻訳を実行します。 そのようなNAPTsはSCTP、超能力(プロトコル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)tは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)tがIPパケットサイズが外向的なインタフェースのMTUを超えている場合で適切に出発しているIPパケットを断片化できます。 しかしながら、既に断片化される出発しているパケットの適切な翻訳は難しいです、そして、ほとんどのNAPTsは正しくこれを扱いません。 2人のホストが同じ目的地に断片化しているパケットを溯源する[RFC3022]のセクション6.3に述べられるように、部分識別子は重なることができます。 あて先ホストが再アセンブリのために相殺された断片化識別子と断片を当てにするので、結果はデータの汚染になるでしょう。 NA(P)数tしか、識別子翻訳をサポートすることによって、識別子衝突から守りません。 NATsが断片化を実行するとき、識別子衝突は問題ではありません、部分識別子がソース/目的地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ヘッダーを含むという保証が全くありません。 したがって、recalculateにおいてTCPチェックサムを見るNA(P)Tは、その後の断片を変更する必要があるかもしれません。 断片を再命令できて、IPアドレスを埋め込んで、断片の間で分けることさえできるので、NA(P)Tは、翻訳を終了する前に再アセンブリに働く必要があるでしょう。 NA(P)数tしかこれをサポートしません。
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
m) 入来を扱うことができないことは断片化します。 最初の断片だけが完全なIP/UDP/SCTP/TCPヘッダーを通常含むので、NAPTsは、単独でソース/dest IPアドレスと部分識別子に基づく翻訳は実行できる必要があります。 断片を再命令できるので、その後の断片が初期のものの前に届いて、ヘッダーが断片の間で分けられるかもしれないなら、与えられた部分識別子へのヘッダーは知られていないかもしれません。 その結果、NAPTは、翻訳を終了する前に再アセンブリに働く必要があるかもしれません。 わずかなNAPTsしかこれをサポートしません。 NAT、アドレスが十分であるソース/dest IPと共にそれに注意してください。
Aboba & Dixon Informational [Page 7] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[7ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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.
これが起こらないように、翻訳を決定してください。 しかしながら、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) インターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)ヘッダー点検。 今日、いくつかのNAT実装が、反-入って来るIKEトラフィックを多重送信するのにIKEクッキーを使用するのを試みます。 ソースポート逆多重化のように、IKEクッキー逆多重化は再の合わせるのに関する問題をもたらします、Phase1再キーが以前のトラフィックと同じクッキーを通常使用しないので。
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実装が非500UDPソースポートを扱うことができないので、いくつかのNATsは500のUDPソースポートでパケットを翻訳しません。 これは、これらのNATsが目的地門あたり1人のIPsecクライアントに制限されることを意味します、彼らがクッキーを調べるためにISAKMPヘッダーの細部を点検しない場合(上に述べられた問題を生じさせます)。
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オプション交渉のためにベンダー_イドペイロードを支えないかもしれません。
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)tの使用につながる問題であると扱うので、IPsec-NAT互換性問題はIPv6の広範囲の展開の前に時間枠で解決される必要がある過渡的な問題です。 したがって、役に立つように、IPsec-NAT互換性ソリューションはIPv6より短いタイムスケールで配布可能でなければなりません。
Aboba & Dixon Informational [Page 8] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[8ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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とほとんど同じタイムスケールで配布可能になるでしょう。 したがって、SHOULDが必要とする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 SHOULD NOTとのコミュニケーションがIPsec-NAT互換性ソリューションによって必要とされるのを含意します、それはNA(P)tへの変化、およびホストと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と共に非機密保護されると、IPsec NAT縦断対策が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縦断対策は、NA(P)Tが縦断であるとサポートしなければなりません、IPsecトンネルモードかIPsec交通機関の上のL2TP[RFC3193]のどちらかを通して。 これはリモートクライアントとVPNゲートウェイの間の1NA(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.
クライアントには、発送可能アドレスがあるかもしれません、そして、少なくとも1NA(P)Tの後ろにVPNゲートウェイがあるかもしれませんか、またはあるいはまた、1NA(P)t以上の後ろにクライアントとVPNゲートウェイの両方があるかもしれません。 在宅勤務者は同じプライベートIPアドレスを使用するかもしれません、それぞれそれら自身のNA(P)Tの後ろで、または、多くの在宅勤務者が同じNA(P)Tの後ろの私設のネットワークに住むかもしれません、それぞれそれら自身のユニークなプライベート・アドレスで、同じVPNゲートウェイに接続して。 IKEが目的地としてUDPポート500を使用するので、同じ外部のIPアドレスの後ろで作動する複数のVPNゲートウェイを可能にするのは必要ではありません。
Aboba & Dixon Informational [Page 9] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[9ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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)インタフェースにプライベート・アドレスを持っているかもしれません。 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コミュニケーションを可能にしなければなりません。 それらの間には、1NA(P)t以上がある状態で、私設のネットワークのホストは1、複数のIPsecによって保護されたTCP接続またはUDPセッションを別のホストに育てることができなければなりません。 例えば、NA(P)tは企業ネットワークに接続しながら、支店の中で配布されるかもしれません、追加NA(P)Tが企業ネットワークをインターネットに接続して。 同様に、NA(P)tは、ワイヤレスの、または、リモートな位置のクライアントを企業ネットワークに接続するために企業ネットワーク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:
彼らの間には、1NA(P)t以上がある状態で別のホストにSCTP接続を育てると、特別な挑戦は提示されるかもしれません。 SCTPはマルチの家へ帰りをサポートします。 1つ以上のIPアドレスが使用されているなら、これらのアドレスは協会セットアップ(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アドレスパラメタも使用しないのが、代替手段であることに注意して、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パケットに入れられるべきでないのを含意します。 NATsが存在していて、IPアドレスが含まれていると、協会セットアップは失敗するでしょう。 最近、協会がいったん設立されるとIPアドレスの変更を許す[AddIP]が提案されました。 NATsは、また、SCTPパケットにIPアドレスを持っているので、変更メッセージを、悪影響を受けさせるでしょう。
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-IPsec互換性ソリューションは、ファイアウォール管理者がIKEとIPsec NA(P)Tに対して縦断トラフィックを可能にするか、または否定するために簡単で、静的なアクセス規則を作成するのを可能にしなければなりません。 IKEかIPsec仕向港の動的割当ては例えば、これが避けられるつもりであることです。
Aboba & Dixon Informational [Page 10] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[10ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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互換性ソリューションは、何千人もの在宅勤務者から成りながら、インストールの中で配布することができるべきです。 この状況で、独身のホストだけが一度に与えられた目的地で交信すると仮定するのは可能ではありません。 したがって、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互換性ソリューションはIKEの縦断をサポートしなければなりません、そして、IPsecモードが[RFC2409]と[RFC2401]の中のサポートに必要です。 例えば、IPsecゲートウェイは、超能力トンネルモードが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もどこに存在していないかを伝えることができるように。 これは、IPsec-NAT互換性ソリューションが[RFC2401]とIKEで定義されるように[RFC2409]で定義されるように後方にIPsecと互換性があるに違いないのを含意します。 さらに、それ、SHOULD、NA(P)Tの存在を検出できてください、必要であるときにだけ、NA(P)T縦断サポートが使用されるように。 これは、既存のIKE実装が、NA(P)Tが縦断であるとサポートしないことを決定するのが可能であるに違いないことを含意します、標準のIKEの会話が起こることができるように、[RFC2407]、[RFC2408]、および[RFC2409]で説明されるように。 これが500を移植するためにIKEの開始を含意しますが、特定のソースポートのための要件が全くないことに注意してください、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セキュリティの脆弱性を導入してはいけません。 例えば、許容できるソリューションは、サービスかスプーフィング脆弱性のどんな新しい否定も導入しないのを示さなければなりません。 [RFC2408]で説明される双方向の方法で再キーにイケを許容しなければなりません。
Aboba & Dixon Informational [Page 11] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[11ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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:
限られたセットの事情では、IPsecトンネルモード実装に、それは可能です、首尾よくNA(P)Tを横断するために[DHCP]で説明されたそれなどのように。 しかしながら、要件がうまくいっている縦断のために十分限られているので、より一般的なソリューションが必要です:
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、特に。 IPsec超能力トンネルは、メッセージの保全チェックの中で外側のIPヘッダーをカバーしていないので、アドレス変換のためAuthentication Data無効にするのを受けないでしょう。 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) 「Anyへのいずれ」SPDエントリー。 IPsecトンネルモードクライアントは「いずれへのいずれ」SPDsを交渉できます。(SPDsはアドレス変換で無効にされません)。 事実上、これはSPDsの許容トンネルトラフィックのフィルタリングの使用を排除します。
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の後ろの独身のクライアントだけと共に、SPDsを重ね合わせるリスクが全くいません。 NATが競争しているクライアントの間を調停する必要はないので、また、再主要な誤訳、不適当な入って来るSPIまたはクッキー逆多重化のリスクが全くありません。
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ポートマッピングはそれほどありそうでないのが、不活発への取り除かれた支払われるべきものであるということです。
Aboba & Dixon Informational [Page 12] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[12ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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縦断のためのメカニズムを含んでいます。 ホスト-NA(P)Tコミュニケーションを可能にすることによって、RSIPはSPDオーバラップと同様に反-多重送信するIPsec SPIの問題を扱います。 その結果、それは企業における使用、およびホームネットワークシナリオに適しています。 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プロトコルへの変化を避けます、大きな変化はRSIP-互換性のためにそれらを改装するためにIKEとIPsec実装を接待しなければなりませんが。 その結果、それはすべての既存のプロトコル(AH/超能力)とモード(輸送して、トンネルを堀る)と互換性があります。
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再キーの逆多重化を扱うために、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によって可能にされたホストが別のホストと共にIPsec SAを設立するために対応するRSIPによって可能にされたゲートウェイを必要とするので、RSIPはIPsec-NAT互換性ソリューションのための展開要件を満たしません。 RSIPがサーバではなく、クライアントとルータだけへの変化を必要とするので、展開するのはIPv6ほど難しくはありません。 しかしながら、ベンダーに関して、RSIPの実装はIPv6サポートに必要であるリソースのかなりの部分を必要とします。 したがって、RSIPは長期のタイムスケールに関する「過渡的な」問題を解決します。(タイムスケールは役に立ちません)。
4.3. 6to4
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.
6to4、説明されるように、[RFC3056]ではIPsec-NAT縦断対策の基礎は形成できます。 このアプローチでは、NATは、NATの外部のIPv4アドレスから得られたIPv6接頭語を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
6to4は独身のNA(P)TがクライアントとVPNゲートウェイを切り離すところの上品で強健なソリューションですが、それは一般に適切ではありません。 6to4がIPv6接頭語の構成を許容するためにroutable IPv4アドレスの課題をNA(P)Tに必要とするので、それは複数のNA(P)tがクライアントとVPNの間に存在するところで使用可能ではありません。
Aboba & Dixon Informational [Page 13] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[13ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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を通してIPv6接頭語を得るのにそれの後ろで外部のインタフェースに関するプライベート・アドレスがあるNA(P)Tを使用できません。
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をサポートするのがNATsへの変化を必要とします。(NATsはアップグレードする必要があります)。 その結果、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のためのものであるかもしれません。 しかしながら、ヌル暗号化がある超能力がAHとして同じセキュリティに資産を提供しないことに注意されるべきです。 例えば、ヌル暗号化と共にAHによって排除されるIPv6ソースルーティングに関係するセキュリティ危険がありますが、超能力であるというわけではありません。
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.
さらに、どんな変換がある超能力もソースアドレススプーフィングから守らないので、ある種のソースIPアドレス正気の照合が、実行される必要があります。 反スプーフィングチェックの重要性は広く理解されていません。 _入力されて、通常、反スプーフィングは、IPsecの一部としてのSource IP Addressで_esp、ああをチェックします。ある、()。 これは、パケットがそれがオリジナルのIKE Phase1とPhaseの中で2つのセキュリティ協会を要求したような同じアドレスから発するのを確実にします。 受信ホストがNATの後ろにいるとき、このチェックはユニキャストセッションのために厳密に重要でないかもしれませんが、Globalインターネットでは、トンネルモードユニキャストセッションが受信機の上のアクセス制御が被膜剥離術の後に確かめられた超能力パケットのソースIPアドレスによると起こることができる[AuthSource]で説明されたスプーフィング攻撃を防ぐように、このチェックは重要です。 アクセス制御にソースアドレスを使用するなら、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.
ともにルータB.Hosts AとCとIPsecトンネルモードSAsを交渉する(異なる)のNATsの後ろの2ホスト、A、およびCには異なった特権があるかもしれないと考えましょう。 例えば、ホストAは法人のイントラネットの多くにアクセスすると信じられた従業員のものであるかもしれません、Cが特定のウェブサイトにアクセスするのに権限を与えられただけである契約者であるかもしれませんが。
Aboba & Dixon Informational [Page 14] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[14ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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.
ソース、A.If認証に対応する特権がこのパケットに与えられていないのが、重要であり、保全の照合が実行されるのでAのIPアドレスを偽造するトンネルモードパケットを送りますが、ホストCがどんな反スプーフィングチェックも送らないなら(起因している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] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] アトキンソンとR.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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)用語と問題をネットワークでつなぐ」RFC2663、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)」、RFC3022、2001年1月。
Aboba & Dixon Informational [Page 15] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[15ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、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]スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、M.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] パテルとB.とAbobaとB.とディクソンとW.とゾルンとG.とS.ブース、「IPsecを使用することでL2TPを固定します」、RFC3193、2001年11月。
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[RFC3309] ストーン、J.、スチュワート、研究開発オーティス、「ストリーム制御伝動プロトコル(SCTP)チェックサム変化」、RFC3309、2002年9月。
[RSIPFrame] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIPFrame] Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「フレームワーク」、RFC3102、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.、最低気温、J.、およびK.谷口、「分野の特定のIP:」 「プロトコル仕様」、RFC3103、2001年10月。
[RSIPsec] Montenegro, G. and M. Borella, "RSIP Support for End-
to-End IPsec", RFC 3104, October 2001.
[RSIPsec] モンテネグロとG.とM.Borella、「終わりまでの終わりのIPsecのRSIPサポート」、RFC3104、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] パテル、B.、Aboba、B.、ケリー、S.、および「IPsecトンネル・モードのDynamic Host Configuration Protocol(DHCPv4)構成」、RFC3456(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] ケント、S.、「認証されたソースアドレス」、IPsec WGアーカイブ( ftp://ftp.ans.net/pub/archive/IPsec )、メッセージイド: <v02130517ad121773c8ed@、[128.89 .0 .110] 1996年1月5日の>。
[AddIP] Stewart, R., et al., "Stream Control Transmission
Protocol (SCTP) Dynamic Address Reconfiguration", Work
in Progress.
[AddIP] スチュワート、R.、他、「ストリームの制御伝動のプロトコルの(SCTP)ダイナミックなアドレス再構成」、ProgressのWork。
Aboba & Dixon Informational [Page 16] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[16ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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のスティーブBellovin、シーメンスのマイケルTuexen、マイクロソフトのピーター・フォード、Extreme NetworksのRanアトキンソン、およびダニエルSenieをありがとうございます。
8. Authors' Addresses
8. 作者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 425 706、6605Fax: +1 7329年の425 936メール: bernarda@microsoft.com
William Dixon V6 Security, Inc. 601 Union Square, Suite #4200-300 Seattle, WA 98101
ワシントン ウィリアム・ディクソンV6セキュリティInc.601ユニオン・スクエア、スイート#4200-300シアトル、98101
EMail: ietf-wd@v6security.com
メール: ietf-wd@v6security.com
Aboba & Dixon Informational [Page 17] RFC 3715 IPsec-NAT Compatibility Requirements March 2004
2004年の[17ページ]RFC3715IPsec-NAT互換性要件行進の情報のAbobaとディクソン
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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aboba & Dixon Informational [Page 18]
AbobaとディクソンInformationalです。[18ページ]
一覧
スポンサーリンク
