Articles /

ネットワークトラフィックフローとは何ですか？

traffic_wide

ネットワークトラフィックフロー（フロー）は、トラフィックの測定および/または処理のための便利な単位を提供し、コンピュータネットワーク上のトラヒックの粗粒度の理解を構築するために有用である。

フローを測定して、ホストがネットワーク上で何を話しているのか、アドレス、ボリューム、トラフィックの種類の詳細を理解することができます。 ネットワークのこのビューは、トラブルシューティング、セキュリティインシデントの検出、計画と請求

に役立ちますが、フローとは正確には何であり、どのように定義されていますか？

この質問に答えるのは簡単に聞こえますが、より深く掘り下げると、フローを面白くし、最終的に定義するのが難しいニュアンスやコーナーケースが見つ

背景

フローを真に理解するためには、いくつかの背景から始める必要があります。

ネットワークは回線交換として始まりました。 ホストが別のホストと通信したいときは、ネットワークに回線を設定するように求めました。 情報の流れが終わった後、回路は取り壊されました。

flow2

図1-回線交換ネットワークの例

回線交換ネットワークは、電話ネットワークでの遺産を持っています。 これらには、スケーラビリティの低さや容量の使用率など、多くの欠点があります。

最終的にインターネットパケットスイッチドネットワークになるものを構築するための代替手段が必要でした。 メッセージは、個別にアドレス指定され、ネットワークを介してパケットとして送信される可変サイズの部分に切り

flow3

図2-パケット交換ネットワークの例

受信側ホストは、パケットからペイロードを再アセンブルしてメッセージに戻します。 注:パケットには、フロー制御などの制御情報を含めることもでき、パスは対称である必要はありません。

回路交換ネットワークでのフローの定義は、回路がフローであり、確立と廃止のためのプロトコル（circuit=flow）に従うので簡単です。

あなたが図1の回路交換ネットワークの観測点Aにいることを一瞬想像してみてください。:

flow4

図3-回路交換ネットワークの拡大

ホスト3&4とホスト5&6の間の2つのフローが観察されます。 回路交換ネットワーク内のフローの観察は、ネットワークが回路の設定に関与しているため、その状態とエンドポイントを知っているため、比較的簡単です。

これで、図2のパケット交換ネットワークの観測点Aにいるとします。:

flow5

図4-パケット交換ネットワークの拡大

突然、物事はあまり明確ではありません。 ホスト5からホスト6宛てに入ってくるパケットがあります。 私たちが一定期間観察したと仮定すると、より多くのパケットが到着して出発するのがわかります。 パケット交換ネットワーク上のフローの観測には時間がかかり、パケット情報の記録と分析が必要です。

フローを定義する最初の（素朴な）試み

パケット交換ネットワークの知識を使用して、”フローとは何か”に答える最初の試みは次のようになります:

フローは、二つのホスト間で情報を運ぶパケットのシーケンスです

この定義は次のようになります:

flow6

図5-フローを定義する最初の試み

しかし、問題があります。 たとえば、AがBへのSSH接続とHTTPS接続を持っているなど、ホスト間で複数のタイプの通信が発生した場合はどうなりますか？ SSHパケットとHTTPSパケットは同じフローの一部ですか？ 直感的に我々は、彼らが異なるセッション、さらには全く異なるプロトコルである、ノーと言います。 より良いことができます…

を定義する2回目の試みパケットヘッダからのプロトコル情報を共通のプロパティとして使用して、パケットをフローに識別するにはどうすればよいですか？ これにより、異なるタイプの接続が異なるフローに分離されます。

ネットワーク上のパケットの大部分はIPレイヤ3プロトコルであり、TCPまたはUDPをレイヤ4トランスポートプロトコルとする可能性があります。 したがって、パケットヘッダからのフローキーとしてTCPおよびUDPパラメータを使用することを検討することは合理的です。

パケットヘッダーから5つのパラメータを使用します; 送信元IP、宛先IP、プロトコル、TCPまたはUDP送信元ポート、およびTCPまたはUDP宛先ポートを順序付けられたリストとして指定します。

flow7

図6-例5-タプル

