[要約] RFC 7430は、Multipath TCP（MPTCP）の残存する脅威と可能な修正策の分析に関するものであり、MPTCPのセキュリティに関する問題を特定し、解決策を提案することを目的としています。
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 7430 UC3M
Category: Informational C. Paasch
ISSN: 2070-1721 UCLouvain
F. Gont
SI6 Networks / UTN-FRH
O. Bonaventure
UCLouvain
C. Raiciu
UPB
July 2015
Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)
マルチパスTCP（MPTCP）の残留脅威と可能な修正の分析
Abstract
概要
This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.
このドキュメントでは、マルチパスTCP（MPTCP）の残りの脅威を分析し、それらに対処するための可能な解決策を探ります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7430.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7430で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ADD_ADDR Attack . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Possible Security Enhancements to Prevent This Attack . . 10
3. DoS Attack on MP_JOIN . . . . . . . . . . . . . . . . . . . . 11
3.1. Possible Security Enhancements to Prevent This Attack . . 12
4. SYN Flooding Amplification . . . . . . . . . . . . . . . . . 12
4.1. Possible Security Enhancements to Prevent This Attack . . 13
5. Eavesdropper in the Initial Handshake . . . . . . . . . . . . 13
5.1. Possible Security Enhancements to Prevent This Attack . . 14
6. SYN/JOIN Attack . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Possible Security Enhancements to Prevent This Attack . . 14
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. MPTCP Security Improvements for a Standards Track
Specification . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Security Enhancements for MPTCP . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
This document provides a complement to the threat analysis for Multipath TCP (MPTCP) [RFC6824] documented in RFC 6181 [RFC6181]. RFC 6181 provided a threat analysis for the general solution space of extending TCP to operate with multiple IP addresses per connection. Its main goal was to leverage previous experience acquired during the design of other multi-address protocols, notably Shim6 [RFC5533], the Stream Control Transmission Protocol (SCTP) [RFC4960], and Mobile IPv6 (MIP6) [RFC6275] for designing MPTCP. Thus, RFC 6181 was produced before the actual MPTCP specification (RFC 6824) was completed and documented a set of recommendations that were considered during the production of that specification.
このドキュメントは、RFC 6181 [RFC6181]で文書化されているマルチパスTCP（MPTCP）[RFC6824]の脅威分析を補足するものです。 RFC 6181は、接続ごとに複数のIPアドレスで動作するようにTCPを拡張する一般的なソリューションスペースの脅威分析を提供しました。その主な目的は、他のマルチアドレスプロトコル、特にShim6 [RFC5533]、Stream Control Transmission Protocol（SCTP）[RFC4960]、およびMobile IPv6（MIP6）[RFC6275]の設計中にMPTCPを設計する際に得た以前の経験を活用することでした。したがって、実際のMPTCP仕様（RFC 6824）が完成する前にRFC 6181が作成され、その仕様の作成中に検討された一連の推奨事項が文書化されました。
This document complements RFC 6181 with a vulnerability analysis of the mechanisms specified in RFC 6824. The motivation for this analysis is to identify possible security issues with MPTCP as currently specified and propose security enhancements to address these identified security issues.
このドキュメントは、RFC 6181をRFC 6824で指定されたメカニズムの脆弱性分析で補足します。この分析の動機は、現在指定されているMPTCPで起こり得るセキュリティ問題を特定し、これらの特定されたセキュリティ問題に対処するセキュリティ強化を提案することです。
The goal of the security mechanisms defined in RFC 6824 was to make MPTCP no worse than currently available single-path TCP. We believe that this goal is still valid, so we will perform our analysis on the same grounds. This document describes all the threats identified that are specific to MPTCP (as defined in RFC 6824) that are not possible with single-path TCP. This means that threats that are common to TCP and MPTCP are not covered in this document.
RFC 6824で定義されているセキュリティメカニズムの目標は、MPTCPを現在利用可能な単一パスTCPよりも悪くしないことでした。この目標はまだ有効であると考えているため、同じ理由で分析を行います。このドキュメントでは、MPRFC（RFC 6824で定義）に固有であり、シングルパスTCPでは不可能であると識別されたすべての脅威について説明します。つまり、TCPとMPTCPに共通する脅威はこのドキュメントではカバーされていません。
For each attack considered in this document, we identify the type of attacker. We can classify the attackers based on their location as follows:
このドキュメントで検討されている各攻撃について、攻撃者のタイプを特定します。次のように、場所に基づいて攻撃者を分類できます。
o Off-path attacker. This is an attacker that does not need to be located in any of the paths of the MPTCP session at any point in time during the lifetime of the MPTCP session. This means that the off-path attacker cannot eavesdrop any of the packets of the MPTCP session.
o パス外の攻撃者。これは攻撃者であり、MPTCPセッションの存続期間中のどの時点でも、MPTCPセッションのどのパスにもいる必要はありません。これは、オフパス攻撃者がMPTCPセッションのパケットを盗聴できないことを意味します。
o Partial-time on-path attacker. This is an attacker that needs to be in at least one of the paths during part of the lifetime of the MPTCP session (but not the entire lifetime). The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o パス上の部分攻撃者。これは、MPTCPセッションのライフタイムの一部（ライフタイム全体ではない）の間、少なくとも1つのパスにいる必要がある攻撃者です。攻撃者は、最初のサブフローおよび/または他のサブフローの順方向および/または逆方向にいる可能性があります。攻撃者の具体的なニーズは、攻撃の説明で明示されます。
o On-path attacker. This attacker needs to be on at least one of the paths during the whole duration of the MPTCP session. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o パス上の攻撃者。この攻撃者は、MPTCPセッションの全期間中、少なくとも1つのパス上にいる必要があります。攻撃者は、最初のサブフローおよび/または他のサブフローの順方向および/または逆方向にいる可能性があります。攻撃者の具体的なニーズは、攻撃の説明で明示されます。
We can also classify the attackers based on their actions as follows:
次のように、攻撃者をアクションに基づいて分類することもできます。
o Eavesdropper. The attacker is able to capture some of the packets of the MPTCP session to perform the attack, but it is not capable of changing, discarding, or delaying any packet of the MPTCP session. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o 盗聴者。攻撃者は、MPTCPセッションのパケットの一部をキャプチャして攻撃を実行できますが、MPTCPセッションのパケットを変更、破棄、または遅延することはできません。攻撃者は、最初のサブフローおよび/または他のサブフローの順方向および/または逆方向にいる可能性があります。攻撃者の具体的なニーズは、攻撃の説明で明示されます。
o Active attacker. The attacker is able to change, discard, or delay some of the packets of the MPTCP session. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The specific needs of the attacker will be made explicit in the attack description.
o アクティブな攻撃者。攻撃者は、MPTCPセッションの一部のパケットを変更、破棄、または遅延させることができます。攻撃者は、最初のサブフローおよび/または他のサブフローの順方向および/または逆方向にいる可能性があります。攻撃者の具体的なニーズは、攻撃の説明で明示されます。
In this document, we consider the following possible combinations of attackers:
このドキュメントでは、攻撃者の次の可能な組み合わせについて検討します。
o an on-path eavesdropper
o 路上の盗聴者
o an on-path active attacker
o パス上のアクティブな攻撃者
o an off-path active attacker
o パス外のアクティブな攻撃者
o a partial-time on-path eavesdropper
o パス上の部分盗聴者
o a partial-time on-path active attacker
o パス上の部分的にアクティブな攻撃者
In the rest of the document, we describe different attacks that are possible against the MPTCP protocol specified in RFC 6824 and propose possible security enhancements to address them.
このドキュメントの残りの部分では、RFC 6824で指定されているMPTCPプロトコルに対して起こりうるさまざまな攻撃について説明し、それらに対処するための可能なセキュリティ強化を提案します。
Summary of the attack:
攻撃の概要：
Type of attack: MPTCP session hijack enabling a man-in-the-middle (MitM) attack
攻撃のタイプ：中間者（MitM）攻撃を可能にするMPTCPセッションハイジャック
Type of attacker: off-path active attacker
攻撃者のタイプ：オフパスアクティブ攻撃者
Description:
説明：
In this attack, the attacker uses the ADD_ADDR option defined in RFC 6824 to hijack an ongoing MPTCP session and enable himself to perform a man-in-the-middle attack on the MPTCP session.
この攻撃では、攻撃者はRFC 6824で定義されているADD_ADDRオプションを使用して、進行中のMPTCPセッションを乗っ取り、MPTCPセッションで中間者攻撃を実行できるようにします。
Consider the following scenario. Host A with address IPA has one MPTCP session with Host B with address IPB. The MPTCP subflow between IPA and IPB is using port PA on Host A and port PB on Host B. The tokens for the MPTCP session are TA and TB for Host A and Host B, respectively. Host C is the attacker. It owns address IPC. The attack is executed as follows:
次のシナリオを検討してください。アドレスIPAのホストAには、アドレスIPBのホストBとのMPTCPセッションが1つあります。 IPAとIPB間のMPTCPサブフローは、ホストAのポートPAとホストBのポートPBを使用しています。MPTCPセッションのトークンは、それぞれホストAとホストBのTAとTBです。ホストCが攻撃者です。アドレスIPCを所有しています。攻撃は次のように実行されます。
1. Host C sends a forged packet with source address IPA, destination address IPB, source port PA, and destination port PB. The packet has the ACK flag set. The TCP sequence number for the segment is i, and the ACK sequence number is j. We will assume all these are valid; later, we discuss what the attacker needs to figure them out. The packet contains the ADD_ADDR option. The ADD_ADDR option announces IPC as an alternative address for the connection. It also contains an 8-bit address identifier that does not provide any strong security benefit.
1. ホストCは、送信元アドレスIPA、宛先アドレスIPB、送信元ポートPA、および宛先ポートPBを含む偽造パケットを送信します。パケットにはACKフラグが設定されています。セグメントのTCPシーケンス番号はiで、ACKシーケンス番号はjです。これらはすべて有効であると想定します。後で、攻撃者がそれらを理解するために必要なものについて説明します。パケットにはADD_ADDRオプションが含まれています。 ADD_ADDRオプションは、接続の代替アドレスとしてIPCをアナウンスします。また、強力なセキュリティ上の利点を提供しない8ビットのアドレス識別子も含まれています。
2. Host B receives the ADD_ADDR message and replies by sending a TCP SYN packet.
2. ホストBはADD_ADDRメッセージを受信し、TCP SYNパケットを送信して応答します。
Note: The MPTCP specification [RFC6824] states that the host receiving the ADD_ADDR option may initiate a new subflow. If the host is configured so that it does not initiate a new subflow, the attack will not succeed. For example, on the current Linux implementation, the server does not create subflows. Only the client does so.
注：MPTCP仕様[RFC6824]には、ADD_ADDRオプションを受信するホストが新しいサブフローを開始する可能性があると記載されています。ホストが新しいサブフローを開始しないように構成されている場合、攻撃は成功しません。例えば、現在のLinux実装では、サーバーはサブフローを作成しません。クライアントだけがそうします。
The source address for the packet is IPB; the destination address for the packet is IPC; the source port is PB'; and the destination port is PA' (it is not required that PA=PA' nor that PB=PB'). The sequence number for this packet is the new initial sequence number for this subflow. The ACK sequence number is not relevant as the ACK flag is not set. The packet carries an MP_JOIN option and the token TA. It also carries a random nonce generated by Host B called RB.
パケットの送信元アドレスはIPBです。パケットの宛先アドレスはIPCです。送信元ポートはPB 'です。また、宛先ポートはPA 'です（PA = PA'またはPB = PB 'である必要はありません）。このパケットのシーケンス番号は、このサブフローの新しい初期シーケンス番号です。 ACKフラグが設定されていないため、ACKシーケンス番号は関係ありません。パケットには、MP_JOINオプションとトークンTAが含まれます。また、RBと呼ばれるホストBによって生成されたランダムなナンスも伝送します。
3. Host C receives the SYN+MP_JOIN packet from Host B and alters it in the following way. It changes the source address to IPC and the destination address to IPA. It sends the modified packet to Host A, impersonating Host B.
3. ホストCはホストBからSYN + MP_JOINパケットを受信し、次のように変更します。送信元アドレスをIPCに、宛先アドレスをIPAに変更します。変更されたパケットをホストAに送信し、ホストBを偽装します。
4. Host A receives the SYN+MP_JOIN message and replies with a SYN/ACK+MP_JOIN message. The packet has source address IPA and destination address IPC, as well as all the other needed parameters. In particular, Host A computes a valid Hashed Message Authentication Code (HMAC) and places it in the MP_JOIN option.
4. ホストAはSYN + MP_JOINメッセージを受信し、SYN / ACK + MP_JOINメッセージで応答します。パケットには、送信元アドレスIPAと宛先アドレスIPC、およびその他の必要なすべてのパラメータが含まれています。特に、ホストAは有効なハッシュメッセージ認証コード（HMAC）を計算し、それをMP_JOINオプションに配置します。
5. Host C receives the SYN/ACK+MP_JOIN message and changes the source address to IPC and the destination address to IPB. It sends the modified packet to IPB, impersonating Host A.
5. ホストCはSYN / ACK + MP_JOINメッセージを受信し、送信元アドレスをIPCに、宛先アドレスをIPBに変更します。変更されたパケットをIPBに送信し、ホストAを偽装します。
6. Host B receives the SYN/ACK+MP_JOIN message. Host B verifies the HMAC of the MP_JOIN option and confirms its validity. It replies with an ACK+MP_JOIN packet. The packet has source address IPB and destination address IPC, as well as all the other needed parameters. The returned MP_JOIN option contains a valid HMAC computed by Host B.
6. ホストBはSYN / ACK + MP_JOINメッセージを受信します。ホストBはMP_JOINオプションのHMACを検証し、その有効性を確認します。 ACK + MP_JOINパケットで応答します。パケットには、送信元アドレスIPBと宛先アドレスIPC、およびその他の必要なすべてのパラメータが含まれています。返されたMP_JOINオプションには、ホストBによって計算された有効なHMACが含まれています。
7. Host C receives the ACK+MP_JOIN message from B and alters it in the following way. It changes the source address to IPC and the destination address to IPA. It sends the modified packet to Host A, impersonating Host B.
7. ホストCはBからACK + MP_JOINメッセージを受信し、次のように変更します。送信元アドレスをIPCに、宛先アドレスをIPAに変更します。変更されたパケットをホストAに送信し、ホストBを偽装します。
8. Host A receives the ACK+MP_JOIN message and creates the new subflow. At this point, the attacker has managed to place itself as a MitM for one subflow for the existing MPTCP session. It should be noted that the subflow between addresses IPA and IPB that does not flow through the attacker still exists, so the attacker has not completely intercepted all the packets in the communication (yet). If the attacker wishes to completely intercept the MPTCP session, it can do the following additional step.
8. ホストAはACK + MP_JOINメッセージを受信し、新しいサブフローを作成します。この時点で、攻撃者は自分自身を既存のMPTCPセッションの1つのサブフローのMitMとして配置することができました。攻撃者を通過しないアドレスIPAとIPBの間のサブフローがまだ存在するため、攻撃者は通信内のすべてのパケットを完全に傍受していないことに注意してください。攻撃者がMPTCPセッションを完全に傍受したい場合は、次の追加手順を実行できます。
9. Host C sends two TCP RST messages. One TCP RST packet is sent to Host B, with source address IPA, destination address IPB, and source and destination ports PA and PB, respectively. The other TCP RST message is sent to Host A, with source address IPB, destination address IPA, and source and destination ports PB and PA, respectively. Both RST messages must contain a valid sequence number. Note that figuring the sequence numbers to be used here for subflow A is the same difficulty as being able to send the initial ADD_ADDR option with valid sequence number and ACK value. If there are more subflows, then the attacker needs to find the sequence number and ACK for each subflow. At this point, the attacker has managed to fully hijack the MPTCP session.
9. ホストCは2つのTCP RSTメッセージを送信します。 1つのTCP RSTパケットがホストBに送信され、送信元アドレスIPA、宛先アドレスIPB、および送信元ポートと宛先ポートPAおよびPBがそれぞれ送信されます。もう1つのTCP RSTメッセージは、送信元アドレスIPB、宛先アドレスIPA、および送信元ポートと宛先ポートPBおよびPAをそれぞれ使用して、ホストAに送信されます。両方のRSTメッセージには、有効なシーケンス番号が含まれている必要があります。ここでサブフローAに使用されるシーケンス番号を計算することは、有効なシーケンス番号とACK値を使用して最初のADD_ADDRオプションを送信できるのと同じ難しさであることに注意してください。さらにサブフローがある場合、攻撃者は各サブフローのシーケンス番号とACKを見つける必要があります。この時点で、攻撃者はMPTCPセッションを完全に乗っ取ることができました。
Information required by the attacker to perform the described attack:
上記の攻撃を実行するために攻撃者が必要とする情報：
In order to perform this attack the attacker needs to guess or know the following pieces of information. The attacker needs this information for one of the subflows belonging to the MPTCP session.
この攻撃を実行するには、攻撃者は次の情報を推測または知る必要があります。攻撃者は、MPTCPセッションに属するサブフローの1つにこの情報を必要とします。
o the four-tuple {Client-side IP Address, Client-side Port, Server-side Address, Server-side Port} that identifies the target TCP connection
o ターゲットTCP接続を識別する4タプル{クライアント側IPアドレス、クライアント側ポート、サーバー側アドレス、サーバー側ポート}
o a valid sequence number for the subflow
o サブフローの有効なシーケンス番号
o a valid ACK sequence number for the subflow
o サブフローの有効なACKシーケンス番号
o a valid address identifier for IPC
o IPCの有効なアドレス識別子
TCP connections are uniquely identified by the four-tuple {Source Address, Source Port, Destination Address, Destination Port}. Thus, in order to attack a TCP connection, an attacker needs to know or be able to guess each of the values in that four-tuple. Assuming the two peers of the target TCP connection are known, the Source Address and the Destination Address can be assumed to be known.
TCP接続は、4つのタプル{送信元アドレス、送信元ポート、宛先アドレス、宛先ポート}によって一意に識別されます。したがって、TCP接続を攻撃するには、攻撃者はその4つのタプルの各値を知っているか、推測できる必要があります。ターゲットTCP接続の2つのピアが既知であると仮定すると、送信元アドレスと宛先アドレスは既知であると想定できます。
Note: In order to be able to successfully perform this attack, the attacker needs to be able to send packets with a forged source address. This means that the attacker cannot be located in a network where techniques like ingress filtering [RFC2827] or source address validation [RFC7039] are deployed. However, ingress filtering is not as widely implemented as one would expect and hence cannot be relied upon as a mitigation for this kind of attack.
注：この攻撃を成功させるためには、攻撃者は偽造された送信元アドレスでパケットを送信できる必要があります。これは、イングレスフィルタリング[RFC2827]や送信元アドレス検証[RFC7039]などの手法が導入されているネットワークに攻撃者がいることはできないことを意味します。ただし、入力フィルタリングは予想されるほど広く実装されていないため、この種の攻撃の緩和策として信頼することはできません。
Assuming the attacker knows the application protocol for which the TCP connection is being employed, the server-side port can also be assumed to be known. Finally, the client-side port will generally not be known and will need to be guessed by the attacker. The chances of an attacker guessing the client-side port will depend on the ephemeral port range employed by the client and whether or not the client implements port randomization [RFC6056].
攻撃者がTCP接続が使用されているアプリケーションプロトコルを知っていると仮定すると、サーバー側ポートも既知であると想定できます。最後に、クライアント側のポートは一般的に知られておらず、攻撃者が推測する必要があります。攻撃者がクライアント側のポートを推測する可能性は、クライアントが使用する一時的なポート範囲と、クライアントがポートのランダム化を実装しているかどうかによって異なります[RFC6056]。
Assuming TCP sequence number randomization is in place (see e.g., [RFC6528]), an attacker would have to blindly guess a valid TCP sequence number. That is,
TCPシーケンス番号のランダム化が行われている場合（[RFC6528]などを参照）、攻撃者は有効なTCPシーケンス番号を盲目的に推測する必要があります。あれは、
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =<
SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
As a result, the chances of an attacker succeeding will depend on the TCP receive window size at the target TCP peer.
その結果、攻撃者が成功する可能性は、ターゲットTCPピアでのTCP受信ウィンドウサイズに依存します。
Note: Automatic TCP buffer tuning mechanisms have become common for popular TCP implementations; hence, very large TCP window sizes of values up to 2 MB could end up being employed by such TCP implementations.
注：一般的なTCP実装では、自動TCPバッファー調整メカニズムが一般的になっています。したがって、2 MBまでの非常に大きな値のTCPウィンドウサイズは、そのようなTCP実装で採用されることになります。
According to [RFC793], the acknowledgement number is considered valid as long as it does not acknowledge the receipt of data that has not yet been sent. That is, the following expression must be true:
[RFC793]によれば、確認番号は、まだ送信されていないデータの受信を確認しない限り、有効と見なされます。つまり、次の式が真でなければなりません。
SEG.ACK <= SND.NXT
SEG.ACK <= SND.NXT
However, for implementations that support [RFC5961], the following (stricter) validation check is enforced:
ただし、[RFC5961]をサポートする実装では、次の（より厳密な）検証チェックが実施されます。
SND.UNA - MAX.SND.WND <= SEG.ACK <= SND.NXT
Finally, in order for the address identifier to be valid, the only requirement is that it needs to be different from the ones already being used by Host A in that MPTCP session, so a random identifier is likely to work.
最後に、アドレス識別子を有効にするための唯一の要件は、そのMPTCPセッションでホストAがすでに使用しているものとは異なる必要があるため、ランダムな識別子が機能する可能性があります。
Given that a large number of factors affect the chances of an attacker successfully performing the aforementioned off-path attacks, we provide two general expressions for the expected number of packets the attacker needs to send to succeed in the attack: one for MPTCP implementations that support [RFC5961] and another for MPTCP implementations that do not.
攻撃者が前述のオフパス攻撃を成功させる可能性に影響を与える要因が多数ある場合、攻撃者が攻撃を成功させるために送信する必要のある予想パケット数の2つの一般式を提供します。1つはサポートするMPTCP実装用です[RFC5961]と、そうでないMPTCP実装用のもう1つ。
Implementations that do not support RFC 5961:
RFC 5961をサポートしない実装：
Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS
Where the new parameters are:
新しいパラメータは次のとおりです。
Packets: Maximum number of packets required to successfully perform an off-path (blind) attack.
パケット：オフパス（ブラインド）攻撃を成功させるために必要なパケットの最大数。
RCV_WND: TCP receive window size (RCV.WND) at the target node.
RCV_WND：ターゲットノードでのTCP受信ウィンドウサイズ（RCV.WND）。
EPH_PORT_SIZE: Number of ports comprising the ephemeral port range at the "client" system.
EPH_PORT_SIZE：「クライアント」システムでの一時ポート範囲を構成するポートの数。
MSS: Maximum Segment Size, assuming the attacker will send full segments to maximize the chances of getting a hit.
MSS：最大セグメントサイズ。攻撃者がヒットを取得する可能性を最大化するために完全なセグメントを送信すると想定しています。
Notes: The value "2^32" represents the size of the TCP sequence number space.
注：値「2 ^ 32」は、TCPシーケンス番号スペースのサイズを表します。
The value "2" accounts for two different ACK numbers (separated by 2^31) that should be employed to make sure the ACK number is valid.
値「2」は、ACK番号が有効であることを確認するために使用する必要がある2つの異なるACK番号（2 ^ 31で区切られている）を表します。
The following table contains some sample results for the number of required packets, based on different values of RCV_WND and EPH_PORT_SIZE for an MSS of 1500 bytes.
次の表には、1500バイトのMSSのRCV_WNDおよびEPH_PORT_SIZEのさまざまな値に基づく、必要なパケット数のサンプル結果が含まれています。
+-------------+---------+---------+--------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+---------+---------+--------+---------+
| 4000 | 699050 | 87381 | 43690 | 5461 |
+-------------+---------+---------+--------+---------+
| 10000 | 1747626 | 218453 | 109226 | 13653 |
+-------------+---------+---------+--------+---------+
| 50000 | 8738133 | 1092266 | 546133 | 68266 |
+-------------+---------+---------+--------+---------+
Table 1: Maximum Number of Packets for Successful Attack
表1：攻撃が成功した場合の最大パケット数
Implementations that do support RFC 5961:
RFC 5961をサポートする実装：
Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) *
EPH_PORT_SIZE/2 * 1/MSS
Where:
ただし：
Packets: Maximum number of packets required to successfully perform an off-path (blind) attack.
パケット：オフパス（ブラインド）攻撃を成功させるために必要なパケットの最大数。
RCV_WND: TCP receive window size (RCV.WND) at the target MPTCP endpoint.
RCV_WND：ターゲットMPTCPエンドポイントでのTCP受信ウィンドウサイズ（RCV.WND）。
SND_MAX_WND: Maximum TCP send window size ever employed by the target MPTCP endpoint (MAX.SND.WND).
SND_MAX_WND：ターゲットMPTCPエンドポイントで使用された最大TCP送信ウィンドウサイズ（MAX.SND.WND）。
EPH_PORT_SIZE: Number of ports comprising the ephemeral port range at the "client" system.
EPH_PORT_SIZE：「クライアント」システムでの一時ポート範囲を構成するポートの数。
Notes: The value "2^32" represents the size of the TCP sequence number space.
注：値「2 ^ 32」は、TCPシーケンス番号スペースのサイズを表します。
The parameter "MAX.SND.WND" is specified in [RFC5961].
パラメータ「MAX.AND.END」は、[RFC 5961]で指定されています。
The value "2 * SND_MAX_WND" results from the expression "SND.NXT - SND.UNA - MAX.SND.WND", assuming that, for connections that perform bulk data transfers, "SND.NXT - SND.UNA == MAX.SND.WND". If an attacker targets a TCP endpoint that is not actively transferring data, "2 * SND_MAX_WND" would become "SND_MAX_WND" (and hence a successful attack would typically require more packets).
値 "2 * SND_MAX_WND"は、式 "SND.NXT-SND.UNA-MAX.SND.WND"の結果です。一括データ転送を実行する接続では、 "SND.NXT-SND.UNA == MAX。 SND.WND」。攻撃者がデータをアクティブに転送していないTCPエンドポイントを標的とする場合、「2 * SND_MAX_WND」は「SND_MAX_WND」になります（したがって、攻撃を成功させるには通常、より多くのパケットが必要になります）。
The following table contains some sample results for the number of required packets, based on different values of RCV_WND, SND_MAX_WND, and EPH_PORT_SIZE. For these implementations, only a limited number of sample results are provided (as an indication of how [RFC5961] increases the difficulty of performing these attacks).
次の表には、RCV_WND、SND_MAX_WND、およびEPH_PORT_SIZEのさまざまな値に基づいた、必要なパケット数のサンプル結果が含まれています。これらの実装では、限られた数のサンプル結果のみが提供されます（[RFC5961]がこれらの攻撃を実行する難しさをどのように増加させるかの目安として）。
+-------------+-------------+-----------+-----------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+-------------+-----------+-----------+---------+
| 4000 | 45812984490 | 715827882 | 178956970 | 2796202 |
+-------------+-------------+-----------+-----------+---------+
Table 2: Maximum Number of Packets for Successful Attack
表2：攻撃が成功した場合の最大パケット数
Note: In the aforementioned table, all values are computed with RCV_WND equal to SND_MAX_WND.
注：上記の表では、すべての値はRCV_WNDがSND_MAX_WNDに等しい場合に計算されます。
1. To include the token of the connection in the ADD_ADDR option. This would make it harder for the attacker to launch the attack, since the attacker needs to either eavesdrop the token (so this can no longer be a blind attack) or to guess it, but a random 32-bit number is not easy to guess. However, this would imply that any eavesdropper that is able to see the token would be able to launch this attack. This solution then increases the vulnerability window against eavesdroppers from the initial 3-way handshake for the MPTCP session to any exchange of the ADD_ADDR messages.
1. ADD_ADDRオプションに接続のトークンを含める。攻撃者はトークンを盗聴する必要があるため（これはもはやブラインド攻撃ではなくなる可能性があります）、ランダムな32ビットの数値は簡単には推測できないため、攻撃者が攻撃を開始するのは難しくなります。 。ただし、これは、トークンを見ることができる任意の盗聴者がこの攻撃を開始できることを意味します。次に、このソリューションは、MPTCPセッションの最初の3ウェイハンドシェイクからADD_ADDRメッセージの交換まで、盗聴者に対する脆弱性ウィンドウを増やします。
2. To include the HMAC of the address contained in the ADD_ADDR option. The key used for the HMAC is the concatenation of the key of the receiver and the key of the sender (in the same way they are used for generating the HMAC of the MP_JOIN message). This makes it much more secure, since it requires the attacker to have both keys (either by eavesdropping it in the first exchange or by guessing it). Because this solution relies on the key used in the MPTCP session, the protection of this solution would increase if new key generation methods are defined for MPTCP (e.g., using Secure Socket Layer (SSL) keys as has been proposed).
2. ADD_ADDRオプションに含まれるアドレスのHMACを含める。 HMACに使用されるキーは、受信者のキーと送信者のキーを連結したものです（MP_JOINメッセージのHMACの生成に使用されるのと同じ方法で）。これにより、攻撃者は両方のキーを（最初の交換で盗聴するか、推測して）持つ必要があるため、はるかに安全になります。このソリューションはMPTCPセッションで使用されるキーに依存しているため、MPTCPに新しいキー生成方法が定義されている場合（提案されているようにSecure Socket Layer（SSL）キーを使用するなど）、このソリューションの保護が向上します。
3. To include the destination address of the SYN packet in the HMAC of the MP_JOIN message. As the attacker requires changing the destination address to perform the described attack, protecting it would prevent the attack. It wouldn't allow hosts behind NATs to be reached by an address in the ADD_ADDR option, even with static NAT bindings (like a web server at home).
3. MP_JOINメッセージのHMACにSYNパケットの宛先アドレスを含める。攻撃者は、上記の攻撃を実行するために宛先アドレスを変更する必要があるため、保護することで攻撃を防ぐことができます。静的NATバインディング（自宅のWebサーバーなど）を使用している場合でも、NATの背後にあるホストにADD_ADDRオプションのアドレスから到達することはできません。
Of the options described above, option 2 is recommended as it achieves a higher security level while preserving the required functionality (i.e., NAT compatibility).
上記のオプションの中で、必要な機能性（NAT互換性）を維持しながら、より高いセキュリティレベルを実現するため、オプション2をお勧めします。
Summary of the attack:
攻撃の概要：
Type of attack: MPTCP denial-of-service attack, preventing the hosts from creating new subflows
攻撃のタイプ：ホストが新しいサブフローを作成できないようにするMPTCPサービス拒否攻撃
Type of attacker: off-path active attacker
攻撃者のタイプ：オフパスアクティブ攻撃者
Description:
説明：
As currently specified, the initial SYN+MP_JOIN message of the 3-way handshake for additional subflows creates state in the host receiving the message. This is because the SYN+MP_JOIN contains the 32-bit token that allows the receiver to identify the MPTCP session and the 32-bit random nonce used in the HMAC calculation. As this information is not re-sent in the third ACK of the 3-way handshake, a host must create state upon reception of a SYN+MP_JOIN.
現在指定されているように、追加のサブフローの3ウェイハンドシェイクの最初のSYN + MP_JOINメッセージは、メッセージを受信するホストで状態を作成します。これは、SYN + MP_JOINに、受信者がMPTCPセッションとHMAC計算で使用される32ビットのランダムナンスを識別できるようにする32ビットトークンが含まれているためです。この情報は3ウェイハンドシェイクの3番目のACKで再送信されないため、ホストはSYN + MP_JOINの受信時に状態を作成する必要があります。
Assume that an MPTCP session exists between Host A and Host B, with tokens TA and TB. An attacker, sending a SYN+MP_JOIN to Host B, with the valid token TB, will trigger the creation of state on Host B. The number of these half-open connections a host can store per MPTCP session is limited by a certain number and is implementation-dependent. The attacker can simply exhaust this limit by sending multiple SYN+MP_JOINs with different 5-tuples. The (possibly forged) source address of the attack packets will typically correspond to an address that is not in use, or else, the SYN/ACK sent by Host B would elicit a RST from the impersonated node, thus removing the corresponding state at Host B. Further discussion of traditional SYN flooding attacks and common mitigations can be found in [RFC4987].
トークンTAおよびTBを使用して、ホストAとホストBの間にMPTCPセッションが存在するとします。有効なトークンTBでSYN + MP_JOINをホストBに送信する攻撃者は、ホストBで状態の作成をトリガーします。ホストがMPTCPセッションごとに保存できるこれらのハーフオープン接続の数は、特定の数によって制限され、実装依存です。攻撃者は、異なる5タプルを持つ複数のSYN + MP_JOINを送信することで、この制限を使い果たすことができます。攻撃パケットの（おそらく偽造された）送信元アドレスは通常、使用されていないアドレスに対応します。そうでない場合、ホストBから送信されたSYN / ACKは偽装ノードからRSTを引き出し、ホストの対応する状態を削除しますB.従来のSYNフラッディング攻撃および一般的な緩和策の詳細については、[RFC4987]を参照してください。
This effectively prevents Host A from sending any more SYN+MP_JOINs to Host B, as the number of acceptable half-open connections per MPTCP session on Host B has been exhausted.
これにより、ホストBのMPTCPセッションあたりの受け入れ可能なハーフオープン接続の数が使い果たされたため、ホストAがこれ以上SYN + MP_JOINをホストBに送信することが実質的に防止されます。
The attacker needs to know the token TB in order to perform the described attack. This can be achieved if it is a partial-time on-path eavesdropper observing the 3-way handshake of the establishment of an additional subflow between Host A and Host B. If the attacker is never on-path, it has to guess the 32-bit token.
攻撃者は、上記の攻撃を実行するためにトークンTBを知る必要があります。これは、ホストAとホストBの間の追加のサブフローの確立の3ウェイハンドシェイクを監視する部分的な時間のパス盗聴者である場合に達成できます。攻撃者がパス上にない場合は、32を推測する必要があります。ビットトークン。
The third packet of the 3-way handshake could be extended to also contain the 32-bit token and the random nonce that has been sent in the SYN+MP_JOIN. Further, Host B will have to generate its own random nonce in a reproducible fashion (e.g., a hash of the 5-tuple + initial sequence number + local secret). This will allow Host B to reply to a SYN+MP_JOIN without having to create state. Upon the reception of the third ACK, Host B can then verify the correctness of the HMAC and create the state.
3ウェイハンドシェイクの3番目のパケットを拡張して、SYN + MP_JOINで送信された32ビットトークンとランダムナンスも含めることができます。さらに、ホストBは、再現可能な方法で独自のランダムナンスを生成する必要があります（たとえば、5タプル+初期シーケンス番号+ローカルシークレットのハッシュ）。これにより、ホストBは状態を作成せずにSYN + MP_JOINに応答できます。 3番目のACKを受信すると、ホストBはHMACの正当性を検証し、状態を作成できます。
Summary of the attack:
攻撃の概要：
Type of attack: The attacker uses SYN+MP_JOIN messages to amplify the SYN flooding attack.
攻撃のタイプ：攻撃者はSYN + MP_JOINメッセージを使用して、SYNフラッディング攻撃を増幅します。
Type of attacker: off-path active attacker
攻撃者のタイプ：オフパスアクティブ攻撃者
Description:
説明：
SYN flooding attacks [RFC4987] use SYN messages to exhaust the server's resources and prevent new TCP connections. A common mitigation is the use of SYN cookies [RFC4987] that allow stateless processing of the initial SYN message.
SYNフラッディング攻撃[RFC4987]は、SYNメッセージを使用してサーバーのリソースを使い果たし、新しいTCP接続を防ぎます。一般的な緩和策は、最初のSYNメッセージのステートレス処理を可能にするSYNクッキー[RFC4987]の使用です。
With MPTCP, the initial SYN can be processed in a stateless fashion using the aforementioned SYN cookies. However, as described in the previous section, as currently specified, SYN+MP_JOIN messages are not processed in a stateless manner. This opens a new attack vector. The attacker can now open an MPTCP session by sending a regular SYN and creating the associated state but then sending as many SYN+MP_JOIN messages as supported by the server with different combinations of source address and source port, consuming the server's resources without having to create state in the attacker. This is an amplification attack, where the cost on the attacker side is only the cost of the state associated with the initial SYN while the cost on the server side is the state for the initial SYN plus all the state associated with all the following SYN+MP_JOINs.
MPTCPでは、前述のSYN Cookieを使用して、ステートレスな方法で初期SYNを処理できます。ただし、前のセクションで説明したように、現在指定されているように、SYN + MP_JOINメッセージはステートレスな方法では処理されません。これは新しい攻撃ベクトルを開きます。攻撃者は、通常のSYNを送信して関連する状態を作成し、送信元アドレスと送信元ポートのさまざまな組み合わせでサーバーがサポートする数のSYN + MP_JOINメッセージを送信することにより、MPTCPセッションを開くことができるようになり、サーバーのリソースを作成せずに消費します攻撃者の状態。これは増幅攻撃であり、攻撃者側のコストは初期SYNに関連付けられた状態のコストのみであり、サーバー側のコストは初期SYNの状態に加えて、後続のすべてのSYN +に関連付けられたすべての状態です。 MP_JOINs。
1. The solution described for the previous DoS attack on MP_JOIN would also prevent this attack.
1. 以前のMP_JOINに対するDoS攻撃について説明したソリューションも、この攻撃を防ぎます。
2. Limiting the number of half-open subflows to a low number (e.g., three subflows) would also limit the impact of this attack.
2. ハーフオープンサブフローの数を少ない数（たとえば、3つのサブフロー）に制限すると、この攻撃の影響も制限されます。
Summary of the attack:
攻撃の概要：
Type of attack: An eavesdropper present in the initial handshake where the keys are exchanged can hijack the MPTCP session at any time in the future.
攻撃のタイプ：キーが交換される最初のハンドシェイクに存在する盗聴者は、将来いつでもMPTCPセッションを乗っ取ることができます。
Type of attacker: partial-time on-path eavesdropper
攻撃者のタイプ：パス上の部分的な時間の盗聴者
Description:
説明：
In this case, the attacker is present along the path when the initial 3-way handshake takes place and therefore is able to learn the keys used in the MPTCP session. This allows the attacker to move away from the MPTCP session path and still be able to hijack the MPTCP session in the future. This vulnerability was readily identified when designing the MPTCP security solution [RFC6181], and the threat was considered acceptable.
この場合、攻撃者は最初の3ウェイハンドシェイクの発生時にパスに沿って存在するため、MPTCPセッションで使用されるキーを学習できます。これにより、攻撃者はMPTCPセッションパスから離れても、今後もMPTCPセッションをハイジャックすることができます。この脆弱性はMPTCPセキュリティソリューション[RFC6181]を設計する際に容易に特定され、脅威は許容できると見なされました。
There are many techniques that can be used to prevent this attack, and each of them represents different trade-offs. At this point, we limit ourselves to enumerate them and provide useful pointers.
この攻撃を防ぐために使用できる手法は多数あり、それぞれの手法が異なるトレードオフを表しています。この時点で、それらを列挙し、有用なポインタを提供するように制限します。
1. Use of hash chains. The use of hash chains for MPTCP has been explored in [HASH-CHAINS].
1. ハッシュチェーンの使用。 MPTCPのハッシュチェーンの使用は、[HASH-CHAINS]で検討されています。
2. Use of SSL keys for MPTCP security as described in [MPTCP-SSL].
2. [MPTCP-SSL]で説明されている、MPTCPセキュリティのためのSSLキーの使用。
3. Use of Cryptographically Generated Addresses (CGAs) for MPTCP security. CGAs [RFC3972] have been used in the past to secure multi-addressed protocols like Shim6 [RFC5533].
3. MPTCPセキュリティのための暗号生成アドレス（CGA）の使用。 CGA [RFC3972]は、Shim6 [RFC5533]のようなマルチアドレスプロトコルを保護するために過去に使用されてきました。
4. Use of tcpcrypt [TCPCRYPT].
4. tcpcrypt [TCPCRYPT]の使用。
5. Use of DNSSEC. DNSSEC has been proposed to secure the Mobile IP protocol [DNSSEC].
5. DNSSECの使用。 DNSSECは、モバイルIPプロトコル[DNSSEC]を保護するために提案されました。
Summary of the attack:
攻撃の概要：
Type of attack: An attacker that can intercept the SYN/JOIN message can alter the source address being added.
攻撃の種類：SYN / JOINメッセージを傍受できる攻撃者は、追加される送信元アドレスを変更できます。
Type of attacker: partial-time on-path eavesdropper
攻撃者のタイプ：パス上の部分的な時間の盗聴
Description:
説明：
The attacker is present along the path when the SYN/JOIN exchange takes place. This allows the attacker to add any new address it wants to by simply substituting the source address of the SYN/JOIN packet for one it chooses. This vulnerability was readily identified when designing the MPTCP security solution [RFC6181], and the threat was considered acceptable.
攻撃者は、SYN / JOIN交換が行われるとき、パスに沿って存在します。これにより、攻撃者は、SYN / JOINパケットの送信元アドレスを選択したアドレスに置き換えるだけで、必要な新しいアドレスを追加できます。この脆弱性はMPTCPセキュリティソリューション[RFC6181]を設計する際に容易に特定され、脅威は許容できると見なされました。
It should be noted that this vulnerability is fundamental due to the NAT support requirement. In other words, MPTCP must work through NATs in order to be deployable in the current Internet. NAT behavior is unfortunately indistinguishable from this attack. It is impossible to secure the source address, since doing so would prevent MPTCP from working through NATs. This basically implies that the solution cannot rely on securing the address. A more promising approach would be to look into securing the payload exchanged and thus limiting the impact that the attack would have in the communication (e.g., tcpcrypt [TCPCRYPT] or similar).
NATのサポート要件により、この脆弱性は根本的なものであることに注意してください。つまり、現在のインターネットに展開できるようにするには、MPTCPがNATを介して機能する必要があります。残念ながら、NATの動作はこの攻撃と区別がつきません。送信元アドレスを保護すると、MPTCPがNATを介して機能しなくなるため、保護することはできません。これは基本的に、ソリューションがアドレスの保護に依存できないことを意味します。より有望なアプローチは、交換されたペイロードを保護し、攻撃が通信に与える影響を制限することです（tcpcrypt [TCPCRYPT]など）。
The current MPTCP specification [RFC6824] is Experimental. There is an ongoing effort to move it to Standards Track. We believe that the work on MPTCP security should follow two threads:
現在のMPTCP仕様[RFC6824]は実験的です。スタンダードトラックに移行するための継続的な取り組みがあります。 MPTCPセキュリティに関する作業は、次の2つのスレッドに従う必要があると考えています。
o The work on improving MPTCP security so that the MPTCP specification [RFC6824] can become a Standards Track document.
o MPTCP仕様[RFC6824]が規格トラックドキュメントになることができるように、MPTCPセキュリティを改善する作業。
o The work on analyzing possible additional security enhancements to provide a more secure version of MPTCP.
o より安全なバージョンのMPTCPを提供するために考えられる追加のセキュリティ強化を分析する作業。
We expand on these in the following subsections.
以下のサブセクションでは、これらについて詳しく説明します。
We believe that in order for MPTCP to progress to Standards Track, the ADD_ADDR attack must be addressed. We believe that the solution that should be adopted in order to deal with this attack is to include an HMAC to the ADD_ADDR message (with the address being added used as input to the HMAC as well as the key). This would make the ADD_ADDR message as secure as the JOIN message. In addition, this implies that if we implement a more secure way to create the key used in the MPTCP connection, then the security of both the MP_JOIN and the ADD_ADDR messages is automatically improved (since both use the same key in the HMAC).
MPTCPが標準トラックに進むためには、ADD_ADDR攻撃に対処する必要があると考えています。この攻撃に対処するために採用する必要がある解決策は、ADD_ADDRメッセージにHMACを含めることです（追加されるアドレスは、HMACへの入力として使用され、キーも使用されます）。これにより、ADD_ADDRメッセージはJOINメッセージと同じくらい安全になります。さらに、これは、MPTCP接続で使用されるキーを作成するより安全な方法を実装すると、MP_JOINメッセージとADD_ADDRメッセージの両方のセキュリティが自動的に向上することを意味します（両方がHMACで同じキーを使用するため）。
We believe that this is enough for MPTCP to progress as a Standards Track document because the security level is similar to single-path TCP per our previous analysis. Moreover, the security level achieved with these changes is exactly the same as other Standards Track documents. In particular, this would be the same security level as SCTP with dynamic addresses as defined in [RFC5061]. The Security Considerations section of RFC 5061 (which is a Standards Track document) reads:
これまでの分析によると、セキュリティレベルはシングルパスTCPに類似しているため、これはMPTCPが標準トラックドキュメントとして進展するのに十分であると考えています。さらに、これらの変更によって達成されるセキュリティレベルは、他の標準化トラックドキュメントとまったく同じです。特に、これは[RFC5061]で定義されている動的アドレスを持つSCTPと同じセキュリティレベルになります。 RFC 5061（Standards Trackドキュメント）のセキュリティに関する考慮事項のセクションには、次のように記載されています。
The addition and or deletion of an IP address to an existing association does provide an additional mechanism by which existing associations can be hijacked. Therefore, this document requires the use of the authentication mechanism defined in [RFC4895] to limit the ability of an attacker to hijack an association.
既存のアソシエーションへのIPアドレスの追加または削除は、既存のアソシエーションをハイジャックできる追加のメカニズムを提供します。したがって、このドキュメントでは、アソシエーションをハイジャックする攻撃者の能力を制限するために、[RFC4895]で定義されている認証メカニズムを使用する必要があります。
Hijacking an association by using the addition and deletion of an IP address is only possible for an attacker who is able to intercept the initial two packets of the association setup when the SCTP-AUTH extension is used without pre-shared keys. If such a threat is considered a possibility, then the [RFC4895] extension MUST be used with a preconfigured shared endpoint pair key to mitigate this threat.
IPアドレスの追加と削除を使用してアソシエーションをハイジャックできるのは、事前共有キーなしでSCTP-AUTH拡張が使用されている場合、アソシエーションセットアップの最初の2つのパケットを傍受できる攻撃者のみです。そのような脅威が可能性と考えられる場合、[RFC4895]拡張機能を事前構成済みの共有エンドポイントペアキーと共に使用して、この脅威を軽減する必要があります。
This is the same security level that would be achieved by MPTCP with the addition of the ADD_ADDR security measure recommended in this document.
これは、このドキュメントで推奨されているADD_ADDRセキュリティ対策を追加したMPTCPによって達成されるセキュリティレベルと同じです。
We also believe that is worthwhile to explore alternatives to secure MPTCP. As we identified earlier, the problem of securing JOIN messages is fundamentally incompatible with NAT support, so it is likely that a solution to this problem involves the protection of the data itself. Exploring the integration of MPTCP and approaches like tcpcrypt [TCPCRYPT] and exploring integration with SSL seem promising.
また、セキュアなMPTCPの代替策を模索することは価値があると考えています。前述のように、JOINメッセージのセキュリティ保護の問題は、NATサポートと根本的に互換性がないため、この問題の解決策にはデータ自体の保護が含まれる可能性があります。 MPTCPとtcpcrypt [TCPCRYPT]のようなアプローチの統合を探索し、SSLとの統合を探索することは有望なようです。
This whole document is about security considerations for MPTCP.
このドキュメント全体は、MPTCPのセキュリティに関する考慮事項です。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、DOI 10.17487 / RFC3972、2005年3月、<http://www.rfc-editor.org/info/rfc3972>。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <http://www.rfc-editor.org/info/rfc4895>.
[RFC4895] Tuexen、M.、Stewart、R.、Lei、P。、およびE. Rescorla、「Authenticated Chunks for the Stream Control Transmission Protocol（SCTP）」、RFC 4895、DOI 10.17487 / RFC4895、2007年8月、<http ：//www.rfc-editor.org/info/rfc4895>。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <http://www.rfc-editor.org/info/rfc5061>.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）Dynamic Address Reconfiguration」、RFC 5061、DOI 10.17487 / RFC5061、9月2007、<http://www.rfc-editor.org/info/rfc5061>。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <http://www.rfc-editor.org/info/rfc5961>.
[RFC5961]ラマイア、A。、スチュワート、R。、およびM.ダラル、「ウィンドウ内のブラインド攻撃に対するTCPの堅牢性の向上」、RFC 5961、DOI 10.17487 / RFC5961、2010年8月、<http：//www.rfc- editor.org/info/rfc5961>。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、DOI 10.17487 / RFC6056、2011年1月、<http://www.rfc-editor.org/info / rfc6056>。
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, <http://www.rfc-editor.org/info/rfc6528>.
[RFC6528] Gont、F。、およびS. Bellovin、「Defendering Sequence Sequence Attacks」、RFC 6528、DOI 10.17487 / RFC6528、2012年2月、<http://www.rfc-editor.org/info/rfc6528>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを使用したマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<http：// www.rfc-editor.org/info/rfc6824>。
[DNSSEC] Kukec, A., Bagnulo, M., Ayaz, S., Bauer, C., and W. Eddy, "ROAM-DNSSEC: Route Optimization for Aeronautical Mobility using DNSSEC", 4th ACM International Workshop on Mobility in the Evolving Internet Architecture (MobiArch), 2009.
[DNSSEC] Kukec、A.、Bagnulo、M.、Ayaz、S.、Bauer、C。、およびW. Eddy、「ROAM-DNSSEC：Route Optimization for Aeronautical Mobility using DNSSEC」、第4回ACM International Workshop on the Mobility in the進化するインターネットアーキテクチャ（MobiArch）、2009年。
[HASH-CHAINS] Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security for multipath TCP: a constructive approach", International Journal of Internet Protocol Technology, Vol. 6, No. 3, 2011.
[ハッシュチェーン] Diez、J.、Bagnulo、M.、Valera、F。、およびI. Vidal、「マルチパスTCPのセキュリティ：建設的アプローチ」、International Journal of Internet Protocol Technology、Vol。 6、No。3、2011。
[MPTCP-SSL] Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP handshake with external keys", Work in Progress, draft-paasch-mptcp-ssl-00, October 2012.
[MPTCP-SSL] Paasch、C。およびO. Bonaventure、「外部キーによるマルチパスTCPハンドシェイクの保護」、作業中、draft-paasch-mptcp-ssl-00、2012年10月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<http：// www .rfc-editor.org / info / rfc2827>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<http://www.rfc-editor.org/info/rfc4960>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987] Eddy、W。、「TCP SYN Flooding Attacks and Common Mitigations」、RFC 4987、DOI 10.17487 / RFC4987、2007年8月、<http://www.rfc-editor.org/info/rfc4987>。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5533] Nordmark、E。およびM. Bagnulo、「Shim6：Level 3 Multihoming Shim Protocol for IPv6」、RFC 5533、DOI 10.17487 / RFC5533、2009年6月、<http://www.rfc-editor.org/info/ rfc5533>。
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011, <http://www.rfc-editor.org/info/rfc6181>.
[RFC6181] Bagnulo、M。、「Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses」、RFC 6181、DOI 10.17487 / RFC6181、2011年3月、<http://www.rfc-editor.org/info/rfc6181> 。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「Mobility Support in IPv6」、RFC 6275、DOI 10.17487 / RFC6275、2011年7月、<http：//www.rfc-editor。 org / info / rfc6275>。
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <http://www.rfc-editor.org/info/rfc7039>.
[RFC7039] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F。、およびC. Vogt、編、「Source Address Validation Improvement（SAVI）Framework」、RFC 7039、DOI 10.17487 / RFC7039、 2013年10月、<http://www.rfc-editor.org/info/rfc7039>。
[TCPCRYPT] Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, D., and Q. Slack, "Cryptographic protection of TCP Streams (tcpcrypt)", Work in Progress, draft-bittau-tcp-crypt-04, February 2014.
[TCPCRYPT] Bittau、A.、Boneh、D.、Hamburg、M.、Handley、M.、Mazieres、D。、およびQ. Slack、「TCPストリームの暗号化保護（tcpcrypt）」、作業中、ドラフト- bittau-tcp-crypt-04、2014年2月。
Acknowledgements
謝辞
We would like to thank Mark Handley for his comments on the attacks and countermeasures discussed in this document. We would also like to thank to Alissa Cooper, Phil Eardley, Yoshifumi Nishida, Barry Leiba, Stephen Farrell, and Stefan Winter for their comments and reviews.
この文書で説明されている攻撃と対策に関するコメントを提供してくれたMark Handleyに感謝します。また、コメントやレビューをいただいたアリッサクーパー、フィルヤードリー、西田喜文、バリーレイバ、スティーブンファレル、ステファンウィンターにも感謝いたします。
Marcelo Bagnulo, Christoph Paasch, Oliver Bonaventure, and Costin Raiciu are partially funded by the EU Trilogy 2 project.
Marcelo Bagnulo、Christoph Paasch、Oliver Bonaventure、およびCostin Raiciuは、EU Trilogy 2プロジェクトによって部分的に資金提供されています。
Authors' Addresses
著者のアドレス
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
Marcelo Bagnulo Carlos IIIマドリード大学Av。Universidad 30 Leganes、Madrid 28911 Spain
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Christoph Paasch UCLouvain
クリストフ・パーシュUCLouvain
Email: christoph.paasch@gmail.com
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンドゴンSI6ネットワーク/ UTN-FRHエヴァリストキャリーゴ2644ブエノスアイレス州ハエド1706アルゼンチン
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Olivier Bonaventure UCLouvain Place Sainte Barbe, 2 Louvain-la-Neuve, 1348 Belgium
Olivier Bonaventure UCLouvain Place Sainte Barbe、2 Louvain-la-Neuve、1348ベルギー
Email: olivier.bonaventure@uclouvain.be
Costin Raiciu Universitatea Politehnica Bucuresti Splaiul Independentei 313a Bucuresti Romania
Costin Raiciu Polytechnic University of Bucharest Splaiul Independentei 313aブカレストルーマニア
Email: costin.raiciu@cs.pub.ro