Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 5879 AuthenTec, Inc.
Category: Informational D. McDonald
ISSN: 2070-1721 Oracle Corporation
May 2010
Heuristics for Detecting ESP-NULL Packets
Abstract
抽象
This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303.
この文書では、暗号化されたESPパケットからパケット（暗号化なしでカプセル化セキュリティペイロード）のIPsec ESP-NULLを区別するためのヒューリスティックのセットを記述する。これらの経験則はすぐに与えられたパケットの流れは、それが検査することができるかどうか、すなわち、暗号化されているかどうかを決定するために、トラフィックアナライザ、およびディープインスペクションエンジンのように、中間デバイス上で使用することができます。これらのヒューリスティックの使用は、RFC 4303に準拠している既存のIPSecホスト上で行った変更を必要としません。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5879.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5879で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability: Heuristic Traffic Inspection and
Wrapped ESP ................................................4
1.2. Terminology ................................................4
2. Other Options ...................................................5
2.1. AH .........................................................5
2.2. Mandating by Policy ........................................6
2.3. Modifying ESP ..............................................6
3. Description of Heuristics .......................................6
4. IPsec Flows .....................................................7
5. Deep-Inspection Engine ..........................................9
6. Special and Error Cases .........................................9
7. UDP Encapsulation ..............................................10
8. Heuristic Checks ...............................................10
8.1. ESP-NULL Format ...........................................11
8.2. Self Describing Padding Check .............................12
8.3. Protocol Checks ...........................................14
8.3.1. TCP Checks .........................................15
8.3.2. UDP Checks .........................................16
8.3.3. ICMP Checks ........................................16
8.3.4. SCTP Checks ........................................17
8.3.5. IPv4 and IPv6 Tunnel Checks ........................17
9. Security Considerations ........................................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
Appendix A. Example Pseudocode ...................................20
A.1. Fastpath ..................................................20
A.2. Slowpath ..................................................23
The ESP (Encapsulating Security Payload [RFC4303]) protocol can be used with NULL encryption [RFC2410] to provide authentication, integrity protection, and optionally replay detection, but without confidentiality. ESP without encryption (referred to as ESP-NULL) offers similar properties to IPsec's AH (Authentication Header [RFC4302]). One reason to use ESP-NULL instead of AH is that AH cannot be used if there are NAT (Network Address Translation) devices on the path. With AH, it would be easy to detect packets that have only authentication and integrity protection, as AH has its own protocol number and deterministic packet length. With ESP-NULL, such detection is nondeterministic, in spite of the base ESP packet format being fixed.
ESP（カプセル化セキュリティペイロード[RFC4303]）プロトコルは、認証、完全性保護、および任意でリプレイ検出が、機密性なしを提供するために、NULL暗号化[RFC2410]で使用することができます。 ESP暗号化なし（ESP-NULLと呼ばれる）のIPsecのAH（認証ヘッダー[RFC4302]）に類似した特性を提供しています。代わりに、AHのESP-NULLを使用する理由の1つは、AHは、NAT（ネットワークアドレス変換）パス上のデバイスがある場合は使用できないということです。 AHは、独自のプロトコル番号と決定論パケット長を持つようAHで、唯一の認証と完全性保護を持つパケットを検出するのは簡単だろう。 ESP-NULLで、そのような検出は、固定されたベースESPパケットフォーマットにもかかわらず、非決定的です。
In some cases, intermediate devices would like to detect ESP-NULL packets so they could perform deep inspection or enforce access control. This kind of deep inspection includes virus detection, spam filtering, and intrusion detection. As end nodes might be able to bypass those checks by using encrypted ESP instead of ESP-NULL, these kinds of scenarios also require very specific policies to forbid such circumvention.
いくつかのケースでは、中間デバイスは、彼らが深い検査を実行したり、アクセス制御を強制することができるようにESP-NULLパケットを検出したいと思います。深い検査のこの種のウイルスの検出、スパムフィルタリング、および侵入検知が含まれています。エンドノードが暗号化されたESPの代わりにESP-NULLを使用して、これらのチェックを回避することができるかもしれないように、シナリオのこれらの種類は、そのような回避を禁止することは非常に特定のポリシーを必要とします。
These sorts of policy requirements usually mean that the whole network needs to be controlled, i.e., under the same administrative domain. Such setups are usually limited to inside the network of one enterprise or organization, and encryption is not used as the network is considered safe enough from eavesdroppers.
ポリシー要件のこれらの種類は、通常、ネットワーク全体が同じ管理ドメインの下で、すなわち、制御する必要があることを意味します。このようなセットアップは、通常、1つの企業や組織のネットワークの内部に限定されており、ネットワークを盗聴者から十分に安全と見なされるよう暗号化が使用されていません。
Because the traffic inspected is usually host-to-host traffic inside one organization, that usually means transport mode IPsec is used. Note, that most of the current uses of IPsec are not host-to-host traffic inside one organization, but for the intended use cases for the heuristics, this will most likely be the case. Also, the tunnel mode case is much easier to solve than transport mode as it is much easier to detect the IP header inside the ESP-NULL packet.
通常、トランスポートモードIPsecを意味することを、通常、ホスト間トラフィックを1つの組織内に検査トラフィックが使用されているので。 IPsecの現在の用途のほとんどは1つの組織内トラフィックにホスト - ホストされていませんが、経験則のための意図したユースケースのために、これが最も可能性の高いケースになることに注意してください。また、トンネルモードの場合は、ESP-NULLパケット内のIPヘッダを検出することがはるかに容易であるように、トランスポートモードよりも解決することがはるかに容易です。
It should also be noted that even if new protocol modifications for ESP support easier detection of ESP-NULL in the future, this document will aid in the transition of older end-systems. That way, a solution can be implemented immediately, and not after 5-10 years of upgrade and deployment. Even with protocol modification for end nodes, the intermediate devices will need heuristics until they can assume that those protocol modifications can be found from all the end devices. To make sure that any solution does not break in the future, it would be best if such heuristics are documented -- i.e., publishing an RFC for what to do now, even though there might be a new protocol coming in the future that will solve the same problem in a better way.
また、ESPのための新しいプロトコルの変更は、将来的にESP-NULLの容易な検出をサポートしていても、この文書は、古いエンドシステムの移行を支援することに注意すべきです。こうすることで、解決策を直ちに実施することができませんアップグレードや展開の5〜10年後。それらは、それらのプロトコルの変更がすべてのエンドデバイスから求めることができると仮定することができるまでもエンドノードのためのプロトコルの変更と、中間デバイスは、ヒューリスティックが必要になります。こうした経験則が文書化されている場合は任意のソリューションは、将来的に壊れていないことを確認するために、それは最高のだろう - すなわち、解決します将来的に来て、新しいプロトコルがあるかもしれないにも関わらず、今何をすべきかについては、RFCを公開より良い方法で同じ問題。
There are two ways to enable intermediate security devices to distinguish between encrypted and unencrypted ESP traffic:
暗号化と暗号化されていないESPトラフィックを区別するために、中間セキュリティデバイスを有効にするには2つの方法があります。
o The heuristics approach has the intermediate node inspect the unchanged ESP traffic, to determine with extremely high probability whether or not the traffic stream is encrypted.
Oヒューリスティック手法は、中間ノードは、不変のESPトラフィックを検査し、トラフィックストリームが暗号化されているか否かを非常に高い確率で決定しなければなりません。
o The Wrapped ESP (WESP) approach [RFC5840], in contrast, requires the ESP endpoints to be modified to support the new protocol. WESP allows the intermediate node to distinguish encrypted and unencrypted traffic deterministically, using a simpler implementation for the intermediate node.
ラップESP（WESP）アプローチ[RFC5840] O、対照的に、新しいプロトコルをサポートするように変更されるESPエンドポイントを必要とします。 WESPは、中間ノードが中間ノードのための簡単な実装を使用して、決定論的に暗号化および暗号化されていないトラフィックを区別することを可能にします。
Both approaches are being documented simultaneously by the IPsecME Working Group, with WESP being put on Standards Track while the heuristics approach is being published as an Informational RFC. While endpoints are being modified to adopt WESP, both approaches will likely coexist for years, because the heuristic approach is needed to inspect traffic where at least one of the endpoints has not been modified. In other words, intermediate nodes are expected to support both approaches in order to achieve good security and performance during the transition period.
ヒューリスティックアプローチは情報RFCとして公開されている間、WESPが標準化過程の上に置かれているとの両方のアプローチは、IPsecMEワーキンググループによって同時に文書化されています。エンドポイントがWESPを採用するように変更されている間、ヒューリスティックなアプローチは、エンドポイントの少なくとも一方が変更されていないトラフィックを検査するために必要とされるので、両方のアプローチはおそらく、年間の共存します。換言すれば、中間ノードは、遷移期間中に良好なセキュリティとパフォーマンスを達成するために、両方のアプローチをサポートすることが期待されます。
This document uses following terminology:
このドキュメントでは、次の用語を使用します。
Flow
フロー
A TCP/UDP or IPsec flow is a stream of packets that are part of the same TCP/UDP or IPsec stream, i.e., TCP or UDP flow is a stream of packets having same 5 tuple (source and destination IP and port, and TCP/UDP protocol). Note, that this kind of flow is also called microflow in some documents.
TCP / UDPまたはIPsecの流れは同じTCP / UDPやIPsecストリームの一部であるパケットのストリームであり、すなわち、TCPまたはUDPフローは、同じ5タプル（送信元および宛先IPとポート、およびTCPのパケットのストリームであります/ UDPプロトコル）。流れのこの種はまた、いくつかの文書でマイクロフローと呼ばれていることに、注意してください。
Flow Cache
フローキャッシュ
deep-inspection engines and similar devices use a cache of flows going through the device, and that cache keeps state of all flows going through the device.
ディープインスペクションエンジンと同様のデバイスは、デバイスを通過するフローのキャッシュを使用し、そのキャッシュは、デバイスを通過するすべてのフローの状態を保持します。
IPsec Flow
IPsecの流れ
An IPsec flow is a stream of packets sharing the same source IP, destination IP, protocol (ESP/AH), and Security Parameter Index (SPI). Strictly speaking, the source IP does not need to be a part of the flow identification, but it can be. For this reason, it is safer to assume that the source IP is always part of the flow identification.
IPsecのフローは、同じソースIP、送信先IP、プロトコル（ESP / AH）、およびセキュリティパラメータインデックス（SPI）を共有するパケットのストリームです。厳密に言えば、送信元IPは、フロー識別の一部である必要はありませんが、それはすることができます。このため、送信元IPが常にフロー識別の一部であると仮定する方が安全です。
This document will discuss the heuristic approach of detecting ESP-NULL packets. There are some other options that can be used, and this section will briefly discuss them.
この文書では、ESP-NULLパケットを検出するヒューリスティックなアプローチを説明します。用いることができる他のいくつかのオプションがあり、そしてこのセクションでは、簡単にそれらを説明します。
The most logical approach would use the already defined protocol that offers authentication and integrity protection, but not confidentiality, namely AH. AH traffic is clearly marked as not encrypted, and can always be inspected by intermediate devices.
最も論理的なアプローチは、認証と完全性保護ではなく、機密性、すなわちAHを提供していますすでに定義されたプロトコルを使用します。 AHトラフィックは暗号化されていないとして明確にマークされ、常に中間デバイスによって検査することができます。
Using AH has two problems. First, as it also protects the IP headers, it will also protect against NATs on the path; thus, it will not work if there is a NAT on the path between end nodes. In some environments this might not be a problem, but some environments, include heavy use of NATs even inside the internal network of the enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could be extended to support AH also, and the early versions of the NAT-T proposals did include that, but it was left out as it was not seen as necessary.
AHを使用すると、2つの問題があります。それはまた、IPヘッダを守るように、まず、それはまた、パス上のNATから保護します。エンドノード間のパス上にNATがある場合ので、それは動作しません。一部の環境ではこれは問題ではないかもしれませんが、一部の環境では、さえも、企業や組織の内部ネットワーク内でのNAT重い使用を含みます。 NATトラバーサル（NAT-T、[RFC3948]）はまた、AHをサポートするように拡張することができ、NAT-Tの提案の初期のバージョンは、ことなどがなかったが、それは、必要に応じて見られなかったとして、それは取り残されました。
Another problem is that in the new IPsec Architecture [RFC4301] the support for AH is now optional, meaning not all implementations support it. ESP-NULL has been defined to be mandatory to implement by "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)" [RFC4835].
もう一つの問題は、新しいIPsecのアーキテクチャ[RFC4301]にAHのサポートはありませんすべての実装がそれをサポートする意味、今オプションであるということです。 ESP-NULLは「カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件」[RFC4835]で実装するために必須であると規定されています。
AH also has quite complex processing rules compared to ESP when calculating the Integrity Check Value (ICV), including things like zeroing out mutable fields. Also, as AH is not as widely used as ESP, the AH support is not as well tested in the interoperability events.
AHも変更可能なフィールドをゼロのようなものを含め、チェック値（ICV）を整合性を計算する際にESPに比べてかなり複雑な処理のルールがあります。 AHは次のように広くESPとして使用されていないとしても、AHのサポートは、同様の相互運用性のイベントでテストされていません。
Another easy way to solve this problem is to mandate the use of ESP-NULL with common parameters within an entire organization. This either removes the need for heuristics (if no ESP-encrypted traffic is allowed at all) or simplifies them considerably (only one set of parameters needs to be inspected, e.g., everybody in the organization who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity algorithm). This does work unless one of a pair of communicating machines is not under the same administrative domain as the deep-inspection engine. (IPsec Security Associations (SAs) must be satisfactory to all communicating parties, so only one communicating peer needs to have a sufficiently narrow policy.) Also, such a solution might require some kind of centralized policy management to make sure everybody in an administrative domain uses the same policy, and that changes to that single policy can be coordinated throughout the administrative domain.
この問題を解決するためのもう1つの簡単な方法は、組織全体の中に共通のパラメータを持つESP-NULLの使用を強制することです。これは、ヒューリスティックの必要性を取り除くのいずれか（何のESP暗号化トラフィックが全く許されていない場合）、またはパラメータのかなりそれらを簡素化（一組のみを検査する必要があり、例えば、ESP-NULLを使用している組織内の誰もが使用する必要がありますHMAC-彼らの整合性アルゴリズムとしてSHA-1-96）。通信機の対の一方が、ディープインスペクションエンジンと同じ管理ドメイン下にない場合を除き、これは動作しません。 （IPsecセキュリティアソシエーション（SA）をその唯一の通信ピアが十分に狭いポリシーを持っている必要があり、すべての通信相手に満足のいくものでなければなりません。）また、このようなソリューションは、管理ドメインに必ず皆を作るために、集中ポリシー管理のいくつかの種類が必要な場合があります同じポリシーを使用し、その単一のポリシーへの変更は、管理ドメイン全体コーディネートすることができます。
Several documents discuss ways of modifying ESP to offer intermediate devices information about an ESP packet's use of NULL encryption. The following methods have been discussed: adding an IP-option, adding a new IP-protocol number plus an extra header [RFC5840], adding new IP-protocol numbers that tell the ESP-NULL parameters [AUTH-ONLY-ESP], reserving an SPI range for ESP-NULL [ESP-NULL], and using UDP encapsulation with a different format and ports.
いくつかの文書は、NULL暗号化のESPパケットの使用に関する中間デバイス情報を提供するためにESPを変更する方法について説明します。以下の方法が議論されています、IP-オプションを追加する新しいIPプロトコル番号に加えて、余分なヘッダ[RFC5840]を追加し、ESP-NULLパラメータ[AUTH-ONLY-ESP]を伝える新しいIPプロトコル番号を追加し、予約しますSPIのESP-NULLのための範囲[ESP-NULL]、及び異なる形式およびポートでUDPカプセル化を使用して。
All of the aforementioned documents require modification to ESP, which requires that all end nodes be modified before intermediate devices can assume that this new ESP format is in use. Updating end nodes will require a lot of time. An example of slow end-node deployment is Internet Key Exchange Protocol version 2 (IKEv2). Considering an implementation that requires both IKEv2 and a new ESP format, it would take several years, possibly as long as a decade, before widespread deployment.
上記の書類のすべては、中間のデバイスは、この新しいESPフォーマットが使用中であることを前提とすることができます前に、すべてのエンド・ノードが変更されている必要がESPに変更を必要とします。エンドノードを更新すると、多くの時間を必要とします。スローエンドノード展開の例は、インターネット鍵交換プロトコルバージョン2（IKEv2の）です。 IKEv2のと新しいESP形式の両方を必要とする実装を考慮すると、それが広範に展開する前に、限り十年のように、おそらく、数年かかるだろう。
The heuristics to detect ESP-NULL packets will only require changes to those intermediate devices that do deep inspection or other operations that require the detection of ESP-NULL. As those nodes require changes regardless of any ESP-NULL method, updating intermediate nodes is unavoidable. Heuristics do not require updates or modifications to any other devices on the rest of the network, including (especially) end nodes.
ESP-NULLパケットを検出するヒューリスティックは、唯一の深い検査やESP-NULLの検出を必要とする他の操作を行うそれらの中間デバイスへの変更が必要になります。これらのノードに関係なく、任意のESP-NULL方法の変更を必要とするように、中間ノードを更新することは不可避です。ヒューリスティックは、（特に）エンドノードを含むネットワークの残りの部分に他のデバイスへの更新または変更を必要としません。
In this document, it is assumed that an affected intermediate node will act as a stateful interception device, meaning it will keep state of the IPsec flows -- where flows are defined by the ESP SPI and IP addresses forming an IPsec SA -- going through it. The heuristics can also be used without storing any state, but performance will be worse in that case, as heuristic checks will need to be done for each packet, not only once per flow. This will also affect the reliability of the heuristics.
フローがIPsec SAの形成ESP SPIとIPアドレスによって定義されている - - この文書では、影響を受けた中間ノードが流れ、それがIPsecの状態を維持する意味、ステートフルインターセプトデバイスとして機能することが想定される介さそれ。ヒューリスティックは、任意の状態を記憶することなく使用することができるが、ヒューリスティックチェックだけでなく、一度フロー当たり、各パケットに対して実行する必要がありますとしての性能は、その場合に悪化するであろう。これはまた、ヒューリスティックの信頼性に影響を与えます。
Generally, an intermediate node runs heuristics only for the first few packets of the new flow (i.e., the new IPsec SA). After those few packets, the node detects parameters of the IPsec flow, it skips detection heuristics, and it can perform direct packet-inspecting action based on its own policy. Once detected, ESP-NULL packets will never be detected as encrypted ESP packets, meaning that valid ESP-NULL packets will never bypass the deep inspection.
一般的に、中間ノードは、新しいフロー（すなわち、新規のIPsec SA）の最初のいくつかのパケットのためのヒューリスティックを実行します。それらのいくつかのパケットの後、ノードは、IPSecフローのパラメータを検出し、検出ヒューリスティックをスキップし、それは、それ自身のポリシーに基づいて直接パケット検査アクションを実行することができます。検出された後、ESP-NULLパケットが有効なESP-NULLパケットが深い検査をバイパスすることはありませんことを意味し、暗号化されたESPパケットとして検出されることはありません。
The only failure mode of these heuristics is to assume encrypted ESP packets are ESP-NULL packets, thus causing completely random packet data to be deeply inspected. An attacker can easily send random-looking ESP-NULL packets that will cause heuristics to detect packets as encrypted ESP, but that is no worse than sending non-ESP fuzz through an intermediate node. The only way an ESP-NULL flow can be mistaken for an encrypted ESP flow is if the ESP-NULL flow uses an authentication algorithm of which the packet inspector has no knowledge.
これらのヒューリスティックの唯一の故障モードは、暗号化されたESPパケットがこうして完全にランダムなパケットデータが深く検査させる、ESP-NULLパケットであると仮定することです。攻撃者は簡単に暗号化されたESPなどのパケットを検出するヒューリスティックが発生しますランダムに見えるESP-NULLパケットを送信することができますが、それは、中間ノードを介して非ESPのファズを送信するよりも悪いことではありません。 ESP-NULLフローは、パケットインスペクタが知識を持たないその認証アルゴリズムを使用する場合はESP-NULLフローが暗号化されたESPの流れと誤解することができる唯一の方法です。
For hardware implementations, all the flow lookup based on the ESP next header number (50), source address, destination address, and SPI can be done by the hardware (there is usually already similar functionality there, for TCP/UDP flows). The heuristics can be implemented by the hardware, but using software will allow faster updates when new protocol modifications come out or new protocols need support.
ハードウェア実装のために、すべてのフロー検索がESP次ヘッダ番号（50）、送信元アドレス、宛先アドレスに基づいて、およびSPIは、ハードウェアにより行うことができる（通常はTCP / UDPフローのが既に同様の機能があります）。ヒューリスティックは、ハードウェアで実現することができますが、新しいプロトコルの変更が出てきたり、新しいプロトコルがサポートを必要とする際に、ソフトウェアを使用すると、より高速な更新が可能になります。
As described in Section 7, UDP-encapsulated ESP traffic may also have Network Address Port Translation (NAPT) applied to it, and so there is already a 5-tuple state in the stateful inspection gateway.
セクション7で説明したように、UDPカプセル化ESPトラフィックは、ネットワークがポート変換（NAPT）がそれに印加されるアドレスあり、そう既にステートフルインスペクションゲートウェイ5タプルの状態が存在することができます。
ESP is a stateful protocol, meaning there is state stored in both end nodes of the ESP IPsec SA, and the state is identified by the pair of destination IP and SPI. Also, end nodes often fix the source IP address in an SA unless the destination is a multicast group. Typically, most (if not all) flows of interest to an intermediate device are unicast, so it is safer to assume the receiving node also uses a source address, and the intermediate device should therefore do the same. In some cases, this might cause extraneous cached ESP IPsec SA flows, but by using the source address, two distinct flows will never be mixed. For sites that heavily use multicast, such traffic is deterministically identifiable (224.0.0.0/4 for IPv4 and ff00::0/8 for IPv6), and an implementation can save the space of multiple cache entries for a multicast flow by checking the destination address first.
ESPがESPのIPsec SAの両端のノードに格納されている状態であり、状態は、宛先IP及びSPIのペアによって識別される意味、ステートフルプロトコルです。宛先がマルチキャストグループでない限り、また、エンド・ノードは、多くの場合、SA内のソースIPアドレスを修正します。典型的には、（すべてではない）、ほとんどが中間デバイスへの関心の流れが受信ノードは、送信元アドレスを使用し、中間装置は、したがって同じことを行うべきであると仮定することが安全であるので、ユニキャストです。いくつかのケースでは、これは余分なキャッシュされたESPのIPsec SAの流れを引き起こすかもしれないが、送信元アドレスを使用して、二つの異なるフローが混在することはありません。頻繁にマルチキャストを使用するサイトでは、そのようなトラフィックは決定的に識別可能です（IPv4とFF00 :: 0/8 IPv6のための224.0.0.0/4）、および実装は、宛先をチェックすることにより、マルチキャストフローのために複数のキャッシュエントリのスペースを節約することができます最初に取り組みます。
When the intermediate device sees a new ESP IPsec flow, i.e., a new flow of ESP packets where the source address, destination address, and SPI number form a triplet that has not been cached, it will start the heuristics to detect whether or not this flow is ESP-NULL. These heuristics appear in Section 8.
中間デバイスが新しいESPのIPsecの流れ、すなわち、送信元アドレス、宛先アドレス、およびSPI番号がキャッシュされていないトリプレットを形成するESPパケットの新しい流れを見ているとき、それを検出するヒューリスティックを開始するかどうか、このフローは、ESP-NULLです。これらの経験則は、セクション8に表示されます。
When the heuristics finish, they will label the flow as either encrypted (which tells that packets in this flow are encrypted, and cannot be ESP-NULL packets) or as ESP-NULL. This information, along with the ESP-NULL parameters detected by the heuristics, is stored to a flow cache, which will be used in the future when processing packets of the same flow.
ヒューリスティックが終了したら、彼らは（このフローのパケットが暗号化されており、ESP-NULLパケットではないことを伝えます）のいずれかが暗号化されたようなフローやESP-NULLとしてラベルを付けます。この情報は、経験則により検出ESP-NULLパラメータとともに、同じフローのパケットを処理する際に、将来的に使用されるフローキャッシュに格納されています。
Both encrypted ESP and ESP-NULL flows are processed based on the local policy. In normal operation, encrypted ESP flows are passed through or dropped per local policy, and ESP-NULL flows are passed to the deep-inspection engine. Local policy will also be used to determine other packet-processing parameters. Local policy issues will be clearly marked in this document to ease implementation.
どちらも暗号化されたESPとESP-NULLフローは、ローカルポリシーに基づいて処理されます。通常の操作では、暗号化されたESPフローが通過しているか、ローカルポリシーごとに滴下し、ESP-NULL・フローは、ディープインスペクションエンジンに渡されます。ローカルポリシーは、他のパケット処理パラメータを決定するために使用されます。ローカルポリシーの問題は明確に実装を容易にするため、この文書でマークされます。
In some cases, the heuristics cannot determine the type of flow from a single packet; and in that case, it might need multiple packets before it can finish the process. In those cases, the heuristics return "unsure" status. In that case, the packet processed based on the local policy and flow cache is updated with "unsure" status. Local policy for "unsure" packets could range from dropping (which encourages end-node retransmission) to queuing (which may preserve delivery, at the cost of artificially inflating round-trip times if they are measured). When the next packet to the flow arrives, it is heuristically processed again, and the cached flow may continue to be "unsure", marked as ESP, or marked as an ESP-NULL flow.
いくつかのケースでは、ヒューリスティックは、単一のパケットからの流れのタイプを決定することができません。それはプロセスを終えることができる前に、その場合には、それが複数のパケットが必要になる場合があります。これらのケースでは、ヒューリスティックは、「わからない」状態を返します。その場合は、ローカルポリシーおよびフローキャッシュに基づいて処理されたパケットは、「わからない」の状態に更新されます。 「わからない」パケットのためのローカルポリシーは、（それらが測定される場合に、人工的に往復時間を膨張さを犠牲にし、送達を維持し得る）キューイングする（エンドノード再送を促進する）落下の範囲であり得ます。流れに次のパケットが到着すると、それは発見的に再処理され、キャッシュされた流れは、「わからない」ESPとしてマークされた、またはESP-NULL流れとしてマークし続けることができます。
There are several reasons why a single packet might not be enough to detect the type of flow. One of them is that the next header number was unknown, i.e., if heuristics do not know about the protocol for the packet, they cannot verify it has properly detected ESP-NULL parameters, even when the packet otherwise looks like ESP-NULL. If the packet does not look like ESP-NULL at all, then the encrypted ESP status can be returned quickly. As ESP-NULL heuristics need to know the same protocols as a deep-inspection device, an ESP-NULL instance of an unknown protocol can be handled the same way as a cleartext instance of the same unknown protocol.
単一のパケットが流れのタイプを検出するのに十分ではないかもしれませんいくつかの理由があります。そのうちの一つは、パケットがそれ以外の場合はESP-NULLのように見える場合でも、ヒューリスティックは、パケットのプロトコルを知らない場合、すなわち、彼らはそれはESP-NULLパラメータを適切に検出されたことを確認することはできません、次のヘッダ番号が不明だったということです。パケットが全くESP-NULLのように見えていない場合は、暗号化されたESPの状態はすぐに返すことができます。 ESP-NULLヒューリスティックが深い検査装置と同じプロトコルを知っておく必要がありますように、未知のプロトコルのESP-NULLインスタンスは、同じ未知のプロトコルの平文インスタンスと同じように扱うことができます。
A deep-inspection engine running on an intermediate node usually checks deeply into the packet and performs policy decisions based on the contents of the packet. The deep-inspection engine should be able to tell the difference between success, failure, and garbage. Success means that a packet was successfully checked with the deep-inspection engine, and it passed the checks and is allowed to be forwarded. Failure means that a packet was successfully checked, but the actual checks done indicated that packets should be dropped, i.e., the packet contained a virus, was a known attack, or something similar.
中間ノードで実行されているディープインスペクションエンジンは、通常、パケットに深くチェックし、パケットの内容に基づいて、ポリシー決定を行います。ディープインスペクションエンジンは、成功、失敗、およびゴミの違いを伝えることができるはずです。成功は、パケットが正常にディープインスペクションエンジンをチェックし、それがチェックに合格して転送することを許可されたことを意味します。障害は、パケットが正常に確認されたことを意味するが、行って実際のチェックはパケットが廃棄されるべきであることを示し、すなわち、パケットがウイルスを含む、既知の攻撃、または類似したものでした。
Garbage means that the packet's protocol headers or other portions were unparseable. For the heuristics, it would be useful if the deep-inspection engine could differentiate the garbage and failure cases, as garbage cases can be used to detect certain error cases (e.g., where the ESP-NULL parameters are incorrect, or the flow is really an encrypted ESP flow, not an ESP-NULL flow).
ごみは、パケットのプロトコルヘッダまたは他の部分が解析できないれたことを意味します。ごみの例は、ESP-NULLパラメータが間違っている、またはフローが本当にある特定のエラーの場合（例えば、検出するために使用することができるようディープインスペクションエンジンは、ゴミや失敗例を区別することができれば経験則では、それが有用であろう暗号化されたESPの流れではなく、ESP-NULLの流れ）。
If the deep-inspection engine only returns failure for all garbage packets in addition to real failure cases, then a system implementing the ESP-NULL heuristics cannot recover from error situations quickly.
ディープインスペクションエンジンは、唯一の真の失敗例に加えて、すべてのゴミパケットのための失敗を返した場合は、ESP-NULLヒューリスティックを実装するシステムはすぐにエラー状況から回復することはできません。
There is a small probability that an encrypted ESP packet (which looks like it contains completely random bytes) will have plausible bytes in expected locations, such that heuristics will detect the packet as an ESP-NULL packet instead of detecting that it is encrypted ESP packet. The actual probabilities will be computed later in this document. Such a packet will not cause problems, as the deep-inspection engine will most likely reject the packet and return that it is garbage. If the deep-inspection engine is rejecting a high number of packets as garbage, it might indicate an original ESP-NULL detection for the flow was wrong (i.e., an encrypted ESP flow was improperly detected as ESP-NULL). In that case, the cached flow should be invalidated and discovery should happen again.
小さなヒューリスティックは、ESP-NULLパケットとしてパケットを検出しますように（それは完全にランダムなバイトが含まれているように見えます）暗号化されたESPパケットが期待される場所にもっともらしいバイトを持っているであろう確率、代わりにそれはESPパケット暗号化されていることを検出があります。実際の確率は、本書の後半で計算されます。ディープインスペクションエンジンは、最も可能性の高いパケットを拒否し、それがゴミであることを返します。このようなパケットは、問題を引き起こすことはありません。ディープインスペクションエンジンは、ゴミとしてパケットの高い数を拒否された場合、それは流れの元ESP-NULL検出（すなわち、暗号化されたESPフローが不適切ESP-NULLとして検出された）間違っている可能性があります。その場合には、キャッシュされたフローが無効にされなければならないと発見が再び起こるはずです。
Each ESP-NULL flow should also keep statistics about how many packets have been detected as garbage by deep inspection, how many have passed checks, or how many have failed checks with policy violations (i.e., failed because of actual inspection policy failures, not because the packet looked like garbage). If the number of garbage packets suddenly increases (e.g., most of the packets start to look like garbage according to the deep-inspection engine), it is possible the old ESP-NULL SA was replaced by an encrypted ESP SA with an identical SPI. If both ends use random SPI generation, this is a very unlikely situation (1 in 2^32), but it is possible that some nodes reuse SPI numbers (e.g., a 32-bit memory address of the SA descriptor); thus, this situation needs to be handled.
各ESP-NULL流れもないので、（すなわち、あるため、実際の検査政策の失敗に失敗しましたどのように多くはチェックをパスしたか、どのように多くは、ポリシー違反でチェックを失敗した、深い検査によりゴミとして検出されたどのように多くのパケットに関する統計を維持する必要がありますパケット）がゴミのように見えました。ごみパケットの数が急激に増加した場合（例えば、パケットのほとんどはディープインスペクションエンジンに応じてゴミのように見えるために開始）、古いESP-NULL SAが同じSPIで暗号化されたESP SAに置き換えた可能です。両端がランダムSPI生成を使用する場合、これは非常に低い状況（2 ^ 32で1）であり、いくつかのノードはSPI番号（SA記述子の例えば、32ビットのメモリアドレス）を再利用することが可能です。したがって、このような状況を扱うことが必要です。
Actual limits for cache invalidation are local policy decisions. Sample invalidation policies include: 50% of packets marked as garbage within a second, or if a deep-inspection engine cannot differentiate between garbage and failure, failing more than 95% of packets in last 10 seconds. For implementations that do not distinguish between garbage and failure, failures should not be treated too quickly as an indication of SA reuse. Often, single packets cause state-related errors that block otherwise normal packets from passing.
キャッシュの無効化のための実際の制限は、ローカルポリシーの決定です。サンプル無効化ポリシーが含まれます：50秒以内にゴミとしてマークされたパケットの％、またはディープインスペクションエンジン場合は、最後の10秒でパケットの95％以上を失敗し、ゴミや故障を区別することはできません。ゴミや故障を区別しない実装の場合、障害がSAの再利用の指標として、あまりにも早く扱われるべきではありません。多くの場合、単一のパケットが通過するそれ以外の場合は、通常のパケットをブロック状態に関連するエラーを引き起こします。
The flow lookup code needs to detect UDP packets to or from port 4500 in addition to the ESP packets, and perform similar processing to them after skipping the UDP header. Port-translation by NAT often rewrites what was originally 4500 into a different value, which means each unique port pair constitutes a separate IPsec flow. That is, UDP-encapsulated IPsec flows are identified by the source and destination IP, source and destination port number, and SPI number. As devices might be using IKEv2 Mobility and Multihoming (MOBIKE) ([RFC4555]), that also means that the flow cache should be shared between the UDP encapsulated IPsec flows and non-encapsulated IPsec flows. As previously mentioned, differentiating between garbage and actual policy failures will help in proper detection immensely.
フロー検索コードは、またはESPパケットに加えて、ポート4500からUDPパケットを検出し、UDPヘッダをスキップした後、それらと同様の処理を行う必要があります。 NATによるポート変換は、多くの場合、それぞれのユニークなポートのペアが別々のIPsecフローを構成する意味は異なる値、にもともと4500だったものに書き換えます。すなわち、UDPカプセル化IPSecフローは送信元および宛先IP、送信元および宛先ポート番号、およびSPI番号によって識別されます。デバイスはまた、フローキャッシュがUDPの間で共有されなければならないことを意味し、IKEv2のモビリティ及びマルチホーミング（MOBIKE）（[RFC4555]）を使用している可能性としてのIPSecフローと非封入のIPSecフローをカプセル化。前述したように、ゴミや実際の政策の失敗を区別することは非常に適切な検出に役立ちます。
Because the checks are run for packets having just source port 4500 or packets having just destination port 4500, this might cause checks to be run for non-ESP traffic too. Some traffic may randomly use port 4500 for other reasons, especially if a port-translating NAT is involved. The UDP encapsulation processing should also be aware of that possibility.
チェックがちょうど宛先ポート4500を持つだけで、ソースポート4500を持つパケットまたはパケットのために実行されているので、これはチェックがあまりにも非ESPトラフィックのために実行されることがあります。いくつかのトラフィックは、ランダムにポート変換するNATが含まれている場合は特に、他の理由のためにポート4500を使用することができます。 UDPカプセル化処理は、その可能性に注意する必要があります。
Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability that a random packet will pass the Hashed Message Authentication Code (HMAC) test. This yields a 99.999999999999999999999999998% probability that an end node will correctly detect a random packet as being invalid. This means that it should be enough for an intermediate device to check around 96 bits from the input packet. By comparing them against known values for the packet, a deep-inspection engine gains more or less the same probability as that which an end node is using. This gives an upper limit of how many bits heuristics need to check -- there is no point of checking much more than that many bits (since that same probability is acceptable for the end node). In most of the cases, the intermediate device does not need probability that is that high, perhaps something around 32-64 bits is enough.
通常、HMAC-SHA1-96またはHMAC-MD5-96、ランダムパケットはハッシュメッセージ認証コード（HMAC）試験に合格する2 ^ 96確率のうちの1を与えます。これは、エンド・ノードが正常に無効であるとして、ランダムなパケットを検出します99.999999999999999999999999998%確率が得られます。これは、中間デバイスは、入力パケットからの周りに96ビットをチェックすることが十分でなければならないことを意味します。パケットのための既知の値に対してそれらを比較することにより、ディープインスペクションエンジンは、エンド・ノードが使用しているものと多かれ少なかれ同じ確率を得ます。その多くのビットよりもはるかにチェックのない点（同じ確率ので、エンドノードのために許容される）が存在しない - これは、ヒューリスティックをチェックする必要があるビット数の上限を与えます。ほとんどの場合、中間デバイスは、32から64ビットの周りおそらく、高い何かが十分にあるということである確率を必要としません。
IPsec's ESP has a well-understood packet layout, but its variable-length fields reduce the ability of pure algorithmic matching to one requiring heuristics and assigning probabilities.
IPsecのESPは、よく理解さパケットレイアウトを有するが、その可変長フィールドは、1つのヒューリスティックを必要とする確率を割り当てることに純粋なアルゴリズムマッチングの能力を低下させます。
The ESP-NULL format is as follows:
次のようにESP-NULLの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data (variable) |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
図1
The output of the heuristics should provide information about whether the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL, the heuristics should also provide the Integrity Check Value (ICV) field length and the Initialization Vector (IV) length.
ヒューリスティックの出力は、パケットがESPやESP-NULLを暗号化するかどうかについての情報を提供する必要があります。場合には、それはESP-NULLで、経験則にも整合性がチェック値（ICV）フィールド長と初期化ベクトル（IV）の長さを提供する必要があります。
The currently defined ESP authentication algorithms have 4 different lengths for the ICV field.
現在定義されているESP認証アルゴリズムは、ICVフィールドのための4つの異なる長さを有しています。
Different ICV lengths for different algorithm:
異なるICVは異なるアルゴリズムのための長さ：
Algorithm ICV Length
------------------------------- ----------
AUTH_HMAC_MD5_96 96
AUTH_HMAC_SHA1_96 96
AUTH_AES_XCBC_96 96
AUTH_AES_CMAC_96 96
AUTH_HMAC_SHA2_256_128 128
AUTH_HMAC_SHA2_384_192 192
AUTH_HMAC_SHA2_512_256 256
Figure 2
図2
In addition to the ESP authentication algorithms listed above, there is also the encryption algorithm ENCR_NULL_AUTH_AES_GMAC, which does not provide confidentiality but provides authentication, just like ESP-NULL. This algorithm has an ICV Length of 128 bits, and it also requires 8 bytes of IV.
上記のESP認証アルゴリズムに加えて、機密性を提供しますが、単にESP-NULLのように、認証を提供していない暗号化アルゴリズムENCR_NULL_AUTH_AES_GMACは、もあります。このアルゴリズムは、128ビットのICVの長さを有し、そしてそれはまた、IVの8つのバイトを必要とします。
In addition to the ICV length, there are also two possible values for IV lengths: 0 bytes (default) and 8 bytes (for ENCR_NULL_AUTH_AES_GMAC). Detecting the IV length requires understanding the payload, i.e., the actual protocol data (meaning TCP, UDP, etc.). This is required to distinguish the optional IV from the actual protocol data. How well the IV can be distinguished from the actual protocol data depends on how the IV is generated. If the IV is generated using a method that generates random-looking data (i.e., encrypted counter, etc.) then distinguishing protocol data from the IV is quite easy. If an IV is a counter or similar non-random value, then there are more possibilities for error. If the protocol (also known as the, "next header") of the packet is one that is not supported by the heuristics, then detecting the IV length is impossible; thus, the heuristics cannot finish. In that case, the heuristics return "unsure" and require further packets.
（ENCR_NULL_AUTH_AES_GMAC用）0バイト（デフォルト）と8バイト：ICVの長さに加えて、IVの長さのために2つの可能な値もあります。 IVの長さを検出するペイロード（等TCP、UDPを意味する）、すなわち、実際のプロトコルデータを理解する必要があります。これは、実際のプロトコルデータから、オプションのIVを区別するために必要とされます。どのようにうまくIVは、実際のプロトコルデータを区別することができることはIVが生成された方法によって異なります。 IVはランダムに見えるデータ（すなわち、暗号化されたカウンタ、等）を生成する方法、次いでIVからプロトコルデータを区別するを使用して生成される場合は非常に簡単です。 IVはカウンタまたは類似の非ランダムな値である場合には、エラーのためのより多くの可能性があります。パケットのプロトコルは（また、「次ヘッダ」として知られている）のヒューリスティックによってサポートされていないものである場合には、IVの長さを検出することは不可能です。したがって、ヒューリスティックが終了することはできません。その場合には、ヒューリスティクスは、「わからない」を返すと、さらにパケットを必要とします。
This document does not cover RSA authentication in ESP ([RFC4359]), as it is considered beyond the scope of this document.
それは、この文書の範囲外と考えられているように、この文書では、ESP（[RFC4359]）でRSA認証をカバーしていません。
Before obtaining the next header field, the ICV length must be measured. Four different ICV lengths lead to four possible places for the pad length and padding. Implementations must be careful when trying larger sizes of the ICV such that the inspected bytes do not belong to data that is not payload data. For example, a 10-byte ICMP echo request will have zero-length padding, but any checks for 256-bit ICVs will inspect sequence number or SPI data if the packet actually contains a 96-bit or 128-bit ICV.
次ヘッダフィールドを取得する前に、ICVの長さを測定しなければなりません。四つの異なるICVの長さは、パッドの長さおよびパディングのための4つの可能な場所に導きます。検査バイトはペイロードデータでないデータに属していないようなICVの大きいサイズをしようとしたとき、実装は注意しなければなりません。例えば、10バイトICMPエコー要求は、長さゼロのパディングを持っていますが、パケットが実際に96ビットまたは128ビットのICVを含む場合、256ビットたICVのための任意のチェックは、シーケンス番号またはSPIデータを検査します。
ICV lengths should always be checked from shortest to longest. It is much more likely to obtain valid-looking padding bytes in the cleartext part of the payload than from the ICV field of a longer ICV than what is currently inspected. For example, if a packet has a 96-bit ICV and the implementation starts checking for a 256-bit ICV first, it is possible that the cleartext part of the payload contains valid-looking bytes. If done in the other order, i.e., a packet having a 256-bit ICV and the implementation checks for a 96-bit ICV first, the inspected bytes are part of the longer ICV field, and should be indistinguishable from random noise.
ICVの長さは常に最短から最長にチェックする必要があります。これは、現在検査されているものよりも長いICVのICVフィールドからよりも、ペイロードの平文部分に有効に見えるパディングバイトを得るために、より多くの可能性があります。パケットは96ビットのICVを有し、実装は最初の256ビットのICVのチェックを開始した場合、例えば、ペイロードの平文部分が有効に見えるバイトを含むことが可能です。他の順序で行われている場合、即ち、96ビットのICV 256ビットのICVと実装チェックを持つパケットは、まず被検査バイトが長くICVフィールドの一部であり、ランダムノイズと区別できなければなりません。
Each ESP packet always has between 0-255 bytes of padding, and payload, pad length, and next header are always right aligned within a 4-byte boundary. Normally, implementations use a minimal amount of padding, but the heuristics method would be even more reliable if some extra padding is added. The actual padding data has bytes starting from 01 and ending at the pad length, i.e., exact padding and pad length bytes for 4 bytes of padding would be 01 02 03 04 04.
各ESPパケットは、常に0から255の間のパディングのバイト、及びペイロード、パッド長、次ヘッダは常に右4バイト境界内に整列されています。通常、実装はパディングの最小限の量を使用しますが、いくつかの余分なパディングが追加された場合のヒューリスティック手法は、より信頼性が高いでしょう。実際のパディングデータは、バイト01から開始し、パッド長さで終わる、即ち、パディングの4バイトの正確なパディングパッド長バイトが01 02 03 04 04なり有します。
Two cases of ESP-NULL padding are matched bytes (like the 04 04 shown above), or the 0-byte padding case. In cases where there is one or more bytes of padding, a node can perform a very simple and fast test -- a sequence of N N in any of those four locations. Given four 2-byte locations (assuming the packet size allows all four possible ICV lengths), the upper-bound probability of finding a random encrypted packet that exhibits non-zero length ESP-NULL properties is:
ESP-NULLパディングの二つの場合は、または0バイトのパディングケース（上に示した04 04のような）バイトに一致しています。これら4つの位置のいずれかにおけるN Nのシーケンス - パディングの一つ以上のバイトが存在する場合には、ノードは、非常に簡単かつ迅速に試験を行うことができます。 （パケット・サイズは、すべての4つの可能なICVの長さを可能にすると仮定して）指定された4つの2バイト位置、非ゼロ長ESP-NULL特性であるを示すランダム暗号化されたパケットを見つけるの上限確率：
1 - (1 - 255 / 65536) ^ 4 == 0.015 == 1.5%
１ ー （１ ー ２５５ ／ ６５５３６） ＾ ４ ＝＝ ０。０１５ ＝＝ １。５％
In the cases where there are 0 bytes of padding, a random encrypted ESP packet has:
パディングの0バイトがある場合には、ランダムな暗号化されたESPパケットがあります。
1 - (1 - 1 / 256) ^ 4 == 0.016 == 1.6%.
１ ー （１ ー １ ／ ２５６） ＾ ４ ＝＝ ０。０１６ ＝＝ １。６％。
Together, both cases yield a 3.1% upper-bound chance of misclassifying an encrypted packet as an ESP-NULL packet.
一緒に、両方のケースは、ESP-NULLパケットとして暗号化されたパケットを誤分類の3.1％上限のチャンスをもたらします。
In the matched bytes case, further inspection (counting the pad bytes backward and downward from the pad-length match) can reduce the number of misclassified packets further. A padding length of 255 means a specific 256^254 sequence of bytes must occur. This virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding.
一致バイトの場合には、（パッド長さの一致から後方且つ下方にパッドバイトをカウントする）さらなる検査はさらに、誤分類されたパケットの数を減らすことができます。 255のパディング長は、バイトの特定256 ^ 254配列が起こらなければならないことを意味します。これは事実上、「FF FF」などの実行可能なESP-NULLパディングのペアを排除します。
Every one of the 255 pairs for padding length N has only a 1 / 256^N probability of being correct ESP-NULL padding. This shrinks the aforementioned 1.5% of matched pairs to virtually nothing.
パディング長さNのために255組の一人一人が正しいESP-NULLパディングであることの唯一の256分の1 ^ Nの確率を持っています。これは事実上、何にもマッチしたペアの前述の1.5％縮小します。
At this point, a maximum of 1.6% of possible byte values remain, so the next header number is inspected. If the next header number is known (and supported), then the packet can be inspected based on the next header number. If the next header number is unknown (i.e., not any of those with protocol checking support) the packet is marked "unsure", because there is no way to detect the IV length without inspecting the inner protocol payload.
この時点で、可能なバイト値の1.6％の最大値が残るので、次のヘッダ番号が検査されます。次ヘッダ番号が既知の（支持）されている場合、パケットは、次のヘッダ番号に基づいて検査することができます。次ヘッダ番号が不明な場合（すなわち、ないプロトコルチェックサポートを有するもののいずれかの）パケットは、内側プロトコルペイロードを検査することなく、IVの長さを検出する方法がないため、「不明」とマークされています。
There are six different next header fields that are in common use (TCP (6), UDP (17), ICMP (1), Stream Control Transmission Protocol (SCTP) (132), IPv4 (4), and IPv6 (41)), and if IPv6 is in heavy use, that number increases to nine (Fragment (44), ICMPv6 (58), and IPv6 options (60)). To ensure that no packet is misinterpreted as an encrypted ESP packet even when it is an ESP-NULL packet, a packet cannot be marked as a failure even when the next header number is one of those that is not known and supported. In those cases, the packets are marked as "unsure".
一般的に使用されている六つの異なる次のヘッダフィールドがある（TCP（6）、UDP（17）、ICMP（1）、ストリーム制御伝送プロトコル（SCTP）（132）、IPv4の（4）、およびIPv6（41）） IPv6が重い使用されている場合、及び、その数は9（フラグメント（44）、ICMPv6の（58）、及びIPv6オプション（60））に増加します。次ヘッダ番号が知られており、サポートされていないものの一つであっても何らのパケットは、それがESP-NULLパケットであっても、暗号化されたESPパケットとして誤って解釈されないことを確実にするために、パケットが失敗としてマークすることはできません。これらの例では、パケットは「わからない」としてマークされています。
An intermediate node's policy, however, can aid in detecting an ESP-NULL flow even when the protocol is not a common-case one. By counting how many "unsure" returns obtained via heuristics, and after the receipt of a consistent, but unknown, next header number in same location (i.e., likely with the same ICV length), the node can conclude that the flow has high probability of being ESP-NULL (since it is unlikely that so many packets would pass the integrity check at the destination unless they are legitimate). The flow can be classified as ESP-NULL with a known ICV length but an unknown IV length.
中間ノードの方針は、しかし、プロトコルが共通のケースではない場合であってもESP-NULL流れを検出するのを助けることができます。ヒューリスティックを介して得られた何「わからない」を返すを計数することによって、同じ位置に一致するが、未知の、次のヘッダ番号を受信すると（同一のICVの長さ、すなわち、おそらく）の後に、ノードは、フローは高い確率を有すると結論付けることができますESP-NULL（彼らが正当でない限り、非常に多くのパケットが先の整合性チェックを通過することはほとんどありませんので）という。流れは、既知ICVの長さが、未知のIV長とESP-NULLに分類することができます。
Fortunately, in unknown protocol cases, the IV length does not matter. If the protocol is unknown to the heuristics, it will most likely be unknown by the deep-inspection engine also. It is therefore important that heuristics should support at least those same protocols as the deep-inspection engine. Upon receipt of any inner next header number that is known by the heuristics (and deep-inspection engine), the heuristics can detect the IV length properly.
幸いなことに、未知のプロトコルの例では、IVの長さは関係ありません。プロトコルはヒューリスティックに知られていない場合、それは最も可能性もディープインスペクションエンジンによって不明となります。ヒューリスティックは、ディープインスペクションエンジンとして、少なくとも、同じプロトコルをサポートする必要があることが重要です。ヒューリスティック（及びディープインスペクションエンジン）によって知られている任意の内部次ヘッダ番号を受信すると、ヒューリスティックは、適切IV長を検出することができます。
Generic protocol checking is much easier with preexisting state. For example, when many TCP/UDP flows are established over one IPsec SA, a rekey produces a new SA that needs heuristics to detect its parameters, and those heuristics benefit from the existing TCP/UDP flows that were present in the previous IPsec SA. In that case, it is just enough to check that if a new IPsec SA has packets belonging to the flows of some other IPsec SA (previous IPsec SA before rekey), and if those flows are already known by the deep-inspection engine, it will give a strong indication that the new SA is really ESP-NULL.
一般的なプロトコルのチェックは、既存の状態とはるかに簡単です。例えば、多くのTCP / UDPフローは、1つのIPsec SAの上に確立された場合、再入力は、そのパラメータを検出するヒューリスティックを必要とする新しいSAを生成し、それらの経験則は、以前のIPsec SAに存在していた既存のTCP / UDPフローの恩恵を受ける。その場合には、それだけで十分で、新しいIPsecのSAは、いくつかの他のIPsec SA（リキーの前に、前のIPsec SA）のフローに属するパケットを持っている場合、それらのフローがすでにディープインスペクションエンジンによって知られている場合は、そのことを確認することです新しいSAが本当にESP-NULLであることを強く示唆を与えるだろう。
The worst case scenario is when an end node starts up communication, i.e., it does not have any previous flows through the device. Heuristics will run on the first few packets received from the end node. The later subsections mainly cover these start-up cases, as they are the most difficult.
最悪のシナリオは、エンド・ノードは、通信を開始するときである、すなわち、それはデバイスを介して、任意の以前のフローを有していません。ヒューリスティックは、エンド・ノードから受信した最初の数パケット上で実行されます。彼らが最も困難なよう以降のサブセクションでは、主に、これらのスタートアップのケースをカバーしています。
In the protocol checks, there are two different types of checks. The first check is for packet validity, i.e., certain locations must contain specific values. For example, an inner IPv4 header of an IPv4 tunnel packet must have its 4-bit version number set to 4. If it does not, the packet is not valid, and can be marked as a failure. Other positions depending on ICV and IV lengths must also be checked, and if all of them are failures, then the packet is a failure. If any of the checks are "unsure", the packet is marked as such.
プロトコルチェックでは、チェックの二つの異なるタイプがあります。最初のチェックは、すなわち、特定の位置が特定の値を含まなければならない、パケット妥当性のためのものです。そうでない場合、例えば、IPv4トンネルパケットの内側IPv4ヘッダが4に設定された4ビットのバージョン番号を持っている必要があり、パケットが有効でない、失敗としてマークすることができます。 ICVおよびIVの長さに応じて、他の位置も確認する必要があり、それらのすべてが失敗している場合、パケットは失敗です。チェックのいずれかが「わからない」の場合は、パケットはそのようにマークされます。
The second type of check is for variable, but easy-to-parse values. For example, the 4-bit header length field of an inner IPv4 packet. It has a fixed value (5) as long as there are no inner IPv4 options. If the header-length has that specific value, the number of known "good" bits increases. If it has some other value, the known "good" bit count stays the same. A local policy might include reaching a bit count that is over a threshold (for example, 96 bits), causing a packet to be marked as valid.
チェックの第二のタイプは、変数のためのものであるが、簡単に解析値。例えば、内側のIPv4パケットの4ビットのヘッダ長フィールド。それは限りない内側IPv4オプションが存在しないように固定値（5）を有しています。ヘッダ長は、その特定の値を有する場合、既知の「良好な」ビットの数が増加します。それは他のいくつかの値を持っている場合は、知られている「良い」のビット数は同じまま。ローカルポリシーは、パケットが有効としてマークさせる、閾値を超えるビット数（たとえば、96ビット）に達する含むかもしれません。
When the first TCP packet is fed to the heuristics, it is most likely going to be the SYN packet of the new connection; thus, it will have less useful information than other later packets might have. The best valid packet checks include checking that header length and flags have valid values and checking source and destination port numbers, which in some cases can be used for heuristics (but in general they cannot be reliably distinguished from random numbers apart from some well-known ports like 25/80/110/143).
最初のTCPパケットがヒューリスティックに供給されると、最も可能性の高い新しい接続のSYNパケットであることを行っています。このように、それは他の後にパケットが持っているかもしれないより少ない有用な情報を持っています。最高の有効なパケットのチェックは、そのヘッダ長をチェックし、フラグが有効な値を有し、いくつかのケースでは、ヒューリスティックのために使用することができるソースおよび宛先ポート番号を、チェックは、（一般的には、それらは別として、いくつかのよく知られた乱数から確実に区別することができません25/80/110/143のようなポート）。
The most obvious field, TCP checksum, might not be usable, as it is possible that the packet has already transited a NAT box that changed the IP addresses but assumed any ESP payload was encrypted and did not fix the transport checksums with the new IP addresses. Thus, the IP numbers used in the checksum are wrong; thus, the checksum is wrong. If the checksum is correct, it can again be used to increase the valid bit count, but verifying checksums is a costly operation, thus skipping that check might be best unless there is hardware to help the calculation. Window size, urgent pointer, sequence number, and acknowledgment numbers can be used, but there is not one specific known value for them.
パケットが既に暗号化され、新しいIPアドレスで輸送チェックサムを修正していないIPアドレスを変更NATボックスを通過したがいずれかのESPペイロードを想定している可能性があるとして、最も明白なフィールド、TCPチェックサムは、使用できなくなる場合があります。このように、チェックサムに使用されるIP番号が間違っています。このように、チェックサムが間違っています。チェックサムが正しければ、それは再び有効ビット数を増やすために使用されるが、チェックサムを検証することはコストのかかる作業であることができ、計算を支援するためのハードウェアがない限り、このようにそのチェックをスキップする最良のかもしれません。ウィンドウサイズ、緊急ポインタ、シーケンス番号、および確認応答番号を使用することができるが、そのための一つの特定の既知の値がありません。
One good method of detection is that if a packet is dropped, then the next packet will most likely be a retransmission of the previous packet. Thus, if two packets are received with the same source and destination port numbers, and where sequence numbers are either the same or right after each other, then it's likely a TCP packet has been correctly detected. This heuristic is most helpful when only one packet is outstanding. For example, if a TCP SYN packet is lost (or dropped because of policy), the next packet would always be a retransmission of the same TCP SYN packet.
検出の一つの良い方法は、パケットがドロップされた場合、次のパケットが最も可能性の高い前のパケットの再送信になるということです。 2つのパケットがシーケンス番号が同じまたは右互いの後のどちらかである同じ送信元と宛先ポート番号、およびで受信している場合はこのように、それはおそらくTCPパケットが正しく検出されています。このヒューリスティックは、一つのパケットのみが顕著である場合に最も便利です。たとえば、TCP SYNパケットが（理由ポリシーのまたは削除）が失われた場合、次のパケットは、常に同じTCP SYNパケットの再送信になります。
Existing deep-inspection engines usually do very good TCP flow checking already, including flow tracking, verification of sequence numbers, and reconstruction of the whole TCP flow. Similar methods can be used here, but they are implementation dependent and not described here.
既存のディープインスペクションエンジンは、通常、非常に良好なTCPフローが流れ追跡、シーケンス番号の検証、および全体のTCPフローの再構築を含め、すでにチェックを行います。同様の方法が、ここで使用することができますが、それらは実装に依存していないここに記載されています。
UDP header has even more problems than the TCP header, as UDP has even less known data. The checksum has the same problem as the TCP checksum, due to NATs. The UDP length field might not match the overall packet length, as the sender is allowed to include TFC (traffic flow confidentiality; see Section 2.7 of "IP Encapsulating Security Payload" [RFC4303]) padding.
UDPも少ないデータを知っているようにUDPヘッダは、TCPヘッダよりも多くの問題を有しています。チェックサムは、NATのによるTCPチェックサムと同じ問題を持っています。送信者がTFC含めることが許可されているとして、UDP長フィールドは、パケット全体の長さと一致しない場合があります（トラフィックフローの機密性を、「IPカプセル化セキュリティペイロード」[RFC4303]の2.7節参照）パディングを。
With UDP packets similar multiple packet methods can be used as with TCP, as UDP protocols usually include several packets using same port numbers going from one end node to another, thus receiving multiple packets having a known pair of UDP port numbers is good indication that the heuristics have passed.
UDPパケットと同様の複数のパケット方法がTCPと同様に使用することができ、UDPプロトコルは、通常、別のエンドノードから行く同じポート番号を使用していくつかのパケットを含むように、このようにUDPポート番号の既知の対を有する複数のパケットを受信すると、その優れた指標でありますヒューリスティックが経過しました。
Some UDP protocols also use identical source and destination port numbers; thus, that is also a good check.
いくつかのUDPプロトコルはまた、同一の送信元と宛先ポート番号を使用します。したがって、それはまた、良好なチェックです。
As ICMP messages are usually sent as return packets for other packets, they are not very common packets to get as first packets for the SA, the ICMP ECHO_REQUEST message being a noteworthy exception. ICMP ECHO_REQUEST has a known type, code, identifier, and sequence number. The checksum, however, might be incorrect again because of NATs.
ICMPメッセージは通常、他のパケットの戻りパケットとして送信されたように、彼らはSA、注目すべき例外であることICMP ECHO_REQUESTメッセージの最初のパケットとして取得するための非常に一般的なパケットではありません。 ICMP ECHO_REQUESTは、既知のタイプ、コード、識別子、およびシーケンス番号を有しています。チェックサムは、しかし、理由のNAT再び間違っている可能性があります。
For ICMP error messages, the ICMP message contains part of the original IP packet inside. Then, the same rules that are used to detect IPv4/IPv6 tunnel checks can be used.
ICMPエラーメッセージについては、ICMPメッセージは、内部の元のIPパケットの一部が含まれています。次に、のIPv4 / IPv6トンネルチェックを検出するために使用されるのと同じ規則を使用することができます。
SCTP [RFC4960] has a self-contained checksum, which is computed over the SCTP payload and is not affected by NATs unless the NAT is SCTP-aware. Even more than the TCP and UDP checksums, the SCTP checksum is expensive, and may be prohibitive even for deep packet inspections.
SCTP [RFC4960]はSCTPペイロードに対して計算され、NATは、SCTP対応でない限りのNATによって影響されない自己完結型のチェックサムを、有しています。 TCPとUDPチェックサムよりもさらに、SCTPチェックサムは高価であり、さらにディープ・パケット・インスペクションのために法外かもしれません。
SCTP chunks can be inspected to see if their lengths are consistent across the total length of the IP datagram, so long as TFC padding is not present.
SCTPチャンクは限りTFCパディングが存在しないように、それらの長さは、IPデータグラムの全長にわたって一貫しているかどうかを確認するために検査することができます。
In cases of tunneled traffic, the packet inside contains a full IPv4 or IPv6 packet. Many fields are usable. For IPv4, those fields include version, header length, total length (again TFC padding might confuse things there), protocol number, and 16-bit header checksum. In those cases, the intermediate device should give the decapsulated IP packet to the deep-inspection engine. IPv6 has fewer usable fields, but the version number, packet length (modulo TFC confusion), and next header all can be used by deep packet inspection.
トンネルトラフィックの例では、パケットは内部の完全なIPv4またはIPv6パケットが含まれています。多くの分野で利用可能です。 IPv4の場合、これらのフィールドは、バージョン、ヘッダ長、全長（再びTFCパディングが物事を混乱させる可能性がある）、プロトコル番号、および16ビットのヘッダのチェックサムを含みます。これらの例では、中間デバイスはディープインスペクションエンジンにデカプセル化したIPパケットを与える必要があります。 IPv6は、より少ない使用可能なフィールドを有するが、バージョン番号、パケット長（モジュロTFCの混乱）、および次のヘッダはすべて、ディープパケット検査で使用することができます。
If all traffic going through the intermediate device is either from or to certain address blocks (for example, either to or from the company intranet prefix), this can also be checked by the heuristics.
中間デバイスを通過するすべてのトラフィックがからか、特定のアドレスブロックに（例えば、いずれかまたは企業のイントラネットプレフィックスから）のいずれかであれば、これも経験則で確認できます。
Attackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. Ultimately, the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. That is, if a server allows encrypted connections also, then an attacker who wants to attack the server and wants to bypass a deep-inspection device in the middle, will use encrypted traffic. This means that the protection of the whole network is only as good as the policy enforcement and protection of the end node. One way to enforce deep inspection for all traffic, is to forbid encrypted ESP completely, in which case ESP-NULL detection is easier, as all packets must be ESP-NULL based on the policy (heuristics may still be needed to find out the IV and ICV lengths, unless further policy restrictions eliminate the ambiguities).
中間ノードの政策は、それは検査できませんパケットのドロップを必要としない限り、攻撃者は常に、代わりに暗号化されたESP（またはいくつかの他の暗号化やトンネリング方式）を使用して、ESP-NULLディープパケットインスペクションをバイパスすることができます。最終的には、深い検査を行う、または中間ノードが深い検査を実施することを可能にするための責任は、エンド・ノード上に置かなければなりません。サーバが暗号化された接続も、その後、サーバーを攻撃したいと真ん中に深い検査装置を迂回しようと、攻撃者は、暗号化されたトラフィックを使用することができますならばそれは、あります。これは、ネットワーク全体の保護のみエンドノードのポリシーの施行と保護と同様に良好であることを意味しています。すべてのトラフィックのための深い検査を施行するための一つの方法は、（ヒューリスティックはまだIVを見つけるために必要とされるすべてのパケットがポリシーに基づいてESP-NULLでなければならないとして、ESP-NULL検出が容易になり、その場合には、完全に暗号化されたESPを禁止することですさらに、ポリシー制限が曖昧さを排除しない限りICV）は、長さ。
Section 3 discusses failure modes of the heuristics. An attacker can poison flows, tricking inspectors into ignoring legitimate ESP-NULL flows, but that is no worse than injecting fuzz.
第3節では、ヒューリスティックの故障モードについて説明します。攻撃者は、毒の流れは、合法的なESP-NULLの流れを無視に検査官をだましことができますが、それはファズを注入することよりも悪いことではありません。
Forcing the use of ESP-NULL everywhere inside the enterprise, so that accounting, logging, network monitoring, and intrusion detection all work, increases the risk of sending confidential information where eavesdroppers can see it.
会計、ログ記録、ネットワーク監視、侵入検知、すべての作業は、盗聴者がそれを見ることができ、機密情報を送信するリスクを増大させるように、企業内のどこにでもESP-NULLの使用を強制。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムとIPsecでの使用"、RFC 2410、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[AUTH-ONLY-ESP] Hoffman, P. and D. McGrew, "An Authentication-only Profile for ESP with an IP Protocol Identifier", Work in Progress, August 2007.
[AUTH-ONLY-ESP]ホフマン、P.およびD.マグリュー、 "IPプロトコル識別子を持つESPの認証のみのプロフィール"、進歩、2007年8月に作業。
[ESP-NULL] Bhatia, M., "Identifying ESP-NULL Packets", Work in Progress, December 2008.
"ESP-NULLパケットの識別" [ESP-NULL]バティア、M.、進歩、2008年12月に作業。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]ヴァイス、B.、RFC 4359、2006年1月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）内のRSA / SHA-1署名の使用"。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility", RFC 5840, April 2010.
[RFC5840] Grewal、K.、モンテネグロ、G.、およびM. Bhatiaは、 "トラフィック可視性のためのカプセル化セキュリティペイロード（ESP）をラップ"、RFC 5840、2010年4月。
Appendix A. Example Pseudocode
付録A.例擬似コード
This appendix is meant for the implementors. It does not include all the required checks, and this is just example pseudocode, so final implementation can be very different. It mostly lists things that need to be done, but implementations can optimize steps depending on their other parts. For example, implementation might combine heuristics and deep inspection tightly together.
この付録では、実装のためのものです。これは、すべての必要なチェックが含まれていません、これは単なる例の擬似コードであるので、最終的な実装は非常に異なることがあります。これは、主に行われる必要がある事を示していますが、実装は彼らの他の部分に応じて、手順を最適化することができます。例えば、実装はしっかりと一緒に経験則と深い検査を組み合わせかもしれません。
A.1. Fastpath
A.1。ファーストパス
The following example pseudocode show the fastpath part of the packet processing engine. This part is usually implemented in hardware.
次の例の擬似コードは、パケット処理エンジンのファストパス部分を示します。この部分は通常、ハードウェアに実装されています。
//////////////////////////////////////////////////////////// // This pseudocode uses following variables: // // SPI_offset: Number of bytes between start of protocol // data and SPI. This is 0 for ESP and // 8 for UDP-encapsulated ESP (i.e, skipping // UDP header). // // IV_len: Length of the IV of the ESP-NULL packet. // // ICV_len: Length of the ICV of the ESP-NULL packet. // // State: State of the packet, i.e., ESP-NULL, ESP, or // unsure. // // Also following data is taken from the packet: // // IP_total_len: Total IP packet length. // IP_hdr_len: Header length of IP packet in bytes. // IP_Src_IP: Source address of IP packet. // IP_Dst_IP: Destination address of IP packet. // // UDP_len: Length of the UDP packet taken from UDP header. // UDP_src_port: Source port of UDP packet. // UDP_dst_port: Destination port of UDP packet. // // SPI: SPI number from ESP packet. // // Protocol: Actual protocol number of the protocol inside // ESP-NULL packet. // Protocol_off: Calculated offset to the protocol payload data // inside ESP-NULL packet.
////////////////////////////////////////////////// // // SPI_offset：プロトコル//データおよびSPIの開始との間のバイト数////////// //この擬似コードは、次の変数を使用しています。これは、ESPの場合は0、UDPカプセル化ESP用// 8（すなわち、スキップ// UDPヘッダ）です。 // // IV_len：ESP-NULLパケットのIVの長さ。 // // ICV_len：ESP-NULLパケットのICVの長さ。 // //状態：パケットの状態、すなわち、ESP-NULL、ESP、または//わかりません。 // //また、以下のデータがパケットから取得されます：// // IP_total_len：合計IPパケット長を。 // IP_hdr_len：バイト単位でのIPパケットのヘッダ長。 // IP_Src_IP：IPパケットの送信元アドレス。 // IP_Dst_IP：IPパケットの宛先アドレス。 // // UDP_len：UDPヘッダから取られたUDPパケットの長さ。 // UDP_src_port：UDPパケットの送信元ポート。 // UDP_dst_port：UDPパケットの宛先ポート。 // // SPI：ESPパケットからSPI番号。 // //プロトコル：// ESP-NULLパケット内のプロトコルの実際のプロトコル番号。 // Protocol_off：ESP-NULLパケット内の//プロトコルペイロードデータにオフセットを計算。
//////////////////////////////////////////////////////////// // This is the main processing code for the packet // This will check if the packet requires ESP processing, // Process packet: * If IP protocol is ESP * Set SPI_offset to 0 bytes * Goto Process ESP * If IP protocol is UDP * Goto Process UDP * If IP protocol is WESP // For information about WESP processing, see WESP // specification. * Continue WESP processing * Continue Non-ESP processing
////////////////////////////////////////////////// //////////は//これは//、パケットはESP処理を必要とする場合、パケットのための主要な処理コードが//これがチェックするあるプロセスパケット：* IPプロトコルが0バイトにESP *設定SPI_offsetある場合*後藤プロセスESP * IPプロトコルは、IPプロトコルがWESP処理の詳細についてはWESP //であれば、WESP //仕様を参照してくださいUDP *後藤プロセスUDP *である場合。 * WESP処理を続行*続行を非ESP処理
//////////////////////////////////////////////////////////// // This code is run for UDP packets, and it checks if the // packet is UDP encapsulated UDP packet, or UDP // encapsulated IKE packet, or keepalive packet. // Process UDP: // Reassembly is not mandatory here, we could // do reassembly also only after detecting the // packet being UDP encapsulated ESP packet, but // that would complicate the pseudocode here // a lot, as then we would need to add code // for checking whether or not the UDP header is in this // packet. // Reassembly is to simplify things * If packet is fragment * Do full reassembly before processing * If UDP_src_port != 4500 and UDP_dst_port != 4500 * Continue Non-ESP processing * Set SPI_offset to 8 bytes * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000 * Continue Non-ESP processing (pass IKE-packet) * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000002 * Continue WESP processing * If UDP_len == 1 and first byte is 0xff * Continue Non-ESP processing (pass NAT-Keepalive Packet) * Goto Process ESP
////////////////////////////////////////////////// //////////は//このコードは、UDPパケットのために実行され、//パケットがUDPはUDPパケットをカプセル化し、またはUDP //は、IKEパケット、またはキープアライブパケットをカプセル化しているかどうかはチェックします。 //プロセスUDP：//再組み立てはここに必須ではありませんが、我々は再構築はまた、唯一//パケットがUDPであることを検出した後、ここで擬似コードが複雑になる我々は、その後、多くのことを//その// ESPパケットをカプセル化しますが、//んでしたUDPヘッダは、この//パケットであるか否かをチェックするためのコード//を追加する必要があります。 //再組み立ては、パケットがフラグメントである場合* *物事を単純化処理する前に、完全な再構築を行うことです* UDP_src_port！= 4500とUDP_dst_port！= 4500 *続行を非ESP処理が8バイトにSPI_offsetを設定します*場合* UDP_len> 4と第1の4バイトの場合UDPパケットのUDP_len> 4と最初の4バイトが0x000002である場合UDP_len == 1と最初のバイトが0xFFである場合にUDPパケットの0×000000 *は非ESP処理を続行している* WESP処理を続行*（IKEパケットを通過させる）*非続行ESP処理（NAT-キープアライブパケットを通過させる）*後藤プロセスESP
//////////////////////////////////////////////////////////// // This code is run for ESP packets (or UDP-encapsulated ESP // packets). This checks if IPsec flow is known, and // if not calls heuristics. If the IPsec flow is known // then it continues processing based on the policy. // Process ESP: * If packet is fragment * Do full reassembly before processing * If IP_total_len < IP_hdr_len + SPI_offset + 4 // If this packet was UDP encapsulated ESP packet then // this might be valid UDP packet that might // be passed or dropped depending on policy. * Continue normal packet processing * Load SPI from IP_hdr_len + SPI_offset * Initialize State to ESP // In case this was UDP encapsulated ESP, use UDP_src_port and // UDP_dst_port also when finding data from SPI cache. * Find IP_Src_IP + IP_Dst_IP + SPI from SPI cache * If SPI found * Load State, IV_len, ICV_len from cache * If SPI not found or State is unsure * Call Autodetect ESP parameters (drop to slowpath) * If State is ESP * Continue Non-ESP-NULL processing * Goto Check ESP-NULL packet
////////////////////////////////////////////////// //////////は//このコードは、ESPパケット（またはUDPカプセル化ESP //パケット）のために実行されます。 IPsecの流れがわかっている場合、および//ヒューリスティックを呼び出していない場合、これはチェックします。 IPsecの流れが//知られている場合、それはポリシーに基づいて処理を続行します。 //プロセスESP：パケットがフラグメントである場合、このパケットはUDPがESPパケットをカプセル化した場合IP_total_len <IP_hdr_len + SPI_offset + 4 //その後、//これは//渡されるかもしれない有効なUDPパケットである可能性がある場合* * *処理する前に、完全な再構築を実行します。またはポリシーに応じて低下しました。 *場合、//これをESPするIP_hdr_len + SPI_offset *初期状態から通常のパケット処理*ロードSPIを続行UDPは、SPIキャッシュからデータを求める際にもUDP_src_portと// UDP_dst_portを使用し、ESPを封入しました。 *検索IP_Src_IP + IP_Dst_IP + SPI SPIが見つかった場合はSPIキャッシュ*から*負荷状態、SPIが見つからないか、または国家でない場合はキャッシュ*からIV_len、ICV_lenはわからないです*コール自動検出ESPパラメータ（低速パスにドロップ）*国はESPの場合は*非を続行-ESP-NULL処理*後藤はESP-NULLパケットをチェック
//////////////////////////////////////////////////////////// // This code is run for ESP-NULL packets, and this // finds out the data required for deep-inspection // engine (protocol number, and offset to data) // and calls the deep-inspection engine. // Check ESP-NULL packet: * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) // This packet was detected earlier as being part of // ESP-NULL flow, so this means that either ESP-NULL // was replaced with other flow or this is an invalid packet. // Either drop or pass the packet, or restart // heuristics based on the policy * Continue packet processing * Load Protocol from IP_total_len - ICV_len - 1 * Set Protocol_off to IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no) * Do normal deep inspection on packet.
////////////////////////////////////////////////// //////////は//このコードは、ESP-NULLパケットに対して実行され、この//はディープインスペクション//エンジンに必要なデータを見つけ出し（プロトコル番号、およびデータへのオフセット）//とディープインスペクションエンジンを呼び出します。 // ESP-NULLパケットをチェックしてください：* IP_total_len <IP_hdr_len + SPI_offset + IV_len + ICV_len + 4（SPI）+ 4（配列なし）+ 4（プロトコル+パディング）//このパケットはの一部であると以前に検出された場合は// ESP-NULLの流れは、これはESP-NULL //いずれかが他のフローと交換したか、これは無効パケットであることを意味しています。 IP_hdr_len + SPI_offset + IV_len + 4（SPI）+ 4（配列なしに1 *セットProtocol_off - //ドロップまたは*パケットの処理を続行し、パケットを通過させる、または//ポリシーに基づいて、ヒューリスティックを再起動* IP_total_lenから負荷プロトコルのいずれか - ICV_len ）*パケットに通常の深い検査を行います。
Figure 3
図3
A.2. Slowpath
A.2。低速パス
The following example pseudocode shows the actual heuristics part of the packet processing engine. This part is usually implemented in software.
次の例の擬似コードは、パケット処理エンジンの実際のヒューリスティックの一部を示しています。この部分は、通常、ソフトウェアで実装されています。
//////////////////////////////////////////////////////////// // This pseudocode uses following variables: // // SPI_offset, IV_len, ICV_len, State, SPI, // IP_total_len, IP_hdr_len, IP_Src_IP, IP_Dst_IP // as defined in fastpath pseudocode. // // Stored_Check_Bits:Number of bits we have successfully // checked to contain acceptable values // in the actual payload data. This value // is stored/retrieved from SPI cache. // // Check_Bits: Number of bits we have successfully // checked to contain acceptable values // in the actual payload data. This value // is updated during the packet // verification. // // Last_Packet_Data: Contains selected pieces from the // last packet. This is used to compare // certain fields of this packet to // same fields in previous packet. // // Packet_Data: Selected pieces of this packet, same // fields as Last_Packet_Data, and this // is stored as new Last_Packet_Data to // SPI cache after this packet is processed. // // Test_ICV_len: Temporary ICV length used during tests. // This is stored to ICV_len when // padding checks for the packet succeed // and the packet didn't yet have unsure // status. // // Test_IV_len: Temporary IV length used during tests. // // Pad_len: Padding length from the ESP packet. //
////////////////////////////////////////////////// //////////は//この擬似コードは、次の変数を使用しています：// // SPI_offset、IV_len、ICV_len、国家、SPI、// IP_total_len、IP_hdr_len、IP_Src_IP、IP_Dst_IP //ファストパス擬似コードで定義されています。 // // Stored_Check_Bits：我々は成功し// //実際のペイロードデータにおける許容値を含むようにチェックしたビット数。この値は、// SPIキャッシュから取得/保存されています。 // // Check_Bits：我々は成功し// //実際のペイロードデータにおける許容値を含むようにチェックしたビット数。この値は、//パケット//検証中に更新されます。 // // Last_Packet_Dataは：//最後のパケットから選択された部分が含まれています。これは、以前のパケット内の同じフィールドを//する。//このパケットの特定のフィールドを比較するために使用されます。 // // Packet_Data：選択されたこのパケットの作品、Last_Packet_Dataと同じ//フィールド、およびこれ//は、このパケットが処理された後にSPIキャッシュを//新しいLast_Packet_Dataとして格納されています。 // // Test_ICV_len：テスト中に使用される一時ICVの長さ。 //これは、パケットのための//パディングチェックが//成功すると、パケットはまだわからない//ステータスを持っていなかったときICV_lenに保存されています。 // // Test_IV_len：テスト時に使用される一時的なIV長。 // // Pad_len：ESPパケットからパディング長。 //
// Protocol: Protocol number of the packet inside ESP // packet. // // TCP.*: Fields from TCP header (from inside ESP) // UDP.*: Fields from UDP header (from inside ESP)
//プロトコル：ESP //パケット内のパケットのプロトコル番号。 // // TCP *：TCPヘッダからのフィールド（ESP内側から）// UDP *：UDPヘッダからのフィールド（ESP内側から）
//////////////////////////////////////////////////////////// // This code starts the actual heuristics. // During this the fastpath has already loaded // State, ICV_len, and IV_len in case they were // found from the SPI cache (i.e., in case the flow // had unsure status). // Autodetect ESP parameters: // First, we check if this is unsure flow, and // if so, we check next packet against the // already set IV/ICV_len combination. * If State is unsure * Call Verify next packet * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info * If State is unsure * Goto Verify unsure // If we failed the test, i.e., State // was changed to ESP, we check other // ICV/IV_len values, i.e., fall through // ICV lengths are tested in order of ICV lengths, // from shortest to longest. * Call Try standard algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info * Call Try 128bit algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info * Call Try 192bit algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info * Call Try 256bit algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from // this document. // If any of those test above set state to unsure // we mark IPsec flow as unsure. * If State is unsure * Goto Store unsure SPI cache info
////////////////////////////////////////////////// //////////は//このコードは、実際の経験則を開始します。 //ファーストパスがすでにロードされているこの時に、//州、彼らは// SPIキャッシュから発見された場合にはICV_len、およびIV_len（すなわち、場合の流れは//わからない状態でした）。 //自動検出ESPパラメータ：そうならば//はまず、我々はこれがわからない流れであるかどうかをチェックし、//、我々は//すでに設定IV / ICV_lenの組み合わせに対して、次のパケットを確認してください。我々はテストに失敗した場合*状態がわからない場合には国がESP-NULL *後藤ストアESP-NULL SPIキャッシュ情報である場合*国が不確かである場合*後藤がわからないことを確認し*次のパケット*を確認して呼び出し//、すなわち、国家//変更しました最短最長からESPに、我々は//、ICVは、長さの順にテストされ、// ICVの長さから落下、すなわち他// ICV / IV_len値を、確認してください。 *コール標準的なアルゴリズムは、国家がESP-NULL *後藤ストアESP-NULL SPIキャッシュ情報である場合*お試しコール128ビットのアルゴリズムは国家がESP-NULL *後藤ストアESP-NULL SPIキャッシュ情報である場合には州立場合*お試しコール192bitアルゴリズムは* * *お試しくださいESP-NULL *後藤ストアESP-NULL SPIキャッシュ情報がある*国がAUTH_DES_MACとAUTH_KPDK_MD5は、この文書//から取り残されESP-NULL *後藤ストアESP-NULL SPIキャッシュ情報//であれば256ビットのアルゴリズムは*お試しください呼び出します。 //テストセット状態上記のもののいずれか場合は、我々がわからないようにIPsecの流れをマーク//不明な点がします。 *状態がわからない場合には*後藤ストアわからないSPIのキャッシュ情報
// All of the test failed, meaning the packet cannot // be ESP-NULL packet, thus we mark IPsec flow as ESP * Goto Store ESP SPI cache info //////////////////////////////////////////////////////////// // Store ESP-NULL status to the IPsec flow cache. // Store ESP-NULL SPI cache info: * Store State, IV_len, ICV_len to SPI cache using IP_Src_IP + IP_Dst_IP + SPI as key * Continue Check ESP-NULL packet
テストの//すべて失敗し、パケットを意味する//このように、我々はESP *後藤ストアESP SPIキャッシュ情報としてのIPsecの流れをマークし、ESP-NULLパケットにはできません//////////////// //////////////////////////////////////////// //ストアESP-NULL IPsecのフローキャッシュの状態。 //ストアESP-NULL SPIキャッシュ情報：*ストア州、IV_len、ICV_len SPIキャッシュへのキーとしてIP_Src_IP + IP_Dst_IP + SPIを使用して* ESP-NULLパケットをチェックし続けます
//////////////////////////////////////////////////////////// // Store encrypted ESP status to the IPsec flow cache. // Store ESP SPI cache info: * Store State, IV_len, ICV_len to SPI cache using IP_Src_IP + IP_Dst_IP + SPI as key * Continue Check non-ESP-NULL packet
////////////////////////////////////////////////// ////////// //ストアは、IPsecフローキャッシュにESPの状態を暗号化。 //ストアESP SPIキャッシュ情報：*ストア州、IV_len、ICV_lenキーとしてIP_Src_IP + IP_Dst_IP + SPIを使用してSPIキャッシュへ*非ESP-NULLパケットをチェックし続けます
//////////////////////////////////////////////////////////// // Store unsure flow status to IPsec flow cache. // Here we also store the Check_Bits. // Store unsure SPI cache info: * Store State, IV_len, ICV_len, Stored_Check_Bits to SPI cache using IP_Src_IP + IP_Dst_IP + SPI as key * Continue Check unknown packet
////////////////////////////////////////////////// IPsecのフローキャッシュに////////// //ストアわからないフローの状況。 //ここで我々はまた、Check_Bitsを格納します。 //ストアわからないSPIキャッシュ情報：*ストア州、IV_len、ICV_len、キーとしてIP_Src_IP + IP_Dst_IP + SPIを使用してSPIキャッシュへのStored_Check_Bits *続行未知のパケットをチェック
//////////////////////////////////////////////////////////// // Verify this packet against the previously selected // ICV_len and IV_len values. This will either // fail (and set state to ESP to mark we do not yet // know what type of flow this is) or will // increment Check_Bits. // Verify next packet: // We already have IV_len, ICV_len, and State loaded * Load Stored_Check_Bits, Last_Packet_Data from SPI Cache * Set Test_ICV_len to ICV_len, Test_IV_len to IV_len * Initialize Check_Bits to 0 * Call Verify padding * If verify padding returned Failure // Initial guess was wrong, restart * Set State to ESP * Clear IV_len, ICV_len, State, Stored_Check_Bits, Last_Packet_Data from SPI Cache
////////////////////////////////////////////////// //////////は//以前に選択// ICV_lenとIV_len値に対してこのパケットを確認してください。これは失敗（と私たちはまだ//これはフローのどのタイプか分からないマークするESPに状態を設定）または増分Check_Bitsを//ますするか//。 //次のパケットを確認してください：//我々はすでにIV_len、ICV_lenを持っており、国家ロード*ロードStored_Check_Bitsは、SPIキャッシュ*設定Test_ICV_lenからICV_len、IV_lenにTest_IV_lenにLast_Packet_Data *が0にCheck_Bitsを初期化* *パディングを確認して呼び出しを検証した場合、パディングは失敗を返さ//最初の推測が間違っていた、SPIキャッシュからESP *クリアIV_len、ICV_len、国家、Stored_Check_Bits、Last_Packet_Dataに*設定された状態を再起動します
* Return // Ok, padding check succeeded again * Call Verify packet * If verify packet returned Failure // Guess was wrong, restart * Set State to ESP * Clear IV_len, ICV_len, State, Stored_Check_Bits, Last_Packet_Data from SPI Cache * Return // It succeeded and updated Check_Bits and Last_Packet_Data store // them to SPI cache. * Increment Stored_Check_Bits by Check_Bits * Store Stored_Check_Bits to SPI Cache * Store Packet_Data as Last_Packet_Data to SPI cache * Return
パケットを確認した場合*戻り// [OK]を、パディングチェックが再び成功しました*パケット*を確認して呼び出し返さ失敗//推測が間違っていた、再起動してください*設定された状態にESP *クリアIV_len、ICV_len、国家、Stored_Check_Bits、SPIキャッシュ*リターンからLast_Packet_Data //それは成功したとSPIキャッシュにCheck_BitsとLast_Packet_Dataストア//それらを更新しました。 * Check_BitsによってインクリメントStored_Check_Bits * Last_Packet_DataとしてSPIキャッシュ・リターンにSPIキャッシュ・ストアPacket_Dataに店舗Stored_Check_Bits
//////////////////////////////////////////////////////////// // This will check if we have already seen enough bits // acceptable from the payload data, so we can decide // that this IPsec flow is ESP-NULL flow. // Verify unsure: // Check if we have enough check bits. * If Stored_Check_Bits > configured limit // We have checked enough bits, return ESP-NULL * Set State ESP-NULL * Goto Store ESP-NULL SPI cache info // Not yet enough bits, continue * Continue Check unknown packet
//////////////////////////////////////////////////我々はすでに、ペイロードデータから許容//十分なビットを見ている場合//////////は//これはチェックしますので、我々は、このIPsecのフローはESP-NULL流れであることを//決定することができます。 //不明な点を確認してください：我々は十分なチェックビットを持っている場合は//で確認してください。 *もしStored_Check_Bits>設定された制限//我々は十分なビットをチェックして、ESP-NULL *設定された状態ESP-NULL *後藤ストアESP-NULL SPIキャッシュ情報//まだ十分なビットを返し、継続*未知のパケットをチェックし続けます
//////////////////////////////////////////////////////////// // Check for standard 96-bit algorithms. // Try standard algorithms: // AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, // AUTH_AES_CMAC_96 * Set Test_ICV_len to 12, Test_IV_len to 0 * Goto Check packet
////////////////////////////////////////////////// //////////は、//標準の96ビットのアルゴリズムを確認してください。標準的なアルゴリズムを試してみてください//：// AUTH_HMAC_MD5_96、AUTH_HMAC_SHA1_96、AUTH_AES_XCBC_96、// AUTH_AES_CMAC_96 *設定Test_ICV_lenを12に、Test_IV_lenを0に*後藤チェックパケット
//////////////////////////////////////////////////////////// // Check for 128-bit algorithms, this is only one that // can have IV, so we need to check different IV_len values // here too. // Try 128bit algorithms: // AUTH_HMAC_SHA2_256_128, ENCR_NULL_AUTH_AES_GMAC * Set Test_ICV_len to 16, Test_IV_len to 0
////////////////////////////////////////////////// //////////は// 128ビットのアルゴリズムをチェックし、これは//がIVを持つことができる唯一のものですので、私たちはここにも//異なるIV_len値をチェックする必要があります。 0にTest_IV_len、16に// AUTH_HMAC_SHA2_256_128、ENCR_NULL_AUTH_AES_GMAC *セットTest_ICV_len：// 128ビットのアルゴリズムを試してみてください
* If IP_total_len < IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) * Return * Call Verify padding * If verify padding returned Failure * Return * Initialize Check_Bits to 0 * Call Verify packet * If verify packet returned Failure * Goto Try GMAC // Ok, packet seemed ok, but go now and check if we have enough // data bits so we can assume it is ESP-NULL * Goto Check if done for unsure
* IP_total_len <IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4（SPI）+ 4（配列なし）+ 4（プロトコル+パディング）パディングを確認する場合*戻る*コール*パディングを確認し、0 *コールに失敗*戻る*初期化Check_Bitsを返された場合パケットを確認した場合はパケット*を確認してください*後藤は、GMACを試してみてください// [OK]を、パケットはOKに見えたが、今行くと我々はそれを取ることができるように、我々は十分な//データビットを持っているかどうかを確認することはわからないために行われていればESP-NULL *後藤が確認され失敗を返さ
//////////////////////////////////////////////////////////// // Check for GMAC MACs, i.e., MACs that have an 8-byte IV. // Try GMAC: // ENCR_NULL_AUTH_AES_GMAC * Set Test_IV_len to 8 * If IP_total_len < IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) * Return * Initialize Check_Bits to 0 * Call Verify packet * If verify packet returned Failure // Guess was wrong, continue * Return // Ok, packet seemed ok, but go now and check if we have enough // data bits so we can assume it is ESP-NULL * Goto Check if done for unsure
////////////////////////////////////////////////// //////////は//、すなわち、GMAC Mac用の8バイトのIVを持つMACを確認してください。 // GMACをお試しください：// ENCR_NULL_AUTH_AES_GMAC *設定Test_IV_lenに8 * IP_total_len <IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4（SPI）+ 4（配列なし）+ 4（プロトコル+パディング）*戻る* 0にCheck_Bitsを初期化した場合*パケットを確認した場合はパケット*を確認して呼び出し失敗//推測が間違っていた、継続*リターン// [OK]を、パケットはOKに見えたが、今行くと私たちは私たちがそれを取ることができる十分な//データビットを持っているかどうかを確認されESP-NULL *後藤を返さわからないために行わないか確認してください
//////////////////////////////////////////////////////////// // Check for 192-bit algorithms. // Try 192bit algorithms: // AUTH_HMAC_SHA2_384_192 * Set Test_ICV_len to 24, Test_IV_len to 0 * Goto Check packet
////////////////////////////////////////////////// //////////は// 192ビットのアルゴリズムを確認してください。 // 192bitアルゴリズムを試してみてください：// AUTH_HMAC_SHA2_384_192 *設定Test_ICV_len 24に、Test_IV_len * 0に後藤チェックパケット
//////////////////////////////////////////////////////////// // Check for 256-bit algorithms. // Try 256bit algorithms: // AUTH_HMAC_SHA2_512_256 * Set Test_ICV_len to 32, Test_IV_len to 0
////////////////////////////////////////////////// //////////は// 256ビットのアルゴリズムを確認してください。 0にTest_IV_len、32に// AUTH_HMAC_SHA2_512_256 *セットTest_ICV_len：// 256ビットのアルゴリズムを試してみてください
* Goto Check packet
*後藤チェックパケット
//////////////////////////////////////////////////////////// // This actually does the checking for the packet, by // first verifying the length, and then self describing // padding, and if that succeeds, then checks the actual // payload content. // Check packet: * If IP_total_len < IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) * Return * Call Verify padding * If verify padding returned Failure * Return * Initialize Check_Bits to 0 * Call Verify packet * If verify packet returned Failure // Guess was wrong, continue * Return // Ok, packet seemed ok, but go now and check if we have enough // data bits so we can assume it is ESP-NULL * Goto Check if done for unsure
////////////////////////////////////////////////// //////////は//これは、実際に第1の長さを確認し、その後自己パディングを//記述//により、パケットのチェックを行い、それが成功した場合、実際の//ペイロードの内容を確認します。 //パケットチェック：IP_total_len <IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4（SPI）+ 4（配列なし）+ 4（プロトコル+パディング）*戻る*コールは、パディングを確認した場合は*を*の場合は、パディングを確認*戻る*初期化の失敗を返さパケットを確認した場合は0にCheck_Bits *パケット*を確認して呼び出し返さ失敗//推測は間違っていた、継続*リターン// [OK]を、パケットは大丈夫に見えたが、それはESPであるので、我々が想定することができ、今行くと、私たちは十分な//データビットを持っているかどうかを確認-NULL *後藤チェックが不明のために行われていれば
//////////////////////////////////////////////////////////// // This code checks if we have seen enough acceptable // values in the payload data, so we can decide that this // IPsec flow is ESP-NULL flow. // Check if done for unsure: * If Stored_Check_Bits > configured limit // We have checked enough bits, return ESP-NULL * Set State ESP-NULL * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len * Clear Stored_Check_Bits, Last_Packet_Data from SPI Cache * Return // Not yet enough bits, check if this is first unsure, if so // store information. In case there are multiple // tests succeeding, we always assume the first one // (the one using shortest MAC) is the one we want to // check in the future. * If State is not unsure * Set State unsure
//////////////////////////////////////////////////私たちは、ペイロードデータに十分に許容//値を見てきましたので、私たちは、この// IPsecのフローはESP-NULLの流れであると判断できる場合////////// //このコードをチェックします。 //わからないために行わないか確認してください：* Stored_Check_Bits>設定した場合の限界//我々は十分なビットをチェックして、SPIキャッシュからTest_ICV_len *クリアStored_Check_Bits、Last_Packet_DataにTest_IV_len、ICV_lenにESP-NULL *設定された状態ESP-NULL *セットIV_lenを返します* //まだ十分なビットを返しますので、//店舗情報ならば、これは、最初に不確かであるかどうかを確認します。場合は、後続//複数のテストがあり、我々は常に最初の1 //（最短MACを使用して1）を想定我々は将来的にチェック//したいものです。 *状態はわからない*設定された状態が不明ではない場合
// These values will be stored to SPI cache if // the final state will be unsure * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len * Set Stored_Check_Bits as Check_Bits * Return
//最終状態は分からないだろう場合は、//これらの値はCheck_Bits *戻り値としてTest_ICV_len *設定Stored_Check_BitsにTest_IV_len、ICV_lenに設定IV_len * SPIキャッシュに保存されます
//////////////////////////////////////////////////////////// // Verify self describing padding // Verify padding: * Load Pad_len from IP_total_len - Test_ICV_len - 2 * Verify padding bytes at IP_total_len - Test_ICV_len - 1 - Pad_len .. IP_total_len - Test_ICV_len - 2 are 1, 2, ..., Pad_len * If Verify of padding bytes succeeded * Return Success * Return Failure
////////////////////////////////////////////////// ////////// // //パディングはパディングを確認記述自己確認：* IP_total_lenからロードPad_len - Test_ICV_len - 2 * IP_total_lenにパディングバイトを確認 - Test_ICV_len - 1 - Pad_len .. IP_total_len - Test_ICV_len - 2であります1、2、...、Pad_len *パディングバイトを確認に成功した場合*戻り値成功*リターン失敗
//////////////////////////////////////////////////////////// // This will verify the actual protocol content inside ESP // packet. // Verify packet: // We need to first check things that cannot be set, i.e., if any of // those are incorrect, then we return Failure. For any / fields that might be correct, we increment the Check_Bits // for a suitable amount of bits. If all checks pass, then // we just return Success, and the upper layer will then // later check if we have enough bits checked already. * Load Protocol From IP_total_len - Test_ICV_len - 1 * If Protocol TCP * Goto Verify TCP * If Protocol UDP * Goto Verify UDP // Other protocols can be added here as needed, most likely same // protocols as deep inspection does. // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for // IPv6) is also left out from here to make the document shorter. * Return Failure
////////////////////////////////////////////////// //////////は//これはESP //パケット内の実際のプロトコルの内容を検証します。 //はパケットを確認してください：//私たちは、//これらのいずれかが正しくない場合、その後、私たちは失敗を返す、最初すなわち設定することができないものを、確認する必要があります。正しいかもしれない任意の/フィールドのために、我々はビットの適切な量のために// Check_Bitsをインクリメントします。すべてのチェックに合格したら、//私たちは成功を返し、我々は十分なビットが既に確認されている場合は、上位層は、//後でチェックします。 IP_total_lenから*ロードプロトコル - Test_ICV_len - 1 *プロトコルTCPの場合*後藤深い検査を行うようプロトコルUDP *後藤はUDP //必要に応じて他のプロトコルは、ここで追加することができ、最も可能性が高い。//同じプロトコルを確認した場合* TCPを確認してください。 //トンネルモードの確認（IPv4のプロトコル4と// IPv6のプロトコル41）も文書を短くするためにここから取り残されています。 *リターンの失敗
//////////////////////////////////////////////////////////// // Verify TCP protocol headers // Verify TCP: // First we check things that must be set correctly. * If TCP.Data_Offset field < 5 // TCP head length too small
////////////////////////////////////////////////// //////////は// // TCPプロトコルヘッダを確認してくださいTCPを確認してください：//まず、正しく設定する必要があります事をご確認ください。 * TCP.Data_Offsetフィールド<5 // TCPヘッドの長さが小さすぎる場合は
* Return Failure // After that, we start to check things that do not // have one definitive value, but can have multiple possible // valid values. * If TCP.ACK bit is not set, then check that TCP.Acknowledgment_number field contains 0 // If the ACK bit is not set, then the acknowledgment // field usually contains 0, but I do not think // RFCs mandate it being zero, so we cannot make // this a failure if it is not so. * Increment Check_Bits by 32 * If TCP.URG bit is not set, then check that TCP.Urgent_Pointer field contains 0 // If the URG bit is not set, then urgent pointer // field usually contains 0, but I do not think // RFCs mandate it being zero, so we cannot make // this failure if it is not so. * Increment Check_Bits by 16 * If TCP.Data_Offset field == 5 * Increment Check_Bits by 4 * If TCP.Data_Offset field > 5 * If TCP options format is valid and it is padded correctly * Increment Check_Bits accordingly * If TCP options format was garbage * Return Failure * If TCP.checksum is correct // This might be wrong because packet passed NAT, so // we cannot make this failure case. * Increment Check_Bits by 16 // We can also do normal deeper TCP inspection here, i.e., // check that the SYN/ACK/FIN/RST bits are correct and state // matches the state of existing flow if this is packet // to existing flow, etc. // If there is anything clearly wrong in the packet (i.e., // some data is set to something that it cannot be), then // this can return Failure; otherwise, it should just // increment Check_Bits matching the number of bits checked. // // We can also check things here compared to the last packet * If Last_Packet_Data.TCP.source port = Packet_Data.TCP.source_port and Last_Packet_Data.TCP.destination port = Packet_Data.TCP.destination port * Increment Check_Bits by 32 * If Last_Packet_Data.TCP.Acknowledgement_number = Packet_Data.TCP.Acknowledgement_number * Increment Check_Bits by 32 * If Last_Packet_Data.TCP.sequence_number =
*戻り失敗//その後、我々は// 1つの決定的な価値を持っていない事を確認するために開始しますが、複数の有効な//可能な値を持つことができます。 * TCP.ACKビットがセットされていない場合は、TCP.Acknowledgment_numberフィールドはACKビットがセットされていない場合は0が、その後、承認//フィールドは通常0含ま//含まれていることを確認し、私は// RFCは、それがされて強制とは思いませんゼロそれはそうではない場合、私たちは、//この失敗することはできません。 * TCP.URGビットがセットされていない場合は32によってインクリメントCheck_Bitsは*、その後、TCP.Urgent_PointerフィールドはURGビットがセットされていない場合は0が、その後、緊急ポインタ//フィールドは、通常、0含ま//含まれていることを確認し、私は考えていません/ / RFCの任務は、それがゼロであるので、それはそうではない場合、我々は//この失敗をすることはできません。 * 16 *もしTCP.Data_OffsetフィールドによってインクリメントCheck_Bits == 5 *インクリメントCheck_Bitsで4 *もしTCP.Data_Offsetフィールド> 5 * TCPオプションの形式が有効であり、それは*インクリメントCheck_Bits応じ* TCPオプションの形式であった場合ゴミ正しくパディングされた場合*戻り失敗* TCP.checksumが正しい場合、パケットがNATを通過したので、//これは間違っているかもしれないので、//我々はこの障害のケースを作ることができません。 *インクリメントCheck_Bitsは16で我々はまた、ここでは、通常より深いTCP検査を行うことができます//、すなわち、// SYN / ACK / FIN / RSTビットが正しく、これはパケット//であれば状態//は既存のフローの状態と一致していることを確認してください既存の流れなどを明らかに何か問題がパケット内に存在する場合（つまり、//いくつかのデータが、それはすることはできません何かに設定されている）//、その後、//これは失敗を返すことができます。そうでない場合は、それだけで//インクリメントCheck_Bitsにチェックビット数に一致する必要があります。 Last_Packet_Data.TCP.sourceポートは= Packet_Data.TCP.source_portとLast_Packet_Data.TCP.destinationポート= Packet_Data.TCP.destinationポート場合// //我々はまた、インクリメントCheck_Bitsは場合は32 *で* *最後のパケットに比べて、ここで物事を確認することができます32 *によるLast_Packet_Data.TCP.Acknowledgement_number = Packet_Data.TCP.Acknowledgement_number *インクリメントCheck_Bits Last_Packet_Data.TCP.sequence_number IF =
Packet_Data.TCP.sequence_number * Increment Check_Bits by 32 // We can do other similar checks here * Return Success
私たちはここに他の同様のチェックを行うことができます32 //によってPacket_Data.TCP.sequence_number *インクリメントCheck_Bits *戻り値成功
//////////////////////////////////////////////////////////// // Verify UDP protocol headers // Verify UDP: // First we check things that must be set correctly. * If UDP.UDP_length > IP_total_len - IP_hdr_len - SPI_offset - Test_IV_len - Test_ICV_len - 4 (spi) - 4 (seq no) - 1 (protocol) - Pad_len - 1 (Pad_len) * Return Failure * If UDP.UDP_length < 8 * Return Failure // After that, we start to check things that do not // have one definitive value, but can have multiple possible // valid values. * If UDP.UDP_checksum is correct // This might be wrong because packet passed NAT, so // we cannot make this failure case. * Increment Check_Bits by 16 * If UDP.UDP_length = IP_total_len - IP_hdr_len - SPI_offset - Test_IV_len - Test_ICV_len - 4 (spi) - 4 (seq no) - 1 (protocol) - Pad_len - 1 (Pad_len) // If there is no TFC padding then UDP_length // will be matching the full packet length * Increment Check_Bits by 16 // We can also do normal deeper UDP inspection here. // If there is anything clearly wrong in the packet (i.e., // some data is set to something that it cannot be), then // this can return Failure; otherwise, it should just // increment Check_Bits matching the number of bits checked. // // We can also check things here compared to the last packet * If Last_Packet_Data.UDP.source_port = Packet_Data.UDP.source_port and Last_Packet_Data.destination_port = Packet_Data.UDP.destination_port * Increment Check_Bits by 32 * Return Success
////////////////////////////////////////////////// //まず、私たちが正しく設定されている必要があり、物事を確認してください。//////////は// UDPを確認してください// UDPプロトコルヘッダを確認してください。 *場合UDP.UDP_length> IP_total_len - IP_hdr_len - SPI_offset - Test_IV_len - Test_ICV_len - 4（SPI） - 4（配列なし） - 1（プロトコル） - Pad_len - 1（Pad_len）*戻り失敗* UDP.UDP_length <8 *を返した場合失敗は//その後、我々は// 1つの決定的な価値を持っていない事を確認するために開始しますが、複数の有効な//可能な値を持つことができます。 UDP.UDP_checksumが//正しい場合*パケットはNATを通過したので、これは間違っているかもしれないので、//私たちは、この障害のケースを作ることができません。 * 16 *によってインクリメントCheck_Bits UDP.UDP_length = IP_total_len場合 - IP_hdr_len - SPI_offset - Test_IV_len - Test_ICV_len - 4（SPI） - 4（配列なし） - 1（プロトコル） - Pad_len - 1（Pad_len）//ないTFCがない場合その後、UDP_lengthは// 16 //によって、完全なパケット長*インクリメントCheck_Bitsをマッチングされるパディングは、我々はまた、ここでは、通常より深いUDP検査を行うことができます。パケットで明確に何か問題がある場合は、//、そして//これは失敗を返すことができます（つまり、//いくつかのデータは、それがすることはできません何かに設定されています）。そうでない場合は、それだけで//インクリメントCheck_Bitsにチェックビット数に一致する必要があります。 // //我々はまた、32 *戻り値成功であればLast_Packet_Data.UDP.source_port = Packet_Data.UDP.source_portとLast_Packet_Data.destination_port = Packet_Data.UDP.destination_port *インクリメントCheck_Bits *最後のパケットに比べて、ここで物事を確認することができます
Figure 4
図4
Authors' Addresses
著者のアドレス
Tero Kivinen AuthenTec, Inc. Fredrikinkatu 47 Helsinki FIN-00100 FI
TERO Kivinenオーセンテック社Fredrikinkatu 47 FIN-00100ヘルシンキ、FI
EMail: kivinen@iki.fi
メールアドレス：kivinen@iki.fi
Daniel L. McDonald Oracle Corporation 35 Network Drive MS UBUR02-212 Burlington, MA 01803 USA
ダニエル・L.マクドナルドオラクル・コーポレーション35ネットワークドライブのMS UBUR02-212バーリントン、MA 01803 USA
EMail: danmcd@opensolaris.org
メールアドレス：danmcd@opensolaris.org