試行2:

フローは、パケットが共通のプロパティを持つ二つのホスト間で情報を運ぶパケットのシーケンスです。

  • フロー内のすべてのパケ

私たちのシナリオは次のようになります:

flow8

図7-フローを定義する2番目の試み

完璧なあなたが言います。 人生は良いです。 私たちはフローの定義を持っていますが、ここで見ることは何もありません…しかし、パケットの方向はどうですか？

第三の試み–双方向

5タプルは単方向（一方向）です。 デフォルトでは、逆方向のパケットはIPアドレスとポート番号を転置しているため、異なる5タプルハッシュであるため、一方向に移動するパケットのみに一致します。

クライアント/サーバーの動作を決定し、ラウンドトリップ時間を計算する機能、スキャンなどのセキュリティインシデントの検出を改善する機能など、フローを単方向ではなく双方向と考えるのに十分な理由があります。

ホストA&B間でパケットが前後にバウンスする図8の単純なTCP接続を考えてみましょう:

flow9

図8-単純なTCPフローのラダー図

古典的なTCP3-wayハンドシェイク(SYN,SYN+ACK,ACK)に続いてデータの交換が表示されます。 ネットワーク内の観測点での単方向フロー解析では、図のように、方向ごとに1つずつ、2つの別々のフローが表示されます9:

flow10

図9-単純なTCPフローの単方向はしご

単方向フロー測定の問題は、フローに関するいくつかの重要なメタデータをキャプチャする機会を逃すことです。 確かに、各単方向フローは、その方向のバイトとパケットの方向メタデータを格納できます。 これにはパケット間のタイミングが含まれます(図9のラベル付けされたドットを参照)。 しかし、両方向のトラフィックパラメータを測定する必要があるメタデータを収集する機会を逃しています。

図の中で双方向観測を考えてみましょう10:

flow11a

図10-単純なTCPフローの双方向観測のラダー

TCP3-wayハンドシェイク(ポイントF1、B1、F2)を観測して測定し、応答時間などの他のメトリックを見ることがで

双方向フローの場合、2つの5タプルが必要で、2つ目のタプルはIPアドレスとポート番号の両方のタプル順序を逆にします。 以下は、SSHフローの順方向および逆方向の5タプルの例です:

flow12

図11-5タプルの反転

右、それはあまりにも難しいことではありませんでした。 しかし、待って、さらなる注意を必要とする小さな細部が潜んでいます。 どのように我々は流れの前方方向が何であるかを知っていますか？ 最初に観測されたパケットに基づいて方向を決定しますが、これはクライアントからサーバーへの方向に移動すると想定されますが、パケットが順不同になる可能性があり、または観測がフローを介して一部の方法で開始される可能性があるため、100％信頼性がありません。 この方法で使用しますが、結果を見ると完璧ではないことを覚えておく必要があります。

別の方法は、トランスポートプロトコルフィールドを検査することです。 たとえば、TCPでは、SYNフラグだけが存在することは、パケットがフローの最初のものであることを示す合理的な指標です。

フローの定義は次のようになりました。

フローは、パケットが共通のプロパティを持つ二つのホスト間の情報を運ぶパケットのシーケンスです:

  • フロー内のすべてのパケットは、同じ5タプルまたは転置された5タプルを共有します

第四の試み–非TCP IPトラフィックを含む

この時点まで、トランスポートプロトコルはTCPであると仮定していました。 他のIP転送プロトコルはどうですか？

UDPは、特にUDP上のリアルタイムトラフィックやQUICなどの新しいプロトコルの台頭により、二番目に一般的なトランスポートプロトコルのための明白な選択です。 UDPは、以下のQUICの例のように、送信元ポート番号と宛先ポート番号を持つのと同じモデルに簡単に適合します:

flow13

図12-UDP5タプルの反転(TCPと同じ)

Stream Control Transmission Protocol(SCTP)は、ポート番号を使用して5タプルで動作する別のトランスポートプロトコルです。

しかし、他のプロトコル、例えばIPsecについてはどうですか？

