[multipathtcp] q about draft-paasch-mptcp-application-authentication-00
Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 07 June 2016 15:04 UTC
Return-Path: <nishida@sfc.wide.ad.jp>
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 3A8FF12D768 for <multipathtcp@ietfa.amsl.com>; Tue, 7 Jun 2016 08:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zQFKLIxTL-G8 for <multipathtcp@ietfa.amsl.com>; Tue, 7 Jun 2016 08:04:29 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5D812D75A for <multipathtcp@ietf.org>; Tue, 7 Jun 2016 08:04:22 -0700 (PDT)
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DC1472784B7 for <multipathtcp@ietf.org>; Wed, 8 Jun 2016 00:04:20 +0900 (JST)
Received: by mail-yw0-f171.google.com with SMTP id o16so172378178ywd.2 for <multipathtcp@ietf.org>; Tue, 07 Jun 2016 08:04:20 -0700 (PDT)
X-Gm-Message-State: ALyK8tLxsfA74aCZt1aIqLI+p1rLaX1FmIQx1s6vrGCuYzdgkP8SnnDJRT99PVmR+R3XVo2xfD5MBiM9q6CGmQ==
X-Received: by 10.129.81.151 with SMTP id f145mr15846749ywb.266.1465311859444; Tue, 07 Jun 2016 08:04:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.196.3 with HTTP; Tue, 7 Jun 2016 08:04:19 -0700 (PDT)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Tue, 07 Jun 2016 08:04:19 -0700
X-Gmail-Original-Message-ID: <CAO249yfkoF8oRzEbQHjxbJ3kuUX2m_GdCyvzzCWy+yxPqG5=3w@mail.gmail.com>
Message-ID: <CAO249yfkoF8oRzEbQHjxbJ3kuUX2m_GdCyvzzCWy+yxPqG5=3w@mail.gmail.com>
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="001a1145696ade3c120534b180d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/ML1Ok0wY4vjSw0KTSAnDzHGcoDc>
Subject: [multipathtcp] q about draft-paasch-mptcp-application-authentication-00
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 07 Jun 2016 15:04:31 -0000
Hello, I might need a bit more time to think about this, but I currently have a few questions on the draft. 1: I am wondering if this is an asymmetric scheme. I mean, if it can be possible to use a token with G flag on one side, while a key without G flag is used on the other side. It seems to me that the draft is a bit unclear on this point, but I am guessing this might be typical for load-balancer use case. I don't see incentive for client to use G flag in this case. 2: How we should react if G and H flags are set in a packet? 3: key-A and key-B in figure 2 might be token-A and token-B? (presume G flag is used) Thanks, -- Yoshi
- [multipathtcp] q about draft-paasch-mptcp-applica… Yoshifumi Nishida
- Re: [multipathtcp] q about draft-paasch-mptcp-app… Christoph Paasch
- Re: [multipathtcp] q about draft-paasch-mptcp-app… Alan Ford
- Re: [multipathtcp] q about draft-paasch-mptcp-app… Yoshifumi Nishida