Re: [multipathtcp] A question related to the 4th ACK in the MP_JOIN handshake

"Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <matthew.t.sargent@nasa.gov> Thu, 13 April 2017 14:52 UTC

Return-Path: <matthew.t.sargent@nasa.gov>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA18129481 for <multipathtcp@ietfa.amsl.com>; Thu, 13 Apr 2017 07:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nasa.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsmGe5wA6nV8 for <multipathtcp@ietfa.amsl.com>; Thu, 13 Apr 2017 07:52:38 -0700 (PDT)
Received: from ndjsvnpf104.ndc.nasa.gov (NDJSVNPF104.ndc.nasa.gov [198.117.1.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EA61205D3 for <multipathtcp@ietf.org>; Thu, 13 Apr 2017 07:52:38 -0700 (PDT)
X-Comment: SPF check N/A for local connections - client-ip=198.117.1.198; helo=ndjsppt104.ndc.nasa.gov; envelope-from=matthew.t.sargent@nasa.gov; receiver=multipathtcp@ietf.org
DKIM-Filter: OpenDKIM Filter v2.11.0 ndjsvnpf104.ndc.nasa.gov 62DF04022B41
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=letsgomars; t=1492095157; bh=7PYvyplHOx1nadHL2MuwdXWsO7/HNY26e5fvILJ79PY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=BrocKwRYv1tjiXlmf3L/dOGRuB1+ge2UVdK3EIlNNOIHlnxqa/zasRoRyFAoomqO+ SgfoLhO6TG//RwNBVv+MRSEZOalHWs4o420rX1yJ8N/V8H5x2Tyr9RdafogaxjK1JF J7Th6nS8Qw4zUoGERVhqVmXCsqMh7QYbcf9zYw1VgYiTKDAtKEOwPTEnsOTgApL+a2 +uSknZTrOhDxOdDuFWFZ13hGivmK+1j8pycLe28k9pXq9ZSWrjdRgknBxBIY8j4Oio 6cIBaAe7MTL/mKH0IiOAeUYE37xNBPvUybRld20AMAJ7XGj9qoGUzOrRsOKfRML9jN iIXlmwkTEsfqA==
Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndjsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 62DF04022B41; Thu, 13 Apr 2017 09:52:37 -0500 (CDT)
Received: from pps.filterd (ndjsppt104.ndc.nasa.gov [127.0.0.1]) by ndjsppt104.ndc.nasa.gov (8.16.0.20/8.16.0.20) with SMTP id v3DEpmdU004713; Thu, 13 Apr 2017 09:52:37 -0500
Received: from ndjscht116.ndc.nasa.gov (ndjscht116-pub.ndc.nasa.gov [198.117.1.216]) by ndjsppt104.ndc.nasa.gov with ESMTP id 29t9x5geed-1; Thu, 13 Apr 2017 09:52:37 -0500
Received: from NDJSMBX102.ndc.nasa.gov ([169.254.5.32]) by NDJSCHT116.ndc.nasa.gov ([198.117.1.186]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 09:52:36 -0500
From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <matthew.t.sargent@nasa.gov>
To: Shuai Wang <13211134@bjtu.edu.cn>
CC: multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] A question related to the 4th ACK in the MP_JOIN handshake
Thread-Index: AQHStD+YzvgdzJGQOEOqE3JRFf2r2aHDtn6A
Date: Thu, 13 Apr 2017 14:52:36 +0000
Message-ID: <C7FF554A-305E-46E9-8EE6-39B6A68323CF@nasa.gov>
References: <f94160e.4c46b.15b667cb4d6.Coremail.13211134@bjtu.edu.cn>
In-Reply-To: <f94160e.4c46b.15b667cb4d6.Coremail.13211134@bjtu.edu.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.88.44.39]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DD1FBF4C05E20A4C8F425385B91FE136@mail.nasa.gov>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-13_11:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/zXUCmLO7N8lRIZ_T8950aUJgCow>
Subject: Re: [multipathtcp] A question related to the 4th ACK in the MP_JOIN handshake
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 14:52:39 -0000

Hi Shuai,

> On Apr 13, 2017, at 4:45 AM, Shuai Wang <13211134@bjtu.edu.cn> wrote:
> 
>     As it is said in RFC 6824 that the 4th ACK packet (for responding ACK/MP_JOIN packet) is necessary in MP_JOIN handshake before sending data. And the reason is that "The initiator's authentication information is sent in its first ACK(the third packet of the handshake). This data needs to be sent reliably, since it is the only time this HMAC is sent; therefore, receipt of this packet MUST trigger a regulat TCP ACK in response, and the packet MUST be retransmitte if this ACK is not received."
> 
>     But in my opinion, the receiver can check whether this HMAC included in the third ACK is correct, so the receiver can know whether the sender is the original sender or not. For the above considerations, I think the 4th ACK packet is unnecessary. 
> 
>     If my opinion is wrong, please help me to correct. Thank you very much!
> 

The trick here is to think of this from the other direction. Suppose Host A opens a connection to Host B and that Host A sends the third packet of the handshake (ACK with HMAC information).

You are correct that if Host B receives this packet it has enough information to authenticate Host A or not. The problem is that Host A does not know whether Host B has received this packet and authenticated Host A or not. This is the purpose of the fourth ACK of the handshake. It lets Host A know that it has been authenticated and that it can send data to Host B.

Suppose the spec changed and we no longer have to send the fourth packet of the handshake. After Host A sends the third packet of the handshake you get two scenarios:

(1) Third packet of the handshake is lost. If A sends data to Host B right now Host B cannot accept the data since Host A has not been authenticated.

(2) Third packet of the handshake is received by Host B. If A sends data to Host B right now Host B could accept the data since Host A has been authenticated.

Note that with the changed spec Host A does not have enough information to decide which case is true for a particular connection. 


The fourth ACK in the handshake removes the ambiguity for Host A:

(a) Third packet of the handshake is lost. Host A, expecting an ACK, is able to timeout and retransmit. 

(b) Third packet of the handshake is received. Host B sends an ACK, but the ACK is lost. Host A, expecting an ACK, is able to timeout and retransmit.

(c) The third packet of the handshake is received. Host B sends an ACK and Host A receives the ACK and now knows that it has been authenticated and can send data.


The fourth ACK gives an explicit signal to Host A that is has been authenticated and is able to send data to Host B. Even with some loss, if (a) or (b) occur, the retransmissions should eventually lead to (c). Once (c) happens, Host A has enough information to know that it should be able to send data to Host B.

Please let me know if that made sense or not.


Thanks,
Matt