IPsec ESP(Encapsulating Security Payload)は送信元/宛先ポート番号を含まないプロトコルであるため、プロトコルのペイロードを理解することは実用的ではないため、3タプルにフォールバックする必要があります。

flow14

図13-双方向3タプル

フローの定義は次のようになりました。

フローは、パケットが共通のプロパティを持つ二つのホスト間で情報を運ぶパケットのシーケンスです。

  • ポート番号を持つトランスポートプロトコル(すなわちTCP/UDP/SCTP)の場合):

フロー内のすべてのパケットは、同じ5タプルまたは転置された5タプル

を共有します。else:

フロー内のすべてのパケットは、同じ3タプルまたは転置された3タプル

しかし、考慮すべきもう一つの要因-時間があります。

5回目の試行–フローの有効期限

フローは一定の時間だけ存在します。 同じホスト間で、異なるフローに対して、異なる時点で同じ5タプル(または3タプル)を再利用できる可能性があります。

一方が他方への多くの新しいTCP接続を開始する二つのホストを考えてみましょう。 新しいTCP接続ごとに新しい送信元ポートが取得され、通常は前の割り当てから1ずつ増加します。 IANAは、これらの一時ポートに49152から65535の範囲を割り当て、16384ポートを与えます。 時間が経つにつれて、TCP送信元ポートは範囲をロールバックし、元の送信元ポートが再利用され、このフローは元のフローと同じ5タプルを持ちます。 これは、同じ流れではないので、問題を提示します!

これを解決するには、指定された時間以上パケットが表示されないフローを期限切れにする必要があります。

フローとは、パケットが共通のプロパティを持つ二つのホスト間で情報を運ぶパケットのシーケンスです。

  • ポート番号を持つトランスポートプロトコル（TCP/UDP/SCTP）:

フロー内のすべてのパケットは同じ5タプルまたは転置5タプルを共有します

else:

フロー内のすべてのパケットは同じ3タプルまたは転置3タプルを共有します

  • すべてのパケット間時間が任意のフロー有効期限タイムアウト値未満です

Sixth Attempt-Arbitrary Parameters

フローを識別するために異なるパラメータが必要な場合や、ネットワーク内のハードウェア/ソフトウェアの種類によって強制される場合があります。たとえばCiscoルータでは、フローはType of Service（ToS;サービスタイプ）および入力サブインターフェイスを標準の5タプルに追加する7タプルによって識別されます。 送信元または宛先MACアドレスなどのレイヤ2フィールドがフローキーとして意味を持つ場合もあります（ただし、ローカルでのみ重要であることに注意して

フロー識別のための共通のプロパティとして使用できる他のパラメータがあります;それは最終的に決定するオペレータと機器の能力次第です. これに基づいて、定義をさらに洗練します:

フローとは、パケットが共通のプロパティを持つ二つのホスト間で情報を運ぶパケットのシーケンスです。

  • ポート番号を持つトランスポートプロトコル(TCP/UDP/SCTP):

フロー内のすべてのパケットは同じ5タプルまたは転置された5タプルを共有します

else:

フロー内のすべてのパケットは同じ3タプルまたは転置された3タプルを共有します

  • すべてのパケット間時間が任意のフロー有効期限タイムアウト値
  • tos、インターフェイスなどを含む任意のパラメータをフローキーとして使用できます。

それをすべてまとめる

私たちは、単一の包括的なフロー定義を作成することは困難な問題であることを示しました。 フロー定義は実装固有であり、ユーザーの要件と、フローを測定するネットワーク機器の機能に依存します。

このブログ記事のパート2では、Ipv6フローラベル、断片化（Ipv4およびIpv6の問題。.）、暗号化、非IPパケット、およびSDNなどの他のシステムでフローがどのように測定され、使用されるか。

参照: 関連する論文については、https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdfおよびhttps://is.muni.cz/th/hilnn/cse2009.pdf

関連するRFCについては、https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdfおよびhttps://is.muni.cz/th/hilnn/cse2009.pdf

を参照してください。: https://tools.ietf.org/html/rfc5103

QUICの標準化の詳細については、以下を参照してください: https://datatracker.ietf.org/wg/quic/about/

参照：https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml

Leave a Reply