[要約] RFC 5879は、ESP-NULLパケットを検出するためのヒューリスティックスについてのガイドラインです。その目的は、ネットワーク上でのセキュリティ上の脆弱性を特定し、対策を講じることです。
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
ESPヌルパケットを検出するためのヒューリスティック
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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-NULLと呼ばれる）がIPSECのAH（認証ヘッダー[RFC4302]）と同様の特性を提供します。AHの代わりにESP-Nullを使用する理由の1つは、パスにNAT（ネットワークアドレス変換）デバイスがある場合、AHを使用できないことです。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ヌルパケットを検出して、深い検査を実行したり、アクセス制御を実施できるようにしたいと考えています。この種の深い検査には、ウイルス検出、スパムフィルタリング、侵入検出が含まれます。ESP-Nullの代わりに暗号化されたESPを使用してこれらのチェックをバイパスできる可能性があるため、これらの種類のシナリオは、そのような回転を禁止するために非常に具体的なポリシーも必要です。
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.
検査されるトラフィックは通常、1つの組織内のホストからホストへのトラフィックであるため、通常は輸送モードIPSECが使用されることを意味します。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トラフィックと暗号化されていない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.
o 対照的に、ラップされたESP（WESP）アプローチ[RFC5840]は、新しいプロトコルをサポートするために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.
両方のアプローチは、IPSECMEワーキンググループによって同時に文書化されており、WESPは標準トラックに配置され、ヒューリスティックアプローチは情報RFCとして公開されています。エンドポイントはWESPを採用するために変更されていますが、エンドポイントの少なくとも1つが変更されていないトラフィックを検査するためにヒューリスティックアプローチが必要であるため、両方のアプローチが長年にわたって共存する可能性があります。言い換えれば、中間ノードは、移行期間中に優れたセキュリティとパフォーマンスを達成するために、両方のアプローチをサポートすることが期待されています。
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ヌルパケットを検出するという発見的アプローチについて説明します。使用できる他のオプションがいくつかあり、このセクションで簡単に説明します。
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-Traversal（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].
もう1つの問題は、新しい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は、整合性アルゴリズムとして）。これは、通信機のペアの1つがディープインスペクションエンジンと同じ管理ドメインの下にいない場合を除き、機能します。（IPSECセキュリティ協会（SAS）は、すべての通信関係者にとって満足のいくものでなければならないため、1つの通信ピアのみが十分に狭いポリシーを持つ必要があります。）また、そのような解決策は、管理ドメインの全員を確認するために何らかの集中型ポリシー管理が必要になる場合があります。同じポリシーを使用すると、その単一のポリシーの変更は、管理ドメイン全体で調整できます。
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.
いくつかのドキュメントは、ESPを変更して、ESPパケットのnull暗号化の使用に関する中間デバイス情報を提供する方法について説明しています。以下の方法について説明しました：IP-Optionの追加、新しいIP-Protocol番号と追加のヘッダー[RFC5840]の追加、ESP-Nullパラメーター[Auth-Only-ESP]を伝える新しいIP-Protocol番号の追加、予約ESP-Null [ESP-Null]のSPI範囲、および異なる形式とポートで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形式の両方を必要とする実装を考慮すると、広範囲にわたる展開の前に、おそらく10年もかかる数年かかります。
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フローの状態を維持します。それ。ヒューリスティックは、いかなる状態も保存せずに使用できますが、その場合、パケットごとにヒューリスティックチェックを行う必要があるため、フローごとに1回だけでなく、パフォーマンスは悪化します。これは、ヒューリスティックの信頼性にも影響します。
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パケットとして検出されることはありません。つまり、有効な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としてパケットを検出するランダムに見えるESPヌルパケットを簡単に送信できますが、それは中間ノードを介して非ESPファズを送信することよりも悪くはありません。ESP-Nullフローが暗号化されたESPフローと間違えられる唯一の方法は、ESP-Nullフローがパケットインスペクターに知識がない認証アルゴリズムを使用している場合です。
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のペアによって識別されます。また、宛先がマルチキャストグループでない限り、ENDノードはSAでソースIPアドレスを修正することがよくあります。通常、中間デバイスの関心のあるフローのほとんど（すべてではないにしても）のフローはユニキャストであるため、受信ノードがソースアドレスも使用していると仮定する方が安全です。したがって、中間デバイスは同じことを行う必要があります。場合によっては、これは外部のキャッシュされたESP IPSEC SAフローを引き起こす可能性がありますが、ソースアドレスを使用することにより、2つの異なるフローが混合されることはありません。マルチキャストを重視しているサイトの場合、そのようなトラフィックは決定論的に識別可能です（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ヌルパラメーターとともに、同じフローのパケットを処理するときに将来使用されるフローキャッシュに保存されます。
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ヌルフローの両方は、ローカルポリシーに基づいて処理されます。通常の操作では、暗号化されたESPフローがローカルポリシーごとに通過または削除され、ESPヌルフローは深部インスペクションエンジンに渡されます。また、ローカルポリシーは、他のパケット処理パラメーターを決定するためにも使用されます。このドキュメントでは、実装を容易にするために、ローカルポリシーの問題が明確にマークされます。
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ヌルフローとしてマークされている可能性があります。
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.
単一のパケットがフローのタイプを検出するのに十分ではないかもしれない理由はいくつかあります。そのうちの1つは、次のヘッダー番号が不明だったことです。つまり、ヒューリスティックがパケットのプロトコルについて知らない場合、パケットがESP-Nullのように見える場合でも、ESP-Nullパラメーターが適切に検出されたことを確認できません。パケットがESP-Nullのように見えない場合、暗号化されたESPステータスをすばやく返すことができます。ESP-null Heuristicsは、ディープインスレクションデバイスと同じプロトコルを知る必要があるため、未知のプロトコルのESPヌルインスタンスは、同じ未知のプロトコルのクリアテキストインスタンスと同じ方法で処理できます。
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フロー）。
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ヌルヒューリスティックを実装するシステムは、エラーの状況からすぐに回復できません。
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パケット（完全にランダムなバイトが含まれているように見える）が予想される場所にもっともらしいバイトを持つ可能性がわずかです。そのため、ヒューリスティックはESPパケットを検出する代わりにESPヌルパケットとしてパケットを検出します。。実際の確率は、このドキュメントの後半で計算されます。このようなパケットは問題を引き起こしません。ディープインテクションエンジンは、おそらくパケットを拒否し、それがゴミであることを返すためです。ディープインスペクションエンジンが大量のパケットをゴミとして拒否している場合、フローの元のESP-null検出が間違っていたことを示している可能性があります（つまり、暗号化されたESPフローはESPヌルとして不適切に検出されました）。その場合、キャッシュされたフローを無効にし、発見が再び発生するはずです。
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ヌル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.
キャッシュの無効化の実際の制限は、現地の政策決定です。サンプルの無効化ポリシーには、1秒以内にゴミとしてマークされたパケットの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によるポート翻訳は、元々4500が別の値に書き換えたことがよくあります。つまり、それぞれの一意のポートペアは個別のIPSecフローを構成します。つまり、UDPにカプセル化されたIPSECフローは、ソースと宛先IP、ソースと宛先ポート番号、およびSPI番号によって識別されます。デバイスがIKEV2モビリティとマルチホミング（MOBIKE）（[RFC4555]）を使用している可能性があるため、UDPカプセル化された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.999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999年にわたるノードがランダムパケットが無効であると正しく検出されます。これは、中間デバイスが入力パケットから約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にはよく理解されているパケットレイアウトがありますが、その可変長さのフィールドは、純粋なアルゴリズムの一致の能力を、ヒューリスティックと確率の割り当てを必要とするものに減らします。
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もあります。このアルゴリズムのICV長は128ビットで、8バイトのIVも必要です。
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.
ICVの長さに加えて、IVの長さには2つの可能な値があります：0バイト（デフォルト）と8バイト（ENCR_NULL_AUTH_AES_GMACの場合）。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の長さを測定する必要があります。4つの異なるICVの長さは、パッドの長さとパディングの4つの可能な場所につながります。ICVのより大きなサイズを試す場合は、検査されたバイトがペイロードデータではないデータに属さないように、実装を注意する必要があります。たとえば、10バイトのICMPエコーリクエストには長さの長さがゼロになりますが、256ビットICVのチェックは、パケットに実際に96ビットまたは128ビット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のチェックを開始した場合、ペイロードのクリアテキスト部分に有効なバイトが含まれている可能性があります。他の順序で行われた場合、つまり256ビットICVを備えたパケットと96ビット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ヌルパディングの2つのケースは、バイト（上記の04 04のように）または0バイトパディングケースと一致しています。パディングの1つ以上のバイトがある場合、ノードは非常にシンプルで高速なテストを実行できます。これらの4つの場所のいずれかでN Nのシーケンスです。4つの2バイトの位置が与えられている（パケットサイズがすべて4つのICVの長さをすべて許可すると仮定）、ゼロ以外の長さの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%.
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ヌルパケットとして暗号化されたパケットを誤分類する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シーケンスのバイトシーケンスが発生することを意味します。これにより、実行可能なESPヌルパディングとしての「FF FF」のペアが実質的に排除されます。
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ヌルパディングであると1/256^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％が残っているため、次のヘッダー番号が検査されます。次のヘッダー番号が既知（およびサポートされている）場合、パケットは次のヘッダー番号に基づいて検査できます。次のヘッダー番号が不明な場合（つまり、プロトコルチェックサポートを持っている人のいずれでもありません）、パケットは「不確か」とマークされています。
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".
一般的な使用中の6つの異なる次のヘッダーフィールド（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ヌルフローの検出に役立ちます。ヒューリスティックを介して取得された「不確かな」リターンの数をカウントすることにより、同じ場所で一貫した、未知の次のヘッダー番号を受け取った後（つまり、同じ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のフローに属するパケット（Rekeyの前の以前の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.
プロトコルチェックには、2つの異なるタイプのチェックがあります。最初のチェックはパケットの有効性のためのものです。つまり、特定の場所には特定の値を含める必要があります。たとえば、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.
2番目のタイプのチェックは、変数用ですが、パルス値が容易です。たとえば、内側の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.
最も明白なフィールドであるTCPチェックサムは、IPアドレスを変更したがESPペイロードが暗号化されており、新しいIPアドレスでトランスポートチェックサムを修正しなかったと仮定するNATボックスを既に輸送している可能性があるため、使用できない可能性があります。。したがって、チェックサムで使用される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.
検出の適切な方法の1つは、パケットがドロップされた場合、次のパケットが以前のパケットの再送信になる可能性が高いことです。したがって、同じソースと宛先ポート番号で2つのパケットが受信され、シーケンス番号が同じまたは互いに直後にある場合、TCPパケットが正しく検出された可能性があります。このヒューリスティックは、1つのパケットのみが未解決の場合に最も役立ちます。たとえば、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チェックサムと同じ問題を抱えています。UDPの長さフィールドは、全体的なパケット長と一致しない場合があります。送信者にはTFC（トラフィックフローの機密性が含まれている」を含めることが許可されているため、「セキュリティペイロードをカプセル化する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の最初のパケットとして取得するためのあまり一般的なパケットではありません。ICMPECHO_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の使用可能なフィールドは少なくなりますが、バージョン番号、パケット長（Modulo 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の深いパケット検査を常にバイパスできます。最終的に、深い検査を実施する責任、または中間ノードが深い検査を実行できるようにする責任は、エンドノードにかかっている必要があります。つまり、サーバーが暗号化された接続を許可している場合、サーバーを攻撃し、中央にディープインスペクションデバイスをバイパスしたい攻撃者は、暗号化されたトラフィックを使用します。これは、ネットワーク全体の保護が、エンドノードのポリシー施行と保護と同じくらい優れていることを意味します。すべてのトラフィックの深い検査を実施する1つの方法は、暗号化されたESPを完全に禁止することです。その場合、すべてのパケットがポリシーに基づいてESP-Nullでなければならないため、ESP-Null検出は簡単です（IVを見つけるには、ヒューリスティックがまだ必要になる場合がありますさらなる政策制限があいまいさを排除しない限り、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ヌルの流れを無視しますが、それはファズを注入することほど悪くはありません。
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] Glenn、R。およびS. Kent、「Null暗号化アルゴリズムとIPSECでの使用」、RFC 2410、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（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] Hoffman、P。and D. McGrew、「IPプロトコル識別子を使用したESPの認証のみのプロファイル」、2007年8月の作業。
[ESP-NULL] Bhatia, M., "Identifying ESP-NULL Packets", Work in Progress, December 2008.
[ESP-Null] Bhatia、M。、「ESP-Nullパケットの識別」、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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「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] Weis、B。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化内でのRSA/SHA-1シグネチャの使用」、RFC 4359、2006年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。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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.、Montenegro、G。、およびM. Bhatia、「トラフィックの可視性のためのセキュリティペイロード（ESP）をラップした」、RFC 5840、2010年4月。
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.
この付録は、実装者向けです。必要なすべてのチェックが含まれているわけではなく、これは単なる擬似コードの例であるため、最終的な実装は非常に異なる場合があります。主に行う必要があることをリストしますが、実装は他の部分に応じてステップを最適化できます。たとえば、実装は、ヒューリスティックと深い検査をしっかりと組み合わせる可能性があります。
The following example pseudocode show the fastpath part of the packet processing engine. This part is usually implemented in hardware.
次の例は、パケット処理エンジンのFastPath部分を示しています。この部分は通常、ハードウェアに実装されます。
////////////////////////////////////////////////////////////
// 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.
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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.
Figure 3
図3
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.
//
// 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)
////////////////////////////////////////////////////////////
// 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
// 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
* 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
* 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（seq no）4（protocol padding） * return * return * return * return verify padd *検証パディングを検証する場合 ** goto gmac // ok、packetはOKでしたが、今すぐ行って、十分な//データビットがあるかどうかを確認してください。
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// Check for 256-bit algorithms.
//
Try 256bit algorithms:
// AUTH_HMAC_SHA2_512_256
* Set Test_ICV_len to 32, Test_IV_len to 0
* Goto Check packet
* GOTOチェックパケット
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
// 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
//これらの値は、//最終的な状態が不確かである場合、SPIキャッシュに保存されます * set iv_len to test_iv_len、icv_len to test_icv_len
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
////////////////////////////////////////////////////////////
// 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
* 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 =
Packet_Data.TCP.sequence_number * Increment Check_Bits by 32 // We can do other similar checks here * Return Success
packet_data.tcp.sequence_number * increment check_bits by 32 //ここで他の同様のチェックを行うことができます *成功を返すことができます
////////////////////////////////////////////////////////////
// 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
Figure 4
図4
Authors' Addresses
著者のアドレス
Tero Kivinen AuthenTec, Inc. Fredrikinkatu 47 Helsinki FIN-00100 FI
Tero Kivinen Aedecurec、Inc。Fredrikinkatu 47 Helsinki Fin-00100 fi
EMail: kivinen@iki.fi
Daniel L. McDonald Oracle Corporation 35 Network Drive MS UBUR02-212 Burlington, MA 01803 USA
ダニエルL.マクドナルドオラクルコーポレーション35ネットワークドライブMS UBUR02-212バーリントン、マサチューセッツ州01803 USA
EMail: danmcd@opensolaris.org